While digging around in my picture archive on Windbringer, I found a handful of photographs from the White House hackathon held by the Internet Archive back in January of this year. I ran a couple of searches and didn't find anything I wrote about what I worked on there (weird...) so here are the pictures I took when I wasn't coding.
Some time ago, I found myself using a Kryoflux interface and a couple of old floppy drives that had been kicking around in my workshop for a while to rip disk images of a colleague's floppy disk collection. It took me a day or two of screwing around to figure out how to use the Kryoflux's software to make it do what I wanted. Of course, I took notes along the way so that I would have something to refer back to later. Recently, I decided that it would probably be helpful to people if I put those notes online for everyone to use. So, here they are.
A persistent risk of websites is the possibility of somebody finding a vulnerability in the CMS and backdooring the code so that commands and code can be executed remotely. At the very least it means that somebody can poke around in the directory structure of the site without being noticed. At worst it would seem that the sky's the limit. In the past, I've seen cocktails of browser exploits injected remotely into the site's theme that try to pop everybody who visits the site, but that is by no means the nastiest thing that somebody could do. This begs the question, how would you detect such a thing happening to your site?
I'll leave the question of logfile monitoring aside, because that is a hosting situation-dependent thing and everybody has their own opinions. What I wanted to discuss was the possibility of monitoring the state of every file of a website to detect unauthorized tampering. There are solutions out there, to be sure - the venerable Tripwire, the open source AIDE, and auditd (which I do not recommend - you'd need to write your own analysis software for its logs to determine what files, if any, have been edited. Plus it'll kill a busy server faster than drilling holes in a car battery.) If you're in a shared hosting situation like I am, your options are pretty limited because you're not going to have the access necessary to install new packages, and you might not be able to compile and install anything to your home directory. However, you can still put something together that isn't perfect but is fairly functional and will get the job done, within certain limits. Here's how I did it:
Most file monitoring systems store cryptographic hashes of the files they're set to watch over. Periodically, the files in question are re-hashed and the outputs are compared. If the resulting hashes of one or more files are different from the ones in the database, the files have changed somehow and should be manually inspected. The process that runs the comparisons is scheduled to run automatically, while generation of the initial database is normally a manual process. What I did was use command line utilities to walk through every file of my website, generate a SHA-1 hash (I know, SHA-1 is considered harmful these days; my threat model does not include someone spending large amounts of computing time to construct a boobytrapped index.php file with the same SHA-1 hash as the existing one; in addition, I want to be a good customer and not crush the server my site is hosted on several times a day when the checks run), and store the hashes in a file in my home directory.Click for the rest of the article...
I haven't spent much time with forge and Nicole since their wedding many, many years ago. Forge was in mine back in '08, but weddings being what they are, I wasn't able to really hang out. I think they lived in the Bay Area for a while, but now they're living in Maryland under what seems like less-than-optimal conditions..
Nicole recently announced that she's been suffering from polycistic kidney disease for much of her life; it is a disease in which cysts grow inside the kidney in the place of normal nephritic tissue. If the cysts become too large or too numerous, the kidneys fail to function the way they're supposed to which causes a whole family of other health problems due to one's blood being filtered insufficiently. If you have any doubts that this can be somewhat problematic, you might want to check out some medical photographs of the condition. Unfortunately, while the condition can be treated to mitigate symptoms it cannot be cured entirely. Nicole has lost 90% of her kidney function and she's going to need to go on dialysis within six months.
If you have it laying around, can you please spare a couple of dollars to help an old friend? Also, if you can spread word of their Gofundme campaign around your respective social networks, can you please do so? If you would like to sign up to see if you could be a possible kidney donor, please go here and fill out the forms: https://maryland.donorscreen.org/register/donate-kidney
UPDATE - 20170512 - More SQL surgery.
So, as you've no doubt noticed I've been running the Bolt CMS to power my website for a while now. I've also mentioned once or twice that I've found it to be something of a finicky beast and doing anything major to it can be something of an adventure. I tried to upgrade my site last week (tonight, by the datestamp on this post) and had to restore from backup yet again because something went sideways. That something was the upgrade process going wrong and throwing an exception because of something in the cache directory, where Bolt temporarily stores HTML files rendered from templates used to make pages that your web browser displays.
As it turned out, the upgrade process was choking on the old cache directories created and used by v2.x of the Bolt CMS. Here is the upgrade process that I used:
- BACK UP YOUR SITE.
- Log into your web hosting provider's server via SSH.
- Download the latest version of the flat file structure build of Bolt.
- If you didn't back up your website, BACK UP YOUR WEB SITE.
- cd ~/my.website.here
- If you didn't back up your website and things go pear-shaped, it's your fault. Don't say I didn't warn you.
- Uncompress the new version of Bolt you just downloaded: tar xvfz ~/bolt-latest-flat-structure.tar.gz --strip-components=1
- Try running the upgrade: php app/nut setup:sync
- If it throws an exception on you, erase the entire on-disk cache. Don't worry, it'll be rebuilt as people visit your site: rm -rf app/cache/*
- Try running the upgrade again: php app/nut setup:sync
- It should complete successfully. If it doesn't you may need to do the following two things before re-running the upgrade command again:
- mkdir -p app/cache/production/data/
- chmod -R 0775 app/cache/
- If you still have problems, jump into the Bolt CMS Slack chat and politely ask good questions: https://boltcms.slack.com/
- If the command finishes normally, try opening the frontpage of your website. It should be up and running.
- If you can see the frontpage of your website, try logging in. You should be able to.
- Try making a test post with a new entry. Be sure to test saving the post partway through. You do save your work every few minutes, don't you?
Special thanks to Bob and thisiseduardo in the Bolt CMS Slack chat for their assistance and hand-holding while I stumbled around trying to make this hapen.Click for the rest of the article...
A couple of months ago for my Lesser Feast I decided to treat myself to a toy that I've had my eye on for a couple of months: A Pi-Top laptop kit. My fascination with the Raspberry Pi aside (which includes, to be honest, being able to run a rack full of servers in my office without needing to install a 40U rack and a new 220 power feed), it strikes me as being a very useful thing to have under one's desk as a backup deck or possibly a general purpose software development computer. Most laptops have one unique motherboard per model and if you want to upgrade (or need to replace it) you're pretty much limited to buying a brand-new laptop. To upgrade a Pi-Top you just need to buy a new RaspberryPi, slide a panel aside, and swap a few cables, a system design that I think could be useful indeed. It also has remarkably few components; the screws and fasteners aside, the PiTop is composed of only a few modules: A base with a battery, a keyboard and touchpad panel, a lid with display, a black lexan access panel, a hub circuit board that ties everything together, and a RasPi. You can get a couple of modules to go with it, such as a prototype board for electrical engineering experiments and modular speakers, all of which attach to a sliding rail and plug into a unique pinset on the hub. I'm not an electrical engineer by any means but I have built many a kit over the years, and from eyeballing it it looked like a fairly simple build. I didn't document the build with photographs or anything because I didn't think to do so at the time. Sorry.Click for the rest of the article...
We seem to have reached a unique point in history: Available to your average home user are gargantuan amounts of disk space (8 terabyte hard drives are a thing, and the prices are rapidly coming down to widespread affordability) and enough processing power is available for the palm of your hand that makes the computational power that put the human race on the moon compare in the same was that a grain of sand does to a beach. For most people, it's the latest phone upgrade or more space for your media box. For others, though, it poses an unusual challenge: How to make the best use of the hardware without wasting it needlessly. By this, I mean how one might build a server that doesn't result in wasted hard drive space, wasted SATA ports on the mainboard, or having enough room to put all of that lovely (and by "lovely" I really mean "utterly disorganized") data that accumulates without even trying. I mentioned last year that I rebuilt Leandra (specs in here) so I could work on some machine learning and search engine projects. What I didn't mention was that I had some design constraints that I had to follow so that I could get the most out of her.
To get the best use possible out of all of those hard drives I had to figure out how to structure the RAID, where to put the guts of the Arch Linux install, and most importantly figure out how to set everything up so that if Leandra did blow a hard drive the entire system wouldn't be hosed. If I partitioned all of the drives as described here and used one as the /boot and / partitions, and RAIDed the rest, if the first drive blew I'd be out an entire operating system. Also, gauging the size of the / partition can be tricky; I like to keep my system installs as small as possible and add only packages that I absolutely need (and ruthlessly purge the ones that I don't use anymore). 20 gigs is way too big (currently, Leandra's OS install is 2.9 gigabytes after nearly a year of experimenting with this and that) but it would leave room to grow.
So, what did I finally decide on?Click for the rest of the article...
I've updated my .plan file yet again. As per usual, NSFW content, out of context quotes, and things that put your keyboard and display in danger at work abound.
Now that ISPs not selling information about what you do and what you browse on the Net is pretty much gone, a lot of people are looking into using VPNs - virtual private networks - to add a layer of protection to their everyday activities. Most of the time there are two big use cases for VPNs: Needing to use them for work, and using them to gain access to Netflix content that isn't licensed where you live. Now they may as well be a part of everyday carry.
So: Brass tacks. Here's a quick way to set up your own VPN server, as well as a solution to a problem that frustrated me until very recently. For starters, unless you're an experienced sysadmin don't try to freestyle the setup. There is an excellent script on Github called openvpn-install that will do all of the work for you (including adding and deleting users) in less than a minute. Use it to do the work for you. Please. Also, if you build an OpenVPN server, consider going in with a couple of friends on the cost.
Chances are you're running either Windows or Mac OSX (Linux and BSD users, you know what to do) so you'll need an OpenVPN client on the users' end. This means that you want to run either the Windows version of the OpenVPN client or an OSX client like Tunnelblick. However, these clients assume that you're just loading an all-in-one configuration file, called an .ovpn file. If you've never done it before they're remarkably tricky to build but they're basically a copy of the OpenVPN client.conf with all of the crypto keys embedded in special stanzas. It took me a lot of fumbling and searching but I eventually figured out how to reliably make them. To save you some time here's a copy of the one I use with all the unique stuff removed from it. If you open it in a text editor you'll notice a couple of things: First, the very first non-commented line says that it's for the client and not the server. Second, I have it configured to use TCP and not UDP. This is so that you don't have to reconfigure the firewall you're behind to get your traffic through. Keep it simple, trust me on this. Third, the ca, cert, and key directives are commented out because those keys are embedded at the end of the file. Fourth, I have tls-auth enabled so that all traffic your server will handle is authenticated for better security.
If you freestyle (that is, build by hand) your OpenVPN server, you'll need to keep in mind the following things:Click for the rest of the article...
kinetic pattern baldness - noun - The characteristic hourglass-shaped pattern of hair loss in both men and women that results from tearing one's hair out in frustration on a regular basis.