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:
Minutes of this meeting and of the previous meeting5m
Brief notes from SRM Production Deployment meeting of Jan 28 2008
Present: J.Shiers (chair), H.Renshall (notes), F.Donno, J-P.Baud
Phone: P.Fuhrmann, T.Cass, G.Oleynik, J.Gordon
Minutes of Previous meeting: No comments
CCRC08 Site and Service issues: The two Twiki links were attached
to the agenda:
JS thought the second srm2 point in the service issues,
choosing the correct pool for a BringOnline from dcache,
was the hottest topic as it affects reprocessing from tape.
He also thought that if we reach needing this functionality in February
we will have gone a long way already. PF said that on this issue dcache
will possibly find a solution and that he had already shown some ideas at
a recent meeting. He would come to CERN for next weeks face-to-face ccrc08
meeting if discussions on srm2 deployment could also be held. These
could be in any framework and if in this slot Gene could hopefully join.
He would also like special meetings with LHCb and ATLAS. JS remarked
that at the face-to-face meeting he wanted to know what each storage
system is proposing for future updates. (It was later agreed that Flavia
would organise an ad-hoc meeting with technical and experiment
representatives to discuss the remaining srm2 issues and this is now
scheduled for 3.30 on Monday 4 February).
On future meetings JS thought that during February we should keep this
slot to review storage management issues that have come up in the week.
This could complement the daily 3pm checkpoint meeting and the weekly
EGEE Operations meeting. He would expect a broader participation such as
having a technical and operations person per experiment. There will then
be another face-to-face meeting in April. JG expressed a worry that that
failures seen in February would be assumed to be fixed for May.
FD asked if there will be another dcache release. PF said patch level 3
should be out tomorrow. It fixes a space miscalculation across dcache
upgrades and it is strongly recommended that sites go to this level.
FD then pointed out that ATLAS will be doing weekly bulk operations
on their files and wondered what was the backend support. PF said they
were trying to speed this up in dcache without changing the code. He will
be able to report on this in a few weeks. TC agreed to follow up for
Castor offline to this meeting.
Next week, 5 Feb, will be the ccrc08 face to face meeting in the pre-GDB
slot. The date and coverage of future conf calls in this series is yet
to be decided.
Brief notes from SRM Production Deployment meeting of Jan 21 2008
Present: J.Shiers (chair), H.Renshall (notes)
Phone: P.Fuhrmann, T.Cass
Minutes of Previous meeting: No comments
Status of Site Upgrades:
JDS believes all sites have upgraded to srm2 but has had no confirmation
from Triumf. PF announced that dcache.org is now recommending the -12
release level and that IN2P3, PIC and BNL will be installing it this week.
Status of client tools:
JDS announced that gfal and lcg-utils have been released to production
today but that another problem has been found with gfal. GD group is
trying to fast-track a fix.
Location of installation Kits for Sites:
JDS said that dpm should be taken from the standard gLite distribution.
For dcache PF said Tier1 sites should get it from dcache.org. In general
the Tier2 should get dcache from the gLite repository at CERN where it
has been fully validated but for CCRC'08 they should take the -12 version
from dcache.org (some already have). For May he hoped to get back to the
JDS asked if we need to continue this series since deployment of SRM2 is
complete and configuration/usage issues are being followed in a new daily
and weekly CCRC'08 meeting. During the February run the weekly CCRC'08
Monday meeting will become part of the weekly EGEE operations meeting.
HR thought this would not be appropriate for detailed Castor and dcache
issues and PF agreed for dcache adding that he had nothing dramatic to look
into at the moment. JDS thought there would be once CCRC'08 started.
JDS will circulate some ideas to the mailing list of this meeting.
The date of the next conf call will depend on events.