openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 19 Sep '19

19 Sep '19

--On Thursday, September 19, 2019 10:26 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thank you, i mean what are the other benefits (like performance) of > using delta replication over full replication other than the ITS#8125 This is covered in the admin guide already: <https://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl%20repl…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

header tag value
by Gustavo Rios 19 Sep '19

19 Sep '19

Hi folks. i am studying the ldap protocol and i have some doubts. I wonder what is the header tag value for the unbind request message. For the bind request the header value is 0x30. May someone here tell me the value for the unbind request tag header? Thanks in advance. -- Pag Bem Fácil Ltda www.pagbemfacil.com.br

1 0

Consistency issue (probably with me)
by Paul Pathiakis 18 Sep '19

18 Sep '19

Hi all, I just went through all of this previously. I documented everything. I don't believe (yeah... believe) I changed anything. I verified that my firewall rules are correct (although this is all local) I just shutdown slapd with: systemctl stop slapd I did: rm -rf /var/lib/ldap/* /etc/openldap/slapd.d/* Changed my password with slappasswd and put the new one in my slapd.conf . Re-initialized everything with: slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d Got that the configuration passed. Checked slapd.d and /var/lib/ldap. Both had expected values/files. Did: chown -R ldap:ldap /etc/openldap/slapd.d /var/lib/ldap systemctl start slapd Tried to add my memberof.ldif file with: ldapadd -f /etc/openldap/memberof.ldif -v -D "cn=config" -H ldap://newldap.hq.example.com -W -c Got prompted for the password and got an "invalid credentials (49)" (I tried re-doing this multiple times with simple passwords....but same issue...) slapd -d -1 shows me: 5d8267a3 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 5d8267a3 backend_startup_one: starting "dc=hq,dc=example,dc=com" 5d8267a3 mdb_db_open: "dc=hq,dc=example,dc=com" 5d8267a3 mdb_db_open: database "dc=hq,dc=example,dc=com": dbenv_open(/var/lib/ldap). 5d8267a3 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5d8267a3 slapd starting 5d8267a3 daemon: added 4r listener=(nil) 5d8267a3 daemon: added 7r listener=0x565118e8b500 5d8267a3 daemon: added 8r listener=0x565118e8b330 5d8267a3 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267a3 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267a3 daemon: activity on 1 descriptor 5d8267a3 daemon: activity on: 5d8267a3 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267a3 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 slap_listener_activate(7): 5d8267b8 daemon: epoll: listen=7 busy 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 >>> slap_listener(ldap:///) 5d8267b8 daemon: listen=7, new connection on 12 5d8267b8 daemon: added 12r (active) listener=(nil) 5d8267b8 conn=1000 fd=12 ACCEPT from IP=192.168.2.60:39984 (IP=0.0.0.0:389) 5d8267b8 daemon: activity on 2 descriptors 5d8267b8 daemon: activity on: 12r 5d8267b8 daemon: read active on 12 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 connection_get(12) 5d8267b8 connection_get(12): got connid=1000 5d8267b8 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 27 02 01 01 60 22 02 0'...`". ldap_read: want=33, got=33 0000: 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 80 12 62 ....cn=config..b 0010: 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 72 69 6e 0020: 67 g ber_get_next: tag 0x30 len 39 contents: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e00 end=0x7f21bc001e27 len=39 0000: 02 01 01 60 22 02 01 03 04 09 63 6e 3d 63 6f 6e ...`".....cn=con 0010: 66 69 67 80 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 fig.. 0020: 6e 65 65 72 69 6e 67 neering 5d8267b8 op tag 0x60, time 1568827320 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable 5d8267b8 conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e03 end=0x7f21bc001e27 len=36 0000: 60 22 02 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 `".....cn=config 0010: 80 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 . 0020: 72 69 6e 67 ring ber_scanf fmt (m}) ber: ber_dump: buf=0x7f21bc001e00 ptr=0x7f21bc001e13 end=0x7f21bc001e27 len=20 0000: 00 12 62 6f 73 74 6f 6e 2d 65 6e 67 69 6e 65 65 . 0010: 72 69 6e 67 ring 5d8267b8 >>> dnPrettyNormal: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5d8267b8 <<< dnPrettyNormal: <cn=config>, <cn=config> 5d8267b8 conn=1000 op=0 BIND dn="cn=config" method=128 5d8267b8 do_bind: version=3 dn="cn=config" method=128 5d8267b8 send_ldap_result: conn=1000 op=0 p=3 5d8267b8 send_ldap_result: err=49 matched="" text="" 5d8267b8 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 12 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 31 04 00 04 00 0....a...1.... 5d8267b8 conn=1000 op=0 RESULT tag=97 err=49 text= 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 12r 5d8267b8 daemon: read active on 12 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero 5d8267b8 connection_get(12) 5d8267b8 connection_get(12): got connid=1000 5d8267b8 connection_read(12): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x7f21bc000a80 ptr=0x7f21bc000a80 end=0x7f21bc000a85 len=5 0000: 02 01 02 42 00 ...B. 5d8267b8 op tag 0x42, time 1568827320 ber_get_next ldap_read: want=8, got=0 5d8267b8 ber_get_next on fd 12 failed errno=0 (Success) 5d8267b8 connection_read(12): input error=-2 id=1000, closing. 5d8267b8 connection_closing: readying conn=1000 sd=12 for close 5d8267b8 connection_close: deferring conn=1000 sd=12 5d8267b8 conn=1000 op=1 do_unbind 5d8267b8 conn=1000 op=1 UNBIND 5d8267b8 connection_resched: attempting closing conn=1000 sd=12 5d8267b8 connection_close: conn=1000 sd=12 5d8267b8 daemon: removing 12 5d8267b8 conn=1000 fd=12 closed 5d8267b8 daemon: activity on 1 descriptor 5d8267b8 daemon: activity on: 5d8267b8 daemon: epoll: listen=7 active_threads=0 tvp=zero 5d8267b8 daemon: epoll: listen=8 active_threads=0 tvp=zero

2 1

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 17 Sep '19

17 Sep '19

--On Monday, September 16, 2019 9:34 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > Any reason you recommend delta replication? It's the only way to mitigate ITS#8125. Running standard syncrepl is just asking for data loss and endless problems. > can you share results of > delta replication over full replication? I'm not sure what you mean. I've been advising delta-syncrepl since OpenLDAP 2.3. > is there any guide/procedure > to change from full to delta replication with out downtime? If you're using cn=config, you can ldapmodify the configuration to enable delta-syncrepl. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

LDAPcon 2019 schedule
by Michael Ströder 16 Sep '19

16 Sep '19

HI! LDAPcon 2019 conference program is now publicly available: https://cfp.ldapcon.org/ldapcon2019/schedule/ Hope to see you all in Sofia in November: https://ldapcon.org/2019/ Ciao, Michael.

2 1

slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
by Norman Gray 13 Sep '19

13 Sep '19

Greetings. I'm having difficulty creating a non-trivial olcUniqueURI spec. Can anyone advise me? The problems are: * A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. * The manpage doesn't make it terribly clear what I should expect from a plausible-looking spec. Details follow: I want to specify something like dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B. If I do this, however, then slapadd spins its wheels: $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C and so on and on and on, apparently indefinitely. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] (I'm taking it that there should be a space between those `URI[URI...]`) in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc * So that's clearly permitting multiple URIs -- perhaps the quotes are required (as the manpage hints). But if I try olcUniqueURI: "ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub" ...then I get 5d77d617 ==> unique_new_domain <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> 5d77d617 olcUniqueURI: value #0: <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> invalid ldap urilist from slapadd (so that's not the problem). But the example there does look VERY much like what I tried. So: * I'm pretty sure I shouldn't be able to make slapadd spin its wheels like that. * The manpage text might be a little too telegraphic. While I'm sure it's not _wrong_, it is quite hard to go from that text to a working spec with any confidence. Googling olcUniqueURI produces very little of use. Is this not the correct way to do this? This looks somewhat similar, in symptoms and module, to ITS#8162, but it does seem distinct. Thanks for any pointers. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 4

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 12 Sep '19

12 Sep '19

--On Thursday, September 12, 2019 12:23 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thanks for quick response, i will consider your recommendations but i > wanted to understand when does consumer go to REFRESH mode? When it detects an inconsitency or error of some type. > 5d7a6178 send_ldap_result: err=66 matched="" text="subordinate objects > must be deleted first" > 5d7a6178 syncrepl_del_nonpresent: rid=001 be_delete dc=example,dc=com (66) > 5d7a6178 => bdb_entry_get: ndn: "dc=example,dc=com" And here is the error. It would appear it's getting the deletes out of sequence as it was requested to delete a parent before a child. I'd also note that back-bdb/hdb are deprecated. I will re-iterate that you need to update to a current release. Anything else is just a waste of time. Please see the change log: <https://www.openldap.org/software/release/changes.html> I'd also heavily advise using back-mdb with the current release and using delta-syncrepl. I would also note that some overlays have undefined behavior in an MMR environment (such as ppolicy as documented in the slapo-ppolicy(5) man page). YMMV with such overlays in use. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

[Q] ModRDN object via Net::LDAP::Control::SyncRequest
by Zeus Panchenko 12 Sep '19

12 Sep '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please advise, how can I catch ModRDN object in syncrepl cosumer? I use perl Net::LDAP on ldapmodrdn I successfully catch LDAP_SYNC_MODIFY event with Net::LDAP::Entry object, DN of which contains *new* rdn ... but how to know/get the old one? accesslog DB doesn't contain reqDN for new rdn yet ... I'm using the example code from Net::LDAP::Control::SyncRequest - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCXXqZHwAKCRCveOk+D/ej KsoLAKCiqf/sGKpYLy0xUybyLCXtkTTVkQCcCfTAoMcwhC+JWHcxvHzeLrppc5w= =cVqP -----END PGP SIGNATURE-----

1 0

Re: logs with "syncrepl_del_nonpresent"
by Quanah Gibson-Mount 12 Sep '19

12 Sep '19

--On Thursday, September 12, 2019 10:57 AM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Any help? > > > On Tue, Sep 10, 2019 at 9:39 AM rammohan ganapavarapu > <rammohanganap(a)gmail.com> wrote: > > > Hi, > > > I have 2 nodes MMR setup with openldap 2.4.44-21 version, i see these > messages in the one of the two server logs, and looks like on consumer > side some of the entries are getting deleted. Sounds like it went into REFRESH. I'd strongly advise: a) Updating to the latest OpenLDAP release (there have been numerous MMR related fixes in the 3.5 years since 2.4.44 was released) and b) Using delta-syncrepl Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Openldap 2.4.x log details for error 49
by François Pernet 11 Sep '19

11 Sep '19

Hi all, We have a solution running on which openldap is the identity repository. OpenLDAP 2.4 is installed (on CentOS) also with policy. The system is able to send traps when authentication problem occurs, based on the slapd generated logs. Unfortunatly the log contains such error: "Jun 5 11:27:16 vms slapd[32101]: conn=1174 op=0 RESULT tag=97 err=49 text=" when the password entered generates an "invalid crendentials" message. This is fine, but the error could mean the following: * Wrong user or password * Expired account * Account locked or disabled * User must change its password Question is : is it possible to find a way to have the details for error 49 ? (this error message is far too generic) Many thanks in advance FPernet

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical