Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
Hi, We wonder about that deprication as well! When will that happen..? How long can we continue to drive the more comfortable road? :-) Have a nice weekend to all! On Thu, 30 Nov 2023 at 16:06, Bastian Tweddell wrote: > > Please also note [1]: > ``` > The older style slapd.conf(5) file is still supported, but its use is > deprecated and support for it will be withdrawn in a future OpenLDAP > release. > ``` > > Is this already on the roadmap when this will happen? > >
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
Hi, We decided to continue using the (old) slapd.conf file, and rely on our openldap MMR-cluster to keep the LDAP service up, while individual servers are restarted. Since the our 2.5 MMR setup is behind a load balancer, clients don't notice individual backend servers going down and coming up again. We just love the simplicity of the config file(and various includes that we do) and also like the inline comments. We configure ldap through ansible scripts.
Re: contextCSN via slapcat outdated, despite having set syncprov-checkpoint
Hi Frédéric,
Wow, you're quick. I tried your suggestion, and it works! :-)
ldapsearch -x -H ldapi:// -b 'o=company,c=com' -s base contextCSN
provides what I need.
Still wonder why "syncprov-checkpoint 100 1" doesn't (always) work, but I
will proceed with your suggestion, the anonymous socket connections.
Passe un bon weekend!
On Fri, 13 Oct 2023 at 15:27, Frédéric Goudal <
frederic.gou...@bordeaux-inp.fr> wrote:
> Hi,
>
> For security reason we do a slapcat every night on our main ldapserver
> and… we have a small desynchronization between our servers during the
> slapcat…
>
> There is no need for authentication to get the constextCSN and if you use
> ldapi you don’t need network.
>
> f.g.
>
> > Le 13 oct. 2023 à 15:20, cYuSeDfZfb cYuSeDfZfb a
> écrit :
> >
> > Hi,
> >
> > We are running replication checks, including one where we compare
> "slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR
> servers.
> >
> > Relevant config (on each server identically through ansible)
> >
> > database mdb
> > maxsize10737418240
> > suffix "o=company,c=com
> > rootdn "cn=ldapadmin,o=company,c=com"
> > rootpw {SSHA}h9xyz.
> > directory /var/symas/openldap-data
> > overlaysyncprov
> > syncprov-checkpoint100 1
> >
> > Now using this config, we would expect the contextCSN to be faily
> up-to-date across all servers, however, this is not always the case.
> >
> > There are occasions where servers contextCSN become 'outdated', while
> others are up-to-date.
> > If we query contextCSN though ldapsearch, the correct contextCSN is
> returned on all servers.
> >
> > This situation can remain for long, and restarting openldap solves it
> immediately.
> >
> > We could of course change our logging to query contextCSN through an
> ldapsearch, but we see advantages (no network, no authentication, etc, etc)
> in using slapcat as well.
> >
> > Is there anything we can do to update on-disk contextCSN more often..?
> > We would expect " syncprov-checkpoint 100 1" to take care of this..?
> >
> > Have a nice weekend, everybody!
> >
> > MJ
> >
>
> —
> Frédéric Goudal
> Ingénieur Système, DSI Bordeaux-INP
> +33 556 84 23 11
>
>
>
>
>
contextCSN via slapcat outdated, despite having set syncprov-checkpoint
Hi,
We are running replication checks, including one where we compare "slapcat
| grep contextCSN" output across our 4 different openldap 2.5 MRR servers.
Relevant config (on each server identically through ansible)
database mdb
maxsize10737418240
suffix "o=company,c=com"
rootdn "cn=ldapadmin,o=company,c=com"
rootpw {SSHA}h9xyz.
directory /var/symas/openldap-data
overlaysyncprov
syncprov-checkpoint100 1
Now using this config, we would expect the contextCSN to be faily
up-to-date across all servers, however, this is not always the case.
There are occasions where servers contextCSN become 'outdated', while
others are up-to-date.
If we query contextCSN though ldapsearch, the correct contextCSN is
returned on all servers.
This situation can remain for long, and restarting openldap solves it
immediately.
We could of course change our logging to query contextCSN through an
ldapsearch, but we see advantages (no network, no authentication, etc, etc)
in using slapcat as well.
Is there anything we can do to update on-disk contextCSN more often..?
We would expect " syncprov-checkpoint 100 1" to take care of this..?
Have a nice weekend, everybody!
MJ
Re: refresh and persistant not always persisting :-)
Hi Quanah, I feel stupid for not having googled "openldap keepalive", and instead write to the list. I have read so much (and seen so many samples) about replication configuration lately, that I thought I did everything correctly. Thanks for patiently pointing at what I should have been able to find out myself. MJ On Wed, 11 Oct 2023 at 16:29, Quanah Gibson-Mount wrote: > > > --On Wednesday, October 11, 2023 4:49 PM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > > > > > > > Hi, > > > > > > Of course I add many more details like detailed configs and logs, just > > ask. > > > > > > We have a 4-host MMR setup, that all replicate to the three others, > > relevant snippets from the config: > > > > We wondered what could cause this behaviour, and started thinking in the > > direction of long-lived tcp connections that perhaps are used in > > refreshAndPersist functionality. (much like in IMAP idle) > > > > > > Is anything special needed to make refreshAndPersistwork reliably through > > firewalls, and across subnets? Does refreshAndPersistwork use (some kind > > of) long-lived network connections..? Is there a kind of "keepalive" > > setting that we could try..? > > Read the section on keepalive settings. This is a common issue with > firewalls and why those settings were introduced. I usually use > keepalive=240:10:30 to go under the (usually default) 5 minute disconnect > most firewalls have. > > --Quanah > >
refresh and persistant not always persisting :-)
Hi, Of course I add many more details like detailed configs and logs, just ask. We have a 4-host MMR setup, that all replicate to the three others, relevant snippets from the config: * moduleload syncprov.la * different (and consistent) serverID's configured correctly on all hosts and then on each host the three other LDAP servers are defined like the below sample from ldapm01.company.com : syncrepl rid=212 provider=ldaps://ldapm02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=232 provider=ldaps://ldaps01.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=242 provider=ldaps://ldaps02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand MirrorMode True We observe that usually replication is quick and instant. But "sometimes" (yes, sometimes...) a replication line (rid) can become 'stuck', and suddeny, after an hour or so it syncs up again. Restarting openldap make it sync immediately. We notice that because we compare contextCSN's across our nodes to monitor replication. There is no significant load, firewall ports are open, but hosts are in different subnets: subnet A: ldapm01 / ldapm02, subnet B: ldaps01 / ldaps02 Of course 389/636 ports are open between the subnets. We wondered what could cause this behaviour, and started thinking in the direction of long-lived tcp connections that perhaps are used in refreshAndPersist functionality. (much like in IMAP idle) Is anything special needed to make refreshAndPersistwork reliably through firewalls, and across subnets? Does refreshAndPersistwork use (some kind of) long-lived network connections..? Is there a kind of "keepalive" setting that we could try..? Input would be appreciated. Also input like: you are looking in the wrong direction, better look into this or that. :-) Thanks!
Re: [EXT] Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
Hi Ulrich, I thought the same, but it seems yum/dnf do not have a post-install 'hook', like debian has with DPkg::Pre-Install-Pkgs & DPkg::Post-Invoke, that allows you to define commands/scripts to run before and after. Not sure how to do something similar on RHEL. I have now excluded openldap from auto updates, and added instructions on our manual update.instructions. Any ideas here..? On Wed, 11 Oct 2023 at 11:05, Windl, Ulrich wrote: > I wonder: > Couldn't some RPM "pre-script" remember the current permissions for some > RPM "post script" to restore them (after they were messed up)? > > -Original Message- > From: cYuSeDfZfb cYuSeDfZfb > Sent: Thursday, September 21, 2023 10:54 AM > To: Ondřej Kuzník > Cc: openldap-technical@openldap.org; Dimitar Stoychev > > Subject: [EXT] Re: regular yum symas-openldap-servers update breaks > permissions on /var/symas/openldap-data > > Hi Ondřej, > > Thanks for your reply. > > Yes, we are putting our (single file) mdb straight in > /var/symas/openldap-data, using subdirs never crossed our minds. > > Anyway, we just have to document this behaviour in our upgrade > documentation. > > Must say: the behaviour, for us, is a little bit unexcpected. We didn't > expect rpm upgrades to "mess" with fs permissions, but we can simply work > around it. > > Thanks again for your reply, appreciated! > > > On Wed, 13 Sept 2023 at 12:25, Ondřej Kuzník on...@mistotebe.net> > wrote: > > > On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb > wrote: > > Hi, > > > > We're seeing this quite consistently. > > > > Before updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx--. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > > > After updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx--. 3 root root 50 Aug 28 16:28 openldap-data > > > > And afterwards symas-openldap-server (running as ldap:ldap) no > longer > > starts, since permission denied on /var/symas/openldap-data. > > > > Reverting the permissions back to ldap:ldap solves it. But...WHY > is this > > happening. > > > > Are we somehow encouraged to run openldap as root..? > > > > Why would a post-install script reset permissions on > > /var/symas/openldap-data? > > Hi, > openldap-data is owned by the package and as such you'll have to > tell > rpm somehow (a trigger, ...) that you don't want it to mess with > it. > AFAIK there's work ongoing to make the directory 711 which should > sort > things for you. > > That's unless you're putting the databases directly into > /var/symas/openldap-data, we advise you create a subdirectory per > DB, > e.g. /var/symas/openldap-data/dc=example,dc=com or > /var/symas/openldap-data/cn=accesslog. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP > > >
Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
Hi Ondřej, Thanks for your reply. Yes, we are putting our (single file) mdb straight in /var/symas/openldap-data, using subdirs never crossed our minds. Anyway, we just have to document this behaviour in our upgrade documentation. Must say: the behaviour, for us, is a little bit unexcpected. We didn't expect rpm upgrades to "mess" with fs permissions, but we can simply work around it. Thanks again for your reply, appreciated! On Wed, 13 Sept 2023 at 12:25, Ondřej Kuzník wrote: > On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb wrote: > > Hi, > > > > We're seeing this quite consistently. > > > > Before updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx--. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > > > After updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx--. 3 root root 50 Aug 28 16:28 openldap-data > > > > And afterwards symas-openldap-server (running as ldap:ldap) no longer > > starts, since permission denied on /var/symas/openldap-data. > > > > Reverting the permissions back to ldap:ldap solves it. But...WHY is this > > happening. > > > > Are we somehow encouraged to run openldap as root..? > > > > Why would a post-install script reset permissions on > > /var/symas/openldap-data? > > Hi, > openldap-data is owned by the package and as such you'll have to tell > rpm somehow (a trigger, ...) that you don't want it to mess with it. > AFAIK there's work ongoing to make the directory 711 which should sort > things for you. > > That's unless you're putting the databases directly into > /var/symas/openldap-data, we advise you create a subdirectory per DB, > e.g. /var/symas/openldap-data/dc=example,dc=com or > /var/symas/openldap-data/cn=accesslog. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by OpenLDAP >
slapd-watcher -i X refreshing unexpectedly...?
Hi,
We noticed that, when using "slapd-watcher -i X" option to refresh display
every X seconds, lagging replication statuses are often not cleared, when
in fact replication as already recovered.
In our MMR environment, we often see this for longer periods of time in
slapd-watcher output :
contextCSN: 20230913104435.605937Z#00#0dd#00 actv@2023-09-13
10:44:35, idle@2023-09-13 10:44:37
But when running like this:
do
timeout --foreground 1 $SLAPDWATCHER -b $BASE -D $LDAPBINDDN -w
$ADMINPW "${SERVERURIS[@]}" -s ${SERVERIDS[*]}
done
the lagging replication lines change back to "idle, sync'd" immediately
after replication has recovered.
It feels like perhaps there is something wrong in the way the -i X option
is implemented.
For the rest: great tool to have!
Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
Hi, We're seeing this quite consistently. Before updating: [root@ldaps01 log]# ls -l /var/symas/ drwx--. 3 ldap ldap 50 Aug 28 16:28 openldap-data After updating: [root@ldaps01 log]# ls -l /var/symas/ drwx--. 3 root root 50 Aug 28 16:28 openldap-data And afterwards symas-openldap-server (running as ldap:ldap) no longer starts, since permission denied on /var/symas/openldap-data. Reverting the permissions back to ldap:ldap solves it. But...WHY is this happening. Are we somehow encouraged to run openldap as root..? Why would a post-install script reset permissions on /var/symas/openldap-data? Thanks!
regular yum update 2.5.14 -> 2.5.16 resets rights on /var/symas/openldap-data
Hi, Just a quick warning to all: we upgraded a RHEL9 test system from 2.5.14 to 2.5.16, and see: Before: [root@ldaps01 log]# ls -l /var/symas/ drwx--. 3 ldap ldap 50 Aug 28 16:28 openldap-data After: [root@ldaps01 log]# ls -l /var/symas/ drwx--. 3 root root 50 Aug 28 16:28 openldap-data So after the update, ldap no longer started, due to "invalid path: Permission denied" Reverting the permissions back to ldap:ldap solves it. But... is this somehow on purpose, or?
Re: question on include ./acls/*.conf
Hi Ondřej and Quanah, Many thanks for your reaction! On Wed, 19 Jul 2023 at 18:28, Ondřej Kuzník wrote: > On Wed, Jul 19, 2023 at 11:01:23AM +0200, cYuSeDfZfb cYuSeDfZfb wrote: > > Hi, > > > > We're wondering: is there some clever way to include any number of .conf > > files that exist in a certain directory? > > > > Something like, in slapd.conf: > > > > include /opt/symas/etc/openldap/acls/*.conf > > > > This would allow us to simply add & remove.conf files under that > directory, > > and restart openldap. > > > > Is that way of configuring (wildcard includes) not supported..? Or are we > > missing something else? > > > > Is there some other way of doing this..? > > Hi, > it's not supported at the moment. AFAIK people who need it usually > add/remove includes in slapd.conf programmatically with ansible/puppet > or assemble the whole file that way. > > I am looking into adding sudoers(5) style `includedir` directive support > for slapd.conf, not clear whether it will make it into 2.7 yet. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by OpenLDAP >
question on include ./acls/*.conf
Hi, We're wondering: is there some clever way to include any number of .conf files that exist in a certain directory? Something like, in slapd.conf: include /opt/symas/etc/openldap/acls/*.conf This would allow us to simply add & remove.conf files under that directory, and restart openldap. We're now getting errors: /opt/symas/etc/openldap/slapd.conf: line 109 (include /opt/symas/etc/openldap/acls/*.conf) could not stat config file " /opt/symas/etc/openldap/acls/*.conf": No such file or directory Is that way of configuring (wildcard includes) not supported..? Or are we missing something else? Is there some other way of doing this..?
auditlog to syslog
Hi, Playing with openldap 2.5 auditlog. Logging to a file works nicely. We wonder (as we use graylog for syslog aggregation for all (LDAP) servers) ... Is it possible to process the auditlogs through syslog? Tip for all: we have solved so many problems just by searching through graylog... if you don't use graylog (or some other log aggregation tool)... consider implementing it!
Re: CSN too old on each MOD, on working 4-node multi-master
Thanks for confirming what we already suspected (and hoped as well) :-) On Tue, 11 Jul 2023 at 16:54, Quanah Gibson-Mount wrote: > > > --On Tuesday, July 11, 2023 2:26 PM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > > > > > > > Hi, > > > > > > We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems > > to work perfectly now. With some (highly appreciated) help from this > list. > > > > > But actually: content *is* replicated instantly (within the same second) > > and the actual served contents between the four ldap (MultiMaster) > > servers matches. > > The RID changes, and is always one of the configured replication lines, > > and the date/time on the four involved hosts is in sync. > > > > > > > > Is this 'just an informational message', and 'normal', and should we > > ignore it? Or is it something to worry about and investigate further? > > Yes, it's informational. Think of it this way: > > Server A receives the modification. Servers B, C, D, replicate the change. > Server A sees that a change was made on Server B, then sees it's too old > and discards it. Same happens when Server A sees the change show up on > Servers C & D as well. And same thing happens for B with servers C & D, > and Server C with B & D, etc. The replication protocol can be very chatty > with MMR because it's constantly noting it is skipping changes it already > received. > > --Quanah > > > >
CSN too old on each MOD, on working 4-node multi-master
Hi, We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems to work perfectly now. With some (highly appreciated) help from this list. However, there is one observation we don't understand, that we would appreciate feedback on. On directory edits, such as a password change, using the rootDN: ldappasswd -H ldaps://ldap01.company.com -D "cn=admin,o=company,c=com" -W -S "uid=username,ou=Users,o=company,c=com" New password: Re-enter new password: Enter LDAP Password: we always receive several (mostly three, sometimes four) of these messages instantly: do_syncrep2: rid=212 CSN too old, ignoring 20230710140929.887114Z#00#0de#00 (uid=username,ou=Users,o=company,c=com)" But actually: content *is* replicated instantly (within the same second) and the actual served contents between the four ldap (MultiMaster) servers matches. The RID changes, and is always one of the configured replication lines, and the date/time on the four involved hosts is in sync. Is this 'just an informational message', and 'normal', and should we ignore it? Or is it something to worry about and investigate further? In the latter case, of course I will share our configs, which are taken from https://www.openldap.org/doc/admin25/replication.html#N-Way%20Multi-Master As otherwise everything seems to be working correctly, I don't expect major issues there. (but again: of course willing to share!)
Re: trying to understand SID portion in contextCSN
Solution: the -s SID has to be comma separated for multiple values. Space separation gives "Number of sids doesn't equal number of server URLs" Comma separation also displays the expected contextCSN replication lines. So... all solved :-) On Fri, 7 Jul 2023 at 10:38, cYuSeDfZfb cYuSeDfZfb wrote: > Follow-up, some progress. > > Using our o=company,c=com rootDN I do get some replication info, but only > two lines of them, and not the four that seem to be the current *actual* > configured RIDs. > > The four (current) contextCSN's are displayed with slapcat and ldapsearch: > > dn: o=company,c=com > contextCSN: 20180917142109.725361Z#00#000#00 > contextCSN: 20230622022112.071635Z#00#001#00 > contextCSN: 20230622151105.174343Z#00#002#00 > contextCSN: 20230706131809.608140Z#00#0d3#00 > contextCSN: 20230706131825.932137Z#00#0d4#00 > contextCSN: 20230707083130.119957Z#00#0dd#00 > contextCSN: 20230706132303.902949Z#000000#0de#000000 > > Tips? > > On Fri, 7 Jul 2023 at 10:19, cYuSeDfZfb cYuSeDfZfb > wrote: > >> Follow-up question on slapd-watcher. >> >> In a youtube video (https://www.youtube.com/watch?v=rYW2jQnS_PM) I can >> see that slapd-watcher can display contextCSN replication info, real time >> as it happens, but I'm not getting that info. >> >> Starting it like: >> >> slapd-watcher -i 1 \ >> -b o=company,c=com \ >> -D cn=monitoring,cn=Monitor \ >> -w abc...xyz \ >> ldaps://ldap01.company.com \ >> ldaps://ldap02.company.com \ >> ldaps://ldap03.company.com \ >> ldaps://ldap04.company.com \ >> >> I also tried adding "-s 222 221 212 211" (and also (learning from this >> list) :-) in HEX format) but it only gives: "Number of sids doesn't equal >> number of server URLs" >> (same result with four separate -s options) (for the record: the number >> of SIDs DID match the number of server URLs: four) >> >> This is openldap 2.5, symas packages, RHEL9, in a 4-host multimaster setup >> >> Can anyone explain what is required to also get the real-time replication >> info? >> >> (in the youtube video I see the command is issued even more basic, with >> just -b -i and 4 server URI) >> >> And should I file an issue on the "Number of sids doesn't equal number of >> server URLs"? (as the number DID match) >> >> On Thu, 6 Jul 2023 at 22:17, sacawulu wrote: >> >>> Hi Quanah! >>> >>> Did NOT know that tool! >>> >>> Thanks again! Great info. >>> >>> MJ >>> >>> Op 06-07-2023 om 22:06 schreef Quanah Gibson-Mount: >>> > >>> > >>> > --On Thursday, July 6, 2023 3:44 PM +0200 cYuSeDfZfb cYuSeDfZfb >>> > wrote: >>> > >>> >> >>> >> >>> >> Hi Quanah, >>> >> >>> >> >>> >> Thanks again for your answer. >>> >> >>> >> >>> >> From what you have written, we understand now that we should not aim >>> for >>> >> four identical timestamps in contextCSN attributes on each node. As >>> >> contextCSN is updated (as you said) only when a server receives a >>> direct >>> >> write. (and NOT for writes received through replication) >>> >> >>> >> >>> >> So, as long as the contextCSN output across all four MM-ldap nodes is >>> >> identical, replication is doing it's thing. >>> >> >>> >> >>> >> Specifically, from my original post: >>> >>> contextCSN: 20230622151102.137085Z#00#001#00 >>> >>> contextCSN: 20230622151105.174343Z#00#002#00 >>> >>> contextCSN: 20230627112536.529432Z#00#0dd#00 >>> >>> contextCSN: 20230627112536.529512Z#00#0de#00 >>> >> >>> >> >>> >> The first two servers (001/002) are just as up-to-date as the last >>> two, >>> >> only: more recent writes have come into the cluster through the >>> 0de/0dd >>> >> servers. >>> >> >>> >> >>> >> I have written a script to compare actual ldap served content, and >>> that >>> >> confirms that they all serve the same data. >>> >> >>> >> >>> >> If any of the above is wrong, I'd appreciate to be corrected :-) >>> > >>> > If you were using delta-syncrepl (I see from your configs you are not) >>> > you'd also need to do comparisons on the CSNs in the accesslog DB. >>> > >>> > If you use the Symas OpenLDAP packages, there's also a nice utility >>> > called slapd-watcher that shows you the status of your servers >>> included >>> > in their builds. >>> > >>> > --Quanah >>> > >>> > >>> > >>> >>
Re: trying to understand SID portion in contextCSN
Follow-up, some progress. Using our o=company,c=com rootDN I do get some replication info, but only two lines of them, and not the four that seem to be the current *actual* configured RIDs. The four (current) contextCSN's are displayed with slapcat and ldapsearch: dn: o=company,c=com contextCSN: 20180917142109.725361Z#00#000#00 contextCSN: 20230622022112.071635Z#00#001#00 contextCSN: 20230622151105.174343Z#00#002#00 contextCSN: 20230706131809.608140Z#00#0d3#00 contextCSN: 20230706131825.932137Z#00#0d4#00 contextCSN: 20230707083130.119957Z#00#0dd#00 contextCSN: 20230706132303.902949Z#00#0de#00 Tips? On Fri, 7 Jul 2023 at 10:19, cYuSeDfZfb cYuSeDfZfb wrote: > Follow-up question on slapd-watcher. > > In a youtube video (https://www.youtube.com/watch?v=rYW2jQnS_PM) I can > see that slapd-watcher can display contextCSN replication info, real time > as it happens, but I'm not getting that info. > > Starting it like: > > slapd-watcher -i 1 \ > -b o=company,c=com \ > -D cn=monitoring,cn=Monitor \ > -w abc...xyz \ > ldaps://ldap01.company.com \ > ldaps://ldap02.company.com \ > ldaps://ldap03.company.com \ > ldaps://ldap04.company.com \ > > I also tried adding "-s 222 221 212 211" (and also (learning from this > list) :-) in HEX format) but it only gives: "Number of sids doesn't equal > number of server URLs" > (same result with four separate -s options) (for the record: the number > of SIDs DID match the number of server URLs: four) > > This is openldap 2.5, symas packages, RHEL9, in a 4-host multimaster setup > > Can anyone explain what is required to also get the real-time replication > info? > > (in the youtube video I see the command is issued even more basic, with > just -b -i and 4 server URI) > > And should I file an issue on the "Number of sids doesn't equal number of > server URLs"? (as the number DID match) > > On Thu, 6 Jul 2023 at 22:17, sacawulu wrote: > >> Hi Quanah! >> >> Did NOT know that tool! >> >> Thanks again! Great info. >> >> MJ >> >> Op 06-07-2023 om 22:06 schreef Quanah Gibson-Mount: >> > >> > >> > --On Thursday, July 6, 2023 3:44 PM +0200 cYuSeDfZfb cYuSeDfZfb >> > wrote: >> > >> >> >> >> >> >> Hi Quanah, >> >> >> >> >> >> Thanks again for your answer. >> >> >> >> >> >> From what you have written, we understand now that we should not aim >> for >> >> four identical timestamps in contextCSN attributes on each node. As >> >> contextCSN is updated (as you said) only when a server receives a >> direct >> >> write. (and NOT for writes received through replication) >> >> >> >> >> >> So, as long as the contextCSN output across all four MM-ldap nodes is >> >> identical, replication is doing it's thing. >> >> >> >> >> >> Specifically, from my original post: >> >>> contextCSN: 20230622151102.137085Z#00#001#00 >> >>> contextCSN: 20230622151105.174343Z#00#002#00 >> >>> contextCSN: 20230627112536.529432Z#00#0dd#00 >> >>> contextCSN: 20230627112536.529512Z#00#0de#00 >> >> >> >> >> >> The first two servers (001/002) are just as up-to-date as the last two, >> >> only: more recent writes have come into the cluster through the 0de/0dd >> >> servers. >> >> >> >> >> >> I have written a script to compare actual ldap served content, and that >> >> confirms that they all serve the same data. >> >> >> >> >> >> If any of the above is wrong, I'd appreciate to be corrected :-) >> > >> > If you were using delta-syncrepl (I see from your configs you are not) >> > you'd also need to do comparisons on the CSNs in the accesslog DB. >> > >> > If you use the Symas OpenLDAP packages, there's also a nice utility >> > called slapd-watcher that shows you the status of your servers included >> > in their builds. >> > >> > --Quanah >> > >> > >> > >> >
Re: trying to understand SID portion in contextCSN
Follow-up question on slapd-watcher. In a youtube video (https://www.youtube.com/watch?v=rYW2jQnS_PM) I can see that slapd-watcher can display contextCSN replication info, real time as it happens, but I'm not getting that info. Starting it like: slapd-watcher -i 1 \ -b o=company,c=com \ -D cn=monitoring,cn=Monitor \ -w abc...xyz \ ldaps://ldap01.company.com \ ldaps://ldap02.company.com \ ldaps://ldap03.company.com \ ldaps://ldap04.company.com \ I also tried adding "-s 222 221 212 211" (and also (learning from this list) :-) in HEX format) but it only gives: "Number of sids doesn't equal number of server URLs" (same result with four separate -s options) (for the record: the number of SIDs DID match the number of server URLs: four) This is openldap 2.5, symas packages, RHEL9, in a 4-host multimaster setup Can anyone explain what is required to also get the real-time replication info? (in the youtube video I see the command is issued even more basic, with just -b -i and 4 server URI) And should I file an issue on the "Number of sids doesn't equal number of server URLs"? (as the number DID match) On Thu, 6 Jul 2023 at 22:17, sacawulu wrote: > Hi Quanah! > > Did NOT know that tool! > > Thanks again! Great info. > > MJ > > Op 06-07-2023 om 22:06 schreef Quanah Gibson-Mount: > > > > > > --On Thursday, July 6, 2023 3:44 PM +0200 cYuSeDfZfb cYuSeDfZfb > > wrote: > > > >> > >> > >> Hi Quanah, > >> > >> > >> Thanks again for your answer. > >> > >> > >> From what you have written, we understand now that we should not aim for > >> four identical timestamps in contextCSN attributes on each node. As > >> contextCSN is updated (as you said) only when a server receives a direct > >> write. (and NOT for writes received through replication) > >> > >> > >> So, as long as the contextCSN output across all four MM-ldap nodes is > >> identical, replication is doing it's thing. > >> > >> > >> Specifically, from my original post: > >>> contextCSN: 20230622151102.137085Z#00#001#00 > >>> contextCSN: 20230622151105.174343Z#00#002#00 > >>> contextCSN: 20230627112536.529432Z#00#0dd#00 > >>> contextCSN: 20230627112536.529512Z#00#0de#00 > >> > >> > >> The first two servers (001/002) are just as up-to-date as the last two, > >> only: more recent writes have come into the cluster through the 0de/0dd > >> servers. > >> > >> > >> I have written a script to compare actual ldap served content, and that > >> confirms that they all serve the same data. > >> > >> > >> If any of the above is wrong, I'd appreciate to be corrected :-) > > > > If you were using delta-syncrepl (I see from your configs you are not) > > you'd also need to do comparisons on the CSNs in the accesslog DB. > > > > If you use the Symas OpenLDAP packages, there's also a nice utility > > called slapd-watcher that shows you the status of your servers included > > in their builds. > > > > --Quanah > > > > > > >
Re: trying to understand SID portion in contextCSN
Hi Quanah, Thanks again for your answer. >From what you have written, we understand now that we should not aim for four identical timestamps in contextCSN attributes on each node. As contextCSN is updated (as you said) only when a server receives a direct write. (and NOT for writes received through replication) So, as long as the contextCSN output across all four MM-ldap nodes is identical, replication is doing it's thing. Specifically, from my original post: > contextCSN: 20230622151102.137085Z#00#001#00 > contextCSN: 20230622151105.174343Z#00#002#00 > contextCSN: 20230627112536.529432Z#00#0dd#00 > contextCSN: 20230627112536.529512Z#00#0de#00 The first two servers (001/002) are just as up-to-date as the last two, only: more recent writes have come into the cluster through the 0de/0dd servers. I have written a script to compare actual ldap served content, and that confirms that they all serve the same data. If any of the above is wrong, I'd appreciate to be corrected :-) On Wed, 5 Jul 2023 at 17:09, Quanah Gibson-Mount wrote: > > > --On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > > > serverID 222 ldaps://ldapm01.company.com > > serverID 221 ldaps://ldapm02.company.com > > serverID 212 ldaps://ldapm03.company.com > > serverID 211 ldaps://ldapm04.company.com > > > > And when I (quick and dirty) check contextCSN using slapcat (I know that > > ldapsearch is the better way) I get: > > > > [root@ldapm04 ~]# slapcat | grep contextcsn -i > > contextCSN: 20180917142109.765066Z#00#000#00 > > contextCSN: 20230622151102.137085Z#00#001#00 > > contextCSN: 20230622151105.174343Z#00#002#00 > > contextCSN: 20230627112536.529432Z#00#0dd#00 > > contextCSN: 20230627112536.529512Z#00#0de#00 > > > > The first 2018 contextCSN is irrelevant (it has alwas been there, and I > > should probably try to get rid of it) but the last four seem to be the > > "actual" configured replication 'lines' on each node to the other three, > > like this: > > > > > > Yet: all info I can find tells me that the third field of contextCSN is > > "the SID". > > > > > > Can anyone explain? Are they perhaps HEX? If why the large gap between to > > consequtive pairs..? > > > Hi! > > So #000# is as you noted an old SID from when the system used single > provider. > > The SID values are indeed in hex. Your current non-zero SIDS indicate: > > You have servers with SID values 001, 002 that last received a direct > write > operation on 2023/06/22, about 3 seconds apart. > > You have servers with SID values 221 (0dd) and 222 (0de) that last > received > a direct write operation on 2023/06/27, during the same second. > > Any server that has a different SID value that has never received a direct > write operation will not appear in the list. > > Regards, > Quanah > >
trying to understand SID portion in contextCSN
Hi! Trying to better understand the contextCSN attribute. ContextCSN is formatted like: TIMESTAMP#COUNT#SID#MOD My question is on the SID part: ServerID. I have the following serverID configuration in our 4-server Multi-Master PoC setup: serverID 222 ldaps://ldapm01.company.com serverID 221 ldaps://ldapm02.company.com serverID 212 ldaps://ldapm03.company.com serverID 211 ldaps://ldapm04.company.com And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get: [root@ldapm04 ~]# slapcat | grep contextcsn -i contextCSN: 20180917142109.765066Z#00#000#00 contextCSN: 20230622151102.137085Z#00#001#00 contextCSN: 20230622151105.174343Z#00#002#00 contextCSN: 20230627112536.529432Z#00#0dd#00 contextCSN: 20230627112536.529512Z#00#0de#00 The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this: syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand Now the actual question: contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above. Yet: all info I can find tells me that the third field of contextCSN is "the SID". Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..? Curious :-) Thanks!
Re: observation on serverID / URI match
Hi, Thanks Quanah. Just to follow-up: Yes, with an ldap listener on 0.0.0.0, openldap is *still* able to determine it's own serverID when multiple are configured, based on the above-mentioned code. In my config I do: serverID 1 ldaps://my.ldapserver1.com serverID 2 ldaps://my.ldapserver2.com (nota bene FQDN) and the local hostname is obviously NOT a FQDN but just a (short) hostname. But it is still matched correctly, which is phenomenal, and not something I could read / understand from the docs! :-) I also tested, by changing the config to a non-existing "serverID 2 ldaps:// my.ldapserver5.com <http://my.ldapserver2.com>", and then we do get the "read_config: no serverID / URL match found. Check slapd -h arguments." Impressed by openldap's cleverness. :-) Regards! On Tue, 27 Jun 2023 at 17:40, Quanah Gibson-Mount wrote: > > > --On Monday, June 26, 2023 10:18 PM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > > > Now we wonder if the serverID is determined and set correctly or > > not and even with loglevel -1 the auto-determined "local serverID" > > is not logged on start. > > > > > > Does anyone know? > > > > > > Can the serverID also be determined from the local hostname? Or is there > > any other magic going on? > > > This is determined in the following code block in servers/slapd/config.c: > > < > https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/config.c#L2311 > > > > So that's the magic you are looking for. > > Regards, > Quanah >
Re: problem, and solution | database monitor
I created https://bugs.openldap.org/show_bug.cgi?id=10073 Thanks for making available a great product. On Mon, 26 Jun 2023 at 18:41, Quanah Gibson-Mount wrote: > > > --On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > > > > > > > Hi, > > > > > > I'm posting this mostly for the archives, so that a search for the error > > below will help a next person. > > Hi, > > Please open a bug on this issue at https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > > >
observation on serverID / URI match
Hi, In an attempt to standardize our config as much as possible, we included in our slapd.conf: serverID 1 ldaps://my.ldapserver1.com serverID 2 ldaps://my.ldapserver2.com serverID 3 ldaps://my.ldapserver3.com serverID 4 ldaps://my.ldapserver4.com The hostname of the RHEL9 servers is set to ldapserver1 & ldapserver2, but on the hosts slapd is configured to run like: /opt/symas/lib/slapd -d 0 -h ldap:/// ldaps:/// ldapi:/// -u ldap -g ldap (so... NO uri specified, also not in /etc/default/symas-openldap) We expected to receive an error like: no match between serverID and URI found, but much to our surprise we don't. :-) Now we wonder if the serverID is determined and set correctly or not and even with loglevel -1 the auto-determined "local serverID" is not logged on start. Does anyone know? Can the serverID also be determined from the local hostname? Or is there any other magic going on? And otherwise... why is everything starting regularly, and are we not getting the error message? (we are running a 4 server multi-master replication setup, and replication with the above setting in place is still working normally)
Re: unable to authenticate, ldaps
I found something in the ACL that looks like it is the problem:
# grep -R -i olcaccess ./*
./cn=config/olcDatabase={0}config.ldif:olcAccess: {0}to * by * none
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {0}to * by * none
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {1}to attrs=userpassword
by anonymous auth by * none break
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {2}to dn.base="" by * read
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {3}to attrs=entry by *
read
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {4}to
dn.subtree="o=ldap,c=com" attrs=objectclass,mail,givenName,sn
./cn=config/olcDatabase={1}mdb.ldif:olcAccess: {5}to * by
dn.base="cn=mirrormode,ou=system,o=ldap,c=com"
followed by more of the same.
We are actually running slapd.conf with included files, but output above
was taken from the slapd.d directory, generated using slaptest -f
slapd.conf -F /tmp/slapd.d
The slapd.d generated dir contains olcDatabase={1}mdb.ldif:olcAccess: {0}to
* by * none *ABOVE * olcAccess: {1}to attrs=userpassword by anonymous
auth by * none break
That's probably our issue! But I can't find that line olcAccess: {0} in our
slapd.conf and the included files.
Wondering now how it got there. But... locating that is something for
another day.
You helped us again. (unless you disagree that this is most likely our
issue?)
Thanks, I will post the result after I manage to get that ACL {0} out of my
config.
On Mon, 26 Jun 2023 at 16:44, cYuSeDfZfb cYuSeDfZfb
wrote:
> Hi,
>
> I was preparing some more logging to show. You were *really* quick in your
> reply! :-)
>
> Below more logging, and I will reply to your ACL question next.
>
> Replication after setting the password:
>
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP=
> 192.168.16.36:45316 (IP=0.0.0.0:636)
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed
> (connection lost)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234
> cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry:
> rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID:
> a8ccf30a-88d0-103d-8b70-5f35ddf1cc44
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
> csn=20230626143609.891703Z#00#0dd#00 tid 0x7f68a6afd640
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> be_search (0)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> uid=testuser,ou=Users,o=ldap,c=com
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c10e190 20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops:
> recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on
> opc=0x7f689c008f90
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_matchops: skipping original sid 0dd
> Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
> syncprov_matchops: skipping original sid 0dd
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c10e190 20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
> be_modify uid=testuser,ou=Users,o=ldap,c=com (0)
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c10a010 20230626143609.891703Z#00#0dd#00
> Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
> removing 0x7f689c10a010 20230626143609.891703Z#00#0dd#00
>
> Failed authentication using the correct password:
>
> Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP=
> 192.168.16.36:46196 (IP=0.0.0.0:636)
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established
> tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND
> dn="uid=testuser,ou=Users,o=ldap,c=com" method=128
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0
> syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com
> on opc=0x7f689c008ed0
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0
> generated new csn=20230626143627.270437Z#00#0de#00 manage=1
> Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing
> 0x7f689c110220 20230626143627.270437Z#00#0de#00
> Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp:
> set up a new syncres mode=2
Re: unable to authenticate, ldaps
Hi,
I was preparing some more logging to show. You were *really* quick in your
reply! :-)
Below more logging, and I will reply to your ACL question next.
Replication after setting the password:
Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP=
192.168.16.36:45316 (IP=0.0.0.0:636)
Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed
(connection lost)
Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234
cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry:
rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID:
a8ccf30a-88d0-103d-8b70-5f35ddf1cc44
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
csn=20230626143609.891703Z#00#0dd#00 tid 0x7f68a6afd640
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
be_search (0)
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
uid=testuser,ou=Users,o=ldap,c=com
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
0x7f689c10e190 20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops:
recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on
opc=0x7f689c008f90
Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_matchops: skipping original sid 0dd
Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_matchops: skipping original sid 0dd
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
removing 0x7f689c10e190 20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234
be_modify uid=testuser,ou=Users,o=ldap,c=com (0)
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing
0x7f689c10a010 20230626143609.891703Z#00#0dd#00
Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
removing 0x7f689c10a010 20230626143609.891703Z#00#0dd#00
Failed authentication using the correct password:
Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP=
192.168.16.36:46196 (IP=0.0.0.0:636)
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND
dn="uid=testuser,ou=Users,o=ldap,c=com" method=128
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0
syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com
on opc=0x7f689c008ed0
Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0
generated new csn=20230626143627.270437Z#00#0de#00 manage=1
Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing
0x7f689c110220 20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp:
set up a new syncres mode=2 csn=20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn:
removing 0x7f689c110220 20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_sendresp: to=0dd,
cookie=rid=243,sid=0de,csn=20230626143627.270437Z#00#0de#00
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1
syncprov_sendresp: sending LDAP_SYNC_MODIFY,
dn=uid=testuser,ou=Users,o=ldap,c=com
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 RESULT tag=97
err=49 qtime=0.15 etime=0.001002 text=
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=1 UNBIND
Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 closed
On Mon, 26 Jun 2023 at 16:36, Quanah Gibson-Mount
wrote:
>
>
> --On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb
> wrote:
>
> >
> >
> > Hi all!
> >
> >
> > We have this in place:olcAccess: {1}to attrs=userpassword by anonymous
> > auth by * none break
>
> It's impossible to answer this question without knowing the rest of your
> ACLs. For example the acl in slot {0} could mean that the acl in slot {1}
> is never evaluated.
>
> --Quanah
>
>
>
>
unable to authenticate, ldaps
Hi all!
We have this in place:
olcAccess: {1}to attrs=userpassword by anonymous auth by * none break
Using the RootDN to set a user password:
# ldappasswd -H ldaps://my.ldapserver1.com -D "cn=admin,o=ldap,c=com" -W
-S "uid=testuser,ou=Users,o=ldap,c=com" -v
New password:
Re-enter new password:
Enter LDAP Password:
ldap_initialize( ldaps://my.ldapserver1.com:636/??base )
Enter LDAP Password:
Result: Success (0)
We observe the password change replicate (master-master) to our other
server.
Then to test access:
# ldapsearch -H ldaps://my.ldapserver1.com -s base -b o=ldap,c=com -D
"uid=testuser,ou=Users,o=ldap,c=com" -w -v
ldap_initialize( ldaps://my.ldapserver1.com:636/??base )
ldap_bind: Invalid credentials (49)
More background: this is fresh a master-master setup, replication works
with the root DN, and all other user authentications fails with the same
Invalid credentials (49)
The server ldaps://my.ldapserver1.com is an actual single (master) server,
no load balancers, no firewalling. Configured an with actual (and valid)
certificate, ldapsearch uses the correct CA, and ldapsearch with the root
DN works fine. This is latest symas openldap 2.5 on RHEL9.
Anyone with an idea why we can only authenticate as the RootDN, and all
other authentications give Invalid credentials (49)?
We have double checked whatever we can think of, and are *really* unsure
what is going on
Hoping for some clues from the experts here :-)
architectural question on master-slave vs multi-master
Hi, As you have already may have discovered by my many posts lately, we're busy with our ldap environment, and migrating from openldap 2.4 (bdb/RHEL7) to 2.5 on mbd/RHEL9. We've always had a duo of masters, replicating to a (READ ONLY) duo of slaves. All clients are configured to talk to the slaves, through a load balancer, and the masters pretty much only receive updates to the DIT from IdM. Our problem is: how to handle failed authentications (ppolicy) considering that the slaves are read-only and the slaves is where the failed authentications take place. Hence, my request for feedback: is master-slave still considered "the best way" of doing this? And then, is there a "standard way" to handle failed authentications on read-only slaves? Or perhaps... is it nowadays better to chose for a simpler multi-master (4 hosts) LDAP setup: four identical servers, where we choose to send clients to two specific servers (firewalled differently to handle client access) and two others to receive updates from IdM, but use multi-master replication so that all changes (either from IdM, or from failed authentications) are replicated equally between all four servers. Seems that new approach is much simpler. Any feedback? What is wise?
problem, and solution | database monitor
Hi,
I'm posting this mostly for the archives, so that a search for the error
below will help a next person.
Today I wanted to setup the cn=Monitor backend, and after doing so,
openldap failed to start with:
backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1)
The reason turned out to be: we had configured one of our databases
("database ldap") without a suffix.
After I added a suffix, openldap started, and cn=Monitor worked as expected.
I added a simple placeholder suffix (o=ldap,c=com) and now I need to find
out what the database ldap was actually used for in our setup, and what the
proper suffix should be.
(does anyone perhaps know what openldap used as a default, if a "database
ldap" suffix is omitted from the config?)
Anyway: Hopefully this post will help a future someone with the same error
message, as the error message had little to do the the cause.
Re: migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
Hi Clément, Thank you for the link! On Wed, 21 Jun 2023 at 08:58, Clément OUDOT wrote: > > > Le mer. 21 juin 2023 à 08:39, cYuSeDfZfb cYuSeDfZfb > a écrit : > >> Hi Quanah, >> >> Thanks for your answer and kind suggestions! We will implement them. >> >> And anyone here using zabbix, and has some scripting for monitoring >> laying around..? >> >> > Hello, > > we provide some monitoring scripts in LDAP Tool Box project, for example: > https://ltb-project.org/documentation/check_lmdb_usage.html > > Clément. >
Re: migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
Hi Quanah, Thanks for your answer and kind suggestions! We will implement them. And anyone here using zabbix, and has some scripting for monitoring laying around..? Thanks! On Fri, 16 Jun 2023 at 16:42, Quanah Gibson-Mount wrote: > > > --On Thursday, June 15, 2023 10:51 PM +0200 sacawulu > > wrote: > > > > Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not > > the db_verify, which is bdb specific. > > > > I don't find a lot of info on the maintenance / integrity checks that can > > be done on mdb databases. In fact: Mostly what I can find is: "MDB uses > > no caching and requires no tuning to deliver maximum search performance" > > There's very little necessary to be done when using back-mdb as you've > already discovered > > > That is very good. :-) We have already discovered that we need to > > increase maxsize, as our database is (much) larger than 10MB. > > The rule of thumb for maxsize is to set it to something larger than you > ever expect to hit. For example, with a database I'm using that's ~3.4GB > in size, I have a 20GB maxsize set. You may want to monitor the size of > your database vs the configured maxsize. This can be done with data > available in the back-monitor database (at least with 2.6, not sure with > 2.5) or via the mdb_stat utility. > > python-ldap3 snippet using back-monitor: > > try: > tls = Tls(validate=ssl.CERT_NONE, version=ssl.PROTOCOL_TLSv1_2) > conn = Connection(Server(ldap_url, tls=tls, use_ssl=True), > auto_bind=True) > conn.search( > "cn=monitor", > "(&(objectClass=olmMDBDatabase))", > attributes=["olmMDBPagesMax", "olmMDBPagesUsed", > "namingContexts"], > ) > > for db in conn.entries: > suffix = db.namingContexts.value > # 4096 is the page size in use > # can be found with mdb_stat -e /path/to/database > max_size = int(db.olmMDBPagesMax.value) * 4096 > current_size = int(db.olmMDBPagesUsed.value) * 4096 > pct_used = float(current_size / max_size * 100) > > > > > Anyone else with tips and tricks on daily maintenance or monitoring? > > Scripts to share..? Perhaps zabbix templates..? > > The only other bits I would recommend is if you have object in the > directory that have very large multi-valued attribute data. For example, > if you use groups extensively, and the 'member' attribute has hundreds of > entries, you would probably want to do something like: > > a) Add member as an attribute to be handled by olcSortvals > > b) Add a multival configuration to back-mdb if the attribute is indexed. > For example, if you indexed member "eq". I usually do 100,10. This will > put the index databse into its own subdb, which helps keep fragmentation > from being an issue. > > For example, I had a ~5.5GB DB that was swelling to over 11GB in size due > to fragmentation before implementing those two configuration options. > > > Regards, > Quanah > > > >
Re: no contextCSN attribute on consumers
Op 12-06-2023 om 17:29 schreef Quanah Gibson-Mount: > It appears you are using the historic back-hdb or back-bdb backend to > OpenLDAP. These backends are particularly susceptible to corruption. > You should migrate to using the supported backend (back-mdb). You > should also upgrade to a supported release series (2.5 or 2.6) as 2.4 > hasn't been supported for a few years. Yes we are in the middle of migrating. :-) The old structure still uses bdb, yes. While working on new (RHEL9) servers with symas-repo 2.5 openldap, things started happening with the 'old' (but still production) ldap. Thank you very much for your insights! Kind regards!
Re: no contextCSN attribute on consumers
Some more (perhaps relevant?) backgroup info.
These four servers have recently (last week) been struck by corruption of
the underlying .dbd files. In order to get things working again, we did on
all four servers:
- stop slapd
- slapcat > temp.ldif
- remove /var/lib/ldap/* (except DB_CONFIG)
- slapadd -n 2 -l temp.ldif
- chown ldap:ldap /var/lib/ldap/*
- chown root:root /var/lib/ldap/DB_CONFIG
- start slapd
Perhaps this background info is relevant..?
Thanks again for your efforts, they are much appreciated!
On Mon, 12 Jun 2023 at 17:02, cYuSeDfZfb cYuSeDfZfb
wrote:
> Hi!
>
> I am using the cn=admin,o=infra,c=com with correct password to connect. I
> will further check ACLs! Thank you for that suggestion.
>
> Just to make things more concrete, below are two samples. One on the
> MASTER with contextCSN, and one from the SLAVE without contextCSN.
>
> EXAMPLE SLAVE:
> ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b
> "o=infra,c=com" -s base contextCSN
> # extended LDIF
> #
> # LDAPv3
> # base with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> EXAMPLE MASTER:
> ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b
> "o=infra,c=com" -s base contextCSN
> # extended LDIF
> #
> # LDAPv3
> # base with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # infra, com
> dn: o=infra,c=com
> contextCSN: 20180917142109.765066Z#00#000#00
> contextCSN: 20230612144901.796553Z#00#001#00
> contextCSN: 20230612144904.899482Z#00#002#00
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount
> wrote:
>
>>
>>
>> --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
>> wrote:
>>
>> > Hi Quanah,
>> >
>> > Thanks for the swift reponse! I think I do, yes, see, from consumer one:
>> >
>> > olcSyncrepl: {0}rid=202
>> > provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple
>> > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
>> > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
>> > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
>> > starttls=critical tls_reqcert=demand
>> > olcSyncrepl: {1}rid=201
>> > provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple
>> > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
>> > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
>> > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
>> > starttls=critical tls_reqcert=demand
>> > olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389
>> > olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389
>>
>> That's syncrepl, not syncprov.
>>
>> However, the issue could be ACLs. If you use the rootdn for your
>> database
>> to run the query, can you see the contextCSN value stored in your
>> database
>> root?
>>
>> --Quanah
>>
>>
>>
>>
Re: no contextCSN attribute on consumers
Hi!
I am using the cn=admin,o=infra,c=com with correct password to connect. I
will further check ACLs! Thank you for that suggestion.
Just to make things more concrete, below are two samples. One on the MASTER
with contextCSN, and one from the SLAVE without contextCSN.
EXAMPLE SLAVE:
ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b
"o=infra,c=com" -s base contextCSN
# extended LDIF
#
# LDAPv3
# base with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN
#
# search result
search: 2
result: 0 Success
# numResponses: 1
EXAMPLE MASTER:
ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b
"o=infra,c=com" -s base contextCSN
# extended LDIF
#
# LDAPv3
# base with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN
#
# infra, com
dn: o=infra,c=com
contextCSN: 20180917142109.765066Z#00#000#00
contextCSN: 20230612144901.796553Z#00#001#00
contextCSN: 20230612144904.899482Z#00#002#00
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount
wrote:
>
>
> --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
> wrote:
>
> > Hi Quanah,
> >
> > Thanks for the swift reponse! I think I do, yes, see, from consumer one:
> >
> > olcSyncrepl: {0}rid=202
> > provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple
> > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
> > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
> > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
> > starttls=critical tls_reqcert=demand
> > olcSyncrepl: {1}rid=201
> > provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple
> > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
> > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
> > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
> > starttls=critical tls_reqcert=demand
> > olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389
> > olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389
>
> That's syncrepl, not syncprov.
>
> However, the issue could be ACLs. If you use the rootdn for your database
> to run the query, can you see the contextCSN value stored in your database
> root?
>
> --Quanah
>
>
>
>
Re: no contextCSN attribute on consumers
Hi Quanah,
Thanks for the swift reponse! I think I do, yes, see, from consumer one:
olcSyncrepl: {0}rid=202
provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple
filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
starttls=critical tls_reqcert=demand
olcSyncrepl: {1}rid=201
provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple
filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
starttls=critical tls_reqcert=demand
olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389
olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389
And the second consumer looks similar.
Thanks again!
On Mon, 12 Jun 2023 at 15:56, Quanah Gibson-Mount wrote:
>
>
>
> --On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb
> wrote:
>
> > Is there any explanation, why I would be unable to obtain these
> > contextCSN attributes through an ldapsearch?
>
> Do you have the syncprov overlay instantiated on the database on the
> consumers?
>
> --Quanah
>
>
>
>
no contextCSN attribute on consumers
Hi, We have a 4-machine setup with two providers (replicating between each other) and two consumers (for client access) that both replicate from both providers, type=refreshAndPersist I'm trying to write a script to monitor replication, using the contextCSN attribute. ldapsearch on the providers gives the expected the contextCSN attributes: contextCSN: 20230612115901.693614Z#00#001#00 contextCSN: 20230612115904.937471Z#00#002#00 However, the same ldapsearch on the consumers gives *no* contextCSN attributes *at all*. But when using slapcat to check directly on the consumers databases, we *can* see the attributes, and they are also up-to-date: contextCSN: 20230612115801.572594Z#00#001#00 contextCSN: 20230612115804.594419Z#00#002#00 Is there any explanation, why I would be unable to obtain these contextCSN attributes through an ldapsearch? This is RHEL7.9, with openldap 2.4.44 Thanks!
