[00:12:19] --- dev-zero@jabber.org has become available [00:15:07] If we are changing the way we open cache files on Linux, I'd like to see before and after performance numbers... [00:23:54] --- Russ has left: Disconnected [00:28:47] --- dev-zero@jabber.org has left [00:28:57] --- dev-zero@jabber.org has become available [00:29:25] --- haba has become available [00:35:50] --- kaj has become available [01:20:43] --- kaj has left [01:30:06] --- abo has left [02:22:20] --- kaj has become available [02:25:44] --- dev-zero@jabber.org has left: Lost connection [02:39:22] --- dev-zero@jabber.org has become available [02:42:27] --- Jeffrey Altman has become available [02:42:37] --- jaltman has left: Replaced by new connection [02:42:38] --- jaltman has become available [03:45:35] --- dev-zero@jabber.org has left: Lost connection [04:25:33] --- haba has left [04:25:45] --- dev-zero@jabber.org has become available [04:26:15] --- squinney has become available [04:44:08] > If we are changing the way we open cache files on Linux [04:44:09] huh? [04:45:56] "i have code for merging darwin/solaris and linux path-based cache." [04:46:14] Oh, and I have a fix for UKERNEL breakage. But why is UKERNEL the only place we use the system xdr? [04:47:09] we used to use the system one in the kernel but then ran into problems where we couldn't just plug in 64 bit support [04:47:31] Okay [04:47:32] and the back-scroll on "code for merging": solaris and macos get the linux way. [04:47:45] Open by filehandle? [04:48:03] open by path, and then handle what happens to the path internally. for linux, fh [04:48:09] Okay, cool. [04:48:22] which is how linux works. the AFSOPs pass a full path [04:48:48] We're going to need some general purpose interface for communicating capabilities between userspace and kernel - and those capabilities need to be more than just bit masks. [04:49:15] (Marcus and I both need to communicate encryption type support, for example) [04:50:08] As much as I disliked it in Edinburgh, having thought further, I wonder if Marcus's sysctl-like interface is the way to go. Perhaps replaced with actual sysctl on those platforms that support it. [05:06:16] --- haba has become available [05:10:22] --- Simon Wilkinson has left [05:10:23] --- Simon Wilkinson has become available [05:10:32] --- Simon Wilkinson has left [05:11:33] --- Simon Wilkinson has become available [05:15:12] sysctl would be fine. it will take longer to test than what russ is probably hoping. [05:15:59] Yeh. I'm just reluctant to deploy something, then rip it out again. And I'd rather not have two ways of doing stuff. [05:16:41] agreed. is there something simple we can do "for now" that's always useable, i wonder. perhaps without adding a new anything [05:16:46] If we're happy that we'll use Marcus's stuff everywhere that doesn't have sysctl, and sysctl where we have it, we could solve Russ's problem by just using sysctl. [05:16:53] Russ only cares about Linux... [05:17:17] (well, that is, Russ's problem only applies to Linux) [05:17:21] have afsd try the AFSOPs for fh, if it fails, assume the kernel has no fh and set up the other way? [05:17:42] that's still a lot of new code to test. this way is almost none [05:17:50] Are they different ops, and not just the same Op with different arguments? [05:18:20] But yeh, if testing the ops works, then doing that would seem like the easiest plan. [05:18:25] istr CACHEINODE versus CACHEFILE [05:23:19] actually, given how non USE_FH osi_get_fh works at least in 1.5, why can we not just always use AFSOP_CACHEFILE? [05:23:46] That would be good if we can. [05:24:11] Do we care about people trying to use 1.4 afsds against 1.5 kernel modules (or vice versa)> [05:25:19] do i? no. i don't even care about cross-minor-version, personally, but it's at least a little more forgiveable [05:57:31] --- dev-zero@jabber.org has left: Lost connection [06:11:15] --- dev-zero@jabber.org has become available [07:02:05] --- jaltman has left: Replaced by new connection [07:02:06] --- jaltman has become available [07:29:50] and now that i have the right kmod in place, i can start the mac client with linux-style paths. let's see if i can also shut it down [07:30:40] ok. i'll push that shortly. need to change locations [07:41:20] --- deason has become available [07:43:35] --- reuteras has left [07:49:52] --- jaltman has left: Disconnected [07:50:08] --- jaltman has become available [08:12:06] so what am i missing? it looks to me like if we just change afsd.c to always call call_syscall(AFSOP_CACHEFILE, fullpn_VFile); and never call_syscall(AFSOP_CACHEINODE, inode_for_V[currVFile]); it will work at least on every linux and presumably everywhere entirely, since that's the same way CacheItems et al are passed in [08:12:32] no version interface needed at all [08:12:36] (for this) [08:12:56] too old to have CACHEFILE? don't run ubernew afsd. [08:18:35] if i'm right we could actually go filesystem-agnostic for cache on every platform if so desired. [08:23:32] as a note, btw, we don't need to worry about the afs cache for spotlight: /private/var not indexed. [08:24:29] --- haba has left [08:25:41] Cool. [08:26:02] Your afsd changes sound like they make sense, but I haven't read the kernel module code to verify. [08:27:56] well, AFSOP_CACHEFILE passes a path, not an inode number. all the *Items mechs pass a path already. presumably, passing paths works. plus, the mechs to support open-by-path work: we use them already [08:28:01] jaltman - I have put the krb5.ini and ksetup info in that folder in afs [08:28:14] so there shouldn't be anything exciting about doing this [08:28:22] CNFAD is the windows short name for our DOMAIN - AD.CNF.CORNELL.EDU [08:28:52] sure, but AD.CNF.CORNELL.EDU does not have any configuration info for the openafs network provider [08:29:00] Cool. Let's do it then, less duplication of code is good. [08:29:21] why would it need it now when it didn't in XP? [08:29:44] anywa, I'm not logging in as dwb7@AD.CNF.CORNELL.EDU [08:29:53] I'm logging in as dwb7@CIT.CORNELL.EDU (the unix kerberos realm) [08:29:57] according to Wnidows you are [08:30:12] which does a cross realm authn to authn me to AD.CNF.CORNELL.EDU [08:30:13] according to Windows, you are logging in as CNFAD\dwb7 [08:30:37] well, windows is wrong [08:30:40] and as far as the network provider is concerned, what Windows tells it is all it knows [08:31:03] then file a bug with Microsoft [08:31:34] so, yes, I am logging in as CNFAD\dwb7 (since in the end I'm logging into the windows domain), but that's not what I'm putting in in the login dialog [08:32:39] out of curiosity, is there some way to work around this bug by specifying realms for CNFAD ( we have two... soon three MIT Kerberos realms we cross realm authn for windows ) [08:33:11] I don't understand why you need a work around. Specify the configuration information that is required and it will work [08:35:37] according to the docs, Realm specifies the Kerberos v5 realm that should be appended to the first component of the Domain login username [08:35:39] if you are mapping N MIT realms to 1 AD domain and Windows is reporting the AD domain at logon, there is no method to map back to one of N realms. You get to choose one of them [08:35:57] yeah... that doesn't work [08:36:00] because we have N realm [08:38:45] bwah... do I have to pay MS to report a bug? [08:40:29] ok. 1132 is the macos/solaris path changes. 1133 is the grand-afsd-unification [08:41:58] Reading 1132 already. Whitespace :) [08:41:59] --- dev-zero@jabber.org has left: Lost connection [08:42:09] yeah yeah wanker [08:42:21] most universities have PSS support contracts. [08:42:45] What stops me from using this interface to scribble over any file on the system from the kernel? [08:43:50] if you're root, you can already do that. if you're not root, this interface doesn't work. [08:44:03] note that this does not add a new interface in any case [08:44:11] That's not quite true. On some platforms the kernel can do things that root can't. [08:44:25] once i'm root the kernel is mine [08:44:35] Not on Linux [08:44:52] on linux, you'll use fh anyway [08:45:01] Not on Solaris, either, I'm pretty sure. I can stop you from doing lots of things as root. [08:45:03] --- dev-zero@jabber.org has become available [08:45:45] if you think the mech for caching paths should be changed that's fine. it's out of scope for this, which does not add it in any case [08:46:02] put otherwise: "we already use this interface. you're too late" [08:46:14] Yeh. I think these changes are fine. [08:47:39] i'm pushing the decode-panic thing unless someone objects to using `` to execute shell commands and has a better idea [08:48:27] actually, screw it. i'm pushing it and if someone objects, they can object in patch form, or fail to actually object [08:48:55] > On some platforms the kernel can do things that root can't. Yeah, not on any real system. If you can load a kernel module, you can do anything. [08:49:13] Yeh. There are 'real systems' where root can't load a kernel module. [08:49:20] those aren't real systems :) [08:50:02] decode-panic thing - this for users to run, or to run on o.s.e? [08:50:15] "yes" [08:50:23] Because my reaction to backticks varies according to where the code is being run, and where the input comes from. [08:50:42] the input comes from the person who runs the script, who is running the script as themselves. [08:50:48] so, you wanna screw yourself? go nuts [08:51:05] for o.s.e we'll want to confirm my regexes are right [08:51:09] Yeh. That's fine. Backticks are fine there. I'd just be a bit more concerned about a web app. [08:51:32] I suspect we can't run this on o.s.e, anyway. It won't have a gdb with the necessary Apple bits. [08:51:45] but the worst you could do, istr, is open a file whose name had a different set of numbers than an actual version number by submiting a fake backtrace [08:51:58] well, no. we'll have to push them to some other system [08:52:06] which could be done by ssh with a key, really [08:52:12] True [08:53:17] --- deason has left [08:53:53] --- deason has become available [08:58:05] wrt afsd CACHEFILE... we don't need afsd to work with linux pre-2.6.24ish (or whatever version it is)? [08:58:56] Nah, we decided to stop supporting all old Linux kernels. We've seen the light, and embraced the Linus way. [08:58:58] I mean, that afsd is uberner _now_, but trying to run 1.6 clients on say rhel4/5 doesn't seem unreasonable to me [08:59:06] hah [09:01:46] --- deason has left [09:02:09] CACHEFILE works with non-USE_FH, or should [09:02:38] because, again, uses the same mechanism we already use globally for *Items files [09:03:12] so my expectation is it will work because it already works or it will fail because it already fails [09:03:30] And the way to test that is to try building with those patches on RHEL5, and see if we go boom. [09:04:34] --- squinney has left [09:05:58] wonder where i put my rhel5 vm [09:06:04] "not on this disk" [09:12:15] --- dev-zero@jabber.org has left: Lost connection [09:22:03] --- dev-zero@jabber.org has become available [09:41:30] --- Jeffrey Altman has left [10:01:38] --- Simon Wilkinson has left [10:01:38] --- Simon Wilkinson has become available [10:02:56] --- Russ has become available [10:33:28] --- kaj has left [10:38:23] --- Russ has left: Disconnected [11:10:49] --- Russ has become available [11:11:07] Oh, ack, was the USE_FH change in 1.4 as well? For some reason I thought it was only in 1.5. [11:11:30] --- deason has become available [11:12:02] is it? i keep looking at the wrong tree. hang on [11:12:14] I didn't actually look. [11:12:22] I thought it was in 1.4; since the inode-only way went away in recent kernels [11:12:23] Given that it's a change for Linux kernel compatibility, it makes perfect sense that it would be. [11:12:26] The iget() change was, yes. Because the kernel wouldn't let us do what we needed to. But I think the change that went into 1.4 was significantly smaller in scope. [11:12:33] Except 14.11 is already working on 2.6.32. Hm. [11:12:44] So we must have done something differently on 1.4. [11:12:49] Since 1.4.11 doesn't have this mismatch problem. [11:13:04] confirmed. in 1.4 [11:14:09] it looks like the 1133 change will "just work" with 1.4.x [11:14:23] mod application of the diff [11:14:27] * Russ wonders why 1.4 is already working for me with an afsd built with --without-kernel-module. [11:15:03] (1.4.11, that is. I'm assuming this wasn't pulled up post-1.4.11, since we would have had to have fixed iget() before then anyway.) [11:15:16] The change is different. [11:15:24] no, wait [11:15:38] Mainly the reason why I'm asking is that I don't think we should pull up Derrick's change necessarily unless 1.4 has the same bug. [11:15:53] yeah, the change is very different. no pullup needed [11:16:00] or required [11:16:22] With your change, Derrick, do we still want a capability flag? [11:16:26] Er, op? [11:16:27] no [11:16:32] well [11:16:45] we don't need one now. we still want capabilities of some sort but it's not urgent [11:17:18] I have doing something capabilities like on my list for rxgk. Marcus has something in rxk5 [11:17:48] Okay, cool. [11:17:53] Then I'll continue, but not urgently. [11:17:59] It still seems like a fun project. [11:18:17] Yeh. Well, Marcus has some code to give us something that looks like sysctl. [11:18:22] And an opportunity possibly to do some refactoring of the afsd code at the same time, since it's kind of an #ifdef maze in places, although I suspect Derrick just cleaned up some of that. [11:18:51] I want something like sysctl too, or at least something where I can communicate more parameters to the cache manager at start than we can right now. [11:19:07] Because I want to be able to enable setcrypt immediately, not at some arbitrary but hopefully close period after afsd starts. [11:19:16] Likewise with setting the sysname. [11:19:39] --- deason has left [11:19:41] And then I can drop fs from the openafs init script dependencies, which means that openafs can then provide instead of require $remote_fs, which is the correct LSB init setting for AFS so that people can run with /usr in AFS. [11:20:10] Adding more command-line options to afsd is bad business. [11:20:20] It should be a configuration file somewhere. [11:20:38] With maybe something sysctl-y to push it into the kernel. [11:20:40] --- deason has become available [11:20:44] Or some other way to pick up the parameters at start. [11:20:47] but that's a larger project. [11:23:29] jaltman - assuming MS says that the new behavior is by design and won't fix the bug, how about adding the ability to configure multiple realms for a login domain? [11:24:29] Russ: On Linux, I suspect that it probably should just be sysctl. [11:24:51] Yeah, that would be great. [11:24:58] Then I can use all our existing mechanism for sysctl settings. [11:25:04] We could also then share settings with kafs. [11:29:30] there. made afsd look more like what marc suggested. [11:29:49] still some ugly there [11:33:40] --- deason has left [11:42:54] --- haba has become available [11:44:55] jaltman - this is where things first differ... [11:45:03] in Win7... the afslogin shows: In GetDomainLogonOptions for user [dwb7] in domain [] [11:45:37] under XP, that shows "GetDomainLogonOptions for user [dwb7] in domain [CIT.CORNELL.EDU]" [11:49:04] --- deason has become available [11:50:29] --- deason has left [12:13:19] --- kaj has become available [12:42:55] so, either MS isn't passing the wrong thing, it's passing either nothing or using a different field than before [13:11:35] --- dev-zero@jabber.org has left [13:31:38] --- jaltman has left: Disconnected [15:25:59] --- jaltman has become available [15:29:19] --- mdionne has become available [15:31:20] David, the problem with supporting multiple realms per AD domain is that the way the network provider works is by constructing a principal name and guessing that the password provided to login to the Windows machine will work for it at the KDC. Supporting multiple means failing N of possible principal names before maybe finding one that works. The risk of principal name collision increases with each realm you add. If the realms are configured for automatic lockout, the risk of locking out an innocent user increases as well. [15:32:38] If Windows is failing to provide a domain when a Kerberos realm is in use, that is a change in behavior. [15:32:49] Although I am very sure it is a bug [16:20:15] --- jaltman has left: Disconnected [16:21:31] --- dev-zero@jabber.org has become available [16:33:55] --- jaltman has become available [17:09:22] --- dev-zero@jabber.org has left [17:10:15] --- Russ has left: Disconnected [17:28:05] --- Russ has become available [17:38:07] --- RedBear has become available [17:38:45] jaltman - I agree with you completely on both counts (downsides of multiple realms and it prolly being a bug) [17:39:18] spent some time today trying to find if perhaps MS had changed the structure to put the Domain info in some other member [17:39:27] so, prolly a bug [17:39:50] and have a call in to find out what Cornell's support situation is with MS [17:46:31] --- RedBear has left [17:47:21] --- cudave has become available [18:37:10] --- deason has become available [18:47:27] --- deason has left [18:54:10] --- mdionne has left [18:54:10] --- mdionne has become available [18:54:53] --- mdionne has left [20:11:01] --- kaj has left [20:23:50] --- mho has left [20:24:08] --- haba has left [20:24:19] --- haba has become available [22:15:06] --- reuteras has become available [22:35:37] --- Simon Wilkinson has left: Lost connection [23:50:40] --- Russ has left: Disconnected