[00:13:39] --- Russ has left: Disconnected [00:57:09] --- Simon Wilkinson has left [01:44:09] --- Simon Wilkinson has become available [01:56:44] --- haba has become available [02:02:15] --- haba has left [02:29:40] --- stevenjenkins has left [03:07:36] --- stevenjenkins has become available [03:31:15] --- dev-zero@jabber.org has left [03:32:02] --- dev-zero@jabber.org has become available [04:22:19] --- tkeiser@sinenomine.net/owl has become available [04:49:17] --- stevegt has left: Replaced by new connection [04:49:17] --- stevegt has become available [06:41:05] --- tkeiser@sinenomine.net/owl has left [06:58:55] --- SecureEndpoints has left [07:11:28] --- SecureEndpoints has become available [07:39:52] --- Derrick Brashear has left [07:41:53] --- reuteras has left [07:54:16] --- Derrick Brashear has become available [07:54:43] --- raini has become available [07:56:34] --- Derrick Brashear has left [08:01:01] --- Derrick Brashear has become available [08:01:10] --- Derrick Brashear has left [08:22:34] --- matt has become available [08:44:47] --- raini has left: Disconnected [08:48:03] --- raini has become available [08:57:57] --- dmontuori has become available [09:04:26] --- manfred furuholmen has left [09:06:47] --- manfred furuholmen has become available [09:21:38] --- Moose has become available [09:21:56] jaltman alive(ish)? [09:22:19] yes maam [09:22:27] don't call me maam [09:22:50] I just got a contract from Usenix for the short-topics book. It looks like it says that it can be (re)used to write a bigger book. [09:22:53] --- summatusmentis has left [09:23:04] excellent [09:23:08] yes [09:23:10] what is your topic? [09:23:12] i arrrr excited [09:23:20] ... [09:23:23] openafs? [09:23:34] they want a "snappy title" [09:23:42] SAVING THE UNIVERSE WITH OPENAFS [09:23:45] "snappy openafs"? [09:23:49] hee [09:24:01] How OpenAFS Saved Derrick Brashear From Terminal Bitterness [09:24:23] I really like "saving the universe with openafs" [09:24:29] and think you should go w. that [09:24:36] shouldn't that be "How Derrick Brashear saved terminals from OpenAFS bitterness"? [09:24:38] somehow i think jane-ellen will roll her eyes at that [09:24:58] OpenAFS And You: A Love Story [09:25:01] at me, terminals or the universe? [09:25:03] it's catchy and it grabs the attention of the potential reader immediately [09:25:12] openafs is dead long life to .. [09:25:33] OpenAFS is a huge topic. I would focus on one specific scenario or functionality [09:25:39] OpenAFS: Why NFSv4 Will Make You Cry [09:25:43] OpenAFS, or, How I Learned to Stop Worrying and Love the Pag [09:25:58] speaking of which, who wants PAGs on Windows? [09:26:06] It's a short-topic book, so it's basically a book version of the 1-hour intros I do [09:26:07] --- dmontuori has left [09:26:15] i want pags on osx [09:26:20] oo! oo! i do! i do! [09:26:24] --- dmontuori has become available [09:26:36] "why openafs today ! " [09:27:06] Use OpenAFS Or We'll Send JHutz To Lecture You About It" [09:27:45] how many pages? [09:27:55] uh [09:27:59] (checks contract) [09:28:03] "i'll show you my cell if you show me yours" [09:28:08] or how many words/ [09:28:23] 40-100 pages [09:28:24] chars [09:28:34] 9340245923804968493068 chars [09:29:07] maxint [09:29:19] 1.6 E20 lines [09:29:50] ~20K to 50K words [09:31:43] I've done so much intro stuff in the past ~1.5 yrs I'm pretty sure I can crank out stuff in my sleep [09:31:54] and until i get this sleep crap under control, i may have to do that [09:32:21] my idea for a book on openafs would be a 1000 page monster consisting of an intro chapter and then 10 to 15 topics focusing on specific use cases or operations (salvaging, backups, volume management, etc.) [09:32:43] absolutely [09:32:46] your short book could become the intro section [09:32:48] --- summatusmentis has become available [09:32:52] possibly [09:32:53] --- summatusmentis has left [09:32:57] --- summatusmentis has become available [09:33:27] but now I must leave to receive my beer delivery [09:33:36] (aka lunch) [09:34:41] openafs is the base of all modern network file system .. everyone took the experience of afs [09:35:32] The short book should obviate the need to read the 1000 page monster for most people and most of the time. [09:38:08] the short book is, to my mind, something like my talks. This is AFS. This is what it can do. This is what it can't do. This is what you need to know. Only I can get a bit more detailed in 100 pages, maybe [09:38:46] i was really pissed off at my guru session at LISA -- I had been told "no slides" and I got there and there was a projector! [09:38:54] I have the coolest p icture for "sometimes AFS is not hte right tool" [09:39:02] It ought to be possible to indicate how to operate a small cell in 100+ pgs? [09:39:20] it would've been nice to have that documentation when I started :) [09:39:22] Well [09:39:28] Yes, but that's a different book :) [09:39:39] ie, suggesting one approach to solving each decision you'd need to make if you were a large environment [09:39:47] That's what people lack, IMO. [09:39:55] When Alf &/or I do AFS training, we go with "This is what you need to understand the install docs and build a cell" [09:40:04] (unless we're doing multi-day training, i believe) [09:40:27] "this is afsd. this is what it does. this is the common switches. this is how to guess how to set them" [09:41:04] That's exploding out the diagram to including things most people won't use, most of the time. [09:41:05] "welcome to ubik. ubik is keen and runs on crack. let's play the 'voting' game!" [09:41:15] untrue [09:41:15] i vote no [09:41:28] the #1 question I get at Guru and other talks is, "How do I tune my afs client" [09:41:35] always always always [09:41:36] Sure. [09:41:40] you can tuna afs client but you can't tuna fish [09:41:51] I say, "first you get the chicken. then draw the pentagram" [09:42:02] you can tuna fish, you just need the right tools [09:42:16] mmmmm can tuna fish [09:42:36] But if AFS lacks one book, it's the one that makes it possible for the admin who would otherwise set up a Samba service using its 120 pp manual, to do it with OpenAFS instead. [09:42:45] That's the big book [09:42:58] Short Topics books are NOT about Let's Build The World [09:43:05] Again, for Samba, it's done in 120 pages. [09:43:17] iirc, anyway [09:43:24] maybe it got bigger by samba 3 [09:43:24] --- dmontuori has left [09:43:28] That's because Samba is shit :) [09:43:30] --- dmontuori has become available [09:43:55] Well, it's annoyingly useful, isn't it? Keeps them coming back. [09:43:55] "Distributed Services with OpenAFS for Enterprise and Education" does an excellent job of getting a cell up and running along with all of the other supporting infrastructure [09:44:12] Is that the one with chapters on doing lots of unrelated stuff? [09:44:23] I gotta get that book [09:44:27] if just for shits and giggles [09:44:30] Like SMTP and what not? [09:44:43] the OpenAFS section is 70 pages. The Samba section is 30 [09:45:22] --- raini has left [09:45:27] starts with NTP, then Kerberos and LDAP, the OpenAFS and Samba, and then application services that can be built on top [09:46:08] You liked the presentation (I haven't actually read it, just reviewed the chapters online)? [09:47:15] its a decent book. I don't think it goes in depth enough at times and does nothing to help debug stuff once it is up and running but it demonstrates that it is easy to setup and admin a multiple server cell with Kerberos v5 auth [09:47:54] its essentially a cook book. follow these steps and you will have a cell [09:48:26] afs needs such a set of instructions [09:48:55] Interesting. I think that's the core of what would deliver most value (eg, double its depth), but I'm probably missing the context that makes the short guide make sense. [09:54:51] un pimento [09:55:00] hm, that could be it [10:04:19] --- manfred furuholmen has left [11:15:11] --- Russ has become available [11:31:41] --- mmeffie has become available [11:33:47] --- dev-zero@jabber.org has left [12:05:00] --- dmontuori has left [12:05:07] --- dmontuori has become available [12:06:01] --- stevegt has left [12:18:40] --- dev-zero@jabber.org has become available [12:38:53] --- dev-zero@jabber.org has left: Replaced by new connection [12:38:53] --- dev-zero@jabber.org has become available [12:46:29] --- stevegt has become available [12:50:00] --- Russ has left: Disconnected [12:59:21] Just catching up with the previous discussion. [12:59:31] we weren't talking about you [12:59:34] really we weren't [12:59:36] much [12:59:44] What AFS really needs is to need fewer instructions. It should be better at doing the right thing out of the box. [13:00:17] Whilst kaserver dying is truly wonderful, I share Derrick's misgivings about the effect of "before you can run AFS, go off and configure Kerberos" [13:01:13] Right. From now on, AFS can use only the following instructions: load/store (any mode), add, xor, branch-if-carry [13:01:31] ? [13:02:01] The answer to that is to get ourselves to the point where AFS works with auth mechanisms other than kerberos. [13:02:12] Yes. [13:02:39] And to look at how we can integrate AFS with the current set of IDMSs that vendors like RedHat are in the process of producing. [13:02:42] --- Russ has become available [13:03:13] (I was talking to someone about that earlier this year, and he was going to look into it. It's all gone quiet on that front. I should find out what's going on) [13:03:14] one step at a time [13:03:24] Well, I think that might be the first step. [13:03:57] The RedHat thing is a Kerberos/LDAP based solution, which is (in theory) pluggable. So, we should be able to teach it about pts without a huge amount of trouble. [13:04:08] only if the preferred authentication system of those systems is kerberos. and I strongly suspect it's actually LDAP, which sucks royally because LDaP isn't an authentication system at all. [13:04:49] The problem is finding someone with the motivation. I doubt anyone with the expertise has the desire to switch IDMSes. [13:05:08] --- dmontuori has left [13:05:14] --- dmontuori has become available [13:05:47] Right; teaching IDMS's about AFS is going to be first PTS, then management of user volumes. [13:06:20] But neither of those is useful unless it's also managing an authentication system we can use, which means we're presently limited to the cases where the idms is managing kerberos or AD [13:06:32] Yup. Which, at least the RedHat one is. [13:06:42] And I think the various other open source ones can manage Kerberos too. [13:07:02] IDMS's? [13:07:13] Identity Management System. [13:07:23] ah [13:07:33] i think it's whatever you're already doing, but with more xml [13:07:56] Indeed, and a more management compliant buzz word. [13:08:37] re the "go configure kerberos"... if these steps were well documented on the oafs page, it wouldn't be that bad, actually [13:08:38] But, boy can the commercial players sell what's essentially a cobbled together bunch of database sync scripts for a lot of money. [13:08:55] I think it's bad from a management perspective. [13:09:10] You're not just deploying a new filesystem, you're deploying a new authorization system. [13:09:19] s/authorization/authentication/ [13:09:23] (before I get jumped on) [13:09:57] fortunately, AD is kerberos, so, presumably, you don't have to deploy a new authentication anything (if a shop already has MS AD deployed) [13:10:27] --- dmontuori has left [13:10:38] Yes, if you're an AD shop. Many sites aren't. [13:11:04] And, if you plan on extending AD to your Unix boxes, you need to make sure you've got your CALs in order. [13:11:09] right... so, what are many sites? [13:11:27] if you're deploying AD anywhere, you've got to make sure you've got your CALS in order [13:11:31] A cobbled together collection of gaffer tape and string. [13:11:55] in which case it sounds like no matter what someone moves to, they may have to do a new authn system [13:12:28] so, the real sell is moving to something that's easier and cheaper to maintain and upgrade... better supported by outside vendors, etc [13:13:07] Yes. But politics means the a filesystem is a very different thing from an authn system. You want to be able to make it look to people like they're just installing a file system. [13:13:13] --- manfred furuholmen has become available [13:13:43] which means lies or deception [13:13:50] No. [13:14:07] when you installed AFS with kaserver, you could view it as just installing a filesystem. [13:14:28] so, bundle preconfigured kerberos V server w. AFS, then [13:14:34] > What AFS really needs is to need fewer instructions. [13:14:36] ++ [13:14:41] (FreeIPA is the system I was thinking of when I mentioned the RedHat IDMS) [13:15:29] --- dmontuori has become available [13:16:28] a bundled krb5 server is not right out. but it's not really the best answer [13:17:24] oh man. at LISA I chaired a talk by a vendor whose product did AD integration for "embracing the kerberos" and other stuff. He went so far out of his way to NOT talk about his product he said... nothing [13:17:31] (simo from samba team work on freeipa) [13:17:37] --- mmeffie has left [13:17:46] Tim Kirby even through him a softball, asking about integrating AD with MIT or Heimdal and he STILL SAID NOTHING [13:18:16] then at the end of hte questions, he was asked to talk about his product. [13:18:20] 0 [13:19:20] It would be interesting to see a fully thought out pts LDAP design. [13:20:07] I wonder to what extent you could implement it within the existing schema. [13:21:08] *which* existing schema [13:21:49] --- dmontuori has left [13:21:55] --- dmontuori has become available [13:24:41] *the* schema :) [13:26:44] --- reuteras has become available [13:27:08] --- reuteras has left [13:31:37] The NIS style groupofNames schema RFCyadyadyada [13:31:53] (which is what most sites will have if they're supporting Unix users from LDAP) [13:32:15] RFC2307. [13:34:06] there are some schema around 2307bis [13:34:22] Yup, but broadly speaking 2307bis is compatible with 2307. [13:34:37] posixMumble? [13:34:43] ok [13:34:44] (The major distinction is whether you have LDAP DNs or Unix UIDs denoting group membership) [13:35:18] there is another scheme that Sun is pushing that converts SIDs to Unix IDs [13:36:04] Sun are still 2307 compatible, though. [13:37:16] 2307 is some way is the migration from NIS to ldap [13:37:26] Well, yes. [13:37:43] But it's also the may that the vast majority of Unix boxes use LDAP for name service information. [13:37:59] s/may/way/. I'm even typing drunk now. [13:38:13] wish i was. [13:38:21] come here and have some of the keg [13:38:25] it's later here. you've still got time. [13:38:32] i type in the same way without .. [13:38:34] Brooklyn Brewery Oktoberfest [13:38:39] gonna need to drive home later... [13:38:59] hm. or maybe i could bus to the strip district. [13:39:56] --- dmontuori has left [13:40:02] --- dmontuori has become available [13:40:03] some problem with ldap it isn't atomic (many implementation) and you don't have transaction [13:40:54] also is fast but not so fast (nscd docet) [13:41:15] nscd is a buggy piece of ... that should be taken out and shot. [13:41:38] why bother to shoot it. just bury it alive :-) [13:41:46] :-) [13:41:53] it's not a horrible... idea. like, if you have expensive lookups, caching them is not a horrible idea. [13:42:00] likewise, the nsswitch itself. [13:42:16] with nscd you can reasonably authenticate the lookups if you key your machines, too [13:42:31] it's a shame every *implementation* kind of sucks [13:42:43] my recent expierments w. nscd and caching (on rhel4 at least) was that nscd was kinda flaky [13:42:58] the lookup of uid and gid made by program .. is very heavy [13:43:34] We're using a local ldap server with a proxy cache on it. Seems to work well. [13:45:19] proxy cache base on openldap ? [13:45:35] yup. [13:45:56] Accepts unauthenticated connections from localhost, and uses a GSSAPI secured link to a master server. [13:46:14] interesting [13:46:43] This is new. Previously we used to replicate the entire database to each client. [13:46:46] That kinda sucked. [13:46:56] i rembember openldap cache lib wasn't very good .. [13:47:35] proxycache isn't a library [13:47:35] i do a similar thing, but sometime the slave loose sync [13:48:16] We seem to be pretty good so far. The guy who implemented it does a lot of monitoring to make sure we stay in sync. [13:49:04] yes, but some years on client side you had a cache [13:49:12] ago [13:51:10] openldap is very fast, probably is a good meta-directory or ldap-proxy..but you must handle with care .. [13:51:40] do you use openldap also for master ? [13:52:58] Yes. [13:53:16] Although it doesn't actually master much data. It's mainly fed from an assortment of other databases. [13:56:03] i'd like to move on fedora directory for master side .. i wil do some experiment [13:56:16] We looked at Fedora DS. We weren't impressed. [13:56:30] It's still got many of the problems of the old Netscape code base. [13:57:26] proxycache> nice [13:57:33] yes, but with netscape i did milions of users [13:57:49] I know of sites that are doing millions of uses with OpenLDAP. [13:58:02] We're not of that scale. [13:58:36] with some corruption :-) [13:58:49] hi matt [13:59:00] hi manfred [13:59:05] With ldbm, perhaps. I think bdb is pretty stable. [13:59:11] hdb these days, ne? [13:59:28] hdb and bdb are essentially identical except that hdb allows subtree renaming. [13:59:40] yes, you'd know a lot about that, I suppose [14:00:18] nscd is a pile of crap. :) The OpenLDAP folks have a lot of hope for the caching stuff to make it obsolete. [14:00:25] yes use the same libs [14:00:48] Well, we're pretty much using proxy cache instead of nscd now. [14:01:02] --- Moose has left [14:01:19] Although, we've never done a direct comparison - nscd loses for many reasons before we consider speed! [14:01:25] We have hundreds of thousands of users in OpenLDAP, but not millions yet. [14:01:40] * Russ first learned to hate nscd for its DNS caching before I ever even looked at the LDAP bits. [14:01:49] Howard Chu has done some tests that are several orders of magnitude larger than millions. [14:01:57] yes [14:01:57] When I realized that it completely ignores DNS TTLs when caching DNS records, that pretty much did it. [14:02:12] i saw the presentation to samba conferece 2007 [14:02:22] http://www.sambaxp.org/index.php?id=122 [14:02:27] is the faster [14:03:09] one of the biggest problem with nscd .. is when the people change the password .. [14:03:12] OpenLDAP really looks like best of breed to me. I still kind of want the repackaged version of OpenLDAP with the same code but less developer hostility, but oh well. :) [14:03:35] russ: developer hostility? [14:03:53] The OpenLDAP developers are kind of notorious if they think you're asking stupid questions. [14:03:55] They can be pretty aggressive if they think you're wrong. [14:04:02] Or stupid, as Russ said. [14:05:39] ok, I suppose--sometimes those lists see some pretty crazy posts, so, maybe it has some justification [14:07:02] I think my most memorable experience there was getting yelled at for pointing out that having the library by default read a configuration file out of the current working directory was a potential security risk. [14:07:19] who yelled at you for that? [14:07:22] Howard. [14:08:13] The specific case that triggered the conversation was nss-ldap. Being told that nss-ldap was crap was not really a useful resolution to that conversation. [14:08:35] Riiight. [14:08:38] I think that code is actually still in there. [14:08:43] At some point, I want to take a closer look at nss-ldapd [14:08:51] Yeah, nss-ldapd looks a lot nicer. [14:09:35] We have had assorted problems with nss-ldap, in particular with it closing sockets, and playing with signals that seriously upset the application that has unwittingly loaded it. [14:09:43] Most of my run-ins have been because I try occasionally to help out with the Debian packages, and Debian does some things that the OpenLDAP developers really don't want to support. But there also don't seem to be any good alternatives. [14:10:12] Yes. The whole Debian GNU-TLS thing doesn't seem to have made them many friends in the OpenLDAP community. [14:10:16] No symbol versioning in libldap being one of the big ones. Needing libldap-r is another. [14:10:35] Oh, I wasn't even counting that. Howard has actually been great about GnuTLS. [14:10:47] (and don't get me started on GNU-TLS not supporting RSA-MD5 certificates. That's currently biting us in a big way) [14:11:03] He bitches and moans and complains about it all the time, but what he actually puts into the code base has been great and he's been very responsive on fixing problems. [14:11:47] * Russ is generally unhappy with the state of the TLS world. [14:11:56] But doesn't have any time to really do anything constructive about it. [14:12:13] All three of the major TLS libraries are really annoying in different ways. [14:12:19] I don't have time to do anything, either. [14:12:37] libldap doesn't use symbol versioning? [14:12:44] libldap doesn't use symbol versioning. [14:12:51] Debian adds it for the sake of our sanity. [14:12:59] But the fact that all of our X509 certificates are broken by a 'security' decision made by the GnuTLS folks is making me very sad. [14:13:00] This is one of the things that gets us yelled at for "breaking their build system." [14:13:21] Well, if their build system weren't broken.... [14:13:45] Yeah, that's kind of my opinion. [14:13:51] --- SecureEndpoints has left [14:14:41] Note that I think you can get away without symbol versioning if you are sufficiently careful. Unfortunately, "sufficiently careful" means you need to carefully select what versions of libraries you link things against so that any given application only has dependencies, direct or otherwise, on one version of each library. And it means that things that load plugins, including PAM and NSS, need to use RTLD_GROUP. [14:15:07] (which almost kills you, because glibc doesn't have RTLD_GROUP, but RTLD_DEEP_BIND is a close-enough approximation) [14:15:42] The problem with not having symbol versioning in Debian is that when there's a new major OpenLDAP release, there's always some period when some stuff is built with the new library and some stuff is built with the old library. [14:15:50] Without symbol versioning, stuff segfaults all over the place during the transition. [14:16:13] pam-ldap and nss-ldap usually make this problem way worse, but it would exist even without them. [14:17:25] And yeah, PAM and NSS could probably make this easier. [14:18:25] I used to know something interesting about how all that stuff worked... I think it's the reason why back-perl is still broken in Debian's build of OpenLDAP due to some libtool thing. [14:21:26] --- manfred furuholmen has left [14:29:32] right. we've managed here without symbol versioning, but we have a lot tighter control over what is released when, and one of the things we do is arrange so that when we have chains of library dependencies, if the soname of one library changes, then the sonames of libraries built against it also change. [14:29:57] But the problem is much larger and messier for Debian, because there is less/no control over when machines take what updates. [14:30:27] --- tkeiser@sinenomine.net/owl has become available [14:30:30] We've been bitten in the past by situations where we have nss libraries built against one library version, and the application built against another. That tends to go badly wrong. [14:30:54] Yeah, and you can't just change all of the sonames as readily in Debian because some of the sonames are important for cross-Linux binary compatibility, which occasionally does matter. [14:31:13] It's nice to be able to run commercial software when you have to. [14:31:42] But there again, we run an OS that ships betas with C compilers whose register allocation is broken, so what can I say :) [14:31:43] The solution for PAM and NSS really is getting the dynamic linker to help you isolate modules from the application. For PAM this is easy; we did a pam_isolate module that directly loads another module using RTLD_GROUP and calls it. For NSS that can be done, but the symbol names in NSS are dependent on the module name and there is no per-module configuration, so you end up having to build nss_isolate separately for each module you want to protect. [14:34:23] We noticed the problem in other places before it ever bit us in PAM or NSS, fortunately. [14:34:37] Oh, I suspect the place we first noticed it was in cyrus sasl plugins [15:29:49] --- edgester has become available [15:50:01] --- edgester has left: Replaced by new connection [15:50:02] --- edgester has become available [16:56:02] --- SecureEndpoints has become available [17:21:29] --- dlc has become available [17:25:03] --- matt has left [17:25:11] --- dmontuori has left [18:02:00] --- stevegt has left [19:04:24] --- edgester has left [20:46:43] --- stevegt has become available [22:05:50] --- Russ has left: Disconnected [23:02:29] --- reuteras has become available [23:33:11] --- dev-zero@jabber.org has left