[00:00] <starscream> i have ubuntu server 10.04  but I´m very new in this
[00:00] <starscream> but I need to learn this for the copany
[00:00] <starscream> company
[00:00] <twb> Quitting was probably not a good start
[00:05] <zambaboo> hey guys does anyone know if it is possible to enable dynamic_debug in lucid 10.04?
[00:08] <twb> Never heard of it
[00:11] <zambaboo> its in the kernel docs
[00:12] <twb> So grep for CONFIG_DYNAMIC_DEBUG in /boot/config-NNN.gz
[00:13] <zambaboo> not set
[00:14] <zambaboo> oh man.
[00:14] <twb> There you are then
[00:14] <zambaboo> a recompile eh
[00:14] <twb> You could reroll the kernel package but it's probably not worth the effort
[00:14] <sethras> Hello
[00:15] <sethras> i have installed an ubuntu server and made it to a router
[00:15] <zambaboo> it is for me, last resort. im having intermittent issues with bonding over ixgbe interfaces.
[00:15] <sethras> and what i need to know is where i save iptalbes NAT Forward rules ?
[00:15] <sethras> so a reboot wont purge my settings
[00:15] <sethras> in centOS it's the file /etc/sysconfig/iptables-config
[00:15] <sethras> but in ubuntu ?
[00:18] <twb> http://bugs.debian.org/657113
[00:18] <twb> Sorry, wrong channel
[00:22] <ChmEarl> sethras, use `iptables-save > myrules.out` , then in /etc/network/interfaces: under eth0 `post-up /sbin/iptables-restore < /etc/iptables/myrules.out
[00:22] <ChmEarl> sethras, so rules are restored every time eth0 starts up
[00:23] <twb> Wrong.
[00:23] <SpamapS> also if its simple enough, ucf might be a simpler choice
[00:23] <twb> The ruleset SHOULD be loaded BEFORE any interfaces are up
[00:23] <twb> The exception is if you need DNS to resolve hostnames in the ruleset.
[00:23] <SpamapS> Wrong? or "sub-optimal" ?
[00:24] <twb> SpamapS: well it leaves a nonzero hole where you can be connected to and you have no fw
[00:25] <twb> http://paste.debian.net/154122/ is what I do on ubuntu systems; on Debian I use iptables-persistent (which performs poorly on ubuntu due to ubuntu using a non-portable init).
[00:25] <twb> Also ref http://cyber.com.au/~twb/doc/iptab and #networking channel
[00:25] <twb> Er, sorry, #netfilter channel.  #networking is full of idiots.
[00:28] <zambaboo> hhaha
[00:43] <Aengus> Anyone have a pointer as to what determines the urgency of security updates to packages?
[00:46] <twb> They count how many hairs on kees' neck are standing up
[01:04] <kees> twb: heh.
[01:05] <SpamapS> Aengus: perhaps ask in #ubuntu-hardened
[01:05] <Aengus> SpamapS: cheers
[01:14] <zul> mtaylor: still around?
[01:25] <stgraber> hallyn: only starting to look at your branch now, will try to spend some time on it tonight so I have something for tomorrow morning
[01:32] <hallyn> stgraber: cool
[02:16] <nOStahl> so guys, I fixed my problem of having forgotten my server cd and the new prospective server could not boot from my usb installer
[02:17] <nOStahl> luckily I had grub2 already on the tower via an old ubuntu desktop installation
[02:17] <nOStahl> unetbootin the server iso to the hard drive heh
[02:17] <nOStahl> rebooted and it loaded the install into ram and took off
[02:17] <nOStahl> very nice
[02:54] <SolarNRT> Help, does anyone know how to bridge eth1 to wlan0,,, what command do I need?
[03:14] <ChmEarl> SolarNRT, auto br0;iface br0 inet dhcp;bridge_ports wlan0 eth1
[03:28] <adam_g> zul: pushed some mix fixes to lp:~openstack-ubuntu-testing/+junk/keystonelight
[05:19] <dravekx> if I want to make a global bash command, where do I save it? /bin ? /usr/bin ? /etc/init.d ?
[05:20] <dravekx> or does it matter?
[07:12] <driiper> Hello, i am currently trying to set up a router via my secondary NIC on my UBUNTU server, basicly this router is supposed to serve internet to users. Primary NIC is connect straight to the NET while as i said earlier the Secondary NIC goes to the wireless router. I Have managed to establish connection to the server via wireless, but does not seem to get past it or out to the internet. is there anyone which can assist me in thi
[07:19] <SpamapS> driiper: so on your internal NIC, you have a non-routable address (192.168.x.x, 10.x.x.x, or something around 172.16-32.x.x ?
[07:21] <driiper> The NIC going to the internet have my external IP (going through a bridge) while i currently configured ETH1 (secondary ) to 192.168.0.1,
[07:22] <driiper> if that makes any sense
[07:25] <driiper> Internet --> eth0 (external ip) ---> eth1 (Internal ip) ---> Wireless router ---> Clients,         |   this is what i am trying to achieve. i have managed to connect to the server via a wireless client using the gateway i used in the router (eth1 Ip)
[07:38] <driiper> hmmm
[07:39] <SpamapS> driiper: so have you done anything to setup NAT?
[07:41] <SpamapS> driiper: https://help.ubuntu.com/11.10/serverguide/C/firewall.html
[07:41] <SpamapS> driiper: look at 'IP Masquerading'
[07:41] <driiper> Not that i know of. i made the eth1 static and used that on the router. obviously i have to make some kinda bridge or routing from eth1 to eth0 inorder to get onto internet, but i guess thats what i have to do?  By the way, do i have to set up a DNS server, or can i still use the one provided by my isp ?
[07:42] <SpamapS> driiper: its a good idea to run something like dnsmasq on your firewall to cache DNS responses locally...
[07:43] <driiper> ok, ill try this out. but so i am clear, this is supposed to route the incoming connection from eth1 to eth0  right?
[07:44] <driiper> so it would be like a routing basicly
[07:45] <SpamapS> driiper: the given example doesn't mention eth1, but it takes packets from 192.168.0.x and gives them the address of eth0.. and sends them out on eth0.. and translates replies back to the appropriate 192.168.0.x address.. this is known as "NAT" or "Masquerading"
[07:45] <SpamapS> driiper: this is what every $40 router+wifi thing you can buy does.
[07:46] <SpamapS> (which is why I don't do this anymore.. ;)
[07:46] <SpamapS> I just let the WRT54G get 'er done. :)
[07:48] <driiper> yeh well i called my ISP yesterday about having slow speed on my internet connection (Supposed to have 40/40) but only got like 10/10. and yeh , they told me that i had to set my router (ISP central) into bridge mode becuase it couldnt handle more than 2-3 port forwardinggs ( i had like 30). so now im stuck with a old B standard wireless router to my clients
[07:48] <driiper> toh the budget
[07:48] <driiper> oh*
[07:49] <SpamapS> well yeah, 802.11b is 11Mbit, and half-duplex..
[07:49] <driiper> mhm :( not really the ting i would want for myself :P
[07:49] <SpamapS> driiper: honestly.. what more do you need? ;)
[07:50] <driiper> you know
[07:50] <driiper> be seedin these torrentz!!
[07:50] <driiper> nah it be working fine i guess.
[07:50]  * SpamapS will never understand why that is so universally acceptible. :-(
[07:51] <driiper> the torrent community will be gone in some few years, just wait and see :)
[07:51] <driiper> or
[07:51] <driiper> big parts of it anyways
[07:52] <driiper> trackers shutting down like crazy these days, i guess the days of payment is near
[07:53] <driiper> but yeh. thank you for your help! ill get back to fixin this thingy!
[07:53] <SpamapS> driiper: they'd have arrived sooner if torrenters had just stopped buying crappy DVD sets of stuff they already torrented. :-/
[07:54]  * SpamapS puts the soap box back in the closet
[07:54] <driiper> haha true :D
[10:18] <NeoNetNinja> anyone up?
[10:18] <NeoNetNinja> I
[10:27] <_ruben> we're all down
[10:27] <NeoNetNinja> lol
[10:27] <NeoNetNinja> I have a questions, basically:
[10:27] <NeoNetNinja> I'm looking for a used server that does SATA not SCSI that will run Ubuntu Server well
[10:28] <NeoNetNinja> all the ones on Amazon that are cheap only do SCSI
[11:19] <derknecht> i work with dmcrypt/luks container files to keep data save. i search for a solution to avoid to have fixed container size, is there a solution for self growing container files?
[11:20] <derknecht> maybe something like ecryptfs, but i found no documentation about that
[11:21] <patdk-lap> heh? ecryptfs isn't a container
[11:22] <patdk-lap> why can't you grow dmcrypt/luks?
[11:25] <derknecht> can container files be enlarged? the only way i see is to create a new one, and copy the data. And you are right, ecryptfs is a crypt filesystem, not a container file.
[11:27] <patdk-lap> I always luks the whole drive
[11:27] <patdk-lap> then used lvm to join the drives together
[11:27] <patdk-lap> mainly did that so I could thread luks over multible cpu's
[11:28] <patdk-lap> as dmcrypt is single threaded per instance
[11:30] <derknecht> good idea, that would work well. but in my situation i have to use a bunch of container files on an unencrypted partition (or i have to create a lot of partitions which will be even more unflexible)
[11:30] <derknecht> btw: the multithreading reason is a good advice!
[11:55] <jamespage> Daviey: do you want to drive off of approved gerrit reviews? or on upload of any patchset?
[11:56] <Daviey> jamespage: any patchset i think
[11:56] <Daviey> it's a pre-validator before a human review IMO.
[11:57] <jamespage> Daviey: OK so that is different to the gating in upstream - they wait for an approval before testing.
[11:57] <Daviey> jamespage: Hmm, have you seen SmokeStack ?
[11:57] <jamespage> Daviey: no
[11:59] <Sander^work> Anyone know about a opensource mature virtualisation platform with clustering?
[12:05] <Daviey> jamespage: we shouldn't ignore, https://github.com/dprince/openstack_vpc either
[12:08] <Daviey> jamespage: BTW, have you seen that you have started reviewing? https://review.openstack.org/#change,3309
[12:08] <jamespage> Daviey: oops
[12:08] <Daviey> jamespage: but anyway, with that example, smokestack did a smoketest before it was Approved
[12:09] <Daviey> it tests when a new patch set is pushed
[12:09] <jamespage> Daviey: thats a feature of the plugin - as soon as I pull and review I get marked as reviewing
[12:09] <Daviey> jamespage: right, i checked with monty about that.. he said there was a config option to make it quiet.
[12:10] <Daviey> 15:39 < mtaylor> Daviey: there's a flag in the job config to run in "silent mode"
[12:11] <Daviey> Hmm, regarding smokestack - unless it has a huge queue... the timestamps cause some doubt for me, https://review.openstack.org/#change,3558
[12:13] <jamespage> Daviey: and this one - https://review.openstack.org/#change,3273
[12:13] <jamespage> doh
[12:14] <Daviey> jamespage: long term, it would be good if it only posted results, not a Started and Finished IMO
[12:14] <Daviey> but at the moment, i think it should be silent.
[12:15] <Daviey> jamespage: note, the current target seems to be trunk proposals.. we want stable/diablo right?
[12:15] <jamespage> Daviey: lets assume for a minute that I'm just testing this...
[12:15] <jamespage> stable/diablo don't get many
[12:15] <Daviey> jamespage: right..
[12:16] <jamespage> its not running in the lab either FYI
[12:16] <Daviey> jamespage: yeah, i guessed that with hendrix :)
[12:18] <jamespage> Daviey: OK - figured out how to disable that for the time being
[12:19] <jamespage> its a little more than a toggle...
[12:19] <Daviey> oh
[12:20] <jamespage> yeah - I had to remove the actual commands that the plugin runs at certain points during testing
[12:20] <jamespage> but I saved them!
[12:22] <jamespage> Daviey: reckon I should comment on those two review to apologize?
[12:22] <Daviey> jamespage: it's in your name, i'd just hold fire and await a comment
[12:23] <Daviey> if it has an offical sounding title.. then yeah.. but i thinmk you are ok
[12:23] <Daviey> ue, "Ubuntu Openstack Validation Bot"
[12:23] <Daviey> ie*
[12:25] <Daviey> irssi just segfaulted on me.. gah.
[12:26] <jamespage> Daviey, ack
[12:33] <jamespage> lynxman, trying to look at your MP but bzr just broke on me
[13:36] <GyrosGeier> hi
[13:37] <GyrosGeier> I'm looking for the switch that says "this server is in a 19" rack, do not under any circumstances stop the boot process before starting sshd, even if an iSCSI target is missing"
[13:38] <GyrosGeier> that is, it is okay if any filesystem except root fails to mount
[14:01] <jdstrand> Aengus: re security update priority> it is a combination of a lot of things: http://people.canonical.com/~ubuntu-security/cve/priority.html
[14:01] <jdstrand> Aengus: did you have a question about a specific issue?
[14:02] <rbasak> GyrosGeier: are you looking for the noauto flag in /etc/fstab?
[14:04] <lynxman> jamespage: no worries :)
[14:06] <GyrosGeier> rbasak, in principle I want automount if possible
[14:06] <GyrosGeier> the important bit is that it should never drop into a console
[14:07] <GyrosGeier> (because there isn't one=
[14:08] <rbasak> I don't know if such a mechanism exists, but it doesn't seem practical in the general case to me. What happens if subsequent services fail because mounts are missing? If you have complicated needs, set noauto and manage it manually - say in rc.local or something. And then take care of any services that depend on the mounts.
[14:09] <GyrosGeier> the most important bit is that ssh works
[14:10] <GyrosGeier> waiting for someone to drive to the colo facility, plug in a keyboard and press "S" is even less practical than having random services fail, IMO :)
[14:11] <ogra_> you could hack an initramfs-tools hook and script in place that switches on networking in the initrd and fires up sshd by default
[14:11] <rbasak> you might change /etc/init/ssh.conf to start on local-filesystems instead of filesystem or something, but my upstart fu is weak and I don't know what other implications that might have.
[14:12] <GyrosGeier> I think that is already the case
[14:12] <rbasak> that's a point - will networking even be up at that stage?
[14:12] <GyrosGeier> but the fs is ext3 on SCSI
[14:13] <rbasak> I think the general solution is that if the mounts aren't critical to the system booting and you want the system to boot regardless of them, then set them noauto and mount them in rc.local. That's the least hacky answer.
[14:13] <rbasak> OTOH, if you break something that the system's boot depends on, don't expect the system to be able to boot :-)
[14:15] <rbasak> OR, perhaps you're asking for a new feature - ssh capability in the event of  boot failure. If that doesn't exist it sounds like a good idea.
[14:15] <smb> Not sure this is helpful, but there seems to be a nofail for fstab...
[14:17] <rbasak> smb: that sounds perfect :)
[14:17] <smb> If it works as one expects. Have never tried, just looked at man fstab
[14:29] <Caribou> I have a question for the kernel people : any reason why Ubuntu kernel is less agressive in caching FS writes than the RHEL kernels ?
[14:30] <Caribou> kernels would be Lucid (2.6.35) .vs. RHEL 5.5 (2.6.18)
[14:31] <Caribou> on a DL380/G7 writing a 11Gb file with dd (to cache) takes 120s on Ubuntu and 9s on CentOS!
[14:31] <henkjan_> Caribou: same server?
[14:32] <Caribou> when bypassing the cache (using oflag=direct) I get 221s for Ubuntu and 190s for CentOS
[14:32] <Caribou> henkjan_: yes, identical H/W same disks/ctrls
[14:33] <henkjan_> looks like the centos one has write back cache enable on the raidcontroller?
[14:34] <Caribou> henkjan_: AFAIK, smart array don't have WB cache and if so, it would be enabled on both
[14:35] <Caribou> I'd get the same behavior with oflag=direct but the values are much closer
[14:36] <Caribou> henkjan: here is an example : http://paste.ubuntu.com/823880/
[14:40] <jamespage> lynxman, sorry more comments on ipxe
[14:41] <lynxman> jamespage: no worries :)
[14:44] <jamespage> Daviey: w00t - I got a gerrit trigger build on trunk!
[14:45] <Daviey> jamespage: about that... do you think it's a good idea?
[14:45] <Daviey> perhaps we should do it by hand?
[14:45] <jamespage> lol
[14:45] <Daviey> jamespage: Sorry, i am blowing smoke.. :)
[14:45] <jamespage> so long as you are willing to be the button pressing monkey
[14:46] <Daviey> soren: that is great to hear, so are you using gerrit as the trigger or github commit?
[14:46] <Daviey> err, jamespage ^^
[14:46] <jamespage> gerrit
[14:46] <jamespage> you have never got me mixed up with soren before...
[14:47] <Caribou> /3
[14:48] <Daviey> jamespage: Yes, sorry - a real insult that was :)
[14:48] <Daviey> jamespage: Seriously, that is topnosh!
[14:48] <Daviey> Really pleased it's going well.
[14:48] <gary_poster> hallyn, hey.  lxc on precise is hanging for me, with lucid containers. I'm up-to-date, and I tried a brand new lucid container.  Details: http://pastebin.ubuntu.com/823882/ .  OTOH, a new precise container works fine, and is much faster to start than it used to be.  We kinda need both lucid and precise though.
[14:48] <lynxman> jamespage: saw your comments, I don't really know what else to do tbh, this has been very time consuming
[14:49] <lynxman> jamespage: feel free to take over if you want, can't justify more time on this cleaning the upstream lintian errors I'm afraid
[14:52] <smoser> hallyn, ping.
[15:03] <gary_poster> Oneiric is also fine.  It is only lucid (that I care about; N and M are not important to me).
[15:14] <smoser> hallyn, ping again (different topic)
[15:15] <smoser> zul, did you push to lp:ubuntu/libvirt ?
[15:15] <zul> smoser: no
[15:16] <gary_poster> hallyn, I filed https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/924337 so I could track
[15:16] <Decepticon> buenas
[15:16] <Decepticon> como configuro un server ubuntu 10.04  para crear una unidad compartida
[15:17] <Decepticon> se puede usar los tutoriales de ubuntu server 11 para losde ubuntu 10.04
[15:17] <smoser> zul, i just ased because it is up to date with your upload, but not the most recent one.
[15:17] <smoser> and its failing
[15:17] <smoser> http://package-import.ubuntu.com/status/libvirt.html#2011-05-26%2020:07:23.558315
[15:17] <Decepticon> hi people sorry I think that this canal in spanish
[15:17] <smoser> and i wondered if hallyn was manually pushing
[15:17] <Pici> Decepticon: Try #ubuntu-es :)
[15:18] <Decepticon> i have ubuntu server but i need to share a folder or unity
[15:18] <Decepticon> Pici: thanks but I can speak englsih, dont problems
[15:19] <Pici> Okay :)
[15:19] <Decepticon> Pici:  do you do of ubuntu server ¿_
[15:19] <Pici> Decepticon: I do.
[15:19] <Decepticon> Pici:  thanks a God
[15:19] <Decepticon> jejej
[15:19] <Decepticon> Pici:  i have ubuntu server wit ubuntu 10.04 server
[15:20] <Decepticon> but i have manual of ubuntu server 11.04
[15:21] <Decepticon> this manual is compatible
[15:21] <Decepticon> manual of ubuntu server 11.04 but i use ubuntu server 10.04
[15:21] <Decepticon> Pici:  please help me with this
[15:21] <Pici> Decepticon: It should be.  You can use https://help.ubuntu.com/10.04/serverguide/C/ instead if you want though.
[15:21] <hallyn> smoser: package importer always fails for libvirt (and qemu)
[15:22] <hallyn> smoser: yes i've been manually doing import-dsc and push
[15:22] <Decepticon> Pici:  ok! thanks
[15:22] <Decepticon> hallyn:  so i can use for this =?
[15:22] <smoser> hallyn, have you ever asked in #bzr to maybe get it sorted out ?
[15:22] <hallyn> of course
[15:22] <hallyn> pls feel free to take your turn
[15:23] <smoser> :)
[15:23] <smoser> funny
[15:23] <smoser> yeah. i've done it, and just asked.
[15:23] <smoser> anyway.
[15:23] <smoser> second question for mr. hallyn.
[15:23] <Decepticon> hallyn:  thanks
[15:23] <hallyn> Decepticon: sorry iw asn't talking to you
[15:23] <hallyn> Decepticon: pls re-ask your question, i don't follow
[15:24] <Decepticon> hallyn:  ok!, dont problems
[15:24] <Decepticon> hallyn: cheeck.  i have a manual of ubuntu server 11.04 but I use to ubuntu server 10.04
[15:24] <smoser> bug 924281, hallyn was the second question.
[15:24] <Decepticon> this manual is compatible with my server
[15:25] <hallyn> Decepticon: I've not paid as much attention to the manuals as I should.  I'd look at the 10.04 one like Pici suggested.
[15:25] <smoser> Decepticon, probably somewhat. but it wont be 100% compatible.
[15:26] <Decepticon> hallyn:  ok perfect thanks
[15:26] <Decepticon> smoser:  thanks
[15:26] <Decepticon> smoser:  this is new for me
[15:26] <Decepticon> hallyn:  thanks
[15:26] <Decepticon> anything in the afthernoon to entrance to canal
[15:26] <Decepticon> thanks a lot
[15:26] <hallyn> smoser: i'll have to look into it.
[15:26] <Decepticon> bye bye
[15:26] <Decepticon> good day
[15:27] <hallyn> gary_poster: ditto (i'll have to look into it - it's been working for me perfectly)
[15:27] <smoser> hallyn, from inside the container, i can't even make paths in /sys/fs/cgroup.
[15:27] <smoser> which i'm guessing is by design
[15:27] <gary_poster> hallyn, ack thanks
[15:27] <hallyn> smoser: is anything mounted there now?  df -h /sys/fs/cgroup?
[15:27] <smoser> not in the container
[15:27] <hallyn> d'oh
[15:27] <smoser> only outside
[15:27] <hallyn> smoser: haha, nm, i get it
[15:28] <hallyn> smoser: workaround, edit your /etc/apparmor.d/usr.bin.lxc-start and remove the /sys denial
[15:28] <smoser> hm..
[15:28] <smoser> i wasn't getting app armor errors in dmesg though.
[15:29] <hallyn> smoser: i think the 'deny' shuts up errors in dmesg actually
[15:29] <hallyn> gary_poster: jsut as an aside, if you're using the config you said you're using, on precise, you don't have to use a config at all
[15:29] <hallyn> (that's the default)
[15:29] <gary_poster> hallyn, I wondered if that were the case.  Cool, thanks
[15:31] <smoser> hallyn, other fun quesiton...
[15:32] <hallyn> smoser: despite my being an ass earlier, i really would like the bzr issue resolved
[15:32] <smoser> what likely hood of getting acccess to loop devices inside a container
[15:32] <smoser> are the loop devices name-spaced ? i suspect not.
[15:32] <hallyn> smoser: yeah they're not.  you can coordinatei t from the host of course
[15:32] <smoser> yeah, but for this that is probably not enough.
[15:32] <hallyn> what exactly do you want?
[15:33] <hallyn> by coordinate, i meant pick loop3 and let a container have it
[15:33] <smoser> ie, nova-volume and nova-compute are going to want to use losetup and the like.
[15:33] <smoser> and go looking for a free device and such.
[15:33] <hallyn> they can do that, the host just has to tell them which to use, and let them use it through the devices whitelist
[15:33] <hallyn> or, the host can just let it access all of them...
[15:34] <smoser> well it clearly can't safely let them access all of them.
[15:34] <hallyn> it's not like containers are *secure* now, so don't let fake security get in the way of getting someting done
[15:34] <hallyn> smoser: well, hw about this,
[15:34] <smoser> and coordinating from the host would seem complex to me at the moment.
[15:35] <hallyn> when the host creates the container, it picks two unassigned loops and lets the container have them;
[15:35] <hallyn> then make sure that when nove gets -EPERM it just tries the next index
[15:35] <hallyn> whatever creates the container will need to keep track of the loops, yes
[15:35] <smoser> it might be sufficient
[15:35] <smoser> but that limits you to N/2 total containers if you do that by default
[15:36] <hallyn> anyway, that's all we got right now, but namespacing loops might not be so bad.  only problem would be that the response might be "you must do all devices"
[15:36] <hallyn> yup
[15:36] <smoser> where 'N' is the number of loop devices...
[15:36] <smoser> i think we set it to 64?
[15:36] <hallyn> maybe you can get fancy with udev
[15:36] <hallyn> it can catch a loop creation (i think),
[15:36] <smoser> well, module load is when its set
[15:37] <hallyn> then deny all other containers access to that loop
[15:37] <hallyn> (and if the host creates the loop, then all contaiens are denied)
[15:37] <smoser> hallyn, hm..
[15:38] <smoser> that'd be pretty neat.
[15:38] <smoser> how would udev know which container created the loop device ?
[15:38] <hallyn> very racy of course
[15:38] <smoser> yeah
[15:38] <hallyn> not sure if the uevent carries the pid which created it
[15:39] <smoser> hm..
[15:39] <hallyn> it really seems to me that, unless nova likes to run around and dd if=/dev/zero into all existing loop devices,
[15:39] <hallyn> you should jsut allow all your containers access
[15:39] <smoser> well... the thing i'm concerned about is something assuming that it is in full control of loop devices
[15:40] <smoser> and saying "is /dev/loop0 used? well, not by me!, i'll use it"
[15:40] <derknecht> has someone used encfs so far? i think about using it as replacement for dmcrypt with crypted container files to get around the fixed size containers problem.  Any advice if encfs is stable enough fpr production usage? Thanks
[15:40] <hallyn> that would be insane
[15:40] <smoser> it snot a completely unrasonable assumption
[15:41] <hallyn> smoser: sure it is.  otherwise you're telling me i can't run anything else on that machine
[15:41] <hallyn> smoser: or even loop mjount a cdrom iso
[15:41] <smoser> you typically would only run one hypervisor management solution on a machine
[15:41] <smoser> :)
[15:41] <smoser> but even if it *were* unreasonable
[15:41] <smoser> then likely the well intentioned user is going to do something like:
[15:42] <smoser>  * check if /dev/loop0 is used
[15:42] <smoser>  * if yes, try /dev/loopN
[15:42] <smoser>  * if not, take it
[15:42] <smoser> which is racy anyway
[15:42] <smoser> but for now i'll try with all having access to /dev/loop*
[15:43] <hallyn> smoser: the good news here is that we ahve a very reasonable user for devices namespace
[15:43] <hallyn> which means we might be able to start discussing a design and implementation
[16:04] <gary_poster> hallyn, another question.  sudo in a precise container complains of no tty.  I found http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg03138.html .  the tty config that writer suggests is not in the config generated for my container (it is commented: "#lxc.cgroup.devices.allow = c 5:0 rwm").  I have to step away, but...is that a bad idea? intentional?
[16:05] <gary_poster> I will try when I return unless you advise against it
[16:05] <hallyn> gary_poster: it's intentional.  5:0 is not namespaced
[16:05] <hallyn> if it really breaks things, then maybe we'll have to undo it and live with it
[16:05] <hallyn> (inameeting)
[16:06] <gary_poster> hallyn, gotcha.  is there another reasonable way to get sudo to work with that setting?  ack on meeting.  will head off, and check back in when i return
[16:08] <hallyn> oh, hm.  5:0 is tty.  that's not right
[16:09] <hallyn> that implies i should re-enable it, and lxc-start didn't do a setsid() somewhere
[16:09] <stgraber> hallyn: hmm, upstart is too limited for what I wanted to do (detect the container type in container.conf and set an environment variable that other jobs using "start on container" can check)
[16:10] <stgraber> hallyn: instead it looks like the easiest would be to move the logic into is-container and have container.conf call is-container the emit an upstart event with a CONTAINER=type variable that other jobs can check
[16:10] <hallyn> stgraber: whatever works, i'm not tied to anything
[16:11] <hallyn> stgraber: so i was thinking that 5:0 was console, but it's tty.  that's what i refused lxc access to, and doing so fixes both soundcard and xmodmap twiddling by container
[16:11] <hallyn> stgraber: i guess ihave to undo it, but it leaves me wondering why it lets the container do what it does
[16:12] <GyrosGeier> smb, will try that
[16:13] <stgraber> hallyn: would read-only make sudo happy and still give us the other benefits?
[16:13] <hallyn> stgraber: i dunno, but shouldn't /dev/tty just connect to current's tty magically?
[16:13] <hallyn> i.e. it's inherently namesapced?
[16:14] <hallyn> i'll play with it i guess (but again, in a mtg)
[16:14] <stgraber> hallyn: indeed, it should. Though it looks like it's pointing to something that isn't namespaced at some point
[16:15] <hallyn> stgraber: AIUI (and apparently i'm wrong) setsid should be setting that
[16:15] <hallyn> i'm *sure (cough) lxc-start is doing setsid :)
[16:17] <stgraber> hallyn: grep tells me lxc-console does but that's the only direct call to setsid
[16:17] <hallyn> hm
[16:20] <stgraber> I'd have expected to find it in start.c or namespace.c
[16:21] <stgraber> (but I don't pretend to understand exactly what's going on in the C code ;))
[16:24] <stgraber> hallyn: just checking, container=lxc-libvirt is what we'll get in the new libvirt right? (not libvirt-lxc)
[16:24] <hallyn> stgraber: yes, but the LIBVIRT_LXC_UUID or whatever will still be there too, so we don't *have* to change anything
[16:25] <stgraber> hallyn: right, I just want to make sure is-container returns something consistent
[16:25] <stgraber> hallyn: if container is set in init's environment it'll always return it as-is and ignore all the other potential ways of detecting a container
[16:25] <hallyn> stgraber: i don't know when that patch will go in, and i wasn't planning on backporting into 12.04 libvirt (though i can if you like)
[16:26] <stgraber> no, backporting won't change anything (unless they choose to change the value of container at the last minute to something else than lxc-libvirt)
[16:26] <hallyn> pls shout (or opena  bug :) if you want that cherrypicked then
[16:27] <hallyn> i've asked dlezcano in email about the setsid
[16:31] <stgraber> hallyn: do you have an opinion on the right way to extract "container" from init's environment? "ps -p 1 e" is fairly clean but extracting a single variable is a pain, parsing /proc/1/environ isn't much pretier
[16:32] <hallyn> stgraber:hm
[16:34] <hallyn> Let's say we wanted container.conf, when it starts, to set the container type in a file.  like /etc/containertype.  What would be the right place for that.  /run ?
[16:34] <stgraber> hallyn: yeah, /run would be the right place
[16:35] <hallyn> and since /run is tmpfs, it doesn't have to do anything on non-container,
[16:35] <hallyn> stgraber: so that would be my suggestion...
[16:35] <stgraber> hallyn: ok, I'll move everything back into the upstart job and have it write to /run
[16:35] <SpamapS> koolhead17: around?
[16:36] <hallyn> stgraber: maybe we should run that by cjwatson and/or jodh...  i don't know if it's deemed kosher.  but i like it.
[16:46] <smoser> hallyn, it looks like you can now race-free get a loop device
[16:46] <smoser> https://lkml.org/lkml/2011/7/30/110
[16:48] <hallyn> smoser: but does nova use it
[16:48] <smoser> almost certainly not
[16:48] <smoser> :)
[16:48] <smoser> but it could.
[16:48] <smoser> and i *think* that is exposed via 'losetup' utility
[16:48] <stgraber> hallyn: ok, I have an updated upstart branch, testing it here now
[16:49] <hallyn> smoser: so you'd use that and allow all containers access to loop*?
[16:49] <hallyn> stgraber: cool.  i need to do an updated lxc to fix the two bugs i introduced
[16:50] <smoser> hallyn, well, it seems likely that nova should use it generally.
[16:50] <hallyn> yes
[16:50] <smoser> and for this speicifc purpose, i would need to allow /dev/loop*
[16:50] <smoser> (jstack purpose)
[16:50] <hallyn> smoser: well udev still might be doable
[16:50] <smoser> but that does not to me seem acceptable across the board for lxc-create
[16:50] <hallyn> no , it would be only for you
[16:50] <smoser> i dont think that adding a complex and racey solution makes much sense.
[16:51] <hallyn> well it might not be racy now
[16:51] <hallyn> i.e. you can refuse all access,
[16:51] <Danny_Joris> hi, I'm trying to install ubuntu server as a vm with virtualbox. During the 'select and install software' process I got an error, and I'm not sure what to do...
[16:52] <smoser> maybe i'm missing something.
[16:52] <Danny_Joris> I'm trying to select another install process step, but it won't let me
[16:52] <smoser> hallyn, but i thought you were proposing:
[16:52] <hallyn> the /dev/loop-control or whatever creates the new loop dev, udev on host provides the container access, container keeps trying to open until it doesn't get -EPERM
[16:52] <smoser> well, /dev/loop-control access would probably be dangerous
[16:53] <hallyn> can you only create new loops with it?
[16:53] <smoser> as i can also remove
[16:53] <hallyn> oh
[16:53] <smoser> no worries.
[16:53] <smoser> hack for now, let /dev/loop* access
[16:53] <hallyn> ok
[16:53] <smoser> so
[16:53] <smoser> so how could i do this cleeanly?
[16:54] <smoser> ie, for my created containers instances give them /dev/cloop0
[16:54] <smoser> lxc-create -t ... then just append before start for the block devices i guess
[16:55] <Danny_Joris> any advice?
[16:55] <hallyn> smoser: (if this is what you're asking) you can just add the lxc.cgroup.devices.allow line to the config that you pass to lxc-create with '-f'
[16:55] <smoser> right.
[16:55] <smoser> oh. i can pass my own config to lxc-create ?
[16:55] <smoser> i didn't know that.
[16:56] <smoser> interesting...
[16:59] <Danny_Joris> the enitre install is screwed... :(
[17:01]  * Daviey buys, http://www.spreadshirt.co.uk/create-your-own-t-shirt-C59/product/102559172/view/1
[17:04] <lynxman> Daviey: can I get one too?
[17:05] <hallyn> Danny_Joris: I fear your info was lost in the noise - can you please repeat?
[17:05] <hallyn> Daviey: it must have been an imposter.  Clearly smoser must be out having lunch, and the maid sat down at the kbd
[17:06] <Danny_Joris> hallyn: I'm having an error in the select and install software - process
[17:06] <lynxman> hallyn: Consuela style? (http://www.youtube.com/watch?v=2IaheLG-05U)
[17:06] <Danny_Joris> hallyn: I just started from scratch and I have it again
[17:07] <koolhead17> SpamapS: back :)
[17:07] <koolhead17> hey Daviey
[17:07] <Danny_Joris> I selected - openssh, LAMP, postgreSQL and mailserver
[17:07] <hallyn> Danny_Joris: is this with Precise (12.04)?
[17:07] <Danny_Joris> 11.10
[17:07] <hallyn> lynxman: my laptop won't play sound from the flash plugin
[17:08] <Danny_Joris> not very helpful: https://skitch.com/dannyjoris/g7cyu/ubuntu-server-11.10-64-running
[17:08] <lynxman> hallyn: aww
[17:08] <SpamapS> koolhead17: was going to suggest that you attend our meeting, but it is over
[17:08] <hallyn> (sure i could youtube-dl it...)
[17:09] <koolhead17> SpamapS: we must be having our meeting log somewhere :)
[17:09] <hallyn> Danny_Joris: I've had that too, though only with Precise.  I assume this was an uptodate iso you used?
[17:09] <hallyn> Daviey: https://skitch.com/dannyjoris/g7cyu/ubuntu-server-11.10-64-running
[17:10] <SpamapS> koolhead17: irclogs.ubuntu.com
[17:10] <SpamapS> koolhead17: you came up, as the PHP5 bug fix (and merge of 5.3.9) need to be done soon
[17:10] <Danny_Joris> hallyn: yeah, just downloaded it from the ubuntu site
[17:10] <koolhead17> SpamapS: yes. will be doing it in 1-2 days
[17:20] <smoser> hallyn, does the config given stick across a clone ?
[17:20] <smoser> i think it does
[17:20] <hallyn> smoser: yeah, i'm pretty sure i copy the config verbatim
[17:20] <smoser> well, and then you change the hostname
[17:20] <smoser> and something like that.
[17:25] <Danny_Joris> OMG now it jammed on apt preparation...
[17:31] <Danny_Joris> it got stuck on this: https://skitch.com/dannyjoris/g7cea/ubuntu-server-11.10-64-running
[17:31] <Danny_Joris> twice
[17:31] <hallyn> Danny_Joris: gah.  exactly which iso are you using?
[17:32] <Danny_Joris> hallyn: http://www.ubuntu.com/download/server/download latest (11.10) 64 bit
[17:32] <hallyn> Danny_Joris: thanks, i'll see what i get here.
[17:32] <hallyn> Danny_Joris: 64bit?
[17:33] <Danny_Joris> virtualbox 4.1.8 on Snow leopard
[17:33] <Danny_Joris> hallyn: yes
[17:33] <hallyn> d'oh
[17:33] <hallyn> all right it'll take me awhile to d/l, but i'll see what i get.  you're not preseeding right?
[17:34] <Danny_Joris> hallyn: not sure what preseeding is, so probably not
[17:35] <hallyn> ok :)
[17:37] <Danny_Joris> hallyn: I'm going to try the LTS
[17:37] <hallyn> Danny_Joris: you mean 10.04 or the 12.04 LTS candidate?
[17:38] <Danny_Joris> 10.04
[17:38] <Danny_Joris> hallyn: would the 12.04 lts candidate be more or less stable than 11.10?
[17:38] <hallyn> far less, at the moment
[17:40] <hallyn> jjohansen: around?
[17:40] <jjohansen> hallyn: yes
[17:41] <hallyn> if my policy says "allow /sys/fs/cgroup rwx; \ndeny /sys/fs/ rwx;"
[17:41] <hallyn> will that do what i expect, applying in order?
[17:41] <hallyn> to be more precise, i mean "allow /sys/fs/cgroup/** wklx; deny /sys/** wklx,"
[17:41] <jjohansen> hallyn: no, AA rules don't have ordering (ie they are declarative)
[17:42] <hallyn> this is for bug 924281
[17:42] <hallyn> drat
[17:42] <jjohansen> its one of those things Crispin was adamant about
[17:42] <hallyn> jjohansen: whats the most concise way to say "deny write under /sys except to /sys/fs/cgroup/**" ?
[17:42] <stgraber> jhelwig: lp:~stgraber/ubuntu/precise/upstart/upstart-containers
[17:42] <stgraber> oops, wrong target. Sorry jhelwig
[17:42] <stgraber> hallyn: lp:~stgraber/ubuntu/precise/upstart/upstart-containers
[17:43] <jhelwig> stgraber: No worries.
[17:43] <stgraber> hallyn: I had to drop the "and stopped runlevel" bit as otherwise the console would sometimes take 3 minutes to show up (or not show up at all).
[17:43] <hallyn> stgraber: i'll take a look
[17:43] <stgraber> hallyn: I poked jodh about that bit. AFAICS we don't actually need to wait on runlevel for LXC, it's usually best to just show the login prompt whenever we can
[17:43] <hallyn> stgraber: yes, but that was because your network wasn't up?  or not?  maybe that actually is the root of gary_poster's bug then!
[17:43] <hallyn> ok
[17:44] <hallyn> good with me
[17:44] <jjohansen> hallyn: err. just have a single allow rule, and don't have any other rules allowing /sys access
[17:44] <jjohansen> /sys/fs/cgroup/** rw,
[17:44] <jjohansen> hallyn: of course that doesn't help if you have a broad rule like /** rw,
[17:45] <hallyn> feh, maybe i should drop the whole /sys rule for now.  it's going to have to change again when the mount perms come anyway
[17:45]  * gary_poster is here.  :-)  Doing other things, and will be back to this soonish, but can also drop everything and try something if it helps
[17:45] <jjohansen> hallyn: otherwise it gets hard atm
[17:45] <hallyn> jjohansen: what is 'at the moment'?  what will make it easier?
[17:46] <hallyn> jjohansen: i suppose i can just do something like "deny /sys/[^fs]/[^cgroup]/** rw" ?  in that spirit anyway?
[17:46] <jjohansen> hallyn: well, the syntax is supposed to get an extension that will make selective set operations easy.  It possible in the matching engine its just not exposed yet
[17:47] <hallyn> jjohansen: in this cycle?
[17:47] <jjohansen> hallyn: except that isn't what you want.  [ ] is a character class
[17:47] <hallyn> i figured i had a 50/50 chance :)
[17:47] <jjohansen> hallyn: I wish, but with the FF deadline coming I doubt it
[17:47] <hallyn> FFE :)
[17:48] <jjohansen> hallyn: I am willing to consider it :), now just to convince jdstrand
[17:48] <hallyn> jjohansen: i'd really like in 12.04 some way of being pretty specific about what under /sys and /proc a container can access, while using a big stick to say "and ntohing else"
[17:49] <jjohansen> hallyn: yeah, completely understand that
[17:49] <hallyn> i guess i can just add a ton of /sys rules, one for each other dir other than fs
[17:49] <jjohansen> hallyn: do you know why lxc uses pivot root instead of chroot?
[17:49] <hallyn> how much will that slow things down (let's say 15 rules per container)?
[17:50] <jjohansen> not at all
[17:50] <hallyn> jjohansen: the reason was to prevent chroot escape
[17:50] <hallyn> i think everyone is somewhat open to switching back
[17:50] <hallyn> especially if apparmor will be able to help (right now it can't)
[17:51] <jjohansen> hallyn: okay.  I currently have some problem with the pivot root stuff, where I can only switch the profile of the current task.  Doing more is turning out to be problematic
[17:51] <stgraber> hallyn: btw, just noticed I have quite a bit of apparmor DENIED messages in my kernel.log: http://paste.ubuntu.com/824140/
[17:51] <hallyn> gah
[17:51] <jjohansen> this limitation shouldn't affect lxc
[17:52] <hallyn> jjohansen: ok.  (note that libvirt-lxc also uses pivot_root.)
[17:52] <jjohansen> hallyn: its doable, but its a pain because of creds, where tasks have to update their owne state
[17:52] <hallyn> pivot_root has other problems, so switching back has been discussed
[17:52] <hallyn> but it's so nice and clean
[17:52] <adam_g> smoser: cobbler devenv / libvirt+pxe working okay for you on precise?
[17:52] <hallyn> ok ok, i need to do a reboot test, biab
[17:52] <Danny_Joris> hallyn: just did a flawless install with 10.04 lts
[17:53] <hallyn> Danny_Joris: worth filing a bug IMO, but i'm not sure against what
[17:53] <hallyn> biab
[17:53] <smoser> adam_g, i think so, yeah. its 'odev' now.
[17:53] <smoser> https://code.launchpad.net/~orchestra/orchestra/odev/
[17:53] <adam_g> ah
[17:58] <hallyn> jjohansen: does http://people.canonical.com/~serge/lxc.apparmor look ok?  (really rebooting now)
[18:05] <hallyn> no that's not right
[18:07] <hallyn> jjohansen: http://people.canonical.com/~serge/lxc.apparmor  ugly and won't scale as more exceptiosn come up, but might work for now
[18:10] <smoser> hallyn, random information, precise util-linux does not have the race-free losetup
[18:11] <smoser> that will be in utli-linux 2.21
[18:11] <smoser> we have 2.20
[18:14] <smoser> hallyn, do i have to do anything after updating the app armour profile to make it take ?
[18:14] <smoser> jjohansen?
[18:17] <hallyn> smoser: 'apparmor_parser /etc/apparmor.d/usr.bin/lxc-start'
[18:17] <hallyn> uh, add --reload
[18:17] <hallyn> gah, replace
[18:17] <jjohansen> smoser: you need to reload the profile
[18:18] <smoser> with sudo service apparmor reload
[18:19] <jjohansen> smoser: yeah that will work, if the profile is in the profile directory
[18:19] <hallyn> smoser: i just installed cgroup-lite in a container with the lxc.apparmor i mentioned above
[18:21] <hallyn> stgraber: so lxcconsole.cofn effectively can start when /run is mounted.  Is there any other fs which lxcconsole.conf might ought to wait on?
[18:22] <hallyn> container-detect.conf looks nice.  scary but nice :)
[18:24] <hallyn> stgraber: secondly, I'm considering pushing lp:~serge-hallyn/ubuntu/precise/lxc/lxc-allowtty (works here).  look ok?
[18:27] <jjohansen> hallyn: re profile: it looks okay I guess, except the ugly attach_disconnected.  I realize you need it, atm but I would like to fix that before FF.
[18:28] <jjohansen> re the DENIED messages, I think that one is actually a bug in the attach_disconnected, I'll have to look into it more
[18:28] <hallyn> jjohanson: me too!  :)  (attach_disconnect)
[18:29] <stgraber> hallyn: AFAIK getty only depends on / being mounted and / should always be there, so no, I think the only condition really is "are we in an LXC container"
[18:30] <stgraber> hallyn: (looking at the branch now)
[18:30] <hallyn> well it does need /dev/console to exist :)
[18:30] <stgraber> hallyn: right, which AFAIK is there in the regular MAKDEV created /dev and by default in devtmpfs/udev?
[18:30] <hallyn> trying setsid in start() real quick...
[18:31] <stgraber> hallyn: anyway, mounted won't be emitted until udev/mounall have run, so we know /dev should be pretty much ready by the time lxcconsole is called
[18:31] <hallyn> stgraber: console is put there by lxc-start anyway before init starts, so never mind :)  i was being silly
[18:31] <hallyn> so, should i change the start on in console.conf in lxcguest for now?
[18:32] <hallyn> or is that not worth it?
[18:33] <stgraber> hallyn: I don't think that's worth it at the moment, just want to get it right when we push that to upstart
[18:33] <hallyn> sounds good
[18:33] <stgraber> hallyn: branch looks good, that's some interesting apparmor path matching you have there ;)
[18:33] <hallyn> :(  yeah
[18:35] <adam_g> zul: that looks pretty straight forward, why did we wait so long to do it after glance? wasn't there something blocking that made it less trivial than that? i dont remember
[18:35] <hallyn> jjohansen: stgraber: maybe it's ugly enough to make jdstrand consider FFE for the pattern matchign extensions :)
[18:35] <zul> adam_g: i think i was waiting for the root wrapper stuff to finish
[18:35] <jdstrand_> jeez my nick is just on fire
[18:36] <jjohansen> hallyn: err yes it is ugly enough we where discussing the possibility of a FFE
[18:38] <hallyn> stgraber: ok pushing
[18:40] <zul> adam_g: im going to throw it up in the testrig
[18:40] <adam_g> zul: what? no
[18:41] <stgraber> hallyn: oh, just thought of it, please avoid uploading lxc until post-freeze. LXC is seeded by Edubuntu so it's affected by the freeze
[18:41] <hallyn> stgraber: sorry, i just did
[18:41] <adam_g> zul: er
[18:41] <adam_g> zul: you mean the changes at http://paste.ubuntu.com/824199/ ?
[18:41] <hallyn> #ubuntu-release did say they were re-spinning, is that separate from edubuntu respins?
[18:41] <stgraber> hallyn: yeah, just saw that. It's not really an issue at this point because we expect rebuilds for kernel + some gnome stuff anyway.
[18:41] <zul> adam_g: yes
[18:42] <hallyn> stgraber: i'll not push any more, sorry
[18:42] <hallyn> stgraber: are openvz consoles in upstart actually going to work?
[18:42] <stgraber> hallyn: np. I should have thought of it earlier ;)
[18:42] <hallyn> You're making console-detect.conf do a bit more work before exiting on non-containers, so i want to make sure it's worth it
[18:42] <adam_g> zul: give it a minute for current test to run.
[18:43] <hallyn> stgraber: especially the actual filesystem reading, which can really slow things down
[18:43] <zul> adam_g: ack...lemme know
[18:43] <stgraber> hallyn: no, they usually fail and use 100% CPU on OpenVZ
[18:43] <adam_g> zul: you're going to merge them into the ~openstack-ubuntu-testing branch or ~ubuntu-server-dev?
[18:43] <hallyn> lol
[18:43] <zul> openstack-ubuntu-testing
[18:43] <adam_g> zul: not sure what the easiest would be
[18:43] <zul> adam_g: well if i merge it into the ubuntu-server-dev then we can test your merge as well
[18:44] <stgraber> hallyn: yeah, /dev/tty* is usually not something you want to touch in a VZ. Most people just rm the tty* jobs. I'd have to do some tests and see if we can deal with that without breaking the world.
[18:44] <hallyn> stgraber: not sure i follow - you're saying you'll edit debian/conf/tty* to not run on container CONTAINER=openvz?
[18:45] <adam_g> zul: i propose we merge to ubuntu-server-dev, they automatically trickle down to the test rig and we can just revert them in ~ubuntu-server-dev  without much work
[18:45] <zul> adam_g: good enough for me
[18:45] <stgraber> hallyn: yes, that'd be a way of doing it, if upstart lets me do that (don't think you can have something depend on an event not being emitted)
[18:46] <adam_g> zul: but please test build *and install* before doing that. if jenkins jobs fail because packages fail to install due to typos in postinst and stuff, im gonna f'in kill you! :)
[18:46] <hallyn> i bet SpamapS can think of a cool way
[18:46] <stgraber> hallyn: the other way would be to have them stop on container CONTAINER=openvz which isn't really ideal either but would avoid the 100% cpu part of the problem :)
[18:46] <hallyn> yeah that sounds worthwhile
[18:46] <zul> adam_g: just doing a test run here
[18:47] <stgraber> hallyn: another way would be to emit "not-a-container" and have the ttys depend on that or container CONTAINER=lxc or container CONTAINER=lxc-libvirt
[18:47] <adam_g> hallyn: have you seen any problems with pxe+kvm on precise? im running into an issue after a recent upgrade where dhcp requests make it thru to dnsmasq only %25 of the time, if that
[18:47] <adam_g> smoser: ^
[18:48] <hallyn> adam_g: no, i 've not noticed, though we have noticed dhcp problems in containers.
[18:48] <hallyn> adam_g is your virbr0 stp on?
[18:49] <stgraber> stp is completely broken in libvirt. I made sure I have my config explicitly saying "stp=off" and it's still setting it on at boot time
[18:49] <hallyn> feh
[18:49] <hallyn> stgraber: pls open a bug?  that needs to get fixed.
[18:49] <adam_g> STP is enabled. if thats broken, that'd make sense
[18:50] <stgraber> hallyn: will do next time I reboot and confirm that doing it the clean way like I just did (net-edit) solves it (instead of messing directly with the .xml like I did last time)
[18:50] <hallyn> adam_g: well that means that the dhcp request (iiuc) will go on the wider net
[18:50] <hallyn> adam_g: at any rate turn it off and see if that fixes it :)
[18:51] <adam_g> hallyn: yes, disabling it fixed
[18:52] <hallyn> stgraber: so one last time, on your upstart-containers tree, is it a concern that non-containers will always process /proc/self/status and look for /proc/{vz,bc}, during early boot?
[18:52] <hallyn> adam_g: drat.  uh, i mean, good.
[18:52] <hallyn> adam_g: thanks
[18:53] <smoser> adam_g, i did see this.
[18:53] <adam_g> hallyn: shall i raise a bug?
[18:53] <hallyn> adam_g: go ahead.  stgraber: adam_g is opening it  ^
[18:53] <smoser> in odev i was timing out on boots sometimes.
[18:54] <hallyn> odev?  wth...
[18:55] <stgraber> adam_g: thanks
[18:55] <hallyn> of course it could be a bridge-utils regression
[18:56] <stgraber> hallyn: it'll make boot slower, yes, now looking through a single file in /proc should be so fast we don't really care
[18:56] <adam_g> what determines the stp + dhcp timeouts on a libvirt network? IIRC, if stp timeout is greather than the dhcp timeout, it will fail to pxeboot unless you drop to ipxe prompt, wait a bit, and retry dhcp
[18:56] <hallyn> stgraber: ok, then i'm happy - pls feel free to push :)
[18:57] <hallyn> stp timeout?  i don't understand those words together
[18:57] <stgraber> real	0m0.003s
[18:57] <stgraber> user	0m0.000s
[18:57] <stgraber> sys	0m0.000s
[18:57] <hallyn> i thought stp was just on or off
[18:57] <stgraber> hallyn: ^ that's running the check ;)
[18:58] <hallyn> adam_g: but since virbr0 by default is nat, stp doesn't make sense anyway i don't think.
[18:58] <smoser> roaksoax,
[18:58] <hallyn> huh.  brctl manpage now is implying that brctl off is a bad thing.
[18:59] <smoser> in early_command, we could 'echo force-unsafe-io > /target/etc/dpkg/dpkg.cfg.d/force-unsafe-io'
[19:01] <Daviey> smoser: we used to do that with uec-deployment-testing thing, didn't we?
[19:01] <Daviey> We did discuss doing it by default for installs.
[19:01] <smoser> hm..
[19:01] <smoser> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605384
[19:02] <smoser> but i sweare things are slower than they should be
[19:03] <adam_g> hallyn: by timeout i mean the time it takes for the port to initialize before the interface has link
[19:05] <Daviey> smoser: look at that, we discussed it and it was done :)
[19:06] <hallyn> i see.  upstream libvirt commit 1ae8eed1b4740f1977f05235b47c820c7397e0f9 appears to be the cause
[19:06] <smoser> you must have said "so be it", Daviey
[19:08] <hallyn> adam_g: i don't understand how, but maybe upping the delay would help you...
[19:08] <hallyn> note i have stp on on virbr0 and haven't noticed any dhcp issues
[19:08] <hallyn> but i'm sure i'm not as heavy as user
[19:09] <koolhead17> SpamapS: Can you suggest me some example/doc i should follow for the merge process
[19:09] <koolhead17> i got one https://wiki.ubuntu.com/MeetingLogs/devweek1107/MergingFromDebian
[19:13] <TimR_> hey guys I cant upgrade my 9.04 to 10.04 and I do not want to do clean install so how do I fix this?
[19:14] <adam_g> hallyn: its only an issue during pxe boot, when the interface has just come online and STP is probably still initializing/discovering/whatever. waiting till normal dhcp discovery later in boot gives it enough time, i assume
[19:15] <hallyn> but then delay in the bridge won't help, right?  that'll just squash traffic from the device during the timeout
[19:17] <adam_g> i suppose not
[19:17] <adam_g> was stp enabled by default on libvirt created bridges previosly?
[19:18] <hallyn> adam_g: i didn't think so
[19:18] <hallyn> adam_g: the commit that mentions their being on by default is from nov 2011
[19:19] <hallyn> lemme put on my dunce hat and go ask upstream on irc why they think on is best.
[19:22] <SpamapS> koolhead17: php5 is *not* an easy merge. ;)
[19:22] <TimR_> anybody?
[19:22] <koolhead17> SpamapS: planning to spend my night with it :D
[19:23] <gary_poster> hallyn, you asked on bug 924337 "Can you show what 'brctl show' on the host gives? Do your host logs show any problems with dnsmasq on lxcbr0?"  The first one is easy. virbr0 does have STP enabled (lxcbr0 does not).  For the second, I looked at /var/log/syslog and saw some dnsmasq chatter but nothing that was obviously an error.  I'll report this in the bug, but I'm mentioning it here so you can quickly give me a be
[19:23] <gary_poster> tter idea if I should look elsewhere.
[19:23] <SpamapS> TimR_: you can still upgrade 9.04 to 9.10, you just need the old releases..
[19:23] <TimR_> where do I find it?
[19:23] <hallyn> gary_poster: as a workaround, you should be able to just change the 'start on' in /etc/init/console.conf in your container to 'start on mounted MOUNTPOINT=/run'
[19:24] <hallyn> gary_poster: when stgraber's new upstart hits archive (not sure how soon that can happen) it'll be fixed there.
[19:24] <gary_poster> hallyn, ok awesome thank you.
[19:24] <hallyn> stgraber: which reminds me, we'll need to do a Breaks: lxc  on current version and below, and fix the ubuntu tempalte to ditch lxcguest on setup.
[19:25] <user10000> i need help to config QoS on my ubuntu server/router for gaming..anybody?
[19:28] <TimR_> SpamapS?
[19:31] <SpamapS> TimR_: google? not sure
[19:34] <gary_poster> hallyn, for the TTY problem (5:0 not allowed) from earlier, I have a workaround (uncomment that line).  Is there a fix coming as well?
[19:34] <hallyn> gary_poster: yes, i'm re-enabling that access.  fix should be in archive already
[19:35] <gary_poster> awesome thanks hallyn
[19:35] <hallyn> np, i think i messed up with that altogether.
[19:38] <smoser> hallyn, i like your /sys/fs/cgroup/* change.
[19:39] <hallyn> smoser: pretty eh?
[19:39] <smoser> but now i can't access /sys/fs/cgrope
[19:40] <smoser> oh well. it was probably just going to get me into trouble anyway
[19:40] <hallyn> especially on the internet
[19:41] <hallyn> boy, trying out having the unity bar not autohide.  it's very distracting while reading a full-screened term :)
[19:43] <Daviey> hallyn: I had to switch to not hide.. i found that /more/ annoying
[19:44] <hallyn> Daviey: not hide?
[19:44] <hallyn> Daviey: i just switched to always hidden.  I tried always present, and it phsyically hurts
[19:48] <Daviey> heh
[19:50] <stgraber> hallyn: oops, just read the comment in lxcconsole.conf saying that libvirt uses tty1.conf, so that means my current start condition is wrong (starts on both lxc and lxc-libvirt)?
[19:53] <zul> adam_g: the ubuntu-server-dev branch has the /bin/false now
[19:53] <hallyn> stgraber: oops, yes.  i forgot about that.
[19:56] <stgraber> hallyn: any luck with setsid()
[19:56] <hallyn> stgraber: well, thsi is where i think i really messed up - it looks like apparmor is preventing the sound+kbd messups now anyway
[19:57] <hallyn> stgraber: so I'm leaving it be for now
[19:57] <hallyn> so right now, with new container creatd with newest lxc, it's not corrupting things for me
[19:58] <adam_g> zul: k, ill kick off a test
[19:58] <zul> adam_g: tested and launched an instance ok
[20:11] <roaksoax> smoser: i guess w ecould do that, but doesn't d-i provide anything to set that already?
[20:11] <smoser> see above, apparently it does it already.
[20:11] <hallyn> Danny_Joris: 11.10 server install went flawlessly for me in kvm.  I assume it's some virtual box issue?  Might be worth looking through the logs after the install fails.
[20:22] <adam_g> roaksoax: ping
[20:25] <roaksoax> adam_g: pong
[20:25] <adam_g> roaksoax: thoughts on Bug #918796 ?
[20:25] <adam_g> roaksoax: im wondering if cobbler might have changed behavior when importing + creating /var/www/ks_mirror/ directories
[20:26] <roaksoax> adam_g: that's something I'm about to start looking into
[20:26] <roaksoax> adam_g: i'm guessing it is because renaming a profile ends up not renaming /var/www/ks_mirror
[20:27] <roaksoax> adam_g: and when adding a new one, it cant use something that was previously used
[20:27] <roaksoax> or the other option is that if the name uses -<arch> and --arch is specified as swell, then there's some validation error somewhere
[20:28] <adam_g> roaksoax: yeah.. its not renaming the ks_mirror directory, because its looking for it ref.name, but apparently when its imported, its created as ref.name + ref.arch or some such.
[20:29] <adam_g> roaksoax: our input to cobbler from o-import-isos + c-ubuntu-import hasn't changed much AFAICS between oneiric  and precise
[20:29] <roaksoax> adam_g: yeah I'm guessing it is a bug within cobbler's validation
[20:29] <roaksoax> adam_g: cause either way, if the arch is not specified in the --name then, once the arch is detected
[20:30] <roaksoax> (or specified) it is automatically added to the name
[20:30] <adam_g> ah
[20:31] <roaksoax> so somewhere in the process something doesn't work the way it should
[20:31] <adam_g> well, either way.. the precise version of cobbler-ubuntu-import has been working fine on the oneiric cobbler server in terms of keeping distros up to date and named properly. the double-arch-in-name bug causes issues for that update process on precise, because renaming fails
[20:32] <roaksoax> adam_ TBH I wasn't the one who found the bug, but rather, it came up in a discussion i was having so I filed it
[20:32] <roaksoax> and I haven't seen it yet
[20:41] <adam_g> roaksoax: just checked again on a fresh daily:  apt-get -y install cobbler && cobbler-ubuntu-import precise-x86_64
[20:41] <roaksoax> adam_g: did the double arch thing happened again?
[20:42] <adam_g> http://paste.ubuntu.com/824379/
[20:42] <adam_g> yeah
[20:42] <smoser> SpamapS, what tool was it hta tyou were usin gthat showed io?
[20:42] <roaksoax> adam_g: ok I think I have an idea of what might be going wrong
[20:43] <smoser> what double arch thing ? adam_g ?
[20:43] <SpamapS> smoser: iostat and vmstat
[20:43] <smoser> oh.
[20:43] <smoser> i see it.
[20:43] <smoser> hm..
[20:43] <roaksoax> adam_g: where you using a server in the lab?
[20:47] <roaksoax> adam_g: is there any free machinein the lab that I can mess with? one that already has precise on it
[20:48] <adam_g> roaksoax: im in cloud instance
[20:48] <roaksoax> adam_g: ok
[20:48] <adam_g> roaksoax: try canonistack precise
[20:49] <roaksoax> adam_g: about to do that ;)
[20:53] <SpamapS> smoser: are you looking at making jstack more efficient again?
[20:54] <smoser> no. i was just working on it.
[20:54] <smoser> it uses btrfs clone now!
[20:54] <smoser> :)
[20:54] <smoser> well, all of lxc uses btrfs clone if /var/lib/lxc/ is btrfs
[21:01] <smoser> hallyn, i hvae a question
[21:01] <smoser> lxc-ls starts to not work properly as non-root, possibly after you've done some bad things to it.
[21:02] <smoser> is it a bug by the user to try to use it as non-root, or in lxc-ls
[21:05] <hallyn> smoser: there's no particular reason why we'd want to stop lxc-ls  for non-root.  Do you know what you've done to it to top it working?
[21:06] <hallyn> smoser: before it wasn't working bc *I* broke lxc-start...  (well, src/lxc/cgroup.c)
[21:06] <smoser> not really. but i see it often. when using juju.
[21:06] <smoser> stuff like:
[21:06] <smoser> /usr/bin/lxc-ls: line 35: cd: /sys/fs/cgroup/cpuset///lxc: Permission denied
[21:06] <smoser> ls: cannot access ubuntu-jstack-nova-cloud-controller-0: No such file or directory
[21:06] <smoser> ls: cannot access ubuntu-jstack-keystone-0: No such file or directory
[21:09] <roaksoax> adam_g: ah yes, I think I had fixed that.. maybe a patch got dropped or something changed in the newest upstream release
[21:09] <adam_g> roaksoax: cobbler/api.py ln. 768
[21:10] <hallyn> smoser: can you file a bug?  (it soudns like a rehash of two earlier issues, nother of which you *should* be having)
[21:10] <adam_g> roaksoax: api.import_tree() is completely changed since oneiric. among other things,  path += ("-%s" % arch)
[21:12] <roaksoax> adam_g: i think there was a patch for that
[21:13] <roaksoax> adam_g: are you providing a fix?
[21:13] <roaksoax> adam_g: or should I
[21:13] <roaksoax> ?
[21:13] <adam_g> roaksoax: im going afk for lunch. i only traced it to there, didn't look any further at a fix or why it changed to begin with
[21:14] <roaksoax> adam_g: ok I'll work on it then :). thanks
[21:40] <stgraber> hallyn: https://launchpad.net/~stgraber/+archive/experimental has a test upstart with my changes
[21:40] <raj> how reliable is 11.10 as a server?
[21:40] <raj> just as reliable as 11.04?
[21:41] <stgraber> hallyn: I basically rebased lxcconsole.conf on the other tty jobs and renamed it to console.conf (in case we one day find something else than lxc needing that). I also added the new conditions to the other jobs and the not-container event,
[21:41] <stgraber> hallyn: would be nice if you could test than in lxc, lxc-libvirt and some standard system (non container). I tested lxc and standard system here (VM).
[21:43] <stgraber> hallyn: as running-in-container depends on stuff that are in the packaging, I'll move it to debian/ and will propose the branch for merging (probably after a quick chat with slangasek)
[21:43] <hallyn> stgraber: ok
[21:44] <hallyn> stgraber: (trying to get two bug reproduce tests going right now, having some trouble... but will try to get to those soon)
[21:50] <adam_g> zul: all tests passed with those packaging changes, btw
[21:51] <hallyn> stgraber: d'oh.  seems i did something wrong.  'mountall : event failed'
[21:54] <TimR> sudo mount -o loop /media/cdrom0/alternate-cd.iso /mnt/alternate
[21:54] <stgraber> hallyn: do you sill get a console after that?
[21:54] <TimR> I cant get the alternative cd to work correctly via command line
[21:55] <hallyn> just took an existing workign container, cloned it, added your ppa, purged lxcguest, updated (including upstart).  no, no console, and lxc-ps shows nothing
[21:56] <hallyn> stgraber: btw I'm not 100% sure about your tty{5,6].conf - why do you have them starting in lxc and lxc-libvirt contianers?
[21:56] <stgraber> hallyn: ok, that's odd. I'm seeing some problems in VM now (looking at it) but it works fine in the container
[21:56] <stgraber> hallyn: yeah, I only just noticed that, we indeed only need tty1-tty4
[21:57] <hallyn> dont' know if that hurts anything...
[21:58] <stgraber> hallyn: when you say lxc-ps shows nothing, is that nothing as in just init or just nothing weird?
[21:58] <hallyn> stgraber: that time it showed nothing at all, now i get http://paste.ubuntu.com/824480/
[21:58] <hallyn> how can emit hang?
[21:59] <hallyn> do i need dbus maybe...
[21:59] <stgraber> hallyn: it can. I actually just fixed that one here.
[21:59] <hallyn> (installing dbus didn't help)
[22:00] <stgraber> hallyn: I also just noticed my package version being stupid (should have been ~ppa1 so I can do some tests). I'll upload a new version now but with a lower version number so you'll need to manually install it (sorry ...)
[22:00] <hallyn> stgraber: np, i'll just use a new container
[22:00] <hallyn> stgraber: i assume it'll be an hour before ppa builds?
[22:01] <stgraber> hallyn: more like 10-15min. I skip the build queue ;)
[22:01] <hallyn> stgraber: please satisfy my curiosity - wtf is making it hang?  :)
[22:02] <hallyn> ok, set a timer - i'll retry in 20 mins
[22:02] <stgraber> hallyn: don't know to be honnest, I just went with my usual fix for cases where it hangs "initctl emit --no-wait"
[22:02] <hallyn> oh.  duh.
[22:02] <stgraber> it usually happens when a job is "start on starting some-other" and you get into weird circular dependencies, but it's not the case here, so not really sure ;)
[22:02] <hallyn> here's hoping i'm not over-taxing my laptop (with a set of nested kvms) and it doesn't overhead+shutdown again...
[22:03] <stgraber> you need water cooling ;)
[22:05] <TimR> can anybody help me I cant get the alternative cd update to work via command line
[22:05] <kirkland> smoser: fyi, i just launched a precise t1.micro, it's up and running, but 30 minutes later, no console output
[22:06] <smoser> it does hapen.
[22:08] <smoser> kirkland, could you follow up in bug 588725
[22:09] <smoser> hm...
[22:09] <smoser> i guess that i should probvably open a thread and then ask you to append your instance-id and ami and such to it.
[22:10] <Patrickdk> hmm, I should file an annoyance against debian-install
[22:10] <Patrickdk> that is the correct package for the installer these days right?
[22:10] <TimR> am I doing something wrong here?
[22:11] <zul> adam_g: swweeeet!
[22:12] <RoyK> ?
[22:12] <roaksoax> adam_g: http://pastebin.ubuntu.com/824494/
[22:13] <kirkland> smoser: another strange thing ....
[22:13] <kirkland> smoser: 0% [Connecting to us-east-1.ec2.archive.ubuntu.com (10.210.205.172)]
[22:13] <kirkland> smoser: i launched another instance
[22:13] <kirkland> smoser: and that archive just isn't responding
[22:14] <kirkland> smoser: I ctrl-c and retry
[22:14] <kirkland> smoser: get a different mirror, and then I'm off and running
[22:14] <kirkland> smoser: i wonder if the two issues are related?
[22:14] <adam_g> roaksoax: ive done something similar locally, will run with that for today while i do some cobbler work. might be worth checking with upstream source for context around that change
[22:15] <TimR> ok I guess im not being heard here
[22:15] <smoser> utlemming, can you dig on archive issue above please ?
[22:16] <smoser> kirkland, says that 10.210.205.172 is dead
[22:16] <smoser> kirkland, two issues not related.
[22:16] <smoser> kirkland, please append instance-id and other information to https://forums.aws.amazon.com/thread.jspa?threadID=86174
[22:16] <smoser> or if you dont want to bother with an id there, i will copy from the bug.
[22:16] <roaksoax> adam_g: IIRC, I saw similar bug long time ago and was fixed in a similar way
[22:17] <smoser> as it says in the bug, i very much suspect that there is a hypervisor loss of data on this stuff.
[22:17] <kirkland> smoser: okay
[22:17] <adam_g> roaksoax: strange
[22:17] <kirkland> smoser: I opt for pasting into bug, eff the forum :-)
[22:17] <roaksoax> adam_g: indeed! I will review upstream branches and our dropped patches later
[22:18] <kirkland> smoser: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588725/comments/12
[22:19] <stgraber> hallyn: packages built, just waiting for them to publish now
[22:21] <smoser> gracias, kirkland
[22:21] <smoser> later all.
[22:21] <kirkland> smoser: de nada
[22:22] <utlemming> smoser: digging
[22:24] <TimR> so can anybody help me?
[22:30] <greppy> TimR: If someone can, they will.  It may help if you give specific error messages, if they take up more than one line, you should probably use !pastebin
[22:30] <greppy> bah
[22:30] <TimR> i have
[22:30] <TimR> and everytime I get muted out
[22:31] <greppy> TimR: *shrug* if no one can help you, then they can't help you, sorry.
[22:31] <TimR> then if they cant help why be in there?
[22:32] <greppy> because they can't help you, they shouldn't be here?
[22:32] <TimR> right....
[22:33] <greppy> You don't think that is a little arrogant on your part?
[22:33] <TimR> no
[22:33] <TimR> you think its arrogant beging muted when asking a question?
[22:33] <greppy> none of us are paid to help people in here.  When you ask a question, if someone can help you, they will.
[22:34] <TimR> ya four hours later?
[22:35] <greppy> If that is when someone can help you, then yes, 4 hours later, or 5 or 6 or whatever.
[22:35] <hallyn> stgraber: not seeing it yet
[22:35] <greppy> and on that note, it's time for me to go become unconscious.
[22:35]  * greppy &
[22:36] <stgraber> hallyn: yeah, it's taking long to publish ...
[22:36] <TimR> nvm I got main issue fix without have to upgrade the whole system
[22:36] <stgraber> hallyn: actually according to LP it just finished
[22:38] <hallyn> ah there it is
[22:38] <hallyn> it didn't auto-remove lxcguest
[22:39] <hallyn> wtf - exact same problem.
[22:39] <hallyn> 1.4-0ubuntu5~ppa1
[22:39] <hallyn> stgraber: bad debuild/dput?
[22:40] <stgraber> hallyn: looks like it. the job is wrong
[22:40] <hallyn> stgraber: was adding --nowait the only difference?
[22:40] <hallyn> i'll just test that by hand if so
[22:41] <hallyn> note i still get 'mountall: event failed" but i now get a console
[22:41] <stgraber> hallyn: that, disabling tty5 and tty6 and adding some || true at some risky places (as pre-start scripts are running with -e)
[22:42] <hallyn> stgraber: do you get the mountall error msg?
[22:42] <hallyn> oh noes!  and reboot didn't work
[22:43] <stgraber> hallyn: yeah, the mountall error seems to come from mounted-debugs
[22:43] <stgraber> *debugfs
[22:43] <stgraber> hallyn: chmod: changing permissions of `/sys/kernel/debug': Permission denied
[22:43] <stgraber> hallyn: got that testing with: lxc-start -n container -- /sbin/init --log
[22:44] <hallyn> not sure what we should do about that
[22:44] <hallyn> stgraber: but, does 'reboot' work for you?
[22:44] <hallyn> ok, added '|| true' to that and it shut up the error
[22:45] <stgraber> hallyn: yep, reboot works. Boot time varies though, probably because of dhclient
[22:45] <hallyn> i wonder if the newest kernel dropped the reboot patch
[22:46] <hallyn> i bet so
[22:51] <stgraber> hallyn: pushed ppa2 (adding --no-wait and actually basing console on tty1 instead of tty2, will make boot a bit slower but consistent with a regular ubuntu system)
[22:53] <hallyn> stgraber: with ppa1, libvirt-lxc container gets a console just fine
[22:55] <hallyn> stgraber: /etc/init.d/ondemand is biting at my ankles.
[22:56] <hallyn> but no that's not the only problem
[22:57] <stgraber> I think I'll start doing all my tests with static networking, dhclient timing randomness doesn't help for testing
[22:58] <hallyn> stgraber: I dunno, exact some container, with ppa1 upstart and no lxcguest, pid 1 will just not go away.  reboot+shutoff just hang
[22:59] <stgraber> hallyn: weird, reboot definitely works here (ppa1)
[22:59] <hallyn> what could i have done...
[22:59] <hallyn> ok i'll just start over i guess
[22:59] <stgraber> anything in dmesg?
[23:00] <stgraber> oh, btw, I just noticed you can flush the kernel log from a container (dmesg -c). Not sure if there's an apparmor way of blocking that though.
[23:00] <hallyn> just the similar stuff to what you have
[23:01] <hallyn> yeah it woudl've been nice to have dmesg separation for lts
[23:01] <hallyn> should be added to LxcSecurity wiki page
[23:02] <stgraber> hallyn: https://launchpad.net/~stgraber/+archive/experimental/+build/3137750/+files/upstart_1.4-0ubuntu5%7Eppa2_amd64.deb (haven't tested yet)
[23:02] <hallyn> i hate typing out python-software-properties
[23:02] <hallyn> ok thx
[23:05] <hallyn> can't resolve launchpad.net.  weird
[23:06] <stgraber> hallyn: if you switched to static and assume /etc/resolv.conf will be kept across reboot, you're wrong (you need to use dns-nameservers in /etc/network/interfaces) ;)
[23:07] <hallyn> i can't believe this.  can't resolve launchpad.net even on my laptop
[23:08] <hallyn> stgraber: that sounds bad
[23:10] <hallyn> stgraber: you purge lxcguest too?
[23:11] <stgraber> hallyn: yep
[23:11] <hallyn> i don't get it
[23:12] <hallyn> hm.  i just have no name service
[23:15] <hallyn> stgraber: i don't have resolvconf installed, but resolv.conf is pointing to 127.0.0.1.  expected?
[23:15] <stgraber> hallyn: yes, Network Manager starts dnsmasq since the sprint
[23:15] <stgraber> ps aux | grep nm-dns-dnsmasq
[23:16] <stgraber> if that doesn't give you a dnsmasq server, you have a problem :)
[23:18]  * hallyn doesn't like all this newfangled redirection and automation
[23:18] <hallyn> but especially not when it breaks his dns :)
[23:19] <hallyn> (obviously, existing connections are fine.)
[23:19] <hallyn> well hmm, what's going on here
[23:19] <hallyn> maybe i'ts not dnsmasq's fault
[23:22] <hallyn> but it is
[23:22] <hallyn> server=192.168.254.254
[23:22] <hallyn> but when i but 'nameserver 192.168.254.254' into /etc/resolv.conf, then i can resolv just fine
[23:26] <hallyn> stgraber: ^
[23:29] <stgraber> hallyn: hmm, that's weird, could it be multiple dnsmasqs fihghting for 127.0.0.1?
[23:29] <hallyn> stgraber: conceivable, though i don't see another
[23:29] <stgraber> hallyn: you can also try asking NM to restart the connection, see if that helps (NM kills and respawns dnsmasq everytime something changes)
[23:29] <hallyn> i've tried disconnecting and reconnecting several times
[23:30] <hallyn> btw, this is a separate issue, but yes i think this will completely screw up my setup for making this laptop a wireless bridge for my other one over eth0 (which runs another dnsmasq listening to eth0 for pxe-boot and dhcp)
[23:30] <hallyn> but i'm not trying to do that right now, and that dnsmasq is not runnign
[23:31] <hallyn> i think maybe i need to stop for the day (and just let my test installs run).  nothing is working or making sense
[23:32] <stgraber> hallyn: ok, lets try a few ideas: do you have nscd running? anything suspicious in /var/log/syslog (both NM and dnsmasq should log there)? any firewalling going on?
[23:33] <hallyn> no nscd
[23:33] <hallyn> three dnsmasqs - libvirt, lxc, and nm
[23:34] <hallyn> only suspiciosu thing i see - which should alarm us just a bit - is udev on the host complaining about the contaienr's veth (i assume) not existing, during the udev storm
[23:34] <hallyn> nothing for nm
[23:36] <hallyn> hm, qemu died while a nested qemu was installing
[23:57] <stgraber> hallyn: rebased on a clean upstart, re-commited everything in small chunks and updated changelog: lp:~stgraber/ubuntu/precise/upstart/upstart-containers/ (new branch, so bzr pull won't work unless used with --overwrite)
[23:58] <hallyn> thx, will look