Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.72.141.24)
Submitted by: ando
I need to implement a modify operation whose semantics is "add if not
present", an add that only takes place if that attribute is not yet
present in the entry.
I need it as an internal operation, so right now I wouldn't bother
formalizing it as an extension of the semantics of the modify operation.
Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an
attribute value only if that value is not already present.
See <http://www.openldap.org/lists/openldap-devel/201005/msg00000.html> for
discussion.
I have introduced a SLAP_MOD_ADD_IF_NOT_PRESENT flag and added code to support
it in back-bdb/hdb. It works as intended. I plan to extend its support to all
backends and overlays.
p.
--On Friday, April 30, 2010 1:23 PM +0000 h.b.furuseth(a)usit.uio.no wrote:
> quanah(a)zimbra.com writes:
>> Actually, the issue seems to be name changes in the header files under
>> BSD. This causes TIOCNOTTY to end up being undefined.
>
> That would not give the error message shown in
> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021.
> html>:
>
> build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libr
> aries/liblutil/detach.c:131:7: error: missing binary operator before
> token "long"
>
> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is
> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY
> somewhere is defined to expand to an expression involving a (long) cast.
Apprently so.
<http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259.html>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
> On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote:
>
>> Isn't ldif-filter supposed to deal with this? Probably, test043 needs
>> to
>> sort entries (-s bdb=a,hdb=a).
>
> Yes, Thanks.
>
> Here is a patch:
Works for me, but I can't check using windows. I'd commit it, pending
verification.
Thanks, p.
> Index: test043-delta-syncrepl
> ===================================================================
> RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v
> retrieving revision 1.1.1.5
> diff -r1.1.1.5 test043-delta-syncrepl
> 342c342
> < $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT
> ---
>> $LDIFFILTER -s bdb=a,hdb=a < $MASTEROUT | grep -iv "^auditcontext:" >
>> $MASTERF
> LT
> 344c344
> < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT
> ---
>> $LDIFFILTER -s bdb=a,hdb=a < $SLAVEOUT | grep -iv "^auditcontext:" >
>> $SLAVEFLT
>
>
>>
>> p.
>>
>>> 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!).
>>>
>>>
>>>
>>>
>>
>>
>
>
>
On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote:
> Isn't ldif-filter supposed to deal with this? Probably, test043 needs =
to
> sort entries (-s bdb=3Da,hdb=3Da).
Yes, Thanks.
Here is a patch:
Index: test043-delta-syncrepl
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v
retrieving revision 1.1.1.5
diff -r1.1.1.5 test043-delta-syncrepl
342c342
< $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT
---
> $LDIFFILTER -s bdb=3Da,hdb=3Da < $MASTEROUT | grep -iv =
"^auditcontext:" > $MASTERF
LT
344c344
< $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT
---
> $LDIFFILTER -s bdb=3Da,hdb=3Da < $SLAVEOUT | grep -iv "^auditcontext:" =
> $SLAVEFLT
>=20
> p.
>=20
>> Full_Name: Matt Hardin
>> Version: 2.4.22
>> OS: Windows 7
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (74.38.117.141)
>>=20
>>=20
>> test043 fails under Windows because the contextCSN attribute for the =
entry
>> dc=3Dexample,dc=3Dcom are returned in different places within the =
entry for
>> the
>> producer and consumer. To wit:
>>=20
>> server1.flt-
>>=20
>> dn: dc=3Dexample,dc=3Dcom
>> 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=3DManager,dc=3Dexample,dc=3Dcom
>> createTimestamp: 20100518161938Z
>> entryCSN: 20100518161938.140191Z#000000#000#000000
>> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom
>> modifyTimestamp: 20100518161938Z
>> entryDN: dc=3Dexample,dc=3Dcom
>> subschemaSubentry: cn=3DSubschema
>> contextCSN: 20100518162026.443250Z#000000#000#000000
>> hasSubordinates: TRUE
>>=20
>>=20
>>=20
>> server2.flt-
>>=20
>> dn: dc=3Dexample,dc=3Dcom
>> 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=3DManager,dc=3Dexample,dc=3Dcom
>> createTimestamp: 20100518161938Z
>> entryCSN: 20100518161938.140191Z#000000#000#000000
>> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom
>> modifyTimestamp: 20100518161938Z
>> contextCSN: 20100518162026.443250Z#000000#000#000000
>> entryDN: dc=3Dexample,dc=3Dcom
>> subschemaSubentry: cn=3DSubschema
>> hasSubordinates: TRUE
>>=20
>>=20
>> 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.
>>=20
>> 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!).
>>=20
>>=20
>>=20
>>=20
>=20
>=20
> Full_Name: Nitin Bhadauria
> Version: OpenLDAP 2.X-Devel
> OS: Ubuntu 10.04
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (119.82.72.226)
>
>
> I am try to configure Samba4 with OpenLDAP and while setup provision...
>
> Using Following doc:
>
> http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP
>
> I got this error in messages logs.
>
> May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at
> 7ffffffb
> ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000]
> May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0
Please read this <http://www.openldap.org/faq/data/cache/56.html> and act
accordingly.
p.
--On Monday, May 24, 2010 3:39 AM +0000 jet(a)hf.webex.com wrote:
> Full_Name: Jet Du
> Version: openldap-2.4.21
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (61.191.27.34)
>
>
> Because there are some typo in some description of (ITS#6558). So, I
> submit a new ITS as below.
>
> There are two openLDAP Directory.
>
> 10.224.39.165 openLDAP has suffix dc=cisco,dc=com
> 10.224.39.172 openLDAP has suffix dc=webex,dc=com
>
> In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below:
> referral ldap://10.224.39.165:389/
>
> Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like
> following:
> lc.connect("10.224.39.172", 389);
> lc.bind(LDAPConnection.LDAP_V3,
> "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com",
> "pass".getBytes("UTF8"));
>
> But, I can not BIND successfully. Exception like below:
> Connect ERRORLDAPException: Invalid Credentials (49) Invalid
> Credentials LDAPException: Matched DN: ......
>
> How to do BIND based on Referral? Thanks ...
Two things:
(a) Don't submit a new ITS because you typoed on the previous one. Just
follow up to it.
(b) Don't submit ITSes for software usage questions. Use the
openldap-technical(a)openldap.org software list.
The ITS system is for reporting bugs found in the software.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: Nitin Bhadauria
Version: OpenLDAP 2.X-Devel
OS: Ubuntu 10.04
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (119.82.72.226)
I am try to configure Samba4 with OpenLDAP and while setup provision...
Using Following doc:
http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP
I got this error in messages logs.
May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at 7ffffffb
ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000]
May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0
Full_Name: Jet Du
Version: openldap-2.4.21
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (61.191.27.34)
Because ther are some typo in some description of (ITS#6558). So, I submit a new
ITS as below.
There are two openLDAP Directory.
10.224.39.165 openLDAP has suffix dc=cisco,dc=com
10.224.39.172 openLDAP has suffix dc=webex,dc=com
In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below:
referral ldap://10.224.39.165:389/
Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like
following:
lc.connect("10.224.39.172", 389);
lc.bind(LDAPConnection.LDAP_V3,
"uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8"));
But, I can not BIND successfully. Exception like below:
Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials
LDAPException: Matched DN: ......
How to do BIND based on Referral? Thanks ...