[06:07] <lordievader> Good morning
[10:35] <jamespage> coreycb: working through the py37/async syntax failures
[10:35] <jamespage> most upstreams have commits at least so generally picking those
[11:48] <coreycb> jamespage: great, thanks
[12:23] <ahasenack> rbasak: hi, good morning, did you see my ping about the git-ubuntu importer being apparently stuck?
[12:25] <rbasak> Yes
[12:25] <rbasak> The experimental deployment environment had died.
[12:25] <rbasak> I intend on restoring it this afternoon
[12:27] <ahasenack> ok
[13:20] <ahasenack> rbasak: I have a salsa merge request to add dep8 tests to the krb5 package. This package is currently a sync in ubuntu
[13:20] <ahasenack> rbasak: no response from salsa yet
[13:20] <ahasenack> rbasak: should I keep waiting, or is it worth it to add a delta because of dep8?
[13:21] <ahasenack> rbasak: https://salsa.debian.org/debian/krb5/merge_requests/2
[13:30] <rbasak> ahasenack: good job with the tests. I think it's fine to add a delta. Though does the slapd-gssapi test perhaps belong in the openldap side source package?
[13:30] <ahasenack> rbasak: it's testing mostly gssapi, not ldap
[13:31] <ahasenack> since the only call I'm making is ldapwhoami
[13:31] <ahasenack> I'm not even seting up an ldap "database"
[13:31] <rbasak> Sure it's testing mostly gssapi, but really isn't it openldap's gssapi implmentation that's being tested here? Anyway, it's clearly subjective :)
[13:33] <ahasenack> no, it's also testing cyrus-sasl
[13:33] <ahasenack> kerberos is used also for services, not just people
[13:33] <ahasenack> so any service I pick could have this argument
[13:34] <ahasenack> it's testing both
[13:34] <ahasenack> but I'm sticking to authentication when talking to this other service, that's where I think the separation lies
[13:35] <ahasenack> if I had been exercising slapd acls with this authentication and authorization, then it would belong in the slapd package, for example
[13:35] <ahasenack> for slapd dep8 tests I have other ideas, much more ldap cnetric
[13:35] <ahasenack> centric*
[13:43] <rbasak> I appreciate it's sort of "in the middle" so which end is very much opinion. Let's see if the Debian maintainer accepts it :)
[14:10] <ahasenack> rbasak: there is one argument in your favor, though. If there is a related bug in the slapd package, the krb5 dep8 tests will fail
[14:10] <ahasenack> rbasak: but so will apache2 tests if openssl has a bug, for example
[14:11] <ahasenack> if, say, slapd gets a bug like the current mariadb one, where it's not running after installation, the krb5 dep8 tests could fail because of that
[14:22] <mattk> Is the ntp package missing from the 18.04 server ISO on purpose? I have some Packer builds that don't reach out to the Internet, and they're failing b/c that package is missing from the install media.
[14:23] <mattk> It's easy enough to fix on my end, but wondering if it'll be back in the 18.04.1 server ISO.
[14:24] <mattk> I based my build off of this preseed.cfg, and it's works for 14.04 and 16.04:
[14:24] <mattk> https://github.com/boxcutter/ubuntu/blob/master/http/preseed.cfg
[14:26] <rbasak> mattk: on purpose. ntp has been demoted to universe in 18.04 in favour of chrony.
[14:26] <rbasak> mattk: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Chrony
[14:27] <mattk> ahhh, good to know. And thanks for the pointer! rtfm ;)
[14:53] <coreycb> jamespage: comparing neutron-lbaas and neutron-fwaas. why do you have python(3)-neutron-fwaas -> neutron-fwaas-common and neutron-lbaas-common -> python(3)-neutron-lbaas? i thought the plan was to do the former but maybe i'm missing something.
[15:34] <paulbarker> Hi, I'm trying to bring up a bridge without any external interfaces (for containers to use) on Ubuntu 18.04, I have the following in /etc/netplan/01-netcfg.yaml: https://pastebin.com/0S9hqZ95
[15:35] <paulbarker> After running `netplan generate && netplan apply` and looking at the ouput of `ip addr` I have a new lxdbr0 interface but it's not fully up: https://pastebin.com/mGXQZ2Pm
[15:35] <paulbarker> I've done some googling but can't find much info on how to set up an "isolated", "private" or "internal" bridge (those are the terms I've searched for as that's what I'd call it)
[15:35] <paulbarker> Anyone got any ideas?
[15:37] <cyphermox> paulbarker: you can't bring an bridge with no member interfaces up right now with netplan, some config is missing from the generated systemd config
[15:37] <cyphermox> (I'm working on fixing this)
[15:38] <cyphermox> I think dja wrote down exactly what you need to do to make it work, if I can find the blog post again
[15:38] <paulbarker> Ok. I'm only trying to set this up in netplan manually due to problems with lxd's managed interfaces
[15:39] <cyphermox> right
[15:39] <compdoc> I use bridges for kvm guests, and i found in 18.04, kvm wont see bridges created in netplan
[15:39] <compdoc> paulbarker ^
[15:39] <paulbarker> Even with "ipv4.firewall", "ipv4.nat", "ipv6.firewall" and "ipv6.nat" set to false in my lxd network config it's still injecting iptables rules
[15:39] <cyphermox> it's top of my list for stuff in netplan, I'm getting to that today
[15:39] <cyphermox> compdoc: you mean libvirt? we fixed this recently
[15:40] <paulbarker> My actual end goal is using lxd + nftables instead of lxd + iptables
[15:40] <compdoc> but if you create the interfaces in netplan, and the bridges in /etc/network/insterfaces, kvm will see them and use them
[15:40] <compdoc> *interfaces
[15:40] <cyphermox> compdoc: yes, but this is unrelated to what we're talking about here
[15:40] <cyphermox> (and we fixed it, at least in bionic)
[15:40] <paulbarker> compdoc: From what I've seen other people post online, lxd should be able to see those interfaces if netplan brings them up correctly
[15:41] <compdoc> try it. create the bridge the old way
[15:41] <paulbarker> cyphermox: I'll be a happy guinea pig to test any fix for this when you have one out
[15:41] <compdoc> i figure kvm will catch up to netplan eventually
[15:42] <paulbarker> compdoc: What's the "old way"? Purge netplan and move back to ifupdown?
[15:42] <cyphermox> paulbarker: what compdoc is suggesting (using ifupdown) will work for now (though not for the same reason as it does anything for libvirt/kvm)
[15:42] <cyphermox> you don't need to purge netplan for that
[15:42] <paulbarker> I did that when Ubuntu 18.04 came up but figured it was time to move to the new stuff
[15:42] <cyphermox> but there's another way too, you can add an extra file to /etc/systemd/network
[15:43] <paulbarker> Manually messing with systemd-networkd configuration is not something I ever want to do
[15:44] <paulbarker> Happy to learn one new config language (netplan) but not 2
[15:44] <blackflow> jackie_chan_meme.jpg
[15:45] <cyphermox> paulbarker: you should be able to copy /run/systemd/network/00-netplan-lxdbr0.network to /etc/systemd/network/00-netplan-lxdbr0.network, and add to it "ConfigureWithoutCarrier=true" under the [Network]  block.
[15:46] <cyphermox> paulbarker: that's your alternative, if you don't want to use ifupdown instead for now
[15:46] <paulbarker> cyphermox: Do I then remove it from the netplan config for now?
[15:46] <cyphermox> or you'll have to wait until I put up the fix on my ppa or upload it to the archive
[15:46] <cyphermox> don't need to, but you can if you wish
[15:47] <paulbarker> I'd rather not throw everything out and move back to ifupdown when I've got almost everything working now with netplan
[15:47] <paulbarker> So will give that a go for now
[15:47] <cyphermox> it's not throwing everything out
[15:47] <cyphermox> on a new install of 18.04, you don't have ifupdown, but you don't need to remove netplan to use it
[15:47] <cyphermox> both can coexist fine if you don't try to configure the same device in both :)
[15:48] <cyphermox> OTOH, what I suggested for systemd-networkd is essentially the fix that will be implemented in netplan's generator, just it will be written in the file under /run (which doesn't help you here, if you don't want to write it yourself every time you reboot)
[15:48] <paulbarker> Living in a world of multiple admins here, having both a netplan config and a network interfaces file on the same server is just inviting others to accidentally break it
[15:49] <blackflow> indeedy. less conflicting layers the better.
[15:49] <paulbarker> I'll do the systemd-networkd config fix for now as it's easy to then back that out when you've got a fix out
[15:50] <blackflow> since netplan is only creating networkd config and not itself doing any networking API, you can do both netplan and throw in a separate .network file for the bridge
[15:50] <cyphermox> paulbarker: I'm a bit surprised you didn't just let lxd handle things, it usually does the bridges just fine itself
[15:50] <paulbarker> cyphermox: Even with "ipv4.firewall", "ipv4.nat", "ipv6.firewall" and "ipv6.nat" set to false in my lxd network config it's still injecting iptables rules
[15:52] <paulbarker> That causes the iptable_nat kernel module to be loaded which prevents me from using nftables (as the modules conflict)
[15:52] <cyphermox> ok
[15:52] <blackflow> are nftables even ready for prime time yet?
[15:52] <cyphermox> paulbarker: then, please also file a bug for lxd so stgraber can potentially fix this
[15:53] <paulbarker> cyphermox: Already done. Also happy to help testing a fix for that
[15:53] <cyphermox> I'm reasonably sure if you set ipv4.firewall=fasle and whatnot, you shouldn't still get stuff injected in iptables :)
[15:53] <cyphermox> paulbarker: ok
[15:53] <paulbarker> https://github.com/lxc/lxd/issues/4739
[15:53] <cyphermox> paulbarker: great
[15:53] <paulbarker> It's still injecting the rule for automatic checksum generation
[15:56] <paulbarker> blackflow: As long as you're running a recent kernel, nftables should be pretty stable now
[15:57] <blackflow> neat, I might start toying with then.
[15:59] <paulbarker> I'm currently loving the ability to split my rules file using "Include" directives but still get atomic switchover to a new ruleset
[16:00] <paulbarker> Never found how to do something like that with iptables
[16:01] <blackflow> paulbarker: different files you use for iptables-restore? with the flush directive available, the replacement should be atomic, no?
[16:03] <paulbarker> Yea you can do atomic replacement with iptables-restore but not with the rules split into multiple files
[16:05] <paulbarker> I'm using ansible to push configurations to a bunch of servers and have never got on well with the ansible iptables module.
[16:05] <sdeziel> paulbarker: I use something along those lines: cat /etc/iptables/*.snippets | iptables-restore
[16:06] <paulbarker> sdezial: Yea, I could put together a script to do that and then write a systemd unit file for it I suppose
[16:06] <paulbarker> But with nftables that's built-in and I can use the existing nftables service
[16:07] <paulbarker> I have `include "/etc/nftables.d/*.conf` in my /etc/nftables.conf file and it works really well
[16:07] <blackflow> paulbarker: check out iptables-persistent and netfilter-persistent packages (the former being a plugin for netfilter), it already comes with a service.
[16:08] <paulbarker> blackflow: Don't need either and iptables-persistent just calls iptables-restore which doesn't support includes
[16:09] <blackflow> why do you need includes if you use ansible? just combine one file from multiple files
[16:12] <paulbarker> The fragments are split across different roles. Yes I can mash it all together using templates in ansible but that's more of a mess
[16:13] <paulbarker> As usual there's 20 ways to solve the problem depending on personal taste
[16:15] <blackflow> no, you can have one role or action run at the end that takes all the files other roles placed into /etc/my-iptables-fragments.d/, creates a single file out of them and has a change handler that feeds it to iptables-restore if they're changed ;)
[16:18] <paulbarker> blackflow: That would work. But I still want to play with the new shiny nftables :p
[16:20] <blackflow> oh, sure :) I just mean it's more than possible to achieve that with iptables, if you want.
[18:29] <jamespage> coreycb: most pkgs with agents ave the dep common -> py
[18:29] <jamespage> not py->common
[18:29] <jamespage> we should switcharoo
[18:30] <coreycb> jamespage: ok so everything should switch to py->common, even pkgs with agents.