Jonas Rockenbauer: février 2011

Installation et configuration de Puppet

Présentation

Puppet est un outils de gestion de la configuration de serveurs, il permet le télédéploiement de configuration sur un ensemble de serveurs en quelques minutes. L’intérêt de cette solution open source réside dans son support multi-plateformes (basé sur ruby), sa sécurité (ssl), son développement actif et sa relative simplicité à mettre en oeuvre. A noter que depuis début 2011 la société Puppetlabs propose une version Puppet Enterprise (support + package sur demande).

Il existe une version Legacy (0.25.x) qui comporte de nombreux bugs et manque de fonctionnalités l'article ci dessous ne traite que de la version stable 2.6.x et supérieure

Prérequis

Disposez de plusieurs serveurs à administrer sans quoi le gain de temps et d'énergie ne sera pas effectif.
Notions en administration système.

Systèmes supportés

Puppet fonctionne sur la plupart des système Uni* et dans une moindre mesure Windows. voir ici pour plus de détails.

Installation

Puppet est présent dans les dépôts, installez les paquets puppet, facter et puppetmaster (pour le serveur maître) :

Sur le client : apt-get install puppet

Sur le master : apt-get install puppetmaster

Cependant si vous souhaitez une version différente rendez vous sur la page de téléchargement officielle pour obtenir un package .tar.gz. Autre solution installer puppet sous forme de gem (le système de paquet ruby). Dans ce cas l'installation est tout aussi simple :

gem install facter
gem install puppet

Configuration

Maître

Fichiers de configuration

Les fichiers de configuration sont donnés à titre d'exemple vous êtes libre d'indiquer d'autres paramètres.

On modifie le fichier /etc/puppet/puppet.conf

[main]
logdir =        /var/log/puppet
vardir =        /var/lib/puppet
ssldir =        $vardir/ssl
rundir =        /var/run/puppet
confdir =       $vardir
factpath =      $vardir/lib/facter
pluginsync =    false
server =        hostnameduserveur
report =        true
reports =       log,store

[master]
templatedir =   $vardir/templates
modulepath =    $vardir/modules
libdir  =       $vardir/plugins
syslogfacility = user

Parefeu

On modifie également notre firewall afin de laissez passer les flux :

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -s ipdumaster \
--sport 8140 -d ipduclient -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED -s ipduclient -d \
ipdumaster --dport 8140 -j ACCEPT

Esclave

Configuration de l'agent Puppet

/etc/puppet/puppet.conf

[main]
server =        hostnamedevotremaster
report =        true
rundir =        /var/run/puppet/
runinterval =   50

[agent]
listen=true

Le paramètre listen et les fichiers auth.conf et namespaceauth.conf sont nécéssaire pour activer le déploiement à partir du master (puppet kick ou puppetrun) si vous ne souhaitez pas utiliser ces commandes, ces fichier sont inutiles.

/etc/puppet/auth.conf

path /run
method save
allow *

/etc/puppet/namespaceauth.conf

[puppetrunner]
allow *
[puppetbucket]
allow *
[puppetreports]
allow *
[resource]
allow *
[kick]
allow *

Parefeu

Si vous disposez d'un parefeu actif il faut songer à ouvrir le port 8139 :

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -s ipduclient --sport 8139 -d ipdumaster -j ACCEPT

iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED \
-s ipdumaster -d ipduclient --dport 8139 -j ACCEPT

Validation

Avant de pouvoir utilisez un client il faut préalablement le valider auprès du master. Pour cela sur le client lancer la commande :

puppetd --test

Cela va générer un certificat que l'on nous demanderas de valider, pour cela sur le serveur :

puppetca --list
nomduclient

doit nous retourner le nom du serveur en attente de validation ensuite on signe le certificat en attente :

puppetca --sign nomduclient

ou bien

puppetca -s nomduclient

Déploiement à partir du master

Pour lancer le puppetd –test sans devoir être connecté à chaque client on lance

puppet kick nomduclient

ou encore

puppetrun nomduclient

Si cela ne fonctionne pas vérifiez bien qu'un déploiement sur le client est fonctionnel ainsi que l'ouverture des ports du parefeu.

Problèmes

Désactivez le déploiement automatique d'un client

Un client puppetd qui tourne en daemon à la fâcheuse tendance d'être configuré pour exécuter un puppetd –test à intervalle régulier. Pour solutionner ce problème tout en gardant un démon à l'écoute du puppetrun du master il faut lancer le process puppetd avec l'option –no-client soit :

puppetd --no-client

pour automatiser l'ensemble on pourra le rajouter dans le fichier /etc/init.d/puppet

err: Could not retrieve catalog: Could not parse for environment development: Could not match ''

Ce problème peut survenir au cours d'un déploiement, il s'agit d'un mauvais encodage du/des fichier(s) de scripts puppet lorsque il ont été créé à partir d'un poste sous Windows, pour résoudre ce soucis un petit coup de dos2unix fera l'affaire

dos2unix le/fichier/de/script

no certificate found and waitforcert is disabled

warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled

Le certificat n'a pas encore été signé sur le master.

Run of Puppet configuration client already in progress

notice: Run of Puppet configuration client already in progress; skipping

Indique que Puppet est déjà en cours d’exécution sur la machine.

certificate verify failed

err: Could not retrieve catalog from remote server: SSL_connect

returned=1 errno=0 state=SSLv3 read server certificate B:

certificate verify failed

indique que le certificat que possède le client diffère de celui du master, aussi la solution la plus simple est de régénérer un certificat sur le client puis de le signer sur le master. pour ce faire on supprime le certificat précédent.

rm -rf /etc/puppet/ssl

Le répertoire peut différer en fonction de votre configuration, il s'agit de la valeur de la variable ssldir dans le fichier /etc/puppet/puppet.conf

On effectue une nouvelle tentative de déploiement qui vas générer un nouveau certificat

puppetd --test
info: Creating a new SSL key for votreserveur.fr
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for votreserveur.fr
info: Certificate Request fingerprint (md5): 80:AE:23:1C:03:DF:5D

:65:0D:8F:04:82:AC:D2:BF:C1

On peut ensuite signer le certificat sur le puppetmaster et déployer de nouveau.

Si le problème persiste toujours il s'agit alors sans doute d'une mauvaise synchronisation horaire entre le client et le master.

err: Could not request certificate: Neither PUB key nor PRIV key:: header too long

Si lors du lancement de la commande puppetd –test vous obtenez cette erreur

puppetd --test
info: Creating a new SSL key for hostnameduserveur
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Caching certificate_request for hostnameduserveur
err: Cached certificate for ca failed: header too long
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
err: Cached certificate for ca failed: header too long
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled

puppetd --test
err: Could not request certificate: Neither PUB key nor PRIV key::

header too long
Exiting; failed to retrieve certificate and waitforcert is disabled

Ce problème survient lorsque le système de fichier sur lequel Puppet essaye de créer le certificat est plein.

Liens

Chillispot : portail captif

Ceci est un de mes anciens tutoriel datant de mon projet en BTS (2006), cependant il doit toujours être possible de l'adapter à CoovaChilli.

Le projet Chillispot est abandonné le développeur principal étant partit, cependant il existe un fork très actif nommé CoovaChilli

Chillispot est un portail captif. Il a pour rôle dans un premier temps de distribuer les adresses IP aux clients qui se connectent sur le Hotspot, puis dans un second temps de capturer toutes les requêtes à destination du web. Il force ainsi le client à passer par la page de demande d’authentification. Il n’est pas possible de passer outre, seuls les sites de dimension iT et la page d’authentification de Chillispot sont autorisés sans être, au préalable, authentifié sur le serveur Radius. Chillispot peut à la fois être installé sur une machine, via les paquets téléchargeables sur le site officiel, mais peut également être flashé dans un routeur compatible (du type Linksys WRT-54G) au moyen d’un firware spécifique (DD-WRT).

Pré-requis

Deux cartes réseau (interface LAN et publique)
serveur web apache2
générateur de certificats
freeradius (authentification)
iptables (pare-feu)

Installation

apt-get install apache2 apache-ssl phpmyadmin mysql-server freeradius freeradius-mysql

Configuration Réseau (module TUN/TAP)

Vous avez besoin du module tun.o (inclus dans les sources du kernel depuis les versions >= 2.4.7). Ubuntu/Debian ne crée pas le périphérique "tun" automatiquement. Dans un terminal, taper les commandes suivantes pour la création d'une interface « tun » :

mkdir /dev/net
mknod /dev/net/tun c 10 200
modprobe tun

Installation de la partie applicative

Ouvrez le fichier /etc/modules.conf et vérifiez qu'il contient la ligne suivante :

alias char-major-10-200 tun

installez le paquet chillispot
Configuration du cgi

On copie le fichier cgi fourni dans le répertoire adéquat :

cp /usr/share/doc/chillispot/hotspotlogin.cgi.gz /usr/lib/cgi-bin/
cd /usr/lib/cgi-bin
gunzip hotspotlogin.cgi.gz
chmod a+x hotspotlogin.cgi.gz

(vous pourrez éditer ce fichier une fois chillispot fonctionnel afin de personnalisez l'installation)

Configuration

Dans le fichier /usr/lib/cgi-bin/hotspotlogin.cgi, décommenter et modifier le paramètre suivant :

$uamsecret = "secretchilli" /* secret partagé entre le CGI hotspotlogin.cgi et le daemon chilli */

Dans le fichier /etc/chilli.conf, décommenter et modifier les paramètres suivants :

net 192.168.1.0/24	ou laisser commenter pour utiliser la configuration par défaut 192.168.182.0/24
dns1 10.187.36.3	(le DNS de mon Fournisseur d’accès) ou laisser commenté pour utiliser la configuration par défaut ( les DNS spécifiés dans votre /etc/resolv.conf)
radiuslisten 127.0.0.1	Décommenter sinon l’adresse 0.0.0.0 (NAS-IP-Address) apparaît dans les logs de freeradius
radiusserver1 127.0.0.1	IP du serveur d’authentification
radiusserver2 127.0.0.1	IP du serveur d’authentification Radius
radiussecret secretradius	secret partagé entre le serveur Radius et le daemon chilli
Radiusnasid portail	identifiant de votre chillispot
radiuslocationid	isocc=fr,cc=33,ac=87000,network=MonESSID
dhcpif eth1	nom de l’interface reliée au point d’accès
uamserver https://ipdevotreserveur/cgi-bin/hotspotlogin.cgi	ou mettre https://192.168.182.1/cgi-bin/hotspotlogin.cgi si vous utilisez la configuration par défaut.
Uamsecret secretchilli	mettre le même secret que dans le fichier /usr/lib/cgi-bin/hotspotlogin.cgi
Uamlisten 192.168.1.1	adresse écoutée
uamallowed localhost www.yahoo.fr	Url autorisée

Configuration du pare-feu

cp /usr/share/doc/chillispot/firewall.iptables /etc/chilli.iptables
chmod u+x /etc/chilli.iptables

Vous devez avoir à l'intérieur :

EXTIF="eth0" /* interface reliée à Internet */
INTIF="eth1" /* interface reliée au point d'accès */

Si ce n’est pas déjà fait, activer le forwarding entre les interfaces réseau. Vérifier que la ligne suivante existe dans le fichier /etc/network/options :

ip_forward=yes

relancez ensuite les interfaces réseaux

/etc/init.d/networking restart

Dans le fichier /etc/freeradius/clients.conf, modifier le paramètre suivant :

client 127.0.0.1 {
#secret = testing123
secret = secretradius /* mettre le même secret partagé que dans le fichier /etc/chilli.conf */

Configuration de Freeradius

modifier le fichier /etc/freeradius/sql.conf:

server = "localhost" (ou x.x.x.x l'ip de votre serveur mysql) 
login = "radius" 
password = "xxxx"

mettre dans /etc/freeradius/radiusd.conf (après le sql.conf) :

authorize {
        preprocess
        chap
        suffix
        eap
        #files
        sql
}
authenticate {
        Auth-Type PAP {
          pap
        }
        Auth-Type CHAP {
          chap
        }
        eap
}
accounting {
        detail
        radutmp
        sql
}
session {
        sql
}
  radutmp {
    filename = ${logdir}/radutmp
    username = %{User-Name}
  case_sensitive = yes
    check_with_nas = yes  
  perm = 0600
  callerid = "yes"
 }
  radutmp sradutmp {
  filename = ${logdir}/sradutmp
  perm = 0644
  callerid = "no"
 }
  attr_filter {
  attrsfile = ${confdir}/attrs
 }
 counter daily {
  filename = ${raddbdir}/db.daily
  key = User-Name
  count-attribute = Acct-Session-Time
  reset = daily
  counter-name = Daily-Session-Time
  check-name = Max-Daily-Session
  allowed-servicetype = Framed-User
  cache-size = 5000
 }
 always fail {
  rcode = fail
 }
 always reject {
  rcode = reject
 }
 always ok {
  rcode = ok
  simulcount = 0
  mpp = no
 }
  expr {
 }
  digest {
 }
  exec {
  wait = yes
  input_pairs = request
 }
  exec echo {
    wait = yes
    program = "/bin/echo %{User-Name}"
    input_pairs = request
    output_pairs = reply
   }
 ippool main_pool {
  range-start = 192.168.1.1
  range-stop = 192.168.3.254
  netmask = 255.255.255.0
    cache-size = 800
  session-db = ${raddbdir}/db.ippool
  ip-index = ${raddbdir}/db.ipindex
  override = no
  maximum-timeout = 0
 } 
}
instantiate { 
 exec
  expr
 }
authorize {
  preprocess
  auth_log 
  chap
  mschap
  suffix
  eap
  files
  sql
}
authenticate {
  Auth-Type PAP {
  pap
 }
  Auth-Type CHAP {
  chap
 }
  Auth-Type MS-CHAP {
  mschap
 }
 unix
 eap
}
preacct {
 preprocess
 acct_unique
 suffix
 files
}
accounting {
 detail 
 unix
 radutmp
}
session {
 radutmp
}
post-auth {
 sql
}
pre-proxy {
}
post-proxy {
 eap
}

Configuration de MySQL

On s'occupe ensuite de notre base de données :

echo "create database radius;" mysql -u root -p
echo "grant all on radius.* to radius@'%' identified by 'motdepasse_sql'; flush privileges;" mysql -u root -p
zcat /usr/share/doc/freeradius/examples/mysql.sql.gz mysql -u root -p radius
#ou bien
zcat /usr/share/doc/freeradius/examples/db_mysql.sql.gz | mysql -u root -p radius

Pour ajouter des utilisateur dans la base il faut ajouter un login + password dans la table radcheck de la base radius , un login plus le type d'authentification dans la table radgroupcheck et enfin un login associé à un nom de groupe dans la table usergroup

Table usergroup

id	UserName	GroupName
1	utilisateur	groupe
2	prof1	professeurs
3	élève1	élèves

Table radcheck

id	UserName	Attribute	Op	Value
1	utilisateur	Password	==	passuser
2	prof1	Password	==	passprof
3	élève1	Password	==	passeleve

Table radgroupcheck

id	GroupName	Attribute	op	Value
1	groupe	Auth-Type	:=	Local
2	professeurs	Auth-Type	:=	Local
3	élèves	Auth-Type	:=	Local

Vous pouvez vous référer au site officiel de chillispot pour l'ensemble des syntaxes supportés.

Test de fonctionnement

On test l'authentification de freeradius en mode débug

/etc/init.d/freeradius stop
freeradius -XXX -A
[...]
Debug: Listening on authentication *:1812Debug:
Listening on accounting *:1813
Debug: Listening on proxy *:1814
Info: Ready to process requests

Dans une autre console on lance un radtest :

radtest tux tuxy 127.0.0.1 0 monsecret_nasradius

Sending Access-Request of id 95 to 127.0.0.1:1812
User-Name = "tux"
User-Password = "tuxy"
NAS-IP-Address = localhost
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=95, length=20

Notre identification par rapport à mysql est donc fonctionnelle on peut dès à présent tester notre chillispot.

/etc/init.d/freeradius stop (ctrl+c pour le mode débug)
/etc/init.d/freeradius start
ifconfig eth1 0.0.0.0
/etc/init.d/chilli stop
/etc/init.d/chilli start
/etc/chilli.iptables

Vérifiez que la borne wifi à bien pris son adresse en dhcp puis connectez vous au réseau wifi avec votre poste, lancez une page web, si tout ce passe bien vous devriez être redirigé sur https://ipdevotreserveur/cgi-bin/hotspotlogin.cgi
Il vous reste maintenant à vous authentifier, si le radtest à été concluant l'authentification devrait réussir sans problèmes.
Un popup s'ouvre alors avec le temps de connexion et la possibilité de se déloguer tandis que la page que vous aviez ouverte est redirigé vers le site demandé.

Voir aussi

(en) Site officiel
(fr) Inspiré du livre blanc http://www.guellec.fr/ressources/rapports/documentation_hotspot.pdf

Pages