initial implementation of install subcommand

[lexming]

Carries out a native installation of EESSI in localhost following the instructions in
https://www.eessi.io/docs/getting_access/native_installation/:

• installs CernVM-FS system-wide
• installs EESSI configuration
• makes client configuration
• runs setup

Supported Linux distros:

• RHEL-based
• Debina-based

Screencast_20260210_014947.webm

Note: root permissions are required for system-wide installations. Only those commands that need root are executed with sudo. User will only be prompted once for the password.

Coded with the assistance of a local AI model (devstral-small-2)

[boegel]

Tried this on Ubuntu 24.04 (LTS) with commit 5f11ec3, works fine with a small "issue" (see which command being run):

Details

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"

$ eessi --version
eessi version 0.2.0

(venv) kehoste@lima-ubuntu2404-test:~/eessi-cli$ eessi install

🚀 Launching native EESSI installation...

EESSI requires the following components:
├── CernVM File System
├── configuration files of EESSI for CernVM-FS
├── client configuration files for CernVM-FS
└── EESSI repositories

🚨 The requested installation steps require executing commands as root
🔑 Enter your user password in this system::

🧩 Step 1 of 4: CernVM-FS

CernVM-FS not found. Do you want to install CernVM-FS in this system? [y/n]:
Please enter Y or N
CernVM-FS not found. Do you want to install CernVM-FS in this system? [y/n]: Y
🚨 The requested installation steps require executing commands as root
🔑 Enter your user password in this system::

📦 Installing CernVM-FS packages...
💥 Command failed: which yum || which dnf; Output: ; Error:
✅ Detected Debian-based distribution
✅ Downloaded https://cvmrepo.s3.cern.ch/cvmrepo/apt/cvmfs-release-latest_all.deb
✅ dpkg -i cvmfs-release-latest_all.deb
✅ apt update
✅ apt install -y cvmfs
🎉 CernVM-FS installed successfully

🧩 Step 2 of 4: EESSI configuration for CernVM-FS

EESSI configuration not found. Do you want to install it in this system? [y/n]: Y
🚨 The requested installation steps require executing commands as root
🔑 Enter your user password in this system::

📦 Installing EESSI configuration for CernVM-FS...
💥 Command failed: which yum || which dnf; Output: ; Error:
✅ Detected Debian-based distribution
✅ Downloaded https://github.com/EESSI/filesystem-layer/releases/download/latest/cvmfs-config-eessi_latest_all.deb
✅ dpkg -i cvmfs-config-eessi_latest_all.deb
🎉 EESSI configuration for CernVM-FS installed successfully

🧩 Step 3 of 4: client configuration for CernVM-FS

CernVM-FS client configuration not found. Do you want to install it in this system? [y/n]: Y
🚨 The requested installation steps require executing commands as root
🔑 Enter your user password in this system::
📦 Creating client configuration file...
✅ Configuration parameters added to temporary file
✅ cp /tmp/tmpxhejuqdg /etc/cvmfs/default.local
🎉 Client configuration file created at /etc/cvmfs/default.local

🧩 Step 4 of 4: EESSI repositories

📦 Running cvmfs_config setup to configure EESSI repositories...
✅ cvmfs_config setup
✅ EESSI repositories configured successfully

🏁 Native EESSI installation completed successfully!

You can now use EESSI by running 'eessi init' or 'eessi shell'

(venv) kehoste@lima-ubuntu2404-test:~/eessi-cli$ eessi check
📦 Checking for EESSI repositories...
    ✅ OK /cvmfs/dev.eessi.io is available
    ✅ OK /cvmfs/riscv.eessi.io is available
    ✅ OK /cvmfs/software.eessi.io is available

🔎 Inspecting EESSI repository software.eessi.io...
    ✅ OK /cvmfs/software.eessi.io is available
    ℹ Revision (client): 14330
    💻 Client cache:
        ℹ Path to client cache directory: /var/lib/cvmfs/shared
        ℹ Shared cache: yes
        ℹ Client cache quota limit: 9.765625 GiB
        ℹ Cache Usage:  285k / 10240000k
        ✅ OK Number of cache cleanups in last 24h: 0
    🌍 Server/proxy settings:
        ℹ List of Stratum-1 mirror servers:
            http://aws-eu-central-s1.eessi.science/cvmfs/software.eessi.io
            http://azure-us-east-s1.eessi.science/cvmfs/software.eessi.io
        ℹ Proxy servers:
            auto
            DIRECT
        ℹ GeoAPI enabled: yes
    💁 Other:
        ℹ Client profile: single

[lexming]

Great, I fixed that and made some other improvements:

• add option --client-profile to install subcommand
• use temp directory to download and install .deb packages with dpkg
• streamline package manager detection and ignore errors on related commands
• avoid re-asking the sudo password whenever and empty password is given

[boegel]

@lexming I don't think we should be asking for the sudo password, storing it, and then passing that around to the various functions while eessi install is running. Security-wise that's a very bad idea imho, especially since i) it's stored in memory, ii) the eessi install command asks for confirmation several times, so it may be sitting there waiting for user input while it has the password sitting around "naked" in memory...

Instead, we should detect whether eessi install is being run with admin permissions. If not, we should print a useful error message that mentions why eessi install needs to be run with sudo, providing an overview of all the actions it will take.

We can also change the confirmation to a single one at the very start, which lists all the things that will be done, and asks the user to confirm that's all good and that those system-wide actions can be taken.
We probably also want a --yes option to bypass the confirmation.

[ocaisa]

I would even go further and limit the actions that can be taken when running with sudo to only those that require it, running with sudo should almost never happen.

[lexming]

I disagree, it is much unsafer to do a sudo eessi install. That runs everything as root, the full python interpreter, we don't want that. Any issue/bug at any level can have terrible implications in the system.

Commands executed as root should be fine-grained, and keeping the user password in memory is a non-issue; program memory is safe. Passwords are not "naked" in memory, they are just in memory; and that is a standard practice. Program memory is not accessible except to the program itself (unless there would be a critical error like a buffer overflow).

This code is not storing that password in any persistent memory, like a file; and it is not transmitting the password over the network. So the only way to get that string is by hacking the memory stack of python, good luck with that.

update: if you are really concerned about security, the current setup can be improved by wiping the password after every use. But that will require to input that password on every command that needs root permissions. Would you prefer this approach?

[boegel]

@lexming Right, OK, I see your point.

We can also take into account that quick subsequent calls to sudo generally don't require you to re-enter the password, so maybe we could try running sudo passwordless, and only actually ask the password when sudo requires it?
Not sure if that's easy to do...

In practice, that would mean you only need to ask the password once, and "wiping it" right after use makes sense, but I don't think it's that easy to do (since it's passed by value into functions).

[lexming]

The user password is now systematically cleared after a timeout that starts with the password prompt. To keep things simple, the reset after the timeout is unconditional.

Currently, the timeout is set in SUDO_PWD_TIMEOUT_SEC to 30 seconds. This time should allow to run the full eessi install process in normal conditions. But if for some reason the process gets stuck, we clear the password for better security.

I moved the methods to run commands into their own class CmdRunner, this allows to:

• keep the sudo password in a single class attribute, avoiding passing it around methods
• start a timer whenever we prompt for the password
• clear the sudo password once the timer ends