openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7348) enhancement: check_password contrib module
by Guillaume.Rousse＠inria.fr 10 Oct '12

10 Oct '12

Ceci est un message signC) cryptographiquement au format MIME. --------------ms010005020603050107040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ping ? Can I have any kind of feedback ? --------------ms010005020603050107040502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJYDCC BJUwggN9oAMCAQICECu5mlkLgTFbaSg8Mgwue0kwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UE BhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMB4X DTExMDExMTAwMDAwMFoXDTE0MDExMDIzNTk1OVowWDELMAkGA1UEBhMCRlIxDjAMBgNVBAoT BUlOUklBMRkwFwYDVQQDExBHdWlsbGF1bWUgUk9VU1NFMR4wHAYJKoZIhvcNAQkCFg9yb3Vz c2VAaW5yaWEuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU9hkZ4j+MxXqQ 310Pah2QqpshhbJ8T9bACuYEcIdsZuxCYDUgJUVZJmHZK6IZbX4xiVr85pSHPJYG8z0nXXh4 ZXN0iPGVd2/YFpcqt2rB+KDydyrioXfLNiS6JZeKWEaPhKh/5C6/E898XwxB7VzV4meEDOpJ 4si8pNkCnPFFLMXfH/IG4lFvMj9qwfTIMGymB5/hLnZBm5/pK0Bm6wUESvN6YWFRjZ0ctd5p bvDG/vZpjQiavHC+r4YSLBgeFUb4W5N6XGXNsxZvUCRc4mC6XaiDaId75klRxFTdDmtynnLl 44mm6KJws158b3YC1kGACTYJaT+01R+D08PsVy2bAgMBAAGjggF2MIIBcjAfBgNVHSMEGDAW gBRjTUNaGUg/xEbBArq/7g7lgrdmpjAdBgNVHQ4EFgQUT8X4ighZJ1th5zEgoWZwKTXpQcIw DgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wPwYDVR0fBDgwNjA0oDKgMIYuaHR0 cDovL2NybC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNybDByBggrBgEFBQcB AQRmMGQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVSRU5BUGVy c29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLnRjcy50ZXJlbmEub3JnMCQG A1UdEQQdMBuBGUd1aWxsYXVtZS5Sb3Vzc2VAaW5yaWEuZnIwDQYJKoZIhvcNAQEFBQADggEB AEItBMmkv3DtWrx5KhZDlYV+ZLht8pFJTiK84GtnZ0dh+8pUSCzk8QS8Hly9gyiTfmTyZXiy UpnVXLLatBp3kgOw9ZCbdGj3TB6iOvHzHKaUHq/jdVf/S2CVlkU1ekRa5UnbsxFObZnZRu0G 2Lb4DbbwZYmS9OgGDzueBQ5B64X5yZXUueXnrgJMBa2JCT9QGvs6Px9src1ZyCArWTLGUmu2 NsaOI+WJMXdByLHOPJZp5A52dPPsnwDoyYrNrXPXngXXL0Pz3JPsKCA3lvb52oQkXDjqgm5o rYdHKhbxJvHG9WozyCppVBgSYve0IVyVfBWXLiCtTWnpY//DA23Hd2cwggTDMIIDq6ADAgEC AhBz/lf637jFCIF7Zrlr8C3vMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTA5 MDUxODAwMDAwMFoXDTI4MTIzMTIzNTk1OVowOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRF UkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyBXZ9TNqI6GQDc+7BUTDqx9KNYUaIYWgT/jwQOJKQ5v+W7Gwv7RX3HWA QUtkGvbbT2+P0CVFNfnqy0r6+9rT7UWIEZQ25MyoDe/FPTftFnvjwpWeWDN/Ivv4/+zmvtuu CmUlIofab4SLRuhAhig/v1YI4krpg6LpIvst+rYoH5HBw3H7U8ArTqQMoW6dVe3s4SSHOgji DRzkxE3Qyyf6hGTm0ZedViRbk7spLkPiQWo94kpl/JpfWoaHvIfHeYCWmVHGkA9kkZl9EN2s LAMq4Xhk/s49TvQrUBFL0VjUmwPwf/U7U7BTQ/vFL8QEKRo6rNdV6dEOldE7MX94T64pLQID AQABo4IBTTCCAUkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYE FGNNQ1oZSD/ERsECur/uDuWCt2amMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wWAYDVR0fBFEwTzBNoEugSYZHaHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25h bmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29j c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEABiupUy8T3Fw5FsyGn15Me3L7 7I1Vil6aCv9TTHb0Bj1Qz1fwos+vmYyq/qAZdj6ZAzL6dYM4irtrmqUME7LUG3bmlC5nmFnj kWwCkJqcyGBLVavKiFqNK+VplQMH0dQO/CQiLlmxY6Rf7dkjcuSczjpcbB9PqQDJHf76f0Ut ti6E3Q8noFkYTtV2JUX0mSZ522+fI/dDuysPBKOBJiy3ezX5PXdfQCHmfx2lllq90MsWOmy7 YYuK/QQ5RArLLOHLzi4QmBrb4JPtSWRkCCCft6NQ8KLdyrTGfAw9514V3CeG5Do7UloXq6kG UyudCXNkHAHD/TDShwNv5BUDejlfaDGCAwcwggMDAgEBME8wOzELMAkGA1UEBhMCTkwxDzAN BgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhAruZpZC4ExW2ko PDIMLntJMAkGBSsOAwIaBQCgggGNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTAxMDE1MTQ1MFowIwYJKoZIhvcNAQkEMRYEFISpiKvxYJ/cJnbtLJAt y+oy8hXXMF4GCSsGAQQBgjcQBDFRME8wOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVO QTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhAruZpZC4ExW2koPDIMLntJMGAGCyqG SIb3DQEJEAILMVGgTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQD ExJURVJFTkEgUGVyc29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEF AASCAQBSTpiPHQsxT9U0zme6qRLWCJXDvU6vfyPzeM+6Fb6t9iH9RlXrmNKBPx501HQWCfwf K/OGGzzNULpU3N3pTp++BRoyPnNPVmIwLe1MedC7SMf/5oL2p8KTGu+VUPd0TXaJihfXwq0+ sThwq9O1464Cfxr+n27k/GSvU3AHsn3j59BqSdGZUXs+Dg/42acuWoV2xYL0ZjyRt8d1ZoU7 3U5TWKTEIAP5zMnSvBfHbfV4HUEIl9AVKtPaaaq4L1aQnByyEG6cN39R4N+LPwQXVW4pBwuI nKUF8FImmM3tovtb0aINf83d+RFuAhGEUGxLLFgYRGHzxRdCSIC85rOry1C4AAAAAAAA --------------ms010005020603050107040502--

1 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com 09 Oct '12

09 Oct '12

arun s wrote: > Hi, > To try and overcome this issue, we tried two fixes: > > 1. Every time a user was deleted from a group, we force-updated the user > object manually to make sure its entryCSN got updated and it got > replicated properly. This is an expensive operation and did not scale > well for big group sizes (10-20k), and did not work out. This is also one of the reasons the code in memberof.c was reverted. Working as you suggest *cannot* scale. It makes no difference whether you do it in your external client or inside slapd, the amount of actual work required to replicate everything quickly grows out of control. This is why the documentation states that memberof must be configured on each replica - the only way to successfully execute the amount of work is to distribute the work evenly to each replica. > 2. We then tried to do the same thing in OpenLDAP. We noticed in the > memberof.c commits that there were a couple of patches to force the > entryCSN of the user object to get updated. (http://tinyurl.com/8k4qrdj > and http://tinyurl.com/9akqgfl)These have since been reverted because of > access log and some replication issues, but for us, speed was a higher > priority. I reapplied these patches back to the code. This solved the > member-of replication issue, but we noticed that occasionally under a > heavy load, there was a sudden surge in OpenLDAP's memory usage going up > to whatever memory was available and finally crashing. > > We have gone back to option (1) though (2) would be the preferred option. > > Any help on figuring out why (2) caused the memory bloat would be really > great. I can provide more details/memory traces if needed. > > We will be glad to contribute any fixes once we are able to nail down > the issue. Probably this conversation should continue on the openldap-devel mailing list. It needs some new design work; it is not a simple bugfix. > > Thanks, > Arunkumar > ------------------------------------------------------------------------------ > *From:* Howard Chu <hyc(a)symas.com> > *To:* arun s <arunkumar_1123(a)yahoo.com> > *Cc:* "openldap-its(a)openldap.org" <openldap-its(a)openldap.org> > *Sent:* Monday, 1 October 2012 6:59 PM > *Subject:* Re: (ITS#7400) Memberof and Syncrepl incompatibility > > arun s wrote: > > Hi, > > Yes, I am able to reproduce the issue with 2.4.32 > > > > Making sense of the logs for the exact reproduction is hard since it needs a > > lot of operations in a short time. But this will probably help: > > > > 1. At the start of the test, the group temp_group existed. > > > > 2. I created a user temp_user and added temp_user to temp_group. > > > > 3. During replication, the group was replicated first and I got an error 32 > > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user object > > (This does not exist in the readslave yet). > > > > 4. The temp_user object was replicated next, and as you see, querying it does > > show a memberOf attribute, proving that this field was replicated. (Note that > > I have run OpenLDAP with debug as -1 and verified that the replicated data has > > the memberOf field in it. I can provide this too if needed.) > > I see. The current code drops the memberOf attribute if it was not explicitly > requested in the search. However, by default the consumer requests "+" which > means "all operational attributes" and so slapd considers memberOf to have > been requested. We need to reconsider this aspect of the design. > > > > 5. The more serious problem occurs when the sequence is reversed and the group > > has been deleted as a last operation - The user is replicated first, but since > > the group is deleted, it is never replicated and a stale memberOf entry stays > > with the user. -- -- 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#7400) Memberof and Syncrepl incompatibility
by arunkumar_1123＠yahoo.com 09 Oct '12

09 Oct '12

--1251447850-1386810138-1349783312=:99375 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0ATo try and overcome this issue, we tried two fixes:=0A=0A1. Every tim= e a user was deleted from a group, we force-updated the user=A0=0Aobject ma= nually to make sure its entryCSN got updated and it got=A0=0Areplicated pro= perly. This is an expensive operation and did not scale=A0=0Awell for big g= roup sizes (10-20k), and did not work out.=0A=0A2. We then tried to do the = same thing in OpenLDAP. We noticed in the=A0=0Amemberof.c commits that ther= e were a couple of patches to force the=A0=0AentryCSN of the user object to= get updated. (http://tinyurl.com/8k4qrdj=A0=0Aand http://tinyurl.com/9akqg= fl)These have since been reverted because of=A0=0Aaccess log and some repli= cation issues, but for us, speed was a higher=A0=0Apriority. I reapplied th= ese patches back to the code. This solved the=A0=0Amember-of replication is= sue, but we noticed that occasionally under a=A0=0Aheavy load, there was a = sudden surge in OpenLDAP's memory usage going up=A0=0Ato whatever memory wa= s available and finally crashing.=0A=0AWe have gone back to option (1) thou= gh (2) would be the preferred option.=0A=0AAny help on figuring out why (2)= caused the memory bloat would be really=A0=0Agreat. I can provide more det= ails/memory traces if needed.=0A=0AWe will be glad to contribute any fixes = once we are able to nail down=A0=0Athe issue.=0A=0AThanks,=0AArunkumar=0A= =0A________________________________=0A From: Howard Chu <hyc(a)symas.com>=0AT= o: arun s <arunkumar_1123(a)yahoo.com> =0ACc: "openldap-its(a)openldap.org" <op= enldap-its(a)openldap.org> =0ASent: Monday, 1 October 2012 6:59 PM=0ASubject:= Re: (ITS#7400) Memberof and Syncrepl incompatibility=0A =0Aarun s wrote:= =0A> Hi,=0A> Yes, I am able to reproduce the issue with 2.4.32=0A> =0A> Mak= ing sense of the logs for the exact reproduction is hard since it needs a= =0A> lot of operations in a short time. But this will probably help:=0A> = =0A> 1. At the start of the test, the group temp_group existed.=0A> =0A> 2.= I created a user temp_user and added temp_user to temp_group.=0A> =0A> 3. = During replication, the group was replicated first and I got an error 32=0A= > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user ob= ject=0A> (This does not exist in the readslave yet).=0A> =0A> 4. The temp_u= ser object was replicated next, and as you see, querying it does=0A> show a= memberOf attribute, proving that this field was replicated. (Note that=0A>= I have run OpenLDAP with debug as -1 and verified that the replicated data= has=0A> the memberOf field in it. I can provide this too if needed.)=0A=0A= I see. The current code drops the memberOf attribute if it was not explicit= ly requested in the search. However, by default the consumer requests "+" w= hich means "all operational attributes" and so slapd considers memberOf to = have been requested. We need to reconsider this aspect of the design.=0A> = =0A> 5. The more serious problem occurs when the sequence is reversed and t= he group=0A> has been deleted as a last operation - The user is replicated = first, but since=0A> the group is deleted, it is never replicated and a sta= le memberOf entry stays=0A> with the user.=0A=0A--=A0 -- Howard Chu=0A=A0 = CTO, Symas Corp.=A0 =A0 =A0 =A0 =A0 http://www.symas.com=0A=A0 Director, Hi= ghland Sun=A0 =A0 http://highlandsun.com/hyc/=0A=A0 Chief Architect, OpenLD= AP=A0 http://www.openldap.org/project/ --1251447850-1386810138-1349783312=:99375 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div style=3D"font-fa= mily: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span= >=0A=0A=0A=0A=0A=0A=0A=0A<div class=3D"p1">Hi,</div></span></div><div><div>= To try and overcome this issue, we tried two fixes:</div><div><br></div><di= v>1. Every time a user was deleted from a group, we force-updated the user&= nbsp;</div><div>object manually to make sure its entryCSN got updated and i= t got </div><div>replicated properly. This is an expensive operation a= nd did not scale </div><div>well for big group sizes (10-20k), and did= not work out.</div><div><br></div><div>2. We then tried to do the same thi= ng in OpenLDAP. We noticed in the </div><div>memberof.c commits that t= here were a couple of patches to force the </div><div>entryCSN of the = user object to get updated. (http://tinyurl.com/8k4qrdj </div><div>and= http://tinyurl.com/9akqgfl)These have since been reverted because of = </div><div>access log and some replication issues, but for us, speed was a = higher </div><div>priority. I reapplied these patches back to the code= . This solved the </div><div>member-of replication issue, but we noticed that occas= ionally under a </div><div>heavy load, there was a sudden surge in Ope= nLDAP's memory usage going up </div><div>to whatever memory was availa= ble and finally crashing.</div><div><br></div><div>We have gone back to opt= ion (1) though (2) would be the preferred option.</div><div><br></div><div>= Any help on figuring out why (2) caused the memory bloat would be really&nb= sp;</div><div>great. I can provide more details/memory traces if needed.</d= iv><div><br></div><div>We will be glad to contribute any fixes once we are = able to nail down </div><div>the issue.</div><div><br></div><div>Thank= s,</div><div>Arunkumar</div></div> <div style=3D"font-family: 'times new r= oman', 'new york', times, serif; font-size: 12pt; "> <div style=3D"font-fam= ily: 'times new roman', 'new york', times, serif; font-size: 12pt; "> <div = dir=3D"ltr"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1"> <b><span style=3D"font-weight:bold;">From:</span></b> Howard Chu <hyc(a)symas.com&= gt;<br> <b><span style=3D"font-weight: bold;">To:</span></b> arun s <aru= nkumar_1123(a)yahoo.com> <br><b><span style=3D"font-weight: bold;">Cc:</sp= an></b> "openldap-its(a)openldap.org" <openldap-its(a)openldap.org> <br> = <b><span style=3D"font-weight: bold;">Sent:</span></b> Monday, 1 October 20= 12 6:59 PM<br> <b><span style=3D"font-weight: bold;">Subject:</span></b> Re= : (ITS#7400) Memberof and Syncrepl incompatibility<br> </font> </div> <br>a= run s wrote:<br>> Hi,<br>> Yes, I am able to reproduce the issue with= 2.4.32<br>> <br>> Making sense of the logs for the exact reproductio= n is hard since it needs a<br>> lot of operations in a short time. But t= his will probably help:<br>> <br>> 1. At the start of the test, the g= roup temp_group existed.<br>> <br>> 2. I created a user temp_user and= added temp_user to temp_group.<br>> <br>> 3. During replication, the group was replicated first and I got an error 32<br>> (NO_SUCH_OBJECT) = when it tried to modify the memberOf of the temp_user object<br>> (This = does not exist in the readslave yet).<br>> <br>> 4. The temp_user obj= ect was replicated next, and as you see, querying it does<br>> show a me= mberOf attribute, proving that this field was replicated. (Note that<br>&gt= ; I have run OpenLDAP with debug as -1 and verified that the replicated dat= a has<br>> the memberOf field in it. I can provide this too if needed.)<= br><br>I see. The current code drops the memberOf attribute if it was not e= xplicitly requested in the search. However, by default the consumer request= s "+" which means "all operational attributes" and so slapd considers membe= rOf to have been requested. We need to reconsider this aspect of the design= .<br>> <br>> 5. The more serious problem occurs when the sequence is = reversed and the group<br>> has been deleted as a last operation - The user is replicated first, but since<br>> the group is deleted, it= is never replicated and a stale memberOf entry stays<br>> with the user= .<br><br>--  -- Howard Chu<br>  CTO, Symas Corp.    &n= bsp;     <a href=3D"http://www.symas.com/" target=3D"_blank">htt= p://www.symas.com</a><br>  Director, Highland Sun    <a hre= f=3D"http://highlandsun.com/hyc/" target=3D"_blank">http://highlandsun.com/= hyc/</a><br>  Chief Architect, OpenLDAP  <a href=3D"http://www.op= enldap.org/project/" target=3D"_blank">http://www.openldap.org/project/</a>= <br><br><br> </div> </div> </div></body></html> --1251447850-1386810138-1349783312=:99375--

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 08 Oct '12

08 Oct '12

> >> 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. As for Fedora, I usualy rebase the package immediately when the new upstream version is available. And I do it in the stable and newer releases (for today it would be stable F17, alpha F18, and Rawhide). And if there is a problem in older Fedora, I just pick the patch. So we are definitelly not behind with Fedora -- the last submitted updates can be found here: https://admin.fedoraproject.org/updates/search/openldap As for RHEL it is more complicated, the rebases are allowed rarely. We cannot afford any API/ABI breakage and regressions. and I can imagine that a new feature in OpenLDAP changes the current behavior or affects some other component. I can remind a bug which appeared after rebase to 2.4.31 in Fedora and we do not want to cause a similar problems in RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=771484 http://www.openldap.org/its/index.cgi?findid=7167 I would like to see newer OpenLDAP in RHEL because it would be easier for me to maintain it. But I'm not sure if the advantages will outweight the disadvantages and if our customers will benefit from it rather than be forced to deal with new problems. > 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. When there is a new bug report, I usualy try to reproduce with the package from RHEL or Fedora. And then with the newest OpenLDAP from git master. If I'm able to reproduce, I always create a report in your ITS. Jan

1 0

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

07 Oct '12

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

1 0

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

07 Oct '12

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--

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 05 Oct '12

05 Oct '12

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%2… Here is the current Fedora openldap bug list - https://bugzilla.redhat.com/buglist.cgi?list_id=641625&classification=Fedor… 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 > >

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 05 Oct '12

05 Oct '12

--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

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 04 Oct '12

04 Oct '12

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

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 04 Oct '12

04 Oct '12

--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

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