(ITS#6555) Syncprov (refreshAndPersist) loses deletes
by ralf＠OpenLDAP.org
Full_Name: Ralf Haferkamp
Version: HEAD/RE24
OS: SLES11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (92.252.42.18)
Submitted by: ralf
If entries are deleted on the provider during the refresh Phase of a
"refreshAndPersist" sync session, those deletes won't get replicated to the
provider.
This only happens if the consumer provided a cookie with the search, i.e. after
the consumer was restarted (not during the initial sync) and if there were
changes since the last sync.
I am working on a fix.
12 years, 10 months
(ITS#6554) OpenLDAP + TLS multiple server certificates
by stepan.kipel＠ab-group.biz
Full_Name: Stepan Kipel
Version: 2.4.19
OS: Red Hat Enterprise Linux AS release 4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (79.140.224.210)
In our network there are 2 servers running slapd, one is syncrepl-provider and
other is consumer. Both have identical IP address for LDAP requests and
configured in manner that when one goes down, second takes over (configured
externally, by routing). Also, TLS is configured and works transparently for
client machines (DNS resolves their "common" IP), but it`s hard to use their
Domain Name for TLS syncrepl - DNS resolves IP, that is up on local machine. We
decided to put up other interface on syncrepl-provider for replication purposes,
mapped another Domain Name on this interface and appended CA, server and private
server certs created for this Domain Names to files included by
TLSCACertificateFile, TLSCertificateFile and TLSCertificateKey in slapd.conf
file, respectively. We`ve tried to execute ldapsearch with two different
ldap.conf configs - for first and second domain name of the server, one works
and another - not? error looks like "TLS: hostname (first_srv_name) does not
match common name in certificate (second_srv_name)."
The question is - can slapd server use more than 2 server certificates or we
should use another technology (tunneling, etc...) for encrypted syncrepl?
12 years, 10 months
(ITS#6553) Test043 oddities under Windows
by mhardin＠symas.com
Full_Name: Matt Hardin
Version: 2.4.22
OS: Windows 7
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.38.117.141)
test043 fails under Windows because the contextCSN attribute for the entry
dc=example,dc=com are returned in different places within the entry for the
producer and consumer. To wit:
server1.flt-
dn: dc=example,dc=com
dc: example
objectClass: organization
objectClass: domainRelatedObject
objectClass: dcObject
l: Anytown, Michigan
st: Michigan
o: Example, Inc.
o: EX
o: Ex.
description: The Example, Inc. at Anytown
postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
telephoneNumber: +1 313 555 1817
associatedDomain: example.com
structuralObjectClass: organization
entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643
creatorsName: cn=Manager,dc=example,dc=com
createTimestamp: 20100518161938Z
entryCSN: 20100518161938.140191Z#000000#000#000000
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20100518161938Z
entryDN: dc=example,dc=com
subschemaSubentry: cn=Subschema
contextCSN: 20100518162026.443250Z#000000#000#000000
hasSubordinates: TRUE
server2.flt-
dn: dc=example,dc=com
dc: example
objectClass: organization
objectClass: domainRelatedObject
objectClass: dcObject
l: Anytown, Michigan
st: Michigan
o: Example, Inc.
o: EX
o: Ex.
description: The Example, Inc. at Anytown
postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US
telephoneNumber: +1 313 555 1817
associatedDomain: example.com
structuralObjectClass: organization
entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643
creatorsName: cn=Manager,dc=example,dc=com
createTimestamp: 20100518161938Z
entryCSN: 20100518161938.140191Z#000000#000#000000
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20100518161938Z
contextCSN: 20100518162026.443250Z#000000#000#000000
entryDN: dc=example,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
While this is not a problem in operation, and is not specifically a bug
according to the RFCs, test043 nonetheless fails because it expects an exact
match in the ordering between the producer and consumer. It's not clear whether
the desired fix is in slapd or in the test itself.
This test does not fail on any other platforms with which we are currently
working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to
ITS#6549, which is now fixed (thanks Ando!).
12 years, 10 months
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com
> Hi Ando. I've tested on RHEL 4/5 x86 and all seems good. I'll test on =
Windows in a little while.
Back-ported to 2.4.22 and tested in Windows. Works.
-Matt
>=20
> Thanks!
>=20
> -Matt
>=20
> On May 17, 2010, at 6:27 PM, masarati(a)aero.polimi.it wrote:
>=20
>>=20
>>> Indeed, syncprov_operational() is right: it duplicates the entry =
only if
>>> contextCSN is already present in the entry, and thus may need to be
>>> updated. What's wrong is back-bdb, which gives up when the entry =
does not
>>> have e_private set appropriately, while it could do more to find out =
about
>>> the entry's subordinates. This may explain why in some cases the
>>> attribute is present. This occurs whenever contextCSN is not =
already
>>> present in the entry. I'm preparing a fix for back-bdb.
>>=20
>> Fixed in HEAD; please test. Thanks, p.
>>=20
>=20
12 years, 10 months
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com
Hi Ando. I've tested on RHEL 4/5 x86 and all seems good. I'll test on =
Windows in a little while.
Thanks!
-Matt
On May 17, 2010, at 6:27 PM, masarati(a)aero.polimi.it wrote:
>=20
>> Indeed, syncprov_operational() is right: it duplicates the entry only =
if
>> contextCSN is already present in the entry, and thus may need to be
>> updated. What's wrong is back-bdb, which gives up when the entry =
does not
>> have e_private set appropriately, while it could do more to find out =
about
>> the entry's subordinates. This may explain why in some cases the
>> attribute is present. This occurs whenever contextCSN is not already
>> present in the entry. I'm preparing a fix for back-bdb.
>=20
> Fixed in HEAD; please test. Thanks, p.
>=20
12 years, 10 months
Re: (ITS#6544) how to implement password policy
by masarati＠aero.polimi.it
The ITS is intended to track bugs; please direct usage questions to
openldap-software(a)openldap.org. This ITS will be closed.
p.
> Full_Name: Devender Singh
> Version: openldap 2.4.16
> OS: RHEL5.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (122.177.190.226)
>
>
> Hello Dear,
>
> Please let me know, how to implement ppolicy in
> openldap2.4.16. I
> am using RHEL5.4
>
> I have followed below steps on installation time:
>
> **************************************************
> Installing BerkeleyDB
> **************************************************
> 1) Create build_unix directory in /opt directory
> 2) Copy db-4.7.25.tar.gz to /opt/build_unix directory
> 3) Goto /opt/build_unix directory
> 4) gzip -d db-4.7.25.tar.gz
> 5) tar xvf db-4.7.25.tar
> 6) db-4.7.25/dist/configure
> 7) make
> 8) make install
> 9) vi /root/.bash_profile
> 10) Add below lines in .bash_profile of root user
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib
> export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib
> 11) Close existing PUTTY and start new PUTTY
> **************************************************
>
> Before Installation check the below packages:
> #rpm �qa|grep openssl*
> After the above command if you don�t find the all openssl
packages than
> install
> them via yum command
> **************************************************
> Installing OpenLDAP
> **************************************************
> 1) Copy openldap-stable-20090411.tgz to /opt directory
> 2) gunzip -c openldap-stable-20090411.tgz | tar xf -
> 3) cd openldap-2.4.16
> 4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include
> -I/usr/local/ssl/include/openssl"
> 5) export CPPFLAGS
> 6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib
> -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib
> -R/usr/local/ssl/lib"
> 7) export LDFLAGS
> 8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib"
> 9) export LD_LIBRARY_PATH
> 10) ./configure
> 11) make depend
> 12) make
> 13) make install
> 14) vi /root/.bash_profile
> 15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export
> PATH=$PATH:$HOME/bin:/usr/local/sbin)
> 16) Close existing PUTTY and start new PUTTY
> **************************************************
>
>
> Thanks in Advance.
>
> Regards,
> Devender Singh
> (+919818107222)
>
>
12 years, 10 months
Re: (ITS#6546) Default olcRootDN of "cn=config" should be documented
by masarati＠aero.polimi.it
> While using the "cn=config" configuration, I found that "cn=config" is
> also the
> default olcRootDN. By just configuring a olcRootPW , login to the config
> database is possible using "cn=config" and the configured olcRootPW. This
> default should be documented in the admin guide, etc.
Fixed in HEAD's slapd-config(5); may be worth mentioning in the admin
guide as well.
Thanks, p.
12 years, 10 months
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it
> Indeed, syncprov_operational() is right: it duplicates the entry only if
> contextCSN is already present in the entry, and thus may need to be
> updated. What's wrong is back-bdb, which gives up when the entry does not
> have e_private set appropriately, while it could do more to find out about
> the entry's subordinates. This may explain why in some cases the
> attribute is present. This occurs whenever contextCSN is not already
> present in the entry. I'm preparing a fix for back-bdb.
Fixed in HEAD; please test. Thanks, p.
12 years, 10 months
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it
> masarati(a)aero.polimi.it wrote:
>> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS
>> 5.2,
>> for what it matters, and db-4.6.21, for what it matters), and it works
>> fine if you explicitly ask for hasSubordinates, while this specific attr
>> is not returned if you request '+'. The fact hasSubordinates does not
>> appear means that the appropriate backend operational attrs hook was not
>> called, or its value was ignored.
>
> Since hasSubordinates is a generated attribute, it would be filtered out
> on
> the consumer anyway. There's no reason to ever include it in replication
> traffic.
Indeed, syncprov_operational() is right: it duplicates the entry only if
contextCSN is already present in the entry, and thus may need to be
updated. What's wrong is back-bdb, which gives up when the entry does not
have e_private set appropriately, while it could do more to find out about
the entry's subordinates. This may explain why in some cases the
attribute is present. This occurs whenever contextCSN is not already
present in the entry. I'm preparing a fix for back-bdb.
p.
>> After a quick check, I figured out that bdb_hasSubordinates is passed a
>> copy of the original entry, thus without bdb information, and
>> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry
>> instead of putting operational attrs in rs_operational_attrs in
>> SlapReply.
>>
>> p.
>>
>>> Full_Name: Matt Hardin
>>> Version: 2.4.22
>>> OS: Red Hat AS 4
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (74.38.117.141)
>>>
>>>
>>> In test043 the test database defines a root entry of dc=example,dc=com.
>>> For this
>>> entry, the results of the ldapsearch do not include the hasSubordinates
>>> attribute at all, in spite of the fact that the entry does have
>>> subordinates.
>>> Test043 passes, due to the fact that this attribute is missing from the
>>> root
>>> entry in both the provider and the consumer.
>>>
>>> Other entries with subordinates do include this attribute and its value
>>> is
>>> correct in all the cases I examined.
>>>
>>> Here is the snippet from tests/testrun/server1.flt:
>>>
>>> dn: dc=example,dc=com
>>> dc: example
>>> objectClass: organization
>>> objectClass: domainRelatedObject
>>> objectClass: dcObject
>>> l: Anytown, Michigan
>>> st: Michigan
>>> o: Example, Inc.
>>> o: EX
>>> o: Ex.
>>> description: The Example, Inc. at Anytown
>>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $
>>> US
>>> telephoneNumber: +1 313 555 1817
>>> associatedDomain: example.com
>>> structuralObjectClass: organization
>>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2
>>> creatorsName: cn=Manager,dc=example,dc=com
>>> createTimestamp: 20100512194705Z
>>> entryCSN: 20100512194705.076849Z#000000#000#000000
>>> modifiersName: cn=Manager,dc=example,dc=com
>>> modifyTimestamp: 20100512194705Z
>>> contextCSN: 20100512194748.621773Z#000000#000#000000
>>> entryDN: dc=example,dc=com
>>> subschemaSubentry: cn=Subschema
>>>
>>> The version of BDB in use here is 4.8.30, although I note this happens
>>> with
>>> earlier releases of BDB as well.
>>>
>>> Also of interest is the fact that this test fails on some platforms
>>> (e.g.
>>> Windows), because the provider slapd correctly reports
>>> hasSubordinates=TRUE,
>>> while the consumer omits the attribute entirely, in spite of the fact
>>> that
>>> subordinate entries do exist on the consumer.
>>>
>>> -Matt
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
>
12 years, 10 months
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it
> masarati(a)aero.polimi.it wrote:
>> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS
>> 5.2,
>> for what it matters, and db-4.6.21, for what it matters), and it works
>> fine if you explicitly ask for hasSubordinates, while this specific attr
>> is not returned if you request '+'. The fact hasSubordinates does not
>> appear means that the appropriate backend operational attrs hook was not
>> called, or its value was ignored.
>
> Since hasSubordinates is a generated attribute, it would be filtered out
> on
> the consumer anyway. There's no reason to ever include it in replication
> traffic.
I'd concur, but syncprov_operational steps in even for regular operations
(correctly, because a client might want to see the contextCSN), and
duplicates the entry unnecessarily, as contextCSN could be appended to
sr_operational_attrs, unless it needs to be in the entry for some reason.
p.
>> After a quick check, I figured out that bdb_hasSubordinates is passed a
>> copy of the original entry, thus without bdb information, and
>> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry
>> instead of putting operational attrs in rs_operational_attrs in
>> SlapReply.
>>
>> p.
>>
>>> Full_Name: Matt Hardin
>>> Version: 2.4.22
>>> OS: Red Hat AS 4
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (74.38.117.141)
>>>
>>>
>>> In test043 the test database defines a root entry of dc=example,dc=com.
>>> For this
>>> entry, the results of the ldapsearch do not include the hasSubordinates
>>> attribute at all, in spite of the fact that the entry does have
>>> subordinates.
>>> Test043 passes, due to the fact that this attribute is missing from the
>>> root
>>> entry in both the provider and the consumer.
>>>
>>> Other entries with subordinates do include this attribute and its value
>>> is
>>> correct in all the cases I examined.
>>>
>>> Here is the snippet from tests/testrun/server1.flt:
>>>
>>> dn: dc=example,dc=com
>>> dc: example
>>> objectClass: organization
>>> objectClass: domainRelatedObject
>>> objectClass: dcObject
>>> l: Anytown, Michigan
>>> st: Michigan
>>> o: Example, Inc.
>>> o: EX
>>> o: Ex.
>>> description: The Example, Inc. at Anytown
>>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $
>>> US
>>> telephoneNumber: +1 313 555 1817
>>> associatedDomain: example.com
>>> structuralObjectClass: organization
>>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2
>>> creatorsName: cn=Manager,dc=example,dc=com
>>> createTimestamp: 20100512194705Z
>>> entryCSN: 20100512194705.076849Z#000000#000#000000
>>> modifiersName: cn=Manager,dc=example,dc=com
>>> modifyTimestamp: 20100512194705Z
>>> contextCSN: 20100512194748.621773Z#000000#000#000000
>>> entryDN: dc=example,dc=com
>>> subschemaSubentry: cn=Subschema
>>>
>>> The version of BDB in use here is 4.8.30, although I note this happens
>>> with
>>> earlier releases of BDB as well.
>>>
>>> Also of interest is the fact that this test fails on some platforms
>>> (e.g.
>>> Windows), because the provider slapd correctly reports
>>> hasSubordinates=TRUE,
>>> while the consumer omits the attribute entirely, in spite of the fact
>>> that
>>> subordinate entries do exist on the consumer.
>>>
>>> -Matt
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
12 years, 10 months
