openldap-bugs April 2012

openldap-bugs@openldap.org

36 participants
172 discussions

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 14 Apr '12

14 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 14 Apr '12

14 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

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2012