[00:05:37] --- haba has left [00:16:46] --- kaj has left [00:16:46] --- abo has left [00:39:23] --- jaltman has left: Disconnected [01:26:54] --- kaj has become available [01:38:04] --- haba has become available [01:52:45] --- dev-zero@jabber.org has left [02:04:38] --- kaj has left [02:06:41] --- Rasmus Kaj has become available [02:41:45] --- Jeffrey Altman has become available [04:01:45] --- Simon Wilkinson has become available [04:17:49] --- dev-zero@jabber.org has become available [05:07:21] --- haba has left [05:10:31] --- haba has become available [05:52:22] --- jaltman has become available [05:52:50] --- meffie has become available [06:24:50] --- mho has become available [07:06:19] --- deason has become available [07:53:07] --- Russ has become available [08:28:43] --- shadow@gmail.com/owlCF7CAB78 has become available [08:28:44] --- shadow@gmail.com/owlCF7CAB78 has left [08:29:35] --- shadow@gmail.com/owlA18F1041 has become available [08:32:34] --- Simon Wilkinson has left [08:52:13] --- jaltman has left: Disconnected [08:52:48] --- reuteras has left [09:10:08] --- haba has left [09:52:46] --- Russ has left: Disconnected [09:53:01] --- Simon Wilkinson has become available [10:07:19] --- Russ has become available [10:09:35] --- Rasmus Kaj has left [10:09:38] --- kaj has become available [10:12:25] --- canehan has become available [10:15:39] --- kaj has left [10:24:39] Hi! I am having an issue with tokens disapearring using 1.4.10 or 1.4.11 on 2.6.18-164.9.1.el5 linux kernel. [10:24:53] Okay. [10:24:59] When do they disappear? Immediately, or after some period of time, or...? [10:25:03] When do they disappear? [10:25:10] Are you using pam_keyinit? [10:26:55] After a few minutes. We are using keyinit. [10:27:06] Is there anything in dmesg? [10:27:33] Not a thing [10:28:03] I pushed "fs messages" to all, but I suspect it is useless. [10:28:25] Does pam_keyinit come before or after your AFS PAM module in the stack? Which AFS PAM module are you using? [10:34:45] After. [10:35:22] Precisely, keyinit comes after pam afs. [10:36:01] Put them the other way round. [10:36:11] keyinit deletes all the hard work afs has just done [10:36:20] For the AFS PAM module, my collegues should use nothing special. [10:36:22] also some of the not so hard work [10:37:23] Basically, keyinit should always be at the start of your PAM stack - it initialises all of the user's keyrings. If you have a PAM module that modifies keyrings (like the AFS ones do), they have to come after it in order to work properly. [10:37:36] I'll give it a try. Thank you. [10:39:13] Do you have any recommandation regarding AFS PAM module ? [10:39:59] Russ's pam_afs_session, available from www.eyrie.org [10:40:28] (Providing you're not still using kaserver) [10:41:04] and if you;'re still using kaserver, stop [10:41:08] http://www.eyrie.org/~eagle/software/pam-afs-session/ is the full link [10:41:33] I'm quitting. [10:41:37] I swear. [10:41:56] Thanks again. [10:43:31] also, the reason you don't lose tokens right away is probably because your pag is getting tracked via groups in addition to via keyrings [10:43:40] --- jaltman has become available [10:43:43] it can be a bit confusing, but I believe it's being worked on [10:43:58] It's gone. In 1.5.x, and for new kernels, we always trust the PAG> [10:44:45] you mean we always trust the keyring? [10:44:55] (Older kernels don't have their own PAG structure, and so it's harder to carry the keyring context around with us) [10:44:59] I allready asked to set up a box with 1.5.68. I can report here if you like. [10:45:01] Sorry, yes - we always trust the keyring. [10:45:21] can I assume we're not going to bother trying to backport that to 1.4? (not requesting that, just wondering) [10:45:42] It's a behaviour change, so I think we'd only backport it if the kernel made us. [10:45:49] no, for the simple reason of it's a behavior change [10:45:59] And, as far as I'm concerned 1.4 is ~dead for new stuff. [10:46:07] that's the goal. [10:46:17] want new stuff? run 1.5 [10:46:22] canehan: Testing of 1.5.x is always welcome - but you won't see this particular change on the kernel you're running. [10:46:27] esp for the client, where it's fairly boring to run [10:46:36] I think that if you run pam-afs-session in the auth stack, you're still screwed if you have pam_keyinit in your session stack at all. [10:46:48] I intend to fix that in the next release. [10:49:39] I suspect that, in the long run, the kernel module shouldn't set up the task session at all, and should just use whatever session is already there when the pioctl gets called. The library providing setpag() would be responsible for building the session. [11:11:37] --- jaltman has left: Disconnected [11:15:13] --- Simon Wilkinson has left [11:15:19] --- canehan has left [11:15:46] --- Simon Wilkinson has become available [11:18:43] --- jaltman has become available [11:20:35] --- kaj has become available [11:43:08] --- dev-zero@jabber.org has left [12:31:29] --- dev-zero@jabber.org has become available [12:44:03] --- dev-zero@jabber.org has left [12:44:14] --- dev-zero@jabber.org has become available [13:41:08] --- meffie has left [13:55:04] --- Simon Wilkinson has left [14:15:57] --- dev-zero@jabber.org has left [15:08:05] --- Simon Wilkinson has become available [15:33:34] Would anyone care if I built an rxgen which didn't create such butt-ugly accessors for opaques? [15:33:53] typedef RGXK_Data opaque<>; [15:34:24] gives struct RGXK_Data with members RGXK_Data_len and RGXK_Data_val, which just aint pretty. [15:35:29] what would they be instead? [15:35:39] len and val [15:36:22] There would have to be a switch to enable this behaviour, of course, because we have out of tree users of rxgen. [15:36:24] Simon: I think it should be possible for extended callbacks to work with the clear security class if no one cares about security [15:36:41] Sure, then you deliver your callbacks over clear. [15:37:51] My argument is that unless you can generate a secure binding between the setting and breaking steps, there isn't actually any security there, whether you encrypt the callback channel or not. [15:37:58] agreed [15:38:45] I think there is confusion caused by the discussion of secure extended callbacks in the rxgk draft when the topic really needs to be addressed properly in the extended callbacks draft [15:39:18] --- deason has left [15:40:51] My suspicion is that AFS_SetCallbackKey belongs elsewhere, and only the rxgk structures belong in the rxgk document. [15:41:40] I don't have a clear view of whether that 'elsewhere' is in the extended callbacks draft, or whether it's in another document. [15:42:49] The issue is actually really thorny. If I'm getting an extended callback which contains actual modified data, but the user who issued the original RPC has unlog'd, should the cache manager still be able to read the callback response? [16:30:51] --- deason has become available [17:43:33] I wonder when the Elders are going to have a discussion with the community about the SFC proposal. [17:44:50] Once we have something to have a discussion about, basically. We're still working out what we want specifically to ask for. [17:45:55] Well, see, that's the thing. I think that's a topic for discussion. By "discussion", I don't mean "announcement". I mean an actual discussion by which the community participates in the process of making a very important decision for the project, rather than simply being told about it after the fact. [17:46:25] I thought that part started when I sent out the message explaining that we wanted to approach the SFC. [17:46:30] You know, the one that absolutely no one replied to. :) [17:47:21] We also mentioned it at the workshop, not that that's a replacement for e-mail, which is why we also sent out the e-mail. [17:47:55] That was the general idea of "join the SFC". Once we have a more specific "and this is exactly what that means" document, then I think we need to have another round of discussion. [17:48:19] And actually, I shouldn't say that no one replied. A few people thanked me for sending it. [17:48:26] It's more that no one really had anything to say in discussion of it. [17:48:38] I don't seem to see that in my archives. When was that? [17:48:48] One sec... [17:49:33] I am tempted to forward to -devel the message they sent me, just to make sure everyone interested knows what's going on. [17:49:40] https://lists.openafs.org/pipermail/openafs-announce/2009/000303.html [17:49:58] --- jaltman has left: Disconnected [17:52:21] Ah, that. An announcement. [17:52:28] We could do that. I'm not sure how useful it is to talk about their template for an agreement without having the additional bits that need to be filled in. [17:52:44] Well, as you said, I think it's time for an update, and an explicit request for input. [17:53:12] We have meeting notes from this morning's meeting to send out. Probably not a bad idea to send out the update in conjunction with those meeting notes. [17:53:22] I believe the actual template was only in what they sent to Jeff, and not what they sent to all the contributors on their list. [17:53:39] Oh, yeah, you're probably right now that I think about it. [17:54:20] * Russ doesn't remember what their mass mail said. [17:55:02] But IIRC it didn't say much that was all that detailed. I certainly can't see any problem with sending it to the lists, though. It came in while I was on vacation and I read it but then didn't do anything with it. [17:55:45] Well, we'll see what transpires... [18:00:14] OOC, is there anything specific that you want to be sure is discussed, so that we can be sure to highlight it? [18:00:27] Mind you, I don't have any objections, provided all of the details are taken care of. But this should be a community decision. The Elders are far too glib about making decisions on their own, based on their own biases, and without consulting the community. And this is especially bad since they are essentially accountable to no one, and have decided to "put on hold" (your words) the changes that would fix that. [18:00:50] It's basically a money handling thing to me, and the whole thing seems reasonably routine, so I'm not doing well at anticipating what other people might want to talk about. [18:01:29] if you have a magic pool of money, the foundation could be unmothballed. i'll wait while you find it [18:01:34] Well, I haven't seen the template, since Jeff didn't exactly share it with the community or anything. But I actually doubt there's anything specific that needs to be dealt with which you haven't thought of. [18:01:39] This is bias from me doing Usenet administration for way too long, but I always have trouble with the idea of a community decision when the community has no well-defined way of making decisions. [18:02:04] Community discussion I can wrap my brain around fairly well. [18:02:10] I'm not quite sure what community decision really means. [18:03:01] (The SFC provisions are actually really nice. In particular, they deal remarkably well with what happens if we decide we want to take our money and go home.) [18:03:41] But see, Derrick, you're unnecessarily binding governance changes to the foundation, which has its own set of goals and requirements. Yes, we need a certain steady source of funding to set up the foundation, which in turn really exists mostly to manage money. Joining SFC seems to solve a number of those problems. It is not an excuse not to deal with the governance situation. [18:04:29] Yeah, and we tried to explicitly say that. The SFC is really a money thing, not a governance change. The governance bits of our relationship with the SFC would get filled in with the current Elders structure (aka, no change as part of this). I agree that governance is a separate problem that we need to solve. [18:04:50] But see, Russ, Usenet _did_ have a form of community decision making, in that pretty much all aspects of its operation existed at the collective pleasure of individual administrators, who in turn were either accountable to or empowered to set policy and speak for their users. [18:05:07] Yeah, which completely failed to ever make a decision. [18:05:26] I'd rather see the governance structure have been fixed a year ago, and the governance bits of the SFC thing filled in with a useful structure. [18:05:30] That's the problem that I'm getting at -- the problem with community decisions is that there's usually no way to reach closure. How do you know when you've made a decision? [18:05:48] On Usenet, the answer was basically "never" and people just kept arguing about things into eternity. [18:06:07] As a result, it was basically impossible to ever change anything substantial on Usenet ever. [18:07:39] Either that, or you tried to run a vote with an ill-defined voting population and constant voting fraud, which was also loads of fun. [18:09:52] I generally agree with the criticism that the Elders don't communicate enough, though. [18:10:24] I think that your point about not enough community discussion may partly come down to that. [18:10:55] You don't have to make every decision by direct democracy. But there needs to be something. I'm getting tired of the Elders saying "Surprise! The Elders have decided that OpenAFS is going to do X", as if they're the only ones whose input or opinion was even worth considering. I'm still really pissed off about the surprise logo announcement at NJIT; not only was the community not given the opportunity to submit proposals or offer opinions on candidate logos, they weren't even given an opportunity to express an opinion on whether the project needed to spend its money on that. It's a cure logo, but I don't see any change in how well the software works as a result. [18:11:03] The other side of that, though, is that we don't really get much feedback. We get the definite impression that most people don't really care. [18:12:12] Hm, one thing that I take away from that is that it would have been helpful to say, instead of "the Elders decided" to say "the Elders propose, said decision to be finalized after considering input from the community, please discuss". [18:12:16] i have a cynical take. i won't share it now. instead, i will pour myself a glass of something and end the productive portion of my day, instead of fixing fsevents on macos. [18:14:32] Not a bad idea. [18:15:10] It would also help if we were better at getting meeting notes out, which is partly my fault. [18:15:27] I should do that, too, all except the pouring part. But I still have bunches of volume moves to do and really want to get the next batch or two done before 2300. [18:15:29] I write the meeting notes during the meeting; I could take the next step and finalize them and propose them for publication rather than, you know, not. [18:15:50] Trust me, I know all about sucking about getting minutes out. [18:15:56] It would probably also be helpful if we were better at meeting more frequently. [18:16:18] the right way to do that is to pick a regular time to meet, and schedule a year worth of meetings. [18:16:24] Yeah. [18:16:26] and if you can make it, great [18:16:39] And if you can't, oh well, that's what quorum rules are for. [18:16:50] Yeah, that's not a bad idea. [18:17:00] ... and mailing lists [18:17:36] Yeah, we're not bad on discussing things on mailing lists. [18:19:37] Anyway, definitely message heard about asking for community input on the SFC agreement. [18:26:55] And now I go home. [18:27:01] --- Russ has left: Disconnected [18:50:28] --- Russ has become available [20:01:43] --- kaj has left [20:33:45] --- mho has left [21:30:26] --- jaltman has become available [21:57:02] --- deason has left [22:08:13] --- reuteras has become available [22:15:56] Jeff, the funny thing is that today the Elders met to discuss the invitation from the SFC to join as a member organization. In order to provide the community something to consider we have to determine what the proposed contract might look like and what the known issues are. I tentatively have a meeting with the SFC on Friday to determine what the range of possibilities are. When there is something to discuss, we will approach the community. [22:39:59] --- kaj has become available [23:08:41] --- kaj has left [23:26:55] --- Russ has left: Disconnected [23:40:10] --- jaltman has left: Replaced by new connection [23:40:11] --- jaltman has become available [23:42:17] --- haba has become available