[00:01] <Daviey> smoser: it's seeded in server
[00:01] <Daviey> blame Keybuk.
[00:04] <SpamapS> not Canada?
[00:09] <zul> SpamapS: too easy to
[00:12] <adam_g> zul:  ping
[00:13] <zul> adam_g: what up?
[00:15] <adam_g> zul: https://bugs.launchpad.net/swift/+bug/836922 thoughts on cherrypicking this? it will make maintaining a single charm to deploy different swift versions a bit easier. https://bugs.launchpad.net/swift/+bug/836922
[00:16] <zul> adam_g: i dont have a problem with it
[00:17] <adam_g> zul: ok. ill look to see if the charm can be modified to be compat with both sets of return codes first.
[00:17] <zul> adam_g: i can probably pull it in tomorrow though
[00:18] <zul> im about to go off line
[00:22] <adam_g> zul: ok, dont worry about it for now i guess. ill let you know. cya
[00:23] <Daviey> RoAkSoAx: did you have a chance to investigate bug 827496?
[01:16] <RoAkSoAx> Daviey my tests they dobaffect so.i would probably mark.that bug invalid but i need to test a bit more cause we use kickstar meta data in.daily basis without issues
[02:20] <ziesemer> Anyone have any quick suggestions for finding the endpoints using the most traffic on an Ubuntu server being used as a SOHO router?  I like the look of iftop, but it only seems to be able to listen on one interface - and as such, always shows the interface as one of the endpoints.
[02:52] <ruben23> hi guys anyone made a successfull install of eaccelerator for php on ubuntu server 10.04 LTS
[04:54] <Gasseus> Umm... I'm having difficulty getting apache to execute my php files...
[04:54] <twb> That's a feature.
[04:55] <Gasseus> Its pushing the php files as a download instead of running them.
[05:02] <malakhi> Gasseus: is mod_php activated?
[05:03] <Gasseus> malakhi yep
[05:08] <malakhi> Gasseus: make sure that Apache is using the right MIME type for php, and that the Apache config for the site that you're setting up allows php scripts to run.
[06:26] <Daviey> Gasseus: Can you try clearing your browser cache, i've seen it happen that people get that before installing  / enabling php, then the .php file is cached by the browser.
[06:26] <Daviey> Failing that, have you turned it off and on again? :)
[06:40] <ikonia> Daviey: think I may have almost got the docecot bug fixed, can't do anything with it for a few hours due to being on a clients site, but I should have a more realistic update later today
[06:40] <ikonia> dovecot
[06:48] <Daviey> ikonia: awesome!
[07:26] <Peetz0r> Hi, I use sslh to run ssh and https over port 443. Connecting to ssh over 443 takes way longer than over port 22. Can this be fixed, and how?
[08:05] <jamespage> morning all
[09:18] <rbasak> jamespage: surely the bug is that root is mounted read-only?
[09:19] <jamespage> rbasak, hmm - not so sure
[09:19]  * rbasak fires up his panda
[09:20] <jamespage> that might be something todo with how libvirt/nova/lxc work together
[09:20]  * jamespage admits he's not expert
[09:21] <Daviey> jamespage: please don't tarnish your brand.
[09:23] <Daviey> jamespage: so that bug seems to be because of:
[09:23] <Daviey> -    chown -R nova:root /var/lib/nova/ /var/log/nova/ /etc/nova/nova.conf
[09:23] <Daviey> +    chown -R nova:nova /var/lib/nova/ /var/log/nova/ /etc/nova/nova.conf
[09:23] <jamespage> agreed - that landed last night
[09:24] <Daviey> Yeah, not sure why that doesn't work
[09:24] <jamespage> it needs to accomodate running lxc filesystems
[09:24] <jamespage> and exclude them
[09:24] <rbasak> So your root filesystem is definitely mounted rw?
[09:24] <jamespage> just trying to figure that out now
[09:25] <rbasak> I see /dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0 in my cobbler-installed /proc/mounts
[09:25] <Daviey> hmm, is it enough to just || true ?
[09:26] <jamespage> http://paste.ubuntu.com/698389/
[09:27] <jamespage> rootfs is owned by root
[09:27] <jamespage> and should probably stay that way
[09:28] <jamespage> hmm - not sure that postinst works that well on upgrades
[09:28] <jamespage> it does not change the default group for nova -> nova
[09:29] <jamespage> so files still get created with nogroup and group owner
[09:30] <jamespage> hmm - I just ran that chmod once I fixed the upgrade
[09:30] <jamespage> it just changed all of the permissions in my rootfs as well
[09:30] <jamespage> yikes
[09:32] <rbasak> OK I'm lost now, I'm not sure I understand the problem
[09:32] <jamespage> rbasak, hmm - that is odd
[09:32] <jamespage> I don't think the issue was that my root filesystem was read-only
[09:32] <jamespage> I just downloaded and unpacked a load of packages
[09:33] <rbasak> Could an error have caused it to go read-only?
[09:33] <rbasak> dmesg?
[09:34] <jamespage> rbasak, well its still read write - I've not rebooted
[09:34] <rbasak> Can you write to it?
[09:34] <jamespage> /dev/mapper/winehouse-root on / type ext4 (rw,errors=remount-ro)
[09:34] <jamespage> yes
[09:35] <rbasak> OK, I'm lost then :)
[09:35] <jamespage> once completed the nova upgrade manually spun up another lxc instance just fine
[09:41] <jamespage> rbasak, OK - so it looks like on the of qemu-nbd mounted filesystems went read-only
[09:41] <jamespage> I can see that in the syslog from around 0600 this morning
[09:41] <jamespage> which caused the upgrade to bork
[09:42] <Daviey> jamespage: ah, could be a remount=ro issue?
[09:42] <Daviey> sdhc card errored?
[09:42] <jamespage> Daviey: yes
[09:42] <jamespage> running off SATA USB disk
[09:42] <jamespage> and only one of three that where mounted so odd
[09:43] <jamespage> the postinst is still *wrong* tho - it should not change the permissions in the filesystem mount on rootfs
[09:43] <jamespage> thats within the lxc instance
[09:48] <jamespage> gah - now nova-compute is borked an won't start
[09:53] <Daviey> eek
[09:53] <Daviey> jamespage: yeah, so lxc needs special-casing. Nice.
[09:54] <jamespage> yep
[09:54] <jamespage> bug report updated
[09:54] <jamespage> thanks for going ro filesystem - I would not have spotted that otherwise
[09:56] <jamespage> Daviey: is 'find' allowed in maintainer scripts?
[09:56] <jamespage> that would make it easy
[10:00] <Daviey> jamespage: there is history of it.
[10:02] <Daviey> jamespage: see gconf package, for example
[10:34] <vagy> hi
[10:35] <vagy> i've a question: i connect via ssh on a 10.04 system ... is it possible to monitor whatever messages the kernel or daemons generate by monitoring some tty device?
[10:48] <TeTeT> vagy: you would need to change (r)syslogs configuration
[10:49] <TeTeT> vagy: man rsyslog.conf might contain some useful information for your undertaking
[10:49] <TeTeT> vagy: in general I think an easier approach is to use byobu on the server and simply tail -f the relevant log files
[10:52] <vagy> TeTeT: thanx...at the moment i try to debug starting/stopping vmware vms, so i need to see whatever messages are produced by the daemons involved
[10:52] <TeTeT> vagy: maybe it's in /var/log/daemon.log
[10:53] <vagy> TeTeT: didn't know about byobu, i'll check it out
[10:53] <TeTeT> vagy: it's an enhancement for screen, if you're familiar with that tool - multiple consoles in one text window
[10:58] <PleXs> how can i change my keyb layout?
[11:04] <TeTeT> PleXs: I'd try sudo dpkg-reconfigure console-setup if you have no GUI
[11:08] <PleXs> I don't get the option to change keyboard layout there
[11:09] <PleXs> TeTeT, it only changes te looks of the console
[11:12] <TeTeT> PleXs: hmm, what Ubuntu version are you using? On Lucid the first screen I get for console-setup asks for the keyboard model
[11:13] <PleXs> TeTeT, latest version 11.04
[11:14] <TeTeT> PleXs: I don't have 11.04 running right now, but google pointed me to: http://igrudge.net/keyboard-layout-ubuntu-server-11-04/
[11:20] <PleXs> TeTeT, lol now it can't find the symbols :)
[11:20] <PleXs> never mind reinstall with the right keyboard :)
[11:43] <PleXs> isn't ssh standard installed with ubuntu server ?
[11:47] <qman__> PleXs, no
[11:47] <qman__> by default, ubuntu server has no listening services
[12:51] <hallyn> adam_g: bug 833891 for me is fixed with the posted debdiffs.  you had seen that bug too right?
[12:55] <smoser> hallyn, thats great digging
[12:59] <Daviey> hallyn: +  if (daemonize)
[12:59] <Daviey> +	  exit(0);
[12:59] <Daviey> Is that right?
[13:03] <lynxman> morning everyone o/
[13:05] <RoAkSoAx> Daviey: bug #827496 is really invalid
[13:06] <smoser> hallyn, and i'm confused.
[13:06] <smoser> just looing at your patch, i dont see how / where it does a daemonize.
[13:06] <RoAkSoAx> Daviey: as I always said/thought it was xD
[13:07] <smoser> oh. i see, it forks always.
[13:07] <Daviey> RoAkSoAx: awesome :)
[13:08] <smoser> jamespage, i commented on mp at https://code.launchpad.net/~james-page/nova/fix-lxc-and-primary-group/+merge/77308
[13:08] <jamespage> smoser: looking
[13:10] <jamespage> smoser: nice feedback - agree and amending now
[13:12] <smoser> thank you for testing, jamespage to find this.
[13:14] <rbasak> Who was working on live migrations on nova?
[13:16] <RoAkSoAx> jamespage: could you point me again to the pastebins you had for the arm provisiioning?
[13:16] <RoAkSoAx> jamespage: the preseed and your script to partition the sd card
[13:16] <jamespage> RoAkSoAx, http://pad.ubuntu.com/arm-server-netboot
[13:16] <RoAkSoAx> jamespage: cool thanks
[13:16] <jamespage> RoAkSoAx, np - any questions give me a shout
[13:19] <jamespage> smoser: updated and pushed
[13:23] <smoser> jamespage, looks like you mixed space and tab
[13:23] <smoser> :-(
[13:23]  * jamespage shouts loundly at himself
[13:23] <jamespage> or even loudly
[13:24] <smoser> that is pretty awesome failure though.
[13:24] <hallyn> Daviey: yes, it has already forked and the child will continue with its exec of vgscan
[13:25] <smoser> chowning a root filesystem to ownership of a uid:gid not likely even *in* the chroot.
[13:25] <jamespage> \o/
[13:25] <jamespage> I enjoyed it!
[13:26] <Daviey> hallyn: ah! :)
[13:27] <jamespage> smoser: updated without tabs
[13:27] <smoser> jamespage, ok.
[13:27] <smoser> one other thing
[13:27] <smoser> i just verified what i had thought
[13:27] <hallyn> Daviey: back in about 30 mins
[13:27] <smoser> i'm looking at marula
[13:27] <Daviey> hallyn: have fun!
[13:28] <smoser> find /var/lib/nova/ \! -user nova
[13:29] <smoser> shows that some files are owned by libvirt-qemu and 'kvm' group
[13:29] <smoser> i had thought that libvirt did that, but other files down that directory are owned by nova
[13:29] <smoser> (perhaps the libvirt-qemu owned ones are the new ones)
[13:29] <Daviey> smoser: nova-compute does chown some files.
[13:30] <smoser> right. thats what we're looking at...
[13:30] <smoser> on install
[13:30] <smoser> https://code.launchpad.net/~james-page/nova/fix-lxc-and-primary-group/+merge/77308
[13:30] <smoser> take a look at marula if you want.
[13:31] <lynxman> jamespage: don't shout at yourself, you're too nice for that
[13:32] <smoser> i'd like to understand what the "correct" permission for those files is
[13:32] <smoser> my experience is that files created by libvirt are owned by libvirt and then on destroy it puts ownership back
[13:33] <smoser> libvirtd runs as root, so in any battle over ownership, it can do what it wants.
[13:33] <smoser> but i dont know that we should just go changing it.
[13:33] <smoser> on an upgrade.
[13:37] <smoser> jamespage, ^
[13:39] <jamespage> smoser: hmmm
[13:39] <jamespage> probably not
[13:39] <smoser> i'm pretty sure we need to not chown . at very least its rude to libvirtd.
[13:40] <smoser> i'm not sure why that chown is thre.
[13:41] <smoser> soren, ^ it seems you at least brought 'chown -R' forward from maverick
[13:43] <jamespage> I think those permissions would be good for lxc instances (looking at what running a new one does)
[13:43] <jamespage> but prob not kvm
[13:43] <smoser> so why are we changing on upgrade?
[13:44] <smoser> i can moderately understand the fresh install case, where there was stuff there for one reason or another from before.
[13:44] <smoser> maybe it makes sense to only do that on first install and not on subsequent.
[13:45] <smoser> other than the case that we're fixing 'nogroup' and we can specially fix that.
[13:50] <jamespage> smoser: interestingly it used to set a root group ownership
[13:50] <smoser> yeah.
[13:51] <smoser> i'm sorry i made a mess of this jamespage
[13:51] <smoser> it started out so easy
[13:51] <smoser> but i really dont know why we'd do that on upgrade.
[13:51] <smoser> it can really only break things.
[13:51] <jamespage> I was working on the 'someone who has more knowledge of why this is done' had implemented that prior to lxc
[13:52] <smoser> yeah.
[13:52] <jamespage> and we just needed to tweak to exclude the rootfs firs
[13:52] <jamespage> dirs
[13:52] <smoser> which make sense.
[13:52] <smoser> but i think now, it is "someone did this, and nothing bad blew up"
[13:52] <jamespage> yes - but I will admit it is a little blind
[13:53] <jamespage> smoser: might just be that
[13:53] <smoser> jamespage, can you confirm this, and i'll open a bug:
[13:53] <smoser>  * apt-get install nova-compute-lxc
[13:53] <smoser>  * sudo apt-get dist-upgrade
[13:53] <smoser>  * be told your nova.conf has changed
[13:54] <smoser> your upgrade log indicates that.
[13:54] <jamespage> smoser: thats because I'm running over two nodes - so I have changed the nova.conf
[13:54] <jamespage> one half on a panda and the other on a laptop
[13:54] <jamespage> panda can't run its all
[13:54] <smoser> hm.. i thought that nova-compute-lxc did it
[13:55] <jamespage> I've not seen that
[13:58] <smoser> ok. it seems sane. i had thought that nova-compute-lxc was modifying on install. but it just lays down its own nova-compute.conf
[13:59] <jamespage> that sounds right
[13:59] <smoser> so what do you think to do here?
[13:59] <smoser> i feel apt to just avoid chowning 'rootfs' like is currently in your mp
[13:59] <smoser> and maybe i'll open a bug saying we shouldn't chown everything on upgrade
[14:00] <jamespage> hmm - so assuming that we take the 'its not blown up so-far approach'
[14:01] <jamespage> i'm nervous that we have switched from nova:root -> nova:nova for the permissions change
[14:04] <jamespage> smoser: looking at the version history of that file it switch from nova:nogroup to nova:root
[14:04] <smoser> and back again i think
[14:04] <smoser> :)
[14:04] <jamespage> and now we are switching to nova:nova
[14:06] <jamespage> smoser: not sure about the switch back - looks like that was done for the 'nogroup' security reason
[14:06] <jamespage> so actually switching to nova:nova makes sense
[14:07] <smoser> yeah, you're right. i dont know why i thoguth it changed back at the moment.
[14:08] <smoser> so then potentially fix things that are owned by root or nogroup
[14:08] <jamespage> so excluding the rootfs directories as in the MP is the minimal change ATM
[14:08] <smoser> i think i'm kind of up for th eminimal change at this point.
[14:08] <jamespage> and switching the primary group to nova closes the last bit of the security fix for nogroup
[14:08] <jamespage> +1 on that
[14:08] <smoser> right.
[14:09] <smoser> i think it make sense to go to nova group
[14:09] <smoser> for things that *were* root
[14:09] <smoser> or were nogroup
[14:12] <jamespage> it is a little blanket ATM
[14:14] <smoser> lets just go with minimal fix.
[14:15] <smoser> the other small concern i have is that 'find' taking ages
[14:15] <smoser> ie, if /var/lib/nova had 100,000s of files
[14:15] <smoser> but i dont think it should really.
[14:16] <jamespage> I think that is an outside case
[14:16] <jamespage> in the event that you have that many files in that directory
[14:16] <jamespage> you are going to be running a monster machine
[14:16] <jamespage> which should have good io - or else you are a flump
[14:53] <jamespage> someones busy with cobbler :-)
[14:54] <smoser> jamespage, ok...
[14:55] <smoser> so i'm almost certain that this is going to cause issue if libvirt closes the filehandles that have been chowned
[14:55] <smoser> i dont know what case it will occur in, as i tihnk on libvirt restart it wuld probably re-chown the files to libvirt ownership, and otherwise, it probably wont close its file handles
[14:56] <smoser> but if it does, its not going to be able to write the files that we chown'd to root:root
[14:56] <smoser> er... to nova:nova
[14:56] <smoser> jdstrand, around ?
[14:56] <jdstrand> yep
[14:56] <smoser> i'm looking at a case in nova, where we have some libvirt instances up, and then a nova upgrade will come through and do
[14:57] <smoser>  chown -R /var/lib/nova/ , which will include some files that are libvirt:kvm owned
[14:57] <smoser> libvirt-qemu:kvm
[14:57] <jdstrand> ok
[14:57] <smoser> is that going to cause a problem ?
[14:58] <jdstrand> otoh, it shouldn't as the perms aren't going to be rechecked since kvm already has the open fds
[14:58] <smoser> so far nothign has flown up in our faces, so i assume that libvirt is just fixing ownership on restart and not closing file handles otherwise (so the perms change dont take affect)
[14:58] <smoser> right.
[14:58] <smoser> so when *would* libvirt not fix these things and us get screwed
[14:58] <jdstrand> libvirt will readjust the perms on stop/start of the guest, yes
[14:58] <smoser> ok...
[14:59] <jamespage> smoser: still feels like that chown should be restricted
[14:59] <jdstrand> on guest reboot, qemu doesn't close the fd, so still should be fine
[14:59] <smoser> jamespage, yeah, but then i'm afraid
[14:59] <jdstrand> it is a bit clumsy the way nova is doing that
[14:59] <smoser> as i'm afraid that nova is going to for some reason need ownership for some reason
[14:59] <smoser> (live migration, instance terminate... something)
[15:00]  * smoser adds another 'for some reason' to make sure everyone knows he is sure of nothing
[15:00] <jdstrand> why not jsut do chown /var/lib/nova/, and then chwon -R on the subdirectories, excepting the one that hold instances
[15:01] <jdstrand> s/instances/image files/
[15:01] <smoser> well, 2 reasons... 1, there are files in there that have 'nogroup' or 'root' group that we want to fix.
[15:01] <smoser> and 2, we're not really sure why this code is there, and we're afraid of breaking things
[15:01] <jdstrand> I'm saying, do your chown, just be selective
[15:01] <smoser> right
[15:02] <jdstrand> you'd have to enumerate what to chown of course, and it would be a bit more brittle
[15:03] <jdstrand> or you could use find creatively and skip stuff that is -group kvm and -user libvirt-qemu
[15:04] <jdstrand> be careful with find though-- you don't want to follow symlinks and do stuff outside of /var/lib/nova
[15:04] <zul> morning
[15:04] <smoser> jdstrand, yeah.
[15:13] <zul> so chown -R the rootfs in lxc blows up?
[15:16] <jamespage> zul: kinda
[15:17] <zul> thats an unintentional effect
[15:18] <jamespage> it was nice to see everything owned by nova:nova in the lxc instance tho
[15:18] <zul> hehe
[15:35] <lynxman> jamespage: lol
[15:35]  * jamespage sighs
[15:36] <jamespage> likewise-open - remind me never to volunteer to look at a bug for Daviey again...
[15:39] <smoser> zul,  you should go ahead and pull jamespage's merge i think.
[15:39] <smoser> er... maybe not.
[15:39] <smoser> maybe we should prune off 'instances'
[15:40] <zul> jamespage: yeah i learned that pretty quick as well ;)
[15:40] <zul> smoser: does qemu/kvm have the same problem?
[15:40] <smoser> shoot
[15:40] <smoser> well, sort of
[15:40] <smoser> info on the above
[15:40] <smoser> in the above
[15:41] <smoser> we change the files, which is bad, but libvirt fixes them for us on restart.
[15:44] <Daviey> jamespage: what is making you said about it?
[15:45] <jamespage> Daviey: install on natty just fine - upgraded to oneiric and it borkes pretty bad
[15:45] <Daviey> jamespage: feel free to bounce it back to me.
[15:45] <zul> smoser: nbd.ko  defaults to 16 for the max number of block devices
[15:45] <Daviey> jamespage: gah, dammit
[15:47] <jamespage> Daviey: well I was able to confirm bug 854971
[15:48] <smoser> yes, i knew that.
[15:48] <smoser> thats why i said we need to bump it.
[15:51] <zul> smoser: is there a way we can check to see what the nbds_max is set to and make the changes dynamically in nova?
[15:52] <smoser> zul, i sort of suggested that.
[15:52] <smoser> theres really no point in the flag
[15:52] <smoser> just check all the devices
[15:53] <zul> smoser: agreed
[15:54] <zul> smoser: like just get the information from /sys/module/nbd/paramaters/nbds_max
[15:55] <smoser> right.
[15:55] <smoser> oh. it is there?
[15:55] <smoser> yeah, so thats nice.
[15:55] <zul> its staring at me right now
[15:55] <smoser> but even then, why bother?
[15:56] <smoser> it already looks through /sys/block/%s/pid
[15:56] <zul> well what if you reload the module....yeah right
[15:56] <smoser> just do that.
[16:26] <dori922> hey! I have a shell script thats works fine(adds users from a mysql database) untill i try to run it off a cron job :( via: "$ sudo crontab -u root -e" then: "5 * * * * /home/trofnan4/addclients.sh"
[16:26] <dori922> it woirks outside the cron so im not sure i have cron set up correctly :s
[16:33] <jamespage> Daviey: hmmm - trouble at mill - bug 845477
[16:36] <Daviey> oh golly.
[16:38] <jamespage> I'm trying a local build without V=1 to see what difference it makes
[16:38] <jamespage> Daviey: how important is it that likewise-open remains in the archive?
[16:40] <Daviey> jamespage: Honestly, not quite sure - i think it is, based on the fact there is bug feedback for Oneiric already
[16:59] <Daviey> m_3: Hey, you are a ruby fan - right? :)
[17:02] <m_3> Daviey: yup
[17:02] <m_3> ssup?
[17:03] <m_3> dang, did I just volunteer for a bug?
[17:03] <Daviey> m_3: Well... rails in oneiric is poorly, and i might need your guidance how to resolve.
[17:04] <m_3> are there specific bugs?
[17:04] <Daviey> m_3: bug 861524 .. does it really need to be that coupled to versions?
[17:04] <skrite> hey all, i have a simple dovcot and postfix mail server, working fine with Maildir but now i need a user to be abel to send mail from his laptop, how do i configure so he can use his user account to send mail?
[17:05] <m_3> Daviey: I can look now
[17:05] <Daviey> m_3: \o/
[17:12]  * robbiew takes a break from the USB key sweatshop...bbiab
[17:23] <Daviey> m_3: So the issue seems to be that some parts are using 2.3.11 and others 2.3.14.
[17:23] <medberry> SpamapS, is bug 523484 still open
[17:23] <medberry> (for say Natty)
[17:23] <Daviey> m_3: It's breaking at versioned depends, rather than code problems.  It's not clear to me what ois the best solution.
[17:24] <Daviey> m_3: bring them all to 2.3.14, or remove the versioned depends?
[17:29] <SpamapS> medberry: I don't know anything about that bug. :-/
[17:30] <SpamapS> medberry: if I did before, its been swapped out for other things :P
[17:30] <medberry> nod. thanks.
[17:35] <medberry> zul, ^ 523484
[17:36] <zul> medberry:  ah
[17:37] <Daviey> medberry: Have you encountered it?
[17:37] <medberry> Daviey, yes, sort of...
[17:38] <Daviey> medberry: If so, does removing ureadahead resolve the issue?
[17:39] <medberry> checking.
[17:41] <negronjl> SpamapS: ping
[17:42] <SpamapS> negronjl: pong, sup?
[17:42] <negronjl> SpamapS, having issues with the mysql charm.  Need MySQL expertise
[17:43] <negronjl> I am trying to create a mysql table with foreign keys and I get errno:150.  any thoughts?
[17:43] <SpamapS> negronjl: MyISAM?$ perror 150
[17:43] <negronjl> the mysql charm is being configured with aug and I don't quite get aug enough to do anything useful with it.
[17:43] <SpamapS> MySQL error code 150: Foreign key constraint is incorrectly formed
[17:43] <negronjl> tables are not MyISAM, they are InnoDB.
[17:44] <negronjl> SpamapS, also, when i install the same verison of mysql vi apt-get, it all works.
[17:44] <SpamapS> negronjl: very strange
[17:44] <negronjl> SpamapS, the issue is that the charm is already being used in other parts of nova and would just like to fix the charm ( I am pretty sure is something that aug is doing )
[17:44] <SpamapS> negronjl: well I don't know what that error message means well enough to debug it..
[17:45] <negronjl> SpamapS, ahh..ok.  Know of any MySQL guru's ?
[17:45] <SpamapS> negronjl: we don't change much in my.cnf ...
[17:45] <SpamapS> negronjl: I'm sure I could help, but don't have any time to dig into it right now. :-/
[17:46] <negronjl> SpamapS, thanks anyway.  I'll work it out somehow ( I hope ) :)
[17:47] <SpamapS> negronjl: google that error message.. I think its probably something simple.
[17:47] <SpamapS> negronjl: the settings we changed in my.cnf really shouldn't have any bearing.. :p
[17:47] <negronjl> SpamapS, will do.  thx
[18:11] <lynxman> SpamapS: actually they did, we found the issue :)
[18:11] <lynxman> SpamapS: InnoDB engine won't do a foreign key relation between two fields that have different type, this case was varchar relating to int
[18:17] <bau_> hi all i have a problem with my ubuntu server: i can't see samba shares but i can ssh it and smb://ip-address to it, why?
[18:51] <skrite> how do i troubleshoot not being able to log into my email server from a client like thunderbird. i can connect to the dovecot receiving but not the postfix smtp from outside
[18:55] <pyro_killer> anyone in today?
[18:56] <koolhead17> hi all
[18:56] <pyro_killer> my ubuntu server will only upload 20-30kBps, wich is not enoug for my use
[18:57] <pyro_killer> ive tried niceing it, reniceing it, and the ww-data user, seen through apaches config files, and it isnt runing anything else atm
[18:58] <pyro_killer> the speeds ive gotten on torrents on it have been up to 9 MBps
[19:01] <Pici> pyro_killer: Stupid question, but your torrents aren't seeding when you're trying to download things from your server, right?
[19:02] <pyro_killer> Pici: no, i've killed it, ive had this problem for some time
[19:02] <pyro_killer> Pici: but it seems that after a certain amount of installations, for compilers, mods for apache and such, it hits, and gets capped
[19:02] <JanC> pyro_killer: it's only with apache that you have the problem?
[19:03] <pyro_killer> also the ......
[19:03] <pyro_killer> vsftp
[19:03] <Pici> pyro_killer: Is it purely a bandwidth issue, or are you seeing problems with apache cpu usage that might be causing a bottleneck?
[19:04] <pyro_killer> no, there is no bottleneck, only running mysql and  apache
[19:04] <jamespage> Daviey: I've marked bug 854971 as server-o-rs
[19:04] <jamespage> patch from upstream - trying it now
[19:04] <jamespage> but looking OK
[19:04] <pyro_killer> http://bildr.no/view/986071
[19:05] <pyro_killer> are there any well known programs that restrict it, cause it has happened before
[19:05] <Daviey> jamespage: you rock star
[19:05] <JanC> pyro_killer: did you try downloading from your server from multiple locations?
[19:06] <Daviey> jamespage: Whilst you are here, remember we talked about jenkins testing via juju for daily testing of openstack?
[19:06] <pyro_killer> yes, my buddies also get it when they download files from it
[19:06] <SpamapS> lynxman: I'm a little confused by that. Are you saying that the FK's basically just weren't happening before, because it was on a MyISAM table?
[19:06] <Daviey> jamespage: - That was blocked on complex testing blueprint, and juju / orchestra being 'ready', right?
[19:07] <pyro_killer> the cap is usually 80-30kbps
[19:07] <pyro_killer> *kBps
[19:07] <lynxman> SpamapS: no, it's an InnoDB constraint
[19:07] <jamespage> Daviey: I do remember
[19:07] <jamespage> and I have done some work on that
[19:07] <jamespage> as I have failed todo for the last week (At least)
[19:08] <jamespage> I need to spend time with the latest versions of adam_g's formulas
[19:08] <jamespage> and get them working with the formula test service
[19:08] <jamespage> and get them working with the formula test charm
[19:08] <jamespage> tomorrow
[19:09] <SpamapS> lynxman: But FK's don't do *anything* on any other engine
[19:09] <SpamapS> lynxman: so its a bug in whatever was creating the FK
[19:09] <lynxman> SpamapS: still it's an InnoDB requirement according to the manual *shrug*
[19:09] <JanC> pyro_killer: does the same issue happen with ssh/sftp?
[19:09] <lynxman> SpamapS: exactly, it's a bug in keystone :)
[19:09] <SpamapS> lynxman: ok, just making sure. :)
[19:09] <Daviey> jamespage: Great!
[19:09] <Daviey> jamespage: Now go home. :)
[19:10]  * SpamapS wishes MyISAM would contact Dr. Conrad Murphy for some sleeping medication...
[19:10] <jamespage> Daviey: will do once I've done limited testing on likewise-open
[19:10] <pyro_killer> ssh, works but is really slow, to my eyes it seems like a security feature, we can be several people downloading slowly from it, so that it goes pretty fast in total, but we both get individually low speeds, even if we are alone
[19:10] <pyro_killer> connecting to the server
[19:11] <pyro_killer> ssh is not really slow slow, but there are small amounts of info
[19:11] <pyro_killer> so you dont really notice
[19:11] <jamespage> Daviey: heck it builds, installs and starts without error - good enought for me
[19:11] <jamespage> and one step further that it does ATM
[19:13] <JanC> pyro_killer: that's why I referred to sftp (or you could use scp instead), which transfers files over an ssh link, so causes more traffic  ☺
[19:13] <JanC> pyro_killer: did you ask your hosting provider?
[19:13] <JanC> pyro_killer: because they might be doing this...
[19:14] <pyro_killer> i have asked them, but a similar ubuntu server with only tiny amount of programs performs extremely well, my 5$ vps can download to me with 2MBps, so i dont think it is the case, they are on the same node
[19:15] <Daviey> jamespage: If it compiles, ship it
[19:20] <jamespage> Daviey, zul: https://code.launchpad.net/~james-page/ubuntu/oneiric/likewise-open/make-it-work/+merge/77390
[19:20] <jamespage> I'll let you fight over it :-)
[19:20] <zul> jamespage: beer me :)
[19:20] <jamespage> can't upload - not in the ubuntu-server packageset
[19:21] <zul> Daviey: can you take care of it so i can work on this nova bug i been working on?
[19:26] <Daviey> jamespage: Grrrrrr
[19:26] <Daviey> jamespage: I wish you were core-dev
[19:26] <Daviey> :)
[19:39] <Daviey> smoser: errr.
[19:39] <smoser> whats up?
[19:39] <Daviey> smoser: m1.small only has 2GB disks?
[19:40] <smoser> where do you see that?
[19:40] <Daviey> smoser: canonistakc
[19:40] <smoser> i think you're seeing bug 836759
[19:41] <Daviey> smoser: ah, thanks
[19:41] <smoser> i'm going to wipe all my images and start with new ones
[19:41] <smoser> to clear any cache issues on nodes
[19:42] <Daviey> sure
[19:42] <smoser> and, i guess in the process test how well the cache cleaning works to avoid a disk full :)
[19:45] <Daviey> :D
[19:45] <Daviey> adam_g: did you see https://bugs.launchpad.net/ubuntu/+source/cobbler-enlist/+bug/860492 ? happy days :)
[19:46] <adam_g> Daviey: neat
[19:48] <Daviey> adam_g: I assume you didn't read the recommendations then?
[19:48] <adam_g> Daviey: hah i just did
[19:49] <adam_g> Daviey: and seems reasonable.
[19:50] <adam_g> Daviey: when would the deadline for that be?
[19:50] <Daviey> reasonable yes.. frustrating also :)
[19:50] <Daviey> adam_g: august 11th
[19:51] <Daviey> :)
[19:51] <Daviey> As each day passes, harder and harder to justify.
[19:57] <Loopzle> Hello, I have setup a Ubuntu Server (10.10) on my old laptop. However, it seems to sleep if I leave it a while. How can I stop it from doing this?
[20:02] <genii-around> Loopzle: Maybe check your default settings in /etc/default/acpi-support
[20:04] <Loopzle> genii-around: /etc/default/acpi-support seems to be empty.
[20:05] <smoser> hallyn, i'm reproducibly hitting that cgroups issue
[20:05] <smoser> with nova lxc
[20:06] <genii-around> Loopzle: Does /etc/default/acpid exist?
[20:07] <Loopzle> genii-around: Yes.
[20:10] <genii-around> Loopzle: I would suggest to install acpi-support package, then tweak the /etc/default/acpi-support values for hibernate, sleep, and so on
[20:13] <hallyn> smoser: build a libvirt with my debdiff...
[20:13] <smoser> where?
[20:13] <Loopzle> genii-around: I have installed the package, Do I just comment out the lines "ACPI_SLEEP=true" and "ACPI_HIBERNATE=true" or change them to false?
[20:14] <hallyn> smoser: bottom of bug 842845.  i can push some .debs to pcc if you like
[20:14] <genii-around> Loopzle: Change them explicitly
[20:15] <smoser> hallyn i will try
[20:15] <Loopzle> genii-around: Okay, I will leave the server a while and see if it works. Thanks.
[20:16] <hallyn> smoser: http://people.canonical.com/~serge/nova-lxc-cgroup-race  has the debs
[20:16] <smoser> then why did you tell me to build one
[20:16] <smoser> :)
[20:17] <hallyn> smoser: i forgot i had them handy
[20:17] <smoser> pfooey
[20:17] <hallyn> and i was hoping to get you to look at the patch and comment :)
[20:17] <smoser> i'm on i386 at the moment.
[20:18] <hallyn> doh
[20:19] <genii-around> Loopzle: No prob. Keep us updated!
[20:22] <raubvogel> When you are setting up isc bind, how do you tell it to try the dns above it if it does not know the answer?
[20:22] <lynxman> smoser: ping
[20:23] <lynxman> smoser: silly question, but you sure know it :)
[20:23] <smoser> k
[20:24] <lynxman> smoser: I'm dealing with rabbitmq-server 2.6.1, so far up to 2.5.0 we had the daemon bg with & and then rabbitmqctl wait would wait for the listener to be up, so that helped control the up situation
[20:25] <lynxman> smoser: problem with 2.6.1 is that it expected the PID as well, which doesn't show up through pidof and it's quite hard to get, but then I'll always go okay which in restart can be a bit of a pain
[20:25] <lynxman> smoser: don't want to go sleep N since it's lame, so I thought you would have a better idea :)
[20:26] <smoser> "it expected the PID"
[20:26] <smoser> what expected the pid ?
[20:26] <smoser> and why doesnt it show up through pidof ?
[20:27] <lynxman> smoser: because we call the daemon who goes "erlang programname parameters" so it's not easy to trace
[20:27] <lynxman> smoser: the PID is not expected by the command "rabbitmqctl wait" where before it just went and looked at the socket
[20:28] <lynxman> smoser: if you install rabbitmq-server 2.5.0 (the oneiric one)
[20:28] <lynxman> smoser: you'll see the init.d file, I'm talking about
[20:42] <Daviey> jdstrand: Is this enough of a warning? http://pb.daviey.com/Hz6i/
[20:43] <jdstrand> Daviey: yeah, looks good
[20:46] <Daviey> jdstrand: the error checking, is that something you really want to see for O?
[20:47] <Daviey> Is it something that can be targeted post MIR?
[20:47] <jdstrand> Daviey: my review isn't done yet. ideally, yes, cause failure to allocate memory and continuing on can be an issue
[20:47] <jdstrand> I gotta run now though
[20:48] <Daviey> jdstrand: Would dropping the universe package pass this?
[20:48] <Daviey> jdstrand: I mean, allocating memory in a volatile enviroment that run for ~30 seconds, then system halts.
[20:49] <Daviey> jdstrand: ok
[20:59] <Loopzle> genii-around: I think sleep is disabled, thanks for that. :)
[21:00] <genii-around> Loopzle: You're welcome.
[21:14] <bookpage> can i use d3d on a virtualised ubuntu image with vnc?
[21:19] <Daviey> m_3: How did you get on?
[21:19] <Pici> bookpage: I don't understand the question.
[21:19] <m_3> Daviey: just about to ping you
[21:20] <DrNick__> i'd imagine he's asking if he can use direct3d over vnc on a virtualised image.  i'd say try it, nothing to loose, but I'd say unlikelt
[21:20] <m_3> so I think the answer is to revert two deps back to the 2.3.11 versions instead of the 2.3.14
[21:20] <DrNick__> * unlikely
[21:20] <m_3> I've never seen things work without all of those lib versions matching exactly
[21:22] <m_3> Daviey: I think it'll be necessary to rebuild the master ruby-rails-2.3 package to lock the deps too (no >=)
[21:24] <savid> So, it appears my mysql client was built with EditLine.   Is there any easy way to restore readline functionality?
[21:25] <savid> This is ubuntu 9.10
[21:28] <m_3> Daviey: I take that back... no need to rebuild the ruby-rails-2.3 base package,
[21:28] <m_3> just pull ruby-activesupport-2.3 and ruby-activeresource-2.3 back to 2.3.11
[21:32] <Daviey> m_3: pull them back?
[21:32] <Daviey> m_3: ahhhhhhh
[21:33] <Daviey> m_3: rails is 2.3.14.1
[21:33] <Daviey> m_3: How viable is it to push forward?
[21:34] <m_3> yikes, but ruby-rails-2.3 is 2.3.11
[21:34] <m_3> rails-2.3.14.1 looks like a wrapper
[21:35] <Daviey> m_3: ruby-rails-2.3 is worse than that...
[21:35] <m_3> Daviey: how much time do we have?
[21:36] <Daviey> m_3: source package is 2.3.14-3, but it failed to build
[21:36] <m_3> quicker to revert if possible... can push other libs forward, but it might take a bit
[21:36] <Daviey> m_3: reverting is hard, we have to butcher the version to appear to be higher
[21:36] <m_3> I get rails-2.3.14.1 source
[21:36] <Daviey> It's really quite ugly.
[21:36] <m_3> ah, I gotcha
[21:37] <m_3> ok, lemme look at what's changed between 2.3.11 and 2.3.14 for the other libs
[21:38] <Daviey> m_3: ruby-rails-2.3 failed to build because:
[21:38] <Daviey>  ruby-actionpack-2.3 : Depends: ruby-activesupport-2.3 (< 2.3.11.1) but 2.3.14-2 is to be installed
[21:38] <Daviey>  ruby-activerecord-2.3 : Depends: ruby-activesupport-2.3 (< 2.3.11.1) but 2.3.14-2 is to be installed
[21:38] <Daviey> so if ruby-activesupport-2.3 is upgraded, we might be ok
[21:38] <m_3> how are you getting 2.3.14.3 source for ruby-rails-2.3
[21:38] <m_3> I'm getting 2.3.11
[21:39] <m_3> (I'm just doing an apt-get source ruby-rails-2.3)
[21:39] <Daviey> $ rmadison ruby-rails-2.3
[21:39] <Daviey> ruby-rails-2.3 |   2.3.11-1 | oneiric/universe | all
[21:39] <Daviey> ruby-rails-2.3 |   2.3.14-2 | oneiric/universe | source
[21:39] <m_3> (sorry, relative noob at packaging)
[21:40] <Daviey> m_3: pull-lp-source ruby-rails-2.3 , is what the cool kids use.
[21:40] <Daviey> or the super cool kids, bzr branch lp:ubuntu/ruby-rails-2.3
[21:41] <m_3> cool.. when do you need this done?
[21:43] <SpamapS> Daviey: super duper cool kids use bzr branch ubuntu:ruby-rails-2.3
[21:43] <m_3> I won't even mention the level of coolness that uses 'git bzr clone ubuntu:ruby-rails-2.3'
[21:45] <m_3> damn... debuild isn't gonna work with that huh
[21:45] <Daviey> SpamapS: I'm not than cool, probably never will be :)
[21:45] <Daviey> m_3: Really soon. :)
[21:46] <Daviey> m_3: "bzr bd -S" ~= debuild -S
[21:55] <Daviey> negronjl: Your keystone change, are you sure it doesn't need a database migration for upgrades?
[21:56] <negronjl> Daviey, it shouldn't need it.. the changes make the FKs more flexible and would work on both MyISAM as well as InnoDB
[21:57] <Daviey> negronjl: sure changing Integer -> String isn't a big deal?
[21:57] <Daviey> not for fresh installs, just upgrades
[21:59] <negronjl> Daviey, furthermore, it makes more sense to use same type of fields when doing FKs.  The type ( Integer or String ) is up for debate.  The current package that we have could go either way.  If/when we pull again from upstream, that decision can be made there.  At that point, some sort of sanity check should be done on the DB to accommodate for any changes in field types
[22:00] <lynxman> negronjl: don't think there's much debate, one is varchar because it might accept UUIDs so... varchar it is
[22:00] <Daviey> negronjl: Oh, i don't disagree that this looks like a worthy fix - what concerns me, is that i don't know how this is handled for people already witha  keystone database
[22:01] <negronjl> Daviey, lynxman: I agree with lynxman on the varchar/integer.  Furthermore, the existing databases would not be affected in creation.  keystone would not try to create tables as it checks before and, the conversion between integer/varchar should be transparent via sqlalchemy
[22:01] <lynxman> Daviey: don't think it does affect anyone really :)
[22:03] <Daviey> Hmm
[22:04] <Daviey> negronjl: I assume you tried it?
[22:04] <Daviey> and upgrade, i mean
[22:05] <negronjl> Daviey, I really can't try it because keystone will not properly work with InnoDB ( hence the change ).  I can ( and am in the process of ) manually test adding data to the tables in both integer and string and test the conversion .
[22:06] <Daviey> negronjl: you are a rock star
[22:07] <lynxman> Daviey: he is
[22:09] <negronjl> Daviey, changing from integer to varchar is handled as integers can be saved as varchar (Strings).
[22:10] <Daviey> negronjl: so we are dandy?
[22:10] <negronjl> Daviey, we are
[22:10] <kirkland> mtaylor: ping
[22:11] <kirkland> mtaylor: minor fix to keystone packaging in lp:~kirkland/keystone/copyright-fixes
[22:11] <kirkland> mtaylor: could you please merge that into lp:~openstack-ubuntu-packagers/keystone ?
[22:11] <Daviey> negronjl: thanks
[22:11] <negronjl> Daviey, no worries.
[22:12]  * Daviey throws kirkland  lp:~ubuntu-server-dev/keystone/diablo .
[22:14] <bookpage> Pici: DrNick__ was right, that's what I wanted to do. I did try it, but I ran into issues related to having no $DISPLAY :/
[22:16] <kirkland> Daviey: can i push there?
[22:22] <kirkland> Daviey: thanks!  pushed
[22:22] <Daviey> cool
[22:24] <Daviey> kirkland / negronjl / lynxman / iamfuzztoo: Is bug 843058 going to cause woe?
[22:24] <negronjl> Daviey, checking now....
[22:26] <negronjl> Daviey, it may for us this late in the game.
[22:26] <lynxman> definitely late
[22:27] <negronjl> Daviey, the request is not a bad one but, the implementation may end up breaking things that could heavily affect our current openstack deployment ( what we are currently working on our sprint now )
[22:29] <Daviey> negronjl: yeah, it's not clear to me if keystone supports EC2 based on that bug. :/
[22:29] <Daviey> There is some support, but NFI how good it is. :/
[22:31] <negronjl> Daviey, from what little information is available, it isn't
[22:32] <lynxman> Daviey: support is limited to "someone actually wanting to support the API"
[22:32] <lynxman> Daviey: so by default no
[22:33] <Daviey> :'(
[22:36] <lynxman> Daviey: yeah, sad face too
[23:01] <m_3> Daviey: I'm gonna step away for food... I'll shoot to have you branches in a few hours.  I'm not seeing anything in the way atm
[23:03] <blaenk> hey guys, I'm on 9.10 server and it has vim 7.2, wondering how I can upgrade to 7.3, or should I just install from source?
[23:10] <TheEvilPhoenix> !9.10
[23:11] <TheEvilPhoenix> blaenk:  i assume upgrading isnt an option?
[23:11] <blaenk> TheEvilPhoenix: not at the moment unfortunately, but hopefully soon
[23:12] <TheEvilPhoenix> well 9.10 is end of life already
[23:12] <TheEvilPhoenix> so...
[23:13] <blaenk> so I guess I'll install from sources
[23:14] <TheEvilPhoenix> well vim is 7.3 in natty
[23:14] <TheEvilPhoenix> but not before
[23:14] <TheEvilPhoenix> so if you *absolutely* need 7.3, sources
[23:35] <soren> smoser: Sorry, which chown?
[23:35] <smoser> in nova-common postinst
[23:35] <smoser> we do a chonw -R nova:nova /var/lib/nova/
[23:36] <smoser> that is going to change perms on files that libvirt had modified to it and possibly other things.
[23:36] <soren> smoser: Ah.
[23:37] <soren> smoser: I thought it only did that for fresh installs.
[23:37] <smoser> i supposed that that was the intent.
[23:38] <smoser> it turns out that we're in the position where we really *should* do some chowning on upgrade now, to fix old perms that were in place.
[23:43] <pukeko_> Hi all - i'm installing a JEOS base image for VM guests, in the software selection window, what does the Basic Ubuntu Server option refer to ?
[23:44] <pukeko_> if i elect to leave that out how much smaller will the img be ?