[00:38:03] --- Simon Wilkinson has left [01:55:56] --- Russ has left: Disconnected [04:06:31] --- haba has become available [06:57:19] --- deason has become available [08:50:31] Am I correct that the contents in my RHEL/Centos /etc/yum.repos.d/openafs.repo must be updated for every release of OpenAFS? [08:50:55] # cat /etc/yum.repos.d/openafs.repo [openafs] name=OpenAFS 1.4.12 for RHEL baseurl=http://dl.openafs.org/dl/openafs/1.4.12/rhel5/i386/ [08:51:26] Or should there be a baseurl that contains ALL releases for rhel5/i386 ? [08:54:09] yes, that's correct. [08:54:27] we have our own yum repo to handle such things [08:54:46] so we can release kernel and kmod-openafs packages at the same time [09:09:19] Admins find it clumsy if they have to edit a file every time they want to upgrade OpenAFS. They just want to use the yum commands to upgrade kernel and AFS packages in one go. [09:10:08] "oh I have to edit this file for OpenAFS and I really do not care about OpenAFS so much, so it got stuck in 1.4.7" [09:19:39] if the official repos were the other way around, and your clients and servers upgraded without you knowing, and something broke, who would you blame then? [09:20:26] the person who ran 'yum upgrade' (or whatever the command is) without expecting it to upgrade something [09:20:34] and anyway, for clients, upgrading afs also involves restarting afs, unloading kernel modules, etc, which you can't do when someone's logged in and using afs [09:21:28] so letting yum update afs when there's a new version doesn't help much when manual intervention is still required. I would imagine most admins will have found a way around this [09:23:16] so you just don't upgrade in-place; it is much better than upgrading "never" [09:23:47] you need to reboot to upgrade a kernel, but you don't need to edit some conf file manually in order to do so [09:23:49] (I hope) [09:39:11] --- jaltman has left: Disconnected [10:05:42] The conf file you need to edit when you upgrade kernels (for grub) is taken care of automatically. Is OpenAFS the only upgrade you can get by yum that requires a reboot? How do other packages handle this? [10:09:07] > only upgrade you can get by yum that requires a reboot er, what about the kernel? [10:10:04] other than that, I thought simon said something to the effect of that fedora (or rhel? or whatever) doesn't include packages that add kernel modules... which would mean nothing else requires it [10:10:04] --- phalenor has left: Lost connection [10:10:24] in the official distros anyway; I assume there's lots of third-party stuff like us that add them [10:10:52] of course, debian does this with openafs and other things... not sure if you're asking aout yum specifically, though [10:12:11] --- phalenor has become available [10:12:46] because the issue was on a centos system. [10:12:57] upgrading afs doesn't require a reboot, just a restart of the client, which means unmounting /afs, which means nothing can have files open in /afs [10:13:46] if you can deal with the fact that afs won't get upgraded until the machine gets rebooted, then there's that. could also wach the output of lsof or something to tell when it's safe to /etc/init.d/openafs-client restart [10:14:54] regarding the dl.openafs.org yum repo, I think the rest of us either push out a new openafs.repo, or provide our own yum repos for afs [10:14:59] It's just a pity if admins upgrade the kernel because of the latest exploit and then not even get the latest OpenAFS onto the machine at the same time. [10:15:02] createrepo is really really easy to use [10:15:04] --- deason has left [10:15:34] (This is not about us who have more than a thousand clients.) [10:15:35] --- deason has become available [10:15:52] ah [10:16:22] --- meffie has left [10:16:24] I asked why the openafs.org yum repo wasn't set up to work that way a year or two ago, don't know if I ever got a response [10:16:39] This is about the lone admin who did put in the openafs repo some years ago and then forgot about that it is version specific. [10:17:06] or at least provide a repo both ways, one for each specific version, then another for allowing updates through yum without switching repos [10:17:34] Yes. repos should be cheap. [10:18:45] (Would a horde of softlinks do the trick?) [10:20:29] probably, not sure how createrepo actually works or if it would care about such things [10:22:15] probably have to run createrepo after every add of softlink, but other than that should be fine. Or just copy the stuff. [10:22:28] * haba but gotta run *bye* [10:22:40] --- haba has left [10:23:09] --- meffie has become available [11:12:33] --- jaltman has become available [11:20:40] --- rra has become available [12:23:21] --- jaltman has left: Disconnected [12:23:45] --- jaltman has become available [13:37:01] --- shadow@gmail.com/owlEBE83A21 has left [13:37:32] --- jaltman has left: Replaced by new connection [13:37:37] --- jaltman has become available [13:44:11] --- phalenor has left [13:44:57] --- phalenor has become available [13:49:07] --- jaltman has left: Disconnected [13:49:19] --- jaltman has become available [13:52:26] i have an abort packet that has the code 49733392, translate_et says "Unknown code uae 16 (49733392)". does that mean EBUSY? [13:57:14] (49733392 is defined as UAEEXIST) [14:01:00] sounds like EEXIST [15:23:43] --- deason has left [15:24:13] --- deason has become available [15:27:00] --- deason has left [15:35:50] --- jaltman has left: Replaced by new connection [15:35:51] --- jaltman has become available [15:54:47] --- Simon Wilkinson has become available [15:58:42] If folk have time to help maintain the OpenAFS yum repo, rather than just bitching about it, any and all assistance is gratefully received. [16:57:39] --- Simon Wilkinson has left [16:58:55] --- jaltman has left: Disconnected [17:09:13] --- jaltman has become available [17:24:19] I hear this 'ezyang' fellow just lost a big time commitment ... [17:25:22] mix? [17:40:31] Not a mix -- Edward is now in the UK, but has had a decent amount of experience with openafs on fedora. [19:31:51] --- rra has left: Disconnected [19:54:48] --- Russ has become available [21:39:42] ...having confused yet another person over on IRC :)