February 2008 - openldap-bugs

Re: (ITS#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry

by kurt＠OpenLDAP.org

On Feb 29, 2008, at 1:56 AM, michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.114.177) > > > Although implemnted since 2.0 the LDAP Syntax with > 1.3.6.1.4.1.1466.115.121.1.58 > (Substring Assertion) is not listed in subschema subentry. IIRC, it's not listed because it only to be used in certain (extensible) matching rules cases and slapd(8) doesn't support any of those cases. I noticed that this came up because someone was trying to use this syntax an attribute description. That attribute description is likely bogus.

15 years, 7 months

1
0
0 / 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)

by ando＠sys-net.it

jclarke(a)linagora.com wrote: > jclarke(a)linagora.com a écrit : >>>> When slapcat is writing it's output to disk, it ignores any errors >>>> (with slapcat -l output_file or slapcat > output_file). If an error is >>>> encountered, such as "No space left on device", slapcat then exits >>>> normally with a return code of 0. > > Thanks for commiting this to HEAD. > > Is there any chance of seeing it a future maintenance release of 2.3? As soon as one is planned, if ever. I can't say anything right now, since this issue is not a showstopper, and 2.3.41 has just been released. Unless 2.4 becomes stable any soon, there'll probably be another 2.3 at some point. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

15 years, 7 months

1
0
0 / 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)

by jclarke＠linagora.com

jclarke(a)linagora.com a écrit : >>> When slapcat is writing it's output to disk, it ignores any errors >>> (with slapcat -l output_file or slapcat > output_file). If an error is >>> encountered, such as "No space left on device", slapcat then exits >>> normally with a return code of 0. Thanks for commiting this to HEAD. Is there any chance of seeing it a future maintenance release of 2.3? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

15 years, 7 months

1
0
0 / 0

ITS#5396

by ecizaguirre＠gmv.com

Another update about this problem. Connections between slpad and the remote active directory servers remains in ESTABLISHED state for a long time and changes to CLOSE_WAIT state in the slapd server. In the active directory servers the connections then changes to FIN_WAIT_2, so it seems the slapd server is not sending the FIN packet to close the socket. Cheers. Eduardo ________________________________ De: Eduardo Izaguirre Pazos Enviado el: jueves, 28 de febrero de 2008 13:21 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 An update about the case, the problem seems to be related with the connections which remains in CLOSE_WAIT state, as an example: [root@metaldap openldap]# netstat -an | grep -i close | wc -l 11361 all these connections are to the remote ldap servers. Cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

15 years, 7 months

1
0
0 / 0

(ITS#5399) LDAP Syntax 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) not listed in subschema subentry

by michael＠stroeder.com

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.114.177) Although implemnted since 2.0 the LDAP Syntax with 1.3.6.1.4.1.1466.115.121.1.58 (Substring Assertion) is not listed in subschema subentry.

15 years, 7 months

1
0
0 / 0

(ITS#5398) An account locked in a consumer is only unlocked when the password is changed two times

by ssnet＠ua.es

Full_Name: maria saez Version: 2.4.8 OS: debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.145.230.2) An account locked in a consumer needs two password changes in the provider to be unlocked. The first time that we change the password in the provider the password change is replicated in the consumer but the account remains locked. Can you help us? We have openldap-2.4.7 and openldap-2.4.8 Is this situation normal? We have the following configuration: Provider ------------------------------------------- database bdb suffix "dc=xx,dc=es" rootdn "cn=config" directory /xx/data index entryCSN eq index entryUUID eq index objectClass eq index mail eq # define the replica provider for this database # (last directives in database section) overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es" ppolicy_use_lockout overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Consumer ---------------------------------------------------------------- database bdb suffix "dc=xx,dc=es" rootdn "cn=config" directory /xx/data index entryCSN eq index entryUUID eq index objectClass eq index mail eq overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es" ppolicy_use_lockout syncrepl rid=123 provider=ldaps://xx.xx.es:xx/ binddn="cn=config" bindmethod=simple credentials=xx searchbase="dc=xx,dc=es" schemachecking=on type=refreshAndPersist retry="60 +" overlay syncprov ------------------------------------------------------------------- The policy we have defined: dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es cn: Standard Policy objectClass: top objectClass: device objectClass: pwdPolicy pwdAttribute: 2.5.4.35 pwdLockout: TRUE pwdLockoutDuration: 0 pwdInHistory: 6 pwdCheckQuality: 2 pwdExpireWarning: 10 pwdMaxAge: 120 pwdMinLength: 5 pwdGraceAuthnLimit: 3 pwdAllowUserChange: TRUE pwdMustChange: TRUE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: TRUE pwdMinAge: 120 -------------------------------------------------------------

15 years, 7 months

1
0
0 / 0

RE: (ITS#5397) syncrepl badly processes modify rdn operation

by emmanuel.duru＠atosorigin.com

OK I have tested it, it works fine. Thank you. > -----Message d'origine----- > De : Pierangelo Masarati [mailto:ando@sys-net.it] > Envoyé : jeudi 28 février 2008 16:24 > À : emmanuel.duru(a)atosorigin.com > Cc : openldap-its(a)openldap.org > Objet : Re: (ITS#5397) syncrepl badly processes modify rdn operation > > emmanuel.duru(a)atosorigin.com wrote: > > > When the provider server receives a modify RDN operation, syncrepl > replicates it > > with the full new DN as new RDN. > > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets > the newrdn > > from a call to dnRdn() function, which only modifies the bv_len of the > ber > > struct, but not the value itself. Following this, the > backend:be_modrdn() > > function does not check the length, and gets the full DN as RDN value > (at least > > back_ldap does this). > > Fixed in HEAD (the patch should apply more or less to 2.3 as well). I > note that slapo-auditlog might siffer from the same problem; other > overlays could print the incorrect newRDN in log messages. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- >

15 years, 7 months

1
0
0 / 0

Re: (ITS#5397) syncrepl badly processes modify rdn operation

by ando＠sys-net.it

emmanuel.duru(a)atosorigin.com wrote: > When the provider server receives a modify RDN operation, syncrepl replicates it > with the full new DN as new RDN. > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn > from a call to dnRdn() function, which only modifies the bv_len of the ber > struct, but not the value itself. Following this, the backend:be_modrdn() > function does not check the length, and gets the full DN as RDN value (at least > back_ldap does this). Fixed in HEAD (the patch should apply more or less to 2.3 as well). I note that slapo-auditlog might siffer from the same problem; other overlays could print the incorrect newRDN in log messages. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

15 years, 7 months

1
0
0 / 0

Re: (ITS#5397) syncrepl badly processes modify rdn operation

by ando＠sys-net.it

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.39 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > When the provider server receives a modify RDN operation, syncrepl replicates it > with the full new DN as new RDN. > Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn > from a call to dnRdn() function, which only modifies the bv_len of the ber > struct, but not the value itself. Following this, the backend:be_modrdn() > function does not check the length, and gets the full DN as RDN value (at least > back_ldap does this). I see. In fact, while slapd internally uses bervals consistently, and honors their length, it is usually accepted that string bervals are NUL-terminated. Probably the "right" fix is in syncrepl code, although the real right fix would consist in rewriting the client API to consistently use bervals. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

15 years, 7 months

1
0
0 / 0

(ITS#5397) syncrepl badly processes modify rdn operation

by emmanuel.duru＠atosorigin.com

Full_Name: Emmanuel Duru Version: 2.3.39 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.68.44.148) When the provider server receives a modify RDN operation, syncrepl replicates it with the full new DN as new RDN. Trying to investigate it, I see that syncrepl.c:syncrepl_entry() gets the newrdn from a call to dnRdn() function, which only modifies the bv_len of the ber struct, but not the value itself. Following this, the backend:be_modrdn() function does not check the length, and gets the full DN as RDN value (at least back_ldap does this).

15 years, 7 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008