FAI + SaltStack anybody?

[Sinh Lam]

Reading through your original post - I think there might be some confusion
as to what SaltStack does and what FAI does (if not, I apologize).
SaltStack is a configuration management tool that is normally used to
ensure the target minion's configuration is exactly as it should, while FAI
is a provisioning tool that essentially builds the server that SaltStack is
used to manage.

With the above said, I do not see what you mean there is a chicken and the
egg problem.

I do not believe that salt can do the actual installation of the server’s
OS because there’s no minion running to begin with.  You should really
leave that to FAI.  Your concern was how to move the minion around servers
that are getting provisioned/re-provisioned so you don’t have to approve
the minion each time and I’m sure there’s a couple of ways to do this but
right now I see two :

1) turn on auto-accept - you don’t have to worry about approving any
minions because they’ll be auto-approved
2) issue a call to the salt master to accept the new minion when it is
registered during fai.  This involves you knowing the minion id/name of the
key.

This is how I’m planning on using SaltStack with FAI -

I have a dedicated network that is tightly controlled so to that point I
know what connects to it and I know why those servers are connected to that
particular network.  In essence, I trust this particular network.  Because
of this, I have auto-accept turned on my salt master.

I have FAI install the base os on the server, toward the end of the
process, a couple things will happen:
* a script will be used to auto-register this server with our CMDB
* a script will be used to enroll this minion with the salt-master and set
the minion_id (if needed).

Once the above two is done, FAI will issue a reboot of the server.  Once
the server is back up, the salt-minion will reconnect with the salt master
and because the key is already accepted (because I have auto-accept turned
on), a high state will run.  Regarding pillar data, I have an external
pillar that pulls information about the minion from the CMDB and generates
all the relevant pillar data the states need to use.

That’s it.  FAI does the OS (and handles the registering of the server with
our CMDB and the minion with the master), and salt stack takes care of the
configuration of the server.

I hope this provides some clarity as to how to use FAI with SaltStack.

The glue I believe you’re talking about is a source of truth to populate
pillar data and grains so your salt states can actually do something
useful.  The above scenario is what I’m about to implement.  I have a CMDB
that contains information about the very server FAI is provisioning.  This
information from the CMDB will populate the pillars which will feed into
states to dynamically do whatever it is that server is provisioned for.
You can do some manual work and pre-populate the CMDB or use FAI to
auto-register this information with the CMDB so on the next boot, when the
salt-minion is started up again and connects to the master (because the key
is already accepted) a high state will get ran against that particular
minion.

And MAC addresses can be spoofed quite easily, so you really shouldn’t rely
on that as your ‘root of trust’.  I deal with a lot of VMs and each one of
those VMs I can easily specify whatever MAC address I want (you really
shouldn’t).  But spoofing a MAC while it’s in the early parts of pxe/net
boot process is harder (if not impossible), you still shouldn’t use it as
the ‘root of trust’.

https://www.tutorialspoint.com/how-to-modify-mac-address-in-windows-10-both-wired-and-wireless-adapter
https://wiki.archlinux.org/title/MAC_address_spoofing

The above are two examples of how to do just that but I’m not sure what you
mean by protected connections.  FAI is ran after the server is pxe/net
booted.  You can pull the root down using a squashfs image or something via
https but otherwise I’m not entirely sure what you mean.

On October 5, 2023 at 9:59:01 PM, Diego Zuccato (diego.zuccato at unibo.it)
wrote:

Il 05/10/2023 16:58, Sinh Lam ha scritto:
> You can essentially establish a ’trust’ to auto-accept keys.  Then you
> wouldn’t really have to worry about moving the minion keys around.  Once
> your bootstrap/installation is done, have it run a state to remove the
> key or auto-purge it somehow.

Uh? If the minion is not known to the master, it doesn't receive
pillars. And can't interact with the master. Chicken and egg.

> Honestly I would just leave the base install and anything else that
> needs to be set up to FAI and run salt against the booted up server
> after FAI is done and the server has been rebooted.
That's what I was planning to do. But without extra "glue" I'm losing
context. In particular if FAI tells Salt "I'm having *this* machine
reinstalled and its key is this" then Salt can auto-accept that key. But
if the machine is not being reinstalled by FAI, there's no reason to
auto accept a new key: it could be anybody!

Does FAI use protected connections (given that usually there's no
available "root of trust" stronger than the MAC address...) to the
machine being installed?

-- 
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20231006/ccb477b5/attachment-0001.html>