Hi Benjamin,
I agree with Ruben here. Try submitting the job and handle the "not
authorized" reply as the test for that user. A positive test for
authorization successful really only scratches the surface anyway.
For a WS GRAM job, there are many levels where the job can fail.
1) Service authentication (e.g. CA not trusted)
2) Service authorization (e.g. user not trusted / not in gridmap file)
3) Service mis-configuration
a) local account issues
b) Sudo misconfigured
c) LRM misconfigured (e.g. user not authorized to submit to LRM)
4) Dependent staging service misconfiguration
Any/All of the issues for the above steps for 1 - 3, but for the
staging services (RFT, GridFTP) that WS GRAM is dependent on.
The ping / authorization feature request would only do #1 + 2. I
guess a metascheduler could do this for a user as a test and assume
that the other steps are also setup, but in the end, I think it makes
more sense to just submit the job and see if it works. If it does
keep a history of what worked and how well. Sounds like this is what
GridWay is doing.
One possibility would be to add a GRAM factory RP that is authorized.
Currently, the RPs are not. So, an RP query would not help do what
you want, but this could be added. However, I don't want to add a new
"ping" RP unless it really makes sense. Do you still see a need for it?
Cheers,
-Stu
On Mar 18, 2008, at Mar 18, 4:52 AM, Ruben S. Montero wrote:
Hi,
In fact, having such a method (auth check) would not provide any
additional
benefit from the meta-scheduler (application) point of view.
GridWay uses the
target job to test authorization,so if the user is in the gridmap-
file no
additional overhead is added, if not you'd have the same overhead as
checking
the authorization. This is if you check the resource before using
it you'd
be adding that overhead to every single job.
Additionally, you have to "remember" those resources that failed
for a given
user (note that the user-specific is quite important here), GridWay
uses an
exponential backoff for this (note also that the initial failure
could not be
related to any authorization issue). So once the system has been
running for
a while GridWay automatically buids a list of authorized resources
for each
user.
Ruben
On Monday 17 March 2008 14:29:13 [EMAIL PROTECTED] wrote:
Benjamin,
unfortunately there's no way to check that without
submitting a dummy job (like /bin/true).
And all in all it might not be so easy to do this if
you're really serious about it. If a job includes file
staging you would have to check with RFT and GridFTP
servers also.
Martin
On Mon, Mar 17, 2008 at 4:36 AM, Benjamin Henne
<[EMAIL PROTECTED]> wrote:
Is there any way to ask a GRAM directly whether an user has
rights to
access it? I mean something simple like "Am I in your grid-
mapfile?".
You're assuming that all GRAM services are protected by a
grid-mapfile, which is not true.
Or is the only way to discover wheter an user has rights to
access and
use a GRAM the submission of a test job and looking if the jobs
runs or
fails?
Well, it seems you'd actually have to make a request to GRAM to
exercise the configured authorization chain (which may or may not
include gridmap processing).
I am doing tests with GridWay metascheduler. Currently the
metascheduler
does not know which user has rights on which maschine and hence
only
tries using a GRAM and if it fails it tries the next one. I guess a
minimal enhancement would be the possibility to ask a GRAM for
rights
instead of waiting for failure when trying to create the working
directory.
I don't know if GRAM supports a no-op but it should be possible to
implement something analogous to an HTTP HEAD request. Just a
thought...
Tom
+---------------------------------------------------------------+
Dr. Ruben Santiago Montero
Associate Professor
Distributed System Architecture Group (http://dsa-research.org)
URL: http://dsa-research.org/doku.php?id=people:ruben
Weblog: http://blog.dsa-research.org/?author=7
GridWay, http://www.gridway.org
OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+
