[00:05] jamespage, coreycb: would it be possible to have Rally ( https://launchpad.net/ubuntu/+source/rally ) into Trusty? [00:16] 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] 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] and then i guess i should file a bug report with that data? [01:23] lost1nfound: sweet! yeah, that's probably the next step [01:24] [Mew2]: you could probably achieve the same thing using iptables NAT portfowarding, but that's not exactly trivial [01:25] awesome, thanks for the help, will do [01:25] good luck lost1nfound :) [01:25] thanks :) [01:26] [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 === rbanffy_ is now known as rbanffy === Guest62646 is now known as IdleOne === Lcawte|Away is now known as Lcawte === Lcawte is now known as Lcawte|Away [08:48] Hi all, does anybody knows when we can expect Vagrant images for Xenial on https://cloud-images.ubuntu.com/vagrant/ ? [10:10] moin! [10:11] 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] where 'stuck' means that they perform as expected, but to get to a login prompt you'd have to CTRL ALT F1. [10:11] Anyone else seen this on 12.04.1? === kickinz1_ is now known as kickinz1 [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] 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] indeed I'm running with the one in updates, not backports... [11:18] * jamespage sighs [11:21] Hi. Ubuntu 16.04 Beta 1 ships with Apache 2.4.17. Isn't it supposed to include the mod_http2 module? [11:21] Or is it in a separate package? [11:24] halvors1: on advice from the security team, we are not building http2 support deliberately since 2.4.17-1ubuntu1 [11:24] mdeslaur, sarnold: do we have a release note bug for the http2 drop, OOI? Shall I create one? [11:24] rbask: Is there a security risk? [11:26] 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] 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. === m1dnight1 is now known as m1dnight_ [11:41] You say the LTS release of ubuntu won't include mod_http2 when it is released? [12:03] 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] 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] 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] rbasak: I have no idea why it was disabled in nginx, I wasn't part of that discussion, sorry [12:24] 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] 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] teward: ^ who were you working with on that, please? [12:26] mdeslaur: noted, thanks. [12:57] mdeslaur: rbasak: sarnold [12:57] 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] boooo, evil IRC client double post >.< [12:57] * teward kicks hexchat out the window [12:57] teward: and nginx doesn't require libnghttp2? it has its own implementation? [12:58] mdeslaur: AFAIK yes, I've not had to pull that in as a build dep to make HTTP/2 work [12:58] 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] ok, perhaps it's worth discussing all 4 of us once sarnold is online [12:59] ok [12:59] https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1510096/comments/2 may be relevant [12:59] Launchpad bug 1510096 in nginx (Ubuntu) "Please merge 1.9.6-2 (main) from Debian Unstable (main)" [Wishlist,Fix released] [12:59] as I asked sarnold to post to the merge bug so there's at least a paper trail [13:00] 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] so i'll put that on hold [13:01] ok, lets discuss this again with sarnold [13:01] acvk [13:01] ack [13:01] ack [13:02] 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] either as SRU or before release date [13:03] 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] having spdy gone is a big plus [13:03] +1 there [13:09] mdeslaur: may want to wait for the reply to my question to the nginx-devel mailing list [13:09] i've pushed the question on HTTP/2 up there to be *certain* [13:09] 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] 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] actually [13:21] 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] mdeslaur: rbasak: so nginx won't need to require libnghttp2 [13:22] 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] stupid question, but when's the next server team meeting [15:52] teward: isn't it in 8 minutes? [15:52] jgrimm: ^^^ [15:53] arges, correct [15:54] According to the fridge, 4pm ( I assume GMT) [16:18] arges: unfortunately phone calls are evil [16:18] rbanffy: ^ [16:18] erm [16:18] rbasak: ^ [16:20] teward: ? [16:22] teward: its an IRC meeting in #ubuntu-meeting going on right now [16:23] rather it just eneddd [16:39] 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] where are the remaining 4? [16:39] only main and security repos enabled [16:49] jge: and dist-upgrade ? [16:56] Sling: that did it, but it installed regular updates too.. was that because the security updates needed them? [16:56] dist-upgrade installs all available upgrades [16:56] including kernel updates [16:57] ahh, even if I only have main/security repos available? [16:57] enabled* [17:07] jge usually it's because the packages listed with security updates also require new packages which aren't installed [17:08] 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] I usually mannual 'apt-get install' those packages and will be prompted for the extra dependencies that aren't installed. [17:10] for example this recently happened with the mariadb security updates on 14.04 === njalk_ is now known as njalk [19:02] 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] -perl in teh changelog? [19:09] 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] 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] rbasak: ok, i'll verify that, thanks [19:14] 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? === Lcawte|Away is now known as Lcawte === jdstrand_ is now known as jdstrand [19:43] 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] rbasak: ok, and for tracking this, should I open a new LP bug? similar to LP 1387817 [19:44] Launchpad bug 1387817 in logwatch (Ubuntu) "New Upstream Version 7.4.1" [Undecided,Fix released] https://launchpad.net/bugs/1387817 [19:51] 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] nacc: assign yourself to the bug too please. That helps avoid someone else working on it concurrently. [19:52] (though that sort of thing still does happen) [20:03] rbasak: ok, will do [20:03] rbasak: still working through the steps from the wiki, etc, but working on it [20:42] rbasak: ok, does this look reasonable? still want to test, etc, but: https://launchpad.net/~nacc/+archive/ubuntu/logwatch/+packages [21:19] how to check if port 80 is opened? [21:20] and wich service use port 80 [21:20] nc -v 1.2.3.4 80 [21:20] netstat -ltpn | grep 80 [21:20] 1.2.3.4 is the local ip? [21:21] is whatever ip you're wondering about port 80 on [21:23] http://pastie.org/10672122 [21:27] -p only works if you run it as root [21:28] ahh [21:28] 1050/nginx [21:28] sounds right [21:30] tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1050/nginx [21:30] how to disable ? [21:30] killing? [21:30] if it's nginx from apt -> service nginx stop [21:30] probably service nginx stop or something similar [21:31] to disable it permanently -> systemctl disable nginx [21:31] * tarpman wonders whether update-rc.d ever ended up learning about systemd [21:32] oh, it did! :) [21:32] systemctl: command not found [21:32] cant disable permanently [21:32] oh, are you running a pre-systemd release? [21:33] then echo manual > /etc/init/nginx.override [21:33] (IIRC) [21:33] been a while since I touched upstart, someone had better confirm that :) [21:33] sudo echo manual > /etc/init/nginx.override [21:33] -bash: /etc/init/nginx.override: Permission denied [21:33] well, yeah [21:34] echo manual | sudo tee /etc/init/nginx.override [21:34] would work [21:34] update-rc.d nginx disable [21:34] sudo and echo .. > don't combine :) [21:34] bearface: does that handle upstart? [21:35] echo manual | sudo tee /etc/init/nginx.override [21:35] say manual [21:35] yes, that's what tee does. [21:35] done [21:35] update-rc.d nginx disable [21:35] jak2000: please read manpages of commands if you don't know what they do. [21:38] tarpman tahnks [21:38] and yes [21:38] reading [21:39] tarpman: err, fair point, not sure [21:40] pretty sure it does. [21:41] err, nope. === Lcawte is now known as Lcawte|Away