GuiguiAbloc

Petit billet rapide suite à la sortie de l’offre MiniCloud d’OVH http://www.kimsufi.com/cloud/

Bien évidemment, cette technique ne s’applique pas seulement à cette offre, elle est juste… bien utile.

En effet, les MiniCloud d’OVH changent d’adresse IP quand on les éteints et qu’on les rallument. C’est assez gênant de courir après la nouvelle adresse ip du cloud n°24, mais heureusement, afin d’éviter ceci, le DNS est notre ami.

Vous connaissez tous DynDNS, un service gratuit, très utilisé par les gens qui disposent d’une adresse IP dynamique chez eux, et qui permet, lors du changement d’adresse, de mettre a jour une entrée DNS de type chezmoi.dyndns.com.

Ce que je vous propose, c’est de faire la même chose sur vos serveurs DNS, et donc de changer dynamiquement une entrée de type A en cas de changement d’adresse IP (de votre MiniCloud par exemple).

Je considère déjà que vous savez comment fonctionne un DNS et que le votre est fonctionnel et opérationnel pour votre ou vos domaines.

• BIND

Pré-requis, les packages dns-utils et bind9  (pour les distributions Debian)

Première étape, créer une paire de clés pour permettre de mettre à jour le DNS à distance en toute sécurité :

dnssec-keygen -a HMAC-MD5 -b 512 -n USER -r /dev/urandom dnscloud.guiguiabloc.fr
Kdnscloud.guiguiabloc.fr.+157+06250

Vous avez désormais 2 clés, 1 privée et 1 publique (comme pour ssh)

serveur:~# ll K*
-rw------- 1 root root 130 jun  1 09:41 Kdnscloud.guiguiabloc.fr.+157+06250.key
-rw------- 1 root root 156 jun  1 09:41 Kdnscloud.guiguiabloc.fr.+157+06250.private

On récupère la clé :

serveur:~# cat Kdnscloud.guiguiabloc.fr.+157+06250.private | grep Key
Key: GaC4ezsL0c/gWqG7nzH4iYyWPqYS2tC3H78ZYkyuvj5LJyq6JZjh4f+KKhuL/A5gTnc1K0rRw2u/3z+eXA76XA==

Ajouter la clé dans le fichier named.conf (ou named.conf.local tout dépend de votre façon de travailler ) :

key "dnscloud.guiguiabloc.fr." {
   algorithm hmac-md5;
   secret "GaC4ezsL0c/gWqG7nzH4iYyWPqYS2tC3H78ZYkyuvj5LJyq6JZjh4f+KKhuL/A5gTnc1K0rRw2u/3z+eXA76XA==";
   };

Ensuite, nous allons autoriser cette clé a mettre à jour notre domaine (ou sous-domaine si vous avez séparé vos entrées)

zone "guiguiabloc.fr" {
type master;
file "/etc/bind/zone.guiguiabloc.fr";
allow-update { key dnscloud.guiguiabloc.; };
allow-query { any; };
};

Dans votre fichier de zone, ajouter votre entrée de type A :

$TTL 180        ; 3 minutes
cloud01                 A       91.12.34.56

Vous remarquerez que je force un TTL a  180 secondes (important, par défaut les entrées sont valables 24h…)

On reload Bind et on tente une mise à jour à distance :

serveur# nsupdate -d -k ./Kdnscloud.guiguiabloc.fr.+157+06250.private
   Creating key...
   > server ns.guiguiabloc.org.
   before getaddrinfo()
   > update delete cloud01.guiguiabloc.org.
   > update add cloud01.guiguiabloc.org. 180 A 212.56.43.21
   > send
...
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  60872
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
cloud1.guiguiabloc.fr.     0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1275379509 300 16 X3gUWw/uLyIJL4RykJbp24w== 60872 NOERROR 0

Et dans les logs de votre serveur Bind :

Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: signer "dnscloud.guiguiabloc.fr" approved
Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: updating zone 'guiguiabloc.fr.fr/IN': delete all rrsets from name 'cloud01.guiguiabloc.fr'
Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: updating zone 'guiguiabloc.fr/IN': adding an RR at 'cloud01.guiguiabloc.fr' A

Magique

Ne reste qu’a scripter tout cela.

2 techniques pour récuperer l’ip (a vous de choisir celle qui vous convient ) :

1. On se créer une petite page php sur un de nos serveurs web qui nous donne l’ip depuis la laquelle nous nous présentons :

cat index.php
 
<?PHP
echo $_SERVER["REMOTE_ADDR"];
?>

On l’héberge sur un nom style ip.guiguiabloc.fr et il suffit d’appeler (via Curl) l’adresse ip.guiguiabloc.fr pour récuperer notre ip fixe.

1. On récupère l’adresse IP via ifconfig

ifconfig eth0 | egrep 'inet adr:'| cut -d: -f2 | awk '{ print $1}'

Le script :

cloud# cat update_cloud.sh
#!/bin/bash
IP=`curl -s ip.guiguiabloc.fr`
 
# Si ifconfig
 
# IP=`ifconfig eth0 | egrep 'inet adr:'| cut -d: -f2 | awk '{ print $1}'`
 
# check si changement
ACTUALIP=`/usr/bin/dig +short cloud01.guiguiabloc.fr @ns.guiguiabloc.fr | /usr/bin/tail -n1 `
 
if test "$ACTUALIP" = "$IP"
then exit 0
else
 
cat > /var/scripts/majdnscloud.txt << EOF
server ns.guiguiabloc.fr
zone guiguiabloc.fr
update delete cloud01.guiguiabloc.fr. A
update add cloud01.guiguiabloc.fr. 180 A $IP
show
send
EOF
 
nsupdate -k /var/scripts/Kdnscloud.guiguiabloc.fr.+157+06250.private -v /var/scripts/majdnscloud.txt
fi

Et hop, on se met a au démarrage du cloud (genre a la fin et rc.local) et au reboot du cloud, le dns sera mis automatiquement à jour.

• DJBDNS

Si vous n’utilisez pas Bind mais l’excellent DJBDNS, il existe un tutorial très bien fait pour appliquer la même technique :

http://qmail.jms1.net/djbdns/dyndns.shtml

Voilà, j’espère que cette technique vous servira, non seulement pour vos serveurs amenés à changer d’adresse IP, mais également chez vous, si vous avez une IP dynamique et vous souhaitez utiliser vos propres noms de domaines.

Amusez vous bien

Tout le monde le sait, on ne cesse de nous rabâcher la même prophétie, bientôt c’est la fin du monde !!!

Enfin, outre la fameuse année 2012, qui a déjà pris de l’avance sur le site http://www.2012fin.com (n’y aller pas !! en plus il est vérolé !!!) si j’en crois le résultat suivant :

C’est surtout la diminution constante des adresses IPv4 publiques disponibles qui continue son oeuvre.

Bien évidemment, depuis quelques années déjà, IPv6 est la réponse a ce problème, mais bon, cela ne sera pas en place partout avant bien longtemps, donc pas de cris paniqués, de viols incongrus, d’immolations inconsidérées ou de bitures monumentales (euh quoique…), IPv4 a encore de beaux jours devant lui.

Quoi qu’il en soit, il était temps de me dépoussiérer un peu et de replonger dans les méandres d’IPv6 et de remettre cela en oeuvre dans mon architecture.

Mes connaissances en IPv6 étant plus qu’anciennes, je me suis donc remis à niveau à coup de lecture multiples sur des sites divers et variés, allant des RFC aux blogs.

La liste étant particulièrement imposante, je vous laisse plutôt vous promener sur Google.

Un des sites les plus amusants pour se remettre a niveau est Hurricane Electric, un provider Internet et également Tunnel Broker IPv6, qui vous propose de passer votre Certification IPv6 à travers une série de questionnaire et d’exercices pratiques a mettre en place (exemple vous rendre sur le site via une connexion IPv6, monter un MX IPv6, des DNS IPv6 etc…), bref des étapes amusantes qui vous permettent de progresser dans votre apprentissage/remise à niveau, tout en maquettant votre future architecture.

Pour la Certification, cela se passe la : http://ipv6.he.net/certification/

Au fur et a mesure vous changez de niveau (newbie, explorer, enthusiast, administrator, professional, guru et enfin sage). Validé bien sûr par un « zoli » diplôme et un lien vers vos résultats a mettre sur votre site :

ah ah ah

Bref, très instructif et amusant pour bosser IPv6 (je sais, les geeks ont des jeux bizarres…)

Fort de ma remise à niveau, il était temps de déployer IPv6 tout autour de ma sphère personnelle.

Un petit panaché donc des différents environnements et situations que j’ai rencontré et dont, je pense, l’un d’entre eux répondra à vos attentes.

RAPPEL DES FAITS

Non, je ne vous ferais pas un cours sur IPv6, mais il faut bien évidemment revoir nos classiques et surtout la façon dont fonctionne l’adressage IPv6.

Pour commencer, je vous invite a lire la page Wikipédia.

Maintenant, vous savez qu’une adresse IPv6 est longue de 128 bits contre 32 en IPv4.

De plus, l’écriture est au format hexadécimal et non décimal.

Pour résumer :

Mais s’il y a un « schéma » qui m’a permit de tout comprendre, c’est celui la :

2001:12d3:4:56 00: 0000:0000:0000:0000
\____________/ \_/ \..._/
partie réseau  s/s  partie pour l'identifiant
(56)           (8)    (64)

Si vous avez un /64, vous avec donc les 56 premiers bits+ les 8 bits de sous réseau + 64 bits pour vos machines (en gros cela nous fait 18 milliards de milliards d’adresses IP à votre disposition…)

Si vous avez un /56, vous avez donc les 56 premiers bits + 2^8 (256) sous réseaux X 2^64 adresses IP (18 446 744 073 709 551 616)…

Donc avec un /56 vous avec 256 sous-réseaux de 18 milliards de milliards d’adresses IP chacun… (un peu too much, non ?… )

Et bien sur, vous pouvez encore redécouper (/126, /120, /112 etc…).

Plus clair ?

ATTENTION : Une remarque importante, iptables ne contrôle pas les flux IPv6 sur vos interfaces. Il faut utiliser ip6tables pour protéger vos accès. N’oubliez donc pas de configurer en plus d’iptables, un ip6tables sur vos serveurs/pc… (et de, surtout, laisser l’icmp6 autorisé…)

CONNECTIVITE IPv6

Si vous êtes dégroupé chez Free (ou chez Nerim), vous avez la chance d’avoir un adressage IPv6 disponible rien que pour vous.

Malheureusement, étant non-dégroupé, je n’ai pas cette option, comme de nombreuses personnes chez d’autres FAI (quand je vous disais que vous avez de beaux jours en IPv4, les FAI ne sachant pas eux même faire fonctionner leurs architectures en IPv6 de bout en bout…).

La solution est le tunnel « 6to4″.

Un tunnel « 6to4″ permet de relier un réseau Ipv4 au réseau IPv6.

Les principaux fournisseurs de tunnels 6to4 sont :

-Hurricane Electric http://www.tunnelbroker.net

-Gogo6 (Freenet6) http://www.gogo6.com

-Sixxs http://www.sixxs.net

Je ne me lancerais pas dans un comparatif mais pour avoir utiliser les trois, j’ai un faible pour Gogo6 dont la facilité d’installation et la stabilité du tunnel m’ont bien plu.

Une fois enregistré chez eux, il en vous reste qu’a télécharger le source d’installation pour Linux (ou autre hein…) la : http://gogonet.gogo6.com/page/download-1

Compilation basique (make, make installdir=/usr/local/bin/gogoc install) et configuration des plus simples (userid, mot de passe et server=authenticated.freenet6.net bref lire le fichier de conf)

Il ne reste qu’a lancer l’executable (/usr/local/gogoc/bin/gogoc par exemple) pour voir un nouveau tunnel se monter dans vos interfaces réseaux :

tun       Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
adr inet6: 2001:5c0:1400:b::5b43/128 Scope:Global

et voila, vous avez un accès IPv6 :

server:/usr/local/gogoc/bin# ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8007::6a) 56 data bytes
64 bytes from 2a00:1450:8007::6a: icmp_seq=1 ttl=55 time=60.4 ms

simple non ?

Par votre navigateur Internet, a vous la joie de voir la tortue Kame gigoter pour prouver que vous utilisez une connexion IPv6.

SERVEURS DEDIES OVH

Ayant des serveurs chez OVH, ce dernier vous attribue une plage d’adresses IPv6 a utiliser sur votre serveur.

Pour cela rien de plus simple, se rendre dans son « Manager », sur la page « serveur dédié », et récupérer le /64 qui vous est attribué.

Le guide est dispo ici : http://guides.ovh.com/Ipv4Ipv6

Rien de bien compliquer mais personnellement, j’en voulais un peu plus et donc utiliser aussi l’IPv6 dans mes machines virtuelles VMWare…

La cela se complique un peu plus mais la réponse je l’ai trouvé sur le blog Linux Attitude, grâce à un excellent tuto écrit par StalkR.

En fait, OVH ne vous attribue pas un simple /64 mais un /56… Ce qui fait que vous pouvez subnetter vos adresses IPv6

Donc pour le /64 qui m’était par exemple attribué : 2001:12D3:4:5678::/64 j’ai donc à ma disposition le bloc suivant : 2001:12D3:4:5600::/56.

Ni une, ni deux, on se prend un petit subnet pour les VMs :

• 2001:12D3:4:5678::/64 pour les serveurs physiques
• 2001:12D3:4:5681::/64 pour les VMs.

(vous suivez toujours ? 2001:12D3:4:56.. est le bloc réseau que m’attribue OVH et j’ai pour moi 256 sous-réseaux (les 8 bits après le chiffre 56, pour créer mes subnets. Dans le cas présent …78.. et ..81.. (a vous de choisir dans la plage hexadecimal de 00 a FE).

A cet effet, une page web intéressante pour visualiser d’un coup tout cela : TABLE ASCII

Chaque sous-réseau disposant de 18 milliards de milliards d’adresses pour mes serveurs (honnêtement, je n’en ai pas autant…)

Un peu de tuning Kernel parce que je ne veux pas d’autoconfiguration.

Ah oui, j’ai oublié de vous parler de cela…

IPv6 a parmi ses facultés, celle d’autoconfigurer les interfaces réseaux et les routes dynamiquement grâce au « Router Advertisement« . En gros, cela permet a Mme Michu de ne pas se prendre la tête et d’avoir une configuration automatique (genre dhcp) annoncé par le routeur IPv6 en amont de sa connexion.

Je ne rentrerais pas dans le détail, (RADVD étant une excellente solution pour l’autoconfiguration de votre parc), car personnellement je tenais a maîtriser chaque étape de mon déploiement.

serveur:~# cat /etc/sysctl.conf
...
net.ipv6.conf.eth0.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.router_solicitations=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv6.conf.all.forwarding=1

Sur le serveur physique :

ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0 (1)
ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff (2)
ip route add 2001:12d3:4:5678::/64 dev vmnet1 (3)
ip neigh add proxy 2001:12d3:4:56ff:ff:ff:ff:ff dev vmnet1 (4)
ip neigh add proxy 2001:12d3:4:5681::1 dev eth0 (5)

A ajouter dans votre /etc/rc.local par exemple pour que cela soit effectif à chaque reboot (sans les (1),(2) etc..) )

Explication :

(1) J’ajoute la route vers la passerelle sur l’interface eth0

(2) J’ajoute la passerelle IPv6 comme route par défaut

(3) J’ajoute une route vers mon subnet /64 dédié a mes VMs sur l’interface VMware

(4) Je demande a l’interface vmnet1 de répondre aux requêtes à destination de l’ip de la passerelle

(5) Je demande a l’interface eth0 de répondre aux requêtes à destination de l’ipv6 de ma VM.

On attribue l’IPv6 2001:12d3:4:5681::1/64 dans notre VM.

# IPV6
iface eth0 inet6 static
address 2001:12D3:4:5681::1/64
netmask 64

On rajoute les routes dans /etc/rc.local

ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0
ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff

Pas la peine de toucher au kernel pour la VM.

On reboot tout le bouzin (physique et virtuel) et hop, magique, la VM est accessible en IPv6 de l’extérieur

SITE WEB

Les serveurs sont en IPv6, reste à rendre accessible votre site web.

Que votre serveur http soit Nginx, Apache ou autre, pas de grandes différences. (Attention, pour Nginx il faut compiler avec l’option –with-ipv6).

Juste se rappeler que les adresses IPv6 s’écrivent entre crochets.

On fait écouter le serveur sur l’IPv6 :

Listen [2001:41d0:2:67a::150]:80

Et on configure un vhost en conséquence :

NameVirtualHost [2001:41d0:2:67a::150]:80
 
...

Il ne vous reste plus qu’a ajouter une entrée de type AAAA dans votre DNS.

dig -t AAAA blog.guiguiabloc.fr
 
;; QUESTION SECTION:
;blog.guiguiabloc.fr.           IN      AAAA
 
;; ANSWER SECTION:
blog.guiguiabloc.fr.    86400   IN      AAAA    2001:41d0:2:67a::150

Et voila, le blog est accessible en IPv6 (j’ai même mis un joli logo en bas de la page ), et vérifié par ipv6forum.

IPv6 AVEC OPENVPN

Utilisant des tunnels openvpn entre mon domicile et mes serveurs OVH, bien entendu, l’idée de me servir du bloc d’adresses IPv6 d’OVH chez moi m’a tout de suite interpellé.

Comme pour les VMs, c’est assez triviale et plutot que de vous expliquez la procédure, je vous invite a lire les excellents tutos de GeekFault ou de  Vincent Riquer.

La seule différence notable est que j’utilise Vyatta comme client Openvpn chez moi (en tant que routeur d’interconnexion VPN).

Pour la spécificité Vyatta, j’ai modifié l’interface de cette façon :

openvpn-option « –dev-type tap –dev vtap0″

Ce qui me permet d’avoir une interface de type TAP et non TUN pour mon tunnel.

Vous pouvez ou utiliser RADVD comme décrit dans les tutos cités, ou utiliser le push ipv6 via le patch de Gert Döring , ou la même technique que pour les VMs.

CISCO et ADRESSAGE PRIVE IPv6

La on se spécifie un peu…

Si comme moi, vous avez monter un gros LAN des familles, l’idée d’utiliser des adresses IPv6 publiques vous enchantent moyennement.

Après tout, vous avez déjà un adressage privé IPv4, pourquoi ne pas continuer en IPv6.

Oyé, Oyé, l’adressage privé IPv6 existe.

Il a pour nom ULA (Unique Local Address) (a lire) et répond a la RFC 4193 (ex 3879).

Son plan d’adressage est le suivant : FC00::/7

( /7 ca fait un peu de monde… en fait /8 si l’on veut être propre)

Lire cet article également, et pour les connexions site à site et la technique pour générer des plans d’adressages ULA basés sur les MAC, lire : http://www.bortzmeyer.org/4193.html (ah ah ah, est-ce la fin des conflits des domaines d’encryption VPN (les habitués des tunnels ipsec comprendront…))

Bien, trêve de plaisanterie, passons a la pratique.

On se réserve un /48 pour la maison.

fd44:4ff0:adda::/48

Mise en place de la passerelle sur le routeur Cisco pour le vlan concerné :

Vlan concerné : 10

Adressage IPv6 : fd44:4ff0:adda:10::/64

cisco#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
cisco(config)#ipv6 unicast-routing
cisco(config)#int fa 0/0.10
cisco(config-subif)#ipv6 enable
cisco(config-subif)#ipv6 address FD44:4FF0:ADDA:10::1/64
cisco(config-subif)#
cisco#ping FD44:4FF0:ADDA:10::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD44:4FF0:ADDA:10::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

Sur un pc du vlan :

ifconfig eth0 inet6 add FD44:4FF0:ADDA:10::5/64
 
pc:# ping6 FD44:4FF0:ADDA:10::1
PING FD44:4FF0:ADDA:10::1(fd44:4ff0:adda:10::1) 56 data bytes
64 bytes from fd44:4ff0:adda:10::1: icmp_seq=1 ttl=64 time=1.09 ms
64 bytes from fd44:4ff0:adda:10::1: icmp_seq=2 ttl=64 time=1.10 ms

Et voila, rien de bien compliqué.

Si vous souhaitez ajouter une route statique ou par défaut, par exemple vers FD44:4FF0:ADDA:33::5

cisco(config)#ipv6 route ::/0 FD44:4FF0:ADDA:33::5

Pour vos ACL même genre (ipv6 access-list)

Un petit blog a lire avec quelques trucs et astuces Cisco et IPv6 : http://www.gho.no/tag/ipv6/

Vous pouvez donc déployer IPv6 dans votre LAN sans être routé sur Internet.

Bien évidemment, rien ne vous interdit d’utiliser les adresses IPv6 publiques dont vous disposez.

Voila pour une approche tout en douceur de l’IPv6, j’espère que ce billet vous a donner envie de manipuler un peu IPv6 et de vous préparer à la Fin du Monde

Amusez-vous bien

Comme tout bon sysadmin, la supervision de vos serveurs et services est pour vous primordiale.

Je ne ferais pas le tour des différentes solutions existantes, la plus réputée étant Nagios.

Nous allons nous focaliser sur la surveillance d’un service bien connu : un site web.

Dans la majorité des cas, les différents éléments que vous scrutez sont les charges du serveur, les différents process Apache, etc,  et bien sur, que le site Web retourne un beau code 200, tout va bien.

Mais si la page d’accueil est « défacée » , ou si un formulaire ne retourne pas la valeur escomptée, ce genre de problème reste transparent.

En lecteur assidu de ce blog, vous avez peut-être mis en place SEC ( http://blog.guiguiabloc.fr/index.php/2009/03/18/interception-des-erreurs-applicatives-dans-nagios-avec-sec-et-prelude-lml ) mais l’idéal serait  de pouvoir simuler les actions d’un utilisateur sur le site web par un scénario défini et de remonter une erreur dans Nagios en cas de comportement anormal.

Ce serait bien hein ?

Alors bien sûr, ce genre de produit existe dans le monde propriétaire (Newtest par exemple) mais en OpenSource, c’était plutôt rare.

Heureusement, mon pote Antoine, le Geek au « garage magique », nous offre une solution efficace : Grandma

Pour reprendre la présentation de l’application :

• Grandma est une sonde robotisée, elle exécute à intervalles réguliers des scénarii permettant de simuler l’action d’un utilisateur sur une application. Chaque étape du scénario fait l’objet d’une vérification pour valider que la réponse de l’application est satisfaisante.

• Grandma permet de simuler ces actions sur toute application web, 3270, OpenVMS et Unix (tout ce qui n’est pas client lourd en fait). Elle utilise pour cela les outils GNU : cUrl, c3270, Expect et est écrite en Bash.

• Grandma prend en charge un calendrier et des profils de scénarii afin de gérer les plages de maintenance et adapter les contrôles aux plages d’activité des applications.

• Grandma fait office de collecteur/ordonnanceur. Une fois les résultats (scénario terminé avec succès, temps d’exécution) récupérés, l’information est remontée vers Nagios à l’aide du client Nsca.

La classe non ?

Suffit les palabres, on se dérouille les doigts, on ferme tout ce qui pourrait nous déconcentrer (oui, oui, ça aussi…), et on se lance (« pas trop fort », oui je sais, elle est pourrie cette blague… (mais elle est quand même moins lourde que « lot du lac« …))

Je considère déjà que vous avez un Nagios actif et que vous savez configurer des remontées d’alertes par NSCA (sinon, un tour ICI )

Téléchargez les sources de Grandma et décompressez le tout dans /opt

Vous trouverez l’arborescence suivante:

/opt/grandma/arch : répertoire de stockage des archives des scénarios en erreur

/opt/grandma/cfg : répertoire de configuration

/opt/grandma/cfg/grandma.cfg : configuration générale de l’application

/opt/grandma/cfg/Grandma.cfg : configuration spécifique à chaque sonde

/opt/grandma/cfg/send_nsca*.cfg : configuration des envois d’informations vers Nagios

/opt/grandma/checks_available : répertoire de stockage des scénarios

/opt/grandma/checks_enabled : répertoire des scripts activés sur la sonde (lien symbolique vers available)

/opt/grandma/lib : répertoire des scripts communs de l’application

/opt/grandma/web : répertoire des fichiers web (interface d’administration de grandma)

Un « petit » tuto d’installation est disponible ici : http://code.google.com/p/grandma/wiki/HowtoInstallationGrandma

La première chose à faire est de créer un utilisateur spécifique  « grandma » puis de donner les droits sur /opt/grandma.

Ensuite, partie paramétrage :

serveur:# echo "export GRANDMAHOME=/opt/grandma" >> /etc/profile
 
serveur:/opt/grandma/lib# ln -s /opt/grandma/lib/grandma /etc/init.d/grandma

• Vérifier les différents chemins dans le fichier /opt/grandma/cfg/Grandma.cfg

(par exemple /bin/basename qui sous Debian est /usr/bin/basename).

• Définition du serveur Nagios : nscaserver= »nagios.guiguiabloc.fr »

Préparons notre premier scénario qui devra vérifier que le texte « Bienvenue sur GuiguiAbloc! » s’affiche sur la page d’accueil du blog.

Un scénario exemple et présent dans /opt/grandma/checks_available.

serveur:/opt/grandma/checks_available$ cat check_site_guiguiabloc
 
#!/bin/bash
#Copyright 2002,2010 - Antoine Theuret
# Affectation des variables et fonction communes
. /etc/profile
. $GRANDMAHOME/cfg/grandma.cfg
 
# Creation des repertoires temporaires et des timestamps
$GRANDMAHOME/lib/creation_rep_travail.sh ; if [ $? -ne 0 ]; then UNKNOWN "KO : Probleme lors de la creation des repertoires temporaires"; fi
 
# Bridage des scenarios en cas de surcharge de la sonde
$GRANDMAHOME/lib/controle_surcharge.sh ; if [ $? -ne 0 ]; then UNKNOWN "KO : La sonde $nomsonde est surchargee, l'execution des scenarios est bridee" ; fi
 
# Controle des plages horaires et jours d'execution
$GRANDMAHOME/lib/verif_heure_exception.sh FTN $1 ; if [ $? -eq 1 ]; then OKOUT "OK : pas de contrôle a faire sur cette periode"; fi
 
# Recuperation des mots de passe
source $GRANDMAHOME/lib/gestion_motdepasse.sh 123456 ; if [ $? -eq 3 ]; then UNKNOWN "KO : Probleme lors de la recuperation des mots de passe"; fi
 
# Test de la page d'accueil
$curl $curl_opts "http://blog.guiguiabloc.fr/" >; $tmpdir/page.html 2>&1
TESTRET ; COUNT "Bienvenue sur GuiguiAbloc!"
if [ "$count" -ne 1 ];then FATAL "KO : Pas de page d'accueil"; fi
 
OK "OK : Scenario Blog Guiguiabloc nominal"
 
serveur:/opt/grandma/checks_enabled$ ln -s ../checks_available/check_site_guiguiabloc check_site_guiguiabloc

Premier test :

serveur:/opt/grandma/checks_enabled$ ./check_site_guiguiabloc
OK : Scenario Blog Guiguiabloc nominal - Scenario execute en 1.236361391 s | ok=1.236361391

Changeons le texte sur la page et retestons :

serveur:/opt/grandma/checks_available$ ./check_site_guiguiabloc
KO : Pas de page d'accueil - Scenario execute en 1.076389951 s - <A href=http://dummy:8080/arch/check_site_guiguiabloc/20100323-155230 target=_blank>ERREUR> | ko=1.076389951

Deuxième test, on vérifie le moteur de recherche ainsi que le résultat obtenu :

# test du moteur de recherche
$curl $curl_opts "http://blog.guiguiabloc.fr/?s=tux+droid" > $tmpdir/page.html 2>&1
TESTRET ; COUNT "GuiguiAbloc search results: tux droid"
if [ "$count" -ne 1 ];then FATAL "KO : Impossible d'effectuer une recherche" ; fi
 
$curl $curl_opts "http://blog.guiguiabloc.fr/?s=tux+droid" > $tmpdir/page.html 2>&1
TESTRET ; COUNT "Les Geeks sont de grands enfants"
if [ "$count" -ne 3 ];then FATAL "KO : Retour résulat recherche incorrect" ; fi
 
serveur:/opt/grandma/checks_available$ ./check_site_guiguiabloc
OK : Scenario Blog Guiguiabloc nominal - Scenario execute en 2.043520474 s | ok=2.043520474

Les possibilités sont presque infinies, la phase la plus longue étant d’écrire les scénarios pour les rendre compatibles avec Curl.

Une fois tout en place, il ne vous reste qu’a lancer le démon Grandma sous root :

serveur:~# /opt/grandma/lib/grandma start
Lancement de grandma : [OK]

Dans Nagios, les traps Nsca  :

Mar 25 14:10:50 nagios: EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;Grandma;check_site_guiguiabloc;2;KO : Pas de page d'accueil - Scenario execute en 0.625854926 s - <A href=http://dummy:8080/arch/check_site_guiguiabloc/20100325-141051 target=_blank>ERREUR< | ko=0.625854926

Et cela vous donne un « zoli » service Nagios supplémentaire :

Il existe également une interface Web, facile à mettre en place, qui vous permettra d’un coup d’oeil d’avoir accès aux résultats des divers scénarios.

Bilan, un excellent outil composé de simples scripts shell qui semble basique,  mais redoutablement efficace pour aller plus loin dans la supervision de vos sites internet.

Amusez vous bien

Comme tout bon sysadmin qui se respecte, vous surveillez scrupuleusement vos serveurs, vos équipements ou que sais-je encore via des outils de monitoring divers et variés.

Votre infrastructure chérie est tellement scrutée que cela rendrais jalouse n’importe quelle jeune maman devant surveiller son bambin.

D’ailleurs, je me suis toujours demander pourquoi on ne passait pas les bébés sous Nagios…

Cela donnerait des résultats intéressants :

AH AH AH   

Bref…

Les remontées d’alertes « critique » doivent pouvoir avertir en temps réel le sysadmin et comme vous le savez, c’est toujours quand on est loin de son écran que la panne intervient.

L’idéal étant de pouvoir ajouter aux diverses méthodes d’alertes (mails, alarme Nagios, etc…) l’envoi d’un SMS sur votre portable.

Si votre opérateur téléphonique est SFR, vous avez la première solution de vous créer une adresse mail en @sfr.fr.

En activant sur www.sfr.fr, rubrique Messagerie, l’alerte SMS, vous recevez un texto a chaque mail reçu sur cette BAL.

Il vous suffit donc de donner un Sujet de mail lié a l’alerte pour voir s’afficher succinctement sur votre téléphone l’alerte en question.

Le concept est intéressant, malheureusement, le SMS arrive assez aléatoirement, entre une dizaine de minutes à… plusieurs heures.

Forcément, côté remontée d’alerte en temps réel, on fait mieux…

La deuxième solution est beaucoup plus fun et plus efficace.

Je vous propose tout simplement d’utiliser les API de SFR et de contacter directement leur Webservice en SOAP, comme on peut le faire avec OVH.

Classe, non ?

Car chose que vous ne savez peut-être pas, mais les opérateurs téléphoniques proposent discrètement des kits des développement (SDK) permettant de communiquer avec leur infrastructure via la plupart du temps un webservice accessible depuis le nain ternet.

C’est le cas chez Orange  sur http://www.orangepartner.com/site/frfr/home/p_home.jsp et également chez SFR.

Client SFR, c’est donc chez eux que je vais utiliser  les API.

L’atelier de développement SFR, appelé RED, est accessible sur http://red.sfr.fr/dev-zone/index.php.

L’inscription est gratuite et vous donne accès aux téléchargements des SDK (Php, JAVA et PUB (Market Place SFR).

Egalement avec la mise a disposition des SDK, vous disposez d’un « compte » lié a une application  (le red101) qui vous crédite d’un nombre de points vous permettant de tester le service et vos développements (100 SMS pour le mois par exemple)

Les API disponibles sont nombreuses et franchement intéressantes (envoi et réception de SMS, de MMS, géolocalisation de portable, gestion d’évenement, utilisation de carnet d’adresses unifié, etc…)

D’ailleurs, certaines applications développées par la communauté mérite le coup d’oeil

Sachez également que vous avez la possiblité d’acheter des packs de jetons. Exemple pour une vingtaine d’euros vous avec 350 utilisations de l’API SMS ou 267 utilisations de l’API Loc.

Le solde offert est largement suffisant pour couvrir ce que nous voulons faire, une remontée d’alerte critique par SMS sur notre portable.

N’étant pas développeur, j’ai donc choisi forcément le kit PHP, langage qui s’adaptera parfaitement à mon niveau

Les prérequis sur votre serveur sont le module soap et les librairies openssl

Sous Debian :

apt-get install php-soap openssl libssl0.9.8

Tout d’abord, téléchargement du SFR-Red_PHP_SDK_v1.1.

Avec le SDK, vous recevrez également par mail vos certificats SSL a utiliser avec l’API.

Première chose a faire, changer le mot de passe par défaut du certificat (fourni dans le mail) :

openssl rsa -des3 -in guiguiabloc.pem -out guiguiabloc.pem
Enter pass phrase for Guiguiabloc.pem:
writing RSA key
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

L’arborescence se présente ainsi (j’ai copié mes certificats dans le répertoire pour des raisons de facilité) :

docs/      config.php    examples/  wsdl/     Guiguiabloc.crt  Guiguiabloc.p12  lib/
config.php   Guiguiabloc.jks  Guiguiabloc.pem

On renseigne le fichier config.php

Et c’est tout

A vous maintenant d’écrire le script PHP utilisant la méthode SendSMS par exemple :

alerte-sms_bascule-IpFO.php
sendSMS(new
UserIdentifier("0612345678","PhoneNumber"),"ALERTE Bascule IPFailOver");
?>

On appelle le script : php alerte-sms_bascule-IpFO.php

et hop; magique, un SMS du  6011

Si vous utilisez heartbeat pour vos bascules d’IP FailOver (suite à la lecture de cet excellent billet ), il vous suffit de rajouter l’appel a ce script dans /etc/ha.d/ressource.d/IPaddrFO.

case $2 in
  start)        /etc/ha.d/ns11111-failoverupdate.py
                php /opt/sfr/alerte-sms_bascule-IpFO.php
                ip_start $1;;
  stop)         ip_stop $1;;
  status)       ip_status $1;;
  monitor)      ip_monitor $1;;
  *)            usage
                exit 1
                ;;
esac

Côté Nagios, je suppose que vous gérez déjà les niveaux d’escalades (lire cet excellent Wifi : http://wiki.nagios-fr.org/nagios/objects-reference )

Nagios envoi un mail à la BAL d’escalade et vous executer le script a réception de mail :

dans /etc/aliases

nagiossms: "|php /opt/sfr/alerte-nagios.php"

(par exemple hein, je vous laisse à votre imagination débordante )

Voilà donc une solution simple pour remonter vos alertes en temps réels, que ce soit vos états critiques Nagios, vos bascules d’IP failover ou la coupure EDF sur votre Onduleur

Amusez-vous bien