In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
Brief notes from CCRC08 Storage Solutions Working Group of 25 Feb 2008
Agenda with attached material at :
Present: J.Shiers (chair), H.Renshall (notes), B.Koblitz, J-P.Baud,
M.Branco, A.Pace, S.Campana, T.Cass
Phone: P.Fuhrmann, G.Oleynik, T.Perelmutov, B.Bockelman, P.Charpentier,
S. De Witt, J.Gordon, F.Donno
Discussion of SRM v2.2 key methods and behaviour:
J.Shiers said that so far ATLAS, LHCb and CMS have uploaded (to the agenda)
their prioritisations of the list of SRM v2.2 issues though the CMS one
is not yet the official position of the experiment. These three are in
agreement on the top two issues though not in the same order namely:
protecting spaces from misuse combined with implementations being fully
handling space tokens for 'more than write' (i.e. PrepareToGet/
JS asked what was currently lacking in voms awareness. BK replied that
writing into CASTOR at CERN does not take the voms group into account.
SdW added that CASTOR still uses the gridmap file. JG asked if dcache
was fully voms aware and JS thought this was a long way off. JS suggested
we should be looking to test the two top priority extensions to SRM 2
during the next annual readiness test before the years LHC data taking -
i.e. CCRC'09. GO said that, in considering priorities, they have not yet
implemented 'change space for files' and was this still needed ? PC said
that we cannot have protection from misuse without voms awareness. JG
gave his definition of the meaning of voms awareness as being access
control based on voms groups and roles.
PF said that they (for dcache) are sufficiently voms aware to support
ACLs on space tokens. SdW said the same for CASTOR proposing to add an
srm attribute to the space tables but adding that gridftp continues to
use the gridmap file. PC said we are asking for protection in the SRM
interfaces which sounds to be fairly easy in CASTOR. SdW promised he would
quantify the effort and give a rough timescale. For dcache PF said a bit
of code was missing and estimated a month or two but that this would
conflict with work on handling space tokens for 'more than write'.
JS asked (again) if both priorities could be done in all mass storage
systems by this time next year, reminding that for the May run of CCRC'08
we are really only considering workarounds rather than permanent
solutions. PC asked if in that case can we expect all the current
'annoyances' in Flavia's SRM 2 problems lists to be fixed for the May
run. FD said that two of them, selecting tape sets and the dcache 'file
exists' problem are done. PC added that he meant issues like the
non-return of space to a token after file deletes recently seen in dcache
at IN2P3. FD said this applied to T1D0 space and PF thought this should
be working both after a file delete (with a minute or two of delay) and
a migration to tape and wondered if IN2P3 was downlevel in dcache. FD
thought they were and in addition promised to come up with a list of
remaining 'annoyances' for the next meeting.
JS summarised that the planning is to fix all known problems by May
leaving the misuse protection/voms awareness and tokens on recall till
later adding that we will need to precise what we mean by voms awareness
and this may lead to another M0U extension. PF preferred to call the
misuse protection 'space token protection' while TP wanted 'voms aware
control of an ACL on a space token'. PF then remarked he understood the
LHCb statement on misuse protection but not that of ATLAS (both are
attached to the agenda). MB reminded that he had sent around by email
a clarification from ATLAS last week which HR pointed out he had attached
at the end of last meetings minutes attached to this agenda. SdW reminded
that changing storage class implies space token changes and asked if the
need for ACLs is only on writing. PC said it was but that this included
the operation of bringOnline into a T0D1 space.
JS finally summarised that access control and bringOnline space tokens
were the remaining priority issues. He proposed that the next CCRC'08
face to face meeting on the 4 March would go through all CCRC'08 issues
and look ahead to these two remaining priority issues with further
follow up and planning to be made at the April face to face meeting
and later WLCG collaboration workshop.
Preparation for WLCG Collaboration Workshop (21 - 25 April at CERN)20m
Urgent issues to discuss:
1. Behaviour of srmPrepareToPut when overwrite flag is specified and a second srmPrepareToPut request is issued. The proposal is to abort the first request (ongoing transfers continue) invalidating the corrispondent TURL and honor the second request. This will solve the "File exist" problem experienced now through the FTS.
2. Performance of bulk deletion through SRM
3. Staging requests not completing or honored in default pool
4. Changing spaces for files T1D1 -> T1D0 difficult for dCache sites ? Request coming from CMS. Is this an issue we need to reconsider ?