Deploy Software Installs To Multiple Computers All At Once

Hey guys,

I was wondering if it was possible to install software/setup qubes OS on multiple systems at the same time? For example for a company which wants to have multiple computers setup the same way with Qubes installed without setting up every single pc manually. Similar to how it is possible on windows.

Much appreciated for any answers :slight_smile:

Puuhhhh, just can tell you, how I would do this, supposed every system have the very same SSD (or HDD) and devices inside.

Install Qubes on the first one and after the OS is setup and configured, do an image of the disk and put it on all other systems with ‘Disks’ and image reload.

1 Like

or make a qubes backup (much simpler)

2 Likes

It is not. When you restore all dom0 contents is restored in a dedicated folder. System configuration files and modifications in dom0 are not backed up at all unless you copied them into dom0 home prior to the backup.

With identical computers the imaging is clearly the fastest and simplest way.

With a more diverse range of machines the solution is likely setting up many salt formula and having them executed after installation.

2 Likes

If you encrypted the base install, I would not use imaging. Otherwise the passworkd and key for all laptops would be the same.

1 Like

thank you (i never tried qubes backup before since i can’t store them)

The most flexible way is probably to do this with a Salt recipe (since Salt has already become quite central in Qubes). You will need to write a set of Salt files for qubesctl to do the job from each or your Qubes machines’ dom0.

And you will need to install them into every machine’s dom0.

To go beyond would require knowing more about what you’re doing. You way want to do the tedious work of getting those files there manually. But if you expect that these customizations will evolve with time (and even if we don’t think about that initially, they usually do :wink: ), you’d be better off with replacing this manual task with (manually) installing an automated way of propagating future versions of those files. To leverage existing mechanisms (including authentication of what enters your dom0), this will involve packaging them in a RPM and referencing your custom yum repo in their dom0.

Now to replace that manual work on every such machine, you may want to build your own custom installation image to include that RPM.

1 Like

This is true, but the ease of imaging deployment far outweighs the
minor pain in running a script on first login to change user password
and disk password. This also gives user a sense of ownership of the
new machine.
(In a corporate environment it’s sometimes useful to have a common
disk key.)

Salt the initial configuration, and then clone the disks for deployment.
If you have a small number of machines, you might install the base
system, with salt formulae, and then salt each individually from a
caching proxy.
For speed of setup and deployment I would full install and clone.
Invest in a hardware duplicator if you are doing this at scale.

2 Likes

Thank you very much guys. I didn’t know that salt was already integraded into qubes. But I got a few ideas how to approach this now.

Cheers :slight_smile:

But changing the disk password won’t change the encryption key. It means that even if you wipe the key from the drive, you’re still going to be able to recover it from a different machine, since they all use the same key.

1 Like

True enough, but in a corporate environment this is not an issue, and
that was what OP asked about.

1 Like

The solution for that is to reencrypt the LUKS container (cryptsetup-reencrypt) and then change its main LUKS key passphrase. Heads permits that from menu options, and is offered through re-ownership prompts.

Note that some other ststem uniqueness are there when cloning a disk which is gonna be used between multiple identical platforms.

  • systemd entropy seed
  • partitions UUID
  • sys-whonix guard nodes (wipe that sys-whonix private lvm)
  • qubes UUID
  • qubes internal IPs
  • etc

Other then that, with sys-net and sys-usb configured as being disposable qubes, not so much other important things are shared across resulting clones.

I have stopped giving love to clonezilla, but that project has infinite potential, considering its able to do bit by bit clones through bittorent on a local network. As you might think, all machines participate into chunks sharing and validation, guaranteeing all machines have the same disk image after the process. Both server and client modea can be instructed from boot options to do their job, which again from Heads is a really interesting approach. Clonezilla usage gets lot cheaper to buy/use a 20 ports switch then it is to buy a 20 drive bay disk cloner, depending of cloning needs. Also note that with some additional scripting (pre and post scripts), it is totally possible to have clonezilla reencrypt the LUKS container on the client laptops getting the image from the master. Dreaming a bit here, but it would also be totally possible to clone the LVMs from within the master’s preopened LUKS container to speed things up as well, instead of cloning random bits from the whole LUKS container as opposed to the whole LUKS partition there. That could of course require clients to create a LUKS container with a precrafted (pre-script) LUKS UUID, and open it prior of injecting the LVMs from the master. All in all, that cloning succeeds under an hour with 10 participants without further tuning then with the PoC I have. But it would be desired to have local LUKS container creation and only cloning LVMs so that the end result doesn’t need to be reencrypted locally, which is still wearing the SSD and should be worked around. But good enough and giving the same result as a physical disk cloner if no reencryption is needed.

Also note that wyng-backups can backup and restore dom0 as any other LVMs, while that setup requires to take snapshot of dom0, preferably through a dom0 shutdown systemd script.
wyng-backups also comes with a qubes tool that permits to backup/inject qubes.xml parts of restored qubes, since that wyng-backups is designed to deal only with LVMs content. But once configured properly and a script created to do things in the right order, it is possible to restore the system in known safe state in a matter of minutes, only applying LVM changes to a volune snapshot and merging snapshot state backbtonoriginal volume. Ideal would be to have a remkte SSH server containing such states (and services provided to remotely restore in known states, which woukd also facilitate debugging), but having that locally on a qube’ LVM is good enough, while the number of states kept locally need to be pruned down otherwise incremental changes, even if deduplicated, consumes always increasing space.

2 Likes