Dear Users,
we just installed and configured a new CYLC instance based on 8.2.1 version.
It has been deployed on a virtual machine and It can reach the login nodes of our HPC cluster.
So, we can play workflows from CYLC and dispatch them, through the login nodes, on the compute nodes.
In order to make CYLC working, we had to install also CYLC “client” (in distributed mode) on login nodes. Anyway, we recently understood that HPC cluster users launch their workflow from login nodes, not from the CYLC VM.
Is there anything we can do to avoid the workflows executions directly from login nodes?
Many thanks in advance,
Mauro
Does the Cylc VM mount the same filesystems (e.g. $HOME) as the login nodes?
If so you can configure Cylc to run any workflows on the the Cylc VM:
https://cylc.github.io/cylc-doc/stable/html/reference/config/global.html#global.cylc[scheduler][run%20hosts]
This won’t work if the filesystems are different. However, you can block workflows from being accidently launched on the login node by configuring [scheduler][run hosts]available and [scheduler][run hosts]condemned to the same host name. This will cause cylc play to fail.
1 Like
Thank you very much for your help!
You really helped me to solve my issue and I appreciated it.
Now, I have the last problem to solve 
I noticed that some HPC cluster users installed CYLC in their home directory (on the login nodes) using mamba…(no words!). It is very difficult to control their behaviour. We sent several e-mails to the users, but it is not enough. I was thinking to block standard CYLC ports using firewall, but they can change them.
Is there a way to make users CYLC instances not working (only the official CYLC service must be used, that is the one we prepared for them)?
Thank you in advance,
Mauro
It is very difficult to control their behaviour.
Ain’t that the truth! 
One of the great advantages of Cylc (as compared to monolithic workflow engines used in similar fields, which require system privileges and a lot of admin) is that it is easy for individuals to install and use in their own environments for their own purposes, on their own personal machines, or even in their own account on a shared platform where Cylc is not an officially supported application.
Given that, I suspect there is not much you can do easily, other than making it a “working practice” issue that your users are encouraged or perhaps even required to comply with. And explain that there is really no sensible reason to install and configure your own version if there is a central one that is maintained and kept up to date.
After all, Cylc is just software. Can you prevent users from installing and using any other software package? (Especially when they can easily change the name of executables, and config file paths).
The good news is, even if your users want to make life difficult for themselves by managing their own Cylc installation, it won’t allow them to do anything on the system that they can’t already do without Cylc. (It just lets them automate stuff that could in principle be run by hand).
Still, I’d be interested to hear if you do come up with an effective way to disable user-installed Cylc versions!
1 Like
Note, one of the advantages of using the centrally installed version is that the pool of hosts used to place Cylc schedulers (via “available hosts” above), with some load balancing, can be managed centrally so it will just work automatically for users. (However, you probably can’t really stop them from doing exactly the same thing with their own user-specific global.cylc file).
1 Like
Hi Oliver,
many thanks for your very importanti reply.
I think I will create a script that will run as a daemon to detect running cylc instances started by users.
It will send us a notification mail.
It is the only thing we can do it, at this point.
Thanks again for you help.
Mauro