Varnish sera situé entre le load balancer et les frontaux (qu’il load balancera). Sont fonctionnement est simple :

1. Je reçois une requête pour la page X
2. L’ai-je dans mon cache ?
3. Si oui je fournis == je soulage un frontal et les bases de X requêtes
4. Si non je récupère et je la cache si possible (on ne peut pas cacher les pages d’utilisateur logé par exemple)

Il est cependant vrai qu’en environnement de production, on mettra les caches devant les load balancer afin d’éviter de charger les load balancer pour rien. Leur load balancing se fera alors en Round-Robin DNS.

Vous allez voir, c’est simple et efficace ! Je vais montrer pour une des deux VM, la deuxième sera une copie conforme.

Prérequis :

Nous allons donc utiliser dans ce tuto deux machines sous FreeBSD 8.2 (load balancer par le load balancer) :

• 4 vCPU
• 1024Mo de RAM
• Un disque de 40Go pour un site “normal”
• 1 cartes réseau : une sur le VLAN LB-FRONT

Installation de Varnish :

La version de varnish dans les ports de FreeBSD est à jour, nous allons donc l’utiliser ! Avant tout on s’assure d’avoir des ports bien à jour :

oaf-prj-cache# portsnap fetch && portsnap extract && portsnap update

Puis on installe Varnish :

oaf-prj-cache# cd /usr/ports/www/varnish
oaf-prj-cache# make install && make clean

Et voilà… C’est bon…

Configuration de Varnish :

Varnish utilise un langage de configuration très puissant nommé “VCL” pour Varnish Configuration Language (pas très original). Tous les fichier .vcl dans le répertoire de configuration (/usr/local/etc/varnish/) sont interprétés.

Voici dont un fichier, commenté comme d’habitude, en guise d’explications :

oaf-prj-cache# vim test.fr.vlc

#On défini nos frontaux
backend web01 {
   #On défini le hostname...
  .host = "oaf-srv-web01";
   #...le header sur lequel matcher...
  .host_header = "test.fr";
   #...le port d'écoute...
  .port = "80";
   #...le nobre de connexion pour le front...
  .max_connections = 5000;
   #...le timeout des sessions...
  .connect_timeout = 60s;
   #...le timeout après l'initiation de la session...
  .first_byte_timeout = 6s;
   #...le timeout entre deux paquets...
  .between_bytes_timeout = 6s;
}

#...Idem pour le deuxième frontal...
backend web02 {
  .host = "oaf-srv-web02";
  .host_header = "test.fr";
  .port = "80";
  .max_connections = 5000;
  .connect_timeout = 60s;
  .first_byte_timeout = 6s;
  .between_bytes_timeout = 6s;
}

#Puis on crée le groupe de front load balancé
director test_fr {
        {
                .backend = web01
        }
        {
                .backend = web02
        }
}

#Pour matcher sur toute les requêtes et augmenter la cachabilite, on réécrit les header
sub vcl_recv {

  if (req.http.host ~ "(?i)^localhost$") {
  set req.http.host = "test.fr";
  set req.backend = test_fr;
  }

  if (req.http.host ~ "(?i)^12.34.56.78$") {
  set req.http.host = "test.fr";
  set req.backend = test_fr;
  }

  if (req.http.host ~ "(?i)^test.fr$") {
  set req.http.host = "test.fr";
  set req.backend = test_fr;
  }

  if (req.http.host ~ "(?i)^test.fr$") {
  set req.http.host = "test.fr";
  set req.backend = test_fr;
  }

  if (req.backend.healthy) {
                set req.grace = 30s;
        } else {
                set req.grace = 1h;
  }

  if (req.url ~ "\.(.flv|js|css|jpg|jpeg|ico|png|gif|tgz|bz2|tbz|mp3|ogg|swf)$") {
    return (lookup);
  }

  if (req.http.Range) {
    return(pipe);
  }

  # Add a unique header containing the client address LOG
  remove req.http.X-Forwarded-For;
  set    req.http.X-Forwarded-For = client.ip;
}

#On défini ce que l'on peut cacher
sub vcl_fetch {

  if (req.url ~ "\.(flv|js|css|jpg|jpeg|ico|png|gif|tgz|bz2|tbz|mp3|ogg|swf)$") {
  set beresp.ttl = 2h;
  unset beresp.http.set-cookie;
  return (deliver);
  }

  #On defini la durée de vie du cache
  set beresp.ttl = 1h;
  set beresp.grace = 2h;
  return (deliver);

}

sub vcl_hit {

        # Le force-refresh met à jour le cache
        if (req.http.Cache-Control ~ "no-cache") {
                # Ignore requests via proxy caches, IE users and badly behaved crawlers
                # like msnbot that send no-cache with every request.
                if (! (req.http.Via || req.http.User-Agent ~ "bot|MSIE")) {
                        set obj.ttl = 0s;
                        return (restart);
                }
        }

        return (deliver);
}

Et voilà !

Il ne reste plus qu’à ajouter les entrés au fichier host :

oaf-prj-cache# echo "192.168.10.10       oaf-srv-web01" >> /etc/hosts
oaf-prj-cache# echo "192.168.10.11       oaf-srv-web02" >> /etc/hosts

On ajoute le service en démarrage automatique au lancement du sytème :

oaf-prj-cache# echo 'varnishd_enable="YES"' >> /etc/rc.conf

Pour finir on fait pointer les load balancer sur les varnish, mais ça vous savez déjà faire !

Le flux passera donc par HAProxy pour les connexions HTTP qui répartira la charge sur les frontaux web. Dans le cas du HTTPS, stunnel reçoit la connexion, la forward à HAProxy qui la forward au frontaux web.

J’entend d’ici : mais c’est un SPOF ! On se calme, l’étape 5 va nous permettre de clusteriser cette brique (et le MySQLProxy aussi ) .

Sans plus attendre, on attaque !

Prérequis :

• 4vCPU
• 1024Mo de RAM
• Un disque (j’utilise des VMDK) 8Go pour le système
• 2 cartes réseau sur, une sur VLAN LB-Front et l’autre sur l’Internet

L’OS qui portera ce beau monde est : FreeBSD 8.2 x64. On a besoin d’une stack TCP/IP robuste et d’un OS économe en resource (je viens de donner une partie de la définition de FreeBSD).

Installation de HAPROXY :

La version de HAPROXY étant relativement récente dans les dépôts FreeBSD, on lance une installation à la FreeBSD, très classique :

root@haproxy-pts/0 [/usr/ports]# cd /usr/ports/net/haproxy
root@haproxy-pts/0 [/ports/net/haproxy]# make config && make && make clean

Et voilà ! HAProxy est déployé ! On l’ajoute aux services à lancer au démarrage du système :

root@haproxy-pts/0 [~]# echo 'haproxy_enable="YES"' >> /etc/rc.conf

Installation de stunnel :

La version de stunnel étant tout aussi récente, on utilise le même mécanisme :

root@haproxy-pts/0 [~]# cd /usr/ports/security/stunnel
root@haproxy-pts/0 [/ports/security/stunnel]# make config && make && make clean

On ajoute stunnel aux services à lancer au démarrage du système :

root@haproxy-pts/0 [~]# echo 'stunnel_enable="YES"' >> /etc/rc.conf

Configuration HAProxy

Toute la configuration de HAProxy tient dans un seul fichier : /usr/local/etc/haproxy.conf. Ci dessous ma configuration avec les commentaires qui vont bien :

global
        #On log en local
        log 127.0.0.1 syslog
        #On gere 10000 connexions sec
        maxconn  10000
        #On chroot pour plus de secu
        chroot /usr/share/haproxy
        #On lance le bousin avec le user nobody
        uid 65534
        gid 65534

defaults
        #Niveau de log
        log     global
        #On forward les requetes RFC-Compliants
        mode    http
        #On log les requete http et les timers
        option  httplog
        #Onlog pas le vide...
        option  dontlognull
        #On redistribu les session en cas de fail d un node
        option  redispatch
        #On active les X-Forwarded-For
        option  forwardfor
        #Nombre de test avant de declarer un node mort
        retries 3
        #Assez explicit...
        contimeout      1000
        clitimeout      10000
        srvtimeout      10000]

#On cree une interface uniquement pour les stats sur le port 1000
listen admin_page :1000
        mode http
	stats enable
	stats hide-version
        stats realm HA\ Proxy\ Stats\
        stats auth raff:hehehyesfdsf
        stats uri /

listen  test :80
        bind    :80
        #URL a tester
        option  httpchk /
        contimeout      1000
        clitimeout      10000
        srvtimeout      10000
        retries 5
        maxconn 10000
        balance roundrobin
        cookie  SERVERID nocache rewrite
        server oaf-prj-web01 192.168.10.1:80 cookie
        server oaf-prj-web02 192.168.10.2:80 cookie
        #On capture les new visiteurs
        capture cookie vgnvisitor= len 32

Configuration stunnel

Tout comme HAProxy, toute la configuration de stunnel tient en un fichier. On crée donc le fichier /usr/local/etc/stunnel/stunnel.conf :

;On configure le demon
setuid = stunnel
setgid = nogroup
pid = /tmp/stunnel.pid

;On met les certificats par defaut
cert = /usr/local/etc/stunnel/test.madeinsyria.fr.crt
key = /usr/local/etc/stunnel/test.madeinsyria.fr.key

;On renforce la stack SSL
options = NO_SSLv2
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE

;On configure les logs
output = /var/log/stunnel.log

;On configure les services https
[https]
accept  = 443
connect = 80
TIMEOUTclose = 0

Le services est donc joignable sur sont IP publique en HTTP et HTTPS. De plus l’outil de stats est joignable sur l’IP publique sur le port 1000 avec le login et mot de passe spécifiés plus haut.

Prérequis :

Nous allons donc utiliser dans ce tuto une machine sous Debian 6 :

• 1 vCPU
• 512Mo de RAM
• Un disque de 8Go pour le système
• 2 cartes réseau : une sur le VLAN Backend et l’autre sur le VLAN LB-Back

Installation de MySQLProxy et configuration système :

Nous sommes sous Debian et nous avons la chance d’avoir une version de MySQLProxy relativement à jour (à une mineure près…) dans les dépôts. Nous allons donc profiter du système de package ! Pour cela :

root@OAF-PRJ-MYSQLPROXY:~# aptitude install mysql-proxy

Et voilà… C’est tout. Avant de continuer, on va mettre à jour le fichier host du serveur :

root@OAF-PRJ-MYSQLPROXY:~# echo "192.168.20.10         OAF-PRJ-SQL01" >> /etc/hosts
root@OAF-PRJ-MYSQLPROXY:~# echo "192.168.20.11         OAF-PRJ-SQL01" >> /etc/hosts

On passe maintenant à la configuration de MySQLProxy.

Configuration de MySQLProxy :

MySQLProxy utilise des script pour définir sont mode de fonctionnement. Nous allons utiliser un des scripts fourni pour effectuer le split read/write et tout simplement créer un script de lancement.

Le script de lancement sera positionné dans /etc/mysql-proxy/. Pour le reste, ça fonctionne tout seul ! Voilà donc le mode opératoire :

root@OAF-PRJ-MYSQLPROXY:~# mkdir /etc/mysql-proxy/
root@OAF-PRJ-MYSQLPROXY:~# cd /etc/mysql-proxy/
root@OAF-PRJ-MYSQLPROXY:/etc/mysql-proxy# ls
root@OAF-PRJ-MYSQLPROXY:/etc/mysql-proxy# vim rw_launcher.sh

#!/bin/bash
#On déclare le master, le slave et le path vers le binaire
MASTERDB=192.168.20.10
SLAVEDB01=192.168.20.11
ROOT_DIR=/usr/share

#On déclare le path vers les scripts de configuration
LUA_PATH="$ROOT_DIR/mysql-proxy/?.lua" 

#On défini la commande de lancement
/usr/bin/mysql-proxy \
 --daemon \
 --proxy-backend-addresses=$MASTERDB:3306 \
 --proxy-read-only-backend-addresses=$SLAVEDB01:3306 \
 --proxy-lua-script=$ROOT_DIR/mysql-proxy/rw-splitting.lua

Et voilà ! Maintenant, on prépare un petit script de lancement automatique que l’on pose dans /etc/init.d. En fait, on va remplacer le script existant qui pu un peu :

root@OAF-PRJ-MYSQLPROXY:~# cd /etc/init.d/
root@OAF-PRJ-MYSQLPROXY:/etc/init.d# rm mysql-proxy
root@OAF-PRJ-MYSQLPROXY:/etc/init.d# vim mysql-proxy

### BEGIN INIT INFO
# Provides: mysql-proxy
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Lance MySQLProxy
# Description: La meme...
### END INIT INFO

start(){
    echo "Demarrage..."
    /etc/mysql-proxy/rw_launcher.sh
}

stop(){
    echo "Arret..."
    killall mysql-proxy
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo "Usage: mysql-proxy {start|stop|restart}"
exit 1
esac

On l’ajoute aux scripts de lancement automatique au moment du boot (normalement c’est déjà le cas) :

root@OAF-PRJ-MYSQLPROXY:~# insserv mysql-proxy

Et voilà ! Maintenant, il suffit de faire pointer vos applications vers l’IP de cette machine sur le port 4040 (celui de MySQLProxy). Pour vérifier que le service tourne bien, il suffit de voir si cette commande retourne bien une ligne :

root@OAF-PRJ-MYSQLPROXY:~# netstat -tape | grep "4040"
tcp        0      0 *:4040                  *:*                     LISTEN      root       3919        1043/mysql-proxy

Contrairement à ce que j’ai annoncé, nous n’allons pas utiliser un MySQL Cluster. Ce choix est justifié par la spécificité de MySQL Cluster qui demande un développement spécifique. En effet, le moteur de base est différent et n’est que très rarement supporté par des CMS ou même des développement spécifique. à la place, je vous propose de faire un Split Read/Write via MySQL Proxy. Il s’agit donc de répartir la lecture sur plusieurs bases (répliqués entre elles) mais de faire les insertions que sur une seule. Typiquement on écrit sur un serveur et on lit sur l’autre.

On attaque donc cette partie qui nous amènera un peu plus près de la fin du projet. Aujourd’hui on va faire de la réplication MySQL.

Prérequis

Nous allons donc utiliser dans ce tuto 2 machines sous Debian 6 :

• 4vCPU
• 1024Mo de RAM
• Un disque (j’utilise des VMDK) 8Go pour le système
• 1 carte réseau sur le VLAN Backend
• Prévoir un disque supplémentaire de XGo en fonction du besoin

Installation des serveurs MySQL :

On attaque donc avec le premier serveur MySQL SQL01 (le maitre). Vous allez voir c’est très simple, on fait l’installation via le gestionnaire de paquets dont on met à jour la liste des paquets au préalable :

root@OAF-PRJ-SQL01:~# aptitude update
root@OAF-PRJ-SQL01:~# install mysql-server

Durant l’installation, je gestionnaire demande le mot de passe root de la base de données.

On réitère la même chose sur le SQL02 (l’esclave).

On sécurise un minimum le tout avant de poursuivre grâce à la commande suivante dont on répondra au question :

root@OAF-PRJ-SQL01:~# mysql_secure_installation

On a donc notre base de travail.

Mise en réplication des bases :

Avant de mettre en place la réplication nous allons insérer une base factice qui nous servira pour les tests. Pour cela, sur le server SQL01, nous allons importer la base de test MySQL Sakila (http://dev.mysql.com/doc/sakila/en/sakila.html). Il s’agit d’une base fournies à des fins de test proposée par MySQL. Allons y, nous importons donc d’abord la structure, puis la donnée :

root@OAF-PRJ-SQL01:~# wget "http://downloads.mysql.com/docs/sakila-db.tar.gz"
root@OAF-PRJ-SQL01:~# tar xzf sakila-db.tar.gz
root@OAF-PRJ-SQL01:~# cd sakila-db/
root@OAF-PRJ-SQL01:~/sakila-db# mysql -p < sakila-schema.sql
root@OAF-PRJ-SQL01:~/sakila-db# mysql -p < sakila-data.sql

Nous pouvons donc maintenant mettre en place la réplication avec un support de test. Le mécanisme est simple : nous allons activer quelques options nécessaire au bon fonctionnement sur le master et le slave. Puis nous créerons un compte dédié à la réplication avec des droits spécifique. Pour finir, nous mettrons en place la réplication sur le slave.

Préparons donc la réplication en définissant un ID unique pour chaque serveur et en activant les log binaires sur la master. Ces log permettrons de transmettre les requêtes. Il faut éditer /etc/mysql/my.cnf et modifier les directives suivante dans la rubrique [mysqld] sur SQL01 :

root@OAF-PRJ-SQL01:~# vim /etc/mysql/my.cnf 

[mysqld]
.
.
.
bind-address            = 0.0.0.0
.
.
.
server_id               = 1
log-bin
binlog-format           = mixed
.
.
.

Puis sur SQL02 :

root@OAF-PRJ-SQL01:~# vim /etc/mysql/my.cnf 

[mysqld]
.
.
.
bind-address            = 0.0.0.0
.
.
.
server_id               = 2

Ne pas oublier de restarter le service MySQL sur SQL01 et SQL02.

Il faut maintenant créer le compte de réplication sur le master :

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepasswordofroxxor';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'slavepasswordofroxxor';
Query OK, 0 rows affected (0.00 sec)

Avant de finir, on execute un dump un peu spécial qui aura pour but de synchroniser les deux bases au niveau de la lecture des logs binaire (ceux qui permettent de rejouer les requêtes), puis on l’envoie sur le slave.

root@OAF-PRJ-SQL02:~# mysqldump -p --master-data sakila > dump.sql
root@OAF-PRJ-SQL02:~# scp dump.sql OAF-PRJ-SQL02:/root

Le compte est donc crée et le dump pret à importer. L’étape suivante est donc la configuration de la réplication sur le slave. Pour cela on commence à ajouter le hostname du slave dans le fichier host :

root@OAF-PRJ-SQL02:~# echo "192.168.20.11      OAF-SRV-SQL02" >> /etc/hosts

Puis on importe le dump du master :

root@OAF-PRJ-SQL02:~# mysql -p < dump.sql

Puis on configure le slave sur la base MySQL et on le lance ! :

mysql> CHANGE MASTER TO
    -> MASTER_HOST='OAF-SRV-SQL02',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='slavepasswordofroxxor',
    -> MASTER_PORT=3306,
    -> MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected (0.02 sec)
mysql> slave start;

pour finir on test le bon fonctionnement de la réplication. Pour cela, on vérifie que la commande qui suit retourne bien “Yes” pour les variable Slave_IO_Running et Slave_SQL_Running :

mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: OAF-PRJ-SQL01
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10
              Master_Log_File: mysqld-bin.000018
          Read_Master_Log_Pos: 247
               Relay_Log_File: mysqld-relay-bin.000033
                Relay_Log_Pos: 393
        Relay_Master_Log_File: mysqld-bin.000018
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 247
              Relay_Log_Space: 593
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

Et voilà ! Parfait ! La prochaine étape, c’est le MySQL proxy, dans le prochain billet

La réponse est simple : un frontal est une machine “jetable”. Elle a pour but d’être déployée rapidement et simplement. Si un frontal porte 250Go de données, il sera lent à répliquer et gourmand en espace disque. Sans compter les problèmes de réplications de données entre les frontaux. Pour répondre à tout cela, nous allons mettre en place un serveur de fichier avec un partage réseau NFS qui sera monté sur les frontaux. Le système de fichier utilisé sera ZFS sous FreeBSD. En effet il offre des possibilités de réplication et de sauvegarde très interessantes, mais là n’est pas l’objet du billet, nous y reviendrons.

Prérequis :

• 4vCPU
• 1024Mo de RAM
• Un disque (j’utilise des VMDK) 8Go pour le système
• Un disque de XGo pour la data (en fonction du besoin…)
• 1 carte réseau sur le VLAN Backend

L’OS qui portera ce beau monde est : FreeBSD 8.2 x64. Le ZFS y est natif, le NFS supporté et al robustesse du système n’est plus à prouver : que du bonheur. Dans une version optimisée à venire de la plateforme, je ferai la même chose, mais sous Solaris.

Partitionment ZFS :

Nous allons donc crée notre partiton ZFS qui utilisera l’ensemble de notre disque DATA. Pour cela, après avoir identifié dans /dev/ le nom de mon disque (ici da1) :

root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# zpool create data /dev/da1
root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# zpool list
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
data  49.8G  76.5K  49.7G     0%  ONLINE  -
root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# ls -l /
total 50
-rw-r--r--   2 root  wheel      798 Feb 17 03:19 .cshrc
-rw-r--r--   2 root  wheel      265 Feb 17 03:19 .profile
drwxrwxr-x   2 root  operator   512 Aug 18 04:18 .snap
-r--r--r--   1 root  wheel     6200 Feb 17 03:19 COPYRIGHT
drwxr-xr-x   2 root  wheel     1024 Feb 17 03:18 bin
drwxr-xr-x   7 root  wheel     1024 Aug 18 04:23 boot
drwxr-xr-x   2 root  wheel      512 Aug 18 04:18 cdrom
lrwxr-xr-x   1 root  wheel       10 Aug 18 04:23 compat -> usr/compat
drwxr-xr-x   2 root  wheel        2 Aug 18 02:31 data
dr-xr-xr-x   6 root  wheel      512 Aug 18 04:25 dev
drwxr-xr-x  20 root  wheel     2048 Aug 18 02:26 etc
drwxr-xr-x   3 root  wheel     1536 Feb 17 03:19 lib
drwxr-xr-x   2 root  wheel      512 Feb 17 03:18 libexec
drwxr-xr-x   2 root  wheel      512 Feb 17 03:18 media
drwxr-xr-x   2 root  wheel      512 Feb 17 03:18 mnt
dr-xr-xr-x   2 root  wheel      512 Feb 17 03:18 proc
drwxr-xr-x   2 root  wheel     2560 Feb 17 03:19 rescue
drwxr-xr-x   2 root  wheel      512 Aug 18 02:29 root
drwxr-xr-x   2 root  wheel     2560 Feb 17 03:19 sbin
lrwxr-xr-x   1 root  wheel       11 Feb 17 03:19 sys -> usr/src/sys
drwxrwxrwt   7 root  wheel      512 Aug 18 02:29 tmp
drwxr-xr-x  16 root  wheel      512 Aug 18 04:23 usr
drwxr-xr-x  23 root  wheel      512 Aug 18 04:26 var

Nous avons donc un système de fichier ZFS d’environ 50Go de crée (on le vois via la commande zpool list), nommé data, et monté à la racine (un simple ls -l /). Pour finir, on active le ZFS au démarrage de la machine :

root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# echo 'zfs_enable="YES"' >> /etc/rc.conf

Et voilà, pas besoin de plus ! Et si on partageait tout ça ?

Partage NFS :

NFS est un partage réseau qui est natif aux kernels de la quasi totalité des Unix. Il est basé sur le protocole RPC. Il est donc très avantageux de le privilégier pour partager ma partition ZFS. En effet, si je décide de changer de type d’Unix au niveau de mon frontal, je suis quasi sur de ne pas perdre la compatibilité. Une autre possibilité de ZFS dont je ne vous ai pas parlé, c’est le partage en NFS d’un pool de données. Pas mal non ?! C’est très simple :

root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# zfs set sharenfs="-maproot=root -alldirs -network 192.168.1.0 -mask 255.255.255.0" data

On remarque que le paramètre sharenfs prend en option les options NFS. Dans mon cas l’autorise le montage à partir de tous les sous répertoires de la partition ZFS pour toutes les machines du réseau 192.168.1.0/24. L’option maproot permet à l’utilisateur root distant d’avoir les droits d’écriture en root sur la partition partagée.

On peut verifier l’option via :

root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# zfs get sharenfs data

Bien sur, les partage ZFS s’appuie sur le NFS, il faut donc ajouter les services lockd et statd de NFS en démarrage automatique. Ses services permettent le lock des fichiers et la gestion du monitoring réseau pour RPC. On édite donc le fichier /etc/rc.conf :

root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# rpc_statd_enable="YES" >> /etc/rc.conf
root@oaf-prj-static.madeinsyria.fr-pts/0 [~]# rpc_lockd_enable="YES" >> /etc/rc.conf

Un petit reboot du server permet de verifier que tout est bien fonctionnel.

Montage des partages :

Sur les machines clients on monte les partages tous fraichement crées en utilisant la commande mount. Un rapide df -h permet de verifier que le filesystem est bien monté:

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# mount -t nfs 192.168.20.100:/data /data
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# df -h
Filesystem              Size    Used   Avail Capacity  Mounted on
/dev/da0s1a             989M    291M    619M    32%    /
devfs                   1.0K    1.0K      0B   100%    /dev
/dev/da0s1e             989M     14K    910M     0%    /tmp
/dev/da0s1f              11G    1.1G    8.7G    12%    /usr
/dev/da0s1d             4.8G    5.3M    4.4G     0%    /var
192.168.20.100:/data     49G     22K     49G     0%    /data

Pour que le montage se fasse automatiquement au démarrage de la machine, il faut éditer le fichier /etc/fstab et y ajouter la ligne ci dessous :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# echo "192.168.100.20:/data   /data    nfs rw  0   0" >> /etc/fstab

On adapte Nginx en modifiant la valeur de la variable “root” et “fastcgi_param”. On obtiens donc :

server {
        listen       80;
        server_name  test.madeinsyria.fr;

        access_log  /var/log/test.madeinsyria.fr.access.log  main;
        location / {
            root   /data;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /data;
        }
        #GESTION DU PHP
        location ~ \.php$ {
       try_files  $uri  /path/to/404.htm;
                #Dossier racine
            root           html;
            #On revoie vers la socket
            fastcgi_param SCRIPT_FILENAME /data/$fastcgi_script_name;
            fastcgi_pass   unix:/tmp/fcgi.socket;
            fastcgi_index  index.php;
            include        fastcgi_params;
        }
    }

On relance bien sur les service Nginx et hop c’est dans la boite ! Nos frontaux s’appuient sur une partition ZFS distante montée en NFS ! La haute dispo est en marche !!!

Depuis le 15 mars, des gens meurs dans les rues Syriennes, et une resistance s’organise. Parmi cette resistance, une cyber resistance. En effet, la dictature en place à Damas est la première au monde à avoir une cyber armée, avec ses objectifs, ces cibles. Mais qu’à cela ne tienne… en face il y a une resistance électronique.

On peut citer les plus connues comme Anonymous ou Telecomix. Sous ces noms, se cache en réalité d’autres groupes, plus fins, plus organisés, plus influents, plus puissants. Ces groupes ont monté #OpSyria. L’objectif est simple : anéantir la présence de la dictature sur le net, mais aussi redonner la liberté numérique aux Syriens.

Aujourd’hui, je revendique publiquement (oui, c’est contraire à l’éthique du groupe) mon appartenance à #OpSyria. J’y ai organisé et executé un certain nombre d’actions, du simple DoS, à l’action plus poussée sur les Internet Ground Services de la Syrie en passant par des actions ultra médiatisés.

Mes actions m’ont en particulier permis de documenter une partie du backbone Syrien ainsi de que l’architecture du réseau Internet. Je ne possède à l’heure actuelle plus aucune des données critiques sur moi, je ne suis pas assez fou pour ça. Tout est en sécurité sur des systèmes sur lesquels je n’ai aucunement la main.

Si je commence à parler en publique c’est parce que d’une part mon rôle dans cette resistance n’est plus mon rôle initial : je vais plus travailler sur la documentation et l’aide aux citoyens censurés. D’autre part, j’avoue ne plus me sentir entièrement en sécurité ou entièrement caché. Je préfère publier ce billet haut et fort plutôt que me retrouver dans une situation inconfortable sans avoir pu parler.

Grace aux aides fournis par Reflets (et donc Telecomix), sachez que de grande actions se prépare et à des dates symboliques.

Je suis ouvert à toute question soit via les commentaires, soit via le formulaire de contact.

Nous sommes Légion, Nous ne pardonnons pas, Nous n’oublions pas, attendez-vous à nous.

Since Mach 15th, people in Syria have been dying, but a resistance is also growing. The resistance I want to talk about, is of course, the electronic one. What you should know is that the Syrian dictatorship is the first one to have a Cyber Army with objectives, targets, and to be honest, results. Of course, armies fight one another.

The most famous enemies of the Syrian cyber army, are Anonymous and Telecomix. Actually, smaller groups are hidding behind those names. They are more organized, more powerful and more influential : they are the ones who created #OpSyria. They have a very simple goal : destroy the Syrian dictatorship presence online and bring electronic liberty to Syria.

Today, I would like to make public (which is the opposite of the group’s ethic) the fact that I’m part of #OpSyria. I’ve organized and/or executed several actions from the highly covered DoS’s to the heavy actions on the Syrian Internet Ground Services.

My actions made me able to dress a good card of the Syrian internet backbone and to gain good access to a part of it. I currently don’t have any information on any of my electronic/paper devices. I’m not that stupid : everything is in a safe place on systems I don’t have access to.

I am going public today because firstly my role in this war is not same anymore : I will work on helping people to protect themselves and on covering their actions. Secondly, I don’t feel safe and anonymous like I used to. I prefer to make everything public before I can’t do it anymore.

Expect some heavy actions in the next days/week. The war has just begun and is almost finished.

I’m open to any questions/comments. You can use the comments or the contact form.

We are Legion. We do not forget. We do not forgive. Expect Us.

Pour rappel, j’ai choisis Nginx pour sa capacité à tenir, avec les même resources, une charge en moyenne dix fois superieur à celle d’un Apache2. De plus, il s’agit d’un serveur web qui gagne énormément en popularité, maitriser sa mise en place ne peut être qu’un plus !

Prérequis :

La configuration hardware des VM utilisées est la suivante :

• 4vCPU
• 1024Mo de RAM
• 20Go de disque
• 2 Cartes réseau sur les 2 Vlan (LB-FRONT et LB-BACK)

L’OS qui portera ce beau monde est : FreeBSD 8.2 x64. J’aime la robustesse et la stabilité de cet OS qui n’est en rien comparable à celle d’un Linux (oui, il y a un peu de troll dans l’histoire…).

 Installation de nginx

La version fournie par les package étant trop ancienne (0.8.53 vs 1.0.5 pour la version stable  actuelle), nous allons procéder à une installation via les sources.

Tout d’abord, installons les dépendances (la librairie pcre) :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [/usr/ports]# pkg_add -r pcre

Puis il faut récupérer la tarball nginx depuis le site. Pour cela on install “wget” puis on l’utilise pour récupérer la tarball :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# pkg_add -r wget
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# wget http://nginx.org/download/nginx-1.0.5.tar.gz

Il faut ensuite procéder à la décompression de la tarball et sa compilation. On ne peut plus classique :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# tar xzvf nginx-1.0.5.tar.gz
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# cd nginx-1.0.5/
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# ./configure \
root@oaf-prj-web01.madeinsyria.fr-pts/0 # --sbin-path=/usr/local/nginx/nginx \
root@oaf-prj-web01.madeinsyria.fr-pts/0 # --conf-path=/usr/local/etc/nginx/nginx.conf \
root@oaf-prj-web01.madeinsyria.fr-pts/0 # --pid-path=/var/run/nginx/nginx.pid \
root@oaf-prj-web01.madeinsyria.fr-pts/0 # --http-log-path=/var/log/nginx/access.log \
root@oaf-prj-web01.madeinsyria.fr-pts/0 # --with-http_ssl_module
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# make
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# make install

On se retrouve donc avec nginx installé dans /usr/local/nginx et le fichier de configuration dans /usr/local/etc/nginx/. Les logs seront placé dans /var/log/nginx.

On crée le script d’init pour finir, puis on le rend executable (le script est pompé du wiki Nginx) :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# vim /usr/local/etc/rc.d/nginx
##### Copié / Collé / Save / Exit #####
#!/bin/sh

NGINX_BASE_DIR="/usr/local/nginx/"
NGINX_DAEMON="${NGINX_BASE_DIR}/sbin/nginx"
NGINX_CONF="/usr/local/etc/nginx/nginx.conf"

__launch_signal( ) {

  ${NGINX_DAEMON} -s ${1} &>/dev/null
}

__checkconfig( ) {

  ${NGINX_DAEMON} -c ${NGINX_CONF} -t &>/dev/null
}

__start( ) {

  [ -r ${NGINX_CONF} ] || exit 1 

  __checkconfig && ${NGINX_DAEMON} -c ${NGINX_CONF} &>/dev/null || return ${?}
}

__stop( ) {

  __launch_signal stop
}

__reload( ) {

  __checkconfig && __launch_signar reload || return ${?}
}

__restart( ) {

  __stop && __start
}

__show_usage( ) {

  echo "Usage: ${0} {start|stop|restart|reload}"
  exit 3
}

##
# :: main ::
case "${1}" in
  start|stop|restart|reload)
    [ -x ${NGINX_DAEMON} ] || exit 2
    __${1}
    ;;
  *)
    __show_usage
    ;;
esac

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# chmod +x /usr/local/etc/rc.d/nginx

Installation de PHP5

On install maintenant PHP5 avec le support CGI, pour cela :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# cd /usr/ports/lang/php52
root@oaf-prj-web01.madeinsyria.fr-pts/0 [/usr/ports/lang/php52]# make config #### Cocher FastCGI ####
root@oaf-prj-web01.madeinsyria.fr-pts/0 [/usr/ports/lang/php52]# make install && make clean

Puis on install les extensions PHP généralement utilisés :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# cd /usr/ports/lang/php52-extensions
root@oaf-prj-web01.madeinsyria.fr-pts/0 [/usr/ports/lang/php52-extensions]# make config #### Cocher mcrypt, GD, toutes les PDO, MySQL, zlib ####
root@oaf-prj-web01.madeinsyria.fr-pts/0 [/usr/ports/lang/php52-extensions]# make install && make clean

Intégration Nginx/PHP5

Contrairement à Apache ou Lighttpd, Nginx ne sait pas faire appel de lui même (spawn) à FastCGI pour le traitement des requêtes PHP. Pour cela, il y a plusieurs façon de faire. Celle que je vais utiliser est baser sur la brique de Lighttpd : spawn-fcgi. (Option 2 : utiliser php-fpm).  Pour faire simple : l’utilisateur appel une page via Nginx (1). Nginx crée un proccess FastCGI via spawn-fcgi (php-fpm) (2), puis lui soumet la requête (3). La page executée (4) est alors renvoyé à l’utilisateur via Nginx (5).

Option 1 (spawn-cgi) :

On commence donc par télécharger et installer spawn-fcgi (la dernière version est dispo ici : http://redmine.lighttpd.net/projects/spawn-fcgi/news) :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# wget "http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.bz2"
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# tar xzvf spawn-fcgi-1.6.3.tar.bz2
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# cd spawn-fcgi-1.6.3/
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~/spawn-fcgi-1.6.3]# ./configure
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~/spawn-fcgi-1.6.3]# make
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~/spawn-fcgi-1.6.3]# make install

On a donc un spawn-fcgi installé dans /usr/local/bin/.

Puis on crée notre script d’init et on le rend executable (bon il est pompé du wiki Nginx http://wiki.nginx.org ) :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# vim /usr/local/etc/rc.d/php-cgi
##### On colle le script suivant, on save and quit #####
#!/bin/sh
# Modified spawn-fcgi for rc.d (original: vivek@nixcraft.com)
NAME=php-cgi
SPAWNFCGI=/usr/local/bin/spawn-fcgi
FCGI_CHILDREN=3
PROCESS_NAME=lua
SERVER_SOCKET=/tmp/fcgi.socket
SERVER_PID=/tmp/fcgi.pid
SERVER_USER=www
SERVER_GROUP=www
FCGI_PROCESS=/usr/local/bin/php-cgi
SOCKSTAT=/usr/bin/sockstat
GREP=/usr/bin/grep
KILLALL=/usr/bin/killall
cmd=$1
fcgi_restart()
{
        fcgi_stop
        fcgi_start
}
fcgi_start()
{
        $SPAWNFCGI -s $SERVER_SOCKET -P $SERVER_PID -u $SERVER_USER -g $SERVER_GROUP -F $FCGI_CHILDREN -f $FCGI_PROCESS
}
fcgi_stop()
{
        $KILLALL $PROCESS_NAME
}
fcgi_status()
{
        $SOCKSTAT -u | $GREP -i $SERVER_SOCKET > /dev/null
        [ $? -eq 0  ] && echo "$PROCESS_NAME is running" || echo "$PROCESS_NAME is not running!"
}
fcgi_help()
{
        echo "Usage: $0 {(re)start|status|stop}"
}
case ${cmd} in
[Rr][Ee][Ss][Tt][Aa][Rr][Tt]) fcgi_restart;;
[Ss][Tt][Aa][Rr][Tt]) fcgi_start;;
[Ss][Tt][Oo][Pp]) fcgi_stop;;
[Ss][Tt][Aa][Tt][Uu][Ss]) fcgi_status;;
*) fcgi_help;;
esac
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# chmod +x /usr/local/etc/rc.d/php-cgi

Option 2 ( php-fpm ) :

C’est un paquet déjà installé avec php (si vous avez bien suivi les instructions…). Bah oui, facil. Il ne reste plus qu’à ajouter php-fpm en démarrage automatique via :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# echo 'php_fpm_enable="YES"' >> /etc/rc.conf

On peut alors démarrer FastCGI de la façon la plus classique avec le script d’init.

Pour finir, il ne reste plus qu’à ajuster la configuration de Nginx et tester !

Finalisation et test

Il suffit tout simplement de dire à Nginx de renvoyer les requêtes vers le FastCGI. La connexion se fait via la socket /tmp/fcgi.socket.

Pour faire simple, voici mon fichier de configuration, plus ou moins commenté (pour plus d’info, il y a la doc…) :

#User qui lance le process et nombre de fork
user www;
worker_processes  1;

#Error log et PID file
error_log  /var/log/error.log;
pid        /var/run/nginx/nginx.pid;

#Nombre max de clients par fork
events {
    worker_connections  1024;
}

#Gestion des connexions HTTP
http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/access.log  main;

    sendfile        on;
    keepalive_timeout  15;
    gzip  on;
#Gestion des VHOST
    server {
        listen       80;
        server_name  test.madeinsyria.fr;

        access_log  /var/log/test.madeinsyria.fr.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
#GESTION DU PHP
        location ~ \.php$ {
            #Dossier racine
            root           html;
            #On revoie vers la socket
            fastcgi_pass   unix:/tmp/fcgi.socket;
            fastcgi_index  index.php;
            #On défini le chemin des scripts php
            fastcgi_param  SCRIPT_FILENAME /usr/local/nginx/html/$fastcgi_script_name;
            include        fastcgi_params;
        }
    }

    # HTTPS server
    #
    #server {
    #    listen       443;
    #    server_name  localhost;

    #    ssl                  on;
    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_timeout  5m;

    #    ssl_protocols  SSLv2 SSLv3 TLSv1;
    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers   on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}

}

Il suffit alors de faire une page php index.php, de mettre un phpinfo(); dedans et d’y accéder afin de valider le bon fonctionnement.

Pour finir, on passe les services Nginx et FastCGI en démarrage automatique. Pour cela :

root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# echo 'nginx_enable="YES"' >> /etc/rc.conf
root@oaf-prj-web01.madeinsyria.fr-pts/0 [~]# echo 'php_cgi_enable="YES"' >> /etc/rc.conf

Et voilà ! On a notre premier frontal web ! Il ne reste plus qu’à le cloner (bah oui, c’est une VM) pour faire le deuxième. La prochaine étape, c’est le serveur de fichiers statique en NFS, ça sera bien plus simple. On s’accroche !

Pour occuper votre temps cet été (on sait tous que c’est plus calme en juillet/août), je vous propose de monter ensemble et en plusieurs étapes une palteforme Web Haute Disponibilité basée uniquement sur des technologies OpenSource. HAPROXY, Nginx, MySQL, NFS, Puppet, tout y passera. Faites chauffer les VM, faites chauffer le café, on va y aller !

Aujourd’hui je ne ferai que vous presenter cette infra, les choix techniques, et les differentes étapes de mise en place.

Un schéma résume souvent mille paroles et explications en IT. Je vais commencer par le schéma donc :

Alors que voit-on sur ce schéma ?

Tout d’abord, on a une couche de load balancing HTTP/HTTPS gérée par HAPROXY. Cette couche est clusterisée en mode failover grace à Pacemaker.

On retrouve ensuite les serveurs de caches Varnish qui soulagent au mieux les frontaux web grace au maintiens des éléments statique et des pages compilés.

La charge est alors répartie sur X serveurs web frontaux propulsés par le serveur web Nginx. Si j’ai choisi Nginx, c’est pour sa robustesse et sa capacité à gérer un nombre de connexions en moyenne 10 fois superieur à celui d’Apache2. Les frontaux web ne portent que de la configuration de serveur web et des interpreteurs de code (comme PHP par exemple).

Le code et autres données statiques sont portés par le serveur de fichiers dans le réseau backend. Le fichiers sont donc disponibles grace à un montage NFS.

Les applications web utilisent les frontaux SQL pour effectuer les requêtes en base. La charge sera répartie entre ces frontaux via ldirectord, un outil de load balancing intégré à Pacemaker.

Les frontaux SQL, eux, interrogent des datanode SQL. Le SGBD retenu est MySQL. En effet il existe en version Cluster et ses performances ne sont plus à prouver.

Pour les bases, on utilisera au final du MySQL Proxy pour faire du Split Read/Write sur des base répliqués en Master/Slave (j’explique le pourquoi du comment dans le billet).

En parallèle, dans le VLAN d’administration, on trouvera un Syslog portant les logs de l’ensemble de la plateforme. On trouvera aussi une machine d’administration portant un ensemble d’outils mais aussi un gestionnaire de configuration Puppet.

Tout ce beau monde tournera dans la mesure du possible sous FreeBSD. Dans certain cas (MySQL) je passerai par Linux pour la facilité d’installation et le support fourni.

Au niveau de l’ordre de déploiement on fera dans l’ordre :

1. Frontaux Web (Nginx + PHP5)
2. Serveur de fichier (ZFS + NFS)
3. Réplication MySQL
4. MySQL Proxy : Split Read/Write
5. HAPROXY
6. Mise en cache avec Varnish
7. Pacemaker
8. Syslog
9. CADEAU : les classes Puppet (le tuto puppet est déjà disponible : http://madeinsyria.fr/2011/06/howto-puppet-administration-et-industrialisation-de-masse/ )

Tout cela m’a fait me pencher sur des solutions de gestion de configurations et d’administration de masse. Parmi toutes ces solutions, j’ai retenu celles proposées par PuppetLabs (http ://www.puppetlabs.com/). La suite de trois outils est infaillible :

1. Puppet permettant la gestion centralisée des services et configurations
2. MCollective qui permet l’administration et l’exécution de commandes centralisé
3. Facter qui permet de dresser une véritable fiche d’identité du server

Aujourd’hui je vous propose une petite initiation à Puppet et quelques tips qui vous feront gagner du temps.

Prérequis :

• Deux machines (OSEF de l’unix, ici il y aura une Debian 6 et une FreeBSD 8.2)
• Une liaison sur le port 8140 (port de communication Puppet) entre les deux

Installation du Server (Puppet Master) :

Le serveur  tournera ici sous Debian 6. Pour installer, le très habituel :

aptitude install puppetmaster

Une fois installer, il faut éditer le fichier fileserver.conf qui permet d’autoriser l’accès aux dépôt de fichier Puppet. Pour cela, voici la syntaxe :

[files]
  #Chemin du partage
  path /etc/puppet/files
  #Machines autorisés
  allow *.madeinsyria.fr
  #Ici tout les réseau en 192.168.X.X sont autorisés.
  allow 192.168.0.0/16

Il faut aussi créer le fichier /etc/puppet/puppet.conf et y ajouter :

[master]
  certname=puppet.madeinsyria.fr

La valeur de certname est celle du hostname de la machine (obtenu via la commande « hostname »).

Pour finir, il faut éditer le fichier /etc/hosts/ afin de spécifier les noms et IP des machines clientes (à supposer que leur noms ne peut être résolu via DNS).

A ce niveau, je préconise un bon reboot de la machine. En effet, un simple restart ne prend pas très bien en compte le certname. Or cela peut devenir un gros problème, car comme nous allons le voir, les certificats permettant de communiquer ne pourront pas être transmis.

Installation du client (Puppet Agent) :

A ce niveau rien d’extraordinaire. On déploie l’agent Puppet avec un classique (oui, mon client est une FreeBSD) :

pkg_add –r puppet

Le paquet est installé et un fichier de configuration /usr/local/etc/puppet/puppet.conf est généré. Je conseil de le vider entièrement et de remplacer son contenu par :

[puppetd]
  server=FQDN-DU-SERVER-PUPPET

[main]
  logdir = /var/puppet/log
  vardir = /var/puppet
  ssldir = /var/puppet/ssl
  rundir = /var/run/puppet
  factpath = /var/puppet/lib/facter:/var/puppet/facts
  templatedir = /var/puppet/templates

En effet, par défaut le fichier contient TOUS les éléments de configuration aussi bien pour la partie cliente que serveur. Et comme je suis gentil comme tout, voici la même chose pour Debian :

[puppetd]
  server=FQDN-DU-SERVER-PUPPET

[main]
  logdir=/var/log/puppet
  vardir=/var/lib/puppet
  ssldir=/var/lib/puppet/ssl
  rundir=/var/run/puppet
  factpath=$vardir/lib/facter
  templatedir=$confdir/templates

Initialisation de la relation entre le maitre et l’agent :

Puppet utilise le chiffrement SSL pour ses communications sur le port 8140. Or qui dit SSL, dit certificats. Le server maitre sera en fait une autorité de certification et permettra de délivrer des certificats aux agents. Ce processus se déroule en deux parties :

1. L’agent demande un certificat via un CSR
2. Le maitre signe le client

Pour faire la demande du coté de l’agent, il suffit de taper la commande :

root@OAF-PRJ-SYSLOG:~# puppet agent --test
info: Creating a new SSL key for oaf-prj-syslog.madiensyria.fr
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for oaf-prj-syslog.madiensyria.fr
info: Certificate Request fingerprint (md5): 8A:03:E3:57:53:8B:91:FC:89:61:B8:A0:E0:F4:F0:EC
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled

Cette commande est celle que vous utiliserez le plus. Elle permet de demander un update manuel coté serveur. Si le client n’a pas de certificat, il demandera par la même son certificat.

Coté maitre, il ne reste plus qu’à signer le client. Pour visualiser les demandes en cours, il faut faire :

root@puppet:~# puppetca --list
oaf-prj-syslog.madiensyria.fr

Puis pour signer le client :

root@puppet:~# puppetca --sign --all
notice: Signed certificate request for oaf-prj-syslog.madiensyria.fr
notice: Removing file Puppet::SSL::CertificateRequest oaf-prj-syslog.madiensyria.fr at '/etc/puppet/ssl/ca/requests/oaf-prj-syslog.madiensyria.fr.pem'

Pour finir, l’agent va récupérer son certificat :

root@OAF-PRJ-SYSLOG:~# puppet agent --test
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for oaf-prj-syslog.madiensyria.fr
info: Caching certificate_revocation_list for ca
info: Caching catalog for oaf-prj-syslog.madiensyria.fr
info: Applying configuration version '1306778426'
notice: Finished catalog run in 0.23 seconds

Après la configuration, un petit déploiement test :

Un exemple Puppet, est le déploiement NTP. Ce service si simple et pourtant crucial est l’exemple parfait du service à industrialiser et maitriser. Nous allons donc voir comment configurer tout ça.

Création du module :

D’un point de vu Puppet, le NTP ne sera qu’un simple module. Je ne vais pas entrer dans le détail de la structure des modules Puppet, c’est assez complexe d’un point de vu hiérarchique (mais simple fonctionnellement parlant). Pour plus d information sur le sujet, il existe : http://docs.puppetlabs.com/learning/modules1.html.

Dans un premier temps j’ajoute la commande suivante qui me permettra de créer toute l’arborescence d’un module en une commande à mon .bashrc :

mkmod() {    
     mkdir "$1"     mkdir "$1/files" "$1/lib" "$1/manifests" "$1/templates" "$1/tests"
               }

Je me rends par la suite dans /etc/puppet/modules/ ou je crée ma hiérarchie de module avec ma nouvelle commande :

root@puppet:/etc/puppet/modules# mkmod ntp

Puis je crée le fichier de module en lui-même (une class Puppet) dans le sous répertoire manifests avec un nom de fichier init.pp :

root@puppet:/etc/puppet/modules# cd ntp/manifests
root@puppet:/etc/puppet/modules/ntp/manifests # vim init.pp
class ntp {
    #En fonction de l’OS, je defini des paramètres spécifiques
    case $operatingsystem {
        freebsd: {
            $service_name = 'ntpd'
            $conf_file = 'ntp.conf.bsd'
            $ntppath = '/etc/ntp/ntp.conf'
        }
        debian: {
            $service_name = 'ntp'
            $conf_file = 'ntp.conf.debian'
            $ntppath = '/etc/ntp.conf'
       }
    }
    #Je m’assure que le service NTP est installé sur la machine
    package { 'ntp':
        ensure => installed,
    }
    #Je m’assure que le service tourne, mais uniquement si le fichier ntp.conf est dispo
    service { 'ntp':
        name => $service_name,
        ensure => running,
        enable => true,
        subscribe => File['ntp.conf'],
     }
     #Je m’assure que ntp.conf existe, mais seulement si le service NTP est installé
     file { 'ntp.conf':
         path => $ntppath,
         ensure => file,
         require => Package['ntp'],
         #Le fichier est récupérable dans : /etc/puppet/modules/ntp/files/
         source => "puppet:///modules/ntp/${conf_file}",
      }
}

En cadeau, mon fichier NTP de démo à placer dans /etc/puppet/modules/ntp/files/ :

root@puppet:~# cat /etc/puppet/modules/ntp/files/ntp.conf.bsd
serveur time.intrinsec.com
driftfile /var/db/ntp.drift

Il ne reste plus qu’à utiliser cette classe en l’appelant dans les fichiers de base de Puppet à savoir :

1. /etc/puppet/manifests/modules.pp qui contient tout les modules utilisables
2. /etc/puppet/manifests/nodes.pp qui contient tout les agents et leur configuration
3. /etc/puppet/manifests/site.pp qui fait appel à nodes.pp et modules.pp

 
Voici donc le contenu de modules.pp :

root@puppet:/etc/puppet/manifests# cat modules.pp
import "ntp"

Celui de nodes.pp :

root@puppet:/etc/puppet/manifests# cat nodes.pp
#n défini un ensemble de service de base
node basenode {
    include ntp
}

#Et on fait hérité mon agent de cet configuration
node 'oaf-prj-syslog.madeinsyria.fr' inherits basenode {
}

#Tout les agents non cité auront la configuration du default
node default inherits basenode {
}

Pour finir, on appel tout le monde dans site.pp :

root@puppet:/etc/puppet/manifests# cat site.pp
import "modules.pp"
import "nodes.pp"

Déploiement :

Tout ce beau monde est prêt à déployer, alors testons tout cela ! Sur le client, executons notre commande magique :

root@OAF-PRJ-SYSLOG:~# puppet agent --server puppet.madeinsyria.fr --test
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for oaf-prj-syslog.madiensyria.fr
info: Caching certificate_revocation_list for ca
info: Caching catalog for oaf-prj-syslog.madiensyria.fr
info: Applying configuration version '1306778426'
notice: /Stage[main]/Ntp/Package[ntp]/ensure: ensure changed 'purged' to 'present'
--- /etc/ntp.conf       2010-10-17 15:35:26.000000000 +0200
+++ /tmp/puppet-file20110601-1931-glkc6r-0          2011-06-01 15:28:22.000000000 +0200
@@ -1,55 +1,2 @@
-# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
-
+serveur time.intrinsec.com
driftfile /var/lib/ntp/ntp.drift
-
-
-# Enable this if you want statistics to be logged.
-#statsdir /var/log/ntpstats/
-
-statistics loopstats peerstats clockstats
-filegen loopstats file loopstats type day enable
-filegen peerstats file peerstats type day enable
-filegen clockstats file clockstats type day enable
-
-
-# You do need to talk to an NTP server or two (or three).
-#server ntp.your-provider.example
-
-# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
-# pick a different set every time it starts up.  Please consider joining the
-# pool: <http://www.pool.ntp.org/join.html>
-server 0.debian.pool.ntp.org iburst
-server 1.debian.pool.ntp.org iburst
-server 2.debian.pool.ntp.org iburst
-server 3.debian.pool.ntp.org iburst
-
-
-# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
-# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
-# might also be helpful.
-#
-# Note that "restrict" applies to both servers and clients, so a configuration
-# that might be intended to block requests from certain clients could also end
-# up blocking replies from your own upstream servers.
-
-# By default, exchange time with everybody, but don't allow configuration.
-restrict -4 default kod notrap nomodify nopeer noquery
-restrict -6 default kod notrap nomodify nopeer noquery
-
-# Local users may interrogate the ntp server more closely.
-restrict 127.0.0.1
-restrict ::1
-
-# Clients from this (example!) subnet have unlimited access, but only if
-# cryptographically authenticated.
-#restrict 192.168.123.0 mask 255.255.255.0 notrust
-# If you want to provide time to your local subnet, change the next line.
-# (Again, the address is an example only.)
-#broadcast 192.168.123.255
-# If you want to listen to time broadcasts on your local subnet, de-comment the
-# next lines.  Please do this only if you trust everybody on the network!
-#disable auth
-#broadcastclient
info: FileBucket adding /etc/ntp.conf as {md5}3e250ecaf470e1d3a2b68edd5de46bfd
info: /Stage[main]/Ntp/File[ntp.conf]: Filebucketed /etc/ntp.conf to puppet with sum 3e250ecaf470e1d3a2b68edd5de46bfd
notice: /Stage[main]/Ntp/File[ntp.conf]/content: content changed '{md5}3e250ecaf470e1d3a2b68edd5de46bfd' to '{md5}9b52a60a69ca6c82e9c8fdb96458e7cb'
info: /Stage[main]/Ntp/File[ntp.conf]: Scheduling refresh of Service[ntp]
notice: /Stage[main]/Ntp/Service[ntp]: Triggered 'refresh' from 1 events
notice: Finished catalog run in 1.13 seconds

root@OAF-PRJ-SYSLOG:~# /etc/init.d/ntp status
NTP server is running.

root@OAF-PRJ-SYSLOG:~# cat /etc/ntp.conf
serveur time.intrinsec.com
driftfile /var/lib/ntp/ntp.drift

C’est gagné et en moins de 2 seccondes ! Je posterai sous peu plein de classes de base pour déployer des Apache, PHP5, MySQL (et MySQL Cluster), NTP, etc.

J’espère que vous voyez mieux le potentiel d’une telle solution ! Pour info, j’ai déployé via Puppet un LAMP configuré et optimisé en 34 secondes…

N’hésitez à poser des questions ou à commenter si vous rencontrer des problèmes