la Tourmentine

Suite au passage à nginx, je n'avais pas testé le support ActiveSync de mon webmail...

Résultat: un smartphone dont la batterie ne durait pas une journée, car il essayait continuellement de se synchroniser

Donc pour les gens qui utilisent "der schön webmail" Tine 2.0, qu'ils évitent de se perdre dans les rewrites moisies qui traînent sur le web, elles ne sont plus valables et celle qui marche est:

rewrite ^/Microsoft-Server-ActiveSync /index.php?frontend=activesync;

Et dire qu'il suffisait de lire le source (Tinebase/Core.php) où cette règle est indiquée en commentaire. Et bien sûr dans la doc, aussi. Comme quoi Google n'est pas toujours notre ami.

...ou un truc comme ça.

Donc, 10 ans après tout le monde - comme d'habitude - je me met au dernier truc qui poutre, j'ai nommé nginx, qui vient remplacer l'ami lighttpd.

Je garde Varnish pour la forme, même s'il n'est plus vraiment utile avec ce serveur.

J'ai été contraint d'adapter la conf de ce site et de quelques autres, donc si certains liens ne marchent pas, n'hésitez pas à m'en faire part !

La Tourmentine et tous ses services ont été inaccessibles pendant un peu plus de 24 heures. La faute à l'un des anciens serveurs que j'ai redémarré en vue du grand nettoyage avant de le rendre à m'sieur OVH.

Or, au démarrage mes serveurs lancent Heartbeat qui s'occupe, entre autre, de basculer l'IP failover qui sert de porte d'entrée principale à toute mon infrastructure. Le serveur en question étant l'ancien "master", il a tout naturellement squatté la VIP, en privant le serveur actif...et tout le monde arrivait sur un serveur mort

Et moi, étant connecté en ipv6, je n'ai rien vu pendant tout ce temps, car je ne passait pas par la VIP...ipv4.

Et je n'ai pas vu non plus le mail de chez OVH m'informant de la "connexion au manager" faite par le serveur. C'est un peu la lose.

Cela a eu au moins le mérite de mettre le doigt sur une méchante faille de mon système de supervision, que je vais m'empresser de corriger !

L'aventure HASTienne c'est terminé hier soir avec un gros crash du pool primaire, avec un fort peu poli "I/O Error" en tentant de ré-importer le pool HAST sur le second serveur. Malaise.

Vu les problèmes de lock que j'avais depuis la mise en prod, j'ai tenté le tout pour le tout: abandonnant HAST, j'ai créé de nouveaux datasets ZFS pour stocker mes précieuses données (que j'ai récupéré des backups de la veille, du coup), et j'ai ensuite synchronisé les deux serveurs à grands coups de snapshots ZFS différentiels.

Voici le principe: on commence par faire un snapshot (full) du dataset à répliquer, et on l'envoi sur l'autre serveur. On renomme ensuite, sur chaque serveur, le snapshot afin qu'il serve de référence pour les prochaines synchros:

serveur1# zfs snapshot servers/pool1/home@newsync
serveur1# zfs send servers/pool1/home@newsync | ssh -q serveur2 "zfs receive -vFd servers"
serveur1# zfs rename servers/pool1/home@newsync servers/pool1/home@prevsync
serveur2# zfs rename servers/pool1/home@newsync servers/pool1/home@prevsync


Un script à mettre en crontab sur le serveur maitre va se charger ensuite d'envoyer les snapshots différentiels; l'ancien snapshot est supprimé après transfert, et le nouveau est renommé afin qu'il serve de base aux suivants.

#!/bin/sh

bro="serveur2"
pools="pool1 pool2"


echo "`date`: ZFSync starting."
for pool in $pools
do
        dataset="servers/${pool}/home"
        echo "making new snapshot for ${pool}"
        zfs snapshot ${dataset}@newsync
        echo "sending snapshot"
        zfs send -i prevsync ${dataset}@newsync | ssh -q ${bro} "zfs receive -vFd servers"
        if [ $? -eq 1 ]
        then
                echo "error, exiting"
                exit $?
        fi
        echo "cleaning"
        zfs destroy ${dataset}@prevsync
        zfs rename ${dataset}@newsync ${dataset}@prevsync
        ssh -q ${bro} "zfs destroy ${dataset}@prevsync && zfs rename ${dataset}@newsync ${dataset}@prevsync"
done

echo

La gestion d'erreur, embryonnaire, demande encore a être améliorée ;)

Avec cette méthode, la synchro de trois datasets prends moins de trois minutes, pour environ 10 Go de données.

À noter qu'en temps normal le second serveur n'utilise pas les datasets en question: ils ne sont pas montés, à la place on utilise un montage NFS hébergé sur le premier serveur (zfs set sharenfs=on $dataset) pour que les éventuelles données écrites par le second serveur ne soient pas écrasées. En cas de bascule, les montages NFS sont démontés et les montages ZFS sont remontés à leur place, via heartbeat.

Pour mes divers besoins (coucou Free) j'utilisais jusqu'à maintenant un proxy SOCKS, 3proxy, qui fonctionne bien avec Firefox (via l'outil ultime FoxyProxy, dont je ne dirais jamais suffisamment de bien) pour mater YouPornTube.

Malheureusement, chipset Intel + 64bit + Flash = pas d'accélération matérielle...ça rame. C'était bien la peine de mettre un proxy pour libérer la bande passante.

L'idée est donc d'utiliser VLC pour voir les vidéos, tout en profitant de l'effet de notre proxy magique. Problème, VLC segfault, pas grand chose dans les logs, la syntaxe à vomir (voir billet précédent...) de 3proxy ne motive pas vraiment à chercher une solution, mais plutôt à chercher une autre solution.

Heureusement, un autre mec a eu le même genre de besoin (et visiblement le même genre d’à-priori négatifs vis-a-vis de 3proxy) et à fini par...écrire son propre soft, sss.pl (je vous avais bien dit que c'était du Chameau)

Simple comme j'aime, il suffit de le télécharger, et de le lancer avec l'IP et le port en paramètres, avec un login/pass si vous voulez. Et ça marche...à moi les vidéos HD en streaming !