openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

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

Re: (ITS#6918) #include statement unsafe
by h.b.furuseth＠usit.uio.no 02 May '11

02 May '11

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... -- Hallvard

1 0

Re: (ITS#6919) "Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by jarl＠dallur.com 01 May '11

01 May '11

--000e0cd48c428f954504a23eaa22 Content-Type: text/plain; charset=UTF-8 First of all let me apologize for the state of the config. As you say the logs don't show any crash yet the OpenLDAP server is not accepting any new connections after 20:36:37, there should be hundreds of connections being logged there but instead the server hangs completely and nothing is logged, even on log level 1. Perhaps someone could suggest a way of getting more information than what loglevel 1 shows? Would the only other step be a debug build? Jarl On Sun, May 1, 2011 at 4:01 AM, Howard Chu <hyc(a)symas.com> wrote: > jarl(a)dallur.com wrote: > >> Full_Name: Jarl Stefansson >> Version: 2.4.22 >> OS: Centos 5.5 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.15.35.75) >> >> >> Two servers running OpenLDAP in master/master using syncrepl, roughly once >> per >> week one of the servers stops responding to new connections, I tried >> logging >> with loglevel=1 and this is all I got, all suggestions and comments >> appreciated. >> >> This is most likely a "load" related problem since we never experience >> this >> problem in the testlab, only production.: >> > > Your log doesn't indicate any kind of crash. It only shows that a shutdown > was requested, and apparently your startup scripts didn't wait for the > shutdown to complete before starting again. > > > Apr 23 20:36:37 ldap01 slapd2.4[32233]: >> bdb_dn2entry("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") >> Apr 23 20:36:37 ldap01 slapd2.4[32233]: => >> bdb_dn2id("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") >> Apr 23 20:36:37 ldap01 slapd2.4[32233]:<= bdb_dn2id: get failed: >> DB_NOTFOUND: >> No matching key/data pair found (-30988) >> Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id_add 0x2fed7: >> "macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx" >> Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8): >> Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=1025 sd=16 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1022 sd=17 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1037 sd=18 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1038 sd=20 >> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1039 sd=25 >> >> Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and >> initiated. I have two Centos 5 servers running Openldap 2.4.22 with >> master/master syncrepl setup, >> Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=1005 sd=21 >> Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59 >> operations/tasks to finish >> Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "": unclean >> shutdown detected; attempting recovery. >> Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting >> > > Your config is a mess, with global directives and DB-specific directives > interleaved. That may not be the cause of any specific problems, but it > shows sloppiness on the part of the sysadmins. > > > ---------------------- Relevant Config >> ------------------------------------------------ >> moduleload syncprov.la >> TLSCertificateFile /etc/pki/tls/private/ldap.pem >> TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem >> TLSCACertificateFile /etc/pki/tls/private/ldap.pem >> >> serverID 001 >> database bdb >> sizelimit 50000 >> cachesize 10000 >> checkpoint 256 5 >> >> >> syncrepl rid=001 >> provider=ldap://10.10.10.10:389 >> bindmethod=simple >> binddn="uid=xxxxrep,ou=xxxxxx,o=xxxxxx" >> credentials=MyPassword >> searchbase="o=xxxx" >> schemachecking=on >> sizelimit="unlimited" >> timelimit="unlimited" >> type=refreshAndPersist >> interval=00:00:00:10 >> retry="5 5 60 +" >> attrs="*,+" >> >> mirrormode on >> overlay syncprov >> syncprov-checkpoint 100 10 >> syncprov-sessionlog 100 >> >> idletimeout 3600 >> threads 32 >> >> >> -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Regards Jarl jarl(a)dallur.com --000e0cd48c428f954504a23eaa22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First of all let me=C2=A0apologize=C2=A0for the state of the config.<div><b= r></div><div>As you say the logs don't show any crash yet the OpenLDAP = server is not accepting any new connections after=C2=A0<meta http-equiv=3D"= content-type" content=3D"text/html; charset=3Dutf-8">20:36:37, there should= be hundreds of connections being logged there but instead the server hangs= completely and nothing is logged, even on log level 1.</div> <div><br></div><div>Perhaps someone could suggest a way of getting more inf= ormation than what loglevel 1 shows?</div><div><br></div><div>Would the onl= y other step be a debug build?</div><div><br></div><div>Jarl<br><br><div cl= ass=3D"gmail_quote"> On Sun, May 1, 2011 at 4:01 AM, Howard Chu <span dir=3D"ltr"><<a href=3D= "mailto:hyc@symas.com">hyc(a)symas.com</a>></span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex;"> <div class=3D"im"><a href=3D"mailto:jarl@dallur.com" target=3D"_blank">jarl= @dallur.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Jarl Stefansson<br> Version: =C2=A02.4.22<br> OS: Centos 5.5<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a><br> Submission from: (NULL) (81.15.35.75)<br> <br> <br> Two servers running OpenLDAP in master/master using syncrepl, roughly once = per<br> week one of the servers stops responding to new connections, I tried loggin= g<br> with loglevel=3D1 and this is all I got, all suggestions and comments<br> appreciated.<br> <br> This is most likely a "load" related problem since we never exper= ience this<br> problem in the testlab, only production.:<br> </blockquote> <br></div> Your log doesn't indicate any kind of crash. It only shows that a shutd= own was requested, and apparently your startup scripts didn't wait for = the shutdown to complete before starting again.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Apr 23 20:36:37 ldap01 slapd2.4[32233]:<br> bdb_dn2entry("macaddress=3D1\2C6\2C00:00:00:00:00:01,ou=3Dxxx,ou=3Dxx,= o=3Dxxxx")<br> Apr 23 20:36:37 ldap01 slapd2.4[32233]: =3D><br> bdb_dn2id("macaddress=3D1\2C6\2C00:00:00:00:00:01,ou=3Dxxx,ou=3Dxx,o= =3Dxxxx")<br> Apr 23 20:36:37 ldap01 slapd2.4[32233]:<=3D bdb_dn2id: get failed: DB_NO= TFOUND:<br> No matching key/data pair found (-30988)<br> Apr 23 20:36:37 ldap01 slapd2.4[32233]: =3D> =C2=A0bdb_dn2id_add 0x2fed7= :<br> "macaddress=3D1\2C6\2C00:00:00:00:00:01,ou=3Dxxx,ou=3Dxx,o=3Dxxxx&quot= ;<br> Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8):<br> Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1025 sd=3D= 16<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1022 sd=3D= 17<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1037 sd=3D= 18<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1038 sd=3D= 20<br> Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=3D1039 sd=3D= 25<br> <br> Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and<br> initiated. I have two Centos 5 servers running Openldap 2.4.22 with<br> master/master syncrepl setup,<br> Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=3D1005 sd=3D= 21<br> Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59<br> operations/tasks to finish<br> Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "":= unclean<br> shutdown detected; attempting recovery.<br> Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting<br> </blockquote> <br></div> Your config is a mess, with global directives and DB-specific directives in= terleaved. That may not be the cause of any specific problems, but it shows= sloppiness on the part of the sysadmins.<div><div></div><div class=3D"h5"> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> ---------------------- Relevant Config<br> ------------------------------------------------<br> moduleload =C2=A0 =C2=A0 <a href=3D"http://syncprov.la" target=3D"_blank">s= yncprov.la</a><br> TLSCertificateFile =C2=A0 =C2=A0 =C2=A0/etc/pki/tls/private/ldap.pem<br> TLSCertificateKeyFile =C2=A0 /etc/pki/tls/private/ldap.pem<br> TLSCACertificateFile =C2=A0 =C2=A0/etc/pki/tls/private/ldap.pem<br> <br> serverID =C2=A0 =C2=A0 =C2=A0 =C2=A0001<br> database =C2=A0 =C2=A0 =C2=A0 =C2=A0bdb<br> sizelimit =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A050000<br> cachesize 10000<br> checkpoint 256 5<br> <br> <br> syncrepl =C2=A0 =C2=A0 =C2=A0 =C2=A0rid=3D001<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 provider=3Dldap://= <a href=3D"http://10.10.10.10:389" target=3D"_blank">10.10.10.10:389</a><br= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bindmethod=3Dsimpl= e<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 binddn=3D"uid= =3Dxxxxrep,ou=3Dxxxxxx,o=3Dxxxxxx"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 credentials=3DMyPa= ssword<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 searchbase=3D&quot= ;o=3Dxxxx"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 schemachecking=3Do= n<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sizelimit=3D"= unlimited"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timelimit=3D"= unlimited"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type=3DrefreshAndP= ersist<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interval=3D00:00:0= 0:10<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 retry=3D"5 5 = 60 +"<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attrs=3D"*,+&= quot;<br> <br> mirrormode on<br> overlay syncprov<br> syncprov-checkpoint =C2=A0 =C2=A0 100 =C2=A0 =C2=A0 10<br> syncprov-sessionlog =C2=A0 =C2=A0 100<br> <br> idletimeout 3600<br> threads 32<br> <br> <br> </blockquote></div></div><font color=3D"#888888"> -- <br> =C2=A0-- Howard Chu<br> =C2=A0CTO, Symas Corp. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http:= //www.symas.com" target=3D"_blank">http://www.symas.com</a><br> =C2=A0Director, Highland Sun =C2=A0 =C2=A0 <a href=3D"http://highlandsun.c= om/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a><br> =C2=A0Chief Architect, OpenLDAP =C2=A0<a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a><br> </font></blockquote></div><br><br clear=3D"all"><br>-- <br>Regards<br><br>J= arl<br><a href=3D"mailto:jarl@dallur.com">jarl(a)dallur.com</a><br> </div> --000e0cd48c428f954504a23eaa22--

1 0

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 30 Apr '11

30 Apr '11

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > An include statement in slapd.conf with no following text will overwrite > slapd.exe as a zero sized binary when it occurs on a windows box. Don't do that. > line 8 (include) > slapd.conf: line 8: keyword<include> missing<file> argument > slapd destroy: freeing system resources. > slapd stopped. > connections_destroy: nothing to destroy. > > > > After this windows does not recognize slapd.exe as a normal windows app.. > It has become 0 size Nothing in the OpenLDAP code issues a truncate operation of any sort. Nor would it, in the midst of a config statement that was rejected. If you're seeing odd behavior here, it's either a C library bug or a Windows OS bug. 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

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by hyc＠symas.com 30 Apr '11

30 Apr '11

mslby(a)deshaw.com wrote: > Full_Name: Mark Selby > Version: 2.4.25 > OS: Solaris 10 x86 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (149.77.104.214) > > > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris > 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming > services (passwd, group, netgroup etc?) as well as holding mail routing and > some custom data. We have master and slave servers and are using syncrepl > refresh and persist. > > Lately we have been experiencing hangs with slapd and I cannot figure out > what the cause is. Things will be humming along and then slapd will simply > stop accepting connections and answering any requests for reads/writes. We > have set the loglevel to 256 and there is nothing in the logs that > indicates what the issue it. At the time that the process goes catatonic all > syslogs from slapd stop > > I have not found a way to reproduce this on demand. > > Today we have had three hangs and the truss ouput is exactly the same on > all process. Once the slapd process gets in this state a simple kill does > not work. The syslog always says that slapd is waiting for tasks to > complete but this never happens. I need to kill -9 the pid. > > I am going to include all of the debug info that I have collected and > hopefully someone will have some idea what is going on. I also have a gcore > of the process if anyone wants and info from that > > All and any help is greatly appreciated This appears to be a dup of ITS#6833. Your OS is broken. 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

Re: (ITS#6919) "Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by hyc＠symas.com 30 Apr '11

30 Apr '11

jarl(a)dallur.com wrote: > Full_Name: Jarl Stefansson > Version: 2.4.22 > OS: Centos 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.15.35.75) > > > Two servers running OpenLDAP in master/master using syncrepl, roughly once per > week one of the servers stops responding to new connections, I tried logging > with loglevel=1 and this is all I got, all suggestions and comments > appreciated. > > This is most likely a "load" related problem since we never experience this > problem in the testlab, only production.: Your log doesn't indicate any kind of crash. It only shows that a shutdown was requested, and apparently your startup scripts didn't wait for the shutdown to complete before starting again. > Apr 23 20:36:37 ldap01 slapd2.4[32233]: > bdb_dn2entry("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") > Apr 23 20:36:37 ldap01 slapd2.4[32233]: => > bdb_dn2id("macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx") > Apr 23 20:36:37 ldap01 slapd2.4[32233]:<= bdb_dn2id: get failed: DB_NOTFOUND: > No matching key/data pair found (-30988) > Apr 23 20:36:37 ldap01 slapd2.4[32233]: => bdb_dn2id_add 0x2fed7: > "macaddress=1\2C6\2C00:00:00:00:00:01,ou=xxx,ou=xx,o=xxxx" > Apr 23 20:37:44 ldap01 slapd2.4[32233]: slap_listener_activate(8): > Apr 23 21:35:42 ldap01 slapd2.4[32233]: connection_close: conn=1025 sd=16 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1022 sd=17 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1037 sd=18 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1038 sd=20 > Apr 23 21:55:42 ldap01 slapd2.4[32233]: connection_close: conn=1039 sd=25 > > Apr 24 12:02:23 ldap01 slapd2.4[32233]: daemon: shutdown requested and > initiated. I have two Centos 5 servers running Openldap 2.4.22 with > master/master syncrepl setup, > Apr 24 12:02:23 ldap01 slapd2.4[32233]: connection_close: conn=1005 sd=21 > Apr 24 12:02:23 ldap01 slapd2.4[32233]: slapd shutdown: waiting for 59 > operations/tasks to finish > Apr 24 12:02:34 ldap01 slapd2.4[26503]: bdb_db_open: database "": unclean > shutdown detected; attempting recovery. > Apr 24 12:02:35 ldap01 slapd2.4[26503]: slapd starting Your config is a mess, with global directives and DB-specific directives interleaved. That may not be the cause of any specific problems, but it shows sloppiness on the part of the sysadmins. > ---------------------- Relevant Config > ------------------------------------------------ > moduleload syncprov.la > TLSCertificateFile /etc/pki/tls/private/ldap.pem > TLSCertificateKeyFile /etc/pki/tls/private/ldap.pem > TLSCACertificateFile /etc/pki/tls/private/ldap.pem > > serverID 001 > database bdb > sizelimit 50000 > cachesize 10000 > checkpoint 256 5 > > > syncrepl rid=001 > provider=ldap://10.10.10.10:389 > bindmethod=simple > binddn="uid=xxxxrep,ou=xxxxxx,o=xxxxxx" > credentials=MyPassword > searchbase="o=xxxx" > schemachecking=on > sizelimit="unlimited" > timelimit="unlimited" > type=refreshAndPersist > interval=00:00:00:10 > retry="5 5 60 +" > attrs="*,+" > > mirrormode on > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > idletimeout 3600 > threads 32 > > -- -- 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

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