[00:14] <r3pek> hey guys
[00:15] <r3pek> anyone know if anything changed on 3.0.0 relating to barriers/ext4
[00:15] <r3pek> ?
[02:57] <LLStarks> hi apw or ogasawara, i'm curious as to why the mainline repo uses a hardy toolset. i
[02:57] <LLStarks> hi apw or ogasawara, i'm curious as to why the mainline repo uses a hardy toolset. i'd like to be able to use oot modules
[02:58] <LLStarks> srry for rpt. touchpad screws around.
[04:34] <twb> Hi, I'm deploying lucid in a bunch of prisons, and for security reasons it has been decided that simply blacklisting drivers (e.g. wifi, USB mass storage) is not sufficient; the .ko files need to be gone.
[04:34] <twb> Currently I'm doing this by rm'ing them, but the number of drivers to remove is growing and I'd prefer to just grab the ubuntu kernel, edit the .config, and "make deb-pkg" or so.
[04:35] <twb> Should I start from the debian source package, or from the ubuntu git (bzr?) repo?
[04:36] <ohsix> you might just replace the hotplug/module loader, or do something with udev to not allow access even if they are loaded; if you give privileges to people they'll be able to do stuff
[04:37] <twb> I think the main concern is that if they manage to escalate to root privileges, they would be able to undo e.g. /etc/modprobe.d blacklists
[04:38] <ohsix> they will also be able to do anything else, like build another module, replace the entire kernel from the repo; anything
[04:38] <twb> All the desktops netboot from a read-only NFS export, so it's not a big deal management-wise to have a custom kernel package in that NFS export
[04:39] <ohsix> there's already policy to control access to stuff, and it's not in the kernel
[04:40] <twb> ohsix: What are you talking about?
[04:47] <RAOF> twb: There are fancier ways of doing things, but you should be able to grab the archive kernel source package, make a change, and rebuild it.
[04:50] <RAOF> twb: You've seen things like https://wiki.ubuntu.com/KernelTeam/GitKernelBuild and https://help.ubuntu.com/community/Kernel/Compile ?
[04:52] <twb> RAOF: I've been flipping through the /KernelTeam subpages as I spoke; before today I'm only familiar with the Debian kernel handbook and misc. upstream usage
[04:52]  * twb reads those specific subpages
[04:58] <twb> Thank the gods you aren't using bzr for ubuntu kernel patches; I'd have gone insane
[05:09] <twb> RAOF: is make-kpkg still du jour for building kernels?  I thought everybody had moved on to "make deb-pkg" ?
[05:10] <RAOF> twb: When I've interacted with the kernel packages I've used neither; fakeroot debian/rules binary-generic has been my invocation of choice.  Often with some environment variables set.
[05:10] <twb> Hum, OK
[05:10] <twb> I think I will just try deb-pkg anyway and see how I go
[06:09] <twb> Ahaha, I git cloned into a setgid dir, so now dpkg refuses to operate because debian/ is 2755
[06:14] <twb> Hm, I just realized the desktops are still stupidly running i386.  So let's change "make deb-pkg" to "linux32 make ARCH=i386 deb-pkg"...
[06:15] <twb> Bleh, no joy
[07:26] <kees> twb: you can just set /proc/sys/kernel/modules_disabled
[07:26] <kees> twb: see https://wiki.ubuntu.com/Security/Features#block-modules
[07:27] <kees> no need to do anything crazy with recompiled kernels :)
[07:28] <RAOF> But surely that can be disabled if someone's already successfully done a priviledge escalation to root?
[07:29] <ohsix> if you get root all is lost, most would say that having physical access means you already lost :>
[07:30] <RAOF> I guess you can always mount some writable storage, grab your kernel module, and insmod.
[07:31] <ohsix> yep
[07:36] <twb> kees: that would prevent other modules being loaded tho
[07:36] <twb> kees: like, what if they plug in a USB keyboard afterward
[07:37] <twb> The prisoners have physical access to their desktops, but what they can bring into the prison is (obviously) controlled, e.g. they're not going to be allowed to walk in with a live CD
[07:38] <twb> The BIOSes are also patched to prevent booting from anything but the network.
[07:38] <twb> And yeah, I grant you that if they get root I'm pretty fucked, but defense in depth dictates that I at least try to slow them down
[07:39] <ohsix> you might want to whitelist things then
[07:39] <ohsix> with something like apparmor or selinux
[07:39] <twb> Mm
[07:39] <ohsix> er nm you already mentioned ubuntu, apparmor :]
[07:40] <ohsix> there are a lot of ways to go from x -> y though, it will still be hard to be worthwhile
[07:40] <twb> apparmor is on there, but I haven't riced it up yet
[07:41] <twb> I definitely should, I just haven't gotten around to it yet
[07:41] <ohsix> if something comes up apparmor will give you pretty responsive policy control too
[07:44] <kees> RAOF: /proc/sys/kernel/modules_disabled ? no, it's one-way
[07:44] <kees> RAOF: with modules_disabled set, insmod will not work.
[07:44] <twb> kees: as in until reboot?
[07:44] <kees> twb: I thought you said you wanted no modules to load? I'm confused.
[07:44] <kees> twb: right
[07:44] <twb> I want specific classes of devices to not work
[07:44] <kees> twb: until you set it again. on my colo I load usb, usb-hid, usb-storage, then set modules_disabled.
[07:44] <twb> e.g. no wifi, ever
[07:45] <kees> aaaah
[07:45] <twb> But it does sound like a good idea
[07:45] <twb> I can probably just dictate that e.g. USB keyboards MUST be plugged in before booting
[07:45] <twb> And set that in e.g. rc.local
[07:45] <kees> the plug-in will be fine as long as the module is loaded
[07:46] <kees> just load usb and usb-hid before blocking modules. basically take the whitelist, load them all, then block modules.
[07:46] <kees> I'm still suspicious of the overall effectiveness of this in the face of physical access, though :)
[07:47] <kees> the BIOS can't be interrupted to allow init=/bin/bash or anything silly?
[07:47] <twb> Well, pxelinux is configured not to allow that, and the bioses are patched (by the hardware vendor) not to allow editing of the boot order
[07:47] <twb> They could probably pull open the case and set a jump or reflash the bios or something, if they were clever
[07:48] <twb> But remember this is inside a prison
[07:48]  * kees nods
[07:48] <twb> Also most of the prisons are coming from running Windows desktops, so the simple fact that e.g. there's no hard disk, that rebooting puts them back to a "clean" version of the OS, has them completely stoked
[07:49] <kees> yeah
[07:49] <twb> This is mostly just me being super pedantic
[07:49] <twb> Like I try to make it so the easiest way for them to run scripts, is to have to write them in oo.org, because they can't get xterm or tty1 or gedit
[07:50] <ohsix> and disable alt+f2, it's really a dead end though
[07:51] <twb> ohsix: yeah, that one is easy, you just write /etc/gconf.blah/mandatory.xml
[07:51] <twb> If it was *me* attacking and I had all year I could probably do some damage, but the tech-savvy prisoners tend to be watched more closely, etc.
[09:08] <gentoo_drummer> ayone here?
[09:08] <gentoo_drummer> anyon*
[10:17] <awilkins> Hello ALSA driver people
[10:17] <awilkins> My latest problem ; any sound directed to the rear right channel is actually playing in rear left
[10:34] <aquarius> I'm getting frequent-ish kernel panics on my HP microserver -- there have been three in the last 24 hours. I'm currently running memtest on the machine, but it's not showing any memory errors so far. It's running Ubuntu Server 11.04. http://ubuntuone.com/4NvFGyH0YdJS17wpDEl2fI is a picture of the most recent. What's the best way to get information to you guys?
[10:35] <aquarius> https://help.ubuntu.com/community/DebuggingSystemCrash suggests taking a photo, as above; should I just attach that photo (and others if/when it panics again) to an LP bug?
[10:50] <smb> aquarius, basically yes. Maybe you could get another photo (which is slightly more readable) when it happens again. But otherwise open the bug with "ubuntu-bug linux" and then attach it to the generated report
[10:51]  * aquarius laughs
[10:51] <aquarius> no offence taken at my poor photgraphy skills :)
[10:51] <aquarius> I shall file a bug
[10:51] <smb> aquarius, Appreciated and I know it can be a pain. :)
[10:51] <smb> (meaning to get a readable result from a photograph)
[10:57] <aquarius> (the machine's headless, so I'm not sure ubuntu-bug will work, but I'll file it the hard way :))
[11:42] <_ruben> so you took a picture of a headless machine's screen? ... interesting :P
[12:57] <apw> awilkins, file a bug with ubuntu-bug audio and that will get all the info needed to work out how audio is routed
[12:59] <Q-FUNK> apw: is 'ubuntu-bug audio' documented anywhere? the man page has nothing about it, yet this would seem to be an eminently useful feature.
[13:00] <apw> a good question indeed, have no idea, i only found out yesterday, i'd been using ubuntu-bug alsa-drivers until then (when it stopped working)
[13:00] <Q-FUNK> ok
[13:01] <Q-FUNK> btw, any news about why vesafb disappeared from mainline's standard builds?
[13:01] <awilkins> apw, Hello again ; I had a look with HDA_analyzer and codec-graph but it doesn't really illuminate the issue since the problem is that half of a stereo pair is going awry ; they only seem to deal with stereo pairs and not individual channels
[13:01] <awilkins> Unless I'm missing something
[13:01] <apw> how are you directing to a specific channel
[13:02] <apw> and is the other half working ?
[13:02] <awilkins> apw, The problem is that the audio for the right rear channel is ending up in the left rear channel
[13:02] <apw> and the audio for the left rear ?
[13:02] <awilkins> Absent
[13:02] <awilkins> Oh, no left is fine
[13:02] <awilkins> Sorry
[13:03] <apw> so left goes left, and right goes left, and right output has ?  nothing ?
[13:03] <awilkins> Yup
[13:03] <apw> now that is odd indeed, could the channel be in mono mode ?
[13:03] <awilkins> I'll fire up HDA_analyzer again
[13:06] <ppisati> mdeslaur: how do i turn off a cve for a branch? previously we had to do it via bzr/cve-tracker, is it still like this? or are cves connected to the corrispective lp bug?
[13:06] <awilkins> I'm not the only person to notice but the only mentions I could find were quite old
[13:08] <mdeslaur> apw: could you answer ppisati? I'm not sure where and how you guys do it...
[13:08] <ppisati> previously we did it via bzr
[13:08] <ppisati> but i heard there was some work toward integrating cves and lp bug
[13:10] <janimo> hello kernel people. I am maintaining the linux-ac100 package and packaging git tree which is now mirrored on kernel.ubuntu.com/git . Shall I mirror the upstream branch I am pulling from there as well?
[13:11] <awilkins> apw, D'oh. It was a partially unseated jack ; must have been shorting the right channel with the left
[13:11] <janimo> my workflow now is, git fetch + git rebase origin but for others to be able to work from the same git tree, they'd need to know where upstream is
[13:19] <apw> awilkins, heh that seems plausable
[13:19] <apw> janimo, why would they need the upstream tree ?
[13:25] <apw> if they are working relative to your tree, your tree is the tip that jumps about that they need to rebase their stuff against ...
[14:03] <ppisati> apw: so, if i want to mark a kernerl release as "not affected", how do i do it? still via bzr and cve-tracker?
[14:03] <ppisati> apw: i mean, cve-wise
[14:05] <apw> ppisati, in theory you should be able to mark it invalid in the bug and it should get copied over
[14:05] <ppisati> apw: ok
[14:16] <ogra_> apw, hmm, i saw several users compßlaining their PS/2 keyboards stopped working on x86 installs ... did we drop any config option here ?
[14:16] <ogra_> seems the same users had them working before upgrading from natty 
[14:16] <ogra_> as well as before a reinstall
[14:17] <ppisati> ogra_: i'm usiong a ps2 keyboard and, so far, everything is fine
[14:17] <ogra_> ppetraki, awesome 
[14:17] <ogra_> so its om their side, great
[14:17] <ppisati> ogra_: in the past, it has happened that after a bit my keyboard suddenly died
[14:17]  * ogra_ doesnt even have such HW around anymore to confirm such stuff
[14:17] <ppisati> but, so far, it's more than a week with no problem
[14:17] <ppisati> i mean
[14:18] <ppisati> more than a week since i upgraded to oneiric on this box
[14:18] <ppisati> and it's ok
[17:12] <janimo> apw, re upstream tree. In case they want to roll a new deb keeping the same packaging but fetching some more upstream commits before
[17:12] <janimo> they can do it now I guess but they need to define their remote
[17:16] <SinnerNyx> i was directed here from #fluxbox. I am running ubuntu-server and installed fluxbox with xinit. when I exit fluxbox the tty appears as: http://tinypic.com/view.php?pic=2s690dx&s=7
[17:19] <bjf> ogasawara, whats the timeframe for uploading the first precise kernel ?
[17:20]  * bjf just remembers she's gone today
[17:20] <cking> precisely
[17:21] <bjf> you've been waiting to throw that out :-)
[17:34] <SinnerNyx> thoughts?
[18:14] <Insyte> I would like to backport (or otherwise obtain) a karmic/lucid kernel to hardy in order to get the fix for this bug:  http://goo.gl/XoFwY
[18:15] <Insyte> Is there a good way to go about this process other than just installing the kernel package from the newer release?
[18:16] <Insyte> One the one hand, it seems like it should be pretty simple as I've routinely replaced kernels on other distros.  But I'm worried about identifying user-space incompatibilities.
[18:17] <jjohansen> Insyte: yep userspace problems, and external drivers (dkms, ...) are the big problems
[18:18] <jjohansen> Insyte: you can try it, and it should likely work, but know that you will need an updated apparmor userspace in hardy as well, if you do this
[18:19] <jjohansen> Insyte: if this bug is affecting hardy, it should probably be an SRU fix
[18:19] <Insyte> Would you recommend just installing the package from Lucid and backporting the userspace stuff?  Or would there be any reason to recompile the kernel on a hardy box?
[18:20] <Insyte> And yeah, the bug is affecting Hardy.  We can reliably reproduce.  Unfortunatley Apparmor changed significantly between hardy and the release the patch was written for, so the patch won't apply to a 2.6.24 kernel.
[18:20] <jjohansen> Insyte: the reason to compile on hardy would be if there are any modules being compiled on the box, dkms does this (not used in hardy), I can't remember the module solution for hardy
[18:21] <jjohansen> as long as the kernel and modules are compiled with the same tool chain it doesn't really matter whether its the same as the rest of the system
[18:21] <Insyte> OK, cool.  Should I open a new bug report since 415632 is marked "fix released"?  Or would it make more sense just to reply to the same bug?
[18:22] <jjohansen> Insyte: well, that is interesting, the bug specifically mentions it being a regression from jaunty which came after hardy
[18:22] <jjohansen> Insyte: please open a new bug, and post it here, and I will take a look at it
[18:22] <Insyte> Cool, thanks.
[18:23] <jjohansen> Insyte: also there is a #apparmor channel on irc.oftc.net, and an apparmor ml (apparmor@lists.ubuntu.com) if you are running into apparmor specific problems
[18:25] <Insyte> Thanks.  Was your patch accepted upstream?  If so, probably no point in bringing it up with them.
[18:27] <jjohansen> Insyte: yes its upstream.  I didn't suggest those specifically for the patch but, if you say try a new kernel and run into problems with the apparmor user space not loading, or some such.  As that would be a better place to discuss that kind of thing than here
[18:27]  * jjohansen is in both places
[18:27] <Insyte> Ah, I understand.  Thanks.
[19:17] <Insyte> jjohansen: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/874544
[19:17] <ubot2> Launchpad bug 874544 in linux "mkdir failure on NFS with Apparmor" [Undecided,New]
[19:17] <jjohansen> Insyte: okay I'll take a look
[19:17] <Insyte> Much appreciated!
[19:18] <Insyte> I am happy to provide any additional details I may have missed.
[19:38] <jjohansen> Insyte: hopefully I will have a kernel for you to test this afternoon, if I need any more info I will ask for it in the bug
[19:39] <Insyte> Awesome, thanks!
[19:48] <jjohansen> Insyte: do you have any log messages with info about the reject?
[19:49] <jjohansen> This is definitely a different than bug #415632
[19:49] <ubot2> Launchpad bug 415632 in linux "apparmor not properly handling file deletion on NFS" [Medium,Fix released] https://launchpad.net/bugs/415632
[19:51] <Insyte> jjohansen: When called from our PHP code, it logs "No such file or directory"
[19:52] <jjohansen> Insyte: is there an apparmor reject in dmesg
[19:52] <jjohansen> or in the No such file or directory what is logged?
[19:52] <Insyte> Not a reject, no, but a "info="Failed name resolution - object not a valid entry""
[19:53] <Insyte> type=1503 operation="inode_mkdir" info="Failed name resolution - object not a valid entry" error=-2 requested_mask="w::" denied_mask="w::" pid=7283 profile="/usr/sbin/apache2//www.example.com" namespace="default"
[19:54] <jjohansen> Insyte: thanks
[19:54] <Insyte> All PHP logs is "No such file or directory", then a reference to the code that called "mkdir()".
[20:39] <Insyte> So I'm attempting to install a Lucid kernel on one of my Hardy test machines:
[20:39] <Insyte> # dpkg -i linux-image-server_2.6.32.34.40_amd64.deb
[20:40] <Insyte> Preparing to replace linux-image-server 2.6.32.34.40 (using linux-image-server_2.6.32.34.40_amd64.deb) ...
[20:40] <Insyte> Unpacking replacement linux-image-server ...
[20:40] <Insyte> dpkg: dependency problems prevent configuration of linux-image-server:
[20:40] <Insyte>  linux-image-server depends on linux-image-2.6.32-34-server; however:
[20:40] <Insyte>   Package linux-image-2.6.32-34-server is not installed.
[20:40] <Insyte> That seems... circular.
[20:41] <ohsix> you're installing the .40 image which linux-image-server doesn't like?
[20:42] <Insyte> Oh, hmmm... I think I see the problem.
[20:42] <Insyte> Yeah, I inadvertently grabbed the virtual package.
[23:40] <niceplace> hi
[23:42] <niceplace> i want to compile the 3.1 linux kernel
[23:42] <niceplace> i know it is rc but i need it
[23:42] <niceplace> is it too dfficult for a n0ob ?