Long overdue, I have finally shut down the remaining core infrastructure of Cluenet.org, namely the website, LDAP directory, and Kerberos KDCs.
I joined Cluenet almost 10 years ago (Aug 2008), and back then it was a popular shell account provider – certainly not the largest, but the only place where people were interested more in system administration than running IRC bouncers and Eggdrop bots. (I mean, have you seen Kerberos outside a large corporate installation recently?) Besides that, it also had somewhat unusual IRC policies and a signup process that involved a questionnaire/introduction letter of sorts, which I somehow memed my way through.
A few years later, the number of people had dwindled, the original owners had left for greener pastures, and I had somehow inherited root access to the central servers. I think by 2012 I was the only one to run the place?…
I was planning to keep the services around for as long as there was even a single host or person using it, but I'm sure that six years is enough. I mean, it's not a technical burden (indeed the same servers now run my own Nullroute LDAP directory anyway), but just seeing it gets me down every time. And on top of that, I still have no control over the DNS domain – nobody knows if the original owners will renew it next January, or whether it will expire again.
So I deleted 481 user accounts, wiped clean all the server ACLs, old signup essays, Kerberos principals, et cetera. It now exists only as an IRC channel and a couple of tarballs in my backup disks. Nobody's going to miss it.
My Dell laptop has recently started showing “Checking media” on every boot, before reaching the bootloader. At first I thought it has something to do with the EFI system partition, but that's not the case.
This message is shown when Dell firmware is trying to PXE-boot from the network, in which the first step is of course to verify the Ethernet connection – the 'media'. This can take up to several seconds when there's no cable, and Dell does it once for the IPv4-capable loader, and again for the IPv6-capable one.
So its presence means the UEFI boot order got reshuffled and somehow the built-in “Onboard LAN IPv4” and “Onboard LAN IPv6” entries have highest priority. (Usually the boot order on Dell UEFI systems looks like this: custom OS entry; built-in “PXE” entries; built-in fallback “HDD” entries; built-in “BIOS mode” (CSM) entries.)
What it also very likely means is that the custom OS-prepared boot entry has disappeared completely, and the computer only boots thanks to the fallback \EFI\BOOT\BOOTX64.EFI loader that happens to be present.
Fortunately this is easy to repair. On my Arch Linux system (which uses systemd-boot), the convenient way is “bootctl install”. Windows 10 systems can be repaired by running “bcdboot c:\windows”. The rest – by very carefully using efibootmgr.
(Alternatively, of course, the fallback “HDD1-1” boot entry could be moved to the front, before PXE, but that's just lazy.)
More from the series of “grawity is hopelessly obsessed with networks”, and because this journal is looking a bit sad & empty at the moment, here's what I've been into recently.
A while ago (two years ago) I signed up on the dn42 network to play around with routing and BGP for a bit. It's a large overlay network that simulates the Internet – in the sense that participants set up their own “autonomous systems”, create WHOIS entries, and set up BGP peerings; although the nodes are connected using just about anything except physical links (IPsec, GRE, IPsec/GRE, OpenVPN, Wireguard, L2TP)... There also are seriously flaky links to parts of freifunk and ChaosVPN.
The second network is Internet – after switching IPv6 tunnels many times, I have obtained an AS number and an IPv6 prefix of my own. (Technically it's still a provider-aggregated prefix but that doesn't stop me from announcing it, primarily via Tunnelbroker and NetAssist.) So now I'm building my own IPv6 tunnels with GRE, OSPF, ZeroTier, and wet string.
(Actually the first time I joined dn42 was three years ago – it seems I have a habit of picking something up, forgetting it after a month or two, and a year later picking it up again for reals. Which, incidentally, is also what happened with the LISP beta network.)
Finally I'm experimenting with LISP – “Locator/Identifier Separation Protocol”, it's a relatively new protocol and one of the proposals brought to IETF for improving the scalability of the global routing table. (It turns out that allowing every nerd to announce their own /48 over shitty ADSL doesn't work all that well.) The current LISP Beta Network is similar in purpose to e.g. the 6BONE network; it's built by several big-name companies, but anyone is allowed to join and obtain a range of EIDs for themselves.
(Interestingly, the IPv4 EIDs provided by LISPnet belong to “Usenix/UUNET Technology Inc.” according to ARIN WHOIS lookup – which is not trivial to perform, as IANA's WHOIS server thinks the addresses belong to APNIC, and APNIC thinks you should ask IANA. The IPv6 EIDs, meanwhile, are just an ordinary Cisco netblock.)