Cet article a pour but de décrire la mise en place d'une authentification 802.1x EAP/TLS sur un réseau filaire.
Ce type d'authentification est très la mode en ce moment, particulièrement pour sécuriser les réseaux sans fils.
Architecture choisie :
Serveur RADIUS : FreeRADIUS sous Debian,
NAS : Switch Netgear,
Clients : Windows XP & Xsupplicant pour UNIX.
Vous devrez vérifier que votre NAS (switch ou AP) supporte le 802.1X.
Mettez à jour votre firmware dans la plupart des cas.
J'ai du mettre en place FreeRADIUS sur une Debian Sid (unstable), malheureusement pour des raisons de license la librairie TLS n'est pas disponible dans le paquet officiel FreeRADIUS de Debian.
Il est donc impossible de faire de l'authentification EAP/TLS avec cette version.
On va utiliser les sources de FreeRADIUS, la dernière disponible lors de la rédaction de cet article est la 1.0.2, celle-ci convient parfaitement.
Heureusement pour nous, dans les dernière version de FreeRADIUS tout est fournit pour faire un paquet Debian. On va pouvoir intégrer facilement notre serveur RADIUS à notre distribution.
NOTE : Il doit être assez facile de mettre en place le serveur RADIUS sous Debian Sarge (testing), pour Woody (stable) ça doit être plus compliqué car il faudra compiler la version 0.9.7 d'OpenSSL vu qu'elle n'est pas disponible via les packages.
Pour commencer on va installer les packages de développement et les librairies qui nous permettront de compiler FreeRADIUS à la sauce Debian :
| apt-get install libssl-dev openssl wget dpkg-dev gcc make autoconf libc6-dev fakeroot |
Téléchargez la dernière release stable de freeradius :
| cd /usr/src wget ftp://ftp.freeradius.org/pub/radius/freeradius-1.0.2.tar.gz tar zxvf freeradius-1.0.2.tar.gz |
Vous pourrez voir qu'il y a un répertoire debian/ à la racine des sources de FreeRADIUS.
Si vous souhaitez avoir plus d'information sur comment faire un paquet Debian reportez vous aux liens à la fin de cet article.
Changeons la version de Radius dans le afin qu'il ne se fasse pas écraser lors d'un upgrade.
Pour ça éditez le fichier changelog qui se trouve dans le répertoir debian, ici : /usr/src/freeradius-1.0.2/debian/changelog
À la 1ère ligne changer la version 1.0.2-0 par 1.0.2-10 par exemple.
Maintenant on va builder le package, remontez à la racine des sources de FreeRADIUS et executer cette commande :
| dpkg-buildpackage -rfakeroot |
Des erreurs vous seront très probablement renvoyées car vous n'avez pas tous les packages nécessaires pour compiler correctement FreeRADIUS :
| dpkg-buildpackage: source package is freeradius dpkg-buildpackage: source version is 1.0.2-10 dpkg-buildpackage: source maintainer is Paul Hampson _ <Paul.Hampson@anu.edu.au> dpkg-buildpackage: host architecture is i386 dpkg-checkbuilddeps: Unmet build dependencies: libtool1.4 | libtool (<1.5) dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: (Use -d flag to override.) |
Installez en fonction les packages demandés.
Une fois la compilation fini, des paquets .deb auront été créé dans le répertoire supérieur à la racine des sources.
Installez FreeRADIUS via dpkg :
| dpkg -i freeradius_1.0.2-10_i386.deb |
Voilà, freeradius est installé, le repertoire de configuration est ici : /etc/freeradius
Un script d'init aura aussi été intégré : /etc/init.d/freeradius
La configuration de FreeRADIUS pour notre cas s'effectuera dans 4 fichiers :
radiusd.conf
eap.conf
clients.conf
users
1/ radiusd.conf
Le radiusd.conf est très long et je vais seulement lister ici les informations vitales au bon fonctionnement :
| user = freerad group = freerad bind_address = votre_ip port = 0 hostname_lookups = no $INCLUDE ${confdir}/eap.conf authorize { preprocess eap files } authenticate { unix eap } |
Un exemple de radiusd.conf :
2/ eap.conf
Le fichier eap.conf est un include au radiusd.conf, il contient les informations concernant le mode de fonctionnement de l'authentification EAP.
Ici on va configurer EAP pour utiliser le TLS.
| eap { default_eap_type = tls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no tls { # Secret partagé avec votre switch private_key_password = la_clef_paratagee # La clef privée du certificat du serveur radius private_key_file = ${raddbdir}/certs/starfleet2.cert-key.pem # Le certificat du serveur radius certificate_file = ${raddbdir}/certs/starfleet2.cert-key.pem # Le fichier contenant la chaine d'autorité de certification publique CA_file = ${raddbdir}/certs/ca_caint.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 include_length = yes check_crl = no } } |
! ATTENTION ! : Si vous générez vos certificats avec une autorité intermédiaire il faudra que le fichier contenant l'autorité de certification (CA_file) contienne toute la chaine des autorités.
Sinon l'authentification échouera.
Un exemple du eap.conf :
3/ clients.conf
Le clients.conf est le fichier où on définit les NAS (Network Authentication Server), dans notre cas c'est le Switch, ou l'AP WiFi. On va y définir l'adresse IP du NAS ainsi que le secret partagé.
| client 10.4.96.1 { secret = le_secret_partagé shortname = netgear nastype = other } |
Un exemple de clients.conf :
4/ users
Dans le fichier users on recensera tous les utilisateurs autorisés à se connectés. On y indiquera aussi par quel module l'utilisateur devra se connecter. Pour nous ce sera donc EAP.
Mettez le nom de chaque certificat pour chaque user.
| "mulet" Auth-Type := EAP |
Exemple de fichier users :
5/ Certificats
Les certificats se trouvent typiquement dans le répertoire /etc/freeradius/certs/
On y retrouvera :
le certificat + clef privée du serveur, les deux peuvent être dans un même fichier, il faudra enlever la passphrase de la clef,
le certificat de l'autorité de certification,
les certificats des clients.
Faites bien attention aux droits pour le fichier contenant la clef privée du serveur !
Pour démarrer FreeRADIUS vous pouvez soit le faire via le script d'init de cette manière :
| /etc/init.d/freeradius start |
Sinon vous pouvez démarrer le serveur RADIUS en mode debug afin d'avoir un maximum d'information :
| freeradius -X -A |
Vous devrez fournir à vos clients windows l'autorité publique au format "der" ainsi que leur certificat+clef au format PKCS12.
Pour importer un certificat client sous Windows XP voici la marche à suivre :
Double cliquez sur le fichier .der qui vous aura été fournit :



Puis double cliquez sur le fichier .p12 :


Voilà les certificats sont importés, maintenant il faut paramétrer votre interface réseau afin qu'elle utilise l'authentification par certificat pour se connecter au réseau :



Sélectionnez l'autorité de certification qui correspond à votre réseau, dans notre cas c'est itinetCA :

Voilà maintenant dès que vous vous connecterez au réseau en question une négociation EAP/TLS s'effectuera.
Sous linux c'est avec l'utilitaire Xsupplicant qu'on pourra procéder à une authentification 802.1X.
Vous devrez fournir à vos clients Linux l'autorité de certification ainsi que leur certificat + clef privée.
Pour l'installer sous Debian :
| apt-get install xsupplicant |
Un script d'init sera installé : /etc/init.d/xsupplicant
La configuration d'Xsupplicant se fera dans le répertoire : /etc/xsupplicant/
Le répertoire où placer les certificats est celui-ci : /etc/xsupplicant/tls/
On considère ici que le fichier contenant l'autorité publique de certification est : ca.pem
Le fichier contenant le certificat client ainsi que sa clef privée : client.pem
Le fichier client.pem doit être en chmod 600.
Editez le fichier de configuration de xsupplicant : /etc/xsupplicant/xsupplicant.conf
| network_list = all default_netname = default startup_command = <BEGIN_COMMAND>echo "xsupplicant startup"<END_COMMAND> first_auth_command = <BEGIN_COMMAND>dhclient %i<END_COMMAND> logfile = /var/log/xsupplicant.log allow_interfaces = eth0 # En considérant que eth0 est l'interface connectée au réseau 802.1X default { type = wired allow_types = eap_tls identity = <BEGIN_ID>nom_du_certificat<END_ID> # Mettez ici le nom de votre certificat eap_tls { user_cert = /etc/xsupplicant/tls/client.pem user_key = /etc/xsupplicant/tls/client.pem user_key_pass = <BEGIN_PASS>passphrase de la clef privée<END_PASS> root_cert = /etc/xsupplicant/tls/ca.pem crl_dir = /etc/xsupplicant/tls chunk_size = 1398 random_file = /etc/xsupplicant/tls/random } } |
Exemple de xsupplicant.conf :
Voici le fichier un fichier random si le package de xsupplicant ne vous en a pas installé un :
Pour lancer xsupplicant à la main :
| xsupplicant -c /etc/xsupplicant/xsupplicant.conf -i eth0 & |
! ATTENTION ! : L'authentification avec xsupplicant ne marchera pas si votre client dhcp est actif, il faudra killer votre client dhcp, mettre votre interface réseau down puis up et lancer xsupplicant :
| killall -9 dhclient ou suivant la version de votre client dhcp killall -9 dhclient3 ifconfig eth0 down ifconfig eth0 up xsupplicant -c /etc/xsupplicant/xsupplicant.conf -i eth0 & |
Si vous vous connectez que ponctuellement à un réseau demandant une authentification 802.1X je vous suggère de désactiver le script d'init de xsupplicant :
| cd /etc/init.d/ update-rc.d -f xsupplicant remove |
Si vous n'avez pas de PKI voici les scripts que j'ai fais :
Lisez l'en-tête pour savoir comment les utiliser.
Une très bonne documentation par Florian Fainelli sur la mise en place d'une authentification 802.1x EAP/TLS :
http://www.alphacore.net/spip/article.php3 ?id_article=33
{Consulter} l'article avec son forum.
Le but de cet article est de configurer un firewall avec iptables sous GNU/Linux. Après une brève explication du fonctionnement d'iptables et de petits exemples, on écrira un script relativement simple.
Le binaire iptables est un utilitaire qui permet d'insérer des règles de filtrage dans le noyau Linux et plus particuliairement dans Netfilter. Netfilter est apparu dans les noyaux 2.4.x et continu toujours d'être enrichi dans les noyaux 2.6.x. Netfilter utilise 3 tables : filter pour filtrer les paquets, nat pour la réécriture d'adresse et mangle pour marquer les paquets. Nous n'utiliserons que les tables filter et nat.
La syntaxe iptables peut paraitre difficile, mais en contrepartie l'outil est extrêmement souple, et nous le verrons un peu plus loin.
Pour la gestion des logs, nous utiliserons directement LOG et pas ULOG qui nous oblige à installer un nouveau daemon (ulogd). Sachez toutefois que la syntaxe est très proche.
De plus, pour gérere des exceptions, insérons une machine de test cliente dans le LAN avec l'ip 192.168.1.3 (Nom : lewella).
Enfin, pour la partie DMZ, nous utiliserons une machine d'ip 10.0.0.2 (sephiria).
Une règle iptables est introduite comme suit :
Ces règles sont enregistrées jusqu'au prochain redémarrage. Ce n'est pas très pratique. Nous allons donc créer un jeu de règles dans /usr/local/bin ainsi qu'un script d'initialisation qui lancera le jeu de règles à chaque démarrage de la machine. Voici les scripts :
root@Flora ~# chmod 0700 /etc/init.d/iptables_rules
root@Flora ~# update-rc.d iptables_rules defaults
root@Flora ~# touch /usr/local/bin/fw_rules
root@Flora ~# chmod 0700 /usr/local/bin/fw_rules
Dans le fichier /etc/init.d/init_iptables ajoutez les lignes suivantes :
#
# By Damien Degorre <malmok@malmok.net>
# For U-Admin http://www.u-admin.org
#
$IPT="/sbin/itpalbes"
$IPT="/sbin/itpalbes"
case $1 in
start)
echo -n "Starting Firewalling : "
/usr/local/bin/fw_rules
echo "done."
stop)
echo -n "Shutting down Firewalling : "
$IPT-t filter -F
$IPT -t filter -X
$IPT -t nat -F
$IPT -t nat -X
echo "done."
*)
echo "Usage : $0 {start|stop}"
;;
esac
exit 0
Ce script simple nous permet de flusher toutes les règles filter et nat lorsqu'il prend le paramètre stop ou executer nos règles dans le cas du start
Enfin, il va falloir charger tous les modules noyaux pour la gestion iptables. Pour ce faire, rendez-vous dans /lib/moudles/Version.De.Votre.Noyau/kernel/net/ipv4/netfilter/. Dans ce répertoire se trouve tous les modules disponibles pour iptables. Vous pouvez charger chacun de ces modules avec la commande modprobe nom_du_module sachant que nom_du_module correspond aux modules du répertoire sans le .o ou .ko.
NB : Pour connaitre la version de votre noyau, tappez la commande uname -a
NB2 : Il est quand meme préférable que les modules netfilters soient compilés dans le noyau directement.
A partir de maintenant, tout se passera dans /usr/local/bin/fw_rules.
Le début du fichier fw_rules est plutot simple :
#
# By Damien Degorre <malmok@malmok.net>
# For U-Admin http://www.u-admin.org
#
##
## Variables :
##
# Reseaux :
INET_IFACE="eth2" # Interface Internet
LAN_IFACE="eth0" # Interface LAN
DMZ_IFACE="eth1" # Interface DMZ
INET_IP="1.2.3.4" # IP Internet
LAN_IP="192.168.1.1" # IP LAN
DMZ_IP="10.0.0.1" # IP DMZ
# Path
$IPT="/sbin/iptables"
##
## Regles :
##
# On efface toutes les regles
$IPT -t filter -X
$IPT -t filter -F
$IPT -t nat -X
$IPT -t nat -F
Nous avons déclaré plus haut des variables pour utilisation plus souple.
D'autre part on vas une nouvelle fois flusher toutes les règles par sécurité.
Passons aux polices générales :
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT
$IPT -A INPUT -m state --state ESTABLISHED -j ACCEPT
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Si après iptables on ne précise pas la table définie avec l'optio -t c'est par défaut la table filter.
Petite explication :
Les règles de base sont INPUT, pour toutes les connexions entrantes, OUTPUT pour les connexions sortantes et FORWARD pour les connexions entre interfaces.
L'option -P permet de donner la police générale des règles. Par défaut, nous interdisons tout trafic entrant ainsi que tout déplacement de trafic, mais nous autorisons la sortie car comme notre serveur est aussi routeur, il suffit de filtrer les règles INPUT et FORWARD car la sortie d'une interface correspond en fait à l'entrée d'une autre (La sortie de l'interface Internet est l'entrée de l'interface LAN)...
Enfin, on sait que Netfilter est statefull c'est à dire retiens et gère les sessions, nous autorisons donc le trafic si la connexion est déjà établie (flag ESTABLISHED) ou relayé dans le cas de la règle FROWARD (flag RELATED).
Passons maintenant au filtrage.
Netfilter permet de filtrer à différents niveaux :
Interface
Adresse IP / Adresse MAC
Session
Les UNIX ont toujours une interface réseau loopback (lo). GNU/Linux ne déroge pas à la règle. Nous allons donc autoriser cette interfae à commuiquer avec elle même :
$IPT -A FORWARD -i lo -m state --state NEW -j ACCEPT
L'option -i permet de spécifier l'interface d'entré ici lo. D'autre part, nous ajoutons le flag NEW pour autoriser n'importe quelle connexion.
Nous allons maintenant autoriser n'importe qui d'Internet à pouvoir se connecer à notre serveur ssh (port tcp/22). Pour ce faire :
Cette règle permet de préciser avec l'option -p le protocole tcp/udp/icmp/gre/etc. et -dport le port de destination.
NB : Si nous avions, mettons un serveur ssh (tcp/22) et un serveur smtp (tcp/25), nous pouvons utiliser l'option mulitport avec --dports de la facon suivante :
Enfin nous allons autoriser notre machine lewella à sortir sur Internet.
Il faut d'abord intervenir sur la machine firewall et autoriser le forward de trafic comme suit :
Nous pouvons aussi l'ajouter directement à notre script fw_rules.
Ensuite, il suffit très simplement d'ajouter la ligne suivante :
Le problème est évidement que l'adresse IP 192.168.1.3 est privée. Nous allons donc être obligé de faire du NAT pour remplacer cette adresse par celle de votre connexion Internet (option MASQUERADE). Pour ce faire :
NB : Vous avez sans doute remarqué que c'est ici la table nat qui entre en jeux.
Voila... Votre script est maintenant prêt. Simple non ?
Dans la suite de cet article on vas essayer de construire u n jeu de règles permettant de mettre à jour simplement notre firewall.
Nous allons reprendre notre script :
#
# By Damien Degorre <malmok@malmok.net>
# For U-Admin http://www.u-admin.org
#
##
## Variables :
##
# Reseaux :
INET_IFACE="eth2" # Interface Internet
LAN_IFACE="eth0" # Interface LAN
DMZ_IFACE="eth1" # Interface DMZ
INET_IP="1.2.3.4" # IP Internet
LAN_IP="192.168.1.1" # IP LAN
DMZ_IP="10.0.0.1" # IP DMZ
# Path
$IPT="/sbin/iptables"
##
## Regles :
##
# On efface toutes les regles
$IPT -t filter -X
$IPT -t filter -F
$IPT -t nat -X
$IPT -t nat -F
# Polices generales
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT
$IPT -A INPUT -m state --state ESTABLISHED -j ACCEPT
$IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# On autorise le forward de paquets au niveau noyau :
echo "1" > /proc/sys/net/ipv4/ip_forward
# Interface loopback
$IPT -A INPUT -i lo -m state --state NEW -j ACCEPT
$IPT -A FORWARD -i lo -m state --state NEW -j ACCEPT
# LAN : On autorise la machine 192.168.1.3 à se connecter à Internet :
$IPT -A FORWARD -s 192.168.1.3 -j ACCEPT
# Internet : On autorise internet à se connecter en ssh :
$IPT -A INPUT -i $INET_IFACE -p tcp -dport 22 -m state --state NEW -j ACCEPT
# Enfin, on NAT :
$IPT -A POSTROUTING -t nat -i $LAN_IFACE -o INET_IFACE -j MASQUERADE
On vas rajouter quelques options sympatiques.
Nous faisons confiance à notre machine lewella et celle ci peut se connecter sur n'importe quel port du Firewall Flora :
D'autre part, nous avons recu des attaques de l'adresse IP 1.2.4.5 et on décide de la bannir comme suit :
# Si c'est du tcp, on rejete avec un flag RST :
$IPT -A 1.2.4.5 -p tcp -j REJECT --reject-with tcp-reset
On va limiter le nombre de paquet icmp/seconde poru éviter le flood :
On va éviter le scan "barbare"
Enfin on limite la portée des SYNFlood :
$IPT -A INPUT -i $INET_IFACE -p tcp --syn -j syn-flood
$IPT -A syn-flood -m limit --limit 1/s --limit-burst 10 -j RETURN
$IPT -A syn-flood -j DROP
Une explication s'impose ici.
L'option -N permet de créer une chaine. Cela nous permet d'y attribuer plusieurs traitements (ici RETURN et DROP).
Notre Firewall est maintenant complètement opérationnel.
Commençons par définir ce qu'est une DMZ. DMZ veut dire DeMilitarized Zone. En fait, on autorise n'importe qui d'Internet à aller dans cette partie du réseau, sachant qu'elle y sera bloquée. On peux ainsi y mettre notre serveur web, DNS, ou encore mail. Dans la pratique, iptables va 'forwarder' les requettes d'un port précis sur une autre machine. Pour cela nous utiliserons notre table nat :
# 10.0.0.2 est l'ip de mon serveur web dans ma DMZ
iptables -t nat -A PREROUTING -d $INET_IP -p tcp --dport 80 -j DNAT --to-destination 10.42.42.80
On utilise la règle PREROUTING de la table nat pour re-router les paquets provenant d'Internet vers notre serveur Web.
Nous allons maintenant définir les règles pour notre DMZ (communication avec notre LAN et Internet) :
iptables -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -p tcp -m multiport --dports 80,22 -m state --state NEW -j ACCEPT
# Internet peut web dans la DMZ
iptables -A FORWARD -i $INET_IFACE -o $DMZ_IFACE -p tcp --dport 80 -m state --state NEW -j ACCEPT
# On MASQUERADE le trafic DMZ -> Internet :
iptables -A POSTROUTING -t nat -i $DMZ_IFACE -o $INET_IFACE -j MASQUERADE
Notre DMZ est maintenant configurée.
Vous avez un proxy squid et vous souhaitez le rendre transparent ? C'est assez simple. Dans votre fichier
<code>
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Enfin ajoutez la ligne suivante dans /usr/local/bin/fw_rules :
La méthode est assez simple.
Iptables est un outils extrêment puissant mais si facile à utiliser. Vous n'avez vu ici qu'un apercu de ses possibilités. Je n'ai pas abordé les logs ni même la Qualité Of Service.
fw_malmok est un ensemble de scripts bash pour automatiser iptables. Vous pouvez y jeter un coup d'oeil pour comprendre tous les mécanismes.
{Consulter} l'article avec son forum.
Le but de cet article est de montrer un exemple d'installation de Gforge avec les paquets Debian.
Je n'expliquerai pas ici comment fonctionne Gforge, le site officiel est assez clair là dessus.
Pour le moment, les versions officiellement disponibles sous Debian (Sarge et Sid) sont des versions 3.1 de Gforge.
Les versions 3.x incluent un annuaire LDAP par défaut, seul soucis, les packages LDAP sur ces versions de Debian évoluent assez rapidement, et cassent souvent l'installation de Gforge.
LDAP est utilisé notament pour l'authentification ftp & cvs.
Dans les versions 4.x de Gforge LDAP n'est plus nécessaire, il est possible de faire l'authentification via la base de données PostgreSQL.
Christian Bayle a mis récemment à disposition, sur une repository non officielle, des paquets Gforge 4.1 (un build à partir des CVS).
Ceux-ci marchent sous Sid (unstable) et sur Sarge (testing) à une condition, on reviendra là dessus plus tard.
Avant tout, il vous faudra une zone DNS qui sera déléguée à Gforge, dans le cadre cet exemple ce sera : dev.iti.esiea.fr
Gforge 4.1 a besoin d'un certain nombre de services pour fonctionner correctement, certains sont optionnels, je vais lister ceux que j'ai choisis d'utiliser :
PostgreSQL
Apache2
PHP4
Un MTA (Exim ou Postfix)
Bind9
Proftpd
Mailman
SSH
CVS
NOTE : Vous n'avez pas besoin de les installer au préalable, apt-get se chargera de les prendre quand vous installerez Gforge.
Comme écrit plus haut, les paquets de Gforge que nous allons utiliser ne marchent qu'avec Sarge (testing) ou Sid (unstable).
Il va donc falloir mettre à jour votre Debian si c'est une fresh install de Woody (stable).
! ATTENTION ! : Au moment où j'écris cet article les paquets de Christian Bayle qu'on va utiliser sont déjà cassé avec l'unstable...
La nouvelle version de PostgreSQL (7.4) n'a pas tout à fait la même syntaxe que la 7.3, la manipulation à faire pour résoudre le problème est relativement simple, je décrirai ça part la suite, pour moins de soucis je vous conseil de partir sur une base de testing (Sarge).
Pour l'unstable éditez votre /etc/apt/sources.list
On va aussi y ajouter la repository non officielle de Christian Bayle pour avoir Gforge 4.1 :
| deb http://ftp.fr.debian.org/debian/ unstable main non-free contrib deb http://ftp.fr.debian.org/debian-non-US unstable/non-US main contrib non-free deb http://security.debian.org/ testing/updates main contrib non-free # Paquets Gforge 4.1 |
Puis effectuer la mise à jour :
| apt-get update && apt-get dist-upgrade |
Si vous choisissez Sarge (la testing) il vous faudra quand même prendre un paquet venant de l'unstable pour installer cette version de Gforge : libnss-pgsql1
Pour ça, vous devrez avoir les lignes de la testing ET de l'unstable dans votre sources.list :
| deb http://ftp.fr.debian.org/debian/ testing main non-free contrib deb http://ftp.fr.debian.org/debian-non-US testing/non-US main contrib non-free deb http://security.debian.org/ testing/updates main contrib non-free # Avoir accès aux paquets unstable # Paquets Gforge 4.1 |
Dans /etc/apt/apt.conf
| APT ::Default-Release "testing" ; APT ::Cache-Limit 10000000 ; |
Ceci permet de garder la testing par défaut mais de prendre des morceaux de l'unstable si necessaire.
Mettez à jour et installez libnss-pgsql de l'unstable :
| apt-get update && apt-get dist-upgrade && apt-get -t unstable install libnss-pgsql1 |
Passons aux choses sérieuses, installons Gforge.
Par défaut Gforge va installer Exim comme MTA à part si vous lui précisez Postfix.
Par ailleur, CVS n'est pas installé par défaut, il vous faudra le préciser aussi.
Pour ma part, j'ai choisis d'installer Gforge avec postfix et cvs, voici donc ce qu'il vous faut prendre pour ça :
| apt-get install postfix postfix-pgsql gforge gforge-mta-postfix gforge-plugin-scmcvs |
1. Configuring Mailman :
Cocher en et fr,
Définir fr par défaut.
2. Configuring gforge-common :
Your Gforge domain or subdomain name : dev.iti.esiea.fr
Rentrez ici le domaine dont le bind de Gforge aura la charge, pour ma part c'est un "sous-sous domaine", rentrez par exemple : nom.org
3. Configuring gforge-db-postgresql :
Your database server : 10.4.98.97
On considère ici que votre adresse IP est 10.4.98.97.
! ATTENTION ! : Ne rentrez pas ici le localhost (127.0.0.1) sinon postgresql refusera de démarrer correctement, on modifiera le fichier de conf à la main après pour régler quelques problèmes.
Your IP address : 10.4.98.97
Your CVS server : scm.dev.iti.esiea.fr
Do you want /etc/postgresql/pg_hba.conf to be updated ? : Yes
Do you want /etc/apache-ssl/httpd.conf to be updated ? : Yes
Répondre Yes à tout update de fichier de conf.
4. ProFTPd configuration
Run proftpd from inetd or standalone ? : Standalone
5. Setting-up
apt-get vous demandera surement votre accord pour modifier des fichiers de conf, répondez "Y".
exemple :
| Configuration file `/etc/init.d/postgresql' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are : Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** postgresql (Y/I/N/O/D/Z) [default=N] ? y |
NOTE : Si vous êtes en unstable, apt-get va surement être cassé au lancement du démon de PostgreSQL, il va falloir vider la base de donnée et relancer apt-get qui la remplira :
| # su -s /bin/bash - postgres $ postgresql-dump -t db.out -dcivlp $PGDATA/../data.save # /etc/init.d/postgresql start # apt-get install gforge gforge-mta-postfix gforge-plugin-scmcvs |
6. Erreurs avec Apache2
Apache2 renvera aussi des erreurs à son lancement, il faut créer un certificat SSL.
Si vous n'avez pas de PKI, créez un certificat autosigné via l'utilitaire fournit avec apache2 :
| # apache2-ssl-certificate creating selfsigned certificate replace it with one signed by a certification authority (CA) enter your ServerName at the Common Name prompt If you want your certificate to expire after x days call this programm with -days x You are about to be asked to enter information that will be incorporated into your certificate request. Country Name (2 letter code) [GB] :FR |
Un fichier "apache.pem" sera créé dans /etc/apache2/ssl/, il contient le certificat ainsi que la clef privée.
Il va falloir éditer le fichier de configuration d'apache2 pour ajouter le path du certificat.
Editez donc /etc/apache2/conf.d/gforge.httpd.conf :
| ligne 149 : SSLCertificateFile /etc/apache2/ssl/apache.pem ligne 150 : SSLCertificateKeyFile /etc/apache2/ssl/apache.pem ligne 260 : SSLCertificateFile /etc/apache2/ssl/apache.pem ligne 275 : SSLCertificateFile /etc/apache2/ssl/apache.pem ligne 343 : SSLCertificateFile /etc/apache2/ssl/apache.pem |
Pour faire ça rapidement utilisez la fonction de remplacement de votre éditeur. ;)
Lancez apache2 et vous pourrez enfin finir l'apt-get :
| /etc/init.d/apache2 restart apt-get install postfix postfix-pgsql gforge gforge-mta-postfix gforge-plugin-scmcvs |
Vous pouvez constater que tout n'est pas encore automatisé, mais au moins ça marche.
7. Erreurs avec Postfix (testing/Sarge)
On vient de me remonter une erreur avec la configuration de postfix qui permet pas la configuration de gforge-mta-postfix en testing/Sarge, je ne sais pas si cette erreur concerne aussi l'unstable/Sid actuellement.
Si vous rencontrez cette erreur :
| WARNING: No /etc/postfix/main.cf to modify ... cp: ne peut évaluer `/etc/postfix/main.cf': Aucun fichier ou répertoire de ce type |
Faites :
| touch /etc/postfix/main.cf |
et relancez l'apt-get.
On va autoriser le localhost à s'authentifier sur la base de donnée.
Editez un des fichiers de configuration de PostgreSQL car il n'autorise pas l'envoi de mail via postfix, à savoir : /etc/postgresql/pg_hba.conf
Ajoutez-y les lignes suivantes :
| host gforge gforge_nss 127.0.0.1 0.0.0.0 trust host gforge gforge_mta 127.0.0.1 0.0.0.0 trust host gforge gforge 127.0.0.1 0.0.0.0 password |
Relancez PostgreSQL :
| /etc/init.d/postgresql restart |
S'il renvoit "(Could not connect to database)." c'est pas grave, c'est le script d'init qui est mal fichu, le démon de PostgreSQL tourne très bien.
Maintenant on va sécuriser un peu l'accès shell des utilisateurs de gforge, par défaut ils peuvent se logger et avoir bash comme shell par défaut.
Heureusement pour nous gforge est livré avec un shell en perl qui permet simplement l'accès aux executables : cvs et scp.
Ce shell s'appel : cvssh.
On définit cvssh comme shell accepté sur la machine, editez /etc/shells et ajoutez la ligne : /bin/cvssh
Maintenant on va utiliser l'outil change_default_shell pour changer le shell par défaut dans la base de donnée à la création d'un nouvel utilisateur.
Malheureusement pour nous ce petit outil n'est pas livré avec les paquets de gforge, il faut aller prendre les CVS de gforge ou le tarball de gforge 4.0.2. Espérons qu'il soit inclut à l'avenir dans les paquets debian. :)
| cd /usr/src wget http://gforge.org/frs/download.php/88/gforge-4.0.2.tar.bz2 apt-get install bzip2 tar jxvf gforge-4.0.2.tar.bz2 /usr/src/gforge-4.0.2/utils/change_default_shell /bin/cvssh |
Vérifiez que vous pouvez vous connecter à gforge avec votre navigateur en rentrant l'url du domaine que vous avez choisis : http://dev.iti.esiea.fr
Le login d'administration est "admin", le mot de passe est celui que vous avez rentré à la configuration de la base de donnée.
Voilà, faites vos petits tests pour vérifier que tout est OK et monitorez les logs. :-)
J'ai rencontré des problèmes avec Postfix, sur la version 2.2.2 disponible en unstable.
Chaque processus fils s'autokillait au moment d'envoyer un mail.
Vous pourrez voir ça en monitorant les logs de postfix :
| tail -f /var/log/mail.info |
Voilà le type de message que je me prennais :
| Apr 21 00:35:44 gforge postfix/master[25274] : warning : process /usr/lib/postfix/cleanup pid 25318 killed by signal 6 Apr 21 00:35:44 gforge postfix/master[25274] : warning : /usr/lib/postfix/cleanup : bad command startup -- throttling Apr 21 00:36:44 gforge postfix/cleanup[25324] : panic : mymalloc : requested length 0 |
Pour ma part la machine hébergeant Gforge n'a pas accès directement à internet, pour envoyer les mails je suis obligé d'utiliser un serveur relai avec une authentification TLS (via la librairie SASL2).
J'ai testé en ne passant pas par le serveur relai et les mails sont bien envoyés. Les modules SASL2 sont apparement mort dans le Postfix 2.2.2 de Sid.
Si vous avez le même problème voici les solutions possible pour contourner ce problème :
Installer Gforge à partir de la testing (Postfix 2.1.x),
Utiliser Exim,
Écraser le postfix existant en compilant une version 2.1.x.
Personnelement j'ai choisis la dernière solution, bien que ce ne soit pas dans la philosophie de Debian.
Si vous choisissez aussi d'écraser Postfix via les sources, voilà les étapes qu'il vous faudra effectuer :
Stoper postfix
Faire un backup du répertoire /etc/postfix (vers /etc/postfix.bak par exemple),
Télécharger la dernière version de postfix 2.1.x,
Installer gcc et tous les petits outils / libraires qui vont avec,
Prendre les libraires pgsql et db4.3,
Compiler postfix avec le support pgsql (et tls, si vous avez besoin comme dans mon cas de faire un authentification TLS sur un MTA relai),
Copier le main.cf et le master.cf du backup vers /etc/postfix.
Je ne détaillerai pas ici comment compiler et installer postfix, les readmes inclus avec les sources expliquent ça très bien.
De la doc utilisateur, maintenue par Guillaume Montard : http://www.kps.fr/gforge/
Le help board de Gforge, on y trouve pas mal de réponse à nos questions en cherchant bien : http://gforge.org/forum/forum.php ?forum_id=6
{Consulter} l'article avec son forum.
Cette page vise à améliorer le confort de lecture des internautes qui ne disposent que d'un terminal en mode texte (VT, tablette braille, synthétiseur vocal...) ou d'une connexion à très bas débit.
Vous trouverez en permanence sur http://www.u-admin.org/oo/ le texte intégral des trois derniers articles publiés, ainsi que les cinq dernières brèves.
Les liens de cette page qui figurent entre {accolades} renvoient vers des pages du site principal, utilisant une maquette graphique et non pas uniquement texte.
| {Site réalisé avec le logiciel SPIP} | {U-ADMIN - FORMATION DOCUMENTATION - GNU/LINUX UNIX} | {PLAN DU SITE} |