One of my philosophies in life is to set personal goals that seem almost impossible to reach. Then reach them. Yes, it sounds ridiculously cliche, but it moves me forward. One such goal of mine was to break 8 bricks. While I didn’t quite nail it last November, I got close.

This year, I plan to try my hand (literally) at 9 instead.

Following up on my post about installing a receipt printer on Ubuntu, I mentioned that I would post my experiences setting up a Ubuntu repository. Most of the documentation out there only covers setting up a repo on your own local machine, for your own local use only. On top of that, the docs vary between how much they tell you about the specifics of a Ubuntu vs Debian setup. Since I am likely not the only one trying to make this kind of thing, I’m posting a step-by-step guide on how to do it yourself.

The Goal

We want to setup a publicly accessible Ubuntu repository so that we can distribute our own .deb packages to other users. Since we’re on a budget, we’re going to host this repo on our DreamHost account. Above all else, it needs to be easy to maintain, since we want this to make life easier, not harder.

The Plan

We’re going to create a local repository on our development machine using dput and mini-dinstall. Then we’ll sync it to the remote web server using rsync and ssh.

The Prerequisites

As always, this guide assumes that you are familiar with Linux and are comfortable doing things on the command line. If not, turn back now, before it is too late! This is not a guide for beginners.

We’re also going to assume that you’ve got a hosting package with DreamHost, and a domain name to which you can add sub-domains.

Lastly, we’ll assume that your development machine is running some form of Ubuntu Linux. I used Feisty (7.04) when writing this article. Adjust the steps as needed for your own setup.

The Process

1. Set up a domain

To keep your website clean, it’s a good idea to set up a sub-domain of your primary site on which to host your repo. Using my site www.drelmo.net as our example, we set up packages.drelmo.net as our domain. On DreamHost, you want to set this up as a Fully Hosted Domain. If you know what you’re doing, you can customize the options on the setup screen, but the defaults are all fine.

2. Configure your SSH login to the new domain

To make life easier down the road, we’ll need a password-less SSH login to the site. I won’t go into the details of how to do this, as it has been documented far better in countless places. The DreamHost wiki, for example. I’ll assume from here on out that you can simply type “ssh user@server.dreamhost.com” and get dropped into a bash shell.

Again, if you don’t understand that last sentence, stop now, before you hurt yourself.

3. Create a folder for the public repository

To keep things clean, I like to segment things a bit. This is an optional step, but one that I suggest doing unless you have a really good reason not to. Log into your server real quick and in the webroot, make a folder called ‘archive’. In the case of our example, this would go something like this:

ssh user@server.dreamhost.com
cd packages.drelmo.net/
mkdir archive
exit

4. Set up your repository… locally

I know, I know, we don’t care about having a local repo, we want to share it with the world! Sit tight, junior. This is part of the process. On shared hosting, you likely won’t have access to the tools needed to easily maintain a repository, and for good reason. So we’re going to set it up (and yes, keep it there) on our development machine first.

Rather than rewrite it, I’ll point you to the excellent guide that I followed called LocalAptGetRepository, over at the Ubuntu Community site. Follow that all the way down to (but not including) the section called “Changing your systems apt-get sources.list“.

All done? Great! Let’s move forward.

5. What you should have so far

At this point, you should have a folder somewhere on your dev machine that looks something like this:

/home/marc/archive
/home/marc/archive/feisty
/home/marc/archive/gusty
/home/marc/archive/mini-dinstall

And in those folders should basically be everything you need for your repo, hopefully with one or more packages already imported. If not, I suggest getting to that point before you move on.

6. Copying your local repo to the remote webhost

We can simply type in the rsync command to get all our files up there, but we want this to be easy later on, remember? So let’s make a simple bash script that can do it all for us, so we don’t need to constantly retype the whole thing. I recommend calling it something simple like “sync-repo“. Stick the following into it, making sure to adjust for your setup.

A few notes about the script: Wordpress messes up the display of the rsync command, so there are two things to pay attention to.

1. The three lines, starting with the rsync one, should all be on one line.
2. The long dashes in front of “stats”, “progress”, and “exclude” should actually be two normal dashes.

#!/bin/bash
rsync -rlptvzh --stats --progress --exclude=mini-dinstall 
-e "ssh -l user" /home/marc/archive/ 
user@server.dreamhost.com:/home/user/packages.drelmo.net/archive/

Now save the script, chmod +x it, and run it! If all went well, you should be able to point your browser at the equivalent of http://packages.drelmo.net/archive and see the same folder tree as the one on your machine. You’ll notice that we excluded the mini-dinstall folder, because that should not be made public.

The Beautiful Finish

The final step is to add your brand new repository to your /etc/apt/sources.list. Open up the list in your favorite editor:

sudo vim /etc/apt/sources.list

Then add in the lines for your repo:

deb http://packages.drelmo.net/archive feisty/
deb-src http://packages.drelmo.net/archive feisty/

Update your cache and you’re done!

sudo apt-get update

The Conclusion

If you’ve followed along, you should now have your very own Ubuntu repository. To add new packages to it, just use dput on your local machine, then run your sync-repo script to update the online version. It’s that easy!

So for one of my clients, I’m setting up a Ubuntu-based Point-of-Sale (POS) system. Part of the headache of getting this going (on top of actually building an interface) is getting the receipt printer to work. One of my biggest pet peeves is manufacturers who provide “Linux drivers” but only pre-compiled binaries for crap like Red Hat. Thankfully, I got to choose the printer we ordered for the store, and Star Micronics provides GPL’ed source code to their drivers. Hooray! So we ordered a TSP600, black, USB interface, with the auto-cutter.

The next problem was getting their code to compile and install cleanly on a Ubuntu Feisty system. My goal in this was not only to be able to compile the library from source, but to package it into a .deb file for easy installation on the store computer. After a whole day of researching and testing, I finally got it to work.  It took some tweaking of the default makefile and setup.sh, but the result is a working starcupsdrv_2.3.0-0ubuntu1_i386.deb, which is the CUPS driver for these Star printer models:

- TUP900 Presenter
- TUP900 Cutter
- TSP1000
- TSP800
- TSP700
- TSP600 Cutter
- TSP600 Tear Bar
- TSP100 Cutter
- TSP100 Tear Bar
- SP500 Cutter
- SP500 Tear Bar

As I’m not interested in being a full maintainer for the package, I am not planning on submitting it to the Ubuntu or Debian projects. If, however, you’re reading this and would like a copy so that you can set up your own printer quickly, just toss me an email. I’d be happy to send you the .deb to make your life easier.  Just install it, then plug your printer in, and it will be automatically recognized by your favorite CUPS administration utility.

The Packaging Experience

I had never packaged my own .deb files before, so I read a LOT of docs on the subject. First and foremost, let me reiterate what most guides start by saying: Packaging .deb files is a complicated process. Expect to spend a lot of time learning how and trying different things. That said, it is an excellent way to handle software distribution to client computers, especially when coupled with your own software repository. I’ll post my experience setting up a repo later on.

For those that want to learn how to package an application into .deb files, the following are URLs that I recommend reading front-to-back, no matter how long they may be:

• Debian New Maintainer’s Guide
• The Ubuntu Packaging Guide
• Ubuntu Pbuilder How To

The Debian one is really just so you understand what you’re doing. The Ubuntu Packaging Guide is the real setup of what you want to follow (I focused on the debhelper method). Pbuilder is a tool you simply cannot do without, and the How To is really an explanation of how to set it up. It may seem daunting, but in the end it’s pretty simple.

Now I have a basic understanding of how to create a package. Hardly something that every programmer should get familiar with, but if you work with Debian-based distributions much, I highly recommend trying out.

I started working on a new client site in Rails recently and reached the point where I was ready to launch a starter-version over at OCS. In the process, I wanted to upgrade a few of my practices and utilities, most notably Capistrano. I have been using the 1.4 series for a while, but this was a brand new site, so what better opportunity would there be to start using 2.0?

Since Capistrano 2.0 is relatively new to the scene, the documentation (as with most Rails-related projects) was lagging behind. The team changed a lot about how 2.0 works, making most of my old deployment recipes obsolete. The problem is, the info about how to write new ones is still very scattered and hard to navigate. OCS was suffering from much the same problem, with no detailed guide on getting a new Rails app ready and launched on their servers. Since I knew I’d need to repeat the process in the future, I decided to document the process as I went. Halfway through, I realized that I was likely not the only one who could benefit from such a guide.

The result of my efforts was posted later that day on the official OCS Support Wiki, as an article entitled “Step-by-step setup using Capistrano 2.0 and Mongrel” under their Ruby on Rails section. It even got a mention and some kind words on the OCS Blog.

Like most web developers, I get asked fairly regularly who I recommend for setting up simple websites. For the record, my experience with project hosting has been very polar. I’ve done a few sites where the requirements called for a full dedicated server, which I got to set up by hand. If there is interest in those installations, I can post some info about them. For now, I’m going to focus on the other end of the spectrum: shared hosting.

#1: OCS Solutions

My uncontested favorite. If you’re setting up anything beyond a simple personal site, these are the folks to go to. Not only do they specialize in Rails hosting, but they actually answer the phone! No, wait, I’ll do you one better. Their CEO (Robert) is part of the 24/7 phone support shift and actually knows exactly what he’s talking about! I know of no other (legitimate) hosting companies that can make that claim.

I’ve already got a few client sites hosted with them, so the team there has seen my name in a good number of support requests already. They never fail to get back to me within 24 hours, but usually less than 3. When I have a truly urgent issue, they are always there on the phone. I have yet to ever leave a voicemail.

More than anything else, their Rails hosting is phenomenal. The first site I moved over to them was a relatively basic Rails app that had been having speed and uptime problems on Dreamhost, even with minimal load. Ever since the move (with zero changes to my code) the site has performed like an athlete on speed. From now on, all of my Rails apps are going on the OCS servers.

My only gripe with them is the occasional usability issues with their web panels, which is where I still use #2 for a few things.

#2: Dreamhost

Very strong in some areas. Very weak in others.

Dreamhost is the ideal “budget-hosting” solution. For a not-expensive price, an account with them will let you do a lot of things. You can register and host a virtually unlimited number of domains with one account. Their “One Click Installs” make basic sites (like this one) ridiculously easy to manage. Even their interface to Subversion, while lacking some more advanced functionality, is ideal for small projects.

On the other hand, their Rails support is not 100%. Google it and you’ll see what I mean. There are posts and discussions abound all over the net about how to get your app to work smoothly, with mixed results. I spent a long time tweaking the code on the Muir Surf & Sport site to get it to work. The best I could get it still had a 1-2% rate of 500 errors. Not acceptable.

To make things worse, their support is sub-par. Their target audience is a very broad client base, so they can’t afford to offer phone support. Ok, fine, I can email them when all hell breaks loose. But when one of my client’s e-commerce sites went offline, completely, it took Dreamhost over 8 hours to get back to me. And guess what? It was their fault it had gone down in the first place! That was the brick that broke the camel’s back for me. I will never again have a client ask me “Why is my site down?” and have to answer “Oh, I’m waiting on the host to get back to me.”

Concluding Thoughts

The basic summary is that Dreamhost works for most circumstances. If your needs are basic, and/or reliability is not mission-critical, then they are a fine host. But for critical projects, 99% uptime means that 10,000 out of every million hits will fail. If you need Rails hosting, and/or actually want good support, go with OCS. The cost is not much higher, but you’ll notice a huge difference.

Alright, I’m finally doing it.

In the spirit of 99% of the rest of the Rails coders out there, I’m jumping on the bandwagon and making my own blog.  For years, I’ve hated even the word “blog” as to me the idea represented adolescent ramblings from dissatisfied narcissists.  This is probably due to the original uses of blogs by the ever verbose “pre-teen” crowd, posting such brain teasers as “OMG!!! SO JEFF TOTALLY JUST IM’ED ME AND WE’RE LIKE TOTALLY GOING TO SEE A MOVIE TOMORROW BUT I DON’T KNOW IF IT’S A DATE WHAT DO YOU THINK?” (spelling corrected for readability).

Thankfully, the idea of blogging has spread to people that actually have something worth talking about.  Bruce Shneier and Jim Hollan always have interesting things posted.  My friend Kevin Clark is definitely my go-to person for cutting-edge Rails info.  Not to mention I’ve owned drelmo.net since February of ‘99, yet I haven’t done anything interesting with it in years.

So here begins my attempt to contribute something useful and insightful to the “blogosphere”.  Let’s see where it goes.