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.zucc...@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
