SheevaPlug
Monday, 08 August 2016
|
Écrit par
Grégory Soutadé

Après avoir ouvert le champomy pour les 6 ans du blog, je reviens rapidement sur IWLA car j'aime m'auto extasier sur ce petit outil. L'idée de base était de remplacer AWSTATS par quelque chose de plus facilement "hackable", ce qui est chose faite. Si on rajoute la concision du langage Python par dessus, on obtient un script du genre :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import argparse
import gzip
import pickle
import re
import operator

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='Statistics extraction')

    parser.add_argument('-f', '--file', dest='file',
                        help='Comma separated IWLA databases')

    args = parser.parse_args()

    blog_re = re.compile(r'^.*blog\.soutade\.fr\/post\/.*$')

    big_stats = {}

    for filename in args.file.split(','):
        with gzip.open(filename, 'r') as f:
            print 'open %s' % (filename)
            stats = pickle.load(f)
            print 'unzipped %s' % (filename)
            top_pages = stats['month_stats']['top_pages']
            for (uri, count) in top_pages.items():
                if not blog_re.match(uri):
                    continue
                big_stats[uri] = big_stats.get(uri,0) + count
            print 'analyzed %s' % (filename)

    print '\n\nResults\n\n'

    for (uri, count) in sorted(big_stats.items(), key=operator.itemgetter(1), reverse=True)[:10]:
        print '%s => %d' % (uri, count)

Que fait-il ? Il va tout simplement appliquer un filtre sur les pages du blog qui concernent les articles pour en extraire les 10 les plus consultées. Ce qui me fait gagner du temps pour mon bilan annuel !

Bien sûr, on peut créer des tas d'outil indépendants qui vont extraire et manipuler les données pour les mettre en forme, le tout avec une facilité déconcertante. Mieux encore, créer un plugin pour l'intégrer directement dans la sortie HTML quand ceci est nécessaire !

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).

Thursday, 14 April 2016
|
Écrit par
Grégory Soutadé

Capture d'écran IWLA

Bientôt un an depuis la version précédente d'IWLA (mon analyseurs de statistiques web écrit en Python) et, sans m'en rendre compte, il y a des tas de nouveautés ! Au menu:

  • Mise en lumière des différences (par rapport à la dernière analyse) pour les mots clés ainsi que les fichiers téléchargés
  • Rappel du résumé annuel dans les statistiques mensuelles
  • Ajout de la durée de l'analyse
  • Détection des navigateurs
  • Détection des systèmes d'exploitations
  • Détection des pays (grâce à iptogeo)
  • Détection des clientS RSS
  • Statistiques détaillées pour un/des visiteur(s) particuliers
  • Possibilité de mettre à jour des configurationS par rapport à celles par défauts (sans écrasement) avec le suffixe "_append"
  • Statistiques par heures
  • Possibilité de spécifier plusieurs fichiers à analyser
  • Support des fichiers compressés (.gz)
  • Possibilité de ne pas compresser la base de données (option -z)
  • Possibilité de spécifier ses propres moteurs de recherche
  • Requêtes DNS inversés pour les clientS RSS

Quelques bugs ont été corrigés :

  • Le dernier jour du mois n'était pas analysé
  • Les pages accédées à la même seconde n'étaient pas analysées

Comme quoi, un logiciel "stable" n'existe pas. Je suis plutôt content de cette version qui est vraiment complète et avec des fonctionnalités non présentes dans AWStats ! Cela tient surtout en la modularité de l'architecture qui, certes, réduit un peu les performances, mais offre une grande souplesse dans l'écriture de modules (filtres).

Thursday, 29 October 2015
|
Écrit par
Grégory Soutadé

Le service f2email était en place depuis un an et demi, mais cela fait environ 6 mois qu'il n'est plus fonctionnel. Je décide donc de le stopper.

Les sources restent disponibles sur ma forge.

Pourquoi ne pas le maintenir ? Parce que Facebook impose trop de restrictions. Le monde entier s'est déchaîné lors de la sortie de Graph API, comme quoi on allait pouvoir espionner automatiquement les personnes... Ce n'est pas complètement faux. Les premières API mises à disposition étaient relativement "large" au niveau des permissions. On assiste aujourd'hui au phénomène inverse : on ne peut plus rien faire !

Dorénavant, les applications (même si elles ne sont pas distribuées) ont besoin d'être approuvées par Facebook (qui ne vérifie même pas le code source...), ce qui nécessite de remplir tout un tas de contraintes. J'ai essayé deux ou trois fois de soumettre la mienne avec des explications sur le pourquoi des permissions et la façon de s'authentifier. J'ai toujours été rejeté...

Ensuite, la lecture des amis. Il n'est possible de découvrir ou de lire le flux de vos amis que si ceux-ci ont installé l'application. On ne peut même plus accéder au flux "public". Autant dire que personne n'a installé f2email (et ce n'était pas le but).

De plus, on ne peut plus (via la graph API) accéder aux profils que via leurs identifiant numérique. Adieu le /JeanDujardinOfficiel, bonjour le /247465978636124.

J'ai vaguement essayé de migrer vers l'API 2.4, sans succès (c'est la version qui tourne actuellement).

Graph API n'est désormais destinée qu'aux mini-jeux monétisables, plus aux réelles applications utiles, dommage...

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