Open dsudar opened 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?
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?
@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?
@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?
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.
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.
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: