openldap-technical September 2017

openldap-technical@openldap.org

54 participants
164 discussions

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 18 Sep '17

18 Sep '17

--On Thursday, September 14, 2017 6:30 PM -0500 Andy Dorman <adorman(a)ironicdesign.com> wrote: > I have our dev server using OLC and it takes me twice as long to modify > it's config than the 15 other servers we have running openLDAP. It takes all of ldapadd/modify to modify cn=config. If you're having that much difficulty, it sounds like you don't understand how to use cn=config. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 4

SASL Passthrough Kerberos Authentication Backend - Preauthentication
by Uli Tehrani 18 Sep '17

18 Sep '17

Hi all, i wanted to use SASL-Passthrough with kerberos-Backend to have a common Password for LDAP and Kerberos Authentication. LDAP-Authentication is only working with the preauthentication Flag disabled. Is this normal or did i make a mistake ? Do i have other possibilities to have a common Password and Password-Policy ? Thanks in advance Kind regards Uli -- =================================== Ulrich Tehrani Am Ulrichshof 19 79189 Bad Krozingen +497633806246 u_tehrani(a)yahoo.de =================================== .

1 0

slapd: null_callback : error code 0x14
by Paul B. Henson 15 Sep '17

15 Sep '17

So I've been putting off posting about this, but I recently upgraded to 2.4.45, stopped using the memberof overlay, no longer have a node with serverID 0, and overall think my ldap servers should be in good shape :), and it's still happening, so I thought it was time... I'm getting weird errors in my logs about group replication changes: Sep 15 03:55:16 minerva slapd[71654]: null_callback : error code 0x14 Sep 15 03:55:16 minerva slapd[71654]: syncrepl_message_to_op: rid=003 be_modify uid=arc464,ou=group,dc=cpp,dc=edu (20) Sep 15 03:56:32 minerva slapd[71654]: null_callback : error code 0x14 Sep 15 03:56:32 minerva slapd[71654]: syncrepl_message_to_op: rid=002 be_modify uid=ce427l01,ou=group,dc=cpp,dc=edu (20) Sep 15 03:56:53 minerva slapd[71654]: null_callback : error code 0x14 Sep 15 03:56:53 minerva slapd[71654]: syncrepl_message_to_op: rid=003 be_modify uid=chm250l01,ou=group,dc=cpp,dc=edu (20) They sporadically happen on my replicas, on random groups, not typically the same groups on each one on any given day: Sep 15 04:04:52 egeria slapd[29652]: null_callback : error code 0x14 Sep 15 04:04:52 egeria slapd[29652]: syncrepl_message_to_op: rid=001 be_modify uid=soc202,ou=group,dc=cpp,dc=edu (20) Sep 15 04:02:38 coeus slapd[3333]: null_callback : error code 0x14 Sep 15 04:02:38 coeus slapd[3333]: syncrepl_message_to_op: rid=001 be_modify uid=mat321,ou=group,dc=cpp,dc=edu (20) I'm updating the member and memberUid attributes: Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205558 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205558 MOD attr=member Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205558 RESULT tag=103 err=0 text= Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205559 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205559 MOD attr=memberUid Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205559 RESULT tag=103 err=0 text= Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205560 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205560 MOD attr=member Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205560 RESULT tag=103 err=0 text= Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205561 MOD dn="uid=soc202,ou=group,dc=cpp,dc=edu" Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205561 MOD attr=memberUid Sep 15 04:04:52 themis slapd[3035]: conn=125451 op=205561 RESULT tag=103 err=0 text= Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174816 MOD dn="uid=arc464,ou=group,dc=cpp,dc=edu" Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174816 MOD attr=member Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174816 RESULT tag=103 err=0 text= Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174817 MOD dn="uid=arc464,ou=group,dc=cpp,dc=edu" Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174817 MOD attr=memberUid Sep 15 03:55:15 themis slapd[3035]: conn=125451 op=174817 RESULT tag=103 err=0 text= As far as I can tell, all the updates succeed and the objects are exactly the same on all the replicas, so these failures just seem to be log noise? Any thoughts on what's going on? Thanks...

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 12:47 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > On Fri, Sep 15, 2017 at 11:44:47AM -0700, Quanah Gibson-Mount wrote: >> Generally it's considered a no-no. For this instance, it may be the >> easiest route if you can do it without breaking things. ;) > > If you do take that path, it's best if you make some kind of online > modification to the same schema entry afterwards (even a no-op), so that > slapd writes out the backing file again with a regenerated checksum and > so forth. You can also just delete the CRC line from the file, or recalculate the CRC. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 12:41 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > But updating schema.ldif file in disk is not recommended way right? Generally it's considered a no-no. For this instance, it may be the easiest route if you can do it without breaking things. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by rammohan ganapavarapu 15 Sep '17

15 Sep '17

Quanah, But updating schema.ldif file in disk is not recommended way right? Thanks, Ram On Fri, Sep 15, 2017 at 11:33 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy <ryan(a)nardis.ca> > wrote: > > > There was some talk, either in IRC or on -devel, of creating a way for >> cn=config to reference schema files (possibly LDIF) on disk rather than >> importing them into the config database. I think that would be an >> improvement. Importing schemas into cn=config is cool - especially if you >> want to replicate the config - but I'm not sure it's a good default. >> > > Since ordering is mandatory, it would be nice if you could just do > something like: > > olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif > olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif > olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif > > > etc. Then you could change the schema files on disk, and cn=config would > just load them in when it started. It'd certainly make the behavior > analagous to slapd.conf, and allow for easier rollback/testing. > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 8:49 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> --On Friday, September 15, 2017 7:57 PM +0200 Michael Ströder >> <michael(a)stroeder.com> wrote: >>> I strongly disagree. It's a schema shipped by OpenLDAP >>> installation. So this update should have simply worked. >> >> Since the schema is stored in the cn=config DB, there's not an >> option to replace the ppolicy LDIF in cn=config on upgrade. It >> has to be scripted. > > I fully understand the technical reason for what went wrong. > > But the sysadmin should not be required to script anything in case a > schema file always shipped by OpenLDAP was updated by a regular OpenLDAP > update. It should simply work like it does with other LDAP server > implementations and cn=config. The OpenLDAP project only provides one thing -- Source code. So no, the sysadmin is actually responsible for ensuring upgrade procedures between versions work for their deployment. If they are using a build of OpenLDAP provided by their OS vendor, then the OS vendor is going to be responsible. However, it is non-trivial for the OS vendor to be aware of what configuration(s) a given end-user is using, and whether or not they are affected by any specific change. Again why I think this particular change should not have gone into RE24. It was a significant breaking change that is non-trivial for end users to deal with. We generally keep such things out of RE24. There are many great logging updates in RE25 for example that can be incredibly helpful for people on RE24 (operation duration, TLS cipher suite logging, etc), but we don't pull them in as it could break tools that depend on the existing 2.4 format. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 9:12 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > This change led to a non-trivial breakage because the back-config > concepts and best practices have serious deficiencies. I actually wrote a utility for Zimbra that replaces the schema in back-config for me on upgrades. This problem would have never manifested there. ;) But it still relies on knowing the exact weighting of the schema files, which in an environment like Zimbra, I could do since I controlled it. For $random installation, it is non-trivial. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 7:57 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > I strongly disagree. It's a schema shipped by OpenLDAP installation. So > this update should have simply worked. Since the schema is stored in the cn=config DB, there's not an option to replace the ppolicy LDIF in cn=config on upgrade. It has to be scripted. > I did test the update with my own installations. > But they simply use slapd.conf. > And it worked. ;-} This would imply you updated the schema files at the same time. If you kept the 2.4.40 ppolicy.schema file with your new configuration, it would not have "simply" worked. Your comparison is not analagous. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 15 Sep '17

15 Sep '17

--On Friday, September 15, 2017 10:01 AM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > And the upgrade issue with 'pwdMaxRecordedFailure' (see other mail > thread) serves as good example how easy it is to run into a operational > dead-end with cn=config. There's no easy way to fix this afterwards > without violating what's considered best practice for maintaining > cn=config. I could give several other examples for this kind of > operational dead-ends. In retrospect, I think the ITS that introduced that change should not have gone into RE24. ;) Unfortunately, one thing that people seldom test in testing calls is upgrade scenarios from older versions of OpenLDAP to a current release, with a variety of configurations, so it was not caught as an issue prior to release. Certainly another reason as to why we need 2.5 out with slapmodify (and possibly a flag to disable loading some modules in that scenario). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

← Newer
1
...
6
7
8
9
10
11
12
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2017