Originally downloaded from here.
A couple of weeks back, somebody I know asked me how I went about deploying SSL certificates from the Let's Encrypt project across all of my stuff. Without going into too much detail about what SSL and TLS are (but here's a good introduction to them), the Let's Encrypt project will issue SSL certificates to anyone who wants one, provided that they can prove somehow that they control what they're cutting a certificate for. You can't use Let's Encrypt to generate a certificate for google.com because they'd try to communicate with the server (there isn't any such thing but bear with me) google.com to verify the request, not be able to, and error out. The actual process is complex and kind of involved (it's crypto so this isn't surprising) but the nice thing is that there are a couple of software packages out there that automate practically everything so all you have to do is run a handful of commands (which you can then copy into a shell script to automate the process) and then turn it into a cron job. The software I use on my systems is called Acme Tiny, and here's what I did to set everything up...Click for the rest of the article...
It's now 2018. Don't ask me how we made it, but we did.
Regular readers have probably been wondering what's been going on that I haven't posted much. The short form, and the honest answer, is that I haven't had it in me to really post, aside from some stuff that I copy-and-pasted out of my notes, polished up a bit, and saved. The holiday season is always a busy time, and my life is no different from anyone else's in that regard.
Lyssa and I flew back to Pennsylvania at more or less the last minute about halfway through the month to celebrate an early Yule with our respective parents. Some last minute jiggery-pokery landed us a pair of get-seats-at-the-gate redeye flights to and from the other coast, which resulted in the peculiar combination of jet lag and sleep deprivation. This resulted in my getting sick again not long after arrival. I was in a fair amount of pain for several weeks due to this particular illness. Frequent readers are somewhat aquainted with my dental history, which reads like a classic farce as written by Hunter S. Thompson. Suffice it to say that I was living in a haze of pain that took most of the wind out of my sails without actually being overtly incapacitating. At least Lyssa and I spent some quality time with our nieces and nephews, and everyone seemed to enjoy their gifts.Click for the rest of the article...
I know I haven't posted much this month. The holiday season is in full effect and life, as I'm sure you know, has been crazy. I wanted to take the time to throw a quick tip up that I just found out about which, if nothing else, will make it easier to get up and running on a Raspberry Pi that you've received as a gift. Here's the situation:
You have a new account on a machine that you want to SSH into easily. So, you want to quickly and easily transfer over one or more of your SSH public keys to make it easier to log in automatically, and maybe make running Ansible a bit faster. Now, you could do it manually (which I did for many, many years) but you'll probably mess it up at least once if you're anything like me. Or, you could use the ssh-copy-id utility (which comes for free with SSH) to do it for you. Assuming that you already have SSH authentication keys this is all you have to do:
[drwho@windbringer ~]$ ssh-copy-id -i .ssh/id_ecdsa.pub pi@jukebox /bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_ecdsa.pub" /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys pi@jukebox's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'pi@jukebox'" and check to make sure that only the key(s) you wanted were added.
Now let's try to log into the new machine:
[drwho@windbringer ~]$ ssh pi@jukebox Linux jukebox 4.9.70-v7+ #1068 SMP Mon Dec 18 22:12:55 GMT 2017 armv7l The programs included with the Debian GNU/Linux system are free software; # I didn't have to enter a password because my SSH pubkey authenticated me # automatically. pi@jukebox:~ $ cat .ssh/authorized_keys ecdsa-sha2-nistp521 AAAAE....
You can run this command again and again with a different pubkey, and it'll append it to the appropriate file on the other machine (~/.ssh/authorized_keys). And there you have it; your SSH pubkey has been installed all in one go. I wish I'd known about this particular trick... fifteen years ago?
As you may or may not be aware, I've been a customer of Dreamhost for many years now (if you want to give them a try, here's my referral link). Both professionally and personally, I've been hosting stuff with them without many complaints (their grousing about my websites being too large is entirely reasonable given that I'm on their shared hosting plan). Something always got me about their SSL support, though, was that you had to buy a unique IP address from them if you wanted to use it. That cost a pretty penny, almost as much as I pay every year for hosting service. After all, there's the SNI protocol which essentially lets you put SSL on multiple websites hosted at the same IP address. It's been around since 2006 and has been supported by Apache since v2.2.12 so there wasn't any real reason to not offer it. On the other hand, though, IPv4 addresses are getting pretty thin on the ground so paying for the privilege so I could have SSL on my website was worth it. Plus, Dreamhost has to sell services to stay in business, and sometimes that means paying for perks as much as you or I might be annoyed by it.
A couple of years ago Dreamhost started offering free SSL certificates through their partnership with the Let's Encrypt project if you were a customer. The idea is that you could click a couple of buttons in their control panel and they'd hook you up with an automatically renewing SSL cert for your website. So, of course I jumped at the opportunity because I got tired of the self-signed certificate errors everybody was getting. Comes with the territory.
Last weekend, for whatever reason I got it in my head to e-mail customer support and ask them if I had to keep paying for a unique IP address if I was using a Let's Encrypt certificate on my website. I use acme-tiny to maintain the certs on my servers (I should write up how I do that one of these days), so... I figured the worst they could do was say "No."
As it turns out, if you use Let's Encrypt on Dreamhost, you do not have to keep paying for a unique IP address. It's safe to go into your control panel, click that tiny little 'x' button, and save yourself some money every year. I did so earlier today (about a week ago, as you'll reckon it) and everything seems copacetic. This also means it's safe to turn on SSL for every site you have there, and it won't cost you any more money. Though it would be good to donate to the Let's Encrypt project to support their work.
Difficulty rating: 8. Highly specific use case, highly specific setup, assumes that you know what these tools are already.
Let's assume that you have a couple of servers that you can SSH into over Tor as hidden services.
Let's assume that your management workstation has SSH, the Tor Browser Bundle and Ansible installed. Ansible does all over its work over an SSH connection, so there's no agent to install on any of your servers.
Let's assume that you only use SSH public key authentication to log into those servers. Password authentication is disabled with the directive PasswordAuthentication no in the /etc/ssh/sshd_config file.
Let's assume that you have sudo installed on all of those servers, and at least one account can use sudo without needing to supply a password. Kind of dodgy, kind of risky, mitigated by only being able to log in with the matching public key. That seems to be the devopsy way to do stuff these days.
Problem: How to use Ansible to log into and run commands on those servers over the Tor network?Click for the rest of the article...
Regular readers of my site no doubt noticed that my site was offline for a little while a few days ago (today, by the timestamp, because Bolt doesn't let me postdate articles, only postdate when they go live) because I was upgrading the software to the latest stable version. It went remarkably smoothly this time, modulo the fact that I had to manually erase the disk cache so the upgrade process could finish and not error out. Deleting the cache alone took nearly an hour, and in the process I discovered something I wish I'd known about when I first started using Bolt.
So, here's what I'm on about...Click for the rest of the article...
A couple of weeks ago a new release of the Keybase software package came out, and this one included as one of its new features support for natively hosting Git repositories. This doesn't seem like it's very useful for most people, and it might really only be useful to coders, but it's a handy enough service that I think it's worth a quick tutorial. Prior to that feature release something in the structure of the Keybase filesystem made it unsuitable for storing anything but static copies of Git repositories (I don't know exactly waht), but they've now made Git a first class citizen.
I'm going to assume that you use the Git distributed version control system already, and you have at least one Git repository that you want to host on Keybase; for the purposes of this example I'm going to use my personal copy of the Exocortex Halo code repository on Github. I'm further going to assume that you know the basics of using Git (cloning repositories, committing changes, pulling and pushing changes). I'm also going to assume that you already have a Keybase account and a fairly up-to-date copy of the software installed. I am, however, going to talk a little bit about the idea of remotes in Git. My discussion will necessarily have some technical inaccuracies for the sake of usability if you're not an expert on the internals of Git.Click for the rest of the article...
A couple of days ago (a couple of minutes ago, as I happen to write this) I watched a documentary on Youtube about a modern urban legend, the video game called Polybius. I don't want to give away the entire story if you've not heard it before, but a capsule version is that in 1981.ev a strange video game called Polybius was installed in a number of video arcades in the Pacific Northwest. The game supposedly had a strange effect on some of the people playing it, ranging from long periods of hypnosis to night terrors, epileptic convulsions and, it is rumored, a small number of deaths due to sudden heart failure. It's a story circulated for years online in one form or another, and a number of people have built their own versions that fit the details of the story, with varying degrees of fidelity. I'll admit, one of my long-term plans is to build a MAME cabinet at home that looks like one as a conversation piece. It's a modern day tall tale, where chances are you know somebody who knows somebody whose brother dated the sister of a guy who wound up in the hospital in a coma back in 198x because he spent 50 hours entranced playing some weird game in an arcade while on a family trip, and mysteriously the cabinet was gone by the time he was released.
One thing that I don't think I've heard anybody say, though, is that the origins of the story might date back to the late 1990's. I first came across a story about a video game in the early 1980's that had strange effects on its players in the book GURPS Warehouse 23, published by Steve Jackson Games (first printing in 1997, second printing in 1999, available for purchase as a downloadable PDF from the Steve Jackson Online Store because the dead tree edition is out of print). The chapter Conspiracies, Cover-Ups, and Hoaxes of the game supplement opens with a story called The Astro Globs! Cover-Up, which talks about a video game called Astro Globs! (unsurprisingly) developed in 1983 by a computer programmer named Gina Moravec (after Hans Moravec?) which was uncannily adaptive to the person playing it. The video game described by the game book would figure out how the person playing it thought and tailored itself to be increasingly challenging and fascinating without ever getting frustrating, which also made it dangerously hypnotic. The son of the programmer of the game was hospitalized for dehydration after playing it for over 72 hours with neither sleep nor food nor water.
The first printing of Warehouse 23 was in 1997, which implies that the genesis of the Astro Globs! story was some time prior to that. From what little I know of the professional RPG authorship industry, factor in maybe a year's time for proofreading, layout, and the first print run to wind up in the warehouse for distribution (this was in the late 90's, after all - desktop publishing was nowhere near as advanced as it is now, and print-on-demand was certainly not a thing then) and two or three years for development, editing, playtesting, kicking around the group of people working on the text... so I would carefully guess that the idea came about some time in the early 1990's.
The documentary states that the page on coinop.org I linked to above was created on 3 August 1998 at 0000 hours (timezone unknown) (local mirror, 20171120), which puts it about a year after the first edition of Warehouse 23 hit the shelves. The researchers who made the documentary say that they traced the page as far back as 6 February 2000 using the Wayback Machine, which strongly implies that the date in the page footer is incorrect, possibly due to a default value entered in the back-end database during a site migration.
So... perhaps some GURPS conspiracy flavor can be found in the roots of this story? Maybe somebody trying to make their favorite part of the book come to life somehow?
I guess I should wish everybody out there a happy Thanksgiving that celebrates it.
I haven't been around much lately, certainly not as much as I would like to be. Things have been difficult lately, to say the least.
Around this time of year things go completely berserk at my dayjob. For a while I was pulling 14 hour days, capped off with feverishly working three days straight on one of the biggest projects of my career, which not only wound up going off without more than the expected number of hitches but has garnered quite a few kudos from the community. I'm rather proud of how it turned out. Unfortunately, it also took its toll, namely, on my health. During the final leg of the project I noticed that I was starting to get sick, and by that Tuesday my cow-orkers were telling me to go home and sleep because I looked like death warmed over. Unsurprisingly, I've been battling a nasty cold that's kicked the legs out from under me. I still haven't kicked out of big-project mode yet, because the last few times I've started to feel better I've run myself aground again without realizing I was doing so. This is not good. It also seems that I brought this particular nasty home, and now my family is in various stages of fighting it off.Click for the rest of the article...