(ITS#6679) syncrepl does not handle modifyTimestamp
by pcernko+openldap＠mpi-sws.org
Full_Name: Patrick Cernko
Version: 2.4.23
OS: Debian Lenny
URL: http://www.mpi-inf.mpg.de/~pcernko/syncrepl_does_not_transfer_or_update_m...
Submission from: (NULL) (139.19.3.67)
Hi OpenLDAP-Programmers,
we discovered a possible bug in the syncrepl code. When objects get modified on
the master server, all changed get propagated to the slaves. However, the for
hidden attributes creatorsName, createTimestamp, modifiersName, modifyTimestamp
seem to be not handled in a reasonable way:
Obviously, the creat* attributes should only be written once (on creation). The
modif* attributes are set to the same values as their creat* counterparts on
creating. After replication, all these values can be found on the slave as
well.
When an object is modified now (for the first time!), the master correctly
updated the modif* attributes. The slave replicates the modification correctly
but neither does update the modif* attributes nor replicates their contents from
the server. Especially the modifyTimestamp attribute does still contain the old
value (equal to createTimestamp). This is wrong as the object WAS modified
later.
More interesting, if you do another modification, the master will handle it the
same way as before, but now, the slave will completely REMOVE the four hidden
attributes, as you can verify in the slapcat of the slave's database.
To demonstrate and reproduce this behaviour, I have combined a set of files in
the linked tarball:
Extract to an empty folder, unpack openldap-2.4.23 into it and
configure-make-make-install it (a suggested configuration can be found in the
boundled configure.sh). The you can start the master and server with the
corresponding sh-Scripts.
You can use the following commands to search or slapcat the servers:
install/bin/ldapsearch -H ldapi://%2ftmp%2fmaster/ -b ou=openldap -LLL
modifyTimestamp
install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL
modifyTimestamp
install/sbin/slapcat -f master.conf
install/sbin/slapcat -f slave.conf
The mod.py script can be used to trigger a change:
python mod.py mod-child
Now check the modifyTimestamp on the slave, it is still the old one:
install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL
modifyTimestamp
install/sbin/slapcat -f slave.conf
After the second modification, the attributes are gone on the slave:
python mod.py unmod-child
install/bin/ldapsearch -H ldapi://%2ftmp%2fslave/ -b ou=openldap -LLL
modifyTimestamp
install/sbin/slapcat -f slave.conf
I would really appreciate a reasonable behaviour for this in the next releases.
If you have reasons not to REPLICATE but UPDATE the modif* attributes (with the
replication timestamp instead of the master's one), that's ok, too.
Thanks.
12 years, 11 months
(ITS#6678) slapd.exe does not respond anymore
by Frank.Offermanns＠caseris.de
Full_Name: Frank Offermanns
Version: 2.4.23
OS: Windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (217.6.189.243)
We are using OpenLDAP 2.4.23 on windows.
We are doing a lot of LDAP work every morning at 5 AM. About every 3rd day the
slapd.exe hang's up while doing this work.
The LDAP client then also hangs. The search never comes back.
It is no longer possible to bind to the server. Slapd.exe can't be stopped
regulary (must be terminated).
After restart of slapd.exe everything works fine.
It does not matter if we specify a (search/open) timeout at client side - it
always hangs. The log attached is without timeout.
It also does not matter if replication is configured or not (currently
replication is activated).
I have uploaded a part of the slapd.log (with loglevel 264) and my configuration
file as Frank-Offermanns-101020.log and Frank-Offermanns-101020.conf.
To better analyse the log at 5 AM I added timestamps to the logging.
At the attached log you can watch the way of "conn=3005" which results in a
search, which never comes back.
Would it make sense to adjust the loglevel. If so what loglevel would be
helpfull?
12 years, 11 months
(ITS#6677) unregister_supported_control not under ifdef control
by doug.leavitt＠oracle.com
Full_Name: Douglas Leavitt
Version: HEAD
OS: OpenSolaris
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.18.43.225)
The definition of unregister_supported_control is ifdef'd SLAP_CONFIG_DELETE
but one reference in sssvlv.c is not. Compiling HEAD in a non Devel
configuration
will cause link failures.
Suggested fix:
--- openldap/servers/slapd/overlays/sssvlv.c.bad Wed Oct 13 12:08:18 2010
+++ openldap/servers/slapd/overlays/sssvlv.c Thu Oct 14 23:32:31 2010
@@ -1183,12 +1183,12 @@
if ( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_ANY, "Failed to register VLV Request control '%s'
(%d)\n",
LDAP_CONTROL_VLVREQUEST, rc, 0 );
#ifdef SLAP_CONFIG_DELETE
overlay_unregister_control( be, LDAP_CONTROL_SORTREQUEST );
-#endif /* SLAP_CONFIG_DELETE */
unregister_supported_control( LDAP_CONTROL_SORTREQUEST );
+#endif /* SLAP_CONFIG_DELETE */
return rc;
}
}
si = (sssvlv_info *)ch_malloc(sizeof(sssvlv_info));
12 years, 11 months
Re: (ITS#6676) Some slap-commands remove nssov overlay socket
by hyc＠symas.com
sergei(a)bslos.com wrote:
> Full_Name: Sergei Butakov
> Version: 2.4.23
> OS: Linux
> URL:
> Submission from: (NULL) (94.190.117.137)
>
>
> I'm using nssov overlay (and nss-pam-ldapd-0.7.10).
>
>
> Some slap-commands remove nssov overlay socket "/var/run/nslcd/socket" (it shows
> "strace slapcat").
>
> For example, next commands remove socket:
> slapcat -n 2, slapschema -n 2, slapacl<anything>
>
> But these ones do not remove:
> slapcat -n 1, slapschema -n 1, slapdn<anything>
Thanks for the report, fixed in CVS HEAD.
>
>
> To avoid this, I commented out in contrib/slapd-modules/nssov/nssov.c file
> from 890 to 894 lines (in nssov_db_close() function). Now the socket exists
> even if slapd is stopped. But it seems that it does not interfere with
> anything.
>
>
> I have in slapd.conf two database:
> ...
> ...
> database monitor
> rootdn "cn=Manager"
> ...
> database hdb
> suffix ""
> rootdn "cn=Manager"
>
> overlay nssov
> nssov-map aliases rfc822MailMember x-bsl-mailMember
> nssov-map group uniqueMember member
> nssov-ssd passwd
> ldap:///??sub?(&(objectClass=posixAccount)(objectClass=sambaSamAccount))
>
> overlay smbk5pwd
> overlay memberof
> ...
> overlay refint
> ...
> ...
>
>
>
--
-- 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, 11 months
(ITS#6676) Some slap-commands remove nssov overlay socket
by sergei＠bslos.com
Full_Name: Sergei Butakov
Version: 2.4.23
OS: Linux
URL:
Submission from: (NULL) (94.190.117.137)
I'm using nssov overlay (and nss-pam-ldapd-0.7.10).
Some slap-commands remove nssov overlay socket "/var/run/nslcd/socket" (it shows
"strace slapcat").
For example, next commands remove socket:
slapcat -n 2, slapschema -n 2, slapacl <anything>
But these ones do not remove:
slapcat -n 1, slapschema -n 1, slapdn <anything>
To avoid this, I commented out in contrib/slapd-modules/nssov/nssov.c file
from 890 to 894 lines (in nssov_db_close() function). Now the socket exists
even if slapd is stopped. But it seems that it does not interfere with
anything.
I have in slapd.conf two database:
...
...
database monitor
rootdn "cn=Manager"
...
database hdb
suffix ""
rootdn "cn=Manager"
overlay nssov
nssov-map aliases rfc822MailMember x-bsl-mailMember
nssov-map group uniqueMember member
nssov-ssd passwd
ldap:///??sub?(&(objectClass=posixAccount)(objectClass=sambaSamAccount))
overlay smbk5pwd
overlay memberof
...
overlay refint
...
...
12 years, 11 months
Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org
--=-ex4J6k12RcsGQxVIbjnQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thu, 2010-10-14 at 14:42 -0700, Howard Chu wrote:
> What is the GnuTLS version number? Seems like you should be submitting
> this to their tracker anyway, as the original reporter.
I'm using GnuTLS 2.8.6. I've just also tried with GnuTLS 2.10.2 which
shows the same behaviour.
I've reported it to
https://savannah.gnu.org/support/index.php?107495
feel free to add any more pointers that may be useful.
Anyway, thanks for your help.
--=20
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org --
--=-ex4J6k12RcsGQxVIbjnQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJMuAfmAAoJECqLdGgQ4K/Bws4P/3AP3NwmRZeO8feXY/F9wFwI
NTr7zxjHjbdVOoOjS81YPIDGXrefDx5kV5ufpVhDI7ojZSyhJc7rKRu7mpEiWzZH
pYIm9h+pFvRBSp4uGYGmlWQlkZHYNZFCYTNJo2+srl/evqyd4vKlvuMMn5QHlb8g
DCJEf+3Zo2+kd42V0WdVcpOuTcTjvGzGEd5SLRHjHvcjSX/YTW4JijgiBILqN745
ei8jyE1qpm/N6W2Zevb+XRhnQ6g5X95UmFNeWie8PNWGgpMu0IhRh79cPX25wOIK
4fSVDTW6rNnKR4E9rtJkhl/VwYNSQgwd9g0kyhinCn3sswa1UGxs6abBcF8sILIe
tEGiUJ7ZtJU4bA9uiILgGu94AV/zwkfqGC9y2q14jJ3N/28IcJIScWGqeYHaKZ1U
uB+2Y33fmEbXaAUBjPng4dNmnmrtNU1/MAyf24SC+wx8HKrOliQl1Y9z5GeN/rgM
bmSgFkdIJmHGvgmfW1+qUjynII67IIW5a42Amg/+o8LzKDJLZjs+WiJeZ7q7Pjd9
K6SgKiXTwu1mFgSt1kKz0rGUIYe4dZhkmmsKe8q7vCy8ME8MzibeQGwGK9cJLRqv
GC1RIXKGVqBhjgwhJVwB+8EFZImWg/pfREofkyuphRwfT2i+omrYuHdpESoSJiCD
i+QftiX5vMjKx+b965Jd
=apB7
-----END PGP SIGNATURE-----
--=-ex4J6k12RcsGQxVIbjnQ--
12 years, 11 months
Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com
Arthur de Jong wrote:
> On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote:
>> It seems you can workaround this by changing tls_g.c's invocation of
>> gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, that
>> strikes me as fundamentally wrong, since libldap is clearly closing both
>> directions when it gets here. I think the bug is in gnutls_bye(), it shouldn't
>> be waiting indefinitely when it tries to read the peer's Close alert. I'm not
>> sure it should even be trying to read that at all; some peers may never send it.
>
> I can't comment on the GnuTLS API because I haven't used it before. Can
> you file a bugreport with GnuTLS? Do you need any more input from my
> end?
What is the GnuTLS version number? Seems like you should be submitting this to
their tracker anyway, as the original reporter.
https://savannah.gnu.org/support/?group=gnutls
>> Note that because you're breaking the connection without warning, TCP doesn't
>> know that the connection is gone, so there will be no error detected when
>> gnutls attempts to send its own Close alert. In this case, it will probably
>> block for 2*MSL before getting any further.
>
> In my tests I haven't waited that long (I think). Do you know if there
> are any problems with using setsockopt(SO_RCVTIMEO) and
> setsockopt(SO_SNDTIMEO) on the socket?
>
I have no idea whether GnuTLS handles asynch I/O properly or not. If you're
only setting these options immediately before closing, I don't see why it
should cause any problems. But GnuTLS has enough flaws in general that I
wouldn't claim it ever does anything right or as expected.
--
-- 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, 11 months
Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com
Version 2...
Part 3 of 3 of this patch with the request changes to options.c
is now available for review. The full details are located here:
http://cr.opensolaris.org/~djl/openldap-patch3/
The revised patch has been updated to include all changes as on
10-14-10AM
including the commit of:
Modified Files:
cyrus.c 1.159 -> 1.160
The only file modified between the first and second version of this patch
was options.c
The web link above includes both the original patch (as version 1) and
the revised patch (version 2) with full diff -Us, tarballs and such
for both versions.
Retesting has been completed on both Solaris x86 and Solaris SPARC.
Both platforms have been re-tested under 32-bit and 64-bit compiles.
All regression testing passed successfully.
IPR Notice
This patch file is derived from OpenLDAP Software. All of the
modifications to
OpenLDAP Software represented in the following patch(es) were developed by
Oracle Corporation. Oracle Corporation has not assigned rights and/or
interest
in this work to any party. I, Douglas Leavitt am authorized by Oracle
Corporation,
my employer, to release this work under the following terms.
Thank you for your consideration,
Doug.
12 years, 11 months
Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org
--=-6hDPPEPvd2QOD+/Er+Q8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Wed, 2010-10-13 at 14:17 -0700, Howard Chu wrote:
> It seems you can workaround this by changing tls_g.c's invocation of=20
> gnutls_bye() to use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR. However, =
that=20
> strikes me as fundamentally wrong, since libldap is clearly closing both=
=20
> directions when it gets here. I think the bug is in gnutls_bye(), it shou=
ldn't=20
> be waiting indefinitely when it tries to read the peer's Close alert. I'm=
not=20
> sure it should even be trying to read that at all; some peers may never s=
end it.
I can't comment on the GnuTLS API because I haven't used it before. Can
you file a bugreport with GnuTLS? Do you need any more input from my
end?
> Note that because you're breaking the connection without warning, TCP doe=
sn't=20
> know that the connection is gone, so there will be no error detected when=
=20
> gnutls attempts to send its own Close alert. In this case, it will probab=
ly=20
> block for 2*MSL before getting any further.
In my tests I haven't waited that long (I think). Do you know if there
are any problems with using setsockopt(SO_RCVTIMEO) and
setsockopt(SO_SNDTIMEO) on the socket?
--=20
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org --
--=-6hDPPEPvd2QOD+/Er+Q8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJMt01mAAoJECqLdGgQ4K/B5ogP/ihMljH3hvC7aKd6W4Mt526F
J/W6Gpx8w7UUI2uymq23epRa1s/2aLWnPDpdP9uGbswrdBrOsRrUARWHPRy/I61L
8JhCiFcEXqyMJxrm7sW4uaVTHBS1AZPklCdfQ0+s4JdVKccLjOkUGJFh4sQL5TtA
3syopgjuQ2inqc9+wA3ZuGL3HgiOuLjXQauHQ0YbWdr+QYZjDZcero5RU6HU+jIv
uh+SyQaTiTkzDc8MqGc/ImPZ5R55YORiKUF90Wr+3lGPGCloj8snqfUbMpjNTBkG
jUPKBrl+bKgmKPtnpJzLzeCAZsH/rMdyhL0Apr1AZb5Ay8uHqxE3bHE/bTL7/mxA
J/RvZlIR/BGed1dWWlQ+j2YE8zsCfvUNxH1GbbmWqk6pO+4BbZP/7XHs6rMW7XkL
bT+LwW6J70ZrUFR7XEjkn/a++S7dm9zRoIVDvVgw7HduQSVU+nVQRIwh/CxyGhoG
J8OefK5OEYuAqZjFJk8U1OpslstpGDvMjr7nbnY2TRkAg1QshydvhFaq+cp56Uey
RT97jWFYTYuIUTrWh8SOog/NxE0WaBJuUqx/Lz/mBX7BkJj+zSDT9SD6IntV73eJ
GBBr5wgyEzYyu7pg9uo3Ux16XFp+wwtjMHd8H9/EEEsBjOkuPyGVCz/9CynUgegr
A/rMhnTnXTAt7zM/ydh2
=uUuU
-----END PGP SIGNATURE-----
--=-6hDPPEPvd2QOD+/Er+Q8--
12 years, 11 months