=== berglh_ is now known as berglh
=== ShaRose_ is now known as ShaRose
=== trekkie1701c_ is now known as trekkie1701c
=== StathisA_ is now known as StathisA
[07:39] <lordievader> Good morning
[08:23] <muhaha> xnox: ping
[08:25] <muhaha> I am still wrestling with resolv.conf, seems that if I delete/recreate /etc/resolv.conf, install libnss-resolve everything works ok, except snx binary, seems that this binary can not use libnss-resolve to look inside systemd-resolved and can not connect. Is there any fallback solution like replace whole systemd-resolved ?  Thanks
[08:28] <muhaha> can https://packages.ubuntu.com/bionic/resolvconf replace systemd-resolved ? like: systemctl stop systemd-resolved.service; systemctl disable systemd-resolved.service; systemctl mask systemd-resolved; apt install -y resolvconf
[08:28] <muhaha>  ?
[08:30] <muhaha> Seems that I need also dnsqmasq if stub resolver will be disabled, right?
[08:36] <andol> muhaha: resolvconf and systemd-resolved are not equivelent in any way. dnsmasq makes more sense as a possible replacement for systemd-resolved.
[08:37] <andol> muhaha: But really, reading some more of the backlog, what is your end goal, and what do you want to accomplish which you can't accomplish with your current setup?
[08:56] <Vic2> I see nothing that offers any information concerning virtual ethernet ... we have several IP addresses on the server and in the past created virtual ethernet for each ... how to accomplish now?
[08:56] <Vic2> Ubuntu 18.04 uses "netplan" instead of "ifupdown" to configure network devices / IP addresses. I've not found sufficient documentation to demonstrate how to configure multiple IPs such as we have on Ubuntu 14.04.  Can you offer a link or practical advice please?
[08:58] <Vic2> Sorry ... copy/pasted those two lines from another channel out of order.
[08:58] <andol> Vic2: You basicially provide a list of addresses. There is an example in netplan(5) man page which among other thing has such an example.
[09:34] <muhaha> andol: Iam using SNX binary (VPN client) which modifies /etc/resolv.conf. Problem is that SNX can not edit /etc/resolv.conf directly ( I found /etc/resolv.conf.bak created by SNX), so VPN connection is established (routes are ok), but nameservers and search-domains are not updated...
[09:35] <antal> muhaha: nothing can modify resolv.conf in 18.04, netplan rewrites it on every occasion
[09:35] <muhaha> Thats the problem
[09:36] <antal> yes I've been pulling my hair out because of netplan.... and everyone else does too based on last week's IRC activity, it's been a common topic
[09:37] <rbasak> I don't think netplan writes resolv.conf. Isn't that systemd-resolved?
[09:38] <antal> muhaha: did you edit your .yaml file correctly?
[09:38] <antal> if you did simply "netplan apply" should update those settings
[09:38] <muhaha> antal: I am using Vagrant, which uses some cloud-init.yml and another custom one
[09:39] <antal> I mean netplan's .yaml config
[09:39] <antal> you can declare namservers and search-domain there
[09:39] <muhaha> I would have to use some kind of wrapper and parsing method to populate netplans.yaml based on results from VPN client
[09:40] <antal> also, if you have multiple entires.... the trick is the /etc/nsswitch.conf file
[09:40] <rbasak> In a systemd-resolved world the VPN client should tell resolved the nameservers needed over the VPN
[09:41] <muhaha> yea, but its obsucre binary blob...
[09:41] <rbasak> It's pretty well documented
[09:41] <rbasak> Oh, you mean the VPN client?
[09:41] <muhaha> yes
[09:42] <rbasak> Seems to me that you're struggling with systemd/networkd/resolved though, rather than netplan
[09:42] <antal> netplan forces a lot of things sadly :/
[09:43] <muhaha> Its Checkpoint SNX (x86) client -> I can not modify its behavior. Its just setting /etc/resolv.conf directly..
[09:44] <muhaha> So unless systemd-resolved can not handle loading different /etc/resolv.conf .. i am screwed
[09:44] <rbasak> It does according to the manpage - if you make it a plain text file and not a symlink
[09:44] <rbasak> I don't know what else might interfere with that though
[09:44] <rbasak> resolvconf perhaps, which might need removing
[09:44] <rbasak> Then your VPN client can be in charge of maintaining /etc/resolv.conf.
[09:46] <antal> and then your netplan doesn't give a damn about resolv.conf and just rewrites it to default on every  occasion :P
[09:46] <muhaha> I am not using resolvconf
[09:48] <rbasak> File a bug against netplan then please
[09:48] <rbasak> Though a workaround is to not use netplan. Write your .network files for networkd directly
[09:49] <antal> sadly, this a feature
[09:50] <blackflow> netplan is just config abstraction using a backend - networkd or NM. it's so easy to just not use netplan if it doesn't work for your use case.
[09:50] <blackflow> personally, netplan and systemd-resolved are two things nuked out first on every new installation.
[09:50] <Ussat> I like netplan
[09:51] <rbasak> Unfortunately more complex use cases need something more advanced to manage things.
[09:51] <rbasak> DNS resolution is an example - on complex networks, it matters where your name queries are going
[09:52] <Ussat> rbasak, more advanced than netplan ?
[09:52] <Ussat> I know came in late
[09:52] <rbasak> More advanced than ifupdown
[09:52] <Ussat> ahh yes
[09:52] <rbasak> And resolvconf, etc
[09:52] <Ussat> I have been very happy since netplan hit
[09:56] <lordievader> > personally, netplan and systemd-resolved are two things nuked out first on every new installation.
[09:56] <lordievader> Same here, along with lx{c,d} and snapd.
[09:57] <rbasak> lxd is _really_ handy for finding reproducers and bugs
[09:57] <rbasak> (and on the production side, for testing deployment snippets)
[09:57] <muhaha> blackflow: So what is proper replacement for systemd-resolved? Not use netplan and .. ?
[09:58] <rbasak> You could install ifupdown. Don't configure netplan. Remove resolvconf (if it's installed). And manage /etc/resolv.conf yourself.
[09:58] <rbasak> Or with the nameservers stanza in ifupdown, though I don't remember how that works exactly. Does ifupdown edit /etc/resolv.conf in that case?
[09:59] <muhaha> dnsmasq can populate resolv.conf from dhcpclient?
[09:59] <rbasak> There are a ton of options available.
[09:59] <rbasak> Getting help will become harder the more obscure you go of course.
[10:00] <blackflow> muhaha: everyhting that existed before systemd-resolved. for starters, you don't need a local resolver at all. dhcp and resolvconf worked and still work. glibc can resolve just fine based on resolv.conf nameserver entries.
[10:00] <blackflow> muhaha: granted, systemd-resolved has additional APIs, based on dbus, but this chan and discussion being about servers, question is do you need dbus api activated resolving on your server.
[10:01] <blackflow> typically, you'll have static network setup and upstream resolver ips you stick into resolv.conf and then no need for dhcp, resolvconf, dnsmasq or anything like that.
[10:03] <muhaha> I just want to have backward compatibility from upstream (dhcp server) and also have an option to directly populate /etc/resolv.conf
[10:05] <blackflow> muhaha: "backward compatibility"?  either you do dhcp or static config. and the two are mutually exclusive wrt "directly populating /etc/resolv.conf"
[10:05] <blackflow> in that you either manually manage resolv.conf or via dhcp (including forcing nameserver entries via dhcp config)
[10:07] <muhaha> resolvconf is enough then, its symlinked after instalation, resolv.conf is populated from my VPN client, and has STUB listener entry... , problem can be if nameservers are used with round robin algo, cuz, first 2 nameservers are populated by VPN client, last one is localhost from systemd-resolved....
[10:10] <blackflow> too much trouble. if I needed VPN I'd run bind or unbound locally on that machine. much less hassle and much less things can go wrong.
[10:19] <muhaha> hm, anyway thanks
[14:00]  * ahasenack tries to remember what he did with brotli
[14:02] <ahasenack> rbasak: checking brotli
[14:03] <sdeziel> speaking of brotli, I wonder if having it in main would make it easier to have nginx support it
[14:04] <sdeziel> teward: ^ any idea?
[14:04] <ahasenack> sdeziel: there is a mir for it
[14:04] <sdeziel> ahasenack: yep, saw it :)
[14:04] <ahasenack> it looks like it's in main
[14:04] <sdeziel> it is
[14:04] <ahasenack> rmadison shows src in main, but binaries still in universe
[14:05] <sdeziel> was pulled in this AM with Firefox update
[14:06] <sdeziel> ahasenack: I think the src in main and binary in universe is because only libbrotli1 was needed in main
[14:06] <ahasenack> sdeziel: ah, sure
[14:10] <ahasenack> rbasak: I think I checked on brotli when an apache2 merge came along, as debian added it as a build-depends
[14:10] <ahasenack> but it's in main now
[14:11] <rbasak> OK, thanks
[14:17] <ahasenack> rbasak: for a non-merge git-ubuntu branch, how do I push the upload tag? Does git ubuntu tag --upload do the right thing?
[14:18] <rbasak> ahasenack: it should do the right thing, yes. That'll create the tag locally. Then you can check and push the tag to pkg.
[14:18] <ahasenack> ok
[14:19] <ahasenack> rbasak: so I'm on karl's branch, I ran the tag command, it created the right tag, then I "git push pkg <upload-tag-name>", right?
[14:20] <rbasak> ahasenack: correct
[14:21] <ahasenack> rbasak: since it's seeded, the upload was held for approval, should I push the tag anyway? I guess we can easily fix/remove tags if needed
[14:23] <rbasak> ahasenack: yeah push the tag anyway. I'd do it before dput to avoid a race. Being held in the queue is an unfortunate edge case for which we have no current solution, except to remove/replace the tag later if needed.
[14:24] <ahasenack> ok
=== ossurayynot is now known as tonyyarusso
[16:16] <teward> sdeziel: ERR: No Scrollback, can you provide me more details?
[16:16] <teward> i'm confused by context / question
[16:16] <teward> no scrollback before [2018-10-03 10:02:25] <ahasenack> rbasak: checking brotli  <--- that
[16:16] <teward> so :|
[16:17] <teward> ahasenack: rbasak: sdeziel: is brotli a compression algo or something?
[16:17] <teward> ahasenack: rbasak: sdeziel: if you intend to ship it in nginx-core then yes it *must* be in main assuming it adds additional runtime deps
[16:18] <teward> if we don't intend to ship it in nginx core but in nginx-light, nginx-full, or nginx-extras, then we don't have to worry
[16:18] <teward> but if we want to include in nginx-core we'll need the security team to ack it
[16:18] <teward> (cc sarnold)
[16:18] <teward> sdeziel: rbasak: third party modules were previously NACK'd on the MIR for 14.04
[16:18] <teward> because of wildly different coding styles
[16:19] <teward> which is why we created nginx-core without third party modules.  if ngx_brotli is the plugin we need to add, then it needs security team audit first
[16:19] <teward> if they NACK it then it can only go in the Universe flavors
[16:19] <teward> but it probably wouldn't be for this cycle, it'd probably be for next.
[16:34] <ahasenack> teward: libbrotli1 is in main
[16:34] <ahasenack> (cosmic)
[16:35] <ahasenack> I was just looking at it because there is an sru request
[16:35] <teward> ahasenack: ah.  well AFAICT to get Brotli into NGINX it needs a third party module
[16:35] <teward> that'd require MIR / security team review if we want it in nginx-core
[16:35] <teward> less of a concern for the non-Main flavors
[16:35] <teward> but the only plugin I can find for it is 3 years old without any development changes currently,.
[16:35] <ahasenack> the sru is about brotli for xenial iirc, it would be a NEW package there
[16:36] <ahasenack> then someone remembered nginx could use it, that's all
[16:36] <teward> ahasenack: with a plugin, yes, it can.
[16:36] <teward> but it'd still need sarnold's review first
[16:37] <teward> and it'd need a HELL of a good reason to be added to Xenial given it doesn't really fit the SRU to add that into NGINX on Xenial
[16:37] <teward> at least, per SRU policy it doesn't fit
[16:37] <teward> for Cosmic, it's a bit late in the cycle to add it to nginx, for 19.04 I could look into it
[16:37] <teward> but it'd still need sec team review - sdeziel rbasak ^
[16:38] <teward> sdeziel: rbasak: note that it'd add a significant delta from Debian, perhaps this should be requested there first?
[16:38] <teward> I know we already have a pretty substantial delta already, but.
[16:43] <sdeziel> teward: sorry, was out for lunch. I just wanted to know if you had plan for brotli support in nginx. Yeah, getting it from Debian would make sense
=== jrwren_ is now known as jrwren
[17:28] <teward> sdeziel: getting it from Debian would make sense...
[17:29] <teward> sdeziel: but given the only code I can find that adds that support is from Google and hasn't had any code changes for 3 years
[17:29] <teward> it'd need sarnold to give it a thorough review for Main consideration
[17:29] <teward> even if it originated in Debian
[17:29] <teward> I'd still suggest it for Debian
[17:29] <teward> and then we'll determine later if Debian adds it
[17:29] <sdeziel> teward: I was not asking for MIR specifically
[17:30] <teward> sdeziel: well, that's the thing
[17:30] <teward> sdeziel: it's not a dynamic module
[17:30] <teward> sdeziel: so it has to be compiled into the executable at compile time.  for which flavors of the NGINX binary would you want this to target?
[17:30] <teward> or rather, be included in?
[17:30] <sdeziel> teward: right, would that mean it should go upstream first ? (in an ideal world)?
[17:30] <teward> sdeziel: in the ideal world, yes.
[17:31] <teward> it wouldn't go into nginx-core which is Ubuntu specific without sarnold reviewing it
[17:31] <sdeziel> teward: OK so I know where to take it next if I really feel like having brotli ;)
[17:31] <teward> sdeziel: Debian.
[17:31] <teward> :P
[17:31] <sdeziel> or NGINX
[17:31] <teward> sdeziel: NGINX if you want it included as a core module
[17:31] <teward> Debian if you want https://github.com/google/ngx_brotli included directly
[17:31] <teward> but if you ask NGINX to add it, expect it to be "An Eternity" before it's available
[17:31] <teward> or for them to NACK it.
[17:32] <teward> sdeziel: you could probably gauge upstream's care about it by emailing nginx-devel's mailing list
[17:32] <sdeziel> I'm surprised that Cloudflare didn't push for upstream inclusion
[17:32] <teward> sdeziel: but consider a headache here - there used to be gzip encryption - it's disabled by default thanks to CVEs
[17:33] <teward> which is another consideration factor if you intend to use brotli in-line with HTTP for compression
[17:33] <teward> (Just saying)
[17:34] <sdeziel> I'd have to revisit this as I don't see how compressing just .css and .js would be dangerous
[17:34] <teward> sdeziel: do you have a comparison spec for brotli vs. gzio?
[17:35] <teward> sdeziel: https://trac.nginx.org/nginx/ticket/798
[17:35] <teward> ^ that's the nginx trac ticket asking for it
[17:35] <teward> google preempted by releasing ngx_brotli
[17:35] <teward> 3 years ago
[17:35] <sdeziel> teward: thanks. No specific benchmark but found this https://hacks.mozilla.org/2015/11/better-than-gzip-compression-with-brotli/
[17:35] <teward> been untouched since 10 months ago, that ticket.
[17:38] <sdeziel> yeah, that pretty much answers my question, thanks again
[17:41]  * Jenshae blinks like a cow and chews a snack.
[17:41] <Jenshae> What was all of that about in a simple version?
[17:42] <teward> Jenshae: sdeziel was asking how hard it'd be to get NGINX to support Brotli, and then we went on a tirade about how there's only third party plugin support that may not even build because it hasn't been changed in 3 years
[17:42] <teward> (and sarnold has said he'd cursory review the code if it doesn't expldoe violently on compile...)
[17:43] <Jenshae> What essentially is NGINX and Brotli and what is Brotli meant to do?
[17:43] <teward> NGINX is a web server software
[17:43] <teward> i'll let sdeziel explain brotli
[17:43] <sarnold> brotli's yet another compression tool
[17:43] <sdeziel> one that's supported by most browser
[17:43] <sdeziel> but yeah, possibly just another in the big lot :)
[17:44] <Jenshae> Compression for video and images?
[17:45] <sdeziel> Jenshae: no, generic compression algo
[17:45] <sdeziel> for gory details https://tools.ietf.org/html/rfc7932
[17:45] <teward> ewwwww this is ugly
[17:45] <teward> sarnold: ^
[17:45] <Jenshae> How would you apply it and why is it needed? For slow connections then the browser decompresses it?
[17:46] <teward> sarnold: it looks like it pulls in a lot of extra brotli deps
[17:46] <teward> into the source tree
[17:46] <teward> which breaks debian
[17:46] <teward> since it pulls the brotli deps in via git submodules and not libbrotli
[17:46] <sarnold> teward: o_O it's not just a -lbrotli kind of thing?
[17:46] <teward> which means I personally am NACKing it
[17:46] <teward> sarnold: correct.
[17:46] <sarnold> yeah. not interested in yet another embedded code copy :)
[17:46] <teward> which means Google needs to learn how to actually write plugins.
[17:47] <teward> sdeziel: NACK'd for NGINX
[17:47] <sdeziel> I had already forgotten about it ;)
[17:47] <teward> :P
[17:47] <Jenshae> (Sorry, I am just curious, I did a bit of XML 15 years ago and 6 month contract of PHP coding a handful of years ago, both for intranets. That is the closest I have come to web development)
[17:47] <teward> *returns to kicking around a firewall*
[17:48] <sarnold> Jenshae: in this case it's probably a transparent server-applied compression that the clients then decompress.. the clients send up a header on requests to indicate which compression schemes they can cope with
[17:48] <teward> ahah wait a second
[17:48] <teward> sarnold: i think i found a fork that'd work
[17:48] <sarnold> Jenshae: zlib's been around forever and everything on the planet supports it, but there are faster systems and there are better compressing systems and sometimes both :)
[17:49] <Jenshae> Cheers. How is default SNI encryption coming along?
[17:50] <sarnold> I think it's still in the "oh god cloudflare what are you breaking *this* time?" stage. maybe it'll come along.
[17:50] <Jenshae> Hehehe :D
[17:51] <sdeziel> teward: the "surviving" fork appears to be https://github.com/eustas/ngx_brotli
[17:51] <Jenshae> GitHub still kicking or is there still a steady stream of devs over to GitLab?
[17:51] <sdeziel> I like what I understood from SNI encryption... leveraging DNSSEC is nice IMHO
[17:52] <teward> sdeziel: yes i'm working with that now
[17:52] <teward> sdeziel: or trying to
[17:52] <teward> sdeziel: if it explodes because it's missing deps/brotli/* then it's still NACK'd
[17:52] <teward> if it doesn't fail, sarnold gets asked to do a cursory code review ;P
[17:52] <sarnold> "add ubuntu 18.04 libbrotli-dev path " -- that's a good start, heh
[17:53] <sdeziel> teward: don't lose time on this, I was just _wondering_/asking if... :P
[17:53] <Jenshae> I also like the theory of eSNI and hope it puts a finger in the eye of snooping government officials. (They really want *everything* in the UK and to distribute it across 49 agencies, which would mean leaks galore.)
[17:54] <teward> not a problem :P
[17:54] <teward> sdeziel: ^
[17:56] <teward> sdeziel: well, it didn't FTBFS
[17:56] <Jenshae> FTBFS = ?
[17:56] <sarnold> fail to build from source
[17:57] <Jenshae> Thanks
[17:59] <teward> sdeziel: going to see if it works in runtime with their examples.
[17:59] <teward> if it doesn't, then it won't work, if it does, sarnold gets the link next :p
[18:05] <teward> sdeziel: i'm going to run a PPA build on this so I can test in containers more easily.  It'll take a bit though, sorry.
[18:06] <teward> sarnold: if you want to review in the interim... https://github.com/eustas/ngx_brotli is the codebase :P
[18:06] <teward> sarnold: thoug hI'm assuming we're going to NACK it for main because third-party :P
[18:06] <teward> (but it never hurts to ask, no?)
[18:06] <sdeziel> teward: no need to be sorry, I have no pressing need for brotli, merely some interest in the tech
[18:06] <teward> sdeziel: indeed.
[18:06] <teward> ERR:INTERNETDIED666THEENDISCOMEAPOCALYPSENOW  *goes to fix his internet*
[18:08] <sarnold> teward: maintaining an ubuntu delta from debian to add features or remove features isn't exactly *new*.. but you'd probably need server team interest in it too. :)
[18:08] <teward> sarnold: :P
[18:08] <teward> sarnold: true statement, though.
[18:08] <teward> (my IRC connection runs on my phone's internet, it's why i'm still here lol)
[18:14] <sarnold> teward: 90% of it looks pretty good. I'll pop open some issues and see what the responses are..
[18:21] <teward> sarnold: 'cept for the license part
[18:27] <kstenerud> in https://dep-team.pages.debian.net/deps/dep3/ what do "forwarded" and "forwarded upstream" mean?
[18:49] <teward> kstenerud: if you would read it it would explain what the forwarded tag means
[18:49] <teward> 'forwarded upstream' means the patch has been relayed to the upstream developers of the code/program typically
=== ChunkzZ is now known as Z3D0T
=== Z3D0T is now known as Z3DD0T
=== Z3DD0T is now known as Miidlandz
[22:37] <ahasenack> kstenerud: about my email, I meant http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#postfix
[22:37] <ahasenack> to keep an eye on that
[22:37] <ahasenack> I was on my phone and didn't have the url at hand