From b8ad5cd0fd54cfb7ac921c59d2752f35ed214add Mon Sep 17 00:00:00 2001 From: Marek Czernek Date: Wed, 16 Oct 2024 13:00:52 +0200 Subject: [PATCH 1/4] Provide RFC for Salt SSH for TU systems --- .gitignore | 4 ++ accepted/uyuni-microos-salt-ssh | 85 +++++++++++++++++++++++++++++++++ 2 files changed, 89 insertions(+) create mode 100644 accepted/uyuni-microos-salt-ssh diff --git a/.gitignore b/.gitignore index e43b0f98..4e59362b 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,5 @@ +# MacOS .DS_Store + +# Vim +*.un~ diff --git a/accepted/uyuni-microos-salt-ssh b/accepted/uyuni-microos-salt-ssh new file mode 100644 index 00000000..93d65970 --- /dev/null +++ b/accepted/uyuni-microos-salt-ssh @@ -0,0 +1,85 @@ +- Feature Name: Salt SSH for transactional OSes +- Start Date: TODO + +# Summary +[summary]: #summary + +Uyuni users may choose to manage minions by using Salt SSH, for example due to network constraints. However, currently, systems that are based on transactional update, i.e. openSUSE MicroOS or SUSE Linux Micro (TU minions), do not support management via Salt SSH. + +This RFC describes improvements for Salt SSH such that Uyuni can fully control TU minions by using Salt SSH. + +# Motivation +[motivation]: #motivation + +Uyuni users want feature parity of TU minions to non-TU minions. Currently, Uyuni users can use the Salt, Salt SSH, or Salt SSH Proxy methods to control their deployed non-TU minions. However, for TU minions, SSH management does not work. + +Enabling Salt SSH for TU minions is crucial, for example, for partially air gapped environments, where system administrators can provide a trusted bridge (SSH proxy) for Uyuni to reach the TU minion and update it as necessary. + +# Detailed design +[design]: #detailed-design + +## Current State + +Currently, when Uyuni bootstraps a minion by using Salt SSH, Uyuni deploys a Salt client into `/var/tmp/venv-salt-minion`. +When Salt SSH makes a `state` call to a client, for example `state.sls example-sls-filename`, it additionally compiles the `example-sls-filename` state (and all its dependencies, such as files used by the state) into a tar file, and deploys it to a generated location in `/var/tmp`, such as `/var/tmp/.root_12345_salt/salt_state.tgz` (together with other data, such as external modules, grain info, etc). + +TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/etc`. To modify such partitions, users use the `transactional-update` command. + +The `transactional-update` command temporarily mounts the partitions as read-write, and after the modifications are done, it creates a new BTRFS snapshot that is activated upon restart (or upon using `transactional-update apply`). + +Note that Salt SSH relies on both file systems for functions that modify the read-only file system: + +- The filesystem outside of a transaction (IAT) contains both the Salt client, and, more importantly, the `salt_state.tgz` file. +- The filesystem inside of a transaction (OOT) requires both the Salt client and the `salt_state.tgz` because the execution must happen in a transaction. + +This poses a problem: on TU systems, Salt needs to coordinate files between the IAT and OOT filesystems. + +## Solution + +There are two Salt modules that modify the filesystem: + +- `state` (e.g. `state.apply`) +- `transactional_update` (e.g. `transactional_update.apply`) + +Users should use the `state` module modify OOT filesystem, and the `transactional_update` module to modify the IAT filesystem. + +Because `state` module will not use transactions, it requires no changes for Salt SSH to work. +However, the `transactional_update` module requires: + +1. a Salt SSH wrapper to prepare and transfer the `salt_state.tgz` file +2. to implement the `pkg` function, which executes the `salt_state.tgz` file +3. to implement a synchronization mechanism that copies Salt and the `salt_state.tgz` file into the transaction + +Steps 1. and 2. for the `transactional_module` are equivalent to the `state` module: + +1. [state's SSH wrapper](https://github.com/openSUSE/salt/blob/openSUSE/release/3006.0/salt/client/ssh/wrapper/state.py) +2. `transactional_module` can delegate execution to `state.pkg` once in a transaction with all the necessary files + +For step 3, this RFC proposes the following mechanism: + +- When `transactional_update.pkg` function is called, it first deploys itself from whatever location Salt initially is on a minion (e.g. `/var/tmp/.root_12345_salt`) to `/var/cache`. + - In case of a traditional Salt, `transactional_update` generates a thin Salt client into `/var/cache`. + - In case of a Salt Bundle (`venv-salt-minion`), `transactional_update` copies the directory from which Salt is currently executed, e.g. `/var/tmp/venv-salt-minion` to `/var/cache`. Consequently, `transactional_update` must also fix the shebangs in the new `/var/cache` copy. + +> [!NOTE] +> In TU systems, the `/var/cache` location is shared between the IAT and OOT filesystems, which is why it serves as a synchronization point. + +- After deploying a copy of Salt into `/var/cache`, `transactional_update` also copies the `salt_state.tgz` file to `/var/cache`. +- Then, the Salt process outside of a transaction (_Salt_OOT_) starts a new Salt process inside of a transaction (_Salt_IAT_), which now executes `state.pkg`. +- After the Salt_IAT process finishes, it passes the execution result to Salt_OOT. +- Salt_OOT deletes the Salt copy from the `/var/cache` location, and returns execution result to Salt master. + +# Drawbacks +[drawbacks]: #drawbacks + +- Greater resource requirements: each execution of Salt SSH deploys a Salt client to the temporary `/var/cache` location, executes a new Salt process, and removing the temporary Salt client at the end of the execution. This means increased storage footprint (both RAM and disk), as well as added CPU cycles related to copying and cleaning up Salt. + +# Alternatives +[alternatives]: #alternatives + +- Not supporting Salt SSH on TU systems. +- We considered alternative approaches to synchronizing the Salt_IAT and Salt_OOT instances, for example via a socket. + +# Unresolved questions +[unresolved]: #unresolved-questions + From b24047ef8009047eacedc2c692c712a5f15d1dc4 Mon Sep 17 00:00:00 2001 From: Marek Czernek Date: Wed, 16 Oct 2024 13:02:03 +0200 Subject: [PATCH 2/4] Add correct file extension --- accepted/{uyuni-microos-salt-ssh => uyuni-microos-salt-ssh.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename accepted/{uyuni-microos-salt-ssh => uyuni-microos-salt-ssh.md} (100%) diff --git a/accepted/uyuni-microos-salt-ssh b/accepted/uyuni-microos-salt-ssh.md similarity index 100% rename from accepted/uyuni-microos-salt-ssh rename to accepted/uyuni-microos-salt-ssh.md From 227726639da6795f44eb88357c67e2d23595c722 Mon Sep 17 00:00:00 2001 From: Marek Czernek Date: Tue, 26 Nov 2024 16:06:27 +0100 Subject: [PATCH 3/4] Implement feedback --- accepted/uyuni-microos-salt-ssh.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/accepted/uyuni-microos-salt-ssh.md b/accepted/uyuni-microos-salt-ssh.md index 93d65970..7019615a 100644 --- a/accepted/uyuni-microos-salt-ssh.md +++ b/accepted/uyuni-microos-salt-ssh.md @@ -11,9 +11,9 @@ This RFC describes improvements for Salt SSH such that Uyuni can fully control T # Motivation [motivation]: #motivation -Uyuni users want feature parity of TU minions to non-TU minions. Currently, Uyuni users can use the Salt, Salt SSH, or Salt SSH Proxy methods to control their deployed non-TU minions. However, for TU minions, SSH management does not work. +Uyuni users want feature parity of contact methods between TU minions and non-TU minions. Currently, users can use the Salt, Push via SSH (Salt SSH), or Push via SSH tunnel (Salt SSH proxy) contact methods to control their deployed non-TU minions. However, for TU minions, we support only the Salt method. -Enabling Salt SSH for TU minions is crucial, for example, for partially air gapped environments, where system administrators can provide a trusted bridge (SSH proxy) for Uyuni to reach the TU minion and update it as necessary. +Enabling Salt SSH for TU minions is important, for example, for partially air gapped environments, where system administrators can provide a trusted bridge (SSH proxy) for Uyuni to reach the TU minion and update it as necessary. # Detailed design [design]: #detailed-design @@ -29,8 +29,8 @@ The `transactional-update` command temporarily mounts the partitions as read-wri Note that Salt SSH relies on both file systems for functions that modify the read-only file system: -- The filesystem outside of a transaction (IAT) contains both the Salt client, and, more importantly, the `salt_state.tgz` file. -- The filesystem inside of a transaction (OOT) requires both the Salt client and the `salt_state.tgz` because the execution must happen in a transaction. +- The filesystem outside of a transaction (OOT) contains both the Salt client, and, more importantly, the `salt_state.tgz` file. +- The filesystem inside of a transaction (IAT) requires both the Salt client and the `salt_state.tgz` because the execution must happen in a transaction. This poses a problem: on TU systems, Salt needs to coordinate files between the IAT and OOT filesystems. From e64cf27bd4fa94b96e31e15acbea4ce3042927e1 Mon Sep 17 00:00:00 2001 From: Marek Czernek Date: Fri, 6 Dec 2024 10:05:33 +0100 Subject: [PATCH 4/4] Implement review feedback for better technical precision --- accepted/uyuni-microos-salt-ssh.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/accepted/uyuni-microos-salt-ssh.md b/accepted/uyuni-microos-salt-ssh.md index 7019615a..12d42b08 100644 --- a/accepted/uyuni-microos-salt-ssh.md +++ b/accepted/uyuni-microos-salt-ssh.md @@ -23,9 +23,9 @@ Enabling Salt SSH for TU minions is important, for example, for partially air ga Currently, when Uyuni bootstraps a minion by using Salt SSH, Uyuni deploys a Salt client into `/var/tmp/venv-salt-minion`. When Salt SSH makes a `state` call to a client, for example `state.sls example-sls-filename`, it additionally compiles the `example-sls-filename` state (and all its dependencies, such as files used by the state) into a tar file, and deploys it to a generated location in `/var/tmp`, such as `/var/tmp/.root_12345_salt/salt_state.tgz` (together with other data, such as external modules, grain info, etc). -TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/etc`. To modify such partitions, users use the `transactional-update` command. +TU minions are different from non-TU minions in that they mount some partitions as read-only, for example `/usr`. To modify such partitions, users use the `transactional-update` command. -The `transactional-update` command temporarily mounts the partitions as read-write, and after the modifications are done, it creates a new BTRFS snapshot that is activated upon restart (or upon using `transactional-update apply`). +The `transactional-update` command creates a new read-write snapshot, performs modifications (modifying the previously read-only system), and activates the latest snapshot at restart (or when using `transactional-update apply`). Note that Salt SSH relies on both file systems for functions that modify the read-only file system: