Hi!
I had reported about trouble when upgrading the openldap from SLES11 SP4 to that from SLES12 SP3. Besides the version jump, SUSE also removed some modules that had been static in SLES11, so that they need to be loaded dynamically now. Besides that, the bdb version was updated as well, and some other minor things.
The real problem is that I'll need to change cn=config to include the modules, one of them being accesslog. The main problem there seems to be that the accesslog module provides the accesslog schema also, meaning the schema is unknown until the module is loaded. Now no configuration change is accepted, because there are attributes in the config database without a schema:
# slapadd -q -n0 -F /etc/openldap/slapd.d/ -l module.ldif 5be00c86 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined slapadd: bad configuration directory
I once did edit the config-db files directly and managed to get slapd running (and bdb auto-upgraded itself), but I'm looking for a clean solution.
The other things I've noticed was that the old SLES11 openldap would not accept a module load directive when the module is not found (mdb in particular); loading modules that are statically included is no problem, however. This makes a replicated cn=config very difficult for a rolling upgrade of MMR servers.
Any splendid idea how to add the accesslog module to a cn=config that already has accesslog configured for ist databases? Even temporarily removing the conflicting attributes does not work.
Regards, Ulrich
--On Wednesday, November 07, 2018 11:05 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
Hi!
I had reported about trouble when upgrading the openldap from SLES11 SP4 to that from SLES12 SP3. Besides the version jump, SUSE also removed some modules that had been static in SLES11, so that they need to be loaded dynamically now. Besides that, the bdb version was updated as well, and some other minor things.
The OpenLDAP project has long recommended against using distribution provided builds for a variety of reasons. You've just excellent summarized another reason why they should be avoided -- You have no control over whether or not they will change how they build the software and thus utterly destroy a working deployment.
What you will have to do:
a) Use slapcat with the older SLES build to export your cn=config database b) Update the resulting LDIF so that it works correctly with the new SLES build c) Import it with the new SLES slapd
None of this is a problem with OpenLDAP. Everything about this is a problem with SLES.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Ulrich,
while I somewhat understand your frustration...
On 11/7/18 11:05 AM, Ulrich Windl wrote:
This makes a replicated cn=config very difficult for a rolling upgrade of MMR servers.
...I think the above is the root cause of your trouble.
Even if the build configuration would not have changed there has been syncrepl interop issues between different releases in the past. So I would not expect this to always work.
Personally I'd strongly recommend to use a decent config management instead of replicating cn=config which helps with lots of other issues too. Still rolling upgrades can be a challenge, but you would at least not have to get cn=config working to get changes propagated. (No, I don't want to start yet another static vs. dynamic config discussion.)
Ciao, Michael.
On 11/7/18 5:19 PM, Quanah Gibson-Mount wrote:
The OpenLDAP project has long recommended against using distribution provided builds for a variety of reasons. You've just excellent summarized another reason why they should be avoided -- You have no control over whether or not they will change how they build the software and thus utterly destroy a working deployment.
Well, the change in the build config was meant as first step to prepare getting rid of Berkeley-DB as hard installation dependency. Because it is probably a bad idea to statically link backends deemed deprecated by the OpenLDAP developers for some years already. ;-]
Ciao, Michael.
--On Wednesday, November 07, 2018 6:29 PM +0100 Michael Ströder michael@stroeder.com wrote:
Even if the build configuration would not have changed there has been syncrepl interop issues between different releases in the past. So I would not expect this to always work.
There was an issue with ppolicy in one release, but outside of that nothing that I'm aware of. ppolicy needs a bit of work to fix its current mix of external and internal schema which would resolve such issues long term, but isn't a problem with other portions of OpenLDAP.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, November 07, 2018 6:34 PM +0100 Michael Ströder michael@stroeder.com wrote:
Well, the change in the build config was meant as first step to prepare getting rid of Berkeley-DB as hard installation dependency. Because it is probably a bad idea to statically link backends deemed deprecated by the OpenLDAP developers for some years already. ;-]
It's questionable as to why it was built anything other than as a module in the first place. Modular support for backends and overlays has existed for a very long time.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 11/7/18 6:37 PM, Quanah Gibson-Mount wrote:
--On Wednesday, November 07, 2018 6:29 PM +0100 Michael Ströder michael@stroeder.com wrote:
Even if the build configuration would not have changed there has been syncrepl interop issues between different releases in the past. So I would not expect this to always work.
There was an issue with ppolicy in one release, but outside of that nothing that I'm aware of. ppolicy needs a bit of work to fix its current mix of external and internal schema which would resolve such issues long term, but isn't a problem with other portions of OpenLDAP.
As I understand Ulrich, the old SLES11 package does not even support the module load directive to be added.
That's why I think that his expectation that rolling upgrades with replicated cn=config always just work cannot be met.
Ciao, Michael.
--On Wednesday, November 07, 2018 7:02 PM +0100 Michael Ströder michael@stroeder.com wrote:
As I understand Ulrich, the old SLES11 package does not even support the module load directive to be added.
That's why I think that his expectation that rolling upgrades with replicated cn=config always just work cannot be met.
Right, because SLES fundamentally changed how slapd is built out. In that scenario, rolling upgrades will not work. This wouldn't work with slapd.conf either, since you'd have to change the slapd.conf configuration too. I.e., nothing specific to cn=config about this, although cn=config does add an additional wrinkle since it can be replicated.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 11/7/18 7:10 PM, Quanah Gibson-Mount wrote:
--On Wednesday, November 07, 2018 7:02 PM +0100 Michael Ströder michael@stroeder.com wrote:
As I understand Ulrich, the old SLES11 package does not even support the module load directive to be added.
That's why I think that his expectation that rolling upgrades with replicated cn=config always just work cannot be met.
Right, because SLES fundamentally changed how slapd is built out. In that scenario, rolling upgrades will not work.
I'm pretty sure there are numerous other corner cases where it does not work smoothly.
This wouldn't work with slapd.conf either, since you'd have to change the slapd.conf configuration too.
I could easily write a *site-specific* slapd.conf...
I.e., nothing specific to cn=config about this,
...as I could also write a *site-specific* cn=config.
(Remember I wrote: "No, I don't want to start yet another static vs. dynamic config discussion.")
although cn=config does add an additional wrinkle since it can be replicated.
And that's what I consider to cause a lot of grief.
Also look at Ulrich's issues with serverID and multi-homed hosts for which there's not really a good solution.
Ciao, Michael.
--On Wednesday, November 07, 2018 7:39 PM +0100 Michael Ströder michael@stroeder.com wrote:
Also look at Ulrich's issues with serverID and multi-homed hosts for which there's not really a good solution.
Utterly false. The only problem was in comprehension of how things worked.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 11/7/18 7:41 PM, Quanah Gibson-Mount wrote:
--On Wednesday, November 07, 2018 7:39 PM +0100 Michael Ströder michael@stroeder.com wrote:
Also look at Ulrich's issues with serverID and multi-homed hosts for which there's not really a good solution.
Utterly false.
Not so.
The only problem was in comprehension of how things worked.
The caveat: You must specify the very same LDAP URI used with serverID when starting the server with slapd -h. But this could lead to some issues with dynamic interface (re-)configuration. E.g. consider a container moved to another host.
Ciao, Michael.
--On Wednesday, November 07, 2018 7:49 PM +0100 Michael Ströder michael@stroeder.com wrote:
The caveat: You must specify the very same LDAP URI used with serverID when starting the server with slapd -h. But this could lead to some issues with dynamic interface (re-)configuration. E.g. consider a container moved to another host.
You must use *one* of the URI's passed to the -h option of slapd (just to be clear, since -h can take > 1 URI).
Hopefully that provides an avenue for containers, but running LDAP in a container environment seems rather sketchy to me to begin with.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount quanah@symas.com schrieb am 07.11.2018 um 17:19 in
Nachricht <F69BE983171EACF5A6B16493@[192.168.1.39]>:
‑‑On Wednesday, November 07, 2018 11:05 AM +0100 Ulrich Windl <Ulrich.Windl@rz.uni‑regensburg.de> wrote:
Hi!
I had reported about trouble when upgrading the openldap from SLES11 SP4 to that from SLES12 SP3. Besides the version jump, SUSE also removed some modules that had been static in SLES11, so that they need to be loaded dynamically now. Besides that, the bdb version was updated as well, and some other minor things.
The OpenLDAP project has long recommended against using distribution provided builds for a variety of reasons. You've just excellent summarized
another reason why they should be avoided ‑‑ You have no control over whether or not they will change how they build the software and thus utterly destroy a working deployment.
What you will have to do:
a) Use slapcat with the older SLES build to export your cn=config database b) Update the resulting LDIF so that it works correctly with the new SLES build c) Import it with the new SLES slapd
I tried to do so, but It did not work: Without debugging the only message I got was "slapadd: database doesn't support necessary operations.".
With debugging enabled, the process ends with these messages: 5bea96e0 backend_startup_one: starting "cn=config" 5bea96e0 ldif_read_file: no entry file "/etc/openldap/slapd.d/cn=config.ldif" 5bea96e0 send_ldap_result: conn=-1 op=0 p=0 5bea96e0 >>> dnNormalize: <cn=Subschema> ... 5bea96e0 slapadd startup: initiated. 5bea96e0 backend_startup_one: starting "cn=config" 5bea96e0 config_back_db_open Backend ACL: access to * by * none
5bea96e0 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context slapadd: database doesn't support necessary operations. ----
What is special with the "Backend ACL"? Is this referring to a specific line of my LDIF? The command I used was "slapadd -v -n0 -F /etc/openldap/slapd.d -S 1 -w -g -dparse,ACL,trace -l /tmp/test-0.ldif"
The basic question is: What is the necessary operation the database does not support?
Regards, Ulrich
None of this is a problem with OpenLDAP. Everything about this is a problem with SLES.
Regards, Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Tuesday, November 13, 2018 11:07 AM +0100 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de wrote:
What you will have to do:
a) Use slapcat with the older SLES build to export your cn=config database b) Update the resulting LDIF so that it works correctly with the new SLES build c) Import it with the new SLES slapd
I tried to do so, but It did not work: Without debugging the only message I got was "slapadd: database doesn't support necessary operations.".
What is special with the "Backend ACL"? Is this referring to a specific line of my LDIF? The command I used was "slapadd -v -n0 -F /etc/openldap/slapd.d -S 1 -w -g -dparse,ACL,trace -l /tmp/test-0.ldif"
It's simply warning the ACL lacks a specific database context, so it can be unclear what to apply it to. It's not the source of your problem.
The basic question is: What is the necessary operation the database does not support?
Please fix your slapadd command to provide the necessary information as to why it stopped (You want a debug level of -1 in this case:
slapadd -v -n0 -F /etc/openldap/slapd.d -w -S 1 -d -1 -l /tmp/test-0.ldif
Additionally, ensure that /etc/openldap/slapd.d is empty before running slapadd, i.e.:
cd /etc/openldap mv slapd.d slapd.d.old mkdir slapd.d
Then run the slapadd command.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl