geekerie
Remontée d’alerte par SMS avec les API SFR
par guiguiabloc le 03 déc, 2009, sous architecture, geekerie, linux
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
;;
esacCô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
Cisco Etherchannel, VTP, OSPF et HSRP
par guiguiabloc le 11 oct, 2009, sous architecture, cisco, geekerie
Outch, la, on cumule
Dans les précédentes aventures du Blog, je vous avais fait part de mon « acquisition » de 2 routeurs Cisco 3620.
Après avoir fait un peu « mumuse » avec (ah la la, les geeks et leurs joujoux…) il était temps de les racker dans ma baie et surtout de repenser un peu l’architecture de mon LAN.
Je vous propose donc aujourd’hui un billet un peu « rigolo » sur les technos Cisco mais surtout, comment appliquer en quelques minutes des configurations que vous avez de très fortes chances de rencontrer dans un réseau d’entreprise.
Je ne détaillerais pas en nombreuses lignes le principe de fonctionnement des technologies mises en oeuvre (je vous laisse surfer sur le Nain Ternet pour plus de détails, ou, si vous le souhaitez, je pourrais m’attarder sur l’une d’entre elles sur un autre billet), mais je vous expliquerais l’essentiel (je pense) pour les utiliser.
D’ailleurs, je vous invite à farfouiller cet excellent site qui regorge de détails sur les technologies Cisco :
Bon, une tasse de café/guronsan/doliprane prête ? Les onglets sur YouPorn YouTube, P0rno.org AFP.com fermés ? On se concentre, et on y va.
(<privatejoke> Fred me susurre de se détendre avant l’effort, donc, oui, Fred, un peu de Karen Cheryl avant tout </privatejoke>)
- Etats des lieux
Le rackage est achevé et la baie réseau de la maison ressemble à cela actuellement :
Baie Guiguiabloc
Donc une architecture normale de particulier…
Mon switch Cisco Catalyst commencant a être saturé, il est temps de mettre en fonction le catalyst 2950 qui me servait de Spare en cas de panne.
Pour schématiser ce que nous allons mettre en place, voici a quoi ressemble les branchements dans la baie (provisoirement il s’entend )
La liaison entre les deux switchs se fait par câbles réseaux croisés (dans mon cas, j’en utilise deux), que je vais agréger dans un etherchannel.
- ETHERCHANNEL
L’etherchannel est une technique d’interconnexion LAN entre switches (ou routeurs bien sûr) pour offrir sur un seul lien logique, plusieurs ports Fast ou Gigabit Ethernert.
Non seulement cela vous permet de créer une redondance en cas de panne d’une interface mais également d’agréger le débit disponible et/ou de faire de l’équilibrage de charge.
Sous Linux, vous trouverez cette technique sous le nom de « Channel Bonding » ou « Teaming » sous l’OS SALE.
La syntaxe entre le 2924 et le 2950 est différente, donc adaptons nous :
sw-2924 :
interface FastEthernet0/21 description --- portchannel sw-2950 fa 0/21 --- duplex full speed 100 port group 1 distribution destination switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/22 description --- portchannel sw-2950 fa 0/22 --- duplex full speed 100 port group 1 distribution destination switchport trunk encapsulation dot1q switchport mode trunk sw-2924#sh port group 1 Group Interface Transmit Distribution ----- --------------------- --------------------- 1 FastEthernet0/21 destination address 1 FastEthernet0/22 destination address
sw-2950 :
interface Port-channel1 switchport mode trunk speed 100 duplex full flowcontrol send off interface FastEthernet0/21 description --- port-channel sw-2924 fa 0/21 --- switchport mode trunk speed 100 duplex full no cdp enable channel-group 1 mode on ! interface FastEthernet0/22 description --- portchannel sw-2924 fa 0/22 --- switchport mode trunk speed 100 duplex full no cdp enable channel-group 1 mode on sw-2950#sh interfaces port-channel 1 status Port Name Status Vlan Duplex Speed Type Po1 connected trunk full 100 sw-2950#sh interfaces port-channel 1 etherchannel Age of the Port-channel = 0d:00h:21m:02s Logical slot/port = 1/0 Number of ports = 2 GC = 0x00000000 HotStandBy port = null Port state = Port-channel Ag-Inuse Protocol = - Ports in the Port-channel: Index Load Port EC state No of bits ------+------+------+------------------+----------- 0 00 Fa0/21 On/FEC 0 0 00 Fa0/22 On/FEC 0
Voila pour la partie liaison redondante des deux switches.
NB: Pour les puristes, je suis en mode « on » (etherchannel) car c’est le seul mode que comprend le 2924, bien évidemment, sur des gammes supérieures, essayez le mode active/passive/auto ou desirable suivant le protocole que vous souhaitez utiliser (LACP ou PAgP).
- VTP
Comme je l’avais expliqué dans un précédent billet , j’utilise les Vlans dans mon réseau. Afin d’éviter de devoir renseigner les vlans dans chaque switches, nous allons utiliser VTP (Vlan Trunking Procotol), toujours en niveau 2, qui permet de centraliser la base de données des Vlans sur un switch et de le diffuser aux autres du même domaine.
Très pratique mais aussi très dangereux si vous y aller a la légère .
Sur le 2924, je le définis comme « Server » :
sw-2924# vlan database sw-2924# vtp server sw-2924# vtp domain GUIGUIABLOCVTP sw-2924# vtp password weshjesuislepatron sw-2924# sh vtp status VTP Version : 2 Configuration Revision : 2 Maximum VLANs supported locally : 68 Number of existing VLANs : 19 VTP Operating Mode : Server VTP Domain Name : GUIGUIABLOCVTP
Sur le 2950, il va falloir définir VTP en mode client (il existe 3 modes, serveur, client et transparent (ou autonome)).
ATTENTION : le champ « Configuration Revision » du futur client est très important, il faut absolument que sa valeur soit inférieure au « Server » sinon vous risquez de perdre vos vlans ! (expérience connue….).
Donc, première chose à faire, sauvegarder votre vlan.dat :
sw-2924#copy flash:vlan.dat tftp://10.154.12.1 Address or name of remote host [10.154.12.1]? Destination filename [vlan.dat]? !! 1396 bytes copied in 0.57 secs
Le plus simple étant de passer le client en mode « Transparent » d’abord, puis « Client » après, ce qui remettra a zéro le numéro de révision.
sw-2950(config)#vtp mode transparent sw-2950#sh vtp status VTP Version : 2 Configuration Revision : 0 sw-2950(config)#vtp mode client sw-2950(config)# vtp domain GUIGUIABLOCVTP sw-2950(config)# vtp password weshjesuislepatron
Après quelques secondes, vous devriez voir les VLANs appris par le client :
sw-2950#sh vtp status VTP Version : 2 Configuration Revision : 2 Maximum VLANs supported locally : 128 Number of existing VLANs : 19 VTP Operating Mode : Client VTP Domain Name : GUIGUIABLOCVTP
Désormais, les ajouts, suppressions, modifications de VLANs ne se feront que sur le 2924, qui les répercuteras sur le 2950.
- OSPF
Ah, ah, ah. Alors là il faudrait quelques heures pour en faire le tour c’est pourquoi je ne vais pas m’attarder en détails. Surtout qu’il existe un excellent article de « Monsieur » hr du GCU-SQUAD dans le Jardin qui vous expliquera tout en détails :
Pour résumer très basiquement, OSPF est un protocole de routage IP interne. Chaque routeur communique a ses voisins les réseaux auxquels il est directement connecté. Cette base connue de tous permet ensuite a chaque routeur de déterminer la route la plus courte vers chacun des réseaux. Ce protocole étant dynamique, un changement de route, une perte de lien est apprise en quelques secondes par les autres routeurs qui se chargeront ou de l’assimiler ou de trouver un autre chemin pour se rendre dans le réseau impacté.
Sur mon routeur principal, le 2611, on prépare la conf (les chiffres entre parenthèses vous amènent a l’explication) :
router ospf 1 log-adjacency-changes area 0 authentication message-digest redistribute connected metric-type 1 subnets (1) redistribute static subnets (1) passive-interface default (2) no passive-interface FastEthernet0/0.100 (3) network 10.154.100.0 0.0.0.255 area 0 (4)
(1) J’annonce tous les réseaux sur lesquels je suis directement connecté (également les subnets)
(2) Je désactive OSPF sur toutes les interfaces sauf celles explicitement nommées
(3) Je parle OSPF sur la sub-interface fa 0/0.100
(4) J’annonce le réseau 10.154.100.0/24 en tant qu’area0, réseau qui correspond a mon backbone.
On prépare les deux routeurs 3620 :
rt-3620-a
interface Loopback1 ip address 10.154.13.8 255.255.255.255 router ospf 1 log-adjacency-changes area 0 authentication message-digest redistribute connected subnets passive-interface default no passive-interface FastEthernet0/0.100 network 10.154.100.248 0.0.0.0 area 0
rt-3620-b
interface Loopback1 ip address 10.154.13.9 255.255.255.255 router ospf 1 log-adjacency-changes area 0 authentication message-digest redistribute connected subnets passive-interface default no passive-interface FastEthernet0/0.100 network 10.154.100.249 0.0.0.0 area 0
Roulez jeunesse, le temps que ca converge (quelques secondes) et les routes sont apprises de partout :
rt-2611#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.154.13.8 1 FULL/DROTHER 00:00:33 10.154.100.248 FastEthernet0/0.100 10.154.13.9 1 FULL/BDR 00:00:33 10.154.100.249 FastEthernet0/0.100
FULL = nous sommes voisins et échangeons les routes
DROTHER = nous ne sommes ni DR (designated router) ni BDR (backup designated router)
BDR = nous sommes le « backup designated router » de ce réseau
rt-2611# sh ip route ... O E2 10.154.13.9/32 [110/20] via 10.154.100.249, 00:00:05, FastEthernet0/0.100 O E2 10.154.13.8/32 [110/20] via 10.154.100.248, 00:00:05, FastEthernet0/0.100 ... rt-3620-b#sh ip route ... C 10.154.13.9/32 is directly connected, Loopback1 O E2 10.154.13.8/32 [110/20] via 10.154.100.248, 00:00:40, FastEthernet0/0.100 O E1 10.154.13.1/32 [110/21] via 10.154.100.253, 00:00:40, FastEthernet0/0.100 ...
Mouahhh c’est beau
- HSRP
Dernière étape et non la moindre, mise en place d’HSRP.
Le Hot Standby Router Protocol est un protocole propriétaire de Cisco que vous connaissez sûrement sous d’autres noms dans d’autres environnements comme VRRP ou (et surtout), CARP sous *BSD dont je vous ai souvent parler. (ICI ou LA)
Ce protocole permet de « partager » une IP Virtuelle qui sera affectée au routeur « Maitre ». En cas de panne de ce routeur, le routeur « Esclave » s’approprie cette adresse IP et reprend donc la continuité de service.
Pour une solution de continuité de service, c’est quand même ce qu’il se fait de mieux (qui a dit VSS au fond ? )
Nous allons configuré une interface de routage pour le Vlan 600, en 10.154.60.254 que se partageront le rt-3620-a, le Maître en 10.154.60.248 et le rt-3620-b, l’Esclave en 10.154.60.249 dans le groupe 10 (ce n’est qu’un identifiant pour HSRP et ses membres)
rt-3620-a(config)#int fa 0/0.600 rt-3620-a(config-subif)#encapsulation dot1Q 600 rt-3620-a(config-subif)#ip address 10.154.60.248 255.255.255.0 rt-3620-a(config-subif)#standby 10 priority 100 rt-3620-a(config-subif)#standby 10 ip 10.154.60.254 rt-3620-b(config)#int fa 0/0.600 rt-3620-b(config-subif)#encapsulation dot1Q 600 rt-3620-b(config-subif)#ip address 10.154.60.249 255.255.255.0 rt-3620-b(config-subif)#standby 10 priority 80 rt-3620-b(config-subif)#standby ip 10.154.60.254
On vérifie que ca ping :
Guiguiabloc-a:~# ping 10.154.60.254 PING 10.154.60.254 (10.154.60.254) 56(84) bytes of data. 64 bytes from 10.154.60.254: icmp_seq=1 ttl=255 time=1.44 ms 64 bytes from 10.154.60.254: icmp_seq=2 ttl=255 time=1.69 ms
Le traceroute me confirme le routeur Maître :
Guiguiabloc-a:~# traceroute 10.154.60.254 traceroute to 10.154.60.254 (10.154.60.254), 30 hops max, 40 byte packets 1 * 2 10.154.100.248 (10.154.100.248) 7.797 ms * *
Sur le rt-3620-b, on voit que l’interface est en attente :
FastEthernet0/0.600 is up, line protocol is up Internet protocol processing disabled
Ne reste qu’a couper l’interface pour avoir une bascule transparente
rt-3620-a(config)#int fa 0/0.600 rt-3620-a(config-subif)#shut Guiguiabloc-a:~# traceroute 10.154.60.254 traceroute to 10.154.60.254 (10.154.60.254), 30 hops max, 40 byte packets 1 * 2 10.154.100.249 (10.154.100.249) 7.705 ms
Magique
Voila donc en « quelques » lignes une approche de diverses techonologies que vous croiserez sûrement dans un LAN d’entreprise.
Il est évident qu’a petite échelle c’est un régal a mettre en place, sur une grosse infra, on est beaucoup plus enclin a réfléchir avant d’appuyer sur la touche « entrée »…
Espérant avoir titiller votre fibre réseau, amusez vous bien
Call me, call me, any, anytime
par guiguiabloc le 22 sept, 2009, sous geekerie, matériel
Bon effectivement, la génération qui n’a pas connu Blondie risque d’être un peu étonné par le titre de ce billet (« C’est quoi ça ??? » réponse ICI )
En même temps, c’est un peu plus « In » que mes précédentes allusions à Carlos et Pierre Perret…
Bref, un titre de billet un peu capilotracté pour vous parler de téléphone portable.
En avril de l’année dernière, je vous avais fait part de mon acquisition d’un Nokia e65 qui m’avait donné grande satisfaction jusqu’à ces dernières vacances…
En effet, si vous mélanger ça :
Eh ben vous obtenez ça :
(Désolé pour la qualité bien pourrie de la photo…)
Donc non, le Nokia E65 n’est pas « Voltige Compliant © »…
Il me fallait donc le remplacer, le e65 n’étant plus disponible au catalogue…
Sans geste commercial de la part de SFR (étonnant, non ? ), je me suis rabattu sur un catalogue d’entreprise auquel j’ai accès.
Bon la liste est petite (snif, snif, pas d’Androïd à disposition), et ayant fait le tour de l’OS SYMBIAN, j’ai décidé de tester le Blackberry, et plus précisement le Curve 8900 (aka Javelin).
Voici la bête :
Premier retour de test donc…
Je vous conseille TRES fortement de prendre l’option Blackberry (mail et/ou web) chez votre opérateur téléphonique, sans cela, votre BB ne sert à rien… (a part téléphoner, ce qui est quand même son but premier )
Le concept Blackberry est un peu bizarre a comprendre mais en gros, sachez que vous passer par une sorte de tunnel vers les Infras de RIM (a Londres pour l’europe) qui vous permet d’avoir par exemple, le « Push mail » sur votre mobile (les mails arrivent automatiquement sur votre BB).
L’option Data illimitée est plus que recommandée si vous ne voulez pas voir votre facture grossir à vue d’oeil (le Curve 8900 est très très bavard sur le réseau… entre le GPS, la synchro horaire etc…)
Côté applications, ce n’est pas le même monde que celui du Symbian, la vague Open Source est beaucoup plus discrète.
A voir ICI par exemple. En attendant que RIM, suite au rachat de Torch Mobile, nous offre un navigateur OpenSource.
Sinon, vous trouverez l’essentiel, Opera mini, Funambol pour vos synchros etc…
Sous Linux, aucun soucis, déjà le Blackberry est détecté en temps que mémoire de masse et pour les synchros et faire joujou avec, je vous conseille cet excellent billet :
http://www.progweb.com/modules/blackberry/index-fr.html
Les forums sont plutôt actif avec quelques bons liens si on prend le temps de les fouiller.
Bref, bilan un peu mitigé (le wifi est étroitement lié au réseau GPRS/EDGE via le BlackBerry Internet Service, et son fonctionnement un peu aléatoire).
Sinon, son utilisation est très agréable et dispose de l’essentiel pour s’en servir comme « bureau mobile ».
A bientôt
Mise en oeuvre d’un cluster Zimbra avec synchronisation multi-plateformes
par guiguiabloc le 07 août, 2009, sous geekerie, linux
Pour un projet, j’ai eu à réfléchir à une solution d’agendas partagés, synchronisable sur blackberry.
C’est donc un dimanche matin, avant de me vautrer comme une loutre sur le canapé la messe, que j’ai mis en place tout cela et j’en suis plutôt content.
En matière d’outil de collaboration, il existe plusieurs produits, achevés ou non, intéressants ou pas.
J’avais d’abord commencé par lorgner du côté de Kolab mais j’ai préféré choisir un outil que je connais bien et qui a fait largement ses preuves : ZIMBRA.
Inutile de vous présenter cette suite d’outils, leur réputation n’est plus a faire.
Maintenant, il me fallait rendre Zimbra hautement disponible et surtout, permettre de synchroniser les agendas et carnet d’adresses avec une multitude d’équipements (téléphone Blackberry, Symbian, Iphone etc…) mais aussi sur les PC sous Thunderbird/Lightning, Evolution voir même (pour les GENS sales), Micro$oft Windaube avec Proutlook (la version complète, pas caca express qui ne dispose pas de calendrier).
Donc du Zimbra a ma sauce, voila donc la mise en oeuvre d’un ZImbrabloc (guiguiabloc + zimbra … ok , je –> [] )
Pour la partie synchronisation, il me fallait quelque chose de solide, d’Open (forcément), utilisable avec Zimbra et une immense majorité de plateformes comme énoncé plus haut.
Ce service magique, je l’ai trouvé chez Funambol.
Comme toujours si vous ou l’un de vos collaborateurs un dessin valant mieux qu’un long discours, voici ce que je vous propose mettre en place :
Architecture ZimbraBloc
- Préparation de l’ip Failover, des DNS et des Serveurs
Si vous êtes chez OVH, c’est le moment d’activer votre IP Failover pour qu’elle pointe sur vos deux serveurs.
(Sinon, a vous de préparer votre VIP CARP ou UCARP si vous utilisez un autre système d’ip failover).
Relire mes précédents billet :
L’installation de Zimbra est triviale si l’on prépare en amont ses DNS. En effet, le serveur sur lequel vous installerez Zimbra doit être MX du domaine (l’installeur le vérifie).
collab.guiguiabloc.fr IN A 10.0.0.1 collab.guiguiabloc.fr MX 10 collab.guiguiabloc.fr zimbrabloc-1 IN A 10.10.10.1 zimbrabloc-2 IN A 10.10.10.2 zimbrabloc-1 MX 10 zimbrabloc-1 zimbrabloc-2 MX 10 zimbrabloc-2
Côté serveurs, prévoir :
Vos partitions / /home /tmp bref, comme vous avez l’habitude de faire
1 partition pour DRBD (tailler large…)
1 partition de quelques gigas juste pour l’installation de Zimbra, que l’on montera en /opt
- Installation de Zimbra, DRBD et Heartbeat
Je me suis basé sur l’excellent article de Mig5 :
http://www.mig5.net/content/howto-highly-available-zimbra-cluster-using-heartbeat-and-drbd
L’installation ce Zimbra sous DRBD demande une manipulation un peu tordue car Zimbra vérifie que la machine sur laquelle il s’installe est bien MX du domaine (en gros il interroge le DNS du domaine et check son /etc/hostname mais drbd vérifie que le /etc/hosts et le /etc/hostname de la machine sont bien identiques sinon il crie au loup.
Pour simplifier la manipulation, la technique est la suivante :
- installation de zimbra dans /opt (on monte notre petite partition en /opt)
Sur zimbrabloc-1 on change le /etc/hostname par collab.guiguiabloc.fr
On reboot, on installe Zimbra (téléchargeable ICI ) (si vous avez une erreur comme quoi le MX ne pointe pas sur la bonne ip (normal puisque l’on pointe sur une ip failover, passez outre et répondre Non au changement de domaine)
Je ne m’étend pas sur l’installation, très simple, et il existe multitude de tutos sur le nain ternet.
- on stoppe Zimbra, on remet le hostname comme il était (zimbrabloc-1)
- on supprime les entrées dans /etc/rc* (c’est Heartbeat qui gèrera l’arrêt/relance de Zimbra)
- on édite le /etc/hosts que l’on modifie ainsi :
Pour Zimbrabloc-1
127.0.0.1 collab.guiguiabloc.fr localhost 10.10.10.1 zimbrabloc-1 collab.guiguiabloc.fr 10.10.10.2 zimbrabloc-2
Pour Zimbrabloc-2
127.0.0.1 collab.guiguiabloc.fr localhost 10.10.10.1 zimbrabloc-1 10.10.10.2 zimbrabloc-2 collab.guiguiabloc.fr
On démonte /opt pour le monter en /mnt/trucmuche temporairement.
Côté serveurs, on se monte une « petite » partition en DRBD comme d’habitude, déjà expliqué dans ce billet.
Je vous passe la synchro et tout le bouzin de drbd, bref, vous devriez vous retrouver avec un /dev/drbd0 que l’on montera en /opt.
Ne reste qu’a copier l’integralité de votre /mnt/trucmuche dans votre nouveau /opt fraichement synchronisé.
(n’oubliez pas de virer l’entrée /etc/fstab…)
Vous installez heartbeat et vous renseignez vos /etc/ha.d/haresources pour basculer votre noeud :
zimbrabloc-1 IPaddrFO::10.0.0.1/32/eth0 drbddisk::r0 Filesystem::/dev/drbd0::/opt::ext3 zimbra MailTo::guiguibloc@guiguiabloc.fr::Bascule_Zimbra
NB: le script IPaddrFO est une modification du IPaddr dans lequel, outre la bascule de l’ipfailover d’une machine a une autre, je « pousse » via un script python, la mise à jour de l’ipfailover dans le manager d’OVH :
Le code a modifier :
case $2 in start) /home/system/zimbrabloc1-failoverupdate.py ip_start $1;;
Le script Python :
#!/usr/bin/python
from SOAPpy import WSDL
soap = WSDL.Proxy('https://www.ovh.com/soapi/ovh.wsdl')
nic = 'guiguiabloc-ovh'
password = 'weshgroscestmoi'
try:
session = soap.login( nic, password )
print "login successfull"
except:
print "Error login"
try:
result = soap.dedicatedFailoverUpdate( session, 'ns12345.ovh.net', '10.0.0.1', '10.10.10.1' );
print "dedicatedFailoverUpdate successfull";
except:
print "Error dedicatedFailoverUpdate"
try:
result = soap.logout( session )
print "logout successfull"
except:
print "Error logout"Je vous laisse rebooter, couper le zimbrabloc-1 et vérifier la bascule sur le zimbrabloc-2.
- Serveur de synchronisation Funambol
Funambol est une entreprise américaine qui propose deux types de licences, Commercial et OpenSource.
Sa force est d’offrir des clients de synchronisation pour quasiment tout ce qui est amené à se synchroniser à quelque chose un jour.
On attendait depuis longtemps le connecteur Funambol pour Zimbra, c’est chose faite :
http://sourceforge.net/projects/zimbrafunambol/
L’installation du serveur Funambol est d’une simplicité déconcertante (on l’installera dans /opt, a coté de notre ZImbra).
Par défaut, il écoute sur le port 8080, ce qui n’entrera pas en conflit avec l’interface web de Zimbra
(Bien évidemment, on passera tout cela en https avant d’ouvrir au public).
L’url de synchro sera donc :
http://collab.guiguiabloc.fr:8080/funambol/ds
(Vous pouvez vérifier que le serveur Funambol fonctionne parfaitement en pointant votre navigateur sur cette adresse)
Funambol Data Synchronization Server v.7.1.0 Man=Funambol Mod=DS Server SwV=7.1.0 HwV=- FwV=- OEM=- DevID=funambol DevTyp=server VerDTD=1.2 UTC=true SupportLargeObjs=true SupportNumberOfChanges=true Ext=X-funambol-smartslow
L’installation et le paramétrage du connecteur Zimbra sont parfaitement documentés :
http://wiki.zimbra.com/index.php?title=Open_Source_Mobile_Calendar_and_Contact_Synchronization
Un excellent tutorial en français (chapeau a son auteur, Jean-François VIAL, et surtout merci )
- Installation et test du client de synchro
Les téléchargements disponibles pour les diverses plateformes se trouvent ici :
https://www.forge.funambol.org/download/
Mon nokia e65, tournant sous Symbian fait bien sur partie des plateformes disponibles (Symbian )
Ici le couple Username/Password correspond au compte de l’utilisateur dans Zimbra.
Le serveur location sera : http://collab.guiguiabloc.fr:8080/funambol/ds
Un petit clic sur « Sync All » et le calendrier se synchronise. Magique
Les paramétrages de synchro sont modifiables (dans 1 sens ou dans les 2 sens, désactivation de la synchro des contacts etc…)
Au final, nous avons mis en place un système collaboratif en haute disponibilité, accessible en Web synchronisable par Client lourd, par téléphone portable etc…
L’agenda partagé est un outil devenu indispensable dans les entreprises.
Offrir ce type de service, qui permet de tenir son calendrier a jour, de le consulter ou que l’on soit, par plusieurs moyens différents, tout en étant certain de la disponibilité du service, c’est quand même pas mal, non ?
A vous de vendre cela a votre DG/PDG/DRH qui vous regardera les yeux humides d’émotion de répondre à l’une de ses problématiques (et accessoirement vous gratifiera d’une tape sur l’épaule avec un « beau travail » en oubliant de vous offrir une augmentation…)
Amusez vous bien
