Hi,
* Jeremy Enos <[EMAIL PROTECTED]> [03-04-03 19:04]:
> sync_users (opium) should probaby be modified if LDAP ends up being
> supported. I assume the opium/etc/*files* would be for a cache of user
> account info? If so, I would think the originals themselves could serve as
> a user acct cache for the other auth methods. i.e. OPIUM's LDAP and NIS
> support could feed of those files, which would always be master.
> Does that make sense?
I think I should explain our "strategy" for the LDAP support.
We wanted to restrict the trafic going from the node outside the cluster
: this is just "best practice" meaning that external trafic is not allowed
from the nodes to the internet (actual OSCAR setup).
In this context, there two main alternatives :
1) Set up an LDAP (NIS, NIS+, ...) on the master node so that nodes can
connect to it and obtain their authentification from this source.
This involved several actions :
1) mirror your existing authentification mechanism and set up a
master-slave relation with your existing infrastructure (LDAP, ...)
2) modify the PAM mechanism for all the nodes
Point 1) is not trivial at all ;-)))
2) Set up your master node as LDAP (NIS, NIS+, ...) client from your
existing service and synchronize the nodes with this information
with the existing opium mechanism.
This involves only minor changes :
1) Set up the server as a client of the authentification service
(LDAP in this case)
2) Modify a bit the opium procedure so that it uses the
authentification data obtained from getent (ie PAM) instead of
the one from the files of the master node.
We choose the second solution which integrate more nicely in an existing
infrastructure.
As a consequence, we can't copy the /etc/passwd file of the master node
and we have to copy the data obtained from getent which is put into
alternate files, namely
/opt/opium/(passwd|group|shadow)
Indeed, those files and the master node one are very different : those
from the master node contain only local account info while the one in
/opt/opium contain the aggregated information from PAM meaning
local account + LDAP (NIS, NIS+, ....).
In the case where there is no external source of authentification then
the files are equals. We can even ignore the shadow file as all loggin
is made with the SSH key exchange ;-)
With the proposed patch, we will have support for all past, present and
future PAM based authentification from simple passwd files to complex
mix of passwd, LDAP, NIS, ...
I believe this is a very versatile add-on to OSCAR which require a
minimal effort for a quick integration into an existing autentification
infrastructure.
Comment, questions ?
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: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
