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:
28-R-15 (CERN conferencing service (joining details below))
CERN conferencing service (joining details below)
email@example.com Weekly OSG, EGEE, WLCG infrastructure coordination meeting.
We discuss the weekly running of the production grid infrastructure based on weekly reports from the attendees. The reported issues are discussed, assigned to the relevant teams, followed up and escalated when needed. The meeting is also the forum for the sites to get a summary of the weekly WLCG activities and plans
OSG operations team
EGEE operations team
EGEE ROC managers
WLCG coordination representatives
WLCG Tier-1 representatives
other site representatives (optional)
To dial in to the conference:
a. Dial +41227676000
b. Enter access code 0148141
OR click HERE (Please specify your name & affiliation in the web-interface)
last week we handled some ticket expired and old alarms as usual.
there is just a site (UKI-LT2-UCL-CENTRAL) that is in downtime since June and has a ticket opened since May 22nd.
I've suggested the ROC_UKI to change the site status in "uncertified" in order to stop the raising of the alarms, until the site will be ready to come back in production. At least fo now, ROC_UKI has just changed the expiration date of the ticket to Aug 18th (the end of the downtime of gw-4.ccc.ucl.ac.uk). The downtime of the other host will end on July 30th.
gLite3.2.0-PPS-UPDATE04 is available for pre-production from this morning. It contains new releases for BDII, LFC mysql and DPM mysql in SL5. It also contains new versions of yaim core and yaim cliernts.
Release of UPDATE 50 to gLite 3.1: gLite-WN. New version of grid-cm-* packages to remove /opt/glite/lib/python/logging. This is to address GGUS ticket 50148, only happening in glite-WN version 3.1.31-0. In fact this private logging version was only ever required on SL3 and can cause problems for people using private python 2.5 versions with the supplied 2.3 versions.
Release of UPDATE 51 to gLite 3.1, including new release of yaim clients, new version of DPM, new version of LFC, new version of yaim LFC
<big> EGEE issues coming from ROC reports </big>
ROC UKI: Published to LCG-ROLLOUT but worth mentioning here for those who missed it:
Eventually RAL Tier-1 found that the cause of the wmproxy issue they had (not finding the VOMS attributes) was that the mod_gridsite part of the WMS wmproxy service does not recognise new format VOMS credentials . The new style VOMS credentials are created when using the --newformat switch on the VOMS server voms_install_db command see https://edms.cern.ch/file/973684/1/voms-guide.pdf (page 19). Details of the differences between old and new formats can be found here:
The new /correct VOMS credentials are not that new , the above bug reports are from 2005, but it looks like many (presumably all other?) VOMS servers are still issuing the incorrect/old format.
There is now a bug report about the wmproxy/mod_gridsite problem we found here https://savannah.cern.ch/bugs/?53314 . We can t move forward much with our plans for the WMS until we ve found a fix for this problem, but at least we know the cause.