[00:39] <DarylXian> I found Ubu's "whoopsie" daemon installed, and spewing DNS queries, on a bunch of our Ubu servers.  *I* certainly never gave it, or apport, permission ... but there you have it.  I've rm'd the package from all the boxes -- QUESTION:
[00:39] <DarylXian> How do you permanenetly lock/prevent the install of package?
[00:50] <holstein> DarylXian: nothing additionally should be installed without sudo permission
[00:51] <DarylXian> holstein: It was apparently installed, and enabled, without my permission in the 1st place.  I'd rather not trust the "should", and lock out 'whoopsie' from ever being (re)installed.
[00:52] <DarylXian> afaict, you can lock UPGRADES.  haven't figured out how to lock out INSTALLS.
[00:52] <holstein> DarylXian: if the packages come with the OS, then they will have already been installed
[00:52] <sarnold> it is installed by default on every system.
[00:52] <holstein> DarylXian: i dont select "auto upagrades" at install
[00:52] <holstein> DarylXian: you should be able to remove anything you please,a nd nothing will be added or changed without your doing so
[00:53] <sarnold> perhaps you want to set up a debian installer preseed file that knows to uninstall it so your own installs won't hve it
[00:53] <DarylXian> sarnold: Right.  ANd apparently enabled.  Which is what's got me riled.  But, ignore me/that.  I simply don't trust this to not happen again.
[00:53] <DarylXian> Is there no locking mechanism -- like opensuse's zypper locks -- to prevent installs?
[00:53] <sarnold> or just add 'apt-get purge whoopsie' or whatever to an after-install script you run on systems?
[00:54] <sarnold> DarylXian: you can always make a fake whoopsie package to install.. kinda blunt as an instrument, but there you go
[00:54] <holstein> DarylXian: things dont get installed without your permission.. nothing was installed.. it comes withthe pacakges you are mentioning
[00:54] <DarylXian> holstein: It's been ENABLED without my express permisson.  That's at best -- shoddy.
[00:55] <DarylXian> sarnold: Not elegant, but a workaround.  THanks.  I can stuff this into Puppet somehow ...
[00:56] <holstein> DarylXian: enabled is not "installed after installation of the OS in the background without permission"
[00:56] <holstein> DarylXian: you should have no trouble removing anything you please, and it wont "automatically" do anything
[00:57] <DarylXian> It 'automatically' was enabled. ~10 million DNS queries later ... I'm simply interested in preventing it from doing so again.
[01:07] <jrwren_> its a good question, you could look into APT pinning?
[01:11] <jrwren_> Pin-Priority: -1  # should prevent it from being ever installed
[01:11] <sarnold> ooh
[01:11] <sarnold> that's easier than what I mentioned to him, the equivs package
[01:14] <jrwren_>         Package: perl
[01:14] <jrwren_>            Pin: version 5.10*
[01:14] <jrwren_> sorry.
[01:14] <jrwren_> clipboard fail
[01:14] <jrwren_> echo -e "Package: whoopsie\nPin-Priority: -1" | sudo tee /etc/apt/preferences.d/whoopsie
[01:14] <jrwren_> on all your servers should do it.
[01:15] <jrwren_> or in a shared cloud-init
[04:01] <MavKen> does someone know of a good site that shows best practices for directory permissions?  I have /var/www/client1/public_html/ for each of my clients... lots of permission issues with joomla
[04:02] <patdk-lap> not specific enough
[04:02] <jkitchen> MavKen: welcome to the wonderful world of "trying to make mod_php secure"
[04:02] <patdk-lap> the question will be, how are you running php? what user?
[04:02] <patdk-lap> there are really just 3 options
[04:02] <jkitchen> solution: don't. use php fpm or cgi or such
[04:03] <MavKen> i added all users to www-data
[04:03] <patdk-lap> run it as a single user, then any user can screw with other users
[04:03] <MavKen> then made www-data owner of each
[04:03] <patdk-lap> run it as the user, then user can screw with themselfs, and anything outside their public_html folder
[04:03] <patdk-lap> or make a new user for each user that the php runs as for that user
[04:04] <patdk-lap> ya, your going have lots of fun there, all you have to do is see what joomla says is required though
[04:05] <MavKen> I set permissions at 755 but no good... only 777 worked
[04:05] <jkitchen> MavKen: whatever you do, do NOT 777
[04:05] <jkitchen> grr
[04:05] <MavKen> yeah
[04:05] <patdk-lap> that is not what I said
[04:05] <patdk-lap> I said set them up as joomla tells you to
[04:05] <jkitchen> NEVER 777.
[04:05] <jkitchen> ever.
[04:05] <patdk-lap> it will tell you what folder needs what permissions
[04:05] <MavKen> I don't plan on keeping 777
[04:06] <jkitchen> MavKen: don't ever even do it to start
[04:06] <jkitchen> 777 is for /tmp and that's it.
[04:06] <jkitchen> and ever that is 1777
[04:07] <MavKen> alright
[04:07] <MavKen> it says to use 755 for all directories
[04:07] <MavKen> but wasnt sure if i should make client1 the owner or www-data
[04:08] <jkitchen> MavKen: you need to look into php fpm
[04:08] <jkitchen> mod_php should not be used for any multi-tenancy
[04:09] <patdk-lap> mod_php should never be used ever :)
[04:09] <jkitchen> I disagree
[04:09] <patdk-lap> it's a memory and performance hog
[04:09] <jkitchen> oh?
[04:09] <jkitchen> weird
[04:09] <patdk-lap> why weird?
[04:09] <jkitchen> maybe fpm is better now, then
[04:09] <jkitchen> I always assumed mod_php was the fastest because the interpreter was always there
[04:09] <patdk-lap> mod_php never beat php fcgi
[04:09] <jkitchen> ahh, I don't think I ever ran it fcgi
[04:09] <patdk-lap> and requires apache prefork, and then you have lots of wasted memory
[04:10] <patdk-lap> php_fpm runs as fastcgi, but even before fpm :)
[04:10] <patdk-lap> I was doing something like 97rps with mod_php and 114 with fcgi
[04:10] <jkitchen> crazy
[04:10] <patdk-lap> but really it was about not wasting all that memory on php to fork apache for html files
[04:10] <jkitchen> we just ran it as cgi. worked ok
[04:10] <patdk-lap> and pictures
[04:11] <MavKen> i keep wondering if i should try something other than php
[04:11] <jkitchen> yes
[04:11] <jkitchen> you should
[04:11] <jkitchen> php should not be used
[04:11] <patdk-lap> you mean, try a language that has a better reputation of developers not making stupid security mistakes? :)
[04:12] <jkitchen> oh set php's security issues aside and you still have an abomination.
[04:12] <patdk-lap> between joomla, wordpress, ...., endless issues
[04:12] <jkitchen> I admit it's getting better but it still carries way too much baggage
[04:12] <jkitchen> oh, I'm only talking core
[04:12] <patdk-lap> I'm not even talking php itself
[04:12] <jkitchen> people write horrible software in all languages
[04:13] <patdk-lap> ya, just the liberty php gives, seems to attract them
[04:13] <jkitchen> I mean sendmail was written in C ...
[04:13] <MavKen> my only experience is with php... what else should I look at?
[04:13] <patdk-lap> I will say, that is why I do code in php, cause it's quick and dirty
[04:13] <jkitchen> MavKen: ruby and python are kinda the new hotness nowadays
[04:13] <MavKen> yeah, its easy to throw something together using php
[04:13] <patdk-lap> though, I have spent a long time *fixing* php issues, and also doing thing right
[04:14] <jkitchen> they have excellent web frameworks (rails, django, to name a few)
[04:14] <jkitchen> then things like node.js are becoming popular
[04:15] <MavKen> never would have imagined .js being used that way
[04:15] <jkitchen> node is pretty rad.
[04:16] <MavKen> thinking about trying www.django-cms.org
[04:18] <jkitchen> I don't know anything about it other than it has automatically created admin interfaces and is written in python and was extracted out of the CMS of a newspaper in kansas
[04:19] <jkitchen> I've known ABOUT it for like .. 8 years now? but never used it.
[11:45] <jamespage> apw, the 3.13 changes for openvswitch look a bit terrifying and are definately beyond my capability to fixup in openvswitch
[11:46] <jamespage> I'm going to punt this upstream and disable the DKMS package for the time being
[11:50] <apw> jamespage, do we lose anything significant by doing so, you mentioned a feature
[11:50] <jamespage> apw, just support for LISP based tunnelling which is pretty experimental
[11:55] <apw> jamespage, so not the end if the world i hope then
[11:55] <jamespage> apw, not at all - the 'supported' tunnelling mechanisms for openstack are GRE and VXLAN
[11:56] <jamespage> both are support directly by the in-tree kernel module now
[11:57] <apw> ok good
[12:14] <jamespage> rbasak_, do you have the report generator that looks at server related package merges?
[12:14] <rbasak> jamespage: http://bazaar.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk/view/head:/server/merges.py
[12:15] <jamespage> rbasak, ah - http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html
[12:15] <jamespage> got it
[12:15] <rbasak> Oh right. You wanted the report, not the generator. Sorry :)
[12:15] <rbasak> One day, I want to get round to being able to prioritise the report.
[12:22] <jamespage> rbasak, np - that report gives me enough
[12:22] <jamespage> looks like we have some merging todo still...
[12:22] <rbasak> I'm still working on apache2. php5 and mysql are on my list.
[14:36] <rbasak> hallyn or stgraber: is it expected that "lxc-ls" no longer works as a normal user, now that /var/lib/lxc permissions are locked down?
[14:39] <hallyn> rbasak: yes, sadly.
[14:39] <hallyn> rbasak: (you can list your own unprivileged containers, if you're on trusty)
[14:43] <stgraber> rbasak: as I just said in the other channel, note that lxc-ls in the next LXC milestone won't try to list system containers anyway
[14:43] <stgraber> rbasak: current upstream lxc-ls when run as non-root will list unprivileged containers present in ~/.local/share/lxc/
[14:44] <stgraber> well, unless you force it to look somewhere else with "lxc-ls -P /var/lib/lxc" of course
[14:48] <rbasak> stgraber: that's interesting, thanks. Looking forward to your "Unprivileged containers" post :)
[14:49] <stgraber> rbasak: just waiting for slangasek to upload my PAM fix so that sshd works in them, then I'll publish it :)
[14:49] <stgraber> (well, maybe by that time we'll also have a 3.13 kernel in the archive which would also make unpriv containers slightly nicer)
[14:50] <rbasak> Locking down /var/lib/lxc broke adt-virt-lxc, btw, which assumes that it can see inside the guest rootfs as an unprivileged user in order to detect when a container has actually booted (by looking for cloud-init's boot-finished flag).
[14:50] <rbasak> I can probably fix that with sudo, but annoyingly that means that I can't just call os.path.exists, etc.
[14:51] <rbasak> An extension to lxc-wait to detect container boot-finished status would be awesome ;-)
[14:56] <makara> hi. i've added moin.conf to /etc/init/ but "start moin" give "unknown job" ?
[14:57] <makara> have to go
[14:57] <makara> damn
[15:03] <jamespage> rbasak, are your mongodb cross arch changes good for cherry picking? I see they are pending merge upstream now
[15:06] <vipconsult> anyone used the  ML350 G5 or ML150 G6 , I am considering between both for a small office. main cafeterias: SAS RAD 10, ilo, low noise, low size
[15:19] <rbasak> jamespage: I was waiting for the patches to actually be merged upstream in case they were changed at all, but it looks like that's unlikely now, so if you need it then go ahead.
[15:20] <rbasak> jamespage: (as we're synced with Debian I was going to send Debian cherry-picks and let Ubuntu sync it)
[15:21] <jamespage> rbasak, find - I'm hacking around on the juju-mongodb package at the moment - I've disabled scripting altogether so it might just build on arm64 with your patches :-)
[15:21] <rbasak> jamespage: also, I don't think you need the third commit. Might as well leave amd64/i386 alone until upstream take it.
[15:34] <jamespage> zul, is savanna actually in 14.04 yet?
[15:42] <zul> jamespage:  not yet i have to upload it
[17:29] <vipconsult> how do you go about protecting the data in case of theft ?
[17:31] <holstein> vipconsult: the machine physically getting taken?
[17:31] <vipconsult> yes
[17:32] <holstein> https://help.ubuntu.com/community/FullDiskEncryptionHowto ..but, if someone can touch the machine, i dont trust anything
[17:32] <Pici> Doesn't that require you to enter a password at boot?
[17:33] <holstein> i think it would make running a headless system more challenging.. if not impossible from a cold reboot without intervention
[17:38] <semiosis> jamespage: ping
[17:41] <jamespage> semiosis, hello
[17:42] <semiosis> hi, marcoceppi suggested i get in touch with you about the glusterfs package in trusty, i have some updates
[17:43] <semiosis> basically, due to upstart, glusterfs is merged rather than synced.  there's a new release of glusterfs, 3.4.2, and also improved upstart jobs, which I'd like to get merged into trusty
[17:43] <semiosis> thoughts?  advice?
[17:44] <semiosis> i take care of upstream ubuntu & debian packaging for the glusterfs project btw
[19:09] <keithzg> Hmphhh, I seem to be running into https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/976632 but am a bit scared to get too invasive chaning settings that otherwise work....sigh.
[19:13] <keithzg> Wellllll, I gave in and set Domain = localhost on both the client and server /etc/idmapd.conf, which seems to have fixed it. Time for the fun part of eventually discovering unintended consequences and ramifications ;)
[19:22] <addisonj> hey, trying to make sense of something, in 12.04.3, the default kernel is 3.8, but under the cloud images, it seems like it defaults to 3.2 instead... is there a reason for that or a place to get the "official" ami with 3.8?
[19:26] <sarnold> addisonj: I don't know the exact answer you'r looking for but I hope this is helpful :) http://cloud-images.ubuntu.com/releases/12.04.2/release/
[19:26] <sarnold> hunh, wonder why the url says 12.04.2 but the content all says 12.04.3.
[19:27] <addisonj> sarnold: yeah, I was looking at that, if you scroll down the list of content and look at kernel info, it shows 3.2...
[19:29] <sarnold> addisonj: how odd
[19:56] <rbasak> jamespage: https://github.com/mongodb/mongo/commit/df3d84e and https://github.com/mongodb/mongo/commit/c9edb7f just landed upstream.
[19:56] <rbasak> I'll file a Debian bug tomorrow.
[19:58] <jvargas> A server was hacked and it runs a fake program named /usr/sbin/nginx, but that file doesn't really exists
[19:58] <jvargas> Inspecting /proc/PID_NUMBER I found that the excutable is a perl script
[19:58] <rostam> HI using ubuntu 12.04 LTS update 3, Missing files/directories: I have observed on afew of my systems, sometimes after reboot some of files or directories are missing,any idea why? thx
[19:59] <jvargas> And its current executing directory is /tmp
[19:59] <jvargas> How can I find the original program being run as "/usr/sbin/nginx" if it doesnt exists?
[20:02] <sarnold> jvargas: check /proc/pid/fd/
[20:03] <sarnold> jvargas: you may be able to vi some of those; I can't recall if it still works if the file's been deleted, but I think it may..
[20:03] <jvargas> sarnold: will check. brb
[20:04] <sarnold> rostam: check your various /lost+found directories ? if the system lost power before umounting, perhaps the files were disconnected..
[20:09] <dcosnet> `which nginx`
[20:09] <dcosnet> or `lsof | grep nginx`
[20:09] <dcosnet> to see what it is talking to
[20:10] <jvargas> sarnold: just did it, but no files open, just sockets and pipes. I found that its /proc/PID/fd/51 points to /proc/OTHER_PID/auxv
[20:10] <jvargas> But that OTHER_PID doesn't exist anymore
[20:11] <sarnold> jvargas: crazy
[20:14] <semiosis> jvargas: possible remote code execution, program code may have arrived over the network & only reside in memory.
[20:16] <dcosnet> ouch
[20:20] <sarnold> yeah perl does make it easy to deliver executable code in a varieyt of ways.. stdin, -e, load a file and execute, etc..
[20:20] <jvargas> semiosis: maybe. since it is a perl program, is it possible to inspect the source code at execution time?
[20:21] <dcosnet> check /tmp and /var/tmp just incase
[20:21] <dcosnet> also any possible memory filesystems like gnome has
[20:22] <jvargas> I just did, nothing there.
[20:22] <semiosis> is this a web server?  runing php perhaps?  i've seen plenty of RFI exploits do stuff like this
[20:23] <semiosis> (remote file include)
[20:24] <jvargas> semiosis: yes, a web server running php. Actually, the process runs as one of the web users
[20:24] <kees> jvargas: you could gdb attach and have it generate a core dump (without actually killing the process)
[20:24] <semiosis> hehe, called it
[20:25] <kees> the command is "gcore", fwiw
[20:26] <jvargas> semiosis: yes. What I am looking for is for the source of the program to eliminate it completely.
[20:26] <sarnold> kees: oh! I didn't know that was an option. nice. /proc/self/mem isn't being friendly to e.g. strings -a  :) hehe
[20:26] <kees> sarnold: right, /proc/$pid/mem needs the reader to be ptrace attached
[20:26] <semiosis> jvargas: most likely you have a php file on the server which is vulnerable to an rfi attack, and someone (many actually) are scanning teh whole internet looking for such vulnerable systems
[20:26] <semiosis> these vulerabilities exist in lots of popular php apps
[20:27] <sarnold> kees: oh! cool. thanks. :)
[20:27] <semiosis> there's very likely no file on your server being executed
[20:27] <kees> in the generated core file, you may have a dump of the original source, if you're lucky
[20:27] <jvargas> semiosis: I know. I've removed some of these before, but this one is the most curious one ever.
[20:27] <sarnold> the /proc/pid/auxv is an odd touch, no doubt.
[20:28] <kees> fd/51 ? wow. I wonder what it was doing
[20:28] <kees> (like, that's a fair number of open files)
[20:29] <jvargas> kees: yes, I read that auxv file is "contains the contents of the  ELF  interpreter  information passed  to the process at exec time"
[20:30] <jvargas> So, why does a process would have an open fd pointing to the AUXV file of another process?
[20:30] <kees> jvargas: there's a lot of weird stuff in the auxv file. the most sensitive is the ELF start location (which can be an ASLR bypass) and the random number seeds for glibc protections (ssp, ptr_mangle)
[20:30] <jvargas> Copying the full binary image of its parent process?
[20:32] <semiosis> jvargas: you might want to look into running mod_security - http://www.modsecurity.org/
[20:32] <kees> jvargas: my arbitrary guess was that it was trying to attack that process by examining its ASLR offset. but that's just a total guess.
[20:32] <kees> jvargas: but getting a gcore via gdb will tell you the most at this point.
[20:32] <YamakasY_> Hi all
[20:32] <jvargas> kees: will run gdb now.
[20:32] <YamakasY_> can apt-mirror not use mirror://
[20:32] <YamakasY_>  ?
[20:32] <kees> gdb, attach $pid, gcore, quit
[20:32] <kees> well, quit if you want it to keep running. otherwise it'll stay paused while you have gdb open
[20:34] <xperia> hi. i am having problem with mailman on my ubuntu saucy server. installed and configured mailman with any problem but having trouble with permission and access of the new created mailing list. getting allways this error message here
[20:34] <xperia> AH00670: Options FollowSymLinks and SymLinksIfOwnerMatch are both off, so the RewriteRule directive is also forbidden due to its similar ability to circumvent directory restrictions : /usr/lib/cgi-bin/mailman/listinfo
[20:34] <xperia> have checked the apache conf and enabled Options +FollowSymlinks but it does not help. anybody who can suggest what need to be done?
[20:35] <jvargas> kees: got the core dump, now what can I do with that binary file?
[20:36] <kees> try "strings" on it, see if anything exciting appears :)
[20:36] <sarnold> on a first shot, try strings -a on it
[20:37] <jvargas> kees: I used vim and found strings like "/tmp/bad" and "/usr/sbin/nginx" too near each other.
[20:37] <kees> no perl code snippets, eh?
[20:38] <jvargas> yes, some code snippets.
[20:39] <jvargas> also found several URLs, joomla vulnerabilities info and search engine queries.
[20:40] <kees> nice! sounds like it might scanning for more vulnerabilities.
[20:40] <semiosis> it's most likely a botnet agent, able to propagate, spam, and ddos
[20:40] <semiosis> that's my guess
[20:40] <kees> jvargas: if you want, gzip and email the gcore to me, I can look too. kees@ubuntu.com
[20:41] <xperia> okay could solve the problem. was a apache config problem with the order of the directory rules.
[20:42] <semiosis> some of these botnet agenst propagate by searching google for paths that indicate possibly vulnerable hosts
[20:43] <semiosis> C&C is often handled over http, where the server address is generated based on a time index & some seed.  check what dns queries that host is generating
[20:43] <semiosis> jvargas: ^
[20:46] <jvargas> semiosis, kees: gimme a minute
[20:50] <jvargas> kees, semiosis: I used strings and checked some target URLs, for example this one: http://www.istanbuldenizotobusu.com/sodd.txt
[20:50] <semiosis> i'd recommend against opening that in a browser!
[20:50] <semiosis> curl is your friend
[20:50] <kees> it's a perl script
[20:51] <semiosis> indeed
[20:51] <jvargas> seems that code is retrieved remotely
[20:51] <semiosis> wow, using irc for C&C, thats old school
[20:51] <kees> Portuguese.
[20:52] <jvargas> $proc var is the process names it takes
[20:53] <kees> "BaDGuyS" is the admin control nick, fwiw (the base64 decode)
[20:53] <semiosis> a ddos agent
[20:54] <jvargas> curiously it also performs checks against speedtest.net for bandwidth performance
[20:55] <semiosis> neat
[20:57] <jvargas> so, it scans and also performs ddos
[20:58] <kees> yeah. you can probably find its outbound network connection in "netstat -anp" as root and find its pid
[20:59] <jvargas> It seems that it used a JCE vulenrability on Joomla websites: http://www.istanbuldenizotobusu.com/update.php
[20:59] <kees> cool, you found its entry point?
[21:01] <jvargas> i hope so. ill keep reading.
[21:03] <semiosis> jvargas: if you're feeling adventurous, you could set up a honeypot & point that exploit tool at it, then capture what it does... that would allow you to see the whole payload
[21:04] <kees> oh, hah. sodd == DDoS (backwards)
[21:04] <semiosis> honeypot could be as simple as a php script that writes the whole request, with headers & post data, to a file
[21:08] <kees> yeah, this thing in memory seems to be the attack-finder.
[21:08] <kees> openflashchart ? another vuln?
[21:16] <YamakasY_> wow a 12.04 mirror is huge
[21:29] <punapantteri> hi
[21:31] <punapantteri> I just installed the dovecot-postfix package
[21:31] <punapantteri> asd configured it as this said: https://help.ubuntu.com/10.04/serverguide/postfix.html
[21:32] <jvargas> semiosis, kees: problem solved now :-) thanks for ur help
[21:32] <punapantteri> but when I connect with netcat and test, it doesn't work as I suppose it should
[21:33] <punapantteri> I don't see the lines "250-AUTH LOGIN PLAIN" and "250-AUTH=LOGIN PLAIN" among others
[21:33] <semiosis> jvargas: yw. what did you do to prevent further attacks?
[21:35] <jamespage> semiosis, hey - sorry - i missed your response
[21:35] <jamespage> re glusterfs
[21:35] <jvargas> semiosis: updated jce extension on that website and for further protection disabled direct php execution that doesnt passes throgh joomla cms
[21:35] <semiosis> jvargas: cool
[21:35] <semiosis> jamespage: yeah no worries :)
[21:35] <xperia> hi does somebody has mailman running on his ubuntu server? i have some strange permission problems. get allways this error message when i try to confirm my subscription => AH00037: Symbolic link not allowed or link target not accessible: /var/lib/mailman/archives/public/
[21:35] <semiosis> jamespage: what do you think about what I was saying?
[21:36] <jamespage> just looking
[21:36] <semiosis> thx
[21:40] <semiosis> jamespage: fyi, my upstream packages (blessed as the official upstream packages for ubuntu) are here: https://launchpad.net/~semiosis/+archive/ubuntu-glusterfs-3.4/+packages
[21:40] <jamespage> semiosis, what does the diff look like between your packags and the distro packages?
[21:41] <semiosis> the glusterfs package in trusty has my old upstart job from 2 years ago
[21:42] <jamespage> semiosis, that sucks a bit
[21:42] <semiosis> in summary, moved the mount block job, mounting-glusterfs.conf, from the -server to the -client package, and changed it to wait for static-network-up instead of started glusterfs-server
[21:42] <semiosis> root issue this addresses is mounting glusterfs vols at boot time
[21:42] <jamespage> ok
[21:42] <semiosis> used to only be a problem when mounting vol from localhost
[21:44] <YamakasY_> damn why are mirrors that huge
[21:46] <semiosis> but more recently (last year or so) many people have had issues with the mount being tried before network is up at all
[21:46] <semiosis> idk if that was caused by a change in ubuntu since precise, or just more people using/testing revealed an issue
[21:46] <semiosis> lots of people use my ppa packages and blocking until static-network-up seems to work for everyone
[21:46] <semiosis> only remaining issue i'm aware of with this config is that if you have multiple glusterfs mounts in fstab, the blocker only holds the first one :(
[21:46] <semiosis> idk how to resolve that
[21:46] <semiosis> or even how to approach it
[21:47] <jamespage> semiosis, sounds like there are some good improvements to incorporate
[21:47] <semiosis> YamakasY_: why do you need a mirror?  maybe just a caching proxy will work for you?
[21:48] <YamakasY_> semiosis: to be sure :)
[21:48] <jamespage> semiosis, any chance I can persuade you to raise a merge proposal against lp:ubuntu/glusterfs with relevant changes to incorporate into the Ubuntu package?
[21:48] <jamespage> that can include the new point release as well
[21:49] <semiosis> jamespage: sure, i did that for precise, about time I do another one :)
[21:49] <jamespage> semiosis, thanks - ping me when you have it ready - i'll review and sponsor :-)
[21:49] <semiosis> any thoughts on that issue of blocking multiple mounts with a single blocker job?
[21:50] <YamakasY_> semiosis: too much traffic over such proxy
[21:50] <YamakasY_> to too large cache
[21:50] <semiosis> not as large as a mirror :)
[21:51] <semiosis> well, not larger than
[21:51] <jamespage> semiosis, tricky
[21:51] <semiosis> yep, i gave up on a general solution.  for my own servers I create an extra blocker for each mount with puppet
[21:53] <jamespage> semiosis, it might be possible to use the instance stanza in some way
[21:53] <YamakasY_> semiosis: yeah might be
[21:53] <YamakasY_> semiosis: but I wonder how good that works
[21:54] <semiosis> jamespage: i'll take another swing at that
[21:54] <jamespage> semiosis, I'll think about it as well - and ping jodh for an opinion
[21:54] <semiosis> jodh?
[23:27] <keithzg> Hmmm, why does virt-manager keep asking me for my passwords for my SSH connections, rather than just using the SSH keys as configured in .ssh/config?