la Tourmentine

Comme l'auront sans doute remarqué les deux-trois bots qui passent ici, il y a visiblement un bug avec le theme "Fallseason", qui n'affiche que le premier billet de la première page, mais pas les billets suivants...

...mais en même temps j'ai la super-flemme de chercher d'où ça vient, et puis je suis super occupé avec les bonnes-résolutions-de-début-d'année-que-je-tiendrais-jamais, alors s'il vous plaît, je vous en prie.

J'ai donc choisi la solution la plus simple: j'ai changé le thème par défaut :)

Il y a un mois j'ai mis en place DNSSEC pour sécuriser mes serveurs de noms. Tout c'est bien passé, j'ai même fait un petit script pour signer mes zones après chaque mise à jour.

Sauf que j'avais zappé un truc: l'expiration des clés. Chaque enregistrement reste valable...30 jours. Au bout de cette période les clés sont invalidées (ce qui brise la chaîne), les résolveurs cessent de faire confiance aux serveurs de noms. Les domaines disparaissent donc du réseau...

C'est ce qui est m'est donc arrivé hier soir, et a persisté sans doute un peu toute la journée. Avec l'ensemble des sites aux fraises, et sans doute pas mal de retard de mails.

Du coup je pense que je vais remettre l’expérience DNSSEC à plus tard.

Edit 11/10: DNSSEC is back, avec cette fois des dates d'expiration beaucoup plus lointaines, et surtout du monitoring.

J'utilise avec grand bonheur une debian chrootée sur mon NAS. Jusqu'à maintenant j’étais bloqué sur la version squeeze, à cause du noyau fourni (2.6.22), incompatible avec la version d'udev utilisée par la nouvelle distribution.

Jusqu'à maintenant, car dlink propose depuis tout récemment une mise à jour de son firmware incluant un noyau 2.6.31 ouvrant la voie à la modernité.

Parmi les grandes nouveautés de ce firmware, une connectivité ipv6 native...désactivée par défaut (!)

Il faut donc l'activer manuellement:

# sysctl net.ipv6.conf.egiga0.disable_ipv6=0

Maintenant le double effet kiss-kool de l'ipv6: n'étant plus protégée par le NAT, l'interface d'admin se retrouve à poil sur le net, car je n'ai pas de firewall devant le NAS (il est relié au reste du réseau via la freebox).

Pour éviter ça, l'astuce consiste à faire squatter les ports ouverts par le lighttpd natif par un autre serveur web, à modifier les ports utilisés, à désactiver le support ivp6 (qui lui, est activé par défaut...), et enfin à rendre le fichier immutable pour qu'il ne soit pas écrasé régulièrement par le NAS:

# sed -i s/80/8888/g /mnt/root/etc/lighttpd/lighttpd.conf
# chattr +i /mnt/root/etc/lighttpd/lighttpd.conf

Ensuite il ne reste plus qu'à lancer un signal (kill) à lighttpd pour qu'il s’arrête. Le NAS le relancera automatiquement, avec les paramètres définis dans /mnt/root/etc/lighttpd/lighttpd.conf. Magique.

Ne pas oublier, évidemment, d'ajouter les commandes ci-dessus au fichier boot/linuxrc pour que les modifications soient effectives après redémarrage.

Quand à la mise à jour vers wheezy proprement dite, pas grand chose de particulier: aptitude semble à éviter sur le coup (calcul de dépendances pendant des plombes), préférer apt-get qui lui lancera la mise à jour de suite:

# sed -i s/squeeze/wheezy/g /etc/apt/sources.list
# apt-get upgrade
# apt-get dist-upgrade

Dernier truc pas glop, le nouveau noyau m’empêche de faire fonctionner le module tun pré-compilé pour le noyau 2.6.22, et un module compilé par mes soins provoque un kernel panic au démarrage d'openvpn. À suivre, donc.

J'ai mis en place un serveur Jabber, Prosody. Pour ceux qui comme moi veulent se la jouer hipsters et ont un accès IPv6, cela peut poser quelques problèmes, comme évoqué dans ce thread (une obscure histoire de résolution DNS, où Prosody demande une adresse IPv6 et si il n'y en a pas, considère qu'il n'y a pas d'adresse...du tout).

Seul hic, la solution proposée (indiquer manuellement les adresse d'écoutes) ne fonctionne pas...

La seule solution pas trop chiante (pour pas avoir à régler le problème manuellement en telnet à chaque redémarrage) est d'ajouter les lignes suivantes au script d'init de prosody:

( echo ">hosts['domain1.tld'].modules.s2s.route_to_new_session.s2sout.try_connect.has_ipv4=true" ; \
  echo ">hosts['domain2.tld'].modules.s2s.route_to_new_session.s2sout.try_connect.has_ipv4=true" ; \
sleep 1 ) | telnet localhost 5582

Bien entendu il faut que mod_admin_telnet soit activé.

Il est possible que se problème soit lié à ma configuration, car elle est proche du thread cité plus haut (jail freebsd avec un alias sur lo1).

Si vous avez plus simple/élégant (j'avoue que la solution ci-dessus est plutôt crade), je suis preneur.