la Tourmentine

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.

Aujourd'hui je vais vous parler des serveurs qui font tourner - entre autre - ce site: "big" est un kimsufi 4G, "small" un kimsufi 2G (ancienne gamme, la nouvelle ne supportant plus l'IP Failover). big est bien sûr le serveur principal: l'IPv4 virtuelle lui est assignée, et il réponds à environ la moitié des requètes IPv6 par le mécanisme du round-robin DNS.

Sur chacun de ces serveurs un ensemble de jails accueillent les principaux services: web, mail, ftp, dns, db. Les données utilisateur, elles, sont soit gardées en local et répliquées sur l'autre serveur (dns & db), soit partagées via NFS (les autres).

Coté sécurité, les deux machines communiquent au travers d'un tunnel IPSec, et le SSH n'est bien sûr accessible que depuis des IP triées sur le volet, et uniquement via clé publique. Pour les accès nomades, un VPN est accessible.

En cas de défaillance du serveur principal, heartbeat ce charge de contacter l'API OVH afin de basculer l'IP virtuelle sur le second serveur, de démonter ses montages NFS et de remonter le dernier snapshot ZFS du premier serveur. Il ne reste plus qu'à remettre le serveur primaire en état: par sécurité, rien n'est lancé au démarrage, et les partitions contenant les précieuses données sont cryptées: une clé, non présente sur le serveur bien sûr, est nécessaire pour les débloquer et les monter...clé qui peut être envoyé via un script depuis ma machine perso :)

À suivre, peut être, d'autres billets qui entreront dans le détail de chaque service !

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 !