Hi, I was using shell backend and now switched to sock backend (shell looks unstable). My problem not is that I can't delete the shell DB.
This is the entry in cn=config:
dn: olcDatabase={3}shell,cn=config objectClass: olcShellConfig objectClass: olcDatabaseConfig olcDatabase: {3}shell
When I try to remove it I get Error 53 - Unwilling to perform.
Looks like there is a dependency with this entry, but I don't see where. Is the last one, i removed the suffix.... hints?
And don't see anything usefull in the logs.
Regards, Diego
-- Diego Woitasen
Diego Woitasen wrote:
I was using shell backend and now switched to sock backend (shell looks unstable). My problem not is that I can't delete the shell DB.
This is the entry in cn=config:
dn: olcDatabase={3}shell,cn=config objectClass: olcShellConfig objectClass: olcDatabaseConfig olcDatabase: {3}shell
When I try to remove it I get Error 53 - Unwilling to perform.
Looks like there is a dependency with this entry, but I don't see where. Is the last one, i removed the suffix.... hints?
And don't see anything usefull in the logs.
back-config does not support delete operation by default.
You can enable delete support by compiling with CFLAGS=".. -DSLAP_CONFIG_DELETE"
Not sure whether that's officially supported/recommended by OpenLDAP developers though.
Ciao, Michael.
On Wed, Apr 17, 2013 at 12:52 PM, Michael Ströder michael@stroeder.com wrote:
Diego Woitasen wrote:
I was using shell backend and now switched to sock backend (shell looks unstable). My problem not is that I can't delete the shell DB.
This is the entry in cn=config:
dn: olcDatabase={3}shell,cn=config objectClass: olcShellConfig objectClass: olcDatabaseConfig olcDatabase: {3}shell
When I try to remove it I get Error 53 - Unwilling to perform.
Looks like there is a dependency with this entry, but I don't see where. Is the last one, i removed the suffix.... hints?
And don't see anything usefull in the logs.
back-config does not support delete operation by default.
You can enable delete support by compiling with CFLAGS=".. -DSLAP_CONFIG_DELETE"
Not sure whether that's officially supported/recommended by OpenLDAP developers though.
Ciao, Michael.
No way to remove configuration??? Sounds really weird :P
-- Diego Woitasen
Diego Woitasen wrote:
On Wed, Apr 17, 2013 at 12:52 PM, Michael Ströder michael@stroeder.com wrote:
Diego Woitasen wrote:
I was using shell backend and now switched to sock backend (shell looks unstable). My problem not is that I can't delete the shell DB.
This is the entry in cn=config:
dn: olcDatabase={3}shell,cn=config objectClass: olcShellConfig objectClass: olcDatabaseConfig olcDatabase: {3}shell
When I try to remove it I get Error 53 - Unwilling to perform.
Looks like there is a dependency with this entry, but I don't see where. Is the last one, i removed the suffix.... hints?
And don't see anything usefull in the logs.
back-config does not support delete operation by default.
You can enable delete support by compiling with CFLAGS=".. -DSLAP_CONFIG_DELETE"
Not sure whether that's officially supported/recommended by OpenLDAP developers though.
Ciao, Michael.
No way to remove configuration??? Sounds really weird :P
From a philosophical standpoint - production configurations generally only grow. If you're mucking around and experimenting, you do that on a throw-away development system.
From a practical standpoint - behavior of the service when clients are making requests to a backend that gets removed is totally undefined.
Howard Chu wrote:
From a philosophical standpoint - production configurations generally only grow.
IMO this general assumption is not valid.
If you're mucking around and experimenting, you do that on a throw-away development system.
Well, one should always experiment on a dedicated test system. But the result of the tests can be to delete things from the production system following a well-defined procedure developed during testing.
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.
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.
Ciao, Michael.
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".
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.
On Wed, Apr 17, 2013 at 6:08 PM, Michael Ströder michael@stroeder.com 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
--On Thursday, April 18, 2013 7:18 AM -0300 Diego Woitasen diego@woitasen.com.ar wrote:
I know that I could remove it from the filesystem, but I wouldn't.
You can use slapcat -n 0 to export your cn=config database to LDIF. Modify the LDIF for cn=config to no longer reference back-shell, and then reload your cn=config DB using slapadd -n 0.
Personally I'd like to see some sort of offline mode for slapd that allows you to purely edit cn=config over ldapi:/// where slapd only accepts connections from the rootdn, and will only respond to queries against the cn=config DIT.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, April 18, 2013 7:18 AM -0300 Diego Woitasen diego@woitasen.com.ar wrote:
I know that I could remove it from the filesystem, but I wouldn't.
You can use slapcat -n 0 to export your cn=config database to LDIF. Modify the LDIF for cn=config to no longer reference back-shell, and then reload your cn=config DB using slapadd -n 0.
IIRC the official OpenLDAP developer statement about this approach was up to now: Don't do that!
Personally I'd like to see some sort of offline mode for slapd that allows you to purely edit cn=config over ldapi:/// where slapd only accepts connections from the rootdn, and will only respond to queries against the cn=config DIT.
Well, the ldapi:/// thing already works. Only for default builds deleting something from cn=config does not work at all.
How about the following: Allow entry deletion under cn=config only if ManageDsaIT or Relax Rules Control control is used. This would make it very clear that the deployer changing configuration cannot expect that every sequence of changes simply works without causing a downtime for clients or even failing in between.
Ciao, Michael.
--On Thursday, April 18, 2013 4:58 PM +0200 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Thursday, April 18, 2013 7:18 AM -0300 Diego Woitasen diego@woitasen.com.ar wrote:
I know that I could remove it from the filesystem, but I wouldn't.
You can use slapcat -n 0 to export your cn=config database to LDIF. Modify the LDIF for cn=config to no longer reference back-shell, and then reload your cn=config DB using slapadd -n 0.
IIRC the official OpenLDAP developer statement about this approach was up to now: Don't do that!
No, using slapcat/slapadd has been the only supported method. The "Don't Do That" is manually editing the files under cn=config.
Personally I'd like to see some sort of offline mode for slapd that allows you to purely edit cn=config over ldapi:/// where slapd only accepts connections from the rootdn, and will only respond to queries against the cn=config DIT.
Well, the ldapi:/// thing already works. Only for default builds deleting something from cn=config does not work at all.
Incorrect. By default ldapi:/// would allow any client connecting over ldapi:/// to query any part of the DIT. And I have a number of such clients. Please re-read my description.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Michael Ströder wrote:
Diego Woitasen wrote:
I was using shell backend and now switched to sock backend (shell looks unstable). My problem not is that I can't delete the shell DB.
This is the entry in cn=config:
dn: olcDatabase={3}shell,cn=config objectClass: olcShellConfig objectClass: olcDatabaseConfig olcDatabase: {3}shell
When I try to remove it I get Error 53 - Unwilling to perform.
Looks like there is a dependency with this entry, but I don't see where. Is the last one, i removed the suffix.... hints?
And don't see anything usefull in the logs.
back-config does not support delete operation by default.
You can enable delete support by compiling with CFLAGS=".. -DSLAP_CONFIG_DELETE"
Not sure whether that's officially supported/recommended by OpenLDAP developers though.
Not yet.
openldap-technical@openldap.org
-
Diego Woitasen -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount