Re: [Devel] race condition when creating ldap entries

[Harald Thingelstad <harald@xxxxxxxxxxxxx>]

A note from someone who can't keep his paws off..

fredag 1. august 2003, 17:35, skrev Andreas Schuldei:
> as i understand it we have no protection against race conditions
> in the ldap code.
...
> we have several options to solve this problem:
>
> use a database with transaction support (postgresql is my
> favourit) and rollback doing the user management. This is the way
> *real* systems like sourceforge and alioth are doing it. (c:
> ldap is just used as a fast lookup, not as the real backend.

Old itch, this one. So far we've just lived with it and demanded no parallell 
submissions. Is this a critical demand?

The problem with postgresql is getting it to install smoothly. See bug #22 
(recently translated to English).
On the other hand, some user index is going to be needed in postgresql 
(default Skolelinux DBMS) sooner or later anyway. To help other applications 
going. Like class management systems and the likes. (National level systems 
are slow and clunky, when all users massively tries to use it with the 
schools "broadband"..) 
Or, should the cups/pyqota page counter be managed in LDAP?

>
> have one "uid-daemon" doing all the (sequential) ldap write
> queries (and also uid and login creation), which he receives from
> the webmin instances, nicely queued through a pipe.

Could get difficult to secure? See the Cups vulnerability.
http://lwn.net/Vulnerabilities/33772/

Harald