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 ?
Just a couple-
Probably shouldn't ignore the shadow file for the event that a root login is needed (it keeps root's local pw too, right?). Besides, it only sync's if it's actually changed.
You mentioned that the nodes don't have access to the outside world in OSCAR. I don't remember how many versions ago it changed, but this isn't the case anymore- by default, private subnetted nodes can see the world, but the world can't see them of course. I don't know how LDAP works or doesn't work in this scenario, where the nodes aren't available for reverse lookup. Are you using an OSCAR version (or pfilter config) which provides NAT/firewalling? It may simplify much of this. I wonder about NIS in this configuration too. Anyone have any experience or know if there are issues with NAT and NIS or LDAP?
Jeremy
-------------------------------------------------------
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
