Résumé sur les discussions sur le GDS
	=====================================

* Information de Joël sur l'évolution du dossier de demande de GDS.
En gros la demande est en bonne voie pour la création du GDS Mathrice, 
ainsi que pour celui pour le RNBM.

* Discussions sur les projets qui ont été lancés dans la demande du GDS :

1/ Tout le monde s'accorde à dire que le noeud central de toutes formes de 
services est l'authentification. Il a été examiné quatre solutions techniques 
à ce besoin :

	a/ Concaténation des différents tables de mots de passes
		cat /etc/passwd.labos* > /etc/passwd
		cat /etc/shadow.labos* > /etc/shadow

	b/ Serveur LDAP

	c/ Kerberos (éventuellement Kerberos + LDAP)

	d/ Serveur Active Directory

La solution d/ a rapidement été supprimée, parce que elle se situe hors de 
notre domaine de compétences, de plus elle ne répond pas vraiment aux besoins 
des mathématiciens, puisqu'elle n'authentifie que des clients Windows.

La solution a/ de concaténation semble présenter plusieurs défauts, dont
notamment la présence sur les serveurs centraux de la table complète avec
tous les mots de passe. Ceci augmente d'autant le risque en cas de piratage 
de la base, Il faudrait alors modifier tous les mots de passe 
dans tous les labos qui auraient contribué à la table. Il y a aussi le risque
d'avoir le même mot de passe sur les serveurs centraux que sur les serveurs
locaux, ce qui n'est absolument pas souhaitable.

La solution c/ Kerberos semble pour tous les gens présents trop complexe, et 
a donc été abandonnée. Nous ne voyons pas non plus comment avoir une
délégation par laboratoire.

La solution b/ LDAP, suivant l'exposé et la maquette présentés la veille par
Philippe Depouilly, est retenue. Ses avantages sont la facilité de couplage
avec tous les applicatifs voulus, la facilité de la délégation, le fait
que le serveur d'authentification puisse être distinct des autres, et être
repliqué plusieurs fois, ...

Le premier problème, concernant la duplication des noms de login dans cette 
base, n'a pas été résolu de manière praticable par la technique présentée par
Philippe : celle-ci consistait à «indexer» le nom de login avec, par ex, le 
numéro de l'UMR d'appartenance. Cela étant jugé trop complexe et déroutant
pour les utilisateurs, la solution retenue est celle de la simplicité, qui 
consiste à «faire à la main» en sorte qu'il n'y ait pas de doublons.
Les développeurs de l'interface Web sont d'accord pour implémenter un petit
algorithme pour tester d'éventues doublons.
Le peu de doublons éventuels semble rendre cette solution applicable.

Sur la structure de la base LDAP, un consensus rapide s'est fait pour 
s'accorder à dire que le plus simple reste une base LDAP unique, que la 
création de compte se fera sur ce serveur unique et que les laboratoires 
le désirant pourront, de façon très aisée, créer un répliqua dans leur
laboratoire. Cette dernière démarche étant fortement conseillée pour éviter 
les problèmes d'interruption de service en cas de panne réseau vers l'extérieur.

Sur la localisation physique de ce serveur, ainsi que la force humaine qui sera
derrière, Philippe Depouilly s'est porté volontaire pour prendre en charge sa 
maquette, développée il y a plus de six mois, et qui semble fonctionnelle. 
La localisation se fera donc naturellement dans le laboratoire du responsable, 
càd à Bordeaux.

Au niveau des services qui seront mis sur place, il a été retenu :

	A/ Un système de messagerie centralisé

	Le premier point sur lequel tout le monde était d'accord est qu'il 
	s'agirait d'un service de courriel autonome et qu'il n'était pas 
	question que ce service «aille» chercher les courriels auprès des 
	serveurs de messagerie de chaque laboratoire.

	Au niveau des solutions techniques, voici ce qui a été retenu après 
	discussion :

		1/ Format des boîtes aux lettres --> Maildir

		Le format mbox a été jugé trop fragile, en cas de problèmes,
		d'autant que le choix du format mbox aurait imposé de fait 
		uw-imapd qui n'est pas le serveur IMAP le plus performant 
		et de loin.

		Le format propre a Cyrus-Imapd a été jugé trop complexe et
		l'apport (à savoir la très forte «scalabilité») inutile vu 
		le volume maximal que nous pourrions avoir (<= 5000). 
		D'autre part une certaine demande sur la possibilité d'accéder 
		aux courriels sur la machine interactive (par connexion ssh) 
		directement, sans avoir nécessairement besoin de passer 
		par IMAP a été considéré comme un plus.

		2/ Serveur de SMTP 	--> Postfix

		Comme sendmail n'est pas nativement compatible avec Maildir,
		et qu'il y a une grande compétence sur Postfix, 
		le choix a été naturel.

		3/ Serveur de POPS/IMAPS	--> Courrier-imapd

			cf point 1

		4/ Serveur Webmail 	--> Horde/IMP

		Le plus commum, proposant le plus de fonctionnalités.
		D'autant plus que dans le projet Horde, il y a la présence de 
		«Golom» qui est un service de WebFTP qui sera le bienvenu
		pour remplacer le WebFTP d'origine qui n'est plus 
		vraiment maintenu.

		Il est proposé de mettre également en oeuvre SquirredMail,
		plus simple, mais plus rapide.

		5/ Service de listes de diffusion 	--> Mailman

		6/ pas de décision sur le service anti-virus

		7/ probablement SpamAssassin pour l'outil anti-spam, mais 
		d'autres solutions seront aussi envisagées.

	B/ Services de bureau virtuel

	Rapidement sont apparus nécessaires, 

		0/ en plus de l'incontournable Horde/IMP

		1/ un service de transfert/synchro de fichiers via SSH
		avec les outils scp/sftp/rsync/unison/etc...

		2/ un service de partage de fichiers via SMB/AFP, avec
		les outils Samba et Netatalk

		3/ un service de session interactive :

			- accès par SSH

			- Pas de XDM, car mot de passe en clair

		 	- on semble donc s'orienter vers l'utilisation 
			  aussi de VNC + applet Java.

		4/ pour Windows, après discussion, la solution, si 
		elle fonctionne, serait d'utiliser une connexion Web 
		via un navigateur pour se connecter, via ICA, 
		sur un serveur Metaframe, vers des applications 
		Windows publiées anonymement.

		Les solutions autorisant une session Windows complète 
		sur le serveur ont été jugées trop complexes 
		à mettre en oeuvre.

		5/ Sur Horde/IMP seront rajoutées des possibilités de WebFTP 
		et de gestion de .forward et .procmailrc

	
	C/ Le "filer" (serveur de fichiers des utilisateurs) sera 
	pour commencer, sur le site de Chevaleret. Un tel service  
	y fonctionne déjà, cela entraînera  
	un minimum d'investissements financier et humain.

	Un échange a eu lieu sur le pertinence d'un système de quota.
	Un consensus a abouti sur de la gestion à «la main» et surtout du 
	«wait and see».


	D/ Le choix de l'OS supportant ces services sera à la discrétion 
	des équipes qui gèreront ces services.


	E/ Sur les problèmes de localisation physique, ont été soulevés 
	le problème de la qualité globale du réseau qui hébergera le service, 
	mais aussi la politique de sécurité du site. Pour l'instant :

	Filer, SMTP, POPS, IMAPS, Mailman, SSH, Samba, Netatalk, 
	Windows, replica LDAP 
		-> Chevaleret

	Master-LDap, WebMail/Horde/IMP/, SquirredMail
		-> Bordeaux


	F/ Un autre service qui semblerait être la «killer-application» est 
	d'offrir la possibilité aux mathématiciens qui seront dans la base 
	LDAP de pouvoir, après authentification, d'accèder aux sites de revues 
	en ligne (MathScinet, Springer, etc...) de n'importe où.

	Le principe est le suivant :

		1/ On monte un service de proxy (au sens large).

		2/ On couple ce service à l'authentification  via la base LDAP.
	
		3/ Le RNBM négocie avec les éditeurs pour que ce serveur proxy 
		soit dans leurs listes d'adresses IP autorisées. On argumentera 
		que les mathématicien(ne)s étant identifiés nominalement, 
		le contrôle est beaucoup plus rigoureux que par simple adresse 
		IP dans les labos.

	De nombreuses solutions techniques ont été mise en avant :

	1/ Tunnel SSH avec un fichier .pac ad-hoc. L'utilisateur fera un tunnel 
	SSH depuis son poste (ce qui fonctionne depuis n'importe quel OS) 
	et en mettant le bon .pac, il accèdera via ce tunnel au proxy.
	Pour mémo, les fichiers .pac désignent les fichiers de configuration
	automatiques de proxy.

	2/ Un système de portail Java, en utilisant des servlets qui permettent 
	de faire de la ré-écriture à la volée des pages Web et qui les 
	réaffichent. C'est donc le serveur de container d'applets qui va 
	chercher les informations auprès de l'éditeur. Néammoins il a été fait 
	remarquer que nous n'avons pas encore de compétence sur cette 
	technologie, et que ces solutions n'ont jamais été validées par 
	notre communauté.

	3/ Le labo de l'univ. X arrive à convaincre son CRI
        - soit d'avoir son propre proxy au sein du labo, qui serait configuré
        pour être client d'un proxy national,
        - soit de modifier le proxy impératif du CRI pour que celui-ci
        soit lui-même client d'un proxy national.

        Ensuite l'utilisateur configure classiquement son navigateur pour être
        client de ce proxy local.

        Dans les deux cas, de manière transparente lors du premier
        accès au proxy national (sous Squid), une authentification
        LDAP serait demandée.

        Et après, c'est transparent.

	4/ En utilisant une particularité du serveur Squid, on crée des alias 
	pour les quelques sites qu'on veut proposer aux utilisateurs. 
	Ce dernier se connecte via son son navigateur Web à une URL du genre
                http://springer.math.cnrs.fr/
        qui lui demande aussi une authentification (cette fois-ci
        au sens HTTP) et cela fait ce qu'il faut. 

	Comme ces solutions ne sont pas du tout antagonistes, il a été convenu
	d'un commun accord de toutes les mettre en place.


* Voici en récapitulatif la liste des projets avec leurs volontaires et la
localisation du service :

Nota: Certaines personnes se sont proposées pour faire de l'hébergement de 
services, c'est-à-dire maintenir un OS à jour et les "développeurs" ne 
s'occuperaint que des services. Mais vu la compétence des gens et l'existence 
d'outils modernes, aucune demande n'a été faite dans ce sens. Donc dans la liste 
qui suit les responsables du service sont aussi responsables de l'OS, 
du hardware, etc.

Les «relecteurs» sont ceux qui sont d'accord pour aller relire les 
configurations et autres scripts.

Il est fortement souhaité que largement plus d'une personne ait la
compréhension précise de chaque service, et que cet ensemble de personnes
ne soit pas réduit à des personnes du même site. Aussi cette liste est
provisoire et chacun est invité à s'y inscrire.

Chaque serveur ci-dessous correspondra dans un premier temps à une vraie
machine physique, prétée généreusement par le site d'accueil. Dans un tout
premier temps, toute "vieille" poubelle fera l'affaire. Dans un second temps,
il sera étudié la possibilité de mettre cela sur des machines "raisonnables".

	Serveur LDAP principal :
			
		Localisation : Bordeaux
		OS : Linux (?)
		Responsables : 
			Philippe Depouilly, Emmanuel Lethrosne, 
			Emmanuel Le Guirriec, Mickael Marchand
		Relecteurs   :	 
			Albert Shih

	Serveur de fichiers (filer) :

		Localisation : Chevaleret
		OS : FreeBSD
		Responsables : 
			Albert Shih, Joël Marchand

	Configuration du routeur de Chevaleret :

		Localisation : Chevaleret
		OS : Foundry OS
		Responsables : 
			Albert Shih, Joël Marchand
		Relecteurs   : 
			Adrien Ramparison

	Serveur LDAP replica :

		Rappel : Il serait bien que chaque laboratoire possède dans 
		un coin un tel serveur. Ceux qui n'auront pas le temps 
		pourront naturellement, soit utiliser le serveur 
		principal, soit utiliser celui d'un collègue. 
		En sachant que les deux ne sont pas contradictoires.

		Pour celui de Chevaleret :
		OS : FreeBSD
		Responsables : 
			Albert Shih, Joël Marchand
		Relecteurs:
	
	Serveur SMTP/IMAPS/POPS/Mailman/anti-virus/anti-spam :

		Localisation : Chevaleret
		OS : Linux Redhat 9
		Responsables : 
			Zouhir Hafidi, Bernard Perrot, Joël Marchand
		Relecteurs :
			Albert Shih

	Serveur SSH/VNC/SMB/AFP
		
		Localisation : Chevaleret
		OS : Linux Debian stable
		Responsables :  
			Jacques Foury, Laurent Renault
		Relecteurs :
			Joël Marchand

	Serveur WebMail/IMP/Horde etc...

		Localisation : Bordeaux
		OS : Linux (?)
		Responsables : 
			Philippe Depouilly, Damien Ferney, Stéphane Aicardi
		Relecteurs :
			Albert Shih

	Serveur Proxy

		Localisation : Chevaleret	
		Responsables : 
			Albert Shih, Joël Marchand
		Relecteurs :

Le planning retenu est :

- premier jet de la maquette pour Noel

- ouverture des services au sein de Mathrice et de nos power-users,
	pour rodage, serrage de boulons, etc,  et usage de ces services
	au sein de cet ensemble < 100 utilisateurs avertis, jusqu'en mars 2004

- si OK, annonce à la communauté après nos prochaines rencontres.


Divers :

- nous pourrons en principe avoir d'ici début 2004 des vrais certificats CNRS 
  pour les services sur SSL.

- d'autres tâches sont à définir et répartir :

	- rédaction d'une charte d'usage et d'une liste d'engagements 
	  (en fait de non-engagements à qualité de service, disponibilité, 
	  durée) -> dans un premier temps, on démarre en mode "best effort".

	- rédaction d'une documentation d'usage de ces services