[Pkg-shadow-devel] slow useradd -r on LDAP box

[Peter Vrabec]

Hi folks,

here are the patches:

* .ldap patch solves the problem with slow addition of system accounts on 
boxes that use big ldap. (https://bugzilla.redhat.com/show_bug.cgi?id=511813)

* .sysacc patch reduces the reuse of system IDs. In order to achieve this I 
had to change SYS_UID_MIN hardcoded in find_new_{uid,gid} from 1 to 101. Range 
between 1 - 100 is used for static UIDs/GIDs.

Peter.



On Wednesday 15 July 2009 11:22:25 am Peter Vrabec wrote:
> Hi,
>
> On Tuesday 14 July 2009 01:16:12 pm Nicolas François wrote:
> > Hi Peter,
> >
> >
> > Sorry for the delay.
> >
> > On Wed, Jul 01, 2009 at 12:08:25PM +0200, pvrabec at redhat.com wrote:
> > > Dear upstream,
> > >
> > > we both know that useradd -r (or useradd) is slow(~minutes) on box with
> > > LDAP accounts. Useradd -r is special case, because it is used by
> > > package system, So when you want to install your favourite daemon you
> > > have to wait a long time which is annoying.
> > >
> > > I'd like to discuss  possibility of changing alg. of find_new_uid/gid
> > > little bit. What if we use getpwuid() to find free SYSTEM UIDs!.
> > > Calling getpwuid() max 1000 times takes almost same time as getpwent()
> > > on the box without LDAP but significantly less than getpwent() on box
> > > with LDAP with 10000 users.
> > >
> > > What do you think?
> >
> > Yes, that could be a solution to fix this issue.
> >
> > It's still strange to me that getpwent() is so slow. But this should fix
> > the handling of system users.
>
> Nicolas, I don't know what's faster getpwent() vs. getpwuid(). Lets assume
> they are equal. The difference is in algorithm. If you want get "map" of
> system accounts you have to call either getpwuid() 1000x times or
> getpwent() on all users. (which might be a lot in case LDAP)
>
> > For regular users, it would be nice to find a solution, and it might be
> > worth trying if the above solution could not be applied also.
>
> I'm afraid we can't apply this solutions on regular users. The solution is
> based on idea that we know the range of system users IDs and this range of
> system user IDs is much smaller then range of regular users. Calling
> getpwuid() on all possible user IDs would actually makes the find_new_uid
> slower.
>
> To be honest, I think regular users case it's much smaller problem, because
> on box that use LDAP is less probable that you will add new regular users
> into passwd. You want to add them into LDAP. But it's just my assumption.
> :)
>
> > > I would also like to ask if you agree with current implementation of
> > > system uid look up. In case of user accounts we look for
> > > * first max free UID.
> > > In case of system accounts we look for
> > > * first free UID in reverse order.
> > > Should we look for
> > > * first min free UID in reverse order?
> >
> > That could be more logical, and could reduce the reuse of system IDs.
> > That's probably a less urgent issue since current user probably still
> > have system IDs creted with the previous algorithm.
>
> I'm just asking because if I write a patch I will have to deal with it
> anyway.
>
>
> thnx. for feedback.
>
> Peter.
>
>
>
> _______________________________________________
> Pkg-shadow-devel mailing list
> Pkg-shadow-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-shadow-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: shadow-4.1.4.1-ldap.patch
Type: text/x-patch
Size: 2853 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20090716/de029001/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shadow-4.1.4.1-sysacc.patch
Type: text/x-patch
Size: 8877 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/attachments/20090716/de029001/attachment-0001.bin>