It still gives direct access to the WNs to snoop around.
cheers
alessandra
On 27/03/2012 15:40, Stuart Wakefield wrote:
> fyi, its not actually ssh it just looks similar, the job checks back
> with the server regularly for a connection request. There is no
> inbound connection its all out of the site. I believe either the site
> or the vo can disable the access though i dont know the details.
>
> On Tue, Mar 27, 2012 at 3:36 PM, Ewan MacMahon
> <[log in to unmask]> 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
>>
|