Re: send_search_entry: conn xxx ber write failed
by Édnei Rodrigues
Hey Quanah, thank you for your answer.
I will ask to application team to update openldap client.
Regards.
Em 10/09/2015 15:19, "Quanah Gibson-Mount" <quanah(a)zimbra.com> escreveu:
> --On Thursday, September 10, 2015 1:04 PM -0300 Édnei Rodrigues <
> ednei.felipe.rodrigues(a)gmail.com> wrote:
>
>
>> Good morning. How are you doing ?
>>
>> Guys, I have a application that do many connections to my ldap server and
>> I am getting the error "send_search_entry: conn xxx ber write failed."
>> and "(connection lost on write)".
>>
>> This error occur only with that application, but The noise is large,
>> because this one is very importante.
>>
>>
> So, Do this message mean a problem with my LDAP Server? Will I need
>> deploy a other LDAP server and balance these connections ?
>>
>
> IIRC, this generally occurs when a client has disconnected w/o telling the
> server it has done so. I.e., this is caused by the client, not the server.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
5 years, 10 months
2.4.42 RPMs for openSUSE
by Michael Ströder
HI!
I've updated my OpenLDAP builds for openSUSE and SLES12 to release 2.4.42.
Build status and files:
<https://build.opensuse.org/package/show/home:stroeder:branches:network:ld...>
Important note:
If you're using the openldap packages shipped with openSUSE make sure to read
the .changes files to see whether something could break your current setup.
As usual I've tested the packages openSUSE Tumbleweed x86_64 and Factory_ARM
on rasperry pi.
The download repos are here:
<http://download.opensuse.org/repositories/home:/stroeder:/branches:/netwo...>
Make yourself familiar with zypper commands.
Example: Add the repo in openSUSE 13.2 (command in one line):
zypper addrepo --refresh
http://download.opensuse.org/repositories/home:/stroeder:/branches:/netwo...
Please test. Your feedback is appreciated. Especially have a look at whether
the RPMs behave well regarding config files, package descriptions etc.
Compared to stock SUSE packages there are two additional packages:
1. openldap2-contrib with a selection of overlays from, you
might have guessed, the contrib/ source directory:
allop, allowed, autogroup, cloak, denyop, lastbind, noopsrch, nops, pw-sha2,
pw-pbkdf2, smbk5pwd
2. openldap2-back-sock
(see http://www.openldap.org/software/man.cgi?query=slapd-sock)
Ciao, Michael.
5 years, 10 months
send_search_entry: conn xxx ber write failed
by Édnei Rodrigues
Good morning. How are you doing ?
Guys, I have a application that do many connections to my ldap server and I
am getting the error "send_search_entry: conn xxx ber write failed." and
"(connection lost on write)".
This error occur only with that application, but The noise is large,
because this one is very importante.
[root@ds1openldap2h log]# grep 132457 openldap.log
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 fd=675 ACCEPT from
IP=172.23.131.51:41958 (IP=0.0.0.0:389)
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=0 SRCH
base="cn=cvs_sicredi,ou=sistemas_cred_seg_consorcio,ou=sistemas_core_banking,ou=superintendencia_sistemas,ou=diretoria_exec_ti_operacoes,ou=confederacao_sicredi,cn=centralizadora,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=0 SRCH attr=cn
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=0 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=1 SRCH
base="cn=as_modulo_ua,ou=campo_grande,cn=ua,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=1 SRCH attr=cn
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=1 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=2 SRCH
base="cn=as_modulo_ua,ou=metropolis,cn=cooperativa,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=2 SRCH attr=cn
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=3 SRCH
base="ou=sistemas_core_banking,ou=superintendencia_sistemas,ou=diretoria_exec_ti_operacoes,ou=confederacao_sicredi,cn=centralizadora,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=2 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=4 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(&(objectClass=SicrediGrupo)(cn=cvs_sicredi))"
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=4 SRCH attr=cn
Sep 10 09:46:28 ds1openldap2h slapd[16282]: send_search_entry: conn 132457
ber write failed.
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 op=3 SRCH attr=ou
sicredicodigoua sicrediapelido sicredientidadepai sicredicodigocooperativa
sicredicodigoagencia sicreditipo sicrediatributosadicionais
Sep 10 09:46:28 ds1openldap2h slapd[16282]: conn=132457 fd=675 closed
(connection lost on write)
[root@ds1openldap2h log]# grep 135338 openldap.log
Sep 10 03:11:27 ds1openldap2h slapd[16282]: conn=96427 op=135338 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(&(objectClass=SicrediGrupo)(cn=as_modulo_ua))"
Sep 10 03:11:27 ds1openldap2h slapd[16282]: conn=96427 op=135338 SRCH
attr=cn
Sep 10 03:11:27 ds1openldap2h slapd[16282]: conn=96427 op=135338 SEARCH
RESULT tag=101 err=0 nentries=1 text=
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=3 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=4 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(&(objectClass=SicrediGrupo)(cn=as_modulo_ua))"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=4 SRCH attr=cn
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=5 SRCH
base="ou=diretoria_exec_ti_operacoes,ou=confederacao_sicredi,cn=centralizadora,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=5 SRCH attr=ou
sicredicodigoua sicrediapelido sicredientidadepai sicredicodigocooperativa
sicredicodigoagencia sicreditipo sicrediatributosadicionais
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=5 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=6 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(uniqueMember=cn=riscodecredito_banco_projetonovorisco,cn=email,cn=groups,dc=sicredi,dc=com,dc=br)"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=6 SRCH attr=1.1
cn
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=6 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=7 SRCH
base="cn=as_modulo_ua,ou=cooperucs,cn=cooperativa,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=7 SRCH attr=cn
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=7 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=8 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(&(objectClass=SicrediGrupo)(cn=as_modulo_ua))"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=8 SRCH attr=cn
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=9 SRCH
base="ou=banco,cn=centralizadora,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=9 SRCH attr=ou
sicredicodigoua sicrediapelido sicredientidadepai sicredicodigocooperativa
sicredicodigoagencia sicreditipo sicrediatributosadicionais
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=10 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(uniqueMember=cn=vpn_homeoffice,cn=internet,cn=groups,dc=sicredi,dc=com,dc=br)"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=10 SRCH attr=1.1
cn
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=11 SRCH
base="cn=groups,dc=sicredi,dc=com,dc=br" scope=2 deref=0
filter="(&(objectClass=SicrediGrupo)(cn=as_modulo_ua))"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=11 SRCH attr=cn
Sep 10 09:47:58 ds1openldap2h slapd[16282]: connection_input: conn=135338
deferring operation: too many executing
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=10 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Sep 10 09:47:58 ds1openldap2h slapd[16282]: connection_input: conn=135338
deferring operation: pending operations
Sep 10 09:47:58 ds1openldap2h slapd[16282]: connection_input: conn=135338
deferring operation: too many executing
Sep 10 09:47:58 ds1openldap2h slapd[16282]: send_search_entry: conn 135338
ber write failed.
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=12 SRCH
base="ou=confederacao_sicredi,cn=centralizadora,cn=entities,dc=sicredi,dc=com,dc=br"
scope=0 deref=0 filter="(objectClass=*)"
Sep 10 09:47:58 ds1openldap2h slapd[16282]: conn=135338 op=12 SRCH attr=ou
sicredicodigoua sicrediapelido sicredientidadepai sicredicodigocooperativa
sicredicodigoagencia sicreditipo sicrediatributosadicionais
So, Do this message mean a problem with my LDAP Server? Will I need deploy
a other LDAP server and balance these connections ?
Thanks for the help!
5 years, 10 months
ldapsearch getting attribute list in specific order
by Craig White
I am surprised I haven't tripped over this before.
ldapsearch -b ou=people, etc. uid pwdChangedTime mail
Wanting to e-mail people with expiring passwords.
I am counting on 4 lines for each person...
Dn:
UID:
pwdChangedTime:
mail:
in this exact order
but on the last one (which happens to be me, perhaps because I was the last one to change my password), my 'mail' attribute was returned before the pwdChangedTime attribute which would cause me to re-write the code to handle randomness of order of the output. Do I have to re-write my bash script?
Craig White
5 years, 10 months
LDAPCon 2015 booking now open
by Andrew Findlay
LDAPCon 2015, the fifth International Conference on LDAP, Directory
Services and Identity Management will be held in the UK at the
University of Edinburgh School of Informatics Forum.
Tutorials: 11th November 2015
Conference: 12th and 13th November 2015
We have 22 peer-reviewed papers. Topics include service design,
LDAP schema, protocol enhancements, server technology and client
programming. There will be a poster display area for updates on the very
latest work-in-progress, and a social event in a spectacular city-centre
venue for networking with other LDAP professionals.
http://ldapcon.org/2015/
Several of the regular contributors to this list will be speaking.
Booking is now open and early-bird prices are available until the
end of September. For full details see the booking page:
http://ldapcon.org/2015/?page_id=112
Book now to get the early-bird price!
There are opportunities for commercial sponsorship that will be of
interest to companies working in related areas. See
http://ldapcon.org/2015/?page_id=101 for details.
Andrew Findlay
Conference Chairman
Thanks to our sponsors for their support.
Our first Platinum sponsor: Symas http://symas.com/
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
5 years, 10 months
ldapmodrdn accented characters with windows client
by LAROCHETTE Philippe
Hello,
I can't use ldapmodrdn command when some attributes like givenname contains accented characters, the error is "Rename result: Invalid DN syntax(34)
My configuration is a server with Linux centos 7 and Openldap 2.4.35
The client is a windows XP where i copy the binarie ldapmodrdn.exe from openldap for windows 2.4.32
When i launch this command for example on linux server it is ok but on the xp client it doesn't work :
ldapmodrdn -h xx.xx.xx.xx:389 -D cn=admin,c=fr -w yyyyyy -s "ou=TEST,c=FR" "cn=TEST Véronique,ou=TEST2,c=FR" "cn=Myname Véronique"
I think the problem is with the executable ldapmodrdn.exe. Where can i find an equivalent version of the linux version that can works on windows ? Have you an idea to solve the problem ?
Thanks
5 years, 10 months
basedn vs binddn
by Kaushal Shriyan
Hi,
I am currently referring to http://www.openldap.org/doc/admin24/ I have
still not understood the difference between basedn and binddn. I will
appreciate if somebody can help me understand with some examples.
Regards,
Kaushal
5 years, 10 months
ldapsearch blocks forever
by Oliver Kowalke
After inspecting the source files of ldapsearch I encountered that
ldap_result() is called with tv.tv_sec = -1. As a result ldap_result()
will block forever (poll() is invoked with -1) in some cases.
If for instance the MTU is no big enough (likely in the context of IPv6
and tunnels), the data will not arrive and ldapsearch will 'hang'.
I'd like to ask what was the intention to call ldap_result() with
tv.tv_sec = -1 even if a timelimit (option -l) was applied at command line.
thx,
Oliver
5 years, 10 months
uniqueness constraint violated when using ldapadd -M
by Geert Hendrickx
Hi,
I noticed uniqueness constraints enforced by the slapo-unique overlay can
be bypassed when using the manage DSA IT control (ldapadd -M).
Using the following simple constraint:
overlay unique
unique_uri ldap:///?mail?sub
I get:
$ ldapadd -x -h localhost -D cn=Manager,dc=my-domain,dc=com -w secret
dn: cn=test1,dc=my-domain,dc=com
objectClass: inetOrgPerson
cn: test1
sn: test1
mail: test(a)my-domain.com
adding new entry "cn=test1,dc=my-domain,dc=com"
dn: cn=test2,dc=my-domain,dc=com
objectClass: inetOrgPerson
cn: test2
sn: test2
mail: test(a)my-domain.com <===== duplicate, violates uniqueness constraint
adding new entry "cn=test2,dc=my-domain,dc=com"
ldap_add: Constraint violation (19)
additional info: some attributes not unique <===== ok, as expected
Retrying with -M
$ ldapadd -M -x -h localhost -D cn=Manager,dc=my-domain,dc=com -w secret
dn: cn=test2,dc=my-domain,dc=com
objectClass: inetOrgPerson
cn: test2
sn: test2
mail: test(a)my-domain.com <===== duplicate, violates uniqueness constraint
adding new entry "cn=test2,dc=my-domain,dc=com" <===== but it is accepted?
$ ldapsearch -x -h localhost -b dc=my-domain,dc=com mail=test(a)my-domain.com
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: mail=test(a)my-domain.com
# requesting: ALL
#
# test1, my-domain.com
dn: cn=test1,dc=my-domain,dc=com
objectClass: inetOrgPerson
cn: test1
sn: test1
mail: test(a)my-domain.com
# test2, my-domain.com
dn: cn=test2,dc=my-domain,dc=com
objectClass: inetOrgPerson
cn: test2
sn: test2
mail: test(a)my-domain.com
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
The uniqueness constraint has been violated when using -M, while it was
correctly enforced without -M.
Feature or bug?
Geert
--
geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!
5 years, 10 months
