When my sisters came out to visit yesterday, they brought what's left of Dad's PC (an old Q6600 that was a very nice machine in it's heyday) with them so that I can try and put it back together. His PSU blew out a while back, and conveniently didn't take much with it, but we cannibalized the hard drive to fix Mum's DVR last time I was out there, so he was missing that too.
So I sorted through my stuff to work out what I had laying around... a no-name PSU of questionable quality, and an old Antec semi-modular that's supposedly 430W. That'll probably do the trick. I also scavenged a 320GB and a 200GB hard drive from the machine I got to use as a case for Duncan's PC. I put everything together, fired it up... nothing.
Turns out that one RAM slot is no good for some reason. Three sticks in, it's fine. Four sticks? No POST. Interestingly, it's not the RAM stick, as if I swap them around it still POSTs fine as long as the fourth slot is empty. Once I figured that out though, no video. The fan doesn't spin, and is very stiff, so I'm suspecting it's cooked. That's not really a problem, as I have an old 7950GT I've been trying to give away that's actually an upgrade from this little piece of shit, so I put that in too.
Installed Windows on the 320GB disk, and it keeps freezing (but recovering). I suspect that's hard disk related, so I checked the Event Viewer, and sure enough it's having to send resets to the device. So I threw that drive away, and installed again on the 200GB disk, which worked fine.
Final hurdle: drivers for this ancient Nvidia card. Couldn't automatically find them, but searching around manually found me the GeForce driver 309.08 which supports the 7950GT on Windows 8, 7 and Vista, but installed without a hiccup on 10 and worked flawlessly.
Windows wouldn't activate, but that's Dad's problem... he should have a license for it, having bounced through 7 (this machine was originally Vista).
While stuffing about trying to upgrade this ancient infrastructure, Atheme promptly exploded in a core-dump. I guessed (correctly) that it was related to the old configuration file being used on a newer version, rewrote the configuration file, and off we went. After I got everything mostly squared away, I decided to come back and take a look and see if there was anything interesting to it.
I built it on my local box, installed ratbox, hacked up the configuration file and... boom. Core files aren't dropping on my box, so I just ran it inside of gdb, to catch the backtrace:
Program received signal SIGSEGV, Segmentation fault.
29 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory.
#0 __strcmp_sse2_unaligned ()
#1 0x00007ffff5ffe2a0 in m_pass (si=<optimized out>, parc=4,
parv=0x7fffffffdb30) at ts6-generic.c:1202
#2 0x00007ffff5df9cff in irc_parse (line=<optimized out>) at parse.c:176
#3 0x00007ffff772ea1e in irc_recvq_handler (cptr=<optimized out>)
#4 0x00007ffff7726581 in recvq_put (cptr=0x607b30) at datastream.c:266
#5 0x00007ffff798c713 in mowgli_epoll_eventloop_select (
eventloop=0x7ffff7e43f70, delay=<optimized out>) at epoll_pollops.c:188
#6 0x00007ffff798d6a4 in mowgli_simple_eventloop_timeout_once (
eventloop=0x7ffff7e43f70, timeout=<optimized out>) at null_pollops.c:57
#7 0x00007ffff798cd94 in mowgli_eventloop_run_once (eventloop=0x7ffff7e43f70)
#8 0x00007ffff773480d in io_loop () at send.c:77
#9 0x00007ffff771a957 in atheme_main (argc=<optimized out>,
argv=0x7fffffffe338) at atheme.c:442
#10 0x00007ffff737bb45 in __libc_start_main (main=0x4005c0 <main>, argc=2,
argv=0x7fffffffe338, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe328) at libc-start.c:287
#11 0x00000000004005ee in _start ()
Frame #1 suggests it's in m_pass, which if atheme is anything like an IRC, means the function despatched to handle PASS messages. Knowing what I know about the configuration file that triggered it, I suspect I know where this is going, and sure enough line 1202 of ts6-generic.c looks like this:
if (strcmp(curr_uplink->receive_pass, parv))
At this point I was pretty sure
curr_uplink->receive_pass is a null pointer, but I hacked in some debug printf()s to be sure and yep:
[2017-07-12 22:22:13] uplink_add(): services.int -> hades.arpa:6667 - 14584490 0
The first is send_password, which was set, the second, is receive_password, which wasn't on this old configuration (because at the time it was set up, Atheme didn't check the password the server sent). I thought that it was perhaps simply not checked, but in fact none of these things are... A null send_pass simply doesn't do anything because it's expanded to (null) when the services sends it's PASS message:
[2017-07-12 22:33:14] <- PASS (null) TS 6 :00A
... which we get away with. So it's probably not even worth fixing - how many people are going to run into a situation where they have the exact same brain-dead configuration file we had? I reported it in the Atheme IRC channel and that'll do.
Update: @grawity noted in IRC that invalid configuration files shouldn't cause a crash, and filed a pull request to fix it. I'm rather happy that despite the fact I know very little about the Atheme codebase these days, it's about what I'd have done to fix the issue too (though I hadn't noticed it affects other protocols as well).
Well, we abandoned the Slackware experiment, and I started configuring a de-systemd'd Debian installation, when my co-admin Avi admitted defeat: "I'd rather you used FreeBSD than Debian if you can't run Slackware". We went back and forth about how Slackware was a "man's distro", and how "real men" don't need dependency tracking and somesuch, but my objective in this is to lower the administrative burden (Debian was pretty low to start with) so I just installed FreeBSD, because it's what I know (it's worth noting that around the time of making this decision, I upgraded my own IRC box, and everything on it, from 10.3 to 11.0 with nary a hitch - I had some minor downtime because I upgraded PostgreSQL and forgot how to do it, and also got bit by a bug in DigitialOcean's networking scripts).
Everything was going swimmingly, barring a few hangups like Atheme services seemingly no longer supporting Hybrid IRCd in the upgraded version (looks like it's been a while, whoops!). I swapped the IPs over, and discovered that the IPv6 wouldn't go with it. Filed a ticket and found out that no, auto-configured IPv6 couldn't be transferred, even by support. Damn it. Oh well, we hardly use that, I don't even think there are any A records, so not much of a workload to change it around.
They suggested they assign me a /116 pool, that I could route between my Linodes in the same DC as I see fit. That sounds like exactly what I want, so we pulled the trigger. I set it up by loosely translating Linode's documentation for several Linux distros to FreeBSD, and... nothing. Couldn't route packets either direction. Upon inspection, I note that it's trying to route the packets via
fe80::1, which is only bound to localhost. IPv6 is mostly voodoo to me, but I don't see that working.
Configured the interface to accept router solicitations, started rtsold and watched, turns out I need to specify the interface on the router on FreeBSD, so the magic source in
2600::1/116 with your IPv6 address and prefixlen)
After a reboot, everything came up and functioned correctly.
Update: Functioned correctly for a few hours anyway. I clearly need to hit some books on IPv6 - it seems like
rtsold advertised my VM to the router, and when I killed it, that advertisement expired.
rtsold appears to have to continue running? I'll have to investigate further.
I run a small community shell server for a group that's going on about 20 years old, I'm sure I've mentioned it here before. We're running Debian Wheezy LTS, which is coming up on it's EOL this year, but the registrant of the domain has gone AWOL and it was going to expire shortly thereafter, so I'd not really been bothering... if the domain expires, I'll simply shitcan the box and that'll be the end of an era.
Well, the day before yesterday my friend Avi figured out that he was in fact the registrant, when someone else tried to scam Wild West Domains into transferring the domain to them, and he received the "confirm this transfer" email. So we solved that problem, now it's time to think about migrating the box over. I'm no fan of Linux (I like FreeBSD), and Avi who is effectively my only co-admin really likes Slackware. We originally met in the middle, settling on Debian, but newer versions of it come packaged with systemd, something neither of us are particularly fond of.
We could run Debian without systemd, I think, and may still do that. In the mean time, I wanted to learn more about Slackware... it was my very first Linux distribution, so there's a little bit of nostalgia there. It was actually the first unix-like OS I'd ever legitimately messed with, if you don't count other machines that didn't strictly speaking belong to me. But Linode's default Slackware image throws in the Kitchen sink:
$ ls /var/log/packages | wc -l
Yep, it comes bundled with shit like
svgalib, and at least two different FTP daemons.
I've built Linux from scratch, before, but that was a long time ago, and dealing with upgrading things manually and coping with dependencies and shit just doesn't sound like much fun. But what about Slackware from scratch? Manually unpack the minimum things required for Slackware's package manager to function,
chrooting to it and installing the rest, only what I wanted? It's actually semi-doable, though I'm not sure it's worth the effort for a minimal Slackware installation.
For reference, with Slackware 14.2, there are very few packages required for the chroot environment to work and be able to run
pkg. Slackware packages are pretty simple: a tarball (compressed with
[xz](https://en.wikipedia.org/wiki/Xz), with an
install/ directory that you're supposed to blow away after unpacking and executing the script contained inside of it. That's easy enough to script (I ran this little script from Finnix):
# Fetch packages required (??) for pkgtools to operate.
# glibc-solibs is installed twice, because the script doesn't seem to do it's job the first time?
mkdir -p tmp/
for p in \
do echo "Fetching+installing: $p";
wget --quiet --no-check-certificate --directory-prefix=tmp/ https://mirrors.slackware.com/slackware/slackware64-14.2/slackware64/a/$p && tar -xf tmp/$p && sh install/doinst.sh; rm -rf install/
As noted in the comments,
glibc-solibs's install script doesn't seem to do it's job the first time. I thought it depended on something else already being there, but even putting it at the end didn't work.
Finally, writing a few files (
fstab, and something else which escapes me), then installing a handful of other packages gave me a system that would boot (on Linode, note that no kernel or bootloader is required there), such as
aaa_terminfo, and a couple things like
It booted, and you could shell in and set more things up. Total install weighed less than a CD-R image (remember, no kernels though). There must be something else the installer configures that I didn't (or I'm missing a package) because while the system would boot, it wouldn't shutdown correctly. It was at this point though that I figured out I really don't care.
When writing up a text file describing all of the above, I started out calling it "Slackware Linux the hard way". However, after playing around with a decent installation of Slackware, and realizing all the things it's missing that a more modern distribution has (dependency management and such), and considering that you gain nothing from all that fuckery (at least with Gentoo you can trivially build, install, and upgrade an Apache that doesn't depend on sqlite!), I decided to add some punctuation and call this entry "Slackware: Linux, the hard way". Other than "old school cred" I can't really see a reason to run Slackware at all, which pains me. I get the "if it ain't broke don't fix it" approach, but it is broken, in my humble opinion - it made me appreciate
freebsd-update and suchlike that much more.
Not content with the 24 hours' self-flagellation, I decided to install OpenBSD as well. I really don't feel like fucking with that any more either. So what to do? Stick with Debian, and try cut out that systemd cancer? Or use FreeBSD and listen to Avi's mouth every time something breaks? I'll decide later.