Where to submit a job instead of pbs server

Hi all:
I know i can sumbit a job in a pbs server node, and i think every can login this master node must be a bad idea; so is there other ways to submit a job?

If you do not want users to log into the pbs server node then you can install the commands rpm on login node(s). This allows the users to submit job to the cluster without having to login to the server.

Hi Jon,

Please provide the required configuration/steps for achieving the submit/login node requirement to submit the job without login in to the master nodes.

Atul Yadav
Locuz HPC Team

Hi @atulyadavtech,

Download PBS (pbspro_14.1.2.centos7.zip) from http://pbspro.org/Download.aspx#download. Then extract the client rpm called “pbspro-client-14.1.2-0.x86_64.rpm” from the zip file. Copy over to the linux machine from where you want to submit jobs and install it. Updated the variable PBS_SERVER in /etc/pbs.conf to point to the host that is running pbs_server. Given network connectivity, you should now be able to submit jobs from this machine.



After completing the activity as per the instruction. we are unable to submit the jobs.
Getting Error
qsub: Bad UID for job execution

User is available from NIS
Home Directory is also common
Selinux disable
SSH Password less working fine

Please guide us further.

Thank You
Atul Yadav
Locuz HPC Team

If you trust the user id for the systems in your environment then in qmgr do

set server flat_uid=true

and your jobs from that system should work as expected.

Are you trying to submit the job as root? If so, it needs to be explicitly
enabled by doing a qmgr -c “s s acl_roots=root”, or else submit the job as
a regular user.

Hi All,

Not using root account for job submission.

Getting Syntax Error
qmgr -c "set server flat_uid = true"
qmgr: Syntax error
set server flat_uid = true

pbs_version = 17.1.0

Thank You
Atul Yadav
Locuz HPC Team

Hi Team,

Got the solution.
It should be
qmgr -c “set server flatuid = True”

Thank for your guidance and quick support.

Atul Yadav
Locuz HPC Team

Here is a bit more detail about what is happening.

For a job to be accepted by the PBS server, the user at the submitting host must pass an ruserok() test.

From the RCMD(3) man page:

The iruserok() and ruserok() functions take a remote host’s IP address or name, respectively, two user names and a flag indicating whether the local user’s name is that of the superuser. Then, if the user is NOT the superuser, it checks the /etc/hosts.equiv file. If that lookup is not done, or is unsuccessful, the .rhosts in the local user’s home directory is checked to see if the request for service is allowed.

If this file does not exist, is not a regular file, is owned by anyone other than the user or the superuser, or is writeable by anyone other than the owner, the check automatically fails. Zero is returned if the machine name is listed in the hosts.equiv file, or the host and remote user name are found in the .rhosts file; otherwise iruserok() and ruserok() return -1. If the local domain (as obtained from gethostname(2)) is the same as the remote domain, only the machine name need be specified.

If the pbs_server attribute flatuid is set to true, this test is skipped and the job is accepted based on the submitting users name alone (with obvious security implications: a rogue user on a system that they control could create a user account with the same name as someone else and submit jobs as that user; if this is a concern but for whatever reason you don’t want to set things up that ruserok() passes, consider using the PBS server attributes acl_host_enable and acl_hosts to whitelist trusted job submission hosts where the user accounts are trusted).

Flatuid set to true or not, to run as a user other than the job owner (the submitter) you must have authorization to do so via ruserok(). Otherwise, any user could run a job as any other user. You authorize for userA to run a job as userB the same way you authorize userA@host1 to run a job as userA on host2 when flatuid is Not SET, i.e. see .ruserok() and .rhosts.

Finally, I don’t think you need it here, but to make this post more complete and useful I will include a simple test program I have used in troubleshooting over the years to see if ruserok() passes for a given user and host:

   Two use cases:
    1) User submitting job from remote host to server getting unexpected
        "Bad UID" message. That is, user doesn't have access when he thinks
        he should.
    2) User(s) can delete, etc other user(s) jobs. That is, one user is able
        to act as what he thinks is a different user, server sees them as
        being equivalent.

Build with "cc ruserok.c -o ruserok"

Usage (run on the PBS server system):

ruserok remote_host remote_user1 local_user2


remote_host:  the host from which the job is being submitted, or where the PBS client command is issued

remote_user1: the username of the user submitting the job, or issuing the client command

loca_user2: the username of the user remote_user1 is trying to submit the job as, or owner of the job that remote_user1 is trying to act on with the client command


#include <errno.h>
#include <stdio.h>
#include <unistd.h>
int main(int argc, char *argv[])
        int rc;
        char hn[257];

        if (argc != 4) {
                fprintf(stderr, "Usage: %s remote_host remote_user1 local_user2\n", argv[0]);
                return 1;
        if (gethostname(hn, 256) < 0) {
                perror("unable to get hostname");
                return 2;
        hn[256] = '\0';

        printf("on local host %s, from remote host %s\n", hn, argv[1]);
        rc = ruserok(argv[1], 0, argv[2], argv[3]);
        if (rc == 0)
                printf("remote user %s is allowed access as local user %s\n", argv[2], argv[3]);
                printf("remote user %s is denied access as local user %s\n", argv[2], argv[3]);

        return 0;
1 Like

Thank you so much scc for detailed explanation.