Project

General

Profile

Bug #12926

change error message from jobsub_client when kerberos credentials and/or proxy not found

Added by Dennis Box about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
06/14/2016
Due date:
% Done:

0%

Estimated time:
First Occurred:
Occurs In:
Stakeholders:
Duration:

Description

Current error message:
[dbox@novagpvm01 ~]$ jobsub_submit --role Production -G nova --jobsub-server https://fermicloud042.fnal.gov file://novapro_sleep.sh
WARNING: /tmp/jobsub_x509up_u8531_nova is not valid. Attempting to regenerate
Cannot find credentials to use. Try the following:

- If you have an FNAL kerberized account, run 'kinit'.
- Otherwise, if you have an FNAL services account, run the following cigetcert command and which
will prompt for your services password, then resubmit your job:
'/fnal/ups/prd/cigetcert/v1_0_0/Linux64bit-2-6-2-12/bin/cigetcert s fermicloud042.fnal.gov -kv -o /tmp/jobsub_x509up_u8531_nova; export X509_USER_PROXY=/tmp/jobsub_x509up_u8531_nova'
Otherwise, follow the instructions at https://fermi.service-now.com/kb_view_customer.do?sysparm_article=KB0010798 to obtain a services and/or kerberized account.

Daves comments/suggestions:

I thought Parag said jobsub was intended to be able to be used by
other projects too, not just those based here at Fermilab. Currently
yes, FNAL's the only place, but is it OK to encode that in an error
message? Maybe it's fine for now but one day we may want to take it
out or change the message. Also, DCAFI phase 2 is supposed to be able
to support federated identity with other institutions, and then an
FNAL kerberos account won't always be relevant anymore; at that point
there could be other institution-specific kerberos accounts for the
other institutions.

(That reminds me, you said the other day that there are still places
where jobsub calls kx509 in the new authentication scheme, and I don't
think that's a good idea because that command is Fermilab-only. The
reason why I suggested the cigetcert -s option in the first place was
because Parag objected to anything Fermilab-specific in Jobsub. You
should be able to use cigetcert -s anywhere jobsub needs to get a
certificate, in place of kx509.)

- Otherwise, if you have an FNAL services account, run the following
cigetcert command

You could leave out 'cigetcert', the details are later.

and which

Drop the "and".

will prompt for your services password, then resubmit your job:
'/fnal/ups/prd/cigetcert/v1_0_0/Linux64bit-2-6-2-12/bin/cigetcert -s
fermicloud042.fnal.gov -kv -o /tmp/jobsub_x509up_u8531_nova; export
X509_USER_PROXY=/tmp/jobsub_x509up_u8531_nova'

That's an awfully long command, much longer than I had envisioned. The
export part shouldn't be necessary for the user to run, correct? Aren't
you defaulting it to that file name? Also cigetcert should aready be in
the user's PATH so they shouldn't have to use the full path to get it.

It's better not to use '-k', because that makes cigetcert attempt to try
kerberos, but your message said it will prompt for the services
password. If the reason for the cigetcert failure was not because of a
lack of kerberos, it may confuse the issue if it succeeds with kerberos
but then fails on something else. The interface design document at
https://cdcvs.fnal.gov/redmine/documents/969
said the message should tell the user to run
cigetcert -s $SERVER
although I see how you need it to also add the -o option in this case.

At least, I assume you have a good reason for not using the default
vaule of /tmp/x509up_`id`. I hope there are situations where that is
used, such as for user (analysis) jobs.

I don't think it's good to advise the user to add the '-v' option
either. The default is better for the average user, and they can add -v
if they know what they're doing.

Dave

History

#1 Updated by Dennis Box almost 3 years ago

  • Status changed from New to Resolved

#2 Updated by Dennis Box almost 3 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF