> I work for a company with a large deployment of cfengine managed
> servers, 1000 or more systems in total. The problem is that the way
> things were initially put together has turned into a huge mess in terms
> of user account management. There's maybe 50-100 separate passwd and
> shadow files for the entire production environment...all in cfengine.
> Adding and removing accounts is a clumsy operation of running different
> scripts on various cfengine master servers. As a result, it takes
> forever to add or modify individual accounts and there also isn't
> enough control over who has accounts on which systems.
> I guess I'm looking for suggestions on how to deal with the mess. It
> seems like the obvious solution is migrating to LDAP or some kind of
> equivalent. That seems daunting because I don't know how I would ever
> manage a seamless transition on such a complex production network where
> extended downtime is unacceptable. Perhaps after consolidating all of
> the cfengine passwd files, I could enter everything into an LDAP server
> and then export from LDAP to a few distinct passwd files (based on
> security requirements) and then push those out with cfengine. You can
> probably tell I'm grasping at straws here.
> I'm also wondering about the idea of having just a few accounts on the
> individual systems such as dba, admin, etc. but I don't know how I
> would be able to tell who had performed what actions with such a setup
> (not that I really can now but at least I can see who logged in and
> when a particular user sudo'd to a privileged account).
> Any suggestions are greatly appreciated.
ldap is probably the only solution, and may not be as daunting as you
think. For a start, you can run ldap in parallel with your 'file' based
system simply by having entries like:
passwd: files ldap
in /etc/nsswitch.conf. This means you can create a test user in ldap
that doesn't have an entry in /etc/passwd+shadow and get the system
working for that single user on a couple of test servers. Eventually you
move users from file entries into ldap.
You will need to consider what users gain access to what servers. You
create profiles for your different server types which contain the search
query that locates a user. Normally it is simple such as 'uid=%user'
where %user is the name supplied by the login process. Since you may not
want all users to log into all servers you might have the filter for
oracle servers set like '&((uid=%user)(memberOf=oracleDBA))'. A user
record may look like:
objectclass: person (+ other objectclasses)
The profile refered to above would also be stored in ldap. Each ldap
client would have an ldap.conf file which would contain the address of
the ldap server, a proxy dn that the client can log in as to search the
directory, and the profile for that client. The ldap.conf would be
distributed or created by cfengine for each system with the appropriate
Your other idea of populating files from ldap also has merit. Since each
server can have ldap client software, you simply run a script that
periodically issues 'ldapsearch', selecting person records for people
that are in the appropriate group for the server. The ldif output from
ldapsearch can easily be massaged into passwd/shadow format and
concatenated with the fixed system accounts. When you change the master
record in ldap, all the hosts will recreate their files in due course.
This system can serve as a stop gap system until a full migration takes
If you have implemented a 'gold' server as your cfengine master, it can
also be the read/write ldap master. Allocate a few read-only replicas,
(which can be set up by cfengine) to help carry the load. If your
servers are geographically dispersed, put a replica in each region.
In case you're wondering, I'm in the process of implementing ldap
myself, although I have far less systems than you. However I have the
added wrinkle of providing ldap access to network devices, using
freeradius. My systems are mainly Solaris, and ldap support is, well,
not a walk in the park.
regards, Frank Ranner
Help-cfengine mailing list