Monthly Archives: May 2009

Non-hideous Condo in Ballard

I\’m sure there will be plenty who disagree with me, but I want to call out the Leva building in Ballard as a non-hideous building, mainly because of the face they put forward at the sidewalk level. Whatever you think of it, it is clear that they put some design and materials budget into it, which is more than I can say for a lot of the newer buildings in Seattle.

Posted via email from Erik\’s posterous

GoDaddy SSL Certificate Gotcha with NGINX

I got a cheapo SSL certificate from for one of our websites, installed it, and promptly got an invalid certificate error when I tried to test it with Safari.  It worked fine in Firefox.

A little googling showed this was a common problem.  I was cursing GoDaddy, but with a little more digging, I found that it was just their instructions that sucked.  They don’t have any information about using their certs with nginx at all, but I figured it would work the same way it worked when I generated a self-signed certificate.

What was missing is that I needed to also install some “intermediate certificates” by appending them to the bottom of our certificate. GoDaddy doesn’t include these certificates if you choose to download your certificate for “Other” webserver.  If you download the certificates for apache, they’ll include the intermediate certificates in the ZIP.  Then all you have to do is add them under the certificate for your server.

I owe my understanding of the issue to “Setting up GoDaddy Turbo SSL on Nginx“.

How and Why to Create Ubuntu Metapackages

Yesterday I wrote about my plans to make deploying new Ubuntu servers both easier and more repeatable by relying on apt metapackages.

I’ve been working on the implementation, and it’s going pretty well so far.  This documents the basic steps:

First, I installed the equivs package

aptitude install equivs

At this point, I’m not including any config files or post installation tasks, so I only have to worry about the control file.

#equivs-control my-metapackage

This generates a control file template in the current directory that you edit. I want to make sure my system has ufw, munin-node, logrotate, rsync, mlocate and wget installed, and I cleaned out the options I didn’t need, so my control file looks like this:

### Commented entries have reasonable defaults.
### Uncomment to edit them.
Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: my-metapackage
Version: 0.01
Maintainer: Your Humble Scribe <>
Depends: ufw, munin-node, logrotate, rsync, mlocate, wget
Description: Depends on Useful Bits and Pieces
 This is a dependency package that we use to make sure that basics,
 like a firewall, rsync, munin-node, etc, are installed.

Next step is to turn that into a debian package:

#equivs-build my-metapackage
dh_clean -k
dpkg-deb: building package `my-metapackage' in `../my-metapackage_0.01_all.deb'.
The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!

Now to test it out:

sudo dpkg -i my-metapackage_0.01_all.deb

This will install my-metapackage, but that’s not enough. Dpkg can’t satisfy remote dependancies, so it will throw errors for each of the dependencies you created and leave your newly installed package in a broken state. You can then use aptitude to resolve these missing dependencies to complete the process:

sudo aptitude -fy --safe-resolver install

This tells aptitude to install to fix any missing dependencies. 

That should be it.  I’ll note though, that for some reason, aptitude was insisting on removing my packages, rather than fixing the broken dependencies.  I’m not sure why, and I’m not sure why its working now

Simplifying Ubuntu Deployment with Custom Metapackages

I think being a good sysadmin requires a special combination of conscientiousness, industriousness, and laziness.  In the past, I’ve never quite had the right mix, I’ve been trying to change that though.  Most of the Ubuntu Linux systems we’ve deployed at work have been one-offs — One of the developers or I fired up a machine or virtual machine with an Ubuntu install CD and stopped once we had the machine doing whatever we needed it to do.  I simplified the process a little by saving a copy of a freshly created VM that I could reuse, but that still takes a bit of manual labor.  

When we started deploying virtual machines for deploying production and staging versions of our apps at an outside hosting provider, I decided it was time to up my game.  The virtual machines are provided with a very basic linux installation.  I scripted as much of the basic system configuration as possible, and was careful to update my script when I made a change or addition.  That helped considerably, when I brought up a second machine, but now that I’m about to do a third, I feel the need to go even further.

I’ve decided to take the approach of creating “metapackages” to handle the installation most of the required pieces. After that, I plan to create some basic packages for a few of the things that we are compiling from source.  I’d also like to figure out how best to automate the further configuration of some of the packages.

Ubuntu Linux is built on top of Debian Linux and it uses, apt (Advanced Packaging Tool), Debian’s packaging, system to manage software installation, maintenance, and removal.  Packages can contain binaries, configuration files and scripts, source code, documentation, etc.  They also define relationships with other packages, such as whether they depend on another package, what functions they make available that might satisfy dependancies of other packages, whether they are a replacement for some other package, etc.  Apt takes advantage of this information to make sure everything that needs to be installed gets installed, and doesn’t conflict with other pieces.  It’s this dependancy management that I’m going to take advantage of first.

A vast number of volunteers in the Ubuntu and Debian communities have done the hard work of packaging thousands of pieces of open source software for easy installation.  They’ve found the source code, they’ve figured out all the dependancies, they’ve considered important use cases to come up with useful default configurations.  They’ve tested things to make sure they work as expected, created patches if they don’t, and they update the packages when new versions of the packaged software is released or bugs are patched.  I’m going to take advantage of all their hard work by creating “metapackages,” which just specify all the existing packages I need to install.

Figuring out the best way to go about creating metapackages is a job in and of itself.  If wouldn’t be Linux if there weren’t at least 4 different ways to do things, and creating debian packages is no different. With some digging though, I found this post on the Ubuntu forums, which pointed to the “equivs” package, which was helpful, because it’s not mentioned in the Ubuntu Packaging Guide.  Armed with that clue, I found a nice looking HOWTO on the Ubuntu forums for creating metapackages with equivs.  It looks like it even covers one of my next steps, which is to handle custom configuration of the installed packages.

For now though, I’m headed outside to work in the yard since we got a break in the rain.  I plan on posting a followup once I’ve had a chance to try putting what I’ve learned into practice.