[07:57] <Aison0> bind9 from bind repository seams to be stable so far
[07:58] <Aison0> but maybe it is just luck
[07:58] <Aison0> :D
[13:31] <Aison0> how do I have to change the systemd bind9.service file, so that the server is directly restarted after exiting?
[13:33] <rbasak> See Restart= in systemd.service(5)
=== Wryhder is now known as Lucas_Gray
=== Wryhder is now known as Lucas_Gray
=== halvors1 is now known as halvors
[14:30] <RoyK> Aison0: does it still die?
[14:32] <sdeziel> Aison0: "sudo systemctl edit named" (the service was renamed to named with 20.04)
[14:33] <Aison0> sdeziel, here it is bind9.service -> /lib/systemd/system/named.service
[14:33] <Aison0> ok, maybe because of upgrade
[14:34] <sdeziel> Aison0: oh, that's because the named.service provides an Alias=bind9.service
[14:35] <sdeziel> I run mine with "Restart=on-failure"
=== halvors1 is now known as halvors
[14:37] <RoyK> sdeziel: that should be the default, but should fail after some attempts if the error repeats
[14:43] <sdeziel> RoyK: oh, didn't know it was the default but yes, there is a limit to how fast restarts are done to avoid DoS'ing the machine
[14:45] <sdeziel> RoyK: man systemd.service(5) says Restart=no is the default
[14:45] <sdeziel> and then > on-failure is the recommended choice for long-running services
[17:07] <Psi-Jack> This is a very strange new thing. I installed Ubuntu 20.04.1 onto a VM in Proxmox VE. Bare minimums only. Convered it to a template, cloned that into a new VM. cloud-init didn't generate a new host key, heck it even somehow had the same IP and I'm not sure how or why. It didn't act new and re-generate anything.
[17:08] <rbasak> AIUI, cloud-init detects that it's on a different host by detecting that the instance-id has changed
[17:09] <rbasak> The instance-id is provided by the VM environment - for example through the Amazon metadata service when on EC2.
[17:09] <rbasak> So you might be able to reduce your problem to: what instance-id did cloud-init pick up from Proxmox, did it change, and if not, why not?
[17:10] <Psi-Jack> Hmmm never had a problem before. Heck even Debian 10 works fine.
[17:10] <rbasak> Oh, and also: I installed Ubuntu 20.04.1 onto a VM in Proxmox VE
[17:10] <rbasak> Why didn't you use a cloud image?
[17:11] <rbasak> If using the installer, I think *it* generates the instance id, and so cloud-init will use that and it will never change?
[17:11] <Psi-Jack> Why would I?
[17:11] <sdeziel> maybe you could "reset" cloud-init with https://cloudinit.readthedocs.io/en/latest/topics/cli.html#clean ?
[17:11] <rbasak> The installer isn't intended for the cloud use case.
[17:12] <rbasak> Our cloud images are intended for the cloud use case.
[17:12] <rbasak> All the installer is doing is configuring a cloud image for non-cloud use anyway
[17:12] <rbasak> If I'm right, the behaviour you're seeing is by design
[17:13] <rbasak> And (again only if I'm right with my assumptions here) Debian works because you installed cloud-init manually there, and it wasn't configured by the installer for a non-cloud use case.
[17:14] <Psi-Jack> Yeah well using a cloud image in this use case adds complications and doesn’t allow for “Golden images”
[17:14] <rbasak> Why not?
[17:14] <rbasak> Ubuntu cloud images _are_ "golden images" and they are customisable to produce your own custom "golden images".
[17:21] <Psi-Jack> Hmmmm.. I suppose I can try. I found some documentation on how to use proxmox-ve CLI tools to use the ubuntu-cloud images, and thought it'd be more difficult.
[18:23] <Psi-Jack> Well, after some work, it is indeed, working.
[18:24] <Psi-Jack> Well, save for the display issue, which seems to work better with it associated to a serial socket.