samedi 20 août 2011

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"

dimanche 31 juillet 2011

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

samedi 30 juillet 2011

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

jeudi 7 juillet 2011

Module::Build rocks!!!

Yes I know, this module is already four years old and I'm probably the last Perl coder still using ExtUtils::MakeMaker for his modules.

Some experienced friends of mine already told me about it.
(Hello Maddingue, better later than never...)
I knew that I had to use it, but until today I didn't...

For those of you who haven't see the light, here are some reasons why you should switch to it:

_ It's easy (and you should be lazy) => make2build from Module::Build::Convert made the conversion a breeze without requiring to read any doc (ok I've read the doc anyway, but it's beccause I'm curious...)

_ It's powerful (and you should be impatient) => Build testcover and you have a complete test coverage provided out of the box!
(this feature alone is a killer to me, I know you can achieve the same with EU::MM but it is provided by default with Module::Build)

_ It's the state of the art (and you should be hubristic): using tool of the past without any good reason isn't a pragmatic behavior.
Module::Build is more portable, offer more options, and offer an automatic Makefile.PL generation for all the tools expecting one
(to get for free the best of both world)

There are tons of other reasons that you'll find if you read the doc.
Alleviating  SCHWERN's pain (the EU::MM's maintainer) being the most original one to me :-)

Do yourself a favor, just use Module::Build with your modules.

mardi 14 juin 2011

Un geste pourtant simple

Une fois n'est pas coutume je ne parlerai pas informatique ou productivité.

C'est aujourd'hui la journée mondiale du don de sang.
J'ai longtemps hésité à en parler;  que dire que vous n'ayez déjà lu/entendu maintes fois :

* Les hôpitaux manquent de sang.
* Donner son sang *sauve de vies*
* Quelque soit votre emploi du temps il y a un moyen de donner près de chez soi.
(Ils travaillent même le Samedi dans la plupart des villes)
* C'est sur à 100%

Plutôt que d'essayer de vous convaincre d'une manière abstraite, allez jeter un œil sur le Blog de mon ami Loïc et sa femme Célia ("Deux expats à Seattle") :
Loïc est un ami, expatrié à Seattle, qui a découvert là bas qu'il était atteint d'une leucémie, il décrit dans son blog avec beaucoup d'humour et d'honnêteté son combat au jour le jour.

Il ne doit sa survie qu'aux donneurs de sang, et sa guérison ne se fera qu'à travers un don de moelle osseuse.

Tout ce que nous avons à faire, pour l'aider lui et des milliers d'autres, c'est de donner notre sang régulièrement et demander à être inscrit sur la liste des donneurs de moelle osseuse.

Un geste tellement simple...

vendredi 10 juin 2011

Un peu d'ordre

Après la discipline je parle d'ordre, ceux qui ne me connaissent pas doivent se poser des questions...
(et ceux qui me connaissent encore plus :-) )

Alors je vais rassurer tout le monde : Je vais commencer petit, sur mon ordinateur, dans mon répertoire .vim

Avant ma crise mon répertoire .vim ressemblait à ça : 
drwxr-xr-x 4 arnaud arnaud 4096 2011-05-19 23:30 after
drwxr-xr-x 4 arnaud arnaud 4096 2011-05-19 23:30 autoload
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:30 bin
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 colors
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:30 compiler
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 doc
drwxr-xr-x 3 arnaud arnaud 4096 2011-05-19 23:30 ftplugin
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 indent
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 keymap
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 lang
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:30 nerdtree_plugin
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 plugin
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 print
-rw-r--r-- 1 arnaud arnaud   85 2011-05-19 23:30 README
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 record
drwxr-xr-x 2 arnaud arnaud 4096 2011-06-09 22:22 snippets
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 spell
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:30 syntax
-rw-r--r-- 1 arnaud arnaud  193 2011-05-19 23:30 test.vim
drwxr-xr-x 2 arnaud arnaud 4096 2011-05-19 23:43 tutor
-rwxr-xr-x 1 arnaud arnaud  916 2011-05-19 23:30 vim-config
-rwxr-xr-x 1 arnaud arnaud 4030 2011-05-19 23:49 vim-keys

Maintenant j'ai ça :
drwxr-xr-x 2 arnaud arnaud 4096 2011-06-09 22:39 autoload
drwxr-xr-x 8 arnaud arnaud 4096 2011-06-09 22:39 bundle
-rw-r--r-- 1 arnaud arnaud   31 2011-06-09 22:34 TODO
-rwxr-xr-x 1 arnaud arnaud  916 2011-06-09 22:39 vim-config
-rwxr-xr-x 1 arnaud arnaud 4030 2011-06-09 22:39 vim-keys

Le truc ?
C'est un plugin vim appelé pathogen.

Pathogen permet d'organiser tous les plugins dans un répertoire bundle, qui contient les plugins chacun dans leur sous répertoire plutôt que de mélanger leur contenu dans des répertoires communs (ftplugin, plugin, autoload...)

L'installation est simple :
git clone https://github.com/tpope/vim-pathogen.git
mv vim-pathogen/autoload .vim
rm -rf vim-pathogen/
cd .vim
mkdir bundle

Je recopie mes fichiers de configs habituels qui sont versionnés :
cp ../git/dotfiles/vim/vim-* .

Il suffit alors d'ajouter au ~/.vimrc les lignes suivantes au tout début de votre fichier : 
filetype off
call pathogen#runtime_append_all_bundles()

Il faut maintenant (re-)installer (dans mon cas) les plugins que le
souhaite utiliser :
cd bundle
hg clone https://bitbucket.org/ns9tks/vim-fuzzyfinder
git clone https://github.com/tpope/vim-fugitive.git
git clone https://github.com/tpope/vim-surround.git
git clone https://github.com/scrooloose/nerdtree.git
git clone https://github.com/msanders/snipmate.vim.git
hg clone https://bitbucket.org/ns9tks/vim-l9

Je récupère mes snippets perl modifiés de mon répertoire versionné :
cp ../../git/dotfiles/vim/snippets/perl.snippets snipmate.vim/snippets/

Je rajoute un fichier pour me souvenir de la dépendance de L9 qui est requis par snipmate et qui me servira pour les dépendances à venir :
vi DEPENDENCIES

Mon répertoire bundle ressemble finalement à ça :
-rw-r--r--  1 arnaud arnaud   27 2011-06-09 22:39 DEPENDENCIES
drwxr-xr-x  6 arnaud arnaud 4096 2011-06-09 22:39 nerdtree
drwxr-xr-x 10 arnaud arnaud 4096 2011-06-09 22:39 snipmate.vim
-rw-r--r--  1 arnaud arnaud   29 2011-06-09 22:39 test.pl
drwxr-xr-x  5 arnaud arnaud 4096 2011-06-09 22:39 vim-fugitive
drwxr-xr-x  6 arnaud arnaud 4096 2011-06-09 22:39 vim-fuzzyfinder
drwxr-xr-x  6 arnaud arnaud 4096 2011-06-09 22:39 vim-l9
drwxr-xr-x  5 arnaud arnaud 4096 2011-06-09 22:39 vim-surround

Et voilà c'est fait !

Mon vim est à nouveau utilisable : j'ai mis de l'ordre dans mes plugins sans avoir à réécrire mes fichiers de configuration.

ADDITIF : Si on veut versionner cette configuration il faut agir légèrement différemment en ajoutant les plugins versionné sous git non pas par un clone mais par un git add submodule à la racine du dépôt git, par exemple :
git add submodule https://github.com/tpope/vim-fugitive.git vim/bundle/vim-fugitive

Une fois tous les submodules ajoutés il ne reste plus qu'a exécuter :
git submodule update --init 

La mise à jour d'un submodule se fait simplement dans le répertoire du submodule par un :
git pull


mercredi 8 juin 2011

Journée mondiale IPv6

"Le 8 juin 2011 l'Internet Society (ISOC) organise une journée mondiale IPv6 pendant laquelle les fournisseurs et les sites sont encouragés à tester la technologie à grande échelle. Google, Facebook, Yahoo!, Akamai et Limelight Networks ont annoncé leur participation à cet événement." -- Wikipedia

C'est aujourd'hui !!!

Pour célébrer l’événement, j'ai décidé de configurer un tunnel IPv6 pour participer moi aussi au "test à grande échelle".

Vous n'aurez probablement pas besoin des opérations suivantes, mais si comme moi vous avez désactivé IPv6 il va falloir réactiver en modifiant les lignes suivantes (pour désactiver appliquez l'opération inverse) :

/etc/hosts
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

/etc/modprobe.d/blacklist.conf
# Uncomment to disable IPv6
#blacklist ipv6

/etc/rc.local
#Uncomment to disable ipv6
#net.ipv6.conf.all.disable_ipv6 = 1
#net.ipv6.conf.default.disable_ipv6 = 1
##net.ipv6.conf.lo.disable_ipv6 = 1

Pour ceux qui utilisent Firefox comme moi, vérifier dans about:config que network.dns.disableIPv6 est à 'false'

Ceci étant fait, un reboot plus tard, l'exécution de la commande ifconfig
fait apparaitre la ligne tant attendue :
inet6 addr: fe80::221:5dff:fe46:1070/64 Scope:Link

Ceci étant fait mon Ubuntu est maintenant revenu à son état naturel et est en mesure de gérer l'IPv6.

Mon fournisseur d'accès ne m'offrant pas d'accès IPv6 natif, il me faut encore passer par un broker pour créer un tunnel.
Un ami (merci aanriot) m'a parlé d'Hurricane Electric (http://tunnelbroker.net/) je me suis donc inscrit, créé un tunnel
en clickant sur le lien idoine et généré les instructions nécessaires à la connexion au tunnel via l'interface du site :
ifconfig sit0 up
ifconfig sit0 inet6 tunnel ::216.66.84.42
ifconfig sit1 up
ifconfig sit1 inet6 add 2001:470:1f12:8c3::2/64
route -A inet6 add ::/0 dev sit1

Voilà ! Il ne vous reste plus qu'a vérifier que ça marche sur un site dédié :
http://test-ipv6.com/
ou

http://ipv6test.google.com/

Ça marche ? Maintenant vous pouvez dire fièrement :
IPv6 day ? J'y étais...
:-)

mardi 7 juin 2011

CPAN modules you love to hate (or the contrary)

If one thing starts to bother me in the Perl universe, it's all the dependencies which force you to pull half of the CPAN each time you try to install a major module.

Don't get me wrong: I love Perl, I love CPAN, I love modules and I definitively love code reuse BUT may be we start doing it the wrong way.

Let's think why we need code reuse:
1) Because we're lazy ( as every good Perl programmer :-) ) and don't want to
rewrite an existing wheel (if a good one already exist)
2) Because it reduces the code size by factorizing common parts

The factorizing aspect is especially important to me:
_ Common parts (modules) are more tested as more users eventually use them
_ Code is easier to maintain (smaller, less heterogeneous...)
_ It forces us to think about the API, which eases enhancements
_ ...

Now if I look at the dependency mess on CPAN, I realize that what's is bothering me is not the numerous dependencies,  but rather that most of them void/lesser the benefits of code reuse.

Why must I use 3 different XML SAX parsers?
Why must I use 3 different Serializer modules?
Must I really use 2 different dispatch modules?
Can't I just use one error/handling module?

I wholeheartedly adhere to the TIMTOWTDI motto, but the more I use CPAN modules the more I get functional duplication code: My applications get globally bigger, more complex, heterogeneous, less tested than it could be...
What a paradox!

I'm calling to your wisdom : am I the only one to feel this dependency bloat?
Do you see any path to a more efficient Modules use?

samedi 28 mai 2011

Da Cloud made eZ...

Petit coup de coeur du moment : Dotcloud
Ce site offre gratuitement (le temps de la beta) un accès à une infrastructure scalable, sa force c'est principalement son extrême simplicité  :
(j'ai déjà dit que c'était gratuit en beta ?)


D'abord s'inscrire sur le site en laissant son adresse email, pour recevoir un code d'accès...
Une fois ce code reçu, on finit l'inscription et récupère la clef d'API qui se trouve dans 'settings', cette clef sera demandée à la première utilisation de dotcloud.

On installe le client python (nul n'est parfait ;-) )
sudo easy_install dotcloud

On crée une application (je l'appelle easylearn)
dotcloud create easylearn

On affiche la liste des types de services disponible
dotcloud deploy -h

Pour déloyer un service Perl (ici appellé www)
dotcloud deploy -t perl easylearn.www

Et un service base de données (nommé dans ce cas db)
dotcloud deploy -t mysql easylearn.db

Notez que j'aurais pu nommer les services frontoffice et backoffice, les noms sont complètements libres.

Pour lister les application et services
dotcloud list

Pour afficher des informations sur un service
dotcloud info easylearn.www

L'infrastructure étant prêt du coté "cloud", occupons nous du contenu :

Sur ma machine je crèe un squelette d'application 
catalyst.pl EasyLearn
ou si vous n'utilisez pas Catalyst
mkdir EasyLearn

Puis on se positionne dans le répertoire
cd EasyLearn

Tant qu'on y est, on transforme ce répertoire en repo git
git init
git add .
git commit -a -m 'Initial commit'

Le service Dotcloud s'appuyant sur PSGI (le WSGI à la sauce Perl), il faut configurer l'application Catalyst pour l'utiliser.

Je me suis basé sur l'excellent blog de garu
(http://onionstand.blogspot.com/2011/04/catalyst-in-cloud.html) qui donne la marche à suivre :

D'abord on crée un lien entre le répertoire static de Catalyst et le répertoire static attendu par l'infrastructure dotcloud :
ln -s root/static static

Puis on installe un moteur PSGI pour Catalyst:
sudo cpan Catalyst::Engine::PSGI
script/easylearn_create.pl PSGI


Enfin on crée un lien entre le fichier crée et le fichier app.psgi attendu par dotcloud
ln -s script/easylearn.psgi app.psgi

Puis on ajoute "use lib 'lib';" au fichier app.psgi,  juste avant "use EasyLearn;" pour que l'application soit trouvée.

Pour faire propre on en profite pour rajouter, la dépendance à Makefile.PL.
requires 'Catalyst::Engine::PSGI';
On devrait avoit un site fonctionnel il est temps de l'envoyer vers le Cloud.
dotcloud push easylearn.www .


Une chose sympa sympa c'est que si le répertoire contient un répertoire .git ou .hg, dotcloud le détectera et fera un git/hg push.
Cela veut aussi dire que si votre répertoire est versionné par git ou mercurial, seuls les fichiers commités seront pushés vers le cloud.

Et au cas où vous auriez une erreur :
dotcloud logs easylearn.www

Dans mon cas la lecture des logs m'a permis de me rendre compte que j'avais oublié certaines dépendances dans mon Makefile.PL :
Catalyst::View::TT
Catalyst::Model::DBIC::Schema

Une modif, un commit et un dotcloud push plus tard, je pouvais accéder à mon site via :
http://www.easylearn.dotcloud.com/

Simple non ?

samedi 21 mai 2011

Un peu de discipline...

"La discipline peut remplacer bien des qualités, aucune qualité ne peut remplacer la discipline..."

Le constat s'impose, "entraîné" par différents projets (dont un déménagement en Septembre en Thaïlande) j'ai tendance à partir un peu dans tous les sens...

Du coup je néglige certaines autres qui faisaient parties de ma "routine".

Je me rends compte par exemple que ce blog est "à l'abandon", comme différents aspects de mon réseau d'ordinateurs, et (j'ai honte à l'avouer) mon réseau relationnel....

Le temps est venu d'y remettre bon ordre.
Il est temps de réintroduire un peu de discipline, et je vais commencer par ce blog, en m'astreignant à plus de régularité.

"La discipline est un corset plus sûr que la bonne volonté."