We have suites that are started as “user_A” and they are monitored by “user_B”. User_B is not allowed to start suites, but they can view tasks/logs and re-run failures, and otherwise manipulate the runs from GCylc.
If “user_B” monitors a suite with gcylc, then they are able to view the job.out and other output files from the GUI.
If they launch gscan and then double-click on a suite, the resulting gcylc window does not allow them to view output. They get an ssh error because it’s trying to ssh to the suite hosts as “user_A”:
I’ve tried setting “use login shell = False” but that doesn’t seem to help. Also, it works fine when they manually open a single suite; it’s only when they open a suite from gscan does the issue occur…
This is the intended behaviour. It makes sense for setups where users have SSH access to “role” accounts under which the workflows are run.
There isn’t a switch to toggle this behaviour (use login shell is to do with the sourcing of shell profile files e.g. ~/.bashrc).
I think this behaviour is controlled by a single line of code:
Removing the --user argument should disable the SSH for the GCylc launcher, however, this approach is baked into other Cylc commands e.g. cylc cat-log.
With Cylc 8 the situation becomes simpler, Cylc 8 is a single-user application so the command line will no longer re-invoke over SSH. Multi-user functionality will be provided by the UI Server which powers the GUI.
Note: In a future release we will be able to reroute the CLI via the UI Server to provide an SSH’less multi-user CLI e.g. cylc stop ~some-user/some-workflow.
Hm, I think maybe the issue for us is the “–user=” + owner part on line 437. Owner is user_A but user_B does not have permission to log in as user_A for separation of roles/IA rules. We’d need “owner” changed to whatever current user is… Also, in our case, user_B is already a shared role account, as is user_A but they’re different roles (user_A is “manager/full-control” and user_B is “monitor/limited-control”).
I thought as long as a user has read permissions to the suite password and certs, they could do things like re-run tasks and hold the suite. Do they also need to have login permissions for the suite owner?
Edit: and to clarify (because I had forgotten the original issue): this only comes up when trying to view job output. User_B does have the capability to hold/re-run tasks. They just can’t view the logs.
Holding and retriggering tasks etc. is done via the suite daemon’s network interface, which given the right credentials is easier to arrange across different user accounts than filesystem access and process execution.
The Cylc 7 GUI literally reads job logs off of disk, rather than asking the suite daemon for them (or at least it executes a process that does that).
If it works when you start a “cylc gui” directly but not when you start one from “gscan” the difference is presumably due to where (which account or host) gscan is launching the “cylc gui” application on… which is controlled by the code highlighted by Oliver above. So hopefully you could modify that to suite your circumstance? And as also noted above, Cylc 8 makes this problem go away.