Jeff Backus

Stuff

Sat, 20 Aug 2016 21:00:00 +0000

Over the past two weekends, my spouse and I have been engaging in the semi-regular act of sorting through, and divestment of, stuff. Ever since we first merged households several years ago, we’ve been slowly picking away at all of the odds and ends that we brought with us.

Some of these things are items you only need once in a while. Items such as extension cords, holiday decorations, turkey pan. Things probably worth keeping.

Some of these things, we keep around “in case we need it”. Not a bad idea, in moderation. Case in point, I originally had three 10 gallon containers full of various computer cables. Power cables, USB cables, monitor cables (VGA, DVI, HDMI, S-Video!), network cables, serial cables, you name it. Sure, some of these might come in handy, but at one point I had over 20 power cables. What are the chances that I’ll need all 20 cables at the same time? Probably not large. And who still uses S-Video? Needless to say, I was able to pare my “collection” back to two containers a couple of years ago. This year I was able to pare myself back to only 1.

My spouse, who is infinitely wiser and smarter than I’ll ever be, made the observation that some of the stuff we drag around through the years and through the moves, doesn’t really belong to us anymore. It belongs to a previous version of ourselves. We keep it around because we like that person and the memories we created as that person. But we aren’t that person anymore, and so we tote these things in move after move, but never quite find the time to use them.

Don’t get me wrong, I think it is very important to keep mementos of the time we spend in this world. I’m not talking about mementos, though even mementos need to be kept in moderation.

Take, for instance, the Gameboy Advance SP that I’ve had for years. Growing up, I’ve always considered myself a gamer (in the traditional sense of the word). To this day, it is still a big part of the bonding experience between my siblings and I. When I bought the thing, I also picked up several re-releases of some of my favorite games. And in the years since I bought it, I’ve played the thing, oh, maybe 5 times? And hardly for more than half an hour. The exception this one time I was traveling for business. Between the layovers and the idle hours in the hotel, I made it about half way through Link to the Past. But otherwise, hardly I touch it.

You see, games just aren’t a big part of my life anymore. I still enjoy them. I still spend money on them. Occasionally. Very Occasionally. I’m just not that person anymore. That kid glued to the TV with the NES controller in a death grip. It took me a while to come to terms with this. It can be really difficult to let go of an identity that no longer fits us. We carry it with us because we’re too scared to let go of the happiness tied up with that identity.

It is actually quite therapeutic, winnowing our things. We don’t realize just how much all that stuff actually weighs on us until we let it go. Maybe part of it is that in the act of giving up the physical item we make peace with all of the emotional baggage, too. I dunno. Not my area of expertise.

So, all told, we probably took 4-5 car loads to Goodwill and the ReStore. And I feel that much lighter. :satisfied:

Taking Over A Project

Sun, 31 Jul 2016 21:00:00 +0000

These days life doesn’t leave me time for much outside of work and family. It is funny how one’s priorities can shift so suddenly and drastically, all within the blink of an eye. But, hey, that’s life.

An interesting thing happened, though. In my almost-hiatus from FOSS and Fedora, the upstream for one of the packages I maintain … disappeared. I don’t mean became abandoned or unresponsive. I mean actually and completely disappeared.

See, this project was hosted on GitHub as a personal project and the original developer was the sole maintainer of this project. Which was fine, particularly since this individual was more responsive than even some large projects with a headcount that rivals most mid-sized companies.

However, one day this individual had had enough and deleted the whole repository. I won’t go into the reasons, and they actually had little to do with the project, but they were sufficient to cause this individual to wash their hands of the whole matter and be done with it. This is understandable. I’m sure most of us have been pushed to the point of throwing our hands up in the air and saying “Fine. Screw it. I’m moving on.”

The problem is that with GitHub, when you delete a repository, it all goes. The code, the wiki, the issues – all of it. It doesn’t matter if you are the origin of 70+ forks. When you delete a repo, it all goes.

This just goes to show how important it is that Fedora maintains source RPMs as well as the binary ones. It also goes to show how important it is to maintain your own repo of any projects you deem critical. Luckily, Git makes doing so ridiculously easy and GitHub makes it easy to do so for the code and for the wiki. However, for the issues you are SOL.

Believe it or not, the torching of a moderately popular project isn’t the most interesting part of this story. People noticed when this project disappeared. And some of these people raised an issue on one of the other projects this developer had on GitHub. Others of us noticed and joined the conversation, even long after the developer stopped responding.

Several of us had fairly recent copies of the repo. Mine was current up through the last official release. But we were still missing quite a few commits. (As I said, this individual was very active). A handful of us decided to take what we had and set up an official fork as an organization. As we worked, more people came forward with their forks. We were able to rebuild the repository with all but two commits.

… And then the ridiculous happened. One individual was able to resurrect those two commits by downloading the patches using the URLs in the developer’s activity stream. … And then someone else was able to track down a cached version of the wiki before it was purged.

And there we were - a completely resurrected repository and wiki, all because of the efforts of a community that was heartbroken because a program they used frequently had disappeared.

And thus, we soldiered on. I’m proud to say that we just released our first official version as an organization. It includes a few bug fixes and updated links, but, hey, it is a start.

This is why open source is so awesome. When a closed source developer decides “Fine. Screw it. We’re moving on,” there is little that the community can do but send e-mail upon e-mail to an already haggard worker-bee, who inevitably ships those e-mails off to the junk folder. But with open source, a community can rise up out of the rubble of an abandoned program and thrive.

Assuming, someone else kept the source that is. So, the moral of the story is: keep copies of all the materials you can. Be it code, wiki pages, or even the issue-related e-mail stream.

Happy Hacking!

Setting Up Your VPS

Sun, 12 Apr 2015 06:39:00 +0000

Last time we talked about how a VPN can help protect our data and our privacy from would-be snoopers on public and semi-public networks, as well as from our internet service providers. I proposed two options - using a VPN service or setting up your own VPN on a virtual private server, or VPS. There is a third option that I intentionally neglected to mention, which is to set up a VPN on your own hardware. I generally dismiss this option for a few reasons.

For one, setting up a VPN on your own hardware will not protect you from your ISP. Kinda negates one of the major reasons for using a VPN.

Even if you happen to trust your ISP, very few of us are lucky enough to have an even remotely symetric connection. Most of us can get decent-to-good downstreams of 10+ Mbps, but we still have to contend with upstreams of 1Mbps or less. Why is this a problem? Well, say you are using a VPN out of your home to protect your laptop when you use it on a public network. All data you send and receive has to go through your home connection. Since the VPN server in your house is just a relay, it has to retransmit all data it receives, thus all data to and from your laptop is limited to 1Mbps. Yikes!

Hosting the VPN on a woefully imbalanced connection might have made sense several years ago before VPS-hosting services were so plentiful. Now, you can rent a VPS for less than it cost to maintain and power your own equipment. For example, as of April, 2015, Atlantic.net offers a Linux option with 256MB of RAM, 1 virtual CPU, 10GB of storage, 1TB of outbound data, and unlimited inbound data, all for $0.99 a month. While 256MB of RAM on a server is miniscule by today’s standards, it is still enough to run a VPN with plenty left over. Now the downside to a “Go Server”, as they call it, is that it is a flat rate for the month, unlike their larger servers which are billed only when they are provisioned (i.e. up) on a per-second basis.

So, in today’s post we’ll go through setting and securing our baby server, leaving the details of actually setting up the VPN for a later post. The following steps utilize the command line and are Linux-centric, but the process is very similar for those on Windows systems using Cygwin or Putty.

Generating Your SSH Key

The first thing to do, before actually creating our VPS, is to generate a SSH authentication keys that we will use to log onto the machine. This is a significantly more secure method of logging into a remote machine than standard passwords - particularly if you protect your key with a passphrase. This is for a couple of reasons: A) keys are significantly more difficult to crack with brute-force due to their larger size and random composition, and B) keys allow you to authenticate over a network without ever sending your password over the network where an eavesdropper can intercept it. If you protect your key with a passphrase, the passphrase is only handled on the local machine and never traverses the network. A good write-up on SSH keys can be found here.

To generate our private/public key pair, use the following command:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa.my_vpn

You will be prompted for an optional passphrase. If you specify a passphrase, you will be prompted to re-enter this phrase every time you attempt to use the key. If you want to be able to log in without specifying a passphrase, leave this blank.

The options used are:

-t rsa - Specify that we want to create a RSA key pair.
-b 4096 - Specify that we want our key to be 4096 bits.
-f ~/.ssh/id_rsa.my_vpn - Specify the path and base name of our key pair.

This will generate two files:

~/.ssh/id_rsa.my_vpn - Your private key. Keep this secret and back it up!
~/.ssh/id_rsa.my_vpn.pub - Your public key. Back it up! The contents of this file will get transferred to all machines you wish to use this key to log in to.

Generate a New Root Password

Next, we want to take a moment to come up with a unique password to use as the root password. Yes, I know we just generated a key so that we never have to actually enter the root password, but we still need to set one. So, pick a password that is reasonably secure. Optionally, you can generate a completely random one and store it in a password manager, such as keepassx.

Acquire Your VPS

Alright, now to actually acquire a VPS. Navigate to https://www.atlantic.net and click “Create a Server”, if you don’t already have an account. If you already have an account, then log into your account, and click “Add Server” under the “Manage Servers” header on the left. You’ll be prompted for the following:

Server Name - Choose whatever you want. For our purposes it is simply used to ID your server in the user panel.
Location - Choose a geographical location closest to where you will be using this the most (i.e. city you live in).
Select OS - I’ll be referring to a Fedora install, but the principles should be the same for Ubuntu, Debian, or Centos. There is no real advantage to pick 32bit over 64bit.
Plan - Pick GO.
Enable backups - If you want, but its cheaper to use rsync to backup your VPS to your home machine.

After you hit continue you will be asked for your name and billing and contact info. You know the drill. And yes, be honest. After you complete the account creation and e-mail verification process, Atlantic.net will e-mail you the IP address and password for your server. Once you receive this e-mail immediately SSH into your box as root:

ssh root@<IP ADDRESS OF VPS>

Once logged in you will be asked to change the password. Enter the password you came up with above.

Installing Your SSH Key

Now it is time to install your SSH key so that you can use it to log in instead of using the root password. To do so, on your home machine (where you generated the keys), open a new terminal and type the following:

cat ~/.ssh/id_rsa.my_vpn.pub | ssh root@<IP ADDRESS OF VPS> 'cat >> ~/.ssh/authorized_keys'

You will be prompted for the root password again, go ahead and enter it.

In your terminal that is still logged into your VPS as root, type:

chmod 600 ~/.ssh/authorized_keys

This is necessary for newer versions of SSH that have an added safety measure that imposes strict rules on the file permissions of authorized_keys.

Install Nano

By default, the only text editor installed is vi. For those that are not comfortable with vi, install the text editor nano:

yum install -y nano

From here on out, replace references to vi with nano.

Lastly, we want to disable logging in with passwords in order to prevent an attacker from brute-forcing the password. Absolutely DO NOT log out until we verify that you can properly log in after completing this step.

To disable password logins via SSH, edit the SSH daemon config file. The anxious will want to create a backup copy, first.

vi /etc/ssh/sshd_config

And look for the line that says:

PasswordAuthentication yes

Save and exit, then restart the SSH daemon:

systemctl restart sshd

Now try to log in with your certificate from your home machine:

ssh -i ~/.ssh/id_rsa.my_vpn root@<IP ADDRESS OF VPS>

If you were able to successfully log in, then your done. If not, go back and review installing your SSH key.

An optional step is to simply the SSH login command by setting up an identity in the SSH user config file on your home machine. Using your favorite text editor, edit the file ~/.ssh/config (creating if necessary) and add the following:

HOST vpn
     Hostname <IP ADDRESS OF VPS>
     IdentityFile ~/.ssh/id_rsa.my_vpn
     IdentitiesOnly yes

This allows you to log in to your machine with the following:

ssh root@vpn

Fini!

Congratulations! You’ve now set up your own VPS and secured it against brute-force password attacks. Next time we’ll get to the main event - setting up our own VPN to protect our internet traffic from prying eyes.

The Prying Eyes of Your ISP

Tue, 31 Mar 2015 23:28:00 +0000

It has long been known that one has to be careful when using public and semi-public WiFi due to the ease with which prying eyes can snoop on internet traffic. Back in the fall we learned that the two largest wireless carriers, Verizon and AT&T, have been injecting tracking cookies into the web streams of their users without their knowledge or consent, and that Comcast had been injecting JavaScript-based ads into web pages for users of its Xfinity WiFi service. And it has now come to light that AT&T is scanning the traffic of the users of its gigabit internet service - unless they pay an additional $30+ “privacy fee”.

Such behavior is expected when using the free services of the Facebooks and Twitters of the world. After all, when something is free that means you’re the product. However, there is a certain expectation of privacy that comes with using a paid-for service, particularly a paid-for communications service. Unfortunately, the laws that guarantee a measure of privacy with voice communications do not extend to internet communications - at least, not yet. Perhaps, now that the FCC has reclassified ISPs as common carriers, that will change. Until that changes, and perhaps even afterward, the only privacy you can count on is privacy you provide for yourself.

The simplest form of protection, at least for web browsing, is to use the encrypted HTTPS protocol, instead of the plain-text HTTP protocol, wherever it is available. Unfortunately, HTTPS isn’t offered everywhere. But even if every nook and cranny of the internet was available with HTTPS, the protocol still would only offer a modest amount of privacy. For one, the source and destination of each packet are still visible for the world to see. This is a fundamental part of how the internet works, so it won’t be changing anytime soon. Additionally, the protocol relies on the exchange of security certificates that are vouched for by trusted agents, known as Certificate Authorities, or CAs. A well-known weakness with all SSL-based protocols, such as HTTPS, involves an attacker inserting themselves in between the server and client during the certificate exchange such that the attacker can then impersonate each endpoint. This is known as a man-in-the-middle, or MitM, attack and ISPs are in the ideal position to institute such an attack.

A better solution is to use what is called a Virtual Private Network, or VPN. A VPN creates a virtual tunnel between client devices connected to the internet that makes each client appear to be on the same local network. VPNs can be configured to either route only client-to-client traffic or all of a client’s internet traffic through the tunnel. This second option is particularly interesting as a solution to problem of prying ISPs. This is because it allows us to set up a tunnel between the machine we are using, be it laptop, smart device, or whatever, and a trusted machine on a trusted network. Furthermore, if this tunnel is encrypted, then all the local ISP and anyone on the local network can see is a stream of seemingly-random data between your client and the trusted machine.

One obvious hole in this scheme is this: your traffic must eventually be exposed to the rest of the world where prying eyes can, well, pry, and where you run the risk of a nefarious party pulling a MitM. To this, I pose the following: which do you distrust more, your ISP or a VPN hosting service?

Not only are there a number of VPN providers in the wild, but it is reasonably simple to set up your own VPN using a virtual private server, or VPS. Contrast that with the fact that most of us only have one, maybe two, ISPs to choose from. So, to rephrase my question: which do you distrust more, your ISP, which considers you a captive audience who should be grateful for the overpriced service that they deign to provide you, or a VPN or VPS hosting service, who is competing on price, availability, reliability, respectability, and speed, among other parameters?

… Yeah, me too. So, how about we set ourselves up a VPN? Since using an existing VPN service is the easy way out, I will instead walk you through setting up your own VPN on a VPS. Running your own VPN has a handful of benefits:

Once set up, you can easily move your VPS to another service without a lot of fuss
You have greater control over what is happening to your traffic on the other side of the tunnel
It’ll be fun and a good learning experience
Plus, you can use your VPS for other things, such as an rss2email or personal git server

So, stay tuned!

Hello? Hello? This Thing On?

Wed, 25 Mar 2015 21:34:00 +0000

For years now I’ve tossed around the idea of setting up a personal site and blog. Usually, I would get a burst of inspiration after running into a problem, generally Linux-based, that I eventually figured out after banging my head against the wall. But before I could get around to doing anything with that solution, I would invariably become distracted by Yet Another Shiny Object™ and that was that.

So, I’ve finally gotten around to it. “Why now?” you may ask, after The Internet™ has moved on to Facebook, or Twitter, or Medium, or whatever? Well, I’m usually late to the party, regardless of the occasion. Actually, I’m usually really late to the party. But the nice thing about showing up to a party long after everyone else has gone home is that you get to pick the music - although you usually have to order your own pizza, which is a bummer.

In all seriousness, it was a confluence of things. For one, the thought has been on my mind a lot more recently than usual. Additionally, I’ve been tinkering with several things that I thought would be helpful to post somewhere on the internet, if for no other reason than so that I can find them later when I need them and can’t remember any of the details - and I happened to actually make notes this time.

What finally pushed me over the edge was Google Code closing down, interestingly enough. Years ago I wrote a few screen savers and released on Google Code, complete with a Google Pages site for them. Well, since Google Code is joining the great GeoCities in the sky, I decided to A) move the repository to GitHub to join various other projects that I’ve started, and B) find a new home for project page as well as the poor excuse for a home page I put up when I started The Idle Screen Project.

In looking around for a place to move the project page I ran across Jekyll, which piqued my interest. The fact that it is simple, uses an open source, markdown-based engine that plays well with Git and is easy to set up and demo at home - well, what’s not to like? Particularly for a person who still keeps various notes and brainstorming lists in LaTeX. (Yes, I’m one of those people.)

So, anyway, we’ll see where this goes. Stay tuned for what I hope are interesting and/or useful posts on various open source- and tech-related topics that keep distracting me from actually moving that fool screen saver page and properly setting up the repository.