At every site there should be:
This is sourced at the beginning of every ATLAS job and is the file editable by atlassgm.
Site configurations are currently stored in Tiersofatlas.py. On one of the many atlas VO boxes at CERN a cron runs over Tiersofatlas and will submit an atlassgm job to update the site configuration should anything change. Tiersofatlas is being migrated to AGIS (ATLAS Grid Information System).
If sites wish to make a specific override you can create a file called:
this will override any settings and will not be changed by atlassgm jobs.
Conditions data access is determined by:
if you are using the new CVMFS mount point you can try changing it to:
You should then start using the conditions via CVMFS and not need to worry about DBrelease, PFC, hotdisks etc anymore! (Add the override to setup.sh.local)
It is unfortunately the case that this local/setup.sh file is still needed however it is well known that this is not an ideal setup and I am sure Alessandro de Salvo will be able to spend some time developing a better method once he no longer has to maintain the current mess of an installation procedure. Also given that in general this local setup.sh file is very rarely changed, it could be possible as a relatively short term solution for sites to put the file on the WNs and then if an edit is required we request the change via say a GGUS ticket.
Hope this helps, thanks for the responses so far.
On 5 Aug 2011, at 13:32, Ewan MacMahon wrote:
>> -----Original Message-----
>> From: Testbed Support for GridPP member institutes [mailto:TB-
>> [log in to unmask]] On Behalf Of Sam Skipsey
>> On 4 August 2011 22:42, Ewan MacMahon <[log in to unmask]>
>>> Can I just clarify what the intended configuration is? It would appear
>>> from some of the responses that the /opt stuff has gone away, but
>>> there's still a need for an ATLAS_LOCAL_AREA variable and space; is
>>> - still the case now?
>>> - expected to remain the case?
>>> And if so, what is it for?
>> As Alessandra says, it's basically a place that contains your
>> setup.sh.local file for local ATLAS configuration. (Use of the CVMFS copy
>> of the conditions database is presently configured there, but the rest is
>> non-CVMFS local configuration you might have set up. So, if you were using
>> pcache, you'd have configured the alias for the pcache transfer script
>> here.) I can't see a way to avoid having to use this, since CVMFS is a
>> read-only filesystem on the client end, and I don't see ATLAS wanting to
>> move away from site-local configuration options.
> If it's just that one file could I just pop it on the WNs
> with cfengine, or does it have to be editable by atlassgm,
> in which case I'll make some NFS space for it?
> Also, what does it have to have in it to make the jobs look
> at CVMFS for the conditions database?