La base centrale sera donc une base SQL (Postgres).

J'ai d'ores et déjà un moteur composé:

• d'un coeur configurable en front-end capable d'utiliser diverse bases
• des plugins capable d'acceder avec les même appels aux infos de diverse bases (actuellement fichier UNIX et SQL).

Ces parties constituent le moteur réel de l'application, et je commence à avoir des outils en ligne de commande pour piloter le tout.

L'idée phare etant d'avoir des bases diverses et variées et de pouvoir dire "transfert les infos de la BASE x vers la BASE y indépendement de leur format ou stockage. Il y a bien entendu une base maitresse qui contient tout (SQL donc), et il sera possible d'ecrire (ou réutiliser) des modules pour gérer d'autres bases (l'intranet par example).

La deuxième partie consiste à écrire une application web pour gérer le tout.

Intervient deux questions:

1) que voulons nous stocker dans les diverses bases ?

La base maitresse doit contenir toutes les informations devant être propagées vers les autres bases. Il me faut donc une liste assez exhaustive des informations que nous voulons gérer.

En premier lieu il y'a les champs UNIX (/etc/{passwd,shadow,group}), mais cette partie ne me pose pas trop de problème, je la maitrise largement.

Ensuite il y a les champs de l'AD, et là en revanche, même si j'en connais pas mal, je ne suis pas le mieux placer pour savoir ce qui est utilisé. Il me faut aussi savoir comment vous gérer les utilisateurs au sein de l'AD (est-ce que tout les utilisateurs sont dans la même OU ? les changez-vous d'OU ? quels infos devront nous avoir en commun avec les autres bases ?).

Enfin il y a le reste (mail, annnuaire, etc...), en sachant que le but n'est pas de créer un module de gestion complet d'entreprise et qu'il n'est pas besoin de dupliquer les bases de gestion du CNRS (labintel and co).

2) Le utilisateurs doivent-il pouvoir changer des informations dans la base eux-même ? si oui lesquelles ? Seront nous les seules à toucher à cette base ?

Nous sommes d'accord que l'utilisateur doit pouvoir changer son mot de passe. Mais cela implique un droit de lecture/ecriture controlé dans la base centrale. Je pense qu'il serait aussi souhaitable que l'utilisateur puisse changer son numéro de téléphone, bureau, etc, si ces informations sont stockés. Le personnel de l'administration peut aussi avoir besoin de changer des choses.

Tout ceci implique qu'il faut coder un module de gestion d'accès dans lequel on pourra définir des groupes qui auront donc des droits sur certains champs seulement.

Non pas que ce soit très difficile à faire, mais ça demande du temps, d'y réfléchir avant et surtout de valider le tout en terme de sécurité.

Donc j'aimerais bien avoir une idée de ce que l'on veut avant lancer du code un direction.

Cordialement.

================================================= Date: Thu, 23 Apr 2009 08:53:39 +0200

Merci d'avoir posé le sujet, cela permettra de réunir les éléments, et les relations entre les éléments. Et mettre cela sous forme d'un document (court et concis).

Ma première question est: est-il possible pour une personne (son login ? son identifiant unique - quel sera l'identifiant unique ?) d'avoir dans la base les périodes pendant lesquelles cette personne était sous contrat ou convention au Latmos ? Donc une trace de sa présence, permettant, par exemple, de déterminer automatiquement sont status de votant (l'AG d'un labo étant défini dans un document de réference du CNRS comme l'ensemble de personnes qui ont plus d'un an de présence continue au labo tous contrats confondus).

Ce sujet de "trace dans la base" est point d'être trivial à ma connaissance.

Voilà pour commencer.

Elisabeth

================================================= From: "Brigitte Piron" <brigitte.piron@…> Date: Thu, 23 Apr 2009 09:35:40 +0200

• est-ce que tout les utilisateurs sont dans la même OU ?

oui OU=utilisateurs-LATMOS et les groupes= Gvelizy-utilisateurs,

Gverrieres-utilisateurs, Gjussieu-utilisateurs, Gstquentin-utilisateurs ca peut servir pour les strategies

les changez-vous d'OU ?

non

Brigitte

================================================= Salut Olivier,

peut etre est ce le moment d'ouvrir un Wiki sur forge (en prive pour Oric et eventuellement Admg) ? Ca pourrait etre plus facile de realiser le cahier des charges de maniere cooperative ?

Merci et A+

================================================= Date: Thu, 23 Apr 2009 09:52:18 +0200

Comme on avait propose en fevrier,

Si modifications de parametres par l'utilisateur : il ne faut pas laisser l'utilisateur toucher a la/les bases.

Donc on pourrait passer par la creation de fichier XML ( un fichier , avec des rubriques par utilisateur, par exemple)

et regulierement, un script lit ces fichiers et remplit la/les base

Brigitte

================================================= Date: Thu, 23 Apr 2009 13:47:49 +0200

• Brigitte Piron (brigitte.piron@…) wrote:

  Comme on avait propose en fevrier,

  Si modifications de parametres par l'utilisateur : il ne faut pas laisser l'utilisateur toucher a la/les bases.

Pourquoi l'utilisateur ne doit-il pas toucher la base ? Dans mon idée, on offre une interface web avec authentification, seuls les champs modifiables selon les privilèges sont proposés et l'application mets à jour directement la base (voir si possible en instanné les bases).

Donc on pourrait passer par la creation de fichier XML ( un fichier , avec des rubriques par utilisateur, par exemple)

et regulierement, un script lit ces fichiers et remplit la/les base

Si j'ai tout suivi (ce dont je ne suis pas sà»r), l'utilisateur créer un fichier xml (comment, via appli web ?) un fichier, puis les données de ce fichier sont intégrées dans la base principale puis recopié vers les autres bases ?

J'y vois de nombreux inconvénients:

• ce n'est pas instantanné: il faut attendre la prochaine synchro
• il faut gérer un format de plus
• il semble qu'il faille passer le mot de passe dans sa version en clair, cela veut-il dire qu'on stocker les mots de passe dans des fichiers sans chiffrement ?
• je ne vois ce qu'apporte le passage par un format supplémentaire dans la mesure o๠tu sera automatique, et que donc le gain en sécurité ne me parait pas évident.

================================================= Date: Thu, 23 Apr 2009 14:14:21 +0200

• Francis Vivat (francis.vivat@…) wrote:

  Salut Olivier,

  peut etre est ce le moment d'ouvrir un Wiki sur forge (en prive pour Oric et eventuellement Admg) ? Ca pourrait etre plus facile de realiser le cahier des charges de maniere cooperative ?

J'ai crée un trac, même si le wiki n'est pas utilisé, il intègre un navigateur SVN et un gestionnaire de bogues dont je me sers comme pense-bête.

​https://forge.ipsl.jussieu.fr/latmos

Sont autorisé les comptes de forge étant dans le groupe 'latmos'.

Compte tenu du contenu du subversion (fichier de configuration de nos machines), tout les parties du trac ne sont ouverte qu'après autentification.

Cordialement.

================================================= c 'est juste des propositions:

proposition 1: ==========

• soit l'utilisateur fait des modifs qui s'inscrivent dans un fichier xml du style :

<?xml version="1.0"?> <users>

<user login="toto" password="ee11cbb19052e40b07aac0ca060c23ee"/> <user login="titi" password="21232f297a57a5a743894a0e4a801fc3"/> <user login="tata" password="3c78b35502b2693fefdfc51cba3a53a5"/>

</users>

et a la fin du formulaire, le bouton [ok] envoie une application PHP

• qui lit ce fichier
• et repartit les modifs directement sur les bases AD,NIS,etc

proposition 2: ==========

• soit l'utilisateur fait des modifs qui s'inscrivent directement dans une

base commune (postgres par exemple)

• et une application , en automatique, lit regulierement cette base pour

voir si elle a ete modifiee,

et dans ce cas, envoie les modifs sur les autres bases

Brigitte

=================================================

• Brigitte Piron (brigitte.piron@…) wrote:

  c 'est juste des propositions:

  proposition 1: ==========

  • soit l'utilisateur fait des modifs qui s'inscrivent dans un fichier xml du style :

  <?xml version="1.0"?> <users>

  <user login="toto" password="ee11cbb19052e40b07aac0ca060c23ee"/>

Mot de passe: user

<user login="titi" password="21232f297a57a5a743894a0e4a801fc3"/>

Mot de passe: admin

<user login="tata" password="3c78b35502b2693fefdfc51cba3a53a5"/>

Mot de passe: manual

Le chiffrage d'un mot de passe par l'utilisation de son md5sum n'est absolument pas fiable, on trouve facilement sur le net des bases de données de correspondance pour des "mots" de moins de 10 caractères.

Là j'ai utilisé: ​http://md5.rednoize.com/

Ensuite le md5 n'est pas réversible, avec un md5 je ne peux retrouver facilement le mot de passe en clair pour l'envoyer dans l'AD.

</users>

et a la fin du formulaire, le bouton [ok] envoie une application PHP

Tout ce que j'ai fait est en Perl, je ne pense pas en changer, surtout maintenant que pas mal de code est fonctionnel.

• qui lit ce fichier
• et repartit les modifs directement sur les bases AD,NIS,etc

proposition 2: ==========

• soit l'utilisateur fait des modifs qui s'inscrivent directement dans

une base commune (postgres par exemple)

• et une application , en automatique, lit regulierement cette base pour

voir si elle a ete modifiee,

et dans ce cas, envoie les modifs sur les autres bases

J'optais plutà´t pour cette solution, mais en lançant la synchronisation (si elle n'est pas trop couteuse) à chaque modif, voir envoyer les modifs dans toutes les bases en même temps, selon comment se passerons les tests en situation réel.

================================================= Date: Thu, 23 Apr 2009 15:43:22 +0200

c 'etait pas la peine de les decoder, ce n'etait que des exemples.

Bon PERL Brigitte

================================================= une base centrale avec tous les champs= pgsql une base d'authentification unix = nis une base d'authentification windows = ad une base applicative = openldap

Selon moi le minimum :

---

Générique: Nom Prénom Status/type=contrat, compte générique,.... date de fin prévu responsable identifié

Avec NIS : Login uid gid=dépendant du status Groupes Mot de passe Gecos = Nom + Prénom home_unix shell

Avec OpenLDAP : Login uid gid=dépendant du status groupes Mail Mot de passe téléphone(s) bureau(x) site

Avec AD: Login gid + groupes Mot de passe home_windows OU

(à compléter)

---

Après, il faut voir ce que l'on veut faire pour les alias,revalias,listes,....

Une interface ou un utilisateur peut modifier directement ses champs me semble le mieux. L'usage de XML rajouterais une couche pour arriver au même résultat.

Pour les clients mails, ils pourront se connecter à l'openldap. L'intranet devrait se connecter à l'openldap/ ou directement se coupler avec la base à voir en fonction des possibilités. L'annuaire pourra être extrait avec une requette ldap ou SQL.

Si cela pouvait se coupler à la demande d'ouverture de compte cela serait bien !

A suivre....

Yann

================================================= Date: Mon, 27 Apr 2009 10:02:19 +0200

parametres pour l'AD:

Login Mot de passe nom prenom descritptif telephone adresse mail date fin de compte gid + groupes home_windows OU groupes windows

Brigitte

================================================= Date: Mon, 27 Apr 2009 10:32:42 +0200

• Brigitte Piron (brigitte.piron@…) wrote:

  parametres pour l'AD:

  Login Mot de passe nom prenom descritptif

Qu'est-ce que contient ce champs ?

telephone adresse mail date fin de compte gid + groupes home_windows OU groupes windows

Quelle(s) différence(s) fais-tu entre gid/groupes et "groupes windows" ?

================================================= Date: Mon, 27 Apr 2009 13:47:01 +0200

---

To: "Brigitte Piron" <brigitte.piron@…> Cc: "oric" <oric@…> Sent: Monday, April 27, 2009 1:42 PM Subject: Re: [oric] Base de compte de centrale: contenu

• Brigitte Piron (brigitte.piron@…) wrote:

  parametres pour l'AD:

  Login Mot de passe nom prenom descritptif

Qu'est-ce que contient ce champs ?

==> ex : TILDE - verrieres - stagiaire de X

IMPEC - velizy - cdd

telephone adresse mail date fin de compte gid + groupes home_windows OU groupes windows

Quelle(s) différence(s) fais-tu entre gid/groupes et "groupes windows" ?

==> gid : groupe NIS, si existe ==> groupes windows :

ex : des groupes par site, pour traiter les strategies du domaine

(Gvelisy-utilisateurs,Gjussieu-utilisateurs,Gverrieres-utilisateurs

...)

=================================================

• Brigitte Piron (brigitte.piron@…) wrote:

  ---

  <olivier.thauvin@…> To: "Brigitte Piron" <brigitte.piron@…> Cc: "oric" <oric@…> Sent: Monday, April 27, 2009 1:42 PM Subject: Re: [oric] Base de compte de centrale: contenu

  • Brigitte Piron (brigitte.piron@…) wrote:

  Quelle(s) différence(s) fais-tu entre gid/groupes et "groupes windows" ?

  ==> gid : groupe NIS, si existe ==> groupes windows :

  ex : des groupes par site, pour traiter les strategies du domaine

  (Gvelisy-utilisateurs,Gjussieu-utilisateurs,Gverrieres-utilisateurs ...)

Donc si j'ai tout suivi, les groupes windows sont les groupes tels que gérés par windows pour windows.

Dans ces groupes windows il y a des groupes qui n'ont pas d'autres raison d'être que la gestion des stratégies windows (Gvelisy-utilisateurs and co).

Mais j'imagine qu'il y a aussi des groupes relatif à l'activité du labo, comme les groupes d'équipes, et que ceux-ci devraient être synchrone avec les groupes UNIX (je suis dans le groupe ORIC sous windows et sous UNIX).

Notre base de comptes n'a pas à priori à gerer les groupes de strastégie, en revanche il faudrait qu'elle gère les groupe de "travail".

Ais-je tout bon ?

================================================= Date: Mon, 27 Apr 2009 15:08:23 +0200

---

Cc: "oric" <oric@…> Sent: Monday, April 27, 2009 2:16 PM Subject: Re: [oric] Base de compte de centrale: contenu

• Brigitte Piron (brigitte.piron@…) wrote:

  ---

  <olivier.thauvin@…> To: "Brigitte Piron" <brigitte.piron@…> Cc: "oric" <oric@…> Sent: Monday, April 27, 2009 1:42 PM Subject: Re: [oric] Base de compte de centrale: contenu

  • Brigitte Piron (brigitte.piron@…) wrote:

  Quelle(s) différence(s) fais-tu entre gid/groupes et "groupes windows" ?

  ==> gid : groupe NIS, si existe ==> groupes windows :

  ex : des groupes par site, pour traiter les strategies du domaine

  (Gvelisy-utilisateurs,Gjussieu-utilisateurs,Gverrieres-utilisateurs ...)

Donc si j'ai tout suivi, les groupes windows sont les groupes tels que gérés par windows pour windows.

==> tout a fait, t'as bien suivi

Dans ces groupes windows il y a des groupes qui n'ont pas d'autres raison d'être que la gestion des stratégies windows (Gvelisy-utilisateurs and co).

==> tout a fait

Mais j'imagine qu'il y a aussi des groupes relatif à l'activité du labo, comme les groupes d'équipes, et que ceux-ci devraient être synchrone avec les groupes UNIX (je suis dans le groupe ORIC sous windows et sous UNIX).

==> actuellement, il n'y a pas de groupe comme tu l'imagines.

mais on peut toujours en creer

Notre base de comptes n'a pas à priori à gerer les groupes de strastégie, en revanche il faudrait qu'elle gère les groupe de "travail".

==> Si c'est uniquement un parametre a ajouter dans ta config,

ca serait bien de les rajouter, sinon on le fera la la main, y a pas de probleme

Ais-je tout bon ?

==> c'est comme tu le sens !!! Brigitte