[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Re: Is existing documentation kind of vague?
TLDR; in a split-brain situation, you could run into trouble. But this
isn't the only place. Efffective systems monitoring is the key here.
Long answer;
If you are loading entries hard and fast with multi-threaded code,
they aren't going to be posixAccount entries - they are going to be
simpleSecurityObject or inetOrgPerson entries for application users.
Small lists of posixAccount entries (up to 100 thousand or so) are
added using a single-threaded bulk user loader, and large lists will
be done using slapadd. No organisation on this planet is going to have
more than 100 thousand posixAccount entries in production on the same
database, with the possible exception of the US or Chinese governments
- and they will be so slow at adding accounts that they never
experience a collision ;-)
In the case of universities, probably the only situation where there
is a possibility to encounter a race condition with regards to
auto-incrementing UID numbers, the accounts will likely be numbered
using the student ID number and batch-loaded anyway.
So, yes, you CAN screw it up if you really go out of your way to prove
it is possible but the operational use cases are just not very likely
going to put you into that situation. There is just not a use case
that I have ever seen where you would need to do hard and fast
multi-threaded addition of numbered accounts. You can do serial
loading over-the-wire into an mdb backend about 1 million users in 5
minutes if you are just building up a db with different scenarios for
load-testing purposes.
The solution I posted has been in production in a large, dynamic
company for several years and never encountered a problem.
On Wed, Nov 15, 2017 at 9:09 AM, Ulrich Windl
<Ulrich.Windl@rz.uni-regensburg.de> wrote:
>>>> MJ J <mikedotjackson@gmail.com> schrieb am 14.11.2017 um 20:36 in
> Nachricht
> <CANCEyfNNs0CC-KxBV4kS3v3QRLFROKsp4BueMQrhOzxgZ1drwQ@mail.gmail.com>:
>> Hi,
>>
>> You don't need a special object class or schema, you can use this:
>>
>> dn: cn=user,ou=increment,dc=foo,dc=bar
>> objectClass: top
>> objectClass: account
>> objectClass: posixAccount
>> cn: user
>> gidNumber: 99999
>> homeDirectory: /no/such/location
>> uid: user
>> uidNumber: 1000
>> description: Modify-increment user
>>
>>
>> And here is a python method to do the job for you:
>>
>> def increment_uidnumber(l, base):
>> """ Perform LDAP modify-increment operation on uidNumber tracking object
>
>> """
>> modlist = [(ldap.MOD_INCREMENT, "uidNumber", "1")]
>> l.modify_s("cn=user,{0}".format(base), modlist)
>> r = l.search_s(base, ldap.SCOPE_SUBTREE, "(objectClass=posixAccount)",
>> ['uidNumber'])
>> next_number = r[0][1]['uidNumber'][0]
>>
>> return next_number
>
> Out of curiosity: How does it play with concurrency on different multi-master
> nodes? Is there a chance to assign the same number multiple times?
>
> Regards,
> Ulrich
>
>>
>>
>> Hope that helps,
>> Mike
>>
>> On Tue, Nov 14, 2017 at 9:13 PM, John Lewis <jl@hyperbolicinnovation.com>
>> wrote:
>>> Hello Everyone.
>>>
>>> I was trying to implement uidNumber Attribute Auto-Incrementing Method
>>> and I read http://www.rexconsulting.net/ldap-protocol-uidNumber.html .
>>>
>>> I specifically want to point to this line here.
>>>
>>>> Create a “uidNext” entry (objectClass: uidNext) at an specific
>>>> location in the directory to store the incrementing value. Publish
>>>> this location in your application programming guides as the well-
>>>> known location for obtaining the next UID. Also publish this method
>>>> as the required method to retrieve a next UID.
>>>
>>> But I already know from http://www.openldap.org/doc/admin23/schema.html
>>> & http://www.zytrax.com/books/ldap/ch3/ that object classes are
>>> defined only. So the writer left out that they defined a schema and
>>> what name the called the schema. Maybe it isn't important. What is
>>> important is that they used object class "objectclass (
>>> 1.3.6.1.4.1.19173.2.2.2.8" to define it, but I can't find the
>>> registration of the object identifier on https://www.ldap.com/ldap-oid-
>>> reference or https://www.iana.org/assignments/ldap-parameters/ldap-para
>>> meters.xhtml#ldap-parameters-3.
>>>
>>> It makes perfect scene because it is a PRIVATE ENTERPRISE NUMBER. It
>>> would mean that anyone outside of Rex Consulting, Inc. https://www.iana
>>> .org/assignments/enterprise-numbers/enterprise-numbers would be using
>>> the wrong OID and that the specific object wouldn't be listed.
>>>
>>>> Under no circumstances should you hijack OID namespace!
>>> - OpenLDAP Software 2.4 Administrator's Guide
>>>
>>> That is a lot of data from a lot of different websites to string
>>> together that information. I have a good idea how to implement
>>> uidNumber, but I haven't seen it done and I can't do it CORRECT today
>>> because I would have to register for a Private Enterprise Number so I
>>> won't hijack an OID namespace and that would take up to 30 days and
>>> there is no documented contingency plan anywhere.
>>>
>>> We are all familiar with the the LDAP call out articles that come out
>>> every year. All of the articles seem to come from a place of
>>> frustration. To be fair I think call out articles are a trend with
>>> databases.
>>>
>>> Do you think existing documentation is kind of vague?
>>>
>
>
>