Otherworld Miniatures

I ordered a bunch of miniatures from Otherworld Miniatures in the United Kingdom. I had been interested in their stuff for a while but failed to order before the whole BREXIT thing took effect. So I figured this would be a good experiment to see how "ordering from the UK" works for folks in Europe now. Here are the basic facts for my order:

• May 25, 2021: Order filed and Paypal authorized for £54.50 GBP.
• June 8, 2021: Email confirming order is complete.
• June 17, 2021: Package arrives at my house around noon.

I am not complaining about anything here, the order wasn't urgent and no particular delivery date had been promised as far as I know. I do, however, want to point out that a June 1, 2021 email I had sent was completely ignored, so that wasn't great.

Here we go with the entirely predictable "unboxing" photos you've all been waiting for! First the outside...

The package itself. Air mail? Fancy!

Post-BREXIT necessities.

Now the inside...

Hmm... I guess I expected more?

I like the note. Good people.

No bottom padding. Sad.

Finally, the contents...

But everything seems to be okay.

Everything seems to have arrived in good condition, despite my misgivings about the lack of all-around padding. Now the hard stuff begins: I am terrible at assembling miniatures. I mean I am even worse at painting them, but I usually only buy "one piece" miniatures because I know about my distinct lack of skills. Oh well, wish me luck! Now where's that glue...?

Third Grade Memory

I just made a forum post elsewhere and realized that I should push this "third grade memory" of mine out here as well. Don't worry about the context.

In like third grade, in the winter, after school, before heading home, we'd go over to the church. Lots of low, curved walls with snow on top there. We'd sketch buttons and screens and stuff into the top of those walls and we'd play out some Star Trek re-run from the night before. Someone was Kirk and someone was Scotty and so on. We decided on the fly what we could and could not do and what would happen. We did this for about thirty minutes to an hour, then went home for lunch and homework and comics and stuff. When we played next, a day or two later, we'd keep some of the decisions we made before, others we redid, new episodes added new information, etc. Nobody wrote any of that down despite us having a grand old time for weeks of school.

Plenty here that sort of dates this of course. Kids these days don't seem to get out of school around lunchtime anymore, instead they are forced to do "pedagogically sound" stuff that others thought up for them in the afternoon. And if that wasn't sad enough, if one of them would actually complain about not liking those "well-designed exercises" they'd get some kids-level psychoanalysis next week. Oh well, I guess it's progress?

Let's hope I am wrong...

...but I fear I might not be. Looking at everything that's going on with Trump and his cronies right now, I cannot help but think that their plan is to drag it all out until some state legislatures have to select electors in order to not miss the safe harbor deadline. And of course Republican state legislatures will pick the Republican slates. Combined with another group of cronies waiting in the wings of the Pentagon, the FBI, and the DHS for crowd control, it will be the coup Trump has been playing for all along. He'll finally be able to join the ranks of his pals in other authoritarian societies and keep on ruling until Junior eventually succeeds him. On the upside, we'll actually live in interesting times, just as the old Chinese curse said. Cheers!

OpenBSD IPv6 on TinyKVM

I had a lot of trouble getting IPv6 to work under OpenBSD 6.7 on a TinyKVM instance. So here, for reference, is how I finally made it work:

1. In your control panel, note the IP addresses for your instance and its gateways; for the IPv6 address of your instance, you get to pick the last 16 bits yourself, but obviously you can't pick the IPv6 of your gateway.
2. Edit /etc/hostname.em0 and put in the IPv4 (keyword inet) and IPv6 (keyword inet6) addresses (and netmasks) for your instance, nothing else.
3. Edit /etc/mygate and put in the IPv4 and IPv6 addresses for your gateways, nothing else.
4. Stop and disable the slaacd daemon using rcctl; I guess the OpenBSD folks are hopeful that most networks support SLAAC but I had no luck here.
   
5. Try restarting the network using sh /etc/netstart but if that doesn't fix things for you, reboot the instance and hope for the best.

Note that I had to add a "mystical" invocation of ifconfig to /etc/rc.local as well. Without that, the instance wouldn't pick up either of its IPs immediately on boot but only after a roughly 5 minute delay. No idea what the TinyKVM folks are doing there, but hey, with this "all static" configuration and the weird ifconfig trick things now work roughly as they should. If you figure out a better way of doing this, please let me know!

Hosting Options

For various reasons I've been looking around for "new" VPS hosting options again. This is a brief summary of the "neat" things I found. It's not a "review" of any kind, it's literally just a bunch of links and commentary. (If I ever use any of these options for long enough to have an opinion, I'll add a review or three.)

Historically I've mostly used Linode, especially "back in the day" when I was running lots of game servers across the US (and even in the UK for a while); my longest-running (shared) server is also on Linode. They have some great tech, nice support, and it's generally very smooth sailing indeed.

But there are "issues" as well, especially these days. First they don't have a "cheap" storage option. Everything is NVME SSDs these days and so with a small plan (what I usually run because I am cheap) you get 25 GB. Not too shabby if you grew up in the 1970s, but not great either.

After a bit of research, I noticed that RamNode actually offers plans with good-old "spinning rust" disks. Yes, the kind some of you don't even remember. As of today, you can get 160 GB for $3/month and 325 GB for $5/month. Pretty sweet if all you need is a bunch of space, for automated backups for example. Of course you need to keep an eye on bandwidth, but hey, here's the storage if you need it.

Another "issue" is that US companies are, well, US companies. Just like German companies are German and Australian companies are Australian. Doh! What I am getting at is that by picking a hosting company, you're also picking (to a degree) the laws that protect (or not!) your data, privacy, freedom, or life. So depending on what you plan on doing with your VPS, you may want to pick an "exotic" jurisdiction instead of the obvious one.

I ended up looking at Switzerland, Austria, and Iceland in more detail. From a "Five (Or More) Eyes" perspective, these are places that at least have no "overt" history of large-scale "illegal" spying. They also have "reasonable" Press Freedom Rankings which can be helpful if you plan to do some investigative reporting online. But don't forget the "small print" of your VPS provider either, different companies have vastly different "Terms of Service" regardless of the level of "freedom" that exists in their respective countries. Also these things are never as simple as shoving your data or services elsewhere, so if in doubt get yourself a lawyer!

For me, 1984 Hosting in Iceland checks most of the boxes I care about. Also their pricing is a lot better than many other VPS vendors in Iceland. For example they have a reasonable $5/month plan that's actually comparable (except for bandwidth) with a cheap Linode plan. On top of that I was impressed by their recent report on a 2017 incident that brought down much of their operation. Yes, maybe it's a little late, but it's certainly detailed and I very much like the idea of them trying to be this transparent about what happened, why it happened, and what they've done to avoid it in the future.

A final "issue" is operating systems: It's kind of a pain (or at least it used to be, maybe it improved recently?) to install OpenBSD on Linode. Yes, I've been mostly a Linux person for the past 15 years or so, but I've recently "tuned back into" the BSD world a bit more and I like what's happened there. I currently run OpenBSD on a small Vultr instance and that works reasonably well. But I also found a small outfit in Amsterdam that not only offers OpenBSD VMs but also uses OpenBSD to run the virtualization infrastructure itself! On top of that, they donate to the OpenBSD developers. Their pricing is yearly and works out to $5/month for a small VM (half the RAM of Linode, but twice the disk space).

That's it for me and hosting for now. Feel free to share any hosting tips you have in the comments, I am "all ears" as it were.

Cobalt Qube 2 / RaQ 2 Notes

I've had an old Cobalt Qube 2 in my possession since at least 2003 and I got my hands on an old Cobalt RaQ 2 sometime in 2007. These are cute ("qute"?) MIPS machines that (used to) work great as targets for my Compilers and Interpreters course. Sadly both boxes have been "out of commission" for a few years, but I recently decided that I want to run them again, the RaQ in particular. In the process I noticed that a few important pieces of Cobalt information are hard to find online these days, so this post is mostly a collection of notes for myself.

First here are two basic shots of the RaQ 2 in pretty much the state I received it in over 10 years ago. First note the lack of a cover for the power supply! You'll need to be somewhat careful working in here if you're worried about a capacitor zapping you.

Cobalt RaQ 2 Front

There is also a spot for a fan but apparently the power supply never gets hot enough because (as you can see in the next shot) that grate is actually covered by the Cobalt logo.

Cobalt RaQ 2 Back

The installed fan is incredibly tiny and in my RaQ 2 it doesn't sound particularly healthy anymore. I have not double-checked yet, but supposedly Cobalt used this SUNON fan for the RaQ 2. Sourcing an exact replacement fan has turned out to be difficult, but I've also found some ancient posts that claim that these machines don't really get hot enough to require a fan in the first place. I am leaving mine in for now, hoping that even if it fails it won't bring down the box with it.

Next topic: Failed battery. There's a CR2032 located on the main board next to the power supply. Sadly the thing has one of those dreaded sockets with an excessively tight retaining clip on top. You're supposed to "lift the clip" and then slide out the battery, but of course in the process of doing that the entire thing just "ripped off" the mainboard. To add insult to injury, a solder pad came off as well, complete with the attached copper track of course.

Socket and copper track, yikes!

Witness the complete destruction on the mainboard:

Battery connector destroyed.

The lesson here is either that I am incapable of treating a piece of history with the required tenderness or that one should just leave good enough alone. Good enough? Well it turns out that the machine works perfectly fine with an empty battery. Better yet, it works perfectly fine even with a ripped out battery. So luckily I did not actually destroy the entire machine with this horrible mistake. If I ever decide to give my Qube 2 the "same" treatment, I'll desolder the entire battery socket instead and replace it with a less insane one.

To be continued... :-)

Unlock LUKS Remotely on Ubuntu 16.04 LTS

I reinstalled my little server at work. It had been running the same Gentoo setup since 2008 (!) but in December 2017 the Gentoo folks finally managed to produce a convoluted enough update to completely hose the darn thing. Well, not "hose" as in "disaster" of course: I got all the data off safely and I could even leave it running over the holidays while I was away in Germany. But in preparation for the Spring 2018 semester it was necessary to "start from scratch" as it were.

Upset enough with Gentoo I decided to go completely the other way and do a minimal Ubuntu 16.04 LTS install. I also used this opportunity to finally add full-disk LUKS encryption to my setup. Not that it makes much sense (the server runs 24/7 so it's basically always decrypted) but what the heck, this is how you're supposed to set up your server, right? And instead of going for ZFS or btrfs (which is what I used on my new home machine), I went "retro" one last time:

1. Partition the disks into one "small" boot partition and one "large" data partition.
2. Use mdadm to create a RAID-1 boot and a RAID-10 data array.
3. Use cryptsetup to LUKS-encrypt the "huge" data RAID array.
4. Use LVM to create swap, root, and various home volumes in the encrypted RAID.

Great! But now I had a problem. You see, every now and then we actually have a power outage. (I know it's weird, but since we're not the hospital we apparently don't get to have a redundant power grid.) I might not be around to reboot the machine manually, but students want to submit their homework assignments. And I don't like giving extensions. So what to do?

Enter the recent dropbear-initramfs package! This thing is supposed to integrate a tiny dropbear SSH server into the early root filesystem, enabling "remote unlocking" of the encrypted RAID array. And it almost works. First the easy parts:

1. apt install dropbear-initramfs (and ignore the error message)
2. mkdir -p /etc/initramfs-tools/root/.ssh/
3. Put your SSH keys into /etc/initramfs-tools/root/.ssh/authorized_keys
4. update-initramfs -u

Now when the machine boots up, it'll still ask for a passphrase on the console, but it will also start the dropbear SSH server. In theory you can ssh in as root at that point and run the unlock script, but that didn't work for me. What did work, however, is to echo the passphrase directly to the FIFO created by cryptsetup:

1. ssh root@server
2. echo -n passphrase >/lib/cryptsetup/passfifo
3. exit

At this point the encrypted RAID will come up and the boot process will continue, just as if you had typed the passphrase at the console. I am positive that they'll eventually fix the scripts, but for now I am just happy that I was able to make it work.

Note that it's convenient to run dropbear SSH and the regular OpenSSH on different ports to avoid getting loads of useless warnings when connecting. It's also just good sane practice if you want to keep the number of script kiddies trying to get into your server down to a minimum. Yes, security through obscurity is bad, but it's only really bad if it's your only approach. Happy remote booting!