NetBSD

02 / 08 / 2011 - Mise à jour il-ne-faut-pas utiliser lo0 comme interface pivot, il ne faut pas. Pour une raison que j’ignore totalement, aucun autre protocole qu’ICMP n’a jamais fonctionné pendant nos tests, si d’aucuns ont une explication rationelle, je suis toutes ouïes. Le problème est résolu en utilisant les interfaces physiques.

IPsec. À l’évocation de ce terme technique, vous avez avalé d’un trait votre Gin Tonic, vous éteignez votre écran en espérant qu’il s’agisse d’un mauvais rève et vous décrivez des cercles dans votre bureau en vous frappant la tête avec une règle metallique. Je le sais, j’étais pareil.

Update

Le post ci-dessous est à considérer “historique”, car depuis pkgsrc-2012Q2, php-fpm est disponible en standard et se configure le plus aisemment du monde.

---

Il y a une foultitude de documentations sur la façon de faire tourner PHP via fastCGI sur un nginx, et à chaque fois, j’ai l’impression de lire des tambouilles copiées/collées de ci et de là. Ça cause de scripts (non portables la plupart du temps), de wrappers, et autres solutions capillotractées, et ça me plaît pas. En dépilant un peu, j’ai abouti à une solution que je trouve élégante… sous NetBSD evidemment :)

Il y a quelques jours, nico me faisait découvrir nagstamon. Ce fabuleux petit outil est le pendant du plugin Nagios Checker pour Firefox pour votre bureau UNIX/Linux.

Nagstamon est disponible dans le repository unstable de Debian, mais devinez quoi, pas dans pkgsrc. Ntt.. ntt.. ntt… je ne pouvais pas laisser ce vide perdurer.

Pkgsrc est actuellement en status freeze afin de préparer la sortie de pkgsrc-2010Q1, aussi, nous ne sommes autorisés à commiter que des correctifs mineurs ou impactant la sécurité. Ainsi, pour l’impatient qui souhaite essayer sur le champs ce package, j’ai mis en ligne un .shar du futur package ici même, à déployer dans /usr/pkgsrc/net/nagstamon.

J’ai, dans mon réseau, des équipements capables d’utiliser le protocole syslog. Bien évidemment, je me suis mis en tête de mettre en route cette fonctionnalité, et ainsi de configurer ma passerelle NetBSD afin qu’elle serve également de serveur syslog.

Syslog est démarré par défaut sous NetBSD, mais uniquement en “secure mode”. On peut constater cela dans le fichier /etc/defaults/rc.conf :

Le flag "-s" ordonne à syslogd de n’écouter que sur une socket UNIX, au lieu d’une socket UDP. La première étape consiste donc à ajouter dans le fichier /etc/rc.conf la ligne suivante :

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.

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