![[Barre Superieure]](../../common/images/Topbar-fr.gif){kind=small}
![[Barre Inferieure]](../../common/images/Bottombar-fr.gif){kind=small}
| Cet article est disponible en: English Castellano Deutsch Francais Nederlands Turkce |
![[Photo of the Author]](../../common/images/Atif-Ghaffar.jpg)
par Atif Ghaffar L´auteur:
Atif est un caméléon. Il change de rôle, passant d'Administrateur système, à
programmeur, instructeur, chef de projet, ou à quoi que ce soit d'autre
permettant l'aboutissement d'un travail.
Sommaire:
|
Résumé:
Dans mon dernier article, je vous ai présenté LDAP sous Linux. J'ai reçu de nombreuses demandes émanant de personnes curieuses de savoir comment LDAP combiné à d'autres bons logiciels open-source pouvait devenir un service de courrier web ou un système d'hébergement.
Dans cet article nous mettrons en place un service de FAI sur mesure basé sur LDAP et Linux. Il éclaircira de nombreux sujets et répondra à la plupart des questions posées. Nous utiliserons ensuite un outil nommé ISPMan pour gérer tout cela.
Pour éviter de prendre trop de place avec les exemples, je les ai inclus dans
des widgets texte. Si vous voulez imprimer cette page, sauvegardez-la sur votre
disque et changez les balises "textarea" en balises "pre".
Ce petit programme Perl fera peut-être l'affaire.
perl -pi.bak -e 's!textarea.*?>!pre>!g' filename
Créer un service de FAI et le gérer est quelque chose de complexe,
particulièrement si vous souhaitez l'automatiser, le rendre très disponible et
modulable. Etre FAI (Fournisseur d'Accès Internet) réclame une équipe
d'administrateurs système dont le rôle consiste à faire fonctionner les
machines, créer les comptes, gérer les sites, régler les problèmes, fournir le
support technique etc.
La plupart du temps, le support technique n'a que peu ou pas de contrôle sur
l'architecture. Presque tous les services de support technique avec lesquels j'ai
été en relation ont désespérément besoin d'aide.
LDAP est un excellent annuaire. Il peut gérer non seulement l'identification des utilisateurs (username/password) mais aussi beaucoup plus en ce qui concerne ces utilisateurs et les ressources. Au fur et à mesure nous verrons comment LDAP aide à centraliser la gestion d'un tas de choses.
ISPMan est le logiciel que j'ai écrit, pour éviter que les personnes du département informatique me cassent les pieds chaque fois qu'elles ont besoin de créer un nouveau domaine, d'installer un nouveau serveur web ou de modifier une entrée DNS. ISPMan est libre et il est disponible sur http://www.ispman.org. Je ne vais pas essayer de détailler ISPMan mais surtout les concepts sous-jacents. N'hésitez pas à l'essayer et à l'améliorer.
Ce FAI fournira des services de DNS, de messagerie, de courrier web,
d'hébergement, etc.
L'idée, c'est qu'un client arrive et veut un hébergement du domaine "exampledomain.com".
Ce domaine est créé de manière centralisée par quelques clics de souris, et
la magie cachée derrière s'occupe d'installer le DNS, le serveur virtuel de
messagerie et un serveur web virtuel.
Le client obtient un nom d'utilisateur ftp pour accèder à son serveur
web/ftp. Il est possible de créer autant d'utilisateurs que souhaité dans le
domaine pour l'accès à la messagerie. Les utilisateurs du domaine peuvent ou non
bénéficier d'un espace web.
Il est également possible de fournir l'accès Internet. Ce peut être une opération très simple ou au contraire quelque chose de très complexe, nous n'aborderons donc pas le sujet dans cet article :).
Chacun veut son site web et son adresse de messagerie sur le domaine. Les
services de messagerie ont été bizarrement liés aux comptes système pour le
courrier électronique. Je n'aime pas ça.
Le problème se pose à différents niveaux lorsque vous souhaitez gérer
[email protected] et [email protected] etc.
Il y a un tas de "mappages"
inutile à effectuer. Espérons que de futurs logiciels seront écrits avec les
noms de domaine présents à l'esprit.
Par exemple, Cyrus, un excellent serveur IMAP. Cyrus gère les boîtes aux lettres
(pas les utilisateurs). Il n'autorise qu'une boîte aux lettres au nom d'
"aghaffar". Si j'ai un autre client du domaine "linuxrus.com" qui veut un nom
d'utilisateur "aghaffar", alors ma chance a tourné. Je vais devoir créer une
boîte aux lettres à un autre nom et ensuite lier l'utilisateur à cette
boîte. Une autre solution aurait été de créer un utilisateur
"aghaffar.linuxrus.com" mais Cyrus a déjà utilisé "." comme délimiteur de la
boîte, je ne peux donc pas m'en servir, pas plus que je ne peux choisir "[email protected]".
Remarquons également que nous ne vivons pas tous aux Etats-Unis. Un grand nombre d'exemples de certaines listes de diffusion suggère user1@domain1 et user1@domain2. Comme si tous les noms de domaine finissaient en .com. Nous devons donc suivre la marche "username" "domain" "TLD"(Top Level Domain).
Notre architecture va prendre en compte tout cela.
Ainsi, au lieu de créer un utilisateur nommé "aghaffar", nous allons créer des
utilisateurs sous la forme "username_domain_tld".
Je ne me rappelle plus très bien pourquoi j'ai choisi "_" comme délimiteur,
mais "." n'était pas disponible à cause de Cyrus, et il y avait des problèmes
avec d'autres délimiteurs, par exemple "&" qui ne peut convenir pour les shells
ou les URL.
Voici une liste des logiciels que j'ai pu utiliser ensemble sans problème. Vous pouvez en choisir d'autres si vous le souhaitez et s'ils fonctionnent correctement.
Notre annuaire est basé sur les domaines. Nous avons les domaines, les
utilisateurs du domaine, les services du domaine, etc.
Par exemple, un utilisateur peut seulement exister dans un domaine (sauf
certains utilisateurs système tels que LDAP admin, Cyrus admin, etc)
La branche du domaine contient des informations sur les utilisateurs de ce
domaine, les données DNS du domaine, les données http du domaine, etc etc
Exemple
Ici, nous avons défini une branche du domaine "developer.ch", cette branche
possède des sous-branches pour les utilisateurs, les données DNS et les données
http.
Dans cet exemple, nous avons défini les uid, gid, répertoire home, etc pour le
domaine, puisque nous voulons que seul l'utilisateur "domain.tld" accède via ftp.
Par exemple, si la cliente qui détient developer.ch veut charger des fichiers
dans son répertoire, elle devra se loger en tant qu'utilisateur "developer.ch"
avec le mot de passe approprié pour se loger sur le serveur ftp qui en principe
permettra de passer root sur le répertoire home.. etc .. etc.. nous y
reviendrons.
Pour les autres utilisateurs, nous n'attribuons pas d'uid, gid, etc puisque nous
ne voulons pas qu'ils se logent via ftp.
Vous trouverez un fichier exemple LDIF complet
ici (ce fichier est peut-être périmé puisqu'il vient d'une machine de
service, et que j'ai ajouté des fonctionnalités dans la nouvelle version) ou
bien, utilisez ce lien si vous
voulez le montrer à votre patron (un peu périmé lui aussi...NDT: non pas le
patron!)
Une autre chose géniale, c'est que nous ne devons pas créer de comptes système
dans /etc/passwd, /etc/shadow, etc ou gérer NIS etc.
Tous les comptes sont gérés dans LDAP et l'authentification est faite
directement depuis LDAP.
Pour cela, nous allons être aidés par PAM (Pluggable Authentification Module) pam_ldap.
PAM permet de définir quel module devra prendre en charge l'authentification,
les autorisations, etc.
Par exemple, mes fichiers /etc/pam.d/imap, /etc/pam.d/pop et /etc/pam.d/proftpd
disent ceci
#%PAM-1.0 auth sufficient /lib/security/pam_ldap.so account sufficient /lib/security/pam_ldap.soMaintenant toutes les authentifications imap/pop3/ftp sont envoyées au serveur ldap. Ainsi, l'utilisateur aghaffar_developer_ch gets est authentifié et récupère son courrier même s'il n'existe pas dans le fichier passwd du système ou dans les enregistrements nis.
Pour l'instant DNS n'est pas lié à LDAP, et ce n'est peut-être pas une bonne idée de lier LDAP et DNS sauf pour Dynamica DNS qui est utilisé conjointement à DHCP. De toutes façons, nous utilisons LDAP pour stocker les informations du DNS et ensuite nous les récupérons pour créer des fichiers de zone DNS. Ceci nous permet de tout gérer de manière centralisée depuis une machine sécurisée, et sans rien changer au DNS.
Voilà à quoi ressemblent les entrées DNS dans LDAP
dn: ou=dnsdata, domain=4unet.net, o=ispman
domain: 4unet.net
ou: dnsdata
objectclass: top
objectclass: domainrelatedobject
objectclass: posixAccount
uid: 4unet.net
uidNumber: 2000
gidNumber: 1000
homeDirectory: /home/4unet.net
userPassword: {crypt}XXffGGHH
loginShell: /bin/true
|
La définition de la branche des données dns. Un compte Posix (un utilisateur) a également été défini par le même nom que le nom du domaine. Cet utilisateur est une espèce de webmaster, qui peut se loger via ftp et charger des fichiers dans des zones désignées, etc. |
dn: cn=soarecords, ou=dnsdata, domain=4unet.net, o=ispman cn: soarecords primary: ns1.4unet.net ou: dnsdata retry: 1800 rootmail: dnsmaster.4unet.net domain: 4unet.net minimum: 432000 objectclass: top objectclass: domainRelatedObject expire: 1209600 refresh: 21600 |
Ceci définit les enregistrements SOA pour le DNS de 4unet.net. Un script prend en charge l'extraction des valeurs et les formate dans un enregistrement DNS SOA afin de l'inclure dans le fichier de zone. |
dn: cn=nsrecords, ou=dnsdata, domain=4unet.net, o=ispman domain: 4unet.net cn: nsrecords ou: dnsdata objectclass: top objectclass: domainRelatedObject record: @,ns1.4unet.net record: @,ns2.4unet.net |
Et voici les enregistrements NS.
Un script va récupérer tous les attributs d'enregistrement, va les séparer par caractère "," et obtiendra ensuite la cible et le serveur de nom à ajouter au fichier de zone. |
dn: cn=mxrecords, ou=dnsdata, domain=4unet.net, o=ispman domain: 4unet.net cn: mxrecords ou: dnsdata objectclass: top objectclass: domainRelatedObject record: @,10, mx1.4unet.net record: @,100, mx2.4unet.net |
Comme ci-dessus, mais pour les enregistrements MX cette fois.
Ces enregistrements contiennent également le champ de priorité qui est ajusté en conséquence dans les enregistrements MX du fichier de zone. |
dn: cn=arecords, ou=dnsdata, domain=4unet.net, o=ispman objectclass: top objectclass: domainRelatedObject domain: 4unet.net cn: arecords ou: dnsdata record: ns1, 193.247.80.43 record: ns2, 193.247.80.44 record: @,193.247.80.43 record: @,193.247.80.44 |
Ce sont les enregistrements de base, hôte, mappage d'adresses ip |
dn: cn=cnames, ou=dnsdata, domain=4unet.net, o=ispman objectclass: top objectclass: domainRelatedObject domain: 4unet.net cn: cnames ou: dnsdata record: ftp, www record: mail, www record: *, www |
Et les CNAMES ou Alias des hôtes |
Le module LDAP doit être installé pour proftpd. Si vous souhaitez utiliser ftp
avec des serveurs virtuels, et que vous pensez qu'il sera très actif, lancez-le
directement plutôt que depuis inetd.
Pour cela, commentez les lignes ftp de votre inetd.conf et relancez le démon inetd.
Créez un groupe avec le gid 1000 nommé ftponly. Nous fournirons ce gid à tous
les domaines.
Editez votre fichier /etc/pam.d/proftpd comme indiqué dans la partie
authentification LDAP ci-dessus.
Votre fichier /etc/proftpd.conf devrait ressembler à quelque chose comme ça.
Pour lancer proftpd, vous pouvez taper /usr/sbin/proftpd et pour le tuer, killall /usr/sbin/proftpd
Compilez et installez Cyrus SASL et imapd, ainsi que le client c-sdk d'UW-IMAP . Le client sdk d'IMAP, est peut-être déjà installé sur votre système. Essayez d'abord de taper rpm -aq | grep imap. En cas de doute, compilez une version plus récente. Créez un utilisateur système nommé cyrus et un groupe mail, suivez les instructions d'installation et vérifiez que votre serveur imap est opérationnel. Lorsqu'il fonctionne, remplissez simplement votre fichier /etc/pam.d/imap comme indiqué dans la partie authentification LDAP ci-dessus.
Vous allez devoir créer un utilisateur nommé cyrus ou un autre nom
d'administrateur dans /etc/imapd.conf dans l'annuaire LDAP.
Par exemple, si votre administrateur cyrus se nomme "cyrus", vous pourrez avoir
une entrée comme celle ci-dessous dans votre annuaire ldap.
dn: uid=cyrus, ou=admins, o=ispman cn: Cyrus Admin sn: Cyrus objectclass: top objectclass: systemadmins uid: cyrus userpassword: XXDDCCYY ou: adminsISPMan crééra ces entrées pour vous lors de l'installation.
Postfix se marie très bien avec LDAP. Vous pouvez décider qu'un domaine virtuel
et qu'un utilisateur virtuel recherchent directement dans LDAP, ainsi vous
n'avez plus à préciser les domaines pour lesquels recevoir du courrier.
Par exemple, si un courrier arrive pour le domaine "perl.ch", il devrait
vérifier tous les domaines pour voir s'il en existe un du nom de "perl.ch", s'il
existe il devrait alors accepter le courrier au lieu de renvoyer "MX pour
perl.ch retourné".
mon fichier /etc/postfix/main.cf ressemble à ça
ISPMan facilite la gestion des utilisateurs. Créer un utilisateur consiste en deux étapes
ISPMan vous permet de créer des boîtes aux lettres sur n'importe quelle
machine de votre ferme. Par exemple, vous pourriez avoir mail1, mail2, mail3,
mail4 etc, chacune gérant 10,000 utilisateurs. En utilisant l'ensemble LDAP +
Postfix + Cyrus,vous pouvez délivrer le courrier sur n'importe quelle machine
du parc.
Par exemple, si un courrier arrive pour [email protected], Postfix demande au
serveur ldap d'envoyer le courrier sur l'entrée qui correspond à
[email protected], et le serveur LDAP répond
[email protected]. Le courrier est alors dirigé vers la machine nommée
mail5 dans la ferme.
Actuellement je travaille avec quelques développeurs sympas sur un proxy IMAP/pop3 fonctionnant au-dessus des serveurs de courrier sur les ports pop3 et imap et qui redirige de manière transparente les demandes faites aux machines du réseau. Ainsi, vos utilisateurs connaîtront seulement une adresse, par exemple mail.developer.ch ou pop.developer.ch à laquelle se connecter au lieu de savoir sur quel serveur de courrier réside leur boîte aux lettres.
IMP est un très bon produit pour fournir un service de courrier web aux
utilisateurs.
Vous pouvez définir un alias de mail.* dans le fichier httpd.conf d'Apache de
manière à ce qu'il pointe vers l'installation centrale d'IMP.
Par exemple, ce qui suit vient de mon installation
Je travaille sur une version légèrement modifiée d'IMP qui devra gérer les cas suivants.
|
|
Site Web maintenu par l´équipe d´édition LinuxFocus
© Atif Ghaffar, FDL LinuxFocus.org Cliquez ici pour signaler une erreur ou envoyer un commentaire à Linuxfocus |
Translation information:
|
2001-03-18, generated by lfparser version 2.8
