search

test-fullautomation / RobotFramework_AIO

RobotFramework All in One installer
Apache License 2.0
6 stars 3 forks source link

Debian package postinstall not sufficient in non-root docker environment #296

Closed MarSianer1 closed 3 months ago

MarSianer1 commented 4 months ago

Installation of debian package installs sources in /opt/rfwaio for user and group 'root'. Additionally there are changes made in $HOME of the user that runs the installation ($SUDO_USER). When the installation is done in a docker container, then there is no $SUDO_USER per default. When now later the container is used as non-root, all changes formerly done in $HOME of root are not accessible and so Robot-AIO is not fully usable. The usecase of installing the package in a container should be considered, so multi-user usage should be possible

ngoan1608 commented 4 months ago

Hi @MarSianer1 ,

There is the executable script initRobotFrameworkAIO.sh (located under /usr/local/bin/) which helps to setup environment in case of multiple users.

Please execute it with your non-root user after AIO installation and let us know in case it does not work properly with your container environment.

Thank you, Ngoan

MarSianer1 commented 4 months ago

Hi @ngoan1608,

running this script when the user starts the container was my first idea. But I see some problems with that

  1. Script has no execution flag so it requires to be sourced.
  2. Script expects a file in /tmp/ which is not existing anymore when the container gets started
  3. Script doesn't check for file existence in many places. E.g. in container we do not install vscode, but function update_vscodium_package is called by the script
  4. Script assumes to be OSD5 but this is not true, sGroup='domain users' is invalid/unknown in container (line 121ff)
  5. Changing permissions of files in /opt/rfwaio requires root permissions which are typically not granted in a non-root container

Running the script after the installation of Robot-AIO package requires on one hand that the user has already been switched to the non-root one to have the $HOME in place, on the other hand root permissions are required to do this or that action. So right now there seem to be no way other than using sudo to exectue the script with success. And sudo in a non-root container is not acceptable. Maybe the script need to be split into two, one doing the action outside of $HOME that require root permission and another one doing the changes in $HOME with user permission. Beside this the problem with the group need to be resolved.

test-fullautomation commented 4 months ago

Hi @ngoan1608 , @huavanthong , please consider Marcs input. Besides usability has highest priority. Nicest solution would be if all will be automatically executed without manual interaction. Thank you, Thomas

test-fullautomation commented 3 months ago

integrated in 0.12.1