[00:55] <golem_> i've installed xubuntu-desktop and i'm having a devil of a time figuring out how to remote desktop
[00:55] <golem_> i've got a monitor attached
[00:56] <golem_> vnc4server griefing me
[01:00] <LisaR> Is there a way to run a mail server using a user id rahter then root?
[01:01] <LisaR> On Fedora, ran ok, but ubuntu, I get a bind error using the user id.
[01:01] <LisaR> running in root, it's ok, but now all logs and such come up root
[01:02] <Jagged> Perhaps run in in a chroot jail?
[01:03] <LisaR> ok, let me check, I've been using fedora for years, ubuntu for a few weeks, so I'm not too famil with the ubuntu ways.
[01:16] <Jagged> I'm not saying its the "ubuntu way", its just a way to isolate the server since you were concerned about running it as root.
[01:20] <LisaR> I realize, just many things I haven't used before such as sudo, update-rc.d vs chkconfig, so on.
[01:32] <golem_> nevermind, i figured out vnc. not even on topic here
[02:31] <brohism> So I made some changes to my server's network interfaces today, and now services aren't accessible outside the local network despite my having returned settings to their original state when things were working
[02:31] <brohism> My server is behind a router, with port forwarding
[02:32] <brohism> ping is very unresponsive, and seems to hang even when I try to terminate it with ctrl+c
[02:45] <giovani> `
[08:41] <kwork> mount.nfs: mount system call failed
[08:41] <kwork> any ideas how to debug it ?
[09:47] <S0ckPants> hi all
[09:47] <S0ckPants> i'm trying to configure an nfs server
[09:47] <S0ckPants> so far i've edited /etc/exports and /etc/hosts.allow, but i still can't seem to connect
[09:49] <S0ckPants> here's those two files, and at the bottom what happens when i try to connect (from my mac): http://sockpants.pastebay.org/58128
[09:51] <S0ckPants> (btw i saw a typo in the ip address, but i fixed that and it had no effect)
[10:33] <ghostlines> I have a vm running on kvm, i can only access it by typing in it's IP for some reason I can't access it by it's hostname
[10:33] <ghostlines> anyone have any idea's why this is?
[10:37] <_ruben> hostnames depend on some form of dns being operational
[10:55] <SockPants> hi all
[10:55] <SockPants> i'm trying to get permissions right while configuring my server this time
[10:55] <SockPants> i've managed to set up nfs so i can access it from my laptop (and only my laptop)
[10:55] <SockPants> now i want to be able to edit /etc/apache2/httpd.conf from there
[10:56] <SockPants> i can open it, but my editor says i cannot unlock the file whenever i try to type in it, unless i chmod it 666 on the server. how can i set the permissions so that not -everyone- can write it, but i still can edit it from my laptop
[11:33] <ara> hello ubuntu-server people!!
[11:33] <ara> new server ISOs in need of love have been just published
[11:33] <ara>  i386: http://iso.qa.ubuntu.com/qatracker/test/3137
[11:33] <ara>  amd64: http://iso.qa.ubuntu.com/qatracker/test/3136
[11:33] <ara>  please, help us testing the ISOs
[11:35] <VK7HSE> ara: downloading now! ;)
[11:35] <ara> VK7HSE, nice :)
[11:58] <ttx> mdz, kirkland: problem in 20090930.1 with -0ubuntu13, bug 439288
[11:59] <ttx> Can't seem to workaround it
[11:59] <ttx> I'll test 20090930 (with -0ubuntu12) and document workaround
[12:00] <ttx> ara: we might go back to 20090930 for the server ISO.
[12:00]  * ttx lunches and will test that option in a few
[12:22] <kirkland> ttx: but registration worke?
[12:22] <kirkland> ttx: worked?
[12:23] <ttx> kirkland: it appears to work in the logs
[12:23] <ttx> kirkland: but apparently that's not sufficient :/
[12:24] <ttx> kirkland: 1/ you need to restart eucalyptus to make it aware of that registration
[12:25] <ttx> kirkland: 2/ for some reason the node believes walrus is running locally to the nc
[12:25] <ttx> kirkland: I tries reregistering and all kind of things with no success
[12:26] <ttx> kirkland: at that point I'll test 20090930 + manual registration and if that works, make 20090930 the beta candidate
[12:26] <ttx> at least I think I know how to make that one work
[12:26] <ttx> the issue being a full UEC test cycle takes a couple hours
[12:28] <kirkland> ttx: arg, okay
[12:28] <kirkland> ttx: i swear, i spent 16 hours on this yesterday
[12:28] <kirkland> ttx: i'm going for run, back in an hour
[12:29] <ttx> kirkland: we should do a LP group for moral support
[12:29] <ttx> ~eucalyptus-victims
[12:31] <VK7HSE> should i stop the current iso's then ???
[12:32] <ttx> VK7HSE: yes :(
[12:32] <VK7HSE> ttx ok!
[12:33] <VK7HSE> silly me deleted previous ones! so I was having to start afresh (DOH)
[12:33] <ttx> you can rsync back to it :)
[12:34] <VK7HSE> true, so the iso I was getting was both i386/amd64 for 20090930.1   will there be another build in the next day or so?
[12:34]  * VK7HSE I assume yes!
[12:35] <ttx> VK7HSE: my idea is to go back to 20090930
[12:35] <ttx> if I can make it work
[12:35] <VK7HSE> o I don't have that iso! on this system due to fresh karmic desktop install (my fail!)
[12:36] <ttx> VK7HSE: if you have 20090930.1, you can rsync 20090930 on it
[12:37] <ttx> rsync -tzhhP rsync://cdimage.ubuntu.com/cdimage/ubuntu-server/daily/20090930/karmic-server-amd64.iso .
[12:37] <ttx> in the directory where you have karmic-server-amd64.iso from 20090930.1.
[12:37] <VK7HSE> ok!... tnx
[12:38] <ttx> VK7HSE: note that the test tracker is still pointing to 20090930.1, so if you test, just keep the results for yourself now, and enter them later
[12:38] <ttx> (if we indeed go back to 20090930)
[12:38] <VK7HSE> yep understood!
[12:39] <VK7HSE> FTW the 2 servers I run here are doing well on Alpha6 (updates) ;)
[12:39] <zul> morning
[12:39] <ttx> zul: morn
[12:59] <alexm> ttx: i was trying this server iso and found a problem booting jeos on kvm after install
[13:00] <alexm> should i report it as a bug or it's better for me to wait iso rollback to previous one?
[13:00] <alexm> ara: ^^
[13:00] <ttx> alexm: If you wait 20 more minutes i'll be able to say which on e is the beta candidate :)
[13:00] <zul> which iso should i be testing?
[13:00] <ttx> zul: test the EC2 images
[13:01] <ttx> those won't move :)
[13:01] <zul> k
[13:01] <alexm> ttx: okay, but i'm leaving right now, i'll catch up with you later
[13:01] <ttx> alexm:  ok
[13:01] <alexm> thanks
[13:08] <ttx> looks like this one is working...
[13:11] <ttx> hmm. no
[13:12] <ttx> aw, come on...
[13:17] <unimatrix> how do i limit bandwidth speed to every client except some exceptions?
[13:24] <ttx> bah
[13:35] <ttx> ok, we are back at testing 20090930
[13:37] <ttx> I can get that one to run instances, minor some k,nown caveats
[13:40] <unimatrix> where can i get some help with /sbin/tc ?
[13:40] <zul> ttx: yay!
[13:41] <ttx> hmmm, yay.
[13:46] <mdz> ttx, kirkland, I guess we're at a point where we should be looking for workarounds to document rather than solutions, as we need to move ahead with testing
[13:46] <ttx> mdz: yes, see my very recent email
[13:46] <mdz> if we have to add one or two additional manual steps, that's what we'll have to do
[13:46] <error404notfound> i keep getting [alert] (40)Too many levels of symbolic links: Can't chdir to /var/www and then apache terminates when i followed http://www.howtoforge.com/chrooting-apache2-mod-chroot-debian-etch to implemented chrootdir
[13:47] <mdz> ttx, I'm still at the QBR and not able ot keep up with mail or IRC, so just checking in
[13:47] <ttx> mdz: we are reverting the candidate to 20090930
[13:47] <ttx> which works with manual registration
[13:47] <ttx> or rather "can work"
[13:47] <mdz> ttx, do you know what broke in 20090930.1?
[13:48] <ttx> mdz: Not exactly, see bug 439288
[13:48] <ttx> everything registers correctly (as far as the logs tell)
[13:48] <ttx> but then the NC seems blocked on downloading stuff from 127.0.0.1
[13:49] <ttx> mdz: eucalyptus is very very sensitive, touch it there, it will break somewhere else. And its difficult to reveal flaws without a complete install + instance run
[13:51] <ttx> mdz: so yes, let's work from a known half-broken-with-workarounds state
[13:52] <smoser> ttx, so 20090929 had issues ?
[13:52] <ttx> mdz: to debug the registration, we need multiple people doing full cluster+node+instancerun tests
[13:53] <ttx> smoser: I had a kernel boot issue, trying UEC beta candidate + local kernel, local ramdisk
[13:53] <ttx> I have yet to try UEC beta candidate + kernel/ramdisk you provide
[13:54] <smoser> hm... well there absolutely shouldn't be any difference in the kernels
[13:54] <smoser> the initramdisk i guess its possible, but i wouldn't have thought so
[13:54] <smoser> so was there something wrong with the 20090929 ? or did you just pick 0930 because its newer ?
[13:55] <smoser> just wondering because i think it'd be nicer if ec2/uec were the same, but not terribly a big deal.
[13:55] <ttx> no, 20090929 is the candidate on the UEC side
[13:55] <ttx> 20090930 is the candidate on the servre ISO side
[13:55] <smoser> oh. i see. so ara referred to iso
[13:56] <smoser> sorry for confusion
[13:56] <ttx> smoser: apparently it can't find the ramdisk in my test
[13:56] <error404notfound> anyone?
[13:57] <smoser> can't find ramdisk or cant find rootfs
[13:57] <ara> cjwatson, migration didn't turn out that well: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/439306
[13:57] <ara> cjwatson, sorry wrong channel
[13:57] <cjwatson> ara: ->evand anyway :)
[13:57]  * cjwatson doesn't really do m-a
[13:58] <ttx> everyone, we are testing the 20090930 server ISO, which doesn't appear on the test tracker yet
[13:59] <smoser> error404notfound, i have to guess that your /var/www is a symlink that causes recursive symlink. at least somewhere down there it is.
[13:59] <ttx> smoser: is there a way to tell which eri an emi is using ?
[13:59] <smoser> $ mkdir /tmp/aa && ln -s ../aa /tmp/aa && find /tmp/aa -L
[13:59] <smoser> describe-images should output it
[14:00] <ttx> ah
[14:00] <smoser> and then you can download it also . download-bundle
[14:00] <ttx> smoser: http://pastebin.ubuntu.com/282153/
[14:01] <ttx> smoser: doesn't show the link between emi and eri/eki
[14:01] <error404notfound> smoser, according to that tutorial provided in my last message, my directory tree is: http://pastebin.com/m7b5aef8d
[14:05] <smoser> ttx, when you bundle'd the image, you have to specify the kernel, or you dont get one
[14:05] <smoser> ttx, hold on, checking somthing
[14:05] <ttx> smoser: I /did/that
[14:05] <ttx> I think.
[14:06] <smoser> ttx: http://pastebin.ubuntu.com/282159/
[14:06] <smoser> bug in euca2ools
[14:07] <ttx> smoser: well, maybe not, maybe I failed when I registered them
[14:07] <smoser> ttx, its a bad paste (first ec2 line is 2 lines)
[14:09] <smoser> http://pastebin.ubuntu.com/282160/
[14:09] <smoser> ttx, no.
[14:09] <ttx> smoser: file it while its not moving too much
[14:09] <smoser> the snippet in my output is from euca2ools looking at ec2
[14:10] <smoser> so i know the issue is with euca2ools.
[14:12] <ttx> ah
[14:12] <ttx> I ran --ramdisk $EKI apparently
[14:13] <ttx> hmm, I did not
[14:14] <ttx> I guess $ERI was wrong then
[14:15] <smoser> ttx. no. they dont show it. its a bug in euca2ools
[14:15] <jdstrand> ttx: I noticed in #ubuntu-meeting that 20090930.1 should maybe be invalidated on server. does that mean I should test 20090930?
[14:15] <smoser> http://paste.ubuntu.com/282167/ demonstrates that more.
[14:15] <ttx> jdstrand: yes. Its been removed from the tracker
[14:15] <smoser> i can open a bug if you'd like
[14:15] <ttx> jdstrand: and now current points to 20090930
[14:16] <jdstrand> ttx: ok, thanks
[14:16] <ttx> jdstrand: pitti is struggling to put 20090930 on the tracker
[14:16] <jdstrand> http://iso.qa.ubuntu.com/qatracker/info/3126 seems to still be around
[14:16] <jdstrand> though, I haven't tried to grab the iso yet
[14:17] <jdstrand> the iso is there...
[14:17] <ttx> smoser: cannot hurt
[14:17] <smoser> ttx, maybe there is some other way you can list it in euca
[14:17] <jdstrand> ttx: and btw, you can disregard my euco/dhcpd3/apparmor question from yesterday. apparently I fixed it already ;)
[14:18] <ttx> jdstrand: cool, one less issue to think about :)
[14:18] <smoser> one way is (hopefully) to use ec2tools and point them at your uec
[14:18] <ttx> jdstrand: yes, but it doesn't show up in the test list ?
[14:19] <jdstrand> ttx: I'm just looking at the email I got and things seem ok there
[14:20] <jdstrand> (so far)
[14:20] <zul> so 20090929?
[14:20] <ttx> server ISO = 20090930
[14:20] <jdstrand> I thought we said 20090930
[14:20] <zul> k
[14:21] <ttx> UEC/EC2 = 20090929
[14:21]  * zul go test the server iso
[14:21] <jdstrand> this is somewhat confusing, but I know what I am supposed to do... :P
[14:21] <zul> riiight ;)
[14:23] <jdstrand> ttx: I see what you mean now-- the http://iso.qa.ubuntu.com/qatracker/build/ubuntuserver reports don't list 20090930
[14:26] <smoser> bug 439366
[14:36] <ttx> smoser: get-console-output booting UEC image candidate with kernel/ramdisk from uec-images.ubuntu.com
[14:36] <ttx> http://pastebin.ubuntu.com/282176/
[14:38]  * ttx checks that it works with the ones taken directly from the cluster node
[14:38] <smoser> ttx, could you point me at an initrd that works for you?
[14:39] <ttx> smoser: I'm testing that right now
[14:39] <ttx> rebundling...
[14:39] <ttx> smoser: could you run the "EC2 rebundle test" for the UEC images ?
[14:39] <smoser> on uec? or can i run it on ec2
[14:40] <ttx> smoser: see "Image run on EC2" at the bottom of http://testcases.qa.ubuntu.com/System/CloudImages
[14:40] <ttx> That's the "Install (EC2 Single Instance)" test for UEC images
[14:41] <smoser> yeah, no problem
[14:41] <smoser> i can do that.
[14:42] <ttx> zul: could you test the europe AMIs ?
[14:42] <zul> am i missing 20090930 server iso doesnt seem to be on the tracker
[14:42] <zul> ttx: already tested
[14:42] <ttx> you know Quebec is almost part of the UE
[14:42] <ttx> ah cool
[14:42] <zul> ttx: wha quebec?
[14:43] <ttx> zul: :-)
[14:43] <zul> ttx: i know euca might be frying your brain but are you on crack? ;)
[14:47] <gamla_kossan> how come the new release of ubuntu will ditch pidgin in favor of empathy?
[14:47] <gamla_kossan> anyone have a clue?
[14:47] <Pici> gamla_kossan: This channel is more for server issues.  #ubuntu+1 might be a better place to discuss that.
[14:48] <gamla_kossan> right
[14:48] <gamla_kossan> just htought anyone in here might have a clue
[14:48] <gamla_kossan> =)
[14:51] <VK7HSE> is anyone having any issue with "Abort pclzip.lib.php : Missing zlib extensions"  zlib1g is installed but not working any ideas ????
[14:52] <VK7HSE> !info zlib1g
[14:52] <zul> VK7HSE: please open a bug report with a sample code so it can be reproduced please
[14:53] <VK7HSE> ok, its affecting my WordPress currently :(  (WP is installed from source!)
[14:55] <ttx> ok everyone, we have a 20090930.2 (which is the same as 20090930) on the tracker now.
[14:55] <ttx> any test you ran on 20090930 can be reported here. Just doublecheck you have the right md5sum
[14:55] <ttx> amd64: fe689dd00226614e6da55d69928b1951
[14:56] <ttx> i386: 	bde35e2c4ff8d238c6562eb7fb55735e
[15:01] <VK7HSE> are there any predefined tests for zlib1g ?
[15:03] <twb> VK7HSE: testing it for what?
[15:05] <VK7HSE> I just want to get some verbose output for zlib is all ... I'm having an issue where WordPress (installed from source) is claiming that zlib extentions aren't installed/enabled
[15:05] <twb> Probably you need to install a PHP-zlib bridge.
[15:06] <twb> Not that I would recommend using either WordPress or PHP...
[15:06] <error404notfound> i read that to secure my web deployments, every web application should run under its own vm and tools, how can i do this? do i need xen-vms? chroot+debootstrap based ubuntu installs?
[15:07] <twb> error404notfound: the recommended virtualization technology for Ubuntu is KVM.
[15:07] <VK7HSE> twb ok well I'll do my best to get something that hopefully will be usable!
[15:08] <error404notfound> twb, yes, but is that the solution for running multiple web application, each in its own sandbox?
[15:08] <ttx> \o/ instance run !
[15:08] <twb> error404notfound: virtualization is a means for running ARBITRARY software in separate sandboxes.  I do not see why web applications would be any different.
[15:09] <twb> error404notfound: however, I caution you not to believe everything you read.
[15:09] <error404notfound> twb, hmm, and why not? :P
[15:09] <twb> error404notfound: because people can lie
[15:09] <error404notfound> twb, whats your opinion over this?
[15:10] <twb> I would prefer to secure web apps by not running them in the first place.
[15:10] <error404notfound> twb, thats a great idea. :D
[15:10] <twb> But if you simply have to have your crappy NIH'd NeWS infrastructure, running each app in a separate VM is probably a good rule of thumb.
[15:11] <VK7HSE> twb: Hmm... I fail to see your logic! if all is insecure? why bother? or enlighten me to your reasoning... ;)
[15:12] <twb> VK7HSE: "security" is not a binary property.
[15:12] <twb> For example, your server is more secure (against some attacks) if it is surrounded by armed guards, than if it is not.
[15:13] <VK7HSE> right! :-/  anyway you have your reasons I respect that! ;)
[15:13] <ttx> smoser: so I have a ramdisk that works
[15:13] <twb> If you don't run a service, that service can't be attacked.
[15:13] <ttx> smoser: /boot/initrd.img-2.6.31-11-generic from the server install itself
[15:14] <VK7HSE> twb: but there has to be a compromise between Fort Knox to say the play park!  anyway I now see what you meant! ;)
[15:15] <smoser> can you just put that somewhere ?
[15:15] <smoser> theres no reason to mismatch
[15:16] <ttx> smoser: uploading
[15:16] <smoser> just being careful because i didn't do anything (*anything*) special to create the initrd. i just pulled it from the image where it was created by insall of -virtual (hm.... maybe thats it)
[15:16] <smoser> you probably used -server
[15:17] <twb> A VM's ramdisk won't necessarily be appropriate for general-purpose use.
[15:17] <jdstrand> ttx: 20090930.2 just floated in. is this what I should be using now?
[15:17] <ttx> its the same as 20090930
[15:17] <twb> (Dunno if I'm following the conversation aright.)
[15:17] <ttx> just a hack since the tracker wouldn't allow going back
[15:17] <jdstrand> ttx: ok cool
[15:19] <ttx> smoser: uploading
[15:21] <smoser> twb, well, its almost the other way around.
[15:21] <smoser> when doing vmbuilder builds of the ubuntu uec images, i installed the -virtual package and collect its generated initramdisk
[15:22] <smoser> when ttx uses that ramdisk, he fails to boot in kvm.
[15:22] <smoser> when he uses his from /boot on his server system, it works.
[15:29] <ttx> smoser: http://people.canonical.com/~ttx/initrd.img-2.6.31-11-generic
[15:32] <smoser> thanks. i'll look at differences.
[15:35] <smoser> ttx, stupid question, but that is i386 right
[15:36] <ttx> no, amd64
[15:36] <ttx> smoser: ^
[15:37] <smoser> k
[15:45] <ttx> kirkland: please also see bug 439251, if you want to dig into autoregistration further
[15:49] <VK7HSE> Bug #439407
[16:01] <ttx> smoser: filed bug 439415
[16:07] <twb> smoser: well, KVM emulates an entire system, not just presenting a vserver/xen-style specialized environment to the kernel.
[16:07] <twb> smoser: so maybe -virtual is not meant for kvm?  I don't know.
[16:08] <smoser> -virtual is intended for kvm. so its a bug we need to fix.
[16:09] <kirkland> ttx: does a .1 iso exist anywhere?
[16:09] <kirkland> ttx: i really want to start my testing based on 13
[16:09] <ttx> ask on release if there is a way to retrieve it
[16:10] <ttx> I have one copy but uploading it with my 10k/s should take approximately 1 week
[16:10] <kirkland> ttx: are you still trying to fix registration too?
[16:10] <ttx> kirkland: no. I'm trying to document known issues
[16:11] <ttx> kirkland: saw mdz's last email ?
[16:11] <ttx> kirkland: I'm trying to translate my experience into filed bugs and test reports
[16:11] <ttx> (on iso.qa.u.c)
[16:12] <ttx> kirkland: there are still plenty of testing to do to make sure we identified all the known issues
[16:17] <ara> ttx, is it worth it to test .2?
[16:17] <ttx> yes, that should be the final
[16:18] <ara> ttx, ok, thanks
[16:19] <smoser> ttx, finished the rebundle test.
[16:20] <smoser> ttx, i'm going to work now on getting the ec2 image into its beta resting place (rather than canonical-testing).
[16:20] <smoser> you are not aware of any thing that would stop our use of the current published amis, right?
[16:20] <smoser> the bug you just opened is all i see, and wouldnt' think it blocks beta
[16:27] <ttx> AMIs are ok
[16:27] <ttx> smoser: its the rtamdisk I'm concerned about
[16:28] <ttx> smoser: if bug 439415 can't be fixed, I think we should pull them
[16:28] <smoser> :-(
[16:29] <ttx> smoser: did you record the result of your rebundling test on the tracker ?
[16:29] <smoser> i think so
[16:29] <ttx> smoser: doesn't appear
[16:29] <ttx> http://iso.qa.ubuntu.com/qatracker/result/3135/359
[16:29] <ttx> http://iso.qa.ubuntu.com/qatracker/result/3134/358
[16:30] <ttx> ah, it's the wrong test you filed
[16:30] <ttx> look at "Install (EC2 Single Instance)"
[16:32] <smoser> i'm consued
[16:32] <smoser> that single test page that lists all the tests is the source of my confusion
[16:32] <smoser> (http://testcases.qa.ubuntu.com/System/CloudImages)
[16:32] <smoser> at that above url, i did: "Image run on EC2"
[16:34] <smoser> ttx, bug 439415 certainly "can't be fixed" in without re-spinning images.  it is possible that it is only vmbuilder changes that could solve it, but even then you'd have to assume that the changes you made to the image so that the initramfs got fixed did not affect other things
[16:35] <ttx> I'm fine with respinning the UEC candidates... if we are sure it fixes the issue
[16:36] <ara> hey zul_, thanks for helping testing the ISO images!
[16:36] <ttx> kirkland: is my last email to -devel reasonable to you ?
[16:36] <zul_> ara: no problem
[16:36] <smoser> ttx, so you're saying in that case, you'd respin UEC candiates, but not ec2
[16:36] <smoser> right?
[16:37] <ttx> hmmmm
[16:37] <kirkland> ttx: looking
[16:37] <ttx> We could respin EC2... the thing is I'm not comfortable with respinning now. Especially with the amount of testing left todo
[16:37] <ttx> and if you're away part of tomorrow...
[16:37] <ttx> that sonds like a bad idea
[16:38] <ttx> I have yet to tset UEC on i386
[16:38] <kirkland> ttx: your email is reasonable
[16:38] <ttx> which should take me the rest of today and tomorrow morning
[16:38] <kirkland> ttx: i don't know that we can rely on mdz to see your note and make a decision in time, though
[16:38] <ttx> kirkland: ok, mdz might disagree though, so watch that space
[16:38] <ttx> I pinged him on IRC, fwiw
[16:38] <kirkland> ttx: it's likely you'll just need to make the call
[16:39] <ttx> tomorrow morning, I will.
[16:39] <kirkland> ttx: dan is going to dial into my system and we'll debug it
[16:39] <ttx> (if nobody else made it before me)
[16:39] <kirkland> ttx: sounds like keybuk might help fix our upstart scripts too
[16:39] <ttx> kirkland: hopefully you'll reproduce it, otherwise you'll really hate me for the whole thing :)
[16:40] <mathiaz> kirkland: ttx: good morning!
[16:40] <ttx> I so wanted it to work, I tried, I promise :)
[16:40] <smoser> ttx, my away tomorrow shouldn't really affect things. i'll be back by noon eastern. we've not been releasing till ~ 5:00 pm eastern. if there everything is ok, 5 hours is plenty of time to get things together.
[16:40] <ttx> mathiaz: ready to test 20090930.2 ?
[16:40] <mathiaz> ttx: only at .2?
[16:40] <ttx> its badly needing your magic test coiverage
[16:40] <ttx> mathiaz: yes, I've been slacking, sorry
[16:40] <mathiaz> ttx: I was expecting at least .42!
[16:41] <mathiaz> ttx: my test magic won't cover eucalyptus though
[16:41] <ttx> mathiaz: I take care of that. amd64 done, i386 tomorrow
[16:42] <ttx> smoser: you didn't check the right box on UEC image testing
[16:42] <ttx> smoser: its the "UEC / Install EC2 Single Instance" that you should have checked
 http://iso.qa.ubuntu.com/qatracker/result/3135/359
 http://iso.qa.ubuntu.com/qatracker/result/3134/358
[16:44] <mathiaz> ttx: what has changed between 20090930 and 20090930.2?
[16:44] <ttx> nothing. It's the same ISO
[16:44] <ttx> same md5sum
[16:44] <ttx> copy
[16:44] <mathiaz> ttx: ah
[16:44] <ttx> you can copy your test results
[16:44] <mathiaz> ttx: now that explains why rsync was so fast
[16:45] <ttx> :)
[16:45] <mathiaz> ttx: ok - amd64 is done then
[16:45] <ttx> kirkland: i'll go into more details in bug 439288, hopefully that will help
[16:47] <mathiaz> kirkland: bug 438602 - Fixed?
[16:47] <smoser> ttx, are you opposed to me changing the header in the wiki doc at http://testcases.qa.ubuntu.com/System/CloudImages such that it corresponds to the name of the test ?
[16:48] <smoser> s/corresponds to/is the same as/
[16:48] <ttx> no
[16:49] <kirkland> mathiaz: yes, i believe it's fixed, but it breaks something else
[16:49] <kirkland> mathiaz: in ttx's testing, he wasn't able to get instances to run
[16:49] <marshall> how do i check the time on my server from the terminal?
[16:49] <mathiaz> kirkland: so it wasn't a problem with upstart?
[16:49] <kirkland> mathiaz: however, in that patch, eucalyptus proclaims in the logs that all 3 components were successfully registered
[16:49] <ttx> mathiaz: there probably still is an issue in upstart
[16:49] <kirkland> mathiaz: well, there are likely upstart problems, too
[16:50] <kirkland> mathiaz: for one thing, i'm confused why all 3 registrations try to happen simultaneously
[16:50] <mathiaz> kirkland: walrus and cc should be happening at the same time
[16:50] <kirkland> mathiaz: you can ps -ef | grep wget and see that all three are looking for the service running, at the same time
[16:50] <mathiaz> kirkland: sc should follow cc though
[16:51] <mathiaz> kirkland: right - I saw something similar when purging the packages
[16:51] <mathiaz> kirkland: it takes 5 minutes to purge the eucalyptus* package
[16:51] <kirkland> mathiaz: hmm, really?  i haven't seen that...
[16:51] <mathiaz> kirkland: eucalyptus-common purging blocks for a long time
[16:52] <Keizer> All Ubuntu server editions have PAE?
[16:52] <Keizer> I thought PAE shows up when you type uname -a
[16:53] <skrite> lo there all
[16:54] <ttx> kirkland: btw, to fully fix autoregistration you also need to fix bug 439251, which is tricky as well
[16:54] <ttx> one of the reasons I let it go
[16:55] <ttx> kirkland: added some comments to bug 439288
[16:55] <kirkland> ttx: i just got my cloud running the .2 iso now
[16:55] <ttx> kirkland: instances running ?
[16:55] <kirkland> ttx: haven't tried yet
[16:55] <kirkland> ttx: i'm waiting for dan
[16:55] <ttx> ah .2
[16:55] <ttx> not .1
[16:55] <kirkland> ttx: we're going to take it from here
[16:56] <kirkland> ttx: i can't get ahold of a .1 iso
[16:56] <Keizer> Man I got an ubuntu server VM running with 16GB of RAM and four Xeon 2Ghz CPUs and vim kills it lol
[16:56] <Keizer> And the VM is hosted by VMWare which is crazy
[16:57]  * zul lunches
[16:57] <Keizer> I'm thinking it's because the vm is i686 and I didn't see the PAE listed when I did uname -a
[16:57] <ttx> kirkland: the tricky part is, to fully validate the fix you need an ISO burned.
[16:57] <Keizer> Either that or that machine is on it's way out =(
[16:57] <ttx> since what you test is the install from installer > reboot > start > autoregister path
[17:00] <cocoa117> how to install Chinese fonts into headless ubuntu-server? At the moment, cli only show <E9><95>rather then real character
[17:02]  * ttx disappears...
[17:02] <ttx> I'll be back.
[17:11] <skrite> hey all, i am needing some hardware advice. Our company has outgrown our web service and we need hardware. We run mysql backed apache and ruby rails. We have been looking at poweredge and blade servers but i need help.
[17:11] <skrite> our site is not like most, we have light read loads but heavy heavy write loads.
[17:14] <giovani> skrite: ok, can you explain a bit about your write load?
[17:15] <skrite> we take in info from machines in the field, we process this into the data that tells the machines to do this or that, and we have a website where the info and processes are displayed.
[17:15] <alexm> ttx: server iso rollback been performed?
[17:16] <ttx> alexm: 20090930.2 = 20090930
[17:16] <skrite> so the machines are writing history info all the time ( about 12 records inserted per second average)
[17:16] <giovani> skrite: ok, so is the data that's being written heavily db-based? files? all at once? millions of individual transactions?
[17:16] <giovani> oh, 12 records per second is not very much
[17:16] <alexm> ttx: thanks, i'm starting this morning test again
[17:18] <skrite> giovani, we are using MySQL for the records writing.  Another heavy load is that when a customer hits a page, it does calculations on thousands of rows adding this and that to create graphs, etc.. so the data writes are expensive and display of data is also a lot of work between ruby and the database
[17:19] <skrite> the reason i am asking here is that most tutorials and info i am finding are relating to websites where lots and lots of reads are done and the need is for fast html serving. That isn't really what we need.
[17:22] <giovani> skrite: so, mysql is a pretty awful database compared to others in performance
[17:22] <giovani> skrite: if you're looking for something FOSS -- then postgresql is the way to go
[17:23] <giovani> it's tunable, and can perform far better than mysql
[17:23] <skrite> did NOT know that
[17:23] <skrite> OK, definatly look into that.
[17:23] <giovani> that's not to say that MySQL won't meet your needs
[17:23] <giovani> it sounds like your needs aren't actually very high -- despite what you think
[17:24] <giovani> disk i/o limitations are static between software, obviously -- postgres is a bit smarter about storage, etc, but ultimately, if disk i/o is your limitation, then you need to work on addressing that first
[17:24] <skrite> what we are using now is a poweredge from Dell, 4 dual core Xeon with 8 GB RAM ( i know, that isn't much )
[17:24] <skrite> ok
[17:24] <rtg_> jjohansen, have you discontinued the AA kernel meetings?
[17:25] <jjohansen> rtg_: no
[17:25] <rtg_> did I just miss it today?
[17:25] <giovani> skrite: none of the specs you listed relate to disk i/o
[17:25] <jjohansen> rtg_: hrmm, my calendar didn't throw up a notice this morning
[17:25] <skrite> giovani, we thought of clustering a few machines, but did not know if the trade off of just using a more powerfull ( newer ) server would be preferable.
[17:25] <skrite> ok
[17:25] <jjohansen> rtg_: nope, it didn't happen
[17:26] <giovani> skrite: you seem to be confused about what "power" it is that you need
[17:26] <skrite> giovani, exactly
[17:26] <giovani> skrite: you've made no mention of current cpu usage
[17:26] <Barre> according to tldp.org a bash script should return a zero on successful completion, but there are some exeption. My question is, what are those exceptions? When is, let's say exit 3 in a script a "bug" or an exception?
[17:26] <rtg_> jjohansen,  is there any reason to continue it? seems like things have settled.
[17:26] <Maleko> in ubuntu we use authorized_keys or authorized_keys2 ?
[17:26] <Maleko> default one
[17:26] <giovani> why would you think you need to cluster machines together?  do you have data that shows that you're using your current cpu heavily?
[17:26] <jjohansen> rtg_: no, there really isn't
[17:26] <Maleko> ssh key i mean
[17:26] <jjohansen> rtg_: we just hadn't officially done that
[17:27] <rtg_> jjohansen, ok, I'll notify Pete and mdz that it no longer seems necessary.
[17:27] <jjohansen> rtg_: okay, thanks
[17:27] <jjohansen> smoser: do you have any objections to dropping the daily EC2 kernel meeting?
[17:27] <skrite> giovani, our processors are (on and off) working pretty hard. We run some scripts from cron that do some calculations and error checking on the machines, and they can run pretty heavy.
[17:28] <skrite> by heavy, i mean that they peak out one or two cores for several seconds
[17:29] <giovani> skrite: ok, do those cron jobs need to run quickly? i.e. would it be a problem if they were prioritized low, and then took more than a few seconds? if not -- I don't see any evidence that you have cpu utilization problems
[17:29] <skrite> giovani, a few of the processes need to run fast, but most can be drawn out.
[17:31] <smoser> i was going to suggest that today
[17:31] <smoser> jjohansen, to give you more time to get me a kexec kernel :)
[17:31] <jjohansen> :)
[17:32] <zul> i swear to god I can do these installs in a language other than english now
[17:33] <skrite> ok, what situation would cause someone to set up like a rack or blade server system instead of using a more powerful server computer?
[17:34] <skrite> giovani, gotta admit, i kinda want to cluster some machines just because it would be cool to learn. But that is my own geeky trip
[17:41] <kirkland> mathiaz: what did you use to get verbose upstart debugging at boot in your syslog?
[17:41] <kirkland> mathiaz: my irc logs are failing me
[17:41] <mathiaz> kirkland: https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/438602/comments/6
[17:41]  * sbeattie wonders why samba is reporting that smbd is reloading smbd.conf every 5 minutes to the console.
[17:42] <kirkland> mathiaz: thx
[17:54] <genii> sbeattie: Do you have logrotate for samba logs set for every 5 minutes?
[17:55] <sbeattie> genii: nope; this is a stock karmic install from the beta server iso.
[17:58] <zul> sbeattie: hmmm?
[18:00] <genii> sbeattie: I'd probably file a bug then
[18:02] <zul> sbeattie: smbd is doing what?
[18:04] <sbeattie> zul: something is triggering smbd to reload its config file every 5 min.
[18:04] <zul> sbeattie: hmm...i suspecting its dhcp
[18:12] <incorrect> i am having a mental breakdown, i can't remember how to apt-get  install a package dependencies
[18:12] <chmac> incorrect: You're installing a package from disk?
[18:12] <incorrect> oh build-dep
[18:12] <incorrect> there we go
[18:13] <chmac> I have fuse-utils installed. Any idea why `modprobe -l fuse` returns nothing?
[18:13] <genii> chmac: You mean: modprobe -l | grep fuse              ?
[18:14] <chmac> genii: Both return nothing, is `modprobe -l fuse` not valid?
[18:15] <chmac> genii: I think llutz on #ubuntu said it's part of the kernel so there's no longer a module
[18:17] <zul> sbeattie: can you do a ls -R /etc/network please?
[18:24] <sbeattie> zul: http://paste.ubuntu.com/282339/
[18:26] <zul> sbeattie: is this the server iso?
[18:27] <sbeattie> zul: it is
[18:28] <zul> sbeattie: this is odd
[18:31] <sbeattie> zul: it does seem to correlate nicely with dhcp client activity
[18:32] <zul> sbeattie: yeah but why is that happening,
[18:32] <genii> Perhaps your lease time is screwy
[18:32] <zul> can you try disabling apparmour?
[18:43] <sbeattie> zul: apparmor disabled, still seeing the messages.
[18:43] <zul> thats what I thought
[18:46] <zul> sbeattie: can you post the contents of your /var/lib/dhcp3/dhclient.eth0.leases as well?
[18:48] <sbeattie> zul: http://paste.ubuntu.com/282363/
[18:49] <genii> Interesting, netboot
[18:50] <zul> sbeattie: option dhcp-lease-time 600;
[18:50] <zul> this is what I have in mine option dhcp-lease-time 604800;
[18:52] <sbeattie> right, this is a test lab, the lease times are AFAIK intentionally tuned low, so that machines can come and go quickly.
[18:53] <zul> yeah so its dhcp doing that but im not sure where its restarting samba though
[18:54] <genii> I think smbd hits the lease expiry, has some internal check for lost IP and restarts
[18:55] <mathiaz> zul: I've seen something similar with sshd and mysqld as well. It seems that the networking subsystem sends a HUP signal when the dhcp lease is renewed
[18:55] <zul> yeah same here
[18:58] <zul> sbeattie: can you add the messages in syslog when it happens as well
[18:58] <zul> mathiaz: its a regression in my eyes
[18:59] <mathiaz> zul: well - was jaunty doing the same ting?
[18:59] <mathiaz> zul: *thing*
[18:59] <zul> mathiaz: i cant be sure
[19:00] <zul> i just see more dhcp/samba bugs about more now
[19:00] <sbeattie> mathiaz: give me a little bit and I can see if I can reproduce on jaunty.
[19:01] <mathiaz> zul: well - a lot the bugs are related to remove filesystem share access via samba and NM
[19:01] <mathiaz> zul: *remote*
[19:01] <zul> true
[19:04] <sbeattie> mathiaz|zul: okay, I'm seeing it in my jaunty instance as well.
[19:05] <mathiaz> sbeattie: hardy?
[19:08] <zul> /etc/dhcp3/dhclient-enter-hooks.d/samba is the one doing it
[19:09] <zul> which is samba-common.dhcp
[19:18] <sbeattie> mathiaz: doesn't look to happen in hardy, but I also got a permission denied error reported from dhclient on trying to write the leases file.
[19:27] <zul> mathiaz, sbeattie: shouldnt it only reload if it gets a new IP address?
[19:28] <mathiaz> zul: yes - that makes more sense
[19:34] <zul> guys i might have a fix
[20:04] <zul> sbeattie mathiaz: does this look reasonable to you? http://pastebin.ubuntu.com/282402/ the thinking behind it after the IP address becomes bound again check the old against the new and restart it if they are different
[20:16] <mathiaz> zul: look good to me - did you test it?
[20:17] <zul> mathiaz: yep did a smbclient -L localhost before and after
[20:20] <zul> ill add it to the 3.4.1 stuff im doing
[20:39] <unknown__user> hi, i was wondering if there is really a significant difference between server hard disks and normal hard disks, because the price difference is almost ten times...i'm asking this because i want to add normal disks to a server, in a RAID 1+0 config, so if a disk fails, no data is lost, and i can replace it ten times before the solution gets more expensive than using server disks.
[20:45] <qman__> unknown__user, There is a difference between consumer grade and professional grade disks. What is your application, and what disks were you considering?
[20:45] <genii> unknown__user: Usually the difference is server drives are something like SCSI versus IDE or SAS vs SATA, also rated high times between failures
[20:49] <unknown__user> qman__:it's going to backup data, and i was considering the Seagate Barracuda 3.5" 1 TB, SATA2 3Gb/s
[20:50] <unknown__user> with 32 MB cache
[20:50] <qman__> unknown__user, if it's a low to moderate I/O application, those should do just fine
[20:50] <qman__> normally you need better disks for things like database servers
[20:51] <qman__> I have a SOHO file server that, among other things, supports daily backups from a few machines
[20:52] <qman__> it uses 500GB SATA seagate drives, and I've been running it for over a year without issue
[20:52] <unknown__user> this isn't the case, it should store data four times a day from another server, just files...
[20:52] <qman__> yeah, that should be fine
[20:53] <qman__> just make sure you implement good monitoring, so you notice if a disk starts to fail right away
[20:53] <unknown__user> that's what i was looking for, thanks a lot qman__, really appreciate your help
[21:29] <ttx> smoser: ping
[21:29] <smoser> here
[21:30] <ttx> smoser: any news on the ramdisk issue ?
[21:30] <smoser> i've not made any progress there.
[21:30] <ttx> fair enough.
[21:31] <ttx> smoser: how feasible is it to pull the ramdisk/kernels from the published items ?
[21:31] <smoser> we can definitely just 'rm a b c'
[21:31] <smoser> and i support that as the most reasonable solution at this point
[21:32] <smoser> the fact that they dont work, is testament to their necessity
[21:32] <smoser> interestingly enough :)
[21:33] <smoser> if my somewhat knowledgeable "this should work" guess at providing an initramdisk failed, it means that using whatever happens to be in /boot on a system is destined for failure
[21:33] <smoser> or at least indeterminate results
[21:34] <ttx> smoser: ok, do it then
[21:34] <smoser> so at this point it looks like we're good with what we have other than that ?
[21:34] <smoser> for server images ?
[21:34] <ttx> smoser: things might get released before you join us tomorrow. Please sync with slangasek
[21:35] <ttx> yes, server images should be "mostly ok"
[21:35] <ttx> smoser: make sure that he has everything needed to trigger what is needed
[21:35] <smoser> i will do so later night. i'll send out a mail of where things are, hopefully a.) making sure that things are ready to go b.) that someone else could do it.
[21:36] <ttx> smoser: thanks
[21:55] <Tux2> Is there anyone here who can help troubleshoot a bind9 problem?
[21:56] <Tux2> Sep 30 14:53:19 CHU-AC1 named[13803]: configuring TKEY: failure
[21:56] <Tux2> Sep 30 14:53:19 CHU-AC1 named[13803]: loading configuration: failure
[21:56] <Tux2> Sep 30 14:53:19 CHU-AC1 named[13803]: exiting (due to fatal error)
[21:59] <Tux2> That is the tail right after trying to start bind9
[23:20] <ezhangin> hey guys
[23:22] <ezhangin> hey so my member:ubuntu server just stopped booting
[23:22] <ezhangin> uh
[23:22] <ezhangin> my ubuntu server*
[23:22] <ezhangin> it does do verifying DMI pools in the bios
[23:22] <ezhangin> but then it doesn't do anything after
[23:23] <ezhangin> any ideas?
[23:29] <ezhangin> ugh i'm not even getting to grub, i don't see why this would happen all of a sudden
[23:29] <ezhangin> the last thing i did was create a raid-5 array with mdadm separate from the boot drive
[23:30] <qman__> unless you accidentally nuked your boot drive, or grub was for some reason on the wrong drive, the only thing left is hardware failure
[23:30] <ezhangin> i can mount the boot drive
[23:30] <ezhangin> in fact i;m looking at the grub menu
[23:30] <ezhangin> .list
[23:30] <qman__> ok
[23:31] <qman__> the second thing I meant was, if grub was installed to the boot sector on one of the other drives, instead of the one you thought it was using
[23:31] <qman__> and you wiped them, that could cause it to stop booting
[23:31] <qman__> the solution there would be to boot live and redo grub-install
[23:31] <ezhangin> the OS is definitely on the boot drive, could grub really have run away to another drive?
[23:31] <ezhangin> i'm on live right now thankfully
[23:32] <qman__> yeah
[23:32] <qman__> grub-install dynamically determines which drive to install its boot sector to
[23:32] <qman__> it doesn't always choose wisely
[23:32] <ezhangin> yeah it just sits there blinking after verifying DMI
[23:32] <ezhangin> oh
[23:32] <ezhangin> hmm
[23:32] <ezhangin> interesting
[23:32] <qman__> so, you can manually reinstall the grub boot sector on the drive you want, from the live environment
[23:32] <ezhangin> i might go back and change some BIOS values to the original ones i had and then do this
[23:32] <ezhangin> you have been very helpful
[23:33] <ezhangin> thanks already
[23:33] <qman__> no problem
[23:33] <ezhangin> how do i manually install grub, apt?
[23:33] <qman__> no, just run grub from the live environment
[23:33] <qman__> google for "reinstall grub", should get you a guide
[23:33] <qman__> or repair grub, etc.
[23:34] <qman__> your config is all fine, you just need to recreate the boot sector
[23:34] <ezhangin> can i use a x64 sever cd or do i need a live cd?
[23:34] <ezhangin> i have a 32 bit live cd
[23:34] <qman__> server CD should be able to do it, but 32/64-bit won't really matter either
[23:34] <qman__> since you're not installing any software, just running a command
[23:34] <ezhangin> k
[23:36] <ezhangin> live cd boot time
[23:36] <ezhangin> yeah i just formatted the array, figures lol
[23:36] <ezhangin> oh this makes sense now (one of my other problems)
[23:36] <ezhangin> haha
[23:39] <ezhangin> ah
[23:39] <ezhangin> here is the grub prompt
[23:39] <ezhangin> let's see
[23:41] <pwnguin> is there a way to log FTP ... "user agents"?
[23:42] <ezhangin> haha nice nick man
[23:42] <pwnguin> focus
[23:42] <ezhangin> i'm in here for help too lol, i just liked the nick
[23:43] <ezhangin> well qman it booted
[23:43] <ezhangin> but my array is jacked again
[23:43] <ezhangin> i dunno wtf is going on >:
[23:44] <ezhangin> oh
[23:44] <ezhangin> it said something about (hd0,0) when booting up when it should probalby be (hd4,0)
[23:47] <ezhangin> qman__: welp
[23:59] <benc> anoyone familiar with autoscan?
[23:59] <benc> what package do I need to install to have it?