SheevaPlug

La réplication quand on est auto hébergé

Tuesday, 20 October 2015
|
Écrit par
Grégory Soutadé

On ne le répétera jamais assez : avoir un serveur chez soi, c'est cool. On est réellement maître de ses données, de ce qu'on publie, de ce qu'on héberge, etc. Mais, parce qu'il y a toujours un mais, cela ne va pas sans contraintes. La première étant le débit montant. Avec une offre fibre, ce n'en est plus un (l'ADSL suffit si les fichiers ne sont pas trop gros). La seconde est l'administration. C'est une réalité, même s'il y a beaucoup de choses pour nous faciliter la vie (des paquets tout faits dans votre distribution préférée, voire une distribution dédiée). La dernière étant la disponibilité/réplication.

Disponibilité et réplication sont des notions inter dépendantes : pour avoir la première, il faut qu'en cas de panne, un autre serveur puisse prendre le relais. Donc, il y a nécessité de faire de la réplication (distante de préférence) et d'avoir un mécanisme qui permet de basculer automatiquement de l'un à l'autre. C'est le point que nous allons aborder aujourd'hui.

Pour faire de la réplication, il n'y a pas de miracles : il faut deux serveurs physiques avec (au moins) deux disques durs indépendants. Pour ma part, j'ai, d'un côté mon nouveau joujou "Déméter" (Cubox i2ex) en serveur principal (maître), et de l'autre, mon vieux Sheevaplug ("Cybelle"). Il faut ajouter à cela, un parent, un ami ou un collègue qui accepte d'héberger l'esclave.

Si la procédure est valable (et même cruciale pour un serveur), s'en est de même pour nos données personnelles en tant que particulier. Les inondations qui ont touchés la Côte d'Azur n'en sont que le triste exemple. J'habite au troisième étage ? Les canalisations du quatrième peuvent exploser, un incendie peut se déclarer, je peux être victime d'un vol. Donc dupliquez, dupliquez, dupliquez !

OpenVPN

La première étape est de configurer un tunnel OpenVPN entre les deux machines. Outre l'aspect sécurité d'un tunnel chiffré, OpenVPN est surtout très utile pour communiquer via une adresse (privée virtuelle) unique. On s'abstrait ainsi des problèmes de changement d'adresse IP, de résolution de nom.

Dans notre cas, on reporte la responsabilité de la création du tunnel sur l'esclave qui doit connaître l'IP publique du serveur maître.

Il faut ensuite mettre en place une configuration quasi similaire sur le maître et l'esclave, ce qui nécessite des petits réglages pas toujours évidents (surtout la gestion des différences).

Réplication

En ce qui concerne la réplication à proprement parler, il faudra appliquer différentes méthodes selon le service cible.

Pour un serveur web, des fichiers, des mails, on utilisera rsync.

rsync -auz root@cybelle:/var/mail /var

Pour une base de données, on s'appuiera sur le modèle maître-esclave de MySQL (dans mon cas)/PostgreSql/MariaDB...

Astuce : j'utilise une authentification SSH par clé pour l'utilisateur root sur l'esclave, valable uniquement à travers le tunnel OpenVPN.

On peut ainsi configurer un cron afin que tout soit automatique :

#!/bin/bash

HOST=soutade.fr

function cybelle_not_here()
{
    echo "Cybelle not here" | mail -s "Error" root@$HOST
    exit 0
}

# OpenVPN tunnel conectivity check
ping -c 1 cybelle >/dev/null || cybelle_not_here

# Get emails from Cybelle
rsync -auz root@cybelle:/var/mail /var
# Delete retrieved emails on Cybelle
ssh root@cybelle 'find /var/mail -name "*cybelle*" -delete'

# Push local data
rsync -auz /var/www root@cybelle:/var
rsync -auz /var/projects root@cybelle:/var
rsync -auz /home/soutade/www root@cybelle:/home/soutade

Cybelle est référencée dans /etc/hosts via son adresse privée OpenVPN.

Attention toutefois : même avec une sauvegarde distante, il est NÉCESSAIRE d'en faire une locale. Encore mieux, si elle est réalisée sur un disque chiffré. On notera que lors de la réplication (quotidienne), je lance une commande directement sur l'esclave (pour effacer les mails dans le cas présent).

DNS Failover

Maintenant que nous avons deux serveurs configurés sur deux sites distants, on peut commencer les choses sérieuses : la défaillance d'un des deux (surtout le maître). La solution proposée ici est une solution de pauvre et n'est pas recommandée pour un usage professionnel.

Nous allons discuter du DNS Failover (basculement DNS). L'idée est, qu'en cas de défaillance du serveur principal (maître), l'entrée DNS (NB: qui gère la correspondance nom de domaine/IP) soit mise à jour vers le serveur de secours (esclave). Cette solution (de pauvre) a deux inconvénients majeurs qui sont :

  • La mise à jour des serveurs DNS primaires est de l'ordre d'une demi-heure
  • Les entrées DNS peuvent être encore dans le cache du client (donc non rafraîchies)

Dans l'idéal, il aurait fallu avoir de l'IP failover, c'est-à-dire qu'un serveur frontal se charge de rediriger le trafic vers la bonne destination (celle qui est encore en vie). Mais cela nécessite des infrastructures beaucoup trop onéreuses pour les petits particuliers que nous sommes.

Pour la mise en pratique, j'ai modifié le script de mise à jour de DNS de Gandi afin qu'il retourne 34 quand une entrée vient d'être modifiée (détection d'un changement d'IP). Il affiche désormais sur la sortie standard l'ancienne et la nouvelle IP.

Sur l'esclave, un script est exécuté toutes les dix minutes. Il est chargé de vérifier que le maître est toujours vivant. Si ce n'est pas le cas, il change l'entrée DNS vers son IP actuelle (il réalise le basculement) :

#!/bin/bash

HOST=soutade.fr
MASTER_ADDRESS="10.8.0.1"

ping -c 4 checkip.dyndns.com 2>/dev/null || exit 0 # No internet connexion at all                                                          
ping -c 4 $MASTER_ADDRESS 2>/dev/null && exit 0 # Master is up, ouf !                                                                      
python /home/soutade/gandi.py || exit 0
echo `date` | mail -s "Fallback server (cybelle) activated" root@$HOST

Sur le maître, un autre script est exécuté toutes les dix minutes également :

#!/bin/bash

HOST=soutade.fr

vals=`python /home/soutade/gandi.py`
if [ $? -eq 34 ] ; then
    old_ip=`echo $vals | cut -d' ' -f9`
    new_ip=`echo $vals | cut -d' ' -f5`
    ssh -oStrictHostKeyChecking=no root@${old_ip} "sed -i -e 's/^remote .*$/remote ${new_ip}/g' /etc/openvpn/cybelle.conf ; service openvp\
n restart"
    echo `date` | mail -s "Master server (demeter) activated" root@$HOST
fi

Si le changement d'IP est effectif (changement d'IP au niveau FAI ou redémarrage du serveur), on va modifier la configuration OpenVPN de l'esclave avec notre nouvelle IP et relancer le service.

Un petit dessin pour bien visualiser les différentes situations :

Infrastructure dans le cas normal

Et en cas de défaillance du maître :

Basculement en cas de défaillance du maître

LUKS on Cubox (imx6 platform)

Sunday, 09 August 2015
|
Écrit par
Grégory Soutadé

Now I have a Cubox (i2ex), I wanted to encrypt my backup disks. I followed this excellent tutorial. The cipher recommendation is aes-xts-plain64. So, I created formated disk, encrypt it, copy data from my computer and connect it to the Cubox.

But, I get this error :

cryptsetup --type luks open /dev/sda1 backup
Enter passphrase for /dev/sda1: 
No key available with this passphrase.

I tried a couple of times, use a keyfile. Nothing worked !! It made me crazy. After a bunch of search, I found that the current kernel in the Debian image from Igor Pečovnik is 3.14.14 and has issues with NEON AES implementation.

I cannot blacklist the module as it's builtin. The solution is to build a new module from the latest 3.14.49 kernel (maintained by Greg Kroah-Hartman). Ouf ! I increased cra_priority to be sure to use the new implementation.

Instructions

In the Cubox :

  • Install kernel headers (already here in the image)
  • Download the latest 3.14 kernel from kernel.org
  • Decompress it
  • Apply this patch
  • Compile
  • Install
  • Reboot

Commands :

patch -p1 < crypto.patch
cd linux-3.14.49/arch/arm/crypto/
make
sudo make install
sudo echo aes-arm-bs >> /etc/modules
reboot

If you just want to test :

insmod aes-arm-bs.ko

Precompiled version

A precompiled version is available here. To manually install it :

sudo cp aes-arm-bs.ko /lib/modules/3.14.14-cubox-i/extra/
sudo depmod
sudo echo aes-arm-bs >> /etc/modules

Or just

sudo make install
sudo echo aes-arm-bs >> /etc/modules

Cinq ans !

Tuesday, 04 August 2015
|
Écrit par
Grégory Soutadé

Gâteau anniversaire 5 ans

Déjà 5 ans ! Les nostalgiques diraient que le temps passe vite. C'est vrai. Il s'en est passé des choses depuis août 2010. Des bonnes, des moins bonnes, la vie quoi... 5 ans, c'est le début de la maturité, du moins pour le blog et les services associés !

Pour cet anniversaire, et parce que les conditions physiques le permettent, je me suis fait un petit cadeau : Déméter.

Quésako ? C'est mon nouveau serveur qui remplace désormais Cybelle. Comme je l'avais annoncé précédemment, il s'agit d'une Cubox i2ex (sans Wifi & bluetooth). On passe ainsi d'un arm11 1,2Ghz avec 512MB de mémoire à un double cortex A9 1Ghz et 1GB de mémoire. La différence ? Trois à quatre fois plus rapide (à la louche) pour une taille diminuée par deux ! C'est surtout visible pour toute la partie dynamique (recherche/forge...). Autre avantage : la Cubox chauffe moins. La fréquence n'est pas plus haute, mais l'architecture est plus optimisée (ARMv6 vs ARMv7), la mémoire plus importante et surtout plus rapide.

SheevaPlug vs Cubox

Point important indirectement lié au nouveau serveur : le temps de présence en ligne (uptime) est maintenant de 24h dans une journée ! Au revoir Orange et son changement d'IP qui nous grève d'une heure. Et bientôt, il y aura même de l'IPv6 (si SFR se décide à mettre à jour ses box Virgin...).

Je dois dire que la migration ne s'est pas faite sans douleur. L'avantage est que j'avais des configurations déjà toutes prêtes, mais, ne pas suivre la procédure d'installation depuis le début amène d'autres problèmes (oubli de modules, de paramètres...). J'ai eu la joie de replonger dans la configuration de postfix/dovecot... aïe ! Aujourd'hui tout semble stabilisé.

Rassurez-vous, Cybelle ne part pas au rebut ! Elle servira de serveur de secours distant en cas de défaillance de Déméter. D'ailleurs, un article est prévu pour parler des mécanismes mis en place à ce sujet.

Concernant le blog en lui même : moins d'articles, mais plus intéressants. Particulièrement tout ce qui tourne autour des liseuses Bookeen avec un jailbreak à la clé (ce qui a demandé pas mal de travail).

L’outil de statistique (iwla) arrive également à maturation. Pour autant, le passage à Debian 8 a fortement perturbé le mois de mai (merci logrotate et la nouvelle conf Apache). Il a donc été moyenné par rapport aux trois mois précédents.

Revenons aux statistiques pures avec les 10 articles les plus consultés (en gras, consultation principalement pour les images. Entre parenthèses, l'année de publication) :

Il y a beaucoup de visites qui se font sur la page d'accueil (donc non comptabilisées). Mais, avec 5 articles de moins d'un an dans le top 11, c'est vraiment pas mal. Le top 2 reste inchangé. Ces 11 articles représentent 27% des pages affichées (au moins).

Des chiffres, encore (entre parenthèses, les années précédentes) :

  • 34 articles publiés (49, 50, 60, 60)
  • 21 300 visites (25 000, 12 000, 18 000, 9 000)
  • 9 Go de données envoyées (5.5, 2.7, 2.5)
  • 23 000 pages affichées

Des chiffres plutôt stables (hormis le nombre d'articles), avec une moyenne de 58 visites par jour, ce qui est plutôt bien.

Quid de la suite ? Améliorer l'existant (passage en Python 3), une petite application de notes en vue et, dans l'idéal, refaire le style CSS du blog. Vu le temps disponible, ce sont des objectifs réalisables sur ... un an, à moins qu'il ne commence enfin à pleuvoir en continu durant trois/quatre mois :)

IWLA 0.2

Thursday, 16 July 2015
|
Écrit par
Grégory Soutadé

Capture d'écran IWLA

Deuxième version d'IWLA, le clone d'AWSTATSl'analyseur de log web écrit en Python.

Qu'est ce qu'on trouve dans cette version ? Et bien ... tout. Cette version arrive au niveau d'AWSTATS en ce qui concerne mon usage, et même le dépasse !

Quelques fonctions non présentes dans AWSTATS :

  • (Meilleure) Détection des robots
  • Affichage des différences entre deux analyses
  • Ajout facile des ses propres moteurs de recherche
  • Traçage d'IP
  • Détection de lecteur de flux RSS
  • Support des fichiers de log compressés

Pour le reste, on retrouve toutes les briques de bases. Mon seul regret est de n'avoir pas encore mis en place les tests automatiques.

Mixing Apache2 and nginx log file

Wednesday, 27 May 2015
|
Écrit par
Grégory Soutadé

My configuration is a bit specific. I have an Apache server for PHP and Python stuff with nginx as a frontend (and for serving static files like this blog). This part seems normal for most of people. BUT, in my case, I want that the two servers write the access logs IN THE SAME FILE (/var/log/apache2/access.log)

I run a Debian stable on my server. With the previous version (7.0), all was fine, but, until Jessie (8.0), I found a very strange behaviour with my web statistics analyzer. I usually have from 60 to 80 visits per day. In may (after the upgrade to Jessie), I get only 2 or 3 visits per day, using only one subdomain. Plus, it's a period where I have no internet at home and no time to investigate...

Finally, I found the problem ! It's located in logrotate. The two files are :

/etc/logrotate.d/apache2

/var/log/apache2/*.log {
    daily
    missingok
    rotate 14
...
    postrotate
            if /etc/init.d/apache2 status > /dev/null ; then \
                /etc/init.d/apache2 reload > /dev/null; \
            fi;
    endscript
...
}

And /etc/logrotate.d/nginx

/var/log/nginx/*.log {
    weekly
    missingok
    rotate 52
...
    postrotate
            invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

The first one do a logrotate every day of all files in /var/log/apache2/*.log (that contains our . The second one, do only one logrotate every week. But, the most important line is located in postrotate. Why it's important ? Because it says to nginx and Apache "Now the log file has changed, close the previous and open the new one". Seems correct, but without that, nginx write in /var/log/apache2/access.log.1 and not /var/log/apache2/access.log until it gets rotated (after a week) because it will keep the handle on access.log that is renamed to access.log.1 by logrotate.

The solution is to add

invoke-rc.d nginx rotate >/dev/null 2>&1

In the postrotate section of /etc/logrotate.d/apache2 (after the if). Then, restart nginx :

systemctl restart nginx