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, 3 months
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, 3 months
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, 3 months
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, 3 months
(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, 3 months
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, 3 months
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, 3 months
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, 3 months
(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, 3 months