[00:00] <Patrickdk> just made one, if it is approved
[00:12] <pmatulis> hallyn_: there now.  i was trying to use other variations in order to continue using preseed.  still not done but i sent in the command i used to get my previous bug comment
[00:51] <fun69> hey folks
[00:51] <fun69> :)))
[00:52] <fun69> I installed nomachine to connect to ubuntu server running gnome - connecting from win7 machine - yet to get full screen
[00:52] <fun69> any advice?
[00:52] <fun69> how to make it full screen :)
[00:56] <sarnold> fun69: windows things often use alt+enter to full-screen
[00:56] <sarnold> or they did back in winnt 4.0 days :) heh
[00:56] <fun69> sarnold: i get full screen but actual ubuntu machine in it is small
[00:57] <fun69> lol
[00:57] <sarnold> fun69: change the 'resolution' of your X server?
[00:58] <fun69> hmm sarnold u mean change it somewhere in ubuntu?
[00:58] <fun69> at this stage I am bit like umm
[00:58] <fun69> :d
[00:58] <fun69> :)
[01:08] <hallyn_> pmatulis: man the code has just totally changed - moved to different filenames and reorg'd.  i may push the debdiff that i said didn't fix it anyway and investigate the next failure differently
[01:09] <pmatulis> hm
[01:14] <sarnold> fun69: yeah, there's gotta be something that says how large to make the display, right?
[01:14] <fun69> sarnold: ok its seems nomachine win for some reason sets diff resolution
[01:14] <fun69> checking how to change it :D
[01:14] <sarnold> fun69: woo :) have fun
[01:14] <fun69> 1680x1050 1024x768
[01:14] <fun69> nr 2 is that nomachine resolution :D
[01:26] <fun69> https://www.nomachine.com/forums/forums/topic/how-can-i-get-higher-screen-resolution
[01:26] <fun69> lol
[01:30] <sarnold> fun69: I have a feeling that titan and dallas just didn't understand each other
[01:31] <fun69> same :D
[01:31] <fun69> I just checked nomachine node in gnome - it says no clients connected
[01:32] <fun69> hmm I wonder if they have irc room
[01:32] <fun69> nope :D
[01:33] <hallyn_> pmatulis: (not that you wanna follow this play-by-play, but) it appears commit 101f176ae4e15d019b570ad5b37794e4bb1fd8ce in libvirt may have something to do with the problem i'm having
[01:34] <atpa8a> beisner: thanks! found the same
[01:34] <atpa8a> setcap solved it
[01:35] <pmatulis> hallyn_: i just wish i could help in some way.  lemme know if you want me to test anything.  so far, this would be a terrible bug to have
[01:37] <atpa8a> ok... so... i don't think it's ubuntu (it's the router likely) but until i ping the 14.04 box from one of the other boxes, the 14.04 box cannot ping the gateway...
[01:37] <hallyn_> pmatulis: thanks, i just need to figure out who isn't happy with what they're getting, and give them what they want...  hopefully i'll find it before mid-day tomorrow.
[01:38] <atpa8a> after any reboot that is
[01:42] <hallyn_> hm, the object being passed in is not a stream class
[01:52] <fun69> :)))
[02:19] <coderanger> Can anyone confirm that the openssl 1.0.1-4ubuntu5.12 package is safe?
[02:20] <coderanger> The output from openssl version -a and some other markers point to it possibly being cranky
[02:20] <sarnold> coderanger: yes, that's the fixed version: http://www.ubuntu.com/usn/usn-2165-1/
[02:20] <coderanger> built on: Tue Jun  4 07:26:06 UTC 2013
[02:21] <coderanger> Also the local CHANGELOG.gz has no entry for the fix
[02:22] <Patrickdk> the changelog does too
[02:22] <Patrickdk> your reading the wrong thing
[02:22] <Patrickdk> cause that is the 5.11 package
[02:22] <Patrickdk> not 5.12
[02:22] <coderanger> Nah, figured it out
[02:22] <coderanger> need to upgrade libssl1.0.0 as well
[02:22] <Patrickdk> oh hell, not even 5.11
[02:22] <Patrickdk> that is older than crap
[03:24] <thumper> stgraber, hallyn_: any idea why on a precise aws image, I get this: $ ubuntu-cloudimg-query trusty released amd64 --format '%{url}\n'
[03:24] <thumper> confused by argument: trusty -- when trying to create a trusty ubuntu-cloud image?
[03:29] <stgraber> probably because
[03:29] <stgraber> ubuntu-cloudimg-query on precise uses some hardcoded list
[03:30] <stgraber> also unless that changed recently, trusty isn't marked as "released", you'd need to use "daily" at the moment
[03:38] <thumper> stgraber: hmm... that same line works on my trustry machine
[03:38] <thumper> https://cloud-images.ubuntu.com/query/trusty/server/released-dl.current.txt
[03:42] <stgraber> ah right, final beta counts as released
[03:43] <hallyn_> i think even alpha did
[03:43] <hallyn_> oh maybe not
[03:44] <thumper> the problem is people creating precise machines with juju then trying to create trusty lxc containers on them
[03:45] <thumper> the lxc is updated, but it is using ubuntu-cloudimg-query to find the image
[03:45] <thumper> which fails
[03:47] <thumper> any idea which package provides that executable?
[03:47] <hallyn_> utlemming: smoser: ^ are those the right arguments for ubuntu-cloudimg-query, and should they work on precise?
[03:47] <thumper> and if we can update it?
[03:48] <hallyn_> you mean ubuntu-cloudimg-query?  that's cloud-image-utils.
[03:48] <thumper> I wonder if that is in the cloud-tools archive
[03:49]  * thumper goes to make coffee
[03:59] <hallyn_> pmatulis: eureka, found it.  will push a fix tonight
[04:04] <stgraber> hallyn_: "eureka, found it", that's a pretty redundant statement :)
[04:05] <hallyn_> admittedly
[04:06]  * hallyn_ looks around for his old greek prof
[04:06] <hallyn_> nowhere to be found - i'll just wait for this to be forgotten on the internet
[04:06] <hallyn_> chuckle
[04:06] <hallyn_> drwxrwxr-x 13 501 501 4096 Mar 23 22:45 /usr
[04:06] <hallyn_> this probably is not good
[04:07] <stgraber> who's 501:501?
[04:07] <hallyn_> not in /etc/group
[04:07] <hallyn_> or passwd
[04:08] <stgraber> fun
[04:08] <hallyn_> i did just purge apache2, maybe that did it
[04:08] <hallyn_> or, it was openssl and being on ipv6
[04:08] <stgraber> both seem rather unlikely
[04:09] <hallyn_> you're telling me not to pull out the gasoline and lighter just yet?
[04:09] <stgraber> :)
[04:09] <hallyn_> stgraber: oh hey, do you happen to know exactly how/when users get added to group sudo during an install from iso?
[04:10] <hallyn_> the problem is, when users install libvirt using tasksel, libvirt-bin.postinst is not placing the initial user into grou plibvirtd - presumably bc he is not yet in group sudo.
[04:10] <hallyn_> i'm wondering whether marking libvirt-bin as Pre-Depends: sudo would solve it
[04:10] <hallyn_> (hard to test without making a new iso)
[04:11] <hallyn_> hm, i suppose the question would be how/when the user gets created.  presumably at end of install.  Pre-Depends would not then help.
[04:12] <stgraber> user-setup would be the one adding the user to the group I suspect
[04:13] <stgraber> and indeed, user creation happens very late in d-i, after packages are installed anyway
[04:13] <hallyn_> so there's really nothing libvirt can do, apart from writing some sudo hook?
[04:14] <stgraber> user-setup-apply does it and it's called from finish-install.d
[04:15]  * hallyn_ looks at user-setup src
[04:16] <stgraber> so you could patch user-setup-apply to detect and deal with libvirt membership which may be very well be the easiest there. Otherwise you can also document that people doing that kind of preseeded installs should set passwd/user-default-groups to include libvirtd
[04:18] <hallyn_> setting passwd/user-default-groups would be done using preseed?
[04:19] <stgraber> yeah. You could also ship a hook which would do it but that'd require introducing a new udeb just for that.
[04:20] <stgraber> so if you mostly care about people doing automated deployments, documenting the preseed option is probably the way to go. If you care about people simply doing a standard install from media and selection libvirt in tasksel, then you probably want to go the user-setup route.
[04:21] <hallyn_> well i don't know that anyone does standard install from media that way any more, but it is pretty easy to do...  hm.
[04:22] <hallyn_> stgraber: thanks, i'll mark down both options for now and sleep on it :)
[04:47] <jamescarr> is the heartleed bug fixed on 12.04?
[05:39] <cdown> Is it expected that there is no patched version of OpenSSL to fix CVE-2014-0160 in the repositories? At least on the NL mirrors, I have no upgrade path available from 1.0.1c-4ubuntu8.2.
[05:41] <cdown> That is on 13.04.
[05:42] <cdown> Wait, 13.04 is out of support.
[05:42] <cdown> Never mind me, time to upgrade...
[07:51] <RoyK> https://www.openssl.org/news/secadv_20140407.txt
[07:53] <RoyK> http://filippo.io/Heartbleed/
[07:56] <lordievader> I think the openssl in Saucy is already patched: https://launchpad.net/ubuntu/saucy/+source/openssl/1.0.1e-3ubuntu1.2
[08:18] <kikimeter> do you know the frequency of the update for the ubuntu mirror ?
[08:19] <kikimeter> an apt-get upgrade on ubuntu 13.10 dont update openssl
[08:20] <RoyK> kikimeter: did you run the test I posted above? http://filippo.io/Heartbleed/
[08:22] <kikimeter> yes
[08:22] <kikimeter> I pass the test :(
[08:22] <RoyK> well, if you passed, what's the problem? ;)
[08:22] <kikimeter> my english should be bad
[08:23] <kikimeter> I have to update my openssl on my server
[08:23] <kikimeter> I have the 1.0.1e
[08:24] <kikimeter> An apt-get update && apt-get upgrade should fix the version of openssl
[08:24] <kikimeter> my unattended-upgrade did nothing
[08:25] <kikimeter> and apt-get update && apt-get upgrade say everything ok
[08:25] <kikimeter> So maybe the mirror (french mirror) are not up to date right now
[08:31] <lordievader> RoyK: Can't say I've tested it, I'm afraid, don't run an https server here.
[08:34] <RoyK> k
[08:34] <RoyK> bug affects ssh too, though
[08:34] <RoyK> but don't know a test for that
[08:42] <xperia> hi. i am trying to configure mysql to use a partition as raw device for storing the data. in /etc/mysql/my.cnf i have this line here
[08:42] <xperia> innodb_data_file_path = /dev/sda3:268435456000newraw ownership of /dev/sda3 was changed to mysql:mysql
[08:42] <xperia> when i try to start mysql however i get allways the error message => 140408 10:36:11  InnoDB: Operating system error number 13 in a file operation.
[08:42] <xperia> InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. InnoDB: File name /dev/sda3 InnoDB: File operation call: 'open'. InnoDB: Cannot continue operation.
[08:42] <xperia> What is here the Problem? I have set up the permission right but mysql fails still to open the /dev/sda3 to use it as raw device. Where is the Problem and how can i fix it?
[08:49] <mardraum> xperia: any apparmor errors?
[08:52] <xperia> mardraum: thanks a lot for the reply. here is the error line =>  kernel: [ 2527.331188] type=1400 audit(1396946978.024:79): apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/dev/sda3" pid=9561 comm="mysqld" requested_mask="rw" denied_mask="rw" fsuid=118 ouid=0
[08:57] <bekks> xperia: apparmor denies raw access.
[08:57] <bekks> xperia: Either lower that mysql profile security, disable it, or edit the profile.
[08:58] <xperia> bekks: yeah going to change then apparmor profile
[09:14] <xperia> mardraum	: bekks	: finally i could solve the problem but there is a new problem with reformating the raw device partition by mysql. based on parted information i set the size of the partition as 268435456000 Bytes. For some strange reason however mysql stops the formating of the device before the end
[09:14] <xperia> 140408 11:00:02  InnoDB: Setting file /dev/sda3 size to 256000 MB InnoDB: Database physically writes the file full: wait...
[09:14] <xperia> InnoDB: Progress in MB: 100 .... 15600 Exit
[09:15] <xperia> asking me if the problem has to do with the EXT4 Filesystem. Erasing the Partition and retrying.
[09:17] <bekks> raw device access never has anything to do with a filesystem.
[09:17] <bekks> Either you put your files on a filesystem, or you are using raw devices.
[09:17] <bekks> Thats basically why it is called "raw device access".
[09:24] <xperia> bekks: yeah but how can i tell mysqld the right size so it does not stop the reformating of the raw device. i used parted to get the size in Bytes and told mysql to use that size. after erasing of the partition mysql was able to format 100GB more Space in the partition now but it still stoped the proces and failed to start.
[09:24] <xperia>  
[11:37] <pmatulis> morning
[11:47] <jamespage> zul, could you do the honours for a new libvirt for the CA please (icehouse)
[11:48] <jamespage> zul, working on a new point release for ceph right now
[11:50] <zul> jamespage:  yep
[11:51] <jamespage> zul: ta
[11:51] <jamespage> zul, i've pushed cinder and swift through to updates btw
[12:26] <smoser> stgraber, thumper, apt-get install distro-info
[12:26] <smoser> and that fixes the hard coded list.
[12:26] <smoser> we can sru a touch to that package to know about trusty though.
[12:31] <zul> jamespage:  cool thanks
[12:46] <ice9> if I need to upgrade an application for security fix but it's package is not ready yet in the repo, what should I do, install it from source? but then how do I keep tracking with recent version?
[12:46] <ice9> in the future
[13:10] <rbasak> hallyn: does bug 1302724 need attention before Trusty's release? It's not clear to me.
[13:10] <rbasak> zul: ^^
[13:10] <pmatulis> hallyn: virt-install is looking good!
[13:12] <rbasak> jamespage: do you know why unbound has ~ubuntu-server subscribed? I don't see it seeded.
[13:12]  * rbasak is wondering about the priority for bug 1303477
[13:12] <jamespage> rbasak, gaughen added it - unbound and strongswan just got accked for MIR
[13:13] <rbasak> Ah
[13:13] <jamespage> rbasak, still it might need seeding in the server-supported seed
[13:13] <rbasak> I was party to that email, but had forgotten. Thanks!
[13:14] <zul> rbasak:  dont think so ill double check
[13:14] <rbasak> jpds: could you take a look at bug 1303477 please? Is this important?
[13:15] <rbasak> It _sounds_ like a fundamental and important issue to me, but I haven't confirmed it.
[13:18] <zul> rbasak:  yeah thats fixed in an SRU i just havent backported it to the CA yet
[13:20] <rbasak> zul: ah, thanks. I found bug 1287232. This one is a dupe of that one then, right?
[13:21]  * rbasak marks it so
[13:22] <zul> rbanffy:  yes
[13:22] <zul> effing autocomplete
[13:22] <zul> rbasak:  yes
[13:22] <rbasak> OK, thanks!
[13:22] <rbanffy> You woke me up, zul ;-)
[13:23] <zul> jamespage:  libvirt uploaded...just going to go fix havana
[13:30] <jamespage> zul, ta
[13:31]  * smb squeals at hearing libvirt upload from zul
[13:32] <smb> ubuntu10 would be ok, I saw that already. :)
[13:38] <jpds> rbasak: The odd thing about that bug is that it's related to saucy.
[13:39] <rbasak> jpds: does it affect Trusty also? Or is it fixed now?
[13:39] <jpds> rbasak: Trusty should be working fine.
[13:39] <jpds> I'll spin up a test VM just to be sure.
[13:39] <rbasak> jpds: thanks!
[13:40] <jpds> rbasak: Trusty did have an issue that I fixed yesterday: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1303088
[13:40] <rbasak> I tried to confirm bug 1303477 the other day, but I got confused results.
[14:00] <hallyn> pmatulis: excellent
[14:01] <hallyn> rbasak: I'm confused.  is it really a bug?
[14:01] <rbasak> hallyn: zul resolved it as a dupe now.
[14:01] <rbasak> (fixed in Trusty, AIUI)
[14:02] <hallyn> rbasak: ok, thx
[14:02] <zul> rbasak:  thanks
[14:03] <batok> Is openssh server affected by heartbleed bug?
[14:03] <jrwren> no.
[14:04] <jrwren> openssh doesn't do ssl over tcp directly.
[14:04] <batok> tks jrwren
[14:06] <jpds> rbasak: Yeah, works fine for me on trusty.
[14:12] <rbasak> jpds: thanks for testing! Do you mind commenting and marking https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1303477 as Fix Released then, please?
[14:13] <jpds> rbasak: Done.
[14:13] <rbasak> Thanks!
[14:17] <zul> coreycb:  hey do you have keystone rc2 yet?
[14:18] <coreycb> zul, still building.  tests are taking a long time.
[14:18] <zul> coreycb: ack
[14:21] <jamespage> zul, foobar - can't get docker to work today
[14:21] <jamespage> zul, trying on something other than my laptop...
[14:23] <jamespage> kirkland, the ubuntu orange in the byobu status bar really hurts my eyes :-)
[14:24] <zul> jamespage:  docker is foobared?
[14:24] <jamespage> zul, neither the upstream packages or the latest in debian can stop/kill running containers
[14:24] <jamespage> I can start them OK :-)
[14:25] <jamespage> zul, hmm - seems to be a 0.9.x issue
[14:26] <zul> jamespage:  lovely want me to have a look?
[14:26] <jamespage> zul, sure - but don't put it higher than openstack
[14:26] <jamespage> zul, the 0.8.1 we have in archive is OK - but that is using the lxc package for cgroups interaction
[14:26] <jamespage> zul, 0.9.0 upwards uses libcontainer to interact directly
[14:27] <jamespage> I suspect that is where the issue lies
[14:27] <jamespage> kirkland, fyi and I know you are interested in docker ^^
[14:40] <zul> jamespage:  cool lemme talk to eric and see if he has seen it
[14:41] <jamespage> zul, +1
[14:42] <zul> jamescarr:  he hasnt seen it
[14:42] <zul> jamespage: he hasnt seen it but he hasnt played much with 0.9.1
[14:42] <jamespage> zul, get the same with 0.9.0
[14:44] <zul> jamespage:  gimme a sec wanna try something first
[14:44] <jamescarr> huh
[14:53] <zul> jamespage:  hmm...i cant even start a container
[14:53] <jamespage> zul, with 0.9?
[14:53] <zul> 0.8.1
[14:53] <zul> the version in trusty
[14:55] <jamespage> zul, oh - that's OK for me
[14:55] <jamescarr> how can I tell if the openssl version I have installed has the fix???
[14:55] <Pici> !sslbug
[14:56] <Pici> hmm.. thats annoying.
[14:56] <zul> jamespage:  where did you get 0.9 from?
[14:56] <jrwren> great, the bots are talking.
[14:56] <jamescarr> how can I tell if the 1.0.1 version of openssl I installed is patched?
[14:56] <jamespage> zul, I pulled it from debian and built it AND i tried from the upstream repositories
[14:57] <jamespage> jamescarr, apt-get changelog openssl
[14:57] <jamespage> check the fix is in the version you are using
[14:57] <zul> jamespage: ah ok
[15:01] <jamespage> zul, one sec - have a hint from upstream
[15:01] <jamespage> apparently apparmor profile needs a fix
[15:02] <zul> jamescarr:  ah
[15:02] <DefunctProcess> hey guys I need some recommendations for some server apps with slick web interfaces for admininstration.  I need a VPN,FTP,PROXY,SAMBA....
[15:03] <DefunctProcess> no love?
[15:04] <cfhowlett> !patience|DefunctProcess
[15:04] <jrwren> DefunctProcess: it is an area lacking IMO
[15:04] <jrwren> DefunctProcess: and we linux types tend to love cmdline and text files for config
[15:05] <jrwren> DefunctProcess: and with things moving to cloud more, we are moving toward not administering single servers, but services which may be on many servers, so admin for that becomes - different.
[15:05] <jrwren> DefunctProcess: once you look at it that way, juju-gui might be the gui you want :)
[15:07] <i_am_good> I am getting "grub-install failed /dev/sdf FATAL ERROR" during installation. Every time it's failing when it gets to GRUB. I chose to use guided partition (entire disk). What am I missing?
[15:08] <DefunctProcess> webmin.... webmin has a frontend for proxy, ftp, samba and vpn
[15:08] <zul> jamespage: yeah that fixed it for me
[15:08] <jamespage> zul, me to
[15:08] <cfhowlett> !webmin|DefunctProcess
[15:08] <jamespage> I had to scrub the existing docker profile first tho
[15:08] <zul> jamespage:  should we bump docker.io in trusty then?
[15:08] <zul> with the patch
[15:08] <DefunctProcess> what is the successor then? juju-gui as suggested?
[15:09] <jamespage> zul, I've been waiting for a FFe for two weeks now
[15:09] <zul> jamespage:  oh maybe bug daviey then
[15:09] <jrwren> certainly not.
[15:09] <jrwren> and I did not mean to suggest juju-gui as an alt. I'm suggesting rethinking hte entire need for such a tool :]
[15:12] <DefunctProcess> jrwren: i cannot demo juju as my browser at work is not supported, care to give a breif summary?
[15:13] <jrwren> DefunctProcess: cloud orchestration tool.
[15:15] <DefunctProcess> jrwren: does this mean the services must be running in the cloud or can i run them locally?
[15:16] <jrwren> DefunctProcess: there are some backends which can run local.
[15:16] <jrwren> DefunctProcess: it will definitely be a mindshift. its is NOT a server admin tool.
[15:16] <DefunctProcess> jrwren: this is not what i want, but I appreciate your help.
[15:18] <jrwren> DefunctProcess: sorry for confusing. gl.
[15:23] <zul> jamespage: https://bugs.launchpad.net/nova/+bug/1304107
[15:24] <jamespage> zul, OK - can you confirm that? I did not see issues on trusty yesterday
[15:26] <zul> jamespage: ill try
[15:31] <coreycb> zul, jamespage : https://code.launchpad.net/~corey.bryant/keystone/2014.1.rc2/+merge/214793
[15:31] <jamespage> hallyn, what's your take on the state of bug https://bugs.launchpad.net/nova/+bug/1254872
[15:31] <bijoo_> Hi, how to reproduce the heartbleed bug?
[15:32] <jamespage> do we have enought to say that's good for acceptance yet?
[15:32] <bijoo_> Everyone's clamoring but no steps.
[15:36] <hallyn> jamespage: i think so...  my impression is there's another bug but this did solve one.
[15:36] <zul> coreycb: looks good to me
[15:41] <coreycb> zul thanks
[15:44] <zul> coreycb/jamespage: keystone rc2 uploaded
[15:44] <RoyK> hi all. trying to install rrdcached on precise64, but it just fails with a segfault when attempting to start: http://paste.ubuntu.com/7222097/. Can't see any issues with anything else, and if it were a memory issue, I *would* have seen more processes crash after a couple of reboots etc...
[15:45] <jgornick> Hey guys, are there any extra steps other than upgrading to fix the latest openssl fix? Do I need to regenerate SSH keys?
[15:45] <jgornick> I'm also running 12.04.
[15:52] <batok> how can I upgrade openssl in 13.04?
[15:53] <cfhowlett> !eol|batok
[15:53] <cfhowlett> batok 13.04 has reached end of life.  see above
[15:57] <patdk-wk> jgornick, no
[15:58] <batok> cfhowlett is it possible to upgrade an aws ec2 instance 13.04 to a supported version?
[15:58] <jrwren> jgornick: ssh keys are fine.
[15:58] <jgornick> patdk-wk: Ok, I would only have to regenerate any SSL certs that are used for the site?
[15:58] <patdk-wk> yes, smtp, imap, pop, https, ftps, ...
[15:59] <cfhowlett> batok my advice is to upgrade your OS to a supported version: 12.04, 13.10, hell, even the 14.04 beta preferable to running an unsupported OS
[15:59] <jgornick> patdk-wk: Thank you.
[16:01] <batok> tks cfhowlett
[16:04] <jgornick> After upgrading and restarting Apache2, if I run
[16:04] <jgornick> ... crap...
[16:04] <jgornick> After upgrading and restarting Apache2, if I run "ls -l /proc/*/fd | grep ssl.*(deleted)" it still shows that apache2 ssl_mutex is deleted. Any thoughts? I'm performing steps from: http://askubuntu.com/questions/444702/how-to-patch-cve-2014-0160-in-openssl/444905#444905
[16:20] <batok> How can I upgrade, with sudo apt-get upgrade or running do-release-upgrade script?
[16:20] <cfhowlett> batok do-release-upgrade
[16:20] <batok> as sudo?
[16:20] <ryan_turner|MTW> Is it a wise decision to install ubuntu 12.04 today and update to 14.04 once released, or install 12.04 and then once 14.04 is released, wipe&reinstall?
[16:21] <JediMaster> hi all, I'm doing a do-release-upgrade on a 13.04 ubuntu-server install to get it to 13.10 to get the latest openssl/ssh vulnerabilities patched
[16:22] <batok> cfhowlett sudo do-release-upgrade or without sudo¿
[16:22] <JediMaster> the do-release-upgrade got stuck for 10 minutes updating the /etc/mysql/mysql.conf file then carried on going, it's now been sitting for nearly 30 minutes doing: Removing any system startup links for /etc/init.d/rpcbind ...
[16:22] <cfhowlett> batok with
[16:22] <JediMaster> I can see there are 40 zombie processes (there were 0 when it started)
[16:25] <Daviey> mdeslaur: Hey, CVE-2014-0076 on ~ubuntu-security CVE tracker has a Priority of Medium.  Is that accurate, if so - how did you come to that?
[16:26] <Daviey> Oh forget that. Looking at the wrong one. :)
[16:29] <JediMaster> 50 zombie processes, still waiting on that rpcbind system startup link for 30+ minutes now
[16:31] <JediMaster> you can't kill zombies right? =)
[16:31] <JediMaster> got a bunch of defunct processes who's parent process ID are now 1
[16:31] <alex-foo> i'm not seeing an openssl 'heartbleed' fix for 10.04 LTS yet -- is it coming?
[16:32] <Pici> alex-foo: it is not applicalble for 0.9.8
[16:32] <alex-foo> oh, so it was never vulnerable! phew
[16:32] <alex-foo> thanks!
[16:32] <Pici> np
[16:36]  * koolhead17 looks around
[16:36] <mdeslaur> Daviey: they're basically all medium...it's the priority that we fix them, not a severity or anything
[16:37] <koolhead17> zul: jamespage hazmat Daviey jcastro adam_g ^^ hellos
[16:37] <Daviey> mdeslaur: Yeah, thanks :)
[16:37] <jamespage> hey koolhead17
[16:38] <koolhead17> jamespage: how are things? anything needed for 14.04 from my side :)
[16:38] <jamespage> koolhead17, ok
[16:38] <jamespage> koolhead17, as always testing testing testing!
[16:39]  * koolhead17 looking forward for the baked 14.04
[16:46]  * hazmat prefer bbq 
[16:47] <koolhead17> hazmat: depands with or without juju :P
[16:49] <zul> jamespage:  hey we are doing another upload for libvirt fyi
[16:49] <zul> https://bugs.launchpad.net/nova/+bug/1304107/comments/8
[16:50] <xibalba> hey everyone, is there going to be a pkg update for opeenssl shortly?
[16:51] <patdk-wk> xibalba, what for?
[16:51] <xibalba> the heartbleed stuff
[16:51] <patdk-wk> heh?
[16:52] <patdk-wk> that is old news
[16:52] <patdk-wk> or, why would there need to be ANOTHER pkg update for it?
[16:52] <xibalba> disable heartbeat?
[16:52] <patdk-wk> !usn
[16:52] <patdk-wk> xibalba, did you bother to read that url yet?
[16:53] <xibalba> this one specifically no
[16:53] <patdk-wk> as the pkg fixed heartbleed over 16hours ago
[16:53] <patdk-wk> I dunno what your asking about
[16:53] <xibalba> well i'm just waking up
[16:53] <xibalba> =D
[16:54] <patdk-wk> isn't it normal to check if a fix was already sent to the public, before asking for one?
[16:54] <xibalba> i'm sure it is
[16:54] <xibalba> by that measure i'm abnormal
[16:55] <patdk-wk> better yet, normal to check if your system already automatically installed the security update, before asking where it is :)
[16:55] <xibalba> no i dont have mine autopatch
[16:58] <smoser> hallyn, did you fix that fd leak in cgmanager ?
[16:58] <hallyn> what fd leak?
[16:58] <hallyn> oh, yeah
[16:58] <hallyn> well it wasn't fixed in cgmanger, it was fixed in logind
[16:58] <hallyn> by stgraber :)
[16:59] <hallyn> there is some new defensive behavior in cgmanager upstream but not in trusty to make this harder to happen in the future...
[16:59] <xibalba> hmm my apt-get upgrade brought me to version : OpenSSL 1.0.1f 6 Jan 2014
[17:00] <patdk-wk> xibalba, and?
[17:00] <smoser> hallyn, thanks.
[17:00] <xibalba> f is still vulnerable
[17:00] <patdk-wk> xibalba, did you even BOTHER to read that url?
[17:00] <hallyn> smoser: hopefully that box is no longer having that issue?
[17:00] <patdk-wk> !usn | xibalba
[17:00] <smoser> hallyn, was just curious. handnt seen it.
[17:00] <patdk-wk> !securityupdate
[17:00] <patdk-wk> !securityupdates
[17:01] <hallyn> ah cool.  ok - ttyl
[17:02] <patdk-wk> xibalba, who said 1.0.1f is insecure?
[17:02] <xibalba> https://www.openssl.org/news/secadv_20140407.txt
[17:02] <xibalba> Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
[17:02] <xibalba> 1.0.1f and 1.0.2-beta1.
[17:02] <patdk-wk> xibalba, and they are running ubuntu?
[17:02] <patdk-wk> or, do they specify what ubuntu versions are vaunerable?
[17:03] <xibalba> this is just openssl's version number
[17:03] <xibalba> the ubuntu one doesn't match?
[17:03] <patdk-wk> xibalba, and what do their versions numbers have to do with ubuntu's?
[17:03] <xibalba> haha are you a troll dude?
[17:03] <smoser> xibalba, what patdk-wk and others are saying, is that if you have ubuntu packages up to date, then you are not vulnerable.
[17:03] <patdk-wk> xibalba, you refuse to read ubuntu's infomation
[17:04] <patdk-wk> you are taking infomation, out of context
[17:04] <xibalba> ubuntu's version # for openssl does not match openssl's versoin #s?
[17:04] <patdk-wk> in this case, not related to ubuntu
[17:04] <smoser> in all supported ubuntu releases, the newest openssl is not vulnerable to that CVE.
[17:04] <smoser> ubuntu patches existing versions, it does not release new upstream versions.
[17:04] <xibalba> ahhhhh
[17:04] <smoser> this is common behavior amoung distros
[17:05] <xibalba> ok i was expecting it to match the same #
[17:05] <patdk-wk> therefore 1.0.1f in ubuntu != openssl 1.0.1f
[17:05] <xibalba> gotcha
[17:05] <patdk-wk> and if you read ubuntu's security info about this
[17:05] <patdk-wk> it would tell you the version in ubuntu that is secure
[17:05] <xibalba> right i just didn't think that was right
[17:06] <jamespage> zul, hallyn: ack
[17:06] <jamespage> I'll hold off promoting anything to -updates just yet
[17:06] <hallyn> ?
[17:06] <hallyn> waht's that pertaining to?
[17:07] <zul> hallyn:  cloud-archive
[17:08] <hallyn> ok
[17:16] <jvargas> Hi
[17:16] <jvargas> Does 13.04 have patch for heartbleed bug?
[17:17] <patdk-wk> 13.04 doesn't even exist
[17:17] <ogra_> all supported releases that need it got it yesterday
[17:18] <patdk-wk> jvargas, http://fridge.ubuntu.com/2014/01/28/ubuntu-13-04-raring-ringtail-end-of-life-reached-on-january-27-2014/
[17:18] <jvargas> thanks patdk-wk, just noticed
[17:40] <tasslehoff> do security updates get automatically installed? I seem to have openssl 1.0.1-4ubuntu5.12 already
[17:41] <patdk-wk> if you setup automatic install yes
[17:41] <patdk-wk> but installing security updates, doesn't restart your programs, to make use of the update
[17:42] <tasslehoff> patdk-wk: I know. rebooting in progress :)
[17:44] <sarnold> tasslehoff: see if you have the unattended-upgrades package installed
[17:45] <tasslehoff> sarnold: I do. It does nothing when run.
[17:45] <sarnold> tasslehoff: that's probably because it ran a cronjob when you weren't looking :)
[17:46] <tasslehoff> sarnold: I see security is uncommented in 50unattended-upgrades
[17:46] <tasslehoff> all is well then. just need to decide if I should generate new keys
[18:02] <xibalba> any of oyu guys using MaaS?
[18:28] <RoyK> !ask | xibalba
[18:28] <xibalba> !patience
[18:28] <xibalba> !uselessresponses
[18:28]  * xibalba did not ask to ask
[18:32] <RoyK> xibalba: well, this is just a place with a lot of people sharing the same operating system. we have no obligation to help, but we can. that !ask thing is just about that - just ask if you have a problem, and please describe in detail. someone might just know
[18:32] <xibalba> i just wanted someones opinions/experiences on trying out the MaaS stuff
[18:32] <xibalba> i like the concept
[18:32] <xibalba> haven't tried it out yet. might try it out w/some virtual machines
[18:36] <sarnold> to the extent I've tested maas while doing security updates for it I thought it looked neat
[18:40] <No_one_a1_all> Hi, incredibly stupid question, here. Will using `sudo reboot now` (note the "now") cause a system to hang on reboot?
[18:41] <No_one_a1_all> Because, as I understand, /sbin/reboot does not accept cli arguments
[18:41] <No_one_a1_all> (unlike shutdown)
[18:42] <patdk-wk> No_one_a1_all, yes, it will
[18:43] <No_one_a1_all> patdk-wk goddammit WHY
[18:43] <pmatulis> i just tried on precise, came up fine
[18:43] <No_one_a1_all> patdk-wk: `shutdown -r now` is, like, second nature. Why why why why. I lost 1:40 of downtime to my own ignorance. This is so not fair.
[18:44] <No_one_a1_all> what about... 13.10?
[18:44] <patdk-wk> shutdown != reboot
[18:44] <pmatulis> No_one_a1_all: dunno, try it
[18:44] <No_one_a1_all> I already did, and had a system hang.
[18:45] <No_one_a1_all> this is so bogus. Second time I've fallen into this trap.
[18:45] <pmatulis> No_one_a1_all: file a bug, i'm surprised the command was processed tbh
[18:46] <No_one_a1_all> Apparently a bug report has already been filed, and a fix implemented. https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1174272
[18:46] <patdk-wk> oh, it was fixed
[18:47] <No_one_a1_all> Except it wasn't, apparently
[18:48] <No_one_a1_all> yeah, Ubuntu 13.10 is what we're running, and just "boom". Server disappeared until we hard-rebooted it.
[18:48] <No_one_a1_all> *sigh*
[18:49] <pmatulis> regression maybe.  test other releases.  except precise, as i just tested it
[18:50] <No_one_a1_all> I don't have any other releases to test. Oh, well.
[18:50] <lstefani> hello.
[18:50] <lstefani> how I can allow port 80 on iptables?
[18:50] <lstefani> iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT  --
[18:53] <pmatulis> yes, trusty is borked too
[18:54] <No_one_a1_all> well that's just excellent.
[18:57] <pmatulis> No_one_a1_all: you should have commented on the bug about Saucy.  get with the program
[18:58] <No_one_a1_all> pfah
[18:58] <No_one_a1_all> I'm not a sysadmin. I know approximately as much about sysadminning and creating bug reports as a monkey knows about ice-skating
[18:59] <pmatulis> No_one_a1_all: can be as simple as "This affects Saucy" - provide a screenshot for bonus points
[18:59] <pmatulis> No_one_a1_all: like i did for 14.04
[19:00] <No_one_a1_all> link
[19:00] <sync0pate> anyone know of a good tutorial to learn iptables?
[19:00] <pmatulis> No_one_a1_all: the one you gave us
[19:00] <No_one_a1_all> Oh, that one...wasn't closed or "resolved" or anything? I have no idea how these bug trackers work
[19:21] <No_one_a1_all> pmatulis: sorry to bug you again, but under "also affects distribution/package", what would I enter to indicate 13.10?
[19:22] <No_one_a1_all> wait, nevermind.
[19:25] <zul> coreycb: i got ceilometer rc2
[19:28] <coreycb> zul, ok anything else you want me to take?
[19:29] <zul> not yet :)
[19:42] <zul> jamespage: https://code.launchpad.net/~zulcss/ceilometer/2014.1.rc2/+merge/214829
[19:43] <jamespage> zul, aside from my fullstop in the middle of a sentence niggle +1
[19:54] <tgm4883> Regarding the heartbleed bug, I just want to confirm that all openssl < 5.12 is affected. The writeup only states it's 5.11
[20:02] <batok> Is 14.04 going to be a supported version?
[20:04] <Patrickdk> tgm4883, only if it starts with 1.0.1
[20:05] <Patrickdk> batok, supported version of what?
[20:05] <batok> I mean like 13.10 where there are still packages available and not 13.04
[20:06] <Patrickdk> batok, oviously, you don't know what supported means
[20:06] <Patrickdk> 13.04 was supported
[20:06] <Patrickdk> the same support for 13.10 also
[20:06] <Patrickdk> exactly how was 13.04 not supported?
[20:07] <mgw> batok: https://wiki.ubuntu.com/LTS
[20:07] <batok> theres is no patch to fix de openssl bug in 13.04
[20:07] <Patrickdk> batok, 13.04 was released on april 2013, it was said, long before it's release, it would only be SUPPORTED for 9 months
[20:07] <Patrickdk> 4+9=13, so in jan it was unsupported
[20:07] <Patrickdk> guess what will happen to 13.10 after 9months
[20:08] <batok> I didn’t know that Patrickdk tks
[20:08] <Patrickdk> batok, release notes are required reading
[20:09] <tgm4883> Patrickdk, ok, that is what I thought. And my understanding is they get full access to the private key of the server allowing an attacker to setup a server pretending to be us. Is that correct?
[20:09] <zul> jamespage:  ack..ill get libvivrt ubuntu11 in the cloud archive as well in a couple of secs
[20:09] <Patrickdk> tgm4883, no
[20:10] <tgm4883> I'm just trying to gauge how much fixing my team needs to do here
[20:10] <Patrickdk> they get access to 64k of ram
[20:10] <jamespage> zul, +1
[20:10] <Patrickdk> that 64k of ram could be ANYTHING
[20:10] <Patrickdk> could be the ssl private key
[20:10] <Patrickdk> could be your root password
[20:10] <Patrickdk> could be anything
[20:11] <tgm4883> hmm
[20:11] <Patrickdk> now, it would be inlikely your root password would be in the ram area accessable by that app
[20:11] <Patrickdk> but possible
[20:11] <mgw> is there any sign that this bug has been exploited?
[20:11] <tgm4883> Patrickdk, I guess I'm just confused by the writeup on the website then, specifically "Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."
[20:12] <Patrickdk> tgm4883, yes
[20:12] <tgm4883> Was it just random they got the secret keys, or am I thinking of something different than what they mean by secret keys
[20:12] <Patrickdk> without doing anything other than making a tcp connection
[20:12] <Patrickdk> they could steal ANYTHING in ram
[20:13] <tgm4883> so it was just random that they got the keys... That's still pretty bad and makes me want to rekey everything
[20:13] <Patrickdk> tgm4883, that is why it says, to rekey everything
[20:16] <tgm4883> mgw, the exploit leaves no signs on the server. You wouldn't be able to tell
[20:17] <tgm4883> Patrickdk, thanks for the info, I'll get my team on replacing al of that
[20:17] <Patrickdk> ya, lots of fun :)
[20:28] <Gargoyle> Hi.
[20:29] <Gargoyle> Is there an official "ubuntu/debian way" to regenerate ssh keys? With dpkg-reconfigure or something?
[20:29] <Patrickdk> Gargoyle, sure, but why do you need to?
[20:29] <Gargoyle> Patrickdk: Hearbleed
[20:29] <Gargoyle> Heartbleed*
[20:29] <Patrickdk> what does hearbleed have to do with ssh?
[20:30] <Gargoyle> The keys are generated by openssl
[20:30] <Patrickdk> Gargoyle, so?
[20:30] <Patrickdk> generated by != compromised
[20:30] <Patrickdk> did you serve up those keys via your website?
[20:30] <Gargoyle> So are SSH keys safe? do we only need to regenerate SSL certificate keys?
[20:30] <Patrickdk> did you email them?
[20:30] <Patrickdk> yes
[20:31] <Gargoyle> Ok. Thanks.
[20:35] <Gargoyle> If you have a public key out in the wild - like on github - would that be a risk?
[21:38] <a|3x> hi
[21:39] <a|3x> is there going to be openssl security patch for the heartbleed bug for raring?
[21:40] <sarnold> a|3x: no, raring has not been supported since january.
[21:40] <sarnold> a|3x: https://wiki.ubuntu.com/Releases
[21:41] <a|3x> lets see, i guess i would need to upgrade
[21:41] <sarnold> please do :)
[22:46] <mgw> anybody using lxc with lvm backing and snapshots? I'm having an issue creating a clone with a different size fs than the original
[23:06] <hallyn> mgw: oh, hey.  didn't see it here :)  lemme know what you end up doing, am interested what others are using