[02:33] <hallyn> xnox: hey, (stgraber suggested I ask you) do you know of any way offhand to have n thread handlers in an nih_main_loop()?  (particularly this is a nih-dbus app)
[02:39] <xnox> hallyn: first one needs to recompile libnih with "--enable-threading" flag, if there is need we can provide it as a separate package. It's same api/abi (sans threading) but threading is not considered safe for e.g. init.
[02:40] <xnox> hallyn: and then I believe you would have a main_loop per thread.
[02:40] <xnox> hallyn: entirely untested, first step is to recompile and check the test-suite results.
[02:43] <xnox> hallyn: if you want some better thread API, I'm all ears.
[02:43] <xnox> I'm writting a lot of libnih upstream code these days.
[02:45] <xnox> hallyn: if you are ok with something more haevy weight, i'd look into into glib / gio, they have more dbus features/code.
[02:52] <stgraber> xnox: it's for the cgroup manager, I think we're mostly using nih for the convenient dbus API. If we are to move away from it, my guess would be to go straight with libdbus and not depend on a giant library like glib
[02:55] <hallyn> xnox: hm, thanks.
[02:55] <hallyn> stgraber: bs.  if we go away from it, i'm going with straight unix socket :)
[02:56] <hallyn> effing kids these days with their little toolboxes that trade control ('its so complicated') for crappy random boilerplate
[02:56] <stgraber> hallyn: considering the pile of hack you had to do to get ucreds to sort of work with dbus, I can't blame you ;)
[02:56] <hallyn> stgraber: now i realize that really the thing to do is add scm_creds sending to dbus,
[02:56] <stgraber> yeah, but that'd be awkward since dbus supports tcp and a bunch of other medium on which scm_creds won't work
[02:57] <hallyn> same with sending scm_rights though
[03:00] <xnox> stgraber: scm_creds work with libdbus on linux (or so I thought)
[03:01] <xnox> plus libnih-dbus depends on libdbus, so you already have libdbus.
[03:01] <xnox> (granted with nih main loop)
[03:01] <stgraber> xnox: you can get the initial ucred from the socket, passing a scm_cred later on over the raw socket proved to be pretty tricky
[03:01] <xnox> I see.
[03:02] <stgraber> xnox: basically what we need is to have our client send a dbus message, then send a ucred struct, then wait for the reply from the server
[03:02] <stgraber> xnox: the server needs to grab the message from the client, wait to get the ucred, then process the request and return the reply
[03:02] <stgraber> based on what hallyn has been telling me today, it's not nearly as easy to do as it should be...
[03:02] <hallyn> xnox: yeah you cannot send a ucred using dbus.  dbus sends an scm_cred during auth phase but that' sit
[03:03] <hallyn> stgraber: not just not easy, not supported
[03:03] <hallyn> stgraber: however, in the end i figured out how to fetch my own reply so I could bypass the send_message_call_reply_block(0 or whatever
[03:03] <hallyn> that was a big step up
[03:04] <hallyn> all i have to do is manually send the scm-credential over the underlying fd
[03:04] <hallyn> xnox: I don't suppose you are at all 'in' with the upstream dbus crowd? :)
[03:05] <hallyn> still the dbus perf overhead (by all accounts no better than at least 2-4x) may be insurmountable
[03:05] <xnox> *giggle* not really no. If anything they hate me for bringing up "upstart dbus activation" and opening with "remember, scott & lennart had a fight about it 2 years ago"
[03:05] <hallyn> lol
[03:06] <hallyn> stgraber: hm, so would statically linking cgmanager against a custom-build libnih with threading be a problem?  after all we wanted minimal dependencies
[03:06] <xnox> hallyn: hm.. but surely kdbus would need to marshal creds & rights? and it looks like systemd commits of kdbus do have it.
[03:06] <xnox> hallyn: i'd provide threaded libnih in debian/ubuntu, but.....
[03:06] <hallyn> xnox: the server can get the creentials of the caller.  but that's not what i'm after
[03:07] <xnox> hallyn: libnih/upstart are removed from most RPM distros these days due to non-maintainance.
[03:07] <hallyn> non-maintenance?
[03:07] <xnox> hallyn: as in no RPM package maintainers in fedora (after it stopped being their init)
[03:07] <xnox> and almost by definition that meant no other RPM distros maintained it either.
[03:08] <hallyn> gotcha
[03:09] <hallyn> (i woudl have thought the RHEL folks would want to maintain it for a bit)
[03:09] <xnox> hallyn: talk to pitti, he did do dbus work, as far as I remember and he might now a better way to do it.
[03:09] <stgraber> hallyn: any static linking is usually very badly seen from the archive admin team and for good reason (security updates being the biggest one)
[03:09] <hallyn> stgraber: yeah...
[03:10] <stgraber> hallyn: desrt (Ryan Lortie) also has a few commits in dbus upstream (but don't mention nih since he's one of the glib guys ;))
[03:10] <hallyn> i dislike glib and nih equally :)
[03:11] <xnox> cgroups manager is an exercise in FLOSS political correctness =)
[03:11] <hallyn> (not that i would've used dbus at all without nih)
[03:12] <hallyn> xnox: astute
[03:12] <stgraber> my feeling is that we either manage to get nih and dbus to play nice or we go with good old (lxc-style) C and raw unix socket then try to build a protocol that's not too awful on top of that
[03:13] <hallyn> stgraber: i'm done with it for tonight, will look more tomorrow - but near as i can tell, all my tests were working today, but that was an accident and in fact the scm_cred sending is very racy
[03:13] <hallyn> (meaning i'm feeling down on our chance of being able to use dbus - again, unless we start making upstream dbus changes)
[03:14] <stgraber> upstream dbus changes will quite problematic with our plans of backward compatibility...
[03:14] <stgraber> *will be
[03:14] <hallyn> stgraber: yup
[03:14] <hallyn> though couldn't we just also backport the dbus delta? :)
[03:14] <hallyn> 'ust'
[03:14] <hallyn> 'just'
[03:14] <hallyn> i crack me up
[03:21] <zul> hallyn:  yeah will have it tomorrow
[03:23] <xnox> stgraber: hallyn: if i understand it right, once authenticated you can open a new abstract private dbus socket for that client & expect the first connect/authentication to be the "new" crendentials you want the client to pass (if kernels permits you to do that) followed by a stream message / magic cookie you gave the client during it's initial authentication.
[03:23] <xnox> ...... but that wouldn't pass scm_rights, only creds, horum.
[03:24] <xnox> dbus-over-dbus
[03:32] <techact> hi
[03:33] <stgraber> xnox: the trick is, we don't want the default ucred struct that's sent on open. We want an hand made struct to be sent instead which contains a different uid and pid than the default one.
[03:33] <stgraber> xnox: that's how we transmit the uid and pid of the task in a way that gets converted by the kernel into the host namespace.
[03:34] <xnox> stgraber: if it's hand-made, would it be verified by kernel? oh interesting. well the _CRED and _RIGHTS are arrays of ints, which is a native dbus type.
[03:34] <xnox> stgraber: it's just you'd need to hand construct it from a{i} into struct ucred once you receive it.
[03:34] <stgraber> xnox: it is verified and converted by the kernel
[03:35] <stgraber> xnox: that's how we retrict root in a container from sending us a pid that doesn't belong to the container
[03:35] <stgraber> xnox: and that's also how we then get the mapped PID on the host namespace (in the container you send the uid and pid in the container. On the host you receive the uid and pid as seen by the host)
[03:36] <xnox> with marshalling between receiver/sender
[03:36] <stgraber> sending an equivalent of the struct over dbus would bypass that convertion and validation step by the kernel which would make the whole thing worthless
[03:36] <xnox> yeah, it would be worthless.
[03:37] <xnox> i don't see how dbus can help you here, since it's inherently insecure for this. Using sockets is the only way i can think of how you can make sure that kernel does conversion/validation.
[03:37] <stgraber> the biggest issue we have is that there's no easy way from the host to know what's the host PID from a provided container PID. The only two ways we can do that is either by attaching to the container (setns with PID namespace) which is only supported since 3.8 (our target is 3.2) or sending scm_cred over a unix socket
[03:38] <stgraber> so our current dbus implementation is similar to upstart's, so we are our own server on the host and we use a unix socket, so as we have access to the raw socket, we can send the ucred, but as hallyn said, that's very hackish and racy
[03:39] <stgraber> so I guess hallyn will poke at it some more tomorrow and if that looks like too much of a hack, we may fallback to our own protocol, ditching dbus and nih for a good old handmade solution...
[03:40] <stgraber> on the upside, that'd reduce our dependencies to basically just the C library, which would be convenient for portability (LXC supports most distros and native Android)
[03:40] <stgraber> tbh I wasn't terribly looking forward to porting libnih to bionic ;)
[03:42] <rostam> HI I need to install python-autobahn on my 12.04 LTS update 3 system. Could someone help me to find out where to get that? thx
[03:53] <AlecTaylor> Which Java should I install, and how can I install it with its dependencies?
[03:53]  * AlecTaylor tried `sudo apt-get install default-jre -f`
[03:55] <martisj> mornigng
[03:56] <martisj> I'm having issues with our ssh keys on an ubuntu 10.4.3 server.
[03:57] <martisj> When ssh'ing in to the server it's still asking for a password even though my key is in the ~/.ssh/authorized_keys file
[04:14] <mardraum> martisj: check the ssh logs, either incorrect key or file perms usually
[04:15] <martisj> mardraum: thanks!!
[04:16] <martisj> found a stackoverflow related to permissions, but it doesn't seem to be it :S
[04:16] <martisj> probably incorrec key
[04:16] <martisj> :S
[04:38] <martisj> mardraum: n00b question, where is the ssh log located?
[04:40] <martisj> found it now
[04:40] <martisj> var/log/auth.lgo
[04:47] <martisj> I foud this in the log: error: key_from_blob: remaining bytes in key blob 268
[04:47] <martisj> blah :S
[06:10] <yogesh> hi
[08:11] <blueking> hello
[08:12] <blueking> where I find settings for removeable devices,  my raid array /dev/md0  are listed as removeable that it shouldn't be
[08:15] <andol> blueking: Listed where?
[08:17] <blueking> andol:  I installed ubuntu server   and added ubuntu gnome desktop  to it    when open 'files' application  raid array are listed there as removeable
[08:18] <andol> blueking: Have you defined a mount point for /dev/md0 in your /etc/fstab?
[08:18] <blueking> yes
[08:19] <andol> In that case I don't know. At least in Unity I seem to recall that having been the distinction.
[08:19] <blueking> UUID=xxxxxx-some numbersxxx /home/user/downloads ext4 defaults   0  2
[08:20] <blueking> nothing wrong there ?   added this line after finished initial install of ubuntu server
[08:21] <sarnold> blueking: in some sense, it -is- removable, you can always use mdadm to turn off the raid array and thus 'detach' it...
[08:22] <blueking> sarnold:  ok
[08:22] <blueking> it wasn't mounted in start
[08:24] <blueking> usb mounted devices are not listed in fstab   don't know where settings for that are ?
[08:25] <sarnold> blueking: check /etc/udev/ and /lib/udev/ for that...
[08:36] <blueking> sarnold:  will look into it
[08:38] <blueking> sarnold:  nothing configured in udev.conf
[08:40] <sarnold> blueking: no, it wouldn't be, check out /lib/udev/hwdb.d/20-usb-vendor-model.hwdb and other files. information about usb devices is scttered all over the udev files..
[08:40] <sarnold> blueking: time for me to call it a day :) have fun and good luck
[08:40] <blueking> thanx for help :)
[08:40] <blueking> sarnold:
[09:03] <blueking> hmm in /sys/devices/virtual/block/md0/removable     it's 0  flag  means not removable
[09:45] <jamespage> yolanda, some feedback on the heat charm - more units tests would be good; and I'd rather see use of the pwgen function from charmhelpers than using hexdump if that would work OK
[09:46] <yolanda> jamespage, ok, i'll take a look
[09:47] <jamespage> yolanda, you can probably ditch the upgrade_charm hook - that call was put into existing charms to deal with changing the default vhost for rabbitmq
[09:53] <yolanda> jamespage, about the heat logo, the one that we have in launchpad isn't the official one?
[09:53] <jamespage> yolanda, don't worry about that for now - I'll poke someone in the design team for some nice openstack ones
[09:53] <jamespage> they did the ones for the other openstack charms
[09:54] <yolanda> ok
[10:56] <yolanda> jamespage, i have a conflict with ceilometer. stevedore version requirements is >=0.12, but we have only 0.10-2, shoud we update stevedore version first?
[10:57] <jamespage> yolanda, sounds like a good idea
[11:00] <jamespage> yolanda, I just pinged zigo (debian maintainer)  - lets see if he has immediate plan - if not we delta it and give him a patch if need be :-)
[11:01] <yolanda> ok
[11:18] <blueking> a question about local net, have setup one pc as router  ubuntu server, with dhcp server  shorewall .. and two asus routers that I have some options to set these two...  1:  make its own subnet for wifi  one wifi router and the second router set in AP mode   or 2: set both wifi router in AP mode and have same subnet as local net ?
[11:19] <yolanda> jamespage, created this MP to prevent at least the FTBFS: https://code.launchpad.net/~yolanda.robla/ceilometer/icehouse_ftbfs/+merge/197692
[11:20] <yolanda> it will be pending the stevedore upgrade to 0.12, because package right now doesn't work
[11:36] <jamespage> yolanda, OK _ I checked with zigo - he has other challenges as he needs to test with havana as well
[11:36] <jamespage> so I uploaded to trusty
[11:37] <yolanda> jamespage, you uploaded 0.12 version?
[11:37] <jamespage> 0.13 actually
[11:40] <yolanda> cool, so i'll try to update my MP for ceilometer
[12:11] <jamespage> yolanda, should land in a bit
[12:11] <jamespage> backport-o-matic will detect it and shove it into the lab the the icehouse staging PPA
[12:11] <jamespage> Daviey, named for you ^^
[12:34] <jamespage> yolanda, some feedback in your ceilometer MP
[12:34] <yolanda> ok
[12:39] <R_L_N> hey guys quick question
[12:40] <R_L_N> im trying to install ubuntu server without the network configured
[12:40] <R_L_N> this should be fine except for when i get to the step for choosing a mirror
[12:40] <R_L_N> i cant get past it because it fails to find the mirror
[12:40] <R_L_N> is there a secret way past this? i cant see one
[13:13] <jamespage> zul, most of our backport failures either seem to be python3 related or due to BD's on dh-python now
[13:25] <jamespage> zul, dh-python from wheezy backports looks like it might be an option
[13:26] <jamespage> at least the delta is probably good for the backport we need to have
[13:26]  * jamespage looks deeper
[13:32] <yolanda> jamespage, pushed the fixes for ceilometer, but it won't work until new stevedore is pushed
[13:33] <zul> jamespage:  ack
[13:34] <smoser> roaksoax, were you planning (or could you) upload a maas to trusty that is >= 1.4+bzr1693+dfsg-0ubuntu2.2  ?
[13:35] <smoser> currently trusty < saucy-proposed
[13:35] <smoser> which is a "violation" in some sense
[13:46] <smoser> jamespage,  could you review https://code.launchpad.net/~smoser/ubuntu-reports/cloud-tools-next/+merge/197604
[13:47] <jamespage> smoser, sorry - I suck
[13:47] <smoser> its admittedly not the most beautiful patch in the world, but it works
[13:47] <smoser> and it gets me charts that actually have meaning versus the confusing bunch of RED at http://status.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/cloud-tools_versions.html
[13:47] <smoser> OMG RED!
[13:50] <jamespage> smoser, looking now
[13:51] <roaksoax> smoser i was working on the package split before releasibg a new version since i wanted it out there sooner rather than later
[13:58] <smoser> roaksoax, just upload 2.2
[13:58] <smoser> early and often rather than perfect.
[13:58] <smoser> rbasak, https://bugs.launchpad.net/maas/+bug/1257082
[13:58] <smoser> i'm confused.
[13:59] <smoser> NTPDATE_USE_NTP_CONF=yes is "correct", no?
[13:59] <smoser> it looks to me like:
[13:59] <rbasak> smoser: I'm not sure that makes sense. AFAICS, if ntpdate intends to pick up the DHCP NTP server, surely it should do it by default?
[13:59] <smoser> i know i'm missing something.
[14:00] <smoser> but to me, ifup of dhcp causes /etc/dhcp/dhclient-exit-hooks.d/ntpdate
[14:00] <smoser> to run
[14:00] <smoser> which writes
[14:00] <smoser> /var/lib/ntpdate/default.dhcp
[14:00] <roaksoax> smoser: do you have anything to upload that doesn't involve a new upstream release?
[14:00] <smoser> and then after that is written
[14:00] <smoser> /etc/network/if-up.d/ntpdate would run, which reads that file if present.
[14:00] <smoser> roaksoax, why can't you just upload the same thing to trusty that is in saucy ?
[14:01] <rbasak> smoser: except it doesn't, which is either intentional or a bug. Take a look at the logic in /usr/sbin/ntpdate-debian.
[14:01] <smoser> rbasak, i'm missing something
[14:01] <roaksoax> smoser: ah! i see.. i guess noone every copied to the package to trusty
[14:01] <smoser> http://paste.ubuntu.com/6519871/
[14:02] <rbasak> smoser: if NTPDATE_USE_NTP_CONF=yes (the default), then /var/lib/ntpdate/default.dhcp is never examined.
[14:02] <smoser> rbasak, thats /usr/sbin/ntpdate-debian
[14:02] <smoser> oh.
[14:02] <smoser> i see.
[14:02] <smoser> i just assumed that the list of files thre in the 'yes' case
[14:03] <smoser> included /var/lib/ntpdate/default.dhcp
[14:03] <rbasak> Seems to me that NTPDATE_USE_NTP_CONF should be treated as if it says no if /etc/ntp.conf doesn't actually exist.
[14:03] <smoser> and never even looked at the other case.
[14:03] <rbasak> I think a bug in Debian is warranted here, to at least figure out the intention.
[14:03] <smoser> yeah.
[14:03] <rbasak> I'll file it, shall I?
[14:04] <smoser> yeah. and link to yours.
[14:05] <smoser> thanks rbasak. i just assumed line 10 there was searchign through ntpdate/default.dhcp
[14:05] <zul> hallyn:  libvirt-pythong should be fixed now
[14:11] <zul> jdstrand:  ping
[14:18] <jdstrand> zul: hey
[14:20] <zul> jdstrand:  can you get someone to look at the MIR for python-misaka please?
[14:30] <jamespage> zul, OK - have a dh-python that works for icehouse/precise
[14:30] <zul> jamespage:  sweet
[14:30] <zul> im just fighting python-librabbitmq
[14:30] <jamespage> zul, can you check http://paste.ubuntu.com/6520014/ and +1
[14:31] <jamespage> I'll then push it to all the right places manullay
[14:31] <zul> +1
[14:31] <zul> maybe we should get that delta in dh-python as well
[14:32] <zul> jamespage:  actually nevermind about what i was saying in the delta
[14:58] <jamespage> smoser, OK - I did a local test and then deployed it to the server
[14:58] <smoser> so will the server magically add the 'cloud-tools-next' ?
[15:14] <smoser> jamespage, ^
[15:15] <jamespage> smoser, no i need to enable that
[15:16] <jamespage> smoser, which I have now down /44 past the hour
[15:17] <smoser> i have no idea what that meant
[15:18] <jamespage> smoser, it runs at 44 minutes past the hour
[15:18] <jamespage> the reports are staggered
[15:18] <smoser> ah.
[15:18] <smoser> k.
[15:20] <Daviey> jamespage: hah, backport-o-matic :)
[15:22] <jcastro> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-webscale
[15:22] <jcastro> does anyone know if any of this is targetted for T?
[15:23] <jamespage> jcastro, nginx was mentioned - rbasak was looking at that I think
[15:24] <jamespage> varnish - nid
[15:47] <zul> jamespage:  crap glance milestone.proposed is using olso.messaging
[15:47] <jamespage> zul, is it or is that on master?
[15:48] <zul> jamespage:  milestone-proposed
[15:48] <zul> jamespage:  aka icehouse-1
[15:48] <zul> grumble grumble
[15:49] <jamespage> zul, better get it uploaded then
[15:49] <jamespage> :-)
[15:49] <zul> jamespage:  i have it uploaded its just old
[15:49] <jamespage> Daviey, b-o-m for short
[15:49] <zul> just need to do an MIR
[15:49] <Daviey> jamespage: b-o-o-m would be better :)
[15:49] <jamespage> zul, that should be a nod through right?
[15:49] <zul> jamespage:  b-o-o-m Daviey jinx
[15:49] <zul> jamespage:  yeah
[15:49] <zul> im on it
[15:50] <jamespage> zul, good man
[15:51] <jamespage> zul, OK - we have quite a few blocked on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:52] <smoser> jamespage, hoorah!
[15:52] <smoser> http://status.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/cloud-tools_versions.html
[15:52] <smoser> http://status.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/cloud-tools-next_versions.html
[15:52] <smoser> still red, but meaningful red
[15:52] <zul> jamespage:  yeah im working my way through im kind of ignoring python-nose though since its not a openstack dependency anymore
[15:53] <jamespage> ok
[15:53] <jamespage> smoser, we should get b-o-m running for cloud-tools and cloud-tools next
[15:53] <zul> jamespage:  kombu is mostly done, misaka is blocked on a security review
[15:56] <zul> jamespage:  we need to package oslo.rootwrap after icehouse-1 is out as well
[16:15] <zul> jamespage:  ok oslo.mesaging a11 (needed by glance) and MIR filed
[16:33] <zul> jamespage/roaksoax: https://code.launchpad.net/~zulcss/glance/oslo-messaging/+merge/197752
[16:56] <zul> jamespage:  oslo.messaging MIR approved, and boomed it
[16:58] <hallyn> zul: it's a problem that 'sudo apt-get dist-upgrade' doesn't cause libvirt-python to be installed automatically.  so you keep your python-libvirt 1.1.4 by default until you fix it
[16:59] <zul> hallyn:  argh...
[16:59] <zul> ill fix that up
[17:00] <hallyn> ok - new tests running (first failed bc i didnt notice the break :)
[17:16] <jamespage> zul, +1
[17:24] <zul> jamespage:  thanks
[17:49] <jamespage> yolanda, ceilometer build fix looks OK _ add one missing BD - down to 35 test failures now!
[17:49] <jamespage> pushed
[17:56] <smoser> jamespage, any idea how big a mess this is:
[17:56] <smoser> https://launchpad.net/~ubuntu-cloud-archive/+archive/cloud-tools-next/+build/5300997
[17:57] <smoser> dh-systemd dependency
[17:57] <jamespage> its not that bad tbh
[17:57] <jamespage> at least I don;t think so
[17:57] <smoser> ok. i'll give a try
[17:57] <jamespage> I just had to backport dh-python for 12.04 for the icehouse archive
[17:58] <smoser> jamespage, did it work ?
[17:58] <smoser> is it no change?
[17:58] <jamespage> smoser, yes - but I had to delta it quite a bit
[17:58] <smoser> hm..
[17:59] <jamespage> it was already backported for wheezy which was pretty close
[17:59] <smoser> well i guess my only real option ins to take your work then.
[17:59] <jamespage> smoser, I'd try it
[18:01] <smoser> jamespage, so i guess i'll just take your cloud0 and make it ctools0 ?
[18:01] <jamespage> smoser, do you need dh-python?
[18:01] <smoser> bah
[18:02] <smoser> for some reason i was thinking dh-systemd was dh-python
[18:02] <smoser> yeah, i'll look at it
[18:02] <jamespage> smoser, is that for mongodb per chance?
[18:02] <smoser> yes
[18:02] <jamespage> smoser, boost will be an issue as well
[18:02] <jamespage> precise has a to-old version
[18:03] <jamespage> I'd not got to looking at that just yet
[18:04] <adam_g> jamespage, so theres a bit of hacking we need to do around the neutron config that gets passed thru nova-compute -> nova-compute, currently handled by nova-compute's CloudComputeContext
[18:04] <adam_g> jamespage, moving that to the charmhelpers context
[18:04] <jamespage> ok
[18:06] <smoser> utlemming, can we get trusty builds of maas-ephemeral images turned on ?
[18:08] <adam_g> jamespage, eek actually this is quite a bit of refactoring
[19:32] <jamespage> zul, gah - that fix for pbr was not quite enough
[19:34] <zul> jamespage:  :(
[19:34] <zul> jamespage:  simplejson fixed
[19:34] <jamespage> zul, I think I have to drop the u at the start of the string as well
[19:35] <igalic> Hello happy people.
[19:35] <igalic> I'm hitting https://bugs.launchpad.net/ubuntu/+source/preseed/+bug/705113 and wondering if anyone knows how to fix it
[19:38] <xnox> igalic: you can wipe the drive clean, or do lvm superblock removal.
[19:38] <xnox> igalic: if you are doing automated pressed you can wipe it from early command
[19:39] <xnox> igalic: i have tried to fix this bug for real, but i'm not sure at which point it happens now again / how to reproduce it. Such that I can catch were else it's borked.
[19:40] <igalic> xnox: I did lvremove only, then ran the setup again. How would I wipe it clean in early command, though?
[19:40] <igalic> I'd like to fix for future installations too.
[19:41] <xnox> igalic: lvremove does not remove the "volume group".
[19:41] <xnox> igalic: you need to remove the volume group.
[19:41] <xnox> igalic: vgremove.
[19:44] <igalic> xnox: no. I'm doing an lvremove on the HOST. This is a VM setup. I'm giving the VM a disk that's essentially an lvm partition. But even if I lvremove that partition, when I create a new host on top of it, it'll end in conflict.
[19:44] <xnox> igalic: from the point of view of booted install, what does it see?
[19:44] <xnox> igalic: e.g. can you go into advanced partitioning?
[19:45] <xnox> does it see a blank "disk", which happens to have "ghosts" ?
[19:45] <igalic> xnox: it sees the same disk that the previous installation created. Which is bad, because I'm running in a preseed, I don't *want* to go into any partioning.
[19:46] <xnox> (lvremove doesn't zero out the disk, so you do have left over metadata left, the installer goes to create partition table & partitions and if they align identical.... which they will for auto-preseed.... lvm metadata is re-detected and BOOM lvm2 explodes)
[19:46] <xnox> igalic: before provisioning a VM, do provide it with clean disks.
[19:47] <igalic> xnox: and I can't preseed that out?
[19:47] <igalic> lvm/confirm_nooverwrite boolean false  or somesuch?
[19:48] <xnox> installer scans the disk and sees no partitioning table no nothing, later when it goes to partition it things appear out of the blue and it doesn't know how to deal with it.
[19:49] <igalic> ah.
[19:49] <igalic> I see.
[19:49] <xnox> igalic: you can preseed partman/early_command which does dd if=/dev/zero of=$your-target count=30M or somesuch.
[19:49] <xnox> igalic: as far as I understand it's a bug in "lvcreate on the host" where "lvcreate" will give you "a random disk with random data on it"
[19:51] <igalic> "random"
[19:51] <xnox> igalic: well, last unused extend, which would match last removal in best case scenario
[19:51] <xnox> igalic: can you try  on the host: lvremove, lvcreate --zero y, provision VM with that created LV and check what happens?
[19:52] <igalic> xnox: no can-do. lvcreate is done by koan. I will however create a bug report for that.
[19:53] <xnox> actually that will not zero out the whole volume, only beginning of it.
[19:55] <igalic> *nod*
[19:56] <igalic> xnox: count=30M == 30 million?
[19:56] <igalic> huh?
[20:08] <xnox> ... 30 MB....
[20:08] <xnox> do bs=1MB count=30 if you wish.
[20:09] <igalic> xnox: one 1m was enough.
[20:10] <igalic> xnox: https://github.com/cobbler/cobbler/issues/664
[20:14] <xnox> cobbler *shrug*
[20:46] <igalic> Can someone exlain to me how to set a default gateway for IPv6? http://dpaste.com/1492966/
[20:50] <jkyle> I accidentally uploaded a package to a ppa that doesn't exist so it was rejected. But when I trie dto dput again to the correct ppa, it says it's already been uploaded
[20:50] <jkyle> is there a way around that
[21:09] <henkjan> pff, bug #879324
[21:09] <henkjan> nasty one :(
[22:25] <hallyn> zul: that's a negatory on the libvirt tests:  http://paste.ubuntu.com/6522197/
[22:26] <hallyn> i'll take a look tomorrow if you don't find it first, but not tonight
[22:26] <zul> hallyn:  son of a bitch
[22:27] <hallyn> s/:/ you/
[22:28]  * hallyn out, bbl
[22:28] <Pryath> Do any of you happen to have experience setting up an Amazon EC2 webserver with ubuntu server 13 64bit?
[22:31] <sarnold> I wouldn't be surprised if I've done that a few times.. are you having trouble?
[22:32] <Pryath> that is an interesting question, would you mind if I query with you to avoid spamming the channel?
[22:32] <sarnold> channel would be best, other people can learn or correct me if I'm wrong :)
[22:35] <Pryath> I've spent many hours trying to configure this thing. After fixing a few obscure errors and problems which should probably have never occured, I'm now having trouble logging in to phpmyadmin. Not only that, but the thing is randomly giving me two different error codes w/ the same message for the same problem ( #2003 & #1130) "Cannot log in to the MySQL server". I'm sure I'm missing something like s
[22:35] <Pryath> etting a default user/pass, but I already did that when I installed everything. I even reinstalled phpmyadmin to reset the passwords
[22:37] <Pryath> to say the least I'm so burnt out from fixing all the other problems & I've spent 30 minutes trying to fix this one. I don't know who to ask or where; the problems have been so numerous.
[22:37] <sarnold> yikes, mysql and phpmyadmin both have iffy security histories; please make sure the configuration of both tools only allows connections from hosts you expect, you have host-based firewalling to only allow connections from hosts you expect, and please double-check your AWS security groups to make sure _those_ only allow connections from hosts you expect.
[22:38] <Pryath> well my security group disallows public connections
[22:38] <sarnold> good good
[22:38] <Pryath> only my ip can ssh in
[22:38] <Pryath> or use http/https
[22:38] <sarnold> Pryath: are both mysqld and phpmyadmin running on the same host? is mysql configured to allow connections from localhost if so?
[22:39] <Pryath> bind-ip was set to 127.0.0.1, I know that because I was trying another tweak
[22:39] <Pryath> not sure if that's what you mean?
[22:39] <Pryath> and I believe they are both on the same host
[22:41] <sarnold> cool. mysql will have a specific username and password used for connecting to it, I can't recall if it is set in my.cnf or set in a database table once you've connected.. make sure it matches your phpmyadmin credentials.
[22:42] <Pryath> I'm normally a windows user. I've used ubuntu very sparingly so it's been hard to adapt to this
[22:42] <Pryath> I'll see if I can figure out if that's the case
[22:44] <Pryath> I looked through my.cnf and I don't see a username or password entry
[22:46] <sarnold> Pryath: hey, the serverguide has a nice little command for changing the mysqld root password: sudo dpkg-reconfigure mysql-server-5.5
[22:47] <sarnold> Pryath: https://help.ubuntu.com/12.04/serverguide/mysql.html
[22:47] <Pryath> I was actually on that page already
[22:47] <Pryath> it's one of my 20 tabs open
[22:47] <Pryath> I believe I've already done that
[22:47] <Pryath> I'll do it again just to see
[22:50] <Pryath> should my mysql username just be root?
[22:52] <sarnold> for the user account that will manage the other mysql user accounts, table privileges, etc., yes
[22:53] <Pryath> "granting access to database phpmyadmin for root@localhost: success.
[22:53] <Pryath> verifying access for root@localhost: failed.
[22:53] <Pryath> "
[22:53] <sarnold> Pryath: is there anything informative in the logs?
[22:54] <Pryath> it's quite amusing actually, it says "error encountered creating user:" but it's just a blank line after that
[22:55] <Pryath> oh by the way this is me doing sudo "dpkg-reconfigure -plow phpmyadmin"
[22:55] <Pryath> I already did mysql, there were no errors for that
[22:56] <Pryath> well anyways, I've been at this for too long and need a break. Thank you for trying to help me sarnold
[22:58] <sarnold> Pryath: good luck, keep at it, and don't forget to read through the log files... they're your friends. :) good luck!
[23:22] <sponzor> hi. i seted up vsftpd ssl on ubuntu 12.04 server. i added users and tested. everything works fine.. now im trying to access files that i uploaded over ftp to server via browser. so when i go ftpserver:990 and then type in ftp:ftppass and see files.. can someone point me to the right direction for google on that?
[23:24] <sarnold> sponzor: what's wrong? it sounds like it works fine?
[23:25] <sponzor> yeah when i go to ip:990 it askes for user:pass and it wont accept it
[23:29] <sarnold> are there any error messages in the vsftpd log files that might indicate why it rejected the username and password?
[23:30] <sponzor> yeah Thu Dec  5 00:29:57 2013 [pid 1] [anonymous] FAIL LOGIN: Client "10.0.0.11"
[23:33] <sponzor> but i get this error even  if i dont enter password
[23:33] <sponzor> and i disabled anonymous in .conf
[23:34] <sarnold> sponzor: perhaps the browser tries anonymous and username@domain as password when trying to retrieve the directory listing in the first place?
[23:36] <sponzor> tryed username@domain its same
[23:37] <sarnold> sponzor: try ftp://username:password@ftpserver:990/   and see what that does?
[23:40] <sponzor> same error and askes for us:pass this is conf i double checked it and it looksfine http://pastebin.com/kDDFZdR2
[23:42] <sponzor> do i have to edit apache sites to make it work?
[23:43] <sarnold> sponzor: what is listening on port 990? apache or vsftpd?
[23:43] <sponzor> vsftpd
[23:43] <sarnold> is that how you -want- to get to the files via web browsers?
[23:44] <sarnold> I've assumed this whole time that you wanted to use vsftpd as the server and configure it for both good ftp clients (like lftp) and bad clients (like web browsers :)
[23:45] <sponzor> ah no :D if someone needs to download i can gaeve him link to file and username:pass (chrome firefox..... much easer than ask him to install filezilla or something... half of ppl cant even connect with filezilla :/ and other half like me cant make server to work :D
[23:47] <sarnold> sponzor: that's not a surprise, ftp is a horrible protocol, half the firewalls in the world break ftp. hehe.
[23:48] <sarnold> sponzor: if you want folks to use web browsers, it would probably be best to also configure apache to have access to these files, and serve them up via http on a different port
[23:48] <sarnold> you could use http authentication if you wanted to restrict it by username/password, but that would be a separate apache-owned username/password database in the easiest cases
[23:50] <sponzor> hmm thats even better i can make different users with no rights to use ftp, but only to download from web. great advice
[23:53] <sarnold> sponzor: I've used mod_authn_file with good success for small numbers of users: http://httpd.apache.org/docs/2.2/howto/auth.html