[Go-essp-tech] DRS hierarchy on disk

[Dean N. Williams]

Hi Phil,

	If I understand your question, it would seem that we would want to  
run the server in a chroot environment. Googling for "chroot gridftp"  
leads to some good examples:

http://*www.*bestgrid.org/index.php/ 
Setup_NGPortal_at_University_of_Canterbury 
#Configuring_chrooted_GridFTP_server

  	It seems possible that the newest versions of GridFTP include  
explicit support for chroot. The ESG-CET team just worked with the  
Gridftp developer team (Mike, Raj, John, etc.) on a recent project --  
I will post this question to them for the full story.

Best regards,
	Dean

On Nov 20, 2009, at 7:43 AM, Dean N. Williams wrote:

> Hi Phil,
>
> 	This is a good question. Perhaps Rachana or Frank can look into  
> this and return a proper answer. My first thought is no, but I am  
> not an expert on GridFTP.
>
> Best regards,
> 	Dean
>
> On Nov 20, 2009, at 2:28 AM, <philip.kershaw at stfc.ac.uk> wrote:
>
>> This is a problem for something like GridFTP where you 'see' the  
>> file system on the server not the DRS hierarchy.  It's a headache  
>> for applying security policy as presumably this is based on the DRS  
>> structure.  Some kind of mapping would need to be maintained.
>>
>> Is there a way of altering the GridFTP server side interface so  
>> that it could see a virtual file system structure based on the DRS?
>>
>> Cheers,
>> Phil
>> -----Original Message-----
>> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-bounces at ucar.edu 
>> ] On Behalf Of Dean N. Williams
>> Sent: 19 November 2009 12:14
>> To: Lawrence, Bryan (STFC,RAL,SSTD)
>> Cc: go-essp-tech at ucar.edu
>> Subject: Re: [Go-essp-tech] DRS hierarchy on disk
>>
>> This is a correct statement.
>>
>> -Dean
>>
>> On Nov 19, 2009, at 4:04 AM, <bryan.lawrence at stfc.ac.uk> wrote:
>>
>>> Hi Stephen
>>> Bob or someone else can confirm, but  I think the issue is that  
>>> ESG in general is aiming at supporting more than just the DRS, so  
>>> while conforming to DRS is a given for CMIP5, it’s not a given for  
>>> all the datasets that ESG may work with.
>>> Bryan
>>> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-bounces at ucar.edu 
>>> ] On Behalf Of stephen.pascoe at stfc.ac.uk
>>> Sent: 19 November 2009 11:49
>>> To: drach at llnl.gov
>>> Cc: go-essp-tech at ucar.edu
>>> Subject: [Go-essp-tech] DRS hierarchy on disk
>>> At the telco this Tuesday I was slightly surprised when someone (I  
>>> think Bob) asserted data is not likely to follow the DRS hierarchy  
>>> on disk.  Although we know the disk layout can be mapped to DRS  
>>> URLs in the web server I thought our default position was that we  
>>> would lay out the data in the DRS hierarchy because it is the  
>>> simplest solution.
>>> This issue came up in a meeting with UKMO yesterday where they  
>>> thought there was a strong reason for using the DRS on disk so  
>>> that fallback positions like ftp follow a consistent structure.  I  
>>> also learnt that CMOR2 will output to the DRS hierarchy  
>>> automatically.
>>> Given this, why wouldn't we want to insist all datasets are stored  
>>> on disk in the DRS hierarchy?
>>> Thanks,
>>> Stephen.
>>> ---
>>> Stephen Pascoe  +44 (0)1235 445980
>>> British Atmospheric Data Centre
>>> Rutherford Appleton Laboratory
>>> -- 
>>> Scanned by iCritical.
>>>
>>>
>>> -- 
>>> Scanned by iCritical.
>>>
>>>
>>> _______________________________________________
>>> GO-ESSP-TECH mailing list
>>> GO-ESSP-TECH at ucar.edu
>>> http://**mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>
>>
>> -- 
>> Scanned by iCritical.
>>
>>
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu
>> http://*mailman.ucar.edu/mailman/listinfo/go-essp-tech
>
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://*mailman.ucar.edu/mailman/listinfo/go-essp-tech

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20091120/3f54c680/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2919 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20091120/3f54c680/attachment.bin