# Pbsconf error: pbs conf variables not found **URL:** \ **Category:** Users/Site Administrators\ **Created:** [June 24, 2021, 9:27pm UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670 "2021-06-24T21:27:47Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Chase](https://avatars.discourse-cdn.com/v4/letter/c/76d3ee/32.png) [@Chase](https://community.openpbs.org/u/Chase)\ **Post date:** [June 24, 2021, 9:27pm UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/1 "2021-06-24T21:27:47Z")
A coworker and I have been able to get openpbs 20.0.1 built within a docker container based on Ubuntu 14.04 where software development happens (we’ve posted a couple other threads with different issues). This will allow our users to send a job from that environment to our head node (Ubuntu 18.04) hosting the scheduler server. Here is one of the earlier threads. [PBS 20.0.1 Within 32-bit Docker container - #4 by Chase](https://community.openpbs.org/t/pbs-20-0-1-within-32-bit-docker-container/2473/4) Now that openpbs is built in a docker container with Ubuntu 14.04, there seems to be a pbs system variable that isn’t being recognized. openPBS won’t start and is giving this error. sudo service pbs restart pbsconf error: pbs conf variables not found: PBS\_HOME PBS\_EXEC PBS\_SERVER /opt/pbs/sbin/pbs\_comm: Configuration error pbs\_comm startup failed, exit aborting I can echo each of those variables with responses echo $PBS\_HOME \>\> /var/spool/pbs echo $PBS\_EXEC \>\> /opt/pbs echo $PBS\_SERVER \>\> \ Here’s the pbs.conf: PBS\_EXEC=/opt/pbs PBS\_SERVER=\ PBS\_START\_SERVER=0 PBS\_START\_SCHED=0 PBS\_START\_COMM=1 PBS\_START\_MOM=1 PBS\_HOME=/var/spool/pbs PBS\_CORE\_LIMIT=unlimited PBS\_SCP=/usr/bin/scp PBS\_DAEMON\_SERVICE\_USER=root I’ve found very little about this error. Any thoughts? Thanks ahead of time ---
**Author:** ![Chase](https://avatars.discourse-cdn.com/v4/letter/c/76d3ee/32.png) [@Chase](https://community.openpbs.org/u/Chase)\ **Post date:** [June 25, 2021, 8:38pm UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/2 "2021-06-25T20:38:33Z")
I should also mention that I can successfully ping the head node and I have the IP address and hostname in the /etc/hosts file. ---
**Author:** ![smgoosen](https://avatars.discourse-cdn.com/v4/letter/s/53a042/32.png) [@smgoosen](https://community.openpbs.org/u/smgoosen)\ **Post date:** [June 25, 2021, 10:19pm UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/3 "2021-06-25T22:19:12Z")
This appears to be a compute node. You don’t need a pbs\_comm on a compute node, one pbs\_comm running on the server/scheduler headnode is enough for a small-medium cluster. You could set PBS\_START\_COMM=0. As for the pbs\_mom, is it running after you start up? If not, can you run the pbs\_mom daemon directly (/opt/pbs/sbin/pbs\_mom)? ---
**Author:** ![Chase](https://avatars.discourse-cdn.com/v4/letter/c/76d3ee/32.png) [@Chase](https://community.openpbs.org/u/Chase)\ **Post date:** [June 26, 2021, 2:46am UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/4 "2021-06-26T02:46:30Z")
This instance of openPBS will be communicating with our head node that hosts the schedule server. To be clear, this openPBS instance is contained in a docker container (on users laptops) while the head node resides on a separate server. I was wondering exactly what daemons would be necessary for that. From my reading, I thought I would need both the comm and mom daemons running. With that in mind; Do you think I still don’t need the pbs\_comm? ---
**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:** [June 30, 2021, 9:47pm UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/5 "2021-06-30T21:47:39Z")
First of all, why are you running a MoM there? For users to “send a job” to the head node you would rather expect either a server to be there (which could indeed send jobs over) or just the client commands. A MoM would be needed to run PBSPro jobs in the container itself (and is quite the can of worms if NAT gateways are involved) that others from outside would submit to a server that knows the MoM, which doesn’t sound what you are trying to achieve. Client commands just need an /etc/pbs.conf but really will only use PBS\_SERVER and PBS\_EXEC. There is no need for daemons to use e.g. “qsub” to submit jobs to the head node. If you are in a container and there is a NAT gateway (i.e. the container does not use host networking and so doesn’t have an extra IP address on the host’s ethernet interface) you’ll have to use munge authentication, though. resvport won’t work. ---
**Author:** ![Chase](https://avatars.discourse-cdn.com/v4/letter/c/76d3ee/32.png) [@Chase](https://community.openpbs.org/u/Chase)\ **Post date:** [July 1, 2021, 4:04am UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/6 "2021-07-01T04:04:03Z")
Thanks. I was beginning to realize that I was not correctly understanding what components would be necessary for this type of setup. I was initially thinking the pbs\_comm and pbs\_mom daemons would be needed to establish networking. After reading up more on multihomed setups I’m uncertain exactly what is needed. I read that interactive jobs need MoMs to establish a connection (interactive jobs are something my users will likely make use of). Regarding munge authentication. I’m not familiar. Feel free to point me to some documentation. I have an LDAP server running on our cluster that is authenticating users. ---
**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:** [July 1, 2021, 7:59am UTC](https://community.openpbs.org/t/pbsconf-error-pbs-conf-variables-not-found/2670/7 "2021-07-01T07:59:00Z")
Nowhere do you need a daemon to run client commands. Client commands simple open a TCP connection to PBS\_SERVER. But if you don’t use munge, they will _also_ run pbs\_iff which will vouch for a particular port/address combination, which won’t work through a NAT gateway. So that forces you to run the container using host networking, _and_ it will only work if the remote machine doesn’t have a NAT gateway between itself and the server. If you want to be able to work just with a single TCP connection and in-band authentication (instead of pbs\_iff) then you need Munge. It’s a daemon with a private key that allows a host to verify that someone pretending to be user X at least has authenticated as user X (through other mechanisms) on a host in the munge domain with the same key. For that you run munged in the entire domain with the same key installed. That’s it. On the PBS side you add munge to PBS\_SUPPORTED\_AUTH\_METHODS (if it’s not there then it’s silently just “resvport”) and add PBS\_AUTH\_METHOD=munge to all the machines where you want munge to be used instead of resvport (usually if you install munge you use it for everything within the munge domain, i.e. even for daemon-to-daemon authentication.) I’d suggest searching Google for PBS\_SUPPORTED\_AUTH\_METHODS to find guides for its usage (often in PBS Professional documentation). For OpenPBS, see [https://openpbs.atlassian.net/wiki/spaces/PD/pages/1510604832/PR-1505+Introduce+LibAuth+and+refactoring+in+DIS+TPP+support+routines](https://openpbs.atlassian.net/wiki/spaces/PD/pages/1510604832/PR-1505+Introduce+LibAuth+and+refactoring+in+DIS+TPP+support+routines) But using a munge domain with domain members scattered on laptops roaming the planet is usually a security nightmare if that’s your only line of defence – it’s hard to ensure that your munge key will not be compromised one day. Frankly: if you have users with laptops roaming the world there are so many security implications and configuration issues that you’d be mad not to consider a VPN solution to make the client connection appear on the same network as the server, with a very strong authentication mechanism for setting up the VPN channel. Especially since that’s the only way that you’re going to be making qsub -I work, since for that qsub will be acting as a _server_ and the execution host needs to be able to connect to it as if they were on the same IP network (without any NAT translation). Whether you use a VPN on the host and use host networking in the container or set up a VPN connection from _within_ the container is something that I can’t decide for you.