[00:05] <EmilienM> jamespage, coreycb: would it be possible to have Rally ( https://launchpad.net/ubuntu/+source/rally ) into Trusty?
[00:16] <sarnold> lost1nfound: investigate kexec/kdump, that might work in aws..
[01:21] <[Mew2]> is it possible to forward incoming connections on port 80 to another port?
[01:21] <[Mew2]> or i must open port 80 to do this
[01:22] <lost1nfound> sarnold: thanks! i configured kdump per https://help.ubuntu.com/stable/serverguide/kernel-crash-dump.html on 4/10 machines so hopefully i can get some good debugging info sometime later today when one crashes
[01:23] <lost1nfound> and then i guess i should file a bug report with that data?
[01:23] <sarnold> lost1nfound: sweet! yeah, that's probably the next step
[01:24] <sarnold> [Mew2]: you could probably achieve the same thing using iptables NAT portfowarding, but that's not exactly trivial
[01:25] <lost1nfound> awesome, thanks for the help, will do
[01:25] <sarnold> good luck lost1nfound :)
[01:25] <lost1nfound> thanks :)
[01:26] <sarnold> [Mew2]: (note that's a guess on my part that iptables NAT can do it -- iptables can be made to do nearly anything, and I do know that you can do port forwarding / manipulating as part of NAT processing.. doing it onthe same IP might be different though.)
[01:31] <[Mew2]> ok thanks sarnold
[08:48] <imincik> Hi all, does anybody knows when we can expect Vagrant images for Xenial on https://cloud-images.ubuntu.com/vagrant/ ?
[10:10] <xmj> moin!
[10:11] <xmj> I just saw one of our engineers reporting that machines were 'stuck' on “Stopping System V runlevel compatibility”, when connecting a terminal to them
[10:11] <xmj> where 'stuck' means that they perform as expected, but to get to a login prompt you'd have to CTRL ALT F1.
[10:11] <xmj> Anyone else seen this on 12.04.1?
[11:11] <[Mew2]> sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 6000 <-- is this the correct command to forward all traffic from port 80 to 6000?
[11:15] <jamespage> smb, got to the bottom of that jdb process issue i had prior to xmas - looks like the cgmanager backport to trusty is causing problems when the mount happens prior to cgmanager starting
[11:18] <jamespage> indeed I'm running with the one in updates, not backports...
[11:18]  * jamespage sighs
[11:21] <halvors1> Hi. Ubuntu 16.04 Beta 1 ships with Apache 2.4.17. Isn't it supposed to include the mod_http2 module?
[11:21] <halvors1> Or is it in a separate package?
[11:24] <rbasak> halvors1: on advice from the security team, we are not building http2 support deliberately since 2.4.17-1ubuntu1
[11:24] <rbasak> mdeslaur, sarnold: do we have a release note bug for the http2 drop, OOI? Shall I create one?
[11:24] <halvors1> rbask: Is there a security risk?
[11:26] <rbasak> halvors1: that's a question for the security team that I can't really answer, sorry. All I know is that they don't want it for security reasons. Could be LTS-length supportability rather than an immediate risk.
[11:26] <rbasak> I accept that we need to communicate their real reason, so I'll try and make sure that there is something in the release notes with an explanation at release time.
[11:41] <halvors1> You say the LTS release of ubuntu won't include mod_http2 when it is released?
[12:03] <mdeslaur> rbasak: I don't think it was a security concern, it's the fact that it's marked "experimental", and libnghttp2 needs a MIR security audit
[12:04] <mdeslaur> rbasak: if you want to support the code, including possibly doing a substantial backport if it changes, I don't have an issue
[12:18] <rbasak> mdeslaur: ah, my misunderstanding, thanks. Is that the same reason as nginx? I don't see a libnghttp2-dev build-dep in nginx in Debian.
[12:23] <mdeslaur> rbasak: I have no idea why it was disabled in nginx, I wasn't part of that discussion, sorry
[12:24] <mdeslaur> we definitely do need to ship http2 in the lts release at some point, whether that's shipping "experimental" code right away, or releasing an SRU of a backport of whatever is considered stable at some time in the future is up to the server team to decide, IMHO
[12:25] <mdeslaur> rbasak: libnghttp2 is all new code, and even got a CVE this week, so if we need it in main, now would be the time to do the MIR paperwork
[12:25] <rbasak> teward: ^ who were you working with on that, please?
[12:26] <rbasak> mdeslaur: noted, thanks.
[12:57] <teward> mdeslaur: rbasak: sarnold
[12:57] <teward> mdeslaur: I asked sarnold whether the Security team had any concerns with the 1.9.6 merge, sarnold said to disable HTTP/2
[12:57] <teward> boooo, evil IRC client double post >.<
[12:57]  * teward kicks hexchat out the window
[12:57] <mdeslaur> teward: and nginx doesn't require libnghttp2? it has its own implementation?
[12:58] <teward> mdeslaur: AFAIK yes, I've not had to pull that in as a build dep to make HTTP/2 work
[12:58] <teward> tested with 1.9.6 in a Xenial VM too just to make sure, with three SSL / HTTPS checker scripts to confirm h2 was a valid proto offering
[12:58] <mdeslaur> ok, perhaps it's worth discussing all 4 of us once sarnold is online
[12:59] <teward> ok
[12:59] <teward> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1510096/comments/2 may be relevant
[12:59] <teward> as I asked sarnold to post to the merge bug so there's at least a paper trail
[13:00] <teward> perfect timing for the pings, too, I was about to put a 1.9.9 update into Xenial since Debian's dragging their heels
[13:00] <teward> so i'll put that on hold
[13:01] <mdeslaur> ok, lets discuss this again with sarnold
[13:01] <rbasak> acvk
[13:01] <rbasak> ack
[13:01] <teward> ack
[13:02] <teward> mdeslaur: what's missing here is that sarnold and I discussed this as well, i think the idea was that once the Sec team was OK'd with the 'real world exposure' to turn it back on
[13:02] <teward> either as SRU or before release date
[13:03] <teward> though, i will say that with SPDY now *gone* in 1.9.5+, HTTP/2's the only thing that would replace it
[13:03] <mdeslaur> having spdy gone is a big plus
[13:03] <teward> +1 there
[13:09] <teward> mdeslaur: may want to wait for the reply to my question to the nginx-devel mailing list
[13:09] <teward> i've pushed the question on HTTP/2 up there to be *certain*
[13:09] <teward> when anyone from @nginx.org replies then that's pretty much an authoritative answer, but AFAIK it's their own implementation that has built and worked without libnghttp2
[13:10] <teward> http://mailman.nginx.org/pipermail/nginx-devel/2016-January/007751.html is the base message, please let me know if I missed anything
[13:19] <teward> actually
[13:21] <teward> mdeslaur: rbasak: confirmed authoritative answer: what I thought I knew is correct - NGINX's HTTP/2 implementation is their own, and only has a dependency on OpenSSL 1.0.2+ with ALPN TLS extensions.   http://mailman.nginx.org/pipermail/nginx-devel/2016-January/007752.html
[13:21] <teward> mdeslaur: rbasak: so nginx won't need to require libnghttp2
[13:22] <teward> perhaps this is why sarnold wanted http/2 disabled for now, to let the nginx implementation get some 'real world' exposure for a while to rule out security risks?
[15:46] <teward> stupid question, but when's the next server team meeting
[15:52] <arges> teward: isn't it in 8 minutes?
[15:52] <arges> jgrimm: ^^^
[15:53] <jgrimm> arges, correct
[15:54] <genii> According to the fridge, 4pm ( I assume GMT)
[16:18] <teward> arges: unfortunately phone calls are evil
[16:18] <teward> rbanffy: ^
[16:18] <teward> erm
[16:18] <teward> rbasak: ^
[16:20] <rbasak> teward: ?
[16:22] <arges> teward: its an IRC meeting in #ubuntu-meeting going on right now
[16:23] <arges> rather it just eneddd
[16:39] <jge> Hey all, my server is notifing that it has 7 updates which are security updates but when I do apt-get update && apt-get upgrade, I only see 3 upgrades which have been held back
[16:39] <jge> where are the remaining 4?
[16:39] <jge> only main and security repos enabled
[16:49] <Sling> jge: and dist-upgrade ?
[16:56] <jge> Sling: that did it, but it installed regular updates too.. was that because the security updates needed them?
[16:56] <Sling> dist-upgrade installs all available upgrades
[16:56] <Sling> including kernel updates
[16:57] <jge> ahh, even if I only have main/security repos available?
[16:57] <jge> enabled*
[17:07] <yoink> jge usually it's because the packages listed with security updates also require new packages which aren't installed
[17:08] <yoink> jge if you enable the "mail" option in the unattended-upgrades config, you'll get a detailed email about which packages were listed as security-updates were held back.
[17:09] <yoink> I usually mannual 'apt-get install' those packages and will be prompted for the extra dependencies that aren't installed.
[17:10] <yoink> for example this recently happened with the mariadb security updates on 14.04
[19:02] <nacc> rbasak: quick q on logwatch ... I noticed that one of the remaining changes was moving libsys-cpu-perl from Recommends to Suggests (your change in vivid/7.4.1-2ubuntu2). Debian added libsys-meminfo-perl to Recommends in the meanwhile. The change is trivial to move libsys-meminfo-perl also to Suggests in control, but can i just put that in the same line in the remaining changes section as the libsys-cpu
[19:02] <nacc> -perl in teh changelog?
[19:09] <rbasak> nacc: if it's a new change, then it isn't a remaining change, so it should be in a separate top-level bullet point below rather than as a subitem of the "remaining changes" bullet.
[19:10] <rbasak> nacc: note that we usually move things from recommends to suggests in an Ubuntu delta because the package is in main and the recommend is not, which isn't allowed. A suggests is allowed in that case though. So libsys-meminfo-perl does need to be moved if it is universe, but not if it is main.
[19:13] <nacc> rbasak: ok, i'll verify that, thanks
[19:14] <nacc> rbasak: yeah, i understand the point about remaining vs. not; but was just wondering as logically it's the "same" change. So in a future merge, we could combine them to one line?
[19:43] <rbasak> nacc: that's right. In a future merge we'd combine them to the same line, but for the first merge that includes it, we call it out.
[19:44] <nacc> rbasak: ok, and for tracking this, should I open a new LP bug? similar to LP 1387817
[19:51] <rbasak> nacc: if we want a bug to track this, we usually have one that is entitled "Please merge logwatch 7.4.1+svn20150731rev294-1 from Debian" or similar with a tag "upgrade-software-version". And the changelog should auto-close that merge bug.
[19:52] <rbasak> nacc: assign yourself to the bug too please. That helps avoid someone else working on it concurrently.
[19:52] <rbasak> (though that sort of thing still does happen)
[20:03] <nacc> rbasak: ok, will do
[20:03] <nacc> rbasak: still working through the steps from the wiki, etc, but working on it
[20:42] <nacc> rbasak: ok, does this look reasonable? still want to test, etc, but: https://launchpad.net/~nacc/+archive/ubuntu/logwatch/+packages
[21:19] <jak2000> how to check if port 80 is opened?
[21:20] <jak2000> and wich service use port 80
[21:20] <tarpman> nc -v 1.2.3.4 80
[21:20] <tarpman> netstat -ltpn | grep 80
[21:20] <jak2000> 1.2.3.4 is the local ip?
[21:21] <tarpman> is whatever ip you're wondering about port 80 on
[21:23] <jak2000> http://pastie.org/10672122
[21:27] <tarpman> -p only works if you run it as root
[21:28] <jak2000> ahh
[21:28] <jak2000> 1050/nginx
[21:28] <tarpman> sounds right
[21:30] <jak2000> tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1050/nginx
[21:30] <jak2000> how to disable ?
[21:30] <jak2000> killing?
[21:30] <tarpman> if it's nginx from apt -> service nginx stop
[21:30] <sarnold> probably service nginx stop or something similar
[21:31] <tarpman> to disable it permanently -> systemctl disable nginx
[21:31]  * tarpman wonders whether update-rc.d ever ended up learning about systemd
[21:32] <tarpman> oh, it did! :)
[21:32] <jak2000> systemctl: command not found
[21:32] <jak2000> cant disable permanently
[21:32] <tarpman> oh, are you running a pre-systemd release?
[21:33] <tarpman> then echo manual > /etc/init/nginx.override
[21:33] <tarpman> (IIRC)
[21:33] <tarpman> been a while since I touched upstart, someone had better confirm that :)
[21:33] <jak2000> sudo echo manual > /etc/init/nginx.override
[21:33] <jak2000> -bash: /etc/init/nginx.override: Permission denied
[21:33] <tarpman> well, yeah
[21:34] <tarpman> echo manual | sudo tee /etc/init/nginx.override
[21:34] <tarpman> would work
[21:34] <bearface> update-rc.d nginx disable
[21:34] <sarnold> sudo and echo .. >  don't combine :)
[21:34] <tarpman> bearface: does that handle upstart?
[21:35] <jak2000> echo manual | sudo tee /etc/init/nginx.override
[21:35] <jak2000> say manual
[21:35] <tarpman> yes, that's what tee does.
[21:35] <jak2000> done
[21:35] <jak2000> update-rc.d nginx disable
[21:35] <tarpman> jak2000: please read manpages of commands if you don't know what they do.
[21:38] <jak2000> tarpman tahnks
[21:38] <jak2000> and yes
[21:38] <jak2000> reading
[21:39] <bearface> tarpman: err, fair point, not sure
[21:40] <jrwren> pretty sure it does.
[21:41] <jrwren> err, nope.