October 2021 - openldap-bugs

[Issue 9730] New: logfile-rotate directive fails in 2.6.0

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9730 Issue ID: 9730 Summary: logfile-rotate directive fails in 2.6.0 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Hello, When setting the logfile-rotate, I get: 617bc9ae.1b73de17 0x7f44f87c9740 /usr/local/openldap/etc/openldap/slapd.conf: line 12 (logfile-rotate 10 100 24) 617bc9ae.1b759154 0x7f44f87c9740 /usr/local/openldap/etc/openldap/slapd.conf: line 12: <logfile-rotate> handler exited with 16384! My configuration file is below. I am using the 2.6.0 release. The strange part is that the same configuration converted into cn=config seems to work well. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema logfile-rotate 10 100 24 logfile /var/log/slapd-ltb/slapd.log logLevel 256 sasl-host ldap.my-domain.com pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args # Load dynamic backend modules: # moduleload back_ldap.la modulepath /usr/local/openldap/libexec/openldap moduleload argon2.la moduleload back_mdb.la moduleload dynlist.la moduleload memberof.la moduleload ppolicy.la moduleload syncprov.la moduleload unique.la access to dn.base="" by * read access to dn.base="cn=subschema" by * read ####################################################################### # config database definitions ####################################################################### database config rootdn cn=config rootpw secret access to attrs="userPassword" by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth =wdx by * auth access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage ####################################################################### # MDB database definitions ####################################################################### database mdb maxsize 4294967296 suffix dc=my-domain,dc=com rootdn cn=Manager,dc=my-domain,dc=com rootpw secret directory /usr/local/openldap/var/openldap-data index objectClass eq index cn eq,sub index uid pres,eq index givenName pres,eq,sub index l pres,eq index employeeType pres,eq index mail pres,eq,sub index sn pres,eq,sub limits group="cn=admin,ou=groups,dc=my-domain,dc=com" size=unlimited time=unlimited access to attrs="userPassword" by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth =wdx by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" =wdx by self =wdx by * auth access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by group.exact="cn=admin,ou=groups,dc=my-domain,dc=com" write by users read -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
5
0 / 0

[Issue 9725] New: attribute olcLastBindPrecision redefined in slapo-lastbind

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9725 Issue ID: 9725 Summary: attribute olcLastBindPrecision redefined in slapo-lastbind Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- An attribute type description for 'olcLastBindPrecision' is present in servers/slapd/bconfig.c and contrib/slapd-modules/lastbind/lastbind.c. Thus the migration of deployments using slapo-lastbind is not as smooth as it should be. With release 2.6.0 one is forced to disable slapo-lastbind. Removing the attribute type description for 'olcLastBindPrecision' from contrib/slapd-modules/lastbind/lastbind.c should work. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
10
0 / 0

[Issue 9647] New: Glue entry creation doesn't replicate properly

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9647 Issue ID: 9647 Summary: Glue entry creation doesn't replicate properly Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- In plain syncrepl, when an entry is turned into glue (to remove it when it still has children), it won't replicate correctly to its consumers - a NEW_COOKIE intermediate message is sent instead. Scenario: - 4 servers (A, B, C, D) and a tree with two entries - cn=parent,cn=suffix and its parent, the database suffix - D replicates from C, C replicates from A and B, no other links set up for this Now: 1. add an entry "cn=child,cn=parent,cn=suffix" on A 2. remove "cn=parent,cn=suffix" from B As things settle, cn=parent,cn=suffix is retained on D while being deleted from C. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
12
0 / 0

[Issue 9728] New: For lastbind-precision, note it is important in busy replicated environments

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9728 Issue ID: 9728 Summary: For lastbind-precision, note it is important in busy replicated environments Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- It would be good to note in the slapd.conf(5)/slapd-config(5) man pages that the lastbind-precision setting can be very important to set in busy, replicated environments. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
5
0 / 0

[Issue 9727] New: slapd-watcher fails to start if any slapd instance is down

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9727 Issue ID: 9727 Summary: slapd-watcher fails to start if any slapd instance is down Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- When starting slapd-watcher and slapd isn't running on one of the monitored servers, slapd-watcher fails to start: Example w/host2 slapd not running: [user@host]# slapd-watcher -xD dc=example,dc=com -w secret -b dc=example,dc=com -s 1,2 ldap://host1/ ldap://host2/ slapd-watcher PID=11892: ldap_sasl_bind_s: Can't contact LDAP server (-1) I would expect that slapd-watcher would start up completely and indicate the host was down, like in the case where a host goes down while slapd-watcher is running. This would allow slapd-watcher to start when one or more replication node is down for maintenance. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
8
0 / 0

[Issue 9691] New: Allow syncrepl persist sessions against empty DBs

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9691 Issue ID: 9691 Summary: Allow syncrepl persist sessions against empty DBs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review, replication Severity: enhancement Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- One way to set up an environment is to start with a completely empty DB, configure all nodes and replication paths and then populate them. Right now, the syncrepl sessions get rejected with a 32 NO_SUCH_OBJECT, triggering the retry cascade. Both the consumer and provider have an empty cookie, so they are in sync and we could actually transition to a persist phase and let the session proceed. This way the environment would start replicating almost immediately after first entries are added. Mind that ITS#9584 still pushes concurrent refreshes into the retry logic adding a short delay before *all* configured links are set up. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
7
0 / 0

[Issue 9707] New: Documentation synchronisation ODSEE --> openldap

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9707 Issue ID: 9707 Summary: Documentation synchronisation ODSEE --> openldap Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: laurent.revillion(a)icloud.com Target Milestone: --- There is no documentation about the synchronisation between ODSEE and Openldap 2.5. Will there be one? -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
16
0 / 0

[Issue 9538] New: Accesslog entryCSN ordering is not always monotonous

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9538 Issue ID: 9538 Summary: Accesslog entryCSN ordering is not always monotonous Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- For delta-sync replication, we rely on CSN order being preserved at all times. When logops includes anything more than "writes", we don't use li_op_rmutex to maintain serialisation. A concurrent write and another operation (like bind) can have the write have its csn assigned before the bind. But before the write finishes on the main DB and is logged, the bind has already hit accesslog. This entry out of order doesn't match the usual filter, so non-persist sessions will not notice, however running persist sessions could get a new cookie sent, depending on how things are ordered when they hit syncprov. A sample: ---- 8< ---- Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 ADD dn="uid=dm01-R1H2-41660,ou=People,dc=example,dc=com" Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 syncprov_matchops: recording uuid for dn=reqStart=20210426195604.000350Z,cn=accesslog on opc=0x7d3d2800dc50 Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1003 op=42 generated new csn=20210426195604.556053Z#000000#002#000000 manage=1 Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148f60 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND dn="dc=example,dc=com" method=128 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=256 Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 RESULT tag=105 err=0 qtime=0.005874 etime=0.015182 text= Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1005 op=1 generated new csn=20210426195604.558683Z#000000#002#000000 manage=1 Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x561f09113f80 20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 syncprov_matchops: recording uuid for dn=reqStart=20210426195604.000364Z,cn=accesslog on opc=0x561f0900fcf0 Apr 26 19:56:04 localhost slapd[43930]: conn=1002 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1001 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1000 op=2 syncprov_qresp: set up a new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x561f09113f80 20210426195604.558683Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 RESULT tag=97 err=0 qtime=0.000020 etime=0.004297 text= Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148250 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x7d3d38148250 20210426195604.556053Z#000000#002#000000 Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing 0x7d3d38148f60 20210426195604.556053Z#000000#002#000000 ---- 8< ---- Example entries in the order slapcat sees them: ---- 8< ---- dn: reqStart=20210426195604.000364Z,cn=accesslog objectClass: auditBind reqStart: 20210426195604.000364Z reqEnd: 20210426195604.000365Z reqType: bind entryCSN: 20210426195604.558683Z#000000#002#000000 dn: reqStart=20210426195604.000351Z,cn=accesslog objectClass: auditAdd reqStart: 20210426195604.000351Z reqEnd: 20210426195604.000366Z reqType: add entryCSN: 20210426195604.556053Z#000000#002#000000 ---- 8< ---- -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
20
0 / 0

[Issue 9556] New: slapd-config should return invalidAttributeSyntax if parsing schema description fails

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9556 Issue ID: 9556 Summary: slapd-config should return invalidAttributeSyntax if parsing schema description fails Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I'm currently testing error handling and interacting with LDAP clients (e.g. my web2ldap). Sending an invalid attribute type description results in an error (as expected) returned by slapd-config: RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes: Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) But result code other(80) seems not very useful. It's too unspecific to decide on specific error handling. It would be much more useful if slapd-config returns invalidAttributeSyntax(21) in this case. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
6
0 / 0

[Issue 9576] New: Add ConfigTable link into ConfigArgs

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9576 Issue ID: 9576 Summary: Add ConfigTable link into ConfigArgs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Would make it possible to examine defaults if necessary. -- You are receiving this mail because: You are on the CC list for the issue.

1 year, 2 months

1
7
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2021