No ssh or rsh in compat layer

[casparvl]

I've hit this issue when trying to start EESSI from a container (note: this is not the EESSI container, it's just docker:rockylinux9 - I'm experimenting with mounting a squashfs filesystem providing EESSI into this container), but I expect it would happen on any system that doesn't have ssh or rsh.

mpirun -np 2 gmx_mpi --version
--------------------------------------------------------------------------
The value of the MCA parameter "plm_rsh_agent" was set to a path
that could not be found:

  plm_rsh_agent: ssh : rsh

Please either unset the parameter, or check that the path is correct
--------------------------------------------------------------------------
[tcn43.local.snellius.surf.nl:99269] [[INVALID],INVALID] FORCE-TERMINATE AT Not found:-13 - error plm_rsh_component.c(335)

Now, I'm not saying we should have ssh and rsh in the compat layer, but... at this point, we have software in the software layer (namely: OpenMPI) which relies on OS dependencies (namely ssh and rsh) that are NOT present in the compatibility layer. That means that, on a system with very minimal OS, a natively installed EESSI would not be able to launch MPI tasks.

[ocaisa]

I wouldn't be keen on this. I'd prefer to add an Lmod hook that complains if you try to load an OpenMPI module without the ssh command being available

[terjekv]

For what it's worth, I'm with @ocaisa here. Bundling ssh into the compat layer is a maintenance headache, and for environments that have strict ssh setups (ciphers, versions, etc) shipping a distinct ssh with its own configuration? That smells like a ticket generator.

[boegel]

Generally speaking, it should be very uncommon to not have the ssh command available, so I agree with @ocaisa as well, let's not try and fix "academic" situations and bring on a maintenance burden on ourselves for little benefit...

[bedroge]

Though it's in some sense a valid argument that the compat layer should provide such OS dependencies, I don't really like providing ssh in the compat layer either. I prefer @ocaisa's solution with the Lmod hook too. I suppose that any cluster set up for running MPI jobs would provide SSH already anyway, and for situations like the one you had with a container, it would probably be easy enough to install it in the container if you would really like to run MPI jobs that way.

[casparvl]

Generally speaking, it should be very uncommon to not have the ssh command available, so I agree with @ocaisa as well, let's not try and fix "academic" situations and bring on a maintenance burden on ourselves for little benefit...

It's not entirely academic, I had this with a pretty standard linux container (don't remember which one, Debian-something I guess) in which I mounted EESSI with a squashfs filesystem.

I wouldn't be keen on this. I'd prefer to add an Lmod hook that complains if you try to load an OpenMPI module without the ssh command being available

I think this is a good approach. I think @terjekv is right that whipping it would cause us only more pain. I'm also going to be honest: I don't have any time for this anytime soon. But at least we have the issue logged... :)