MAAS sets manage_etc_hosts=True always and wipes out /etc/hosts on every reboot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Triaged
|
High
|
Unassigned | ||
OpenStack RabbitMQ Server Charm |
New
|
Undecided
|
Unassigned |
Bug Description
1:3.4.5-
Considering a situation where admins, users, or external automation to MAAS (e.g. Juju/Charms) modifies /etc/hosts after the initial provisioning by MAAS. Those changes will be lost immediately after a reboot.
By looking to the detail, the deployed hosts have the following:
[/etc/cloud/
# written by cloud-init debian package per preseed entry
# cloud-init/
manage_etc_hosts: true
manual_cache_clean: true
reporting:
maas:
consumer_key: Kmc8Wz45YnfQ2nT6EG
endpoint: http://
token_key: LDpwjgW5DVMPCdZRrH
token_secret: 9neUuyUPdBwamfC
type: webhook
And the explicit manage_
https:/
> /etc/hosts will be re-written on every boot
[/root/
debconf_selections:
grub2: grub2 grub2/update_nvram boolean false
maas: 'cloud-init cloud-init/
cloud-init cloud-init/
cloud-init cloud-init/
cloud-init cloud-init/
true\
http://
9neUuyUPdBw
'
description: | updated |
tags: | added: sts |
Changed in maas: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 3.6.x |
If I'm not mistaken the explicit manage_etc_hosts is coming from here: /git.launchpad. net/maas/ tree/src/ maasserver/ compose_ preseed. py#n403 preseed( node=None) :
https:/
> def get_base_
> """Return the base preseed config used by all ephemeral environments."""
> cloud_config = {
> # The ephemeral environment doesn't have a domain search path set which
> # causes sudo to fail to resolve itself and print out a warning
> # message. These messages are caught when logging during commissioning
> # and testing. Allow /etc/hosts to be managed by cloud-init so the
> # lookup works. This may cause LP:1087183 to come back if anyone tries
> # to JuJu deploy in an ephemeral environment.
> "manage_etc_hosts": True
> }
It wasn't like that when manage_ etc_hosts= True was introduced initially and it was purely for an ephemeral environment instead of deployed one. /git.launchpad. net/maas/ commit/ ?id=976cd6ca527 3da289c6b769d28 70614a28de87e5 /bugs.launchpad .net/maas/ +bug/1670444
https:/
https:/
Then, it looks like this commit dropped a condition for manage_ etc_hosts= False without much of explanation. /git.launchpad. net/maas/ commit/ ?id=22641cffcce a44ded1d20a72d8 4ba23856730d05 hostname) ` on a node
https:/
> - config = {
> - # Do not let cloud-init override /etc/hosts/: use the default
> - # behavior which means running `dns_resolve(
> - # will query the DNS server (and not return 127.0.0.1).
> - # See bug 1087183 for details.
> - "manage_etc_hosts": False,
manage_ etc_hosts= False has the least surprises for MAAS users obviously but if there is a good reason to stick to manage_ etc_hosts= True, we should document that explicitly and guide users how to deal with /etc/hosts properly, IMO.