Témoignage

Hier, alors que je parcourais la zone privée de mon DNS interne, je constate la présence d’une entrée ajoutée par dhcpd que je ne connais pas. Elle était de la forme :

Intrigué, je nmap l’IP en question pour m’apercevoir qu’il s’agit d’une machine windows, exposant fièrement ses ports 135 et 139. Cette fois c’était sur, il ne s’agissait pas d’une machine de mon réseau.

Pour des raisons évidentes, j’ai décidé de rendre un peu moins aisée (i.e. pas immédiate) la découverte de mon IP. Plus précisemment, pour certains protocoles et pour certaines machines, je veux que l’IP vue par mon/mes peers ne soit pas directement l’IP que mon fournisseur d’accès m’affecte.

J’ajoute, mais cela n’a evidemment aucun rapport avec cet article, que certains pays intellectuellement plus développés ont recemment confirmé que le partage de fichiers sur le réseau n’était pas illégal sur leur sol.

SL10, c’est fini, et on va encore se faire plein d’amis ! Merci à llaumgui pour la photo ci-dessus et au mysterieux Monsieur J pour cette idée simplement géniale :)

C’est remarquable cette propension des petits lutins bleus de la nuit à aller bousiller les seules machines qui ne sont pas backupées, ils savent tout, ils voient tout, et ce sont de sacrés petits pervers de merde.

Hier matin, alors que je m’apprétais à faire le tour de mes mails avant de partir au boulot, je constate avec effroi que “je ne sors plus”. Comportement plus qu’étrange, ma passerelle récupère bien l’IP publique Free via DHCP, le ping passe quelques secondes, puis s’arrête, plus rien. Inévitablement, je commence à blâmer Free -bien qu’objectivement, je n’ai pas recontré de problèmes majeurs depuis des mois-, puis par acquis de conscience, teste le lien sur une machine differente. Ça passe.

Dernière étape de la migration des services de l’ancien iMil.net vers son nouveau foyer: icecast.

Alors que je me préparais à l’enfermer dans un chroot comme quelques-uns de ses petits camarades, je me suis souvenu que icecast supportait déjà cette fonction. Sa configuration est une promenade de santé.

Après l’avoir installé via un bête pkgin in icecast-2, l’édition de son fichier de configuration, si l’on fait abstraction de cette saloperie de format XML, est assez rapide, voici les sections qu’il vous faudra renseigner dans le fichier /usr/pkg/etc/icecast/icecast.xml afin de rapidement diffuser du son sur l’intarwebz :

Contre toute attente, la migration de mon IPBX perso a été parfaitement sans douleur. Après l’installation de la toute dernière version d’Asterisk sur mon domU NetBSD à l’aide de pkgin (puisqu’aucune option particulière ne m’était nécessaire), je me suis souvenu d’un article que j’avais initialement écrit sur le site Freephonie.org, dans lequel j’expliquais les diverses manipulations pour monter un Asterisk fonctionnel derrière du NAT. Comme souvent, l’article a été peaufiné par quelques contributeurs, et son contenu est tout à fait valide pour la configuration d’un Asterisk 1.6.

Sur le “SuperPlan Mini” qui héberge désormais iMil.net, les services sont portés par des DomUs paravirtualisés Xen. Ces machines virtuelles fonctionnent avec les mêmes versions de noyau, d’espace utilisateur et surtout, de packages. Je ne partage pas via NFS l’espace utilisateur car je ne garantis pas la sécurité des applications hébergées sur l’une et l’autre des VMs (du php, beaucoup trop de php…).

Afin de simplifier la mise à jour des packages, j’utilise, devinez quoi: pkgin. Seulement voila, comme je l’expliquais quelques posts plus bas, j’ai besoin de spécifier certaines options à quelques packages, et de fait, je ne peux pas uniquement fonder mes mises à jour sur les paquets binaires fournis par le Projet NetBSD. Dans l’exemple qui suit, on considèrera une machine “maître”, à qui revient la bonne gestion des packages et qui exporte son repertoire /usr/pkgsrc en NFS :

Je sais, je suis un vieux con. Et en bon vieux con que je suis, je n’ai jamais réussi à utiliser un autre MUA que pine / alpine. C’est pas qu’il soit franchement au dessus des autres, loin s’en faut, mais que voulez-vous, on ne change pas 14 ans d’habitudes comme ça.

Alpine a des avantages, mais aussi beaucoup d’inconvénients, et l’un d’entre eux, c’est la manière dont il “gère” la validité des certificats TLS/SSL.

Je suis toujours dans le fastidieux processus de migration des services d’iMil.net vers sa nouvelle demeure. Vous ne l’avez probablement pas remarqué, mais le site que vous avez sous les yeux est désormais servi par un apache chrooté, reverse-proxyisé par l’incroyable nginx. Je reviendrai probablement sur cette configuration dans un prochain post.

Ce week end, je m’attaque à la migration du MX. soupir

Dans la liste infinie de trucs à configurer, il y a mon “nouveau” meilleur ami: dspam.

Au boulot, j’ai élu une solution de déploiement à haute teneur en convivialité qui m’a été suggérée par nico, j’ai nommé fabric.

Ce soft à l’utilisation simplissime permet en un tournemain de réaliser des opérations complexes en masse sur une architecture distante en utilisant le protocole SSH.

Si la documentation de la plupart des fonctions est clarissime, l’une d’entre elles, qui pourtant me semblait avoir un fort potentiel loutresque, n’était pas très clairement exposée: upload_template. Cette fonction, comme son nom semble l’indiquer, permet d’envoyer sur un serveur distant un fichier “template” en ayant préalablement remplacé des variables par le contenu souhaité. Après un peu de lecture du code source de fabric, la subtilité de son utilisation m’est apparue.