-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ben,

I think this is a problem of LDAP search limits.
Please check your server side search limit. Additionally, there can be
limit defined in your LAM server profile.
Of course, the server side limit will override the limit in LAM's
configuration.


Best regards

Roland


Am 01.03.2012 18:55, schrieb Ben Hodgens:
> Does anyone know what might be causing this problem? It's fairly severe for 
> me. 
> 
> If someone with a similar version could at least check their LAM install to 
> see if the 'to replicate this problem' steps cause the same errors, I'd be 
> appreciative. 
> 
> Thanks,
> 
> Ben
> 
> -----Original Message-----
> From: Ben Hodgens [mailto:[email protected]] 
> Sent: Wednesday, February 29, 2012 9:25 AM
> To: [email protected]
> Subject: Re: [Lam-public] LAM auto-increment of uidNumber
> 
> Roland,
> 
> The server profile says UID range is 1000 through 30000. The lowest "over 
> 7840" unused UID I see is 7820, and every UID from 7860 through 7890 is 
> already used. I've got UIDs as low as 200 and as high as 9000. (sub-1000 
> accounts have special purpose so I do not want LAM creating within that UID 
> range).
> 
> I also noticed just now that if I filter the order in which LAM displays UIDs 
> (by clicking on the column headers), it will not display the UIDs over 7860. 
> I have a known usable account with UIDs over that number which isn't 
> displayed unless I specifically filter by their specific UID for that field 
> (or their username, etc.).
> 
> To replicate this problem:
> 
> * click "New User"
> * enter required fields under "Personal"
> * Click "Unix" tab
> * make sure username is defined
> a)
> * click "Set Password"
> * set password
> * uid field is now populated with 7860
> b)
> * click "Save" 
> - get either "Constraint violation" (good, if you're using the uniqueness 
> overlay, but user isn't created)
> - or the user is created with uid 7860
> 
> Alternatively, have a user with UID over 7860 and sort the userlist view 
> descending.
> 
> I should note, the schema test in LAM DOES pass for me. If my veracity is 
> doubted, I can provide screenshots if necessary. :)
> 
> Here is my slapd.conf, in the event that it might be contributory: 
> 
> include         /etc/ldap/schema/core.schema
> include         /etc/ldap/schema/cosine.schema
> include         /etc/ldap/schema/inetorgperson.schema
> include         /etc/ldap/schema/nis.schema
> require strong
> require authc
> disallow bind_anon
> 
> password-hash {SSHA}
> 
> pidfile         /var/run/slapd/slapd.pid
> argsfile        /var/run/slapd/slapd.args
> 
> loglevel 256 
> 
> modulepath      /usr/lib/ldap
> moduleload      back_bdb.la
> moduleload      unique.la
> 
> TLSCACertificateFile /etc/ldap/certs/root.pem TLSCertificateFile 
> /etc/ldap/certs/ldap.example.org.cert
> TLSCertificateKeyFile /etc/ldap/certs/ldap.example.org.key.insecure
> TLSVerifyClient never
> 
> security ssf=1 update_ssf=112 simple_bind=64
> 
> database        bdb
> suffix "dc=example,dc=org"
> 
> directory       /var/lib/ldap
> 
> cachesize 4000
> checkpoint      256     30
> 
> index objectClass                       eq,pres
> index ou,cn,mail,surname,givenname      eq,pres,sub
> index uidNumber,gidNumber,loginShell    eq,pres
> index uid,memberUid                     eq,pres,sub
> index nisMapName,nisMapEntry            eq,pres,sub
> index uniqueMember                      eq,pres
> 
> overlay unique
> unique_uri ldap:///?mail?sub?
> unique_uri ldap:///?uidNumber?sub?
> unique_uri ldap:///?sn?sub?
> unique_uri ldap:///?homeDirectory?sub?
> 
> access to attrs=userPassword
>   by dn="cn=acctmgr,dc=example,dc=org" read
>   by self write
>   by anonymous auth
> access to 
> attrs=shadowLastChange,uid,cn,sn,givenName,description,memberUid,loginShell,gecos,description,cn,sn
>   by dn="cn=acctmgr,dc=example,dc=org" read
>   by self write
>   by anonymous auth
> 
> access to *
>         by * read 
> 
> include /etc/ldap/ox.conf
> 
> Thanks,
> 
> Ben Hodgens
> 
> -----Original Message-----
> From: Roland Gruber [mailto:[email protected]]
> Sent: Tuesday, February 28, 2012 10:04 PM
> To: [email protected]
> Subject: Re: [Lam-public] LAM auto-increment of uidNumber
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Ben,
> 
> you can specify the UID number range in your LAM server profile. LAM will 
> search your directory (user+host suffix) for the highest number and increment 
> it by one.
> If the maximum limit is reached then LAM will search for a free number inside 
> your existing ones.
> 
> Probably, you have a user with uidNumber 7859 and this is the highest one.
> 
> 
> Best regards
> 
> Roland
> 
> 
> Am 28.02.2012 23:04, schrieb Ben Hodgens:
>> I've got a problem with LAM's auto-incrementing of the uidNumber. 
>> Specifically: it isn't, and I can't seem to figure out why. 
>>
>> I'm using Debian 6 packages with LAM 3.1.0-2 and OpenLDAP slapd (and 
>> slapd.conf configuration) 2.4.23-7.2.
>>
>> If I create a new user, it will give it a uidNumber of 7860 by default, even 
>> though the tooltip says that leaving it blank will pick the next available 
>> uidNumber. If I create multiple users in batch, it will set them in 
>> sequence, but starting at that UID. 
>>
>> I may have set this "base uidNumber" but I could've sworn I set it around 
>> 1800, not 7860. I can't seem to find where that base uid is set now, either.
>>
>> Is there a specific attribute, schema, overlay etc. that I need to get this 
>> to work properly and not have users with duplicate UIDs? I'm using the 
>> 'unique' overlay now, and while this prevents the creation of additional 
>> 'duplicate uid' problems, it also results in LAM erroring while trying to 
>> create a new user without specifically setting the uid. 
>>
>> Thanks,
>>
>> Ben
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning Cloud computing 
> makes use of virtualization - but cloud computing also focuses on allowing 
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Lam-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lam-public
> 
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Lam-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lam-public
> 

- -- 

Mit freundlichen Grüßen

Roland Gruber
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9RJzUACgkQq/ywNCsrGZ7YEQCfdQZdF8lfMwjkI68nZbN2CGGF
mzUAn2v47q/3Wa3qh4iuggTLfm3MINQT
=JXh5
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Lam-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lam-public

Reply via email to