However, it does meet the most important criteria: It just works for me.

Now for the big disclaimer: Most of the projects I use bzr to manage fall into 1 of 2 categories:

1. Projects with small teams (1-4 developers)
2. Public projects where I just want to grab the source and maybe maintain some local patches

If I needed to somehow manage a project with dozens or hundreds of contributors (like Gnome or the Linux Kernel), git would probably look a lot more appealing to me. After all, it was designed for large code bases with lots of contributors and branches.

I’ve seen lots of git cookbooks popping up lately, so I thought I’d explain my bzr workflow for the 2 use cases I list above.

1. Starting and sharing a project with a small team
Prerequisite: You’ve created a directory with some code in it.

1. Turn your source code directory into a bzr repository:

   ~/src/foo$ bzr init

2. Add you source files:

   ~/src/foo$ bzr add

3. Commit:

   ~/src/foo$ bzr ci

4. Push my changes to a remote location* other team members can access:

   ~/src/foo$ bzr push --remember sftp://some/file/server

Done! My favorite part is that besides the --remember option, bzr just does what you expect without any flags or configuring. The --remember option simply tells bzr to use that location for future push commands (so you can drop all the typing after “push”).

For more information check out the excellent bazaar documentation on sharing code.

2. Getting the code for an open source project

Unfortunately most big bzr-hosted projects are on Launchpad which makes for a pretty boring demonstration:

~/src$ bzr branch lp:terminator # yawn

To make matters worse, non-Launchpad hosted projects are nearly as dull:

~/src$ bzr branch http://bzr.savannah.gnu.org/r/gnash/trunk

In each case bzr will create a new directory for you using the last part of the source path (terminator & trunk respectively). You can optionally give it a second argument to put the branch in a different location. The destination can even be a remote server!

~/src$ bzr branch http://source/branch sftp://destination/branch

Ok now I’m just showing off. I’ve never found a use for that feature. However, I do appreciate that a location is a location to bzr regardless of whether that location is the local filesystem or a remote server. It just works how you’d expect it.

Chapters 4-6 of Bazaar’s documentation give some excellent examples of various collaboration workflows.

Bonus Feature: Subversion mode!

So its not really Subversion mode, but bzr does support pulling repositories via the checkout command and updating your working copy from the remote repository via the update command just like Subversion. As you would expect, the commit now sends changes directly to the remote server.

While I’ve used this feature mainly to make transitioning to bzr easier for Subversion users, Bazaar’s documentation has some excellent techniques for making advanced workflows easier using checkouts.

• bzr+ssh is faster than plain old sftp but requires bzr to be installed on the server.
• Setup ssh connection multiplexing using ControlMaster in ~/.ssh/config and leave an ssh session active to speed up bzr operations.

Denyhosts has been doing its job perfectly. It should be illegal to run a Internet exposed SSH server without it or a similar tool.*

Thanks to HoopyCat in #linode for pointing me to a SANS Internet Storm Center article explaining the Summer of Hacks phenomenon.

* Unless of course you only accept key based logins.

Goal: Backup a directory from computer Zim to computer Ark

Details:

• Both Zim and Ark are subdomains of example.com
• The user on Ark which receives the backup files is named backupuser
• The user on Zim with access to the files you want to backup is named steve

Prerequisites:

• ssh installed on both hosts
• rsync installed on both hosts

1. Login to Zim via ssh:

   ssh steve@zim.example.com

2. Generate a ssh key pair using:

   ssh-keygen -t rsa
   <press enter when prompted where to save the key>
   <press enter twice when asked for a passphrase>

3. To use the key to login to Ark remotely without manually entering a password you need to copy the public key from Zim to Ark using:

   ssh-copy-id -i .ssh/id_rsa.pub backupuser@ark.example.com

   If you don’t have ssh-copy-id on your system, get a new system. If thats not possible you can download the script with:

   wget -O ssh-copy-id http://cvsweb.mindrot.org/index.cgi/~checkout~/openssh/contrib/ssh-copy-id?rev=1.6;content-type=text%2Fplain && chmod +x ssh-copy-id

   Then retry the above command only you’ll need to prepend a “./”:

   ./ssh-copy-id -i .ssh/id_rsa.pub backupuser@ark.example.com

4. Verify the key copied properly by attempting to login to Ark. You should not be prompted for a password:

   ssh backupuser@ark.example.com

5. Logout of Ark. The key is setup, so you’re now ready to rsync files without having to manually enter a password.
6. Test rsync by choosing a small file to backup and using:

   rsync -tP /some/small/testfile backupuser@ark.example.com:/tmp

   A nice little progress bar should be displayed as the file is transferred. Confirm that “testfile” is now in /tmp on Ark.

7. You’re finally ready to do a real rsync like:

   rsync -t /directory/to/backup/* backupuser@ark.example.com:/existing/backup/directory

   Note: There are several useful options for rsync. Check man rsync to find out more.

   • -p — preserve permissions (useful for backups, use -E if you only care about the executable bit)
   • -r — recursively backup directories.
   • -z — compressed uncompressed files
   • And just FYI: -t tells rsync to use the last modified timestamp to determine whether or not to transfer files. It makes rsync a lot faster at determining whether or not files have changed.
8. To schedule the backup to take place nightly at 1:13 AM edit your crontab using crontab -e and insert the following line:

   13 1 * * * rsync -qt /directory/to/backup/* backupuser@ark.example.com:/existing/backup/directory

Caveats:

• These instructions will push files from Zim to Ark. There’s no reason why Ark couldn’t pull files from Zim. In fact, this is often more secure if Zim is a web server with a larger attack surface than Ark. Mea culpa.
• If the IP address of Ark is dynamic, use a service like dyndns.com. Otherwise SSH will give you errors.
• Major security warning: If someone breaks into Zim, they can also delete all of your backups on Ark. Never ever ever use the root user for backups on Ark. You can use the root user on Zim to send the backups, but its best to have a special backup user setup on Ark to receive the backup.

   ssh username@ridiculouslylong.domain.com

Ugh

Using the same username makes life a bit simpler:

   ssh ridiculouslylong.domain.com

Meh, better, but I’m really lazy!

I’d heard about tab-completion for hostnames from various blogs, but never knew how to do it. I hopped into #debian and thirty seconds later someone had kindly told me about ~/.ssh/config

Not only is any host listed in your ~/.ssh/config auto-completed on the command line by hitting tab, but you can also specify what username to connect as! So my .ssh/config file looks something like:

Host host1.domain.com
     User randomuser
Host www.somewhereelse.com
     User someotheruser
Host mail.domain2.com
Host domain3.com

Now I can just type:
   ssh h<TAB><ENTER>
to connect to host1.domain.com as randomuser.

Beautiful.

Check out man ssh_config for details and other options.

Also, if you’re not using ssh keys instead of passwords, you’re doing too much work. Seahorse makes SSH keys simple.