On Wed, Apr 17, 2013 at 6:08 PM, Michael Ströder <[email protected]> wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>>> From a practical standpoint - behavior of the service when clients are >>>> making >>>> requests to a backend that gets removed is totally undefined. >>> >>> LDAP clients do not care about (OpenLDAP) database backends at all. >>> They simply query a DIT. >> >> Yes, but they expect to get consistent answers to their queries. You cannot >> make any assertions about consistency when the rug is pulled out from under a >> running query. >> >>> AFAICS the original poster wanted to replace back-shell with back-sock for >>> the >>> very same naming context. In theory this could be done with back-config - >>> only >>> requring a very small downtime - entry deletion in back-config would be >>> possible. >> >> It would require adding a suffix to one backend while removing it from >> another. Since this can't be done in a single LDAP request it would require >> wrapping both changes in a single LDAP Transaction. >> >> Doing it non-atomically would invariably result in inexplicable client error >> messages as they send requests to an LDAP server that was "working fine >> before" but suddenly replies "no global superior knowledge". > > Of course one would prevent clients from connecting before. > That's what I meant with "requiring a very small downtime". > > Well, the point is that deleting something in back-config has to be done with > some care - just like other non-trivial configuration/schema/data changes - > but should not be completely impossible. > > Ciao, Michael. > >
My personal experience was: I had a requirement about having a custom behavior for a subtree so I used back-shell because it looks the easier option. It worked in a testing server and when I moved the config to the production server it started to hangs (load wasn't very high) frequently. Then I switched to back-sock recommend by somebody at the IRC channel. It's been working very stable since the switch, but back-shell remains there. I disabled it removing the subtree attrs and others, but removing taking dependencies into consideration is a good feature. Thinking that configurations only grows is out of the real world. I know that I could remove it from the filesystem, but I wouldn't. Regards, Diego -- Diego Woitasen
