eth-cscs / sarus

OCI-compatible engine to deploy Linux containers on HPC environments.
https://sarus.readthedocs.io/en/stable/
BSD 3-Clause "New" or "Revised" License
130 stars 10 forks source link

home basedir hard-coded #26

Open mvhulten opened 2 years ago

mvhulten commented 2 years ago

When running sarus pull, it tries to write to /home/$USER/.sarus/ instead of $HOME/.sarus/.

[submarco@vm-13.FRAM ~]$ sarus pull alpine
# image            : index.docker.io/library/alpine:latest
# cache directory  : "/home/submarco/.sarus/cache"
# temp directory   : "/tmp"
# images directory : "/home/submarco/.sarus/images"
> save image layers ...
[704118.455223156] [vm-13-8629] [main] [ERROR] Error trace (most nested error last):
#0   createFoldersIfNecessary at "Utility.cpp":460 Failed to create directory "/home/submarco"
#1   "unknown function" at "unknown file":-1 boost::filesystem::create_directory: Permission denied: "/home/submarco"
[submarco@vm-13.FRAM ~]$ echo $HOME
/home/sub/submarco

This is for instance relevant on our compute nodes where the user's homedirs are /cluster/home/${USER}.

Madeeks commented 2 years ago

Hi Marco, the location of the local image repositories can be configured through the localRepositoryBaseDir parameter in sarus.json. Sarus will attempt to create repository in <localRepositoryBaseDir>/<user name>/.sarus.

The initial value for localRepositoryBaseDir is set to /home by the configure_installation.sh script, but following your feedback I think it would be a better option to use ${HOME} in the configuration script in the future.

mvhulten commented 2 years ago

I see that /home is hardcoded in three lines in configure_installation.sh. I don't know if or where /${USER} is added at some point, so it looks like it is not completely trivial to "fix" this.

This is not an urgent issue as it is quite easy to resolve. In my opinion it would, in retrospect, also be okay to not fix it and close this issue.

Madeeks commented 2 years ago

After a more focused analysis, I realized that leveraging env vars like ${HOME} or ${USER} is not a viable solution: the configure installation script needs to be executed with superuser privileges, which means its home directory is usually set to /root, having no relationship with the location of home directories for regular users.

That said, I still think that the ability to guide in some measure the configuration created by the script would be a nice thing to have. For example, it could save time when very few modifications are needed from the base config. I'm considering the possibility to support arguments in the configuration script. If there is agreement with the rest of the dev team, this could be available in a future patch release.