Monthly Archives: January 2011

coloncolonone.net

For some reason I decided it was a good idea to register the domain coloncolonone.net. Currently it is only used to serve a static html page, proclaiming the following message.

There’s no place like ::1

Any ideas on other, possible slightly more creative, ways to use the domain name?

OpenSSH 5.7, SFTP and hard links

OpenSSH 5.7 just got released. You can read the full announcement at http://www.openssh.com/txt/release-5.7. Personally I especially appreciate the following improvement to their SFTP stack.

sftp(1)/sftp-server(8): add a protocol extension to support a hard link operation. It is available through the “ln” command in the client. The old “ln” behaviour of creating a symlink is available using its “-s” option or through the preexisting “symlink” command

Being able to handle hard links definitely makes SFTP even more useful as a remote filesystem.

Tarsnap Nagios checks

While I have been using Tarsnap for a while now it is first recently I have gotten around to make Nagios monitor those backups. Given that I really don’t want to give the nagios user any actual access to my backups, I instead take the approach of having my backup script create a status file containing a Unix timestamp of the most recent backup.

My check_tarsnap Nagios plugin can then use that status file to check that the most recent backup isn’t older than a specified number of hours. For my nightly backups I have the Warning threshold set to 26 hours and the Critical threshold set to 42 hours.

(See the top comment in the plugin source for an example on how to create the status file.)

Managing passwords using GnuPG, Git and Emacs

Like any other security conscious and/or slightly paranoid computer geek I have lots and lots of unique and nontrivial passwords to keep track of.  My solution to this problem involves having one GnuPG encrypted text file per username/password pair.

andreas@stilgar:~/safe$ gpg < example.gpg

You need a passphrase to unlock the secret key for
user: "Andreas Olsson <andreas@arrakis.se>"
4096-bit RSA key, ID 9A943D4A, created 2010-07-11 (main key ID 13CD4F59)
  Here gnupg-agent calls pinentry-gtk2 to prompt me for the passphrase
gpg: encrypted with 4096-bit RSA key, ID 9A943D4A, created 2010-07-11
      "Andreas Olsson <andreas@arrakis.se>"

https://127.0.0.1/

username: sigge
password: sigge

andreas@stilgar:~/safe$

As I need to have access to those passwords on more than one computer I use Git, and a remote repository, to keep my encrypted files in sync. Other options might be to mount a SFTP folder using SSHFS, or to simply put the files in your Dropbox. Yet, if you too decide to go with Git, here is a .gitignore you might want to use.

andreas@stilgar:~/safe$ cat .gitignore
*
!*.gpg
!.gitignore
andreas@stilgar:~/safe$

Thanks to Emacs and EasyPG it is a breeze to  create new GnuPG encrypted text files, as well as to modify existing ones. Just use the file extension .gpg, and EasyPG will do its thing. The first time, when you actually create the file, you will be prompted for which public keys you want to encrypt against.

andreas@stilgar:~/safe$ emacs yet_another_example.gpg

(EasyPG is included in Emacs 23, and don’t need to be installed separately.)

Do note that this method also works when there are multiple people involved. Just make sure that the intended users have access to the share/repository in question, and that their public keys are included when you create the GnuPG files.

Server configuration and version control

One of the (few?) good habits I managed to pick up during 2010 was that I became serious about keeping server configuration under version control. While it might primarily have been something I was taught at work it is definitely a practice I have adopted privately as well.

The most obvious benefit, and potentially the most valuable one, is the historic record version control provides. Yet, the part I appreciate most is how easy it becomes to compare new configuration against current one; to verify that you only made  just those changes which you  intended to make. There is a certain comfort in being able to run a git diff before restarting a local service or before pushing new cluster configuration.

(Not that I do not appreciate having access to the configuration history. When being asked about something which happend a few months ago, those commit messages and those diffs becomes awful handy.)

For your local /etc this is as a good time as any to take a peak at etckeeper.

Hosting myself

About half a year ago this blog moved to wordpress.com. As of this post my blog is moving back home to my (virtual) server.

While I have been generally happy with the service provided by wordpress.com I guess I still prefer having the ability to do things my way. I especially enjoy yet again having the blog properly integrated with my Yubikey.

(Bonus being that the blog is yet again reachable using IPv6.)