la Tourmentine

Quand on aime pas trop filer ses données perso, il peut être pratique de virer toutes les conneries qu'on a posté sur les réseaux sociaux, le grand méchant Facebook en tête. Il y a deux méthodes: à la mano (va mourir avec 5 ans d'usage quotidien et des milliers de posts), ou via un script.

Concernant Facebook justement, il existe plusieurs scripts sur userscripts.org, mais le seul vraiment efficace que j'ai pu trouver est Absperge. Il ajoute un un lien supplémentaire dans la barre de menu, qui permet de tout wiper tranquillement. Attention, c'est assez gourmand en ressources. 

Depuis mon mur est propre comme un sous neuf, plus aucun tag de keupon dessus !

Aujourd'hui, suite de mes aventures expérimento-culinaires: faire des gougères. Étant bourguignon d'origine, je me devais d'avoir au moins une spécialité de mon país à savoir-faire, c'était ça ou le bœuf bourguignon, et j'ai jamais été très fan de ce dernier.

Donc voila, on se moque pas SVP:

La pâte était un peu juste, je ne l'ai sans doute pas laissé "sécher" suffisamment longtemps. Et comme on peut le voir, j'ai encore de gros progrès à faire sur le moulage. Et mettre un peu de fromage dessus aussi.

Depuis la dernière migration, au début de l'année, la situation au niveau de l'IPv6 reste loin d'être idéale: ne disposant toujours pas d'un failover digne de ce nom (et Monsieur OVH n'en ayant visiblement rien à foutre), je suis obligé de passer par une solution du pauvre, c'est-à-dire du round-robin DNS, pour redonder mes services. Malheureusement, le round-robin se rapproche plus du load-balancing que du failover, ce qui oblige le second serveur à servir des requêtes alors qu'il devrait juste faire office de serveur de secours, sans parler des problèmes collatéraux, comme le NFS ne supportant le locking quand utilisé via ZFS.

Pour simplifier tout ça (façon de parler, mon ifconfig fait tout de même 60 lignes) et avoir du vrai failover, je me suis donc résigné à passer par un tunnel 6in4 me permettant de transférer la connectivité IPv6 d'une machine à l'autre, au prix, toutefois, d'une connexion plus lente (110 ms de ping au lieu de 30, aïe) et d'un SPOF supplémentaire. Mais comme dit Octave, ce n'est que de l'IPv6, donc ce n'est pas si grave.

J'utilise donc le service IPv6 Tunnel broker d'Hurricane Electric, qui offre jusqu'à 5 tunnels gratuits. Deux choses à savoir pour celles et ceux que ça tente, toutefois:

• Si le tunnel n'est pas utilisé, il s’effondre, il faut donc mettre une solution type keepalive en place pour que le tunnel reste actif, en envoyant des pings réguliers à la gateway:
• le port 25 est bloqué par défaut; ce n'est pas gênant en soi (je vais garder les IPv6 natives pour cela), mais j'ai perdu pas mal de temps à chercher pourquoi ce putain de qmail ne répondait pas de l’extérieur...

Les DNS se mettant tranquillement à jour, la Tourmentine devrait être joignable sur les nouvelles IPs d'ici quelques heures, voire quelques jours.

Update 27/11: ayant peur de perdre des mails j'ai finalement gentiment demandé l'ouverture du port 25 au support, ce qui m'a été accordé moins de cinq heures plus tard (en tenant sans doute compte du décalage horaire). Propre, nickel, rapide. Merci Hurricane !

Il arrive qu'on se connecte sur un site via un site externe assurant l’authentification (typiquement, Facebook). Je suis pas fan de ce genre de choses (kikoo Big Bro'), surtout quand, comme je viens de m'en apercevoir, ce type d'usage est obligatoire: utiliser un identifiant Wordpress.com pour pouvoir accéder à Gravatar par exemple. Mais ce qui est encore plus problématique, c'est qu'au bout d'un moment on ne sait même plus comment on se connecte à un site...

La solution du pauvre, faute de mieux, est de noter le nom du site en question dans le champs "commentaires" de la fiche du site principal dans son KeePass favori. Ainsi la fiche remonte directement quand on fait une recherche.

Si vous trouvez mieux...

10 Septembre 2013: Je met à jour mes serveurs via freebsd-update(8), il me reste à recompiler le noyau, rebooter...et j'oublie (il faut dire que c'était un peu compliqué IRL pour moi à cette période).

23 Septembre 2013: Le serveur principal reboot pour une raison inconnue. au redémarrage, les services ne répondent pas. Il ne semble plus y avoir d'IPv6 en sortie non plus. Les partitions sont bien montées, les jails démarrées, tous les applicatifs tournent. Niveau réseau, les interfaces sont up, mais la route IPv6 par défaut est inaccessible. Les services, eux, répondent sur les IP privées des jails mais pas sur l'IP publique...

Je commence à pencher pour un problème de pare-feu:

big ~ # /etc/rc.d/pf status
pfctl: /dev/pf: No such file or directory

Aïe.

big ~ # uname -a
FreeBSD big.tourmentine.com 9.1-RELEASE-p7 FreeBSD 9.1-RELEASE-p7 #0: Mon Sep  9 21:34:37 UTC 2013     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Re-aïe.

Depuis le reboot, la machine utilise donc un noyau "generic", auquel manque entre autres...pf. D'où, pas de filtrage, mais surtout pas de redirection vers les jails.

Deux heures plus tard (ça m'apprendra à recompiler le noyau juste après les mises à jour), le problème est enfin réglé... pour IPv4. Ça a toujours été un peu la galère avec l'IPv6 chez OVH (suppression de l'annonce des routes passée inaperçue  l'année dernière par exemple); après quelques recherche je tombe là dessus. Bingo, ça marche ! Reste à trouver pourquoi ce n'est pas fait au démarrage... mais pour l'heure, dodo.