Hey !

Merci beaucoup Calibal pour le wiki ! Super bonne idée ! ChapO

Et vous avez raison les gens... pour faire ça propre et pas cher faut s'installer une petite Debian et se le configurer à la main comme on veut. C'est pas la première fois qu'on me le dit. J'avais juste espéré pouvoir éviter de tout configurer dans les fichiers de config à la main parce que ça prend pas mal de temps. Mais apparement, c'est comme ça que c'est le mieux...

Vous croyez qu'une Debian avec tout ça, ça peut tourner sur un Duron 900Mhz ?

Sinon, je me ferai une petite config récente pour par cher. La puissance brute c'est pas un pb. Il suffit de se faire une petite config avec surtout pas mal de RAM et de Stockage pour que ça marche.

Je vous tiens au courant, je pense que j'aurais pas le temps de m'y atteler vraiment d'ici fin février mais ça fait un moment que ça me travaille. Appremment je peux compter un peu sur vous pour m'aider si besoin ?

@ Tetio : je ne te (vous) oublie pas

Bonsoir ! (ou bonne nuit)

J'ai commencé à me renseigner sur les différents éléments d'une config comme celle de Helgrind. A quoi ils servent, comment ils s'articulent, tout ça...

Comme un bon schéma vaut mieux qu'un long discours. Voici ce que j'ai compris des différents services :



J'ai bon ?

Ya encore quelques trucs que j'ai pas compris... par exemple, par quel protocole discutent postfix et procmail ? et aussi, à quoi sert LDAP pour postfix ? seulement aux domaines ? et aussi, il semblerait que en fait on peut rajouter la couche kerberos pour quasiment toutes les applications utilisant LDAP. Est-ce que c'est ce que tu as fait ?

Et puis plein de questions encore... mais je vais continuer à me renseigner.

J'ai vu qu'il y avait aussi des moyens de simplifier l'architecture au moins pour mettre en place les choses au départ. Je vais faire un schéma d'une archi simplifiée...

Macquicalement

Et moi qui pensais qu'on avait inventer l'ordinateur pour se simplifier la vie ... !!!!

Ca à l'air correct sauf pour samba, ça serait plutôt samba <---> LDAP.

En attendant, pour pouvoir mettre les mains dans le camboui et vraiment tester cette config, j'ai rappatrié mon serveur Web sur Windows avec WampServer... C'est laid mais ça marche.

Comme ça je vais pouvoir commencer à installer la Débian sur le Duron 900MHz Il en aura vu de toute les couleurs ce vieillard. C'était mon premier PC perso (les autres étaient à la famille).

Macquicalement

Bonjour !

Allons-y pour les explications du dimanche matin...

Ceci est un serveur web tout ce qu'il y a de plus standard :
Le serveur Apache répond aux requêtes HTML sur le port 80, transmets les requêtes PHP au serveur PHP qui lui répond avec des pages HTML (générées grâce au PHP donc). Le serveur MySQL est un serveur de base de donnée tout ce qu'il y a de plus standard, ça sert pour n'importe quel forum par exemple... MySQL possède une interface "web" de gestion : phpMyAdmin. Le navigateur fait donc une requête à Apache qui la transmet à PHP et PHP va chercher les infos sur la base de donnée MySQL grâce à phpMyAdmin pour pour pouvoir générer les pages à afficher.

Ceci est un serveur FTP standard également :

Le serveur FTP (ici ftpd mais il en existe plein d'autres) reçoit les requêtes (de type FTP) sur le port 21 et les traîte selon le protocole. Ne figure pas ici le système de fichier dans lequel ftpd va piocher.

Même chose pour le serveur SSH qui reçoit ses requêtes sur le port 22.

Pour les gens qui ne connaissent pas SSH, en (très très) gros, c'est une manière d'ouvrir une session en console sur une machine distante.

Idem (habituellement que sur le réseau local mais rien n'empêche d'ouvrir les ports pour l'étendre au WAN, reste des questions de sécurité...) pour les serveurs samba (partage de fichier, protocole SMB, port 445, généralement couplé au NetBios, port 139) et daapd (partage de musique, notamment par iTunes, port 3869).


Restent le mail et le rôle de LDAP dans tout ça. Commençons par le mail et avec un cas simple :

PostFix est ce qu'on appelle un MTA pour Mail Transfert Agent. Il reçoit des messages sur le port 25 par le protocole SMTP et décide (selon le nom de domaine : ce qu'il y a après le @) de les prendre en charge ou non. S'il les prend en charge il les passe à un module qui s'appelle le MDA pour Mail Delivery Agent. Celui-ci se charge de les distribuer, donc de les déposer dans les bonnes boîtes aux lettre (représentées par mailboxes sur le schéma). Enfin, pour les clients (MUA : Mail User Agent) tels que Mail.app ou ThunderBird, il faut permettre l'accès à ces boîtes par un des protocoles POP ou IMAP. C'est le rôle de courier qui vient lire les boîtes selon les requêtes des clients.

Il y a une analogie extrêmement simple avec le courrier réel : vous postez une lettre dans une boîte jaune de la poste. Ça c'est l'envoi, la boîte jaune est le premier MTA que la lettre rencontre. La lettre ensuite est prise en charge par la poste et traverse plusieurs centres de tri avant d'arriver au bon. Chacun des centres de tri est un MTA qui accepte ou non le message selon sa destination. Puis, une fois au bon centre de tri, un facteur prend en charge la lettre et la pose dans votre boîte aux lettres. C'est le MDA. Enfin, vous sortez (en robe de chambre) chercher votre courrier dans votre boîte, c'est le MUA. La clé de la boîte aux lettre joue le rôle courier sur le schéma. Voilà pour le premier cas. Passons à une configuration un peu plus corsée :
Ici, nous voyons arriver 3 agents en plus. Commençons par procmail. procmail remplace en fait le module MDA de postfix. C'est à dire qu'il prend en charge de manière bien plus complète la distribution des messages. postfix se limite donc à faire le MTA (ie à recevoir) et les transmets à procmail pour la distribution. Ici, procmail interagit avec spambayes qui est chargé de scanner les messages pour filtrer les virus/spams, puis si les messages son "propres" procmail continue son travail et les distribue dans les boîtes appropriées. Je ne détaillerai pas plus ici mais procmail est uniquement un MDA donc il a beaucoup plus de fonctions que le module MDA de postfix. D'où son utilisation.
Vient alors fetchmail qui lui, est en quelque sorte un relai de la poste. C'est à dire qu'il est entre MTA et MUA (sans être MDA) il va chercher sur les boîtes aux lettres que vous lui indiquez les messages (en POP ou en IMAP donc comme un MUA) et les transmets à postfix (en SMTP, d'où MTA) pour les délivrer à une autre adresse. C'est ce qui vous permet de rediriger automatiquement des messages de votre boîte GMail sur votre boîte MobileMe par exemple. Voilà pour le mail (ouf).

Enfin le rôle de LDAP dans tout ça ? LDAP est une base de donnée dont la structure est basée sur un arbre de recherche. Ce qui en fait une base de donnée très efficace pour la recherche et la lecture de donnée (et moins efficace pour l'écriture ou l'ajout). C'est pour cela qu'elle est utilisée ici pour référencer les utilisateurs, leur mot de passe, leurs droits, adresse mail etc. L'intérêt majeur est de rassembler dans une seule base de donnée le compte et les carctéristiques d'un utilisateur pour tous les services mentionnés précédemment. Chaque utilisateur n'a alors qu'un seul identifiant et mot de passe pour tous les services et c'est LDAP qui autorise ou non les différents service à donner acces à cet utilisateur (d'où le terme "authentification centralisée").

Il reste quelques détails me direz-vous... et c'est vrai ! Le premier étant celui-ci :

En effet, postfix, lui en tant que MTA n'a pas besoin d'identification des utilisateurs. Donc ce n'est pas pour cela qu'il interagit avec LDAP. Postfix vient en fait chercher dans LDAP les domaines de mail (ce qu'il y après le @) qu'il reconnait comme sien. En effet, l'organisation de LDAP repose sur ces informations (c'est la racine de l'arbre de recherche) donc il est très facile pour postfix de venir lire ces infos dans LDAP, plutôt que de les stocker (surtout dans le cas où il y en a plusieurs).

Et puis ceci :

Ce n'est que la représentation de ce que l'on appelle communément un "webmail" c'est à dire une interface pour lire ses mails dans un navigateur web. Celui-ci fait une requête HTTP à Apache qui appelle PHP qui appelle les fonctions définies par squirrelmail qui est en fait un MUA communiquant avec courier par le protocole IMAP et va donc chercher les messages dans votre boîte aux lettre, puis renvoie le résultat à PHP qui génère les pages HTLM pour Apache qui les envoie à votre navigateur. Simple non ?

Et c'est exactement le même principe pour l'administration web de LDAP :

Vous ouvrez votre navigateur à la bonne adresse, Apache appelle PHP qui appelle les fonctions définies par phpLDAPadmin qui, elles, permettent de voir et d'interagir avec la base de donnée LDAP et renvoie les donées dans le sens inverse pour vous les afficher.

C'était d'ailleurs exactement le même principe (avec MySQL à la place de LDAP) dans le serveur web présenté en tout premier, ça ne vous a pas gênés si ? :


Et voilà !! Assemblez tout ça façon IKEA et vous aurez le schéma complexe que j'avais posté. Pas si compliqué finalement

NB : j'ai laissé volontairement de côté Kerberos pour le moment que je n'ai pas encore vraiment compris son fonctionnement donc je ne voudrais pas raconter trop de bêtise.
NB2 : Évidemment, j'ai simplifié pas mal la description et je ne suis pas du tout specialiste des serveur alors il est probable qu'il y ait des choses à corriger. N'hésitez pas à me le dire... Ça pourrait faire un joli totu pour LM une fois propre

Macquicalement

BenCello

Oula ! ben c'est pas plus simple pour moi

Il va me falloir du temps et des recherches pour comprendre le système.

Sans vouloir te vexer, vivement un serveur pour les nuls d'Apple.
Je ne peux malheureusement pas t'aider, même si je comprends les schéma, c'est trop complexe pour moi, même clairement expliqué, je ne retiens pas après coup.
Mais même avec toutes ces connaissances, tu n'arrives toujours pas à faire communiquer tous tes ordinateurs ?