Indeed in which
ssh to your job - is "Bonus 3. Cool stuff"

not the whole reason for atlas interest in glexec - its not even Bonus 1 (!)
The main reason is in "Motivation":
Glexec usage handled by Condor
● NIKHEF white-hats 'hacked' user jobs
● only id switching on WN prevents this


wahid

On 27 Mar 2012, at 15:45, Alastair Dewhurst wrote:

> Hi
>
> I have attached Rod's presentation from software week on the topic.
>
> Alastair
>
>
>

> <GlideinWMS_APF_13.2.12.pdf>

>
>
>
> On 27 Mar 2012, at 15:36, Ewan MacMahon wrote:
>
>>> -----Original Message-----
>>> From: Testbed Support for GridPP member institutes [mailto:TB-
>>> [log in to unmask]] On Behalf Of Sam Skipsey
>>>
>>>
>>>     Um. You can't just say something like that and leave it
>>>     hanging; we're going to need some details, especially bearing
>>>     in mind that there in no requirement for individual worker
>>>     nodes to allow incoming connections, and many don't.
>>>
>>> And, indeed, this specifically breaks (for example) almost all the NATted
>>> solutions which a lot of grid sites use for their worker nodes. Which they
>>> use because, as Ewan notes, there is absolutely no requirement for a
>>> worker node to allow incoming connections (and allowing such makes
>>> security on them harder).
>>>
>> What they could do is have every job VPN back to an ATLAS server
>> where it could be allocated a private internal (to ATLAS) IP
>> address (possibly calculated from it's panda job ID) which would
>> then accept incoming connections. If this is going to be 'command
>> and control' it doesn't need to be high bandwidth.
>>
>> Ewan
>

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.