| ruben23 | hi, how do i create lvm on my vg..in command line | 00:01 |
|---|---|---|
| cemc | ruben23: you mean LV in an existing VG? | 00:05 |
| ruben23 | cemc: yes i have exixting VG | 00:06 |
| cemc | ruben23: man lvcreate | 00:06 |
| ruben23 | cemc: i would like to increase my /var/ cemc: | 00:07 |
| ruben23 | http://pastebin.com/m445a6846 | 00:07 |
| === erichammond1 is now known as erichammond | ||
| cemc | ugh, how I hate the default VG and LV names :) should be something more like dev/mapper/<hostname>/<partition_name>, IMHO | 00:10 |
| cemc | ruben23: resizing is not creating, you have to look that up on the net. I've done that a couple of times, but I'm not 100% sure how, was some time ago | 00:11 |
| cemc | ruben23: but if you have the space and time, I would create another bigger LV for /var and copy it, then delete the old one. not a fan of resizing ext3 (or any fs for that matter), dunno why. should be safe tho | 00:12 |
| mathiaz | kirkland: hey - did you run the new eucalyptus.conf files system via upstream? | 00:18 |
| kirkland | mathiaz: i did | 00:19 |
| kirkland | mathiaz: nurmi wants me to get rid of /usr/share/* | 00:19 |
| mathiaz | kirkland: ok - so the issue I see is that the CC is not able to load its configuration file | 00:19 |
| kirkland | mathiaz: and just put that stuff into /etc/eucalyptus/eucalyptus.conf | 00:19 |
| mathiaz | kirkland: right - the cluster.c file only knows about *two* configuration file | 00:19 |
| kirkland | mathiaz: yeah, i'm sorry i didn't update you | 00:19 |
| kirkland | mathiaz: nurmi implemented half of it | 00:19 |
| kirkland | mathiaz: while i implemented the other half | 00:20 |
| kirkland | mathiaz: but we miscommunicated on the file names | 00:20 |
| mathiaz | kirkland: so the whole include stuff doesn't work since the cluster config parser doesn't understands includes | 00:20 |
| kirkland | mathiaz: and the design changed, after i talked to him, was my multi-hour conversation with you and slangasek | 00:20 |
| kirkland | mathiaz: right, it just looks for KEY=VALUE | 00:20 |
| * mathiaz would just suggest to use yam; | 00:20 | |
| * mathiaz would just suggest to use *yaml* | 00:21 | |
| mathiaz | kirkland: so what's the current plan | 00:21 |
| mathiaz | kirkland: ? | 00:21 |
| kirkland | mathiaz: well, i told nurmi that i need to collect my notes to recollect why we needed 3, and not just 2 | 00:22 |
| kirkland | mathiaz: i remember i lost the argument in favor of just 2 files | 00:22 |
| kirkland | mathiaz: but i don't recall which reason was the reason i finally gave in to | 00:22 |
| mathiaz | kirkland: right - in order to be able to stick new default options without prompting for a conffile | 00:22 |
| mathiaz | kirkland: if new options are available and need to be defined, we'd rather not update eucalyptus.conf which is a conffile | 00:23 |
| mathiaz | kirkland: that being said we could update eucalyptus-local.conf programatically | 00:23 |
| mathiaz | kirkland: ie from the upgrade script | 00:24 |
| kirkland | mathiaz: it certainly sounds like upstream would prefer it this way | 00:24 |
| mathiaz | kirkland: since eucalyptus-local.conf should not be modified by the end user (even though we should take care of keeping local changes - just to follow the debian policy) | 00:24 |
| kirkland | eucalyptus.conf and eucalyptus-local.conf | 00:24 |
| mathiaz | kirkland: ok - so to accomodate both upstream and the debian policy I'd suggest to move eucalyptus-local.conf to /var/lib/eucalyptus/ | 00:25 |
| mathiaz | kirkland: and have all the default options set in eucalyptus-local.conf | 00:25 |
| mathiaz | kirkland: maintainer scripts and euca_conf write to eucalyptus-conf | 00:26 |
| mathiaz | kirkland: maintainer scripts and euca_conf write to eucalyptus-local.conf | 00:26 |
| mathiaz | kirkland: if new options are needed, we can mangled eucalyptus-local.conf | 00:26 |
| kirkland | mathiaz: okay | 00:26 |
| mathiaz | kirkland: probably using a token to delimit the section updated by euca_conf | 00:27 |
| kirkland | mathiaz: how much effort do you suggest i put in supporting upgrades from today's version to the next version? | 00:27 |
| mathiaz | kirkland: none | 00:27 |
| kirkland | mathiaz: i'm inclined to call today's bust | 00:27 |
| kirkland | okay | 00:27 |
| kirkland | mathiaz: i can handle this, i think | 00:27 |
| kirkland | mathiaz: so what was going to /usr/share/eucalyptus/eucalyptus-defaults.conf now get's put into /etc/eucalyptus/eucalyptus.conf (as a conffile) | 00:28 |
| mathiaz | kirkland: the package has been in the archive for just one day | 00:28 |
| kirkland | mathiaz: right | 00:28 |
| mathiaz | kirkland: and it's a developement version - we do our best effort | 00:28 |
| mathiaz | kirkland: hm nope - /usr/share/eucalyptus/eucalyptus-defaults.conf goes into /var/lib/eucalyptus/eucalyptus-local.conf | 00:28 |
| mathiaz | kirkland: /etc/eucalyptus/eucalyptus.conf stays at it is | 00:29 |
| mathiaz | kirkland: /etc/eucalyptus/eucalyptus.conf stays *as* it is | 00:29 |
| mathiaz | kirkland: maintainer scripts and euca_conf should *not* touch /etc/eucalyptus/eucalyptus.conf | 00:29 |
| mathiaz | kirkland: /etc/eucalyptus/eucalyptus.conf is the override, while /var/lib/eucalyptus/eucalyptus-local.conf is the default configuration file | 00:29 |
| kirkland | mathiaz: WTF goes in eucalytpus.conf then? | 00:29 |
| mathiaz | kirkland: what's in it now | 00:30 |
| kirkland | mathiaz: as of yesterday, everything (monolithic config file) | 00:30 |
| kirkland | mathiaz: as of today, 2 lines, sourcing -defaults and then -local | 00:30 |
| kirkland | mathiaz: as of tomorrow .... ???? | 00:30 |
| mathiaz | kirkland: tomorrow: 1 line sourcing /var/lib/eucalyptus/eucalyptus-local.conf | 00:31 |
| kirkland | mathiaz: installed by dpkg as a conf file? | 00:31 |
| mathiaz | kirkland: and /var/lib/eucalyptus/eucalyptus-local.conf is the merge of eucalyptus-local.conf and eucalyptus-default.conf | 00:31 |
| mathiaz | kirkland: yes | 00:31 |
| mathiaz | kirkland: today's /etc/eucalyptus/eucalyptus.conf is all good IMO | 00:31 |
| kirkland | mathiaz: and when we add a new option | 00:32 |
| mathiaz | kirkland: (modulo the source change) | 00:32 |
| kirkland | mathiaz: we add it to the manpage | 00:32 |
| kirkland | mathiaz: and mangle -local in the maintainer scripts? | 00:32 |
| mathiaz | kirkland: yes! :) | 00:32 |
| kirkland | mathiaz: okay | 00:32 |
| kirkland | mathiaz: i'll make it happen | 00:32 |
| kirkland | mathiaz: you're not particular about eucalyptus-local.conf vs. eucalyptus.local.conf ? | 00:33 |
| kirkland | mathiaz: nurmi's code does eucalyptus.local.conf | 00:34 |
| mathiaz | kirkland: not all all | 00:34 |
| mathiaz | kirkland: right - noticed that | 00:34 |
| mathiaz | kirkland: I'm testing the new setup discussed above | 00:34 |
| kirkland | mathiaz: his code also sources /etc/eucalyptus/eucalypts.local.conf, which i'll put a symlink there to /var | 00:34 |
| mathiaz | kirkland: (ie eucalyptus.conf and a merged eucalyptus.local.conf) | 00:34 |
| kirkland | mathiaz: btw, does your -cc preseed file work? | 00:34 |
| kirkland | mathiaz: i'm using your eucalyptus values there and i'm not getting a cloud installation | 00:35 |
| mathiaz | kirkland: :) - haven't tested it for a while | 00:35 |
| mathiaz | kirkland: right - that's very well possible | 00:35 |
| mathiaz | kirkland: the debconf questions have probably changed | 00:35 |
| kirkland | mathiaz: okay | 00:35 |
| kirkland | mathiaz: does order matter at all in preseed files? | 00:35 |
| mathiaz | kirkland: I don't think so | 00:36 |
| kirkland | mathiaz: hrm, okay | 00:36 |
| mathiaz | kirkland: the preseed file is read at once and all the values are dumped in the debconf database | 00:36 |
| kirkland | mathiaz: right, that's what i figured | 00:36 |
| kirkland | mathiaz: my node preseed is working well, but not the clc/cc/sc/walrus | 00:36 |
| mathiaz | kirkland: the relevant scripts access the debconf database, not the preseed file | 00:36 |
| * kirkland kinda wishes eucalyptus worked more that way :-) | 00:37 | |
| mathiaz | kirkland: hm - thinking about the filenames | 00:40 |
| mathiaz | kirkland: .local.conf seems counter-intuitive | 00:40 |
| mathiaz | kirkland: as .local.conf is the file edited by euca_conf and the maintainer scripts | 00:40 |
| mathiaz | kirkland: how about switching the two? | 00:41 |
| mathiaz | kirkland: eucalyptus.conf not being a conffile anymore | 00:41 |
| mathiaz | kirkland: and eucalytpus.local.conf is a conffile | 00:41 |
| mathiaz | kirkland: to be edited by the local sysadmin | 00:42 |
| mathiaz | kirkland: eucalyptus.conf would then source .local.conf at the *end* | 00:42 |
| mathiaz | kirkland: and point the sysadmin to edit .local.conf instead | 00:42 |
| kirkland | mathiaz: why have .local.conf at all? | 00:43 |
| kirkland | mathiaz: why not just make eucalyptus.conf not a conf file | 00:43 |
| kirkland | mathiaz: when we need to add something to it, we just jam it in | 00:43 |
| mathiaz | kirkland: well - if we do so we need to make sure that local modifications are kept | 00:44 |
| mathiaz | kirkland: when new options are added | 00:44 |
| * kirkland has grown exhausted of this "challenge" | 00:45 | |
| mathiaz | kirkland: it's possible - the logic in the maintainer scripts can get ugly though | 00:45 |
| mathiaz | kirkland: I totally understand you | 00:45 |
| mathiaz | kirkland: it's complicated | 00:46 |
| kirkland | mathiaz: at the end of the day, eucalyptus does not "source" these files | 00:46 |
| kirkland | mathiaz: it does a crappy job parsing them instead | 00:46 |
| kirkland | mathiaz: for that reason, cascading any set of sourcing/including just doesn't fit eucalyptus' model | 00:46 |
| * mathiaz nods | 00:46 | |
| mathiaz | kirkland: aren't the upstart job sourcing it? | 00:46 |
| Sam-I-Am | mathiaz: did you see my note earlier about being out of whack for a few months? | 00:47 |
| kirkland | mathiaz: ubuntu's code does, eucalyptus' code does not | 00:47 |
| mathiaz | Sam-I-Am: yes - that's life | 00:47 |
| Sam-I-Am | k, just wanted to make sure | 00:47 |
| mathiaz | Sam-I-Am: thanks for letting me know though | 00:47 |
| Sam-I-Am | hopefully its going to be fixed in a bit | 00:47 |
| Sam-I-Am | i'm sorry i kinda fell off | 00:47 |
| mathiaz | Sam-I-Am: that's ok - as long as you attend to the more important things ;) | 00:48 |
| mathiaz | Sam-I-Am: I hope everything will turn out well | 00:48 |
| Sam-I-Am | things are starting to look good | 00:48 |
| mathiaz | kirkland: ah ok. | 00:49 |
| Sam-I-Am | should have a job back in the sys/netadmin world soon | 00:49 |
| mathiaz | kirkland: I thought that having eucalyptus.conf was a hard requirement | 00:49 |
| mathiaz | kirkland: so what we could do is to introduce /var/lib/eucalytpus/eucalyptus-defaults.conf | 00:49 |
| mathiaz | kirkland: keep /etc/eucalyptus/eucalyptus.conf as it is now | 00:50 |
| mathiaz | kirkland: and have euca_conf and maintainer scripts modify /var/lib/eucalytpus/eucalyptus-defaults.conf | 00:50 |
| mathiaz | kirkland: and update the ubuntu upstart jobs to source both /var/lib/eucalytpus/eucalyptus-defaults.conf and /etc/eucalyptus/eucalyptus.conf | 00:50 |
| mathiaz | kirkland: that also means updating the upstream source code to use /var/lib/eucalytpus/eucalyptus-defaults.conf as the default configuration file and have /etc/eucalyptus/eucalyptus.conf be the .local.conf file | 00:52 |
| kirkland | mathiaz: hrm | 00:52 |
| mathiaz | kirkland: ie: EUCALYPTUS_CONF_LOCATION=/var/lib/eucalytpus/eucalyptus-defaults.conf | 00:52 |
| mathiaz | kirkland: EUCALYPTUS_CONF_OVERRIDE_LOCATION=/etc/eucalyptus/eucalyptus.conf | 00:53 |
| kirkland | mathiaz: i'm starting to feel more like throwing in the towel ... back to a monolithic /etc/eucalyptus/eucalyptus.conf | 00:53 |
| kirkland | mathiaz: just not a conffile | 00:53 |
| mathiaz | kirkland: that way eucalyptus.conf stays as a conffile | 00:53 |
| kirkland | mathiaz: users, euca_conf, dpkg edits that file | 00:53 |
| kirkland | mathiaz: upstream code stays the same | 00:53 |
| kirkland | mathiaz: we just seed it if it's not there | 00:54 |
| kirkland | mathiaz: and handle new options ad hoc | 00:54 |
| kirkland | mathiaz: we have a manpage now | 00:54 |
| mathiaz | kirkland: the last part may be trickier though | 00:54 |
| kirkland | mathiaz: then we don't handle them at all in dpkg ... we handle them in euca_conf | 00:54 |
| === erichammond1 is now known as erichammond | ||
| kirkland | mathiaz: document them in the manpage | 00:55 |
| kirkland | mathiaz: and force eucalyptus to choose a sane (documented) default if unspecified | 00:55 |
| mathiaz | kirkland: right - does the code currently have sane default if unspecified? | 00:56 |
| kirkland | mathiaz: don't know | 00:56 |
| mathiaz | kirkland: AFAICT no | 00:56 |
| mathiaz | kirkland: as the CC doesn't start with the current empty eucalyptus.conf file | 00:56 |
| mathiaz | kirkland: as the CC doesn't start with the current *almost* empty eucalyptus.conf file | 00:57 |
| kirkland | mathiaz: okay -- in that case, you're instructed to run "euca_conf" | 00:58 |
| kirkland | mathiaz: until you get a eucalyptus.conf that is not empty | 00:58 |
| kirkland | mathiaz: with sufficient configuration to start your cluster | 00:58 |
| mathiaz | kirkland: well - that's how things were in karmic, with euca_conf being run in the postinst script | 00:59 |
| mathiaz | kirkland: the problem is how to handle upgrades | 00:59 |
| mathiaz | kirkland: where you need to add new (default) options | 00:59 |
| mathiaz | kirkland: either we can rely on upstream to do that | 00:59 |
| mathiaz | kirkland: or we can ship a default set of options that can be easily upgraded | 01:00 |
| kirkland | mathiaz: nurmi is here | 01:02 |
| * nurmi waves | 01:02 | |
| mathiaz | nurmi: hi! :) | 01:02 |
| nurmi | mathiaz: hey mathiaz! | 01:02 |
| nurmi | mathiaz: what's up? | 01:02 |
| mathiaz | nurmi: is it snowing down there? | 01:02 |
| mathiaz | nurmi: kirkland and I have been discussing how to handle configuration files in eucalyptus | 01:03 |
| nurmi | mathiaz: heh, hardly | 01:03 |
| nurmi | mathiaz: nod | 01:03 |
| mathiaz | nurmi: IIUC there was one monolitic configuration file (eucalyptus.conf) | 01:03 |
| mathiaz | nurmi: and you've added an override (eucalyptus.local.conf) | 01:04 |
| nurmi | mathiaz: that is correct | 01:04 |
| nurmi | mathiaz: i also think it is important to clearly state how the files are parsed | 01:04 |
| mathiaz | nurmi: IIUC it's key=value | 01:04 |
| nurmi | mathiaz: there are some shell scripts that source the files (init scripts, euca_conf, etc), and, there are some C components that parse the files directly (key=val) | 01:05 |
| mathiaz | nurmi: and isn't actually a shell file | 01:05 |
| nurmi | mathiaz: right, that is the key point | 01:05 |
| mathiaz | nurmi: right - so it's fair to assume that the configuration file are not shell fragment | 01:05 |
| nurmi | mathiaz: yep, in fact, that will potentially break the C parser | 01:05 |
| mathiaz | nurmi: but just key=val pair to keep the lowest commmon denominator | 01:05 |
| nurmi | mathiaz: correct | 01:06 |
| kirkland | nurmi: is it "incorrect" that our upstart scripts (etc) actually source them as if they're shell? | 01:06 |
| nurmi | kirkland: no, the files can be sourced by bash/sh, in that they're just KEY=VAL and comment lines start with '#' | 01:06 |
| mathiaz | nurmi: do the different components of eucalyptus work correclty if there isn't any configuration file? | 01:07 |
| nurmi | hmm | 01:07 |
| mathiaz | nurmi: or rather if configuration files don't have all the options defined | 01:07 |
| mathiaz | nurmi: for example, a new version introduces a new option - what should be done to upgrade existing configuration files? | 01:07 |
| nurmi | mathiaz: oh, sure. There are some options that are used by more than one component, but some are only used by an individual component | 01:07 |
| nurmi | mathiaz: we have been using 'euca_conf --upgrade' to handle config file upgrades | 01:08 |
| nurmi | mathiaz: sorry '--upgrade-conf' | 01:08 |
| mathiaz | nurmi: ok | 01:08 |
| mathiaz | nurmi: --upgrade-conf will add new keys with reasonable default values | 01:09 |
| mathiaz | nurmi: and (may be) remove deprecated keys? | 01:09 |
| nurmi | mathiaz: our common mechanism is to move the old file aside, put in a new default, then run '--upgrade-conf' | 01:10 |
| nurmi | mathiaz: right | 01:10 |
| mathiaz | nurmi: how do you handle local modified options? | 01:10 |
| mathiaz | nurmi: for example, the list of nodes? | 01:10 |
| nurmi | mathiaz: they persist when one uses 'upgrade-conf' | 01:10 |
| mathiaz | nurmi: is this the case for any options, or only of the nodes option? | 01:10 |
| nurmi | mathiaz: so any value that you had before, with a key that is still valid, persists | 01:11 |
| mathiaz | nurmi: ok | 01:12 |
| mathiaz | nurmi: where is the new default file that upgrade-conf uses? | 01:12 |
| mathiaz | nurmi: in /usr/share/eucalyptus/... ? | 01:12 |
| nurmi | mathiaz: no it would be /etc/eucalyptus/eucalyptus.conf | 01:12 |
| mathiaz | nurmi: I meant in the package | 01:13 |
| nurmi | mathiaz: first, we move the existing eucalyptus.conf aside (eucalyptus.conf.orig), then install the new default (eucalyptus.conf), then run '--upgrade-conf' | 01:13 |
| nurmi | mathiaz: that is how our packages do conf upgrades | 01:13 |
| mathiaz | nurmi: and you move the existing eucalyptus.conf file in the preinstall script? | 01:14 |
| nurmi | mathiaz: nod | 01:14 |
| mathiaz | nurmi: and /etc/eucalyptus/eucalyptus.conf is a conffile then? | 01:14 |
| mathiaz | nurmi: ie it's shipped in the package as /etc/eucalyptus/eucalyptus.conf? | 01:15 |
| nurmi | mathiaz: yes | 01:15 |
| mathiaz | kirkland: what happens if a conffile has been moved? | 01:16 |
| mathiaz | kirkland: is it reintalled? or is there an prompt made by dpkg? | 01:16 |
| kirkland | mathiaz: in which case? | 01:16 |
| kirkland | mathiaz: yesterday, or today's upload? | 01:16 |
| nurmi | mathiaz: the new situation (with eucalyptus.local.conf), is an attempt to allow the system to keep eucalyptus.conf unmodified, so that pacakge upgrades can happen smoother | 01:16 |
| mathiaz | nurmi: I'm trying to figure out whether dpkg would prompt the end user would be prompted | 01:16 |
| nurmi | .oO(more smoothly) | 01:16 |
| mathiaz | kirkland: yesterday | 01:17 |
| kirkland | mathiaz: it would have been reinstalled | 01:17 |
| mathiaz | nurmi: right - one of the goal here is to avoid useless prompts | 01:17 |
| nurmi | mathiaz: nod | 01:17 |
| === erichammond1 is now known as erichammond | ||
| mathiaz | nurmi: ok - so on an upgrade by moving the existing eucalyptus.conf in preinstall, dpkg would install the *new* default eucalyptus.conf without prompting the user | 01:18 |
| nurmi | mathiaz: so, if eucalyptus.conf was a 'sane default' file, and any run-time modifications were only made to eucalyptus.local.conf, then package upgrade should not ask any questions, if I understand correctly | 01:18 |
| mathiaz | nurmi: kirkland: is that correct? | 01:18 |
| mathiaz | nurmi: yes - that's one possibility | 01:19 |
| kirkland | mathiaz: i'm digesting that still ... | 01:20 |
| nurmi | mathiaz: following this idea just for a moment; on upgrade, we could make '--upgrade-conf' do its thing with 'eucalyptus.local.conf' instead of 'eucalyptus.conf' | 01:20 |
| nurmi | mathiaz: avoiding the need to mess with eucalyptus.conf at all | 01:20 |
| nurmi | mathiaz: and, since eucalyptus.local.conf is not part of the package, the whole upgrade process could happen in post-install | 01:21 |
| nurmi | mathiaz: okay, i'm done following that idea, thanks :) | 01:21 |
| * mathiaz thinks | 01:21 | |
| * kirkland thinks eucalyptus does its own thing with its configuration files; it doesn't want dpkg or distro management thereof | 01:22 | |
| mathiaz | nurmi: right | 01:22 |
| * kirkland thinks we make eucalyptus.conf a non-conffile | 01:22 | |
| kirkland | and it's up to euca_conf to keep it sane | 01:23 |
| kirkland | ^ at least, that's one option | 01:23 |
| uvirtbot` | kirkland: Error: "at" is not a valid command. | 01:23 |
| kirkland | thanks uvirtbot` | 01:23 |
| mathiaz | nurmi: so having eucalyptus.conf be a conffile and eucalyptus.local.conf a configuration file edited by euca_conf and the local sysadmin | 01:23 |
| mathiaz | nurmi: you wouldn't need to move eucalyptus.conf in the presinstall | 01:24 |
| nurmi | mathiaz: nod | 01:24 |
| mathiaz | nurmi: since eucalyptus.conf shouldn't be changed | 01:24 |
| nurmi | mathiaz: we wouldn't need to mess with eucalyptus.conf at all | 01:24 |
| mathiaz | nurmi: and if it is, then dpkg should prompt for a diff | 01:24 |
| nurmi | mathiaz: well it *could* be, but that is up to the admin | 01:25 |
| nurmi | mathiaz: nod | 01:25 |
| mathiaz | nurmi: right - it could be - but then it's up to the admin and we don't wanna loose anything | 01:25 |
| nurmi | mathiaz: nod | 01:25 |
| mathiaz | nurmi: hence relying on dpkg conffile mechanism | 01:25 |
| mathiaz | nurmi: and then euca_conf would modify .local.conf | 01:25 |
| mathiaz | nurmi: and upgrade .local.conf as well in the postinst | 01:26 |
| nurmi | mathiaz: nod | 01:26 |
| mathiaz | kirkland: ^^ sounds like a good plan to me | 01:26 |
| mathiaz | kirkland: eucalyptus.conf stays as a conffile | 01:27 |
| * kirkland reads | 01:27 | |
| mathiaz | kirkland: euca_conf modifies eucalytpus.local.conf | 01:27 |
| mathiaz | kirkland: the sysadmin is advised to edit eucalytpus.local.conf | 01:27 |
| kirkland | mathiaz: and what is eucalyptus.conf seeded with on new install? | 01:27 |
| mathiaz | kirkland: eucalyptus.local.conf is actually a configuration file | 01:28 |
| mathiaz | kirkland: eucalytpus.conf is a conffile, ie is part of the debian package | 01:28 |
| mathiaz | kirkland: it's content is the default eucalytpus.conf with all the options set correclty | 01:28 |
| mathiaz | kirkland: eucalyptus.local.conf is installed by the maintainer script (thus is a configuration file, but not a conffile) | 01:29 |
| nurmi | maybe s ' | 01:29 |
| nurmi | er | 01:29 |
| nurmi | mistype, nvm | 01:29 |
| kirkland | mathiaz: basically what i put in /usr/share ? | 01:29 |
| mathiaz | kirkland: nothing | 01:29 |
| mathiaz | kirkland: the current eucalyptus-default.conf is /etc/eucalytpus/eucalyptus.conf | 01:30 |
| mathiaz | kirkland: and the current eucalyptus.conf is the base for eucalyptus.local.conf | 01:30 |
| kirkland | mathiaz: right | 01:30 |
| mathiaz | kirkland: euca_conf modifies eucalyptus.local.conf (during pkg upgrade as well) | 01:30 |
| kirkland | mathiaz: gotcha | 01:31 |
| mathiaz | kirkland: and since eucalyptus.local.conf is *not* a conffile, there shoudn't be any prompt on upgrades | 01:31 |
| kirkland | nurmi: you're good with this? | 01:31 |
| nurmi | kirkland: yep! that sounds great to me | 01:31 |
| mathiaz | kirkland: now - there is a special case to upgrade from karmic | 01:31 |
| mathiaz | kirkland: since eucalyptus.conf will have changed between karmic and lucid | 01:31 |
| mathiaz | kirkland: (well technically it is different on every system since the list of NODES is local) | 01:32 |
| nurmi | kirkland: i'll make sure '--upgrade-conf' is working properly, over the next week, if this is the decided upon plan | 01:32 |
| mathiaz | kirkland: so to avoid a prompt on upgrade from karmic, the presinstall script should move the existing eucalytpus.conf to eucalyptus.local.conf | 01:33 |
| mathiaz | kirkland: so that dpkg installs the new eucalyptus.conf file | 01:33 |
| kirkland | mathiaz: right, i already hacked it that way in today's upload | 01:33 |
| kirkland | mathiaz: slangasek advised me as such | 01:33 |
| mathiaz | kirkland: and then --upgrade-conf should be run as part of the normal upgrade process in the maintainer script | 01:33 |
| kirkland | mathiaz: basically, if upgrading, and eucalyptus.conf exists, and .local doesn't, it's moved to .local | 01:34 |
| * mathiaz nods | 01:34 | |
| kirkland | nurmi: what's the full syntax for --upgrade-conf? | 01:34 |
| kirkland | mathiaz: always --upgrade-conf ? | 01:34 |
| mathiaz | kirkland: nurmi: and so we rely on euca_conf --upgrade-conf to mangle properly the local configuration file | 01:34 |
| kirkland | mathiaz: on any upgrade? | 01:34 |
| nurmi | kirkland: euca_conf --upgrade-conf <old-config-file> | 01:34 |
| mathiaz | kirkland: yes | 01:34 |
| nurmi | kirkland: however, I am going to need to modify it to work in the new environment (with two config files) | 01:35 |
| kirkland | nurmi: and it does it work in-place ? | 01:35 |
| mathiaz | kirkland: nurmi: unless euca_conf --upgrade-conf is *not* idempotent | 01:35 |
| nurmi | mathiaz: i will make it so | 01:35 |
| mathiaz | kirkland: mysql-server does the same thin | 01:35 |
| mathiaz | kirkland: thing | 01:35 |
| mathiaz | kirkland: the upgrade script is always run | 01:35 |
| kirkland | mathiaz: nurmi: okay, i think i know what needs to be done | 01:35 |
| kirkland | it will be a late night, but i'll get it done tonight | 01:36 |
| kirkland | nurmi: ping me if you have a rev you want me to merge | 01:36 |
| nurmi | kirkland: mathiaz: for now, we should omit --upgrade-conf until we have a chance to test it, I think | 01:36 |
| kirkland | nurmi: as i'll depend on your work too | 01:36 |
| mathiaz | kirkland: great - I'll setup a local version of the setup | 01:36 |
| kirkland | nurmi: agreed | 01:36 |
| kirkland | mathiaz: cool, let me know what you find | 01:36 |
| mathiaz | kirkland: to make sure things are working correclty | 01:36 |
| kirkland | mathiaz: i'll be online for another 5 hours, probably | 01:36 |
| nurmi | kirkland: cool, i'll start working on it tonight, but I have some other obligations and will probably not be able to finish | 01:37 |
| kirkland | nurmi: okay | 01:37 |
| kirkland | nurmi: thanks for irc'ing | 01:37 |
| nurmi | kirkland; anytime - thank *you* guys for working to get this all right | 01:37 |
| mathiaz | kirkland: right - so the key part for now is to have euca_conf modify eucalytpus.local.conf rather than eucalyptus.conf | 01:37 |
| kirkland | mathiaz: that's trivial | 01:38 |
| mathiaz | kirkland: while waiting for the upgrade-conf the be tested | 01:38 |
| kirkland | mathiaz: i already changed it to edit eucalyptus-local | 01:38 |
| mathiaz | kirkland: oh - and the upstart jobs need to be updated | 01:39 |
| mathiaz | kirkland: to source both configuration file | 01:39 |
| mathiaz | kirkland: and eucalyptus.conf should *not* source eucalytpus.local.conf | 01:39 |
| mathiaz | kirkland: since it may break the C parser | 01:39 |
| nurmi | brb guys | 01:41 |
| kirkland | mathiaz: right | 01:42 |
| zig_ | Is there anything wrong with only having LVM2 LV's? | 02:22 |
| zig_ | And no /boot outside the LVM or anything? | 02:22 |
| === jono_ is now known as jono | ||
| jtaji | zig_: with grub2 it works | 02:25 |
| zig_ | Reliably? | 02:25 |
| zig_ | Yeah, I tested it and it works like a dream with Ubuntu 9.10 server | 02:26 |
| zig_ | /dev/sda & /dev/sdc => /dev/md0 => LVM => root & swap LV's | 02:26 |
| zig_ | A very elegant setup for a software RAID1 system, I think. | 02:26 |
| jtaji | it's been good on my thinkpad with 9.10 | 02:27 |
| zig_ | Yeah | 02:27 |
| zig_ | I'm pleased. | 02:27 |
| zig_ | Second question: Have you dont an ubuntu server installation USB drive? | 02:27 |
| jtaji | luks on lvm with no separate /boot.. nice | 02:27 |
| zig_ | Or rather, USB stick? | 02:27 |
| zig_ | I didn't bother with a crypt setup. | 02:28 |
| jtaji | I have not messed around with bootable USB yet.. actuallly | 02:28 |
| jtaji | yeah I only use it because it's a laptop | 02:29 |
| zul | smoser: are you using vmbuilder for the ebs stuff? | 02:32 |
| smoser | that is the goal. really, the goal is to basically take root filesystem that we create for local-store instances and dump it onto a ebs volume, create a snapshot and register. | 02:33 |
| zul | so do you do it on an ami or on the build machine? | 02:35 |
| smoser | you have to do it on an instance | 02:38 |
| smoser | that part sucks | 02:38 |
| zul | oooooh.....fun | 02:38 |
| smoser | i mention in the spec the complications of many more moving parts | 02:39 |
| zul | well now you get to do what we talked about at the last server sprint | 02:41 |
| === mrmojo is now known as billynom | ||
| === erichammond1 is now known as erichammond | ||
| === dantaliz1ng is now known as dantalizing | ||
| === erichammond1 is now known as erichammond | ||
| === erichammond1 is now known as erichammond | ||
| === erichammond1 is now known as erichammond | ||
| jamil | I have us robotics 56k message modem, How to install driver at ubuntu 8.10??? | 04:33 |
| === rberger_ is now known as rberger | ||
| mcarse | can anyone help with ubuntu 9.10 and vmware server? | 06:01 |
| Parabola | whats your question | 06:01 |
| mcarse | i can't get the vmware tools to compile in a vmware 9.10 guest | 06:02 |
| Parabola | okay, what error are you getting | 06:02 |
| mcarse | it is not on the officially supported list for vmware server 2.0 | 06:02 |
| mcarse | when it is trying to build the kernel modules, it exits with Error 2 | 06:03 |
| mcarse | failed to insert into kernel | 06:03 |
| Parabola | oh my | 06:03 |
| mcarse | I have done this countless times without error on 9.04 | 06:03 |
| Parabola | will you be around tomorrow? its 1am and i need to get to bed, however i can test this from work :) | 06:04 |
| Sam-I-Am | you might want to try the openvm-tools | 06:04 |
| Sam-I-Am | or whatever its called now... | 06:04 |
| Parabola | still called that i think | 06:04 |
| mcarse | Parabola: I can be back on tomorrow yep | 06:04 |
| Sam-I-Am | they're basically vmware's tools... only some folks outside of vmware update them more quickly to support newer stuff | 06:04 |
| Parabola | alright, i'll be on off and on during the day from 7am est to 4pm est | 06:05 |
| mcarse | is it not best to use the vmware ones though | 06:05 |
| Sam-I-Am | they are the vmware tools, more or less | 06:05 |
| Parabola | shouldnt make a difference | 06:05 |
| mcarse | Parabola: I will be on around 9 est | 06:05 |
| Sam-I-Am | since the vmware tools are open source | 06:05 |
| mcarse | maybe I am confusing openvm-tools with something else. | 06:06 |
| Sam-I-Am | theres even a nice interface using the module installer thing... cant remember its name | 06:06 |
| mcarse | Do you think Vmware will release an updated Server where the tools support 9.10? | 06:07 |
| Sam-I-Am | sure | 06:07 |
| mcarse | I am patient I can wait. | 06:07 |
| Sam-I-Am | they're just a tad slow | 06:07 |
| mcarse | slow is one word i guess. | 06:07 |
| mcarse | soon to be 3 months behind. | 06:07 |
| Sam-I-Am | they'll roll a patch level which will include it most likely | 06:07 |
| Sam-I-Am | so pay attention to randomly incrementing build numbers | 06:08 |
| Sam-I-Am | sometimes they dont tell you about added OS support | 06:08 |
| * Sam-I-Am wanders off to sleep | 06:09 | |
| _ruben | Sam-I-Am: open-vm-tools is actually maintained by vmware themselves | 08:06 |
| jiboumans | morning | 09:22 |
| clusty | mornin | 09:39 |
| ploum | Hello | 09:43 |
| ploum | Can anybody with an LDAP server help me to confirm this bug : | 09:44 |
| ploum | https://bugs.edge.launchpad.net/ubuntu/+source/python-ldap/+bug/506317 | 09:44 |
| uvirtbot | Launchpad bug 506317 in python-ldap "ldap.schema.urlfetch doesn't work anymore since slapd.d migration" [Undecided,New] | 09:44 |
| ploum | it's a matter of launching 3 lines of Python | 09:44 |
| uvirtbot | New bug: #423527 in libvirt (main) "Should suspend or shut down domains on system shutdown" [Medium,Triaged] https://launchpad.net/bugs/423527 | 09:57 |
| uvirtbot | New bug: #506328 in squid-langpack (main) "Please sync squid-langpack 20091005-1 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/506328 | 10:17 |
| === freeflyi1g is now known as freeflying | ||
| uvirtbot | New bug: #506316 in eucalyptus (main) "[lucid] New config file system fails to support node registration" [High,Fix committed] https://launchpad.net/bugs/506316 | 10:51 |
| === giLL0r_ is now known as giLL0r | ||
| underdev | Hi! Does anyone know how to run a server in the background that will persist after the shell is closed? | 11:41 |
| cemc | underdev: if that server doesn't have any -d (as in daemon) switch, or config file option, you could try runinning it with '&' at the end, like ./server_daemon & | 11:42 |
| underdev | cemc- ty | 11:44 |
| cemc | underdev: if you go with the '&' one, you might want to redirect output to some logfile, like ./server_daemon > /var/log/logfile.log 2>&1 & (if you need the output) | 11:45 |
| === dendrobates is now known as dendro-afk | ||
| === deegee_1 is now known as deegee | ||
| rags | Is there a way I can configure directory level quota's? | 13:06 |
| ttx | zul: i've split the canonical-app-support work items to alpha3... please doublecheck, if there is anything you plan to complete by Thursday, please move them back to alpha2 | 13:21 |
| zul | ttx: ack | 13:22 |
| ttx | zul: also for seeds I still assume that it will be completed by alpha2 | 13:22 |
| ttx | so I didn't defer any item to alpha3 | 13:22 |
| zul | ttx: k | 13:23 |
| zul | ttx: umm we are still discussing packages for the server-lucid-seeds packages | 13:25 |
| ttx | zul, mathiaz: but the discussion should end before thursday, right | 13:26 |
| ploum | does anybody have an idea why phpldapmyadmin is displayed recursively when I install it ? | 13:26 |
| ploum | http://ldap.fritalk.com | 13:26 |
| ploum | (fresh phpldapadmin install !) | 13:26 |
| zul | ttx: afaik yes | 13:26 |
| zul | autofs5 is done on our side now pitti just has to flick the switch | 13:30 |
| jiboumans | ttx, zul: mathiaz confirmed to me that he'd close the dicussions on monday actually | 13:30 |
| zul | jiboumans: ah good | 13:31 |
| jiboumans | during our 1:1 last friday | 13:31 |
| zul | so we just have to wait for him to wake up ;) | 13:31 |
| ttx | jiboumans: so that kinda spills over as well. | 13:31 |
| jiboumans | ttx: yesterday's monday | 13:31 |
| ttx | jiboumans: ah | 13:31 |
| ttx | that's good :) | 13:31 |
| jiboumans | ttx: best follow up with him on that then, as i haven't seen a conclusion mail yet | 13:31 |
| ttx | I don't mind an exception for something requiring wider consensus/discussion, but that should be the exception rather than the rule | 13:32 |
| jiboumans | and there was some traffic overnight still | 13:32 |
| jiboumans | ttx: agreed | 13:32 |
| zul | im still trying to beat ctdb into shape | 13:32 |
| Italian_Plumber3 | how do I audit my startup process, to see if, or make sure that, one service is started before another? I need to do that with NTP and networking. | 14:12 |
| cemc | Italian_Plumber3: I think ubuntu takes care of that. take a look in /etc/network/if-up.d/ntpdate | 14:19 |
| Italian_Plumber3 | i'm not using ntpdate I'm using npt (the server) | 14:21 |
| smoser | good morning all. | 14:22 |
| smoser | ttx, ping | 14:22 |
| smoser | bug 506332 | 14:23 |
| uvirtbot | Launchpad bug 506332 in ec2-init "Can't login with SSH to Lucid UEC image" [High,New] https://launchpad.net/bugs/506332 | 14:23 |
| ttx | smoser: yo | 14:23 |
| smoser | where is that one? its fixed? | 14:23 |
| ttx | smoser: no it isn't | 14:23 |
| ttx | I was wondering what broke it | 14:23 |
| Xpistos|work | Hi everyone | 14:24 |
| smoser | hm... i havent tried 20100112, maybe something busted outside ec2 init | 14:24 |
| ttx | smoser: fwiw it still boots and starts an SSH server | 14:24 |
| cemc | Italian_Plumber3: scroll further down, there is a bit where it's restarting ntpd, too | 14:24 |
| smoser | 20100111.1 is the first first with new ec2 | 14:24 |
| Xpistos|work | Can someone help me with a message I am getting when I try to apt-get upgrade? "The following packages have been kept back: linux-generic-pae linux-headers-generic-pae linux-image-generic-pae" I am no sure why anything is being held back? | 14:25 |
| RoyK | http://www.daily.pk/norway-time-hole-“leak”-plunges-northern-hemisphere-into-chaos-14311/ <-- whee - it's all our fault! | 14:26 |
| ttx | smoser: let me know how I can best assist you on that one. Try on EC2 ? Try 20100111.1 on UEC ? | 14:26 |
| smoser | oh, i see. so ssh is up but you can't log in. its probably timing, as i dont know what changed between 2010111.1 and 20100112 (nothing from me) | 14:26 |
| ttx | smoser: haven't tried 20100111.1 | 14:27 |
| ttx | 20100108.1 works | 14:27 |
| ttx | smoser: want me to try 20100111.1 on UEC ? | 14:27 |
| smoser | ah. is uec easily installable? should i install it locally? | 14:28 |
| ttx | smoser: it's installable, but maybe not the best use of your time | 14:29 |
| ttx | smoser: what did you tested so far ? 20100111.1 on EC2 ? | 14:29 |
| smoser | yeah | 14:29 |
| ttx | smoser: ok, then try 20100112 on EC2, I'll try 20100111.1 on UEC | 14:30 |
| smoser | 'euca-get-console-output stops before "ec2: Generating public/private rsa key pair." on the affected images.' | 14:30 |
| smoser | thats a bug, there wont be the ec2 fingerprints to console at the moment. | 14:30 |
| ttx | smoser: ok, known bug ? | 14:30 |
| smoser | i should open a bug, but yes, i was aware that i'd not added that into ec2-init 0.5.x | 14:31 |
| smoser | i just verified that 20090112 booted on ec2 and i reached it | 14:31 |
| ttx | ok | 14:32 |
| ttx | smoser: downloading 20100111.1 for UEC testing | 14:33 |
| smoser | i really dont expect any difference there. | 14:33 |
| Maleko | hi. whats the simplest way to track down the time that a server spends to reboot | 14:33 |
| ttx | smoser: well, there is a difference between 20100108.1 and 20100112 | 14:34 |
| smoser | well yes. but ec2-init 0.5.0 went into 20100111.1 | 14:34 |
| ttx | smoser: you think it's the ec2-init stuff that landed in 20100111.1 ? | 14:34 |
| smoser | so theres a big difference. | 14:34 |
| ttx | ok | 14:34 |
| smoser | well right now i'd think thats the smoking gun | 14:34 |
| ttx | smoser: i'll narrow the regression to 20100111 -> 20100111.1 just to be sure | 14:35 |
| ttx | smoser: you need a UEC to debug this ? Do you have a karmic UEC leftover ? | 14:36 |
| smoser | i think i might have lucid alpha1 | 14:36 |
| smoser | which ~ karmic, right? | 14:36 |
| ttx | smoser: yes | 14:36 |
| ttx | anything that saves you from reinstalling it is good | 14:37 |
| smoser | i'll resurect it and see. | 14:37 |
| ttx | smoser: if I can do anything apart from this narrowing-down, let me know | 14:37 |
| ttx | I'll have a look at ec2-init to see if anything rings a bell | 14:37 |
| ttx | smoser: kvm should be pretty close anyway | 14:38 |
| smoser | i had been testing in kvm. i can test it too. | 14:38 |
| ttx | smoser: also see slangasek message from ~3 hours ago on #ubuntnu-devel | 14:39 |
| ttx | about "lucid-server-amd64.tar.gz" | 14:39 |
| ttx | instead of "lucid-uec-amd64.tar.gz" | 14:40 |
| smoser | i dont see anything on -devel | 14:41 |
| ttx | smoser: see pm | 14:42 |
| bogeyd6 | is it even possible to burn an iso from a network share? | 14:46 |
| kwork | sure it is | 14:46 |
| kwork | will it work :P? who knwos | 14:47 |
| uvirtbot | New bug: #506317 in python-ldap (main) "ldap.schema.urlfetch doesn't work anymore since slapd.d migration" [Undecided,Invalid] https://launchpad.net/bugs/506317 | 14:51 |
| === robbiew_ is now known as robbiew | ||
| Xpistos|work | Can someone help me with a message I am getting when I try to apt-get upgrade? "The following packages have been kept back: linux-generic-pae linux-headers-generic-pae linux-image-generic-pae" I am no sure why anything is being held back? | 15:00 |
| RoyK | Xpistos|work: just apt-get remove them and add new replacements. being held back means apt/dpkg can't do an automatic upgrade for some reason. removing and re-adding replacements usually work | 15:03 |
| RoyK | s/$/s/ | 15:03 |
| Italian_Plumber3 | what is the best way to automatically keep the clock updated on an ubuntu server? | 15:03 |
| Xpistos|work | RoyK: So remove linux-generic-pae and then reinstall it? | 15:04 |
| Parabola | Xpistos|work - use apt-get dist-upgrade | 15:07 |
| Parabola | that will install thoes for you | 15:07 |
| Xpistos|work | Parabola: which is prefered upgrade or dist-upgrade? | 15:07 |
| Parabola | depends | 15:08 |
| Parabola | i personally do dist upgrade | 15:08 |
| Parabola | but that will upgrade the kernel if its availible :) | 15:08 |
| Parabola | just upgrade is "safer" however if you need thoes packages updated | 15:08 |
| Parabola | then dist-upgrade is the way to go, you could also block kernel upgrades, and then use dist-upgrade | 15:09 |
| Parabola | would be a little safer | 15:09 |
| Parabola | (again i've been using dist-upgrade on my webservers for sometime, never had an issue) | 15:09 |
| JanC | well, upgrading kernels might be useful in case of security issues ;) | 15:09 |
| psyferre | hey folks, does anyone know if there's a stripped down package of gnome that can be installed on ubuntu server? I'd like to use gnome once in a while, but i don't need open office, etc that comes with the ubuntu-desktop package... | 15:17 |
| dei | hello | 15:23 |
| dei | anyone here familiar with dns? | 15:25 |
| uvirtbot | New bug: #506464 in squid (main) "snmp not enabled in squid" [Undecided,New] https://launchpad.net/bugs/506464 | 15:26 |
| cemc | dei: somewhat | 15:27 |
| dei | on my dns server | 15:27 |
| dei | for my dns server rather | 15:27 |
| dei | 1: Set Subnet with Registrar (i.e. NS8.blahblah.com equals 149.242.440.10 | 15:28 |
| dei | 2: Created Zone at above ip | 15:28 |
| dei | 3: Created A record, Set NS Records, and created PTR records on Server at above ip | 15:28 |
| dei | a record = ns8.bahblah = 149.242.440.10 [for example] | 15:29 |
| dei | ns record = ns8.blahblah.com | 15:29 |
| dei | ptr record = 149-242-440-10.myserver.myisp.com | 15:29 |
| dei | is that how its supposed to be done? | 15:30 |
| bogeyd6 | dei would you like me to pastebin my dns setup? | 15:30 |
| dei | im running powerdns | 15:31 |
| dei | its functional.. | 15:31 |
| dei | =\ | 15:31 |
| bogeyd6 | well you are taking the right steps | 15:32 |
| dei | i mean | 15:32 |
| dei | dig @ns0.osmiumdefensesystems.com any osmiumdefensesystems.com | 15:32 |
| dei | that works | 15:32 |
| bogeyd6 | yes | 15:32 |
| dei | its just | 15:33 |
| dei | when im doing squish, for example | 15:33 |
| dei | sometimes you see stuff like this | 15:33 |
| dei | Referral: com is at L.GTLD-SERVERS.NET - IP not supplied | 15:33 |
| dei | but it will say | 15:33 |
| dei | Referral: com is at NS0.OSMIUMDEFENSESYSTEMS.COM - IP not supplied | 15:33 |
| dei | 15:35 | |
| dei | Asking A0.ORG.AFILIAS-NST.INFO (199.19.56.1) for paschool.org (type A) | 15:35 |
| dei | 15:35 | |
| dei | Referral: paschool.org is at ns0.osmiumdefensesystems.com - IP not supplied | 15:35 |
| dei | Referral: paschool.org is at ns8.osmiumdefensesystems.com - IP not supplied | 15:35 |
| henriquev | "update-rc.d my-script 2" => I get this: update-rc.d: warning: /etc/init.d/plifk missing LSB information | 15:37 |
| henriquev | and it doesn't do anything else... Like something is wrong | 15:37 |
| sub | it's just a warning. did you confirm that it made the appropriate symlinks? | 15:39 |
| henriquev | it didn't | 15:39 |
| henriquev | if I use update-rc.d my-script defaults it does | 15:40 |
| henriquev | the man page doesn't help | 15:42 |
| ttx | smoser: confirmed regression is between 20100111 and 20100111.1 | 15:44 |
| smoser | i think its timing | 15:44 |
| smoser | wait | 15:44 |
| smoser | your input is useful, yeah. | 15:44 |
| ttx | smoser: anything I can test ? | 15:44 |
| smoser | i just verified that 20100112 boots fine in kvm with ec2 metadata inserted | 15:44 |
| smoser | ah | 15:45 |
| smoser | i might know, yeah | 15:45 |
| smoser | you can get to a 20100111 ? | 15:45 |
| smoser | inside it, it should have boto 1.9 | 15:45 |
| smoser | try | 15:45 |
| ttx | I'm in | 15:45 |
| smoser | python -c 'import boto.utils; import pprint; pprint.pprint(boto.utils.get_instance_metadata())' | 15:46 |
| smoser | pastebin that output if you can | 15:47 |
| smoser | http://pastebin.com/f7939e1a7 is what i get | 15:48 |
| ttx | http://pastebin.ubuntu.com/355571/ | 15:48 |
| smoser | so metadata service in uec is not identical to ec2. i'm using that instance metadata call to get the keys | 15:49 |
| ttx | smoser: I'd say, I'm not surprised | 15:50 |
| smoser | i think i can work around. | 15:50 |
| ttx | smoser: sure, but don't forget to file a bug against eucalyptus | 15:50 |
| smoser | yeah, i should have expected that. boto just such a nice job of crawling the data to a object | 15:50 |
| ttx | smoser: please update the bug to "In Progress" with a comment about the lead you're following now | 15:51 |
| ttx | smoser: that's workaroundable in time for alpha2, right | 15:52 |
| smoser | yeah, i think so | 15:53 |
| ttx | smoser: let me know as soon as you respin an image and I'll validate the fix | 15:53 |
| smoser | what euca version is that? | 15:54 |
| ttx | The current, lucid one | 15:54 |
| ttx | 1.6.2~bzr1124-0ubuntu2 | 15:54 |
| smoser | thanks | 15:54 |
| ttx | mathiaz: just checking, you have 5 work items left, 4 in uec-testing. All those should still get completed for alpha-2, you don't expect any of them requiring to defer to alpha-3 ? | 15:56 |
| mathiaz | ttx: * Automate UEC upgrade of existing 9.10 CLC+Walrus+CC+SC / NCs: TODO | 15:57 |
| mathiaz | ttx: ^^ probably defer to alpha3 | 15:57 |
| mathiaz | ttx: and running functional test suites require a working UEC which have may have today | 15:58 |
| ttx | mathiaz: it's working now | 15:58 |
| ttx | mathiaz: minus a small bugfix I committed that didn"t land on the ISO yet | 15:58 |
| mathiaz | ttx: great - I'll reinstall my UEC setup later today then | 15:58 |
| ttx | mathiaz: to work around it, just add NODES="" to /etc/eucalyptus/eucalyptus.local.conf before starting to add nodes | 15:59 |
| ttx | euca_conf can't modify a valud that's not tere in the first place | 15:59 |
| ttx | mathiaz: if you netboot, you should get the fixed version | 16:00 |
| mathiaz | ttx: right | 16:00 |
| mathiaz | ttx: I do package installation - so 1.6.2~bzr1124-0ubuntu3 should be installed | 16:00 |
| ttx | mathiaz: yes. | 16:00 |
| mathiaz | ttx: great - so I should be able to run the functional tests later today | 16:01 |
| ttx | mathiaz: ok, just ack with jib the deferred items and move those you can't do to alpha3 on the whiteboard by the end of your day | 16:01 |
| mathiaz | ttx: okidoki | 16:02 |
| zul | mathiaz: hi mathiaz, do you have a list of packages we can demote to universe? | 16:05 |
| mathiaz | zul: already done | 16:29 |
| mathiaz | zul: FYI http://wiki.ubuntu.com/LucidServerSeeds | 16:30 |
| zul | you filed them in launchpad? | 16:30 |
| zul | mathiaz: ah ok | 16:31 |
| === fahadsadah is now known as Guest14190 | ||
| ikthus | Hi all :) it's me | 17:14 |
| ikthus | I want to install ubuntu server on an IBM 84805AX, but i dont see any hard drive in the description of the bios, but there is already a system installed in this machine. | 17:19 |
| ikthus | see desc here http://servers.alege.net/IBM-eserver-xSeries-205-8480-84805AX.html | 17:19 |
| smoser | ttx, see bug 506332 | 17:21 |
| uvirtbot | Launchpad bug 506332 in ec2-init "Can't login with SSH to Lucid UEC image" [High,In progress] https://launchpad.net/bugs/506332 | 17:21 |
| === [1]cab938 is now known as cab938 | ||
| uvirtbot | New bug: #504368 in qemu-kvm (main) "sdl window intermittently scales instead of resizing" [Undecided,New] https://launchpad.net/bugs/504368 | 17:32 |
| smoser | mathiaz, kirkland anyone able to test https://bugs.launchpad.net/ubuntu/+source/ec2-init/+bug/506332 | 17:51 |
| uvirtbot | Launchpad bug 506332 in ec2-init "Can't login with SSH to Lucid UEC image" [High,In progress] | 17:51 |
| mathiaz | smoser: I should be able to | 17:51 |
| smoser | i've tested locally, seen it fail and then succeed, but i'd like someone else to if possible. | 17:52 |
| mathiaz | smoser: I've just installed a UEC setup | 17:52 |
| smoser | ok | 17:52 |
| mathiaz | smoser: and I'm about to register the latest image | 17:52 |
| mathiaz | smoser: latest *lucid* image | 17:52 |
| smoser | well, you wont be able to ssh to it :) | 17:52 |
| mathiaz | smoser: would that work for the test? | 17:52 |
| smoser | yeah. | 17:52 |
| smoser | you can verify it fail | 17:52 |
| smoser | then fix by mount -o loop <img> /mnt && install-package-into-image && umount && register modified image | 17:53 |
| smoser | that should show you fail and then fix | 17:53 |
| mathiaz | smoser: ok - I'll do that | 17:54 |
| mathiaz | smoser: looking at the bug - should this be a bug against eucalyptus meta-data service? | 17:56 |
| mathiaz | smoser: is eucalyptus meta-data supposed to be the same as the on on EC2? | 17:56 |
| smoser | mathiaz, you're correct, yes. | 17:58 |
| smoser | it should be but it isn't | 17:58 |
| mathiaz | smoser: right - I'll open a task against eucalyptus then | 17:58 |
| smoser | so work around in ec2-init for now. and should open a bug against metadata service, or at least a task here. | 17:58 |
| smoser | yeah | 17:58 |
| smoser | thanks. | 17:58 |
| kirkland | mathiaz: were you able to take a look at my eucalyptus upload? | 18:01 |
| mathiaz | kirkland: yop - works like a charm! | 18:02 |
| kirkland | mathiaz: implementing the last round of eucalyptus.conf changes | 18:02 |
| kirkland | mathiaz: beautiful :-) | 18:02 |
| === aubre is now known as aubre_afk | ||
| mathiaz | kirkland: I've got a running UEC now ! | 18:02 |
| kirkland | mathiaz: ttx said it worked too :-) | 18:02 |
| mathiaz | kirkland: thanks for all your hard work on this one! | 18:02 |
| kirkland | mathiaz: so you're testing smoser's bug for him? | 18:02 |
| kirkland | mathiaz: sure, think. thank *you* for your patience :-) | 18:02 |
| nurmi | kirkland: mathiaz: ttx: nice! | 18:02 |
| mathiaz | kirkland: well - I think it's an issue with eucalyptus | 18:02 |
| mathiaz | nurmi: oh - you're here | 18:02 |
| kirkland | nurmi: o/ | 18:03 |
| mathiaz | nurmi: bug 506332 | 18:03 |
| uvirtbot | Launchpad bug 506332 in ec2-init "Can't login with SSH to Lucid UEC image" [High,In progress] https://launchpad.net/bugs/506332 | 18:03 |
| kirkland | nurmi: that'll teach you to speak up :-) | 18:03 |
| nurmi | kirkland: hehe :) | 18:03 |
| nurmi | mathiaz: let me take a looksee | 18:03 |
| kirkland | mathiaz: i have fully automated installs of all 5 of my UEC machines now | 18:04 |
| kirkland | mathiaz: i can trigger them from anywhere with a web browser :-) | 18:04 |
| mathiaz | kirkland: :) | 18:04 |
| kirkland | mathiaz: completely hands off :-) | 18:04 |
| mathiaz | kirkland: how do you deal with ssh public keys? | 18:04 |
| mathiaz | kirkland: hm - never mind - it's part of the installer | 18:04 |
| kirkland | mathiaz: i'm planning on bringing all of it with me to PDX | 18:04 |
| kirkland | mathiaz: yeah | 18:04 |
| mathiaz | kirkland: so you're planning to go through airport security with 6 computers? | 18:05 |
| kirkland | mathiaz: right now, i do a ssh-copy-id after first reboot from my primary desktop | 18:05 |
| kirkland | mathiaz: i'd like to automate that | 18:05 |
| kirkland | mathiaz: that's the plan | 18:05 |
| nurmi | mathiaz: looks like smoser has a new ec2-init that | 18:05 |
| nurmi | works | 18:05 |
| mathiaz | nurmi: well - it's a workaround | 18:05 |
| mathiaz | nurmi: is eucalyptus supposed to provide the same metadata as EC2? | 18:06 |
| nurmi | mathiaz: boto 1.9 change incompatible with eucalyptus meta-data, it appears | 18:06 |
| smoser | boto 1.9 crawls the metadata service. Euca is close, but not the same. result is that the public-keys come out a bit different when its crawled. | 18:06 |
| smoser | there are some other differences there too | 18:06 |
| nurmi | smoser: yep, we'll take a look | 18:07 |
| mathiaz | nurmi: ok - so can we say that it's a bug that should be fixed in eucalyptus? | 18:07 |
| nurmi | smoser: is there a place where you have/can document the differences? | 18:08 |
| mathiaz | nurmi: and for alpha2 we could upload a workaround in ec2-init? | 18:08 |
| nurmi | mathiaz: not enough information yet, I need to see the bits that are actually different to determine how Eucalyptus should behave - this is frequently a 'documented spec versus implementation (boto) versus reality (AWS)' problem | 18:09 |
| smoser | nurmi, there are 2 files there, vimdiff shows fairly well. | 18:09 |
| mathiaz | nurmi: ok - so it seems like it won't be fixed in time for alpha2 | 18:10 |
| nurmi | smoser: do we know what difference is actually breaking boto? | 18:10 |
| smoser | nurmi, boto is just crawling the metadata service. for data. i just posted a comment with the differences. | 18:12 |
| smoser | regarding the public keys, there are 2 differences | 18:12 |
| smoser | i'd have to look more at what the web service is responding with, but my guess is that uec is listing 'public-keys/0' in the index of the metadata/ | 18:13 |
| nurmi | smoser: yep, instead of a 'list' | 18:13 |
| smoser | and then the similar with the public-keys | 18:14 |
| nurmi | smoser: this looks like the API has changed, we'll have to ensure that the version of boto and Eucalyptus support the same AWS API version, which it appears is not the case | 18:15 |
| smoser | nurmi, well, in the actual use case, ec2-init requests the 2009-04-04 api | 18:16 |
| smoser | hopefully they're not changing things inside an api level. | 18:17 |
| smoser | i can't say for certain, but you'd think that is pretty bad behavior, if one day http://169.254.169.254/2009-04-04 has one set of files and thne later it has a different set | 18:18 |
| smoser | kind of pointless to have the versions if you're going to do that | 18:18 |
| === aubre_afk is now known as aubre | ||
| nurmi | smoser: of course, i'm actually trying to make sure that we can claim that EUcalyptus fully supports the API that you're using to develope ec2-init/boto | 18:22 |
| nurmi | smoser: thanks, I've got the necessary information to figure out the problem and communicate with you guys on a solution | 18:23 |
| dnaumov | does Ubuntu automatically recognize when its being installed on an SSD an setups the partition alignment and sector/track sizes accordingly (like Windows 7 and Win2008 R2 do) or is there a lot of crazy manual fdisk trickery involved? | 18:23 |
| smoser | given that attachment you should pretty easiliy be able to run your own 'python -c "import boto.utils, pprint; pprint.pprint(boto.utils.get_instance_metadata())"' and compare | 18:24 |
| nurmi | smoser: we need to start with the spec, and then will take into account what a third-party expects (i.e., the objects you posted as part of the bug report) | 18:26 |
| nurmi | smoser: thanks for that, those are really useful reports for us | 18:26 |
| mathiaz | kirkland: are you able to run instances on the latest lucid UEC? | 18:35 |
| mathiaz | kirkland: my setup isn't able to start instances - the error in nc.log is: libvirt: Failed to add tap interface to bridge 'br0': No such file or directory (code=38) | 18:36 |
| kirkland | mathiaz: i haven't tried today | 18:36 |
| kirkland | mathiaz: ttx said he was able to, though | 18:36 |
| mathiaz | kirkland: hm - there is a new kernel available - let me upgrade first | 18:37 |
| mathiaz | nurmi: where is the metadata service running? on the CC or on the CLC? | 18:49 |
| nurmi | mathiaz: CLC | 18:49 |
| xteejx | Hey guys, anyone know anything about sudo-ldap? | 18:50 |
| mathiaz | nurmi: and the 169.254.169.254 IP address is supposed to be on the CC or CLC? | 18:50 |
| nurmi | mathiaz: CC | 18:50 |
| nurmi | mathiaz: if you are running a CLC and CC on different hosts, you have to set VNET_CLOUDIP="CLC-IP" in eucalyptus.conf on the CC | 18:51 |
| nurmi | mathiaz: the CC sets up an iptables redirect for 169.254.169.254:80 to the CLC-IP:8773 | 18:52 |
| mathiaz | nurmi: ok - that's the setup I have | 18:52 |
| mathiaz | nurmi: CLC+Walrus on one host | 18:52 |
| xteejx | If there is anyone around that understands ldap and is able to help with bug 115967, please do so, it would be appreciated :) | 18:52 |
| uvirtbot | Launchpad bug 115967 in sudo "sudo-ldap not working with ldaps" [Medium,Confirmed] https://launchpad.net/bugs/115967 | 18:52 |
| mathiaz | nurmi: CC+SC on another host | 18:52 |
| mathiaz | nurmi: when you mentioned VNET_CLOUDIP="CLC-IP" - should "CLC-IP" be used? or the actual CLC IP address (X.X.X.X)? | 18:54 |
| mathiaz | nurmi: nervermind - I've read the documentation | 18:55 |
| dnaumov | anyone? | 19:00 |
| smoser | mathiaz, did you verify that fix? | 19:08 |
| mathiaz | smoser: not yet | 19:13 |
| mathiaz | smoser: I'm not able to start instances on my UEC setup - debugging it | 19:14 |
| mathiaz | nurmi: is that the iptables rules supposed to handle the metadata service on the CC: 0 0 DNAT tcp -- * * 172.19.0.0/16 169.254.169.254 tcp dpt:80 to:169.254.169.254:8773 | 19:19 |
| mathiaz | nurmi: ? | 19:19 |
| nurmi | mathiaz: yep, that rule implies that VNET_CLOUDIP was not set (the default is to set the redirect to 'itself') | 19:24 |
| nurmi | mathiaz: if you have changed eucalyptus.conf, then you'll have to do a 'clean' restart for the change to take effect | 19:24 |
| mathiaz | nurmi: ok - let me double check my configuration files | 19:25 |
| nurmi | mathiaz: iirc, the upstart script honors a "restart eucalyptus-cc CLEAN=1" style argument | 19:25 |
| mathiaz | nurmi: I've added VNET_CLOUDIP="192.168.12.42" to eucalyptus.local.conf | 19:26 |
| mathiaz | nurmi: and rebooted the CC | 19:26 |
| ttx | mathiaz: you'd still have to use CLEAN=1 | 19:26 |
| ttx | network state is preserved accross reboots | 19:27 |
| mathiaz | nurmi: ttx: \o/ - works thanks | 19:27 |
| ttx | smoser: testing your fix | 19:28 |
| marks256 | i'm trying to compile the 2.6.31 kernel to include the Lustre FS patch, but i am getting an error: Failed to create a ./debian directory: No such file or directory at /usr/bin/make-kpkg line 1048. Any ideas on how to solve this? | 19:31 |
| mathiaz | marks256: I'd ask in #ubuntu-kernel | 19:31 |
| === rberger_ is now known as rberger | ||
| marks256 | mathiaz, ok thanks | 19:32 |
| ttx | nurmi: is rebooting an instance supported ? | 19:40 |
| nurmi | ttx: it should be, i havn't tried with the latest KVM in lucid recently (that is the part that varies) | 19:41 |
| ttx | nurmi: just tried to do a test for smoser -- I get "restarting system" as the last message in get-console-output and then nothing | 19:42 |
| === gnac_ is now known as gnac | ||
| nurmi | ttx: if the libvirt/kvm combination supports reboot, then eucalyptus should work as well | 19:42 |
| ttx | nurmi: looks like it doesn't :) | 19:42 |
| ttx | nurmi: any way to trigger it artifically on the NC ? | 19:43 |
| ttx | virsh start <instance> ? | 19:43 |
| mathiaz | nurmi: hm - so the CLC needs also to be able to route to the public IPs of the CC | 19:43 |
| mathiaz | nurmi: IIUC instances asking for meta-data will have their source IP set to their public IP | 19:43 |
| nurmi | ttx: if that didn't work, then I don't know another way, perhaps a 'start' (you'll have to do it fast, though, before euca marks it as terminated | 19:43 |
| * ttx runs | 19:44 | |
| mathiaz | nurmi: if the CLC doesn't have a route setup to the CC things are not working correclty | 19:44 |
| nurmi | mathiaz: the public ips? | 19:44 |
| mathiaz | nurmi: right - there a SNAT rule on the CC | 19:44 |
| nurmi | mathiaz: those should be on the same subnet as the CC, which also must have an address that is routable from the CLC? | 19:45 |
| nurmi | mathiaz: nod | 19:45 |
| nurmi | mathiaz: oh i see | 19:45 |
| nurmi | mathiaz: you're specifying public IPs that are on a different subnet from the CC's public interface | 19:45 |
| mathiaz | nurmi: yes | 19:46 |
| mathiaz | nurmi: and the CLC doesn't know about it | 19:46 |
| nurmi | mathiaz: yeah, the CLC must be able to route to the instance's public IPs | 19:46 |
| nurmi | mathiaz: for the meta-data service to work | 19:47 |
| mathiaz | nurmi: right - a workaround is to masquerade that traffic | 19:47 |
| mathiaz | nurmi: adding an iptables rules that just masquerade traffic to 169. | 19:48 |
| nurmi | mathiaz: without the source IP, though, the meta-data service will not know which data to return | 19:49 |
| mathiaz | nurmi: ah good point | 19:49 |
| nurmi | mathiaz: that is the only reason we don't use MASQ (which would be much simpler :) | 19:49 |
| mathiaz | nurmi: right - I guess that documenting that configuration is enough for now | 19:50 |
| mathiaz | nurmi: another solution would be to proxy meta-data requests via the CC at the http level | 19:50 |
| mathiaz | nurmi: but that would require some redisgn | 19:50 |
| mathiaz | *redesign* | 19:51 |
| nurmi | mathiaz: yep, we've considered that as well - the complexity comes from the fact that some of the data is dynamic | 19:51 |
| mathiaz | smoser: so the instance is stuck here in the boot process: http://paste.ubuntu.com/355668/ | 19:52 |
| nurmi | mathiaz: in that it can change at run-time (so, we have a distributed state problem, which we try to avoid whenever possible) | 19:52 |
| ttx | mathiaz: what did you test ? | 19:52 |
| mathiaz | ttx: the current-non-fixed image | 19:53 |
| ttx | mathiaz: in fact it's not stuck | 19:53 |
| mathiaz | ttx: is this what I'm supposed to see? | 19:53 |
| ttx | mathiaz: yes, but it's not stuck | 19:53 |
| ttx | mathiaz: ssh is running | 19:53 |
| smoser | hm... | 19:53 |
| ttx | mathiaz: we are missing the ec2: messages but that's anither bug | 19:54 |
| ttx | mathiaz: that's what smoser said, at least | 19:54 |
| ttx | smoser: I've trouble testing | 19:54 |
| smoser | we are definitely missing ssh messages. | 19:54 |
| ttx | smoser: looks like I can't reboot | 19:54 |
| mathiaz | smoser: well - I can't connect to the instance | 19:54 |
| ttx | (not your fault) | 19:54 |
| mathiaz | smoser: the ssh client is stuck at connecting | 19:55 |
| ttx | smoser: I'm losing the instance if I reboot | 19:56 |
| smoser | mathiaz, i dont know. can't think of why it would be stuck where it is. | 19:56 |
| smoser | where does it go to? | 19:56 |
| mathiaz | smoser: ok - I'm trying to figure out if ssh is running according to the message log | 19:56 |
| smoser | instances in kvm reboot fine, i've verified that locally. same is true on ec2. | 19:57 |
| smoser | obviously timing or something could break that. | 19:57 |
| smoser | i should install euc | 19:57 |
| nurmi | smoser: maybe the libvirt abstraction? | 19:57 |
| ttx | smoser: I reboot, then I get "restarting system" as the last message in get-console-output | 19:58 |
| nurmi | smoser:ttx:mathiaz: general euca/VM debugging tool - run /usr/share/eucalyptus/gen_kvm_libvirt_xml to see the libvirt 'template' that we use to run the VM | 19:59 |
| ttx | my geuss is that it's stuck at "rebooting", and never actually reboots | 19:59 |
| nurmi | ttx: there are some libvirt options to set various behaviors when libvirt recieves the 'reboot' call, playing with adding them to the template may be useful | 20:00 |
| mathiaz | smoser: ttx: it works! | 20:01 |
| ttx | smoser: any other way to exercise the code, without rebooting ? | 20:01 |
| mathiaz | smoser: ttx: I can connect to the ssh daemon running on the instance | 20:01 |
| smoser | mathiaz, was it just slow to come up? | 20:02 |
| mathiaz | smoser: and I see the public key denied | 20:02 |
| ttx | mathiaz: that's where I am | 20:02 |
| mathiaz | smoser: I can't say - it was an issue with my setup | 20:02 |
| smoser | so you see public key denied? thats not "works", though | 20:02 |
| * mathiaz tries the proposed-fix | 20:02 | |
| mathiaz | smoser: well - that's what was expected with the current-not-fixed image? | 20:02 |
| smoser | right | 20:03 |
| smoser | ok. good. | 20:03 |
| ttx | <ttx> smoser: any other way to exercise the code, without rebooting ? | 20:03 |
| smoser | ttx, yeah, you can mount -o loop the image and install the new pkg | 20:04 |
| smoser | then register | 20:04 |
| smoser | and start instance | 20:04 |
| smoser | that is what mathiaz is doing now | 20:04 |
| smoser | ttx, actually, you might not need ar eboot | 20:04 |
| smoser | try just rm -Rf /var/lib/cloud/*, then start ec2init | 20:05 |
| ttx | hmm | 20:05 |
| ttx | rebooting works if I don't install the modified ec2-init | 20:05 |
| smoser | ugh | 20:07 |
| mathiaz | smoser: \o/ | 20:08 |
| mathiaz | smoser: works! | 20:08 |
| mathiaz | smoser: I was able to login into the -fixed instance | 20:08 |
| smoser | well good to have one happy customer, but why not ttx. | 20:08 |
| mathiaz | smoser: however the ssh public key is not available in the console.log | 20:09 |
| smoser | right | 20:09 |
| * mathiaz files a bug | 20:09 | |
| racquad | hi guys, I'm with trouble with .htaccess file and userdir module. .htaccess is ok in regular paths, but doesn't work at all under userdir paths | 20:09 |
| ttx | smoser: maybe I miss something. I usually do miss things when I work late | 20:09 |
| ttx | mathiaz: could you reproduce the reboot issue ? I can reboot a pristine 20100111 instance, but if I install the new ec2-init before rebooting, then it fails | 20:10 |
| mathiaz | ttx: by rebooting you mean just logging and running the reboot command? | 20:11 |
| ttx | mathiaz: yes | 20:11 |
| mathiaz | ttx: how do you do on a pristine 20100111 where you can't login? | 20:11 |
| ttx | 20100111 is fine | 20:11 |
| ttx | 20100111.1 is broken | 20:12 |
| smoser | where are instructions for installing uec. | 20:12 |
| smoser | or do you think i should just try to get the alpha1 uec up | 20:12 |
| ttx | smoser: you should just use your alpha1 install | 20:12 |
| mathiaz | smoser: I'd try alpha2 - it's working | 20:13 |
| smoser | if you hold your mouth right. | 20:13 |
| ttx | mathiaz: he already has a setup | 20:13 |
| mathiaz | smoser: now it depends how you plan to install it? iso? | 20:13 |
| smoser | you've got a very friendly definition of "working" :) | 20:13 |
| mathiaz | ttx: reboot works for me | 20:13 |
| ttx | ... | 20:14 |
| mathiaz | ttx: the instance has rebooted according to the console.log file on the NC | 20:14 |
| ttx | mathiaz: reboot what | 20:14 |
| ttx | 20100111+new ec2-init ? | 20:14 |
| mathiaz | ttx: and I can login into ssh | 20:14 |
| mathiaz | ttx: 20100111.1 + new ec2-init | 20:14 |
| ttx | ok then :) | 20:15 |
| mathiaz | smoser: I think we're good here | 20:16 |
| ttx | mathiaz: looks like it's worth at least an upload and an image respin | 20:16 |
| * mathiaz nods | 20:16 | |
| ttx | I'll let you guys sort it out | 20:16 |
| smoser | alright. please sponsor that patch then. | 20:16 |
| mathiaz | smoser: I'm going to upload your ec2-init | 20:16 |
| ttx | and pick it up for testing tomorrow morning | 20:16 |
| === dendro-afk is now known as dendrobates | ||
| smoser | i'll spin an image build now | 20:16 |
| smoser | Warning: failed to parse error message from AWS: <unknown>:1:0: syntax error | 20:17 |
| smoser | EC2ResponseError: 403 Forbidden | 20:17 |
| smoser | Failure: 403 Forbidden | 20:17 |
| smoser | does that ring a bell ? | 20:17 |
| ttx | yep | 20:17 |
| smoser | from euca-describe-images | 20:17 |
| ttx | sounds like the deadlock thing | 20:17 |
| ttx | try sudo stop eucalyptus | 20:18 |
| ttx | sudo start eucalyptus | 20:18 |
| ttx | bug 444352 | 20:19 |
| smoser | that fixed it | 20:19 |
| uvirtbot | Launchpad bug 444352 in ubuntu-release-notes "DB deadlock on reboot prevents UEC from working, temporarily - 403 Forbidden errors" [Undecided,Fix released] https://launchpad.net/bugs/444352 | 20:19 |
| mathiaz | smoser: allright - ec2-init uploaded | 20:22 |
| maestrojed | I have built LAMP server with Ubuntu. I am missing a mail server that would allow me to use php's sendmail(). What would be the easiest to install/get up and running? | 20:34 |
| Xodiac13 | i need help with the error i get i have torrentflux installed and when i try from another computer i get this error SSL received a record that exceeded the maximum permissible length. | 20:48 |
| Xodiac13 | i had no problem with it when i was getting another server ready but now idk | 20:49 |
| marks256 | If anyone here has complied their own kernel, what is your average compile time? | 20:51 |
| Xodiac13 | marks256: i need help with torrentflux i get this error SSL received a record that exceeded the maximum permissible length. | 20:55 |
| jpds | marks256: https://edge.launchpad.net/ubuntu/+source/linux/2.6.32-10.14/+build/1434680 | 20:56 |
| Xodiac13 | jpds: i need help with torrentflux i get this error SSL received a record that exceeded the maximum permissible length. | 20:56 |
| jpds | Xodiac13: I know, I saw. But I've never used torrentflux, so; no idea. | 20:57 |
| Xodiac13 | jpds: when i try to go to port 80 thats when i get the error | 20:57 |
| Xodiac13 | crap | 20:57 |
| marks256 | jpds, ouch. 3.5 hours. haha. ok thanks | 20:57 |
| Xodiac13 | jpds: do you know anyone that knows about it | 20:57 |
| marks256 | Xodiac13, google? | 20:57 |
| Xodiac13 | mark256: i tried google see i never had this problem or if i can find a tutorial or something on how to get it working i already tried port forwording | 20:58 |
| Xodiac13 | mark256: but then i realized its probably some config file or the certificate is giving me an error | 20:58 |
| mathiaz | zul: what are the plan for php5 in lucid? | 21:01 |
| mathiaz | zul: are we sticking to 5.2 or upgrade to 5.3? | 21:01 |
| Xodiac13 | #torrentflux | 21:02 |
| Xodiac13 | join #torrentflux | 21:02 |
| marks256 | put a slash in front Xodiac13 | 21:02 |
| Xodiac13 | mark256: thanks | 21:02 |
| === luis__lopez is now known as luis_lopez | ||
| Xodiac13 | #torrentflux/ | 21:03 |
| Xodiac13 | lol | 21:03 |
| marks256 | "/join #torrentflux" | 21:03 |
| Xodiac13 | o okay duh thanks | 21:03 |
| Xodiac13 | no one there | 21:03 |
| diago | I need to do change passwords for ldap, but I can't figure out what the salt is to do so. Does anyone know where I can find this? | 21:13 |
| zul | mathiaz: i would like to stick with 5.2 and the security team probaby wants to stick with 5.2 as well | 21:16 |
| mathiaz | zul: why? | 21:17 |
| zul | mathiaz: i think 5.3 is still buggy | 21:17 |
| zul | and its still in debian experimental | 21:18 |
| zul | mathiaz: i wouldnt mind having it in universe if it plays nicely and if someone takes care of security for it | 21:22 |
| cab938 | I'm running a script as sudo, but I want to execute some lines as the user who is currently executing the script | 21:23 |
| cab938 | can I do this without hardcoding their username? | 21:23 |
| qman__ | cab938, the only way I know of to do that without hardcoding the user is to put the 'sudo's for the root stuff inside the script, and simply not sudo the lines that don't need root | 21:28 |
| qman__ | you could also grab the UID at the beginning, but you'd still have to put the sudo inside the script for it to work | 21:29 |
| Xodiac13 | i need help with torrentflux i get a ssl error saying its too long | 21:34 |
| uvirtbot | New bug: #506332 in ec2-init "Can't login with SSH to Lucid UEC image - uec metadata service returns a string instead of a list of string for ssh public keys" [High,In progress] https://launchpad.net/bugs/506332 | 21:36 |
| zul | ajmitch: so you are going to try to get 5.2 and 5.3 playing side by side? | 21:37 |
| ajmitch | I can give it a go, depending on how annoying the package renaming is | 21:37 |
| zul | mathiaz: ^^ there you go :) | 21:38 |
| ajmitch | hopefully 5.3 will actually be stable enough this time to replace 5.2 | 21:38 |
| EtienneG | ok, there we are! | 21:43 |
| EtienneG | context for the rest of the channel participants: I was asking mathiaz privately about the best network topology for running UEC | 21:43 |
| mathiaz | EtienneG: IIRC the CC is already doing NAT | 21:43 |
| mathiaz | EtienneG: so you don't need to do anything special | 21:44 |
| EtienneG | mathiaz, really? that would be awesome! | 21:44 |
| mathiaz | EtienneG: note that the CLC will need proper routes to the CC to talk to the *public* ips of the instances | 21:44 |
| mathiaz | EtienneG: otherwise the meta-data service won't work (I've run into this issue today) | 21:44 |
| EtienneG | mathiaz, that is a given, I will running the CLC and CC on the smae machine anyway | 21:44 |
| mathiaz | EtienneG: ah - so things will be simpler then | 21:45 |
| mathiaz | EtienneG: you don't need NAT then | 21:45 |
| EtienneG | mathiaz, but I would be running Walrus on a separate machine, though | 21:45 |
| EtienneG | so I guess tha yes, NAT will be needed for the NC to fetch the AMI. right? | 21:46 |
| mathiaz | EtienneG: hm - I'd suggest to run CLC+Walrus then | 21:46 |
| mathiaz | EtienneG: some topologies haven't been tested | 21:46 |
| mathiaz | EtienneG: yes - you're right. | 21:46 |
| EtienneG | mathiaz, so: (CLC + Walrus) <---> (CC + SC) <---> (nc, nc, nc, ...) | 21:47 |
| mathiaz | EtienneG: right - that's an good setup | 21:47 |
| mathiaz | EtienneG: I'm running something similar | 21:47 |
| EtienneG | mathiaz, ok, i will do that then | 21:47 |
| mathiaz | EtienneG: same setup except with only one network | 21:47 |
| EtienneG | mathiaz, thanks for the clarification, otherwise I would have recommended (Walrus + SC) -> (CLC + CC) -> nc, nc, nc | 21:48 |
| EtienneG | would not have worked so well | 21:48 |
| mathiaz | EtienneG: the SC and CC need to be on the same network | 21:48 |
| EtienneG | mathiaz, yes, right, missed it! | 21:49 |
| mathiaz | EtienneG: the SC uses aoe as it provides the block storage service | 21:49 |
| EtienneG | mathiaz, if i am not mistaken, the CLC needs to talk to the SC, right? | 21:49 |
| mathiaz | EtienneG: https://wiki.ubuntu.com/FoundationsTeam/UECInstallerEnhancement | 21:51 |
| mathiaz | EtienneG: ^^ has a diagram of who needs to connect to whom | 21:51 |
| EtienneG | mathiaz, that is terribly useful. thanks! | 21:56 |
| === MTecknology is now known as MTeck-ricer | ||
| smoser | mathiaz, ttx, kirkland there is a 20100112.1 build running, it will contain the updated ec2-init | 22:10 |
| mathiaz | smoser: great - thanks! | 22:11 |
| smoser | it will also have output named lucid-server-uec-arch | 22:11 |
| smoser | rather than lucid-server-arch | 22:11 |
| xteejx | hey guys, anyone here? | 22:26 |
| xteejx | can someone take a look at bug 115967 please? It affects Karmic, and may affect Lucid, both server. From a triaging point of view does it need any more debugging information? ldap doesn't have a documented triaging procedure and I've asked our Bug Control team. | 22:29 |
| uvirtbot | Launchpad bug 115967 in sudo "sudo-ldap not working with ldaps" [Medium,Confirmed] https://launchpad.net/bugs/115967 | 22:29 |
| uvirtbot | New bug: #506667 in euca2ools (main) "euca-describe-volumes fails with 'Volume' object has no attribute 'availabilityZone'" [Undecided,New] https://launchpad.net/bugs/506667 | 22:36 |
| === erichammond1 is now known as erichammond | ||
| gregcoit | hi all. if "netstat -na|grep 6082" returns "tcp 0 0 127.0.0.1:6082 0.0.0.0:* LISTEN", is that port open to remote connections? | 22:44 |
| === erichammond1 is now known as erichammond | ||
| === A_Tuin is now known as A-Tuin_ | ||
| macli | Hi, curious, what test automation software ubuntu server use for testing? | 23:06 |
| === alex88 is now known as alex88[sleep] | ||
| === robbiew is now known as robbiew_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!