Matt Benjamin <[EMAIL PROTECTED]> wrote: > 1. I do not disagree with your statements in this mail, except as > below (two previous mails discuss id-mapping concepts and > mechanisms as applicable to Samba and NFSv4 in ways I find > confusing)
In a nutshell, with regards to Exam 302, whenever Samba touches on authentication for Kerberos and IDMAP, I think the relevant NFSv4 concepts should be introduced. Months ago I backed away from supporting AFS consideration because AFS uses virtual filesystems and you cannot share out the same data from the local filesystem with NFS and SMB. I realized the "driver" for Exam 302 was Samba, so I left it at only basic NFS integration. I just wanted to revisit this consideration after the 2006 Aug 22 announcements from OSDL. I was going to bring it up back then, but I'm really a guy that hasn't "put up" due to my current workload, so I've adopted a largely "shut up" attitude until this past Monday. > 2. Traditional AFS has weaker wire security than NFSv4 with > RPCSEC_GSS integrity+privacy, actually, and that applies to > today's OpenAFS 1.4 > 3. That is not the case with rxk5, which Marcus Watts and I have > worked on for OpenAFS Your understanding and experience on AFS is going to be far superior to mine. I have only implemented AFS in passing, and almost strictly limited to use in existing Kerberos 5 realms (using the krb4 compatibility and probably more of a "hacked" setup compared to someone like yourself). > 4. Rxk5 does not use GSSAPI--it uses Kerberos V directly, Correct. GSSAPI can be a PITA (among other things), but it does allow some great flexibility. > so even though PKINIT gives Kerberos V some X.509 integration, > that would be more complicated for small sites to manage than > LIPKEY, I would think (but I have not tried to use LIPKEY, > actually--but I am calling that out because people are going > to need it) Hey man, I'm just getting back into Fedora Directory Server (supporting more UW LDAP, Netscape Directory Server and Certificate Services going back to the late '90s). Most of my work over the last 15 months has been embedded Linux, which means I'm a bit ignorant myself on the latest developments. > 5. Rxk5 is not an IETF standard, and neither is Rx (but Jeff > Hutzelman and others have stated a desire to change that), > nor is AFS (not that you claimed that) Well there are many aspects to NFS that aren't IETF standards either, although NFSv4 is trying to change that. > 6. I think you are highly over-the-top very frequently, As of the last 24 hours, I most certainly agree. I tried to "cut through the non-sense" with the certification requirements. Again, I had avoided posting much on Discuss because I'm so busy, and I believe in the "put up or shut up" attitude. But since I spoke, I decided I might as well throw in some updated technical info, like the OSDL announcement on NFSv4. That's when the barrage of "Samba-only" non-sense started. I didn't take to kindly to it. > and that the tit4tat-ing contributes to the effect you remarked > on yesterday (of people you think your are in agreement with, > believing they are in an argument with you) But I did *NOT* reguritate what I *THOUGHT* you said. Someone else did that, when it was clear they thought I merely stated what someone else did (and not myself). Instead of doing that, I let your statements stand on their own. I agreed with your points, but *ALSO* said please correct me if I was wrong or incorrect in my agreements, possibly missing your points. Trust me, I'm not a hypocrite, and take extensive and great pains to avoid being such. And when I'm wrong, I'll admit it fully. Maybe not always the first time it is pointed out, but by God the second time. There are 17 dead US astronauts because people are too prideful to admit when they are mistaken. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-discuss mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-discuss
