<div dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">I did not read this whole threads, but yes, here we are currently managing a FAI server through SaltStack. It configures pxelinux files and my DHCP server. FAI rootfs installs the SaltStack repository with a script class, and my SaltStack server auto-accept keys from known hostnames through a SaltStack reactor or orchestrator, depending on the machine. When the key is accepted, a highstate is deployed to finish the install when the orchestrator is launched. All my machines configurations are stored on the SaltStack pillars. Those pillars contains the SaltStack minion's name, the hostname, the mac address, the IP address, the boot state and some other useful informations. When a machine is finally installed, the orchestrator change the value "boot" in my pillar corresponding to the machine to "OS" instead of "install" and the value is deployed to the tftp FAI server to changed the pxelinux file like fai-chboot would have done with states tftp and dhcp.</div><div dir="auto">When a machine needs to be reinstalled, orchestrator starts by changing its boot state, deploys the tftp state, reboot the machine and removes the key. Then the machine is installed; there is a big timeout in order to wait for the reinstall. Then the machine tries to reconnect to the machine "salt", key is auto-accepted, highstate is deployed, etc..</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Problem with the orchestrator is that it is only one machine by one machine, contrary to a fully reactor system.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Hope it helps,</div><div dir="auto"><br></div><div dir="auto">Best regards,</div><div dir="auto">Rémy</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 11 oct. 2023, 13:33, Markus Köberl via linux-fai <<a href="mailto:linux-fai@uni-koeln.de">linux-fai@uni-koeln.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die<br>
eigentliche Nachricht steht dadurch in einem Anhang.<br>
<br>
This message was wrapped to be DMARC compliant. The actual message<br>
text is therefore in an attachment.<br><br><br>---------- Forwarded message ----------<br>From: "Markus Köberl" <<a href="mailto:markus.koeberl@tugraz.at" target="_blank" rel="noreferrer">markus.koeberl@tugraz.at</a>><br>To: <a href="mailto:linux-fai@uni-koeln.de" target="_blank" rel="noreferrer">linux-fai@uni-koeln.de</a><br>Cc: <br>Bcc: <br>Date: Wed, 11 Oct 2023 13:32:46 +0200<br>Subject: Re: FAI + SaltStack anybody?<br>On Thursday, 5 October 2023 14:59:40 CEST Diego Zuccato wrote:<br>
> Hello all.<br>
> <br>
> Does someone use FAI to install the base system that will be managed by<br>
> Salt?<br>
> I'm trying to integrate 'em but there's still something that doesn't<br>
> "click"...<br>
> <br>
> My current idea is to use Salt to orchestrate the install, but maybe<br>
> it's better left to FAI? How can I "pass around" minion key so I don't<br>
> have to manually re-approve the new key every time?<br>
> The ideal scenario would be: target generates its keypair, sends the<br>
> pubkey to FAI that "certifies" it's from the system being installed and<br>
> passes it to Salt. Should I write a custom fai-monitor (that would be<br>
> needed anyway to disable netboot once system is reinstalled)?<br>
> <br>
> TIA.<br>
<br>
My solution at the moment is non-interactive.<br>
In classes I have a script which asks for username and password for the salt <br>
api to save a cookie which is valid for a 30min.<br>
Later during the fai installation a script uses the cookie to get the salt key <br>
via the salt api. After the first boot salt is doing the rest...<br>
<br>
Instead of using the non-interactive approach I guess you could also provide <br>
the cookie base64 encoded via boot parameter or dhcp. <br>
<br>
<br>
regards<br>
Markus<br>
-- <br>
Markus Koeberl<br>
Graz University of Technology<br>
Signal Processing and Speech Communication Laboratory<br>
E-mail: <a href="mailto:markus.koeberl@tugraz.at" target="_blank" rel="noreferrer">markus.koeberl@tugraz.at</a></blockquote></div>