Debian packaging with git – Part 1

Recently, I’ve been taking a look at tools to version control and maintain my Debian packages in git.

Git, like mercurial, is a distributed SCM used to maintain the Linux kernel since version 2.6.12. Branching in git is very cheap, and merging is trivial and follows a decentralized model where developers can push and pull code with each other in true distributed fashion.

Of the Debian tools I’ve tried, the main contenders are:

• gitpkg
• git-buildpackage

gitpkg, is extremely simple to use, and quick to get you off the ground. If you already have an entire revision history of .dsc, .diff.gz files, maintained in the good old fashioned way, gitpkg provides the git-debimport utility that lets you import everything into a git repository in one go. It does this intelligently by applying consecutive revisions and tagging the different versions along the way.

Here are the steps that I took to import my ncc package history into git:

$ mkdir /git/repo
$ cd /git/repo
$ git-debimport ../../debian/ncc/ncc

It will then pick up all the files beginning with ncc in the ../../debian/ncc directory.

To see the revision history:

$ cd ncc
$ gitk

The .orig.tar.gz files will be extracted to a branch called upstream and tagged (v2.5), it will then be merged to master and the .diff.gz files applied sequentially and tagged at each step (v2.5-1). A list of tags like the following will be created:

v2.5
v2.5-1
v2.5-2
v2.6
v2.6-1
v2.6-2

To create the source package for a particular revision:

gitpkg v2.6-1 v2.6

Where the first argument is the tag with the Debian changes, and the second argument is the tag for upstream code.

$ ls -F ../deb-packages/ncc/
ncc-2.6/ ncc_2.6-1.diff.gz ncc_2.6-1.dsc ncc_2.6.orig.tar.gz
$ cd ../deb-packages/ncc/ncc-2.6
$ debuild

These steps didn’t work for me the first time as git silently dropped an empty directory that caused the build to fail. The workaround was to create a .gitignore file in the empty directory. This is probably something that gitpkg could be configured to handle.

To upgrade to a new upstream version:

$ git checkout upstream
$ rm -rf *
$ tar zxvf /path/to/new/upstream.tar.gz
$ git add .
$ git commit -m
$ git tag v2.7

# Merge the Debian changes
$ git checkout master
$ git branch debian
$ git checkout debian
$ git merge upstream

# Fix conflicts / make Debian specific changes / test

$ git add .
$ git commit -a
$ git checkout master
$ git merge debian
$ git tag v2.7-1

# Generate Debian package artifacts
$ gitpkg v2.7-1 v2.7

# Build Debian package
$ cd ../deb-packages/ncc/ncc-2.7
$ debuild

A couple of caveats – gitpkg generates the orig.tar.gz by tarring up the upstream branch. As far as I know, gitpkg does not yet have pristine-tar support yet and that’s a must-have if you don’t want to re-package the upstream sources. I also noticed that git-debimport had trouble with absolute paths, for which I submitted a patch – so I don’t have a whole lot of confidence in the tool yet, but it’s getting there.

On OpenSolaris

In a recent article, Ted T’so makes some interesting points on Sun’s motives behind OpenSolaris, and how it fares today in the FOSS ecosystem as a result.

“Fundamentally, Open Solaris has been released under a Open Source license, but it is not an Open Source development community.”

It’s quite sad that this is the case simply considering the enormous potential that OpenSolaris had back in 2005, and the opportunities for cross pollination with Linux had the licenses been compatible. Given some of killer features of the operating system, it’s quite a shame that it has not been able to rally the developer community that it deserves.

At this point, I think the only hope for OpenSolaris is GPLv3 and a truly open development process. Then for once, Linus’ kernel will have a strong contender and a raised bar on licensing grounds.

Nexenta (a project unaffiliated with Sun), and essentially a Debian distribution with an OpenSolaris kernel, has been a strong attempt at attracting developers. Debian is by far is the most developer friendly GNU/Linux distribution out there, with a mature and proven development model, and to build an OpenSolaris distribution with user land tools of Debian makes the most sense.

I’ve been a Solaris user since version 6, which I attempted to run (quite foolishly) on a 333MHz Pentium. The user experience was anything but smooth, but still ended up gaining a lot of respect for the platform. Only time can say whether the tide changes for OpenSolaris or whether it ends up relegating to the Minix boat.

Updated: 03 May – Corrections on Nexenta

Marmot ’08

So, there’s a thread on the Debian mailing lists on a mascot for the project. Someone jokingly suggested a Marmot.

Marmots typically live in burrows, and hibernate there through the winter. Most marmots are highly social, and use loud whistles to communicate with one another, especially when alarmed.

Now if that’s not a reason why the Marmot shouldn’t be the Debian mascot…

And just look at this froody Marmot. He’s the complete embodiment of all that is free and open.

And here’s yet another blissfully content Marmot, chilling out. These dudes are cool. This post deserves a whole new category. And it’s called…

wait.. for… it…

Marmot.

My vote is for the Marmot.

Virtual Private Networking

I’m sure most of you would have had to mess around with VPNs at some point of your lives. Sometimes, VPNs can turn nasty and bind you to an OS that hinders your free spirit. But thanks to IPSec, that doesn’t always have to be the case. For instance, assuming your place of work has set up Cisco based VPN concentrators, connecting to it using Linux is quite simple with the help of vpnc. Cisco, being somewhat of an opensource friendly hardware manufacturer, has released their vpn client software for Linux as a free download so long as you use it with their products. vpnc on the other hand, is an opensource alternative, very easy to configure, and a delight to work with.

Once again, its just a matter of

apt-get install vpnc resolvconf

Then you need to add the following lines to /etc/vpn/vpnc.conf:

IPSec gateway XX.XX.XX.XX
IPSec ID MegaCorpNetwork
IPSec secret ThisIsAPlaintextPassword
Xauth username myuserid

The gateway is the IP Address of the VPN concentrator. If your trusty MIS department has already setup the Cisco VPN client on Windows (such as in a dual booting scenario in my case) you can extract this information from the profile file that gets created. It should reside somewhere in the neighbourhood of “Program Files”, under the Cisco VPN Client installation folder, and within the Profiles subdirectory. There’s one small caveat, the group password, that corresponds to the “IPSec secret” field in vpnc.conf, is usually “encrypted” on Windows. But have no fear, for it can be undone. This is a well known flaw, and the group password encryption is practically redundant. I recommend that you download the C program and run it locally instead of using the form on the web page to decrypt it.

Once you have the plaintext, plug it into your vpn.conf.

Also, vpnc requires TUN/TAP device driver support in the kernel, but the good news is that it comes standard with most distributions. At least the ones I’ve tried out so far. If not:

modprobe tun

Failing which, you’d need to do a bit o’ kernel compilin’.

That out of the way, you’ll also need resolvconf to setup your /etc/resolv.conf so that you’ll be able resolve hostnames properly on the various networks you’re connected to. Later on, if you find out that your hostnames aren’t resolving, /etc/resolvconf/interface-order is probably a good place to start troubleshooting.

Depending on the version of vpnc you’re are using, you can connect to the vpn by either using vpnc, or vpnc-connect. Although I noticed that the latter has been deprecated in most recent versions, but the following should work no matter which version you use:

vpnc /etc/vpnc/vpnc.conf

If you have a static xauth password (which btw, is a very very bad idea) you could either hardcode it in vpnc.conf (again, bad idea) or have it prompted by not specifying in the config file as shown in the sample above. For added security, xauth authentication shouldn’t be relied upon solely, and should be complemented with some form of two-factor authentication for maximum security.

If all goes according to plan, you’ll be prompted with a legal disclaimer from the network you’re connecting to and all the routes will be automatically set up.

To log off from the vpn, simply issue vpnc-disconnect, and you’ll be back to where you started from.

The Onion Router

I recently tried out TOR for the first time as this has been something in my TODO list for a while. It was just a matter of

apt-get install tor privoxy

Adding the following line in /etc/privoxy/config

forward-socks4a / localhost:9050 .

And starting the tor and privoxy services. Next, setup your applications to use tor and privoxy to proxy your connections and route it through the tor networks, effectively hiding your trails and stripping HTTP header information that could be used to track you. The latter is handled by privoxy.

Tor provides a socks proxy that listens on port 9050 and privoxy is a filtering web proxy listening on port 8118 that can be used by your web browser. Privoxy routes the HTTP traffic through tor and handles DNS requests securely. Using plain old socks through tor for HTTP browsing is not very effective because DNS requests can leak, and blow your cover. Enter privoxy.

If you’re using lynx, you can configure it to use privoxy by setting the http_proxy environment variable to “http://localhost:8118″. Wget and curl can also be configured this way. If you’re not sure, set both http_proxy and HTTP_PROXY variables and your http client should hopefully use either.

On firefox, the proxy settings are availble in preferences, connection settings. Set all proxies to localhost on port 8118 and select SOCKS v4. There’s also a neat firefox plugin called SwitchProxy that can be used to easily torify your browsing experience.

Once you’re connected to tor networks, visit this link to verify whether you really ARE anonymous. It will recognize whether your traffic is coming from a recognized tor exit node.

The only gotcha at the moment is that only tools capable of using SOCKS and HTTP is capable of anonymizing your traffic through tor, the rest is routed normally through more insecure channels. This problem can be easily subverted using tools such as socat, which having discovered it recently, I think is a very powerful tool which can be used for a wide range of applications. Think netcat for sockets. More on that in a later rant.