[00:42:58] --- haba has become available [00:58:38] --- jaltman has left: Disconnected [01:00:13] --- jaltman has become available [02:03:22] --- kaj has become available [02:07:43] --- haba has left [02:49:27] --- haba has become available [02:53:53] --- Simon Wilkinson has become available [03:00:38] gerrit should be sending email once again ... [03:15:46] --- reuteras has left [03:17:31] --- reuteras has become available [03:24:38] --- pod has become available [04:08:20] --- Simon Wilkinson has left [04:14:16] with regards to the version number proposal. my concern is that few people remember to run regen.sh every time they pull in changes from git and worse, fewer people perform a clean and a complete rebuild. This could very well result in a higher level of expectation about what sources were used than will in fact exist. [05:38:40] --- Simon Wilkinson has become available [05:39:54] I agree with jaltman. The problem is that autoconf expects to be told the version number to use when configuring the package, and in lots of places that's the only change we get to substitute in a version number. [05:43:53] Lots of other projects run 'git describe' as part of the make process if they discover that they're running from within a git repo. We could do something similar, but it is going to require jumping through build system hoops to put the results anywhere useful. [05:59:04] --- haba has left [06:04:05] --- haba has become available [06:13:09] --- Simon Wilkinson has left [06:14:18] --- Simon Wilkinson has become available [06:18:58] --- jaltman has left: Disconnected [06:26:51] --- Simon Wilkinson has left [06:28:21] --- Simon Wilkinson has become available [06:30:24] --- Simon Wilkinson has left [06:39:22] --- Simon Wilkinson has become available [06:41:45] actually, not really. we could easily put the results useful places. just switch to generating a CML file. that gets us marked binaries. the only things it doesn't get us is usefully-versioned macos kexts (harder) rpms (differently harder) and tarballs (orthogonal) [06:42:08] in fact if we didn't care about kext and rpms we could do it exceedingly simply. [06:42:23] Maybe we should for those, and think about the RPM plan separately. [06:42:51] I wonder if, for 1.6, we should switch to using better named tags, so that git describe's output is more immediately useful. [06:43:16] and we could generate a cml file for releases, nightlies, and made the makefile try to run git describe|some script to create one if none exists [06:43:37] nothing precludes us from writing a second set of tags today [06:44:28] Yes, but I'm not sure how git describe fares in the face of choices. [06:44:49] i assume it depends what you checked out [06:45:01] I doubt it. [06:45:28] It just tells you the tag that's closest to either a SHA1 you give it, or the current branch tip. [06:46:33] --- haba has left [06:57:13] tag commits on either side of the tagpoint with other tags, ensuring less is ever close to the "actual" tag? [06:58:16] Not sure what you mean. [06:59:13] What git describe gives you, by default, is the annotated commit that's nearest (travelling up the revision tree) to the commitish that you supply. [06:59:18] tag the point just before openafs-stable-1_4_12 with something. tag the point just after it with something. nothing is going to be "closest" to the openafs-stable-1_4_12 tag [07:00:30] s/annotated commit/annotated tag/ [07:00:32] If you are on the same commit as the tag, then it will give you just the tag name - so if your tag names directly correspond to versions, it's a great way of getting version numbers. [07:01:11] No, your misunderstanding how git describe works. [07:01:32] Say I have a tree a-b-c-d [07:02:01] i'm suggesting if c is tagged openafs-stable-1_4_x, and you're git describing a, you get what? [07:02:26] i want to tag b and d so if you'd get something based on c's tag, now you won't, unless you're ctuallygit describing c [07:02:30] Nothing. [07:02:50] Because git describe works backwards in time. [07:03:21] fine. so assume i'm looking at e. [07:03:28] i now get d's tag, instead of c's [07:03:39] I'm not sure what you're trying to acheive. [07:03:39] openafs-stable-1_4_x isn't a tag, in any case. [07:03:39] Yes. [07:03:59] er, yes. but i assume you understand what i'm suggesting now [07:04:14] for every version tag, tag the commit after it as something more descriptive [07:04:25] --- shadow has become available [07:04:34] You'd get something like d-1- [07:04:44] Why bother? [07:05:00] Why not just make our version tags do the right thing. [07:05:35] can't do it retroactively [07:05:57] Because, otherwise, you end up with problems where someone pulls 1.4.10, and makes their own changes. You really want that to git describe as 1.4.10-3-abcdef (for example) [07:07:07] I just want it to be obvious what I'm looking at [07:07:18] We can do it retroactively. [07:07:32] -3-abcdefg could be it but not necessarily [07:07:36] explain? [07:07:48] Tags aren't part of the object tree. [07:07:54] We could just change all of our tags. [07:08:15] --- deason has become available [07:09:04] makes rebuilding old releases hard [07:09:26] Well, it means that you need to use the 'new' tag name to pull the source. But beyond that, why hard? [07:10:12] just that [07:10:31] --- jhutz@jis.mit.edu/owl has become available [07:11:32] We probably should have fixed this when we did the switchover. But, I don't think it's too painful to sort out now. [07:12:11] well, I guess we should figure out what the tags will be [07:12:52] I'd be interested in Russ's input, and andersk (if he's around) [07:13:17] Shawn uses tatgs like 'v2.1.1.1' for gerrit [07:14:39] which isn't much better than now IMO [07:16:25] --- haba has become available [07:16:28] Well, the problem at the moment is that our tags are [07:16:37] openafs-stable-1_4_12 (for example) [07:17:20] The "openafs" portion is superfluous. "stable" is pretty much meaningless too. [07:19:19] we reserved right to repurpose [07:20:02] Not sure what you mean by that? [07:20:45] 1.5 could become stable [07:21:09] But why encode that information in the tag? [07:22:16] script simplicity for scripts never done [07:22:42] so you advocate Spartan tag names? [07:24:15] I think I do, too [07:25:40] --- Simon Wilkinson has left [07:36:00] --- Simon Wilkinson has become available [07:37:10] Sorry, connection dropped out. If by "spartan" you mean "tag names that just contain version information", then yes, I do. [07:37:48] (Linux uses v2.6.20 - so that does seem to be something like a convention ... ) [07:40:58] yes. ok [07:43:05] WRT to the setpag vs keyring quotas thing. I'm slightly inclined to say that PAM modules should just change their effective uid before calling setpag() if they want to charge the PAG against a particular user. [07:45:48] AFS doesn't have the concept of charging a PAG against a user. The whole problem is Linux-specific and relatively recent. I'm not convinced a presumably-portable AFS PAM module should have to know about this platform-specific problem. [07:46:20] Thus I'm in favor of behaving reasonably when PAM modules call setpag as root. [07:46:53] Note that Solaris considers changing your effective UID like that to be a bad thing for PAM modules to do, because you might not be the only thread. [07:47:40] (we do it anyway, for manipulating credential caches, but we're probably going to have to do something else in some future Solaris) [07:47:54] ((sorry; by "we" I mean CMUCS, not opeanfs)) [07:48:00] (((and I can't type))) [07:49:39] --- reuteras has left [07:51:10] --- cclausen has become available [07:51:53] --- Simon Wilkinson has left [07:52:02] --- Kevin Sumner has become available [07:57:20] --- Simon Wilkinson has become available [07:58:55] --- Kevin Sumner has left [07:59:28] --- Simon Wilkinson has left [07:59:33] --- Simon Wilkinson has become available [08:00:15] Okay, so perhaps we should do something special with setpag() when it's called as root. [08:02:00] I'm just nervous about bypassing the keyring quotas entirely. Rainer is right that in the session keyring case, you'll run out of processes before you can exhaust memory (because you can only have one session keyring per process) - but I'm worried that there may be some way to obtain a reference count on a session keyring such that it isn't replaced every time you call setpag(). [08:11:17] --- Simon Wilkinson has left [08:12:30] We've already set the precedent by allowing root to ignore PAG creation rate throttling. I don't think this is worse. [08:13:51] I guess I'd rather we didn't have to be the ones creating the session keyring, but I don't think charging effectively all PAG creation to root's keyring quota is the right answer either. [08:17:36] --- Simon Wilkinson has become available [08:22:50] --- Simon Wilkinson has left [08:23:00] --- Simon Wilkinson has become available [08:24:37] It's worse because PAGs are our problem. keyrings are the Linux kernel's - I don't us to be bypassing a kernel security protection, and then actually causing problems because of it. That's the kind of thing the ends with symbols being taken away from us. [08:28:01] It's more resource management than security. And it wouldn't allow non-privileged users to bypass restrictions, since they're still subject to their quotas. It just means that the keyrings the system creates for you when you log in don't count toward your quota. I think that's reasonable, because it amounts to a constant term compared to the quota's linear term. [08:28:36] That does sound fair. [08:28:38] It'd be more straightforward if keyring quotas were handled more like other resource limits, instead of being per-uid [08:28:50] I'll put a patch together for 1.5, and see what Marc thinks ... [08:30:01] The main problem is the root quota. The keyring code assumes that keyrings will be created by pam_keyinit, running as the user who's going to use them. [08:30:12] So root's quota is no larger than a user quota. [08:30:37] Now, I suspect that we're doing the wrong thing by overwriting the session keyring that pam_keyinit creates. [08:32:34] That's probably true, but how are we to distinguish setpag from vsetpag? [08:33:04] That is, how do we know when it's OK not to create a new session keyring? [08:33:42] However, that brings up an interesting idea. Can we tell who the owner of the existing session keyring is? Perhaps we want to make our new keyrings owned by the same owner... [08:33:52] (but again, how do we tell login from su?) [08:34:46] We're having that debate internally at the moment - should you call setpag on su? [08:38:47] That's a question for the admin who writes the PAM config, not for openafs. Our answer has always been yes. [08:39:05] ugh. again, we-CMUCS have always done so [08:39:28] Yeah (that it's a question for the admin) [08:39:32] We also give you new kerberos ccaches [08:40:57] It's actually hard to solve the overwriting session keyring problem. setpag()s semantics means that you must, unless you are sure that you are the only process owning that keyring. I guess we could probably use reference counts to determine that, but it's a bit nasty. [08:44:59] Suppose we add a new "addpag" call, which has the effect of insuring you are in a real (non-uid) PAG, but does not change your existing PAG if you're already in one. In Linux, this means creating the PAG keyring if it does not already exist, but not replacing existing session or PAG keyrings. [08:45:20] Then we give the PAM module a flag, to be used when it's being invoked after pam_keyinit, which causes it to use "addpag" instead of setpag. [08:46:00] That would be reasonable. [08:46:13] Further suppose that I don't have to write any code. :-) [08:46:36] At some point, I suspect that the Linux kerberos implementations are going to start using the keyring for the credentials cache, and it would be nice to be able to share a session with them. [08:47:11] Maybe. I can't decide if it's really for that. [08:47:42] Well, it seems the way that per-session NFSv4 credentials are going. [08:48:10] And also the way that David's kafs stuff works (your token goes into your keyring, rather than keyring just containing a numerical pointer) [08:54:58] We have the problem that the MPI job start is not avare of credentials or credential forwarding. So we need to prime the UID pag before the job starts. This is fine as long there is only one job at the time per user and OS image. With multi-core machines you may want to have serveral jobs with different credential lifetimes and then that assumption breaks. So I'd like to be able to jump into an existing pag when I setuid() or thereabout. [08:55:50] That's an entirely new interface. One that I'm not opposed to, but I've got no interest in specifying or writing it. [08:56:55] It's worth noting that providing joinpag() (or whatever you want to call it) removes any protection that PAGs give against malicious activity by privileged users. [08:57:08] Btw, the next computer to be installed here at PDC will be a Cray. Anyone knowing anyone running AFS on such a beast? [08:58:14] * haba does not believe that pags give much protection from really malicious+priviledged users. [08:58:32] > joinpag removes any protection if your malicious user can call arbitrary syscalls, don't you already lose? [08:58:32] Not against one who knows how to wield a kernel debugger, no. [09:00:21] Not entirely. [09:00:53] Normally there is a ticket associated with the token that is much easier to get, unless the user has done a kdestroy --no-unlog before the evil person shows up. [09:01:53] I was thinking more like attaching to a proc with gdb or similar [09:02:11] krb5 creds sticking around is still a potential problem, but it's not ours [09:02:49] It's kernel memory that's the issue, not stuff in userspace. [09:05:24] * haba feels a bit divided between acting as the developer (can not see aaaaany prooooblem heeere) and the sysadmin (ugh, we have prooooooblem). ;) ;) [09:06:38] Well, as the developer, if you'd like to see joinpag(), write a patch. [09:16:52] --- pod has left [09:17:07] --- pod has become available [09:34:53] --- kaj has left [09:36:36] --- Russ has become available [09:54:32] --- Simon Wilkinson has left [09:59:58] shadow: have you seen the (seemingly not-used right now) kauth_cred_supplementary_* api? that looks like something we'd want, assuming there was a proc_* call for it, too [10:09:44] not just unused. not implemented [10:11:39] well yes; I just mean, it looks like something at least someone was thinking about [10:15:44] --- jaltman has become available [10:18:31] --- haba has left [10:20:16] i dunno if I sent a link to my Darwin-dev message. that was in my summary of 'things I can't have' [10:42:58] --- kaj has become available [11:00:53] --- shadow has left [12:48:24] hmm, the DELETE_ZLC symbol never seems to be defined, all the way back to openafs 1.0; anyone know if it's something that just never got turned on, or something that just never got deleted? [12:49:07] (if enabled, it would appear to delete files with 0 link counts in namei) [13:11:45] --- haba has become available [13:40:35] --- mdionne has become available [14:08:11] --- Simon Wilkinson has become available [14:28:07] --- kaj has left [14:28:13] --- kaj has become available [14:36:07] --- haba has left [15:00:02] > Because git describe works backwards in time. git describe --contains can go the other way [15:11:47] --- Ben Poliakoff has become available [15:15:53] --- Ben Poliakoff has left [15:24:04] --- deason has left [15:42:40] --- haba has become available [15:50:48] deason: Yes - that's what I use with the Linux kernel all the time. [15:51:18] But that's not what we're interested in here - what we want to know is the OpenAFS release that a given build is based on, not which one it's part of in the future. [15:56:29] --- kaduk@mit.edu/barnowl has become available [15:58:48] Apparently I messed up my git commit --amend; "this time for sure" my s/bzero/memset/ is up at gerrit.openafs.org/1560 when Simon (or someone else, I guess) wants to look at it. [15:59:18] I'll take a look. [16:00:47] Actually, you just need to get Derrick to push it. [16:00:58] Okay; thanks [16:01:06] --- deason has become available [16:01:19] (void) memset should be uneccessary, btw. [16:02:47] Unnecessary in that it will compile just fine with the current warnings? [16:03:34] With the current, and future warning settings. I don't think we've got any intention of starting to test for unchecked return codes. [16:03:45] Also, you don't need to cast the results of osi_AllocSmallSpace [16:04:59] The line above it used a cast for the alloc, so I figured it would be consistent. [16:17:02] I don't think gcc even *can* check for that for things like memset. [16:17:16] That particular coding style seems to have fallen completely out of popularity. [16:22:53] ... in fact, I don't see any occurrences of it in the freebsd kernel tree. I wonder where I got it from ... [16:23:40] some other things in the openafs tree do it [16:24:20] for some reason, I recall a lot of afs_snprintf's like that, at least in the vol package [16:33:45] --- kaj has left [16:33:51] --- kaj has become available [16:37:18] I've been weeding them out, when I'm in the neighbourhood. [16:37:39] I'm planning to do it with casts from allocators at some point too, but last time I did a big search and replace change like that, I broke things. [16:38:48] So ... I should change it and re-push? [16:39:48] If you like. It's not the end of the world, and I'm certainly not going to -1 it for them, but every step in the right direction is a good thing. [16:51:31] I guess I'm not sure how to tell git that I want to amend the HEAD^^-->HEAD^ commit instead of HEAD^-->HEAD, though. [16:51:56] Okay, let's get this straight. [16:52:09] You've got origin/master -- a -- b and you want to amend 'a' ? [16:52:58] Uh ... I think so? I committed the s/bzero/memset/ change locally, and then a "don't vrele(NULL)" change locally, and then I pushed to gerrit. [16:53:06] Okay. [16:53:17] So what you want to do is git rebase -i origin/master [16:53:35] You'll get a window point up in your editor of choice that lists all of the patches since origin/master [16:53:49] And I get to reorder? [16:53:53] Change the word 'pick' at the start of the line corresponding to the patch you want to change to 'edit' [16:54:09] git rebase will then spit you out into a shell. Make the change [16:54:14] git commit --amend -a [16:54:18] git rebase --continue [16:54:21] and you're done. [16:54:38] Ah, that's pretty clean. [16:54:47] (Oh, sorry, after you've changed 'pick' to 'edit' save the file, and exit your editor) [16:56:04] And the git commit --amend -a means I don't need to git add the file changed (which is what bit me last time)? [16:56:22] Yes [16:56:34] The -a adds everything that's been modified in the current working tree. [16:56:49] But git rebase won't let you do anything with a dirty working tree, so it's perfectly safe for this usage. [16:57:46] Great; thanks! [16:57:53] No problem. [16:58:08] git rebase rocks. [17:02:40] --- kaj has left [17:02:41] --- kaj has become available [17:48:39] --- mdionne has left [17:55:16] git rebase? rocks? well, it's ok [18:01:24] --- pod has left [18:07:05] --- Russ has left: Disconnected [18:30:34] "DELETE_ZLC" would be delete zero link count. it's never been defined that i k now. we need to test before we do [19:14:21] --- pod has become available [20:09:26] well, what I was wondering is whether we want to; is it a 'new' feature that nobody tested to turn on, or something that was going away and nobody yet got rid of it completely? [20:09:45] and/or something that doesn't really matter too much, so it could just be gotten rid of and nobody would notice [20:12:44] my assumption is new (risky, could discard orphaned data) feature. [21:52:05] --- Born Fool has become available [22:01:42] --- deason has left [22:20:36] --- Russ has become available [22:36:08] Hm, these warnings about assignment from incompatible pointer type in afs_vfsops are probably related to my problems ... [22:53:40] --- Born Fool has left [23:07:49] It also looks like a bunch of the xdr stuff isn't right for at least 64-bit fbsd, but I'm not terribly inclined to tangle through it right now. [23:13:32] --- reuteras has become available