SheevaPlug
Thursday, 04 August 2016
|
Écrit par
Grégory Soutadé

Gâteau 6 ans

Le blog a six ans ! L'occasion de faire le petit bilan annuel. Les premières pensées qui me viennent à l'esprit vont vers les victimes d'une année noire (une de plus...). Une année où la France et l'Europe en général ont re découvert la barbarie aveugle. Les nouvelles d'un attentat au moyen orient étaient tellement (et tristement) courantes que l'on n'y faisait plus attention. Le fait que ces mêmes actes se passent sous notre nez a un impact totalement différent. Qui plus est quand on aurait pu se trouver soit même sur les lieux.

Paris, Bruxelles, Nice, Munich, Saint-Etienne-du-Rouvray. Autant de villes qui ont connu l'horreur. Difficile dans ce contexte de ne pas tomber dans une haine primaire. Difficile aussi de sortir sans avoir un sentiment de suspicion permanent.

Pour autant, il faut s'accrocher à ses idéaux, continuer à vivre.

Les statistiques de cette année seront déséquilibrées. En effet, j'ai décidé de ne plus compter les visites ne correspondant qu'à un seul élément (par exemple, quand on recherche une image et que l'on n'affiche que celle-ci sans visiter le site). Changement qui s'est opéré à partir de janvier 2015. Malgré cela, le nombre de visites totale est en légère hausse. La masse de données envoyée également. Cela provient des reportages photos qui sont très gourmands en bande passante.

On obtient en moyenne 65 visites par jour, là aussi, en hausse. Pourtant, depuis mai, il y a une baisse significative des visites qui s'établit à ~26/jour (non visible ici). Cette tendance est compensée par les bons chiffres de l'année passée, mais devrait se retrouver dans les statistiques de l'année prochaine.

Côté publication, encore une baisse avec seulement 31 articles, même si 3 ou 4 articles ont été avortés ou repoussés. Je dois dire que, si la matière première me manque, j'éprouve toujours autant de plaisir dans la rédaction. En substance, les articles sont un mélange de technique (dont 4 en anglais), découverte, politique. Mélange qui reste fidèle à l'objectif d'un blog pluridisciplinaire.

Côté technique, il y a la création de Dénote. Je n'aurais jamais cru que cette bête application de prise de notes puisse être aussi utile ! La fermeture de facebook2email, mais aussi et surtout, une mise à jour d'IWLA qui, conjointement avec iptogeo, devient de plus en plus puissant !

Quelques chiffres :

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

Le fameux top 10 (en gras, consultation principalement pour les images. Entre parenthèses, l'année de publication) :

C'est assez impressionnant de constater qu'il est quasi identique à celui de l'année dernière (modulo le classement), avec un seul article qui fait son entrée (position 8). Si on fait le cumul du top 10, on obtient 31,4 % des pages affichées. Bien sûr, tous ces chiffres ne tiennent pas compte de la page d'accueil.

Un autre point amusant : L'article sur la liseuse (GAME_OVER) est quasiment devenu (via les commentaires) un forum sur les firmwares Bookeen !

Toujours d'après mon analyseur de statistiques, il y a 3 personnes qui me suivent via les flux RSS et Atom.

On peut donc considérer que ce fut une bonne année en terme d'audience. Quels sont les projets pour l'année prochaine ? Tenir encore un an de plus ! Ce qui n'est pas du tout évident. De leurs côté, les outils arrivent à maturité, je ne fais presque plus que de la maintenance. Néanmoins, il faudrait retravailler le design du blog (notamment pour qu'il s'adapte aux petits écrans).

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