Re: slapd: null_callback : error code 0x14

[Quanah Gibson-Mount]

--On Tuesday, September 19, 2017 7:40 PM -0700 "Paul B. Henson" 
 wrote:



Hmm. I only have one active master, and it's the only server receiving
updates. Let me try including some more detail on an error from this
morning.

So here's the error on the replica:

Sep 19 03:56:19 coeus slapd[43551]: null_callback : error code 0x14
Sep 19 03:56:19 coeus slapd[43551]: syncrepl_message_to_op: rid=003
be_modify uid=egr44503,ou=group,dc=cpp,dc=edu (20)


Well, my first question is, do you see these changes to this group entry in 
the log from your other rid as well?  I.e., if it is being applied twice, 
you should see each modification logged twice.  Usually with sync logging, 
you have lines noting what the CSN is that's being processed as well. 
There's not enough log information here to act on. :)


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: slapd: null_callback : error code 0x14

[Paul B. Henson]

On Mon, Sep 18, 2017 at 08:31:34AM -0700, Quanah Gibson-Mount wrote:

> These aren't "wierd errors".  0x14=20.  I.e., you're simply getting the 
> same error logged twice.

Well, "unexpected" errors perhaps :).

I knew the lines were related but I didn't notice the hex decimal
equivilency.

> Well, error code 20 is "type or value already exists".  If the replica and 
> the masters are starting from the same point, this would tend to imply that 
> the replica is receiving the change multiple times, and it's failing on the 
> subsequent modify operations.

Hmm. I only have one active master, and it's the only server receiving
updates. Let me try including some more detail on an error from this
morning.

So here's the error on the replica:

Sep 19 03:56:19 coeus slapd[43551]: null_callback : error code 0x14
Sep 19 03:56:19 coeus slapd[43551]: syncrepl_message_to_op: rid=003 be_modify 
uid=egr44503,ou=group,dc=cpp,dc=edu (20)

rid 3 is the backup master:

syncreplrid=3
provider=ldaps://minerva.ldap.cpp.edu/

Let's see what's in the accesslog:

dn: reqStart=20170919105619.57Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20170919105619.57Z
reqEnd: 20170919105619.58Z
reqType: modify
reqSession: 1
reqAuthzID: cn=ldaproot,dc=cpp,dc=edu
reqDN: uid=egr44503,ou=group,dc=cpp,dc=edu
reqResult: 0
reqMod: member:- uid=michaelm3,ou=user,dc=cpp,dc=edu
reqMod: entryCSN:= 20170919105619.291799Z#00#004#00
reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu
reqMod: modifyTimestamp:= 20170919105619Z
reqEntryUUID: f0b9ac97-5eec-4ac7-86e6-ac691689a3c8
entryUUID: 390ff571-794c-4fc1-86ac-d72aeac1dbbf
creatorsName: cn=accesslog
createTimestamp: 20170919105619Z
entryCSN: 20170919105619.291799Z#00#004#00
modifiersName: cn=accesslog
modifyTimestamp: 20170919105619Z

dn: reqStart=20170919105619.60Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20170919105619.60Z
reqEnd: 20170919105619.61Z
reqType: modify
reqSession: 1
reqAuthzID: cn=ldaproot,dc=cpp,dc=edu
reqDN: uid=egr44503,ou=group,dc=cpp,dc=edu
reqResult: 0
reqMod: memberUid:- michaelm3
reqMod: entryCSN:= 20170919105619.295478Z#00#004#00
reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu
reqMod: modifyTimestamp:= 20170919105619Z
reqEntryUUID: f0b9ac97-5eec-4ac7-86e6-ac691689a3c8
entryUUID: 6d3a042b-d6ab-4b3e-bc14-6b37eaef91f7
creatorsName: cn=accesslog
createTimestamp: 20170919105619Z
entryCSN: 20170919105619.295478Z#00#004#00
modifiersName: cn=accesslog
modifyTimestamp: 20170919105619Z

dn: reqStart=20170919105619.63Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20170919105619.63Z
reqEnd: 20170919105619.69Z
reqType: modify
reqSession: 1
reqAuthzID: cn=ldaproot,dc=cpp,dc=edu
reqDN: uid=egr44503,ou=group,dc=cpp,dc=edu
reqResult: 0
reqMod: member:+ uid=qxho,ou=user,dc=cpp,dc=edu
reqMod: entryCSN:= 20170919105619.305311Z#00#004#00
reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu
reqMod: modifyTimestamp:= 20170919105619Z
reqEntryUUID: f0b9ac97-5eec-4ac7-86e6-ac691689a3c8
entryUUID: 2ce0cd50-70eb-4bbc-80a5-85fd8322290a
creatorsName: cn=accesslog
createTimestamp: 20170919105619Z
entryCSN: 20170919105619.305311Z#00#004#00
modifiersName: cn=accesslog
modifyTimestamp: 20170919105619Z

dn: reqStart=20170919105619.71Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20170919105619.71Z
reqEnd: 20170919105619.72Z
reqType: modify
reqSession: 1
reqAuthzID: cn=ldaproot,dc=cpp,dc=edu
reqDN: uid=egr44503,ou=group,dc=cpp,dc=edu
reqResult: 0
reqMod: memberUid:+ qxho
reqMod: entryCSN:= 20170919105619.308548Z#00#004#00
reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu
reqMod: modifyTimestamp:= 20170919105619Z
reqEntryUUID: f0b9ac97-5eec-4ac7-86e6-ac691689a3c8
entryUUID: 5f896be6-74b9-4c16-a96a-d7fc6f6a85eb
creatorsName: cn=accesslog
createTimestamp: 20170919105619Z
entryCSN: 20170919105619.308548Z#00#004#00
modifiersName: cn=accesslog
modifyTimestamp: 20170919105619Z

That's all that's in the accesslog. Ok, now in the slapd log on minerva;
there's no mention of egr44503 anywhere in the slapd log. In the
accesslog:

dn: reqStart=20170919105619.55Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20170919105619.55Z
reqEnd: 20170919105619.57Z
reqType: modify
reqSession: 1
reqAuthzID: cn=ldaproot,dc=cpp,dc=edu
reqDN: uid=egr44503,ou=group,dc=cpp,dc=edu
reqResult: 0
reqMod: member:- uid=michaelm3,ou=user,dc=cpp,dc=edu
reqMod: entryCSN:= 20170919105619.291799Z#00#004#00
reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu
reqMod: modifyTimestamp:= 20170919105619Z
reqEntryUUID: f0b9ac97-5eec-4ac7-86e6-ac691689a3c8
entryUUID: be73d55d-bccc-4409-b3e1-1620440a5b99
creatorsName: cn=accesslog
createTimestamp: 

Re: Antw: Re: Olc deployment vs slapd.conf based deployment

[Quanah Gibson-Mount]

--On Tuesday, September 19, 2017 7:31 PM +0200 Radovan Semancik 
 wrote:



What I meant were external contributions from people outside of the core
team. And I have obviously missed (at least) one such contribution. I'm
sorry for this. My fault. And I get your point and I apologize for this
confusion.


One thing you're likely missing is that -devel is generally used for 
discussion of new feature requests.  The ITS system (and thus the 
openldap-bugs list) are where discussion generally occurs for contributions 
related to existing features.  So the -devel list is generally much lower 
traffic.  For example, this is the archive for September (so far):






I just want to point out I haven't failed to notice that all of my other
points got ignored.


I didn't think any of the rest of what you said was valid so there was 
nothing to address.  You came in with a premise that was not based on fact. 
There are numerous people contributing that are not direct project team 
members, and they don't have issues with the contribution process.


--Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Getting ldappasswd and PAM in the same page under CentOS 7

[Robert Heller]

I am having a hard time setting a user password using ldap (OpenLDAP 
2.4.40-13.el7) on a CentOS 7 system.

I have installed OpenLDAP 2.4.40-13.el7 (stock CentOS 7 server and client),
nss-pam-ldapd (0.8.13-8.el7) and used authconfig to enable ldap. I have
created a user in the ldap database, and getent works just fine -- the uid and
gid are seen, etc. But I cannot set the user's password in a way that works
for su (and presumably login/slogin, etc.).  I am using ldappasswd to set the 
user's password.

I am thinking that PAM and ldappasswd are using *different* oneway encryption 
methods and I am guessing I need to update a configuration somewhere (either 
for pam, sssd, or nslcd), but I am not finding it.

-- 
Robert Heller -- 978-544-6933
Deepwoods Software-- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
hel...@deepsoft.com   -- Webhosting Services
  

Re: Antw: Re: Olc deployment vs slapd.conf based deployment

[Radovan Semancik]

What I meant were external contributions from people outside of the core 
team. And I have obviously missed (at least) one such contribution. I'm 
sorry for this. My fault. And I get your point and I apologize for this 
confusion.


I just want to point out I haven't failed to notice that all of my other 
points got ignored. But I'm afraid that it does not make much difference 
anyway. I do not think I can help here. And I do not think I can improve 
this project in any way. I'm really sorry for this. And I sincerely 
apologize for all this uproar that I have caused in the mailing list. 
But I consider the information that I have got from this discussion to 
be very important. And I think that it may be also important for other 
potential contributors and users of OpenLDAP.


Thank you all for your time.

--
Radovan Semancik
Software Architect
evolveum.com



On 09/19/2017 06:14 PM, Quanah Gibson-Mount wrote:
--On Tuesday, September 19, 2017 11:54 AM +0200 Radovan Semancik 
 wrote:



Regarding the pull requests and discussions: I have checked the devel
mailing list for several months and I haven't see any discussion
regarding a contribution.


Really? You must not have looked very hard then.

 
covers some 22 contributions.


 
discussions some contributions related to man page fixes.


 
covers work I did to make TLS command line options for the ldap* tools


 is 
part of an ongoing discussion of allowing ldap clients to use a 
specific local address


 is 
a discussion about adding ldap_init_fd contribution from samba



etc.



What I see as a major problem is that there is no will. OpenLDAP project
clearly needs major improvement. But there are almost no contributors to
improve the project.


As demonstrated by the above you clearly are incorrect.  I would 
generally suggest you withhold comment on the project until you have 
some clue what you're talking about.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Antw: Re: Olc deployment vs slapd.conf based deployment

[Quanah Gibson-Mount]

--On Tuesday, September 19, 2017 11:54 AM +0200 Radovan Semancik 
 wrote:



Regarding the pull requests and discussions: I have checked the devel
mailing list for several months and I haven't see any discussion
regarding a contribution.


Really? You must not have looked very hard then.

 covers 
some 22 contributions.


 
discussions some contributions related to man page fixes.


 covers 
work I did to make TLS command line options for the ldap* tools


 is part 
of an ongoing discussion of allowing ldap clients to use a specific local 
address


 is a 
discussion about adding ldap_init_fd contribution from samba



etc.



What I see as a major problem is that there is no will. OpenLDAP project
clearly needs major improvement. But there are almost no contributors to
improve the project.


As demonstrated by the above you clearly are incorrect.  I would generally 
suggest you withhold comment on the project until you have some clue what 
you're talking about.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Olc deployment vs slapd.conf based deployment

[Dieter Klünter]

Am Mon, 18 Sep 2017 10:12:23 -0400
schrieb Brian Reichert :

> On Sat, Sep 16, 2017 at 04:24:36PM +0200, Daniel Pluta wrote:
> > On 16.09.2017 09:04, Michael Str??der wrote:  
> > >Daniel Pluta wrote:  
> > >>Call it strange, useless, insane, fine or whatever, but my
> > >>customers (also anybody who's interested in using a distinct
> > >>service) should be able to get a chance for a detailed view into
> > >>the running configuration of each service - before and while
> > >>using it. slapd's cn=config supports this, not perfectly but
> > >>better than any other service I'm aware of. For further details
> > >>see our paper from LDAPcon2011.  
> 
> I'm jumping in late here.  I'm curious about this talk.  I see a
> YouTube playlist of LDAPCon 2011 talkshere; which one should I look
> at for these details?

There is no video, but you may read the papers.
https://ldapcon.org/2011/downloads/plutahommelweinert-paper.pdf

[...]

>   https://www.youtube.com/playlist?list=PLXuMrj-t1hqGdOJvswPFvNtwZFHD5SODK
> 
> > >
> > >I very well remember your interesting talk and that you give read
> > >access to olcRootDN to prove it's not set.  
> > 
> > 
> > It was olcRootPw: to prove that it's not present and thus there is
> > no slapd-BOFH (aka administrative man-in-the-middle).
> > 
> > I very well remember the shocked/laughing faces of (parts of) the 
> > audience right after I switched to the slide containing this at
> > first surely suicidal seeming ACL.
> > 
> > Forget about it. It's sufficient to keep in mind that the future
> > lies in cn=config. ;-)

-Dieter


-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

Re: Olc deployment vs slapd.conf based deployment

[Christopher Wood]

On Mon, Sep 18, 2017 at 08:01:31PM +0200, Michael Ströder wrote:
> Quanah Gibson-Mount wrote:
> > > So instead of writing a single file (in one FS transaction) after
> > > letting slaptest check it I have to write several files (multiple
> > > FS operations), diff that and then apply multiple LDAP operations.
> > 
> > Hm? How is this any different really than tracking slapd.conf in git?
> > And plenty of people break out slapd.conf into multiple files and use
> > "include" handling to pull, such as with schema, ACLs, etc.  I see no
> > difference here.
> 
> (Except the schema files) I break up slapd.conf in several *templates* but
> the config management (currently ansible) generates a single slapd.conf file
> on the target system. So after the includes in the template engine there is
> a single file transferred to the target and installed there.
> 
> > > Yeah, sounds really great regarding error handling.
> > 
> > How does this differ from slapd.conf?  You get no error handling with
> > that, either, if you modify it and commit it to git.
> 
> I had some detail issue with slaptest I have to revisit. But mainly I want
> to use "validate: slaptest..." in the ansible template task to avoid
> installing a broken slapd.conf. Yes, that's feasible even with a directory
> tree. But it needs much more work/caution without added value.
> 
> Ciao, Michael.
> 

It feels like it would be relatively trivial to run a cn=config managed by a 
configuration management system. I've already gotten puppet to stand up a 
multimaster pair where the replication Just Works (at two jobs now), so 
ensuring that the CM doesn't mess up the existing cn=config seems fairly 
trivial with the -F option to slapd.

The ingredients and sequence (I have a+b and that's fine for me right now):

a) ldif template, creates an ldif file on the host
b) slapadd exec which runs (only once) on the ldif to populate a specific 
cn=config directory, requires the ldif file to exist
c) exec which runs slaptest on that directory, requires the slapadd exec to 
ahve succeeded
d) init script template where -F points to that directory, service restart 
requires the slaptest to have succeeded

If I hook everything on to the template name then I would get:

1) the ldif

/etc/me/config_one.ldif

2) cn=config

/opt/openldap/etc/openldap/config_one/cn=config.ldif

3) init script (cut-down example)

stop() {
  kill `cat /var/run/openldap.pid`
}

start() {
  /opt/openldap/libexec/slapd -F /opt/openldap/etc/openldap/config_one
}

restart() {
  start
  stop
}

This seems like it would work because the init script stop doesn't rely on the 
cn=config directory being known, and every config change is a different 
template. I could also work out something deft with the commit hash of the git 
repository holding the templates combining with the template filename to make 
something more unique so that templates themselves could change, but you get 
the general idea.

Re: Instructions for Open LDAP library?

[John Lewis]

On Mon, 2017-09-18 at 14:31 +1200, Martin van den Nieuwelaar wrote:
> Hi People,
> 
> I'm writing an application using Qt and wish to use the openldap
> library 
> within my program to query an LDAP server.  I have been searching
> for 
> instructions on using the library from a client point of view but
> have 
> not been successful.  I tried using the man pages and I think I'm
> part 
> way there but have reached an impasse on the correct way (or any way
> at 
> all for that matter) to extract the results from an LDAPMessage
> *.  I 
> have an example search working using the command line program 
> ldap_search, so the next thought is to look at the source for 
> ldap_search and see what calls it makes to figure things out.  This 
> somehow seems like the wrong way to be going about things however.
> 
> Is there something equivalent for openldap to the documentation for 
> libcurl, https://ec.haxx.se/libcurl-easyhandle.html ?  If there is
> that 
> would be brilliant.
> 
> I also tried searching for 3rd party howtos and tutorials and there
> are 
> a few of those but invariably they use now deprecated library calls.
> 
> Regards,
> 
> -Martin
> 
> 

The libcurl library supports LDAP. Howard Chu even wrote a new LDAP
implementation for it back in 2010 to make it fully asynchronous. Is
there a good reason not to use it?