[06:01] <lordievader> Good morning
[07:42] <OlofL> Hello how do I run an ntp server properly ?
[07:43] <OlofL> https://paste.ubuntu.com/p/BQdCbWDHj6/ time seem to sync down to my server. but noone else can query me. tcpdump and I see requests coming in. firewall is off
[07:45] <OlofL> https://paste.ubuntu.com/p/32zHCpxshG/ systemctl status ntpd its running
[09:43] <blackflow> OlofL: ntp.conf is deliberately blocking queries from outside due to vulnerabilities inherent in the protocols. Check that. I don't know more because I never ran a stratum like that, only clients.
[09:43] <blackflow> OlofL: also timedatectl is relevant when systemd-timesyncd is in use, which shuts off when you install another ntp service like you did.
[12:15] <ahasenack> rbasak: hi, around?
[12:18] <rbasak> o/
[12:35] <ahasenack> rbasak: hi, about samba and libldb. ldb is stuck in migration for quite some time http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ldb
[12:35] <ahasenack> the reason is it needs a samba rebuild
[12:36] <ahasenack> rbasak: I'm not uploading my samba 4.8 merge because of that possible regression in samba upstream (https://bugzilla.samba.org/show_bug.cgi?id=13486)
[12:36] <ahasenack> rbasak: libldb is a sync from debian, it's in the migration queue probably because of an auto-sync
[12:36] <ahasenack> it's a library, used by others (like sssd)
[12:36] <ahasenack> if we want to get that into cosmig (by we, I mean ubuntu), we should unblock it soon
[12:37] <ahasenack> one way would be to just upload a no-change samba pkg, the one in cosmic currently
[12:37] <ahasenack> I don't know how long it will take to upstream comment on that bug, so far only debian has
[12:37] <ahasenack> I pinged #ubuntu-devel yesterday, no response
[12:53] <rbasak> ahasenack: I think a no change rebuild of samba is reasonable to unblock ldb, regardless of the status of an upcoming merge.
[12:53] <ahasenack> right
[12:53] <rbasak> ahasenack: separately I trust your judgement on whether a merge is appropriate now or you want to wait for the upstream regression to be fixed.
[12:54] <ahasenack> I would like to have upstream at least comment
[12:54] <ahasenack> "yes, it's a bug" or "no, you are holding it wrong"
[12:55] <ahasenack> rbasak: how should I proceed with a no change rebuild? Add a changelog entry with a "build1" suffix and request sponsorship?
[12:55] <ahasenack> or is there a script for that
[12:55] <rbasak> dch has a switch for it that should help
[12:55] <ahasenack> do we need an mp for that?
[12:55] <ahasenack> (I can't upload samba, if that hasn't become clear yet ;)
[12:57] <rbasak> It'd be a debdiff or an MP. I don't mind which since it'll only be a change to debian/changelog so the resulting commit willl be basically the same whether we use an upload tag or not.
[12:59] <ahasenack> from 4.7.6+dfsg~ubuntu-0ubuntu2 to 4.7.6+dfsg~ubuntu-0ubuntu2build1, does that look correct? dch --rebuild didn't add build1 but instead bumped 0ubuntu2 to 0ubuntu3
[12:59] <rbasak> Bumping 0ubuntu2 to 0ubuntu3 is correct
[12:59] <rbasak> We only add build1 when in sync with Debian
[12:59] <ahasenack> ah, ok
[13:01] <ahasenack> rbasak: switching topics, I was looking at an exim4 merge, that normally christian handles
[13:02] <ahasenack> rbasak: our only delta is a patch to add the distribution name ("Ubuntu") to the smtp banner
[13:02] <ahasenack> rbasak: I didn't find evidence of that having ever been submitted to debian
[13:02] <ahasenack> rbasak: and the patch is as such that it will work with debian as well, just adding "Debian" to the banner
[13:02] <ahasenack> rbasak: do you know of some history behind this? Would debian oppose to such a change (advertise that the service is running on a debian box)?
[13:03] <ahasenack> "220 sid-exim4 ESMTP Exim 4.91 Debian Tue, 03 Jul 2018 13:03:03 +0000"
[13:03] <rbasak> I believe it's down to individual Debian maintainers. I think Debian took a similar change to squid3 from us, for example.
[13:04] <ahasenack> ok, I'll try to send it to them
[13:05] <ahasenack> Yolanda made that one, back in 2013
[13:17] <ahasenack> rbasak: and launchpad's diff got nuts again
[13:17] <ahasenack> https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/348888
[13:19] <rbasak> ack
[14:02] <supercool> Hello guys!
[14:02] <supercool> Could someone help me to run the apt-get update command please?
[14:03] <blackflow> !ask | supercool
[14:03] <compdoc> whats the problem?
[14:03] <supercool> When I run it it seems a old app has a invalid signature or something. I just want to restart it from scratch
[14:03] <ahasenack> rbasak: in a dep3 header, can Forwarded be used to indicate the patch has been forwarded to debian as well, or just to upstream?
[14:03] <compdoc> if you have 16.04 or newer, use apt, not apt-get
[14:04] <compdoc> disable that repo then
[14:04] <supercool> how do I disable a repo?
[14:04] <ahasenack> supercool: better to show the error. It might just be an outdated mirror
[14:04] <supercool> It is not a official ubuntu mirror, it is related to a app I did install
[14:06] <supercool> I did already remove the sources.list fine
[14:06] <supercool> file*
[14:06] <ahasenack> you removed sources.list?
[14:06] <ahasenack> not sources.list.d/<someotherfile>?
[14:06] <ahasenack> or just a line from sources.list?
[14:06] <compdoc> just needed to edit it
[14:06] <rbasak> ahasenack: I don't think dep3 has considered that case for derivatives, so "undefined" maybe? I think it makes sense to use the header multiple times, once for each place it has been forwarded, including Debian (for us).
[14:07] <ahasenack> rbasak: yeah, I would like to record somewhere that I forwarded the patch to debian
[14:07] <supercool> Alright. Let me see it this file is listed.
[14:07] <rbasak> ahasenack: essentially I'm unilaterally extending dep3 using the existing pattern in the spec set for Author.
[14:08] <rbasak> ahasenack: another established way is to file the bug in Debian and then include "Closes: #XXX" in your changelog entry. You can do both.
[14:08] <ahasenack> rbasak: I'll stick with the salsa mp, let's see how it works out
[14:08] <ahasenack> I think the intent is clear
[14:09] <ahasenack> and I rather deal with salsa's interface than bugs.debian.org ;)
[14:24] <supercool> ahasenack: where do I locate sources.list.d ? The dir I removed was /var/lib/apt/lists
[14:25] <ahasenack> supercool: it's just a subdirectory of /etc/apt
[14:25] <supercool> Checking
[14:25] <ahasenack> supercool: to add a new repository, one can add a line to /etc/apt/sources.list, or a new file inside /etc/apt/sources.list.d/
[14:26] <ahasenack> add-apt-repository, for example, adds a file to /etc/apt/sources.list.d/ instead of a new line to /etc/apt/sources.list
[14:26] <supercool> And to remove it perhaps one can remove a line from /etc/apt/sources.list,
[14:33] <supercool> I think I get it ahasenack. There was some files into /etc/apt/source.list.d
[14:33] <supercool> Thank you a lot!
[14:34] <ahasenack> cool
[14:55] <coreycb> jamespage: i'm working on some keepalived backports for LP: 1744062
[14:55] <coreycb> jamespage: are you ok with backporting keepalived to ocata and pike cloud archives? to fix this in xenial would be non-trivial.
[16:03] <jamespage> coreycb: what does the version bump look like?
[16:05] <coreycb> jamespage: xenial is 1.2.19 and ocata/pike would be 1.3.2
[17:26] <ahasenack> rbasak: do we need to wait a bit more? https://pastebin.ubuntu.com/p/qbryPBpXCv/
[17:27] <ahasenack> I bet that output is left as is just to serve as a test for core-dev applicants :)
[18:42] <rbasak> ahasenack: :)
[18:42] <rbasak> ahasenack: looks like it migrated now?
[18:42] <ahasenack> let me check
[18:43] <ahasenack> rbasak: indeed. Odd, I didn't get the bugs ahhh, ok, the bugs being closed were tied to my 4.8 merge
[18:44] <ahasenack> rbasak: cool, it did migrate, thanks
[18:55] <eriswans> From #ubuntu: Where should I have been watching to find out in advance about the change to automatically install the ssm agent snap in the Xenial AMIs owned by Canonical, when earlier Canonical-owned Xenial AMIs did not?
[18:55] <nacc> dpb1: Odd_Bloke --^ ?
[18:56] <ahasenack> does he mean snapd, or an actual snap called ssm?
[18:56] <eriswans> the amazon-ssm-agent snap
[18:57] <ahasenack> no idea what that is
[18:57] <nacc> ahasenack:  a specific snap --^
[18:57] <eriswans> I only found out about it being installed (with no change to my cloud-init data) because of a monitoring freakout on newly-created instances panicking about there being no space or inodes free in the snap filesystem.
[18:58] <nacc> :cough: that's a buggy monitor :)
[18:58] <sarnold> useful thuogh :)
[18:58] <eriswans> ami-759bc50a (ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180627) automatically installed it; previous versions did not
[18:58] <Odd_Bloke> eriswans: o/
[18:58] <nacc> Odd_Bloke: thanks :)
[18:58] <ahasenack> https://snapcraft.io/amazon-ssm-agent
[19:00] <eriswans> This wouldn't have been problematic if it was something introduced in 18.04, but it's a very surprisng change to see made to canonical-provided amis of an lts release.
[19:00] <Odd_Bloke> Adding amazon-ssm-agent was a change to the image requested by Amazon; it enables a number of their solutions to work seamlessly on top of Ubuntu.  We worked with them to ensure that it is inert unless there is specific metadata that indicates it should do something (which would only be present if you were using one of the services that require it).
[19:01] <Odd_Bloke> eriswans: Sorry that it ended up causing that monitoring problem for you; other than that sort of fallout, it's a fairly minor addition to the image, so I'm not sure that we really communicated it out.
[19:01] <Odd_Bloke> We should do a better job of that in the future.
[19:02] <eriswans> It's not just monitoring, it silently broke a pattern for immutable-for-security-reasons instances (cloud-init turns off sshd and disables cloud-init from ever running user data again)
[19:03] <sdeziel> snap's ro loopback mounts being 100% used also tripped our monitoring ;)
[19:03] <eriswans> It's a good change, but IMO disastrous to add to an LTS release after that release
[19:04] <sdeziel> the fix was simply to ignore squashfs mounts
[19:05] <eriswans> Yeah, I've already fixed our monitoring, but this is still a dizzying, trust-destroying experience to learn that it's not safe to automatically grab the latest canonical-provided ami for an lts.
[19:07] <Odd_Bloke> In cloud environments, we have to find a position between the immutable LTS release and keeping up with the cloud platform so people can continue using Ubuntu on top of it effectively.
[19:07] <eriswans> My expectation is, well was, that a new ami in an lts will never be sufficiently different than grabbing the original ami for an lts and having the user data do an automatic dist-upgrade.
[19:08] <Odd_Bloke> And, as I mentioned, we worked with Amazon to ensure that the installed daemon will be inert unless specifically required by services that users have opted-in to.
[19:10] <eriswans> The security impact is that it provides a way around what was previously a reasonable way to ensure that once launched an instance wont' accept arbitrary administrative commands even from someone with access to the aws account.
[19:10] <Odd_Bloke> The dist-upgrade thing almost always holds true; this was an exceptional case because of the new platform requirement.
[19:11] <eriswans> It's not unlike sshd going from off by default to on by default mid-lts
[19:13] <Odd_Bloke> They are different categories of risk IMO, but I do accept your point.
[19:14] <eriswans> Is there at least a flag i can add to the user data to prevent it from being installed (stopping after starting isn't good enough), or is the snap baked into the ami?
[19:15] <_KaszpiR_> make your own custom ami without it?
[19:16] <Odd_Bloke> The snap is preseeded, which means it's put in to place on first boot.
[19:17] <Odd_Bloke> So I don't think a `snap remove amazon-ssm-agent` would be sufficient, as it would have to be installed (and started) for that to possibly work.
[19:17] <Odd_Bloke> Let me try a couple of things.
[19:19] <eriswans> Is it correct that the snap being pre-seeded would mean that it'll start whenever systemd starts the snap stuff up? (Sorry, I'm not familiar with snaps.) With that in turn implying that unless the snap services are somehow default-disabled and turned on by/*after* cloudinit, there'd always be a race?
[19:20] <Odd_Bloke> Yep, when snapd starts up, it will install the snaps that are preseeded in the image.
[19:20] <eriswans> Thanks for the clarification.
[19:21] <Odd_Bloke> user-data explicitly runs _after_ seeding is complete, so that preseeded applications are available to user-data.
[19:21] <Odd_Bloke> (Not particularly necessary in the amazon-ssm-agent case, but for snaps that install a CLI tool it's handy to actually be able to use them. :)
[19:24] <Ubu-1604> hello :)
[19:25] <compdoc> yur old
[19:28] <Ubu-1604> compdoc: well true ... I still use 5 1/4 floppy disks :)
[19:28] <Odd_Bloke> eriswans: http://paste.ubuntu.com/p/dCCprfCqBp/ removes the seed configuration, so amazon-ssm-agent will never be installed.
[19:29] <sarnold> handy, thanks
[19:31] <_KaszpiR_> rm -f  rahter
[19:33] <powersj> there was a command that would draw an topology of your system, can't recall it
[19:33] <powersj> hwloc-ls does a picture, but I thought i recalled an ascii one as well
[19:33] <sarnold> lstopo
[19:33] <Odd_Bloke> _KaszpiR_: Right.
[19:33] <eriswans> @Odd_Bloke thanks for that
[19:34] <powersj> sarnold: thanks that is it, but I guess it is the same as hwloc-ls
[19:34] <sarnold> powersj: oh :)
[19:35] <sarnold> powersj: I was using lstopo --of console and lstopo --of ascii the other day..
[19:35] <sarnold> ascii is surprising
[19:35] <powersj> hah wow
[19:35] <Odd_Bloke> eriswans: Happy I could help!
[19:38] <_KaszpiR_> whoa so many years in linux and haven't seen that command
[19:47] <npgm> I'm looking for a text/cli based network management tool that knows about linux network namespaces. 18.04's netplan has no notion of network namespaces. I need a configuration that will allow me to define the namespaces and the associated interfaces and have this persist on restart.
[19:47] <npgm> is my only option to write raw ip commands in a bash script or something?
[19:48] <sdeziel> npgm: I'd look into "lxc network"
[19:49] <npgm> will look - but to be clear I'm not using any containers
[19:49] <sdeziel> npgm: yeah, it's not a perfect match to what you need but you can use lxc defined network without using lxc containers
[19:50] <npgm> got it
[19:50] <sdeziel> hmm, not sure that will fit the bill though because the created networks are in the host context, sorry
[19:50] <npgm> so I am running a binary with `ip netns exec` under a certain namespace. At that point how far off is this from just being an lxc container?
[19:51] <npgm> I guess my issue is I know the exact ip configuration that I want, I just want to be able to write it down in a file that will be loaded on startup, so not terribly interested in writing some container file for this.
[19:53] <sarnold> npgm: please file a bug report against the netplan/nplan package, describing what you want, I have to imagine that we'd like to cover it in the future
[19:53] <sarnold> npgm: but you'll probably have best success most quickly just doing it by hand.
[19:54] <npgm> sarnold: how do you suggest doing that? i.e. whats the best way to manage raw `ip` commands?
[19:55] <sarnold> npgm: you could probably still install and use ifupdown and use /etc/network/interfaces
[19:55] <npgm> sarnold: oh, does that support namespaces?
[19:56] <sarnold> not that I know of, but it provides a place fo ryou to put all the ip commands that you want..
[19:56] <npgm> I see, I'll look into that. Thank you
[19:59] <sdeziel> some scriptability should be possible with netplan: https://netplan.io/faq#use-pre-up-post-up-etc-hook-scripts