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.
______________________
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.
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
-------------------------------------------------------------
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
---------------------------------------
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
---------------------------------------
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).
Full_Name: Eduardo Izaguirre Pazos
Version: 2.4.8
OS: CentOS 5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.0.110.2)
Hi all, using openldap 2.4.8 as a metadirectory server in front of a couple of
Active Directory Servers and a local database we have found an issue with the
number of ESTABLISHED connections.
This is a part of the slapd configuration file:
backend meta
database meta
## Sufijo del arbol mostrado por el metadirectorio y usuario
## administrador del mismo(superusuario de ldap).
suffix "dc=gmv,dc=es"
rootdn "cn=diradmin,dc=gmv,dc=es"
## Password del superusuario, pasar a texto cifrado con slappasswd.
rootpw secret
##############################################
### Opciones comunes a todo el metadirectorio.
##############################################
#########################################
#### Directivas comunes de configuracion.
## TTL para tirar una conexion, aunque no este inactiva (6 minutos).
conn-ttl 360
## Version del protocolo LDAP a utilizar.
protocol-version 3
## Accion ante un referral.
chase-referrals no
## TTL para tirar una conexion inactiva (5 minutos).
idletimeout 300
#####################################################################
### Definicion del LDAP remoto para las consultas de informacion de
### usuario y grupos UNIX desde maquinas que son clientes LDAP.
#####################################################################
## Definicion de los servidores target remotos a consultar.
## Se consultara el primer servidor remoto que responda.
## Defino una lista de dcs que pueden responder para el contexto de
## nombre dc=gmv,dc=es. Primer target con sus parametros de configuracion.
uri "ldap://gmvdc1.gmv.es/DC=gmv,DC=es ldap://gmvdc2.gmv.es/"
idle-timeout 300
## Habilitamos el sistema de reescritura para las consultas.
rewriteEngine on
overlay rwm
and the output of the netstat -an command shows too much ESTABLISHED connections
between the metadirectory and the remote servers.
After a while, the process runs out of file descriptors.
Thanks an regards.
Eduardo