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

Lors de chaque connexion a mes machines Linux depuis RoyaTSx, ce message « LC_CTYPE: cannot change locale (UTF-8): No such file or directory » apparaissait à la connexion, mais aussi a l’exécution de chaque script.
Pour se débarrasser de celui-ci il faut aller dans la configuration par defaut du plugin iTerm2 :
RoyalTSx - 1

Et décocher la case suivante :
« Set locale variables automatically »
RoyalTSx - 2

A la prochaine connexion sur une de vos machines cela devra être bon.

Préambule

Il est possible dans Zimbra de signer/encrypter ses messages grâce a la Zimlet disponible dans le version Network. Une autre Zimlet utilisant PGP est disponible mais je ne vais pas utiliser celle-ci pour la suite de cet article.

Dans mon cas j’aimerai signer et surtout encrypter mes mails a destination des personnes de mon entreprise, sans avoir a récupérer la clef publique de tous les utilisateurs. L’idée ici est donc d’utiliser l’annuaire pour stocker les clefs publiques de mes utilisateurs.

Cela peut être fait de deux façon, soit en passant par un annuaire externe qui contient les utilisateurs et leurs certificats (on imagine très bien un Active Directory par exemple), ou bien en injectant directement dans Zimbra la clef publique.

Je vais expliquer la deuxième option, car je suis en attente de mon matériel pour faire un lab digne de ce nom et n’ai que très peu de mémoire sur mon portable pour faire tourner convenablement un OpenLDAP/AD plus Zimbra.

Scénario

Le scénario est le suivant :

Users :

  • User1@demo.local
  • User2@demo.local

Zimbra version 8.5 (fonctionne aussi en 8.0)

Generation du certificat

Le certificat doit etre au format DER comme expliqué dans ce bug de Zimbra.

On va donc générer le certificat ainsi qu’une clef privée par utilisateur. Dans votre cas il est préférable de vous appuyer la clef privée de votre PKI d’entreprise plutôt que de créer une clef par utilisateur.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout user1.key -out user1.crt
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout user2.key -out user2.crt

export de la clef au format DER :

openssl x509 -in user1.crt -outform DER -out user1.der
openssl x509 -in user2.crt -outform DER -out user2.der

Et enfin export de la clef au format PKCS12 pour import dans le navigateur de l’utilisateur

openssl pkcs12 -export -out user1.p12 -in user1.crt -inkey user1.key
openssl pkcs12 -export -out user2.p12 -in user2.crt -inkey user2.key

Transferer-les sur votre serveur Zimbra avec votre outil preferé puis importez les dans chaque compte avec la commande suivante :

su - zimbra
zmprov ma user1@demo.local userCertificate /tmp/user1.der
zmprov ma user2@demo.local userCertificate /tmp/user2.der

Enfin,on regénère la GAL pour que le changement soit effectif de suite.

su - zimbra
zmgsautil forceSync -a galsync.@demo.local -n InternalGAL (valeur par default à adapter à votre environement)

Import du certificat dans le navigateur (ici Firefox)

Maintenant que coté serveur on a les certificats dans l’annuaire, il faut maintenant que l’utilisateur importe son certificat dans le navigateur. Pour Firefox il faut faire comme suit :

  1. Dans les preferences de Firefox cliquer sur Advanced -> Certificates -> View certificates
  2. Puis on clic sur import
  3. et enfin on choisi son certificat.

Zimbra-SMIME-1

On pourrais croire que c’est fini mais non. La Zimlet s’appuyant sur Java, il faut aussi intégrer le certificat dans le keystore de Java.

Import du certificat dans le Keystore Java

On lance donc le panneau de commande Java puis :

  1. On clic sur security -> Manage certificate
  2. Puis import et on importe le certificat

Zimbra-SMIME-2

A partir de cet instant, on peu envoyer des messages signés a des destinataires inconnu et aussi envoyer des mails cryptés aux utilisateurs de la plateforme Zimbra (ici un screenshot de l’annuaire global) :

Zimbra-SMIME-3

Et la l’envoi du mail crypté :

Zimbra-SMIME-4

Easy !

PS : N’oubliez pas d’activer la zimlet smime sinon rien de tout cela fonctionne…

Cet article est petit pense bête qui permet de creer les fichiers de demarrage de Saltstack sur Macosx

Création du daemon Saltstack sur MacOSX

Saltstack fourni un executable qui permet de générer le fichier de démarrage. On le lance comme suit :

 sudo salt-run launchd.write_launchd_plist salt-master<?xml version="1.0" encoding="UTF-8"?>
 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.saltstack.salt-master</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/python</string>
        <string>/usr/local/bin/salt-master</string>
    <string>--log-level=all</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Le souci avec cette commande, c’est qu’elle ne detecte pas le bon path the l’executable, il s’agit d’un bug référencé. Il faut donc le modifier à la main avant de créer le fichier :

sudo vim /System/Library/LaunchDaemons/salt-master.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.saltstack.salt-master</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/bin/python</string>
        <string>/usr/local/bin/salt-master</string>
       <string>--log-level=all</string> <= si vous voulez augmenter la verbositédes logs
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>
 

on verifie que la syntaxe est correct :

sudo plutil -lint /System/Library/LaunchDaemons/salt-master.plist

puis on load le lanceur dans launchd :

sudo launchctl load /System/Library/LaunchDaemons/salt-master.plist

et enfin on lance l'executable :

sudo launchctl start org.saltstack.salt-master

Et pour le minion il suffi de repeter l'operation avec l'executable salt-minion

Références :
Documentation officielle
Documentation apple

Installation de SaltStack depuis Git

Afin de provisionner dans vSphere avec Saltstack, il faut utiliser la branche de developpement.

On commence donc par un git clone :

git clone https://github.com/saltstack/salt.git

Une fois cela fait, on se déplace dans le répertoire nouvellement créé par le git, puis on installe les prérequis. Comme les développeurs de Saltstack sont des mecs (peut être des filles aussi) sympas, ils fournissent des fichiers de prérequis. Il suffi donc de le donner a manger a pip :


sudo pip install -r _requirements.txt <= prerequis SaltStack
sudo pip install -r cloud-requirements.txt <= prerequis Salt-Cloud
sudo pip install -r zeromq-requirements.txt <= prerequis SaltStack
sudo pip install -r dev_requirements_python26.txt <= prerequis SaltStack
sudo pip install -r dev_requirements_python27.txt <= prerequis SaltStack

Puis on lance l’installation :
sudo python setup.py install
Enfin, on verifie que le salt-master est up-to-date :

salt-master --version
salt-master 2014.7.0 (Helium)

Ok, une fois Saltstack a la dernière version, on va s’attaquer à la partie la plus compliquée. Pourquoi compliquée ? Car autant les documentations de Saltstack sont complètes, autant celle concernant vSphere est inexistante et le peu qui existe contient des erreurs…

Je ne reviendrai pas sur la partie configuration du master et connexion des minions car tout ça est expliqué dans la documentation. Je vais me concentrer sur les modifications à apporter pour pouvoir provisionner dans vSphere.

Environnement

Mon environnement est le suivant :

Salt: 2014.7.0
Python: 2.7.5 (default, Mar 9 2014, 22:15:05)
Jinja2: 2.7.3
M2Crypto: 0.22
msgpack-python: 0.4.2
msgpack-pure: 0.1.3
pycrypto: 2.6.1
libnacl: Not Installed
PyYAML: 3.11
ioflo: 0.9.39
PyZMQ: 14.3.1
RAET: Not Installed
ZMQ: 4.0.4
Mako: 1.0.0
Apache Libcloud: 0.15.1

OS : MacOSX
VSphere version : 5.1

Configuration

Cloud Provider

Afin de provisionner dans des environement de type « cloud », Salt s’appuie sur des fichiers de configurations se situant dans le dossier suivant /etc/salt/cloud.providers (celui-ci est a creer).
Il est evident que l’on peut stipuler plusieurs providers et donc provisionner des machines dans n’importe quel « cloud » avec les memes states.
Je vais donc creer mon provider comme ceci :

/etc/salt/cloud.providers.d/vsphere.conf
my_provider:
   provider: vsphere
   user: 'administrator'
   password: 'My_Password'
   url: 'https://vcenter.domaine.tld/sdk'  <= attention ici, cela depend de la version du vcenter ainsi que de votre implementation. Je vous invite a aller sur le ce bug pour voir les différentes possibilités de configuration.

Puis redemarrer le salt-master.
A partir de ce point, on peut se connecter a notre vsphere et lister par exemple les templates mis a disposition :

sudo salt-cloud --list-images=all
Password:
[INFO ] salt-cloud starting
my_provider:
    ----------
    vsphere:
        ----------
        Centosx64:
            ----------
            Name:
                Centosx64
        Windows2k8r2:
            ----------
            Name:
                Windows2k8r2

Maintenant que l’on peut lister, on va provsionner 🙂

Provsionning

Cloud Profiles

Par defaut Salt va regarder les profiles de machines auquel il a accès dans le fichier suivant /etc/salt/cloud.profiles.
Pour ma part n’ayant que deux templates, je n’ai créé que deux profiles :

centos_vsphere:
   provider: les-titans
   image: Centosx64
   folder: Production
   resourcepool: resgroup-47
windows_vsphere:
   provider: les-titans
   image: Windows2k8r2
   host: cloud-02.domain.tld
   folder: Saltstack
   datastore: Datastore-02

Je ne vais pas m’étendre sur les options car elles sont toutes expliquées et bien documentées dans le fichier /Library/Python/2.7/site-packages/pysphere/vi_virtual_machine.py » a partir de la ligne 402. Le seul souci est la détection du MOR, c’est l’objet géré par vSphere via son API. Pour l’instant Salt-Cloud n’arrive pas a retrouver le MOR du resourcePool et uniquement de celui-ci (ne me demandez pas pourquoi).
Il faut donc aller se palucher la récupération de cette information a la main comme expliqué dans ce bug.

Enfin, on va pouvoir provisionner une ou plusieurs machines dans notre vSphere comme ceci ( en parallèle ou non, man salt-cloud 😉 ) :

sudo salt-cloud -p centos_vsphere web1
[INFO ] Creating Cloud VM web1 web2 web3
...
[DEBUG ] clone_kwargs are set to {'datastore': None,
'folder': 'Saltstack',
'host': None,
'name': 'web1',
'resourcepool': 'resgroup-47',
'template': False}
[DEBUG ] VM web1 is created, waiting for it to boot
[DEBUG ] Attempting function

Et voila, la ou les machines sont créés \o/ . Maintenant le Salt-Master va essayer de se connecter afin d’installer le salt-minion et intégrer les machines dans son trousseau Une fois cela fait, il ne reste plus qu’à balancer ses services dessus. Si c’est pas beau la vie !

Dans un autre article je vais expliquer comment créer des maps, ce qui permettra de provisionner un groupe de machines afin de monter rapidement des POC ou des infrastructures en un minimum de temps.

Références :
Cloud Profiles
Cloud Providers

 

Depuis longtemps maintenant j’utilise Metamorphose pour renommer mes fichiers de façon massive. Même si le projet n’est plus maintenu, je n’ai pas trouvé de remplaçant à celui-ci (j’ai pas cherché non plus 🙂 ).

De plus j’ai changé de boulot récement et l’on m’a attribué un macbook, cela complique donc la tâche car le logiciel n’est disponible qu’en binaire pour Windows et certaines distributions de Linux.

Prérequis

Avant toute chose, on va verifier que python est bien installé et si oui quel version on utilise. Donc on sort un terminal et :

python --version
Python 2.7.5

Normalement Python est installé par défault, mais sait on jamais.
Metamorphose necessite aussi deux autres dependances PIL et wxPython (v2.8)

PIL

sudo easy_install --find-links http://www.pythonware.com/products/pil/ Imaging

wxPython

Pour celui-ci il faut se rendre sur le site et telecharger la version qui correspond a votre version de Python. Puis l’installer de façon standard car il inclus un installer.

Installation

On telecharge les sources puis on les extrait. Une fois dans le dossier, lancer la commande suivante :

sudo make all

Comme l’installateur ne detecte pas que c’est un mac il simule un Linux, l’installation n’est pas effectué jusqu’au bout. Il faut faire quelques changement :

Interface en français

sudo cp messages/fr/LC_MESSAGES/metamorphose2.mo /usr/share/locale/fr/LC_MESSAGES/

utilisation de python 32 bits

Metamorphose fonctionne en 32 bits, il faut juste changer le lanceur (script shell) afin de specifier quel version utiliser. Pour ça on modifie le fichier /usr/bin/metamorphose2 et on ajoute l’occurence en gras :

...
PREFIX=/usr
 MAIN=
 export VERSIONER_PYTHON_PREFER_32_BIT=yes
#findPrefix
 if [ -x /bin/rpm ];then
...

Après ça on peut enfin lancer le logiciel.

Histoire de fignoler, vous pouvez suivre ce tuto afin de creer un lanceur personalisé.