jbbarth's corner

L’info est déjà disponible au fond d’une page du wiki Redmine, ici. Je vais faire exactement pareil, parce que c’est bien. Et comme j’ai envie de faire un article technique, je mets ça ici.

Voilà donc en très bref la config que j’ai utilisée pour linker mon Redmine (prochainement en ligne, dès que les bons DNS seront propagés) à mon dépôt github pour Simplelog (rien mis encore dessus, seulement la release officielle).

$ sudo mkdir -p /var/redmine/git_repositories
$ sudo chown rails:rails /var/redmine/git_repositories
$ cd /var/redmine/git_repositories
$ git clone —bare git://github.com/jbbarth/simplelog.git
$ crontab -e
        #git repo for simplelog
        */15 * * * * git-pull /var/redmine/git_repositories/simplelog/ 2>&1 | grep -vE "^From|FETCH_HEAD|^Already up-to-date"

…chagrin. Mais quand même.

2 jours qu’un collègue essaye d’installer OCSInventory sur un serveur Red Hat Enterprise 5. Ce matin, je me connecte à mon poste de test sous Ubuntu 8.10 :

$ sudo apt-get install ocsinventory-server

10 minutes plus tard (le temps du téléchargement et de me souvenir de mon mot de passe MySQL quoi), OCS était installé. Il me demande un mot de passe à la connexion, que je ne connais pas… Oups. Je fouille 2 secondes dans les confs Apache, je trouve le fichier qui va bien…

$ sudo htpasswd -b /etc/ocsinventory/htpasswd.setup admin admin

Et ça marche. 15 minutes VS 2 jours.

Debian/Ubuntu 1 – 0 RedHat.

Je reprends le titre de cet article, paru sur le blog du rédacteur en chef de Linux Mag’. Même remarque : soit vous comprenez directement le titre, soit cet article n’est même pas fait pour vous. Quoiqu’il en soit, je vais finalement installer ça au boulot lundi ; seul petite angoisse dans les tuyaux, il semble que le support des cartes Broadcom Netextreme II ne soit pas présent d’origine, ce qui va me lourder quelque peu, mais c’est la vie.

Bonne Saint Valentin et longue vie à Lenny !

Sous mon PC principal (Ubuntu/wrath), les résolutions DNS sont assez lentes. J’ai trouvé des solutions ici, immédiatement mises en oeuvre :

# echo "supersede domain-name-servers 80.10.246.2, 80.10.246.129;" >> /etc/dhcp3/dhclient.conf
# /etc/init.d/networking restart #ou un reboot pour être sûr..

J’ai upgradé hier ma Ubuntu Intrepid vers une Jaunty, qui commence à être suffisamment bien supportée ; au passage, j’avais tenté de faire ça il y a deux mois, et le support des pilotes Nvidia était lamentable, je n’avais aucun affichage correct, j’étais donc revenu sous Intrepid.

sudo vi /etc/apt/sources.list #puis :%s/intrepid/jaunty/g, et :wq!
wajig update && wajig dist-upgrade

A peine une demie-heure plus tard tout marchait impec’ ;-)

Seul bémol, Jaunty supporte ext4 et ma partition racine n’était pas passée en ext4 toute seule (on s’en serait doutés).

J’ai inauguré un petit truc bien sympa, le boot depuis une clé USB live (en lenny, comme ça je m’en resservirai au boulot) :

sudo -s
mkdir /tmp/usbkey && cd /tmp/usbkey
apt-get install live-helper
lh_config -d lenny -b usb-hdd -p xfce-desktop —packages wajig screen ruby
lh_build #patienter quelques minutes
umount /dev/sdf1
dd if=binary.img of=/dev/sdf bs=1M

Et reboot sur la clé usb ! Tout marche au poil, sauf que le clavier est en Qwerty :

dpkg-reconfigure console-data

Là commence le passage en ext4 ; mes partitions à migrer étaient /dev/sda2, 5 et 6, mais ça ne s’invente pas : fiez vous au /etc/fstab et au besoin, montez temporairement chaque disque sur /mnt. Mon “/” étant sur /dev/sda2

mount /dev/sda2 /mnt
vi /mnt/etc/fstab
#(remplacement de ext3 par ext4 sur les partitions à migrer)

Et l’opération qui suit est donc à répéter pour chacune de vos partitions :

tune2fs -O extents,uninit_bg,dir_index /dev/sda2
fsck.ext4 -pf /dev/sda2

Un reboot plus tard, everything is ok ;-)

Passé récemment sous zsh comme shell par défaut (merci Laurent), je trouve la complétion automatique de mes commandes wajig très lente. Pour mémoire, wajig est une surcouche plutôt sympa des apt* écrite en Python, et il me sert de gestionnaire de package principal sur mes Debian et Ubuntu depuis plus d’un an. La complétion automatique étant relativement rapide avec les commandes apt-get et compagnie, j’ai décidé de jeter un oeil aux scripts de complétion zsh pour wajig en particulier. J’en ai profité pour rajouter le switch -y/—yes qui manque à la complétion bien qu’étant une option parfaitement valide et documentée.

Les scripts de complétion se trouvent dans /usr/share/zsh/functions/Completion/Debian. J’ai repris le script _apt pour adapter la section install dans le script _wajig. Les deux se servent d’un 3e script commun nommé _deb_packages au cas où ça vous intéresse. Le bonheur c’est que sans connaître vraiment le langage ou les structures utilisées, comme c’est du script relativement lisible on peut tenter par des essais/erreurs de modifier ça… et on y arrive !

Voici le résultat sous forme de patch :

% diff _wajig.orig _wajig
11a12
>   '(-y —yes)'{-y,—yes}'[assume yes for any questions asked]' \
44,45c45,46
<         _alternative \
<           'packages:package:_deb_packages uninstalled' \
—-
>         _wanted \
>           'packages:package:_deb_packages "$expl_packages[@]" avail' \

Et les complétions sont redevenues rapides ; le fait de changer _alternative par _wanted m’indique d’abord une liste quand j’appuie sur TAB, plutôt qu’enchainer directement sur les options possibles.

EDIT: une simple recherche Google montre que certains poussent pour que le “framework” de complétion apt pour zsh soit aussi utilisé pour wajig ; à creuser, j’éditerai ce billet si je trouve quelque chose d’intéressant…

Sur mon serveur perso, j’ai des besoins simples en terme de mails :
1- envoyer des mails (relai local) n’importe où
2- recevoir des mails sur mes domaines (jbbarth.com et autres)

Seulement voilà, à force de suivre des tutos à droite à gauche, de piquer des conseils d’un côté et de l’autre, et surtout de me référer à la doc officielle Postfix, impossible de s’y retrouver. Je relayais des centaines de spams par jour sans savoir pourquoi, de quoi s’arracher les cheveux.

Premier coupable, Postfix : je ne me suis pas paluché tous les MAN ni toute la doc officielle dans la longueur, mais après en avoir lu une bonne partie, ce truc est d’une complexité e-ffra-yante. OK, c’est puissant, mais après ? En 1 ligne mal placée on fout toute une conf par terre, génial.

Enfin en regardant autour, Exim n’a pas l’air beaucoup plus simple bien qu’il m’attire nettement plus (ça m’a l’air souple, sympa, c’est le choix Debian par défaut, etc.).

Vient le second coupable, moi : j’ai édité les confs à la main, en tatonnant. Là, je décide de rester sous Postfix, mais de chercher une doc bien foutue. Et là hourra, merci Debian encore (<3), je trouve cette page de wiki ; voici donc :

tar cvzf /home/salvor/postfix.tgz /etc/aliases* /etc/postfix/
wajig remove —purge postfix
wajig install postfix
sudo -s
tail /var/log/mail.log
postconf -e "myorigin = chanmasters.com"
postconf -e "myhostname=$(hostname)"
postconf -e "relay_domains = chanmasters.com, vds171.sivit.org, jbbarth.com, trollsports-trial.com"
postfix reload
vi /etc/postfix/main.cf
#ajout des restrictions proposées sur le debian wiki
vi /etc/aliases
#on vérifie que les aliases sont toujours en place
#au besoin, un petit coup de "newaliases"
postconf -e "alias_maps = hash:/etc/aliases"
postfix reload
echo "test" | mail -s "1. Mail test to root" root
echo "test" | mail -s "2. Mail test to webmaster@chanmasters.com" webmaster@chanmasters.com
echo "test" | mail -s "3. Mail test to jeanbaptiste.barth@gmail.com" jeanbaptiste.barth@gmail.com
tail /var/log/mail.log
#les trois mails semblent bien passer
#ils sont bien arrivés où il faut
#mêmes tests de l'extérieur
tail /var/log/mail.log
#idem, ça roule \o/

:-)

EDIT: petit oopsie, j’ai rajouté l’option permit_mynetworks à la liste smtpd_recipient_restrictions (en premier), et pour des raisons pratiques (liées au comportement par défaut de Rails), j’ai désactivé le TLS pour le moment. Et là, ça marche !

Suite au visionnage du Railscasts d’il y a 2 semaines, je voulais tester MongoDB. Problème, il n’existe pas dans les dépôt officiels. Qu’à cela ne tienne, quelqu’un aura sûrement créé un PPA pour ça, et… en effet, il est ici

Un petit coup de add-apt-repository et c’est parti :

sudo add-apt-repository ppa:rattlecentral
sudo aptitude update

Hélas, là ça plante, et pour cause, ce PPA ne semble pas suivre la même structure de dossiers que ceux que j’ai pu ajouter via add-apt-repository par le passé. Qu’à cela ne tienne, il suffit d’éditer /etc/apt/sources.list.d/rattlecentral-ppa-karmic.list comme suit :

#deb http://ppa.launchpad.net/rattlecentral/ppa/ubuntu karmic main
deb http://ppa.launchpad.net/rattlecentral/mongodb/ubuntu karmic main

Ensuite :

sudo aptitude update
sudo aptitude search mongodb
sudo aptitude install mongodb

Nouveau problème : le démon de mongodb mongod ne démarre pas. Il suffit de lancer le démon à la main pour se rendre compte du problème :

% sudo /usr/bin/mongod
/usr/bin/mongod: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory

Et le résoudre :

sudo ln -s /usr/lib/libmozjs.so.0d /usr/lib/libmozjs.so
sudo /etc/init.d/mongodb start

Y’a plus qu’à.

PS: évidemment, si vous préférez utiliser l’excellent wajig en lieu et place de dpkg/aptitude, ce n’est pas moi qui vous retiendrai :)