Alright, gotcha. Then just using the Debian-packaged version nicely saves us adding a repo.
Ah, ye, makes sense! Would just assign an IP then as that doesn't hurt and Lilly can choose to use it or not.
Ah, I see, yeah, okay. We would have the option now, as we change things anyway, to clean up that configuration, but I'm also fine with keeping it as is for legacy reasons.
Oh, that totally makes sense. I'm fine with the name, if others really like it, but personally I would prefer something like z9-router indeed.
IPv6 is missing the most significant bits. And is generally commented out weirdly?
If we want to count the v6 up in hex (which I think is reasonable as we do the same for the VLAN ID in the prefix), then it should also be done properly.
Again, getting rid of the Arch Linux logic also greatly simplifies this file.
Do we have a requirement for the more up-to-date version present in the upstream repository or is the one in the Debian repos sufficient?
Since we got granular control over whether to use dhcpv4, v6 or the agent, would it make sense to then also granularly install the relevant packages?
Most of the variables here are commented out, so we can just massively simplify this file.
It's fine, just feel like rt1 is one of those obscure names again, which gives more trouble than benefit.
If we configure ansible-pull variables above, the host should also be added to the relevant host group. (However an ansible-pull age private key is still missing.)
Again, same comment as in the kea role, I don't think it makes sense to have granular tags in the role itself.
There is no bind package on Debian and we already install dig in the base_config role: 7832978ff7/roles…
We have a nice role for managing systemd-resolved already, so no need to duplicate functionality here.
The search domain would be z9.ccchh.net. Unless it got decided to drop that now.
I would rather just stick to only having tags at the playbook level. I don't think this kind granular control for the role is really needed as it the config files also shouldn't trigger a reload,…