Hi,
That's right the grid tools don't really care what version of torque and
maui you are using as long as they are consistent.
My suggestion is to set up your own torque and maui yum repository with a
yum priority higher than the emi or epel repos.
This has the added advantage that you won't be surprised by a torque or
maui update.
Yours,
Chris.
On 30/09/2011 17:22, "Stuart Purdie" <[log in to unmask]> wrote:
>On 30 Sep 2011, at 16:33, Stephen Jones wrote:
>
>> Stuart wrote:
>> ... I'm pretty sure that's what we do
>>
>> That's interesting. When I tried to install
>> EMI-CREAM/EMI-TORQUE_UTILS(torque 2.5...) to talk to a cluster with
>> EMI-TORQUE_SERVER (torque 2.3...), the first problem was about MUNGE,
>
>Ah! Not quite what we have - we've got torque 2.3 on each. Looks like
>the torque libs haven't been updated since I installed it, and if I
>remember correctly I had problems getting YUM to install torque at the
>time (unrelated reasons) - might be that 2.5 is realtivly new in EPEL?
>
>This does, however suggest a solution - if all else fails, just install
>and pin torque 2.3, and that (by experience) works. Then, once
>everything can move together, update all the machine to 2.5 at once.
>
>
>> i.e. qsub would grumble about a missing socket from a missing MUNGE
>> server. When I installed MUNGE, things went to the next step - I just
>> got "End Of File" messages from qsub. I figured that is because the pbs
>> server was getting off-protocol messages, i.e. some kind of MUNGE
>> message that the server doesn't want or understand.
>>
>> I'll try it again.
>>
>> Steve
>>
>>
>>
>>
>> Stuart Purdie wrote:
>>> On 30 Sep 2011, at 13:18, Stephen Jones wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> If everyone an early adopter, is anyone an early adopter? While we
>>>> ponder that, I've got something to say/ask about emi-cream and
>>>> emi-torque. Maybe an early-adopter could enlighten me?
>>>>
>>>> The plan was to fix a new new emi-cream onto our existing (separate)
>>>> glite_TORQUE_server cluster. But I discovered that emi-torque (server
>>>> and utils) is built to use MUNGE to safety transmit the login
>>>>details.
>>>> This is a new thing.
>>>>
>>>> Unfortunately, due to MUNGE, the emi-cream can't qsub from a system
>>>> using emi-torque-utils to a batch cluster headnode that uses
>>>> glite_TORQUE_server (job array syntax is also new). This would mean
>>>> that, by design, emi-cream cannot work with a standalone
>>>> glite_TORQUE_server cluster -- the whole lot has to be updated at
>>>>once.
>>>>
>>>
>>>
>>>
>>>> This could deserve a GGUS ticket, but I'm not sure of the facts -- is
>>>>it
>>>> possible to run emi-cream/emi-torque-utils with an existing
>>>> glite_TORQUE_server?
>>>>
>>>
>>> ... I'm pretty sure that's what we do
>>>
>>> Ok, strictly, no - we're using what looks like the SL5 native Torque,
>>>probably inherited from Centos, not the gLite one.
>>>
>>>
>>>> Should it be possible to qsub from a
>>>> system using emi-torque-utils to a batch cluster headnode that uses
>>>> glite_TORQUE_server?
>>>>
>>>
>>> I've been able to qsub, and I can assure you that we're defiatly using
>>>ruserok (and not munge) on our torque head node, and the
>>>emi-torque-utils where I submitted from.
>>>
>>> What error message are you actually seeing - it could be down to the
>>>different authentication keys in the different builds of torque?
>>>
>>
>>
>> --
>> Steve Jones [log in to unmask]
>> System Administrator office: 220
>> High Energy Physics Division tel (int): 42334
>> Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334
>> University of Liverpool
>>http://www.liv.ac.uk/physics/hep/
|