[01:04:05] --- summatusmentis has left [01:09:44] --- reuteras has become available [01:31:05] --- haba has become available [01:46:36] This Linux (Scientiffic Linux 6.0) seems to habe selinux enabed by default. Anything special I should think about before running the DB servers on that? [01:46:56] --- jaltman has left: Disconnected [02:55:55] --- jblaine has left [04:02:05] --- shadow@gmail.com/barnowlA109197F has left [04:04:25] --- shadow@gmail.com/barnowlA109197F has become available [04:23:38] --- steven.jenkins has left [05:50:06] --- summatusmentis has become available [06:20:23] --- jblaine has become available [06:21:48] --- steven.jenkins has become available [06:22:01] --- lars.malinowsky has become available [06:22:13] --- lars.malinowsky has left [06:43:10] --- Simon Wilkinson has become available [06:43:49] haba: Providing you use the standard locations for everything, the RedHat SELinux profile should work fine with OpenAFS servers. [06:44:19] (With 1.6.0, it will also work fine for OpenAFS clients. Prior to 1.6, there are some packaging, and runtime issues that can trip you up) [06:52:38] --- reuteras has left [07:23:13] * haba does not have the standard locations. [07:24:09] In which case, you're going to need to alter the SELinux configuration so that all of the non-standard locations have the correct security information. Good luck! [07:32:50] --- deason/gmail has become available [08:25:57] --- haba has left [08:26:29] --- haba has become available [09:13:26] --- summatusmentis has left [09:15:49] And BTW I am not running 1.6.0pre-something which I would get from SL as my DB servers yet. [09:54:31] --- mfelliott has left [10:08:12] Anyone know anything about s390 RPMs? Is there any reason to still disable authlibs on that platform? [10:11:17] istr that came from me, but i don't remember why [10:12:41] --- summatusmentis has become available [10:14:22] * haba runs now the DB servers under selinux started by root and it seems to work (inherits stuff from root shell I suppose). Will probably disable selinux next time I reboot the box (when I am in the same machine room to catch if it goes wrong). [10:16:29] Simon: Apart from that, does that mean there should be a selinux profile about openafs somewhere in /usr/share/selinux/ ? [10:20:44] The selinux stuff has already annoyed me, looks like it makes all network connection to sshd look like they come from loopback, i.e. 127.0.0.1. [10:22:39] When I finally shipped around that cliff, the selinux pam stuff logs me out again if I come in with GSSAPIKeyExchange but it works fine with Passwordauth. But sshd in debug mode on another port "of course" works. [10:23:44] Simon Wilkinson: david b tells me we disabled authlibs for sles9. i can check if we still need to for sles10. [10:24:15] That would be good. Ideally, I'd like to drop that section from the spec file. [10:58:35] simon, you are refering to the build_authlibs in the spec, right? [11:04:45] Yeah, that's the one. [11:11:56] --- Simon Wilkinson has left [11:12:05] --- Simon Wilkinson has become available [11:36:48] --- jaltman has become available [11:53:22] --- ktdreyer has become available [13:58:21] hmm, if I'm getting soft lockups in linux as a result of someone copying something into afs (second time this has happened today under the same circumstances), if it's an afs issue, is there some alt+sysrq key combo I can use to figure out where things are stuck? [14:08:38] alt sysrq t [14:13:26] now to figure out how to send that over conserver... [14:21:07] it should be the first break sequence over serial [14:21:45] I don't remember the specific key sequences to get conserver to send "special" stuff, but I recall there's a help screen that lists the stuff you can send [14:21:53] --- cudave has become available [14:22:11] and l0 through l4 (or l9 or something) are a bunch of different break sequences; iirc l0 is what you wan [14:22:12] t [14:22:19] yeah [14:22:23] phalenor - I see similar soft lockups when copying fr my home machine to work afs [14:22:31] and then just type the key to go along with the sysrq, so 'h' gives you the help message [14:22:34] at work, my afs volume basically stops responding until the copy is complete [14:22:49] You can also just echo t to /proc/sysrq-trigger [14:22:57] Simon Wilkinson: can't login to the machine [14:23:08] Ah. Well, that won't work then. [14:23:43] I think with conserver the l0 to l9 break sequences are configurable - so one site's l0 may not be another's. [14:24:04] need to define \zt as a particular break sequence, and the conserver.cf syntax is a bit confusing [14:24:58] yeah, but if you haven't done this before, it tends to be the default :) [14:25:15] I don't remember needing to configure anything to get sysrq to work; I thought the l0 default just did it [14:25:30] 0 just sends a break in my case, which is the default [14:25:52] --- ktdreyer has left [14:26:16] So l0t should be what you want, I think. [14:26:30] that sends a break, then the letter t [14:26:45] yes [14:26:51] just tried defining \zt as a break, but no luck [14:27:09] a break over the serial console should engage the sysrq stuff [14:27:09] You want to send a break, then the letter t. [14:27:18] what Andrew said ... [14:27:29] then that's not working in my case [14:27:46] Whose kernel are you using? [14:27:49] the kernel has to have the sysrq stuff enabled [14:27:54] some debian incarnation [14:28:07] which is enablable/disablable at runtime via a sysctl [14:28:41] well, we seem to be able to reproduce this fairly easily, so I could just reset it a second time and enable it via sysctl [14:29:06] well, before you reset the box, if a 'cmdebug' from another machine doesn't hang, that could also help say what it's doing [14:29:08] --- jaltman has left: Disconnected [14:29:59] cmdebug: error checking locks: server or network not responding [14:30:27] yep, a reset is in order [14:31:34] it's a 2.6.38-2-amd64 kernel if that means anything to anyone [14:34:34] alright, so that setting is a bitmask, and it's set to 438. [14:36:44] which should mean that 't' should work, I think [14:38:08] according to wikipedia's reporting of that bitmask, you want 0x8 [14:38:08] --- haba has left [14:38:21] which is not included in 438 [14:38:30] ok, then I suck at math ;) [14:38:38] I'd just set it to 1 [14:39:49] yep [14:40:38] sounds like a similar issue was brought up on -devel sometime in may for the 2.6.38 kernel, but it doesn't look like anything became of it [14:43:25] and that user is gone for the day, but they should see my email soon enough [14:50:35] --- jaltman has become available [14:50:52] phalenor: Do you have a reference for when in May that came up? [14:51:13] https://lists.openafs.org/pipermail/openafs-devel/2011-May/018381.html [14:51:23] that's the last in that thread [14:51:55] --- jblaine has left [14:51:55] --- meffie has left [14:52:10] I think Marc investigated that problem a bit. [14:53:06] http://rt.central.org/rt/Ticket/Display.html?id=129751 [14:53:21] (fixed in 1.6.0pre6) [14:53:25] oooh, new spiffy RT ;) [14:54:55] excellent [14:55:37] now to find the best way to get this thing up to pre6 [14:59:14] --- meffie has become available [14:59:21] --- jblaine has become available [15:04:26] ah, Russ had to wait a day or so. We can reproduce this within minutes of the system being up. [15:14:04] anyway, email sent to russ re: pre6 in wheezy. thanks for the help. [15:17:54] It could still be a different bug. [15:19:47] you speak as if there's more than one bug in the client [15:19:49] preposterous [15:20:20] well, all signs point to this one bug [15:20:40] ignoring the fact that we're talking about afs [15:25:38] Yeah, and Linux, where every vendor seems to do something different with regards to the soft lockup detection options. [15:38:31] --- deason/gmail has left [17:01:11] --- Russ has become available [17:04:33] OpenAFS 1.6.0pre6 isn't in wheezy because it doesn't build on armel due to a bug in gcc. Sadly, not something I can do anything about. [17:05:07] --- meffie has left [17:05:07] --- jblaine has left [17:09:46] --- jblaine has become available [17:11:51] Is $(shell $(shell ), even [17:15:10] I'm pretty sure that's a GNUism. [17:15:26] Yeah. Sadly, it's crept into the tree with the SWIG stuff. [17:21:52] Simon, won't you have to delete all the old BP-- tags off of master? [17:22:24] (I never liked them anyway; there are a few old useless CVS tags that I think we could stand to nuke.) [17:25:43] It's only an issue right now, because it interferes with building off master. [17:26:17] I guess the old ones will get in the way if we want to use new tools to build older code - but I suspect we won't be able to do that. [17:26:47] But yeh, I'd have no problem with nuking all of the BP— tags. I don't think they add any value now. [17:28:14] (This is all part of a plan to be able to do RPM builds of any commit of the code, so that we can get some test coverage of rpm building before it comes to release time) [17:29:44] Well, I was probably assuming the wrong cause of the breakage. I was thinking the breakage was due to our use of that git command to generate version numbers backing up and then generating a version based on the BP tag. [17:39:20] That's exactly what's happening on master at the moment, and why the BP-openafs-stable-1_6_x tag needs to go. [17:41:16] Wouldn't it then just go back to the next older BP- tag and fail the same way? [17:41:23] That's why I was thinking you'd need to kill all of them. [17:58:38] --- steven.jenkins has left [19:52:38] --- steven.jenkins has become available [23:43:47] --- reuteras has become available [23:52:23] --- haba has become available