Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com
On Oct 7, 2012, at 11:04 AM, Michael Ströder wrote:
> chuck.lever(a)oracle.com wrote:
>> It appears that the schema LDIF files shipped with OpenLDAP are strictly
>> for basic LDAP attribute type and object class definitions. Everything
>> else is considered a "user schema," including schemas for implementing a
>> DNS or NIS backend, and so on. It appears to me that FedFS would fall into
>> this latter category, and thus should not be included in the packaged
>> schema.
>
> There are various schema files shipped with OpenLDAP source. In opposite to
> other LDAP servers not all schema files are enabled by default.
I see.
> But it seems to me that
>
> https://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif
>
> does not contain exactly the same schema elements like defined in
>
> http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-13
The oss.oracle.com fedfs-utils home page has been deprecated, and will go away soon. That site contains an outdated version of the NSDB schema.
Since then, we have attempted to address comments received from openldap-technical. The version defined in the current IETF NSDB protocol draft, which you link to above, is the authoritative version. We may see one or two more revisions as the draft goes through the final IESG review process.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
10 years, 11 months
Re: (ITS#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms060706000603000508050902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
chuck.lever(a)oracle.com wrote:
> It appears that the schema LDIF files shipped with OpenLDAP are strictl=
y
> for basic LDAP attribute type and object class definitions. Everything=
> else is considered a "user schema," including schemas for implementing =
a
> DNS or NIS backend, and so on. It appears to me that FedFS would fall =
into
> this latter category, and thus should not be included in the packaged
> schema.
There are various schema files shipped with OpenLDAP source. In opposite =
to
other LDAP servers not all schema files are enabled by default.
But it seems to me that
https://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif
does not contain exactly the same schema elements like defined in
http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-13
Ciao, Michael.
--------------ms060706000603000508050902
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC
BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG
EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM
MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF
MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M
VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K
b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/
kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB
1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC
EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0
Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw
QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1
c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/
BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3
LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2
KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj
Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M
MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK
KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR
GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4
B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ
FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx
QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw
ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF
MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl
ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ
MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV
BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz
IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt
5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z
5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH
hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1
3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst
smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB
BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv
dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p
dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ
dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB
MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E
gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k
ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy
MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/
Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE
m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV
0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz
UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9
ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X
iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx
CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU
QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD
bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA3MTUwNDU1WjAjBgkq
hkiG9w0BCQQxFgQUn45Ie943claWxEltvXj9KkPQ5CIwbAYJKoZIhvcNAQkPMV8wXTALBglg
hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP
MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL
ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl
ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS
oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD
VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl
bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE
ggEASdFJWmwg6o8+45+N2/K5j5/Bgop65wO2Xs8wL0f8XYBT1IlCgm2B78w4xEX/eKLYXae8
jiZ4+iYuWevD5uaufqzc0abNhObQGfcGxo2zU2IqmcnxRdKjSavb+E99V/I2X96j9CA4W5b6
lajdyuGxcomdEgMQv1BGXukfLQptvdXgwiUyxd21f5s/n46CCQy5VvkFBd1CZRxwYWl0pmdi
QeHSAJ6qFZgwFSRUctt1SxcqpmleKx9muf96Cy44XJhy7E4g4VJ5VKjf4MVERKL0CFTEPNkd
bURQx7kYJaR01rNuRmkP7eOb/9+2c4qn40enb7qGH0pDke+mZupHPmyysQAAAAAAAA==
--------------ms060706000603000508050902--
10 years, 11 months
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org
On 10/05/2012 02:12 PM, quanah(a)zimbra.com wrote:
> --On Friday, October 05, 2012 2:11 AM +0000 richm(a)stanfordalumni.org wrote:
>
>>> Certainly, here's a recent example:
>>> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
>> I guess I missed it, but exactly which OpenLDAP release(s) had the fix
>> for this particular problem? That is, how could Red Hat have avoided
>> this problem by rebasing to a later OpenLDAP?
> My guess is it was fixed in 2.4.26 or 2.4.27. There have been numerous
> fixes to cn=config support since 2.4.23, so it is hard to know specifically
> which one fixes the above issue. ;)
I've gone through the entire thread again. I still don't know
1) what caused the hanging problem with slaptest
2) if upgrading to 2.4.32 fixed the problem
https://www.openldap.org/lists/openldap-technical/201210/msg00024.html
"
# slaptest -v -d 448 -f ./slapd.conf.new -F /etc/openldap/slapd.d
The last step just hangs and does not do anything even after waiting 45
minutes.
"
Do you know if there was a specific hanging problem with slaptest used
to convert slapd.conf to slapd.d in 2.4.1-2.4.23 that would have been
fixed by rebasing to 2.4.26-2.4.27? How can you be sure that upgrading
to 2.4.32 will fix the problem that this guy was having? No one asked
him to use gdb to attach to the process to see what was going on. No
one asked him to provide the log output of the -d 448 log level. Is it
possible that his issue was unrelated to the version of openldap he was
using? I guess we'll never know.
I've looked through the list of changes at
http://www.openldap.org/software/release/changes.html
I do see several fixes for cn=config/slapd.d issues in 2.4.24 and
later. But I don't see any that look like they have something to do
with hanging.
I would still like to know a specific problem in Red Hat's OpenLDAP,
that has been reported by a customer/user, that would have been avoided
by rebasing. It would be a good data point to present to management to
say "we could have avoided all of these customer problems by rebasing
instead of cherry picking patches".
>
>>> I will note that Mandriva, at least, continually updates the version
>>> of OpenLDAP they ship, unlike most distributions, so it definitely
>>> isn't all. And my point is, Red Hat could do better, and I'd like to
>>> see them do better. I'd like to see Debian/Ubuntu do better too.
>>> I.e., this isn't specific to Red Hat, but the discussion here is about
>>> Red Hat, and what it can do. I discuss Debian and what it can do
>>> better with the Debian devs on their openldap dev list.
>> Then I'd like to hear what Jan and the other Red Hat OpenLDAP
>> maintainers have to say.
> Ok. One thing I do with Debian is help triage issues that are reported
> there with the upstream ITS system if the issues do not appear to be due to
> the usage of an old version. If there is a simple way to do that with Red
> Hat, I could help there as well.
Here is the current RHEL 6 openldap bug list -
https://bugzilla.redhat.com/buglist.cgi?list_id=641623&classification=Red...
Here is the current Fedora openldap bug list -
https://bugzilla.redhat.com/buglist.cgi?list_id=641625&classification=Fed...
If you have a bugzilla account, you can simply add the link to the ITS
as a comment in the bugzilla bug. That would be most appreciated. Thanks!
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
10 years, 11 months
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com
--On Friday, October 05, 2012 2:11 AM +0000 richm(a)stanfordalumni.org wrote:
>> Certainly, here's a recent example:
>> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
>
> I guess I missed it, but exactly which OpenLDAP release(s) had the fix
> for this particular problem? That is, how could Red Hat have avoided
> this problem by rebasing to a later OpenLDAP?
My guess is it was fixed in 2.4.26 or 2.4.27. There have been numerous
fixes to cn=config support since 2.4.23, so it is hard to know specifically
which one fixes the above issue. ;)
>> I will note that Mandriva, at least, continually updates the version
>> of OpenLDAP they ship, unlike most distributions, so it definitely
>> isn't all. And my point is, Red Hat could do better, and I'd like to
>> see them do better. I'd like to see Debian/Ubuntu do better too.
>> I.e., this isn't specific to Red Hat, but the discussion here is about
>> Red Hat, and what it can do. I discuss Debian and what it can do
>> better with the Debian devs on their openldap dev list.
>
> Then I'd like to hear what Jan and the other Red Hat OpenLDAP
> maintainers have to say.
Ok. One thing I do with Debian is help triage issues that are reported
there with the upstream ITS system if the issues do not appear to be due to
the usage of an old version. If there is a simple way to do that with Red
Hat, I could help there as well.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 11 months
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org
On 10/04/2012 06:07 PM, Quanah Gibson-Mount wrote:
> --On Thursday, October 04, 2012 11:29 PM +0000
> richm(a)stanfordalumni.org wrote:
>
>> If a customer reports such a problem, Red Hat will respond.
>
> Again, reactive rather than proactive.
Red Hat is not entirely reactive.
>
>>> There have been approximately 450 committed fixes to RE24 since 2.4.23
>>> was released. So you have about 5% of the fixes in your build. That
>>> is just so very encouraging to hear, isn't it? As a customer,
>>> wouldn't you truly feel that Red Hat was doing its best for you, but
>>> grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair
>>> number of those patches you have actually have zero to do with
>>> OpenLDAP itself, but with MozNSS... So we're down to what? 3%?
>>
>> If you will concede the point that quantity != quality, then so will I.
>
> Certainly, but a fair number of those commits are actual bug fixes.
> 2.4.23 in particular had some significant issues.
>
>> So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new
>> features or regressions, ever?
>
> We have introduced new features, sure. MDB and delta-syncrepl for MMR
> would be examples. But they don't impact existing functionality.
Famous last words.
> And certainly can be the case that regressions are introduced. I'm
> not saying to immediately upgrade to the latest OpenLDAP release every
> time it comes out. One has to have some common sense about it.
> However, it has been over 2 years since 2.4.23 was released. Many
> significant and real issues have been fixed since that 2.4.23 was
> done, with numerous fixes in the syncrepl area and the cn=config DB,
> which Red Hat deploys on RHEL6.
Ok. Fair enough. This then gets to the point about whether the Red Hat
OpenLDAP maintainers would be willing and able to do this.
>
>> If this is really the case, then why would Debian or any other
>> distribution not want to rebase every time OpenLDAP has a 2.4.x+1
>> release? The FAQ says ". . . upgrading to newer versions is often
>> desireable but also means introducing change into stable releases, which
>> is exactly opposite to the point of release stability". So it's ok for
>> Debian to take a hard line for release stability, but not Red Hat? Or
>> is your problem really that Red Hat doesn't openly proclaim that the
>> OpenLDAP server included with the distribution is not for "a large site,
>> a complicated installation" or the like? So if Red Hat were to provide
>> such a disclaimer, it would be ok for Red Hat to take a hard line for
>> release stability?
>
> Debian provides a backports channel that allows its users to update to
> later releases. And no, I don't find Debian's hard line any more
> acceptable, but at least they provide a supported solution. Red Hat
> doesn't provide any supported alternative.
Ok. This is feasible. I know that Red Hat has done things like this in
the past. This is something that could be done.
>
>> So what's the difference between Debian and Red Hat with respect to
>> OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not
>> Debian stable? I suppose the same thing applies to Red Hat - if a Red
>> Hat customer has "a large site, a complicated installation, or problems
>> for which [they] need to seek help here", they will probably be willing
>> to pay extra for extra attention, in the form of adding additional
>> resources to build and maintain OpenLDAP themselves, or hiring a firm
>> like Symas.
>
> If you think I don't bash Debian, then you haven't been paying
> attention. ;) In any case, my point is about improving how Red Hat
> handles things, not about bashing. There are improvements that can be
> made.
It's hard not to pay attention to you. But I guess your point is that
Debian does provide a supported way to get newer versions of packages
even on older, stable releases, and that is an important distinction.
>
>
>> Most of the complaints I see from users in the OpenLDAP community are
>> about the TLS/SSL support in RHEL6. Do you have evidence to the
>> contrary?
>
> Certainly, here's a recent example:
> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
I guess I missed it, but exactly which OpenLDAP release(s) had the fix
for this particular problem? That is, how could Red Hat have avoided
this problem by rebasing to a later OpenLDAP?
>
>>>>> And then that leads to the question of what exactly they are
>>>>> paying RedHat for support for in the first place.
>>>>
>>>> I like how you use "RedHat" instead of "Red Hat".
>>>
>>> I like how you avoided addressing my point.
>>
>> I see your point. I get it - the OpenLDAP community is not happy with
>> the way Red Hat handles OpenLDAP. If you are really, truly concerned
>> about Red Hat customers using OpenLDAP software, what are you going to
>> do about it? If your goal is to get Red Hat to rebase OpenLDAP
>> releases on a regular basis, how can you achieve that goal? Complain to
>> Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the
>> temerity to use rhel/fedora/centos and ask a question in #ldap and
>> # openldap and the OpenLDAP mailing lists? If a critical mass of paying
>> Red Hat customers tells Red Hat that they are not happy with OpenLDAP,
>> then Red Hat will do something about it. That's the demand side.
>>
>> Red Hat (and probably all OS distributions) has the same problem to some
>> extent with all upstream projects. There are probably Apache upstream
>> community members who are unhappy with the way Red Hat deals with Apache
>> releases.
>>
>> As for the supply side, if Jan and the other OpenLDAP maintainers feel
>> that it is better to rebase than patch, then that's a good start. They
>> are the ones who are on the hook - it's their necks if things don't work
>> correctly. Once they convince themselves, then they have to convince
>> QE, Doc, support, and management that it really is the best policy. And
>> part of it is Red Hat's policy towards release stability, which adds
>> additional process, but is workable.
>
>
> I will note that Mandriva, at least, continually updates the version
> of OpenLDAP they ship, unlike most distributions, so it definitely
> isn't all. And my point is, Red Hat could do better, and I'd like to
> see them do better. I'd like to see Debian/Ubuntu do better too.
> I.e., this isn't specific to Red Hat, but the discussion here is about
> Red Hat, and what it can do. I discuss Debian and what it can do
> better with the Debian devs on their openldap dev list.
Then I'd like to hear what Jan and the other Red Hat OpenLDAP
maintainers have to say.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
10 years, 11 months
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com
--On Thursday, October 04, 2012 11:29 PM +0000 richm(a)stanfordalumni.org
wrote:
> If a customer reports such a problem, Red Hat will respond.
Again, reactive rather than proactive.
>> There have been approximately 450 committed fixes to RE24 since 2.4.23
>> was released. So you have about 5% of the fixes in your build. That
>> is just so very encouraging to hear, isn't it? As a customer,
>> wouldn't you truly feel that Red Hat was doing its best for you, but
>> grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair
>> number of those patches you have actually have zero to do with
>> OpenLDAP itself, but with MozNSS... So we're down to what? 3%?
>
> If you will concede the point that quantity != quality, then so will I.
Certainly, but a fair number of those commits are actual bug fixes. 2.4.23
in particular had some significant issues.
> So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new
> features or regressions, ever?
We have introduced new features, sure. MDB and delta-syncrepl for MMR
would be examples. But they don't impact existing functionality. And
certainly can be the case that regressions are introduced. I'm not saying
to immediately upgrade to the latest OpenLDAP release every time it comes
out. One has to have some common sense about it. However, it has been
over 2 years since 2.4.23 was released. Many significant and real issues
have been fixed since that 2.4.23 was done, with numerous fixes in the
syncrepl area and the cn=config DB, which Red Hat deploys on RHEL6.
> If this is really the case, then why would Debian or any other
> distribution not want to rebase every time OpenLDAP has a 2.4.x+1
> release? The FAQ says ". . . upgrading to newer versions is often
> desireable but also means introducing change into stable releases, which
> is exactly opposite to the point of release stability". So it's ok for
> Debian to take a hard line for release stability, but not Red Hat? Or
> is your problem really that Red Hat doesn't openly proclaim that the
> OpenLDAP server included with the distribution is not for "a large site,
> a complicated installation" or the like? So if Red Hat were to provide
> such a disclaimer, it would be ok for Red Hat to take a hard line for
> release stability?
Debian provides a backports channel that allows its users to update to
later releases. And no, I don't find Debian's hard line any more
acceptable, but at least they provide a supported solution. Red Hat doesn't
provide any supported alternative.
> So what's the difference between Debian and Red Hat with respect to
> OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not
> Debian stable? I suppose the same thing applies to Red Hat - if a Red
> Hat customer has "a large site, a complicated installation, or problems
> for which [they] need to seek help here", they will probably be willing
> to pay extra for extra attention, in the form of adding additional
> resources to build and maintain OpenLDAP themselves, or hiring a firm
> like Symas.
If you think I don't bash Debian, then you haven't been paying attention.
;) In any case, my point is about improving how Red Hat handles things,
not about bashing. There are improvements that can be made.
> Most of the complaints I see from users in the OpenLDAP community are
> about the TLS/SSL support in RHEL6. Do you have evidence to the contrary?
Certainly, here's a recent example:
<https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
>>>> And then that leads to the question of what exactly they are
>>>> paying RedHat for support for in the first place.
>>>
>>> I like how you use "RedHat" instead of "Red Hat".
>>
>> I like how you avoided addressing my point.
>
> I see your point. I get it - the OpenLDAP community is not happy with
> the way Red Hat handles OpenLDAP. If you are really, truly concerned
> about Red Hat customers using OpenLDAP software, what are you going to
> do about it? If your goal is to get Red Hat to rebase OpenLDAP
> releases on a regular basis, how can you achieve that goal? Complain to
> Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the
> temerity to use rhel/fedora/centos and ask a question in #ldap and
># openldap and the OpenLDAP mailing lists? If a critical mass of paying
> Red Hat customers tells Red Hat that they are not happy with OpenLDAP,
> then Red Hat will do something about it. That's the demand side.
>
> Red Hat (and probably all OS distributions) has the same problem to some
> extent with all upstream projects. There are probably Apache upstream
> community members who are unhappy with the way Red Hat deals with Apache
> releases.
>
> As for the supply side, if Jan and the other OpenLDAP maintainers feel
> that it is better to rebase than patch, then that's a good start. They
> are the ones who are on the hook - it's their necks if things don't work
> correctly. Once they convince themselves, then they have to convince
> QE, Doc, support, and management that it really is the best policy. And
> part of it is Red Hat's policy towards release stability, which adds
> additional process, but is workable.
I will note that Mandriva, at least, continually updates the version of
OpenLDAP they ship, unlike most distributions, so it definitely isn't all.
And my point is, Red Hat could do better, and I'd like to see them do
better. I'd like to see Debian/Ubuntu do better too. I.e., this isn't
specific to Red Hat, but the discussion here is about Red Hat, and what it
can do. I discuss Debian and what it can do better with the Debian devs on
their openldap dev list.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 11 months
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org
On 10/04/2012 03:19 PM, Quanah Gibson-Mount wrote:
> --On Wednesday, October 03, 2012 10:42 PM +0000
> richm(a)stanfordalumni.org wrote:
>
>> This is quite off-topic, but I could not resist replying.
>
> Agreed, but Jan opened it up for discussion.
>
>> On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote:
>>> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com
>>> wrote:
>>>
>>>> I understand that you don't want to support older OpenLDAP versions,
>>>> builds with non-default libraries, etc. But the users will rather use
>>>> the package from their distribution, instead of compiling it by
>>>> themselves. And we cannot support users' builds, because we do not
>>>> have
>>>> the sources and the build environment under control. And we cannot
>>>> rebase the packages freely.
>>> Redhat needs to come up with a solution to this problem, because
>>> they are
>>> putting their users in a catch-22 situation. Either they get support
>>> from RedHat for a package that will not work,
>>
>> There are many Red Hat customers who are happy using the openldap server
>> that comes with the distribution, and they do escalate problems through
>> the support they are paying for, and they do get help and fixes that
>> they pay for.
>
> There are many people who use Red Hat. There are many of those many
> who don't use openldap at all. There are many people just now
> migrating to RHEL6. My question would be -- Why is Red Hat being
> reactive instead of proactive? Upgrade your builds to include the
> latest patch level. Also, you may have "many" happy customers using
> the distribution version, but I wonder how many would be "happy" if
> they knew the risks they were being exposed to because Red Hat will
> not update the build. Like data loss in sync replication, etc.
If a customer reports such a problem, Red Hat will respond.
>
>>> or they build their own, and can't
>>> get support from RedHat.
>>
>> Why should they get support from Red Hat if they build their own (in
>> which case they have to support it themselves, or use the openldap
>> community), or install 3rd party software (in which case they should get
>> support from whoever provided the software)?
>
> You missed my point entirely. My point is they shouldn't have to
> build it themselves in the first place. Red Hat, as the provider,
> should be a *responsible* entity, and upgrade the build being
> provided, so none of their customers get put in the untenable
> situation they now face. Either build it themselves to get a working
> OpenLDAP server and lose Red Hat support, or deal with the fact that
> they are provided with a bad build.
>
>>> There are reasons new *patch* level releases are
>>> made. I see zero reason why RedHat cannot update the versions of
>>> OpenLDAP they ship since the fixes are incremental. No one should be
>>> running OpenLDAP 2.4.23 as a *production server*.
>>
>> The openldap in RHEL6 is *not* a *stock* openldap 2.4.23. They are
>> running 2.4.23 with many patches backported from later openldap
>> releases. The current version is openldap-2.4.23-26.el6_3.2.x86_64 -
>> note the "-26" which means a lot more than 26 patches.
>
> Sorry, but the number "26" is quite unimpressive.
It is not meant to impress, just a statement of fact that the RHEL
OpenLDAP 2.4.23 is not a stock 2.4.23, but contains many patches
backported from 2.4.24 and later.
> How many of those 26 patches deal with fixing Red Hat's busted MozNSS
> bits?
Many, not all.
> Your statement here is like having a mechanic tell me how much better
> my vehicle is now because he replaced one of twelve bad spark plugs.
I did not mean to imply that more patches == better. I just meant more
patches == not stock 2.4.23.
>
> There have been approximately 450 committed fixes to RE24 since 2.4.23
> was released. So you have about 5% of the fixes in your build. That
> is just so very encouraging to hear, isn't it? As a customer,
> wouldn't you truly feel that Red Hat was doing its best for you, but
> grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair
> number of those patches you have actually have zero to do with
> OpenLDAP itself, but with MozNSS... So we're down to what? 3%?
If you will concede the point that quantity != quality, then so will I.
>
>
>>> Keep the RPM version string the
>>> same, and note the upstream release in the RPM patchlevel, if that is
>>> necessary, but fix the actual code to be current.
>>
>> That's not what many Red Hat customers pay for. They pay for very
>> stable releases with only critical patches applied. The Red Hat
>> customers that want to use newer versions have many options - use Fedora
>> (which does track upstream openldap closely), build their own, go to
>> Symas, etc.
>
> As is often noted, Fedora is for "bleeding edge". Patch level
> releases are not bleeding edge. They are INCREMENTAL FIXES. If Red
> Hat's goal is to provide a "stable release", then your current
> strategy is utterly flawed. You aren't providing a stable release.
> Your fixing your distribution to a *random* release, and then holding
> all your customers to that release, regardless of how broken it might
> be. If your goal is truly to provide a stable release, then upgrade
> the patch level. If I was asking you to jump from 2.3 to 2.4, or 2.4
> to 2.5, where the minor level was changing, I'd agree that would not
> qualify as stable. I'm not. I'm saying be responsible, and do right
> by your customers. Given them actual stable builds of OpenLDAP,
> instead of hiding behind this excuse of sticking to a specific version
> for "stability". You will notice that the OpenLDAP foundation does
> not mark *any* release as "stable". And that is because people would
> use that in the same broken fashion Red Hat is applying here.
So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new
features or regressions, ever?
If this is really the case, then why would Debian or any other
distribution not want to rebase every time OpenLDAP has a 2.4.x+1
release? The FAQ says ". . . upgrading to newer versions is often
desireable but also means introducing change into stable releases, which
is exactly opposite to the point of release stability". So it's ok for
Debian to take a hard line for release stability, but not Red Hat? Or
is your problem really that Red Hat doesn't openly proclaim that the
OpenLDAP server included with the distribution is not for "a large site,
a complicated installation" or the like? So if Red Hat were to provide
such a disclaimer, it would be ok for Red Hat to take a hard line for
release stability?
>
>
>>> This is why the Debian folks *wisely* recommend that people do *not*
>>> use
>>> the distribution build for a production server.
>>
>> Can you point me to a link that has that statement in context?
>
> Absolutely. They were kind enough to contribute it to the OpenLDAP
> FAQ. I'm actually surprised you aren't familiar with it at this point,
> given that I routinely note it on IRC and the mailing list:
>
> <http://www.openldap.org/faq/data/cache/1456.html>
So what's the difference between Debian and Red Hat with respect to
OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not
Debian stable? I suppose the same thing applies to Red Hat - if a Red
Hat customer has "a large site, a complicated installation, or problems
for which [they] need to seek help here", they will probably be willing
to pay extra for extra attention, in the form of adding additional
resources to build and maintain OpenLDAP themselves, or hiring a firm
like Symas.
>
>
>>> As long as RedHat keeps up this policy, the only advice ever for RedHat
>>> customers is to build their own RPMs, and get support elsewhere, since
>>> RedHat clearly can't keep working server versions together for their
>>> customers.
>>
>> Clearly. Except for the many customers who are quite happy.
>
> See above. You say they are happy, but would they actually be happy
> if they knew the risks Red Hat was knowingly putting their data
> under? And in that "happiness" quotient, are you counting the
> increasing number of people emailing the -technical list and asking
> question on IRC about why their OpenLDAP build is so broken? I'm
> think that is likely not the case.
Most of the complaints I see from users in the OpenLDAP community are
about the TLS/SSL support in RHEL6. Do you have evidence to the contrary?
As for other comments, see below.
>
>>> And then that leads to the question of what exactly they are
>>> paying RedHat for support for in the first place.
>>
>> I like how you use "RedHat" instead of "Red Hat".
>
> I like how you avoided addressing my point.
I see your point. I get it - the OpenLDAP community is not happy with
the way Red Hat handles OpenLDAP. If you are really, truly concerned
about Red Hat customers using OpenLDAP software, what are you going to
do about it? If your goal is to get Red Hat to rebase OpenLDAP
releases on a regular basis, how can you achieve that goal? Complain to
Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the
temerity to use rhel/fedora/centos and ask a question in #ldap and
#openldap and the OpenLDAP mailing lists? If a critical mass of paying
Red Hat customers tells Red Hat that they are not happy with OpenLDAP,
then Red Hat will do something about it. That's the demand side.
Red Hat (and probably all OS distributions) has the same problem to some
extent with all upstream projects. There are probably Apache upstream
community members who are unhappy with the way Red Hat deals with Apache
releases.
As for the supply side, if Jan and the other OpenLDAP maintainers feel
that it is better to rebase than patch, then that's a good start. They
are the ones who are on the hook - it's their necks if things don't work
correctly. Once they convince themselves, then they have to convince
QE, Doc, support, and management that it really is the best policy. And
part of it is Red Hat's policy towards release stability, which adds
additional process, but is workable.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
10 years, 11 months
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com
--On Wednesday, October 03, 2012 10:42 PM +0000 richm(a)stanfordalumni.org
wrote:
> This is quite off-topic, but I could not resist replying.
Agreed, but Jan opened it up for discussion.
> On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote:
>> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com wrote:
>>
>>> I understand that you don't want to support older OpenLDAP versions,
>>> builds with non-default libraries, etc. But the users will rather use
>>> the package from their distribution, instead of compiling it by
>>> themselves. And we cannot support users' builds, because we do not have
>>> the sources and the build environment under control. And we cannot
>>> rebase the packages freely.
>> Redhat needs to come up with a solution to this problem, because they are
>> putting their users in a catch-22 situation. Either they get support
>> from RedHat for a package that will not work,
>
> There are many Red Hat customers who are happy using the openldap server
> that comes with the distribution, and they do escalate problems through
> the support they are paying for, and they do get help and fixes that
> they pay for.
There are many people who use Red Hat. There are many of those many who
don't use openldap at all. There are many people just now migrating to
RHEL6. My question would be -- Why is Red Hat being reactive instead of
proactive? Upgrade your builds to include the latest patch level. Also,
you may have "many" happy customers using the distribution version, but I
wonder how many would be "happy" if they knew the risks they were being
exposed to because Red Hat will not update the build. Like data loss in
sync replication, etc.
>> or they build their own, and can't
>> get support from RedHat.
>
> Why should they get support from Red Hat if they build their own (in
> which case they have to support it themselves, or use the openldap
> community), or install 3rd party software (in which case they should get
> support from whoever provided the software)?
You missed my point entirely. My point is they shouldn't have to build it
themselves in the first place. Red Hat, as the provider, should be a
*responsible* entity, and upgrade the build being provided, so none of
their customers get put in the untenable situation they now face. Either
build it themselves to get a working OpenLDAP server and lose Red Hat
support, or deal with the fact that they are provided with a bad build.
>> There are reasons new *patch* level releases are
>> made. I see zero reason why RedHat cannot update the versions of
>> OpenLDAP they ship since the fixes are incremental. No one should be
>> running OpenLDAP 2.4.23 as a *production server*.
>
> The openldap in RHEL6 is *not* a *stock* openldap 2.4.23. They are
> running 2.4.23 with many patches backported from later openldap
> releases. The current version is openldap-2.4.23-26.el6_3.2.x86_64 -
> note the "-26" which means a lot more than 26 patches.
Sorry, but the number "26" is quite unimpressive. How many of those 26
patches deal with fixing Red Hat's busted MozNSS bits? Your statement here
is like having a mechanic tell me how much better my vehicle is now because
he replaced one of twelve bad spark plugs.
There have been approximately 450 committed fixes to RE24 since 2.4.23 was
released. So you have about 5% of the fixes in your build. That is just
so very encouraging to hear, isn't it? As a customer, wouldn't you truly
feel that Red Hat was doing its best for you, but grabbing a full 5% of
fixes to OpenLDAP? And lets not forget a fair number of those patches you
have actually have zero to do with OpenLDAP itself, but with MozNSS... So
we're down to what? 3%?
>> Keep the RPM version string the
>> same, and note the upstream release in the RPM patchlevel, if that is
>> necessary, but fix the actual code to be current.
>
> That's not what many Red Hat customers pay for. They pay for very
> stable releases with only critical patches applied. The Red Hat
> customers that want to use newer versions have many options - use Fedora
> (which does track upstream openldap closely), build their own, go to
> Symas, etc.
As is often noted, Fedora is for "bleeding edge". Patch level releases are
not bleeding edge. They are INCREMENTAL FIXES. If Red Hat's goal is to
provide a "stable release", then your current strategy is utterly flawed.
You aren't providing a stable release. Your fixing your distribution to a
*random* release, and then holding all your customers to that release,
regardless of how broken it might be. If your goal is truly to provide a
stable release, then upgrade the patch level. If I was asking you to jump
from 2.3 to 2.4, or 2.4 to 2.5, where the minor level was changing, I'd
agree that would not qualify as stable. I'm not. I'm saying be
responsible, and do right by your customers. Given them actual stable
builds of OpenLDAP, instead of hiding behind this excuse of sticking to a
specific version for "stability". You will notice that the OpenLDAP
foundation does not mark *any* release as "stable". And that is because
people would use that in the same broken fashion Red Hat is applying here.
>> This is why the Debian folks *wisely* recommend that people do *not* use
>> the distribution build for a production server.
>
> Can you point me to a link that has that statement in context?
Absolutely. They were kind enough to contribute it to the OpenLDAP FAQ.
I'm actually surprised you aren't familiar with it at this point, given
that I routinely note it on IRC and the mailing list:
<http://www.openldap.org/faq/data/cache/1456.html>
>> As long as RedHat keeps up this policy, the only advice ever for RedHat
>> customers is to build their own RPMs, and get support elsewhere, since
>> RedHat clearly can't keep working server versions together for their
>> customers.
>
> Clearly. Except for the many customers who are quite happy.
See above. You say they are happy, but would they actually be happy if
they knew the risks Red Hat was knowingly putting their data under? And in
that "happiness" quotient, are you counting the increasing number of people
emailing the -technical list and asking question on IRC about why their
OpenLDAP build is so broken? I'm think that is likely not the case.
>> And then that leads to the question of what exactly they are
>> paying RedHat for support for in the first place.
>
> I like how you use "RedHat" instead of "Red Hat".
I like how you avoided addressing my point.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 11 months
Re: (ITS#7409) ldapsearch issue using * in filters
by quanah＠zimbra.com
--On Thursday, October 04, 2012 9:14 AM +0000 fishakos(a)yahoo.gr wrote:
> When i try to use the command
>> ldapsearch -h localhost -LLL -x -s sub -d 32 -b
> bill=postpaid,msisdn=*,dc=cosmote,dc=ro
-b is the base, not a filter. Your search is invalid, and you definitely
have provided an invalid DN syntax. This ITS will be closed.
I would note that back-ndb was never finished, and is considered beta at
best.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 11 months
(ITS#7410) ldapsearch issue using * in filters
by fishakos＠yahoo.gr
Full_Name: Panagiotis Psarrakos
Version: 2.4.31
OS: CentOS release 5.5 (Final)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.205.53.214)
My environment consists of MySQL Cluster database with 2 Data nodes and 2 mysql
nodes. I have installed openLDAP at both mysql nodesusing back-ndb for
retrieving data from MySQL Cluster database.
The table OL_dn2id contains entries like the sample below
eid |objectclass | a0 | a1 | a2 | a3
---------------------------------------------------------------------------------
2790113 |entitlement@top| dc=ro | dc=cosmote | msisdn=40765494677 | bill=prepaid
---------------------------------------------------------------------------------
993566 |usertable@top | dc=ro | dc=cosmote | msisdn=40765494677 | bill=postpaid
I need to perfrom search based on msisdn or based on attribute bill (bill can
have values prepaid/postpaid)
When i try to use the command
>ldapsearch -h localhost -LLL -x -s sub -d 32 -b
bill=postpaid,msisdn=*,dc=cosmote,dc=ro
then i receive the error
Invalid DN syntax (34)
Additional information: invalid DN
As i understand i have to use both columns a3 and a2 in order to do searches
based on bill attribute but i need to have all msisdn based on the bill value
Is there a limitation in openLDAP implementation in using the character * for
wildcard LDAP searches?
10 years, 11 months