[00:01:51] --- dev-zero@jabber.org has left [00:33:27] --- haba has left [00:46:06] --- dev-zero@jabber.org has become available [01:04:33] --- haba has become available [02:57:52] --- abo has left [03:07:41] --- abo has become available [05:11:04] --- pod+ has become available [05:34:27] --- Jeffrey Altman has left: Replaced by new connection [05:34:31] --- Jeffrey Altman has become available [05:49:58] --- sxw mobile has become available [06:24:31] --- sxw mobile has left [06:28:36] --- sxw mobile has become available [06:47:43] --- deason has become available [06:51:55] --- sxw mobile has left [06:54:34] --- sxw mobile has become available [07:18:28] --- sxw mobile has left [07:21:41] --- deason has left [07:26:50] --- sxw mobile has become available [07:28:44] --- reuteras has left [09:17:08] I have a keyctl question: I want to test from the shell if I'm in a newpag:ed pag or if I'm in the "uid pag". The output looks like: Computer 1: Session Keyring -3 --alswrv 0 0 keyring: _ses.26147 627039822 ----s--v 0 0 \_ afs_pag: _pag or Session Keyring -3 --alswrv 0 0 keyring: _uid_ses.0 2 --alswrv 0 0 \_ keyring: _uid.0 Computer 2: Session Keyring -3 --alswrv 0 0 keyring: _ses.20152 1036531473 ----s--v 0 0 \_ afs_pag: _pag or Session Keyring -3 --alswrv 0 0 keyring: _ses.1183 2 --alswrv 0 0 \_ keyring: _uid.0 Is it safe to assume that I'm in UID pag if there is no "afs_pag:" in the output or should I rather test for "keyring: _uid.0"? [09:25:35] the output of what? [09:26:21] keyctl show [09:26:38] (or suggest a better test ;) [09:29:24] The presence of a key of type afs_pag is what you're looking for. [09:30:18] keyring: _uid.0 is _not_ a "UID PAG"; it's a per-user keyring. [09:31:28] I suppose $ keyctl show | grep "afs_pag: _pag" && echo In PAG will do then. [09:31:54] (With added "> /dev/null") [09:35:54] rtfm grep -q [09:36:53] Ok, that may now be available in all grep involved here. [09:50:01] It'll be available on all machines with Linux keyring support. [09:51:03] jhutz: Yes, you are of course right, but old habits die hard. [09:53:13] (but not as hard as it seems to be to convince openssh to build and NOT to link to _any_ MIT gssapi lib that happens to be lying around and I don't want to rewrite the whole damn specfile and patch configure and what else to get it to link with Heimdal) [09:58:33] I've never had a problem with that. Then again, I generally don't install the krb5-devel RPM's. [10:01:53] It works as long as configure does not go "oh, and you have a gssapi_krb5 here which you MUST use" and so on. But now it's FRIDAY EVENING here so I'm going HOME! [10:02:28] Yeah; I was up for FRIDAY MORNING there. [10:11:06] sxw around? [10:11:22] --- haba has left [10:11:27] unlikely. he was gonna be away for the weekend [10:11:48] Hrm, OK. [10:12:28] I realized I have been a bit lame on the standardization spinup thing, and need to start dealing this weekend in order for the timeline to work. [10:13:36] I am thinking of sending out a consensus call on charter draft 3, with a two-week expiration, followed immediately by opening nominations. [10:13:44] well, he's off for a wedding [10:14:05] that seems reasonable [10:14:24] --- sxw mobile has left [10:15:30] The tricky part is the timeline nominally requires 2 weeks for nominations, a week delay to verify stuff, 2 weeks for voting, results announced within a week, with the chair(s) to take office on Oct 1. The document allows the vote-takers to alter the timeline, within certain parameters, and I think I want to take advantage of that to extend the nomination period. [10:15:42] I need to find kula [10:29:16] --- dev-zero@jabber.org has left [10:45:38] --- sxw mobile has become available [10:50:58] is there a plan to provide a Makefile for doc/protocol so that the documentation can be built easily? [10:54:00] also, there are ~100K lines of errors in that documentation when passed through doxygen. all but a handful are unknown tags (which makes me wonder if something is is intended to preprocess this) [10:54:40] if someone sends one. and makes it do something sensible (like, don't assume i have the tools; let configure check) [10:55:24] well, the commit says the work was funded by an SBIR grant, so I'm trying to determine what else is going to be coming before I touch anything..ie, don't want to duplicate effort. [10:56:01] also, it's not clear to me how additions to this documentation handle copyright. [10:56:23] ie, the contents are all the original 1991 documentation copyright. [10:56:35] it's darpa-copyright, right? [10:56:44] e.g. your tax dollars at work [10:57:28] one would think; however, the text says it's copyright Transarc Corporation. [11:05:36] --- sxw mobile has left [11:21:09] --- dev-zero@jabber.org has become available [11:40:22] --- Russ has become available [11:46:51] --- sxw mobile has become available [11:51:13] for the DAFS-aware volume status RPCs, do we want a single document covering all of them, or one background doc + one RPC at a time [11:51:32] one covering all is probably fine [11:52:22] hm. that gets a bit hairy, as it crosses some interface boundaries (i.e., vos vs fs<->cm), but ok. [11:53:07] I may just do 'background + vos RPCs' as one doc, then once we get that hashed out, the fs<->cm ones will be simpler. [11:53:25] well, properly, document the RPCs with the subsystem they're from, i guess, in that sense [11:53:39] ok [11:53:44] it's not like we can't rearrange [11:55:12] * stevenjenkins nods. I'm trying not to think in terms of patches to the existing docs, but I'm at least using those as a starting point for structure. [11:55:34] what goes to afs3-stdization will be 'full doc', but what ends up in doc/protocol will be patches [11:55:57] jaltman's work getting the old PS docs into a text-friendly format is a big help, btw. [11:56:04] sure [12:03:05] * Russ has something for the Debian packages that builds the Doxygen documentation and seems to result in vaguely usable HTML, but I haven't studied it closer than that. [12:03:08] It doesn't have a configure probe. [12:41:56] --- sxw mobile has left [12:45:55] --- sxw mobile has become available [12:54:40] --- sxw mobile has left [12:58:02] --- sxw mobile has become available [12:59:26] --- dev-zero@jabber.org has left: Lost connection [13:04:30] It's OK if it crosses interface boundaries. We want documents that describe coherent protocol changes/extensions, such that people can talk about whether a given implementation/version implements a given document. [13:06:19] > what ends up in doc/protocol will be patches I wouldn't do that, for the most part. Most of the packages I've seen that implement standardized protocols and ship protocol docs ship the actuall specifications, not the result of someone interpreting the spec and trying to produce a comprehensive but non-normative doc. [13:08:52] --- sxw mobile has left [13:10:11] --- sxw mobile has become available [13:29:28] --- dev-zero@jabber.org has become available [13:30:58] --- sxw mobile has left [13:40:33] --- sxw mobile has become available [13:51:09] --- sxw mobile has left [14:29:07] --- sxw mobile has become available [14:51:13] --- dev-zero@jabber.org has left [14:59:15] --- sxw mobile has left [16:15:17] --- matt has become available [16:16:53] --- matt has left [18:23:42] --- Russ has left: Disconnected [18:51:03] --- pod+ has left [22:10:24] It would seem that I have a freebsd client mostly working. There is at least one (haha, who am I kidding) locking bug, in the lstat() path, but it seems pretty stable so far. I think I will will try to get it to a semi-publishable state and then start working forward with newer freebsd and openafs versions. [22:56:53] Hm, this is unfortunate, though: freebsd-afs# rxdebug localhost Trying 127.0.0.1 (port 7000): getstats call failed with code -1 [23:06:32] rxdebug localhost 7001 [23:07:35] I'll try when I finish fsck-ing ... interestingly, this panic does not look to be AFS's fault ... [23:27:47] freebsd-afs# rxdebug localhost 7001 Trying 127.0.0.1 (port 7001): getstats call failed with code -1