[00:05:54] --- dev-zero@jabber.org has become available [00:06:04] --- dev-zero@jabber.org has left: offline [00:21:38] --- abo has become available [00:59:15] --- Russ has left: Disconnected [02:40:37] --- matt has become available [05:27:06] --- Jeffrey Altman has left: Replaced by new connection [05:58:29] --- cclausen has left [06:06:25] --- cclausen has become available [06:16:22] --- matt has left [06:59:37] --- reuteras has left [08:13:05] --- dev-zero@jabber.org has become available [08:13:09] --- dev-zero@jabber.org has left: offline [08:14:19] --- matt has become available [09:14:44] --- dev-zero@jabber.org has become available [09:14:48] --- dev-zero@jabber.org has left: offline [09:31:59] for new man pages, do you want the blank file, or the results of a diff -Nu /dev/null ? [09:32:05] s/blank/plain/ [09:32:30] I have several, btw. [09:33:13] reslts of diff against /dev/null [09:33:42] will do, tx. [09:34:40] --- abo has left [09:35:12] --- abo has become available [09:51:34] That's "diff -N" [10:04:33] * stevenjenkins nods. [10:05:12] done. you can take a look at 124788-124793. [10:05:28] I have about 3 more patches to come in for cleanup, but those are all the new files. [10:06:05] this set will empty out the 'the following commands have no man page section', which will be nice.. [10:14:29] for the *.krb man pages, what is the preferred option? Changing the original man pages is easy (e.g., 'klog, klog.krb' in the synopsis), but how do we want the .krb man pages to exist? 1- as symlinks in the dest back to the originals 2- as symlinks in the src, which get copied into dest [10:14:55] #2 is trivial; #1 requires a bit of Makefile hacking (not a problem..but the savings in space is rather minimal) [10:17:12] No, #2 is not trivial. The source tree cannot contain symlinks [10:17:52] the makefile should install the links [10:18:36] jhutz - um. already tested #2, and it works fine. [10:18:40] but I can do #1. [10:18:45] In fact, I thought there was a fairly standard way to record that a man page has multiple names. [10:19:11] it would be great if there is a standard way to do that -- I looked and didn't see one. [10:19:26] Symlinks cannot be represented in a CVS repository or in a diff. Thus, they cannot be part of our source tree. [10:19:37] ah. got it. [10:19:44] --- abo has left [10:19:50] You can create symlinks in your sandbox, but CVS will not do what you expect with them. [10:20:01] * stevenjenkins nods. true. [10:20:25] --- abo has become available [10:24:36] --- dev-zero@jabber.org has become available [10:24:37] --- dev-zero@jabber.org has left: offline [10:38:55] --- Russ has become available [11:10:47] Whoohoo, lots more man pages! [11:17:07] yeah, they're all done now but the cleanup.. [11:18:48] I just need to work out a relatively clean way to handle the *.krb man pages (i.e., produce symlinks on install). I hate to just hack the Makefile, but that's what it's looking like atm. [11:20:04] We could install .so redirections, but most man programs these days actually prefer symlinks. [11:20:10] I usually just do it in the Makefile, yeah. [11:28:17] --- dev-zero@jabber.org has become available [11:28:19] --- dev-zero@jabber.org has left: offline [11:59:44] russ -- 124799 finishes out the 'missing man pages' [12:40:48] --- dev-zero@jabber.org has become available [12:40:48] --- dev-zero@jabber.org has left: offline [12:48:18] makefile really seems like the right way to do it [12:49:18] cf 124799 [12:49:46] I'd like a little better way to do it, but given that it's only 2 files, that's probably reasonable enough. But any other suggestions are welcomed. [12:50:40] and, of course, I see some bugs in it. argh. [12:50:43] unless this becomes a huge problem, hardcoding. if we have lots we could do something more sophisticated. [12:52:32] * stevenjenkins nods. that seems reasonable to me. fix for the path bug is emailed, btw. [12:58:51] Just bear in mind that make generally does not handle symlink targets correctly. [12:59:15] I hard-coded the ln in the Makefile.in..ugly, but effective. [12:59:41] if there's A Better Way, let me know. [13:00:44] once russ (or whomever) gets those tickets committed, I have one or two other doc cleanup patches, then I'm going to be working on some ubik stuff and/or rx osd. [13:00:55] handle failure (existance) gracefully [13:01:05] of the symlinks? [13:01:11] yes [13:01:23] ok. [13:01:29] this probably means "prefix the ln -s command with a minus" [13:01:47] I generally rm the symlink and then create it with ln -s. [13:02:39] that would also be reasonable, though my preference would be something harder: if the name which we want to install is not a symlink to x, remove and install one. otherwise, no touch [13:04:44] Yeah, that's hard, since I don't believe there's a standard POSIX command to tell you the destination of a symlink. [13:04:51] You can check whether it's a symlink, but not the destination portably. [13:05:20] "perl". which is a crappy answer [13:05:20] coreutils has readlink, but I don't think it's something we can count on arbitrary UNIXes to have. [13:05:34] how about this? test -L ${NEWPAGE} || ln -s $$M.1 ${NEWPAGE} [13:05:46] portable -- doesn't test destination, though. [13:06:22] IIRC, test -h is the portable one; test -L is the new one. [13:06:43] They're both in POSIX now, but I think -L was added later. [13:34:44] --- Jeffrey Altman has become available [13:45:07] * Russ finds RT's authentication behavior around downloading attachments incredibly annoying. [13:45:26] yeah. [13:45:28] * Russ once again has "save link as" in Firefox save an HTML login page instead of the attachment, despite the fact that clicking on the link gives me the attachment in a browser. [13:47:31] that i haven't had [13:49:45] Steven: For future reference, you want set -e in front of any loop in a Makefile. [13:51:18] please create a ticket with the names of all of the new man pages with a request to add them to the windows installer scripts [13:51:29] Also, we're still installing klog.krb as well, so klog needs similar treatment. [13:51:32] Jeff: Will do. [13:53:53] What *is* the difference between tokens and tokens.krb? [13:54:11] russ - ah, good point. [13:54:47] russ -- what do you mean with klog and klog.krb? we already have both klog and klog.krb, so how do you want those handled? [13:55:02] those two man pages are not the same. [13:55:32] (I didn't look at them in detail, other than a quick diff to see if they were essentially the same -- and they looked fairly different at a high level) [13:59:24] tokens.krb also lists tickets [14:33:24] looks like I can generate cygwin .a import libraries for all of the native Windows openafs dlls. [14:33:33] is that useful? [14:33:44] I'm not sure [14:33:50] it definitely is for kfw [14:34:11] I guess it would be useful for building cygwin sshd with afs support [15:01:45] --- matt has left [15:13:45] Steven: Oh, there are two separate man pages. I'd not realized that. Thank you! That means that README was just out of date -- I'll fix that. [15:13:57] --- sxw has become available [15:14:06] * Russ looks. Hm, I'm not seeing klog.krb as a separate man page. [15:14:13] There's a klog.krb5, but that's not the same. [15:16:57] I wouldn't worry too much about RT's attachment behaviour. Gerrit will make them redundant. [15:18:37] In other news. I now have a git repo with sensible tagging, delta names and author attribution. [15:19:09] Next step is to check that every release tag is correct. [15:19:17] I'm curious - how are the delta tags represented? [15:20:00] Where the delta is one patchset, through a git tag with the delta name. [15:20:30] * broder@mit.edu/vinegar-pot nods [15:23:09] Where patchsets can be simply merged we do so. [15:23:47] Where we can't, the delta gets renamed as delta-pt0 and so on. [15:23:58] Steven: All of the man page patches have been applied and I'm going to pull them up in just a second. Thank you! [15:25:01] So a web tool could still use git's contents to return an old delta [15:26:47] that's good, because URI's for downloading deltas need to continue to work [15:27:29] that's easy: worst case, we leave cvs up [15:29:02] --- sxw has left [15:29:49] initially, yes. but ideally I'd like a unified interface that works for both old and new deltas [15:30:42] --- sxw has become available [15:30:58] Is there an expectation that you guys will continue to name your deltas? [15:31:08] the script can have a "flag date" hardcoded if needed, also [15:31:19] we will keep naming our deltas. [15:31:42] We name our deltas because IBM used to do it and we found it really useful [15:31:51] Deltas in git won't perfectly match those in CVS, btw [15:32:00] That seems like it has fairly annoying interactions with git - what happens when you cherry-pick a delta from one branch to another? [15:32:05] I don't know of anyone who thinks naming them has stopped being useful. [15:32:27] jhutz: I'm not saying they're not useful [15:33:08] ... including any gatekeepers. I'm not sure what you mean by "what happens". The tag can only be in one place, no? [15:33:11] Deltas need different names on different branches. If you cherry pick, you're going to need to retag. [15:33:21] ... which is the same as it is now [15:33:48] Same as it should be now. [15:34:06] well, we don't retag, we commit with a new commit message, but yes [15:34:14] Number of delta name collisions is rather dull. [15:34:20] *nods* I guess that just seems annoyingly inconvenient to me, but given that I'm neither a committer nor even a remotely active developer, I'll shut up now :) [15:34:20] yes. yes it is [15:34:34] Right now, if you pull up a delta to another branch, you need to retag. The fact that sometimes people don't actually _do_ it doesn't remove the need. :-) [15:35:00] re"tag" implies it's tagged in the first place. not so much. [15:35:09] Well, it's named. [15:35:10] At least with git you'll get told if you reuse an existing tag. [15:35:17] which is good. [15:35:40] CVS would do that too, if we tagged deltas. but we don't, because that might make things _really slow_ and wouldn't actually be all that useful. [15:36:16] It does mean that the current practice of modifying deltas post commit won't work any more. [15:36:37] which, well, properly it shouldn;t [15:36:45] --- abo has left [15:36:48] if we have better pre-commit tools it won't matter [15:37:10] --- abo has become available [15:37:33] > the current practice of modifying deltas post commit which is fine, because that's sloppy engineering anyway [15:37:55] Is the source for wdelta available? [15:48:24] --- edgester has become available [15:53:16] Is rxk5 the project to replace the "fs setcrypt" with better over-the-wire encryption? Will that give openafs the same encryption types as kerberos? [16:03:38] edgester: rxk5 is one of two projects to do this, yes. [16:04:02] ok, what the other one? rxkad? [16:04:18] rxkad is the current security mechanism. [16:04:30] The other is rxgk, which Love presented on a couple of workshops ago. [16:04:40] rxk5 uses raw Kerberos, rxgk uses GSSAPI. [16:05:12] ok, which looks like it'll be more successful? [16:05:30] rxk5 is further along. [16:05:46] (I believe that the code in the rxk5-devel branch works, and can secure connections today) [16:05:59] It only solves the Kerberos subset of the problem. [16:06:06] ok, so rxk5 gives all of the encryption types that kerberos does, yes? [16:06:46] It certainly gives you a load of them, yes. Because the crypto needs to be done in the kernel, I'm not entirely sure whether all of the more esoteric encryption types have been implemented. [16:06:58] ouch [16:07:17] I suspect that means performance issues as well [16:07:21] Why? [16:07:38] I have servers now that are 8x slower doing fcrypt [16:07:50] would only get worse doing des3 or rc4 or aes [16:08:16] Yes. So, if you don't care about data security, don't use a more complex crypto algorithm. [16:08:41] until security can be enforced server-side, I'm not sure that it matters [16:09:04] --- stevenjenkins has left [16:09:15] I can only go so far to help end-users be secure [16:09:20] I thought someone was looking at patching a fileserver to do that. [16:10:06] Depending on your OS, you may eventually see a performance improvement by switching to something like rxk5 or rxgk, both of which use RFC3961 crypto where rxkad uses fcrypt. This is because some OS's will make it possible for us to use hardware crypto acceleration, both in user and kernel mode, but there are no hardware fcrypt accelerators. [16:10:46] Jeff H: cool! [16:11:23] would I need this hardware on both ends? [16:11:42] Of course, AFAIK to date no one has done any work on making OpenAFS use hardware crypto acceleration where it is available. And Linux is not one of those OS's, because the common crypto API's in current kernels are all GPL-only [16:11:52] No, of course not. [16:12:00] --- stevenjenkins has become available [16:12:42] --- abo has left [16:12:55] Solaris, for example, has an in kernel Kerberos implementation for NFS, which uses in the kernel crypto framework, which can be hardware accelerated. [16:13:06] Oh, well, Linux is not one of those wrt kernel code. User-mode code will be able to deal, eventually. And, I suspect our user-mode code will get it for free when we start using crypto libraries that support it. For all I know, that may already be the case when using rxk5 or rxgk, depending on your Kerberos library. [16:13:10] yeah, I have an Intel SSL accelerator with a fancy 3 pci slot linked card that does hardware crypto. I believe that the system is BSD based. [16:13:22] OpenAFS could do the same. But, I wonder whether we'll get there before Solaris meets an untimely end. [16:13:30] --- sxw has left [16:13:33] --- abo has become available [16:13:41] would openafs then require openssl or similar crypto libs? [16:13:48] I'm not sure I'd expect Solaris to meet an untimely end. [16:14:26] cclausen: No. But we might use a Kerberos library that has that as a requirement. [16:14:29] It will require something that supports RFC3961 crypto, which basically means a Kerberos library. And that will need to get its crypto primitives from somewhere, yes. [16:14:38] ah, ok [16:15:13] Note that neither rxgk nor rxk5 makes any direct use of crypto; everything is done in terms of the GSS-API, Kerberos, or RFC3961. [16:15:18] There's also the option that we use Kerberos for connection establishment, and to do key negotiation for an indepedently implemented bulk cipher. [16:16:11] I wouldn't expect us to end up in a situation where we used a raw cipher rather than a 3961 enctype. [16:16:47] The question is whether using libraries implementing 3961 ciphers gives us a rich enough API, in particular for things like in place encryption. [16:17:20] is there a sane way to let clients know the newer methods are supported? [16:17:29] Yes. [16:17:42] I assumed so, just wanted to make sure [16:18:04] I'm also not sure how well the 3961 encryption types are suited for bulk encryption of large quantities of data. [16:18:22] yeah, I was wondering about that [16:18:31] --- stevenjenkins has left [16:18:33] Kerberos tickets aren't usually all that large [16:19:01] Kerberos session tickets are used to encrypt streams of data. [16:19:08] Session keys, rather. [16:19:20] for things like telnet and ftp ? [16:19:28] cclausen: Yes. [16:19:30] I believe that SSH uses its own ciphers, correct? [16:19:34] --- abo has left [16:19:46] Indeed, ssh does its own thing. Kerberos just protects the handshake. [16:19:55] And for any GSSAPI service that negotiates data integrity. [16:19:59] Like remctl. [16:20:23] They're not, but I think we took reasonable care in designing RFC3961 to make it possible for applications other than Kerberos to use it, including for longer-life data streams. Note that the Kerberos GSS-API mechanism uses RFC3961 crypto for wrap tokens when a "new" enctype is used such as one of the AES ones (see RFC4121) [16:20:25] yeah... I need to have some people re-write some stuff to actually use remctl [16:20:34] --- abo has become available [16:20:59] Note that 3961 was still open when 4120 and 4121 were being written. [16:21:48] --- stevenjenkins has become available [16:23:14] With rxgk, at least, you're not going to end up using the session key for connection encryption, anyway. So you may well use a 3961 encryption type, but it could be independently negotiated (say your kernel module has much less crypto code than your userspace, for example) [16:27:11] Yes, and rxgk makes provision for negotiating the enctype of the keys that will be used to protect the connection separately from the keys used to authenticate the GSS-API context. In fact, it must, because the GSS-API mechanism might not even be Kerberos. [16:27:58] And you may also end up stirring key material from the cache manager into the pot, too. [16:31:59] --- jhutz@jis.mit.edu/owl has left: Disconnected [16:32:03] --- jhutz@jis.mit.edu/owl has become available [17:13:02] --- cclausen has left [17:38:26] --- Russ has left: Disconnected [17:52:15] --- cclausen has become available [17:54:31] --- Russ has become available [18:37:42] --- kaduk@mit.edu/owl has left [18:40:31] --- kaduk@mit.edu/owl has become available [18:56:41] --- edgester has left [19:06:13] --- Russ has left: Disconnected [19:07:00] --- Russ has become available [19:40:04] are the xml contents buildable? [19:40:09] ie, 'make pdf' fails for me.. [19:44:52] this doesn't seem to be valid: Name Index [19:44:55] line 53. [19:47:32] Yup, fails for me as well. [19:50:12] That appears to be a recent modification -- maybe a different version of DocBook in use? [19:51:04] it requires xsltproc. the unix makefiles still need to be updated [19:51:14] see the Windows NTMakefile [19:52:04] using xslt indexes are autogenerated [19:53:16] Ah, okay. [19:56:13] Hm. NTMakefile doesn't help with how to generate the indices for make pdf. [19:57:36] I haven't done pdf rules yet. I believe it is something like create the single file version of the html output and run a conversion of html2pdf [19:59:05] Hm. [19:59:24] That won't give as nice of PDF as being able to render directly via DocBook. I wonder if there's a way to pregenerate the index as XML and then use docbook2pdf. [20:00:36] * Russ fixes make html for UNIX at least. [20:03:36] Can we generate the PDF using the old method and the HTML using the new method? The problem that I'm running into at the moment is that the contents of the tag in the 000 document are invalid XML according to docbook2pdf. [20:03:41] the way to do it is xsltproc output to latex and then pdf from the latex [20:05:21] the problem is that docbook2pdf does not support the tag from docbook. That is supported by the docbook xsl stylesheets [20:06:58] apparently dblatex or something called FOP is used. [20:07:14] http://www.methods.co.nz/asciidoc/chunked/ar01s30.html [20:08:33] sounds like we want to use dblatex until we start using callouts [20:08:45] Hrm, but I just ran docbook2pdf and generated an index without any trouble at all, once I fixed the invalid contents of the tag in the 000 file and re-included the generated 009 file. [20:09:02] but that won't work on Windows [20:09:24] docbook2pdf and docbook2html do not exist on Windows and there is no html help support [20:09:39] Right, but I'm wondering if we can have our cake and eat it too here. [20:09:49] I don't think I broke anything about what you were doing with what I just did. [20:10:07] diff? [20:10:57] what about the Name Index is invalid? [20:12:05] can't contain text. [20:12:09] It contains other tags. [20:12:17] So the XML doesn't validate. [20:12:24] ok, i have a dumb question: why do we have to be able to generate it everywhere? [20:12:35] One sec, I'm double-checking that I didn't break anything. [20:13:00] Yeah, xsltproc just ignores the contents of and generates its own. [20:13:21] So on Windows, just create auqbg009.xml containing only . [20:13:25] Then the following diff will do it: [20:13:49] --- auqbg000.xml 14 May 2009 02:25:40 -0000 1.5 +++ auqbg000.xml 19 May 2009 03:13:41 -0000 @@ -8,6 +8,7 @@ + ]> @@ -50,7 +51,7 @@ &chapter4; &appendixA; &appendixB; - Name Index + &index;