Tag Archives: Debian

Déploiement automatisé et sans effort d’un webserver avec Foreman

L’objectif de ce post est de montrer le niveau d’industrialisation pour le déploiement d’application sur des machines virtuelles que nous apporte Foreman à Yakaz.

Cette vidéo montre comment très facilement nous pouvons créer une nouvelle machine virtuelle et comment puppet configure de manière automatisé le serveur pour faire tourner notre application. Nous utilisons la notion de Compute Resource qui arrive avec Foreman 1.0.

Comparés à l’ancien support de la virtualisation (les hypervisors cf précédent article), les Computes Resources permettent de :

  • Déployer des VM avec plusieurs disque et interfaces réseaux
  • Avoir une console VNC directement depuis l’interface de Foreman 
  • De contrôler qui peut utiliser quelle compute resource : ceci permet d’avoir un cluster de virtualisation pour l’environnement de dévelopement où n’importe qui peut déployer des VM et un cluster de production isolé.
  • Support de la gestion de l’alimentation de la VM directement dans Foreman 
  • Suppression de l’host dans Foreman supprime maintenant aussi la VM sur l’hyperviseur
Les computes resources supportées pour l’instant par Foreman sont : 
  • oVirt / RHEV-M
  • libvirt
  • Amazon EC2
  • support partiel de VMware
Pour rappel, lors d’un déploiement en ‘Unattended Installation’, Foreman s’occupe de :
  • Créer les enregistrements A et PTR pour le domaine
  • Créer la lease DHCP pour la machine
  • Configurer puppet pour la machine via les ENC
  • Signer le certificat client puppet de votre nouvelle VM dans la PuppetCA de votre puppetmaster
Voir ces billets part1 part2 part3 pour le déploiement de Foreman.
Une fois la VM créée et buildée puppet va configurer la machine afin qu’elle soit conforme à l’environnement d’exécution de l’application sélectioné (en l’occurence nos serveurs Web avec notre site)

Cette vidéo vous montre que notre temps humain nécessaire au déploiement d’un nouveau serveur à été drastiquement réduit en misant sur l’intégration de Foreman dans notre architecture. Cette approche nous apporte une forte fléxibilité et élasticité dans la gestion de notre production.

 

Share

Vérifiez le run de vos Puppet avec Foreman et Nagios

J’avais besoin de m’assurer de la fiabilité des runs de Puppet sur l’ensemble de ma production. Pour cela il faut m’assurer de 2 choses :

- Premièrement que puppet s’exécute correctement toute les demi-heure (j’utilise un cron et non pas le daemon puppet) . Pour cela, c’est assez simple, j’utilise un check nagios de base « check_file_age » et je vérifie l’âge du fichier « state.yaml ». Voici donc à quoi ressemble ma commande sur un serveur Debian:

/usr/lib/nagios/plugins/check_file_age -w 3780 -c 43200 -f /var/lib/puppet/state/state.yaml

- La première commande me permet de savoir que Puppet tourne bien régulièrement. Cependant je suis incapable de dire si les runs s’effectuent correctement ou non. C’est pourquoi  j’ai décidé d’utiliser la fonction de Reports de Foreman (voir ces 3 billets 1 2 3 pour l’installation de Foreman).

Vous pouvez trouver mon script içi sur Github. Pour l’utiliser sur un serveur Debian, il faut installer les dépendances (dont une qui n’est pas packagée en deb) :

# apt-get install libhttp-server-simple-perl libjson-perl
# wget http://search.cpan.org/CPAN/authors/id/M/MC/MCRAWFOR/REST-Client-243.tar.gz
# tar xvf REST-Client-243.tar.gz
# cd REST-Client-243
# make
# make install

Ensuite pour l’utiliser c’est très simple :

$ /usr/lib/nagios/plugins/check_foreman_puppet_failure.pl -H webserver.example.com -F http://foreman.example.com -w 3 -c 5 -u username -p password

Cette commande va vérifier les derniers rapports d’exécution de Puppet. Si le nombre de run en erreur est supérieur à warning ou critical alors le check retournera une erreur.

Voila, vous pouvez superviser correctement vos runs de Puppet grâce à Foreman et Nagios

Share

Problème de désinstallation de package python avec pip sous Debian

Juste un tout petit billet pour avertir les personnes ayant des soucis pour désinstaller un package python sous Debian Squeeze.

Si vous avez installé celui-ci avec pip vous risquez de ne pas pouvoir le désinstaller.

Si  

 #pip uninstall $package_name 

vous confirme la bonne suppression du package mais que

 #pip freeze 

continue à vous afficher le paquet comme installé alors vous tombez sur le même bug que moi (voir bugtracker de Debian).

La solution que j’ai choisi est de backporter le package Debian de python-pip.

# wget http://ftp.de.debian.org/debian-backports/pool/main/p/python-pip/python-pip_1.0-1~bpo60+1_all.deb
# dpkg -i python-pip_1.0-1\~bpo60+1_all.deb

Vous ne devriez plus avoir de problème !

Share

Protégez votre Google Apps avec LemonLDAP::NG grâce à SAML2 !

Après avoir vu comment protéger efficacement votre infrastructure en mettant en place en WebSSO reposant sur une authentification à 2 facteurs, voyons maintenant comment protéger votre Google Apps avec LemonLDAP::NG.

Si vous ou votre entreprise à pris le parti de déléguer la gestion de vos e-mail à Google vous avez toujours la possibilité d’intégrer ces services Web à votre SSO LemonLDAP::NG grâce à la prise en charge du protocole SAML2. Dans ce cas de figure la Google Apps se positionera en tant que fournisseur de service SAML.

Une communication se faisant entre Google et LL::NG, votre SSO doit bien entendu être accessible sur Internet.

Ce billet n’a pas pour vocation de décrire la mise en place d’une Google Apps, veuillez vous rapporter à la documentation de Google si nécessaire.

Il est à noter que cette installation est possible avec n’importe quel type de Google Apps même la version gratuite !

Installation des dépendances

Pour utiliser le protocole SAML, LL::NG utilise la librairie perl lasso qui n’est pas packagée en standard sous Debian.  Pour l’installer (les repos sont compatibles avec squeeze) :

# vim /etc/apt/source.list.d/entrouvert.list
deb http://deb.entrouvert.org/		lenny	main
deb-src http://deb.entrouvert.org/	lenny	main

# wget -O - -q http://deb.entrouvert.org/entrouvert.gpg | apt- key add -
# apt-get update
# apt-get install liblasso3-perl
# service apache2 restart

Configuration de LemonLDAP::NG

Dans le manager de LL::NG :

  • Paramètre généraux => Modules fournisseur => SAML => Activation : Activé
  • Service SAML2 =>  Format de NameID => Email : mail
  • Service SAML2 => Paramètres de sécurité =>  Signature =>  Clé privée => Générer
  • Service SAML2 => Paramètres de sécurité => Chiffrement => Clé privée => Générer
  • Service SAML2 => Organization => Nom affiché / Nom / URL (pour informations)
Il faut ensuite ajouter un fournisseur de service SAML :
    • Fournisseurs de service SAML => Nouveau fournisseur de service
    • Fournisseurs de service SAML => Votre_Service => Metadata



urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddres

Attention à modifier le CHANGE_ME !

  • Fournisseurs de service SAML => Votre_Service > Options => Réponse d’authentification => Format par défaut du NameID : Email
  • Fournisseurs de service SAML => Votre_Service > Options => Signature : Tout doit être désactivé sauf « Signature des messages SSO »
Enfin il vous faut créer un certificat reconnu par Google pour l’échange SAML :
  • Service SAML2 => Paramètres de sécurité =>  Signature =>  Clé privée =>  Télécharger ce fichier (lemonldap.key)
$ openssl req -new -key lemonldap.key  -out lemonldap.csr
$ openssl x509 -req -days 3650 -in lemonldap.csr -signkey lemonldap.key -out lemonldap.pem

Configuration du SSO sur la Google Apps

Connectez vous à l’interface d’administration avec un compte Super-Utilisateur (Adresse http://www.google.com/a/CHANGE_ME)

Dans Outils Avancés => Mise en place du SSO :

  • Cochez Activer l’authentification unique
  • URL de la page de connexion : http://auth.changeme.com/saml/singleSignOn
  • URL de la page de déconnexion : http://auth.changeme.com/?logout=1
  • URL de la page de modifications du mot de passe :  http://auth.changeme.com
  • Certificat de vérification : envoyez le certificat généré précédemment (lemonldap.pem)

Connexion à la Google Apps

Vous devriez avoir fini l’intégration de votre Google Apps avec LemonLDAP::NG. Lors de l’accès à celle-ci vous devriez être automatiquement redirigé vers LL::NG si vous n’avez pas de session active, sinon vous êtes automatiquement connecté.

En cas de problème, vous pouvez toujours vous authentifier sur votre Google Apps via l’URL http://www.google.com/changeme.com

Remarques

Pour que le SSO fonctionne, il faut que l’attribut mail exporté par votre annuaire soit présent dans votre Google Apps. Nous verrons dans un prochain billet comment synchroniser votre Google Apps avec votre annuaire en utilisant Google Apps Directory Sync.

Share

Installation de pam-ldap avec Google Authenticator

Nous avons vu dans les précendents articles : Découverte Google Authenticator et Installation de Freeradius avec Google Authenticator comment commencer à mettre en place notre solution de « 2-factor authentication ».

Nous allons aborder dans cet article un sujet relativement mieux traité sur internet : la mise en place de la du module PAM LDAP.

Installation de PAM LDAP

On commence tout d’abord à installer le module PAM LDAP.

# apt-get install libnss-ldap libpam-ldap

Debconf va vous demander plusieurs fois pour configurer /etc/pam_ldap.conf et /etc/libnss-ldap.conf

  • L’URI de votre annuaire
  • Votre base DN
  • La version du protocole à utiliser v3 / v2
  • Le DN d’un utilisateur admin de votre annuaire
  • Son mot de passe

Il vous reste maintenant à définir dans /etc/nsswich.conf les formats files et ldap :

passwd:         ldap files
group:          ldap files

Voila, en tapant un simple « # getent passwd » vous devriez avoir vos utilisateurs systèmes et ldap qui s’affichent si ceux-ci ont l’objectClass posixAccount.

Il vous suffit enfin de compléter la configuration de votre module PAM radiusd :

# cat /etc/pam.d/radiusd
auth required pam_google_authenticator.so forward_pass
auth sufficient pam_ldap.so use_first_pass
auth sufficient pam_unix.so use_first_pass

Vous devriez pouvoir tester avec succès l’authentification d’un utilisateur LDAP avec la commande radtest (voir billet précédent).

Il ne vous reste plus qu’à aller voir la configuration de LemonLDAP::NG pour avoir un WebSSO avec une authentification à 2 facteurs.

Share

Installation de Freeradius avec Google Authenticator

Afin de mettre en place LemonLDAP::NG avec une double authentification LDAP + OTP nous allons devoir installer Freeradius. En effet LemonLDAP::NG ne supporte pas pour le moment PAM comme backend direct d’authentification.

 (Ré)Installation de Google Authenticator

Si vous avez suivi ce billet, vous avez certainement installé le paquet de Google Authenticator de Debian. Malheureusement celui-ci n’est au moment où j’écris ces lignes pas assez à jour pour être utilisé avec Freeradius : il ne gère pas les applications ne supportant pas les challenges.

Nous allons donc désinstaller le paquet et installer le projet depuis les sources.

# apt-get remove lib-pam-google-authenticator
# apt-get install libpam0g-dev gcc make mercurial
# hg clone https://code.google.com/p/google-authenticator/
# cd google-authenticator/libpam
# make
# make test
# make install

Installation de Freeradius

Ne pouvant pas utiliser directement PAM comme mécanisme d’authentification, nous allons passer par Freeradius qui s’appuiera lui même sur PAM.

# apt-get install freeradius

Pour fonctionner avec le module PAM de Google Authenticator, Freeradius a besoin d’un tout petit peu de configuration.

Dans ‘/etc/freeradius/radiusd.conf’, il faut demander à Freeradius de s’éxecuter en tant que root:root à la place de freerad:freerad:

user = root
group = root

Dans ‘/etc/freeradius/users, on va définir PAM comme méthode d’authentification par défaut :

DEFAULT   Auth-Type := PAM

Dans le default site de Freeradius, décommentez la ligne pam dans la section ‘authenticate’ :

authenticate {
<.../>
        pam
<.../>
}

Il nous faut maintenant aller modifier le fichier ‘/etc/pam.d/radiusd’ pour obtenir :

auth    requisite       pam_google_authenticator.so forward_pass
auth    required        pam_unix.so use_first_pass

Test de l’installation de Freeradius

En prérequis il vous faut un utilisateur système ayant un fichier .google_authenticator dans son home.

Ensuite on va utiliser l’outils radtest :

#radtest myuser userpwdOTP localhost 18120 testing123

ATTENTION : Notez bien que le mot de passe à fournir à radtest est le password UNIX de l’utilisateur et son OTP concaténés !

Vous devriez obtenir quelque chose comme ceci :

# radtest toto totopasswd966037 localhost 18120 testing123
Sending Access-Request of id 0 to 127.0.0.1 port 1812
        User-Name = "toto"
        User-Password = "totopasswd966037"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 18120
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=0, length=20

En cas de problème vous pouvez toujours relancer Freeradius en mode Debug. Attention vous allez voir passer les mots de passe en clair dans les logs de debug de Freeradius :

# service freeradius stop
# freeradius -X

Voila ! Votre Freeradius peut maintenant utiliser PAM pour fonctionner. Nous allons passer dans l’article suivant sur la configuration de PAM + LDAP + Google Authenticator.

Share

Compilation des paquets Debian pour LemonLDAP::NG

Petit article pour expliquer comment compiler facilement les paquets Debian pour LemonLDAP::NG. Je passe pour l’instant par la compilation du trunk car le backend d’authentification Radius de LemonLDAP. que j’utilise pour Google Authenticator n’est pas encore tagué dans une version stable (dernière version au moment où j’écris ces lignes 1.2.2). Il devrait en toute logique faire partie de la prochaine version stable.

La compilation de ces paquets est relativement facile.

$ svn checkout svn://svn.forge.objectweb.org/svnroot/lemonldap
$ cd lemonldap/trunk
$ make debian-packages -C build/lemonldap-ng/
 

De manière personnelle je remplace dans le Makefile la commande debuild par la commande pdebuild de l’outils pbuilder. Elle permet de construire de le paquet dans un environement chrooté ce qui permet de ne pas avoir à installer tous les paquets ‘Build-Depends’ sur le serveur de build.

Les paquets générés sont au nombre de 6 :

  • lemonldap-ng
  • lemonldap-ng-doc
  • lemonldap-ng-conf-perl
  • lemonldap-ng-handler-perl
  • lemonldap-ng-manager-perl
  • lemonldap-ng-portal-perl

Voila, cet article nous sera utile pour le couplage de LemonLDAP::NG avec Google Authenticator.

Share

Mise en place d’une authentification à deux facteurs avec Google Authenticator

Dans une volonté d’améliorer la sécurité d’un système d’information, nous allons voir une série d’articles sur l’utilisation d’une authentification forte basée sur Google Authenticator.

Cette authentification forte repose sur le prérequis pour se connecter sur une plateforme de la possession d’un mot de passe ET d’un bien matériel. Nous partirons du principe que ce bien matériel est un smartphone proposant un mot de passe à usage unique et changeant dans le temps.

Ce premier article va expliquer le fonctionnement de base de celui-ci ainsi qu’une installation d’un serveur SSH reposant sur cette « 2 steps authentication ».

Google Authenticator est un système développé par Google afin d’offrir une solution Libre et souple d’OTP.

Le projet est divisé en deux parties :

  1. un module PAM permettant d’être utilisée comme n’importe quel module PAM
  2. des clients pour téléphone mobile (Android évidemment mais aussi iPhone et BlackBerry)

Pour l’installer sur un système sur un système Debian, il vous faudra backporter le paquet que l’on peut trouver içi ou compiler directement depuis les fichiers sources téléchargeables içi.

L’utilisation est assez simple. Nous allons voir comment utiliser cet outils pour s’authentifier en SSH.

Installation du module PAM

Tout d’abord installer le paquet : (Attention, ceci est le dernier paquet proposé par Debian lors de l’écriture de cet article mais ceci est susceptible de changer ! Je vous conseil fortement d’aller voir à cette adresse pour récupérer la dernière version.)

# wget http://ftp.fr.debian.org/debian/pool/main/g/google-authenticator/libpam-google-authenticator_20110413.68230188bdc7-1.1_amd64.deb
# dpkg -i libpam-google-authenticator_20110413.68230188bdc7-1.1_amd64.deb
# apt-get install -f
 

Une fois installé, vous devez créer un fichier .google_authenticator dans la home de vos utilisateurs. La commande utilisée pour cela est simplement google-authenticator en tant que l’utilsateur.

Vous obtiendrez un QRCode à l’écran comme ci-dessous : 

Téléchargez sur l’AppStore ou l’Android Market l’application Google Authenticator puis alors scannez le QR code avec votre téléphone portable pour ajouter ce compte sur votre smartphone.

  • La commande google-authenticator vous demande si elle doit créer le fichier .google_authenticator dans la home de votre utilisateur. Répondez oui car c’est ce fichier va être lu par le module PAM pour vérifier l’OTP.
  • On vous demande après si vous acceptez le rejeu de votre OTP. Vous pouvez accepter ou non en fonction de votre politique de sécurité.
  • On vous demande ensuite le temps de validité de votre jeton OTP qui est à 30 secondes par défaut. (Attention de bien avoir l’horloge de vos téléphones synchronisée sur un serveur de temps !)
  • Et enfin si vous souhaitez limiter le nombre de tentatives de login afin d’empêcher une tentative de brute-forcVous aurez donc un fichier « .google_authenticator » créé dans la home de votre utilisateur et un mécanisme d’OTP sur votre smartphone.

Utilisation du module PAM par le serveur OpenSSH

Dans un premier lieu, il va falloir adapter le fichier /etc/pam.d/sshd et rajouter les lignes :

auth required pam_google_authenticator.so

devant la ligne « @include common-auth » (sous Debian 6)

Dans le fichier de configuration d’OpenSSH, il suffit de placer les directives :

  • PasswordAuthentication yes # Permet l’utilisation des mots de passe et non pas uniquement des clés SSH ou certificats
  • ChallengeResponseAuthentication yes # Cela permet l’utilisation d’un challenge utilisé pour la demande du « Verification Code »

Si vous essayez de vous connecter sur votre serveur avec un utilisateur ayant un .google_authenticator vous devriez obtenir une séquence proche de celle-ci :

ssh toto@bastion
Verification code: 
Password:
Linux bastion 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64
toto@bastion:~$
 
 

Nous verrons dans un prochain article comment pousser bien plus loin la mise en place d’une authentification forte avec Google Authenticator et LemonLDAP::NG.

Share

Intégration de PuppetDoc avec Foreman

Nous allons voir dans cet article comment intégrer la documentation de puppet à Foreman. L’objectif est de donner accès aux utilisateurs à cette documentation pour qu’ils sachent quelles règles sont appliquées dans les classes.

Patcher Puppetdoc de Debian 6

Pour les utilisateurs de Debian 6, la première chose à faire est de patcher puppetdoc (voir bug). Pour cela, vous pouvez utiliser le backport du patch que je met à disposition :

# curl http://www.fitzdsl.net/wp-content/uploads/2011/05/puppet_generator.rb_.patch | patch /usr/lib/ruby/1.8/puppet/util/rdoc/generators/puppet_generator.rb

Générer la documentation

Vous pouvez en premier lieu définir le « document root » de votre documentation. J’ai décidé pour ma part de laisser la doc dans le dossier par défaut : RAILS_ROOT/public. Pour générer la documentation, nous allons utiliser une commande rake prévue pour cela. Dans /usr/share/foreman :

# rake puppet:rdoc:generate

Pensez à mettre cette commande en Cron pour mettre à jour votre documentation au fur et à mesure.La documentation est maintenant accessible en allant dans Additional Settings, Puppet Classes, et en cliquant dans la colonne Environements de la classe.

Share

Mise à jour de la libvirt-ruby de Debian pour Foreman

Cet article très court fait suite à mon précédent billet sur l’intégration de la libvirt avec Foreman. Nous avons vu qu’il était possible de gérer la création de VM et faire des actions simples sur ces VM. Cependant l’installation décrite dans l’article précédent ne permet pas d’exploiter tout ce que Foreman peut faire. En effet, Foreman peut lister les bridges présents sur les Hyperviseurs quand l’intégration de la libvirt le permet (c’est à dire sur Fedora et RHEL mais pas sur Debian / Ubuntu : voir ce bug).

Nous allons donc voir comment corriger très simplement ce problème quand Foreman est installé sur une machine Debian. Nous allons désinstaller le paquet ruby-libvirt de Debian et installer la gem correspondant mais à une version bien supérieure.

# apt-get remove --purge libvirt-ruby1.8
# apt-get install libvirt-dev libxen-dev rubygems
# gem install ruby-libvirt
# service apache2 restart

C’est bon, si vous essayez de créer un nouvel Host sur un Hyperviseur basé sur Fedora ou RHEL, Foreman devrait vous proposer les bridges disponibles.

Share