Salt Cloud not changing minion ID of template

[Batgranny]

Hi, 

I'm running salt-cloud against VMWare and deploying ubuntu 16.04 machines from a template.  When I deploy a VM from a profile everything seems OK except the minion_id retains the hostname of the template.  The output does not show any errors and I have updated the bootstrap file to the latest.  Any ideas how I would go about debugging and resolving this?

Both the salt minion and salt cloud are running 2019.2.0 (flourine) 

[Vaarlion]

Hi ;)
I'm not running salt-cloud, but instead i'm doing manual template deployment from vmware template.
i found out that i needed to do some cleanup after a clone, so i havea script who run at the first boot. Maybe you could find a way to put it in salt-cloud process

rename_host() {
 
    echo "Type new hostname :"
    read newhostname
 
    oldhostname=$(hostname)
 
    for file in \
        /etc/hostname \
        /etc/hosts \
        /etc/motd \
        /etc/postfix/main.cf \
        /etc/mailname \
 
    do
        [ -f $file ] && sed -i.old -e "s:$oldhostname:$newhostname:g" $file
    done
      hostname "$newhostname"
      HOSTNAME=$newhostname
}
 
reset_ssh-hostkey() {
 
    rm -f /etc/ssh/ssh_host_*
    dpkg-reconfigure openssh-server
}
 
reset_machine-id() {
 
    rm -f /etc/machine-id
    rm -f /var/lib/dbus/machine-id
    dbus-uuidgen --ensure=/etc/machine-id
    dbus-uuidgen --ensure
}
 
reset_salt() {
 
    rm -f /etc/salt/minion_id
    salt-call test.ping >/dev/null 2>&1
}

I hope i'm not to much out of topic

[Batgranny]

Thanks for your reply!  That not quite what I'm looking for however I've added the following line to the bootstrap file: 

echo $(hostname -s) > /etc/salt/minion_id && service salt-minion restart

I hope that this will add the hostname to the minion_id file.  I'll report back!

[Batgranny]

Even if it does work I would like to know how I would troubleshoot why it's not happening automatically so if anyone has any ideas please let me know.

[Vaarlion]

I have no idea of if it should or why it don't reset this value, but i believe you should not set it yourself. you should delete the file, and let salt-minion regenerate it on it's own (doing a test.ping from minion is enough in my case to regenerate the file).

[Batgranny]

My problem is that the minion won't be accepted because it has the same ID as the template but different keys so doing a test.ping isn't something I can do. Regardless, the command I added to the bootstrap file seemed to work however I suspect that the hostname parameter isn't being passed to whatever part of the bootstrap file sets the minion_id.  The actual hostname of the machine is being changed so I assume the hostname part of the salt-cloud -p PROFILE HOSTNAME command is being successfully passed from salt-cloud to the bootstrap file.  Is is anyone out there who has any experience with the bootstrap file  who could help me through this?

[Raf Czlonka]

Hi Batgranny,

Why don't you simply remove the minion_id file and associated keys
from the template?

Regards,

Raf

[Raf Czlonka]

On Thu, Jan 23, 2020 at 06:59:53AM GMT, Vaarlion wrote:
>
> Hi ;)
> I'm not running salt-cloud, but instead i'm doing manual template
> deployment from vmware template.
> i found out that i needed to do some cleanup after a clone, so i havea
> script who run at the first boot. Maybe you could find a way to put it in
> salt-cloud process
>

Hi Vaarlion,

If you don't mind, a couple of tips regarding the below ;^)

> rename_host() {
>
> echo "Type new hostname :"

This is purely for aesthetics - if you'd like the read to happen
on the same line, use printf(1) instead of echo(1).

> read newhostname
>
> oldhostname=$(hostname)

hostname(1) behaves differently depending on the OS, i.e. on Linux
it displays *only* the short _hostname_ part while on the macOS and
the *BSDs it prints the full name - the FQDN. Not an issue if you
only use Linux but if you'd like to make sure it is *only* the
_hostname_ part that you'd like to display, regardless of the OS,
use '-s'.

> for file in \
> /etc/hostname \
> /etc/hosts \
> /etc/motd \
> /etc/postfix/main.cf \
> /etc/mailname \

^^
This is redundant before 'do'.

>
> do
> [ -f $file ] && sed -i.old -e "s:$oldhostname:$newhostname:g" $file
> done
> hostname "$newhostname"
> HOSTNAME=$newhostname
> }

Unless you control your hostnames very tightly, i.e. they aren't
parts of longer words, then the above can cause issues. I'm looking
at Postfix's postconf(5)/main.cf specifically.

Also, some of the above files (should) use a short hostname while
others use FQDN.

> reset_ssh-hostkey() {
>
> rm -f /etc/ssh/ssh_host_*
> dpkg-reconfigure openssh-server
> }

There's no need to run dpkg-reconfigure if all you need is to
generate new keys and restart the ssh daemon:

ssh-keygen -A && service ssh restart

This also has the benefit of working on Debian-derived Linux
distributions, as well as the ones with roots in Red Hat.

> reset_machine-id() {
>
> rm -f /etc/machine-id
> rm -f /var/lib/dbus/machine-id
> dbus-uuidgen --ensure=/etc/machine-id
> dbus-uuidgen --ensure
> }
>
> reset_salt() {
>
> rm -f /etc/salt/minion_id
> salt-call test.ping >/dev/null 2>&1
> }
>
> I hope i'm not to much out of topic
>

In general, certain steps can be omitted, i.e. files which are
auto-generated at boot or service start, i.e. /etc/salt/minion_id,
could be removed from the template altogether, while other ones
edited beforehand with an unambiguous content to be replaced, i.e.
files containing $HOSTNAME, could have THIS_IS_TO_BE_CHANGED instead
of the old hostname if edited by sed(1), etc.

I hope you'll find some of this useful :^)

Cheers,

Raf

[Raf Czlonka]

On Thu, Jan 23, 2020 at 02:18:14PM GMT, Batgranny wrote:
> Thanks for your reply! That not quite what I'm looking for however I've
> added the following line to the bootstrap file:
>
> echo $(hostname -s) > /etc/salt/minion_id && service salt-minion restart
>
> I hope that this will add the hostname to the minion_id file. I'll report
> back!
>

Hi Batgranny,

The above will of course work but both echo(1) and the subshell are
redundant, i.e. this will do exactly the same thing:

$ hostname -s > /etc/salt/minion_id && service salt-minion restart

However, if you'd prefer to generate a minion_id the way Salt does
it, then you'd need something like this:

$ printf $(hostname -f) > /etc/salt/minion_id && service salt-minion restart

No newline character (\n) is being appended the minion_id file hence
the use of printf(1). Also, hostname(1)'s '-f' *should* work in
most circumstances, but please be aware of its limitations[0].

[0] https://manpages.debian.org/buster/hostname/hostname.1.en.html#THE_FQDN

If you'd like to avoid the above altogether, simply remove minion_id
file *and* the old keys, and the minion will generate them at (re)start.

Regards,

Raf