Jason Gunthorpe <[EMAIL PROTECTED]> writes: > You don't really need this, just a simple detect/backoff algorithm will do > OK for determining the UIDs
Could you elaborate? If you have at least two machines, I can't see how you don't have to have a shared locking mechanism to make sure they don't both try to add the same user to the ldap database with different uid's, or are there some ldap semantics that allow you to avoid the race condition. > > 2) get the next user id (how?). [1] > > The only way I could see is to suck down the entire UID list and pick the > highest, it is a big search, but ldap doesn't have a mechanism for > integer value compares so it is the best I could think of. It won't be that big here. Ldap's only going to be managing the local users, and there will only be a handful or two. And if I just mandate that all account maintenance (add/delete/modify) be handled from a single machine, I could just store the last uid/gid in a local state file. This would also avoid the problems in the previosu point above. > > 5) Run a script to do whatever's needed to create the user's home > > directory in all the right places [1]. > > The pam_mkhomedir module I cooked up is what I think we will ultimately > use on debian.org, the home dirs just spring into existance on the first > login. Saves resources+headaches Right, but that doesn't help if you need to do something more complicated (or even just different). It might be nice to modify the mkhomedir module to use a config file, and just have that config file allow you to specify the script to be run to handle things. The default could be something like /sbin/pam-mkhomedir which would have the current behavior. Of course, maybe it just makes sense for us to take pam-mkhomedir and modify it for our purposes. Here we really just need it to make sure the user's CODA volume is available and ready. I'm wondering if there's anything I'm going to have to do here that could be generalized and useful to others, or if it's just going to be too domain specific to be useful to anyone else. (Oh, and I guess you didn't have any idea why my script was failing with authentication problems?) Thanks for the help. -- Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930