I’ve created a GIT repository for cduce and few experiments of mine at http://git.cduce.org . I’m using gitweb, that is a neat piece of sw. Easy to install and to manage. I had a minor problem related to the fact I’m using http as transport protocol to clone our git repos. In particular, the error was:

$git clone http://git.cduce.org/r/hashconsing.git
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?

The easy fix was to do what I was told to do and to run git-update-server-info in the remote repo.

From the manpage:

A dumb server that does not do on-the-fly pack generations must have some auxiliary information files in $GIT_DIR/info and $GIT_OBJECT_DIRECTORY/info directories to help clients discover what references and packs the server has. This command generates such auxiliary files.

Here I come. Following from the DSA announcement I’ve regenerated the ssh/openssl keys for cduce.org.

apt-get update
apt-get upgrade
rm /etc/ssh/*
dpkg-reconfigure -plow openssh-server

One the user side:

first ssh to the remote machine and remove the for ~/.ssh/authorized_keys . This will lock you out if you don’t remember the passowrd for that machine !

Then, you should remove your ssh keys (from you local machine), and regenerate them with:

ssh-keygen
ssh-copy-id <host>

At this point you should be able to login back on your remote host using the new ssh key.

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 !!!

A quick one about mod_rewrite. I added ssl to cduce.org for our user pages. However I’ve no use of ssl to serve our static pages. This rule will redirect all https requests (^443$) that are not related to userdirs (!^/~) to http:// .

        RewriteEngine   on
        RewriteCond %{SERVER_PORT} ^443$
        RewriteCond %{REQUEST_URI} !^/~
        RewriteRule ^(.*)$ http://www.cduce.org$1 [L,R]

There are many many howto on the net regarding this topic. Here I’ll not give another howto, but just a list of mistakes I’ve done today. I hope this will same some time to others.

openssl certs

With debian we generally use make-ssl-cert to generate self signed certs. This tools works fine also to generate ssl certs for ldap. The only important thing to remember is to specify your FQN as host name while creating the cert. Failing to do that will make the openldap server fail to start. Remember also to change the permissions of the server certificate to allow the openldap user to read it.

self signed certs VS signed certs

If I understand correctly, openldap works just fine with self signed certs, but this is not optimal. To generate signed certs, you first need to create a CA cert and then use this to sign you server cert. In debian you can find scripts to do that in /usr/lib/ssl/misc/

TLS_REQCERT allow

If you use a self signed cert you need to specify TLS_REQCERT allow in /etc/ldap/ldap.conf and TLSVerifyClient allow in you /etc/ldap/slapd.conf. The first is necessary to get the ldap clients working. I’m not sure about the second one in the server configuration file.

pam and nss

cat /etc/libnss-ldap.conf 
base dc=cduce,dc=org
uri ldaps://osmium.pps.jussieu.fr
ldap_version 3
ssl on

cat /etc/pam_ldap.conf 
base dc=cduce,dc=org
uri ldaps://osmium.pps.jussieu.fr
ssl on
ldap_version 3
pam_password crypt
nss_base_passwd ou=people,dc=cduce,dc=org?one
nss_base_shadow ou=people,dc=cduce,dc=org?one
nss_base_group  ou=group,dc=cduce,dc=org?one
nss_base_netgroup ou=netgroup,dc=cduce,dc=org?one

The important bits here are the ssl on to force the client to use ssl. Of course, remember to specify ldaps in the uri.

Enable ldaps

On debian you need to modify /etc/default/slapd and add this line:

SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps://cduce.org:636/"

I decided to keep ldap without ssl on localhost, but only ldaps on the external interface.

More about Kerberos + SASL + OpenLdap soon…