- openldap-bugs - openldap.org

Re: (ITS#7246) Addition of FedFS schema LDIF
by hyc＠symas.com 16 Apr '12

16 Apr '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> 4.2.2.2 fedfsFsn >> IMO name/port should just be an LDAP URL. Also your definition provides >> absolutely zero information of how the LDAP server should be contacted (e.g. >> using ldaps or StartTLS) which both can be encoded in an LDAP URL. > > Which standard describes how to mandate use of StartTLS with a LDAP URL? > OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with > web2ldap. But AFAIK this is not defined in any standard which could be > referenced in a RFC. True but irrelevant. The point is that standardizing on a URL syntax today future-proofs a spec and allows it to handle new connection mechanisms that may appear in the future. Host/port is inextricably tied to networking in the 1980s. > http://www.openldap.org/lists/openldap-devel/200202/msg00060.html > http://www.openldap.org/lists/openldap-devel/200810/msg00034.html > > Ciao, Michael. > -- -- 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#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

hyc(a)symas.com wrote: > 4.2.2.2 fedfsFsn > IMO name/port should just be an LDAP URL. Also your definition provides > absolutely zero information of how the LDAP server should be contacted (e.g. > using ldaps or StartTLS) which both can be encoded in an LDAP URL. Which standard describes how to mandate use of StartTLS with a LDAP URL? OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with web2ldap. But AFAIK this is not defined in any standard which could be referenced in a RFC. http://www.openldap.org/lists/openldap-devel/200202/msg00060.html http://www.openldap.org/lists/openldap-devel/200810/msg00034.html Ciao, Michael.

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

On Apr 16, 2012, at 1:09 PM, Howard Chu wrote: > chuck.lever(a)oracle.com wrote: >> Full_Name: Chuck Lever >> Version: All >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (99.26.161.222) >> >> >> I'd like to request the addition of the FedFS schema described in this draft: >> >> http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 >> >> as part of the repertoire of schemas that are installed by default for new >> servers. An overview of FedFS can be found here: >> >> http://tools.ietf.org/html/rfc5716 >> >> I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: >> >> http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif > > This gets a 404 for me. > >> This contains the correct IETF boilerplate. The schema is extracted verbatim >> from draft 11. >> >> Addendum: The NSDB draft is in last call, and there have been some changes to >> the schema. I will provide a refresh as soon as the next revision of the draft >> is available. > > From an LDAP perspective I see a few nits that should be cleaned up in this definition. Haven't looked at it from the NFS perspective. > > 4.1 > fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry. > > 4.2.1.1 > I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't believe you should be defining yours as inheriting from "name". > > 4.2.1.2/3 > IMO you should define a URL format instead of distinct address/port attributes. > > 4.2.1.14 > XDR blobs? Really? The point of XDR blobs is that a file server doesn't need to un-marshall then re-marshall the pathname data when it generates a referral. Replacement suggestions welcome. > 4.2.1.18... > Single-bit attributes? You seem to be specifying a particular implementation of a file service. IETF specs should define protocols and data interchange formats, but leave implementation-level details to implementors. > > 4.2.2.2 fedfsFsn > IMO name/port should just be an LDAP URL. Also your definition provides absolutely zero information of how the LDAP server should be contacted (e.g. using ldaps or StartTLS) which both can be encoded in an LDAP URL. It also precludes the use of ldapi:// which might be preferred for an inward-facing/local agent. > > I haven't read the rest of the draft but IMO this is premature for a last call. This draft has been in last call for months, I'm surprised there are so many issues. I think there is still an opportunity for discussion on the working group mailing list. We welcome your comments on nfsv4(a)ietf.org. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

(ITS#7247) smbk5pwd.c: hdb_generate_key_set_password function changes
by quanah＠OpenLDAP.org 16 Apr '12

16 Apr '12

Full_Name: Quanah Gibson-Mount Version: 2.4.28 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From the Debian bug tracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664930 The cause of the problem is that a function declared in a header file in the heimdal package has changed its signature. The old header said: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, Key **/*keys*/, size_t */*num_keys*/); The new version says: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, krb5_key_salt_tuple */*ks_tuple*/, int /*n_ks_tuple*/, Key **/*keys*/, size_t */*num_keys*/);

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

Corrected URL: http://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by hyc＠symas.com 16 Apr '12

16 Apr '12

chuck.lever(a)oracle.com wrote: > Full_Name: Chuck Lever > Version: All > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.26.161.222) > > > I'd like to request the addition of the FedFS schema described in this draft: > > http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 > > as part of the repertoire of schemas that are installed by default for new > servers. An overview of FedFS can be found here: > > http://tools.ietf.org/html/rfc5716 > > I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: > > http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This gets a 404 for me. > This contains the correct IETF boilerplate. The schema is extracted verbatim > from draft 11. > > Addendum: The NSDB draft is in last call, and there have been some changes to > the schema. I will provide a refresh as soon as the next revision of the draft > is available. From an LDAP perspective I see a few nits that should be cleaned up in this definition. Haven't looked at it from the NFS perspective. 4.1 fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry. 4.2.1.1 I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't believe you should be defining yours as inheriting from "name". 4.2.1.2/3 IMO you should define a URL format instead of distinct address/port attributes. 4.2.1.14 XDR blobs? Really? 4.2.1.18... Single-bit attributes? You seem to be specifying a particular implementation of a file service. IETF specs should define protocols and data interchange formats, but leave implementation-level details to implementors. 4.2.2.2 fedfsFsn IMO name/port should just be an LDAP URL. Also your definition provides absolutely zero information of how the LDAP server should be contacted (e.g. using ldaps or StartTLS) which both can be encoded in an LDAP URL. It also precludes the use of ldapi:// which might be preferred for an inward-facing/local agent. I haven't read the rest of the draft but IMO this is premature for a last call. -- -- 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#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030305020403080208020708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable chuck.lever(a)oracle.com wrote: > I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: >=20 > http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This link does not work: HTTP/1.1 404 Not Found > This contains the correct IETF boilerplate. The schema is extracted ve= rbatim > from draft 11. >=20 > Addendum: The NSDB draft is in last call, and there have been some cha= nges to > the schema. I will provide a refresh as soon as the next revision of t= he draft > is available. I really wonder why 'fedfsUuid' is SUP name instead of being based on LDA= P syntax UUID (see RFC 4530). Ciao, Michael. --------------ms030305020403080208020708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxNjE2MzUxN1owIwYJKoZIhvcNAQkEMRYE FJYm4uvB6dO0Xfb+VWGOiUGFmjzuMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAXr+lTSmYWrS1gIcELAxFI1MQ2sMnWAtCIkDhV++q2rtHIxv3FMtGDZMVrpVUUJpmLtfM S8qRyiP23ceohvePmIKviVd+imlCn0wYjTYirg2+BVgjt5NyaA1pT7C5GbjcfF5o7+Fbroy3 5wrk+S+P+EjMqT3XLuvVKeWDYN/5pea8kv0QGnFj2xkkRaNFSX1zwsjAzBRuqcRi8M5/DwIg YvUI2oefNktzAOYxW6LGn0YQxQ+WhJj+BzKbwYViiQsRCZR8h6EHSbUzqMC6DZz3NXMkdp4i dlyR0f00tcfu92e7TINj2c/eCbfLrDEA4YqUwUA2yCsx/D5n3Kp/Ln3ilgAAAAAAAA== --------------ms030305020403080208020708--

1 0

(ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

Full_Name: Chuck Lever Version: All OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.26.161.222) I'd like to request the addition of the FedFS schema described in this draft: http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 as part of the repertoire of schemas that are installed by default for new servers. An overview of FedFS can be found here: http://tools.ietf.org/html/rfc5716 I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This contains the correct IETF boilerplate. The schema is extracted verbatim from draft 11. Addendum: The NSDB draft is in last call, and there have been some changes to the schema. I will provide a refresh as soon as the next revision of the draft is available.

1 0

Re: (ITS#7245) crash when using CSN in cookie
by hyc＠symas.com 16 Apr '12

16 Apr '12

jsoula(a)univ-lille2.fr wrote: > Full_Name: julien soula > Version: 2.4.30 > OS: gentoo/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.254.117.85) > > > hello, > > on a replica, when I use cookie parameter with csn value as : > -c 'rid=101,csn=20120320035618.177820Z#000000#000#000000' > the server crash immediately du to bad free : Thanks for the report, fixed in git master. > > #0 0x00007ffff6ac3a55 in raise () from /lib64/libc.so.6 > #1 0x00007ffff6ac4d55 in abort () from /lib64/libc.so.6 > #2 0x00007ffff6afe972 in ?? () from /lib64/libc.so.6 > #3 0x00007ffff6b03df5 in ?? () from /lib64/libc.so.6 > #4 0x00007ffff6b08d2c in free () from /lib64/libc.so.6 > #5 0x00000000005b78d6 in ber_memfree_x (p=0xd45628, ctx=0x0) at memory.c:152 > #6 0x00000000005b85e4 in ber_bvarray_free_x (a=0xd45660, ctx=0x0) at > memory.c:731 > #7 0x00000000005b8620 in ber_bvarray_free (a=0xd45660) at memory.c:741 > #8 0x00000000004be085 in slap_sync_cookie_free (cookie=0x8f3140, > free_cookie=1) > at ldapsync.c:106 > #9 0x00000000004a3ab1 in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) > at syncrepl.c:675 > #10 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) > at syncrepl.c:1512 > #11 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) > at tpool.c:688 > #12 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 > #13 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 > > After some analyzes, I noticed that the allocation of this block was done with a > not null memory context : > > #0 ber_memalloc_x (s=41, ctx=0xd3ebd0) at memory.c:231 > #1 0x00000000005b7f46 in ber_dupbv_x (dst=0x7fffad9f8350, src=0x7fffad9f8360, > ctx=0xd3ebd0) at memory.c:506 > #2 0x0000000000480ff9 in csnNormalize (usage=2, syntax=0x912160, mr=0x918670, > val=0x7fffad9f8360, normalized=0x7fffad9f8350, ctx=0xd3ebd0) > at schema_init.c:5395 > #3 0x00000000004be94d in slap_parse_sync_cookie (cookie=0x8f3140, > memctx=0xd3ebd0) > at ldapsync.c:342 > #4 0x00000000004a3a6f in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) > at syncrepl.c:671 > #5 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) > at syncrepl.c:1512 > #6 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) > at tpool.c:688 > #7 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 > #8 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 > > but was freed with a null context as seen above. > > If I modify the code to force a null context allocation, it works. > > PS: I shortly took a look at Git code and it seems to be the same. > > Best regards, -- -- 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#7245) crash when using CSN in cookie
by jsoula＠univ-lille2.fr 16 Apr '12

16 Apr '12

Full_Name: julien soula Version: 2.4.30 OS: gentoo/linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.254.117.85) hello, on a replica, when I use cookie parameter with csn value as : -c 'rid=101,csn=20120320035618.177820Z#000000#000#000000' the server crash immediately du to bad free : #0 0x00007ffff6ac3a55 in raise () from /lib64/libc.so.6 #1 0x00007ffff6ac4d55 in abort () from /lib64/libc.so.6 #2 0x00007ffff6afe972 in ?? () from /lib64/libc.so.6 #3 0x00007ffff6b03df5 in ?? () from /lib64/libc.so.6 #4 0x00007ffff6b08d2c in free () from /lib64/libc.so.6 #5 0x00000000005b78d6 in ber_memfree_x (p=0xd45628, ctx=0x0) at memory.c:152 #6 0x00000000005b85e4 in ber_bvarray_free_x (a=0xd45660, ctx=0x0) at memory.c:731 #7 0x00000000005b8620 in ber_bvarray_free (a=0xd45660) at memory.c:741 #8 0x00000000004be085 in slap_sync_cookie_free (cookie=0x8f3140, free_cookie=1) at ldapsync.c:106 #9 0x00000000004a3ab1 in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) at syncrepl.c:675 #10 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) at syncrepl.c:1512 #11 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) at tpool.c:688 #12 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 #13 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 After some analyzes, I noticed that the allocation of this block was done with a not null memory context : #0 ber_memalloc_x (s=41, ctx=0xd3ebd0) at memory.c:231 #1 0x00000000005b7f46 in ber_dupbv_x (dst=0x7fffad9f8350, src=0x7fffad9f8360, ctx=0xd3ebd0) at memory.c:506 #2 0x0000000000480ff9 in csnNormalize (usage=2, syntax=0x912160, mr=0x918670, val=0x7fffad9f8360, normalized=0x7fffad9f8350, ctx=0xd3ebd0) at schema_init.c:5395 #3 0x00000000004be94d in slap_parse_sync_cookie (cookie=0x8f3140, memctx=0xd3ebd0) at ldapsync.c:342 #4 0x00000000004a3a6f in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) at syncrepl.c:671 #5 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) at syncrepl.c:1512 #6 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) at tpool.c:688 #7 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 #8 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 but was freed with a null context as seen above. If I modify the code to force a null context allocation, it works. PS: I shortly took a look at Git code and it seems to be the same. Best regards, -- Julien

1 0

Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by hyc＠symas.com 15 Apr '12

15 Apr '12

napalaniappan(a)paypal.com wrote: > --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Thanks a lot for the information. I have the following configurations, coul= > d you check and help me to fix the NSS config. No. You've been told multiple times that this is not the place to ask these questions. -- -- 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#7243) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠paypal.com 15 Apr '12

15 Apr '12

--_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a lot for the information. I have the following configurations, coul= d you check and help me to fix the NSS config. # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=3Dreturn]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # # nis or yp Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # ldap Use LDAP (only if nss_ldap is installed) # nisplus or nis+ Use NIS+ (NIS version 3), unsupported # [NOTFOUND=3Dreturn] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files ldap nis #shadow: db files ldap nis #group: db files ldap nis passwd: files shadow: files group: files #hosts: db files ldap nis dns hosts: files dns # Example - obey only what ldap tells us... #services: ldap [NOTFOUND=3Dreturn] files #networks: ldap [NOTFOUND=3Dreturn] files #protocols: ldap [NOTFOUND=3Dreturn] files #rpc: ldap [NOTFOUND=3Dreturn] files #ethers: ldap [NOTFOUND=3Dreturn] files bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: files automount: files aliases: files [root@ppdoldap01 etc]# uptime 18:02:10 up 230 days, 10:53, 2 users, load average: 0.95, 0.98, 0.92 [root@ppdoldap01 etc]# more nscd.conf # # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by nscd. # # Legal entries are: # # logfile <file> # debug-level <level> # threads <initial #threads to use> # max-threads <maximum #threads to use> # server-user <user to run server as instead of root> # server-user is ignored if nscd is started with -S parameter= s # stat-user <user who is allowed to request statistics> # reload-count unlimited|<number> # paranoia <yes|no> # restart-interval <time in seconds> # # enable-cache <service> <yes|no> # positive-time-to-live <service> <time in seconds> # negative-time-to-live <service> <time in seconds> # suggested-size <service> <prime number> # check-files <service> <yes|no> # persistent <service> <yes|no> # shared <service> <yes|no> # max-db-size <service> <number bytes> # auto-propagate <service> <yes|no> # # Currently supported cache names (services): passwd, group, hosts # # logfile /var/log/nscd.log # threads 6 # max-threads 128 server-user nscd # stat-user nocpulse debug-level 0 # reload-count 5 paranoia no # restart-interval 3600 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 [etc]# cat libuser.conf # This is a first-generation configuration file. Eventually I'll rewrite # all of the configuration-reading code to use alchemist, but for now this # will have to do. # Do not modify the default module list if you care about unattended calls # to programs (i.e., scripts) working! [defaults] # The default (/usr/lib*/libuser) is usually correct # moduledir =3D /your/custom/directory skeleton =3D /etc/skel mailspooldir =3D /var/mail modules =3D files shadow create_modules =3D files shadow crypt_style =3D md5 # modules =3D files shadow ldap krb5 # create_modules =3D ldap krb5 [userdefaults] LU_USERNAME =3D %n LU_UIDNUMBER =3D 500 LU_GIDNUMBER =3D %u # LU_USERPASSWORD =3D !! # LU_GECOS =3D %n # LU_HOMEDIRECTORY =3D /home/%n # LU_LOGINSHELL =3D /bin/bash # LU_SHADOWNAME =3D %n # LU_SHADOWPASSWORD =3D !! # LU_SHADOWLASTCHANGE =3D %d # LU_SHADOWMIN =3D 0 # LU_SHADOWMAX =3D 99999 # LU_SHADOWWARNING =3D 7 # LU_SHADOWINACTIVE =3D -1 # LU_SHADOWEXPIRE =3D -1 # LU_SHADOWFLAG =3D -1 [groupdefaults] LU_GROUPNAME =3D %n LU_GIDNUMBER =3D 500 # LU_GROUPPASSWORD =3D !! # LU_MEMBERUID =3D # LU_ADMINISTRATORUID =3D [files] # This is useful for the case where some master files are used to # populate a different NSS mechanism which this workstation uses. # directory =3D /etc [shadow] # This is useful for the case where some master files are used to # populate a different NSS mechanism which this workstation uses. # directory =3D /etc [ldap] # Setting these is always necessary. # server =3D ldap # basedn =3D dc=3Dexample,dc=3Dcom # Setting these is rarely necessary, since it's usually correct. # userBranch =3D ou=3DPeople # groupBranch =3D ou=3DGroup # Set only if your administrative user uses simple bind operations to # connect to the server. # binddn =3D cn=3DManager,dc=3Dexample,dc=3Dcom # Set this only if the default user (as determined by SASL) is incorrect # for SASL bind operations. Usually, it's correct, so you'll rarely need # to set these. # user =3D Manager # authuser =3D Manager [krb5] # Set this only if it differs from the default in /etc/krb5.conf. # realm =3D EXAMPLE.COM # Set this only if the default (currentuser/admin) will be incorrect. # principal =3D example/admin(a)EXAMPLE.COM [sasl] # Set these only if your sasldb is only used by a particular application, a= nd # in a particular domain. The default (all applications, all domains) is # probably correct for most installations. # appname =3D imap # domain =3D EXAMPLE.COM -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Friday, April 13, 2012 11:22 PM To: VEERASWAMY PALANIAPPAN, NATARRAJAN(VPN) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file! > Full_Name: Natarrajan > Version: 2.2.13-7.4E > OS: RHEL4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.113.168.128) > > > I am getting the following error frequently in my ldap client machine. > > LDAPCLIENT ~> whoami > whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv > ls > sudo: uid 14281 does not exist in the passwd file! > > Let me know the fix for the issue. Upgrade (2.2.13 is about 10 years old now; 2.4.30 is the current release). Then, fix the configuration of your nss? p. --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ 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-micr= osoft-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=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Thanks a lot for the information. I have the foll= owing configurations, could you check and help me to fix the NSS config.<o:= p></o:p> <o:p> </o:p> # /etc/nsswitch.conf<o:p></o:p> #<o:p></o:p> # An example Name Service Switch config file. Thi= s file should be<o:p></o:p> # sorted with the most-used services at the begin= ning.<o:p></o:p> #<o:p></o:p> # The entry '[NOTFOUND=3Dreturn]' means that the = search for an<o:p></o:p> # entry should stop if the search in the previous= entry turned<o:p></o:p> # up nothing. Note that if the search failed due = to some other reason<o:p></o:p> # (like no NIS server responding) then the search= continues with the<o:p></o:p> # next entry.<o:p></o:p> #<o:p></o:p> # Legal entries are:<o:p></o:p> #<o:p></o:p> #       nis or yp&n= bsp;           &nbsp= ;  Use NIS (NIS version 2), also called YP<o:p></o:p> #       dns  &= nbsp;           &nbs= p;      Use DNS (Domain Name Service)<o:p></o= :p> #       files =             &nb= sp;     Use the local files<o:p></o:p> #       db &nb= sp;            =         Use the local database (.db) fil= es<o:p></o:p> #       compat&nbsp= ;            &n= bsp;    Use NIS on compat mode<o:p></o:p> #       hesiod&nbsp= ;            &n= bsp;    Use Hesiod for user lookups<o:p></o:p> #       ldap &= nbsp;           &nbs= p;      Use LDAP (only if nss_ldap is installed)<o= :p></o:p> #       nisplus or = nis+         Use NIS+ (NIS = version 3), unsupported<o:p></o:p> #       [NOTFOUND= =3Dreturn]       Stop searching if not found = so far<o:p></o:p> #<o:p></o:p> <o:p> </o:p> # To use db, put the "db" in front of &= quot;files" for entries you want to be<o:p></o:p> # looked up first in the databases<o:p></o:p> #<o:p></o:p> # Example:<o:p></o:p> #passwd:    db files ldap nis<o:p>= </o:p> #shadow:    db files ldap nis<o:p>= </o:p> #group:     db files ldap nis= <o:p></o:p> <o:p> </o:p> passwd:     files<o:p></o:p><= /p> shadow:     files<o:p></o:p><= /p> group:      files<o:p></= o:p> <o:p> </o:p> #hosts:     db files ldap nis= dns<o:p></o:p> hosts:      files dns<o:= p></o:p> <o:p> </o:p> # Example - obey only what ldap tells us...<o:p><= /o:p> #services:  ldap [NOTFOUND=3Dreturn] files<o= :p></o:p> #networks:  ldap [NOTFOUND=3Dreturn] files<o= :p></o:p> #protocols: ldap [NOTFOUND=3Dreturn] files<o:p></= o:p> #rpc:       ldap [N= OTFOUND=3Dreturn] files<o:p></o:p> #ethers:    ldap [NOTFOUND=3Dretur= n] files<o:p></o:p> <o:p> </o:p> bootparams: files<o:p></o:p> ethers:     files<o:p></o:p><= /p> netmasks:   files<o:p></o:p> networks:   files<o:p></o:p> protocols:  files<o:p></o:p> rpc:        fi= les<o:p></o:p> services:   files<o:p></o:p> netgroup:   files<o:p></o:p> publickey:  files<o:p></o:p> automount:  files<o:p></o:p> aliases:    files<o:p></o:p> [root@ppdoldap01 etc]# uptime<o:p></o:p> 18:02:10 up 230 days, 10:53,  2 users, = load average: 0.95, 0.98, 0.92<o:p></o:p> [root@ppdoldap01 etc]# more nscd.conf<o:p></o:p><= /p> #<o:p></o:p> # /etc/nscd.conf<o:p></o:p> #<o:p></o:p> # An example Name Service Cache config file.&nbsp= ; This file is needed by nscd.<o:p></o:p> #<o:p></o:p> # Legal entries are:<o:p></o:p> #<o:p></o:p> #       logfile&nbs= p;            &= nbsp;   <file><o:p></o:p> #       debug-level=              &l= t;level><o:p></o:p> #       threads&nbs= p;            &= nbsp;   <initial #threads to use><o:p></o:p> #       max-threads=              &l= t;maximum #threads to use><o:p></o:p> #       server-user=              &l= t;user to run server as instead of root><o:p></o:p> #        =        server-user is ignored if nscd is star= ted with -S parameters<o:p></o:p> #       stat-user&n= bsp;           &nbsp= ;  <user who is allowed to request statistics><o:p></o:p> #       reload-coun= t            unlimit= ed|<number><o:p></o:p> #       paranoia&nb= sp;            &nbsp= ;  <yes|no><o:p></o:p> #       restart-int= erval        <time in seconds><o:p= ></o:p> #<o:p></o:p> #       enable-cach= e            <ser= vice> <yes|no><o:p></o:p> #       positive-ti= me-to-live   <service> <time in seconds><o:p></o:p></= p> #       negative-ti= me-to-live   <service> <time in seconds><o:p></o:p></= p> #       suggested-s= ize          <service> &= lt;prime number><o:p></o:p> #       check-files=              &l= t;service> <yes|no><o:p></o:p> #       persistent&= nbsp;           &nbs= p; <service> <yes|no><o:p></o:p> #       shared&nbsp= ;            &n= bsp;    <service> <yes|no><o:p></o:p> #       max-db-size=              &l= t;service> <number bytes><o:p></o:p> #       auto-propag= ate          <service> &= lt;yes|no><o:p></o:p> #<o:p></o:p> # Currently supported cache names (services): pas= swd, group, hosts<o:p></o:p> #<o:p></o:p> <o:p> </o:p> <o:p> </o:p> #       logfile&nbs= p;            &= nbsp;   /var/log/nscd.log<o:p></o:p> #       threads&nbs= p;            &= nbsp;   6<o:p></o:p> #       max-threads=              12= 8<o:p></o:p>        server-= user           &nbsp= ; nscd<o:p></o:p> #       stat-user&n= bsp;           &nbsp= ;  nocpulse<o:p></o:p>         debug-= level           &nbs= p; 0<o:p></o:p> #       reload-coun= t            5<o:p><= /o:p>         parano= ia            &= nbsp;   no<o:p></o:p> #       restart-int= erval        3600<o:p></o:p> <o:p> </o:p>         enable= -cache            pa= sswd          yes<o:p></o:p></= p>         positi= ve-time-to-live   passwd      &nbsp= ;   600<o:p></o:p>         negati= ve-time-to-live   passwd      &nbsp= ;   20<o:p></o:p>         sugges= ted-size          passwd =          211<o:p></o:p>         check-= files           &nbs= p; passwd          yes<o:p></o= :p>         persis= tent           &nbsp= ;  passwd          yes<o:= p></o:p>         shared=             &nb= sp;     passwd      &nbsp= ;   yes<o:p></o:p>         max-db= -size           &nbs= p; passwd          33554432<o:= p></o:p>         auto-p= ropagate          passwd =          yes<o:p></o:p> <o:p> </o:p>         enable= -cache            gr= oup           yes<o:p></o= :p>         positi= ve-time-to-live   group       =     3600<o:p></o:p>         negati= ve-time-to-live   group       =     60<o:p></o:p>         sugges= ted-size          group &= nbsp;         211<o:p></o:p>         check-= files           &nbs= p; group           yes<o:= p></o:p>         persis= tent           &nbsp= ;  group           y= es<o:p></o:p>         shared=             &nb= sp;     group       =     yes<o:p></o:p>         max-db= -size           &nbs= p; group           335544= 32<o:p></o:p>         auto-p= ropagate          group &= nbsp;         yes<o:p></o:p> <o:p> </o:p>         enable= -cache            ho= sts           yes<o:p></o= :p>         positi= ve-time-to-live   hosts       &nbsp= ;   3600<o:p></o:p>         negati= ve-time-to-live   hosts       =     20<o:p></o:p>         sugges= ted-size          hosts &= nbsp;         211<o:p></o:p>         check-= files           &nbs= p; hosts           yes<o:= p></o:p>         persis= tent           &nbsp= ;  hosts           y= es<o:p></o:p>         shared=             &nb= sp;     hosts       =     yes<o:p></o:p>         max-db= -size           &nbs= p; hosts           335544= 32<o:p></o:p> <o:p> </o:p> [etc]# cat libuser.conf<o:p></o:p> # This is a first-generation configuration file.&= nbsp; Eventually I'll rewrite<o:p></o:p> # all of the configuration-reading code to use al= chemist, but for now this<o:p></o:p> # will have to do.<o:p></o:p> <o:p> </o:p> # Do not modify the default module list if you ca= re about unattended calls<o:p></o:p> # to programs (i.e., scripts) working!<o:p></o:p>= <o:p> </o:p> [defaults]<o:p></o:p> # The default (/usr/lib*/libuser) is usually corr= ect<o:p></o:p> # moduledir =3D /your/custom/directory<o:p></o:p>= skeleton =3D /etc/skel<o:p></o:p> mailspooldir =3D /var/mail<o:p></o:p> modules =3D files shadow<o:p></o:p> create_modules =3D files shadow<o:p></o:p> crypt_style =3D md5<o:p></o:p> # modules =3D files shadow ldap krb5<o:p></o:p></= p> # create_modules =3D ldap krb5<o:p></o:p> <o:p> </o:p> [userdefaults]<o:p></o:p> LU_USERNAME =3D %n<o:p></o:p> LU_UIDNUMBER =3D 500<o:p></o:p> LU_GIDNUMBER =3D %u<o:p></o:p> # LU_USERPASSWORD =3D !!<o:p></o:p> # LU_GECOS =3D %n<o:p></o:p> # LU_HOMEDIRECTORY =3D /home/%n<o:p></o:p> # LU_LOGINSHELL =3D /bin/bash<o:p></o:p> <o:p> </o:p> # LU_SHADOWNAME =3D %n<o:p></o:p> # LU_SHADOWPASSWORD =3D !!<o:p></o:p> # LU_SHADOWLASTCHANGE =3D %d<o:p></o:p> # LU_SHADOWMIN =3D 0<o:p></o:p> # LU_SHADOWMAX =3D 99999<o:p></o:p> # LU_SHADOWWARNING =3D 7<o:p></o:p> # LU_SHADOWINACTIVE =3D -1<o:p></o:p> # LU_SHADOWEXPIRE =3D -1<o:p></o:p> # LU_SHADOWFLAG =3D -1<o:p></o:p> <o:p> </o:p> [groupdefaults]<o:p></o:p> LU_GROUPNAME =3D %n<o:p></o:p> LU_GIDNUMBER =3D 500<o:p></o:p> # LU_GROUPPASSWORD =3D !!<o:p></o:p> # LU_MEMBERUID =3D<o:p></o:p> # LU_ADMINISTRATORUID =3D<o:p></o:p> <o:p> </o:p> [files]<o:p></o:p> # This is useful for the case where some master f= iles are used to<o:p></o:p> # populate a different NSS mechanism which this w= orkstation uses.<o:p></o:p> # directory =3D /etc<o:p></o:p> <o:p> </o:p> [shadow]<o:p></o:p> # This is useful for the case where some master f= iles are used to<o:p></o:p> # populate a different NSS mechanism which this w= orkstation uses.<o:p></o:p> # directory =3D /etc<o:p></o:p> <o:p> </o:p> [ldap]<o:p></o:p> # Setting these is always necessary.<o:p></o:p></= p> # server =3D ldap<o:p></o:p> # basedn =3D dc=3Dexample,dc=3Dcom<o:p></o:p> <o:p> </o:p> # Setting these is rarely necessary, since it's u= sually correct.<o:p></o:p> # userBranch =3D ou=3DPeople<o:p></o:p> # groupBranch =3D ou=3DGroup<o:p></o:p> <o:p> </o:p> # Set only if your administrative user uses simpl= e bind operations to<o:p></o:p> # connect to the server.<o:p></o:p> # binddn =3D cn=3DManager,dc=3Dexample,dc=3Dcom<o= :p></o:p> <o:p> </o:p> # Set this only if the default user (as determine= d by SASL) is incorrect<o:p></o:p> # for SASL bind operations.  Usually, it's c= orrect, so you'll rarely need<o:p></o:p> # to set these.<o:p></o:p> # user =3D Manager<o:p></o:p> # authuser =3D Manager<o:p></o:p> <o:p> </o:p> [krb5]<o:p></o:p> # Set this only if it differs from the default in= /etc/krb5.conf.<o:p></o:p> # realm =3D EXAMPLE.COM<o:p></o:p> # Set this only if the default (currentuser/admin= ) will be incorrect.<o:p></o:p> # principal =3D example/admin(a)EXAMPLE.COM<o:p></o= :p> <o:p> </o:p> [sasl]<o:p></o:p> # Set these only if your sasldb is only used by a= particular application, and<o:p></o:p> # in a particular domain.  The default (all = applications, all domains) is<o:p></o:p> # probably correct for most installations.<o:p></= o:p> # appname =3D imap<o:p></o:p> # domain =3D EXAMPLE.COM<o:p></o:p> <o:p> </o:p> -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Friday, April 13, 2012 11:22 PM To: VEERASWAMY PALANIAPPAN, NATARRAJAN(VPN) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!<= /p> <o:p> </o:p> > Full_Name: Natarrajan<o:p></o:p> > Version: 2.2.13-7.4E<o:p></o:p> > OS: RHEL4.5<o:p></o:p> > URL: <a href=3D"ftp://ftp.openldap.org/incom= ing/">ftp://ftp.openl= dap.org/incoming/</a><o:p></o:p> > Submission from: (NULL) (216.113.168.128)<o:= p></o:p> ><o:p> </o:p> ><o:p> </o:p> > I am getting the following error frequently = in my ldap client machine.<o:p></o:p> ><o:p> </o:p> > LDAPCLIENT ~> whoami<o:p></o:p> > whoami: cannot find name for user ID 14281 L= DAPCLIENT ~> sudo -u qserv <o:p></o:p> > ls<o:p></o:p> > sudo: uid 14281 does not exist in the passwd= file!<o:p></o:p> ><o:p> </o:p> > Let me know the fix for the issue.<o:p></o:p= > <o:p> </o:p> Upgrade (2.2.13 is about 10 years old now; 2.4.30= is the current release).<o:p></o:p> Then, fix the configuration of your nss?<o:p></o:= p> <o:p> </o:p> p.<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_--

1 0

Re: (ITS#7229) still not fixed
by michael＠stroeder.com 14 Apr '12

14 Apr '12

hyc(a)symas.com wrote: > Your problem is completely unrelated to ITS#7229, which was about an ENOSPC > error. You're getting ENOMEM, which simply means you've exceeded the > configured size of the DB. Yes, forgot setting maxsize. Sorry. Ciao, Michael.

1 0

Re: (ITS#7229) still not fixed
by hyc＠symas.com 14 Apr '12

14 Apr '12

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms000002080400040504030402 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > HI! > > I'm testing with RE24 (39fb7afe5f5acb48686a41a11ef57aa72a772626) on openS= > USE > 11.4 x86_64 but I'm still getting this error when loading an accesslog DB= > =2E It > is not fixed yet. > > slapadd: could not add entry dn=3D"reqStart=3D20110131134340.000002Z,cn=3D= > accesslog" > (line=3D270877): txn_aborted! Internal error (80) > 4f897bb9 mdb_id2entry_put: mdb_put failed: Cannot allocate memory(12) > "reqStart=3D20110201074944.000001Z,cn=3Daccesslog" Your problem is completely unrelated to ITS#7229, which was about an ENOSPC error. You're getting ENOMEM, which simply means you've exceeded the configured size of the DB. > The problem is that adding most entries does work but the error happens > occasionally no matter whether -q is used or not. > > Ciao, Michael. -- -- 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#7229) still not fixed
by michael＠stroeder.com 14 Apr '12

14 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000002080400040504030402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI! I'm testing with RE24 (39fb7afe5f5acb48686a41a11ef57aa72a772626) on openS= USE 11.4 x86_64 but I'm still getting this error when loading an accesslog DB= =2E It is not fixed yet. slapadd: could not add entry dn=3D"reqStart=3D20110131134340.000002Z,cn=3D= accesslog" (line=3D270877): txn_aborted! Internal error (80) 4f897bb9 mdb_id2entry_put: mdb_put failed: Cannot allocate memory(12) "reqStart=3D20110201074944.000001Z,cn=3Daccesslog" The problem is that adding most entries does work but the error happens occasionally no matter whether -q is used or not. Ciao, Michael. --------------ms000002080400040504030402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxNDEzMzgyOVowIwYJKoZIhvcNAQkEMRYE FKKKmWqR32lsW+TjX16Hc69krw+dMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAbbQYCiOcoNfziXvc8fZxpKVoCT37MQv9Se72yCki6aW7JscIVueaH82mYczG5sba6V94 ayQiMhLeGq+LTlqpN9ZacEm1/SgN8Nfh9NU70F564Zw34YZ78PPVpodxy8e/IB4EX6sV3vaq XGNObPCBUKhMrXIvJ4nmjgzDbDcH9gTxY3WxHfU3JQlzI89s3bwVNVLmb5ET1XEi+3kAbrik CdjO0ysc9abDarLzp9jKkElzVb1Tb3xRygFEyLtPmqfQMktHIhIqUlWkbo3+w9WpoH0obHLd UV9k3F3A7EYSeYVvA9N5mcNcTyDt4SKybNIT9rbMxQzv44DCfJ12MUHXyQAAAAAAAA== --------------ms000002080400040504030402--

1 0

Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by masarati＠aero.polimi.it 14 Apr '12

14 Apr '12

> Full_Name: Natarrajan > Version: 2.2.13-7.4E > OS: RHEL4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.113.168.128) > > > I am getting the following error frequently in my ldap client machine. > > LDAPCLIENT ~> whoami > whoami: cannot find name for user ID 14281 > LDAPCLIENT ~> sudo -u qserv ls > sudo: uid 14281 does not exist in the passwd file! > > Let me know the fix for the issue. Upgrade (2.2.13 is about 10 years old now; 2.4.30 is the current release). Then, fix the configuration of your nss? p.

1 0

(ITS#7244) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠yahoo.com 14 Apr '12

14 Apr '12

Full_Name: Natarrajan Version: 2.2.13-7.4E OS: RHEL4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.113.168.128) I am getting the following error frequently in my ldap client machine. LDAPCLIENT ~> whoami whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv ls sudo: uid 14281 does not exist in the passwd file! Let me know the fix for the issue. Thanks,

1 0

(ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠paypal.com 14 Apr '12

14 Apr '12

Full_Name: Natarrajan Version: 2.2.13-7.4E OS: RHEL4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.113.168.128) I am getting the following error frequently in my ldap client machine. LDAPCLIENT ~> whoami whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv ls sudo: uid 14281 does not exist in the passwd file! Let me know the fix for the issue. Thanks,

1 0

Re: (ITS#7242) new -y (Read password from file) does not work
by chris.paul＠rexconsulting.net 13 Apr '12

13 Apr '12

Oh duh. I see now. Thanks! CP On Apr 13, 2012, at 13:59, masarati(a)aero.polimi.it wrote: >> Full_Name: Chris Paul >> Version: ldapsearch 2.4.23 (Dec 7 2011 21:37:03) >> OS: tried both Centos 2.6.32-220.el6.i686 and Cygwin >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (162.119.68.25) >> >> >> I really like the new -y option to read the password from a file but it >> doesn't >> work. Also it broke the old behavior which read it from standard input if >> you >> used -W. >> >> I have a one line password file. I used to use this successfully with a >> command >> like: >> >> $ ldapsearch -x -H $TIM -s sub -b "dc=myorg, dc=org" "(uid=someuid)" uid >> cn < >> ~/.ldappw >> >> Now this command just prompts me for the password. >> >> And when I try -y, it seems that an 0x0a character is added to the >> password >> string (I found this by using tcpdump to capture the packets), so that >> fails >> with "Invalid credentials (49)". > > This is a common user error. The "0x0a" is a newline ('\n') which is > probably present in your file. You need to create a file that contains > exactly the password. For example, to create a file that contains the > password "secret" you need to do > > echo -n "secret" > filename. > > This ITS will be closed. > > p. >

1 0

Re: (ITS#7242) new -y (Read password from file) does not work
by masarati＠aero.polimi.it 13 Apr '12

13 Apr '12

> Full_Name: Chris Paul > Version: ldapsearch 2.4.23 (Dec 7 2011 21:37:03) > OS: tried both Centos 2.6.32-220.el6.i686 and Cygwin > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (162.119.68.25) > > > I really like the new -y option to read the password from a file but it > doesn't > work. Also it broke the old behavior which read it from standard input if > you > used -W. > > I have a one line password file. I used to use this successfully with a > command > like: > > $ ldapsearch -x -H $TIM -s sub -b "dc=myorg, dc=org" "(uid=someuid)" uid > cn < > ~/.ldappw > > Now this command just prompts me for the password. > > And when I try -y, it seems that an 0x0a character is added to the > password > string (I found this by using tcpdump to capture the packets), so that > fails > with "Invalid credentials (49)". This is a common user error. The "0x0a" is a newline ('\n') which is probably present in your file. You need to create a file that contains exactly the password. For example, to create a file that contains the password "secret" you need to do echo -n "secret" > filename. This ITS will be closed. p.

1 0

(ITS#7242) new -y (Read password from file) does not work
by chris.paul＠rexconsulting.net 13 Apr '12

13 Apr '12

Full_Name: Chris Paul Version: ldapsearch 2.4.23 (Dec 7 2011 21:37:03) OS: tried both Centos 2.6.32-220.el6.i686 and Cygwin URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (162.119.68.25) I really like the new -y option to read the password from a file but it doesn't work. Also it broke the old behavior which read it from standard input if you used -W. I have a one line password file. I used to use this successfully with a command like: $ ldapsearch -x -H $TIM -s sub -b "dc=myorg, dc=org" "(uid=someuid)" uid cn < ~/.ldappw Now this command just prompts me for the password. And when I try -y, it seems that an 0x0a character is added to the password string (I found this by using tcpdump to capture the packets), so that fails with "Invalid credentials (49)".

1 0

Re: (ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 13 Apr '12

13 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2012 11:11 AM, ondrej.kuznik(a)acision.com wrote: > For slapmodify to be usable on a database, that database needs to > implement the bi_tool_dn2id_get and bi_tool_entry_modify > functions, which is not the case of the back-config. I've put > together a minimal (and maybe too naive) implementation of these > for back-config and back-ldif at the above link. Ok, nevermind for now, the implementation was too naive and would break some other things (the slapadd in test005). - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IMUkACgkQ9GWxeeH+cXtodQCeJdq8IQvH+hWEYTTMt3hn+6UC K20An0uaLb/lmDo6zBJtHm3RL9FMXezq =xnVE -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Re: (ITS#7088) slapo-accesslog makes OpenLDAP hang
by Pierangelo Masarati 12 Apr '12

12 Apr '12

> The root cause of this bug seems to be related to olcAccessLogOps and > olcAccessLogBase features. If I use one of them to specify I want to log > only "modify" operations: > olcAccessLogOps: modify > or > olcAccessLogBase: modify <suffix> > > Then when I do an "add", slapo-accesslog takes the op_rmutex in > accesslog_op_mod but never release it in accesslog_response. The analysis looks correct. slapo-accesslog(5) was locking the mutex for all write operations, but only releasing it for those that needed to be logged. Should be fixed now in master. Please test. Thanks, p.

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 12 Apr '12

12 Apr '12

> ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7241) [PATCH] unbind: free the socket prior to destroying TLS context
by jvcelak＠redhat.com 12 Apr '12

12 Apr '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-unbind-free-socket-prior-to-… Submission from: (NULL) (209.132.186.34) Hello. I'm proposing uploaded patch which moves ber_sockbuf_free() prior to ldap_int_tls_destroy() in ldap_ld_free(). I sent the reasoning on the openldap-devel list: http://www.openldap.org/lists/openldap-devel/201204/msg00003.html And there is an answer from Howard: http://www.openldap.org/lists/openldap-devel/201204/msg00004.html Please, consider its inclusion. Jan The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs