[09:24] <lordievader> Good morning.
[11:21] <Prezident> Morning
[11:45] <haithar> Hi all! I'm a ~beginner sysadmin and currently working on moving 10+ reverse proxies (on old Fedura, CentOS etc.) to Ubuntu LTS. I've installed Ubuntu 14.04.1 LTS and its Squid (3.3.8) has a serious bug ( http://bugs.squid-cache.org/show_bug.cgi?id=3806 ) that basically means Squid won't cache much in real life. (It doesn't cache any item with a Va
[11:45] <haithar> ry HTTP header - and that's often used on HTML, CSS and JS files.) What do you think I should/could do? Use Ubuntu 12 LTS? Or maybe that non-security patch could be included in 14 LTS? (Well it is indeed hardening existing functionality.)
[11:46] <jpds> haithar: That bug is fixed on 3.3 ?
[11:47] <haithar> jpds: will check now
[11:47] <jpds> haithar: At least, that's what hte bug report says.
[11:47] <jpds> haithar: My squid proxies are caching things just fine.
[11:47] <haithar> jpds: yeah, http://bugs.squid-cache.org/show_bug.cgi?id=3806#c11 says it's in 3.3
[11:48] <jpds> haithar: OK, are you saying that there's a regression?
[11:49] <haithar> jpds: as far as I understand the problem, yes, eg. if you upgrade 12 LTS to 14 LTS and Squid is upgraded, most objects* won't be cached anymore. (*: For a generic website serving images and HTML-JS-CSS files.)
[11:50] <jpds> haithar: Have you reported a bug about about this regression?
[11:50] <haithar> jpds: it caches images, favicon.ico, ZIP etc. just fine, only MISSes files with a Vary header.
[11:50] <haithar> jpds: no. I'm all new to Ubuntu server support. I don't even know where to report it. I wasn't even aware of the fact that this is indeed a regression :)
[11:51] <jpds> haithar: Well, what I'm saying is: that bug was reported against squid 3.2, and the squid guys say that it's fixed in 3.3.
[11:51] <jpds> haithar: So you shouldn't be seeing the issue on 3.8 in Ubuntu.
[11:51] <haithar> it's 3.3.8
[11:51] <jpds> Sorry, same thing.
[11:52] <Odd_Bloke> jpds: It was applied to the 3.3 branch, not released in 3.3.
[11:52] <Odd_Bloke> Looking at dates on http://www.squid-cache.org/Versions/v3/3.3/, it was probably released in 3.3.12.
[11:52] <jpds> Hmm.
[11:53] <haithar> got that, indeed it was fixed in 3.3.12
[11:53] <jpds> I see.
[11:54] <lordievader> !info squid3 utopic
[11:54] <Odd_Bloke> This looks like https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1336742
[11:54] <lordievader> !info squid3 vivid
[11:54] <Odd_Bloke> s/looks like/is/
[11:55] <jpds> haithar: Best to file a bug at: https://bugs.launchpad.net/ubuntu/+source/squid3/
[11:55] <Odd_Bloke> jpds: haithar: It's already filed as bug 1336742.
[11:55] <haithar> Odd_Bloke: yep, that's that
[11:56] <haithar> I belive I downloaded and installed all patches after installing Ubuntu 14.04.1 LTS; should I have this fix already?
[11:56] <Odd_Bloke> haithar: It hasn't been fixed in Ubuntu.
[11:59] <haithar> Ah I see. I looked up the status triaged, so I guess 14 LTS will eventually get this patch - great stuff! Knowing the ins and outs of the Ubuntu Server fixes-patches workflow, do you think you can guess when/if this gets shipped?
[12:00] <Odd_Bloke> haithar: So, generally, the fix lands in the development release and is backported.
[12:00] <Odd_Bloke> But vivid is feature frozen at the moment, so someone would need to get a feature freeze exception before that could happen.
[12:02] <haithar> oh sugar now I see it enters beta freeze just tomorrow
[12:04] <haithar> We're doing core app server upgrades (from 10 LTS) that looks a lengthy process, and have to install good proxies before we touch the core. Even if this fix made it into vivid, when do you think would it realistically available as a patch autoinstalled?
[12:05] <haithar> (Weeks? Months? I'm not even sure about the order of magnitude :) )
[12:05] <Odd_Bloke> haithar: It's difficult to know; it depends on someone deciding that they care about it enough to do it. :p
[12:06] <haithar> Is there a way to sponsor merges?
[12:07] <Odd_Bloke> haithar: Not 100% sure what you're asking. :)
[12:09] <haithar> To offer some cash or reward if someone would be so kind to push this through vivid and trusty. (Do the merges, raise the exception etc. For the person or for the Ubuntu project, or to a charity etc.)
[12:10] <haithar> I'd do it myself but I'm not a C programmer and I know nothing about the Ubuntu bugfixing/merging/release mechanism.
[12:14] <nobody44> we use Ubuntu LTS 14.04 on our servers + tomcat 7 and java 7. What happens to the openjdk package when oracle stop supporting Java 7? Or does this only concern the Oracle JDK / JRE 7 package users?
[12:17] <Odd_Bloke> haithar: Not really that I know of; I've pinged the people looking at that bug, and they aren't likely to get to it.
[12:17] <Odd_Bloke> haithar: (I also had a quick look myself, and I'm out of my depth)
[12:36] <haithar> Odd_Bloke: so is my understanding right that if I need to set proxies up in about 2-4 weeks, maybe I shouldn't wait for this fix to appear in trusty?
[12:36] <haithar> What'd you recommend, going for 12 LTS or installing the latest stable Squid on 14 LTS and manually monitor+upgrade it every time? Or is there another way?
[12:37] <rbasak> haithar: thank you for bringing this up. I've only just caught up with this discussion. It'd be improper for me to take your money, since I'm already paid by Canonical. But it's fine if you can find an independent Ubuntu developer to pay to prioritise this for you, or you can pay Canonical for support to fix this for you. They'll be able to tell you if 2-4 weeks is realistic.
[12:38] <rbasak> Alternatively this sounds like something that someone will get round to fixing eventually, but 2-4 weeks seems unrealistic to me.
[12:39] <rbasak> I might get to it in 2-4 weeks, but I get pulled away in all sorts of directions all the time.
[12:39] <rbasak> You could try and submit a fix yourself for sponsorship (not money - just review and upload to Ubuntu), but I guess you've ruled that out because of your skillset?
[12:43] <haithar> Yes, I wouldn't dare to touch C code after not coding in that for 10+ years, and I'm sure I can't code a proper regression test within a reasonable time.
[12:45] <haithar> rbasak: Do you know a ballpark number for the Canonical support needed to push this right down to trusty? (Again, I'm not even sure about the order of magnitude, whether it's in the 100+ EUR or in the 1000+ EUR range.)
[12:45] <haithar> rbasak: and thanks for looking into this!
[12:52] <rbasak> haithar: I'm not really sure, sorry - it's a different department here. I think you might need an Ubuntu Advantage contract - details are on the website. Maybe someone like pmatulis knows more? ^^
[12:53] <rbasak> (or to whom to pass this to?)
[12:55] <nobody44> I just saw an update for OpenJDK 6... oracle dropped support a long time ago. Is canonical supporting this OpenJDK 6 (and in the future 7) package?
[12:56] <nobody44> I just don't understand how those LTS releases "work"... who fixes the security issues in those OpenJDK releases?
[12:59] <rbasak> nobody44: depends on whether it is in main or universe on the release you're using. If in main, Canonical commits to supporting it. If the vendor drops support they'll still do what they can.
[12:59] <rbasak> Looks like OpenJDK 6 was in main until 12.04 LTS. Since 14.04 LTS it's OpenJDK 7 that's in main.
[13:00] <rbasak> However, it looks like OpenJDK 6 in universe in 14.04 has had a security update. These still happen in universe if somebody in the community puts the correctly backported fix forward.
[13:00] <nobody44> rbasak: so Canonical "guarantees" support for OpenJDK 7 in Ubuntu 14.04 LTS
[13:01] <nobody44> rbanffy: even if Oracle drops support for Oracle JDK 7...
[13:01] <rbanffy> rbasak, we need to talk about these namespace collisions...
[13:02] <RoyK> :P
[13:02] <rbasak> Both "guarantee" and "support" are weasel words that have no strict meaning in English, but essentially yes - they'll continue backporting fixes as possible even if upstream drops support. But if nobody knows of a vulnerability then it won't get fixed, just the same as any other package.
[13:02] <Odd_Bloke> from canonical.maas import rbanffy
[13:02] <rbasak> rbanffy: :-/
[13:03] <rbasak> (vendor support or no)
[13:03] <nobody44> rbasak: ok, thank you for your help
[13:18] <haithar> If supporting this Squid fix doesn't work out, what'd you recommend, going for 12 LTS or installing the latest stable Squid on 14 LTS and manually monitor+upgrade it every time? Or is there another way?
[13:19] <pmatulis> haithar: how many servers are you talking about?
[13:19] <haithar> 10+
[13:19] <pmatulis> haithar: i would just install 12.04 LTS
[13:20] <rbasak> pmatulis: can haithar buy UA and have Canonical sort this out for him? I wasn't really sure.
[13:20] <rbasak> (he was asking about how he could spend money to fix this)
[13:22] <pmatulis> UA should not be seen as a bug-fixing service.  things can get escalated to an engineering team and get fixed, sometimes via PPA until the fix is in the archive, but they can also be rejected
[13:24] <haithar> please define:PPA (Pay Per Annum?)
[13:25] <RoyK> !ppa
[13:25] <haithar> wow ok:)
[13:26] <haithar> Thanks for the info. Indeed UA looks more like a subscription for general support and I also haven't found something there that'd suggest it's a way to push a regression through. Thanks for the confirmation.
[13:26] <pmatulis> but a UA PPA can be supported, or unsupported
[13:27] <rbasak> pmatulis: OK, thanks. I didn't really understand before. So we don't really have a solution for users with valid bugs who want to pay for them to be fixed?
[13:27] <rbasak> I wish we did have a good answer for that.
[13:51] <pmatulis> rbasak: again, we fix bugs, but there is no guarantee.  UA is not a mercenary/bounty service.  it is an enterprise-level support service
[13:52] <Odd_Bloke> rbasak: There are certainly consultancies which will do that.
[13:56] <Quoexl> EHLO
[14:08] <haithar> Any idea how can I find someone to do that? (Apart from googling of course.) Any directories, wiki pages listing people/companies open to do paid support?
[14:09] <Quoexl> I'm sorry I missed what you are trying to do
[14:10] <haithar> Ah sorry. It's about finding someone who could push https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1336742 this though to trusty.
[14:10] <haithar> s/though/trough/
[14:11] <Quoexl> I'm terribly sorry but squid and me have had problems since dapper
[14:16] <Quoexl> know anything about videowhisper conference?
[16:10] <fidothe> hey there. We're booting Ubuntu instances in EC2, from the Ubuntu Cloud AMI. cloud-init sets the main APT repos to be S3 mirrors for the region / zone (i.e. eu-central-1a), but leaves security at security.ubuntu.com. Is there any problem with using the S3 mirror for this too? (we've been seeing DL speed from security.ubuntu.com < 400kbps all day, which is
[16:10] <fidothe> adding minutes to boot-and-bootstrap times...)
[16:28] <rbasak> fidothe: using security.ubuntu.com minimises delays
[16:28] <rbasak> Otherwise you might be waiting a while until your mirror picks up the most recent security updates.
[16:29] <rbasak> However, I believe that every security update is pushed to -updates too, although it's probably worth checking with a security team member on that in #ubuntu-hardened.
[16:29] <fidothe> rbasak: yeah, but these are Canonical-run mirrors, so presumably more reliably synced?
[16:29] <rbasak> Presumably. Do they mirror the security pocket?
[16:29] <rbasak> For security issues though, it might be better to not assume anything, and go straight to the source.
[16:29] <fidothe> rbasak: AFAICT (i.e. I can get the Release file just fine)
[16:30] <fidothe> rbasak: apt-get update was taking > 10 minutes
[16:30] <rbasak> So it sounds like it'll work. But unless someone says otherwise I wouldn't recommend it.
[16:30] <fidothe> which is long enough for booting instances to be culled by health checks...
[16:31] <rbasak> Maybe check out and fix why security.ubuntu.com is being slow? (Not necessarily your end, but it should be fixed)
[16:31] <rbasak> Rather than a workaround which gives you worse security (or at the risk of a mirror issue giving you a security issue)
[16:32] <Daviey> Security updates hit -updates aswell, but there is a window between when it hits s.u.c to the mirror you are using.  Your primary mirror should be ordered first, so if the update is there - you should get the prioritized full speed mirror
[16:34] <Daviey> Check what is causing the delay, is it just downloading the indexes (apt-get update) or are you pulling down kernels or similar from s.u.c
[17:11] <fidothe> Daviey / rbasak: it was just pulling down the indexes
[17:12] <fidothe> And the #ubuntu-hardened tip is a good one, thanks
[17:20] <mgagne> I would like to know when Ubuntu switched from qemu-kvm source tree to qemu. I found conflicting info
[17:20] <mgagne> in README.Debian, it's since 14.04: http://launchpadlibrarian.net/186695491/qemu_2.0.0%2Bdfsg-2ubuntu1.5_2.0.0%2Bdfsg-2ubuntu1.6.diff.gz
[17:20] <mgagne> According to wiki, it's since 12.10: https://wiki.ubuntu.com/QemuPTMigration
[17:21] <RoyK> out of curiosity, what's the big difference?
[17:21] <mgagne> one is that machine types from qemu-kvm are not compatible with the ones found in qemu. And it matters a lot if you perform a live migration.
[17:22] <rbasak> hallyn might be able to help ^^
[17:22] <RoyK> mgagne: qemu is the better?
[17:23] <mgagne> RoyK: it's the new source. previous one looks to be a fork or something. but tbh, I don't care that much as long as I can perform my live migration =)
[17:24] <hallyn> rbasak: https://wiki.ubuntu.com/QemuPTMigration
[17:24] <RoyK> mgagne: do you have something setup to autostart VMs if a host in the cluster goes down?
[17:24] <RoyK> mgagne: and btw, what sort of clustering/storage do you use for this?
[17:24] <mgagne> RoyK: we are using openstack
[17:24] <RoyK> ok
[17:25] <mgagne> RoyK: the original issue is: I can't live migrate instances from QEMU 1.5 to QEMU 2.0.
[17:25] <RoyK> ok
[17:26] <mgagne> hallyn: which info source is right? the wiki or README.Debian?
[17:27]  * RoyK guesses README.Debian
[17:28] <mgagne> because the wiki mentions the "incoming_assume_qemukvm" config which in fact got renamed before packaging for "allow_incoming_qemukvm"
[17:46] <mgagne> I opened a bug: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1425619
[19:02] <Zeelot3k> good morning! this seems like a more accurate place for my server questions :)
[19:02] <Zeelot3k> can anyone here tell me (in an upstart script) when I should be using `start-stop-daemon`? I don't see what it provides over a simple `exec`. doesn't upstart already monitor and manage my process for me? so what does start-stop-daemon do on top of that?
[19:11] <sarnold> Zeelot3k: I suspect you don't need start-stop-daemon in upstart configurations; if you see it used, it might have just been because it was easier to copy-and-paste it from an old init script that used it..
[19:14] <Zeelot3k> sarnold: I see. The only reason I can find so far is if I need to run different parts of the init script as root while changing user for the main process. And I also need to be able to generate a pid file which upstart does not do for me (from what I can tell)
[19:15] <Zeelot3k> so if I need those two things… valid to use `start-stop-daemon`?
[19:16] <teward> sarnold: is there documentation on creating systemd init scripts and such?  Like, what the structure is, etc.
[19:16] <sarnold> Zeelot3k: do you strictly need the pid file? iirc upstart doesn't care about one, and most tools that relied upon them are slightly racy anyway...
[19:16] <sarnold> teward: I think pitti put most of the work into this: https://wiki.ubuntu.com/SystemdForUpstartUsers
[19:17] <Zeelot3k> sarnold: I'm using Monit and I don't see a way to tell it to ask Upstart for the pid :(
[19:17] <sarnold> teward: 90% of what I know about systemd came from skimming that file :)
[19:17] <sarnold> Zeelot3k: ahhhhh
[19:17] <teward> sarnold: mmm, see, I mean from scratch - I mean, I could dig into, say, the nginx or apache or any other systemd init script but i'm lazy :P
[19:18] <Zeelot3k> any suggestions? I was a little disappointed by the Monit capabilities
[19:28] <Zeelot3k> sarnold: inspeqtor seems to support Upstart specifically: https://github.com/mperham/inspeqtor/wiki/INQ-Configuration
[19:30] <sarnold> Zeelot3k: there are some uses of $$ in the upstart cookbook, you might be able to printf $$ > /path/to/pidfile  or something similar: http://upstart.ubuntu.com/cookbook/
[19:34] <Zeelot3k> thanks will take a look
[19:34] <Zeelot3k> cookbook site isn't loading heh but I'll check back later
[19:37] <sarnold> Zeelot3k: dang, I waited until it loaded for me before pasting the url. (it was being rebooted when I first wanted it, heh)
[19:37] <Zeelot3k> hehe it finally came back
[19:37] <Zeelot3k> I think I want to fix the monitoring tool before hacking things into my init scripts
[19:38] <Zeelot3k> upstart already knows the pid so there isn't a real reason for me to write pid files
[20:31] <mamuskus> Hi
[20:33] <pmatulis> hi
[22:14] <thunder1> hello
[22:17] <teward> hello
[22:18] <thunder1> teward: what is the expected operation of the known_hosts file?
[22:19] <thunder1> is it similar to a hash file where it gives the url then the hash? I see no url in the file.
[22:20] <teward> thunder1: you mean known_hosts inside the .ssh folder in a home dir?
[22:21] <teward> thunder1: the answer on http://security.stackexchange.com/questions/20706/what-is-the-difference-between-authorized-key-and-known-host-file-for-ssh gives a nice description of what known_hosts does (see Server Authentication section of the answer)
[22:21] <teward> the accepted answer there*
[22:22] <teward> somewhat in depth, but a decent one
[22:22] <thunder1> teward: known_hosts inside the .ssh folder in a home dir
[22:23] <teward> thunder1: that's explained in the link i just posted
[22:23] <teward> the accepted answer on there, anyways
[22:23] <thunder1> Not big on stackexchange
[22:24] <teward> thunder1: well then you're out of luck - those explanations are accurate - to summarize, known_hosts stores the public key fingerprints of the remote SSH servers
[22:24] <teward> ideally you'd check the one you see against known ones, but...
[22:24] <teward> if you don't know, then if the remote fingerprint changes at any time it'll deny the connection and throw a huge warning
[22:24] <teward> about checking the remote SSH host legitimacy
[22:26] <thunder1> teward: yes I get the usage of it but when looking at it why doesn't it have a hostname/url in the file?
[22:27] <squisher> thunder1, it is hashed for privacy reasons
[22:27] <teward> ^ that
[22:27] <thunder1> squisher: that sounds like an addition the usual ssh shows the host
[22:28] <thunder1> squisher: it is an answer to what I've asked, very well squisher
[22:29] <thunder1> Is ubuntu14 backwards compatible?
[22:29] <Prezident> yes but not recommend it
[22:29] <Prezident> So i would say no
[22:30] <Prezident> Why btw?
[22:30] <thunder1> Is there any plans on using 14 as the distribution server?
[22:30] <Prezident> Rather play with kernel then if something is missed
[22:30] <thunder1> If the distribution server runs say ubuntu 6, 9 or 10 why is 14 reccomended for others?
[22:31] <thunder1> Something looks fishy there.
[22:33] <thunder1> If it were really so important for security the distribution server could also need that security.
[22:34] <thunder1> milsim
[22:34] <thunder1> put your hand on the glass
[22:35] <thunder1> What is bug #1?
[22:37] <thunder1> Feel free to give hypothetical answers for that.
[22:37] <thunder1> The recommending 14 question.
[22:38] <thunder1> Simulate a best case for that recommending 14.
[22:40] <thunder1> Prepend it with a disclaimer so you don't have to accept fault.
[22:41] <thunder1> go on
[22:43] <thunder1> You don't have to ascribe to being one with the author of that nonsense.
[22:47] <thunder1> If 14 is really so much better I want to see the distribution server running 14.
[22:48] <thunder1> ok?
[22:49] <thunder1> How does that work saying don't use 12 it is insecure unsupported , download 14 from ubuntu 8.
[23:33] <Valduare> hey guys… got something odd here.. one of my servers wont update   keeps trying to use ipv6 addresses it seems...
[23:34] <rbasak> Is your server using ipv6 addresses that actually don't route?