[00:01] <RoyK> the graph at the bottom of https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/ tells me bpfilter is a wee bit faster ;)
[00:02] <trippeh_> until there is anything actually working, I woulnt place much trust in that graph.
[00:02] <RoyK> nah
[00:03] <RoyK> but it looks promising, though
[00:03] <trippeh_> also features (eg feature-parity) ends up slowing things down ;)
[00:04] <trippeh_> BPF also took quite a hit with Spectre
[00:04] <RoyK> heh
[00:04] <trippeh_> (of course that is hopefully temporary)
[00:05] <RoyK> bugs come and go
[00:05] <Hell-Razor> Hey fellas, quick question -- wastomcat removed from the server repos?
[00:05] <Hell-Razor> tomca7
[00:05] <RoyK> ,v wastomcat
[00:06]  * RoyK thought he was at #debian 
[00:06] <Hell-Razor> Sorry I dont know why I cant type tonight - was tomcat7 removed from the repos
[00:06] <Hell-Razor> RoyK its for school,
[00:06] <RoyK> !tomcat
[00:07] <trippeh_> Hell-Razor: seems to be available on Ubuntu 16.04
[00:08] <Hell-Razor> Ah maybe I am just running the wrong version
[00:08] <RoyK> seems tomcat8 is in 18.04
[00:08] <trippeh_> "wrong" as in newer Ubuntu versions only ship tomcat8
[00:09] <Hell-Razor> apt search tomcat brings up nothing
[00:09] <RoyK> Hell-Razor: have you enabled universe/multiverse?
[00:09] <RoyK> iirc there's a bug with those repos not being enabled after installation, only main
[00:10] <Hell-Razor> How would I do that?
[00:10] <RoyK> Hell-Razor: check /etc/apt/sources.list
[00:12] <Hell-Razor> Ill just reinstall. School wants tomcat7 installed. Were probably going to break whats patched in 8
[00:12] <Hell-Razor> install 16.04*
[00:12] <RoyK> no need to reinstall
[00:12] <RoyK> just find a repo
[00:13] <Hell-Razor> Will do
[00:42] <trippeh_> RoyK: I'm hoping bpfilter will make my skill of hand optimizing iptables rulesets obsolete
[00:47] <RoyK> trippeh_: hehe
[05:55] <lordievader> Good morning
[11:28] <zioproto> hello, I have a problem with git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron today, it is super slow
[11:28] <zioproto> is there any known problem in the infrastructure ?
[11:29] <zioproto> pinging coreycb and jamespage ;)
[11:30] <zioproto> I am chasing a Neutron Ocata bug... trying to build Xenial packages today. If I fix it I will send a merge request on LP
[11:30] <zioproto> The bug is already fixed back to Pike. I am talking about https://bugs.launchpad.net/neutron/+bug/1628455
[11:34] <zioproto> it will take a while like this:
[11:35] <zioproto> https://www.irccloud.com/pastebin/4kGmkJfy/
[12:14] <zioproto> is it normal that commands like:
[12:14] <zioproto> debcheckout --git-track='*' neutron
[12:15] <zioproto> dont work anymore ? I even upgraded to Bionic my building server because I thought that was the problem
[13:22] <zioproto> coreycb: are you around ? I am having an hard time with pristine-tar and neutron_10.0.7.orig.tar.gz
[13:26] <jamespage> zioproto: hey - not sure let me look
[13:27] <zioproto> so it looks like a generic problem with pristine-tar and xdelta3
[13:27] <zioproto> I moved to bionic
[13:27] <zioproto> I should correct versions for pristine-tar tar and xdelta3
[13:28] <zioproto> I have tar 1.29b-2 pristine-tar 1.42
[13:28] <zioproto> xdelta3 3.0.11-dfsg-1ubuntu1
[13:29] <zioproto> https://www.irccloud.com/pastebin/1X9w6Sbk/
[13:29] <zioproto> I am actually not able to checkout any tarball
[13:29] <zioproto> I tried with master
[13:29] <zioproto> I have the same problem. Now I am working in branch stable/ocata
[13:30] <zioproto> I cloned the neutron repo from git://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/neutron
[13:30] <zioproto> steps to reproduce:
[13:30] <zioproto> pristine-tar -v checkout neutron_10.0.7.orig.tar.gz
[13:33] <zioproto> jamespage: when you have time tell me if you can reproduce the bug
[13:33] <jamespage> zioproto: ok - still in my pj's atm
[13:33] <zioproto> I was able to download the file with 'pull-uca-source neutron ocata'
[13:33] <jamespage> will take a look later
[13:34] <zioproto> OK, I found a workaround, but this should be checked if it is a bug or not, Thanks
[13:34] <jamespage> zioproto: not sure if its my hotel wifi connection or not but a git pull is slow
[13:35] <zioproto> jamespage: yes, read the IRC history. Today is damn slow, I was complaining about it earlier
[13:36] <jamespage> zioproto: I'm not able to reproduce your pristine-tar/checkout issue for 10.0.7
[13:36] <jamespage> gbp buildpackage -S -d dtrt
[13:37] <zioproto> are you on Bionic ?
[13:37] <zioproto> may I ask you the versions of your pristine-tar tool ?
[13:37] <jamespage> zioproto: cosmic - I can check on bionic as well
[13:37] <jamespage> 1.44 of pristine-tar
[13:38] <zioproto> I have 1.42
[13:39] <zioproto> could be that, but Bionic ships 1.42
[13:39] <jamespage> I doubt it
[13:39] <jamespage> alot of other people would be shouting as well!
[13:40] <zioproto> I will try to upgrade pristine-tar later
[13:41] <zioproto> for now I fixed it with
[13:41] <zioproto> gbp buildpackage -S -us -uc --git-tarball-dir=../sandbox/
[13:41] <zioproto> and downloading the file with the command: pull-uca-source neutron ocata
[13:41] <jamespage> zioproto: git slowness is a know issue - canonical-is investigating
[13:55] <Ussat> question about an upgrade from 16.04LTS --> 18.04LTS   http://pastebin.centos.org/1787581/
[14:00] <JanC> Ussat: yes, it disables third part repositories during upgrade (because otherwise it would be unpredictable)
[14:01] <JanC> third party*
[14:02] <JanC> you can re-enable it afterwards; possibly check if the same or another repository is needed for 16.04 & 18.04 (in this case it might be the same?)
[14:03] <JanC> you can leave the .distUpgrade file, or you can remove it, doesn't really matter AFAIK...
[14:05] <Ussat> Thanks
[14:12] <zioproto> jamespage: I manage to fixed. It was the tar package that had a problem
[14:12] <zioproto> Unpacking tar (1.30+dfsg-2) over (1.29b-2) ...
[14:13] <zioproto> I installed the cosmic package manually over the bionic package
[14:13] <zioproto> and now pristine-tar works
[14:13] <zioproto> I also upgraded pristine-tar from cosmic, but that alone did not fix it
[14:13] <zioproto> should I fill a bug somewhere ?
[14:13] <zioproto> can anyone reproduce this ?
[14:22] <Conqueror> Hello, I'm try to do basic PoC for stable and robust openstack environment. I can't decide the exact version of the openstack and ubuntu server. Which the best selection Quens + 18.04.1 or Pike + 16.04.05 and why? What is important to me is to build a solid, stable, robust Openstack structure. Thanks in advance.
[14:24] <Conqueror> Or something else version recommendation
[14:27] <zioproto> btw I found the problem I had with newtron
[14:27] <zioproto> btw I found the problem I had with neutron
[14:27] <zioproto> I dont need a new package
[14:27] <zioproto> I need to upgrade python-ryu
[14:27] <zioproto> so I will not send any MR
[14:57] <ahasenack> hm, I have a case (https://bugzilla.samba.org/show_bug.cgi?id=13607) where winbind needs to be sent a HUP after network changes
[14:57] <ahasenack> would this be a good candidate for a networkd-dispatcher hook/script?
[14:57] <ahasenack> until the upstream fix comes in, that is
[14:57] <ahasenack> it feels like so
[14:57]  * ahasenack looks for examples
[14:58] <ahasenack> cpaelzer: have you written a dispatcher hook?
[15:04] <cpaelzer> ahasenack: yes
[15:05] <cpaelzer> wait I'll send you a link ahasenack
[15:06] <ahasenack> thanks
[15:07] <cpaelzer> ahasenack: this should lead you https://git.tuxfamily.org/chrony/chrony.git/commit/examples/chrony.nm-dispatcher?id=8cbc68f28f96d48a7ee128fa91731ca02a598913
[15:07] <cpaelzer> I reused the nm-dispatcher hook they already had and just made it ready to also work for networkd-dispatcher
[15:08] <cpaelzer> on top of that  man page and https://github.com/craftyguy/networkd-dispatcher to check details
[15:08] <ahasenack> ok
[15:09] <ahasenack> I created a simple one to HUP winbind, placed it in routable.d, and it worked
[15:09] <ahasenack> but I guess I can't rely on networkd-dispatcher being installed
[15:09] <ahasenack> it's "important"
[15:10] <ahasenack> and not worth adding dep to winbind since the bug will eventually be fixed upstream, and HUP won't be needed
[15:10] <ahasenack> but I can suggest it as a workaround for this bug reporter
[15:16] <jamespage> zioproto: ack - what was the issue with ryu? do we need todo a fix there more generally?
[15:16] <zioproto> no it was my fault
[15:16] <zioproto> I did an upgrade Newton to Ocata
[15:16] <zioproto> and I upgraded with apt just the neutron packages
[15:16] <zioproto> and my script did not include python-ryu
[15:17] <zioproto> ok, I am not sure if the apt package for neutron-common could be actually improve to pull the updated version of python-ryu. I am not sure about this.
[15:17] <jamespage> zioproto: ah right - yes we generally test with a dist-upgrade with the new UCA pocket enabled
[15:17] <jamespage> zioproto: lets check the versions
[15:18] <jamespage> zioproto: there is no minimum version spec on ryu
[15:19] <jamespage> zioproto: so the versioning could be tightened up to force the upgrade
[15:19] <zioproto> jamespage: https://github.com/openstack/neutron/blob/stable/ocata/requirements.txt#L22
[15:19] <jamespage> yeah it needs 4.9 which is in the Ocata UCA
[15:19] <zioproto> exactly
[15:19] <zioproto> I mean
[15:19] <zioproto> I usually do dist-upgrade
[15:19] <jamespage> but not expressed in the pkging
[15:19] <zioproto> I am not sure if this is too much optimization or not
[15:20] <zioproto> but the neutron-common package will not work at all
[15:20] <zioproto> without the right ryu library
[15:20] <zioproto> when I figured it out I did dist-upgrade on everything
[15:20] <zioproto> and it worked
[15:20] <jamespage> yah it would
[15:21] <jamespage> but it would not hurt to version the dependency in the package if it won't work with earlier versions.
[15:21] <zioproto> OK. I am on a tight schedule. I am just 1 more week in this company and I have trying to push the Ocata upgrade as far as possible
[15:21] <zioproto> so I will leave to you guys this small packaging issue ;)
[15:22] <zioproto> I am trying to push :)
[15:22] <zioproto> I think the other issue is more wide
[15:22] <zioproto> the tar version that kills pristine-tar in Bionic
[15:22] <zioproto> I mean, more wide in terms of impacted people
[15:23] <jamespage> zioproto: I'm surprised that's not hit me before - I spent the whole of bionic development using those versions!
[15:23] <zioproto> I dont know how to check if there is a `tar` package update sitting in the queue for Bionic. Were you able to reproduce it ?
[15:24] <jamespage> zioproto: git lp performance should be better now
[15:24] <jamespage> zioproto: I was
[15:27] <zioproto> ah ok, so I writing the minimal steps to reproduce
[15:31] <zioproto> jamespage: here you go
[15:32] <zioproto> https://www.irccloud.com/pastebin/MDLMNX6g/
[15:32] <zioproto> this is really the minimal steps to reproduce
[15:33] <zioproto> jamespage: I dont see any bug listed here https://launchpad.net/tar
[15:33] <jamespage> zioproto: please raise one if you have time
[15:33] <zioproto> jamespage: where exactly ?
[15:33] <zioproto> I mean I dont see ANY bug. 0 bugs open for tar
[15:33] <jamespage> ubuntu-bug tar
[15:34] <jamespage> or pristine-tar infact
[15:34] <zioproto> well the bug is fixed updating the version of tar
[15:35] <jamespage> yes but bionic is still broken and installing cosmic packages in bionic is not really a solution
[15:35] <jamespage> i suspect its a version mismatch - pristine-tar is quite brittle
[15:37] <zioproto> https://bugs.launchpad.net/ubuntu/+source/tar/+bug/1791710
[15:37] <zioproto> I need to go offline soon. Thanks for your support ! ciao :)
[15:44] <jamespage> zioproto: added a task for pristine-tar - https://bugs.launchpad.net/ubuntu/+source/pristine-tar/+bug/1791710
[15:48] <Epx998> Aside from packages and the kernel, is there any difference between minor releases on a version of ubuntu?
[15:52] <RoyK> not really
[15:53] <RoyK> with 18.04.1, the "live" server installer got some fixes, though, meaning it's still quite useless IMHO
[15:56] <computa_mike> I'm just wondering : Has anyone tried setting up a PXE server on ubuntu 18.04?  I'm trying to follow some guides, but having issues with DNSMASQ.  Was wondering if I could configure systemd.resolved instead ?
[15:56] <Ussat> well, dis a 16.04 --> 18.04 on a XWIKI box, tomcat/xwiki shit all overitself, reverted
[15:57] <Ussat> \o/ snapshots
[15:57] <Ussat> HATE java based apps
[16:00] <computa_mike> i just found this page : https://www.hiroom2.com/2018/05/05/ubuntu-1804-tftpd-hpa-en/ so I'll try that
[16:04] <computa_mike> nope - that's only the FTP aspect - there's still the DHCP resolution aspect that I'm missing
[16:08] <RoyK> computa_mike: what're you trying to achive?
[16:10] <computa_mike> Hi @RoyK - I'm experimenting with setting up a PXE server - at the moment I have a couple of machines set up in VirtualBox.  My goal is to server a windows installation image from the server allowing me to re-build a windows machine from a network boot.  But to start with i was just looking at getting a basic PXE Server working
[16:11] <RoyK> computa_mike: then tftp is your friend, I guess
[16:11] <RoyK> not FTP
[16:12] <computa_mike> RoyK: sorry - the tftp part
[16:12] <computa_mike> RoyK: yeah - as far as I understand PXE is a combination of a DHCP resolution and tftp server
[16:13] <computa_mike> RoyK: I think that the newer 18.04 ubuntu has systemd resolver installed - which I think provides name resolution.  Whereas all the tutorials I've seen use dnsmasq - which has settings for tftproot etc
[16:14] <computa_mike> RoyK: I think there is a technique to remove systemd's resolver but I had a go a that an promptly broke the server (got an error about host resolution when using sudo).
[16:15] <RoyK> sorry - no idea
[16:15] <computa_mike> RoyK: No worries -
[16:24] <tomreyn> computa_mike: you could look into cobbler or foreman for a more manageable pxe setup.
[16:26] <tomreyn> i haven't actually done it, yet, but would expect pxe on 18.04 to work very siumilar to earlier releases.
[16:27] <tomreyn> after all, the pxe client is always the one your system(s) provide(s), and the components on the server side remain the same, too.
[16:29] <computa_mike> tomreyn: I did see cobbler while scouting around...the problem with 18.04 is as you alluded to - the DNS resolution provided by systemd I think screw up dnsmasq and I think the only option is to remove systemd resolutiuon, and install dnsmasq instead. Perhaps an appliance is more like what I need rather than trying to configure a new server to operate like that
[16:32] <tomreyn> so this resolver issue is on the pxe server, not the client?
[16:33] <computa_mike> tomreyn: yes
[16:36] <tomreyn> so it's "sudo systemctl disable systemd-resolved.service && sudo service systemd-resolved stop" + installing dnsmasq
[16:36] <Ussat> https://news.slashdot.org/story/18/09/09/0318228/engineering-firm-plans-to-tow-icebergs-from-antarctica-to-parched-dubai
[16:36] <Ussat> ooppsss wrong channel
[16:53] <Epx998> ive set pxe up on ubuntu and stuffs - if youre still needing help
[17:39] <sudormrf> would this be a good place to ask about an Apache SSL forced redirect (webserver running on ubuntu) that has caused the sub-pages to fail to load, or should I ask in #apache?
[17:39] <sudormrf> not really an ubuntu-server specific question, so I think #apache is probably better suited
[17:39] <sudormrf> but just asking
[17:42] <mason> Hey, I just realized that Bionic Beaver finally honors ctrl:nocaps. Woot.
[18:01] <sudormrf> well, since #apache is _dead_...I have a webserver setup that I am doing some testing on and I have enabled forced redirection to the SSL site. now when I do that I can get to the main page, but all subpages give me 404. this was not the case when the forced redirect was not in place. trying to understand what is happening. anyone in here able to offer any guidance? happy to post the enabled site config
[18:29] <sudormrf> sorted
[18:29] <sudormrf> buh bye
[19:54] <blackflow> mason: the what now?
[20:01] <mason> blackflow: /etc/defaults/keyboard, XKBOPTIONS="ctrl:nocaps"
[20:01] <mason> It's from Debian. It evidently works now in Ubuntu, where it didn't previously.
[20:03] <blackflow> oh.
[20:39] <jelly> that looks like an argument for setxkbmap -option ... so you can do it manually (or some other way) in any X session
[20:40] <mason> jelly: It works in consoles too.
[20:42] <jelly> I have no idea how that bit's achieved
[20:42] <mason> That's the magic. :)
[22:36] <jonfen> Does anyone have any recent instructions for configuring ubuntu 18.04 to use an active directory server for authentication?  I have only found outdated instructions so far.
[23:23] <keithzg[m]> Heh I get why apt would prompt for whether you want to overwrite /etc/postfix/makedefs.out or not, but it seems like it'd be very silly not to go with the distro-provided one when upgrading postfix, eh? ;)
[23:33] <RoyK> keithzg[m]: I don't remember the flag, but apt has flags for disabling prompts
[23:34] <RoyK> -f is one, but that's not really safe
[23:35] <tomreyn> i agree that prompting about overwriting this file doesn't seem to make a lot of sense. in fact i guess it shouldn't be in /etc in the first place.
[23:35] <keithzg[m]> RoyK: Yeah I'm more just saying that in this particular case, it doesn't really make any sense to do anything other than replace that file; it is, after all, the autogenerated details of how postfix was built, so the version of that file from the package being installed is basically by definition the one that you'd want!
[23:36] <keithzg[m]> tomreyn: Yeah it's a bit odd of a place for it
[23:37] <RoyK> keithzg[m]: I just don't remember that flag…
[23:37] <RoyK> keithzg[m]: there's one used for unattended upgrades to just ignore such prompts and *not* overwrite old files
[23:37] <tomreyn> if it's really the ubuntu postfix package placing the file there, then i'd say that's worth filing a bug.
[23:39] <tomreyn> hmm yes it does https://packages.ubuntu.com/bionic/amd64/postfix/filelist
[23:40] <keithzg[m]> tomreyn: True enough, and yeah `dpkg -S /etc/postfix/makedefs.out` confirms it's definitely owned by the postfix package.
[23:41] <tomreyn> https://launchpad.net/ubuntu/+source/postfix/+changelog#detail_postfix_3.1.4-1 : "* Install /etc/postfix/makedefs.out so users can see how the package was built"
[23:42] <tomreyn> adding the file was a good choice, i just think it should have been stored elsewhere
[23:46] <keithzg[m]> I suppose I should open the bug upstream with Debian, rather than on Launchpad
[23:55] <tomreyn> that, or both. ;)
[23:56] <keithzg[m]> Well, did https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1791853 at least