During the weekend I upgraded my laptop to sqeeze. I usually track unstable pretty closely, but in between transition I gave myself a bit of slack in order to avoid messing up with the gnome transition. The result is ok, NetworkManager Just Work !!!, the new kernel seems pretty snappy. I finally get the power status for my network card.

My laptop is a old dell latidute x200. I always had problem with the graphic card and Xorg. With this upgrade I’ve always motivated myself to find a solution. Not surprisingly it was quite easy. I’ve added these option to my xorg.conf :

Section "Device"
        Identifier "Configured Video Device"
        Driver "intel"
        Option "Tiling" "false"
        Option "FramebufferCompression" "false"
        Option  "XAANoOffscreenPixmaps" "true"
        Option  "AccelMethod" "EXA"
        Option  "ExaNoComposite" "true"
EndSection

I’m not entirely sure if I need them all. I’ve noticed that already my screen corruptions go away with “tiling” and “framebuffercompression” set to false. But the life changing options are the accell method (EXA seems much more stable) and the “ExaNoComposite”.

What I’ve left to figure out is to fix the hibernate function, that is still not very reliable as it works 8 out of 10 times.

After 1.3Gb of updates, I’m happy I’m again surfing the unstable wave.

I’ve packaged latexdiff for debian, that is a small utility to generate latex files with revision markers from multiple versions of the same file. While packaging this utility I’ve learned about two very nice tools to help the debian maintainers: git-buildpackage and topgit.

Regarding git-buildpackage there is an extensive manual that should get you started : http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html

Topgit documentation is a bit sparse. tg help <command> should guide you for syntax. The README file in the tg distribution is full of examples.

Zack’s work on debcheckout to make it topgit aware is also very interesting ( http://upsilon.cc/~zack/blog/posts/2008/10/debcheckout_hacking/ )

I’ve put everything on alioth.debian.org in my personal git space following these instructions : http://wiki.debian.org/Alioth/Git

the git repo is here : http://git.debian.org/?p=users/munga-guest/latexdiff.git;a=summary

to build the package :

debcheckout git://git.debian.org/git/users/munga-guest/latexdiff.git
debian/rules tg-export
git-buildpackage --git-pristine-tar --git-ignore-new

the second command debian/rules tg-export exports the patch from the git branch that is managed by topgit and transform it to a quilt patch that will be applied to the master branch to generate the package.

You can also get the package in the usual way with dget : dget -u http://alioth.debian.org/~munga-guest/latexdiff_0.5-1.dsc

This package is nice and easy, with only on patch, so it should be nice to see what topgit, git-buildpackage is all about.

Rails/redmine installation on debian etch as a user requires a bit of googling. This is what I have done.

First, as root, install these packages:

apt-get install ruby rake
apt-get install rubygems -t etch-backports
aptitude install libopenssl-ruby1.8 libfcgi-ruby1.8

you need the backports version of gems as the version in etch is not compatible anymore with redmine.

Then you should follow these instructions: http://www.redmine.org/wiki/redmine/HowTo_Install_Redmine_in_a_home_directory_on_Debian

Once you setup the db, installed your gems (remember to install rails 2.0.2 : gem install -i $GEM_PATH -v=2.0.2 rails -y) you need to pass your GEM_PATH to your cgi. I use fcgi and I added ENV["GEM_HOME"] = "/path/to/gems" to the file dispatch.fcgi .

that’s all. Happy redmining

I’ve been looking for a solution to this problem for a long time. Basically apache2 is not able to do name-based virtual hosting if you also want to use ssl. The reason for this problem is very simple. In order to know then hostname, apache2 I need to establish a secure channel, but to establish a secure channel, if I have more then one virtual host, then I need to know the hostname, that is, to provide the client the correct certificate. There is also a better explanation on the apache website [1].

There correct solution to this problem is to use the TLS extension called SNI [2]. This is provided by two different apache modules: mod_gnutls and mod_ssl.

There are two nice tutorials one for mod_ssl [3] and the other one for mod_gnutls [4] . If you are running lenny (debian testing at the time of writing), you can just install mod_gnutls. If you are running etch, then your best bet is to recompile apache with the mod_ssl patch to support SNI. The first tutorial [3] is about the latter option. The patch can be downloaded from this website [5] mentioned also in [3].

The tutorial explains how to recompile the package. The only thing I’ve done is to use pbuilder to automate the process. In particular, if you’re building the apache2 package in pbuilder, you need to recompile openssl first, then to install in your pbuilder image and then build apache. This is the command I’ve used to add the package.

sudo /usr/sbin/pbuilder --login --save-after-login --bindmounts /var/cache/pbuilder/

dpkg -i /var/cache/pbuilder/results/libssl*.deb /var/cache/pbuilder/results/openssl*.deb

so far so good. I’ve save myself an big headache.

:)

[1] http://httpd.apache.org/docs/2.1/ssl/ssl_faq.html#vhosts2

[2]http://en.wikipedia.org/wiki/Server_Name_Indication

[3]http://www.how2forge.org/enable-multiple-https-sites-on-one-ip-using-tls-extensions-on-debian-etch

[4]http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/

[5]https://dave.sni.velox.ch/

If I don’t trust a stranger to wonder inside my house, why should I allow a closed source program to access my home directory ? Apart from the paranoia and conspiracy implications I decided to spend some time learning how to chroot skype (and iceweasel for that matter, since I don’t really trust javascript, flash and the mozilla plugin model) in a chroot.

I started from this article : http://www.debian-administration.org/articles/566

This recipe didn’t work out of the box. This is mine:

Now step by step: First we install the software. I’m working on a debian unstable…

apt-get install schroot debootstrap

Then we create the chroot with debootstrap, we install skype and let apt-get do the rest. Installing skype will cause a lot of broken dependencies. apt-get -f install will fix them all. Quick and dirty. Note: you have to copy the package inside the chroot!

sudo debootstrap --variant=minbase --arch i386 sid /home/chroot/sid http://ftp.fr.debian.org/debian

sudo schroot -d / -c sid -p -- dpkg -i /skype-debian_2.0.0.68-1_i386.deb

sudo schroot -d / -c sid -p -- apt-get -f install

At this point the chroot is ready. To run an application, we still need to convince the xserver to accept xsessions from the chroot to be displayed. Since but default my xserver doesn’t accept tcp connections (—nolisten tcp), we need to bind-mount the tmp directory inside the chroot.

See also : http://www.gelato.unsw.edu.au/IA64wiki/XinChroot

Notice that this is not the safest solutions. We could re-start the xserver to listen to tcp connections and avoid this step. I’ve chosen to go this way at the moment.

mount --bind /tmp /home/chroot/sid/tmp

Then we need to authorize the client using xauth and run you command using this little wrapper

xauth extract - $DISPLAY | xauth -f /home/chroot/sid$HOME/chhome/.Xauthority merge -

schroot -- "$@"

rm -f /home/chroot/sid$HOME/chhome/.Xauthority

Depending from your settings you might want to fix the display variable. Running schroot with the -p option let you pass your env variables to the application in the chroot. I suggest you don’t do that but add a .bashrc in your chroot home to set only selected variables.

We are ready to skype away in our chroot:

./wrapper skype

Installing iceweasel is just a matter of apt-get in the chroot.

Maybe now they won’t be able to tap in your computer so easily, but they will still be able to record you conversations and messages !!!