Signe extèrieur de geekitude

Ça va faire 5 mois que je n'ai plus de smartphone.
(Non en fait ça fait 5 mois que je n'ai plus de téléphone, de carte d'identité, de permis de conduire et de carte visa, mais c'est une autre histoire)

Je n'ai plus qu'un vieux portable (pas de desktops), 13" (pas de doubles écrans) plus d'imprimante, de scanner...

Et vous savez quoi ? Je m'en passe bien, j'ai découvert que j'ai"besoin" de peu.

Le problème c'est qu'on ne change pas sa nature :  "Geek un jour, geek toujours"

Tout ça pour dire que je ne suis pas aidé; j'avais fort raisonnablement décidé d'acheter un téléphone qui ne fait que ça (pas d'écran tactile, pas de haute résolution, pas d'appareil photo, pas de gps...) quand la voix de la tentation me susurre à l'oreille (par la bouche de ma femme) : Arrêtes tes bêtises il te faut un vrai téléphone, tu veux pas plutôt un Galaxy S II ?

Que voulez vous que je réponde ?

Risquer mon mariage pour défendre le bon sens.
En plus un Galaxy S II, un joyaux de technologie sous Android (presque libre quoi) ça va être difficile d'argumenter.

Et puis le Geek est faible...

Bref je suis possesseur d'un Galaxy S II.
Merci Didine.

Using maildirs on Ubuntu [en/fr]

Among all the operations that I do not so frequently, there's the one consisting in setting up system-wide maildirs. As I always forget how to redefine this pesky MAIL variable set by default to /var/mail/username, I've decided to blog about it to record the solution:

If you're directed to  /etc/login.defs  forget about it, just read the comments in it that points you to /etc/pam.d/* files.

The change to do are in

/etc/pam.d/su:

#session    optional   pam_mail.so  nopen

session    optional   pam_mail.so dir=~/Maildir nopen
/etc/pam.d/sshd:
#session    optional     pam_mail.so standard noenv # [1]
session    optional     pam_mail.so dir=~/Maildir standard

/etc/pam.d/login:
#session    optional   pam_mail.so standard
session    optional     pam_mail.so dir=~/Maildir standard

I used to call my maildirs folder simply 'Mail' but as most software expect them to be called 'Maildir' by default. I now follow the 'Maildir' name convention to avoid redefining the set name in multiple config files.

In my case, some additional steps:

in /etc/postfix/main.cf:

home_mailbox = Maildir/

If you use procmail for local delivery, don't forget to add to
/etc/procmailrc:
DEFAULT=$HOME/Maildir/

And if you're a mutt user,
/etc/Muttrc:
set mbox_type=Maildir
set mbox="~/Maildir"
set spoolfile="~/Maildir"
set folder="~/Maildir"

[French translation]

Parmi toutes les opérations que je ne fait pas si fréquemment, il y a celle consistant à définir les maildirs pour l'ensemble du système. Comme j'oublie toujours comment redéfinir cette agaçante variable MAIL,  définie par défaut à /var/mail/nomutilisateur, j'ai décidé de blogguer sur le sujet pour me souvenir de la solution :

Si vous vous retrouvez dans /etc/login.defs,  oubliez ça, lisez juste les commentaires qui vous redirigent vers les fichiers /etc/pam.d/* .

Les changements à opérer sont dans

/etc/pam.d/su :

#session    optional   pam_mail.so  nopen

session    optional   pam_mail.so dir=~/Maildir nopen

/etc/pam.d/sshd :
#session    optional     pam_mail.so standard noenv # [1]
session    optional     pam_mail.so dir=~/Maildir standard

/etc/pam.d/login :
#session    optional   pam_mail.so standard
session    optional     pam_mail.so dir=~/Maildir standard 

J'avais l'habitude d'appeler mes maildirs simplement 'Mail', mais comme la plupart des logiciels s'attendent à ce qu'ils s'appellent 'Maildir' par défaut. Je suis maintenant la convention du nom 'Maildir' pour éviter d'avoir à redéfinir le nom dans plusieurs fichiers de configuration.

Dans mon cas, quelques étapes additionnelles :

dans /etc/postfix/main.cf :

home_mailbox = Maildir/

Si vous utilisez procmail pour la délivrance locale, n'oubliez pas d'ajouter à
/etc/procmailrc : 
DEFAULT=$HOME/Maildir/

Et si vous êtes un utilisateur de mutt,
/etc/Muttrc :
set mbox_type=Maildir
set mbox="~/Maildir"
set spoolfile="~/Maildir"
set folder="~/Maildir"

Gitolite / Mercurial server

Lately I installed 2 similar tools : gitolite and mercurial-server.
The 2 tools achieve the same goal, managing a central repository handling remote virtual users and differ mainly on the dscm they target (as their name imply).


As a matter of taste, I tend to prefer git (and so gitolite) beccause of its wider users base and architecture's simplicity.

But mercurial has roughly the same potential, and depending on your context you might prefer (or 'have to' in my case) to work with it.

But before discussing their benefits, let's detail how to install step-by-step :

For gitolite

#apt-get install gitolite


The following NEW packages will be installed:
  git gitolite libcurl3-gnutls liberror-perl rsync

A gitolite or git user will be created in the process, for the rest of the document I assume this user to be 'gitolite'.
(this is the case on debian and ubuntu)

Some people prefer to create a gitolite admin dedicated user, but I prefer to reuse and existing user :

su -  noc

This user has to create a ssh key (without passphrase) if he doesn't already have one.

ssh-keygen
cp .ssh/id_rsa.pub /tmp/noc.pub

su - gitolite

gl-setup  /tmp/noc.pub

su - noc


git clone gitolite@localhost:gitolite-admin

cd gitolite-admin
vi conf/gitolite.conf

        repo    gitolite-admin
                RW+     =   noc

        repo    testing
                RW+     =   @all


Mercurial-server
Get the deb from :
http://packages.debian.org/sid/all/mercurial-server/download

install dependencies :
apt-get install mercurial

install the deb :
dpkg -i mercurial-server_1.1-1_all.deb

cp /tmp/noc.pub /etc/mercurial-server/keys/root/

sudo -u hg /usr/share/mercurial-server/refresh-auth

creating repo is a mater of cloning to the server
hg clone localrepo ssh://hg@server/reponame

The access rights seems a little bit more cumbersome to me
you can either use the /etc/mercurial/server/keys on the server and the refresh-auth command or
in a similar way to gitolite use the hgadmin repo.
Let's follow this way :

http://www.lshift.net/mercurial-server.html
https://github.com/sitaramc/gitolite#start

Why I use gitolite

Whereas github is great for hosting your public repositories, as soon as you want to use many private remote repositories you should consider other options.

First because it's going to cost you some money and because it's always a good idea to avoid scatter your private stuffs on external server (Yes I know, as a google minion I'm not a good example...)

Among the many options to hosts your remote git repo, I've found gitolite to be the best one to suit my needs, let me explain why :

* I firmly believe in the KISS principle, and the fact that you don't need to use another daemon (it just uses sshd) is very appealing to me. (Other solutions often requiring to setup an apache/Webdav vhosts, git-daemon or whatever)

* Fine-grained access control : gitolite really shines in this aspect
   In addition to the usual  read/write/read&write gitolite provides access  to 'non-fast forward push', branches creation/deletion, write deny and extends the targets to not only repositories but also branches/tags

* It's simple ! It's simple to install, simple to configure. Don't even need to read the doc to understand :

@admins    = arnaud jeff

@team1     = jeff bob

@team2     =  arnaud jeff

 

        repo    gitolite-admin

                RW+     =  @admins

        repo    testing

                RW+     =   @team1 arnaud

        repo    kronar

                RW+     =   @team1 @team2

* Even if it relies on ssh as a basis for its authentication, it uses virtual users and doesn't require the users to have an account on the server

* It's configuration is versioned, gitolite-admin is a default repo managed by gitolite enabling remote administration through git. The whole gitolite configuration is self-contained.

* Other features you might like (but that I don't use)

     Informational commands (info, expand)

     disable write to git during backup (sysadmins will like this one...)

     gitweb support

     ...