| Aison0 | bind9 from bind repository seams to be stable so far | 07:57 |
|---|---|---|
| Aison0 | but maybe it is just luck | 07:58 |
| Aison0 | :D | 07:58 |
| Aison0 | how do I have to change the systemd bind9.service file, so that the server is directly restarted after exiting? | 13:31 |
| rbasak | See Restart= in systemd.service(5) | 13:33 |
| === Wryhder is now known as Lucas_Gray | ||
| === Wryhder is now known as Lucas_Gray | ||
| === halvors1 is now known as halvors | ||
| RoyK | Aison0: does it still die? | 14:30 |
| sdeziel | Aison0: "sudo systemctl edit named" (the service was renamed to named with 20.04) | 14:32 |
| Aison0 | sdeziel, here it is bind9.service -> /lib/systemd/system/named.service | 14:33 |
| Aison0 | ok, maybe because of upgrade | 14:33 |
| sdeziel | Aison0: oh, that's because the named.service provides an Alias=bind9.service | 14:34 |
| sdeziel | I run mine with "Restart=on-failure" | 14:35 |
| === halvors1 is now known as halvors | ||
| RoyK | sdeziel: that should be the default, but should fail after some attempts if the error repeats | 14:37 |
| 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:43 |
| 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 | 14:45 |
| 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:07 |
| rbasak | AIUI, cloud-init detects that it's on a different host by detecting that the instance-id has changed | 17:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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. | 17:21 |
| Psi-Jack | Well, after some work, it is indeed, working. | 18:23 |
| Psi-Jack | Well, save for the display issue, which seems to work better with it associated to a serial socket. | 18:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!