In order to get off NIS, I did an upgradeable ldap->master.passwd build script system. It's not instantly obvious what is happening when you look at it, but:

One worked example might be in order.

admin# crontab -l -u root
*/10 * * * *    /usr/sbin/daemon -cf /usr/bin/lockf -s -t 0 /var/run/ldap-client.lock /etc/ldap-client/

admin# cat /etc/ldap-client/ 
#! /bin/sh
# */10 * * * *    /usr/sbin/daemon -cf /usr/bin/lockf -s -t 0 /var/run/ldap-client.lock /etc/ldap-client/
/etc/ldap-client/ 180
/etc/ldap-client/ 2>&1 | /etc/ldap-client/ -d -s "`/bin/hostname` - $0"

admin# cat /etc/ldap-client/ 
#! /bin/sh
cd /etc/ldap-client && /usr/bin/cvs -Rq up -d -P -C
/etc/ldap-client/ -o adminAccount -s adminShell -q
/etc/ldap-client/ -o adminAccount -k adminPublicKey -q
/etc/ldap-client/ -q
/etc/ldap-client/ -o adminAccount -q

The general flow:

The scripts do their best to merge with local changes. Except for things that are in ldap. eg: if there is a local user called "peter", and one in ldap, it will remove the local user and install the ldap one instead. This means you CAN just build/install ports that install local ports users.

The scripts DO interact correctly with useradd/vipw/etc. All locking conventions are maintained. You can still vipw.

So far, this should be easy enough. Where it gets complex is deciding what accounts to put on a machine, and which ssh keys to use.

There are three filtering / access control systems.

ldap accounts are tagged with "objectClass".

ldap accounts have a "loginShell".

The third access filter is ssh shell selection.

With these basic rules I was able to implement all the one-off hacks we had done with NIS. Its not pretty, but it works so far.

Some examples:

I expect this will need refining. I want to add signature checking for updates, etc. Lots todo, but we are off NIS.

Teams/clusteradm/ldap_access_control (last edited 2012-10-15 17:12:05 by PeterWemm)