[07:30] <genkgo1> ddstreet: I failed to get AddPrefixRoute=false working. I added the .network filein /etc/systemd/network, with a Match and the [Address] containing this param.
[07:30] <genkgo> but after boot, the prefix routes were still there
[12:29] <ddstreet> genkgo you should check networkctl output to see if your network file is actually what networkd is matching to the interface, if you left netplan-generated network file in /run/systemd/network then that might be used instead of yours
[12:30] <ddstreet> (well, i should say if you left the netplan yaml that creates the networkd .network file for your interface, it may be used instead of your hand-created .network file)
[12:39] <genkgo> ddstreet: it cannot be that my own .network file is additional to what is already defined by netplan?
[12:43] <ddstreet> no
[12:43] <ddstreet> networkd only uses a single .network file
[12:43] <ddstreet> if you want to add on or modify it, you have to use systemd drop-in files, you can't define a second .network file
[12:46] <genkgo> ddstreet: clear, thanks for helping me!
[15:13] <chaslinux> Hey all, trying to autoinstall ubuntu server via PXE. It appears meta-data and user-data are being read, bit it doesn't autoinstall: https://pastebin.ubuntu.com/p/2fmbrDfT5y/ Checked and I can http to meta-data and user-data path. Any ideas? I saw something about an installer ssh key, but it went by too quickly, and using http, not ssh.
[15:16] <chaslinux> My pxelinux.cfg/default looks like this: https://pastebin.ubuntu.com/p/QTZFqHgC4v/
[15:47] <chaslinux> The message I mentioned earlier is ci-info: no authorized ssh keys fingerprints found for user installer/join #kwlug
[15:47] <chaslinux> Ooops, sorry, thought I cleared everything.
[18:38] <_DWD_> Is it possible to configure Ubuntu Server to not update snaps unless explicitly requested?
[18:39] <leftyfb> _DWD_: no. You can only schedule them, but eventually they will get updated
[18:40] <smoser> what happens if you pihole the store ? or something like that.
[18:43] <_DWD_> My friend has asked me this question, and I'm intrigued.  The temporary solution i've given him is to use a cron job to continuously set back the refresh date. Some people have mentioned blocking the url, but that seems a bit ineligant 
[18:47] <Ussat> Or you can totally remove snaps
[18:47] <Ussat> Which is what I do in an post install script
[18:51] <sarnold> uninstalling snapd is the easiest way to make sure snaps don't auto-update
[18:51] <Ussat> Yup
[18:51] <sarnold> you could probably also firewall or null route the servers in question
[18:51] <sarnold> in case you wanted to use them, and select the moments you wanted them to be auto-updated
[18:52] <sarnold> or you could buy a brand store and control when packages are updated that way, similar to running a free aptly instance
[18:59] <_DWD_> not so good when the tool they need, maas, is snap only :P
[19:00] <sdeziel> _DWD_: maybe use a snap store proxy? https://docs.ubuntu.com/snap-store-proxy/en/
[19:01] <sdeziel> this lets you ping a given snap revision
[19:01] <sdeziel> s/ping/pin/
[19:02] <stgraber> we have https://discuss.linuxcontainers.org/t/managing-the-lxd-snap/8178 for LXD which likely has a few pointers that can be applied to maas too
[19:05] <leftyfb> stgraber: that looks like it requires upstream to pin a version. If MAAS doesn't have a pinned version, this doesn't work. It also doesn't work for pinning the latest version
[19:06] <_DWD_> thank you, that's very useful info to know :)
[19:07] <stgraber> leftyfb: maas has per-release channels very similar to what LXD does, so you can at least pin on the version, then if that version is the latest one, you're still going to be getting the bugfix updates so may want to setup a maintenance window for those. If you want to completely control things, then an enterprise proxy or preventing snapd from reaching the store is the way to go.
[19:08] <leftyfb> _DWD_: your cron job also won't work indefinitely: "However after 60 days a refresh will occur irrespective of the value of refresh.hold."
[19:11] <_DWD_> right, that's an important thing I didn't know
[19:12] <_DWD_> Why was the decision taken to feature this behaviour and not to allow admins to completely hold all snap updates/
[19:22] <Gorian> okay, I haven't used IRC in a few years - how do I register my name?
[19:23] <Ussat> Its a "feature" of snaps......hence why I remove all snaps etc from alll my installs
[19:24] <Gorian> Ussat: I wish I could. But snap is the "canonical" way to install maas afaik. The apt packages are just metapackages for the snap
[19:24] <_DWD_> @gorian https://libera.chat/guides/registration
[19:24] <Ussat> eww...sorry to hear that, we dont use MaaS
[19:25] <Gorian> I don't want to, lol. Some developer who knows nothing about systems administration deployed it as a snap before I joined the team
[19:25] <Ussat> Ya I refuse to have anything on my servers that restarts without me knowing / controlling it
[19:25] <Ussat> Gorian , you have my sympathy
[19:26] <Gorian> and maas gets it's little roots in everything - it configures everything to PXE to maas, manages the servers via cloud-init, and requires that it is in charge of DHCP and DNS
[19:26] <_DWD_> now i feel a desperate urge to do a stock-check on what I have running on my server that's snappy
[19:26] <Gorian> it's a bit hard to replace
[19:26] <Gorian> working on it, but it's not simple
[19:26] <Ussat> Ya I hear ya
[19:27] <_DWD_> I'm alright haha I only have the livespatch snap and core/core18