Cela faisait longtemps une éternité que je n’avais pas écrit un billet.
Je profite d’avoir enfin un peu de temps pour le faire.

J’était tombé sur l’article de Jorge permettant de créer des comptes de démonstration sur Zimbra en utilisant un script.
Hormis le fait que Zimbra propose déjà cette option par défaut :

zmprov createBulkAccounts(cabulk) {domain} {namemask} {number of accounts to create}

le fait de passer par un fichier intermédiaire et de devoir modifier le script pour l’adapter rend la solution, a mon sens, pénible.
Lire la suite de

J’ai récemment été confronté à un problème. Je souhaitais connecter un Pfsense à un VPN Cisco.
Apres avoir glané pas mal d’informations sur le web, j’ai compris que cela n’allait pas être facile puisque les paquets permettant la connexion ne sont pas inclus dans Pfsense.
Pour se connecter au Cisco on va utiliser un utilitaire : Openconnect. Par défaut il n’est pas installé dans Pfsense, on va donc l’installer.
Le souci c’est que la version de Pfsense que j’utilise (la 2.1.5) est basée sur un FreeBSD 8.3. Hors le paquet officiel précompilé est pour la version 8.4 de FreeBSD. J’ai quand même essayé de l’installer :

pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openconnect.tbz
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/Latest/openconnect.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/vpnc-scripts-20130311_1.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/libiconv-1.14_1.tbz... Done.
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8-stable/All/libxml2-2.8.0_3.tbz... Done.

A priori tout a l’air bon.
Afin que la commande soit disponible directement depuis la shell on utilise la commande rehash
A partir de maintenant vous pouvez déjà vous connecter via la commande openconnect.

openconnect --background --user=USERNAME --no-cert-check vpn.domain.tld

Openconnect va directement faire appel à vpnc et créer l’interface tun pour vous. Si vous voulez gérer cette interface via l’interface web de Pfsense, vous n’allez pas pouvoir. En effet un filtre s’applique à toutes les interfaces de type tun. Il faut donc renommer l’interface une fois que le vpn est connecté. Et pourquoi seulement après ? Car Openconnect n’accepte pas des interfaces de connexion différentes de tunX (hard codé dans le logiciel).
On peut donc renommer l’interface comme ceci :
ifconfig tun8 name ovpnc8
elle apparaitra donc dans l’interface et vous pourrez la gérer et l’affecter a une interface dans Pfsense.

Ok, maintenant on va rendre tout cela automatique via un script et le positionner dans la cron :

 #!/bin/sh
 #Variable to adjust
 HOSTPING=HOST_TO_PING
 HOSTPVN=VPN_ADDRESS
 USER=wolfyxvf
 PASS=strongpassword
 INITTUN=tun8
 NAMETUN=ovpnc8
 #Tools
 PING='/sbin/ping'
 IFCONFIG='/sbin/ifconfig'
 OPENCONNECT='/usr/local/sbin/openconnect'
 DATE=`date`
 PINGRES=`$PING -c 2 $HOSTPING`
 PLOSS=`echo $PINGRES : | grep -o '[0-9][0-9][0-9].[0-9]% packet loss' | cut -f1 -d%'`
 echo "$DATE : Loss Result : $PLOSS"
 if [ "100.0" = "$PLOSS" ];
 then
 echo "$DATE : Deleting Old Interface : $NAMETUN"
 $IFCONFIG $NAMETUN down
 $IFCONFIG $NAMETUN destroy
 echo "$DATE : Creating Interface : $INITTUN"
 $IFCONFIG $INITTUM create
 $IFCONFIG $INITTUM up
 echo "$DATE : Starting : $NAMETUN"
 echo -n $PASS | exec $OPENCONNECT --background --interface=$INITTUN --user=$USER --no-cert-check $HOSTPVN
 echo "$DATE : Renaming Interface : $INITTUN to $NAMETUN"
 $IFCONFIG tun8 name ovpnc8
 echo "$DATE : Now running : $NAMETUN"
 else
 echo "$DATE : Already running"
 fi

Puis on le met dans la cron de root :

crontab -e
*/10 * * * * /root/openconnect-vpn.sh >> /var/log/openconnect_pinger.log 2>&1

Petite note :

J’ai eu un souci lors du montage du VPN. Celui-ci me modifiait mon resolv.conf. Etant donné mon installation je ne souhaitais pas que cela arrive, j’ai donc mis en place un flag immutable

chflags schg /etc/resolv.conf

References :

  1.  : Installation des paquets FreeBSD sur Pfsense
  2. : Interface tun non disponible dans l’interface Pfsense
  3. : Script d’automatisation du VPN

A chaque version de Zimbra, de nouvelles fonctionnalités apparaissent sans que l’annonce soit faite.
Dans la version 7 de Zimbra, deux scripts ont fait leurs apparitions : vmware-appmonitor et vmware-heartbeat.
Le premier est l’exécutable développé par VMware permettant le dialogue avec l’hôte physique grâce aux vmware tools, le second est, quant à lui, un script de vérification applicatif. Dans notre cas celui-ci vérifie que les composants de Zimbra fonctionne correctement.
Si ceux-ci sont « OK » alors, le script renvoi à vSphere le statut « OK » via l’applicatif vmware-appmonitor.
Si un des services critique est « KO » alors le script renvoi l’erreur au vSphere qui au bout de 3 fois (paramétrage par défaut), redémarre la machine.

Attention, ne pas mettre en production ceci est à des fins de tests !

Mise en place

Dans un premier temps, vérifiez que votre cluster vSphere comprend bien l’option de surveillance d’application.

Puis connectez-vous a votre serveur Zimbra et exécutez les commandes suivantes :

1. sed -i -e '146 s/^/#/' -e '145 s/^#//' /opt/zimbra/libexec/vmware-heartbeat

2. echo "export LD_LIBRARY_PATH=/opt/zimbra/lib" >> /opt/zimbra/.bashrc

Explication

1. Par défaut le script de check retourne en permanence OK au vSphere, on modifie donc celui-ci pour qu’il exécute zmcontrol et retourne la bonne valeur.

2. Lorsque l’on exécute le scipt en tant qu’utilisateur Zimbra, celui-ci n’a pas le chemin vers les dépendances. On ajoute donc le chemin dans le PATH.

On peut maintenant lancer le script.

su - zimbra

/opt/zimbra/libexec/vmware-heartbeat start

Si l’on veut suivre l’exécution du script, on peut regarder dans /opt/zimbra/log/vmware-heartbeat.log. Si tout ce passe bien, alors vous aurez quelque chose comme ça :

Fri Jul  6 20:10:16 2012: Checking ZCS status
Fri Jul  6 20:10:25 2012: Sending heartbeat to VM

Nous allons provoquer un arret de service de Zimbra :
su - zimbra
ldap stop

Dans le fichier de log vous verrez que le service ne retourne rien, c’est au bout de trois fois que le script renvoi au vSphere de redémarrer la machine.

Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Mon Jul  9 01:37:47 2012: Checking ZCS status
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Mon Jul  9 01:38:12 2012: Checking ZCS status
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.

Au niveau du vSphere vous aurez l’erreur suivante :

Et le serveur sera redémarré dans la foulée !

Cette fonctionnalité est intéressante, mais n’est pas encore mure. En effet, elle vérifie l’intégralité  des services via la commande zmcontrol, celle-ci est relativement longue et c’est pour cela qu’elle est commenté dans le script d’origine.

Ce script nous montre un bout de ce que sera la prochaine version de Zimbra.