Re: Accessing external https repo during install
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.--- Begin Message ---
On Wednesday, 17 January 2024 16:13:02 CET Diego Zuccato wrote:
> Il 17/01/2024 14:15, Carsten Aulbert ha scritto:
> >> How can I have ca-certificates installed when the repository gets added?
> >
> > I think you could either add it into your basefile
>
> Thought that, but would require regular maintenance, regenerating
> basefile every time ca-certificates is updated.
>
> > or add it to your
> > hook to install ca-certificates from Debian first.
>
> That whould be the perfect solution.
>
> > Does that make sense?
>
> Sure it does. I just have to understand how to do it the correct way :)
>
> First issue (that deranged me): I forgot to set SALT class for the
> test-fai host, but files/etc/apt/sources.list.d/salt.list/BOOKWORM got
> copied anyway... some script is fcopy-ing more than expected...
> Fixed (partially) the first issue, hooks/repository.SALT (the one that
> should create salt.list file...) finally got called and attempted to
> install ca-certificate. But it failed. Seems I'm attempting to install
> it too soon.
> Uff. Work for tomorrow...
>
> Tks for all the hints!
I have on the fai server in /etc/fai/nfsroot.conf:
FAI_DEBOOTSTRAP_OPTS="--include=ca-certificates,apt-transport-https"
and /etc/fai/nfsroot-hooks/ca-certificates:
# load deffinition of ${NFSROOT}
. /etc/fai/nfsroot.conf
mkdir -p ${NFSROOT}/usr/local/share/ca-certificates
cp /etc/fai/nfsroot-hooks/ComodoIntermediateCertificates.crt \
${NFSROOT}/usr/local/share/ca-certificates/ComodoIntermediateCertificates.crt
chroot $NFSROOT update-ca-certificates
regards
Markus Köberl
--
Markus Koeberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: markus.koeb...@tugraz.at
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
Re: FAI + SaltStack anybody?
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.--- Begin Message --- On Thursday, 5 October 2023 14:59:40 CEST Diego Zuccato 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. My solution at the moment is non-interactive. In classes I have a script which asks for username and password for the salt api to save a cookie which is valid for a 30min. Later during the fai installation a script uses the cookie to get the salt key via the salt api. After the first boot salt is doing the rest... Instead of using the non-interactive approach I guess you could also provide the cookie base64 encoded via boot parameter or dhcp. regards Markus -- Markus Koeberl Graz University of Technology Signal Processing and Speech Communication Laboratory E-mail: markus.koeb...@tugraz.at signature.asc Description: This is a digitally signed message part. --- End Message ---
Re: Transient secrets
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.--- Begin Message --- On Thursday, 7 July 2022 08:12:54 CEST Diego Zuccato wrote: > Hi all. > > Is there a preferred way to pass a (different) secret to every host > being installed? > > Something to implement a workflow like: > - admin asks Salt to (re)install a host > - salt handles shutdown and switch reconfiguration (OT) > - salt tells FAIserver to enable install of given host > - FAI generates the secret and passes it back to Salt (or Salt generates > the secret and passes it to FAI, as long there's a shared secret) > - the host boots via network and installs as usual, saving/using the > given secret > - FAI (or the reinstalled host) tells Salt reinstall is complete and > Salt "cleans up" (reconfig switches & so on) (OT) > > The only "solution" I could find is to save the secret in > /srv/tftp/fai/pxelinux.cfg/C0A8xxyy in append line, like FAI_FLAGS, > FAI_CONFIG_SRC and FAI_ACTION, but since append line can be at most 255 > chars there's not much space... I's good just for very small "secrets" > (that gets transferred in the clear, hence the need to reconfigure the > switches). I am asking at the beginning (with a script in `class` using dialog) for username and password for the salt api and save a cookie which I later use in a script to get the salt key for the host. The relevant part in the cookie contains of 97 chars and base64 encoded it gets 134 chars therefore it might still be too long. Maybe encrypt the cookie file and pass the password for decryption which could be short enough. Or just make the time the cookie is valid very short. regards Markus Köberl -- Markus Koeberl Graz University of Technology Signal Processing and Speech Communication Laboratory E-mail: markus.koeb...@tugraz.at smime.p7s Description: S/MIME cryptographic signature --- End Message ---
Re: Dualboot-Installations fails for boot to Windows 10 after running fai
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.--- Begin Message ---
On Tuesday, 5 October 2021 19:41:27 CEST Sven Schumacher wrote:
> Hello Markus,
>
> thanks for your hint regarding the PARTUUIDs.
>
> I modified setup-storage (see attached file, Thomas, might by of
> interest) so it takes a look for preserved or resized partitions, and
> saves the PARTUUID before recreating the partition-table and setting
> them back afterwards using the mechanisms setup-storage already has.
As I am following a different approach I am not sure how much I can help.
Hopefully this will help you:
My disk_config:
disk_config disk1 disklabel:gpt align-at:1M fstabkey:uuid bootable:2
# windows boot partition
primary - 450 - -
# uefi boot partition
primary /boot/efi 100 vfat rw
# windows reserved partition
primary -16 - -
# windows C:
primary -142773 - -
primary - 859 - -
# linux:
primary /50G xfs rw,noatime
primary /srv 10G- xfs rw,noatime createopts="-L srv"
primary swap 5G swap rw
primary /home 13G xfs rw,noatime createopts="-L home"
An my mountdisks hooks code:
error=0; trap 'error=$(($?>$error?$?:$error))' ERR # save maximum error code
if [ -z "$BOOT_DEVICE" ]; then
exit 189
fi
# Disk GUID
sgdisk --disk-guid=692A8440-E7A6-4F1E-8D8E-B6ABF895F247 ${BOOT_DEVICE}
# Partiton GUID
sgdisk --partition-guid=1:B8BAA86C-B3D4-4A02-8713-03FE4B7AC42D ${BOOT_DEVICE}
sgdisk --partition-guid=2:BC9CC09F-D739-4FF3-9650-72FD84BD92AB ${BOOT_DEVICE}
sgdisk --partition-guid=3:98D35356-2FB2-4A07-A1F3-1ACF486F8642 ${BOOT_DEVICE}
sgdisk --partition-guid=4:6848A458-2A6C-4C73-AD6D-6B6CC9DAF8D6 ${BOOT_DEVICE}
sgdisk --partition-guid=5:262EFA0A-1DE4-4DC1-B2F7-F203A8D2A712 ${BOOT_DEVICE}
# Partiton type
sgdisk --typecode=1:2700 ${BOOT_DEVICE}
sgdisk --typecode=2:EF00 ${BOOT_DEVICE}
sgdisk --typecode=3:0C01 ${BOOT_DEVICE}
sgdisk --typecode=4:0700 ${BOOT_DEVICE}
sgdisk --typecode=5:2700 ${BOOT_DEVICE}
# Partition name
sgdisk --change-name=1:"Basic data partition" ${BOOT_DEVICE}
sgdisk --change-name=2:"EFI system partition" ${BOOT_DEVICE}
sgdisk --change-name=3:"Microsoft reserved partition" ${BOOT_DEVICE}
sgdisk --change-name=4:"Basic data partition" ${BOOT_DEVICE}
# Partition attributes
sgdisk --attributes=1:set:0 ${BOOT_DEVICE}
sgdisk --attributes=1:set:63 ${BOOT_DEVICE}
sgdisk --attributes=2:set:63 ${BOOT_DEVICE}
sgdisk --attributes=3:set:63 ${BOOT_DEVICE}
sgdisk --attributes=5:set:0 ${BOOT_DEVICE}
sgdisk --attributes=5:set:63 ${BOOT_DEVICE}
exit $error
regards
Markus Köberl
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
Re: Dualboot-Installations fails for boot to Windows 10 after running fai
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.--- Begin Message --- On Monday, 4 October 2021 12:34:35 CEST Sven Schumacher wrote: > What does setup-storage do (or the used programs behind that tool), that > the windows-bootloader can't find the C: partition after using fai? setup-storage recreates the partition table. therefore the partition table and all partitions get different ids. at least with MS-DOS partition table this was the case for the partition id, with GPT partition table I never searched what exactly is necessary. I am using a mountdisks hook to restore the ids using sgdisk. > Thanks for any input... If I didn't find the solution I have to boot 140 > PCs with Windows-USB-Stick to type the bcdedit lines mentioned above... I do have a windows 10 image which I restore on all my laboratory hosts. after the restore I mount the C: partition and edit the registry using chntpw to replace the hostname. If you are interested I can give you my scripts (which are very particular to my system) but they might help you finding a solution. regards Markus Köberl signature.asc Description: This is a digitally signed message part. --- End Message ---
