ome / ansible-role-omero-server

Installs and configures OMERO.server
https://galaxy.ansible.com/ome/omero_server/
BSD 2-Clause "Simplified" License
4 stars 14 forks source link

setting up bash environment for omero-server and omero-web users #59

Open dsudar opened 3 years ago

dsudar commented 3 years ago

At least for the "ansible-example-omero-onenode" playbook and under Ubuntu 20.04, the omero-server and omero-web users are created but without a usable bash environment. Would be nice to have those accounts be immediately usable: 1: currently it gives a /bin/sh shell instead of /bin/bash 2: add a .bash_profile and/or .bashrc that sets some of the required PATH and other env variables, e.g. for omero-server:

# Location of the OMERO.server
export OMERODIR=/opt/omero/server/OMERO.server

# Location of the virtual environment for omero-py
export VENV_SERVER=/opt/omero/server/venv3

export PATH=$VENV_SERVER/bin:/opt/ice/bin:$PATH
sbesson commented 3 years ago

Thanks as always for the feedback. A few immediate thoughts.

1- /bin/sh vs /bin/bash that's a least a surprise to me as I was expecting bash to be the default shell when creating new users on Ubuntu. Otherwise, that's something that should be configurable in https://github.com/ome/ansible-role-omero-server/blob/ed4960dfa4638c5da8852806631595ec06ec7e8c/tasks/omero-user.yml#L6-L13 via an extra parameter

2- which workflows do you have in mind? For invoking OMERO CLI commands, the /opt/omero/server/OMERO.server/bin/omero wrapper should pre-set all the required environment and might be a workaround? Following the Python 3 upgrade and the separation of OMERO.py from the server bundle, we have certainly been facing ourselves the overhead of setting up a working environment. Setting up .bash_profile/.bashrc would definitely be a possibility for the omero-server/omero-web users and cover both interactive/non-interactive cases but it assumes a bash environment and the same logic would need to be duplicated for every new user added to the system?

dsudar commented 3 years ago
  1. Yes, surprise for me as well. Guess the Bourne Shell is still the official default.
  2. definitely for the newly created omero-server and omero-web accounts, setting up just enough of a bash env would be very useful so you can immediately do some basic things like "omero admin diagnostics" after ansible is done. For regular users (and also the 2 service accounts) I've set up a little "omero" script in /usr/local/bin (which is pretty much in everyone's path) similar to this:
    export OMERODIR=/opt/omero/server/OMERO.server
    /opt/omero/server/venv3/bin/omero "$@"

    Would it be too invasive for ansible to do something like that?

sbesson commented 3 years ago

@dsudar the idea of the /usr/local/bin/omero wrapper is certainly appealing. Brainstorming the idea with the team, I could easily imagine an extra task in the role adding a symlink from the wrapper script mentioned above.

As this should suffice to make the OMERO CLI usable out of the box for any user on the system (incl.diagnostics, import...), would that completely solve the usability problem here or is there an additional need for a shell profile?

dsudar commented 3 years ago

@sbesson ah yes of course. One thing to do in that case is adding /opt/ice/bin to the PATH. Only the "omero-server" user will actually need that but it can't hurt.

And sorry for bringing up something entirely different: why, in the docs and implemented in the roles, are the venv3 environments owned by root and not by the omero-{server, web} users? Whenever you want to pip install a plugin, you have to first become root, remember to activate that specific venv, etc. Wouldn't it be much easier to let the omero-{server, web} own their own venv and have it be activated upon login to that account?

sbesson commented 3 years ago

The /opt/ice/bin logic is already included in the wrapper so I would propose to start with an extra task creating a symlink under /usr/local/bin.

As per the ownership question, I did not implement this and thus my answer might not be the most authoritative one. I think the idea was to follow the principes of a package manager i,.e. requires root level permissions for the installation of the software and its dependencies and delegate the execution to a service user. I think the primary advantage is that the service user cannot accidentally delete/corrupt the installed files.

manics commented 3 years ago

And sorry for bringing up something entirely different: why, in the docs and implemented in the roles, are the venv3 environments owned by root and not by the omero-{server, web} users?

@dsudar I implemented this in the Ansible role 😄 . The goal was to have everything root owned read-only, following best practice for application installations. In practice this didn't work as OMERO.server expected write access to several directories, it's not as simple as making var writeable. I think it's a good long-term goal though.