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.
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,…
The search domain would be z9.ccchh.net. Unless it got decided to drop that now.
Core configuration looks good, tho I left some comments. Left some more comments on the roles as well.
Are those all the CPUs we use? Might it make sense to have this configurable or at least change the comment?
Just a nit-pick, but having the indentation be consistent across the dhcp4 and dhcp6 config would be nice.
I would rather move the enable and start logic into the file itself, since that's not really the job of a handler. See the main unbound setup tasks for reference.
Most of the variables here are commented out, so we can just massively simplify this file.
There is no bind package on Debian and we already install dig in the base_config role: 7832978ff7/roles…
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?
We have a nice role for managing systemd-resolved already, so no need to duplicate functionality here.
Again, same comment as in the kea role, I don't think it makes sense to have granular tags in the role itself.