[Embarrassed cough]
Well, I spotted the problem in the end - I'd mistyped the
ARGUS_PEPD_ENDPOINTS yaim variable as http: rather than https: :-( Sorry
for the noise on this list.
John
On 10/10/2013 16:46, John Hill wrote:
> Oddly, there's nothing in the logs about my connection attempts. I may
> try increasing the debug level - if I can track down the way to do it.
>
> On the whitelist, I traced the problem - I needed to set the
> PILOT_JOB_FLAG yaim variable. For reasons lost in the mists of time, we
> don't use the default in users.conf (and it doesn't appear to have
> mattered for anything else). yaim uses this to populate the whitelist in
> /etc/glexec.conf.
>
> John
>
> On 10/10/2013 16:22, Stephen Jones wrote:
>> Good - that's means your request is getting to the ARGUS server. Maybe
>> find the logs there - it may say why it failed.
>>
>> Maybe a policy issue? Or that argus bug Chris mentioned? The logs should
>> say something.
>>
>> Steve
>>
>>
>> On 10/10/2013 02:51 PM, John Hill wrote:
>>> Incidentally, after fudging the whitelist on a WN to include the
>>> relevant user, your recipe returns
>>>
>>> [gLExec]: LCMAPS failed.
>>>
>>>
>>> and /var/log/messages has
>>>
>>> glexec[25919]: lcmaps: Error: pep_authorize(request,response) failed.
>>> The Argus-PEP return code is: 8 with error message: "authorize request
>>> error"
>>> glexec[25919]: lcmaps: LCMAPS failed to do mapping and return account
>>> information
>>>
>>> Cheers,
>>> John
>>>
>>> On 10/10/2013 14:40, John Hill wrote:
>>>> Hi Steve,
>>>> Thanks for the ideas. There's nothing in the ARGUS logs, which does
>>>> suggest a misconfigured CREAM CE - though I can't at present see what.
>>>> At the moment I don't have a functional gLExec WN (this was part of the
>>>> upgrade I am trying to implement) - which leads me on to a followup
>>>> question: where is it documented what to put in the whitelist on the
>>>> WN?
>>>> I can find nothing which tells me clearly what should be in there.
>>>> Indeed the documentation on how to implement gLExec seems so poor
>>>> that I
>>>> wonder how anyone else managed to do it.
>>>> Cheers,
>>>> John
>>>>
>>>> On 10/10/2013 13:51, Stephen Jones wrote:
>>>>> Hi John,
>>>>>
>>>>> On 10/10/2013 12:53 PM, John Hill wrote:
>>>>>> Unable to read response from PEP Server
>>>>>
>>>>> Here are some ideas. Are there any logs on the ARGUS server, and
>>>>> what do
>>>>> they say?
>>>>>
>>>>> cd /var/log/argus;
>>>>> find . -name "*.log" -exec ls -lrt {} \;
>>>>>
>>>>> You may find either a sign that it connected and then some message, or
>>>>> no sign at all. If there is no sign at all, then maybe it's a network,
>>>>> socket, port or config error on cream (assuming ARGUS firewall
>>>>> off). If
>>>>> there is a sign that it connected and failed, then maybe there will be
>>>>> another sign of why. Also, this test should work from any server
>>>>> (e.g.
>>>>> WN). See if it works:
>>>>>
>>>>> Be on a UI in your user account. Make a proxy.
>>>>>
>>>>> voms-proxy-init --voms dteam
>>>>>
>>>>> voms-proxy-info
>>>>>
>>>>> Be on test worker node, as root. Copy in the proxy with scp from
>>>>> location shown in voms-proxy-init to /tmp/x509up_u460
>>>>>
>>>>> Change ownership of proxy to some valid user of the ARGUS server (I
>>>>> use
>>>>> a pilot account).
>>>>>
>>>>> chown pilatl01:atlas /tmp/x509up_u460
>>>>>
>>>>> Change permissions.
>>>>>
>>>>> chmod 600 /tmp/x509up_u460
>>>>>
>>>>> Switch to the ARGUS user.
>>>>>
>>>>> su - pilatl01
>>>>>
>>>>> Run these commands to setup for the test.
>>>>>
>>>>> export GLEXEC_CLIENT_CERT=/tmp/x509up_u460
>>>>> export GLEXEC_SOURCE_PROXY=/tmp/x509up_u460
>>>>> export X509_USER_PROXY=/tmp/x509up_u460
>>>>>
>>>>> Do the test
>>>>>
>>>>> /opt/glite/sbin/glexec /usr/bin/id
>>>>>
>>>>> Note: In EMI2, use /usr/sbin/glexec. If all is well, you will see
>>>>> something like this:
>>>>>
>>>>> uid=24683(dteam184) gid=2028(dteam) groups=2028(dteam)
>>>>>
>>>>> If you don't see that, something is wrong. Check the ARGUS policies if
>>>>> it says "Not Applicable".
>>>>>
>>>>> Steve
>>>>>
>>
>>
|