[00:01] hi, how do i create lvm on my vg..in command line [00:05] ruben23: you mean LV in an existing VG? [00:06] cemc: yes i have exixting VG [00:06] ruben23: man lvcreate [00:07] cemc: i would like to increase my /var/ cemc: [00:07] http://pastebin.com/m445a6846 === erichammond1 is now known as erichammond [00:10] ugh, how I hate the default VG and LV names :) should be something more like dev/mapper//, IMHO [00:11] 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:12] 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:18] kirkland: hey - did you run the new eucalyptus.conf files system via upstream? [00:19] mathiaz: i did [00:19] mathiaz: nurmi wants me to get rid of /usr/share/* [00:19] kirkland: ok - so the issue I see is that the CC is not able to load its configuration file [00:19] mathiaz: and just put that stuff into /etc/eucalyptus/eucalyptus.conf [00:19] kirkland: right - the cluster.c file only knows about *two* configuration file [00:19] mathiaz: yeah, i'm sorry i didn't update you [00:19] mathiaz: nurmi implemented half of it [00:20] mathiaz: while i implemented the other half [00:20] mathiaz: but we miscommunicated on the file names [00:20] kirkland: so the whole include stuff doesn't work since the cluster config parser doesn't understands includes [00:20] mathiaz: and the design changed, after i talked to him, was my multi-hour conversation with you and slangasek [00:20] mathiaz: right, it just looks for KEY=VALUE [00:20] * mathiaz would just suggest to use yam; [00:21] * mathiaz would just suggest to use *yaml* [00:21] kirkland: so what's the current plan [00:21] kirkland: ? [00:22] mathiaz: well, i told nurmi that i need to collect my notes to recollect why we needed 3, and not just 2 [00:22] mathiaz: i remember i lost the argument in favor of just 2 files [00:22] mathiaz: but i don't recall which reason was the reason i finally gave in to [00:22] kirkland: right - in order to be able to stick new default options without prompting for a conffile [00:23] kirkland: if new options are available and need to be defined, we'd rather not update eucalyptus.conf which is a conffile [00:23] kirkland: that being said we could update eucalyptus-local.conf programatically [00:24] kirkland: ie from the upgrade script [00:24] mathiaz: it certainly sounds like upstream would prefer it this way [00:24] 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] eucalyptus.conf and eucalyptus-local.conf [00:25] 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] kirkland: and have all the default options set in eucalyptus-local.conf [00:26] kirkland: maintainer scripts and euca_conf write to eucalyptus-conf [00:26] kirkland: maintainer scripts and euca_conf write to eucalyptus-local.conf [00:26] kirkland: if new options are needed, we can mangled eucalyptus-local.conf [00:26] mathiaz: okay [00:27] kirkland: probably using a token to delimit the section updated by euca_conf [00:27] mathiaz: how much effort do you suggest i put in supporting upgrades from today's version to the next version? [00:27] kirkland: none [00:27] mathiaz: i'm inclined to call today's bust [00:27] okay [00:27] mathiaz: i can handle this, i think [00:28] 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] kirkland: the package has been in the archive for just one day [00:28] mathiaz: right [00:28] kirkland: and it's a developement version - we do our best effort [00:28] kirkland: hm nope - /usr/share/eucalyptus/eucalyptus-defaults.conf goes into /var/lib/eucalyptus/eucalyptus-local.conf [00:29] kirkland: /etc/eucalyptus/eucalyptus.conf stays at it is [00:29] kirkland: /etc/eucalyptus/eucalyptus.conf stays *as* it is [00:29] kirkland: maintainer scripts and euca_conf should *not* touch /etc/eucalyptus/eucalyptus.conf [00:29] kirkland: /etc/eucalyptus/eucalyptus.conf is the override, while /var/lib/eucalyptus/eucalyptus-local.conf is the default configuration file [00:29] mathiaz: WTF goes in eucalytpus.conf then? [00:30] kirkland: what's in it now [00:30] mathiaz: as of yesterday, everything (monolithic config file) [00:30] mathiaz: as of today, 2 lines, sourcing -defaults and then -local [00:30] mathiaz: as of tomorrow .... ???? [00:31] kirkland: tomorrow: 1 line sourcing /var/lib/eucalyptus/eucalyptus-local.conf [00:31] mathiaz: installed by dpkg as a conf file? [00:31] kirkland: and /var/lib/eucalyptus/eucalyptus-local.conf is the merge of eucalyptus-local.conf and eucalyptus-default.conf [00:31] kirkland: yes [00:31] kirkland: today's /etc/eucalyptus/eucalyptus.conf is all good IMO [00:32] mathiaz: and when we add a new option [00:32] kirkland: (modulo the source change) [00:32] mathiaz: we add it to the manpage [00:32] mathiaz: and mangle -local in the maintainer scripts? [00:32] kirkland: yes! :) [00:32] mathiaz: okay [00:32] mathiaz: i'll make it happen [00:33] mathiaz: you're not particular about eucalyptus-local.conf vs. eucalyptus.local.conf ? [00:34] mathiaz: nurmi's code does eucalyptus.local.conf [00:34] kirkland: not all all [00:34] kirkland: right - noticed that [00:34] kirkland: I'm testing the new setup discussed above [00:34] mathiaz: his code also sources /etc/eucalyptus/eucalypts.local.conf, which i'll put a symlink there to /var [00:34] kirkland: (ie eucalyptus.conf and a merged eucalyptus.local.conf) [00:34] mathiaz: btw, does your -cc preseed file work? [00:35] mathiaz: i'm using your eucalyptus values there and i'm not getting a cloud installation [00:35] kirkland: :) - haven't tested it for a while [00:35] kirkland: right - that's very well possible [00:35] kirkland: the debconf questions have probably changed [00:35] mathiaz: okay [00:35] mathiaz: does order matter at all in preseed files? [00:36] kirkland: I don't think so [00:36] mathiaz: hrm, okay [00:36] kirkland: the preseed file is read at once and all the values are dumped in the debconf database [00:36] mathiaz: right, that's what i figured [00:36] mathiaz: my node preseed is working well, but not the clc/cc/sc/walrus [00:36] kirkland: the relevant scripts access the debconf database, not the preseed file [00:37] * kirkland kinda wishes eucalyptus worked more that way :-) [00:40] kirkland: hm - thinking about the filenames [00:40] kirkland: .local.conf seems counter-intuitive [00:40] kirkland: as .local.conf is the file edited by euca_conf and the maintainer scripts [00:41] kirkland: how about switching the two? [00:41] kirkland: eucalyptus.conf not being a conffile anymore [00:41] kirkland: and eucalytpus.local.conf is a conffile [00:42] kirkland: to be edited by the local sysadmin [00:42] kirkland: eucalyptus.conf would then source .local.conf at the *end* [00:42] kirkland: and point the sysadmin to edit .local.conf instead [00:43] mathiaz: why have .local.conf at all? [00:43] mathiaz: why not just make eucalyptus.conf not a conf file [00:43] mathiaz: when we need to add something to it, we just jam it in [00:44] kirkland: well - if we do so we need to make sure that local modifications are kept [00:44] kirkland: when new options are added [00:45] * kirkland has grown exhausted of this "challenge" [00:45] kirkland: it's possible - the logic in the maintainer scripts can get ugly though [00:45] kirkland: I totally understand you [00:46] kirkland: it's complicated [00:46] mathiaz: at the end of the day, eucalyptus does not "source" these files [00:46] mathiaz: it does a crappy job parsing them instead [00:46] mathiaz: for that reason, cascading any set of sourcing/including just doesn't fit eucalyptus' model [00:46] * mathiaz nods [00:46] kirkland: aren't the upstart job sourcing it? [00:47] mathiaz: did you see my note earlier about being out of whack for a few months? [00:47] mathiaz: ubuntu's code does, eucalyptus' code does not [00:47] Sam-I-Am: yes - that's life [00:47] k, just wanted to make sure [00:47] Sam-I-Am: thanks for letting me know though [00:47] hopefully its going to be fixed in a bit [00:47] i'm sorry i kinda fell off [00:48] Sam-I-Am: that's ok - as long as you attend to the more important things ;) [00:48] Sam-I-Am: I hope everything will turn out well [00:48] things are starting to look good [00:49] kirkland: ah ok. [00:49] should have a job back in the sys/netadmin world soon [00:49] kirkland: I thought that having eucalyptus.conf was a hard requirement [00:49] kirkland: so what we could do is to introduce /var/lib/eucalytpus/eucalyptus-defaults.conf [00:50] kirkland: keep /etc/eucalyptus/eucalyptus.conf as it is now [00:50] kirkland: and have euca_conf and maintainer scripts modify /var/lib/eucalytpus/eucalyptus-defaults.conf [00:50] kirkland: and update the ubuntu upstart jobs to source both /var/lib/eucalytpus/eucalyptus-defaults.conf and /etc/eucalyptus/eucalyptus.conf [00:52] 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] mathiaz: hrm [00:52] kirkland: ie: EUCALYPTUS_CONF_LOCATION=/var/lib/eucalytpus/eucalyptus-defaults.conf [00:53] kirkland: EUCALYPTUS_CONF_OVERRIDE_LOCATION=/etc/eucalyptus/eucalyptus.conf [00:53] mathiaz: i'm starting to feel more like throwing in the towel ... back to a monolithic /etc/eucalyptus/eucalyptus.conf [00:53] mathiaz: just not a conffile [00:53] kirkland: that way eucalyptus.conf stays as a conffile [00:53] mathiaz: users, euca_conf, dpkg edits that file [00:53] mathiaz: upstream code stays the same [00:54] mathiaz: we just seed it if it's not there [00:54] mathiaz: and handle new options ad hoc [00:54] mathiaz: we have a manpage now [00:54] kirkland: the last part may be trickier though [00:54] mathiaz: then we don't handle them at all in dpkg ... we handle them in euca_conf === erichammond1 is now known as erichammond [00:55] mathiaz: document them in the manpage [00:55] mathiaz: and force eucalyptus to choose a sane (documented) default if unspecified [00:56] kirkland: right - does the code currently have sane default if unspecified? [00:56] mathiaz: don't know [00:56] kirkland: AFAICT no [00:56] kirkland: as the CC doesn't start with the current empty eucalyptus.conf file [00:57] kirkland: as the CC doesn't start with the current *almost* empty eucalyptus.conf file [00:58] mathiaz: okay -- in that case, you're instructed to run "euca_conf" [00:58] mathiaz: until you get a eucalyptus.conf that is not empty [00:58] mathiaz: with sufficient configuration to start your cluster [00:59] kirkland: well - that's how things were in karmic, with euca_conf being run in the postinst script [00:59] kirkland: the problem is how to handle upgrades [00:59] kirkland: where you need to add new (default) options [00:59] kirkland: either we can rely on upstream to do that [01:00] kirkland: or we can ship a default set of options that can be easily upgraded [01:02] mathiaz: nurmi is here [01:02] * nurmi waves [01:02] nurmi: hi! :) [01:02] mathiaz: hey mathiaz! [01:02] mathiaz: what's up? [01:02] nurmi: is it snowing down there? [01:03] nurmi: kirkland and I have been discussing how to handle configuration files in eucalyptus [01:03] mathiaz: heh, hardly [01:03] mathiaz: nod [01:03] nurmi: IIUC there was one monolitic configuration file (eucalyptus.conf) [01:04] nurmi: and you've added an override (eucalyptus.local.conf) [01:04] mathiaz: that is correct [01:04] mathiaz: i also think it is important to clearly state how the files are parsed [01:04] nurmi: IIUC it's key=value [01:05] 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] nurmi: and isn't actually a shell file [01:05] mathiaz: right, that is the key point [01:05] nurmi: right - so it's fair to assume that the configuration file are not shell fragment [01:05] mathiaz: yep, in fact, that will potentially break the C parser [01:05] nurmi: but just key=val pair to keep the lowest commmon denominator [01:06] mathiaz: correct [01:06] nurmi: is it "incorrect" that our upstart scripts (etc) actually source them as if they're shell? [01:06] kirkland: no, the files can be sourced by bash/sh, in that they're just KEY=VAL and comment lines start with '#' [01:07] nurmi: do the different components of eucalyptus work correclty if there isn't any configuration file? [01:07] hmm [01:07] nurmi: or rather if configuration files don't have all the options defined [01:07] nurmi: for example, a new version introduces a new option - what should be done to upgrade existing configuration files? [01:07] 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:08] mathiaz: we have been using 'euca_conf --upgrade' to handle config file upgrades [01:08] mathiaz: sorry '--upgrade-conf' [01:08] nurmi: ok [01:09] nurmi: --upgrade-conf will add new keys with reasonable default values [01:09] nurmi: and (may be) remove deprecated keys? [01:10] mathiaz: our common mechanism is to move the old file aside, put in a new default, then run '--upgrade-conf' [01:10] mathiaz: right [01:10] nurmi: how do you handle local modified options? [01:10] nurmi: for example, the list of nodes? [01:10] mathiaz: they persist when one uses 'upgrade-conf' [01:10] nurmi: is this the case for any options, or only of the nodes option? [01:11] mathiaz: so any value that you had before, with a key that is still valid, persists [01:12] nurmi: ok [01:12] nurmi: where is the new default file that upgrade-conf uses? [01:12] nurmi: in /usr/share/eucalyptus/... ? [01:12] mathiaz: no it would be /etc/eucalyptus/eucalyptus.conf [01:13] nurmi: I meant in the package [01:13] 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] mathiaz: that is how our packages do conf upgrades [01:14] nurmi: and you move the existing eucalyptus.conf file in the preinstall script? [01:14] mathiaz: nod [01:14] nurmi: and /etc/eucalyptus/eucalyptus.conf is a conffile then? [01:15] nurmi: ie it's shipped in the package as /etc/eucalyptus/eucalyptus.conf? [01:15] mathiaz: yes [01:16] kirkland: what happens if a conffile has been moved? [01:16] kirkland: is it reintalled? or is there an prompt made by dpkg? [01:16] mathiaz: in which case? [01:16] mathiaz: yesterday, or today's upload? [01:16] 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] nurmi: I'm trying to figure out whether dpkg would prompt the end user would be prompted [01:16] .oO(more smoothly) [01:17] kirkland: yesterday [01:17] mathiaz: it would have been reinstalled [01:17] nurmi: right - one of the goal here is to avoid useless prompts [01:17] mathiaz: nod === erichammond1 is now known as erichammond [01:18] 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] 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] nurmi: kirkland: is that correct? [01:19] nurmi: yes - that's one possibility [01:20] mathiaz: i'm digesting that still ... [01:20] 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] mathiaz: avoiding the need to mess with eucalyptus.conf at all [01:21] mathiaz: and, since eucalyptus.local.conf is not part of the package, the whole upgrade process could happen in post-install [01:21] mathiaz: okay, i'm done following that idea, thanks :) [01:21] * mathiaz thinks [01:22] * kirkland thinks eucalyptus does its own thing with its configuration files; it doesn't want dpkg or distro management thereof [01:22] nurmi: right [01:22] * kirkland thinks we make eucalyptus.conf a non-conffile [01:23] and it's up to euca_conf to keep it sane [01:23] ^ at least, that's one option [01:23] kirkland: Error: "at" is not a valid command. [01:23] thanks uvirtbot` [01:23] nurmi: so having eucalyptus.conf be a conffile and eucalyptus.local.conf a configuration file edited by euca_conf and the local sysadmin [01:24] nurmi: you wouldn't need to move eucalyptus.conf in the presinstall [01:24] mathiaz: nod [01:24] nurmi: since eucalyptus.conf shouldn't be changed [01:24] mathiaz: we wouldn't need to mess with eucalyptus.conf at all [01:24] nurmi: and if it is, then dpkg should prompt for a diff [01:25] mathiaz: well it *could* be, but that is up to the admin [01:25] mathiaz: nod [01:25] nurmi: right - it could be - but then it's up to the admin and we don't wanna loose anything [01:25] mathiaz: nod [01:25] nurmi: hence relying on dpkg conffile mechanism [01:25] nurmi: and then euca_conf would modify .local.conf [01:26] nurmi: and upgrade .local.conf as well in the postinst [01:26] mathiaz: nod [01:26] kirkland: ^^ sounds like a good plan to me [01:27] kirkland: eucalyptus.conf stays as a conffile [01:27] * kirkland reads [01:27] kirkland: euca_conf modifies eucalytpus.local.conf [01:27] kirkland: the sysadmin is advised to edit eucalytpus.local.conf [01:27] mathiaz: and what is eucalyptus.conf seeded with on new install? [01:28] kirkland: eucalyptus.local.conf is actually a configuration file [01:28] kirkland: eucalytpus.conf is a conffile, ie is part of the debian package [01:28] kirkland: it's content is the default eucalytpus.conf with all the options set correclty [01:29] kirkland: eucalyptus.local.conf is installed by the maintainer script (thus is a configuration file, but not a conffile) [01:29] maybe s ' [01:29] er [01:29] mistype, nvm [01:29] mathiaz: basically what i put in /usr/share ? [01:29] kirkland: nothing [01:30] kirkland: the current eucalyptus-default.conf is /etc/eucalytpus/eucalyptus.conf [01:30] kirkland: and the current eucalyptus.conf is the base for eucalyptus.local.conf [01:30] mathiaz: right [01:30] kirkland: euca_conf modifies eucalyptus.local.conf (during pkg upgrade as well) [01:31] mathiaz: gotcha [01:31] kirkland: and since eucalyptus.local.conf is *not* a conffile, there shoudn't be any prompt on upgrades [01:31] nurmi: you're good with this? [01:31] kirkland: yep! that sounds great to me [01:31] kirkland: now - there is a special case to upgrade from karmic [01:31] kirkland: since eucalyptus.conf will have changed between karmic and lucid [01:32] kirkland: (well technically it is different on every system since the list of NODES is local) [01:32] kirkland: i'll make sure '--upgrade-conf' is working properly, over the next week, if this is the decided upon plan [01:33] 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] kirkland: so that dpkg installs the new eucalyptus.conf file [01:33] mathiaz: right, i already hacked it that way in today's upload [01:33] mathiaz: slangasek advised me as such [01:33] kirkland: and then --upgrade-conf should be run as part of the normal upgrade process in the maintainer script [01:34] mathiaz: basically, if upgrading, and eucalyptus.conf exists, and .local doesn't, it's moved to .local [01:34] * mathiaz nods [01:34] nurmi: what's the full syntax for --upgrade-conf? [01:34] mathiaz: always --upgrade-conf ? [01:34] kirkland: nurmi: and so we rely on euca_conf --upgrade-conf to mangle properly the local configuration file [01:34] mathiaz: on any upgrade? [01:34] kirkland: euca_conf --upgrade-conf [01:34] kirkland: yes [01:35] kirkland: however, I am going to need to modify it to work in the new environment (with two config files) [01:35] nurmi: and it does it work in-place ? [01:35] kirkland: nurmi: unless euca_conf --upgrade-conf is *not* idempotent [01:35] mathiaz: i will make it so [01:35] kirkland: mysql-server does the same thin [01:35] kirkland: thing [01:35] kirkland: the upgrade script is always run [01:35] mathiaz: nurmi: okay, i think i know what needs to be done [01:36] it will be a late night, but i'll get it done tonight [01:36] nurmi: ping me if you have a rev you want me to merge [01:36] kirkland: mathiaz: for now, we should omit --upgrade-conf until we have a chance to test it, I think [01:36] nurmi: as i'll depend on your work too [01:36] kirkland: great - I'll setup a local version of the setup [01:36] nurmi: agreed [01:36] mathiaz: cool, let me know what you find [01:36] kirkland: to make sure things are working correclty [01:36] mathiaz: i'll be online for another 5 hours, probably [01:37] 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] nurmi: okay [01:37] nurmi: thanks for irc'ing [01:37] kirkland; anytime - thank *you* guys for working to get this all right [01:37] kirkland: right - so the key part for now is to have euca_conf modify eucalytpus.local.conf rather than eucalyptus.conf [01:38] mathiaz: that's trivial [01:38] kirkland: while waiting for the upgrade-conf the be tested [01:38] mathiaz: i already changed it to edit eucalyptus-local [01:39] kirkland: oh - and the upstart jobs need to be updated [01:39] kirkland: to source both configuration file [01:39] kirkland: and eucalyptus.conf should *not* source eucalytpus.local.conf [01:39] kirkland: since it may break the C parser [01:41] brb guys [01:42] mathiaz: right [02:22] Is there anything wrong with only having LVM2 LV's? [02:22] And no /boot outside the LVM or anything? === jono_ is now known as jono [02:25] zig_: with grub2 it works [02:25] Reliably? [02:26] Yeah, I tested it and it works like a dream with Ubuntu 9.10 server [02:26] /dev/sda & /dev/sdc => /dev/md0 => LVM => root & swap LV's [02:26] A very elegant setup for a software RAID1 system, I think. [02:27] it's been good on my thinkpad with 9.10 [02:27] Yeah [02:27] I'm pleased. [02:27] Second question: Have you dont an ubuntu server installation USB drive? [02:27] luks on lvm with no separate /boot.. nice [02:27] Or rather, USB stick? [02:28] I didn't bother with a crypt setup. [02:28] I have not messed around with bootable USB yet.. actuallly [02:29] yeah I only use it because it's a laptop [02:32] smoser: are you using vmbuilder for the ebs stuff? [02:33] 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:35] so do you do it on an ami or on the build machine? [02:38] you have to do it on an instance [02:38] that part sucks [02:38] oooooh.....fun [02:39] i mention in the spec the complications of many more moving parts [02:41] well now you get to do what we talked about at the last server sprint === 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 [04:33] I have us robotics 56k message modem, How to install driver at ubuntu 8.10??? === rberger_ is now known as rberger [06:01] can anyone help with ubuntu 9.10 and vmware server? [06:01] whats your question [06:02] i can't get the vmware tools to compile in a vmware 9.10 guest [06:02] okay, what error are you getting [06:02] it is not on the officially supported list for vmware server 2.0 [06:03] when it is trying to build the kernel modules, it exits with Error 2 [06:03] failed to insert into kernel [06:03] oh my [06:03] I have done this countless times without error on 9.04 [06:04] will you be around tomorrow? its 1am and i need to get to bed, however i can test this from work :) [06:04] you might want to try the openvm-tools [06:04] or whatever its called now... [06:04] still called that i think [06:04] Parabola: I can be back on tomorrow yep [06:04] they're basically vmware's tools... only some folks outside of vmware update them more quickly to support newer stuff [06:05] alright, i'll be on off and on during the day from 7am est to 4pm est [06:05] is it not best to use the vmware ones though [06:05] they are the vmware tools, more or less [06:05] shouldnt make a difference [06:05] Parabola: I will be on around 9 est [06:05] since the vmware tools are open source [06:06] maybe I am confusing openvm-tools with something else. [06:06] theres even a nice interface using the module installer thing... cant remember its name [06:07] Do you think Vmware will release an updated Server where the tools support 9.10? [06:07] sure [06:07] I am patient I can wait. [06:07] they're just a tad slow [06:07] slow is one word i guess. [06:07] soon to be 3 months behind. [06:07] they'll roll a patch level which will include it most likely [06:08] so pay attention to randomly incrementing build numbers [06:08] sometimes they dont tell you about added OS support [06:09] * Sam-I-Am wanders off to sleep [08:06] <_ruben> Sam-I-Am: open-vm-tools is actually maintained by vmware themselves [09:22] morning [09:39] mornin [09:43] Hello [09:44] Can anybody with an LDAP server help me to confirm this bug : [09:44] https://bugs.edge.launchpad.net/ubuntu/+source/python-ldap/+bug/506317 [09:44] Launchpad bug 506317 in python-ldap "ldap.schema.urlfetch doesn't work anymore since slapd.d migration" [Undecided,New] [09:44] it's a matter of launching 3 lines of Python [09:57] New bug: #423527 in libvirt (main) "Should suspend or shut down domains on system shutdown" [Medium,Triaged] https://launchpad.net/bugs/423527 [10:17] 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 === freeflyi1g is now known as freeflying [10:51] New bug: #506316 in eucalyptus (main) "[lucid] New config file system fails to support node registration" [High,Fix committed] https://launchpad.net/bugs/506316 === giLL0r_ is now known as giLL0r [11:41] Hi! Does anyone know how to run a server in the background that will persist after the shell is closed? [11:42] 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:44] cemc- ty [11:45] 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) === dendrobates is now known as dendro-afk === deegee_1 is now known as deegee [13:06] Is there a way I can configure directory level quota's? [13:21] 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:22] ttx: ack [13:22] zul: also for seeds I still assume that it will be completed by alpha2 [13:22] so I didn't defer any item to alpha3 [13:23] ttx: k [13:25] ttx: umm we are still discussing packages for the server-lucid-seeds packages [13:26] zul, mathiaz: but the discussion should end before thursday, right [13:26]