updates to fai-cd
Hi - I’m running into an issue where it looks like some options in the xorriso command is no longer valid when trying to make a fai-cd iso image. I was wondering if anyone has an updated fai-cd that accounts for this. Details as follow : fai-server - 5.10.3-buster1 xorriso - 1.4.2-4ubuntu1 ubuntu - 16.04.6 LTS Here is what’s in the fai-cd script : echo "Writing FAI CD-ROM image to $isoname. This may need some time." xorriso -report_about HINT -as mkisofs -iso-level 3 \ -iso_mbr_part_type 00 \ -full-iso9660-filenames \ -volid "$vname" -appid "$aname" \ -eltorito-boot boot/grub/bios.img \ -no-emul-boot -boot-load-size 4 -boot-info-table \ --eltorito-catalog boot/grub/boot.cat \ --grub2-boot-info \ --grub2-mbr $NFSROOT/usr/lib/grub/i386-pc/boot_hybrid.img \ -eltorito-alt-boot -e EFI/efiboot.img -no-emul-boot \ -append_partition 2 0xef $scratch/efiboot.img \ -o $isoname -graft-points \ --sort-weight 0 / --sort-weight 1 /boot \ "$tmp" \ /boot/grub/bios.img=$scratch/bios.img \ /EFI/efiboot.img=$scratch/efiboot.img || die 12 "xorriso failed." Some of these options are not valid in the version of xorriso that’s available in 16.04 (or 20.04 for that matter). I’ve even tried looking for this version on a Debian server and they aren’t there. I have several hundreds (roughly 800) mini servers that are deployed in the field that needs updating and the only reasonable way is to use a USB key to re-provision them. Making a cd image using fai-cd would help tremendously. Thanks. Sinh
Re: FAI + SaltStack anybody?
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. 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. On October 5, 2023 at 6:54:51 AM, Laura Smith via linux-fai ( linux-fai@uni-koeln.de) wrote: Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die eigentliche Nachricht steht dadurch in einem Anhang. This message was wrapped to be DMARC compliant. The actual message text is therefore in an attachment. Hi Diego Its been a while since I worked with Salt, but IIRC it sounds like what is not "clicking" is that you need to fix the TOFU problem. Looking back through my notes, it seems https://docs.saltproject.io/en/latest/topics/tutorials/multimaster_pki.html might be worth a read. In particular, maybe "master_sign_pubkey: True" on the Salt master, "verify_master_pubkey_sign: True" on the minion, and the master pubkeys put in "/etc/salt/pki/minion/" on the minions. Then on Salt master all you have to do is approve the new connections as they come online. --- Original Message --- On Thursday, October 5th, 2023 at 13:59, Diego Zuccato < diego.zucc...@unibo.it> wrote: > Hello all. > > Does someone use FAI to install the base system that will be managed by > Salt? > I'm trying to integrate 'em but there's still something that doesn't > "click"... > > My current idea is to use Salt to orchestrate the install, but maybe > it's better left to FAI? How can I "pass around" minion key so I don't > have to manually re-approve the new key every time? > The ideal scenario would be: target generates its keypair, sends the > pubkey to FAI that "certifies" it's from the system being installed and > passes it to Salt. Should I write a custom fai-monitor (that would be > needed anyway to disable netboot once system is reinstalled)? > > TIA. > > -- > 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
Re: FAI + SaltStack anybody?
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
Re: Who is using the ISC DHCP server in their FAI environment?
I use ISC DHCP server with FAI. I have been wanting to migrate to KEA but have not done so. If I could I’d stay on ISC DHCP forever cause kea’s config is just awful. Just really really awful. Sinh On May 27, 2025 at 12:34:18 AM, Thomas Lange (la...@cs.uni-koeln.de) wrote: Hi, I like to know who is using the DHCP server from ISC when doing a FAI network installation. Debian plans to remove this package for the upcoming release (trixie) and I'm not sure how much work it may cause to sysadmin to migrate to a replacement, for e.g. the new DHCPD from ISC called kea. Did anyone already migrated to kea? Do you think you can easily migrate to kea or dnsmasq or other packages? Currently FAI provides examples for the dhcpd.conf for ISC dhcp, but if Debian removes the isc dhcp package, I cannot provide a working config for the trixie release in time and FAI users have to do it on their own. I'll try to convince the Debian release team to keep ISC dhcp for the trixie release, but some people want to remove it , because it's EOL and there will be no security support by Debian any more. What's your oppinion on that? -- best regards Thomas
