[00:10:08] --- jaltman/FrogsLeap has left: Disconnected [00:10:49] --- jaltman/FrogsLeap has become available [02:49:49] Email cellservdb@grand.central.org with the new CellServDB line. CellServDB updates are sporadic at best, though, so you may be in for a long wait. [02:50:03] --- reuteras has left [02:50:15] --- reuteras has become available [04:56:15] --- reuteras has left [04:56:35] --- reuteras has become available [05:38:12] --- meffie has become available [05:42:36] --- canehan has become available [05:45:53] --- canehan has left [06:22:24] --- mho has become available [06:33:39] > Hmm, what's the proper procedure for CellServDB updates, again? Send mail to cellservdb@grand.central.org. Do it now, because I'm planning on doing a release this morning. OpenAFS source tarballs shouldn't include a CellServDB at all, though the actual binary releases do. I generally try to do an update just in advance of OpenAFS stable releases. [06:35:21] I'll check and make sure what I release today has current athena servers. [06:43:53] OpenAFS source tarballs do include CellServDBs, unfortunately, for all sorts of reasons that I don't entirely remember. [06:44:28] Our packaging process for (at least) Fedora should pick up new ones from grand.central.org, rather than using the one from the repository whenever the SRPM is built. [06:51:05] --- reuteras has left [07:06:31] --- jaltman/FrogsLeap has left: Disconnected [07:06:42] --- jaltman/FrogsLeap has become available [07:12:11] --- deason has become available [07:15:00] 2/3 servers listed for athena.mit.edu in the Feb, 2010 CellServDB are still correct. The paris/aether swap is one I know about. Do OpenAFS source tarballs include an _ancient_ CellServDB ? [07:25:35] They include multiple CellServDBs. I can't comment on their age. [07:31:39] I'm sure that no one has updated the CellServDB files in the 1.4 branch Windows tree since 1.4.2 since Windows no longer builds on that branch [07:31:46] --- meffie has left [07:31:53] --- meffie has become available [07:36:32] Great. Let's get the CellServDB files out of the source repository, please. There's no reason they should ever be there. [07:37:53] may I ask why you didn't remove them from the tree in 2000 when you prepared it for cvs? [07:38:16] the reason they are there is because the installer build processes require a local in tree copy [07:42:04] I probably didn't notice they were there. You could fix the installer build process. Or force people to fetch a fresh one manually. [07:42:13] Anyway, whatever. [07:42:56] You could at least replace all the stale CellServDB in the repository with /afs/.grand.central.org/service/csdb/CellServDB-2010-12-13 [07:42:57] I suspect the version that is being commented upon is the 5 Jul 2007 src/afsd/CellServDB on master. I don't know if that copy is used any longer [07:43:22] s/You/someone [07:45:19] when new versions are announced, copies are pushed prior to the next release. [07:45:52] Apparently not to all of the copies in the tree. [07:48:37] as I said, I'm not sure that the src/afsd/ copy is used any longer. [08:00:06] In any case I'm taking care of updating everything [08:04:00] Great; thanks. [08:09:47] since we are on the subject of CellServDBs, what I think we should do is support CellServDB and CellServDB.GCO. Where CellServDB contains local entries and is authoritative. CellServDB.GCO is used as a secondary public lookup prior to DNS [08:10:42] --- ktdreyer has become available [08:11:10] Windows already has multiple sources. The lookup order is Windows Policy (registry), CellServDB, DNS [08:11:28] Eh. That doesn't seem superior to the merge-from-multiple-sources approach that most of the existing packaging is already taking. [08:13:33] merge has its own set of problems. its not possible to determine what is local from what is not after the fact. updating the cellservdb after the initial installation is fraught with peril. [08:16:18] It's possible if you keep a copy of what you last merged, as MacOS does. [08:16:29] (or at least, I'm pretty sure it does; I remember cg2v writing that code) [08:17:43] if I remember correctly, that code does a poor job of handling the case where an entry has been modified locally and in the CellServDB and they don't match. [08:19:16] the process also has the negative side effect that a user examining the resulting output thinks the in use CellServDB is the copy from GCO because that is what it says at the top of the file in the grand.central.org entry comment [08:20:25] I believe that merge from multiple sources is a fine process for sites that choose to use it as part of the local CellServDB management. I do not believe it is appropriate to use for end user systems. [08:22:15] Well, I suppose we could support CellServDB.d [08:23:08] On a related subject, I believe that most sites that publish DNS records for AFS should not be listing server entries in their GCO CellServDB. The name of the cell should be listed but no servers. That would permit tools to recognize that the cell exists but permit DNS to be used for the lookups [08:23:43] And yes, things that merge should also arrange for the merged thing to correctly identify what it is. [08:26:11] So, the GCO CellServDB has traditionally not included no-servers entries because ancient versions of AFS can't deal with that. We do perform AFSDB lookups at the time a CellServDB is published, for cells that are marked for that behavior. Producing a version with no-servers entries instead of cached AFSDB lookup results has been on my todo list for a while, but it's of limited utility because almost no cells have that flag set. [08:26:25] > The name of the cell should be listed but no servers I was considering that, but what about clients that predate afsdb, or don't have it turned on? [08:28:34] I would argue that most sites that do not have afsdb turned on shouldn't be trusting the OpenAFS installed CellServDB. [08:29:48] I think that Jeff H. is correct that the right thing to do is have two versions. OpenAFS would distribute the AFSDB aware one [08:33:25] should we turn on client afsdb by default, then? (if/when we do that) [08:33:41] Jeff, would you consider publishing a version of CellServDB in Kerberos Profile format complete with the "DNS" tags set? If so, then I would suggest that the CellServDB.d file be in Kerberos Profile format. Other per cell values I would like to see are alternate default service port numbers. "no dns". "require dns" [08:34:26] windows has always had dns on by default. Windows doesn't use the IP address values in the CellServDB. It always looks up the host names. [08:34:39] UNIX should do the same [08:34:43] (for clients only) [08:34:51] --- abo has left [08:38:35] another parameter that might be stored in such a profile is the list of Kerberos realms considered to be local [08:39:34] > merge has its own set of problems. its not possible to determine >what is local from what is not after the fact. bull. [08:40:12] > because that is what it says at the top of the file in the > grand.central.org entry comment wow. i wonder if it's possible to edit the merge script to fix that? ;) [08:44:16] --- deason has left [08:44:47] --- abo has become available [08:47:22] > Kerberos Profile format Not until the development community nails down exactly what that should look like, including how (if at all) it relates to the issue of richer configuration for Ubik servers. But once that stuff is finalized, sure, I don't see why not. [08:48:05] --- deason has become available [08:53:33] I suspect that we should consider making DNS take priority over CellServDB. [08:53:48] And then providing a mechanism for overriding DNS where people absolutely must. [08:59:42] the problem with dns having priority is that users of sites that do not publish dns records will end up experiencing delays [08:59:58] Tricky, given the way the Unix CM currently handles this. I agree that in the general case it is preferable to use DNS instead of a database like the GCO CellServDB, when the former has data. However, local overrides are fairly important. [09:00:38] They'll surely only experience delays in cases where the site has no DNS at all. Otherwise, getting an error back should be pretty rapid. [09:00:39] Only if the DNS is broken. An NXDOMAIN doesn't take more time to return than a legitimate answer. [09:01:46] I've seen plenty of places where hotel DNS drops AFSDB and DNS SRV record lookups on the floor [09:02:17] If you're using Kerberos, you've already lost at that point. [09:03:09] I don't know about AFSDB, but dnsmasq does include a "filterwin2k" option which is documented to "filter useless windows-originated DNS requests which can trigger dial-on-demand links needlessly" but which in fact simply punts all SRV requests. [09:28:07] yeah "filterwin2k" is a pretty misleading title for that setting [09:28:19] that bit me last week [09:43:46] I haven't read the entire thread yet, but the freebsd packaging was grabbing src/afsd/CellServDB . Is it supposed to be fetching the GCO one over http instead? [09:51:14] What I believe is that OpenAFS packages should not include a CellServDB file at all. Instead, the OpenAFS installation should periodically check for an update from GCO and silently install it as the public version. [10:01:05] "What can I do now, without code change or cooperation from other people?" I expect this was covered already, but auto-fetch would have the nasty side effect of overwriting local changes. [10:02:22] you should read the thread [10:09:07] If you include a CellServDB in your package, you should fetch it when the package is built, instead of using something out of the OpenAFS source tree. You can fetch the latest one, or if you want the package to be reproducible, you can use one of the timestamped filenames. [10:10:32] auto-update sounds nice to some people, but is not always appropriate or compatible with policy. That's really a decision best left to package mainatiners. [10:11:22] I think that if CellServDB is going to be packaged, it should be in its own package [10:12:23] Whereas most of the package maintainers seem to believe that the software should work out of the box. [10:12:50] A CellServDB should not be required for OpenAFS to work [10:13:00] But anyway, I have a lot of work to get done today, so I'm not going to participate in a discussion on packaging right now. [10:16:36] --- Russ has become available [10:31:10] Is there a way to get push notifications when a new GCO CellServDB goes out instead of polling? [10:57:51] i think there's a cellservdb-announce list? [10:59:50] > I haven't read the entire thread yet, but the freebsd > packaging was grabbing src/afsd/CellServDB . Is it supposed to be fetching the GCO one over http instead? ideally it would do that, using the same merge infrastructure the macos rc script does [12:11:17] > Is there a way to get push notifications subscribe to cellservdb-announce [12:15:26] > If you include a CellServDB in your package So, FreeBSD is something of an odd case in that the majority of the end users are going to be using a Makefile (and maybe a couple other scripts) that I (the package maintainer) provide to compile the software on their own machine. I expect only a small number of people to use a binary package provided from the FreeBSD servers. Thus, any script which fetches the CellServDB needs to be robust enough to run successfully on a user's machine at an arbitrary time. [12:21:51] > Thus, any script which fetches the CellServDB needs to be robust > enough to run successfully on a user's machine at an arbitrary time. the macos thing will [12:23:21] is the openafs source itself contained in the ports repo, or does the ports makefile cause the source to be pulled from somewhere else? (like git) [12:23:39] it pulls tarballs. or did. [12:24:34] pulling CellServDB I would assume is about as reliable as that, so I don't see an issue [12:25:10] if it doesn't pull... well, cellservdb updates aren't very frequent; you could just update it yourself when it changes [12:27:15] > pulling CellServDB I would assume is about as reliable as that, you'd be correct; they're distributed via the same mechanisms from the same servers. [12:28:48] --- Russ has left: Disconnected [12:34:52] --- Russ has become available [13:48:35] --- jakllsch has left [14:04:02] --- jakllsch has become available [14:20:54] It still pulls tarballs, and could pretty easily be convinced to pull a CellServDB. It probably wants to checksum it, though, which is why I asked about push notification for updates :) [14:26:18] --- jaltman/FrogsLeap has left [15:27:37] --- deason has left [15:51:31] --- deason has become available [18:48:40] Are there known issues with 'backup' from 1.5.78 on DARWIN? [18:52:23] --- shadow@gmail.com/owl497D8295 has left [19:03:51] --- kula has left [19:10:53] --- mfelliott has become available [19:10:53] --- mfelliott68059 has left [19:21:22] --- ktdreyer has left [19:24:26] --- ktdreyer has become available [19:44:14] I'm pretty sure there's not much testing of the combination: darwin, 1.5, and the openafs native backup system [19:44:26] unless there's a darwin tool called 'backup' you're talking about [19:44:30] or "vos backup" [19:47:10] --- mfelliott has left [19:47:11] --- mfelliott has become available [19:53:54] --- kula has become available [19:54:21] This was referring to the openafs native backup system. quentin@mit.edu got a bus error attempting to do a restore using the version on his laptop. [20:13:12] can he get a stack trace into an rt ticket? [20:13:36] Maybe. He is sometimes lame about these things. [20:14:07] or just create a ticket; I can try reproducing locally but you'll probably have to wait a least a week that way [20:21:17] --- ktdreyer has left [20:21:35] --- ktdreyer has become available [22:13:09] --- deason has left [22:30:54] --- reuteras has become available [23:50:13] --- Russ has left: Disconnected