This is the script /usr/local/bin/ssl-cert-check which checks the expiry date of the certificate files passed as arguments:

#!/bin/bash

DAYS=30

for file in "$@"; do
    openssl x509 -checkend $(( 86400 * $DAYS )) -in "$file" > /dev/null
    if [ $? != 0 ]; then
        echo "==> Certificate $file is about to expire soon:"
        openssl x509 -enddate -in "$file" -noout
    fi
done

And the corresponding cronjob entry checking SSL certificates once a day:

6       6    * * *   root   /usr/local/bin/ssl-cert-check /etc/apache2/ssl/*.crt /etc/ssl/certs/dovecot.pem

I prefer IRC as communication protocol for multi-user chat and instant messaging. To keep in contact with users of other protocols/clients I use BitlBee which is a gateway connecting other chat networks like Jabber/XMPP and ICQ to your own IRC server.

IRC is a well-established open protocol, but unfortunately it lacks encryption or other measures to secure the transmission of information. I don’t want to run an open BitlBee server, but password protection in plaintext is quite useless if you are in an untrusted network. Authentication should be done with a challenge-response method to avoid leaking passwords, but IRC as a very old protocol does not offer anything like this. And again communication itself would still be unencrypted.

Many people use their terminal-based IRC client irssi over SSH. This way the client runs on the same machine as bitlbee, so a very simple solution would be to bind the server socket to localhost only in this case. For me this is not an option as I am using a GUI-based IRC client xchat locally.

Fortunately it’s possible to secure any TCP connection using SSL!

Unfortunately BitlBee itself does not have builtin SSL support for the server. But a general solution for this problem exists: stunnel. This program acts as a general wrapper around any stream socket based program and is often in use for inetd based services.

Setup instructions

The following instructions are for setting up bitlbee over xinetd with stunnel to secure the connections. Be aware that this inetd approach will spawn a new process for each incoming connection. This setup is not meant to serve many users at once, but works fine for personal use.

First we have to generate and self-sign a new certificate to be used with SSL:

# openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout /etc/stunnel/bitlbee.pem -out /etc/stunnel/bitlbee.pem

Usually you need to be root to write to /etc/stunnel. Of course you can also use a pre-existing certificate signed by a well-known CA or request a new one.

Only stunnel for BitlBee needs to read the certificate file, so we will need a new user bitlbee for this purpose. On my Debian system the package management already added such a user, so your mileage may vary.

# adduser --system --group --disabled-login --disabled-password --home /var/lib/bitlbee/ bitlbee
# chmod 700 /var/lib/bitlbee/
# chown bitlbee:bitlbee /etc/stunnel/bitlbee.pem

Then we need to set up xinetd to secure the connection using stunnel. I modified the basic configuration file provided with the BitlBee source for this; changes are marked in bold text below. The following file should be saved as /etc/xinetd.d/bitlbee:

## xinetd file for BitlBee. Please check this file before using it, the
## user, port and/or binary location might be wrong.

## This file assumes you have ircd somewhere in your /etc/services, if things
## don't work, check that file first.
service ircd
{
        socket_type     = stream
        protocol        = tcp
        wait            = no

        ## You most likely want to change these two
        user            = bitlbee
        server          = /usr/bin/stunnel
        server_args     = -p /etc/stunnel/bitlbee.pem -l /usr/local/sbin/bitlbee

        ## You might want to limit access to localhost only:
        # bind            = 127.0.0.1

        ## Thanks a lot to friedman@splode.com for telling us about the type
        ## argument, so now this file can be used without having to edit
        ## /etc/services too.
        type            = UNLISTED
        port            = 6667
}

After the file is in place, xinetd configuration files need to be read again:

# /etc/init.d/xinetd reload

Now you should be able to connect to bitlbee using your favorite IRC client! Make sure you enable SSL for this connection. If you are using a self-signed certificate you will have to verify it, of course.

For bitlbee usage, you should refer to the official documentation. And maybe I will also write down some basic setup instructions for a closed server in the near future…

$ pastie --help
Usage: pastie [options] [files...]

Options:
    -h, --help          display this help
    -l, --lang    set language of the paste
    -p, --private       make paste private

If --lang is not specified, this script will try to determine the type of each
file automatically based on the extension. If no files are given on the
command line it reads from standard input.

You can download it here:
http://pastie.org/904797

The script is public domain, so do whatever you want with it.

Although this is the initial release, I bumped the version number to 1.6 already. During testing the script I pasted itself several times to pastie.org. I set a arbitrary higher version number to avoid confusion in case the previous pastes ever turn up in Google or wherever.

Update:
Seems like their parser for shell is a bit broken and doubles the heredoc starting and ending sequences in the output. For whatever reason it appears as “<<END<<END”. Please use the raw version for download instead of copy & paste.

Imagine a command producing a list of numbers like this:


$ ...
42
23
966
1764
529
4711


Now calculating the sum of these numbers is not trivial. Using tools like bc or calc directly is not possible because you would need to put plus signs between the numbers first. So you could probably replace all ‘\n’ with ‘+’ with tr — but not the last one as that would lead to a syntax error later. Or as an alternative you could write a long shell construct with while read ... etc. In short this is just getting way too complicated for such a simple task.

Here is the simple solution in awk:


$ ... | awk 'BEGIN {total = 0} {total += $1} END {print total}'
8035


Just add the option change_editor to your ~/.bazaar/bazaar.conf in the [DEFAULT] section.

For example:


[DEFAULT]
change_editor = vimdiff -f @new_path @old_path

Alternatively, you can of course use meld or kdiff3 as well as change_editor, which will be a lot easier to use for beginners.

The placeholder @new_path will automatically be replaced with the path of the new version and @old_path with the path of the old version. With this configuration, there will be a new choice “e” during shelve:

...
Shelve? [yNefq?]

Entering “e” will start vimdiff in a two column view with the new version to the left and the old version to the right. You should read :help diff in vim to get more information about this mode. Basically you can obtain changes from the other buffer using do (“diff obtain”) and put changes to the other buffer using dp (“diff put”). Note that the old version on the right will be read-only and you are not supposed to change it. Also do not make unrelated changes or introduce new differences as that will result in conflicts on bzr unshelve later.

When you are fine with the changes exit the editor with :wqa. After confirming the shelve once more, you will see the left file as the new version in the working tree and every difference to the right file will be shelved.

Unfortunately this is not yet documented in bzr itself at the time of this writing.

Instead, after too much struggling with git, I totally turned to bzr now. Why? Now that’s what this post is about.

Supporting multiple workflows

One cannot deny that git is very successful in what it does. But let’s take a look back in the history how git has been started all. At first it has been written as a management tool for the Linux kernel development. The first goal was to create a fast distributed version control system, which was met very early. Back then it was only usable for technical aware people (see the man page, it still calls git the stupid content tracker).

Later on, git has been improved a lot and became easier to use. But what stayed was the Linux centric view of development. Therefore, git has good support for a distributed workflow as it is used in Linux kernel development, but nothing more. So if you want to use git productively in a team you have to adopt this workflow, which is entirely based on a hierarchy of pull operations. The main developer pulls from fellow developers, those again pull from below and so on.

With bzr instead, you have the choice how you want to work. There is more than one workflow and it is possible to use them all. Of course you can do the same with bzr as with git, setting up a pull-based distributed system. But bzr also supports working in centralized ways. You can bind your local branch to another remote branch. Every time you commit, it will automatically be submitted to the bound branch. This is also sometimes called a checkout. A branch contains the full history which will be available for local operations after pulling from remote. Additionally there are lightweight checkouts, where the branch is not in the same location as the checkout and therefore requires access to the branch for almost all operations. But compared with branching a lightweight checkout is a very fast operation and requires less network traffic.

Supporting centralized workflows makes it easier to convert existing projects and infrastructures from CVS/SVN to bzr. There is not much training required for the developers as it works nearly the same as their old system after initial setup.

Each branch has its own tree

As we are talking about workflows this is the next point. A git clone can fetch a lot of different branches. All live in the same directory and if you want to view another one you need to use git checkout <branchname>. You cannot compare files in branches in a simple way with external tools, you always have to use git diff

(or rather git difftool) which operates on temporary files which means you are unable to edit files right there.