staypirate / secbox Goto Github PK

the container won't be able to automatically start after a reboot in openSUSE TW (maybe leap too) because the SSH_AUTH_SOCK env variable and "${SSH_AUTH_SOCK}:/ssh-agent" bind mounted socket are defined at container creation time, and won't be the same after an host reboot

Since all the required shares are already mounted in wotan.suse.de, adding the --sshfs options could allow having access to all of them without the need to locally mount them via NFS. Moreover, no higher privs will be required anymore :).

Hi,

when I try to compile a package locally using oscb (default secbox alias for osc build --ccache --cpio-bulk-download --download-api-only), the build stage fails with
sudo: No such file or directory: 'sudo'

Steps to reproduce:

1. osc co security:SELinux/selinux-policy
2. cd security:SELinux/selinux-policy
3. oscb

Misbehavior

secbox container was unable to access VPN resources because it was created before the VPN was on.

Reason

secbox is using --network host option at container creation, this (among other capabilities) allows containerized software to share the same resolver of the host system. This permits to containerized tools like osc to resolve internal domains (like: build.suse.de).

The container maintains its own copy of /etc/resolv.conf, which is copied from the host at the time of the container creation. If the host was configured to use the SUSE internal resolvers once the container was created, then the container would be able to use them since they will be present in its /etc/resolv.conf. Instead, if the container is created while the host is not connected to the VPN, it will inherit a not properly configured /etc/resolv.conf. If the host connect to the VPN only after the container is created, then the host will be able to resolve internal domains since it will be reconfigured to use the internal DNS servers passed via DHCP (and its resolv.conf change), but the copy maintained by the container won't be updated.

Workarounds

1. secbox creates a disposable container, hence it can be destroyed and recreated on-demand any time. After the VPN connection is established on the host side, the already existing container can be destroyed via secbox --destroy -f and the next issued secbox command will recreate the container, this time with access to the VPN resources.
2. Enter the container as root via secbox --root and manually update the /etc/resolv.conf

If I run secbox twice at the same time with the flag --nfs (same would happen with --sshfs #1) after the faster process terminates, secbox then umount the NFS exports leaving the second secbox instance without the needed resources.

Need to add a check before release the resources... check if another secbox instance are using them.

When secbox --destroy is ran, check if there are any other running instances in the system. If yes, abort destruction with a warning.

It could be helpful some times to initialize or overwrite environmenet variables for that command.

Pretending a --env option is implemented for that, an example could be:

secbox --env PYTHONPATH=/opt/imtools python3.11 -m imtools.im help

It should also work for appending data, like:

secbox --env PYTHONPATH=$PYTHONPATH:/opt/imtools python3.11 -m imtools.im help

The --env option could be passed multiple time.

secbox --env PYTHONPATH=$PYTHONPATH:/opt/imtools --env ABC=DEF python3.11 -m imtools.im help

Secbox can be called from a script and if an update is available it will make whatever command you are running interactive.
To better approach all any use-case, it is required to switch from the current interactive update prompt to an INFO message to the stderr which inform the user that an update is available. This change will require a new option --update-container.

The management of the container is currently not optimized due the fact that the logic is part of the sub-functions.
For instance start_container() calls create_container() when it should only start the container.

This generates confusion when other functions calls start_container() and then create_container(), like in update_image():

Functions need to be rewritten following the UNIX philosophy (or a KISS approach).

Having the possibility to force an update when a new version is not available will help to get the latest container-image built which might contains updated packages version installed.