openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

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

16 Apr '12

Howard Chu wrote: > 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. I did not want to endorse the use of host/port. I just wanted to point out that one cannot specify the use of StartTLS by LDAP URL in a standard way. Of course nothing prevents somebody to add custom extension to LDAP URLs. Ciao, Michael.

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs