[00:37:12] --- Russ has left: Disconnected [02:48:12] --- Simon Wilkinson has become available [03:17:17] --- Simon Wilkinson has left [03:17:17] --- Simon Wilkinson has become available [04:41:44] --- Simon Wilkinson has left [06:55:48] --- Jeffrey Altman has become available [06:55:54] --- Jeffrey Altman has left [07:01:50] --- mho has become available [07:04:43] --- reuteras has left [09:47:44] --- dwbotsch has left [11:00:27] --- geekosaur has left [11:03:48] --- geekosaur has become available [11:25:56] --- rra has become available [12:34:37] --- jaltman has left: Disconnected [13:07:36] --- haba has become available [13:20:48] --- jaltman has become available [14:11:18] --- Simon Wilkinson has become available [14:11:37] --- Simon Wilkinson has left [14:13:44] --- Simon Wilkinson has become available [14:14:39] Rick Cochran's problem (on openafs-info) is intriguing. If we had a general 1.4.12 data corruption problem we would surely have heard the screaming by now. [14:48:32] He suggests that just Ubuntu (and hence, I suspect, Debian) is broken. But I don't think even a general breakage there is plausible. [14:49:31] I'd be curious what is used as a cache partition. [14:51:28] I have an Ubuntu 10 test box at work but I don't know if I can test something tomorrow (E-NO-TIME). [14:52:53] 1.4 should just refuse to play if it doesn't like the look of your cache partition [14:54:55] Should I ask him to restart with memcache and see if the problem is still there? [14:59:23] But if it would be a general Ubuntu 10 problem, I would have heard from our department who has a lot of student workplaces on that. [14:59:39] But it could be something new, like ext4 [15:06:28] * haba uses still ext2 for cache partitions. [15:06:53] So do we [15:07:13] --- geekosaur has left [15:08:45] --- mdionne has become available [15:10:11] --- geekosaur has become available [15:43:53] --- jaltman has left: Disconnected [15:46:07] or nobody diligently checksums their files [15:54:44] If you have Git repositories in AFS, you'd probably notice fast. [15:55:55] We use ext3 for cache partitions. [15:56:28] --- jaltman has become available [16:00:54] good point [16:01:35] we're either memcache or ext2 where it matters [16:15:54] --- jaltman has left: Disconnected [16:15:58] --- jaltman has become available [16:24:08] --- jaltman has left: Replaced by new connection [16:24:09] --- jaltman has become available [17:33:11] --- Simon Wilkinson has left [18:28:26] --- rra has left: Disconnected [18:41:50] --- jaltman has left: Disconnected [18:47:31] --- Russ has become available [18:55:26] --- jaltman has become available [18:57:24] * Russ is going to patch the server hosting this, Gerrit, etc., late tonight and reboot for a kernel upgrade. Shouldn't break anything -- just a Debian stable update. [19:37:11] --- mdionne has left [21:51:49] Hey Russ, why are you rebooting to pick up a kernel update? Isn't that what ksplice is for? [21:53:05] I don't think I have any of the facilities required to make use of ksplice. [21:53:27] What distribution is the machine running? Is it running that distribution's standard kernels? [21:54:13] Debian stable, yeah. [21:56:13] stable is lenny? Looks like uptrack is $4/mo for that, after a free 30-day trial [21:56:45] Yeah. Not sure why I'd bother when I can reboot the system for free. :) [21:57:34] reboots are not free; they cause disruption [21:59:37] ksplice itself is free in any event. What your paying for is the service of having someone else transform updates released by upstream into something ksplice can load (plus automation for obtaining and applying them) [21:59:44] Out of curiosity, are you completely confident in ksplice? I've been hearing about it for a while, but I've always been a bit dubious that, particularly when applying security updates, it really gets all of it and completely closes the vulnerability. [21:59:59] One of the reasons why I like rebooting after any security update is that it ensures you don't still have old shared libraries loaded and whatnot. [22:00:04] Does the same thing for the kernel, of course. [22:03:53] I am reasonably confident that it performs as advertised, but that's based more on my impressions of the people involved plus a general understanding of how it works; it's not like I've done any detailed analysis. Most security fixes involve relatively small changes in behavior, which ksplice should handle well. Of course, applying an update doesn't save you if someone has already taken advantage of the hole. [22:04:07] You would probably get a better answer in another forum. [22:04:59] Yeah, you of course lose if someone already broke in. [22:05:26] Investigating deploying ksplice-based updates to our own kernels and to AFS modules is definitely on my todo list; I just haven't had the cycles. It's certainly a big improvement over pushing out traditional updates that never get used because users don't reboot. [22:05:36] It's kind of amusing that ksplice is possible, but we can't modify the system call table because that would be insecure. [22:06:12] It's kind of amusing that some OSes provide a supported interface to modify the system call table but we don't use it. [22:07:40] We do in some places. [22:07:42] AIX, IIRC. [22:07:46] IRIX too, I think. [22:07:59] And we did something like that on Solaris. [22:08:08] AIX system calls are effectively by-name, and we do use that mechanism. [22:08:16] We started looking at ksplice for our timeshare systems. [22:08:36] For most servers, they're load-balanced, and I don't really mind rebooting them occasionally. I kind of like it, since I know that the system will come back up after a reboot. [22:08:44] I'd rather find out problems during a maintenance window. [22:08:49] But for some of our client systems, it would be nice. [22:08:49] Definitely. [22:10:27] On Solaris we follow the mechanism for "registering" system calls for the benefit of things that keep track of such things, but our system call number is fixed, and we get control by patching the system call table. Under an appropriate lock, of course. [22:20:32] > It's kind of amusing that some OSes provide a supported interface to > modify the system call table but we don't use it. we predate those interfaces. also, freebsd was unloved for quite a while [22:23:12] In some cases, we predate those entire operating systems. :-) [22:25:18] ahem linux. [22:35:54] --- reuteras has become available [22:45:55] --- pod has left: Lost connection [23:39:13] --- Simon Wilkinson has become available [23:50:37] Starting the upgrade of the system now. Will be rebooting in a few. [23:53:05] good luck [23:57:06] --- LOGGING STARTED [23:57:11] --- Russ has become available [23:57:28] --- Jeffrey Altman has become available [23:57:53] --- jaltman has become available [23:58:05] --- geekosaur has become available [23:58:37] --- shadow@gmail.com/owlF25FFC04 has become available