Hello,
We are currently testing LDAP on an OSCAR cluster. We ran into several
problems :
The generation of SSH key is based on the reading of the /etc/passwd
file. This is not correct for an LDAP based cluster because the
administrative information is _not_ in /etc/passwd.
Each time /etc/passwd is used in OSCAR, we should use "getent passwd"
that "gathers entries from the specified administrative database using the specified
search keys. Where database is one of passwd, group, hosts, services, protocols, or
networks."
(from the man page).
The getent command will allow OSCAR to support any kind of
authentification (LDAP, NIS, NIS+, file, ...) if we use getent instead
of reading the /etc/(passwd|group) file.
[ I opened a bug report for that on SF.
http://sourceforge.net/tracker/index.php?func=detail&aid=678323&group_id=9368&atid=109368
As we are in code-freeze or so, I think it should wait the post 2.2
stuff because it will affect a key component of OSCAR ]
Anyway, once this is done, there is two solutions :
1) Configure only the OSCAR head node so that he use pam ldap on an external
LDAP server for authentification.
Then the administrative files (/etc/(passwd|group|shadow)) can be
generated from the LDAP entries (with the getent utility).
This is a relatively easy task and we need minimal information from
the user when configuring the head node (LDAP server address,
user/password, LDAP branch to use for authentification).
Once this is done, regular opium actions will distribute the
administrative files to the node as it is now the case.
Advantages : - Easy to set up
- Good integration with the existing OSCAR
installation.
Disadvantages : - Some home made scripts (maybe distro dependent)
- Changing passwd on node will not change the "master"
password on the LDAP server.
- Passwd can be changed only on the head node (that
will upate the LDAP server)
2) Make an oscar_ldap server with an interface in the private network.
This can be a replicate of another LDAP server (main) or from only a
branch of the users (group of users allowed to use the cluster).
This will define the "oscar_ldap" server in the private network of
the nodes.
Then all the nodes can be set so that their authentification used
pam_ldap and the "oscar_ldap" server for authentification.
Disadvantages : - Server duplication is very site dependent. Can provide
some doc but very difficult to fully automatize
- Difficult to make an OSCAR package with that
Advantages : - Passwd will always be synchronised and opium will be
more or less useless.
- Passwd can be changed on any computer and the LDAP
server will be updated correctly.
- Less distro dependant for the client (affect only the
pam component which is, I think, very standard...).
We started with an implementation of 2) but were stopped by the
/etc/passwd instead of "getent passwd" bug and we are now doing 1) which
seems easier and more "packagable". 2) will certainly be in the
documentation part of the OSCAR-LDAP package unless everyone told us
that this is the way they want to set up their OSCAR-LDAP cluster ;-)
Ben
--
Benoit des Ligneris Etudiant au Doctorat -- Ph. D. Student
Web : http://benoit.des.ligneris.net/
Mydynaweb Developpe(u)r: http://mydynaweb.net/
Centre de Calcul Scientifique http://ccs.USherbrooke.ca/
OSCAR Symposium-May 11-14 http://oscar2003.ccs.USherbrooke.ca/
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
