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

[dsudar]

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]

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

ansible-role-omero-server/tasks/omero-user.yml

Lines 6 to 13 in ed4960d

	user:
	name: "{{ omero_server_system_user }}"
	home: "{{ omero_server_basedir }}"
	createhome: false
	state: present
	system: true
	uid: "{{ omero_server_system_uid | default(omit) }}"
	when: omero_server_system_user_manage

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]

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]

@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]

@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]

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]

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.