# Running qsub inside a container **URL:** \ **Category:** Developers\ **Created:** [December 14, 2020, 6:45pm UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398 "2020-12-14T18:45:20Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![matzmz](https://avatars.discourse-cdn.com/v4/letter/m/2bfe46/32.png) [@matzmz](https://community.openpbs.org/u/matzmz)\ **Post date:** [December 14, 2020, 6:45pm UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398/1 "2020-12-14T18:45:20Z")
I have a legacy software that use qsub/qstat/qdel (it submit jobs programmatically). I don’t want to pollute the system installing a lots of legacy dependencies. My idea is to create a container (in my case i use singularity). In the container i have installed al dependencies excluding pbs. Than i have bindend pbs installation dir from host to container. I have the following error: ``` $ singularity shell --bind /opt/pbs --bind /etc/pbs.conf /work/XXXX/legacysofware.sif Singularity> /opt/pbs/bin/qstat pbs_iff: cannot connect to host pbs_iff: cannot connect to host auth: error returned: -1 auth: Unable to authenticate connection (XXXXX:15001) Invalid argument qstat: cannot connect to server XXXXX (errno=-1) ``` I think that the problem is related with the setuid bit of pbs\_iff. For security reason is disabled on singularity. Do you have any suggestion ? There is a clean way to solve this problem? ---
**Author:** ![speleolinux](https://avatars.discourse-cdn.com/v4/letter/s/779978/32.png) [@speleolinux](https://community.openpbs.org/u/speleolinux)\ **Post date:** [December 16, 2020, 3:09am UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398/2 "2020-12-16T03:09:21Z")
Why not just install pbspro-client in the container and treat that container as a submission node? You then do not need to bind /opt/pbs or anything else. ---
**Author:** ![alessia](https://avatars.discourse-cdn.com/v4/letter/a/bb73d2/32.png) [@alessia](https://community.openpbs.org/u/alessia)\ **Post date:** [December 18, 2020, 2:19pm UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398/3 "2020-12-18T14:19:41Z")
Hi @speleolinux, thanks for the suggestion. We did it (so we installed pbspro-client in the container) but we still have the same problem, that is: Singularity\> /opt/pbs/bin/qstat pbs\_iff: cannot connect to host pbs\_iff: cannot connect to host auth: error returned: -1 auth: Unable to authenticate connection (XXXXX:15001) Invalid argument qstat: cannot connect to server XXXXX (errno=-1) Do you have any hints? ---
**Author:** ![speleolinux](https://avatars.discourse-cdn.com/v4/letter/s/779978/32.png) [@speleolinux](https://community.openpbs.org/u/speleolinux)\ **Post date:** [January 18, 2021, 6:23am UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398/4 "2021-01-18T06:23:47Z")
> auth: Unable to authenticate connection (XXXXX:15001) > The port is blocked for some reason. 15001 is the port that the PBS server on the head node listens on. > Check your firewall is not blocking the singularity node on the server. > Check you do not have a firewall running in the singularity. > Check root on the singularity is the same as root on the server. Maybe try starting the singularity as root to see if you get the same problem. > Check your running the same version of PBS in the container as on the head node. > Can you ping or ssh to the head node from the singularity and vice versa. > Mike ---
**Author:** ![taco](https://avatars.discourse-cdn.com/v4/letter/t/ec9cab/32.png) [@taco](https://community.openpbs.org/u/taco)\ **Post date:** [February 2, 2021, 12:56pm UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398/5 "2021-02-02T12:56:22Z")
Same problem here, in the end I created a wrapper for qsub that executes a qsub with ssh on a node that is not running singularity. Not the cleanest way to do this. I would like to have a pbs client install without the need for suid. ---
**Author:** ![alexis.cousein](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.openpbs.org/alexis.cousein/32/265_2.png) [@alexis.cousein](https://community.openpbs.org/u/alexis.cousein)\ **Post date:** [February 25, 2021, 8:18pm UTC](https://community.openpbs.org/t/running-qsub-inside-a-container/2398/6 "2021-02-25T20:18:50Z")
You need to use munge _or_ enable the container to have an IP address on the host interface. For Munge see: > **[openpbs/openpbs](https://github.com/openpbs/openpbs/tree/master/src/lib/Libauth/munge)** > > master/src/lib/Libauth/munge If you don’t use munge, then the authentication method is “resvport”. That _cannot_ work with a NAT in between. “resvport” means that pbs\_iff will get a reserved port, connect with it to the server, and then vouch for the earlier established client connection by telling it what IP address and port are OK to listen to, but if what the server sees are different ports on the host side of a NAT it won’t work. With Munge you don’t need a second TCP connection from pbs\_iff that will use the port if the client in its message – authentication is in-band. If you container has an IP alias on a host interface then you also won’t have a NAT and then resvport will also work.