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

Reply via email to