[00:34] <rzgd> on the ubuntu server installer with pre-exiting and unlocker dm-crypt partitions, the installer is trying  to read keyfiles when not needed, and throws an error on block_meta.py line 1384, but being a preserved partition it shouldn't, error doesnt happen in the desktop version
[00:48] <sarnold> rzgd: I think there's a 'report bug' entry in the menu in the upper right hand corner
[00:48] <sarnold> rzgd: could you file one on this? :) thanks
[00:55] <mwhudson> the handling of existing dm-crypt devices is not so great :(
[00:56] <sarnold> morning mwhudson :)
[02:59] <rzgd> sarnold: i sent several reports yesterday :)
[02:59] <rzgd> just wondering if there is an easy way to by-pass, i tried commenting the line but the snap is read-only
[03:37] <mwhudson> you can play bind mount games to get around that but it's tedious
[07:18] <albech> Anyone here who is a champ in mail headers and SPF that will have a look at mail to see why the SPF is not being validated?
[08:40] <icey> Hey jamespage - I'm seeing a new set of test failures in the latest OpenStack milestone and couldn't figure anything, so I retried the m2 packages, and they're failing the same way. I'm not sure what the best approach is to ride tidying what changed but it looks like something landed in G that's hurting me
[08:43] <jamespage> icey: log?
[08:45] <icey> jamespage: https://pastebin.ubuntu.com/p/8TD5j233GD/
[08:48] <jamespage> icey: hmm yeah
[08:48] <jamespage> icey: I'd probably look at the build logs for the last built version in groovy and try to figure out which deps have changed
[08:55] <icey> jamespage: I don't know where to look to find the last built version in groovy
[08:55] <icey> could you give me a pointer please?
[09:05] <jamespage> icey: https://launchpad.net/ubuntu/+source/designate
[09:05] <jamespage> follow the links to the individual package versions
[09:06] <icey> thanks jamespage
[09:37] <icey> jamespage: only 61 package changes it looks like ;-P https://pastebin.ubuntu.com/p/cd6K2nZnNN/
[10:15] <jamespage> yeah but you can probably narrow it down - maybe dnspython?
[10:15] <jamespage> that's a major version bump
[10:16] <jamespage> icey: I would suspect that - upstream is pinned to 1.16.0
[10:17] <icey> jamespage: well, pinned-ish, maybe - dnspython>=1.16.0
[10:18] <jamespage> look at upper-constraints.txt in the requirements project as well
[10:18] <jamespage> that's used to limit transient breaks
[10:19] <icey> I see what you mean
[10:20] <icey> so jamespage, it seems like openstack packages are now conflicting on groovy, since they can't be 1.16?
[10:20] <jamespage> icey: welcome to being a distribution
[10:20] <jamespage> :)
[10:20] <jamespage> moving backwards is not possible, so we need to debug and fix designate to be compat with 2.0.0 of dnspython I would suspect
[10:22] <icey> and any other consumers of dnspython
[11:01] <icey> jamespage: it just gets better and better: eventlet 0.26.1 has requirement dnspython<2.0.0,>=1.15.0, but you'll have dnspython 2.0.0 which is incompatible.
[11:02] <icey> and the version of eventlet actually in groovy is 0.25.2
[11:06] <icey> that version hasn't (yet) pinned the dnspython to less than 2 :-P
[11:09] <icey> on the plus side, forcing it to work with dnspython>=2 fails in the same way, so I'll work on a fix (that won't be acceptable upstream until the rest of the ecosystem moves forward :-/)
[12:23] <icey> jamespage: this is looking bad - eventlet downgraded from dnspython2 because it broke a lot of bits - Nova folk are also commenting on this issue: https://github.com/eventlet/eventlet/issues/619
[12:23] <icey> so, with an older eventlet in groovy, we can install it, but things using eventlet may be very broken
=== benpro0 is now known as benpro
[16:28] <gunix> is there any way to downgrade this? https://packages.ubuntu.com/xenial/libc-bin
[16:28] <gunix> i can find only the latest version in the mirrors
[16:28] <gunix> i need 2.23-0ubuntu11, not 2.23-0ubuntu11.2
[16:29] <RoyK> what's wrong with the new one?
[16:31] <gunix> RoyK: some very old internal library is failing with the new one
[16:32] <gunix> can we rsync this from another node that still has the older packages? :-D
[16:47] <sdeziel> gunix: you can get the old binaries from https://launchpad.net/ubuntu/+source/glibc/2.23-0ubuntu11
[16:54] <gunix> ty
[17:07] <RoyK> gunix: I guess setting up a vm or container to run that archaic code would be a better idea and just isolate it from everything else on the net
[17:34] <RoyK> gunix: or just recompile the old lib
[18:46] <gunix> RoyK: that is sadly not an option
[18:58] <RoyK> gunix: neither of them?
[19:07] <gunix> no  :-(
[19:12] <RoyK> gunix: why not a vm?
[19:13] <gunix> RoyK: cause the server is already deployed on hundreds of physical servers
[19:13] <gunix> and they have to stay alive
[19:14] <RoyK> hm - ok - so you have an old library and its app to which you don't have any code and that is running on hundreds of physical machines? sounds a wee bit like bad planning to me
[19:19] <oerheks> such ol' glibc, there is no reason to use it.
[19:24] <RoyK> gunix: from where did this software come?
[19:24] <gunix> internal software. The legacy one, nobody touched in years
[19:24] <gunix> :-D
[19:25] <RoyK> but the code is there somewhere?
[19:25] <RoyK> and someone can probably read it, even if it was written in FORTRAN77
[20:04] <znf> Hey - question question in regards to UFW
[20:04] <znf> I haven't really dabbled with iptables/netfilter in ages, so I just resorted to use UFW
[20:04] <znf> I did a fresh install of UFW, I only enabled ssh/http/https
[20:04] <znf> everything works when I test, I haven't gotten any reports of it not working
[20:05] <znf> yet... I get messages in my log about blocks to port 80
[20:06] <znf> Most of my traffic on that server comes from Cloudflare, so I see a lot of their IPs in the logs, but I don't get why
[20:22] <oerheks> znf,  i would start with enable ufw logs https://help.ubuntu.com/community/UFW#Logging
[20:23] <TJ-> znf: multiple IP addresses and/or interfaces?
[20:23] <oerheks> some blocks are explainable, old post; https://askubuntu.com/questions/299964/why-is-ufw-logging-block-messages-regarding-a-port-for-which-ufw-is-configured
[20:24] <znf> TJ-: multiple IPs yes
[20:24] <znf> As far as I can tell, there is no actual block
[20:24] <znf> Just... Logging? For... Reasons?
[20:25] <TJ-> znf: maybe there's just a logging rule enabled
[20:25] <TJ-> znf: is the log entry in the kernel log? is it prefixed with a UFW indicator so you can tell what is generating it?
[20:25] <TJ-> znf: "sudo iptables -nvL INPUT" might help spot the rule doing the reporting
[20:28] <znf> the output of -S does show logs, yes: https://pastie.dev/uh7gO2
[20:28] <znf> but it's so very weird to have them show up as UFW BLOCK when... there's no actual blocking
[20:30] <TJ-> It looks like that is due to the limit rules, when the number of connections exceeds the limit in a certain time they get blocked (anti denial of service rules)
[20:32] <znf> but there doesn't actually seem to be a limit
[20:32] <znf> it's just -j LOG
[20:35] <znf> at least taht's what I understand
[20:46] <znf> oerheks, I believ that logging is enabled by default, hence... why I see the log messages :)
[20:47] <znf> and yes, setting logging off gets rid of the messages
[20:47] <znf> not something I really want
[20:47] <TJ-> znf: is the target i/f or IP on the local host or in a container (and thus affected by FORWARD rules) ?
[20:47] <znf> nope, it's a stand-alone server, no container, just runs nginx
[20:50] <TJ-> znf: I was going to point to the ufw-before-logging-input chain but that's empty, and the ufw-user-input is called from ufw-before-input so port 80 connections shouldn't reach the -A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "