[00:56] <hallyn> gary_poster: that shouldn't be lxc...
[00:56] <hallyn> gary_poster: to top running int he container, there's no difference between tasks in or not ina  continer
[00:56] <hallyn> gary_poster: now if you set the cgroups to throttle the container, you can do that, but then the container would act slow...
[00:57] <hallyn> and actually, you could pin it to one cpu and limit memory, but you can't make it slow (only give it fewer cpus shares if there are other active competing tasks)
[01:51] <hallyn> smoser: you've got impressive bash-fu.  Do you mind proofreading my bash replacement for lxc-wait?
[01:52] <hallyn> (it seems to work...)
[01:52] <smoser> sure
[01:53] <hallyn> smoser: http://people.canonical.com/~serge/lxc-wait
[01:53] <hallyn> thanks
[01:55] <smoser> hallyn, how real a critique do you want
[01:55] <smoser> ?
[01:55] <smoser> :)
[01:56] <hallyn> smoser: particularly things that look dangerous (that a c programmer would mistakenly do in a bash script)
[01:56] <smoser>  * container_exists does not check the return code of lxc-ls
[01:56] <hallyn> smoser: hopefully it won't have to live long...
[01:56] <hallyn> (only until i re-write all of lxc in go)
[01:56] <smoser>  * verify_state() does not use local variables
[01:56] <smoser> and
[01:57] <smoser>   for((i=0;i<${#valid_states[@]};i++)); do ... ; done
[01:57] <smoser> would be bash specific, but does not fork for 'seq'
[01:57] <hallyn> smoser: to spare others, do you mind pastebining?  :)
[01:57] <smoser> you could also do that with a local 'i' counter variable and increment it with i=$(($i+1))
[01:58] <hallyn> smoser: i don't mind bash specific, this is definately bash.  will use that thanks
[01:58] <smoser> verify_states: use local variables
[01:59] <smoser> hm...
[01:59] <smoser> can i do this tomorrow, hallyn ?
[01:59] <smoser> can you just ping me when you get in ?
[01:59] <smoser> i'm way past should-be-working time
[01:59] <hallyn> smoser: sure - thanks
[01:59] <smoser> you know, that in general, stuff like this:
[01:59] <smoser>  s=`lxc-info -s -n $lxc_name | awk '{ print $2 }'`
[01:59] <smoser> just doesn't check for failure
[01:59] <smoser> right?
[02:00] <smoser> even with set -e (which i generally dislike) that will not fail
[02:00] <smoser> because the return code used for checking is that of 'awk' which most likely didn't fial
[02:00] <hallyn> yeah...  is therea  better idiom?
[02:00] <hallyn> use variable for each step?
[02:01] <smoser> that is safer. then you can catch the failure of one.
[02:01] <smoser> or, direct to a file
[02:01] <hallyn> (it's tough to resist my love of pipelines :)
[02:01] <smoser> and then read from file
[02:01] <hallyn> i'll split it into steps.  thanks.  good night.
[02:01] <smoser> in bash, you can actually do it
[02:01] <smoser> see BASH_PIPESTATUS (man page)
[02:01] <smoser> might be PIPE_STATUS
[02:01] <smoser> good night
[02:03] <lifeless> smoser: pipefail isn't it?
[02:03] <lifeless> smoser: or do you mean manually implementing it via $PIPESTATUS ?
[02:04] <hallyn> pipefail sounds nice
[02:17] <twb> I use pipefail all the time
[02:17] <twb> Otherwise false | true will not cause an abort in set -e
[02:18] <twb> http://paste.debian.net/160476/
[02:31] <hallyn> twb: i've learned something today
[02:32] <hallyn> gary_poster: around?
[02:32] <twb> I strongly recommend having all sh code peer reviewed by #bash
[02:32] <hallyn> freenode?
[02:32] <twb> Yes
[02:32] <hallyn> are they going to bikeshed?
[02:32] <twb> twkm, greycat et al may be acerbic, but they will help you avoid the most common fuckups
[02:32] <twb> hallyn: yes, but feel free to ignore that
[02:33] <hallyn> :)
[02:33] <hallyn> cool, i think i'll start doing that. thanks!
[02:33] <twb> It is a lot like #netfilter, if you read and understand the FAQ then you have 90% of the problems solved
[02:33] <twb> Even just lurking there helps
[02:54] <linocisco> hi pfsense vs Ubuntu server , which is stronger and reliable ?
[02:58] <qman__> linocisco, both are strong and reliable
[02:58] <qman__> pfsense is a tailored firewall distribution, while ubuntu server is general purpose
[02:58] <qman__> both can run most of the same software, and perform most of the same tasks
[03:54] <twb> In lucid, why are there both ipset and xtables-addons-common packages
[03:54] <hallyn> jjohansen: any news on aa_getcon?  does it help if i file a bug?  i can't really push new lxc without it fixed
[03:54] <hallyn> (bc user wouldn't e able to disable apparmor)
[04:22] <twb> I have a lucid server.  I want to use ipset on it.  As at lucid, xtables-addons is implemented via module-assistant, but I want the dkms version.  I can cherry-pick xtables-addons-dkms from natty, but this needs a newer libxtables.so (from the iptables package).  Should I keep cherry picking from natty, or is it time to say "this is silly" and do something different?
[04:22] <twb> Hmm, and natty's iptables package needs a newer nfnetlink
[05:18] <jjohansen> hallyn: aa_getcon should be working in current, as long as you make sure the profile has access.  Adding the following rule to the profile will do it
[05:18] <jjohansen>   /proc/*/attr/current r,
[05:18] <jjohansen> The bug is in the failure path
[05:19] <hallyn> jjohansen: but even just running a test case unconfined i get the weird result
[05:19] <jjohansen> or at least that is how it is working for me.  I have a patch for that, and am working on change_profile on exec, which isn't setting the perm in the profile correctly
[05:20] <hallyn> jjohansen: i just (20 mins ago) switched to a hand-rolled read from /proc/%d/attr/current...
[05:20] <hallyn> i can try switching back tomorrow though with that policy added
[05:20] <jjohansen> hallyn: hrmm, it has been working fine for me, but I haven't checked inside a container yet
[05:21] <hallyn> jjohansen: i'm not doing it in a container
[05:21] <jjohansen> hallyn: hrmm strange.  can you send me your code so I can use that exactly
[05:21] <hallyn> jjohansen: and even the code in lxc i was using, that was in the usr.bin.lxc-start profile which doesn't restrict /proc
[05:21] <hallyn> ok
[05:22] <jjohansen> hallyn: I will get it sorted out tonight, so you can play with it in the morning
[05:24] <hallyn> jjohansen: http://paste.ubuntu.com/893227/
[05:24] <hallyn> jjohansen: right now it's giving me the right profile, but 128 return value
[05:24] <hallyn> jjohansen: yesterday i swear it was giving me NULL or something else for profile
[05:25] <hallyn> jjohansen: i'm heading off - good night
[05:26] <jjohansen> hallyn: okay I will audit through again, and test. I can believe it failed especially if you did it in a profile, the failure path returned garbage
[05:26] <hallyn> jjohansen: oh and i did figure out the lvm problem, fwiw.  apparmor just aggravated a weirdness
[05:26] <jjohansen> hallyn: oh! Thanks, thats one less thing to look at tonight
[05:28] <hallyn> jjohansen: ok so i guess failure path needs to get cleaned up no matter what :)  otherwise i was going to say since workaround works, if you have other things to work on, i can get by...
[05:28] <hallyn> thanks again - good night
[05:28] <jjohansen> good night hallyn
[08:20] <linocisco> hi all
[09:02] <lynxman> morning o/
[09:04] <bluefrog> is this channel ok for 12.04 problems?
[09:05] <soren> bluefrog: Probably.
[09:06] <soren> bluefrog: Depends on the problem, really. The fact that it's on 12.04 isn't a problem.
[09:06] <soren> I mean... er... the fact that it's on 12.04 doesn't disqualify it from this channel.
[09:07] <soren> Quite the contrary, IMO. 12.04 is much more interesting.
[09:07] <bluefrog> upgraded yesterday to 12.04. (was 10.04 before). Have dns and dhcp server on the machine. before the search domain was ok i could host computer and have an answer. since the upgrade the search domain doesn't work. I have to enter an FQDN to do a host query
[09:08] <soren> What's in /etc/resolv.conf?
[09:08] <bluefrog> added dns-search domain.local to /etc/network/interfaces, restarted networking service but with no luck
[09:09] <soren> bluefrog: Is resolvconf installed?
[09:09] <bluefrog> soren,  basic stuff from resolvconf. hang on
[09:09] <bluefrog> nameserver 127.0.0.1
[09:09] <soren> Ah.
[09:09] <bluefrog> host computer.domain.local is ok host computer is not
[09:10] <soren> If that used to work, we should be looking at your DNS config.
[09:11] <soren> Can you pastebin the output of "ls -l /etc/named" (or is it /etc/bind9? I always forget)
[09:11]  * soren has a hunch
[09:12]  * soren recommends pastebinit
[09:12] <bluefrog> named.conf.local amongst other. the db are located in /var/lib/bind
[09:13] <bluefrog> soren http://pastebin.com/Tyfmzmrz
[09:14] <soren> Hm. No .dpkg-old files.
[09:14] <bluefrog> no
[09:16] <greppy> bluefrog: is "nameserver 127.0.0.1" all that is in your /etc/resolv.conf?
[09:16] <bluefrog> yes
[09:16] <bluefrog> the rest is in /etc/resolvconf.resolv.conf.d/original
[09:17] <greppy> bluefrog: try adding "search $domain" and "domain $domain" where $domain is what domain you expect it to find
[09:17] <bluefrog> greppy, this I don't need I know it works. I am fighting with the resovlconf package
[09:18] <bluefrog> it gets the domain ok as a fqdn host search works
[09:19] <bluefrog> http://pastebin.com/HNR3vR0J
[09:21] <bluefrog> I suppose it get the domain form this file. I added search domain.local to that file, restarted networking and resolvconf but it still doesn't get the search part
[09:24] <bluefrog> and yes of course it works when adding the search part to resolv.conf directly
[09:27] <soren> bluefrog: Can you pastebin your /etc/network/interfaces?
[09:28] <soren> bluefrog: Does the search bit in /etc/resolv.conf get overwritten once you restart networking? (Just making sure that resolvconf actually does run)
[09:28] <bluefrog> http://pastebin.com/minAwPdq
[09:28] <bluefrog> testing the rest
[09:29] <bluefrog> soren, right on. resolv.conf is not rewritten after a service networking restart
[09:35] <bluefrog> but ifdown eth0 ifup eth0 does the trick
[09:36] <bluefrog> and it works now
[09:36] <bluefrog> thx soren
[09:36] <bluefrog> and greppy
[09:37] <bluefrog> a bit weird though that I had to bring down/up eth0. thought networking service restart would d o that
[09:38] <ivoks> soren: i'm running for a motu again :) i would appriciate your input on https://wiki.ubuntu.com/AnteKaramatic/DeveloperApplicationMOTU :D thank you
[09:40] <bluefrog> well iresolv.conf is not rewritten at every ifdown ifup
[09:42] <soren> ivoks: Whuh?
[09:42] <soren> ivoks: Oh, you expired?
[09:42] <ivoks> yeah :/
[09:43] <soren> tsk, tsk :)(
[09:43] <soren> :)
[09:43] <ivoks> hehe
[09:46] <soren> ivoks: done
[09:46] <ivoks> soren: thanks
[11:52] <Daviey> jamespage: please upload rabbitmq, FFe Ack'd
[11:52] <jamespage> Daviey, ack
[11:53] <Daviey> soren: if you can touch memberships, i also expired from MOTU.. (gah).. i'd like to re-be an explicit member please.
[11:53] <Daviey> jamespage: did you see bug 961008 ?
[11:54] <Daviey> jamespage: I think this upload solves that?
[11:55] <jamespage> Daviey, I don't think so - that looks like something local to the reporter
[11:55] <jamespage> I'll take a look tho
[11:55] <Daviey> win
[11:56] <jamespage> Daviey, no idea what 'airtime-easy-setup' is doing...
[11:57] <Daviey> jamespage: no, i don't know either.
[11:57] <Daviey> jamespage: don't worry about that one
[11:57] <jamespage> I won't
[11:57] <jamespage> :-)
[11:58] <jamespage> lynxman, Daviey: rabbitmq-server uploaded
[11:58] <lynxman> jamespage: \o/
[12:44] <zul> hallyn: ping
[12:44] <hallyn> zul: .
[12:44] <zul> hallyn: have you ever came across the virtio-console stuff from qemu-kvm
[12:44] <hallyn> no
[12:45] <hallyn> zul: is it something supposedly in teh code, or proposed and never pulled in?
[12:45] <zul> hallyn: ah ok...we are running into a problem in openstack that if you send junk to the console then the console.log will just fill up and dos the machine
[12:46] <zul> the code is there already but the patch isnt
[12:46] <hallyn> patch fixing the dos?
[12:47] <zul> hallyn: it just throttles the console basically when the chardev cant handle any more info: https://build.opensuse.org/package/view_file?file=0008-virtio-console-Enable-port-throttling-when-chardev-i.patch&package=qemu&project=home%3Aftr3g%3AVirtualisation-test&rev=1cecc426586196cfc468312adca8583a
[12:51] <zul> hallyn: what do you think?
[12:52] <zul> totally untested of course but thats my theory anyways
[12:55] <hallyn> zul: I can't find mailing list discussion of it.  Amit is still active, so it might be worth asking him.
[12:55] <hallyn> since it sounds like you have a testcase, should take 3 mins to test right?
[12:56] <zul> hallyn: right
[12:56] <zul> hallyn: lemme see if i can find the thread
[12:58] <zul> hallyn: starts here: http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg01048.html
[12:58] <Cryp71c> Working with an ubuntu-server, it restarted and the openssh didn't seem to start (or at least I couldn't access it externally via ssh), one of our on-site guys had to fix it...want to make sure this doesn't happen again so I'm looking at the services that run at startup via "service --status-all" and ssh is listed as having a + next to it...
[13:06] <hallyn> zul: so it was quite simply nacked
[13:06] <hallyn> and the async api never showed up
[13:06] <hallyn> (which i don't think wouldve helped with your problem)
[13:08] <zul> hallyn: k
[13:09] <hallyn> zul: what does the client do to dos the machine exactly?
[13:09] <zul> hallyn: im thinking this more what i need though: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=f1925dff7e6c4799f5951cf167a437c0737a266c
[13:09] <hallyn> looking
[13:10] <zul> hallyn: im not sure, if you just send malicious data it would be possible to keep filling up the log files
[13:10] <hallyn> define malicious
[13:10] <hallyn> the patch you cite is there...
[13:11] <zul> yeah
[13:12] <zul> spamming /dev/ttyS0 with dd or some such from within the instance
[13:12] <hallyn> and this is only for serial?
[13:12] <zul> correct afaik
[13:12] <hallyn> I recommend you write the m-l, or if you prefer open a bug (and i'll lookat it after i clear lxc)
[13:13] <hallyn> (one more look at the patch)
[13:13] <zul> hallyn: heh bug already open https://bugs.launchpad.net/nova/+bug/832507 ;)
[13:14] <hallyn> crap been around awhile
[13:14] <hallyn> i'll mark it affecting qemu-kvm.
[13:14] <zul> yeah we had a work around for a while now which is causing other problems now as well
[13:15] <zul> ill try going down the rabbit hole with the virtio-serial throttling as well
[13:15] <hallyn> thanks.
[13:34] <hallyn> stgraber: are you around, do you have 1.5 minutes?
[13:34] <twb> That's a very specific interval...
[13:34] <hallyn> i didn't say 1.50 :)
[13:35] <hallyn> buys me a half-moment more if i need it
 I'm after somebody who's got five minutes.  <twb> Five minutes... in a row?
[13:37] <twb> Ah, the benefits of having an in-office fortune file.
[13:37] <hallyn> twb: you use containers right?  I'm trying to decide whether to risk slice-n-dicing containers on upgrade, or ask the few people usign lvm-backed containers to update themselves
[13:38] <twb> I'm using lxc but only on lucid, and it's about 50:50 whether I will even bother with precise or just wait til 2014
[13:39] <hallyn> yup i knew you were on lucid :)  ok thanks
[13:39] <twb> I am using lxc on lvm tho
[13:39] <stgraber> hallyn: yep
[13:39] <hallyn> i *suppose* i could just force-mount proc if i need to
[13:39] <hallyn> stgraber: for bug https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/960860
[13:40] <hallyn> the problem is: to change apparmor profile in lxc-start, you need to write to /proc/slef/attr/exec
[13:40] <twb> It's too late to for me to think about that tonight
[13:40] <stgraber> hallyn: right, yeah, I noticed that and that's also what's forcing us to allow procfs and sysfs in the container as lxc won't mount them itself
[13:40] <hallyn> stgraber: but the way lxc works, it refuses to mount a file listed in /var/lib/lxc/container/fstab if the target pth is absolute and doesn't start with the contaienrs rootfs
[13:40] <twb> Also my brother and his friend both just busted in blind drunk
[13:40] <hallyn> stgraber: i'm trying to figure out the best course of action...
[13:41] <hallyn> twb: good luck wwith that :)
[13:41] <stgraber> hallyn: could we allow entries like "/usr/lib/lxc/root/..." in the fstab?
[13:41] <hallyn> stgraber: i was going to upgrade containers, but maybe it's better to figu
[13:41] <hallyn> right
[13:41] <hallyn> no
[13:41] <hallyn> that still requires a change to the containers
[13:41] <hallyn> i'm wondering if i should update lxc to guess /var/lib/lxc/<containe/rootfs and allow that
[13:41] <hallyn> i think that's best
[13:42] <hallyn> so then even though rootfs.path = /dev/sda1, it'll allow /var/lib/lxc/container/rootfs...
[13:42] <hallyn> i'll do that.  thanks  :)
[13:42] <stgraber> np :)
[13:42] <hallyn> stgraber: no reason not to use relative paths in new containers right?
[13:42] <hallyn> (i.e. 'proc proc proc defaults 0 0' in place of 'proc /var/lib/lxc/c1/rootfs/proc proc defaults 0')
[13:43] <hallyn> ok with that fixed i think i'm going to push the next version
[13:43] <hallyn> (then do one more update after aa_getcon is fixed)
[13:46] <stgraber> hallyn: relative sounds like a nice default
[13:46] <hallyn> yeah looks prettier too.  ok i'll do that, thanks
[13:46] <stgraber> hallyn: that way people can rename/move their container without having to update the fstab
[14:00] <hggdh> roaksoax: I am using fence_cdu to reboot 4 machines in four individual processes; the output from fence_cdu (on all processes) show *all* machines, not only the one affected by each process. Is this a bug?
[14:00] <hggdh> roaksoax: the processes are started at the same time, BTW
[14:02] <hggdh> hallyn: what could cause http://pastebin.ubuntu.com/893637/ ? It happens every so often
[14:03] <hggdh> hallyn: this is Oneiric, BTW
[14:04] <hallyn> hggdh: what are the lines pefixed with + ?
[14:05] <hggdh> hallyn: this is the output of a shell script, run with '-x'. The '+' lines are expansion from the '-x'
[14:05] <hallyn> hggdh: no idea, never seen it..
[14:05] <hallyn> heavy load?  precise?
[14:06] <hggdh> hallyn: OK. I will open a bug. What would you like for libvirt debugging?
[14:06] <hggdh> hallyn: at the time this happens, there are four different processes trying to start a domain, at the same time
[14:06] <hggdh> hallyn: oneiric
[14:07] <hallyn> xml dump, ps -ef, result of repro wit libvirt_debug=1...
[14:07] <hallyn> oh.
[14:07] <hallyn> oneiric is known unstable under load :(
[14:07] <hallyn> i haven't found the patch to cherrypick to fix it
[14:07] <hggdh> gawddammit..
[14:07] <hallyn> i'm considering asking if i can backport the precise version
[14:07] <hggdh> so no need for a bug?
[14:07] <hallyn> lemme find the existing bug
[14:08] <hallyn> well a new bug may provide new input...
[14:08] <hggdh> heh
[14:08] <hggdh> ok. libvirt_debug=1, bounce libvirt, and try again, correct?
[14:10] <hggdh> hallyn: if you find the original bug, please tell me
[14:11] <koolhead11> hey all
[14:12] <hallyn> hggdh: i think it was #903212
[14:12] <hallyn> bug #903212
[14:13] <hallyn> hggdh: yeah, and hope debug doesn't hide the bug :)
[14:13] <hallyn> thanks
[14:13] <hallyn> frankly i don't know tha ti believe the git lots - localtime_r specifically *shoudl* be thread-safe
[14:21] <hggdh> OK. I will request some time to test
[14:23] <hallyn> stgraber: I'm going to push lp:~serge-hallyn/ubuntu/precise/lxc/lxc-shutdownv2 .  I'd rather push it now and have time to push fixes to it tonight if i need to before freeze.  (and everything appears to now be working)
[14:23] <hallyn> stgraber: if you have *time* for a review, i'll wait, but i'm assuming you don't
[14:23] <roaksoax> hggdh: maybe it is
[14:23] <roaksoax> hggdh: haven't touched in a while
[14:24] <hggdh> roaksoax: the feeling I have is this is the CDU jumbling it all together. Anyway, want a bug?
[14:25] <roaksoax> hggdh: sure!
[14:25] <hallyn> jjohansen: the lxc i'm pushing today uses my hand-rolled aa_getcon.  i'll update to getcon when it's fixed.
[14:25] <hggdh> roaksoax: er. Againt which package? cobbler itself?
[14:25] <roaksoax> hggdh: fence-agents
[14:25] <hggdh> roaksoax: roj
[14:26] <stgraber> hallyn: yeah, I'm quite busy at the moment, so just upload :)
[14:27] <hallyn> stgraber: will do, see you on the other side :)
[14:56] <sktd> I’m profiling Firefox11. I can never get it to work, in enforce mode, without problems. I keep running it, then running aa-logprof to make corrections to the profile. Then I go into Edit A Profile (in YaST) to look at the changes and I see some weird entries at the beginning of the profile. They are as follows:
[14:56] <sktd> [+] ^null-15
[14:56] <sktd> [+] ^null-1e
[14:56] <sktd> [+] ^null-27
[14:56] <sktd> [+] ^null-32
[14:56] <sktd> [+] ^null-d
[14:56] <sktd> And it keeps making these things. I think this is why I keep having problems. Each time it creates one of the entries, it has a new name. I thought I’d try highlighting the first entry ([+] ^null-15) and doing an edit of the entry and set it to [+] ^null-*, but when I highlighted the entry and clicked the Edit Entry button, it was like it took me into another file that was full of
[14:56] <sktd> entries of its own.
[14:56] <sktd> Any idea on what I can do to resolve this?
[14:58] <hallyn> gary_poster: so at least the aufs path corruption is a kernel issue.  I can only assume the overlayfs one is too then
[15:00] <sktd> Are there any AppArmor experts out there?
[15:03] <hggdh> sktd: you will probably get all experts you need in the #ubuntu-hardened channel
[15:04] <sktd> Ok, thanks
[15:04] <hallyn> jjohansen: I hate to disturb you, but i have a feeling pathname changes to do with apparmor attach_disconnected stuff may be related to bug 959352 ? (/proc/self/maps shows paths not relative to task's pivot_root'd root)
[15:06] <gary_poster> hallyn, ack.  thank you for looking at it
[15:09] <hallyn> all though
[15:09] <hallyn> i notice lxc is doing pivot_root without a chroot
[15:09] <hallyn> that should also hit non-ephemeral containers, but...  lemme try
[15:10] <esuave> question, so if i have a static IP defined in /etc/network/interfaces.. than how come the server still pulls a new IP automatically from time to time?
[15:12] <soren> Daviey: You were interested in getting keystoneconfig-common into Ubuntu, is that right?
[15:12] <Daviey> soren: yes, very much so.
[15:12] <Daviey> BUT, need to go afk right now.
[15:12] <soren> Daviey: It only really makes sense if the other openstack packages will be consuming it.
[15:12] <soren> Daviey: Ok.
[15:12] <soren> Daviey: I've got it ready now. Let's discuss later.
[15:12] <Daviey> cool
[15:13] <hallyn> nope.  doesn't help
[15:17] <soren> esuave: 999 out of 1000 cases, it's because you didn't reboot after setting the interface to use static addresses.
[15:18] <esuave> you have to reboot the machine?!
[15:18] <soren> esuave: Not really.
[15:18] <soren> esuave: But it's easier to explain.
[15:18] <soren> esuave: You need to get rid of the dhcp client that's still running.
[15:18] <soren> esuave: You started the machien with dchp configuration.
[15:18] <soren> esuave: Then you changed the network config
[15:19] <soren> esuave: ...and maybe did and ifdown && ifup.
[15:19] <esuave> right but cant i just restart the service?
[15:19] <esuave> ahh
[15:19] <esuave> cool
[15:19] <esuave> ok
[15:19] <soren> esuave: By the time you did ifdown, /etc/network/interfaces claimed the interface was statically configured. I.e. ifdown didn't know that there was a dhcp client that needed killing.
[15:19] <soren> Hence, it didn't.
[15:19] <soren> Rebooting solves it.
[15:20] <soren> So does killing the dhcp client manually.
[15:20] <esuave> so how can i do it without rebooting the server?
[15:20] <soren> But telling people to reboot is orders of magnitude easier than explaining how to kill a stray dhcp client.
[15:20] <soren> Monkeys can reboot.
[15:20] <soren> I've heard of cats doing it, too.
[15:21] <soren> Unintentionally, but still.
[15:21] <koolhead11>  soren monkeys/cats
[15:21] <soren> I've never heard of a cat hunting down and killing a dhcp client.
[15:21] <soren> esuave: Kill the dhcp client.
[15:21] <esuave> soren: how can i do that? :) without rebooting
[15:21] <soren> esuave: See? Orders of magnitude more complicated to explain.
[15:22] <esuave> soren: haha
[15:22] <soren> it's a process.
[15:22] <soren> Kill it like  you would any other.
[15:23] <esuave> dhclient3
[15:23] <esuave> would that be the process?
[15:23] <soren> I'm rather busy. My solution: Reboot. If that's a problem, see if you can work it out yourself or find someone to explain it.
[15:23] <soren> Sounds like a decent guess.
[15:23] <esuave> soren: ok thank you for your help..
[15:25] <soren> Depending on your hardware, you could have rebooted anywhere between 3 and 50 times in the time it took to have this conversation.
[15:25] <soren> Just saying
[15:26] <esuave> soren: :P your absolutely correct. sorry
[15:32] <JesseC> Anybody have experience with PBIS / Likewise Open?
[15:33] <JesseC> I did a fresh install with thier script on Ubuntu 10.04 Server and it installs it, but Ubuntu doesn't recognize it.
[15:33] <JesseC> So if I do a domainjoin-cli, Ubuntu just says that it isn't installed.
[15:37] <cwillu_at_work> JesseC, (I don't know anything about likewise, but) specific and exact errors messages will be more helpful than paraphrasings
[15:41] <qhartman> I'm running into a problem where a large number of tiny log files are consuming all available inodes on a system. Does anyone know of a logratotion tool that handles this? They all seem to be geared towards rotating a few large files instead.
[15:54] <JesseC> cwillu: Sorry, I got it though. Seems the new PBIS isn't in the Ubuntu repos yet, so you have to specify the path with the commands for them to work correctly.
[15:55] <JesseC> qhartman: you could just write a shell script and put it in a cron job to clear the files at set intervals.
[15:59] <qhartman> JesseC, Yeah, I'm about to dive into that. Was just hoping to use something off the shelf if possible.
[16:01] <Daviey> esuave: I switched a server from dhcp to static just last night.. rebooting is thoroughly recommended..
[16:02] <Daviey> if you made a goof, and the old lease is still valid.. you won't knwo you made a goof until next time you reboot/power cut
[16:02] <esuave> Daviey: thanks! i just killed dhcp service though.. i think that should be sufficient
[16:02] <Daviey> Therefore, something like that.. i really think you should reboot.
[16:02] <esuave> Daviey: ok ill get a reboot in there
[16:02] <Daviey> esuave: Okay, but soren and myself have recommended otherwise.. but, hey, it's your party :)
[16:02] <Daviey> Oh, good.
[16:03] <esuave> Daviey: nah your right.. ill reboot! its a good idea to see what it does
[16:03] <esuave> Daviey: thank you!
[16:03] <Daviey> esuave: BTW, when i did it yeserday.. i DID make a goof.. and a reboot outlined it.. :)
[16:04] <esuave> nice!
[16:31] <stgraber> hallyn: /var/lib/dpkg/info/lxc.postinst: 43: /var/lib/dpkg/info/lxc.postinst: apparmor_parser: not found
[16:32] <stgraber> hallyn: that's with LXC in an LXC container where apparmor isn't installed (as it wouldn't work anyway)
[16:33] <hallyn> stgraber: hrmph - should make apparmor a depend
[16:33] <hallyn> stgraber: well, do you think it's worth making it work without apparmor?  i prefer not to...
[16:34] <zul> hallyn: how can you find what belongs to what in devices.list for cgroups?
[16:34] <hallyn> zul: i don't understand?
[16:34] <hallyn> stgraber: it's far too late to merge 0.8.0 right?
[16:35] <zul> hallyn: i have http://paste.ubuntu.com/893850/ in my devices.list how do i find out which major/minor it belongs to
[16:35] <stgraber> hallyn: it should work without apparmor
[16:36] <stgraber> hallyn: I tried installing apparmor in that container and it'd then fail because it doesn't have mac_admin
[16:36] <hallyn> well that's bad
[16:36] <hallyn> but ok, i'll fix the postinst to check for that
[16:36] <hallyn> instead of adding apparmor to Depends
[16:37] <hallyn> zul: which major/minor *what* belongs to?  aparticular device you want to add?
[16:38] <zul> hallyn: actually i think i just answered my own question
[16:38] <hallyn> ok
[16:42] <hallyn> stgraber: does http://paste.ubuntu.com/893863/ look sufficient?
[16:44] <smoser> hallyn, you should redirect output to /dev/null
[16:44] <smoser> o rotherwise make it go away
[16:44] <smoser> no one really cares to see "apparmor_parser is /usr/bin/apparmor_parser"
[16:44] <hallyn> i make it go away with my gruff demeaner
[16:44] <hallyn> thanks will do
[16:45] <hallyn> (i did it when i did it on the cmdline...  :)
[16:46] <stgraber> hallyn: it works but you probably should >/dev/null 2>&1 it too otherwise I get "apparmor_parser: not found"
[16:46] <hallyn> yup, done and pushed, thanks
[16:47] <micahg> hallyn: what would you like to backport?
[16:47] <hallyn> micahg: i'm nto sure what you're referring to
[16:47] <micahg> hallyn: [09:07] <hallyn> i'm considering asking if i can backport the precise version
[16:47] <hallyn> micahg: oh!  libvirt
[16:48] <hallyn> the oneiric version is just an unstable piece of junk
[16:48] <micahg> well, it works for some use cases
[16:49] <hallyn> micahg: you mean libvirt works for some use cases?
[16:49] <micahg> yeah, worked fine for me for my VMs on oneiric AFAICR
[16:49] <hallyn> yeah it works ok if you're using it casually, one thing at a time
[16:49] <hallyn> but these openstack ppl like to push it
[16:50] <micahg> hallyn: the problem is that there are quite a few reverse dependencies (mostly openstack) and it gets frequent security updates
[16:50] <hallyn> hggdh: zul: I trust there's heavy testing of openstack on precise going on too, so the instabilities are fixed in precise, not just not-yet-discovered?
[16:51] <hallyn> micahg: why is that a problem?  because some APIs might ahve changed o->p in libvirt and break users ,you mean?
[16:52] <hggdh> hallyn: zul is the one to answer on openstack
[16:52] <hallyn> hggdh: sure, but what about your jenkins stuff?
[16:52] <micahg> hallyn: yeah, or just general quirk interactions between the different versions, if you're willing to test the reverse dependencies (install/run), I'll throw up test packages, but I'd also need a commitment to test if there's a security update so we can make sure the -backports users aren't exposed
[16:52] <micahg> oneiric only has 13 more months of life, so it's not such a long commitment
[16:52] <hggdh> hallyn: on jenkins we have not reached openstack yet; there it is purely domains being started for other tests
[16:53] <hallyn> micahg: oh, wait, we're taking different things anyway.  i didn't mean in -backports
[16:53] <hallyn> i meant one ginormous sru
[16:53] <micahg> hallyn: oh :), I doubt you'll get a full SRU :)
[16:53] <micahg> but you can ask, anyways, my offer stands if you want it
[16:53] <hallyn> hggdh: yes 'im just trying to figure out whether you've done heavy use of libvirt on preicse
[16:53] <hallyn> micahg: thanks, i appreciate it
[16:54] <hallyn> anyway i'll try to reproduce on a reintalled laptop
[16:58] <hggdh> hallyn: no, our test environment runs Oneiric
[16:58] <zul> hallyn: yeah we do lots of testing :)
[16:58] <hallyn> zul: with lots of vms start/stopping simultaneously?
[16:58] <hallyn> zul: I just want to make sure that bugs 961217 and 903212 don't show back up later in precise
[16:59] <zul> hallyn: not that far yet, still need to do more functional testing
[16:59] <hallyn> all right then i need to find a testcase that works in oneiric and test in precise
[16:59] <hallyn> like asap
[17:10] <jjohansen> hallyn: makes sense, my updates to getcon, etc. are just waiting for review and we will try to get them into an upload today
[17:11] <hallyn> thx
[17:18] <adam_g> SpamapS: ping
[17:19] <SpamapS> adam_g: pong, sup?
[17:20] <adam_g> SpamapS: https://launchpad.net/ubuntu/precise/+queue  , the nova upload has a new binary package and is blocked.   is there anything i can do to help  nudge that along?
[17:22] <SpamapS> adam_g: yes, an archive admin can review it.. there should be somebody who can do it in #ubuntu-devel
[17:23] <SpamapS> adam_g: technically I could do it but I'm not an "official" archive admin :-P
[17:23] <adam_g> SpamapS: ah, i see, thanks
[17:28] <SpamapS> adam_g: its a very fast process, I'm sure theyll just +1 it
[17:43] <smoser> SpamapS, speaking of +1...
[17:44] <smoser>  https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=cloud-init
[17:45] <SpamapS> smoser: I will be doing SRU stuff later today
[17:46] <smoser> k. thank you. there are 4 of those.
[18:06] <zul> adam_g: i dont think truncate will do it
[18:07] <zul> adam_g:http://paste.ubuntu.com/893983/
[18:10] <zul> adam_g: nm i suck
[18:32] <koolhead17> hi all
[18:32]  * koolhead17 is happy today ^^
[18:39] <Dr4g> Trying to install mongo
[18:39] <Dr4g> This was successfull: apt-get install mongodb-stable
[18:39] <Dr4g> nevermind, i got it working.
[18:39] <Dr4g> sorry :)
[18:50] <adam_g> zul: did you have a fix for Bug #948719  ?
[18:50] <zul> adam_g: not yet
[18:50] <zul> lemme finish what im doing here and ill see what i can do
[18:51] <adam_g> zul: im working on keystone packaging right now, is it an obvious error?
[18:51] <zul> adam_g: yeah i think you need || true in the postrm
[18:52] <adam_g> zul: looks like its prerm, tho
[18:52] <zul> adam_g: try in the || prem as well
[18:53] <zul> bah one of the two
[18:55] <smoser> hallyn, around ?
[18:56] <smoser> hm.. maybe this is more smb
[18:56] <smoser> but...
[18:56] <smoser> wget https://cloud-images.ubuntu.com/server/precise/20120321/precise-server-cloudimg-amd64-disk1.img
[18:56] <smoser> from inside canonistack
[18:57] <smoser> lucid instance: 37.6 MB/s
[18:57] <smoser> precise instance: 10.4 MB/s
[18:58] <hallyn> smoser: all right all right.  once i reproduce (or fail) libvirt wonkiness on oneiric, i'll do an io perftest
[18:58] <hallyn> do you know offhand if it uses virtio+raw?
[18:59] <smoser> just changed to wget https://cloud-images.ubuntu.com/server/precise/20120321/precise-server-cloudimg-amd64-disk1.img -O /dev/null
[18:59] <koolhead17> noaXess, hey there
[18:59] <smoser> and the precise instances (tried 2) then get a bit of a boost (12M/S and 19M/S)
[19:00] <smoser> but the lucid improves to 47.4 MB
[19:00] <smoser> what is '+raw' ? hallyn
[19:01] <hallyn> smoser: as in 'qemu-img create x.img 10G'.  not qcow2/qed
[19:03] <smoser> not raw.
[19:03] <smoser> wait.
[19:03] <smoser> yes.
[19:03] <smoser> they're raw, almost cetain.
[19:03] <smoser> oh.
[19:03] <smoser> but wait.
[19:03] <smoser> they're backed by raw
[19:04] <smoser> they're delta images
[19:04] <smoser> but that concern was partially invalidated by the write to/dev/null
[19:04] <smoser> as i saw in a youtube video about mysql that writing to devnull is super fast
[19:05] <hallyn> so you're saying it's network
[19:05] <smoser> well, i actually think a bit of both.
[19:05] <smoser> because i *did* see an increase
[19:05] <hallyn> virtio network?
[19:05] <smoser> and even out of the 2, one was almost doubled.
[19:06] <smoser> yeah, virtio. is there a way i can tell in the guest for sure though?
[19:06] <hallyn> lspci -v?
[19:06] <hallyn> not sure.  but there should be an indication due to the driver
[19:06] <smoser> $ ethtool -i eth0
[19:06] <smoser> driver: virtio_net
[19:12] <smoser> adam_g, around ?
[19:12] <hallyn> smb: zul: ^ ring any bells?
[19:12] <smoser> on canonistack, i just did euca-allocate-ip, and assigned that to an instance
[19:12] <smoser> i can then ssh to the instance by its new ip address
[19:12] <adam_g> smoser: here
[19:12] <smoser> but only the 10. addresses show up in euca-describe-instances *or* nova show.
[19:13] <adam_g> smoser: try this
[19:13] <adam_g> smoser: re-associate the IP
[19:13] <adam_g> smoser: that is, run the associate command again and get an error
[19:13] <adam_g> then check
[19:13] <zul> hallyn: missing context (kid is sick)
[19:14] <smoser> ok. prior to that error.
[19:14] <smoser> $ euca-describe-addresses
[19:14] <smoser> ADDRESS 91.189.93.84    i-00001ba7      standard
[19:14] <smoser> that showed correct
[19:15] <smoser> and now, either human error, or weirdness, adam_g your suggested kick fixed things.
[19:17] <adam_g> smoser: theres some weirdness or crappiness in the way floating IPs are associated. when they're initially associated, the instance's cache is not properly updated with its new IP (which is where describe/show is getting its info)  re-assocaiting somehow refreshes somewhere in its error path
[19:18] <smoser> adam_g, is there a bug open ?
[19:18] <adam_g> smoser: theres now a periodic task that runs on compute that refreshes that nw info cache, but im not sure canonistack is running a new enough version for that
[19:18] <smoser> ah.
[19:18] <smoser> ok.
[19:18] <adam_g> smoser: but even that is kind of crappy, because it takes a min or so for that to be updated
[19:18] <smoser> well, it was well more than a minute or so.
[19:19] <adam_g> smoser: i agree its annoying and something that should be looked and hopefully improved, but i probably wont be getting to it this week and not sure upstream would consider it release critical
[19:19] <smoser> right. well if it is eventually consistent (even at 60 seconds) thats better than nothing.
[19:26] <hallyn> hggdh: you say one of the vms almost always fails to start?
[19:26] <hggdh> hallyn: one of them, not necessarily the same
[19:26] <hallyn> (haven't reproduced yet, but i don't have the i/o overhead of creating new images)
[19:26] <hallyn> ok i'll leave an image clonging while starting...
[19:26] <hggdh> hallyn: I am booting already-created images
[19:26] <hallyn> hm
[19:27] <hallyn> can you post your virsh dumpxml output?  cause i'm not reproducing.  and this is on a crappy laptop
[19:27] <hggdh> I have some 14 images, one for every kernel flavour
[19:30] <hallyn> hggdh: but you just boot 4 at a time and get one failing right?
[19:31] <hggdh> hallyn: correct
[19:31] <hggdh> 4 our five at a time
[19:32] <hggdh> s/our/or/
[19:32] <hallyn> hggdh: any xml for any one which has failed is fine
[19:32] <hallyn> just want to see your net and disk setups
[19:32] <hggdh> hallyn: will attach to the bug
[19:32] <hallyn> thx
[19:36] <hallyn> hggdh: ah - i did reproduce
[19:36] <hggdh> cool!
[19:36] <hggdh> and the XML in in the bug
[19:37] <hallyn> so now i'm going to do-release-upgrade and see if it gets fixed in precise
[19:41] <hallyn> jjohansen: the usr.bin.lxc-start policy does 'umount /mnt/**'.  But lxc-start then does pivot_root and then umounts/mounts dev/pts.
[19:42] <hallyn> jjohansen: do i have to allow all umounts, or is there a way to tell apparmor to use the pathname relative to original root?
[19:42] <hallyn> it's not so bad, i don't mis-trust lxc-start, it's the container i want to confine
[19:42] <hallyn> but if possible would be nice to keep it stricter
[19:42] <hallyn> (see bug 961536)
[19:45] <jjohansen> hallyn: maybe, pivot_root can transition the profile (do a change_profile), but it only works against the task doing the pivot_root atm, and it may be broken since the updates, as I don't have a regression test finished for it yet, and I haven't manually tested
[19:46] <hallyn> i missed something - whawt only works against the task doing pivot_root?  name resolution against origianl root?  that's all i want in that case
[19:47] <jjohansen> hallyn: name resolution against the original root isn't possible atm, sorry
[19:47] <hallyn> ok then i'll have to open it up.  thanks
[19:47] <jjohansen> it will come but is not available yet
[19:48] <bencer_> jamespage: any update on the zentyal packages stuck on the new queue?
[19:48] <bencer_> from the docs team want us to hit the archive before merging, so kind of presure from there too
[20:18] <adam_g> zul: ping
[20:55] <nancy--> * urthmover has quit (Ping timeout: 250 seconds)
[20:55] <nancy--> * Leseb has quit (Ping timeout: 244 seconds)
[20:55] <nancy--> * Leseb_ is now known as Leseb
[20:55] <nancy--> * Leseb_ (~Leseb@45873hpv102119.ikoula.com) has joined #ubuntu-server
[20:55] <nancy--> * Leseb has quit (Ping timeout: 246 seconds)
[20:55] <nancy--> * Leseb_ is now known as Leseb
 wonderman,  http://pastebin.com/EfFLn92z any help?
[20:55] <nancy--> * dob_ (~dob@dslb-094-217-102-019.pools.arcor-ip.net) has joined #ubuntu-server
[20:55] <nancy--> * dob_ has quit (Remote host closed the connection)
 http://pastebin.com/EfFLn92z any help with permission for apache ?
[20:55] <nancy--> * jiboumans_ (~jib@99-9-208-230.lightspeed.sntcca.sbcglobal.net) has joined #ubuntu-server
 nancy--: STOP posting in 2 channels
 nancy--, have you tried installing apache before?
 yes but never configured bind
 nancy--, what exactly y
[20:55] <nancy--> sory
[20:55] <guntbert> !paste | nancy--
[21:07] <nancy--> does anybody knows whats the  meaning of the amazaons bandwidth means ? 15 GB of bandwidth out aggregated across all AWS services ,   1 GB of Regional Data Transfer
[21:12] <patdk-lap> I thought regional data transfer was free
[22:08] <nancy--> guys.. any good sites for php work? elance.com ? etc ?
[22:08] <soren> Daviey: Areound?
[22:09]  * soren is typing like it's 11 PM
[22:13] <Daviey> soren: always for ypu.
[22:13] <Daviey> you*
[23:04] <soren> Daviey: Cool.
[23:05] <soren> Daviey: So, you're interested in the keystone config thing. It's only useful if you'll be changing at least one package to use it.. Will you be doing tht post betafreeze?
[23:07] <adam_g> soren: im curious, what keystone config thing?
[23:07] <soren> adam_g: I wrote a keystoneconfig-common (think dbconfig-common, but for hooking things into keystone)
[23:08] <adam_g> soren: oh, nice
[23:09] <fidothe> hello. stoopid network question. I have a machine with a static IP, and a block of other IPs, like this http://www.bytemark.co.uk/support/technical_documents/vmh_public_internal_bridge (i have a bytemark-hosted box). I've completely forgotten the magic route invocation to make this work with a libvirt-generated virbr0… Can someone point me?
[23:09] <adam_g> soren: is the code somewhere, an example of how to use maybe?
[23:10] <soren> adam_g: Code is at lp:~soren/+junk/keystoneconfig-common
[23:10] <soren> adam_g: My glance packaging uses it. Hang on, I'll post the link.
[23:11] <fidothe> I have tried route add -net 1.0.0.0/24 dev virbr0 equivalent, FWIW
[23:12] <soren> adam_g: lp:~cisco-openstack/glance/ubuntu
[23:12] <Daviey> soren: I think this makes much sense.. if it's regression free, i'd love to include it in precise.
[23:12] <Daviey> adam_g: thoughts?
[23:12] <soren> Daviey: Well, it'll suddenly hook things into keystone.
[23:13] <soren> Daviey: Which is different from what you've done so far.
[23:13] <Daviey> adam_g: Do you have capacity to look at hooking it in pre b2?
[23:13] <Daviey> soren: it's a new bin, not new src, right?
[23:13] <soren> When's b2 again?
[23:13] <soren> Daviey: New src.
[23:13] <Daviey> soren: we freeze tomorrow :)
[23:13] <adam_g> Daviey: heh definitely not
[23:14] <Daviey> adam_g: A day for you, is like 10 days for a normal person.
[23:14] <soren> Daviey: Whether I add an extra bin to an existing src or I add a new src doesn't matter.
[23:14] <Daviey> soren: a binNEW is much cheaper on review time. :)
[23:15] <soren> meh
[23:15] <soren> When is b2?
[23:15]  * soren <- Too lazy to check
[23:16] <Daviey> soren: I'll check with the techboard.
[23:16] <Daviey> soren: beta2 freeze is tomorrow at ~9:00 PM UTC
[23:17] <soren> Oh. Heh.
[23:17] <soren> Right.
[23:17] <soren> Too many projects with freezes right around now.
[23:17] <soren> It's confusing!
[23:19] <adam_g> soren: that looks really cool, im not sure if ill be able to get to play with it any point soon though
[23:19] <soren> I have no problem with that. Daviey just sounded really interested.
[23:20] <soren> It's there. Take it if you want it.
[23:20] <soren> Or rather: Let me know if you want it, and I'll upload it.
[23:20] <soren> It's going to be quite a bit of rowk still to get everything integrated with keystone.
[23:20] <soren> rowk == work
[23:21] <adam_g> there was a chat in #openstack-packaging  yesterday about the same problem
[23:22] <soren> I'm solving all of this, though.
[23:22] <soren> I just won't be done for another two weeks, probably.
[23:22] <Daviey> hallyn: numactl is showing as a libvirt candidate for main promotion, is it required?
[23:23] <soren> I'll be doing all of glance, nova, swift, horizon, and quantum.
[23:23] <Daviey> adam_g: This makes it much easier to install openstack from apt-get.. so it's quite exciting really.
[23:25] <adam_g> speaking of keystone, ive been working on getting unit tests going okay at package build. its going to require some tweaks to a config override file in the $src/tests/ directory to setup the environment properly. is it kosher to scribble on that file during override_dh_auto_test (and possibly revert changes) or should it be patched with quilt?
[23:25] <hallyn> Daviey: define required....  it's wanted by people
[23:25] <hallyn> it got MIR
[23:25] <hallyn> (biab)
[23:26] <adam_g> Daviey: yeah, definitely
[23:27] <Daviey> hallyn: i'm not seeing a MIR?
[23:28] <Daviey> adam_g: depends on the size of the change TBH... both are valid, but quilt allows easier inspection of our diff
[23:29] <adam_g> Daviey: its minimal stuff, but im not sure the changes applied via a quilt would be useful to anyone after the package is installed (ie, creating a temporary db a build time, in debian/tmp/ or some such)
[23:32] <Daviey> adam_g: Yeah, either are valid.. do the path that is easier.
[23:32] <adam_g> Daviey: thanks
[23:55] <jMCg> How do I get this string 'lib/x86_64-linux-gnu' from debian build tools?