[01:34] <StrangeCharm> manually trying to set up an encrypted lvm, grub is giving me an error at boot. what am i likely to be doing wrong?
[01:49] <twb> StrangeCharm: LTS or 9.04?
[01:49] <StrangeCharm> twb, 9.10
[01:49] <StrangeCharm> RC
[01:49] <twb> Oops, yeah
[01:50] <twb> Wait, 9.10 is still in RC?  It's nearly 2009-11!
[01:51] <StrangeCharm> i think the release is in 4 days
[01:53] <ScottK> On Thursday
[01:53] <StrangeCharm> either way, twb did you have some tips?
[01:54] <twb> StrangeCharm: sorry, I was just triaging
[01:54] <StrangeCharm> lts>9.04>9.10RC ?
[01:55] <ScottK> Nope.  Sorry.
[01:55] <twb> LTS is currently 8.04.
[01:55] <ScottK> StrangeCharm: The most recent LTS is 8.04.  It was followed by 8.10, 9.04, and on Thursday, 9.10.
[01:55] <ScottK> The next LTS will be 10.04.
[01:56] <twb> non-LTS releases are for people with more faith or more time :-)
[01:56] <StrangeCharm> i am aware. i was facetiously remarking on triage priorities
[01:56] <StrangeCharm> or more need for immediat efeatures
[01:58] <StrangeCharm> does / have to have the boot flag?
[01:59] <ScottK> twb: I disagree.  I don't think non-LTS releases are any less stable and the improvements more than offset the amount of time it takes to upgrade, but YMMV.
[01:59] <twb> ScottK: well, for example, I do not want to have to deal with LDAP's config moving into the database
[01:59] <ScottK> Right, I can understand that one.
[01:59] <twb> That is, not until some other bugger has ironed out the big problems
[02:00] <ScottK> Yeah.
[02:00] <ScottK> That's a particular special case for staying with LTS.
[02:00] <twb> StrangeCharm: the boot flag isn't necessary for GRUB, as long as GRUB is installed into the MBR (which is very, very likely).
[02:01] <twb> ScottK: also, I'm talking about mission-critical servers.  Obviously for a workstation or a SOHO fileserver, non-LTS releases would be "stable enough"
[02:02] <StrangeCharm> twb, what would determine whether it was?
[02:02] <twb> StrangeCharm: if grub was installed by grub-install or by debian-installer, then it's in the MBR
[02:03] <ScottK> twb: For my use cases they have been pretty equally stable.  I have two production servers on Hardy and a test server on Karmic and they all just work.
[02:03] <StrangeCharm> twb, so that's the default behaviour of the install disks?
[02:04] <twb> StrangeCharm: yes.  It is extremely unusual to install Grub into a partition's boot record.
[02:04] <twb> I only mentioned it for the sake of accuracy (pedantry)
[02:05] <twb> ScottK: granted.
[02:06] <StrangeCharm> so the boot flag have to be one /boot at all? will the boot flag be problematic?
[02:08] <StrangeCharm> under what circumstances would grub say that it couldn't find the disk in question?
[02:14] <twb> StrangeCharm: boot a live CD, and pastebin the output of "parted -s /dev/sda print" and "lvs".
[02:14] <twb> It'll need to be a live CD with LVM support, so try CentOS instead of Ubuntu Desktop if you have it.
[02:15] <twb> Or just write the equivalent data by hand and pastebin that.  What I really want to know is the partition layout and the LV layout
[02:16] <twb> Grub ignores boot flags entirely AFAIK, so as long as it's the first thing the BIOS bootstraps (i.e. it is in the MBR, not a partition boot sector), boot flags on partitions are totally irrelevant.
[02:18] <StrangeCharm> can i just describe the partition layout in words?
[02:25] <StrangeCharm> twb http://pastebin.com/d301080a3
[02:37] <skuld> I have a second hard drive in my system.  When I had fedora I did something that "joined" my two hard drives together so linux saw them both as one drive.  How do I do that again?
[02:40] <twb> skuld: if you do this the naïve way, a failure on either drive will destroy your filesystem.
[02:41] <skuld> oh, well, I'm backing up my critical stuff
[02:41] <twb> skuld: it would be better to either make it a separate partition or logical volume, and make a new filesystem on that partition/LV and mount it somewhere.
[02:41] <qman__> skuld, it's called RAID, and the configuration to use depends on what you're looking for
[02:42] <skuld> the problem is, I need the extra space on the second  hard drive for my /var/www
[02:42] <twb> Yes, ideally if you are concerned about individual drive failures, you should get two or three (or more) equal-sized drives and RAID them.  However, this is unlikely to be useful if you're e.g. adding a 200GB drive to a system which currently has a single 80GB drive.
[02:42] <twb> skuld: are you using LVM currently?
[02:42] <skuld> I think so.  is there a way to check?
[02:43] <qman__> if you don't know, you probably aren't
[02:43] <qman__> but a 'sudo fdisk -l' should tell you
[02:43] <twb> skuld: does /proc/mounts refer to /dev/mapper/foo-bar or /dev/foo/bar, or does it refer only to /dev/sdXN ?
[02:43] <skuld> I saw the option when I installed Ubunto, but I don't remember if I chose it or not
[02:43] <twb> StrangeCharm: OK, your partition layout looks OK.
[02:44] <twb> StrangeCharm: what is the exact error that grub emits?
[02:44] <skuld> http://pastebin.com/f1385fd5e
[02:44] <qman__> skuld, you're definitely using lvm
[02:44] <twb> StrangeCharm: I'm guessing it can't find /boot because the bit in the MBR is broken.  But it might be that the code in /boot can't find root.
[02:45] <skuld> ok
[02:45] <qman__> I don't remember the lvm commands to list volume groups and expand them and whatnot
[02:45] <twb> skuld: what you want to do is create a PV on the new disk (which appears to already have been done), then add that PV to your existing VG, then create an LV on that PV, then make a filesystem on the new LV, then mount that LV on /var/www.
[02:45] <twb> qman__: "lvs"
[02:46] <twb> qman__: oops, VGs is "vgs"
[02:46] <qman__> ah
[02:47] <qman__> for the sake of simplicity I generally don't use LVM, but it certainly is useful and allows for some really neat tricks
[02:47] <twb> LVM is great if you expect to change your mind later
[02:47] <skuld> wow...that sounds complicated LOL
[02:48] <twb> This happens a lot in my case, because most of my customers continue to use the same server for years, upgrading it piecemeal over time.
[02:49] <skuld> I know how they feel.  If I had the money.... LOL
[02:50] <skuld> and I know I'm going to want to add a couple of TB drives when I can afford it
[02:50] <twb> Well, for example you might have deployed with 20GB disks seven years ago, and upgrade to 1TB disks right now.  LVM allows that to happen with less downtime.
[02:52] <twb> If they had lots of money, they'd be more likely to replace the entire box every three years :-)
[02:53] <StrangeCharm> twb,  i think the error is that it can't find the disk 'disk not found', or words to that effect
[02:54] <skuld> I know I'd love to do that.  I'm still running on a PIII
[03:16] <twb> Everything in this office is PIIIs
[03:16] <twb> Except for engineer-owned laptops, and (sigh) our Q9550 PPPoE bridge.
[03:24] <billybigrigger> hey all, for some reason apache's access.log has stopped being written to since oct 16...i restarted apache, created some traffice and still nothing is being written to my access.log, i've checked my site settings in /etc/apache2/sites-enabled/xxxxxx and they are all set to log to my access.log
[03:24] <billybigrigger> running 9.04 server in a vm if that helps
[03:25] <billybigrigger> i haven't done any messing around with settings for this server for months...but i guess that doesn't rule out an update and i overwrote a config file somewhere right?
[03:30] <twb> Have you turned on unattended upgrades?
[03:30] <twb> (I really hope they're still off by default.)
[03:54] <skuld> okay, so I think I have the second hard drive ready to be added to the Volume Group...I think.
[03:55] <skuld> well, maybe not.  I don't see sdb1 anymore
[03:55] <twb> skuld: this disk *is* connected internally, right?
[03:55] <twb> LVM's probably not appropriate for an external HDD that you're gonna be plugging and unplugging.
[03:55] <skuld> yes, it shows up fdisk -l, just no info...
[03:55] <twb> No info where?
[03:55] <skuld> http://pastebin.com/f33728691
[03:56] <skuld> no, this is an internal HDD
[03:56] <twb> Looks like /dev/sdb has no partition table.
[03:57] <skuld> ugh!  I need to figure out how to do that.  I thought I did it
[03:57] <twb> cfdisk /dev/sdb
[03:58] <skuld> FATAL ERROR can not open disk
[03:58] <twb> Ha!
[03:58] <twb> And fdisk still works?  Stupid fdisk.
[03:59] <twb> Your kernel has forgotten about your disk.  Try rebooting, also confirm the cables are snugly connected.
[04:00] <skuld> ok
[04:38] <pipedream> 3
[05:23] <twb> Where in IRC can I find the LVM people?
[05:23] <twb> I have accidentally create a LVM snapshot and filled it to 100%.
[05:24] <twb> Now "lvs" and "lvremove /dev/foo/bar-20090909" both tell me it can't read a block of 4096 at points 0 and $bignum for /dev/foo/bar-20090909"
[05:24] <twb> This means I can't remove the old snapshot, which makes me worry that something more than it just being 100% full has happened.
[06:14] <twb> OK, here's an interesting feature for you.
[06:15] <twb> Make an LVM snapshot.  Now you have an LV and an LV snapshot with the SAME ext3 UUID as listed in /etc/fstab.  Reboot.  Is it possible for the LVM snapshot to get the symlink in /dev/disk/by-uuid?
[07:44] <soren> twb: Unless something makes sure that it doesn't happen (which may or may not be the case), then yes, that could certainly happen.
[07:45] <twb> Yay for huge failures!
[07:45] <soren> twb: Something does seem to handle that.
[07:45] <soren> Let me just check real quick.
[07:48] <twb> soren: ah, but are you sure it's not just a coincidence that your test picks the right LV first?
[07:48] <twb> i.e. a negative result alone isn't conclusive that the problem is fixed
[07:48] <soren> twb: I'm not testing.
[07:48] <twb> OK, good, carry on
[07:48] <soren> twb: I'm looking at code.
[07:49] <twb> Good man
[07:49] <soren> I know. Absence of evidence is not evidence of absence.
[07:49] <twb> Forgive me, I deal with a lot of stupid people, so I tend to assume the worst
[07:49] <soren> Yeah. I know the feeling :)
[07:50] <soren> twb: Can you give me the output of "blkid -o udev -p /dev/mapper/<the snapshot>" as well as "blkid -o udev -p /dev/mapper/<the "real" lv>"?
[07:50] <twb> Unfortunately that specific box I have metaphorically jumped up and down on.
[07:50] <twb> Let me grab another one
[07:51] <twb> soren: Invalid output format udev.  Chose from value, device, or full
[07:51] <twb> This is 8.04
[07:52] <soren> Oh.
[07:52] <soren> Let me check one of those, then..
[07:53] <twb> -o value gives me the UUID
[07:53] <soren> twb: Ok, use "vol_id --export /dev/mapper/blah" instead.
[07:53] <twb> ID_FS_UUID=2b96f387-98dc-4a7b-95b1-747d00fe4f2d same for all of them
[07:54] <soren> That's all it outputs?
[07:54] <twb> No, sorry, shall I pastebin the whole thing?
[07:54] <soren> Yes, please.
[07:56] <soren> twb: Oh, and one more thing.
[07:57] <soren> twb: Include "dmsetup export /dev/mapper/whatever" as well, please.
[07:57] <soren> I actually think that's really what I want.
[07:57] <twb> Nice one
[07:57] <twb> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=11167#a11167
[07:59] <soren> And which one does /dev/disk/by-uuid/2b96f387-98dc-4a7b-95b1-747d00fe4f2d link to?
[07:59] <soren> If I'm reading this correctly, it should be /dev/mapper/testtrim-debmirror.
[08:01] <twb> readlink /dev/disk/by-uuid/2b96f387-98dc-4a7b-95b1-747d00fe4f2d ==> ../../mapper/testtrim-debmirror20091002
[08:01] <twb> That I did not expect
[08:01] <alvin> Why is /etc/fstab no longer by-uuid, but by-label by default? Can it give problems? (root device is sometimes no longer found on an ubuntu-server here)
[08:02] <twb> alvin: hey, man, hold up!  I'm only just working out why by-uuid is evil and dodgy!
[08:02] <twb> :-)
[08:02] <alvin> twb: lol, I joined at the right moment
[08:03] <alvin> So, why is it evil?
[08:03] <soren> It's really not.
[08:04] <alvin> Something must be different. On the same server, Jaunty always boots and karmic does not. (Sometimes the root drive is not found, sometimes it's the network)
[08:04] <alvin> I'm currently suspecting the 'by-label', but there's no proof yet.
[08:04] <alvin> (the network is bug 459134 . Probably another reason.
[08:07] <twb> alvin: 17:15 <twb> Make an LVM snapshot.  Now you have an LV and an LV snapshot with the SAME ext3 UUID as listed in /etc/fstab.  Reboot.  Is it possible for the LVM snapshot to get the symlink in /dev/disk/by-uuid?
[08:07] <alvin> (I'm totally wrong. The default is not by label, but just the path /dev/mapper/vg0-home for example)
[08:07] <twb> Does karmic include the insserv migration?
[08:08] <alvin> twb: just a moment. Testing this...
[08:08] <twb> alvin: do you get as far as busybox?  If you do break=bottom and inspect stuff, is it any different?  RTFS by diffing /usr/share/initramfs on the two hosts?
[08:08] <soren> twb: The problem is not uuid based mounting. The problem is that apparantly the thing that's supposed to make sure the snapshot-origin takes precedence over the snapshot when making that symlink is failing.
[08:08] <soren> twb: uuid based mounting is a good thing. Really. The alternatives are much worse.
[08:08] <twb> soren: yeah, I know
[08:08] <twb> soren: I'm just being grumpy
[08:09] <alvin> twb: You're right. It's the same UUID!
[08:09] <twb> Having said that, I spent some time recently waiting for bootdegraded=true type failures due to the huge long default timeout
[08:09] <soren> alvin: Of course it's the same UUID. Otherwise it wouldn't be a snapshot.
[08:10] <alvin> soren: But then I can't mount the snapshot by UUID?
[08:10] <twb> alvin: right
[08:10] <soren> alvin: Right.
[08:10] <alvin> ok
[08:10] <twb> If there are two people in your office called "Zippy", you can't refer to them both just as "Zippy" without causing confusion.
[08:11] <twb> At least one of them has to be referred to as e.g. "Zippy the Pinhead"
[08:11] <soren> twb: Just for good measure, can you please pastebin your /etc/udev/rules.d/65-dmsetup.rules from that server?
[08:12]  * alvin is rebooting until the server no longer finds its root disk to test busybox stuff.
[08:12] <twb> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=11167#a11168
[08:13] <twb> alvin: hey, I'm clutching at straws
[08:13] <twb> alvin: don't assume I know what I'm talking about
[08:13] <twb> Incidentally, insert grumbling here about busybox-initramfs being crippled by removal of e.g. busybox httpd
[08:14] <twb> Oh, and a user-accessible "busybox start-stop-daemon"
[08:14] <alvin> twb: No worries, I need to test this today or it's back to Jaunty, where the root disk is always found and NFS mounts do not halt the boot process.
[08:14] <twb> I actually wanted to use that one in my .bash_profile, but I can't assume it's there on Ubuntu.
[08:14] <twb> alvin: are you sure it's NFS and not LDAP/NIS?
[08:15] <alvin> twb: very sure
[08:15] <twb> alvin: hard binding in the latter is a common source of slowdowns if the init order is futzd
[08:15] <soren> twb: thanks.
[08:15] <twb> OK.
[08:15] <twb> Anyways, I'm going home
[08:16] <alvin> (My personally most hated bug is 328881. Fixing that one would probably help a lot.)
[08:16] <alvin> Hey ubottu, bug 328881
[08:16] <twb> Ew!
[08:17] <twb> Do the upstart people say something horrible like "just start the script with "exec >/var/log/yow"
[08:18] <soren> twb: I'm filing a bug on this.. What's your launchpad ID so that I can subscribe you to it?
[08:18] <alvin> Currently, there simply is no boot log. I see some people taking pictures of their screen. Try explaining that to a collegue who is used to Solaris.
[08:19] <soren> The stuff echoed to the screen was never logged.
[08:19] <alvin> I know. Makes it a bit difficult to file bug reports. Always has been.
[08:20] <soren> Point is: It's nothing new about upstart.
[08:20] <alvin> That's true. Ubuntu never had boot logging. I don't know if debian has it actually.
[08:23] <soren> It doesn't.
[08:28] <twb> soren: sorry, I don't use launchpad because I hate its UI
[08:30] <alvin> What is the bug number? (I actually like Launchpad. Pity some things do not work in webkist browsers.)
[08:30] <alvin> s/webkist/webkit
[08:35] <alvin> twb: After 5 successfull reboots (NFS mounts commented out) I see the busybox. What is break=bottom supposed to do? (does nothing). It says: /dev/mapper/vg0-root does not exists.
[08:36] <twb> break=bottom is supposed to stop busybox just before it pivot-roots
[08:36] <twb> And dump you into a local shell
[08:37] <alvin> Without root, I can't get a local shell
[08:37] <soren> twb: We don't pivot-root.
[08:37] <soren> twb: We haven't for a loong time.
[08:37] <alvin> So, approximately 1 in 5 boots, the root drive is not found. Someone who knows if there is already a bug report?
[08:37] <twb> OK, whatever it is now
[08:37] <twb> break=bottom worked on an 8.04 box I tried the other day
[08:38] <twb> I concede I don't use non-LTS releases at all, raelly.
[08:39] <alvin> No use here: libvirt and kvm are more recent. We get crashes on hardy that no longer occur in Karmic. Of course, if the servers don't boot...
[08:40] <alvin> Against what should I report the /dev/mapper/vg0-root not found bug?
[08:43] <soren> alvin: try lvm2.
[08:43] <alvin> soren: thanks. Will do
[08:52] <alvin> Reported as bug 460914
[10:02] <fahadsadah> twb: All my servers run Karmic beta.
[10:03] <fahadsadah> (or debian)
[10:28] <simplexio> i have karmic in vbox for gis development, have tosay that it feel much faster than 9.04 in vbox
[10:37] <TeTeT> I just set up UEC on karmic . I get a  "The certificate specified is invalid!" in axis2c.log on the node. Any ideas how to fix that?
[10:52] <yann2> hello
[10:54] <yann2> I am currently using ubuntu hardy with Puppet on quite a few servers, although it is from universe. I am thinking of moving to chef in a close future. What are Ubuntu plans regarding automated deployments and configuration, is one tool going to make it into main for 10.4?
[11:20]  * soren goes to eat
[12:18] <Bilge> Where does aptitude get its package descriptions from?
[12:22] <heath|work> apt-cache more than likely
[12:27] <pmatulis> Bilge: when you perform an update the files that are updated are placed under /var/lib/apt/lists.  the apt tools use these files to determine what packages need to be upgraded.  they also contain package descriptions
[12:27] <pmatulis> Bilge: do an update and then enter that directory and do 'ls -ltr'
[12:29] <Bilge> I see
[12:30] <Bilge> Maybe I could write a script to somehow query a package description
[12:30] <Bilge> But I doubt it given that these files could be called anything and are generally all over the place
[12:30] <Bilge> Now I see why it takes aptitude a while to start up
[12:31] <pmatulis> Bilge: that's been done already: 'aptitude show foo'
[12:31] <soren> Bilge: What are you trying to achieve?
[12:31] <soren> Bilge: There are rather good tools to deal with the apt cache already.
[12:31] <Bilge> Well fancy that!
[12:32] <pmatulis> or 'apt-cache show foo'
[12:33] <Bilge> apt-cache gives me two results while aptitude gives only one
[12:34] <Bilge> I can't see any difference between the two results
[12:34] <soren> Nor can we, because we don't know which package you're talking about.
[12:34] <Bilge> Well no, but you'd also have to have my distro as well
[12:35] <soren> Ok, don't tell me anything. I'll reciprocate :)
[12:35] <Bilge> In case you can match it, I was running `apt-cache show imagemagick` on 8.04
[12:36] <soren> I get three results.
[12:36] <soren> different versions.
[12:50] <Bilge> Oh, heh
[12:50] <Bilge> One is 7:6.3.7.9.dfsg1-2ubuntu1
[12:50] <Bilge> The other is 7:6.3.7.9.dfsg1-2ubuntu1.1
[12:50] <Bilge> I'm not really sure how you'd target one specifically if you want to install it
[13:01] <_ruben> Bilge: apt-get install $packagename=$version
[13:06] <aubre> hmm - what would cause me all of a sudden to not be able to ssh into my instances?
[13:07] <aubre> I did do a apt-get update, and apt-get dist-upgrade on all of my servers
[13:07] <jsalisbury> aubre:  did your public IP address change?  This happened to me.  Try euca-describe-instances
[13:08] <aubre> jsalisbury: well these are brand new instances
[13:08] <aubre> jsalisbury: let me check something
[13:08] <jsalisbury> aubre:  Ok.  I opened a bug for my issue: Bug# 455625
[13:10] <aubre> jsalisbury: those were instances using the images from the UEC store
[13:10] <aubre> jsalisbury: now I am trying one of my own
[13:11] <aubre> jsalisbury: nope locked out of it too
[13:13] <jsalisbury> aubre:  ahh, Ok.
[13:18] <aubre> trying to do a new keypair
[13:21] <soren> jdstrand: I took the liberty of assigning bug 460271 to you.
[13:22] <aubre> tried changing keypairs, that didn't work
[13:24] <nijaba> Is someone taking care of bug #450044 which seems to be fixed upstream, but not in the version of euca2ools we deliver?
[13:29] <zoopster> aubre: what are you seeing log or console wise?
[13:31] <aubre> zoopster: console wise, when I do a ssh-i mykey.priv ubuntu@ipaddress I get Permission denied (publickey)
[13:33] <aubre> zoopster: I'm rebooting my front-end and will try again, I didn't think the dist-upgrade would have caused any problems but I am checking
[13:33] <zoopster> aubre: *should* not have, but anything is possible.
[13:45] <jsalisbury> aubre:  Did you take a look at your .ssh/know_hosts file?  Maybe there is an old entry conflicting with your new entry?
[13:46] <aubre> no I cleared it out already
[13:46] <jsalisbury> aubre:  Ok
[13:52] <aubre> zoopster: jsalisbury : doesn't seem to be anything in the nc.log - what's the best log to look into for ssh-instance problems?
[13:55] <jsalisbury> aubre:  I'm taking a look too, but I don't see anything logged about ssh logins in any of the /var/log/* or /var/log/eucalyptus/* files
[13:57] <jsalisbury> aubre:  I'm running a apt-get dist-upgrade today too.  I'll let you know if it affects my existing instances.
[13:58] <aubre> jsalisbury: thanks
[14:10] <jdstrand> soren: sure
[14:11] <soren> jdstrand: Lovely, thanks.
[14:27] <smoser> ttx, kirkland, one of you told me about euca-describe-availability-zones and i think impllied to me that the settings there are configurable
[14:27] <smoser> do you know where/how ?
[14:27] <ttx> in the web UI
[14:27] <kirkland> smoser: you mean the density of systems per core?
[14:27] <ttx> VmTypes thing
[14:27] <kirkland> smoser: yeah, web ui
[14:28] <smoser> ok, so if i hadn't previously logged into my admin UI
[14:28] <smoser> how do i do that
[14:28] <smoser> user/pass ?
[14:29] <smoser> kirkland, ttx
[14:29] <soren> mathiaz: Oh, thanks for the awesome write-up on https://bugs.edge.launchpad.net/ubuntu/+source/debian-installer/+bug/457767/comments/7   That is going to be really useful. Can you put it on a wiki somewhere (not urgent, just do it after release or something).
[14:29] <mathiaz> soren: right - for 10.04 we should bundle gpxe - to have native iscsi support in the boot loader for kvm
[14:30] <mathiaz> soren: I was wondering how/if I could just drop the new bootloader somewhere for kvm to use it (to avoid chainloading from pxe)
[14:30] <soren> mathiaz: etherboot should have this as welll... Or so I thought.
[14:30] <mathiaz> soren: etherboot is dead - it's now gpxe
[14:30] <mathiaz> soren: AFAICT etherboot doesn't support native iSCSI
[14:31] <soren> Oh, I may have chainloaded gpxe from etherboot when I tried it.
[14:31] <soren> mathiaz: Yeah, it's been dying for years.
[14:31] <soren> :)
[14:59] <stas> Hi, any syadmins/network admins up?
[15:00] <smoser> kirkland, ttx, bug 461156
[15:00] <smoser> this is possibly quite serious if not user error
[15:02] <stas> can anybody help me create a one nic nat connection for my home network
[15:05] <smoser> ttx, kirkland can you verify sane-ness of this:
[15:05] <smoser> $ cat /proc/partitions
[15:05] <smoser> major minor  #blocks  name
[15:05] <smoser>    8        0    2144256 sda
[15:05] <smoser>    8        1    2097152 sda1
[15:05] <smoser>    8        3      47071 sda3
[15:05] <smoser> thats from a 'm1.small' instance
[15:06] <smoser> there is *no* ephemeral storage
[15:09] <elginix> hi all - have just been reading about the EC2 cloud images for 9.10 - am interested if anyone has been using ubuntu on the cloud in a production environment and what your experiences have been
[15:11] <smoser> elginix, there are lots of users of it.  the http://groups.google.com/group/ec2ubuntu?pli=1 is probably the largest group of people.
[15:12] <elginix> oooh tasty link :) thank you
[15:13] <elyezer> email server what can I use? Postfix?
[15:16] <alvin> elyezer: dovecot-postfix is a package that will give you a useful basic mailserver
[15:17] <smoser> ttx, kirkland please, help, above^
[15:17] <elyezer> alvin: thank you
[15:17] <kirkland> smoser: okay
[15:17] <smoser> my euca is seeing no ephermal storage
[15:17]  * ttx read backlog
[15:17] <smoser> i can't spell that word
[15:17] <ttx> smoser: admin/admin
[15:18] <smoser> already got that
[15:18] <elyezer> alvin: If I'm in the desktop edition I need to add any repository?
[15:18] <smoser> sorry, the other 2 things are 1.) please look at that bug 2.) i see no ephermal storage on my instances... which doesn't seem right.
[15:19] <alvin> elyezer: no, just $ sudo apt-get install dovecot-postfix
[15:19] <ttx> smoser: I think its normal to not have any ephemeral if your image is taking up all the space
[15:19] <ttx> i.e. running a 2G image over a 2G allowance -> no space
[15:19] <ttx> running a 2G image over a 4G allowance -> ~2G space
[15:19] <smoser> oh... ewll that is much different. wow. ok.
[15:20] <alvin> elyezer: it's in main
[15:20] <smoser> i'll change settings then and test.
[15:20] <smoser> ttx, so do you get a single partition with "all the additional space" ?
[15:20] <ttx> smoser: I may have understood that concept wrong, but yes, that's how someone described it to me
[15:21] <elyezer> alvin: E: Couldn't find package dovecot-postfix (I'm in Ubuntu 8.04)
[15:21] <ttx> smoser: looking at the bug now
[15:22] <alvin> elyezer: that explains. That package was new in 9.04
[15:22] <ttx> aw. that sounds ugly
[15:23] <alvin> elyezer: but no worries. You can install postfix and dovecot and configure them yourself.
[15:23] <genii> Hm. Why can something like: script -c /bin/bash -q -a /var/log/$USER    work as a default shell on local console login but not ssh? ("openpty failed" etc)
[15:23] <elyezer> thank you
[15:23] <elyezer> alvin: great =D
[15:25] <ttx> smoser: about bug 461156, I don't get how the SSH key thing works if that bug is real
[15:26] <smoser> ssh key does not come over user-data
[15:26] <ttx> ah
[15:26]  * ttx fires up his UEC
[15:26] <zoopster> stas: check out the ServerGuide and use UFW to do what you want
[15:26] <mathiaz> hm - the ubuntu server domain thread on u-devel-discuss is *almost* reaching 100 messages
[15:27] <smoser> ttx. i can verify it.
[15:27]  * ttx should author some research on recurring threads
[15:32] <alvin> For a bug report (bug 461133) I'm asked to run "$ sudo mountall --debug" and send it SIGUSR1. I've send that signal with htop, but the process does not end. What to do to give a useful output?
[15:35] <smoser> ttx, this is serious. soren please read that bug also. (bug 461156) and confirm with me that without a fix all user-data is hosed in UEC
[15:36] <soren> smoser: Yeah, that's pretty bad.
[15:37] <alvin> What is the SIGUSR1 supposed to do?
[15:38] <soren> alvin: For what?
[15:38] <soren> alvin: Eucalyptus?
[15:38] <alvin> No, "sudo mountall --debug"
[15:38] <alvin> the mountall script runs, (without success), and hangs somewhere. I'm supposed to send it SIGUSR1, but nothing changes.
[15:39] <ttx> smoser: could we fix it from inside, like detecting both formats ?
[15:39] <alvin> I can create a log until SIGINT
[15:40] <soren> alvin: It's supposed to let mountall know that all your network interfaces are up.
[15:40] <smoser> ttx, arguably no
[15:40] <ttx> smoser: I see what you mean
[15:40] <alvin> soren: ow, they are. I'm running the script within ssh
[15:40] <soren> alvin: I'm not saying they aren't.
[15:41] <smoser> in the bug there, there would be no way that that data was not intended.
[15:41] <soren> alvin: I'm just answering your question.
[15:41] <alvin> soren: thx, in that case, I will give the output of the command with Ctrl+C at the end.
[15:41] <smoser> ttx, you could, say, though "if i'm in eucalyptus, then the data is not correctly decoded, so i decode it now".
[15:42] <smoser> the problem with that is a.) in theory we can't tell if we're in euca versus we're in ec2 (but we can, so that coudl be worked around) b.) that logic fails to work anymore if you fix euca
[15:42] <ttx> mdz: ping
[15:43] <soren> smoser: Is this massively different from the ephemeral storage thing?
[15:44] <soren> smoser: In that case, you wanted to go around and detect stuff and just deal with it, so that either UEC or EC2 could change whatever they wanted and stuff would still work (I'm still curious of the details of that
[15:44] <smoser> i think i can fix the storage without knowing "am i in euca or ec2"
[15:44] <soren> )... In this case, why not just try to base64 decode it, and if that succeeds, go ahead and do with what your normally would have.
[15:44] <smoser> i know you will say "good enough", but its not
[15:45] <ttx> soren: that would screw up someone sending base64 encoded userdate, I guess
[15:45] <ttx> userdata
[15:45] <soren> ttx: Not really.
[15:45] <smoser> because of the case, that in a fixed eucalyptus, the user provides you with base64 encoded data
[15:45] <soren> ttx: If they're using it for something, they can still query it, and get the right stuff.
[15:45] <soren> It's not like we're chaning anything in the meta-data service.
[15:45] <smoser> which is then re-encoded, and decoded (correctly), resulting in encoded data that would correctly decode, but shouldn't
[15:46] <ttx> smoser: yes, that was my point.
[15:46] <soren> Right. This is just like you wanting to mount stuff that the user may not want mounted.
[15:46] <stas> zoopster: thx, but that didn't help
[15:46] <smoser> right. ttx. thats the case (possibly unlikely) that is impossible to detect
[15:46] <zoopster> stas: where are you stuck?
[15:47] <ttx> smoser: I think we need to parallelize efforts
[15:47] <smoser> soren, yes, its obviously similar. i think there is enough data to correctly do mount.
[15:47] <stas> zoopster: I got a pc and the gw, both can ping each other, but pc gets no nated
[15:47] <smoser> ttx, the user data needs to be fixed in eucalyptus
[15:47] <smoser> it affects *all* instances that run inside
[15:47] <soren> Well..
[15:47] <smoser> empheral storage argubably only affects ours
[15:48] <smoser> ok, well, thats not true...
[15:48] <soren> all instances that expect user-data passed from a file.
[15:48] <smoser> or from the command line
[15:48] <smoser> either way
[15:48] <SyL> anybody getting this error when starting an instace?
[15:48] <smoser> if they expect user data you're hosed
[15:48] <soren> Virtually /every/ image will expect the ephemeral storage.
[15:48] <SyL> err... nevermind
[15:49] <ttx> smoser: no doubt it should be fixed inside eucalyptus
[15:49] <smoser> soren, by default, you're hosed on that. in euca even "fixed"
[15:49] <soren> smoser: That does not compute.
[15:49] <smoser> because default setting is 2G "storage" for an instance. and our images are 2G. thus you get 2G /,and will have no filesystem mounted at /mnt
[15:50] <smoser> if you do anything larger than 2G - ~600M populated root, operations to fill up /mnt you're done.
[15:50] <smoser> but that fixable with config
[15:50] <ttx> smoser: I think eucalyptus needs to work on a fix and we need to have an image-based workaround
[15:50] <soren> smoser: I'm having trouble following you. I need more punctuation :)
[15:50] <ttx> smoser: so that we can make the best choice
[15:51] <zoopster> stas: if you do the steps outlined in the ufw Masquerading of the serverguide you will have a fully working nat - https://help.ubuntu.com/9.04/serverguide/C/firewall.html
[15:52] <soren> smoser: The code to handle the automatic mounting thing... does that exist yet, or has it yet to be written?
[15:52] <smoser> soren, if you fire up a UEC instance of m1.small with no configuration changes to your server, you will have 2 partitions '/' (/dev/sda1) and swap (/dev/sda3).  /dev/sda1 is 2G, and is /. we have ~ 600M on /.
[15:53] <soren> Right, ok.
[15:53] <smoser> if you change your configuration to make that 4G, then you'll end up with /dev/sda1 of / of 2G, the swap, and 2G /dev/sda2
[15:53] <smoser> soren, yet to be written.
[15:53] <soren> Ok.
[15:53] <smoser> but i think fairly easy
[15:53] <stas> zoopster: yes, thats the first page i got googleing, I followed the steps but still nothing
[15:53] <soren> smoser: I would very much like to see it.
[15:53] <elyezer> when using postfix and dovecot for each user@domain.com I need to create a new user??
[15:53] <soren> And /dev/sda2 is the expected for i386 images, right?
[15:53] <SyL> anybody getting this error when starting instances in eucalyptus.  [RemoteBootstrapperClient:SystemClockTimer]  ERROR java.nio.channels.UnresolvedAddressException
[15:54] <soren> elyezer: Depends.
[15:54] <ttx> smoser: so by parallelizing I mean we need to forward the issue upstream and we need to have a workaround ready, then make the best choice if/when both are available
[15:54] <smoser> if /etc/fstab contains /dev/sdb && not exists /dev/sdb && exists /dev/sda2 && /dev/sda2 is ext2 filesystem, then modify /etc/fstab, replacing sdb with sda2
[15:54] <smoser> only do the above on first boot.
[15:54] <elyezer> soren: on what?
[15:54] <smoser> ttx, i realized what you're saying.
[15:54] <soren> elyezer: Well, first of all, is user@domain.com an alias?
[15:54] <ttx> kirkland: could you take care of the "forward the issue to eucalyptus and pressure them for a minimal fix" part ?
[15:54] <elyezer> soren: no
[15:55] <soren> elyezer: Or should it have its own, separate mailbox?
[15:55] <zoopster> stas: then you likely missed something...you'll need to do some troubleshooting to find where the issue is and then pose a more specific question
[15:55] <ttx> smoser: it might be too late to change eucalyptus now, so we might switch in damage-control mode
[15:55] <smoser> soren, does that logic above seem safe? (it does have to be modified to be arch specific on ec2)
[15:55] <elyezer> soren: each will have its own mailbox
[15:55] <soren> smoser: I don't know. Are we having "that type of discussion" or are we being reasonable?
[15:56] <smoser> ttx, i understand. i just think that if we fix it in ec2-init we are 100% guaranteed to break *some use case* (even unlikely) if it is later fixed in eucalyptus
[15:56] <elyezer> soren: if not an alias then I need to createa new user, isn't it?
[15:56] <soren> elyezer: Then of course it requires a separate (mail) user.
[15:56] <smoser> soren, which discussion
[15:56] <stas> zoopster: I flushed my firewall and tried this http://www.linuxjournal.com/article/7175, still the same
[15:56] <elyezer> soren: thank you very much
[15:56] <stas> sysctls forwarding are ok
[15:56] <smoser> for fstab please tell me where that logic would fail
[15:56] <ttx> smoser: it may be the only option we have on the table. Better than leaving it the way it is
[15:56] <smoser> in any type of discussion
[15:57] <stas> zoopster: should that count if I'm running karmic desktop kernel?
[15:57] <smoser> ttx, if it is the only option.  i think you can probably fix euca
[15:58] <soren> smoser: I don't know. Maybe the user is monitoring the contents of /etc and doesn't like having it changed.
[15:59] <smoser> we only change on "once per ami".
[15:59] <soren> smoser: What do I know? I think it's perfectly reasonable, but not 100% bullet proof.. Just like I think it's perfectly reasonable to make expectations about names of devices attached to a Xen paravirt guest.
[15:59] <smoser> i'll even allow you to say "only once ever"
[15:59] <smoser> in that case, it will only ever happen in our official untouched images.
[15:59] <soren> smoser: ...and images other people build with the same tools.
[16:00] <smoser> soren, yes, possibly.
[16:01] <smoser> so i'd be willing to even put a comment in the /etc/fstab that we use that says "this is going to possibly be modified"
[16:01] <soren> smoser: I think it's perfectly reasonable. I just wanted to know if this was going to be "that sort of argument" again.
[16:01] <smoser> and if that comment is not present, then not do it.
[16:01] <smoser> soren, i am seriously interested in making it not break.
[16:01] <smoser> in any case.
[16:01] <soren> Then fix eucalyptus instead.
[16:01] <smoser> i dont like software that works if you hold your mouth right.
[16:02] <smoser> so, you're correct with your euca suggestion.
[16:03] <soren> Maybe someone doesn't want the extra space mounted, and has been using amd64 images on Eucalyptus and has been quite happy that this extra space did not get mounted.
[16:04] <soren> I don't know. In "that sort of argument" I didn't think it was necessary to have examples.
[16:05]  * soren chuckles at that bug
[16:06] <mdz> ttx, hi
[16:07] <ttx> mdz: bug 461156
[16:07] <ttx> mdz: basically prevents userdata from workin in Eucalyptus in general
[16:07] <mdz> ttx, ...
[16:08] <ttx> mdz: do you think we can still fix it inside eucalyptus
[16:08] <ttx> mdz: or should we prefer a broken workaround in ec2-init
[16:08] <ttx> mdz: I was planning to parallelize both efforts
[16:08] <ttx> mdz: and see how disruptive each is
[16:09] <mdz> ttx, has it regressed or has it never worked?
[16:09] <ttx> mdz: it has never worked.
[16:09] <stas> zoopster: i'm getting this with tcpdump, ICMP time exceeded in-transit, any ideas?
[16:10] <stas> this happens when i ping from pc
[16:10] <ttx> soren: is the possibility to send a script through userdata something specific to our images ?
[16:11] <TeLLuS> stas: http://en.wikipedia.org/wiki/ICMP_Time_Exceeded
[16:11] <smoser> ttx, it is not.
[16:11] <smoser> the alestic images do it.
[16:12] <stas> TeLLuS: yeah, i got it, but why im getting ttl exceed?
[16:12] <smoser> and it is not just "a script". it is all possible user data. customizing an instance via user data is *major* functionality in ec2
[16:13] <TeLLuS> stas: Maybe a loop or routing error that cause the packet ttl to count down to 0
[16:13] <ttx> mdz: so should we pursue both tracks in parallel or is one of them not a possibility anyway ?
[16:13] <TeLLuS> stas: try traceroute
[16:13] <mathiaz> kirkland: what's the importance for bug where the guest crashes (in qemu-kvm)? medium?
[16:13] <mathiaz> kirkland: bug 458521
[16:14] <kirkland> mathiaz: yes, medium
[16:14] <kirkland> mathiaz: i just saw that one this weekend
[16:14] <mathiaz> kirkland: and in this case the package should qemu-kvm instead of kvm?
[16:14] <kirkland> mathiaz: yes
[16:15] <kirkland> mathiaz: i changed it
[16:15] <zul> mathiaz: i modified the report to do incomplete unconfirmed as well fyi
[16:16] <mathiaz> zul: which report?
[16:16] <zul> mathiaz: the incompleteconfirmed.py report
[16:16] <zul> meh...doesnt work
[16:17] <mathiaz> ttx: I'll have a look at reproducing bug 458904
[16:17] <ttx> mathiaz: cool, thx
[16:17] <mathiaz> ttx: I may have access to enough hardware for it
[16:18] <stas> TeLLuS: traceroute stops in gw, so the gw firewall is the problem
[16:19] <ttx> kirkland: could you take care of the "forward the issue to eucalyptus and pressure them for a minimal fix" part ?
[16:19] <kirkland> ttx: okay
[16:19] <kirkland> ttx: assign the bug to me for now
[16:19] <ttx> kirkland: I couldn't find where the metadata service is handled in the code
[16:20] <kirkland> ttx: just make sure the bug is fully updated, and i'll take this up with nurmi
[16:20] <kirkland> ttx: i'm looking at https://bugs.edge.launchpad.net/qemu/+bug/458521
[16:20] <kirkland> ttx: which i'm experiencing too, and has me concerned
[16:20] <ttx> kirkland: keep in sync with mdz in case he discards one of the options
[16:20] <kirkland> ttx: this will need to be fixed via SRU
[16:20]  * soren calls it a day
[16:22] <ttx> mdz, kirkland: we could fix it in eucalyptus in a post-release SRU, and document the missing userdata support
[16:23] <fbc-mx> I need to install an UBUNTU server inbetween  by router and may lan to limit connects to certain IPs and to give internet to only certain machines, etc. What software could I load for this purpose? I already have an ebox setup running on a server and could stick another nic into it to serve this purpose as well.
[16:24] <TeLLuS> stas: or after, but someone running runing the firewall could probably provide more information, I just added a similar thing to a firewall to stop 80.82.120.X from trying all passwords, I just added a routing loop for it
[16:24] <heath|work> if I edit visudo do I need to restart for changes to take?
[16:24] <fbc-mx> I've heard of some floppy based distros doing this kind of stuff, but I would like something highly recommended by the ubuntu community.
[16:25] <KurtKraut> fbc-mx, you should try Squid and ufw (uncomplicated firewall)
[16:26] <fbc-mx> KurtKraut, great, let em see if I could find some howto's.. thanks
[16:26] <KurtKraut> fbc-mx, if you're doing this as a job, I suggest you to buy books about Squid and books about iptables (firewall)
[16:28] <fbc-mx> KurtKraut, It's my dad's shop and we are just a small company of 15 or so. I just need something that I can keep certain machines off of internet and others with limited Instant messaging access.
[16:28] <heath|work> oh cool sudo !!
[16:29] <fbc-mx> KurtKraut, you block msn-messenger ip ranges, and crap like that for certain macs.
[16:29] <simplexio> fbc-mx: iptables (firewall ,NAT ) is in linux kernel, Squid can do all kind stuff to net traffic (like proxy, deny some traffic based it content etc, i dont really know it). all other programs what you are speaking are pretty much user interfaces for iptables
[16:30] <KurtKraut> fbc-mx, Squid and iptables (or an easier variant, ufw) will do the job. But as I said before, there are books that teach this stuff better than the howtos online.
[16:30] <simplexio> fbc-mx: then all you need is smallest ubuntu installation and few iptables rules
[16:31] <magnetic__> fbc-mx: if you already have eBox you can also use the firewall and proxy modules
[16:31] <simplexio> and maybe add NAT configuration there with dhcp server to give clients ip addre based on nic MAC and build rules from there, possibilities are not endless but allmoust
[16:32] <fbc-mx> simplexio, KurtKraut,  great... thanks.. I just found some great HOwto's specific to ubuntu on UFW.  KurtKraut, yes, I would like to download the ebooks on squid and ufw from that book publisher with the animals on the cover ( I can't remember their name)
[16:32] <fbc-mx> magnetic__, yeah except that their documentation stinks, and can't find any information about what to do after I load the modules.
[16:35] <simplexio> umm.. how about loading those modules and then checking is there some way to confgiure them
[16:36] <simplexio> offcourse, dont do that on office hours. and first make somekind fallback plan if you dont get it to work, like backup systems and restore plan first
[16:37] <simplexio> usually if something arent mentioned in docs, then writer has thoght that its trivial. which it usually isn't but its not that comlicated
[16:41] <mdz> ttx, if it has never worked, it is not critical for 9.10
[16:41] <mdz> kirkland, ^^
[16:41] <nekro_> ttx: can you confirm if the patch from revno 942 fixes the userdata problem?
[16:41] <nekro_> ttx: I just committed something.
[16:41] <kirkland> mdz: okay, i have never tested it before
[16:42] <simplexio> btw. why there is postgis 1.4 for postgresql 8.3 in 9.10 but not for postgresql 8.4. 8.3 is obsolete in 9.10
[16:42] <ttx> kirkland: I'll move it to updates
[16:43] <magnetic__> fbc-mx: there are new docs in http://doc.ebox-platform.com/
[16:43] <heath|work> I need www-data to be able to sudo without a password to chown on some files
[16:43] <heath|work> I have: www-data ALL=NOPASSWD: /bin/chown 1[0-9][0-9][0-9]\:1[0-9][0-9][0-9] /var/www/.*
[16:44] <heath|work> in visudo, but it's still not working
[16:44] <fbc-mx> magnetic__, cool, I'll check it out.
[16:44] <heath|work> I'm attempting to test it with sudo -u www-data sudo chown 1001:1001 file.txt
[16:44] <mdz> kirkland, ttx, so does that mean we can close the ec2-init task?
[16:44] <ttx> mdz: yes, fixing it is not desirable if we fix it postrelease
[16:45] <ttx> mdz: since the ec2-init fix introduces a bug for specific cases
[16:45] <mdz> ttx, we only need to fix it in ec2-init OR eucalyptus, right?
[16:45] <ttx> yes
[16:45] <mdz> in which case I say we should fix it in eucalyptus
[16:45] <kirkland> mdz: i agree -> eucalyptus is where the fix belongs
[16:45] <ttx> mdz: i'l update the bug to reflect that, thanks for your inpit
[16:45] <ttx> input even
[16:46] <mdz> ttx, kirkland, please pass this upstream right away
[16:46] <kirkland> mdz: i've already emailed and pinged nurmi
[16:47] <ttx> and nekro_ just proposed a fix
[16:47] <nekro_> ttx: yes, just committed it. please let me know if it works
[16:49] <heath|work> my sudo issue: http://pastebin.com/d1b1a865d
[16:49] <ttx> nekro_: I won't be able to test it before the end of my day, maybe kirkland will
[16:50] <kirkland> nekro_: i'll gladly test it; however, i'm not able to run instances at the moment
[16:50] <kirkland> ubuntu@cloud:~$ euca-run-instances -k mykey emi-E60E17EC -t c1.medium
[16:50] <kirkland> FinishedVerify: Trying to allocate an address which is already pending: Address [cluster=canyonedge, instanceAddress=pending, instanceId=pending, name=192.168.1.30, pending=true, state=unallocated, userId=eucalyptus]
[16:54] <ttx> kirkland: I added a release notes task
[16:55] <TeTeT> how can I tell the frontend, specifically cc to bind to a specific network interface?
[16:59] <Reepicheep> does anyone know what I have to do to increase the max open files?
[16:59] <Reepicheep> I've added it to /etc/security/limits.conf and also make sure pam_limits.so is required in /etc/pam.d/common-session
[16:59] <Reepicheep> but it doesn't seem to work
[17:00] <heath|work> What group do you need to be in to be allowed to sudo?
[17:00] <Reepicheep> I need dovecot to be able to open more files
[17:01] <Reepicheep> in limits.conf I added a soft and hard limit with the * filter
[17:01] <JanC> heath|work: 'admin' (you can see that in /etc/sudoers)
[17:03] <heath|work> JanC: do you think it is safe to add www-data to the admin group?
[17:03] <heath|work> I need to exec chown as www-data
[17:03] <SyL> is the new ubuntu karmic beta give you a working eualyptus cloud?
[17:04] <JanC> heath|work: why would you need to do that?
[17:08] <anothernoob> hi ppl
[17:10] <heath|work> JanC: so I can keep quotas accurate with uploaded files
[17:11] <JanC> heath|work: why not sudo as your normal user?
[17:12] <heath|work> I was trying to use php's own chown() function, but I may have to end up using exec() in which I could do that
[17:13] <JanC> if your webserver needs to run a script that can run that as root, then configure sudo specifically to allow running that exact command and nothing else
[17:17] <JanC> I mean, allow www-data to only run that command as root
[17:18] <heath|work> that's what I have www-data ALL=NOPASSWD: /bin/chown
[17:19] <JanC> I'd suggest you also limit the parameters  ;)
[17:19] <JanC> and even the directories on which it's allowed to run  ;)
[17:21] <JanC> there are some examples in man sudoers showing how to do that
[17:25] <heath|work> Yeah I have it limited big time at this point
[17:25] <smoser> kirkland, see my comment in bug 461156.
[17:25] <kirkland> smoser: about base64 -d ?
[17:25] <kirkland> smoser: that you confirmed that it's encoded twice?
[17:26] <smoser> yeah, that euca-run-instances is the issue
[17:26] <smoser> i'm looking at euca2ools, and i *htink* that you can just
[17:27] <smoser> -	if user_data:
[17:27] <smoser> -	    user_data = base64.urlsafe_b64encode(user_data)
[17:27] <smoser> -        euca_conn = euca.make_connection()
[17:27] <heath|work> JanC: here is the issue I am having
[17:27] <kirkland> smoser: okay, i'm having serious issues with my production system
[17:27] <heath|work> http://pastebin.com/d1b1a865d
[17:27] <kirkland> smoser: i can't do anything until i fix that
[17:27] <kirkland> smoser: this is why i'm dropping on/off irc
[17:27] <kirkland> smoser: my production server is a hardy vm, which is crashing
[17:30] <JanC> heath|work: according to your sudoers, you need to use something like /var/www/file.txt or /var/www/subdir/file.txt instead of file.txt  ;)
[17:38] <heath|work> ahhh full path. I will try that tx
[17:45] <smoser> kirkland, i'm 99.3% sure that the fix is listed there in that bug. but it really does need to be fixed in euca2ools
[17:47] <nekro_> smoser: so if the data were base64 encoded once, would it work?
[17:47] <nekro_> smoser: I'm trying to figure out if it is an issue with eucalyptus or euca2ools
[17:47] <ajtanus> ciao a tutti
[17:47] <nekro_> smoser: or both
[17:47] <ajtanus> hello
[17:47] <ruben23> hi is it possible to used alias on ethernet card on my linux server, eth0, eth0:0
[17:48] <ajtanus> my gps garmin edge705 doesn't run in ubuntu
[17:48] <smoser> nekro_, read my final comment there.
[17:49] <smoser> its a bug in euca2ools
[17:49] <nekro_> smoser: and not in eucalyptus? in that case I need to revert the latest "fix" to eucalyptus.
[17:49] <smoser> i can imagine that htis is a matter of boto now encoding user data for you when it didn't before
[17:49] <nekro_> smoser: that is likely
[17:49] <smoser> nekro_, correct. there is nothing wrong with eucalyptus . at least thats what i think.
[17:50] <smoser> nekro_, your fix to euca likely breaks usage of euca and ec2tools
[17:50] <smoser> ec2-api-tools
[17:50] <garymc> [TK]D-Fender : sorry to bother you, i dont have my notes with me at home and I cant remeber the dial pattern you helped me with. It was something like x.T|xx.T etc can you remeber?
[17:50] <smoser> unless you're checking for "is this double encoded".. but anyway you look at it, i'm fairly certain the fix is to remove 2 lines in euca-run-instances
[17:51] <nekro_> smoser: it was added there because a user complained that user data was not being encoded but it could be an issue with an older boto
[17:55] <smoser> nekro_, http://code.google.com/p/boto/source/browse/trunk/boto/ec2/connection.py?r=180
[17:55] <smoser> "Forgot to Base64 encode the UserData
[17:55] <smoser> parameter to RunInstances.  Fixes
[17:55] <smoser> Issue-47."
[17:55] <elyezer> can I use webmin in a production server?or It's a security issue
[17:55] <elyezer> ?
[17:57] <kees> I don't recommend webmin.
[18:01] <nekro_> bug #461301
[18:04] <ninjah> kees: What about ebox?
[18:04] <kees> ninjah: I've heard it's better.  soren might know more, IIRC
[18:05] <ninjah> kees: People told me to switch from webmin to ebox. I haven't tried it yet.
[18:14] <qman__> webmin isn't supported by ubuntu because of what it does to the configuration files
[18:14] <qman__> ebox is supported
[18:16] <genii> It bugs me that the latest Linux Pro magazine has instructions for webmin install to Ubuntu
[18:19] <genii> Oct issue, sorry, not Nov or Dec
[18:41] <axisys> I just changed the eth0 to 100 full .. zince switch has no auto.. and it took the change per ethtool eth0.. i did that using the command
[18:41] <axisys> ethtool -s eth0 speed 100 duplex full autoneg off
[18:41] <axisys> how do I make the change so it survive the reboot ?
[18:48] <garymc> If i have 2 web servers on the same outside IP I can only assign one of them to port 80, how do i get to the other from the outside too?
[18:48] <Reepicheep> axisys: you may want to ad it to the rc.local file
[18:50] <Reepicheep> garymc: connect to the port the other is listening on.. "http://server.domain.name:81" where 81 is the port number
[18:51] <axisys> Reepicheep: i was wondering if i can add it to /etc/network/interface file
[18:52] <Reepicheep> I'm not aware of a way to set it in the interface file.  But that doesn't mean that there isn't one
[18:53] <Reepicheep> I know you can set stuff like MTU in the interface file. I just have never see speed & duplexing set there
[18:54] <Reepicheep> I don't see anything in the interfaces man file either
[18:54] <genii> You can use some post-up directive in the interfaces file to run whatever command you want, ethtool, whatever
[18:55] <axisys> genii: sweet!
[18:55] <axisys> genii: thanks
[18:55] <genii> np
[18:57] <axisys> genii: i was looking for the post-up dir .. should I just create it under /etc/network ?
[18:57] <garymc> Reepicheep: so i assign port 81 to the other server?
[18:58] <genii> axisys: directive, not directory. So in /etc/network/interfaces some stanza under eth0 for instance like:  post-up /somewhere/somecommand -options -to -that -command
[18:58] <axisys> genii: sorry
[18:59] <axisys> /usr/share/doc/ifupdown/examples/network-interfaces.gz is pretty helpful
[19:00] <Reepicheep> garymc: you can assign it what ever port you choose.  you probably just don't want to put it on a standard port used by other services
[19:00] <Reepicheep> and possibly above 1024 depending on what user starts the web server
[19:01] <Reepicheep> I just pulled port 81 out of the air
[19:03] <axisys> genii: do I need to mention the device w/ ethtool when doing post-up for the stanza of that interface?
[19:03] <axisys> genii: post-up /usr/sbin/ethtool -s eth0 speed 100 duplex full autoneg off .. like this ?
[19:03] <genii> axisys: Whatever command you normally run like earlier you put: ethtool -s eth0 speed 100 duplex full autoneg off                  is what you put again
[19:04] <genii> (with full path however, like you had just above)
[19:05] <axisys> up /usr/sbin/ethtool -s eth0 speed 100 duplex full autoneg off  .. seems to be right syntax.. i just found out there is no post-up.. up is what run the command .. there is only pre-up and post-down.. just an fyi
[19:06] <garymc> ok i assigned port 81 to my other web server on the router firewall.
[19:07] <garymc> I put ip addres in browser e.g. 81.234.567.888:81
[19:07] <garymc> and I get nothing
[19:07] <Reepicheep> garymc: make sure you also configure the web server on the host to listen on port 81 instead of the default port 80
[19:08] <garymc> ahhh ok
[19:08] <garymc> how do i do that?
[19:08] <Reepicheep> and make sure that you have it allowed through the host based firewall if you have a firewall running
[19:09] <Reepicheep> garymc: what web server are you using?
[19:09] <garymc> apache
[19:09] <Reepicheep> and what is the other web server on the same host?
[19:10] <garymc> ??
[19:10] <Reepicheep> the one that is already listening on port 80?
[19:10] <garymc> no differnt machine
[19:10] <garymc> its a seperate machine
[19:10] <garymc> can i make it listen for both ports?
[19:10] <garymc> 80 and 81?
[19:11] <Reepicheep> you probably don't need to .. it just needs to be setup correctly in the router
[19:12] <garymc> Well iforwaded port 81 in the routers firewall to the server I want to access
[19:12] <garymc> but when i put ip addy:81 in browser it doesnt work
[19:12] <Reepicheep> just set the port nat to forward some high port to port 80 on the second server..  how to do that is probably quite a bit off topic for this channel
[19:13] <Reepicheep> it really depends on what nat router you have?
[19:13] <garymc> Well ive done that already
[19:14] <Reepicheep> and internally you will still connect to it via port 80 .. only externally with the PNAT work
[19:30] <smoser> mdz, ttx, ping
[19:30] <smoser> regarding bug 461156
[19:30] <ttx> smoser: pong
[19:30] <smoser> you follow that, ttx ?
[19:31] <smoser> is it 100% unacceptable to fix this in 9.10 release by changing euca2ools ?
[19:31] <smoser> i'll never say something is regression-potential free, but we've fairly clearly identified what is wrong here
[19:32] <ttx> smoser: mdz said that if its not a regression it should be fixed in an early post-release update
[19:32] <kirkland> smoser: you want me to teach you how to do an SRU?
[19:32] <smoser> i dont know if its a regression or not.
[19:33] <kirkland> smoser: we'll fix this in an update
[19:33] <smoser> actually, i know that it is not
[19:33] <kirkland> smoser: i'll show you how :-)
[19:33] <kirkland> smoser: this fix does not *have* to be on the released CD
[19:34] <smoser> euca2ools was not in jaunty, so it is not a regression.
[19:34] <ttx> smoser: and it never worked in a previous kermic release either
[19:34] <smoser> and ec2-api-tools in universe can be pointed at euca to work around.
[19:35] <smoser> so the, the right answer is "fix in SRU in euca2ools package"
[19:35] <smoser> ttx, are you around and able to test something for me ? on UEC ?
[19:36] <ttx> around, but not able to test on UEC
[19:36] <ttx> unless I shift to high prio mode :)
[19:39] <smoser> ttx, ok. i will test on ec2 and on uec and likely have what i believe fairly safe fix for ec2-init for bug 458850
[19:40] <garymc> anyone know how I restart httpd?
[19:41] <garymc> in the CLI?
[19:41] <ttx> smoser: good. If there is anything I can test tomorrow morning let me know
[19:41] <smoser> if all goes well, you would expect that i can get this sponsored, uploaded, built ?
[19:41] <ttx> smoser: if reasonably sure keep the release team updated so that we get a daily image to validate ?
[19:41] <smoser> ttx, ?
[19:41] <ttx> smoser: yes
[19:42] <smoser> k
[19:46] <kirkland> smoser: i will help you get it sponsored and tested
[19:47] <kirkland> smoser: in the reverse order, tested, then sponsored
[19:47] <kirkland> smoser: i am reinstalling my UEC now
[19:47] <smoser> kirkland, k
[19:49] <kirkland> smoser: okay, first, let's get your fixed euca2ools pushed to your ppa
[19:50] <kirkland> smoser: on the end of the version, add a ".1" iterator
[19:50] <kirkland> 1.0+bzr20091007-0ubuntu1.1
[19:50] <kirkland> smoser: and since you're going to send it to your ppa, add a ~ppa1 iterator to the end of that
[19:50] <kirkland> 1.0+bzr20091007-0ubuntu1.1~ppa1
[19:51] <smoser> kirkland, if its post release, not terribly worried about that right now.
[19:51] <smoser> i need to get the other stuff tested and in
[19:51] <kirkland> smoser: hmm, okay; we should prep that upload soon, though
[19:51] <smoser> y
[19:51] <smoser> yes
[19:53] <kirkland> smoser: it shouldn't take but 5 minutes to upload it to your ppa
[19:53] <kirkland> smoser: i'll pull from there, test it, and sponsor for you
[19:53] <smoser> ok.
[19:56] <mathiaz> smoser: is it normal that all UEC instances that I boot have the same hostname (172) ?
[19:56] <mathiaz> smoser: same instances of the same EMI
[19:57] <smoser> i see that here, mathiaz
[19:57] <smoser> i believe that the dhcp server is telling the instance that that is its hostname
[19:58] <mathiaz> smoser: I don't think so
[19:58] <smoser> where do you think its coming from?
[19:58] <mathiaz> smoser: on the CC /var/run/eucalyptus/net/euca-dhcp.conf
[19:58] <mathiaz> smoser: there isn't anything related to hostname
[19:59] <mathiaz> smoser: I'd guess ec2-init
[20:00] <mathiaz> smoser: in /usr/share/pyshared/ec2init/__init__.py
[20:00] <mathiaz> smoser: it comes from the metadata service
[20:01] <mathiaz> smoser: I guess that UEC metadata service gives out D.D.D.D as the local-hostname
[20:02] <mathiaz> smoser: whereas EC2 give a hostname like D-D-D-D.domain.name
[20:02] <smoser> yeah, i see that.
[20:03] <smoser> ec2:
[20:03] <smoser> $ wget http://169.254.169.254/1.0/meta-data/hostname -q -O -; echo
[20:03] <smoser> ip-10-242-63-240.ec2.internal
[20:03] <smoser> uec:
[20:03] <smoser> $ wget http://169.254.169.254/1.0/meta-data/hostname -q -O -; echo
[20:03] <smoser> (no output)
[20:04] <smoser> actually, the above should have been 'local-hostname'
[20:04] <smoser> but still no output on uec
[20:05] <smoser>     def get_hostname(self):
[20:05] <smoser>         hostname = self.get_instance_metadata()['local-hostname']
[20:05] <smoser>         hostname = hostname.split('.')[0]
[20:05] <smoser>         return hostname
[20:05] <mathiaz> smoser: well - may be boto is doing something
[20:06] <mathiaz> smoser: because ec2-init should fail if the output was empty
[20:06] <smoser> you're right.
[20:06] <smoser> boto is returning the ip addr
[20:06] <smoser> and get_hostname taking the first piece
[20:08] <mathiaz> smoser: so I guess that's a bug in UEC metadata service
[20:12] <smoser> kirkland, you wanted my ec2-init to ppa ?
[20:12] <kirkland> where's the fix?  I thought it was in euca2ools?
[20:20] <smoser> kirkland, bug 461156 is to be fixed post-release (SRU) in euca2ools.
[20:21] <smoser> bug 458850 and bug 458576 are to be fixed pre-release (NOW) in ec2-init
[20:21] <kirkland> smoser: ah, okay
[20:21] <kirkland> smoser: i'll help you with both of those
[20:24] <kirkland> smoser: okay, for 458576... can you attach the patch you want sponsored into that bug?
[20:24] <mathiaz> kirkland: didn't we fix euca_find_cluster in the installer to use the ip published by avahi-publish?
[20:25] <kirkland> mathiaz: yes
[20:25] <mathiaz> kirkland: hm - bug 458904
[20:25] <smoser> kirkland, lets test that, along with bug 458850 fix
[20:25] <smoser> patch is http://paste.ubuntu.com/302282/
[20:25] <mathiaz> kirkland: I've reproduced it and will update the description as it's clear what happens
[20:26] <mathiaz> kirkland: but basically euca_find_cluster returns on of the public IP addresses
[20:26] <kirkland> smoser: is that the suggested patch attached to the bug?
[20:26] <kirkland> mathiaz: huh?
[20:26] <smoser> kirkland, it fixes both
[20:27] <mathiaz> kirkland: http://paste.ubuntu.com/302286/
[20:27] <mathiaz> kirkland: this is the network configuration of the CC
[20:27] <mathiaz> kirkland: euca_find_cluster in the installer return 192.168.222.12 as the ip of the CC
[20:28] <kirkland> smoser: the patch in the pastebin ... could you please make sure that's the patch attached to the bug?
[20:28] <kirkland> smoser: launchpad is authenticated; pastebin's are not
[20:28] <kirkland> smoser: i will pull your patch from launchpad, not a pastebin
[20:28] <smoser> ok. thats fine.
[20:28] <mathiaz> kirkland: http://paste.ubuntu.com/302287/ - while avahi-publish publishes the correct IP address of the CC
[20:28] <smoser> but i'm not saying you should uploda it at this point
[20:28] <smoser> you should test it first.
[20:29] <kirkland> smoser: right, i will test it first
[20:30] <kirkland> mathiaz: do you have a fix in mind?
[20:30] <kirkland> mathiaz: i'm juggling several other things at the moment, don't really have time to troubleshoot that right now
[20:31] <mathiaz> kirkland: ok - I'll look into it
[20:31] <kirkland> smoser: let's prepare both of those fixes in parallel
[20:31] <kirkland> smoser: we'll upload the ec2init one first, for karmic
[20:32] <kirkland> smoser: and prep the euca2ools one for -updates
[20:32] <smoser> there isn't really a reason to wory about euca2ools right now
[20:32] <smoser> is there?
[20:32] <kirkland> smoser: but we can knock them both out now
[20:32] <smoser> lets get ec2init fixed
[20:34] <kirkland> smoser: i'm re-installing my UEC now
[20:36] <jafo1> Hi all. I got a strange problem with ubuntu 8 lts and softraid. I got 3 raid1 partitions. If I set one disc as fail, at next reboot the rebuild process does'nt start automagically.. I need to start it by hand doing mdadm --manage --add...
[20:36] <jafo1> any hint?
[20:37] <jafo1> (I tweaked the initramfs-tools to let the system boot with degraded array as well)
[20:38] <jafo1> I remember that it was a default to automagically rebuild degraded arrays on boot..I'm I wrong?
[20:41] <jafo1> oopss.. I'm back..
[20:44] <yann2> sorry for the bump: I am currently using ubuntu hardy with Puppet on quite a few servers, although it is from universe. I am thinking of moving to chef in a close future. What are Ubuntu plans regarding automated deployments and configuration, is one tool going to make it into main for 10.4?
[20:45] <jafo1> I got a problem with mdadm softraid, I cant' get the md arrays automagically start rebuilding at boot time. I got a problem with 3 raid1 array on a hp sata server.. the rebuild starts only by hand with mdadm --manage --add.....
[20:45] <jafo1> can I fix this?
[20:46] <kirkland> yann2: -> mathiaz
[20:46] <jafo1> I need that md arrays starts rebuild at boot time (and that the system boots with degraded arrays)
[20:46] <mathiaz> yann2: puppet is in main starting from karmic
[20:47] <fbc-mx> How can I make a USB startup from ubuntu-9.04-server-i386 image? I tried the USB Creator on ubuntu desktop, but I only get the BOOT: prompt
[20:47] <yann2> thx kirkland , just thinking abuot moving from puppet to chef, but my choice might depend on ubuntus
[20:47] <yann2> mathiaz, does puppetd still leak?
[20:47] <mathiaz> yann2: I don't know - bug number?
[20:47] <yann2> is in hardy so universe, didnt report it yet as not officially supported
[20:48] <yann2> but have seen quite a few reports about this on channels and blogs
[20:48] <yann2> (for more recent versions)
[20:49] <yann2> using puppet right now, but that leak kind of cooled my ambitions :)
[20:50] <yann2> mathiaz, just out of pure interest, why did you chose puppet over the other solutions? I am still undecided :)
[20:50] <mathiaz> yann2: puppet has been around for much longer than chef
[20:50] <mathiaz> yann2: the maintainance in debian is good (google is behind)
[20:50] <yann2> ok that makes sense
[20:51] <mathiaz> yann2: ubuntu users are more using puppet than chef
[20:51] <yann2> is it safe to assume it will still be in main for 10.4 then? :)
[20:52] <mathiaz> yann2: yes
[20:52] <jafo1> no one experienced my problem?
[20:52] <yann2> ok thanks a lot then ;) this is good news, such a software was definitely needed
[20:54] <kirkland> smoser: reviewed your patch; code looks good
[20:54] <smoser> but its bad
[20:54] <kirkland> smoser: i'm downloading karmic-uec-amd64 now
[20:54] <kirkland> smoser: sure, it's a hack
[20:54] <smoser> just checked, i typoed slomething in copy
[20:54] <smoser> so ssh patch doesn't work
[20:55] <kirkland> smoser: i haven't tested it yet
[20:55] <kirkland> smoser: you have an update coming?
[20:55] <smoser> yes. attaching now.
[20:56] <ahe> someone knows where the debian/ dir of vmbuilder moved?
[20:59] <fbc-mx> any ideas on how to get ubuntu serer to install from a usb stick??
[21:00] <jafo1> I need an mdadm expert..
[21:00] <ScottK> fbc-mx: You should be able to use usb-creator to put the ISO stuff on a stick
[21:01] <fbc-mx> ScottK, yeah, I did however all I get is a BOOT: prompt it doesn't go any further...
[21:02] <ScottK> Dunno.  I've only done it on netbooks, so I can't say
[21:16] <smoser> kirkland, update is attached.
[21:16] <smoser> i've tested on 4 cases on uec
[21:16] <kirkland> smoser: i'm still downloading the image
[21:16] <smoser> k.
[21:17] <Guest16233> is there a nice way to turn off ipv6 in ubuntu-server?
[21:17] <kirkland> smoser: that diff is dirty
[21:17] <kirkland> smoser: includes the previous diff too
[21:17] <kirkland> http://launchpadlibrarian.net/34426991/fix.debdiff
[21:17] <smoser> its a replacement
[21:18] <smoser> identical except for 4 chars
[21:18] <smoser> maybe 5
[21:18] <smoser> 2>&1
[21:18] <kirkland> smoser: scroll down
[21:18] <kirkland> +++ ec2-init-0.4.999/fix.debdiff	2009-10-26 16:30:45.000000000 -0400
[21:18] <smoser> oh. i see.
[21:19] <jafo1> could be enough to update initramfstools to load raid1 module?
[21:27] <jafo1> hey.. any md-raid expert here?
[21:27] <smoser> kirkland, new version is attached there now.
[21:28] <smoser> and i've tested this on ec2 anad uec.
[21:28] <smoser> it functtions as i expect it to
[21:28] <smoser> kirkland, i've got to step out for a while. if you can test that, please do.
[21:29] <smoser> instructions for doing so are in the bug there.
[21:31] <smoser> soren, zul your thoughts on patch attached to bug 458576 would be appreciated. i think its generally sane, and i've tested on ec2 and uec
[21:31] <smoser> that patch should fix bug 458850 and the bug its attached to.
[21:31] <smoser> i have  to step away for a while.
[21:31] <smoser> kirkland, call cell if you need.
[21:39] <kirkland> smoser: okay, i'm running the instance now
[21:39] <kirkland> smoser: whoa, i just missed you
[21:42] <Guest16233> is there a way to re generate the keys on the front end? all my pem files are empty
[21:45] <nekro_> SyL: you can deregister clusters/SCs, walrus. stop the front end. then delete the pem files everywhere and delete euca.p12. restart the front end
[21:45] <nekro_> SyL: and re-register everything
[21:47] <smoser> kirkland, you still around ?
[21:47] <kirkland> smoser: yessir
[21:47] <SyL> nekro_: ok, trying it now
[21:47] <kirkland> smoser: quick phone sync?
[21:47] <smoser> sure
[21:47] <kirkland> smoser: i want to knock this out, and knock off for the day
[21:56] <SyL> nekro_: euca_conf --no-rsync --discover-nodes, just rsyncs keys to 127.0.0.1 for some reason
[22:03] <nekro_> SyL: I don't know how that works. I'd try manually registering a node with euca_conf --register-nodes <ip>
[22:04] <SyL> nekro_: ok, I'll try it again
[22:06] <SyL> INFO: We expect all nodes to have eucalyptus installed in //var/lib/eucalyptus/keys for key synchronization.
[22:06] <SyL> warning: //var/lib/eucalyptus/keys//node-cert.pem doesn't exists!
[22:07] <SyL> yeah, again, the keys aren't being generated
[22:09] <SyL> forget it, I'm just going to format it and reinstall again.
[22:09] <SyL> this is geting old
[22:10] <nekro_> SyL: perhaps you should stick with Jaunty or wait until the Karmic setup is stable.
[22:12] <SyL> nekro_: Jaunty eucalyptus wasn't working for me either. I've gotten farther in karmic using euca 1.6 then 1.5
[22:12] <SyL> 1.5 I got things launching, but couldn't get the network to work, and in 1.6, everything works most of the time.
[22:46] <zzz2009> test:)