openldap-bugs September 2013

openldap-bugs@openldap.org

30 participants
114 discussions

RE: (ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

I forgot to mention that the operations are all active at the same time: Issue paged op 1 Receive results for op 1 Issue paged op 2 Issue paged op 3 Request 2nd page for op 1 >From our trace: 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SEARCH one 'ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=5a 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> attribute[0]=1.1 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SendingControl[0]=SimplePaged, Length=7, IsCritical=true 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SimplePaged: 30 05 02 01 02 04 00 16:45:00.693: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> ReceivedControl[0]=SimplePaged, Length=11 16:45:00.693: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SimplePaged: 30 09 02 01 00 04 04 04 00 00 00 16:45:00.693: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SEARCH Result OK received=0 total=2 (complete) 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> SEARCH one 'cn=c1,ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=5d 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> attribute[0]=1.1 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> SendingControl[0]=SimplePaged, Length=7, IsCritical=true 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> SimplePaged: 30 05 02 01 02 04 00 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> SEARCH one 'cn=c2,ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=60 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> attribute[0]=1.1 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> SendingControl[0]=SimplePaged, Length=7, IsCritical=true 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> SimplePaged: 30 05 02 01 02 04 00 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SEARCH one 'ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=61 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> attribute[0]=1.1 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SendingControl[0]=SimplePaged, Length=11, IsCritical=true 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SimplePaged: 30 09 02 01 02 04 04 04 00 00 00 16:45:00.737: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SEARCH Result ERROR='DA_E_PROTOCOL_ERROR' received=0 total=0 (complete) 16:45:00.737: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SEARCH Result Server_Info='paged results cookie is invalid'

1 0

(ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

Full_Name: John Unsworth Version: 2.4.34 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.139.153.176) If I issue multiple paged requests on a single connection then when requesting the second page for the first request I receive 'paged results cookie is invalid'. I suspect from looking at the code that only a single paged request is allowed to be active at once on a connection. Can someone confirm please. parse_paged_cookie( Operation *op, SlapReply *rs ) if ( ps->ps_cookieval.bv_len ) { ... } else { /* we're going to use ps_cookie */ op->o_conn->c_pagedresults_state.ps_cookie = 0; It seems to me that the cookie is held against the connection (o_conn) and not the operation. Surely this is wrong?

1 0

Re: (ITS#7697) RFE: contrib/slapo-lastbind as an official overlay
by michael＠stroeder.com 17 Sep '13

17 Sep '13

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: All > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.11.209.11) > > > I would like to use contrib/slapo-lastbind as I currently do with all official > overlays: > > - main configure option > - cn=config integration > > So my request is to official adopt it. > > Few years ago I asked for another enhancement of this module with ITS#6871. +1, also for ITS#6871. Ciao, Michael.

1 0

(ITS#7697) RFE: contrib/slapo-lastbind as an official overlay
by marco.pizzoli＠gmail.com 17 Sep '13

17 Sep '13

Full_Name: Marco Pizzoli Version: All OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) I would like to use contrib/slapo-lastbind as I currently do with all official overlays: - main configure option - cn=config integration So my request is to official adopt it. Few years ago I asked for another enhancement of this module with ITS#6871. Any hope? Thanks in advance Marco Pizzoli

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 16 Sep '13

16 Sep '13

Hi Quana, Now i understood what you mean. ;) I'll try it. Thank you Mike -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

(ITS#7679)
by a.rossini＠cineca.it 16 Sep '13

16 Sep '13

This is a multipart message in MIME format. ------=_NextPart_000_00FF_01CEB2BE.DC3AE260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have checked our build and it passes test044. I'll open a new discussion on the openldap-technical mailing list. Thanks, Angelo. ------=_NextPart_000_00FF_01CEB2BE.DC3AE260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DIT link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>We have checked our build and it passes = test044.<o:p></o:p><o:p> </o:p>I’ll open a new discussion on the openldap-technical mailing = list.<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Angelo.<o:p></o:p><o:p> </o:p><= /p><o:p> </o:p></div></body></html> ------=_NextPart_000_00FF_01CEB2BE.DC3AE260--

1 0

Re: (ITS#7696) FACING ISSUE WHILE ADDING LDAP USER
by michael＠stroeder.com 15 Sep '13

15 Sep '13

This is a cryptographically signed message in MIME format. --------------ms030307080905040004000600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cs.sudhan.mca(a)gmail.com wrote: > [root@ldap5 migration]# ldapadd -D "cn=3DManager,dc=3Dlinux,dc=3Dcom" -= W -x -f > user1.ldif > Enter LDAP Password: > adding new entry "uid=3Duser1,ou=3DPeople,dc=3Dlinux,dc=3Dcom" > ldap_add: No such object (32) > matched DN: dc=3Dlinux,dc=3Dcom Likely the superior entry ou=3DPeople,dc=3Dlinux,dc=3Dcom does not exist = yet. You should ask usage questions on the openldap-technical mailing list. Th= e ITS is for reporting bugs only. Ciao, Michael. --------------ms030307080905040004000600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE1MTkxMzIzWjAj BgkqhkiG9w0BCQQxFgQUneiKFZgfezFKbuPAyOqPw6iORi8wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAGTiZEC0y1XwM2TkuYLmrAj10vLIHF4Jw FHmGeNdvETMVOxMk7RoMxD27gJdXjRdq85QGgXdbxhMsWqfWOSqZphtQ9euuPkgOVIbhGoIO AyNUK09CnHTUKQOGQeBC25dnqMGPUckdkJs+qA8GmhQbdTMg5SxLc9cJNIEzLkv5Bb4nu9AK y5hd9ZxhFEXYFekAh4z6audsR81FZBMWkwIaSQ04Z8J6n7OeFkuxX/Pdu3dHI7mWxXK67vNd tEL1TWNHAODgz4p6RBHEMQJZyKbJfI9bj9XJ9gaIMBuxh+I3ZdNpwl5S2hkX/XqOktu7LxcP 57nxztNqalkCMnXVVVSqEwAAAAAAAA== --------------ms030307080905040004000600--

1 0

(ITS#7696) FACING ISSUE WHILE ADDING LDAP USER
by cs.sudhan.mca＠gmail.com 15 Sep '13

15 Sep '13

Full_Name: HARI HARA SUDHAN S Version: OS: RHEL 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (116.202.144.181) [root@ldap5 migration]# ldapadd -D "cn=Manager,dc=linux,dc=com" -W -x -f user1.ldif Enter LDAP Password: adding new entry "uid=user1,ou=People,dc=linux,dc=com" ldap_add: No such object (32) matched DN: dc=linux,dc=com

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 14 Sep '13

14 Sep '13

I wrote: > Also on RHEL 6.4 (2.6.32-358.18.1.el6.x86_64) with > /dev/shm/nosuch. I'll report it to RedHat and see what they say. https://bugzilla.redhat.com/show_bug.cgi?id=1008073 Simpler fix, at least on Linux: #ifdef O_DIRECT if ((rc = fcntl(fd, F_GETFL)) != -1) (void) fcntl(fd, F_SETFL, rc | O_DIRECT); #endif But that could fail elsewhere, if some OS only accepts O_DIRECT to open() and not to fcntl(). BTW, does the nearby Apple code need to fail if fcntl(newfd, F_NOCACHE, 1) fails? Could ignore errors. -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 14 Sep '13

14 Sep '13

On 2013-09-13 23:09, sog(a)msg.com.mx wrote: > If the call fails because O_DIRECT, in a "tmpfs" in my Fedora 19 > '/tmp', > the file is left created anyway! so the retry fails because > O_EXCL|O_CREAT. Also on RHEL 6.4 (2.6.32-358.18.1.el6.x86_64) with /dev/shm/nosuch. I'll report it to RedHat and see what they say. > I propose the following: > (...) > + * Fortunately seems that other errors are reported before EINVAL > + * So, we need to remove it before retry open. > */ > if (newfd == INVALID_HANDLE_VALUE && ErrCode() == EINVAL) > + (void)unlink(lpath) , No unlink(). EINVAL does not say whether the file existed before the call. Not on another OS, nor on another Linux version or filesystem where Linux may work differently. Somewhat better: #ifdef <buggy Linux>, replace O_EXCL with O_TRUNC in the 2nd call. Or add paranoia like taking an exclusive lock, but ignore "locking not supported" errors. > #endif > newfd = open(lpath, O_WRONLY|O_CREAT|O_EXCL, 0666); > #endif -- Hallvard

1 0

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2013