Re: Making sure to partition the right disk(s)
On Sat, 2024-01-20 at 01:27 +1300, Andrew Ruthven wrote: > On Fri, 2024-01-19 at 09:48 +0100, Thomas Lange wrote: > > > > I use this script to manipulate the disklist: > > http://fai-project.org/download/misc/99-disklist.sh > > Attached is the script which I wrote to do this. It goes in the class > directory. > > Some of our servers have NVMe drives that should be used for operating > system disks, which is why they can be skipped. Although I see a stale comment in there now about the NVMe disks. Ah well. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Making sure to partition the right disk(s)
On Fri, 2024-01-19 at 09:48 +0100, Thomas Lange wrote: > I use this script to manipulate the disklist: > http://fai-project.org/download/misc/99-disklist.sh Attached is the script which I wrote to do this. It goes in the class directory. Some of our servers have NVMe drives that should be used for operating system disks, which is why they can be skipped. > In the next FAI version 6.2 (the release may come in the next few > days) there are more functions to change the order of the disks, like > smallestdisk or matchdisks which can match to a certain serial number. Nice! Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz | 94-disklist-order Description: application/shellscript
Re: Accessing external https repo during install
On Wed, 2024-01-17 at 17:10 +0100, Markus Köberl wrote: > FAI_DEBOOTSTRAP_OPTS="--include=ca-certificates,apt-transport-https" Hey, My approach for this kind of thing is to have a hook that install ca- certificates. Probably updatebase.SALT - or better, updatebase.CACERTIFICATES and have SALT set CACERTIFICATES Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Single FAI server, multiple Debian versions?
Hey Diego, On Wed, 2024-01-17 at 09:06 +0100, Diego Zuccato wrote: > I copied DEBIAN.var to BOOKWORM64.var, then changed the var to > release=bookworm . It'll depend on what you're using as in our profile as well. You need to have a class set that matches the class named used for the basefile you want to use. Are you setting BOOKWORM64? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Single FAI server, multiple Debian versions?
On Tue, 2024-01-16 at 14:15 +0100, Diego Zuccato wrote: > Tks, that's indeed way easier. And more manageable, especially if the > files are kept on a dedicated http server => no changes to nfsroot. They're kept in the config directory structure that is mounted to /var/lib/fai/config . Not in the nfsroot. I use git-annex for tracking the basefiles with git, but without ballooning the size of my git repo. > The con is that the file needs to be saved somewhere on the local system > before being extracted, and that could be a problem with small disks, > while with nfsroot it is accessible as a normal file and does not need > to be copied. Already answered by Thomas. > Will dig this, too. For now I'm trying to get rid of some spurious error > messages (related to PCI addresses that are not available, probably a > BIOS issue) that prevent install to automatically reboot. This is an on-going battle with every new hardware type! Definitely worth doing though. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Single FAI server, multiple Debian versions?
> You can install multiple debian (and even ubuntu) releases from the > same nfsroot, if you run ``debootstrap`` at installtime. It is much faster if you use basefiles, and have one per release you install. See https://fai-project.org/fai-guide/ and search for basefiles. We set a class of $RELEASE_$ARCH and use that to select the basefile. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Disk config with GRUB/EFI, RAID + LVM
Nice, good work. A couple of suggestions... I'd put swap on RAID1, if you have a disk go offline while the system is running, you've lost anything that had been swapped out to the swap on the failed disk. I like to put a 100MB partition at the end of disks in a RAID pair to allow for slightly differing size of a replacement disk. Although currently it seems that any new disk we get is many many GB bigger than the old failed one. I've found that some servers allow the EFI partition to be RAID1, the current servers we're using support that. So no need to copy files around. Cheers, Andrew On Thu, 2023-11-30 at 17:20 +0100, Rémy Dernat wrote: > Ok, FYI, I think I have a working configuration with : > > ``` > # example of new config file for setup-storage > # > # options> > > disk_config disk1 disklabel:gpt fstabkey:uuid bootable:1 > primary - 2G - - > primary /boot/efi 1G vfat rw createopts="-F32" > primary swap 2G swap sw,pri=1 > primary - 0- - - > > #disk_config disk2 sameas:disk1 > disk_config disk2 disklabel:gpt fstabkey:uuid > primary - 2G - - > primary /boot/efi2 1G vfat rw createopts="-F32" > primary swap 2G swap sw,pri=1 > primary - 0- - - > > disk_config raid fstabkey:uuid > #raid1 /boot disk1.1,disk2.1 - - mdcreateopts="--verbose > --metadata=1.0" createopts="-L boot" > raid1 /boot disk1.1,disk2.1 vfat rw,noatime mdcreateopts="--verbose > --metadata=0.90" > raid1 - disk1.4,disk2.4 - - > > disk_config lvm fstabkey:uuid > vg vg_system md1 > vg_system-root / 60G-200G ext4 rw,noatime > vg_system-tmp /tmp 20G-50G ext2 rw,noatime,nosuid,nodev > ##vg_system-scratch /scratch 30%- ext2 rw,noatime > vg_system-home /home 30%- ext4 rw,noatime,nosuid,nodev > ``` > > My previous message was crystal clear. md0 did not have any formatted > filesystem on it. So I added `vfat` option on /boot. > > Best regards, > Rémy > > > Le jeu. 30 nov. 2023 à 16:53, Rémy Dernat <[remy...@gmail.com](mailto:remy...@gmail.com)> a écrit : > > > > > What is strange here, is that md1 is found, as well as md0, but > > contrary to md0, md1 have an UUID ... > > > > However, UUID seems to be retrieve by blkid from /dev/disk/by-id, > > where both md array have their own mdadm UUID, but only md1 have an > > UUID from LVM (with pvdisplay / pvs ) ... > > > > > > Le jeu. 30 nov. 2023 à 14:52, Rémy Dernat <[remy...@gmail.com](mailto:remy...@gmail.com)> a écrit : > > > > > > > > Hi Andrew, > > > > > > Indeed, this removed the syntax issue. However, I have a new error now: > > > > > > ``` > > > /sbin/blkid -c /dev/null -s UUID -o value /dev/md0 had exit code 2 > > > Command had non-zero exit code > > > ``` > > > Indeed, blkid is not able to found md0 UUID. > > > > > > I tried to modify the disk_config file to avoid this error, but I am > > > still stuck with it. Here is what look like my disk_config file now: > > > > > > ``` > > > # example of new config file for setup-storage > > > # > > > # > > > > > > disk_config disk1 > > > primary - 2G - - > > > primary /boot/efi 1G vfat rw createopts="-F32" > > > primary swap 2G swap sw,pri=1 > > > primary - 0- - - > > > > > > #disk_config disk2 sameas:disk1 > > > disk_config disk2 disklabel:gpt fstabkey:uuid > > > primary - 2G - - > > > primary /boot/efi2 1G vfat rw createopts="-F32" > > > primary swap 2G swap sw,pri=1 > > > primary - 0- - - > > > > > > disk_config raid fstabkey:uuid > > > raid1 /boot disk1.1,disk2.1 - - mdcreateopts="--verbose > > > --metadata=0.90" createopts="-L boot" > > > raid1 - disk1.4,disk2.4 - - > > > > > > disk_config lvm fstabkey:uuid > > > vg vg_system md1 > > > vg_system-root / 60G-200G ext4 rw,noatime > > > vg_system-tmp /tmp 20G-50G ext2 rw,noatime,nosuid,nodev > > > ##vg_system-scratch /scratch 30%- ext2 rw,noatime > > > vg_system-home /home 30%- ext4 rw,noatime,nosuid,nodev > > > ``` > > > > > > I also tried to change the raid metadata to 1.0, but that did not > > > change anything. I wrote back ` fstabkey:uuid` behind disk_config raid > > > because it does not fail with syntax error. > > > > > > Thanks for help > > > > > > Le jeu. 30 nov. 2023 à 11:55, Andrew Ruthven <[and...@etc.gen.nz](mailto:and...@etc.gen.nz)> a écrit : >
Re: Disk config with GRUB/EFI, RAID + LVM
Hey, On Thu, 2023-11-30 at 11:14 +0100, Rémy Dernat wrote: > Hi awesome Fai guys, > > I have a weird syntax issue with the following disk_config: > [snip] > disk_config raid disklabel:gpt fstabkey:uuid bootable:1 This line is your problem, remove everything after the word raid. So it should just be: disk_config raid Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: FAI + SaltStack anybody?
On Fri, 2023-10-06 at 20:02 +0200, Henning Glawe wrote: > p.s.: call me biased, as I implemented ``softupdate`` almost 20 years ago > and use it since then as a configuration manager for a few 1k hosts in > various contexts softupdate is very handy. We used to use it at work (and I still do at home) for building Linux VServers, and I have happily used it to bootstrap cloud based instances. The difficulty I run into, and which others might as well, is there is broad knowledge of Puppet, Salt, Ansible, Chef, etc. as well as there being many many modules/recipes/whatever for these tools. Neither of these so much for FAI[0], so the tool used for on-going configuration management tends to be one of these other tools. At work we have a similar model as other people in this thread. FAI to handle the hardware and get a server into a state that it is ready to be taken over by configuration management. For operating system upgrades we do reinstalls rather than dist-upgrades, so FAI also needs to be able to rebuild a server - hence having various secrets able to be deployed during a build. Cheers, Andrew [0] Hmm, is there scope for sharing classes for doing common useful tasks? I have some I can most probably share. Could FAI have a "plugins" directory that mimics the top level of a profile and allow for contained plugins to be installed? -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: FAI + SaltStack anybody?
On Fri, 2023-10-06 at 11:18 +0200, Thomas Lange wrote: > > > > > > On Fri, 06 Oct 2023 21:57:28 +1300, Andrew Ruthven > > > > > > said: > > > This isn't ideal as the secrets are still present in the NFSROOT for > a short > > period of time, but does solve the chicken and egg issue others > mentioned > This reminds me of a solution I once saw. > Put some info into a fifo (named pipe), so only one receiver can read > it. After that the fifo is empty. > > What about having a daemon on the FAI server which serves some secrect > using: > echo secrect | nc -p 12345 -l > > So only one FAI client can read the secrect from port 12345 once. > This may help a little bit. This could help. It could also do some level of validation of the IP/MAC that the request is coming from, especially if you've used fai-chboot. Again not ideal, but better. The thing I like about my solution is that fcopy just works. :) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: FAI + SaltStack anybody?
On Fri, 2023-10-06 at 11:36 +0200, Diego Zuccato wrote: > I really like it a lot! > Not bulletproof but more secure than a file. > > Still no way to have "hooks" run on FAI server? We kind of do this, we call it Semi Automatic Installer (SAI). But the problem is that you still need to have some credentials in the NFSROOT to talk to the server. It is primarily used for fetching and storing answers to questions on the server. This allows us to have interactive builds that can save the answers to the server so the next build can be automatic. Hence the "Semi". -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: FAI + SaltStack anybody?
On Fri, 2023-10-06 at 06:47 +0200, Diego Zuccato wrote: > Il 05/10/2023 15:54, Laura Smith via linux-fai ha scritto: > > 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. > > Actually there are 2 distinct problems: > - pass the pubkey from the minion to FAI during the install (possibly in > an authenticated way) > - authorize that key in Salt from FAI Not related to Salt, but possibly an approach that can be used here. I have a script that we run on the FAI server for managing secrets. It will copy secrets, generating them as required, into the NFSROOT and then remove them after a period of time. I have this handling ssh hostkeys so we can get the same keys on a rebuild. It can handle Puppet keys, including signing them, although we no longer use it for Puppet. This isn't ideal as the secrets are still present in the NFSROOT for a short period of time, but does solve the chicken and egg issue others mentioned and removes the need for a generic "sign any request that comes in" that others have suggested. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: RAID + UEFI
On Wed, 2023-09-20 at 09:52 +0200, Diego Zuccato wrote: > TL;DR: IMO having /boot/uefi on (sw) RAID1 is not worth the headaches. > Long version follows. > > That's quite normal. You should use older RAID format that places > metadata at the end of the partition instead of the newer that places it > at the beginning. And even so it's risky, since one of the partitions > could get modified by other systems (the BIOS, for example) that aren't > RAID-aware (that's also one of the reasons that lead to the newer > format...). Yeah, I tried the older RAID formats, didn't work. ;) What I have considered is having a hook that copies /boot/efi from the "primary" drive to the "secondary". But I'm not sure how safe that is in reality. > Since you're using FAI, it's probably faster to just completely > reinstall the system (possibly preserving data partition(s)) than > risking RAID desync and related headaches. To keep the disk partitions > aligned, you could use the "mirror" space for an extra swap partition :) Heh, maybe. :) We're just going through and rebuilding a bunch of servers now. Better than doing a dist-upgrade. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: RAID + UEFI
Hey, Just a note that I've found that some hardware doesn't like /boot/efi being on RAID1. Which is rather disappointing. But otherwise, the examples that Justin provided look very similar to what I've succesfully used (although sometimes without the RAID1 for /boot/efi!) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Installation of package_config/CLASS.gpg
Hey, This is almost what I did. We already have a postinst for all our files/etc/apt/sources.list.d/X directories to substitute in distro names and URLs, so I added: # See if we need to fcopy a signing key in key=$(grep signed-by= $2 | sed -E 's/.*signed-by=(.+?asc)( |\]).*/\1/') if [ "$key" != "" ]; then fcopy -M $key fi Cheers, Andrew On Tue, 2023-08-22 at 09:46 +0200, Thomas Lange wrote: > I would suggest you are using a hook with an fcopy command to put > those files to some other locations. > > > > > > > On Tue, 18 Jul 2023 21:36:04 +1200, Andrew Ruthven > > > > > > said: > > > Hey, > > I see that FAI since 5.8.7 will install package_config/CLASS.gpg > > into /etc/apt/trusted.gpg.d/ . Apt will then trust all the keyrings > in > > /etc/apt/trusted.gpg.d . This isn't really ideal, and I'd prefer to > use > > Signed-By to specify which GPG keyring to trust for our various > additional > > repositories. > > > How about having task_repository check for another file, say > > package_config/CLASS.gpg_dest that'd allow us to specify where to > copy > > package_config/CLASS.gpg to? > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Installation of package_config/CLASS.gpg
Hey, I see that FAI since 5.8.7 will install package_config/CLASS.gpg into /etc/apt/trusted.gpg.d/ . Apt will then trust all the keyrings in /etc/apt/trusted.gpg.d . This isn't really ideal, and I'd prefer to use Signed-By to specify which GPG keyring to trust for our various additional repositories. How about having task_repository check for another file, say package_config/CLASS.gpg_dest that'd allow us to specify where to copy package_config/CLASS.gpg to? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Automatically disabling PXE boot
On Wed, 2023-06-07 at 10:05 +0200, Diego Zuccato wrote: > Hi Andrew. > > That would be OK, but I don't need (and it's actually undesirable) to > reinstall at every reboot: one of the systems actually requires an extra > reboot to complete the setup... if installation restarts, I'll find the > system in a bootloop... > > Or maybe I didn't understand and you're calling fai-chboot and just not > bothering about DHCP ? Oh, we're not doing a reinstall on each boot, that'd suck. While we aren't using fai-chboot, similar concept. We have a pxelinux.cfg/default file that has: default localboot label localboot localboot 0 So by default the boxes will just boot off the local disk. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Automatically disabling PXE boot
Hey, On Wed, 2023-06-07 at 09:45 +0200, Diego Zuccato wrote: > IIUC hooks are run on the system being installed, so I could use LAST > hook to somehow signal FAI host to run "fai-chboot -d host". But that > would leave DHCP server sending a DHCP OFFER for a PXE boot that's been > disabled. Maybe I'm reinventing the wheel, but couldn't find anything. We just leave our servers to PXE boot. It slows boot down a little, but we don't reboot that often, so, meh. The reduction in mucking around required to enable PXE boot is worth a slightly slow boot in my opinion. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Unable to install etckeeper with FAI - triggers break
Hey Thomas, I find it unlikely that someone would want to install etckeeper into the nfsroot. However, for consistency, I think it'd make sense to remove --pid from fai-make-nfsroot as well, unless there is a good reason to retain it. Cheers, Andrew On Tue, 2023-01-10 at 11:48 +0100, Thomas Lange wrote: > Hi Andrew, > > unshare --pid is also called in fai-make-nfsroot. Does it also > need to be removed in there or only in bin/fai? > > > > > > On Thu, 05 Jan 2023 20:54:28 +1300, Andrew Ruthven > > > > > > said: > > > Hey, > > I've run into an interesting issue now that I've updated an > nfsroot to Bullseye. The change to using unshare in $ROOTCMD in v5.10 > is > > breaking the dpkg trigger for etckeeper. > > > After editing /usr/sbin/fai and removing ' --pid' I get a > successful installation, complete with etckeeper. > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Unable to install etckeeper with FAI - triggers break
Hey,
I've run into an interesting issue now that I've updated an nfsroot to
Bullseye. The change to using unshare in $ROOTCMD in v5.10 is breaking
the dpkg trigger for etckeeper.
The trigger runs: etckeeper post-install, when in turn runs
/etc/etckeeper/post-install.d/50vcs-commit which has in it:
ETCKEEPER_PID=$( ps --no-headers -o ppid "${PPID}" 2>/dev/null | sed
's/^ *//' )
But $PPID is 1, which then causes ETCKEEPER_PID to be set to 0, which
then breaks a later call of ps.
If I change $ROOTCMD to be: unshare --fork --kill-child --mount-proc
chroot /target
Then the trigger runs correctly.
This is what is displayed when it breaks:
-- BEGIN --
root@cc-porwal-prod-kvm1:/# $ROOTCMD etckeeper post-install
error: process ID out of range
Usage:
ps [options]
Try 'ps --help '
or 'ps --help '
for additional help text.
For more details see ps(1).
error: garbage option
Usage:
ps [options]
Try 'ps --help '
or 'ps --help '
for additional help text.
For more details see ps(1).
-- END --
After editing /usr/sbin/fai and removing ' --pid' I get a successful
installation, complete with etckeeper.
Any thoughts? (Well, other than not installing etckeeper!)
Cheers,
Andrew
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
Re: Secure deploy of keys
Hey, On Tue, 2022-12-13 at 14:47 +0100, Diego Zuccato wrote: > What's the recommended way to deploy (or re-deploy) security- > sensitive > objects (just to say one: private ssh key to avoid client warnings > when > redeploying a server)? For things like ssh host keys I have a command that we run which copies them into the NFSROOT, and then a cron job that runs every minute that removes "expired" files from the NFSROOT. Given our NFSROOT is on a restricted network I feel that is sufficient. I know someone who had GPG encrypted tarballs, but that required entering a passphrase during the build process. Another option for ssh which I am considering is using PKI for it. Then servers and clients just need to trust a CA. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Need help on deploying bullseye
Hey Romain, I think that unfortunately the answer to your question is "it depends". With the FAI setup that I use for servers, we can deploy most releases of Ubuntu and Debian. But I've spent quite a bit of effort making it work that way. Our desktop support team only support one version of Ubuntu with their FAI setup, and adjust it for the next LTS when they're ready. Cheers, Andrew On Mon, 2022-07-18 at 11:19 -0400, Romain Pelissier wrote: > Hi, > I have herited of an already FAI setup that deploy debian buster > using pxe and it works great! > Now, I try to use it to deploy bullseye but even if I have ready the > documentation I am still not sure how to proceed with the correct > steps... > Should I modify the existing config or create a new one dedicated to > bullseye and point my server pxe boot to this one? > Even if I set /srv/fai/config/class/DEBIAN.var with release=bullseye > it's not working.. > Let me know if you want me to share some config files. > > Any help will be greatly appreciated :) > Thanks! -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Transient secrets
Hey, Yes, agreed, depends on the use case. For the gear I'm dealing with they're on physically very secure networks and NFS is firewalled off. You could potentially have a kernel token as you suggest and then go to fetch the secrets from a HashiCorp Vault with an approval needing to be issued. I know of someone who used to store GPG encrypted tar files in their FAI profile and you had to enter a GPG key during the build to decrypt them. We do in some cases generate passwords (root and encrypted filesystems) during build and have those emailled with GPG encryption to the relevant parties. Cheers, Andrew On Thu, 2022-07-07 at 08:35 +0200, Diego Zuccato wrote: > Hi Andrew. > > That's an option, but is seems less secure: while PXE net have to be > quite "locked down", NFS could potentially be exposed on a "public" > network (say to handle reinstalls on many networks with a single > server). > If only machines had an "attestation key" by default... Maybe an USB > key > to insert in the machine being reinstalled... Possibly in an internal > slot... Uhm... Still brainstorming... > > Tks, > Diego > > > Il 07/07/2022 08:22, Andrew Ruthven ha scritto: > > Hey, > > > > I'm not sure if this is preferred or not, but the approach I take > > is to > > have a command we run first, that copies any required secrets (and > > will > > generate SSH host keys and puppet certs if required first) into the > > NFS > > root. A cron job runs every 15 minutes and cleans up any of those > > secrets which are older than 2 hours (this could be much shorter). > > > > Cheers, > > Andrew > > > > On Thu, 2022-07-07 at 08:12 +0200, 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). > > > > > > > -- > > > > Andrew Ruthven, Wellington, New Zealand > > and...@etc.gen.nz | > > Catalyst Cloud: | This space intentionally left blank > > https://catalystcloud.nz | > > > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: Transient secrets
Hey, I'm not sure if this is preferred or not, but the approach I take is to have a command we run first, that copies any required secrets (and will generate SSH host keys and puppet certs if required first) into the NFS root. A cron job runs every 15 minutes and cleans up any of those secrets which are older than 2 hours (this could be much shorter). Cheers, Andrew On Thu, 2022-07-07 at 08:12 +0200, 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). > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: 50-host-classes
Hi Marc, On Tue, 2022-04-26 at 14:27 +, Marc Hoppins via linux-fai wrote: > The documentation leads one to the opinion that all hosts sit in the > 50- file which makes it very unwieldy. You can split it up into whatever files you want. You'll just want to be careful if you have multiple files that match as the last match would be what is used. FAI processes the files in the class directory in shell sorting order. We also use multiple Perl scripts that perform a regexes on the hostname and sets classes that way. One script perl per cluster type or customer. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: CD, NFSROOT and expiring DHCP lease
On Thu, 2021-04-29 at 22:48 +1200, Andrew Ruthven wrote: > > > Is there an approach so that ISO images created with fai-cd > > perform > > > DHCP lease renewals? > > As a workaround, you could write a hook, that starts dhclient. > > Since the hooks are on the ISO and will be executed, this should > > work > > until I release a new FAI version with a fix. > > Yup, sure thing. I'll see about doing this tomorrow. I can now confirm that this didn't work, in fact it made things worse! Running dhclient caused a second IP to be allocated to the machine being built which then caused the nfsroot to become unreachable. I wasn't able to get to the bottom of things as I had to get the new servers built. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: CD, NFSROOT and expiring DHCP lease
On Thu, 2021-04-29 at 12:04 +0200, Thomas Lange wrote: > > > > > > On Thu, 29 Apr 2021 21:21:06 +1200, Andrew Ruthven < > > > > > > and...@etc.gen.nz> said: > > > Dracut acts as a DHCP client, but is a single shot only. Once > the > > lease expires nothing on the machine building rebuilt renews > > it. > Hi Andrew, > > you are right, in FAI the kernel (or maybe the initrd) configures the > IP addresses and sets valid_lft and preferred_lft to forever. It is the kernel which performs the DHCP request, and renews it as required. > Then a one-shot dhcp request is done, but with a different config and > dhcp script to write the file boot.log. > FAI does not start the dhclient to automatic renew the ip leases. > This > is a bug. Cool. Good to know I'm not going crazy! > > Is there an approach so that ISO images created with fai-cd > perform > > DHCP lease renewals? > As a workaround, you could write a hook, that starts dhclient. > Since the hooks are on the ISO and will be executed, this should work > until I release a new FAI version with a fix. Yup, sure thing. I'll see about doing this tomorrow. > It would be nice if you could file a bug report for this. Done. :) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
CD, NFSROOT and expiring DHCP lease
Hey, I've successfully created a boot CD with fai-cd that supports LACP and VLAN. Dracut acts as a DHCP client, but is a single shot only. Once the lease expires nothing on the machine building rebuilt renews it. Using a traditional PXE boot the kernel takes care of renewing the lease. Is there an approach so that ISO images created with fai-cd perform DHCP lease renewals? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
Re: preserve_* options and luks partitions
On Fri, 2021-03-12 at 10:26 +0100, Thomas Lange wrote: > > > > > > On Thu, 11 Mar 2021 22:43:31 +1300, Andrew Ruthven < > > > > > > and...@etc.gen.nz> said: > > > Is the reason that setup-storage can't just leave these volumes > alone > > if they already exist? > Hi Andrew, > > the setup-storage tool was written long time ago mainly by a guy > who is not active in FAI any more. Another guy added btrfs support > and > I have some minor knowledge about how this tool works. But I do not > know much about all the crypt stuff and why is was decided not to > support crypt configs. Maybe noone though that people will need this. > > Preserving in setup-storage is not just "leave this untouched" but > may > include much more logic behind the scene. For example, > when setup-storage preserves a physical partition, it needs to know > the > start and end sector of it because it will not leave the partitioning > for this disk untouched, but it writes a new partitioning (because > other partitions may change) but preserves the start and end sector > of > the physical partition which is marked as preserve. > > This may be a reason why it was decided not to support crypt setups. > Maybe you will find some explanation in the git logs. Yup, fair enough. I did start going down the path of trying to add logic to handle preserving the encrypted volumes but ended up decided it would be rather tricky. Instead for this situation I'll just ignore the partitions in FAI and fcopy in the relevant supporting files needed. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | Catalyst Cloud: | This space intentionally left blank https://catalystcloud.nz |
preserve_* options and luks partitions
Hey,
We're rebuilding some servers which have some encrypted LVs using luks
for storing data. I would really like to preserve these LVs over the
rebuild without needing to modify the disk_configs and deploying my own
fstab files.
I have tried setting preserve_lazy for them, but when I test this, the
encrypted volumes are recreated. Looking in Volumes.pm I found this:
} elsif ($config eq "CRYPT") {
# We don't do preserve for encrypted partitions
next;
Which is probably what I'm running into.
It would be really nice if we could preserve encrypted LVs. I'm already
copying the keys back into place, and the partitions don't need to be
mounted for the build phase.
Is the reason that setup-storage can't just leave these volumes alone
if they already exist?
Cheers,
Andrew
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |
systemd-udevd issues with Buster nfsroot
Hey, I've just switched to using a Buster nfsroot and I sometimes encounter issues on rebuilding machines, while setup-storage is running errors like this appear: [ 67.003059] systemd-udevd[2520]: sdb1: Failed to process device, ignoring: Resource temporarily unavailable And then setup-storage is unable to use that block device after this point and the installation fails. Is anyone else encountering issues like this? Any suggested fixes? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2021, Canberra, AU Catalyst Cloud:| http://lca2021.linux.org.au/ https://catalystcloud.nz|
Re: AW: Install Fedora CoreOS using FAI
On Mon, 2020-04-20 at 22:40 +0200, Rémy Dernat wrote: > Hi > > I have a couple of questions. > > - Do you deploy this system to operate a k8s cluster ? No, I was requested to build this system, which will be a pet, to run some docker containers for Gitlab & Prometheus. I have just raised some concerns this morning that it might not be the best operating system for the use case I've installed it for... I'll see how that discussion goes. For our managed k8s platform (using Magnum with OpenStack) we just spin up instances running Fedora CoreOS in our public cloud. > - If so, I imagine you disable the swap (?). But why are you > deploying this stack over bare-metal, with no VM ? For our k8s clusters we aren't using my FAI process. I believe that swap is disabled in the k8s clusters. I should note that I'm just preparing the base server with filesystems built. I would then expect someone else to use configuration management tools to then customise the server. > - Why not using kickstart, which is the redhat standard tftp system ? > (I mean, I am a big of FAI and its powerful class system, but anyway > that choice seems a bit odd to me), We aren't a RedHat shop, we're a mostly Ubuntu shop with a bit of Debian. Because of that I don't have a Kickstart environment kicking (sorry) around, but I do have a FAI one. ;) I also started with the PXE install process that is documented in the Fedora CoreOS docs and which makes no mention of Kickstart [0]. > - btw, why not using k3s, rancherOS or whatever other k8s ready > distro ? Different use case. Also a colleague was very keen on us using (or at least trying) Fedora CoreOS for this server. > I have my opinion about these last questions, but I would also like > to hear yours. To honest I haven't looked into the various other options out there, my colleague has been. > Finally, I also had to deal with httpd/tftp issues. It depends on > your booting system (I am using syslinux 6.0.4 + lighttpd for UEFI > booting systems while I am using basic tftp for legacy boot clients). Well... I'm still using legacy boot for these machines. I've been meaning to get UEFI network booting set up, but I just haven't had the time. I thought I'd try and do that this month while we're in lockdown, but I've been busy! Cheers, Andrew [0] https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/ -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2021, Canberra, AU Catalyst Cloud:| http://lca2021.linux.org.au/ https://catalystcloud.nz|
Re: AW: Install Fedora CoreOS using FAI
Hey, Nice. I had considered using HTTP, but didn't want to deviate from the "recommended" approach. Well. Up until I decided to completely the approach. ;) That is also a much smaller initrd! The main reason I changed was to be able to configure the disk layout, the much faster build was a very pleasant side effect. Cheers, Andrew On Mon, 2020-04-20 at 06:33 +, Schulz, Reiner wrote: > For our OpenShift we use http to load the PXE file: > > /var/lib/tftpboot/gpxelinux.0 > > dhcpd.conf: > filename "gpxelinux.0"; > > nginx: > $ ls -lh /usr/share/nginx/html/rhcos-4.2.18-x86_64-* > 63M 11. Feb 17:04 /usr/share/nginx/html/rhcos-4.2.18-x86_64- > installer-initramfs.img > 7,8M 11. Feb 17:04 /usr/share/nginx/html/rhcos-4.2.18-x86_64- > installer-kernel > 703M 11. Feb 17:04 /usr/share/nginx/html/rhcos-4.2.18-x86_64-metal- > bios.raw.gz > > Reiner Schulz -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2021, Canberra, AU Catalyst Cloud:| http://lca2021.linux.org.au/ https://catalystcloud.nz|
Install Fedora CoreOS using FAI
Hey, I've spent the last couple of days trying to deploy Fedora CoreOS to some physical hardware for a colleague using the official PXE installer. It wasn't very pleasant, and just wouldn't work reliably. A few interesting aspects I encountered: 1) The PXE installer for it has a 618MB initrd file. This takes quite a while to transfer via tftp! 2) It can't build software RAID for the main install device, and it seems very finicky to build other RAID sets for other partitions. 3) And, well, I just kept having problems where the built systems would hang during boot for no obvious reason. 4) The time to do an installation was incredibly long. During the night I got feed up with that and wrote a FAI profile that'd do it instead. I can now use setup-storage using our standard disk_config files. A big bonus is that a rebuild, timed from typing reboot to a fresh login prompt is 10 minutes - and this is on physical hardware so includes BIOS POST and RAID controller set up, twice each. The FAI Profile I developed for this is located here: https://github.com/catalyst-cloud/fai-profile-fedora-coreos I thought this might be of interest to other people, and is potentially a good example of how we can easily deploy other operating systems using FAI. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2021, Canberra, AU Catalyst Cloud:| http://lca2021.linux.org.au/ https://catalystcloud.nz|
Re: FAI build using a small disk image with LACP support
On Fri, 2020-02-28 at 09:24 +0100, Thomas Lange wrote: > > > > > > On Fri, 28 Feb 2020 16:21:38 +1300, Andrew Ruthven < > > > > > > and...@etc.gen.nz> said: > > > All the servers support Redfish, so I can script uploading a > disk image > > to be booted from. > > > What I'm thinking is prepare a FAI boot image based on an > nfsroot, with > > minimal configuration to bring up a degraded LACP bond. > > > Has anyone already done this? > No. But > using fai-cd you can create different flavours of a boot CD. > A boot CD with just the kernel and the initrd, or a CD including > additionally the nfsroot. > > In your case a boot only CD (kernel+initrd) should be fine. Have a > look at the man page dracut.cmdline(7) (which we are using to build > the initrd). This includes already options for bonding: [snip] Ah ha! That sounds like it would be ideal, I'll give it a shot and report back. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz| linux.conf.au 2020, Gold Coast, AU https://catalystcloud.nz |https://lca2020.linux.org.au
FAI build using a small disk image with LACP support
Hey, I have some servers which I need to build which have all their network interfaces (other than the dedicated service processor port) set up in LACP bonds. This means that PXE can't boot as PXE can't talk LACP (even in degraded mode). What we've been doing so far is changing the switches for the duration of the server build to remove LACP from the switch ports, do the FAI (re)build, then re-add the LACP. This is a drag. All the servers support Redfish, so I can script uploading a disk image to be booted from. What I'm thinking is prepare a FAI boot image based on an nfsroot, with minimal configuration to bring up a degraded LACP bond. Has anyone already done this? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud:|https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: Upgrade error in nfsroot
Hey, I've found that this will happen if fai-make-nfsroot bails out part way through the update (or build) of the nfsroot. Really confused me the first time I hit it! Cheers, Andrew On Wed, 2020-02-26 at 09:20 +0100, Andreas Heinlein wrote: > Hello, > > I have to correct myself: upgrading the nfsroot worked, but the NFS > root is not functional now. When booting, it says "cannot execute > /etc/init.d/rcS". Indeed, /etc/init.d/rcS does not exist. > > Is rcS supposed to be a real file or a link somewhere? > > Thanks, > > Andreas > > Am 26.02.20 um 08:31 schrieb Andreas Heinlein: > > Hello, > > > > when upgrading FAI inside the nfsroot with 'fai-make-nfsroot -v -k > > -N', I got: > > > > Preparing to unpack .../15-fai-nfsroot_5.9.2_all.deb ... > > dpkg-divert: error: 'diversion of /etc/init.d/rcS to > > /etc/init.d/rcS.orig by fai-nfsroot' clashes with 'diversion of > > /etc/init.d/rcS to /etc/init.d/rcS.distrib by fai-nfsroot' > > dpkg: error processing archive /tmp/apt-dpkg-install-hXzBfK/15-fai- > > nfsroot_5.9.2_all.deb (--unpack): > > new fai-nfsroot package pre-installation script subprocess > > returned error exit status 2 > > > > when upgrading FAI from 5.9.1 to 5.9.2 > > > > I had to manually chroot to the nfsroot and remove the diversion, > > then it worked. Maybe this should be included in the preinst > > script. > > > > Bye, > > > > Andreas > > > > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud:|https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: Update for Trusty PPA?
On Fri, 2020-01-03 at 08:56 +0100, Thomas Lange wrote: > > > > > > On Fri, 03 Jan 2020 11:49:52 +1300, Andrew Ruthven < > > > > > > and...@etc.gen.nz> said: > > > Would it be possible to get the fai-server available for Trusty > from > > http://ppa.launchpad.net/fai/ppa/ubuntu updated so that at lase > fai- > > make-nfsroot includes the fix to run mkdir -p $NFSROOT/dev/pts > in the > > upgrade_nfsroot function? > Hi Andrew, > > I do not know how maintains the PPA. I only work on the Debian > versions. Hey Thomas, That's fair enough. I was hoping someone responsible for that PPA would be on this list. I've also posted the request to their mailing list. Hopefully someone will action it. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud:|https://lca2020.linux.org.au/ https://catalystcloud.nz|
Stretch+ NFSROOT for building Ubuntu Trusty and Xenial
Hey, If you use Stretch or beyond as the NFSROOT to build anything less than Ubuntu 16.10 with ext4 filesystems, then those filesystems can't be fsck'ed on the resulting system. Because of this I've had to keep a Jessie NFSROOT around to build those systems. But I finally encountered a system which can't be built by Jessie with my FAI Profile [0]. However, there is a fix! This assumes that you mount an NFSROOT using aufs or overlayfs so any modifications are transient. Use a hook to modify /etc/mke2fs.conf if building affected systems. In my case I create a class called UBUNTU or Ubuntu machines, so I created hooks/partition.UBUNTU with the following content: -- Begin -- #!/bin/bash # Trusty and Xenial can't fsck ext4 filesystems with the metadata_csum # flag. # See: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997 ifclass -o XENIAL TRUSTY \ && sed -i 's/,metadata_csum//' /etc/mke2fs.conf -- End -- Cheers, Andrew [0] I run lspci during the build to identify PCI cards which need customised actions, and a new server uses 32 byte PCI IDs which lspci on Jessie doesn't support. -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz| linux.conf.au 2020, Gold Coast, AU https://catalystcloud.nz |https://lca2020.linux.org.au
Update for Trusty PPA?
Hey, Would it be possible to get the fai-server available for Trusty from http://ppa.launchpad.net/fai/ppa/ubuntu updated so that at lase fai- make-nfsroot includes the fix to run mkdir -p $NFSROOT/dev/pts in the upgrade_nfsroot function? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz| linux.conf.au 2020, Gold Coast, AU https://catalystcloud.nz |https://lca2020.linux.org.au
Re: Using NFS v4 when mounting the nfsroot
That's awesome! On Wed, 2019-09-18 at 17:12 +0200, Thomas Lange wrote: > Since a long time, I've tried using NFS v4 for the nfsroot. This did > not worked since FAI uses overlayfs for making the read-only nfsroot > writeable. Therefore FAI force a NFS v3 mount for the nfsroot which > works nicely. > > But now it's possible to use NFSv4. I put some effort in debugging > the > setup, and asked the overlayfs maintainers for help. It's a > complicated mixture of NFS and acl support (POSIX and nfs4 acl) and > what overlayfs expects from the filesystems in respect to certain > xattr. There may be an improvement inside overlayfs in the future. > But > currently we can use NFS v4 for the FAI nfsroot with a very simple > change. Just disable acl for the exported filesystem on the FAI > server > which holds /srv/fai/nfsroot. More is described here: > > http://fai-project.org/fai-guide/#_a_id_nfsv4_a_how_to_use_nfs_v4_with_the_nfsroot -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud:|https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: Limitation on VG name in setup-storage?
Hey Thomas,
On Tue, 2019-07-02 at 13:38 +0200, Thomas Lange wrote:
> > > > > > On Tue, 02 Jul 2019 22:57:48 +1200, Andrew Ruthven > > > > > etc.gen.nz> said:
>
> > When we manually create them, we tend to name our VGs for SSDs
> as: vg-
> > ssd[0-9]+ .
>
> > However, setup-storage doesn't like that and ends up confused
> with the
> > colums on the vg line in the disk_config file.
>
> > Would it be able possible to have VG names allow hyphens?
> Not sure, if this can be done easily. In the FAI example we use a
> hyphen
> in the lv name, but not for vg.
>
> Maybe this code in Parser.pm in line 936 is responsible for the
> limitation:
> name: m{^([^/,\s\-]+)}
>
> You could try to remove \- and see if setup-storage is still working.
Yes, that works okay.
Cheers,
Andrew
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU
Catalyst Cloud: | https://lca2020.linux.org.au/
https://catalystcloud.nz|
Limitation on VG name in setup-storage?
Hey, When we manually create them, we tend to name our VGs for SSDs as: vg- ssd[0-9]+ . However, setup-storage doesn't like that and ends up confused with the colums on the vg line in the disk_config file. Would it be able possible to have VG names allow hyphens? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: MD devices are not wiped if LVM exists
Hey Jerry, That indicates to me that the MD is still running for some reason. I have occasionally had that as an intermittent fault, but I can't recall what I did to resolve it. Sorry, Andrew On Tue, 2019-07-02 at 11:34 +0100, Jerry Steele wrote: > Hi Andrew, > > Many thanks for that, however, that seems to bring up another issue. > During the partitioning step, it is able to create all the underlying > partitions, but fails with: > > Executing: yes | mdadm --create /dev/md0 --level=raid1 --force --run > --raid-devices=2 /dev/sda1 /dev/sdb1 > (STDERR) mdadm: cannot open /dev/sda1: Device or resource busy > > I've checked a couple of things as described here (https://www.thegee > kdiary.com/mdadm-cannot-open-dev-sda1-device-or-resource-busy/) and > here (http://dev.bizo.com/2012/07/mdadm-device-or-resource- > busy.html), but that didn't seem to help. > > Is this something you've come across before whan using this hook? > > Thanks > > Jerry > > > > > > > -- > --- > > Jerry Steele > Telephone: +44 (0)7492 910225 > GPG: 43A3A8C6 > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: Short circuit dracut?
That. Is. Brilliant. Thank you, 'ipappend 2' worked beautifully! On Tue, 2019-07-02 at 08:12 +0100, Justin Cattle wrote: > If you're using PXELINUX to boot, you can use the ipappend option > like this in your pxe config: > > ipappend 2 > > That will make it add this to the kernel comandline for the device it > pxe'd from: > > BOOTIF= > > So dracut _should_ only use that interface and ignore the others. > > > If that's not working for you for some reason, another approach would > be to just change the timeouts. > This one is 60 seconds by default: > > rd.net.timeout.iflink=10 > > ..or even less if that will still work for the interface you do want > configured :) > > > > Cheers, > Just > > > On Tue, 2 Jul 2019 at 07:29, Andrew Ruthven > wrote: > > Hey, > > > > I think this has been asked before (possibly by me), but is it > > possible > > to short circuit dracut so it stops processing interfaces as soon > > as it > > has a successful DHCP responses? > > > > I'm doing some test builds on a machine with 10 interfaces and > > dracut > > takes 60 seconds to timeout on each interface... > > > > Cheers, > > Andrew > > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz|
Short circuit dracut?
Hey, I think this has been asked before (possibly by me), but is it possible to short circuit dracut so it stops processing interfaces as soon as it has a successful DHCP responses? I'm doing some test builds on a machine with 10 interfaces and dracut takes 60 seconds to timeout on each interface... Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: MD devices are not wiped if LVM exists
On Mon, 2019-07-01 at 16:10 +0200, Thomas Lange wrote: > You can write a simple hook, which is then executed before > task_partition. Therefore, create a shell script > hooks/partition.DEFAULT Hey, Here is what I have as hooks/partition.WIPEDISKS it'll stop any MDs or VGs that were started by the kernel and eradicate anything from the disks. Based on a hook written by W. Walkowiak in 2013, but modified over the years to fix various new behaviours I've discovered. Save the file, set a class of WIPEDISKS and, well, all your data will be gone. ;) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz| partition.WIPEDISKS Description: application/shellscript
Re: Raspberry PI 3 B+
Hey, On Fri, 2019-04-26 at 06:56 +0200, Daniel Haensse wrote: > Dear all > > I read that raspberry pi supports PXE boot and that it is enabled > per > default on the latest B+ version. I'm wondering if there is anybody > out > there using it with plain debian or raspbian yet? > > Maybe even on qemu with arm emulation on x64 platform? I wasn't aware that PXE boot was enabled by default now - that's much nicer! I have a Pi 3B+ here which I can't use as the SD card slot is damaged and we didn't enable PXE boot before the slot was damaged. Yes, I'm doing this with an NFSROOT provided from a Debian Stretch machine as the server. I install the NFSROOTs using debootstrap with -- foreign, which allows to just chroot into them if I need to compile things, or install other packages. This is very handy! I'm not using FAI to do this yet. ;) All of this is currently deployed via Ansible playbooks. I've been meaning to write a blog post about this and publish the playbooks... Information from my previous iteration is here: http://blog.etc.gen.nz/archives/131-Network-boot-a-Raspberry-Pi-3.html Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: fai-cd - encryption possibilities
Hi Justin, On Fri, 2019-03-22 at 22:36 +, Justin Cattle wrote: > > What I actually want to do is, produce an ISO using the fai-cd > utility, but make some of the contents of that ISO encrypted. > So, not encrypting the disks in the server, but part or all of the > ISO used to build the server. Some years ago a colleague of mine wrote some logic for FAI where secrets could be contained within a GPG encrypted file which was unpacked during installation. Would that do the job for what you're after? I've tracked the script down (and just fixed a bug in it!), but none of the other tooling around it exists any longer (like how to make the encrypted file, or how to manage GPG keys). Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2020, Gold Coast, AU Catalyst Cloud: | https://lca2020.linux.org.au/ https://catalystcloud.nz|
Re: Solved: Problem with disk_config in a KVM Client
Hey, Because of problems like this and a few others, I always wipe the disks before partition runs using a hook... Cheers, Andrew On Sat, 2019-01-05 at 12:15 +0100, Christian Meyer wrote: > Hello there, > > this mail is just for the archive. It's about my second problem with > setup_storage, but that has been my fault (misconfiguration). Perhaps > it's a bug in setup-storage, too, but it can be worked around easily. > > I had problems with disk_config and a virtual disk in a virtual > machine. > > Using a valid configuration (no problems for real hardware), I got: > ... > Using config file: /var/lib/fai/config/disk_config/DEFAULT > Executing: wipefs -a /dev/vda1 > (STDERR) wipefs: error: /dev/vda1: probing initialization failed: > File > or directory not found. > Command had non-zero exit code > > Error in task partition. Code 710 > > > Problem was that I previously formated the virtual disk with a > filesystem (ext4) from KVM host. > Because of this it wasn't detected as a drive and so no new MBR could > be created. > > I found out / solved it using cfdisk in the virtual machine. > cfdisk warned me that the device has an "ext4 signature" and that it > will be destroyed when continuing. > So i did it and with next reboot FAI installed without an error. > > Christian > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2019, Christchurch, NZ Catalyst Cloud: | https://lca2019.linux.org.au/ https://catalystcloud.nz|
Re: Issue Stretch nfsroot on Trusty
On Thu, 2018-11-22 at 13:06 +0100, Thomas Lange wrote: > OK, I will just add the mkdir into FAI. I guess an older deboostrap > version does not create this device. Cool, thank you. But, it does occur to me that this'll only help if the PPA for Ubuntu is updated. ;) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2019, Christchurch, NZ Catalyst Cloud: | https://lca2019.linux.org.au/ https://catalystcloud.nz|
Re: Issue Stretch nfsroot on Trusty
Hi Thomas, On Wed, 2018-11-14 at 14:03 +0100, Thomas Lange wrote: > Hi Andrew, > > is this a trusty nfsroot or a Debian nfsroot on a trusty server? > Maybe > send the fai-make-nfsroot.log to me. > I've checked all Debian and Ubuntu basefiles I've created (using a > debootstrap on a Debian machine) and they always include /dev/pts. > Maybe > the debootstrap on trusty do not create /dev/pts inside the nfsroot. This is building a stretch nfsroot on a trusty server. I've just run debootstrap manually as: sudo debootstrap stretch test http://debian.catalyst.net.nz/debian I: Retrieving Release I: Retrieving Packages I: Validating Packages ... puck@trusty_server:~$ ls -l test/dev/pts ls: cannot access test/dev/pts: No such file or directory puck@trusty_server:~$ And building a jessie debootstrap, dev/pts does exist within it. > > This might just be an issue on Trusty, not sure, but Thomas, > what do > > you think about adding that mkdir -p? > I can do this, but I would like to know if debootstrap on Ubunu > causes > this issue. I've repeated building stretch on a sid host and dev/pts does exist within it. On both trusty and sid, /usr/share/debootstrap/scripts/stretch and jessie are all symlinks to the sid script. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz| linux.conf.au 2019, Christchurch, NZ https://catalystcloud.nz | https://lca2019.linux.org.au
Issue with dracut 048 and Ubuntu
[Time to rewrite this a third time as I've learnt more! But I'll include some of my learning steps in the hope that if people find this via web searches it might resolve their issues.] Hey, I've just spent the past few hours tearing my hair out trying to get a build to work. Finally got there! The nfsroot: Stretch, FAI 5.7.2 and initially dracut 048. The server: Ubuntu Trusty (I know), with FAI 5.3.2 from the FAI PPA. The root cause of my issue was that fai-make-nfsroot bailed out of building my nfsroot because of this error: mount: mount point /srv/fai/nfsroot.stretch/dev/pts does not exist I didn't think too much about that, but noticed no kernel was installed so then ran: fai-make-nfsroot -k But, I found that dracut 048 (from fai-project repo) wouldn't mount my nfsroot, with the dreaded "nfs: Protocol not supported" error. I started out with a 4.18 backports kernel (to try and support a new network card), then 4.17, then finally the Stretch 4.9 kernel. Still busted. I checked my other nfsroots, and they're all using dracut 044, so I downgraded. Bingo, working. Next issue was that I didn't get a /etc/init.d/rcS symlink pointing to /usr/sbin/fai. I've never had that issue before! I manually created the symlink and managed to get a server build to work. But this didn't feel right, so I dug a bit more. Turns out that mount up above failed because for whatever reason, $NFSROOT/dev/pts didn't exist so the mount call in upgrade_nfsroot() failed. Adding a mkdir -p $NFSROOT/dev/pts before the mount resolved the issue. And now I have a working nfsroot, with dracut 048 in it. I haven't tried the 4.18 kernel as it turns out the 4.9 kernel supports these network cards. This might just be an issue on Trusty, not sure, but Thomas, what do you think about adding that mkdir -p? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz| linux.conf.au 2019, Christchurch, NZ https://catalystcloud.nz | https://lca2019.linux.org.au
Re: FAI.me service now supports creation of VM disk images
This is very cool. We can almost get OpenStack Glance to consume the generated images directly: openstack image create puck-faime glance location-add \ --url https://images.fai-project.org/files/$your_file puck-faime But it currently downloads the compressed file and stores the compressed file, it doesn't even try to decompress it. There is the potential to use a Glance Task to decompress the image, but that requires someone with the admin role (a cloud operator) to set it up: https://docs.openstack.org/glance/latest/admin/tasks.html Currently the only option is to get it locally, decompress it, then upload the image. Cheers, Andrew On Tue, 2018-03-13 at 16:54 +0100, Thomas Lange wrote: > A few days ago, the new feature of the FAI.me build service was > added. > Additionally to creating an installation image, FAI.me can now build > bootable disk images. These disk images can be booted in a VM like > KVM, Virtualbox or VMware or openstack. > > You can define a disk image size, select a language, set a user > password, select a Debian distribution and enable backports just by > one click. It's possible to add your public key for access to the > root > account. This can also be done by just specifying your GitHub > account. > Several disk formats are supports, like raw (compressed with xz or > zstd), qcow2, vdi, vhdx and vmdk. And you can add your own list of > packages, you want to have inside this OS. After a few minutes the > disk images is created and you will get a download link, including a > log the the creation process and a link to the FAI configuration that > was used to create your customized image. > > The new service is available at > >https://fai-project.org/FAIme/cloud > > If you have any comments, feature requests or feedback, do not > hesitate to contact me. > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: LVM+Encryption
Hi David, On Mon, 2018-03-05 at 14:12 -0300, Davinder Chandhok wrote: > Hi, > > I've set up an Ubuntu install profile that configures the disk in the > following way: See the disk_config file you have would be helpful to diagnose what is going on. In case it's helpful, here's what I use for laptops, we also have some other scripts to set a random passphrase and email it encrypted to certain people. -- begin -- disk_config sda bootable:1 primary /boot256M ext3 defaults primary -1024M- -- disk_config cryptsetup luks:"some default passphrase" -/dev/sda2-- # config the LVM disk_config lvm vg vg0 /dev/sda2 vg0-root/10G ext4 rw,errors=remount-ro vg0-swapswap 4G swap defaults vg0-home/home4G ext4 defaults vg0-tmp /tmp 4G ext3 defaults vg0-var /var 4G ext4 defaults -- end -- Cheers. Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: Several Questions
On Tue, 2018-02-27 at 09:23 +0100, Thomas Lange wrote: > > > > > > On Mon, 26 Feb 2018 17:40:14 -0800, Bill MacAllister <bill@ > > > > > > ca-zephyr.org> said: > > > prevent fsck from running. Specifically metadata_csum is > preventing > > fsck from running. How would we specify a setup-storage to > create file > > systems without that option? > This is already in FAI since FAI 5.4. Add this into the disk_config > for XENIAL: > createopts="-O ^metadata_csum" Any chance of setting some default createopts from an environment variable? I use generic disk_configs, like QEMU_GUEST for any distro if an VM is being built. It'd be nice to not have to special case all the Ubuntu >= XENIAL distros. Then in my UBUNTU.var file I can set createopts if need be (I set classes like WILY_GT for example, which is an Ubuntu release greater than WILY). Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: FAI 5.5 released and new ISO images
On Thu, 2017-11-09 at 11:40 +0100, Thomas Lange wrote: > > > > > > On Thu, 09 Nov 2017 22:48:37 +1300, Andrew Ruthven <andrew@ > > > > > > etc.gen.nz> said: > > > But you missed my pull request on github to add -S to the help > output > > of the fcopy command. ;) > No, I added it short time before the release. > https://github.com/faiproject/fai/commit/5f8e606b525c1760f831c2df7e6e > f6761c4e2dcd Ah ha! ;) -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: FAI 5.5 released and new ISO images
On Wed, 2017-11-08 at 18:20 +0100, Thomas Lange wrote: > The new FAI version 5.5 supports a very nice feature in fcopy. Using > -S, > fcopy itself can do variable substitution, which may replace your > preinst scripts. Until now preinst scripts for fcopy were used for > doing variable substitution. We also got rid of the need to have > aptitude installed. I stumbled upon this new feature a couple of days ago. Fantastic, most of my preinst fcopy scripts were doing exactly this. But you missed my pull request on github to add -S to the help output of the fcopy command. ;) Thank you! -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: New video of FAI 5.4
Now this could be useful. Taking a network boot RPi with Raspbian and customising it via Ansible is painfully slow. If I can use FAI to just build the nfsroot on a server in the correct fashion, then boot from it will be very very nice. On Sun, 2017-10-08 at 13:12 +0200, Thomas Lange wrote: > I've created a new video that show how to create an ARM64 disk image > on an x86 64bit machine using fai-diskimage. FAI needs about 6 > minutes > to create this cross-architecture disk image. Later I show how to > boot > this image with Qemu. The video can be found on > http://fai-project.org/screenshots/ > > The log files of this installation are available at > https://fai-project.org/logs/armhost/last/ > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: FAI for ARM image building
On Tue, 2017-10-10 at 09:30 +, Holger Levsen wrote: > Appearantly five years ago I also learned to use backups here, so > this is what I > use currently: I have a hook that installs and configures etckeeper as early as possible, and then I run a etckeeper commit as a script in LAST as well. ;) -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2018, Sydney, AU New Zealand's only Cloud: | Just a little bit of history https://catalyst.net.nz/cloud | http://linux.conf.au
Re: Customise settings for cryptsetup
On Thu, 2016-09-22 at 00:48 +0200, Thomas Lange wrote:
>
> Sure. I plan to release FAI 5.2 in one week, so if you like to get
> this included, sent a patch soon.
Patch attached. I'm happily building servers with it.
This is my first time using RecDescent, so there may be a better
approach than that I've done.
Cheers,
Andrew
--
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU
New Zealand's only Cloud: | The Future of Open Source
https://catalyst.net.nz/cloud | http://linux.conf.auFrom d2a718357da1d46b8ef5494709f4403172d4c353 Mon Sep 17 00:00:00 2001
From: Andrew Ruthven <and...@etc.gen.nz>
Date: Mon, 26 Sep 2016 12:09:29 +1300
Subject: [PATCH] Allow specifying options to cryptsetup
---
debian/changelog | 3 +++
lib/setup-storage/Commands.pm | 16 +---
lib/setup-storage/Parser.pm | 8 +++-
man/setup-storage.8 | 9 -
4 files changed, 31 insertions(+), 5 deletions(-)
mode change 100644 => 100755 lib/setup-storage/Commands.pm
diff --git a/debian/changelog b/debian/changelog
index 76c7e82..b048769 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -52,6 +52,9 @@ fai (5.2~beta19) UNRELEASED; urgency=low
[ Paul Schulz ]
* setup-storage.8: add documentation for luks:
+ [ Andrew Ruthven ]
+ * setup-storage: Add lukscreateopts to disk config file.
+
-- Thomas Lange <la...@debian.org> Thu, 15 Sep 2016 04:09:52 +0200
fai (5.1.2) unstable; urgency=low
diff --git a/lib/setup-storage/Commands.pm b/lib/setup-storage/Commands.pm
old mode 100644
new mode 100755
index 9606ed5..31898ca
--- a/lib/setup-storage/Commands.pm
+++ b/lib/setup-storage/Commands.pm
@@ -164,6 +164,7 @@ sub handle_oldstyle_encrypt_device {
mount_options => $partition->{mount_options},
filesystem => $partition->{filesystem},
createopts => $partition->{createopts},
+lukscreateopts => $partition->{lukscreateopts},
tuneopts => $partition->{tuneopts}
};
@@ -243,21 +244,30 @@ sub build_cryptsetup_commands {
if ($mode =~ /^luks(:"([^"]+)")?$/) {
my $keyfile = "$FAI::DATADIR/$enc_dev_short_name";
+my $luksoption = $1;
+my $passphrase = $2;
# generate a key for encryption
::push_command(
"head -c 2048 /dev/urandom | od | tee $keyfile",
"", "keyfile_$real_dev" );
+
+my $lukscreateopts = $vol->{lukscreateopts} // "";
+if ($lukscreateopts !~ /(^|\s)-c\s+\S+/) {
+ $lukscreateopts .= " -c aes-cbc-essiv:sha256";
+}
+if ($lukscreateopts !~ /(^|\s)-s\s+\d+/) {
+ $lukscreateopts .= " -s 256";
+}
# encrypt
::push_command(
- "yes YES | cryptsetup luksFormat $real_dev $keyfile -c aes-cbc-essiv:sha256 -s 256",
+ "yes YES | cryptsetup luksFormat $real_dev $keyfile $lukscreateopts",
"$pre_dep,keyfile_$real_dev", "crypt_format_$real_dev" );
::push_command(
"cryptsetup luksOpen $real_dev $enc_dev_short_name --key-file $keyfile",
"crypt_format_$real_dev", "exist_$enc_dev_name" );
-if (defined($1)) {
- my $passphrase = $2;
+if (defined($luksoption)) {
# add user-defined key
::push_command(
diff --git a/lib/setup-storage/Parser.pm b/lib/setup-storage/Parser.pm
index 4373364..943eaa5 100755
--- a/lib/setup-storage/Parser.pm
+++ b/lib/setup-storage/Parser.pm
@@ -812,7 +812,7 @@ $FAI::Parser = Parse::RecDescent->new(
$FAI::partition_pointer = (\%FAI::configs)->{CRYPT}->{volumes}->{$vol_id};
$FAI::partition_pointer_dev_name = "CRYPT$vol_id";
}
-mountpoint devices filesystem mount_options lv_or_fsopts
+mountpoint devices filesystem mount_options lukscreate_or_lvopts
| /^tmpfs\s+/
{
($FAI::device eq "TMPFS") or die "tmpfs entry invalid in this context\n";
@@ -1112,6 +1112,12 @@ $FAI::Parser = Parse::RecDescent->new(
}
| createtuneopt(s?)
+ lukscreate_or_lvopts: /lukscreateopts="([^"]*)"/ lv_or_fsopts(s?)
+{
+ $FAI::partition_pointer->{lukscreateopts} = $1;
+}
+| lv_or_fsopts(s?)
+
lv_or_fsopts: /lvcreateopts="([^"]*)"/ createtuneopt(s?)
{
$FAI::partition_pointer->{lvcreateopts} = $1;
diff --git a/man/setup-storage.8 b/man/setup-storage.8
index f0e14de..5ded92a 100644
--- a/man/setup-storage.8
+++ b/man/setup-storage.8
@@ -613,7 +613,7 @@ option ::= /* empty */
.br
-volume ::=
+volume ::=
.br
| vg
.br
@@ -733,6 +733,13 @@ filesystem ::= -
/* mkfs.
Re: Customise settings for cryptsetup
On Thu, 2016-09-22 at 00:48 +0200, Thomas Lange wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, 22 Sep 2016 10:39:57 +1200, Andrew Ruthven <andrew@ > > > > > > etc.gen.nz> said: > > > I have a requirement to change some of the settings that are > passed to > > cryptsetup. I could add in a createopts similar to the various > other > > options what'd allow changing the cipher and size (and whatever > else). > > Would this be of interest? > Sure. I plan to release FAI 5.2 in one week, so if you like to get > this included, sent a patch soon. Great, I have a patch that looks legit. I'll test it on some real hardware tomorrow. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Customise settings for cryptsetup
Hey, I have a requirement to change some of the settings that are passed to cryptsetup. I could add in a createopts similar to the various other options what'd allow changing the cipher and size (and whatever else). Would this be of interest? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Re: Preserving encrypted disks
On Wed, 2016-09-21 at 03:49 +, Paul Schulz wrote: > (How is the Isle of the Long White Cloud?) It's fantastic! ;) (We actually use the Land of the Long White Cloud - there's a few islands that make up NZ.) > Are the encrypted disks separate? (ed. sdc,sdd?) > If so, you could run it in a hook script with just the drives you > want to partition. Using the '-D' option allows you to set the disks. Yes, they are different disks. Yeah, I guess I could do that. A little bit awkward, but certainly do-able. Cheers, Andrew > On Wed, 21 Sep 2016 at 10:43 Andrew Ruthven <and...@etc.gen.nz> > wrote: > > Hey, > > > > I'm happily creating encrypted file systems now, which is great, > > but > > I'd like to look forward to having to rebuild the system. The > > encrypted > > file systems are for data storage only. Ideally if we rebuild the > > server, the data storage disks would be left alone. > > > > I've run into three problems here: > > > > 1) preserve for LUKS isn't supported. > > 2) preserve_always requires the disks to already be configured and > > won't change them. > > 3) preserve_reinstall requires you to set a class for the first > > build. > > > > To resolve 1, ideally setup-storage would honour preserve flags and > > let > > me worry about the crypt files etc. > > > > But the behaviour with 2 & 3 are a problem. Ideally we'd have > > lazyformat back. ;) I don't want to have to set any classes for > > the > > first build, or modify the disk_config for future builds. > > > > I could potentially have a class file that looks to see if a > > partition > > exists on the first hard drive, and if it doesn't exist, set the > > INITIAL class. But that seems a bit brittle to me. > > > > How are others handling that situation? > > > > Cheers, > > Andrew > > > > -- > > Andrew Ruthven, Wellington, New Zealand > > and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU > > New Zealand's only Cloud: | The Future of Open Source > > https://catalyst.net.nz/cloud | http://linux.conf.au > > > > > > > > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Preserving encrypted disks
Hey, I'm happily creating encrypted file systems now, which is great, but I'd like to look forward to having to rebuild the system. The encrypted file systems are for data storage only. Ideally if we rebuild the server, the data storage disks would be left alone. I've run into three problems here: 1) preserve for LUKS isn't supported. 2) preserve_always requires the disks to already be configured and won't change them. 3) preserve_reinstall requires you to set a class for the first build. To resolve 1, ideally setup-storage would honour preserve flags and let me worry about the crypt files etc. But the behaviour with 2 & 3 are a problem. Ideally we'd have lazyformat back. ;) I don't want to have to set any classes for the first build, or modify the disk_config for future builds. I could potentially have a class file that looks to see if a partition exists on the first hard drive, and if it doesn't exist, set the INITIAL class. But that seems a bit brittle to me. How are others handling that situation? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Re: FAI with RAID+CRYPT+LVM
Also, as I've just managed to work, to have LUKS encrypt an LVM LV you need to specify the path to the LV, for example: disk_config cryptsetup luks /srv/node/obj01 /dev/vgobj01/lvobj01 xfs rw createopts="-L obj01" That took a bit of head bashing to work out, initially I was trying vgobj01-lvobj01 and /dev/mapper/vgobj01-lvobj01. The sample above worked, and I'm just running the package installation phase of my build now. ;) On a similar note, is it possible to use uuid's in /etc/crypttab instead of the device name? Cheers, Andrew On Tue, 2016-09-20 at 11:36 +, Paul Schulz wrote: > Woot! (.. for setup-storage anyway) > Thanks everyone for your suggestions. > > The solution to my problem is to not worry about the name of the > 'cryptsetup' partition, 'setup-storage' handles this automatically. > > Cryptsetup is called and creates a device called "crypt_format_md1" > (in my case) which is then fed correctly to LVM. > > Can this be put into the documentation somewhere? > (./man/setup-storage.8 ?) I only found this out somewhat by accident. > > Cheers, > Paul > > ps. FAI installes the system installs but doesn't boot, so that's the > next thing to solve. Fails to decrypt the luks partition and find > /dev/mapper/Base-Root > > > On Fri, 16 Sep 2016 at 00:58 Paul Schulz <p...@mawsonlakes.org> > wrote: > > I am still having an isse with the setup-disk configuration > > > > I'm now getting the following error after the file is parsed.. > > "Cannot determine size of /dev/mapper/md1_crypt - scheme unknown" > > > > See attached files: > > raid1-disk1-disk2t.txt - Just RAID1 > > lvm-disk1-disk2.txt - RAID1+LVM (works) > > crypt-disk1-disk2.txt - RAID1+CRYPT+LVM (error) > > > > For testing, I have two external USB 90G disks attached for testing > > and am using the following: > > ./bin/setup-storage -D"sdb sdc" -fcrypt-disk1-disk2.txt > > (With export PERL5LIB=`pwd`/lib/setup-storage) > > or > > /usr/sbin/setup-storage -D"sdb sdc" -fcrypt-disk1-disk2.txt > > (Ubuntu 16.04) > > > > Q. Do I need to know or set the size of the crypted drive before it > > is created? It is then used by LVM, so maybe I do? > > > > My Plan B is to take the log from ' lvm-disk1-disk2.txt' and then > > modify it manually setup the encrypted partition. I can then run > > this script in place of setup-storage in the FAI partitioning step. > > > > Regards > > Paul > > > > On Thu, 25 Aug 2016 at 13:15 Paul Schulz <p...@mawsonlakes.org> > > wrote: > > > Hi Alexandros > > > > > > Thank you for your reply. It was helpful and I have made some > > > progress, > > > but I'm still getting errors when processing the 'cryptsetup' > > > stanza. > > > > > > I have attached my FAI configuration files that I am tying to > > > parse. > > > FSRAID - produces error on 'luks' line > > > FSRAID-parses > > > > > > (If I comment out the 'luks' line I can parse.but I don't know > > > what output > > > or commands it will produce.) > > > > > > To test this, I have used copy of the latest github code, and > > > have modified > > > the code so it can access it's perl modules (without > > > installation). > > > > > > Also, I gen another error if I don't use the full path > > > '/dev/mapper/md1_crypt' > > > in the luks line, BUT cryptsetup only uses the filename part ' > > > md1_crypt'. > > > > > > I am trying to grok the parser code... > > > > > > Regards, > > > Paul > > > > > > On Tue, 23 Aug 2016 at 20:04 Alexandros Afentoulis <ale...@noc.gr > > > net.gr> wrote: > > > > On 08/22/2016 09:56 AM, Paul Schulz wrote: > > > > > (Repeated as first attempt didn't go through.) > > > > > > > > > > Greetings, > > > > > I have been asked to setup some systems with an encrypted > > > > disk > > > > > configuration (see below for FAI setup-storage format), > > > > essentially two > > > > > disks with: > > > > > RAID1(/boot+other) < Crypt(other) < LVM((Root,Home,Swap) > > > > > > > > > > Should I expect this to work? If not, what would need to be > > > > done to > > > > > include this support in LVM. Can I run setup-storage > > > > multiple times(3 > > > > > confiig files)? > > > > > > > > Hello there, > > > > > > > > yes the disk scheme you aim for is feasible. In fact I did > > > > setup a node > > > > like that a couple of days ago. > > > > > > (snip) > > > > > > > Hope I helped, > > > > Greetings > > > > > > > > > -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Re: Dracut, stop on first configured interface?
On Tue, 2016-09-20 at 20:07 +1200, Andrew Ruthven wrote: > On Tue, 2016-09-20 at 09:58 +0200, Thomas Lange wrote: > > IIRC if you specify a NIC on the kernel cmdline, it only probes > > this > > interface. For more info read dracut.cmdline(7). > > Yes, but then sometimes it isn't always eth0, and I don't want people > to have to fiddle with the cmdline for every build... Oh, and I should say I've gone through dracut.cmdline and the kernel networking docs, nothing in those. I was hoping someone would have a trick to resolve this. ;) Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Re: Dracut, stop on first configured interface?
On Tue, 2016-09-20 at 09:58 +0200, Thomas Lange wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 20 Sep 2016 15:12:30 +1200, Andrew Ruthven <andrew@ > > > > > > etc.gen.nz> said: > > > Is it possible to have Dracut stop on the first interface that > receives > > a DHCP configuration? > IIRC if you specify a NIC on the kernel cmdline, it only probes this > interface. For more info read dracut.cmdline(7). Yes, but then sometimes it isn't always eth0, and I don't want people to have to fiddle with the cmdline for every build... Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Dracut, stop on first configured interface?
Hey, Is it possible to have Dracut stop on the first interface that receives a DHCP configuration? Some of my servers have 8 NICs, and while we typically netboot off eth0, the rest might be plugged into switches and it can take a long time for the rest to time out. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2017, Hobart, AU New Zealand's only Cloud: | The Future of Open Source https://catalyst.net.nz/cloud | http://linux.conf.au
Re: FAI going to the cloud
On Fri, 2016-07-29 at 16:27 +0200, Thomas Lange wrote: > A new beta version of FAI is available. It now includes a new command > for creating cloud^Wdisk images. fai-diskimage can create a raw or > qcow2 disk image without starting a virtual machine. This image is > ready-to-boot for your VM or cloud instance. Currently it has no man > page, but a help is printed when calling with -h. Oh, this looks interesting. I was planning on doing something similar to how we've been using FAI to build Linux-VServers. Use a standard image, then copy up the FAI config directory and for a fai-softupdate. > I plan to release FAI 5.2 in september, so any feedback is welcome. I'll give it a whirl in the new week. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2016 New Zealand's only Cloud: | LCA By the Bay, Geelong, AU https://catalyst.net.nz/cloud | http://lca2016.linux.org.au
Issue with lvcreate
Hey, Interesting issue with lvcreate and setup-storage on Jessie with FAI 5.0.3, we've started getting the following error sometimes: /dev/VGNAME/LVNAME: not found: device not cleared Aborting. Failed to wipe start of new LV. Which causes setup-storage to abort and so does fai. It seems that udev isn't picking up the new LV in time to create the device before lvcreate tries to wipe the start of the device. I've worked around this for now by modifying: /usr/share/fai/setup-storage/Commands.pm to have lvcreate have the "-Z n' parameter. Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2016 New Zealand's only Cloud: | LCA By the Bay, Geelong, AU https://catalyst.net.nz/cloud | http://lca2016.linux.org.au
Re: issue with install_packages in FAI 5.0.3
On Fri, 2016-04-15 at 11:49 +1200, Andrew Ruthven wrote: > On Tue, 2016-04-12 at 10:10 +0200, Thomas Lange wrote: > > You can disable the ramdisk by setting > > FAI_RAMDISK=/doesnotexist > > in class/*.var > I've put this into LAST.var and now I can complete installs without > hacking /usr/lib/fai/subroutines to add -N to install_packages. ;) Actually, I take it back. Even with FAI_RAMDISK set to that, install_packages still fails to run with the same error. This exists: /target/var/lib/dpkg/status This doesn't: /var/lib/dpkg/status Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2016 New Zealand's only Cloud: | LCA By the Bay, Geelong, AU https://catalyst.net.nz/cloud | http://lca2016.linux.org.au
Re: issue with install_packages in FAI 5.0.3
On Tue, 2016-04-12 at 10:10 +0200, Thomas Lange wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 12 Apr 2016 12:04:57 +1200, Andrew Ruthven <andrew@ > > > > > > etc.gen.nz> said: > > Could not open file /var/lib/dpkg/status - open (2: No such > file or > > directory) > Another cause could be, that you machine does not have much RAM. FAI > is putting a ramdisk (tmpfs) on top of /var/lib/dpkg. If this gets > overcrowded, a process may not be able to write the status file, and > therefore it may be missing. How much RAM does your client have? I was doing a test build in a KVM instance with 1GB of RAM. I've also tried it on a server with 384GB, looking in the logs we have: Calling task_extrbase Unpacking distro base archive ftar: extracting /var/lib/fai/config/basefiles/TRUSTY_AMD64.tar.gz to /target/ Ramdisk mounted onto /target/var/lib/dpkg I've checked on the real box, and /var/lib/dpkg is still empty, and install_packages fails in the same fashion. The basefile is extracted into /target as expected and /target/var/lib/dpkg looks sane to me. > You can disable the ramdisk by setting > FAI_RAMDISK=/doesnotexist > in class/*.var I've put this into LAST.var and now I can complete installs without hacking /usr/lib/fai/subroutines to add -N to install_packages. ;) Perhaps install_packages could check to make sure that /var/lib/dpkg/status exists before trying to use Apt::Pkg? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2016 New Zealand's only Cloud: | LCA By the Bay, Geelong, AU https://catalyst.net.nz/cloud | http://lca2016.linux.org.au
issue with install_packages in FAI 5.0.3
Hey, I'm in the process of updating my FAI nfsroot to Jessie, and FAI 5.0.3. I've discovered an issue with install_packages. It seems that Apt::Pkg is causing issues. I'm getting the following error message: ... install_packages: read config file LAST Could not open file /var/lib/dpkg/status - open (2: No such file or directory) The package lists or status file could not be parsed or opened. Can't call method "exists" on an undefined value at /usr/sbin/install_packages line 409, line 235. After a bit of poking around, that error about /var/lib/dpkg/status is because /var/lib/dpkg in the running install box is empty. The logic in install_packages at line 142 which loads AptPkg::Cache appears to be trying to use $target/var/lib/dpkg/status but that isn't working correctly. If I run install_packages manually with -N then I can successfully install packages. Is there something else that I should be doing here? Cheers, Andrew -- Andrew Ruthven, Wellington, New Zealand and...@etc.gen.nz | linux.conf.au 2016 New Zealand's only Cloud: | LCA By the Bay, Geelong, AU https://catalyst.net.nz/cloud | http://lca2016.linux.org.au
Re: GPT partition labels via setup-storage
On Wed, 2014-08-20 at 11:19 +0200, Thomas Neumann wrote: On Wednesday 20 August 2014 16:11:47 Andrew Ruthven wrote: Is it possible to set labels on individual partitions with setup-storage when GPT is being used? Do you want to set a label so you can mount the filesystem by using that label or do you want something else entirely. If you just want to use labels for mounting then this has nothing to do with GPT. The label is provided via the filesystem. You could use createopts to set the label: primary / 2G- ext3 rw createopts=-L root (from the top of my head, please refer to the documentation if setup-storage complains) Nope, this is from GPT. For example, in parted, use the name command to set a name on the partition. Below is an example (assigned manually after a FAI build). Ceph will find all the various partitions and assemble itself based on what it finds. GNU Parted 2.3 Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA INTEL SSDSC2BA20 (scsi) Disk /dev/sdc: 200GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End SizeFile system Name Flags 1 1049kB 17.2GB 17.2GB ceph journal 2 17.2GB 34.4GB 17.2GB ceph journal 3 34.4GB 51.5GB 17.2GB ceph journal 4 51.5GB 68.7GB 17.2GB ceph journal (parted) quit Cheers, Andrew
GPT partition labels via setup-storage
Hey, Is it possible to set labels on individual partitions with setup-storage when GPT is being used? Cheers, Andrew
