openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

Re: (ITS#6923) ldapsearch issue
by hyc＠symas.com 30 Apr '11

30 Apr '11

michael(a)stroeder.com wrote: > charles.merrick(a)nice.com wrote: >> I am trying to execute a ldapsearch command with a -w option for password. The >> problem occurs when I have an extended ASCII char in the password like the >> British Pound symbol "£" (ascii number 163) embedded in the password string. >> Are extended ASCII chars allowed in password string? LDAP passwords are Octet Strings. It doesn't matter if your octets correspond to ASCII or any other character set, as long as the tools you use all send the exact same sequence of octets. > I guess this depends on the locale's charset configured for your console. His console at Bind time is only part of the question. The other question is what locale was in effect when the password was originally set, and what tool was used to set it. Some tools may assume you're in an 8-bit ASCII environment and do no conversion of the input characters. Some may assume you're in a UTF-8 or ISO-8859 locale and transform the characters to some other octet sequence. -- -- 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#6921) bind failure with LDAP_OPT_NETWORK_TIMEOUT
by quanah＠zimbra.com 30 Apr '11

30 Apr '11

--On Friday, April 29, 2011 5:23 AM +0000 pravat.singh(a)nsn.com wrote: > Full_Name: Pravat Singh > Version: 2.4.23 > OS: solaris 5.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.131.155.20) > > > I am facing problem while in ldap_simple_bind () while setting > LDAP_OPT_NETWORK_TIMEOUT. Can anybody let me know if I am missing > something. Just to add some information that I have compiled the > openldap-2.4.23 version on solaris 10 with sun studio compiler. The bind > api ?ldap_simple_bind()? is successful if don?t use > LDAP_OPT_NETWORK_TIMEOUT but fails if I use. The ITS system is for reporting bugs, not for asking how to program. I already noted to you there are multiple examples in the OpenLDAP source code itself for using this option. --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#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by quanah＠zimbra.com 30 Apr '11

30 Apr '11

--On Thursday, April 28, 2011 6:05 PM +0000 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. Correcting the from address (mselby(a)deshaw.com is correct). I will note that there have been numerous issues IIRC reported with using Solaris 10 and OpenLDAP, due to a kernel bug in Solaris. --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#6923) ldapsearch issue
by michael＠stroeder.com 30 Apr '11

30 Apr '11

charles.merrick(a)nice.com wrote: > I am trying to execute a ldapsearch command with a -w option for password. The > problem occurs when I have an extended ASCII char in the password like the > British Pound symbol "£" (ascii number 163) embedded in the password string. > Are extended ASCII chars allowed in password string? I guess this depends on the locale's charset configured for your console. Ciao, Michael.

1 0

(ITS#6923) ldapsearch issue
by charles.merrick＠nice.com 29 Apr '11

29 Apr '11

Full_Name: Charles Merrick Version: 2.1.29 OS: SunOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.91.126.66) I am trying to execute a ldapsearch command with a -w option for password. The problem occurs when I have an extended ASCII char in the password like the British Pound symbol "£" (ascii number 163) embedded in the password string. Are extended ASCII chars allowed in password string? I get the following error message: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece I understand that this means that the password is invalid. For example, if I have userID "Guest_01" and password "Test" then ldapsearch will work, but if I have userID "Guest_01" and passworrd "Test_£" then ldapsearch fails with above message. I have tried putting the -w password in double quotes and with no quotes. When password is -w Test or -w"Test" it works fine but when I use -w Test£ or -w"Test£", it fails. Thank you for your assistance. I am a developer who fixes bugs and ldap stuff is new to me for maintenance.

1 0

Re: (ITS#6922) connection_read(20): no connection!
by hyc＠symas.com 29 Apr '11

29 Apr '11

Michael Ströder wrote: > hyc(a)symas.com wrote: >> The debug output shows that a read attempt was queued up for a socket that was >> closed. This is a normal occurrence when an LDAP client closes its connection >> immediately after sending its last request (Unbind here) and slapd doesn't >> have enough CPU resources to process the read attempt immediately. > > Just because of not enough CPU? Are you sure? "not enough CPU" is relative here. The socket layer receives the Unbind and close pretty much atomically, while slapd receives them as two separate events. Given that slapd *always* receives these as two separate events, it can *never* be "fast enough" to process this without at least one extraneous "no connection" occurrence. > This is a local test server on a 99% idle dual-core notebook which did not do > anything else than processing a single search and after the client received > all the results (72 entries, few short text attributes) the client sends the > unbind. Nothing else is happening. And I can reproduce it everytime. >> If you're reporting a hang with OpenLDAP, you should have said that >> explicitly. If not, then I see no bug here and this ITS will be closed. > > I'm so cautious about this because I had a situation where a slapd process (a > provider) died several times. And the last message seen in the syslog was > exactly "connection_read(20): no connection!". If you see that, run the slapd with gdb attached and get a trace when it dies. There's nothing here that indicates anything abnormal. 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#6922) connection_read(20): no connection!
by michael＠stroeder.com 29 Apr '11

29 Apr '11

hyc(a)symas.com wrote: > The debug output shows that a read attempt was queued up for a socket that was > closed. This is a normal occurrence when an LDAP client closes its connection > immediately after sending its last request (Unbind here) and slapd doesn't > have enough CPU resources to process the read attempt immediately. Just because of not enough CPU? Are you sure? This is a local test server on a 99% idle dual-core notebook which did not do anything else than processing a single search and after the client received all the results (72 entries, few short text attributes) the client sends the unbind. Nothing else is happening. And I can reproduce it everytime. > If you're reporting a hang with OpenLDAP, you should have said that > explicitly. If not, then I see no bug here and this ITS will be closed. I'm so cautious about this because I had a situation where a slapd process (a provider) died several times. And the last message seen in the syslog was exactly "connection_read(20): no connection!". Ciao, Michael.

1 0

Re: (ITS#6922) connection_read(20): no connection!
by hyc＠symas.com 29 Apr '11

29 Apr '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: 2.4.25 > OS: openSUSE Linux 11.4 > URL: > Submission from: (NULL) (84.128.243.158) > > > Currently I observe something like below in my syslog. The syslog output you included doesn't show anything unusual. Did you have an actual bug to report? > This is a simple > python-ldap (linked against OpenLDAP libs 2.4.25) script doing LDAPI connect and > unbind. I occasionally experience hangs when doing unbind also to other LDAP > servers. Your syslog output doesn't show any problem. Your debug output also doesn't show any problem. The debug output shows that a read attempt was queued up for a socket that was closed. This is a normal occurrence when an LDAP client closes its connection immediately after sending its last request (Unbind here) and slapd doesn't have enough CPU resources to process the read attempt immediately. By the time slapd gets to this event in its queue, the connection is gone. If you're reporting a hang with OpenLDAP, you should have said that explicitly. If not, then I see no bug here and this ITS will be closed. > ---------------------- debug log ---------------------- > [..private search results snipped..] > <= send_search_entry: conn 1000 exit. > send_ldap_result: conn=1000 op=0 p=3 > send_ldap_result: err=0 matched="" text="" > send_ldap_response: msgid=1 tag=101 err=0 > ber_flush2: 14 bytes to sd 18 > 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ > ldap_write: want=14, written=14 > 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ > conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=72 text= > daemon: activity on 1 descriptor > daemon: activity on: 18r > daemon: read active on 18 > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > daemon: activity on 1 descriptor > daemon: activity on: > daemon: read active on 18 > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > daemon: activity on 1 descriptor > daemon: activity on: > daemon: read active on 18 > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > connection_get(18) > connection_get(18): got connid=1000 > connection_read(18): checking for input on id=1000 > ber_get_next > ldap_read: want=8, got=7 > 0000: 30 05 02 01 02 42 00 0....B. > ber_get_next: tag 0x30 len 5 contents: > ber_dump: buf=0xe9d5a0 ptr=0xe9d5a0 end=0xe9d5a5 len=5 > 0000: 02 01 02 42 00 ...B. > op tag 0x42, time 1304096292 > ber_get_next > ldap_read: want=8, got=0 > > ber_get_next on fd 18 failed errno=0 (Success) > connection_read(18): input error=-2 id=1000, closing. > connection_closing: readying conn=1000 sd=18 for close > connection_close: deferring conn=1000 sd=18 > conn=1000 op=1 do_unbind > conn=1000 op=1 UNBIND > connection_resched: attempting closing conn=1000 sd=18 > connection_close: conn=1000 sd=18 > =>ldap_back_conn_destroy: fetching conn 1000 > daemon: removing 18 > conn=1000 fd=18 closed > connection_get(18) > connection_get(18): connection not used > connection_read(18): no connection! > connection_read(18) error > connection_get(18) > connection_get(18): connection not used > connection_read(18): no connection! > connection_read(18) error > daemon: activity on 1 descriptor > daemon: activity on: > daemon: epoll: listen=7 active_threads=0 tvp=zero > daemon: epoll: listen=8 active_threads=0 tvp=zero > daemon: epoll: listen=9 active_threads=0 tvp=zero > > -- -- 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

(ITS#6922) connection_read(20): no connection!
by michael＠stroeder.com 29 Apr '11

29 Apr '11

Full_Name: Michael Ströder Version: 2.4.25 OS: openSUSE Linux 11.4 URL: Submission from: (NULL) (84.128.243.158) Currently I observe something like below in my syslog. This is a simple python-ldap (linked against OpenLDAP libs 2.4.25) script doing LDAPI connect and unbind. I occasionally experience hangs when doing unbind also to other LDAP servers. ---------------------- syslog ---------------------- Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 fd=20 ACCEPT from PATH=/tmp/openldap-socket (PATH=/tmp/openldap-socket) Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=0 SRCH base="dc=stroeder,dc=de" scope=2 deref=0 filter="(dateOfBirth=*)" Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=0 SRCH attr=telephoneNumber cn mobile dateOfBirth mail homePhone Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=72 text= Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 op=1 UNBIND Apr 29 18:52:37 nb2 slapd[6090]: conn=1000 fd=20 closed ---------------------- syslog ---------------------- ---------------------- debug log ---------------------- [..private search results snipped..] <= send_search_entry: conn 1000 exit. send_ldap_result: conn=1000 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=101 err=0 ber_flush2: 14 bytes to sd 18 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 65 07 0a 01 00 04 00 04 00 0....e........ conn=1000 op=0 SEARCH RESULT tag=101 err=0 nentries=72 text= daemon: activity on 1 descriptor daemon: activity on: 18r daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero connection_get(18) connection_get(18): got connid=1000 connection_read(18): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 02 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0xe9d5a0 ptr=0xe9d5a0 end=0xe9d5a5 len=5 0000: 02 01 02 42 00 ...B. op tag 0x42, time 1304096292 ber_get_next ldap_read: want=8, got=0 ber_get_next on fd 18 failed errno=0 (Success) connection_read(18): input error=-2 id=1000, closing. connection_closing: readying conn=1000 sd=18 for close connection_close: deferring conn=1000 sd=18 conn=1000 op=1 do_unbind conn=1000 op=1 UNBIND connection_resched: attempting closing conn=1000 sd=18 connection_close: conn=1000 sd=18 =>ldap_back_conn_destroy: fetching conn 1000 daemon: removing 18 conn=1000 fd=18 closed connection_get(18) connection_get(18): connection not used connection_read(18): no connection! connection_read(18) error connection_get(18) connection_get(18): connection not used connection_read(18): no connection! connection_read(18) error daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 29 Apr '11

29 Apr '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Note that with assertion control always >> Operations error: "unique_search failed" >> is returned even if the attribute values are unique. >> >> I'd really like to get this solved. web2ldap makes use of the assertion >> control to ensure that an entry has not been changed since being >> edited by the >> user. Otherwise I have to implement another vendor-specific hack >> switching off >> this feature when OpenLDAP is used as server. :-( > > First step toward a solution would be providing slapd -d output for the > problem. Probably a sample config would help too. (Sigh! Did anybody actually read through my report?) Take any slapd.conf with database hdb and add these lines (no other overlays configured): overlay unique unique_attributes uid uidNumber employeeNumber Or any other LDAP-URL-based unique constraint... Then apply a LDIF change record (example below) which contains any of the attributes defined as unique (no matter whether unique constraint is violated or not). ------------------------------- snip ------------------------------- dn: cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local changetype: modify replace: employeeNumber employeeNumber: 456 - ------------------------------- snip ------------------------------- Try these commands (bind-DN is the rootdn here): Without assertion control it works: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" Assertion control just contains objectClass filter: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e 'assert=(objectClass=*)' modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" This fails: $ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret -f unique.ldif -e 'assert=(cn=*)'modifying entry "cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" ldap_modify: Operations error (1) additional info: unique_search failed Output of slapd -d config,stats,stats2,acl,args,trace,sync: ------------------------------- snip ------------------------------- [..] conn=1000 op=1 modifications: replace: employeeNumber one value, length 3 conn=1000 op=1 MOD dn="cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local" conn=1000 op=1 MOD attr=employeeNumber bdb_dn2entry("cn=anna blume,ou=users,ou=schulung,dc=stroeder,dc=local") => hdb_dn2id("ou=users,ou=schulung,dc=stroeder,dc=local") <= hdb_dn2id: got id=0x6 => hdb_dn2id("cn=anna blume,ou=users,ou=schulung,dc=stroeder,dc=local") <= hdb_dn2id: got id=0xd entry_decode: "" <= entry_decode() ==> unique_modify <cn=Anna Blume,ou=Users,ou=schulung,dc=stroeder,dc=local> ==> unique_search (|(employeeNumber=456)) put_filter: "(|(employeeNumber=456))" put_filter: OR put_filter_list "(employeeNumber=456)" put_filter: "(employeeNumber=456)" put_filter: simple put_simple_filter: "employeeNumber=456" ber_scanf fmt ({mm}) ber: => hdb_search bdb_dn2entry("ou=schulung,dc=stroeder,dc=local") => access_allowed: search access to "ou=schulung,dc=stroeder,dc=local" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) => access_allowed: search access to "ou=schulung,dc=stroeder,dc=local" "cn" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=122 matched="" text="" send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=1 matched="" text="unique_search failed" send_ldap_response: msgid=2 tag=103 err=1 ber_flush2: 34 bytes to sd 16 conn=1000 op=1 RESULT tag=103 err=1 text=unique_search failed connection_get(16) connection_get(16): got connid=1000 connection_read(16): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1304069972 ber_get_next ber_get_next on fd 16 failed errno=0 (Success) conn=1000 op=2 do_unbind conn=1000 op=2 UNBIND connection_close: conn=1000 sd=16 conn=1000 fd=16 closed ------------------------------- snip -------------------------------

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