[torqueusers] How to rip out user validation?

matthew devney matthew at devney.net
Wed Jun 23 10:47:37 MDT 2010

Thanks much Chris.  That's exactly what I needed.  I remain convinced
that most users probably want this functionality turned off.

After messing with this last night for a couple hours I never found
the problem.  As far as I can tell my hosts.equiv, dns names, users,
etc. are all set up properly.  Even compared against 2 working
clusters (both running torque 2.4.2).

In the end my solution was to try the exact same install procedure
with each version of torque successively going backward.  My procedure
is the stupid-simple install:
make install
./torque.setup user

When I got back to 2.4.2 it magically worked.  I do not know what is
broken with each successive version since then, but the above worked
with 2.4.2 and not with any version since.  I will be happy to isolate
this and file a proper bug report if someone will work with me on it.

Matthew Devney
matthew at devney.net

On Tue, Jun 22, 2010 at 6:05 PM, Christopher Samuel
<samuel at unimelb.edu.au> wrote:
> Hash: SHA1
> On 23/06/10 10:03, matthew devney wrote:
>> The ideal solution is a compile-time option: --disable-validation
>> after which anyone who can run qsub can run any jobs they like.
> I would suggest this isn't a good idea as Garrick has
> pointed out.
> The code that does the validation is intended as an example
> implementation and could be tuned to your needs - it lives
> here:
>  src/lib/Libsite/site_check_u.c
> and is called site_check_user_map(), the comments say:
> /*
>  * site_check_u - site_check_user_map()
>  *
>  * This routine determines if a user is privileged to execute a job
>  * on this host under the login name specified (in user-list attribute)
>  *
>  * As provided, this routine uses ruserok(3N).  If this is a problem,
>  * It's replacement is "left as an exercise for the reader."
>  *
>  *      Return -1 for access denied, otherwise 0 for ok.
>  */
> So it's trivial to patch to get the (lack of) functionality
> you see to want, but I'd suggest it's a very bad idea and
> could have a lot of unintended consequences.
> Much better to just set up your /etc/hosts.equiv file
> correctly on system running the pbs_server.
> cheers,
> Chris
> - --
>  Christopher Samuel - Senior Systems Administrator
>  VLSCI - Victorian Life Sciences Computational Initiative
>  Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545
>          http://www.vlsci.unimelb.edu.au/
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> Oc0An1iB8GxIsxeyoB7RV80TjaPRI9qR
> =NSn+
> _______________________________________________
> torqueusers mailing list
> torqueusers at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torqueusers

More information about the torqueusers mailing list