openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (195.145.144.134) slapd (serving as provider) crashes from time to time (several times today!) when a consumer has some problems. I suspect this is related to ITS#6922 and therefore I suspect that Howard's answer is again just "there is no issue". The last lines in the logs always show that the consumer already sent an UNBIND and after that slapd dies with this failed assertion. conn=1090 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 conn=1090 op=2 UNBIND conn=1090 fd=112 closed connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. /infraldap/sbin/start-slapd.sh: line 16: 28888 Aborted ${OPENLDAP_PREFIX}/libexec/slapd -h "ldap://0.0.0.0:389 ldaps://0.0.0.0:636 ldapi://%2ftmp%2finfraldap-socket????x-mod=0770" -d config,stats,stats2,sync -n slapd-e2-infra-ldap -u openldap -g openldap -f ${SLAPD_CONF}

1 0

Re: (ITS#6926) Delta-Sync produce undefined situation after split-brain
by Howard Chu 04 May '11

04 May '11

Delta-Syncrepl is only single-master. Closing this ITS.

1 0

Re: (ITS#6927) smbk5pwd handles DST incorrectly
by hyc＠symas.com 04 May '11

04 May '11

ryans(a)aweber.com wrote: > Full_Name: Ryan Steele > Version: 2.4.23 > OS: Ubuntu Server 10.04 (Lucid) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle > Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet > attribute, populating it with a value that does not take DST into account. As > an example, consider the following attributes from one of the entries in my > directory: > > pwdChangedTime: 20110502160329Z > sambaPwdLastSet: 1304352209 > > Obviously, pwdChangedTime specifies the timestamp: > > Mon May 2 16:03:29 EDT 2011 > > On the other hand, sambaPwdLastSet specifies the timestamp as being an hour > later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 > sec'): > > Mon May 2 17:03:29 EDT 2011 > > Right now we're in DST on the east coast, which is GMT -0400. This would mean > that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly > calculating results using GMT -0500. The sambaPwdLastSet value is not calculated at all, it is exactly what the OS system clock returns, and the OS system clock is in UTC so DST is irrelevant. Probably your machine's timezone is misconfigured; notice that pwdChangedTime is also in UTC so 20110502160329Z cannot be "May 2 16:03:29 EDT". Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6927) smbk5pwd handles DST incorrectly
by ryans＠aweber.com 04 May '11

04 May '11

Full_Name: Ryan Steele Version: 2.4.23 OS: Ubuntu Server 10.04 (Lucid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet attribute, populating it with a value that does not take DST into account. As an example, consider the following attributes from one of the entries in my directory: pwdChangedTime: 20110502160329Z sambaPwdLastSet: 1304352209 Obviously, pwdChangedTime specifies the timestamp: Mon May 2 16:03:29 EDT 2011 On the other hand, sambaPwdLastSet specifies the timestamp as being an hour later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 sec'): Mon May 2 17:03:29 EDT 2011 Right now we're in DST on the east coast, which is GMT -0400. This would mean that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly calculating results using GMT -0500.

1 0

(ITS#6926) Delta-Sync produce undefined situation after split-brain
by sascha.kuehndel＠deka.de 04 May '11

04 May '11

Full_Name: Sascha Kuehndel Version: 2.4.25 OS: HP-UX 11.31 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.166.104.102) Hi, i tested the delta-sync in a multi-master (2 master) architecture. In a split-brain szenario the sync produced an undefinded state. Some times the data wasn't synchronized (both master hold there data unchanged), sometimes the data was fliped (master1 take data from master2, and master2 from master1). A defined and synchronized state must reached after the end of the split-brain. Senario: 1. master1 and master2 runs in sync 2. shutdown of master2 3. data change on master1 4. shutdown of master1 5. start of master2 6. data change on master2 (the same attribute on the same object, other value) > now the masters are out of sync in the same field 7. restart of master1 8. the sync process is running 9. take a look on the change field.. there are different regards Sascha Kuehndel PS - Nice to have: The posibility to define the action in thouch an situation - master1 or master2... wins - the newest win - or no change and the posibility to write a log-entry about it (with the exact dn,the attribute and the values before the synchronization)

1 0

Re: (ITS#6918) #include statement unsafe
by quanah＠zimbra.com 03 May '11

03 May '11

--On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> Nothing in the OpenLDAP code issues a truncate operation of any sort. > > There are several fopen(filename, "w") calls, which truncate the file. > Maybe the error confuses slapd so it takes a detour into one of them. > > Quanah, can you provide a full slapd.conf and command line which causes > this? Not that I have a Windows box to test it on, but still... The command line was just slapd.exe -d -1 -f slapd.conf The slapd.conf itself is fairly small. The line that wrapped was the include for inetOrgPerson. Everything obviously stopped when it hit the wrapped include. ucdata-path "/opt/zimbra/openldap/ucdata" include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/schema/zimbra.schema" pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" modulepath /opt/zimbra/openldap/openldap moduleload back_bdb-2-4-2.dll moduleload back_monitor-2-4-2.dll access to dn.subtree="" by dn.children="cn=admins,cn=zimbra" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database config rootpw {SSHA}8+r0nkcErptqasSrFPcT0k81NFrbTcAS database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra" read database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/opt/zimbra/data/ldap/hdb/db" index objectClass eq index uid pres,eq index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited access to attrs=userPassword by anonymous auth by dn.children="cn=admins,cn=zimbra" write access to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write access to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zimbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory,zimbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admins,cn=zimbra" write by * none access to filter=(!(zimbraHideInGal=TRUE)) attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumber,title,uid by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=objectclass,zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6912) authz-regexp DN normalization of authcIDs
by daniel＠pluta.biz 03 May '11

03 May '11

In case authcIDs do not need to be normalized, this seems to be a better place to disable normalization: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110502.patch Now authzIDs of the form "u:xxxx" are also affected.

1 0

(ITS#6925) [PATCH] Use inet_ntop for server when available
by delphij＠gmail.com 02 May '11

02 May '11

Full_Name: Xin LI Version: 2.4.25 OS: FreeBSD/amd64 9.0-CURRENT URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.40.55.65) slapd uses inet_ntoa in several places and some of them does not use inet_ntop when it's available. The inet_ntoa is not thread-safe on FreeBSD and thus could cause denial of service if it loses the race, when an IP based ACL is in effect. diff --git a/servers/slapd/connection.c b/servers/slapd/connection.c index aea3b39..65ce576 100644 --- a/servers/slapd/connection.c +++ b/servers/slapd/connection.c @@ -1500,12 +1500,21 @@ connection_input( Connection *conn , conn_readinfo *cri ) #ifdef LDAP_CONNECTIONLESS if ( conn->c_is_udp ) { char peername[sizeof("IP=255.255.255.255:65336")]; + const char *peeraddr = NULL; len = ber_int_sb_read(conn->c_sb, &peeraddr, sizeof(struct sockaddr)); if (len != sizeof(struct sockaddr)) return 1; +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &peeraddr.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ + peeraddr = inet_ntoa( peeraddr.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", - inet_ntoa( peeraddr.sa_in_addr.sin_addr ), + peeraddr, (unsigned) ntohs( peeraddr.sa_in_addr.sin_port ) ); Statslog( LDAP_DEBUG_STATS, "conn=%lu UDP request from %s (%s) accepted.\n", diff --git a/servers/slapd/daemon.c b/servers/slapd/daemon.c index 8e8a69d..ccfa2ee 100644 --- a/servers/slapd/daemon.c +++ b/servers/slapd/daemon.c @@ -1971,8 +1971,16 @@ slap_listener( # ifdef LDAP_PF_INET6 case AF_INET6: if ( IN6_IS_ADDR_V4MAPPED(&from.sa_in6_addr.sin6_addr) ) { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, + ((struct in_addr *)&from.sa_in6_addr.sin6_addr.s6_addr[12]), + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( *((struct in_addr *) &from.sa_in6_addr.sin6_addr.s6_addr[12]) ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in6_addr.sin6_port ) ); @@ -1989,12 +1997,19 @@ slap_listener( break; # endif /* LDAP_PF_INET6 */ - case AF_INET: + case AF_INET: { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &from.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( from.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in_addr.sin_port ) ); - break; + } break; default: slapd_close(sfd);

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by Mark.Selby＠deshaw.com 02 May '11

02 May '11

--_000_7A74C7BE829D9D478879E3DBC0EFDA732B395EE5NYCMBX1winmaild_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "FWIW, we don't think this is the same problem. All the threads except the = main one and the one blocking on select(), are blocked on pthread_cond_wait= () - and, according to our analysis of the core file, while they all are us= ing different mutexes, they are all waiting on the same condition variable.= " Is there anything that we can do to have you look at the issue closer? --_000_7A74C7BE829D9D478879E3DBC0EFDA732B395EE5NYCMBX1winmaild_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Calibri, sans-serif" size=3D"2"> <div><font color=3D"#1F497D">“FWIW, we don’t think this is the = same problem. All the threads except the main one and the one blocking on <= i>select(),</i> are blocked on <i>pthread_cond_wait() </i>– and, acco= rding to our analysis of the core file, while they all are using different mutexes, they are all waiting on the same condition var= iable.”</font></div> <div> </div> <div><font face=3D"Courier New, monospace" size=3D"2">Is there anything tha= t we can do to have you look at the issue closer?</font></div> <div> </div> </font> </body> </html> --_000_7A74C7BE829D9D478879E3DBC0EFDA732B395EE5NYCMBX1winmaild_--

1 0

(ITS#6924) www.openldap.org and git.openldap.org serve different repositories
by ondrej.kuznik＠acision.com 02 May '11

02 May '11

Full_Name: Ondrej Kuznik Version: OS: URL: Submission from: (NULL) (62.168.56.1) It seems that the repositories served over http and git protocol (urls as advertised on http://www.openldap.org/devel/gitweb.cgi?p=openldap-etc.git;a=summary) differ. While containing roughly the same history, there are a few commits (at least) at the beginning that are unwound differently in each one. The list of differences between the two repos might be larger, however I have no tool at hand that could help me find them all.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs