[00:26:35] --- kula has left [00:42:39] --- haba has become available [00:48:48] --- dev-zero@jabber.org has left [01:45:56] --- dev-zero@jabber.org has become available [02:14:02] --- haba has left [02:51:32] --- haba has become available [04:39:52] Russ, no guarantees that the document I wrote last summer is helpful or entirely complete. I wasn't quite sure I knew what I was doing when writing it [04:59:38] --- kula has become available [05:33:14] --- Jeffrey Altman has left: Replaced by new connection [06:29:09] --- Jeffrey Altman has become available [06:57:57] --- deason has become available [08:01:10] --- reuteras has left [08:15:48] --- Russ has become available [08:22:10] --- mmeffie has become available [08:22:31] No problem -- it's an excellent starting point. [08:22:36] I looked it over last night and like it a lot. [08:22:55] do feel free to edit/modify/expand on it should you come accross something [08:38:31] Derrick: You won't be able to push 93 before 92, which depends semantically on 91. [08:38:48] The cleanup is right next to and entangled with code reorganization from 92. [08:39:18] ok. [08:39:33] 91 and 92 should be good to go if they look right to you, though. [08:40:01] Yay, lots of new code to review! [08:40:33] i'd rather have had it more slowly, but it's good to have nonetheless [08:58:09] --- haba has left [09:06:26] apparently I committed something to my 'master' that I shouldn't have. I better start verifying the git state more carefully before I push. [09:06:58] I wonder if there's some way we can tell Gerrit to just reject any attempted push that contains merge commits. [09:07:19] that would be useful. [09:07:34] agreed [09:14:09] > it only does two system calls. Are they setpag and pioctl? [09:14:14] Yes. [09:20:35] So, I think it turns out you really want two interfaces. You want an interface that does setpag and pioctl, possibly using rmtsys. And you want a second interface that does afs_syscall directly, which is used by the first interface and by afsd for setting up the CM. Note that only the first interface, and then only for some pioctls, needs to interop with David. [09:21:07] Yes. [09:21:25] Also note that I'm not interested in _us_ being forced to have a new interface, again. And despite what the linux kernel folks think, 'fs lsm' and 'fs rmm' must work even when the mount point cannot be resolved. [09:21:35] * Russ is very tempted to make libkopenafs the blessed way of doing setpag and pioctl, except that right now it doesn't do rmtsys. [09:25:45] And then there's the weird inode calls for SGI. [09:30:04] Hm? We have a series of weird inode calls for all inode platforms. [09:31:41] Ah, yes, I see. [09:31:44] > make libkopenafs the blessed way I'm almost fine with doing this anyway. Most people don't use rmtsys, and lots of tools don't support it. If we bless libkopenafs, then it would be possible to produce an alternate library which exports the same interface and can be installed in its place on systems running the NFS translator (which is the only time rmtsys is used) [09:32:20] Also note that for Linux, we have an alternate kernel module which implements our syscall interface by making rmtsys RPC's. [09:32:22] The only reason why libkopenafs didn't do rmtsys is that introducing the requirement to link it with rx was a huge pain. [09:32:42] However, I fear that's probably still true. [09:33:06] * Russ thinks that the Linux implementation is a much nicer way to go. [09:33:29] So basically the only thing we'd break are Solaris NFS translator systems. [09:33:35] Me too, but user-mode rmtsys works on ~any NFS client [09:33:50] hm? No. rmtsys runs on translator _clients_ [09:33:54] Oh, I see. [09:34:01] Right, right. [09:34:24] --- mmeffie has left [09:34:32] However, what do we do about the fs binary? If we link it to libkopenafs, for instance, then it stops working on NFS translator clients. [09:38:53] Unless you install the currently-nonexistent alternate library. hrm. [09:40:02] retaining nfs translator support is important. [09:40:28] We really need a shared library with a stable API that provides the rx stuff. libafsrpc is probably mostly there. [09:40:46] Yeah, and so is having a binary that works on both native and translator clients, since you might switch back and forth depending on what kernel you've booted. [09:40:51] Then libkopenafs could just link with it and rmtsys would work where we need it to. [09:40:52] libafsrpc should be it [09:41:01] And we could provide some lower-level library that's used by afsd. [09:41:07] note i didn't say "is" [09:41:10] Doesn't libafsrpc have too much in it? [09:41:18] It has more than just rx, yes. [09:41:22] Really, librx should be it, dammit. [09:41:31] librx requires other things [09:41:52] like? [09:41:53] Well, here's another future-pondering annoying question: at what point can we require POSIX threads? [09:41:55] lwp? [09:42:13] Since having pthread and LWP versions of everything is massively obnoxious. [09:42:33] well, the ubik pthreads project needs work, but that was its goal [09:44:14] Ah, right, Ubik doesn't support anything but LWP yet, does it. [09:44:47] A possibly less controversial version of my question is "can we build only LWP *or* pthread on each given platform, and never build both of them at the same time?" But Ubik still needs to be fixed. [09:45:05] --- bpoliakoff has become available [09:45:28] Yeah, the immediate showstopper is that we can't build pthreads only. [09:46:15] until ubik is fixed it's an uncontroversial question with a simple answer: "no" [09:46:28] How close is Ubik to being fixed? [09:46:32] And how hard of a project is that? [09:47:21] there is code in the tree. it does not yet work. i suspect this is another case where a third party bug tracker has more information [09:55:31] * Russ rebases 91. [09:56:59] yay [10:14:22] I sent in 3 patches recently re: pthreaded ubik (not technically pthreaded ubik, but they were getting in the way of digging into real problems). [10:14:51] the short answer is 'ptserver seems fine; vlserver can corrupt your vldb if you have multihomed servers...sometimes..not reproducible' [10:15:00] that's scary [10:15:04] * stevenjenkins nods. [10:15:25] having clients get the IP addrs of fileservers reversed (and thus not be able to find volumes) is *not* a good thing. [10:15:56] it's on my personal 'to do' list, but nothing official. [10:16:05] something isn't locked, and when you search a hash the "wrong" way it gets corrupted, i bet [10:16:16] more or less, yes. [10:17:00] there is a patch (various versions) that protects the MH section from other threads, but it's known to have issues. I tested it a few weeks back and found several problems. [10:20:24] at this point, there is no private bug tracker that has significantly more info than that. [10:20:42] excellent [10:20:42] (that I'm aware of) [10:21:12] the ubik patches I put into RT a few weeks ago, though, would be useful. [10:22:09] if you are unlikely to be able to submit to gerrit, i should be able to troll the patches in RT and push things to gerrit soon [10:22:39] I'm unlikely to submit to gerrit in the next 2 wks. work has me slammed atm (with ruby, rails, puppet, etc) [10:47:58] --- haba has become available [11:15:18] hm. solaris fstrace needs -lnsl to link. [11:16:35] Huh. That shouldn't be new. [11:16:55] I didn't change anything about the build system that I'm aware of, and all the functions that are called now were called before. [11:27:50] my yum is unhappy about what it finds on http://dl.openafs.org/dl/openafs/1.4.11/rhel-5/i386/ and aborts everything with: (1/4): kmod-openafs-1.4.11-1.1.2.6.18_128.1.16.el5.i686. | 230 kB 00:00 http://dl.openafs.org/dl/openafs/1.4.11/rhel-5/i386/kmod-openafs-1.4.11-1.1.2.6.18_128.1.16.el5.i686.rpm: [Errno -1] Package does not match intended download (and so on for all 1.4.11 stuff I've tried) [11:29:44] Unfortunately not; they were running it once a day or so, but in the afternoon. [11:31:25] jhutz: Was this related to my comment or something else? *scratches head* [11:31:43] No, it was a mix [11:31:47] :-) [11:34:34] no updates from the build hosts. i wonder if the repodata is somehow screwed up [11:47:30] i guess fstrace needs XLIBS [11:59:09] There are RPMs in there which are younger than the reprodata. [12:00:13] My guess is that the createrepo or something like that need to be rerun. [12:01:43] that may be. i can't do it yet [12:01:49] i have no system to do so [12:08:38] * haba -> offline (icecream bar closes) [12:08:41] --- haba has left [12:09:21] beer->me [12:37:01] --- bpoliakoff has left [12:50:13] --- haba has become available [14:11:09] --- dev-zero@jabber.org has left [14:16:02] --- Russ has left: Disconnected [14:29:22] I've kicked the build system. [14:31:02] i'll re-rsync after i bike [14:31:31] It's just doing a rebuild, so it might take a while. You'll get email from it, or me, when its done. [14:33:17] ok [14:38:23] --- Russ has become available [15:26:52] --- dev-zero@jabber.org has become available [15:50:50] --- deason has left [15:50:57] --- deason has become available [16:25:32] --- pod has left [16:29:07] Should we create a new Git repository to hold our supporting tools? I'm thinking of the delta scripts that Simon has written and the generation scripts for the HTML pages. [16:29:17] Oh, btw, I'm converting the HTML CVS repository to Git now. [16:31:20] we should move or tools to git [16:31:27] "our" tools [16:32:28] Shall I create a new openafs-tools.git repository and start putting stuff in it? [16:32:40] Or should it be tools.git and we'll use it for tools for anything we host? [16:32:56] I called the web one openafs-web.git, since who knows, maybe we'll have some other web pages we host. [16:36:13] for the web pages one of the things that we want to have present on every page is the tracking code from google analytics. I wonder if we can ensure that is done properly with a pre-processing script in the git repository [16:36:48] Well, my plan is to take the current export script and teach it about Git. [16:36:56] At which point I think the right place to put that is into the export script. [16:37:10] Since the export script is responsible for pulling stuff out of Git and turning it into the actual web pages. [16:37:28] It already adds the frame stuff -- adding the Google Analytics stuff should be similar. [16:38:14] ok [16:38:57] --- cclausen has become available [16:40:54] I've wasted quite a bit of time working on https://www.ohloh.net/p/openafs. the announce mailing list now is registered through nabble as an Atom feed [16:41:44] We could add an "RSS" link from the existing web page to the Nabble RSS feed next to "News" [16:42:05] or perhaps a "RSS" link for each of the mailing lists [16:43:17] Ohloh is pretty neat. [16:43:26] * Russ has most of his stuff registered now. [16:44:17] Shawn Pearce is pretty high up in the kudos rankings [16:50:40] Good -- he really should be. [16:52:36] Anything besides export_htdocs, frameless, and make_www_release that I should import into the tools Git repository while I'm at it? I may as well do this properly and get the revision history. [16:53:25] I assumed make_release and make_snapshot would need to change so much the current versions are not horribly interesting. [16:53:53] I suppose I should grab relindex. [17:21:06] --- dev-zero@jabber.org has left [18:00:40] Looks like the way the frame pages are generated for www.openafs.org isn't supported by a current version of Apache, so I can't really fully test the scripts when they're being served by openafs.stanford.edu. So I think the next step is to write it into AFS. [18:07:02] --- mdionne has become available [18:08:40] Which I'm doing now, thanks to the setup jhutz did a while back. [18:09:17] how is apache failing? [18:09:38] The current frame htdocs setup relies on treating an shtml file as the document root. [18:09:48] Current Apache insists on the document root being a directory. [18:10:00] I didn't dive further into the Apache configuration stuff since I have another way to test, by way of sb.openafs.org. [18:10:13] ok [18:10:22] It's possible there's some way to tell it to work. [18:10:33] Writing to grand.central.org AFS cell very slow. [18:11:04] one thing that we need to decide on for documentation is what version we make available and whether we provide links to older docs [18:11:05] Well, to whatever volume /afs/grand.central.org/www/sb.openafs.org is in. [18:11:29] Ideally, we should build two doc trees, one from latest stable and one from latest development. [18:11:57] There are two new Git repos on git.openafs.org. [18:12:01] openafs-web.git has the web pages. [18:12:15] tools.git has an import of portions of gco-tools in a subdirectory called openafs. [18:12:23] can you get rid of the manpages directory? [18:12:28] openafs-web.git should be hooked into Gerrit. [18:12:34] tools.git should probably not be. [18:12:36] man pages are now on docs.openafs.org [18:12:42] tools.git is provisional -- jhutz may want me to do something else. [18:12:44] --- deason has left [18:12:52] --- stevenjenkins has left [18:12:54] --- abo has left [18:13:06] I figured I'd start with a repository and if jhutz wants to handle this another way, I can always back out and do something else, no harm done. [18:13:10] --- deason has become available [18:13:13] Sure. That will make this much faster. [18:13:28] --- abo has become available [18:14:42] I have a Git-aware export_htdocs. [18:14:45] That works fine. [18:14:47] --- haba has left [18:15:08] Once we know where we're putting the sandbox, I'll hook it into the openafs-web.git repository so that it automatically updates the sandbox on every commit. [18:15:15] If this is sb.openafs.org, I need a keytab. [18:15:25] With write access into that directory. [18:15:28] That volume is on grand.mit.edu. I can move it to Pittsburgh if you think that will make a difference. [18:15:28] --- haba has become available [18:15:42] Dunno, it might. It's almost done now. [18:16:01] --- stevenjenkins has become available [18:16:13] Gah, or maybe it's not. It has another manpages directory to go. [18:16:49] BTW, the stuff that was already in sb.openafs.org I moved into an OLD directory. If I messed anything up, let me know, and I can move stuff back. [18:17:03] I assumed since it was a sandbox I couldn't do much harm. [18:18:42] There are some things in /afs/grand.central.org/local/src, but most of it is related to maintaing the GCO machines, which means it probably doesn't want to move. However, there are a couple of things in src/tools that might be of interest, including what I _think_ are the latest cvsweb and wdelta and several things I was using for the experimental web site that was in sb.openafs.org before you started. [18:19:27] You probably don't even want those now, but I'm mentioning them in case anyone decides to start hacking on the web site and finds them interesting. [18:19:30] Yeah, I started with a CVS import of portions of /data/cvs/gco-tools, but I didn't take all of it, just the bits that looked related to the openafs site. [18:19:45] Cool, thank you. [18:20:05] I think that in the long run we may have to do something else for the frameset provisioning, unless I can figure out how to convince Apache to do that. [18:20:20] Yeah, the stuff in gco-tools is mostly what you wanted. [18:21:01] OK, I'm slightly confused. I may want you to do something else about what? [18:21:51] Hm. [18:22:15] Oh, in terms of how I grabbed bits of your tools and made a Git repository out of them. [18:22:29] I just don't want to grab stuff from your toolset without your permission or do stuff with it that you don't want done. [18:24:52] Okay, sb.openafs.org has all the files. It looks like it's not set up to serve the frameset through the DocumentRoot, which makes sense since that stuff wasn't there. [18:25:00] So you get the unframed front page. [18:25:18] --- mdionne has left [18:25:42] Oh. So, gco-utils contained two classes of things -- those used to maintain grand and those used to maintain the web sites. You probably don't care about anything in the first class, and you're welcome to do whatever you want with the second class. [18:26:14] take make_www_release from andrew ~shadow, btw [18:27:08] > not set up to serve the frameset Yeah. The theory at the time was that it wasn't going to use frames, and there'd only be one set of files. I can probably fix it up to do what grand did. [18:27:34] The httpd.conf for michigan is in /afs/grand.central.org/local/src/httpd [18:28:05] * Russ suspects you'll hit the same problem I did and Apache will barf. [18:29:20] I don't think so; michigan doesn't run apache 2 [18:30:08] Oh, okay. [18:30:10] --- mdionne has become available [18:30:22] Then yes, that would do it until we have a chance to do something else. [18:30:53] Should you give me a keytab and I should set things up to push the web site into some AFS directory which is then served by either michigan or grand? [18:30:57] --- mdionne has left [18:31:06] Ah! [18:31:11] I found it. [18:31:14] "Files processed for server-side includes no longer accept requests with PATH_INFO (trailing pathname information) by default. You can use the AcceptPathInfo directive to configure the server to accept requests with PATH_INFO." [18:32:31] Note that serving the web site from michigan is fine; that's really its primary role in life (once we thought we'd move mailing lists there, too, but I don't think that's going to happen any more) [18:32:59] And yeah, I can give you a keytab. [18:33:03] --- stevenjenkins has left [18:33:48] Okay, cool, let's go with that approach. Then in the longer run we can get a remctl call to release the prod web directory and I can have export_htdocs take a separate flag to update the prod area. [18:34:06] Yeah, that's a good idea. [18:35:02] You know, it's nice having a cell small enough for 'pts liste' to be a reasonable command to run [18:35:20] --- stevenjenkins has become available [18:35:58] What principal name do you want? [18:36:59] service/openafs-web would be the Stanford naming convention. I don't know how you tend to name non-human principals. [18:38:17] We tend to create users, sometimes more often than necessary. I should think about adopting the service/* convention. [18:38:34] either service/openafs-web or openafs-web works fine for me. [18:39:01] OK; give me a couple of minutes. [18:41:09] openafs.stanford.edu now serves the sandbox I'd been playing with as a proof of concept, so that we can see the Git export works properly. [18:47:37] /afs/cs.cmu.edu/user/jhutz/tmp/service-openafs-web.keytab.asc [18:48:01] User service.openafs-web has id 14771 [18:49:08] and openafs:gatekeepers now has 'a' on www/sb.openafs.org [18:53:56] Okay, when you get a chance, could you replicate the www.openafs.org frame configuration on sb.openafs.org? I'm getting things set up to write things there now. [18:55:34] yay! https://www.ohloh.net/openafs/ is now serving the OpenAFS announce list as the news feed [18:56:49] --- Jeffrey Altman has left [18:56:53] --- Jeffrey Altman has become available [18:58:34] openafs.stanford.edu looks fine [19:01:24] Yeah, let me see what I can do. [19:09:30] Oh, right, iptables doesn't let me talk to you on that server. [19:09:32] * Russ goes to fix that. [19:14:32] Why the hell is this still not working? Hm. [19:14:39] I can use that keytab from windlord, but not from openafs. [19:15:17] Ah, hm, kinit works but k5start doesn't. [19:24:19] Okay, that's fixed. [19:24:24] I should read my own documentation. [19:24:43] I believe it's now updating sb.openafs.org, although it's kind of slow, so we'll see what it's like when it's done. [19:30:09] * Russ suspects jhutz just ran into what I ran into and needs to add AcceptPathInfo on to the Apache configuration, or at least that's the error message I was getting when I had that problem. [19:31:36] maybe. [19:34:20] Ah, could you give openafs:gatekeepers the 'a' bit on .../www/sb.openafs.org recursively down the tree? [19:36:03] can't you? [19:36:16] Hm. [19:36:22] this is 1.3.33 acceptpathinfo is in 2.0.20 [19:36:31] 2.0.30 [19:36:41] Oh, okay. [19:36:43] And no: [19:36:45] openafs:/afs/grand.central.org/www/sb.openafs.org/elders> fs sa . openafs:gatekeepers all fs: You don't have the required access rights on '.' [19:43:06] --- Simon Wilkinson has left: Lost connection [19:49:11] huh [19:49:44] Oh, nevermind. You are not the volume owner. [19:51:37] ACL fixed [19:51:41] Danke! [19:59:26] openafs:/afs/grand.central.org/www/sb.openafs.org> rm .aliases rm: cannot remove `.aliases': No such file or directory openafs:/afs/grand.central.org/www/sb.openafs.org> cat .aliases # Special files at the root [...] [19:59:29] Er. [20:00:03] Hm. I think I lost a callback somewhere. [20:00:08] I see no such file in that directory [20:00:09] Flushing the directory fixed it. [20:10:23] Okay, I think my script works. [20:10:40] export_htdocs -s on openafs.stanford.edu writes the current Git tree to the AFS area for sb.openafs.org. [20:13:24] cool [20:15:10] Scripts are in /usr/local/bin and writable by webconfig group. [20:15:20] And they're all in the tools.git repository. [20:15:48] Right now, export_htdocs -s takes forever, so I'm not sure if we want to run it on every commit. [20:18:32] * Russ also fixed relindex so that it doesn't think 1.4.11pre3 is later than 1.4.11. [20:19:50] jhutz: If you want to give me a place to write the production www.openafs.org pages, I can put that into my script as well, and then we can start the process of moving from the current system to serving the pages out of AFS from a replicated volume. [20:22:52] Why is it slow? [20:23:02] I really don't know. [20:23:15] I'm not sure if I have something screwy in iptables, or if it's being really slow for some other reason. [20:23:21] I do have the callback port open to the world. [20:23:54] I can give you a place to write, but it won't be live [20:24:05] russ, i will need to regenerate the 1.4.11 release page in about 20 minutes. should i do it, or should i assume what you're doing will supercede it and not bother? [20:24:26] You should do it since grand is still serving the prod www.openafs.org site from local disk. [20:24:34] Unless jhutz plans on doing magic in the next 20 minutes. [20:24:36] ok [20:25:00] jhutz: Not live is fine -- I can get the script tested and we can throw the switch later. [20:29:26] The volume is there. I'm not even considering throwing the switch until next week. [20:29:58] Right. [20:30:02] cool, thanks. [20:36:49] or perhaps i will be unable to reach inf.ed.ac.uk. hm. [20:37:16] The system I have is writing everything to the top level of the AFS volume rather than doing the subdirectory and pivot thing. Should I change it to do the latter, or are we going to assume volume releases are going to take care of that? [20:38:19] volume releases should be sufficient [20:39:13] Okay, cool. [20:39:31] Yeah, I think it's fine to use volume releases. [20:39:38] Now populated and the script works. [20:39:48] But Jeff shouldn't assume that, since he doesn't know what sort of autoreleaser might appear. [20:39:52] export_htdocs without any arguments writes to the sandbox, with -p writes to the production directory. [20:40:13] It's actually exported, too, at http://michigan-openafs.central.org/ [20:41:04] Later (probably not before next week) I will replicate the volume and get afs-backend running on penn.central.org so you can do releases. [20:42:20] * Russ wonders what we should do about the "powered by" icons, which were specific to the Apache config on grand. We could either drop that bit or copy the icons into the htdocs tree. [20:42:37] i want a powered by electricity icon [20:44:12] http://www.furry.org.au/haal/plush/img/poweredby3.gif [20:44:26] alas, it only runs on Aussie/European power. :) [20:49:31] > we should do about the "powered by" icons fix the server config? [20:50:04] That also works. [20:56:45] Does your script re-export from scratch, or just 'git pull' ? [21:00:18] It re-exports from scratch. [21:00:33] It doesn't create a repository clone at all, actually -- it does a real export. [21:01:07] It would probably be smart to export to a local directory and then rsync or something so that I don't rewrite the whole site each time. [21:03:52] Hm, does that work? [21:04:17] Also, why not have a real clone? [21:04:52] No reason, really. I could do that -- it would certainly make updates faster. [21:05:27] And does which work? [21:05:33] Of course, it would make the directory grow without bound. [21:05:51] Does rsync do the right thing in that case, where you're regenerating the input every time? [21:06:32] Is openafs-web in gerrit? [21:06:45] not yet [21:08:06] It does, kind of. [21:08:08] It's not great. [21:09:25] Yeah, it does, but git archives are small. [21:09:32] I think I'm going to go that route. [21:09:41] That should be fast enough I can do it from a hook. [21:13:03] The standard template includes a "last modified" tag at the bottom that depends on RCS keyword expansion. [21:13:25] Which means a bunch of pages need to be fixed, somehow [21:14:50] Yeah, I was noticing that. I can do that. [21:27:01] Ah, need more quota in the www.openafs volume. That's why that's failing. [22:40:09] --- dev-zero@jabber.org has become available [22:45:24] --- deason has left [22:58:25] --- dev-zero@jabber.org has left: Replaced by new connection [22:58:25] --- dev-zero@jabber.org has become available [23:10:33] --- reuteras has become available [23:12:51] --- reuteras has left [23:19:25] --- reuteras has become available [23:35:34] --- Russ has left: Disconnected