HOSTS file changed at reboot due to cloud-init – which way to go?

Just been caught out by a little Cloud-init on Trixie…

DNS (what else) server is not handling the .internal resolution at the moment (unbound is off-line so having to use the basic ISP router for DNS) and I needed to run a few scripts on a Trixie box based on a local web server so I ran:

echo 192.168.0.21 comp-setup.internal | sudo tee -a /etc/hosts 

so curl etc can find the files it needs from the internal web service. Install starts fine till I reboot the Pi part way through the scripts (due to a kernel update).

Post reboot I find this entry has gone as dear old cloud-init rewrites the HOSTS file now.

Looks like the template is in /etc/cloud/templates/hosts.debian.tmpl so I could change that (till an upgrade replaces it???) or look at stopping the overwrite in a config in /etc/cloud/cloud.cfg.d

The problem with this is I have no idea of the syntax other than to replace the whole cloud_init_modules section and that could come with its own issues if an update adds or removes modules here!

In the hosts.debian.tmpl there is a note on using manage_etc_hosts: True – so possibly adding a false line entry to an override file is the way to go?

I could possibly hold cloud-init by creating /etc/cloud/cloud-init.disabled but that seems drastic (and I am unsure what that will stop on the Pi – being headless is a bit of a risk).

Reading through https://docs.cloud-init.io/en/latest/explanation/configuration-priority.html#configuration does not really help in best-practise as it is mainly about including functions not overriding one not to run!

More annoyingly / worryingly is that I am seeing cloud-init run post reboot every time now – cannot get on a Pi with a 'live' Trixie to check if this is just this OS download. If so, this is going bite me more often that I would like (lazy habits).

Any thoughts my options (excluding getting unbound up and running) seem to be:

1. Edit hosts.debian.tmpl – risky if an update changes this file
2. Change hosts post each reboot – could script it I suppose
3. Edit the module load and comment out the overwrite option – any an update risk
4. Try the override 'false' entries
5. Disable cloud-init post first boot and hope nothing breaks
6. Give up and play with another box or Ubuntu till I get unbound up and running again
7. Give up till Forky is out and see if the Pi team have stopped using cloud-init 👀

edit:

Found creating cat /etc/cloud/cloud.cfg.d/98_nohost.cfg with

cloud_init_modules: - update_etc_hosts : false 

seems to work 😄