Hi Ste,
On Wed, Jan 02, 2019 at 04:43:31PM +0000, Stephen Jones wrote:
> Hi Mischa,
>
> I'll just say a few words, before I dig deeper, and perhaps it might remind
> you of something. I'm use GSI_PEP_CALLOUT in a HTCondor-CE setup on CentOS7.
> We use an ARGUS system. I'm using your argus test tool to debug the setep
> (which doesn't work yet). I suspect NSS/Libcurl.
>
> Part 1 : Running a job through HTCondor-CE that has to authenticate on
> ARGUS:
>
> In /var/log/messages, I see no activity on the ARGUS server. On the
> HTCondor-CE client I see this:
>
> Jan 2 16:26:17 hepgrid6 gsi_pep_callout[14917]: Authorizing DN
> /C=UK/O=eScience/OU=Liverpool/L=CSD/CN=stephen jones
> Jan 2 16:26:18 hepgrid6 gsi_pep_callout[14917]: argus_pep_callout:
> gsi_pep_callout_error: Authorization error: Can not map
> /C=UK/O=eScience/OU=Liverpool/L=CSD/CN=stephen jones to local
> identity#012gsi_pep_callout_error: PEP client error: Failed to authorize
> XACML request: Problem with the local SSL certificate
>
> And on the HTCondor-CE client in the GSI_PEP_CALLOUT_DEBUGFILE, I see this:
>
> * failed to load '/etc/grid-security/certificates/530f7122.r0' from
> CURLOPT_CAPATH
> * failed to load '/etc/grid-security/certificates/ffc3d59b.r0' from
> CURLOPT_CAPATH
> * CAfile: /etc/grid-security/hostcert.pem
This is not right. It looks like a misconfigured gsi-pep-callout.conf
Not sure what exactly you specified, but the hostcert should not be
specified as CAfile. Are you perhaps accidentally using proxy-like
configurations?
There are 3 relevant variables in that config:
pep_ssl_client_cert
pep_ssl_client_key
pep_ssl_server_cert
For proxy certificates, they all 3 need to be set to the proxy file.
For a hostcert/hostkey use the first two and leave out the last.
Not sure if that's the issue, but if the hostcert is set for all three
(e.g. by using it as a proxy file) you're probably missing the key,
hence the error.
> CApath: /etc/grid-security/certificates
> * unable to load client key: -8178 (SEC_ERROR_BAD_KEY)
> * NSS error -8178 (SEC_ERROR_BAD_KEY)
> * Peer's public key is invalid.
>
> Part 2 : Using your tool.
>
> Using the tool with PILOT_PROXY=/etc/grid-security/hostcert.pem, I again get
> "unable to load client key: -8178 (SEC_ERROR_BAD_KEY)". No sign of action on
> ARGUS server.
Indeed, that makes no sense, see above. If you want the tool with a
hostcert/key, you need to adapt where it writes out the config file (I
perhaps should have made it a bit more flexible, but then, it was only a
Friday afternoon debug script (-; ). I.e. change all the occurances of
PILOT_PROXY for either hostcert.pem, hostkey.pem or nothing.
> Using the tool with PILOT_PROXY=$X509_USER_PROXY, I see this:
>
> DEBUG4:debug_xacml_response: response.result[0].decision= Not Applicable
>
> I.e. it's getting through to the ARGUS server, but it says "Not Applicable".
A "Not Applicable" means that the server did understand the request, and
answered that there was basically nothing matching in its policy, so
neither a "rule permit" nor a "rule deny" matched.
> Given all this information, where would you be looking to find out what's
> up?
You probably want to have a look in the /var/log/argus/pdp/process.log
and /var/log/argus/pepd/process.log files.
> And what is PILOT_PROXY supposed to be? A user proxy, some random job
> proxy or the hostcert of the system or what?
There are two different scenarios, and typically two different entities
for each of those two. In either scenario, one entity contacts the Argus
server to ask about another entity. The latter entity is typically a user.
The contacting entity can be either a service using host credentials, or
a pilot job (typically for use with gLExec) using a pilot proxy.
So for example in case of a pilot job, the pilot sets up the TLS
handshake using its PILOT_PROXY and then asks about the payload user,
identified in the gsi-pep-callout using the X509_USER_PROXY.
Hope this clarifies this? Feel free to ask further.
On Wed, Jan 02, 2019 at 04:50:11PM +0000, Stephen Jones wrote:
> One extra thing (and a change to the Subject!)
>
> When using your tool, with PILOT_PROXY=$X509_USER_PROXY, I see this on the
> server in /var/log/argus/pepd/process.log (which is mysterious, since I'm
> using the proxy, not the hostcert.pem)
>
> WARN [AbstractX509PIP] - No VOMS attributes found in cert chain:
> CN=hepgrid6.ph.liv.ac.uk,L=CSD,OU=Liverpool,O=eScience,C=UK
In this case (which is fine for debugging) you do client-auth on
the TLS with same proxy as you ask to get mapped on the Argus server.
Assuming you actually do have a VOMS proxy (check with
"voms-proxy-info -all" or just "voms-proxy-info -vo"), not a plain
proxy, the Argus server does not recognize or accept the VOMS AC. It
could be that you're missing the .lsc files for the VO in question.
Check in /etc/grid-security/vomsdir/<VO NAME>
Cheers,
Mischa
--
Nikhef Room H155
Science Park 105 Tel. +31-20-592 5102
1098 XG Amsterdam Fax +31-20-592 5155
The Netherlands Email [log in to unmask]
__ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
########################################################################
To unsubscribe from the LCG-ROLLOUT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=LCG-ROLLOUT&A=1
|
