https://wiki.egi.eu/w/api.php?action=feedcontributions&user=Brucelli&feedformat=atomEGIWiki - User contributions [en]2024-03-29T05:51:06ZUser contributionsMediaWiki 1.37.1https://wiki.egi.eu/w/index.php?title=Software_Provisioning_Process&diff=99615Software Provisioning Process2018-06-26T14:11:03Z<p>Brucelli: /* The software provisioning process, step by step */</p>
<hr />
<div>{{Tech menubar}} {{SWProv menubar}} <br />
<br />
{{TOC_right}} <br />
<br />
EGI's UMD Provisioning activity governs and executes two main processes: <br />
<br />
#'''Software Provisioning Process:''' That handles software delivery from software development teams, aka Technology Providers (TP), Quality Assurance and Reporting. <br />
#'''UMD Release Process''': That collects tested Products per Platform and Architecture (PPAs) into UMD Releases<br />
<br />
<br> The following picture depicts the processes as described: <br />
<br />
[[Image:Provisioning workflow.png]] <br />
<br />
= Software Provisioning process =<br />
<br />
The Software Provisioning process consists of <br />
<br />
#'''Software Delivery''' – Technology Providers submit new software releases<br> <br />
#'''Software Assessment''' – through Quality Assurance &amp; Staged Rollout <br />
#'''Reporting '''– inform TP about outcome of the software provisioning process<br />
<br />
== Software Delivery ==<br />
<br />
'''Software Delivery''' this is the process according to which Technology Providers submit through GGUS new software releases. Software delivery is performed using one of the three different user interfaces available, i.e. a web form, e-mailing and a web service interface, that create tickets including all the necessary information about the software delivered in order to be processed. GGUS forwards the tickets to RT creating one RT ticket per Product per Platform and Architecture (PPA).<br> <br />
<br />
<br> <br />
<br />
#After the first successful release, TP should request the subscription to the UMD Release team <br />
#Communication Channels of new updates: <br />
#*E-mail to URT team <br />
#*Update the information on the URT meeting agendas <br />
#Information needed for each update: <br />
#*Product Name &amp; Version <br />
#*Release Notes as:<br> <br />
#**What’s New – bug fixes, new features <br />
#**Installation &amp; Configuration instructions – what needs to be done to correctly update the product (package, service) on production infrastructure <br />
#**List of Packages to be updated <br />
#**Location where the packages are available:<br> <br />
#***TP repositories<br> <br />
#***APP DB <br><br />
<br />
== Software Assessment ==<br />
<br />
'''Software Assessment''' is done in two phases <br />
<br />
#Quality Assurance <br />
#Stage Rollout<br />
<br />
<br> <br />
<br />
<br> <br />
<br />
[[Image:SW-Assesment.png|800px|SW-Assesment.png]] <br />
<br />
== Reporting ==<br />
<br />
'''Reporting''' this is the last process that reports back to Technology providers the outcome of the software provisioning process. <br />
<br />
<br> <br />
<br />
[[Image:SW-Reporting.png|800px|SW-Reporting.png]] <br />
<br />
<br> [[Image:UMD Software Provisioning Process summary.pdf]]<br />
<br />
= The software provisioning process, step by step =<br />
<br />
# The product team submits a ggus ticket for the "EGI Software provisioning support" support unit with the following information<br />
#* Product release and version number<br />
#* Link to the release notes<br />
#* Full list of packages that compose the release, and that need to be released in UMD<br />
# The product release is injected in the EGI SW provisioning infrastructure<br />
#* One or more RT tickets are created to track the progresses of the UMD software provisioning of the new product release<br />
#* The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and close as 'solved' the GGUS ticket<br />
#* The status of the product release will be tracked in RT<br />
#* This action must be closed in '''5 working days''' by the UMD team<br />
# The RT ticket is in "Unverified" status<br />
#* This is the "waiting line" for the verification process<br />
#* RT cannot stay longer than '''one month''' in the "Unverified" status<br />
#* After a month if the verification has not started the RT ticket will be updated with an explanation for the delay and the status will be changed to "Delayed"<br />
#* Product team (using the contact in the Product ID card) will be informed of the delay, with the reasons that caused the delay<br />
#* Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely. <br />
# The RT ticket is in "Verification" status<br />
#* This means that the UMD team is verifying the product in the testbed.<br />
#* An RT ticket cannot stay longer than '''one week''' in verification<br />
#* After one week, if it has not been verified it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.<br />
# Product is in "Staged Rollout" Status<br />
#* The product is announced to the early adopters testing in staged rollout the product.<br />
#* #* RT cannot stay longer than '''one month''' in the "Staged Rollout" status<br />
#* After one month, if it has not been tested in staged rollout it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.<br />
# After the staged rollout product is ready to be included in the next UMD release<br />
#* The overall process should not take longer than *two months*, without the PT be informed of any delays</div>Brucellihttps://wiki.egi.eu/w/index.php?title=EGI_Infrastructure_operations_oversight&diff=99217EGI Infrastructure operations oversight2018-05-14T10:37:55Z<p>Brucelli: e-grant is decommissioned ?</p>
<hr />
<div>{{Template:Op menubar}} {{Template:GO menubar}} <br />
<br />
<br />
'''EGI Infrastructure operations oversight''' activity is provided by:<br />
<br />
*EGI Foundation Operations team<br />
*Regional Operators on Duty (ROD) teams<br />
<br />
Oversight activity over the NGI infrastructures is needed for detecting problems, coordinating the diagnosis, and monitoring the problems during the entire lifecycle until resolution. Oversight of the NGI is based on monitoring of status of services operated by sites, opening of tickets and their follow up for problem resolution. EGI.org supports and actively controls the overall status of services and sites, opening of tickets for requesting problem fixing, and tackling of residual problems not successfully distributed to NGI’s. <br />
<br />
<br> <br />
<br />
'''EGI.eu Operations '''team is the central team responsible for EGI Production Infrastructure. It is also responsible to provide:<br />
<br />
# Coordination of activities with the Operations Management Board and the User Community Board. <br />
# Central Technical Support to site administrators, NGI operators and new user communities. This includes <br />
#* technical support to the EGI Foundation operations activities <br />
#* technical support to ROD teams through target training activities <br />
#* coordination of technical working groups <br />
#* technical support to new resource centres in their certification phase when requested by the Operations Centre because of lack of sufficient local expertise <br />
#* certification and technical support for new infrastructures being integrated by providing assistance and training about EGI operations services, policies and procedures, and developing documentation as needed <br />
# Resource Allocation<br />
#* defining service management processes for resource allocation and other EGI.eu operations services<br />
#* training, communicating, adapting, enforcing these at an NGI level <br />
#* defining requirements for the operations tools that generate from the provisioning of these new services <br />
<s>#* managing resource allocation process (eg. operating e-grant tool)</s><br />
<br> <br />
<br />
'''EGI Foundation Operator on Duty (OD)''' is a person in the central EGI Foundation Operations team primarily responsible for responding to tickets. This duty is rotated among the team using a [https://calendar.google.com/calendar?cid=ZWdpLmV1X2tkOWdhdGNyZnVhMjNhdjZqOTVqaGJsa2FrQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 rota] and ensures that everyone in the team is given hands-on experience dealing with tickets and coordinating operations activities. OD duties include:<br />
<br />
* ensuring a timely response to emails sent to: operations@egi.eu<br />
* verifying the status of GGUS tickets that are marked as URGENT or have not been attended to in a timely manner. Useful filters are: [http://go.egi.eu/ggus_operations tickets opened against Operations SU] and [http://go.egi.eu/ggus_egi_toppriority open top priority tickets in the EGI scope] and also [http://go.egi.eu/ggus_egi_veryurgent open very urgent tickets in the EGI scope].<br />
** Note that the target initial response times for these are 1 day; for lower priorities it is 5 days. <br />
** Note that to be able to edit tickets, you need "GGUS supporter" role. See [https://ggus.eu/?mode=register_info GGUS registration]<br />
* check the ROD Dashboard on the [https://operations-portal.egi.eu/rodDashboard/ngi/any/tab/list/filter/operators/page/list Operations Portal] especially for long-standing critical alarms, and checking with NGIs of their status as necessary<br />
* check for new tickets in the [https://rt.egi.eu/ RT] Change Management queue, especially changes that need the CAB to be convened urgently, and if so, inform the CHM Manager<br />
<br> <br />
<br />
'''Regional Operators on Duty (ROD) '''is a team responsible for solving problems on the infrastructure within NGI according to agreed procedures. They ensure that problems are properly recorded and progress according to specified time lines. They ensure that necessary information is available to all parties. The team is provided by each NGI and requires procedural knowledge on the process (rather than technical skills) for their work. Depending on how an NGI is organized there might be a number of members in the ROD team who work on duty roster (shifts on a daily or weekly basis), or there may be one person working as ROD on a daily basis and a few deputies who take over the responsibilities when necessary. This latter model is generally more suitable for small NGIs. <br />
<br />
[[Category:Infrastructure_Oversight|*]]</div>Brucellihttps://wiki.egi.eu/w/index.php?title=EGI_Infrastructure_operations_oversight&diff=99212EGI Infrastructure operations oversight2018-05-14T08:39:24Z<p>Brucelli: Add a sub-bullet about registering for supporter on GGUS</p>
<hr />
<div>{{Template:Op menubar}} {{Template:GO menubar}} <br />
<br />
<br />
'''EGI Infrastructure operations oversight''' activity is provided by:<br />
<br />
*EGI Foundation Operations team<br />
*Regional Operators on Duty (ROD) teams<br />
<br />
Oversight activity over the NGI infrastructures is needed for detecting problems, coordinating the diagnosis, and monitoring the problems during the entire lifecycle until resolution. Oversight of the NGI is based on monitoring of status of services operated by sites, opening of tickets and their follow up for problem resolution. EGI.org supports and actively controls the overall status of services and sites, opening of tickets for requesting problem fixing, and tackling of residual problems not successfully distributed to NGI’s. <br />
<br />
<br> <br />
<br />
'''EGI.eu Operations '''team is the central team responsible for EGI Production Infrastructure. It is also responsible to provide:<br />
<br />
# Coordination of activities with the Operations Management Board and the User Community Board. <br />
# Central Technical Support to site administrators, NGI operators and new user communities. This includes <br />
#* technical support to the EGI Foundation operations activities <br />
#* technical support to ROD teams through target training activities <br />
#* coordination of technical working groups <br />
#* technical support to new resource centres in their certification phase when requested by the Operations Centre because of lack of sufficient local expertise <br />
#* certification and technical support for new infrastructures being integrated by providing assistance and training about EGI operations services, policies and procedures, and developing documentation as needed <br />
# Resource Allocation<br />
#* defining service management processes for resource allocation and other EGI.eu operations services<br />
#* training, communicating, adapting, enforcing these at an NGI level <br />
#* defining requirements for the operations tools that generate from the provisioning of these new services <br />
#* managing resource allocation process (eg. operating e-grant tool)<br />
<br> <br />
<br />
'''EGI Foundation Operator on Duty (OD)''' is a person in the central EGI Foundation Operations team primarily responsible for responding to tickets. This duty is rotated among the team using a [https://calendar.google.com/calendar?cid=ZWdpLmV1X2tkOWdhdGNyZnVhMjNhdjZqOTVqaGJsa2FrQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 rota] and ensures that everyone in the team is given hands-on experience dealing with tickets and coordinating operations activities. OD duties include:<br />
<br />
* ensuring a timely response to emails sent to: operations@egi.eu<br />
* verifying the status of GGUS tickets that are marked as URGENT or have not been attended to in a timely manner. Useful filters are: [http://go.egi.eu/ggus_operations tickets opened against Operations SU] and [http://go.egi.eu/ggus_egi_toppriority open top priority tickets in the EGI scope] and also [http://go.egi.eu/ggus_egi_veryurgent open very urgent tickets in the EGI scope].<br />
** Note that the target initial response times for these are 1 day; for lower priorities it is 5 days. <br />
** Note that to be able to edit tickets, you need "GGUS supporter" role. See [https://ggus.eu/?mode=register_info GGUS registration]<br />
* check the ROD Dashboard on the [https://operations-portal.egi.eu/rodDashboard/ngi/any/tab/list/filter/operators/page/list Operations Portal] especially for long-standing critical alarms, and checking with NGIs of their status as necessary<br />
* check for new tickets in the [https://rt.egi.eu/ RT] Change Management queue, especially changes that need the CAB to be convened urgently, and if so, inform the CHM Manager<br />
<br> <br />
<br />
'''Regional Operators on Duty (ROD) '''is a team responsible for solving problems on the infrastructure within NGI according to agreed procedures. They ensure that problems are properly recorded and progress according to specified time lines. They ensure that necessary information is available to all parties. The team is provided by each NGI and requires procedural knowledge on the process (rather than technical skills) for their work. Depending on how an NGI is organized there might be a number of members in the ROD team who work on duty roster (shifts on a daily or weekly basis), or there may be one person working as ROD on a daily basis and a few deputies who take over the responsibilities when necessary. This latter model is generally more suitable for small NGIs. <br />
<br />
[[Category:Infrastructure_Oversight|*]]</div>Brucellihttps://wiki.egi.eu/w/index.php?title=Middleware_Requirements&diff=99145Middleware Requirements2018-05-07T04:25:57Z<p>Brucelli: fixed a typo in workdir</p>
<hr />
<div>{{Template:Tech menubar}}<br />
[[Category:Technology]]<br />
{{Template:Middleware_menubar}}<br />
{{TOC_right}}<br />
<br />
{{Template:Under_construction}}<br />
== Existing requirements ==<br />
<br />
=== OMB Statement of Requirements ===<br />
Overview of [[OMB_Requirements| OMB approved requirements]] (static page)<br />
<br />
=== Requirements dashboards ===<br />
The following table provides access to ''all'' open EGI requirements (UMD requirements and tool requirements), submitted by the User Community and the Operations Community.<br />
<br />
<br />
{|border="1"<br />
|- style="background-color:darkgray;"<br />
|'''Board'''<br />
|'''Middleware Requirements'''<br />
|'''Tool Requirements'''<br />
|'''Nagios Requirements'''<br />
|'''Comment'''<br />
|- <br />
| Technology Collaboration Board<br />
| [[Track_UMD_Requirements |Go to wiki dashboard]]<br />
| -<br />
| -<br />
| This category shows high priority tickets (subset of all tickets) that have already been forwarded to TCB<br />
|-<br />
| Operations Management Boards<br />
| [http://go.egi.eu/omb-requirements OMB Requirements] (RT tickets)<br />
| [[Track_Operations_Requirements| Tool Requirements]]<br />
| [https://rt.egi.eu/rt/Dashboards/1748/SA1%20Nagios%20requirements OMB Nagios Requirements]<br />
| This category shows ALL tickets discussed within the OMB in different technical areas.<br />
|-<br />
| User Community Board<br />
| [[Track_User_Support_Requirements| Go to wiki dashboard]]<br />
| -<br />
| -<br />
| This category shows tickets discussed within the User Community.<br />
|}<br />
<br />
== How to submit requirements ==<br />
* [[Nagios_requirements |Nagios test requirements]]<br />
* [[Submitting_a_middleware_requirement| Middleware requirements]]<br />
<br />
== More information==<br />
* [https://www.egi.eu/indico/getFile.py/access?contribId=1&resId=0&materialId=0&confId=152 EGI Operations requirements gathering process], OMB, 21 Dec 2010<br />
* [[EGI Operations Surveys]]<br />
* [[Jobs workdir and tempdir]]</div>Brucellihttps://wiki.egi.eu/w/index.php?title=AAI_guide_for_SPs&diff=98808AAI guide for SPs2018-03-23T08:39:03Z<p>Brucelli: fixed typo</p>
<hr />
<div>{{TOC_right}}<br />
<br />
= Overview =<br />
<br />
This wiki page contains information about connecting services to the [[AAI|EGI AAI Check-in service]] in order to allow user login through Check-in and to receive users' attributes.<br />
<br />
= Services eligible for integration =<br />
<br />
EGI Operations, as owner of the Check-in service, must approve every request for integration of new services with the AAI proxy. The approval (or non-approval) will be based on some pre-requisites, the relevance of the service for the EGI community and the available resources to support the integration.<br />
The pre-requisites are described in the following sections. <br />
<br />
'''EGI at any time can prevent a service provider to access the Check-in service'''<br />
<br />
== Services federated in EGI ==<br />
All the services that are operated by Resource Providers federated in EGI federation and that abide to the RC OLA, and consequently to the relevant security policies of EGI, can be SP for the EGI Check-in service. Fulfilling all the relevant EGI policies makes the service eligible in receiving attributes released by the Check-in proxy.<br />
<br />
== Services not federated in EGI ==<br />
<br />
A service not part of the EGI federation can be integrated as a SP in the Check-in AAI Proxy if the organisation providing the service complies with the EGI security requirements relevant to the service providers. <br />
<br />
'''To assert compliance, the organisation needs to fill in the [https://documents.egi.eu/document/3086 registration form for SPs]. A PDF scan of a printed and signed copy should be sent to [mailto:&#111;&#112;&#101;&#114;&#097;&#116;&#105;&#111;&#110;&#115;&#064;&#101;&#103;&#105;&#046;&#101;&#117;?Subject=EGI%20Check-in%20service%20provider%20registration%20form operations (at) egi.eu].'''<br />
<br />
By accepting the policies a service provider assures that they will operate the service in good faith, without deliberately exposing the user to security risks, without claiming intellectual property on the data owned by the user, and protecting sensitive data generated by the interaction of the user with the service.<br />
<br />
The policies that the service provider will have to accept are available in this page [https://wiki.egi.eu/wiki/Policies_and_Procedures EGI Policies and procedures page] and specifically are:<br />
# [https://documents.egi.eu/document/3015 e-Infrastructure Security Policy]<br />
# [https://documents.egi.eu/document/1475 Service Operations Security Policy]<br />
# [https://documents.egi.eu/document/81 Traceability and Logging Policy]<br />
# [https://documents.egi.eu/document/82 Security Incident Response Policy]<br />
# [https://documents.egi.eu/document/2732 Policy on the Processing of Personal Data]<br />
<br />
= Service Provider integration workflow =<br />
<br />
To integrate your Service Provider with the EGI Check-in service, you need to submit a [[GGUS]] ticket indicating your request. The responsible support unit is [[GGUS:AAI_SUPPORT_FAQ|AAI Support]]. The integration follows a two-step process:<br />
<br />
* '''Step 1.''' Register your Service Provider and test integration with the development instance of EGI Check-in. The development instance allows for testing authentication and authorisation without affecting the production Check-in service. Note that the development instance is not connected to the production service and no information is shared between the two systems. However, the development instance has identical functionality, with the exception that the list of supported Identity Providers is limited. Therefore, we recommend using the EGI SSO or any of the social identity providers to test the login workflow when using the development instance.<br />
* '''Step 2.''' Register your Service Provider with the production instance of EGI Check-in to allow members of the EGI User Community to access your service. This requires that your service meets all the [[#Services eligible for integration|eligibility criteria]] and that integration has been thoroughly tested during Step 1.<br />
<br />
The most important URLs for each environment are listed in the table below but more information can be found in the protocol-specific sections that follow.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Protocol<br />
! Development environment<br />
! Production environment<br />
|-<br />
| SAML<br />
| https://aai-dev.egi.eu/proxy/saml2/idp/metadata.php<br />
| https://aai.egi.eu/proxy/saml2/idp/metadata.php<br />
|-<br />
| OpenID Connect<br />
| https://aai-dev.egi.eu/oidc/.well-known/openid-configuration<br />
| https://aai.egi.eu/oidc/.well-known/openid-configuration<br />
|}<br />
<br />
= SAML Service Provider =<br />
<br />
To enable federated access to a web-based application, you can connect to the EGI Check-in IdP as a SAML Service Provider (SP). Users of the application will be redirected to Check-in in order to log in, and Check-in can authenticate them using any of the supported backend authentication mechanisms, such as institutional IdPs registered with eduGAIN or Social Providers. Once the user is authenticated, EGI Check-in will return a SAML assertion to the application containing information about the authenticated user.<br />
<br />
== Metadata registration ==<br />
<br />
SAML authentication relies on the use of metadata. Both parties (you as a SP and the EGI Check-in IdP) need to exchange metadata in order to know and trust each other. The metadata include information such as the location of the service endpoints that need to be invoked, as well as the certificates that will be used to sign SAML messages. The format of the exchanged metadata should be based on the XML-based [https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf SAML 2.0 specification]. Usually, you will not need to manually create such an XML document, as this is automatically generated by all major SAML 2.0 SP software solutions (e.g., Shibboleth, SimpleSAMLphp, and mod_auth_mellon). It is important that you serve your metadata over HTTPS using a browser-friendly SSL certificate, i.e. issued by a trusted certificate authority.<br />
<br />
You can get the metadata of the EGI Check-in IdP Proxy on a dedicated URL that depends on the integration environment being used:<br />
{| class="wikitable"<br />
|-<br />
! Development environment<br />
! Production environment<br />
|-<br />
| https://aai-dev.egi.eu/proxy/saml2/idp/metadata.php<br />
| https://aai.egi.eu/proxy/saml2/idp/metadata.php<br />
|}<br />
<br />
== Attributes ==<br />
<br />
The EGI Check-in IdP is guaranteed to release a minimal subset of the [https://refeds.org/category/research-and-scholarship REFEDS R&S] attribute bundle to connected Service Providers without administrative involvement, subject to user consent. The following attributes constitute a minimal subset of the R&S attribute bundle:<br />
<br />
* Persistent, non-reassignable, non-targeted, opaque, globally unique EGI user ID (<tt>eduPersonUniqueId</tt>); this is always scoped <tt>@egi.eu</tt><br />
* Email address (<tt>mail</tt>)<br />
* Display name (<tt>displayName</tt>) OR (<tt>givenName</tt> AND <tt>sn</tt>)<br />
<br />
A more extensive list of all the attributes that may be made available to Service Providers is included in the following table:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Attribute friendly name<br />
! Attribute OID<br />
! Example value<br />
|-<br />
|<tt>eduPersonUniqueId</tt><br />
|<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.13</tt><br />
|<tt>ef72285491ffe53c39b75bdcef46689f5d26ddfa00312365cc4fb5ce97e9ca87@egi.eu</tt><br />
|-<br />
|<tt>mail</tt><br />
|<tt>urn:oid:0.9.2342.19200300.100.1.3</tt><br />
|<tt>john.doe@example.org</tt><br />
|-<br />
|<tt>displayName</tt><br />
|<tt>urn:oid:2.16.840.1.113730.3.1.241</tt><br />
|<tt>John Doe</tt><br />
|-<br />
|<tt>givenName</tt><br />
|<tt>urn:oid:2.5.4.42</tt><br />
|<tt>John</tt><br />
|-<br />
|<tt>sn</tt><br />
|<tt>urn:oid:2.5.4.4</tt><br />
|<tt>Doe</tt><br />
|-<br />
|<tt>eduPersonAssurance</tt><br />
|<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.11</tt><br />
|<tt>https://aai.egi.eu/LoA#Substantial</tt><br />
|-<br />
|<tt>distinguishedName</tt><br />
|<tt>urn:oid:2.5.4.49</tt><br />
|<tt>/C=NL/O=Example.org/CN=John Doe</tt><br />
|-<br />
|<tt>eduPersonScopedAffiliation</tt><br />
|<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.9</tt><br />
|<tt>faculty@example.org</tt><br />
|-<br />
|<tt>eduPersonEntitlement</tt><br />
|<tt>urn:oid:1.3.6.1.4.1.5923.1.1.1.7</tt><br />
|<tt>urn:mace:egi.eu:group:vo.test.egi.eu:role=member#aai.egi.eu</tt> <br/> <tt>urn:mace:egi.eu:aai.egi.eu:member@vo.test.egi.eu</tt> ''(WARNING this format will be deprecated)''<br />
|}<br />
<br />
== Attribute-based authorisation ==<br />
<br />
EGI Check-in provides information about the authenticated user that may be used by Service Providers in order to control user access to resources. This information is provided by the EGI Check-in IdP in the [[#Attributes|SAML attribute assertion]]. The table below lists the SAML attributes that are relevant for user authorisation:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description<br />
! SAML Attribute<br />
|-<br />
| [[#VO membership and role information|VO/group membership/roles of the authenticated user]]<br />
| <tt>eduPersonEntitlement</tt><br />
|-<br />
| [[#Level of Assurance|Level of Assurance (LoA)]]<br />
| <tt>eduPersonAssurance</tt><br />
|}<br />
<br />
== References ==<br />
* [https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPConfiguration Shibboleth SP Configuration]<br />
* [https://simplesamlphp.org/docs/stable/simplesamlphp-sp SimpleSAMLphp Service Provider QuickStart]<br />
* [https://github.com/UNINETT/mod_auth_mellon Simple SAML 2.0 service provider with mod_auth_mellon Apache module]<br />
<br />
= OpenID Connect Service Provider =<br />
<br />
Service Providers can be integrated with EGI Check-in using OpenID Connect (OIDC) as an alternative to the SAML2 protocol. To allow this, the EGI Check-in IdP provides an OpenID Connect (OAuth2) API based on [https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server MITREid Connect], which has been [http://openid.net/certification/ certified by the OpenID Foundation]. Interconnection with the EGI Check-in OIDC Provider allows users to sign in using any of the supported backend authentication mechanisms, such as institutional IdPs registered with eduGAIN or Social Providers. Once the user has signed in, EGI Check-in can return OIDC Claims containing information about the authenticated user.<br />
<br />
== Client registration ==<br />
<br />
Before your service can use the EGI Check-in OIDC Provider for user login, you must set up a client at https://aai-dev.egi.eu/oidc/manage/#admin/clients in order to obtain OAuth 2.0 credentials and register one or more redirect URIs. <br />
<br />
=== Obtaining OAuth 2.0 credentials ===<br />
<br />
You need OAuth 2.0 credentials, including a client ID and client secret, to authenticate users through the EGI Check-in OIDC Provider.<br />
<br />
You can specify the client ID and secret when creating/editing your client or let the [https://aai-dev.egi.eu/oidc/manage/admin/client/new New Client page] generate the values for you (''recommended'').<br />
<br />
To find the ID and secret of your client, do the following:<br />
# Select your client from the [https://aai-dev.egi.eu/oidc/manage/#admin/clients Clients page].<br />
# Look for the '''Client ID''' in the '''Main''' tab. <br />
# Select the '''Display/edit client secret:''' option from the '''Credentials''' tab.<br />
<br />
=== Setting one or more Redirection URIs ===<br />
<br />
The Redirection URI(s) that you set when creating/editing your client determine where the EGI Check-in OIDC Provider sends responses to your authentication requests. Note that the Redirection URI MUST use the <code>https</code> scheme; the use of <code>http</code> Redirection URIs is only allowed in the development environment.<br />
<br />
To find the Redirection URI(s) for your client, do the following:<br />
<br />
# Open the [https://aai-dev.egi.eu/oidc/manage/#admin/clients Clients page]<br />
# Find the redirect URIs for your client listed under the '''Information''' column of the overview table or '''Edit''' the particular client and look for the '''Redirect URI(s)''' in the '''Main''' tab.<br />
<br />
=== Setting additional information about the client ===<br />
Although optional, it is strongly suggested that you add a short '''description''' and a '''logo''' for the client.<br />
<br />
== Endpoints ==<br />
<br />
The most important OIDC/OAuth2 endpoints are listed below:<br />
{| class="wikitable"<br />
|-<br />
! Endpoint<br />
! Development environment<br />
! Production environment<br />
|-<br />
| Provider configuration<br />
| https://aai-dev.egi.eu/oidc/.well-known/openid-configuration<br />
| https://aai.egi.eu/oidc/.well-known/openid-configuration<br />
|-<br />
| Client registration<br />
| https://aai-dev.egi.eu/oidc<br />
| ''Contact [mailto:egi-aai-checkin@lists.grnet.gr EGI Check-in support] for registering your client''<br />
|-<br />
| Authorisation<br />
| https://aai-dev.egi.eu/oidc/authorize<br />
| https://aai.egi.eu/oidc/authorize<br />
|-<br />
| Token<br />
| https://aai-dev.egi.eu/oidc/token<br />
| https://aai.egi.eu/oidc/token<br />
|-<br />
| User Info <br />
| https://aai-dev.egi.eu/oidc/userinfo<br />
| https://aai.egi.eu/oidc/userinfo<br />
|-<br />
| Introspection<br />
| https://aai-dev.egi.eu/oidc/introspect<br />
| https://aai.egi.eu/oidc/introspect<br />
|}<br />
<br />
== Claims ==<br />
<br />
EGI Check-in OIDC ID Tokens may contain the following fields (known as ''claims''):<br />
<br />
{| class="wikitable"<br />
|-<br />
! Name<br />
! Description<br />
! Example value<br />
|-<br />
|<tt>sub</tt><br />
| An identifier for the user, unique among all EGI accounts and never reused. Use <tt>sub</tt> within your application as the unique-identifier key for the user.<br />
|<tt>ef72285491ffe53c39b75bdcef46689f5d26ddfa00312365cc4fb5ce97e9ca87@egi.eu</tt><br />
|-<br />
|<tt>email</tt><br />
| The user's email address. This may not be unique and is not suitable for use as a primary key (in the future this will be provided only if your scope included the string <tt>"email"</tt>).<br />
|<tt>john.doe@example.org</tt><br />
|-<br />
|<tt>name</tt><br />
| The user's full name, in a displayable form (in the future this will be provided only if your scope included the string <tt>"profile"</tt>).<br />
|<tt>John Doe</tt><br />
|-<br />
|<tt>given_name</tt><br />
| The user's first name (in the future this will be provided only if your scope included the string <tt>"profile"</tt>).<br />
|<tt>John</tt><br />
|-<br />
|<tt>family_name</tt><br />
| The user's last name (in the future this will be provided only if your scope included the string <tt>"profile"</tt>).<br />
|<tt>Doe</tt><br />
|-<br />
|<tt>acr</tt><br />
| The Authentication Context Class Reference that identifies the Level of Assurance (LoA) that the authentication performed satisfied.<br />
|<tt>https://aai.egi.eu/LoA#Substantial</tt><br />
|-<br />
|<tt>edu_person_scoped_affiliations</tt> (multivalued)<br />
| The user's affiliation within a particular security domain (scope).<br />
|<tt>member@example.org</tt><br />
|-<br />
|<tt>edu_person_entitlements</tt> (multivalued)<br />
| The user's entitlements expressed as group/VO membership/role information.<br />
|<tt>urn:mace:egi.eu:group:vo.test.egi.eu:role=member#aai.egi.eu</tt> <br/> <tt>urn:mace:egi.eu:aai.egi.eu:member@vo.test.egi.eu</tt> ''(WARNING this format will be deprecated)''<br />
|}<br />
<br />
== Claims-based authorisation ==<br />
<br />
EGI Check-in provides information about the authenticated user that may be used by Service Providers in order to control user access to resources. This information is provided by the EGI Check-in OIDC Provider in the form of [[#Claims|OIDC claims]]. The table below lists the claims that are relevant for user authorisation:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Description<br />
! OIDC Claim<br />
|-<br />
| [[#VO membership and role information|VO/group membership/roles of the authenticated user]]<br />
| <tt>edu_person_entitlements</tt><br />
|-<br />
| [[#Level of Assurance|Level of Assurance (LoA)]]<br />
| <tt>acr</tt><br />
|}<br />
<br />
== Example OIDC Client ==<br />
In this guide we will demonstrate how to install and configure a [https://github.com/rciam/simple-oidc-client simple OIDC client].<br />
<br />
=== Install simple-oidc-client ===<br />
This guide assumes the Apache HTTP server has been installed and the document root is <code>/var/www/html</code><br />
<br />
Move to the apache document root and download and extract [https://github.com/rciam/simple-oidc-client/releases/download/v1.0.0/simple-oidc-client.zip simple-oidc-client.zip].<br />
<br />
=== Configure Client ===<br />
Go to this link and login https://aai-dev.egi.eu/oidc/<br />
<br />
Then create a new client or edit your existing client.<br />
In <code>main</code> tab enter a <code>Client name</code> and in the <code>Redirect URI(s)</code> insert your simple-oidc-client URL (e.g. https://example.com/simple-oidc-client/popup.html). This URL must link to popup.html which is located in simple-oidc-client directory.<br/><br />
Next, move to <code>access</code> tab and pick the <code>scopes</code> your service needs. Then, in <code>Grant types</code> check <code>authorization code</code> and <code>implicit</code>. In <code>Response Types</code> check <code>code</code> and <code>token id_token</code>.<br/><br />
Then, click save and copy your <code>Client ID</code>.<br />
<br />
=== Configure simple-oidc-client ===<br />
Now that we have everything we need, we can configure our login settings.<br />
Go to your terminal and open <code>configuration.js</code> with your favorite text editor.<br />
ex.<br />
<pre><br />
vi simple-oidc-client/configuration.js<br />
</pre><br />
<br />
Let’s go quickly through the settings:<br />
<br />
* <code>title</code> is the title on the navigation bar.<br />
* <code>authority</code> is the base URL of our IdentityServer instance. This will allow oidc-client to query the metadata endpoint so it can validate the tokens.<br />
* <code>client_id</code> is the id of the client we want to use when hitting the authorization endpoint.<br />
* <code>popup_redirect_uri</code> is the redirect URL used when using the signinPopup method. If you prefer not having a popup and redirecting the user in the main window, you can use the redirect_uri property and the signinRedirect method.<br />
* <code>post_logout_redirect_uri</code> is the redirect URL used when using the signoutRedirect method.<br />
* <code>response_type</code> defines in our case that we only expect an identity token back.<br />
* <code>scope</code> defines the scopes the application asks for.<br />
* <code>debug</code> displays user data.<br />
* <code>filterProtocolClaims</code> indicates to oidc-client if it has to filter some OIDC protocol claims from the response: nonce, at_hash, iat, nbf, exp, aud, iss and idp.<br />
<br />
You must change the followings options based on your client configuration:<br />
* <code>authority</code> (issuer)<br />
* <code>client_id</code><br />
* <code>scope</code><br />
<br />
An example configuration follows:<br />
<pre><br />
var settings = {<br />
title: 'Simple OIDC Client',<br />
authority: 'https://aai-dev.egi.eu/oidc',<br />
client_id: 'client',<br />
popup_redirect_uri: 'https://example.com/simple-oidc-client/popup.html',<br />
post_logout_redirect_uri: 'https://example.com/simple-oidc-client/index.html',<br />
<br />
response_type: 'token id_token',<br />
scope: 'openid profile email', /* add offline_access to obtain a refresh token*/<br />
<br />
debug: false,<br />
filterProtocolClaims: false<br />
};<br />
</pre><br />
<br />
= Integrating Science Gateways with RCauth for obtaining (proxy) certificates =<br />
<br />
In order for Science Gateways (VO portals) to obtain RFC proxy certificates derived from '''personal''' end-entity certificates, an EGI Science Gateway can make use of the IGTF-approved IOTA-type RCauth.eu online CA. The actual integration goes via an intermediary service, called a Master Portal.<br />
<br />
== Registering a client at the Master Portal ==<br />
<br />
EGI is running two Master Portal instances, one development, one production instance. In order to register a new client go to:<br />
<ul><li>EGI Development instance:<br><br />
https://masterportal-pilot.aai.egi.eu/mp-oa2-server/register<br><br />
<li>EGI Production instance:<br><br />
https://aai.egi.eu/mp-oa2-server/register<br />
</ul><br />
'''''NOTE''''': Make sure to store the ''client_id'' and ''client_secret'' in a secure place.<br />
<br />
In order to get the client approved, send an email to the adminstrator of the EGI Master Portal using [mailto:egi-aai-checkin@lists.grnet.gr EGI Check-in support].<br />
<br />
=== Detailed information ===<br />
For further and detailed instructions on the integration flow, see the generic [https://wiki.nikhef.nl/grid/RCAuth.eu_MasterPortal_VOPortal_integration_guide RCAuth.eu MasterPortal VOPortal integration guide]<br />
<br />
==== SSH key authentication for proxy retrieval ====<br />
The EGI MasterPortal also allows users to authenticate using ''SSH key pair'', in order to retrieve proxy certificates from the MasterPortal. Users need to first upload the public key via a self-service portal, https://aai.egi.eu/sshkeys/. About once a week they need to follow a web-flow to ensure a long-lived proxy certificate is present in MasterPortal, e.g. by going to https://aai.egi.eu/vo-portal/. They can then obtain a proxy certificate by doing<br />
ssh proxy@ssh.aai.egi.eu<br />
and storing the output in /tmp/x509up_u$(id -u)<br />
<br />
Generic information for users on how to do this can be found at [https://wiki.nikhef.nl/grid/AARC_Pilot_-_SSH_Key_Portal Instructions for end-users on how to use the SSH key authN for proxy retrieval].<BR><br />
Alternatively VO portals could implement such functionality themselves by using the API described at the [https://wiki.nikhef.nl/grid/Master_Portal_sshkey_endpoint Master Portal sshkey endpoint description].<br />
<br />
= User authorisation =<br />
<br />
The following information about the authenticated user can be provided by EGI Check-in in order to control user access to resources:<br />
<br />
# VO/group membership and role information about the authenticated user<br />
# Level of Assurance (LoA)<br />
<br />
== VO membership and role information ==<br />
<br />
=== Background ===<br />
Different entitlements (encoded as <tt>eduPersonEntitlement</tt> attribute values in SAML or <tt>edu_person_entitlements</tt> claim in OIDC) are typically used to indicate access rights to protected resources. Entitlements are multi-valued, with each value formatted as a URN.<br />
<br />
=== Syntax ===<br />
Values for <tt>eduPersonEntitlement</tt> for use within the EGI environment adopt the following formatting specification:<br />
<pre><br />
urn:mace:egi.eu:<authority-fqdn>:[<group>[:<subgroup>:…]]:<role>@<vo><br />
</pre><br />
where:<br />
* <tt><authority-fqdn></tt> is the FQDN of the authoritative source for the entitlement value<br />
* <tt><vo></tt> is the name of the Virtual Organisation<br />
* <tt><group></tt> is the name of a group in the identified <tt><vo></tt>; specifying a group is optional<br />
* zero or more <tt><subgroup></tt> components represent the hierarchy of subgroups in the <tt><group></tt>; specifying sub-groups is optional<br />
* the <tt><role></tt> component is scoped to the rightmost (sub)group; if no group information is specified, the role applies to the VO<br />
<br />
=== Semantics ===<br />
Each <tt>eduPersonEntitlement</tt> attribute value represents a particular position of the user within a VO. A user may be member or hold more specific roles within the groups associated to a VO. Groups are organised in a tree structure, meaning that a group may have subgroups, which in turn may have subgroups, etc. <br />
<br />
This hierarchical structure implies that if someone is member of a subgroup, then they are also member of the parent group. For example:<br />
<pre><br />
parent-group:child-group:member<br />
</pre><br />
<br />
implies membership in parent-group, i.e.:<br />
<br />
<pre><br />
parent-group:member<br />
</pre><br />
<br />
Ownership of any role always implies the member role for that particular (sub)group. However, holding a more specific role (i.e. one other than member) in a subgroup does not imply the same role in the parent group. For example: <br />
<pre><br />
parent-group:child-group:manager<br />
</pre><br />
<br />
implies plain membership in both <tt>child-group</tt> and <tt>parent-group</tt>, but '''NOT''':<br />
<br />
<pre><br />
parent-group:manager<br />
</pre><br />
<br />
== Level of Assurance ==<br />
<br />
Based on the authentication method selected by the user, the EGI proxy assigns a Level of Assurance (LoA), which is conveyed to the SP through both the <tt>eduPersonAssurance</tt> attribute and the Authentication Context Class (<tt>AuthnContextClassRef</tt>) of the SAML authentication response. EGI AAI currently distinguishes between three LoA levels, similarly to the [http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOL_2015_235_R_0002 eID Assurance Framework (eIDAF)]. Each level is represented by a URI as follows:<br />
<br />
* '''Low''': Authentication through a social identity provider or other low identity assurance provider: https://aai.egi.eu/LoA#Low<br />
* '''Substantial''': Password/X.509 authentication at the user's home IdP: https://aai.egi.eu/LoA#Substantial<br />
* '''High''': Substantial + multi-factor authn (not yet supported, TBD): https://aai.egi.eu/LoA#High <br />
<br />
Some EGI SPs have been configured to provide limited access (or not to accept at all) credentials with the Low LoA. <br />
<br />
Note: When logging in through the EGI SSO IdP, the LoA is determined based on the selected authentication mechanism as follows:<br />
* Username/password credentials → Low<br />
* X.509 certification → Substantial<br />
<br />
'''Important:''' A proposal for updating and refining the existing Levels of Assurance is currently a work in progress (see [[EGI-Engage:TASK JRA1.1 Proposal for Levels of Assurance|here]])</div>Brucellihttps://wiki.egi.eu/w/index.php?title=EGI_IGTF_Release&diff=88341EGI IGTF Release2016-06-20T14:27:45Z<p>Brucelli: Changed IGTF name</p>
<hr />
<div>[[Category:Security Policy Group (SPG) ]]<br />
To ensure interoperability within and outside of EGI, the [https://documents.egi.eu/document/83 Policy on Approved Certification Authorities] defined a common set of trust anchors ("Certification Authorities" or "CAs") that all sites in EGI should install. In short, all CAs accredited to the [http://www.igtf.net/ Interoperable Global Trust Federation] under the [http://www.eugridpma.org/guidelines/classic classic], [http://www.eugridpma.org/guidelines/MICS/IGTF-AP-MICS-1.2-clean.pdf MICS] or [http://www.tagpma.org/authn_profiles/slcs SLCS] ''Authentication Profiles'' are approved for use in EGI. Of course, sites may add additional CAs as long as the integrity of the infrastructure as a whole is not compromised. Also, if there are site or national policies/regulations that prevent you from installing a CA, these regulations take precedence -- but you then must inform the EGI Security Officer (see [[EGI CSIRT:Main Page]]) about this exception. <br />
<br />
= Version 1.74 - change log and information =<br />
<br />
The change log contains important notices about the release, as well as a list of changes to the trust fabric. <br />
<br />
* Review the release notes at [http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core-readme-1.74.txt http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core-readme-1.74.txt] <br />
* 1.74 was released on '''2016-05-28''' as a '''regular''' update <br />
* 1.74 is a '''dual-hash''' (new) style release only<br />
<br />
== Important Notice for sites in EGI that support WLCG ==<br />
<br />
The WLCG collaboration - having so requested EGI and in line with long-term EGI developments in AAI - has included a specific CA to its own trust anchor distribution. Sites that are also part of WLCG should install BOTH the "egi-core" AND "lcg" meta-packages, according to your policies. Note that your organisation or NGI may also have a specific policy and may have added or removed CAs compared to the EGI core policy. Sites that need compliance with the WLCG policy should install BOTH packages, or you will miss out the CERN WLCG IOTA CA specific exception see [https://documents.egi.eu/document/2745 EGI document https://documents.egi.eu/document/2745] for details and the WLCG statement [http://lcg-ca.web.cern.ch/lcg-ca/doc/WLCG-CERN-IOTA-statement-MB.pdf http://lcg-ca.web.cern.ch/lcg-ca/doc/WLCG-CERN-IOTA-statement-MB.pdf for the WLCG specific decision].<br />
<br />
The EGI production repository contains all relevant packages for both policies (and the WLCG repository contains also all EGI packages). There is no reason to reconfigure repository locations. Specifically installing (adding) also the ca-policy-lcg package may be necessary for system configurations built after May 2009.<br />
<br />
== Reminder notice for VOMS AA operators ==<br />
<br />
Several updates to this trust anchor distribution incorporate changes to the name of the issuing authority, but the name of the end-entities and the users remains exactly the same. To make the change transparent, all operators of VOMS and VOMS-Admin services are requested to enable the subject-only name resolution mechanisms in VOMS and VOMS Admin<br />
<br />
* on the VOMS core Attribute Authority service, configure the "-skipcacheck" flag on start-up. In YAIM this is done by setting "VOMS_SKIP_CA_CHECK" to true. See https://wiki.italiangrid.it/twiki/bin/view/VOMS/VOMSYAIMGuide<br />
* update VOMS-Admin to version >= 3.3.2, and set "voms.skip_ca_check=True" in the service properties. For more info, read the release notes at http://italiangrid.github.io/voms/release-notes/voms-admin-server/3.3.2/<br />
<br />
= Installation =<br />
<br />
To install the EGI trust anchors on a system that uses the RedHat Package Manager (RPM) based package management system, we provide a convenience package to manage the installation. To install the currently valid distribution, all RPM packages are provided at <br />
<br />
http://repository.egi.eu/sw/production/cas/1/current/<br />
<br />
The current version is based on the [https://dist.eugridpma.info/distribution/igtf/current/ IGTF release] with the same version number. Install the meta-package <tt>ca-policy-egi-core</tt> and its dependencies to implement the core EGI policy on trusted CAs. <br />
<br />
== Using YUM package management ==<br />
<br />
Add the following [http://repository.egi.eu/sw/production/cas/1/current/repo-files/EGI-trustanchors.repo repo-file] to the <tt>/etc/yum.repos.d/</tt> directory: <br />
<br />
[EGI-trustanchors]<br />
name=EGI-trustanchors<br />
baseurl=http://repository.egi.eu/sw/production/cas/1/current/<br />
gpgkey=http://repository.egi.eu/sw/production/cas/1/GPG-KEY-EUGridPMA-RPM-3<br />
gpgcheck=1<br />
enabled=1<br />
<br />
and then update your installation. How to update depends on your previous activity: <br />
<br />
*'''if you have previously ever installed the <tt>lcg-CA</tt> package''', remove any references to <tt>http://linuxsoft.cern.ch/LCG-CAs/current</tt> from your YUM setup, and run<br />
<br />
yum clean cache metadata <br />
yum update lcg-CA <br />
<br />
:and you are done. This will update the packages installed to the latest version, and also install the new <tt>ca-policy-egi-core</tt> package as well as a <tt>ca-policy-lcg</tt> package. All packages encode the same set of dependencies<br />
<br />
*'''if you are upgrading from a previous EGI version only''', just run<br />
<br />
yum update ca-policy-egi-core<br />
<br />
:although at times you may need to clean the yum cache using <tt>yum clean cache metadata</tt><br />
<br />
*'''if you are installing the EGI trust anchors for the first time''', run<br />
<br />
yum install ca-policy-egi-core<br />
<br />
== Using the distribution on a Debian or Debian-derived platform ==<br />
<br />
The 1.39+ releases experimentally add the option to install the trust anchors from Debian packages using the APT dependency management system. Although care has been taken to ensure that this distribution is installable and complete, no guarantees are given, but you are invited to report your issues through GGUS. You may have to wait for a subsequent release of the Trust Anchor release to solve your issue, or may be asked to use a temporary repository. To use it: <br />
<br />
*Install the EUGridPMA PGP key for apt:<br />
<br />
wget -q -O - \<br />
https://dist.eugridpma.info/distribution/igtf/current/GPG-KEY-EUGridPMA-RPM-3 \<br />
| apt-key add -<br />
<br />
*Add the following line to your sources.list file for APT:<br />
<br />
#### EGI Trust Anchor Distribution ####<br />
deb http://repository.egi.eu/sw/production/cas/1/current egi-igtf core<br />
<br />
*Populate the cache and install the meta-package<br />
<br />
apt-get update<br />
apt-get install ca-policy-egi-core<br />
<br />
== Using the distribution on other (non-RPM) platforms ==<br />
<br />
The trust anchors are provided also as simple 'tar-balls' for installation on other platforms. Since there is no dependency management in this case, please review the release notes carefully for any security issues or withdrawn CAs. The tar files can be found in the EGI repository at <br />
<br />
http://repository.egi.eu/sw/production/cas/1/current/tgz/<br />
<br />
Once you have downloaded the directory, you can unpack all the CA tar,gz as follows to your certificate directory: <br />
<br />
for tgz in `ls <ca download dir>`; do tar xzf <ca download dir>/$tgz --strip-components=1 -C /etc/grid-security/certificates; done<br />
<br />
== Installing the distribution using Quattor ==<br />
<br />
Quattor templates are povided as drop-in replacements for both QWG and CDB installations. Update your software repository (re-generating the repository templates as needed) and obtain the new CA templates from: <br />
<br />
*[http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core.tpl http://repository.egi.eu/sw/production/cas/1/current/meta/ca-policy-egi-core.tpl] for QWG <br />
*[http://repository.egi.eu/sw/production/cas/1/current/meta/pro_software_meta_ca_policy_egi_core.tpl http://repository.egi.eu/sw/production/cas/1/current/meta/pro_software_meta_ca_policy_egi_core.tpl] for CDB<br />
<br />
Make sure to mirror (or refer to) the new repository at http://repository.egi.eu/sw/production/cas/1/current/ and create the appropriate repository definition file. <br />
<br />
For wLCG sites that are migrating from the lcg-CA package: the wLCG policy companion of the EGI templates can be found at [http://lcg-ca.web.cern.ch/lcg-ca/distribution/current/meta/ca-policy-lcg.tpl http://cern.ch/lcg-ca/distribution/current/meta/ca-policy-lcg.tpl] (QWG) and [http://lcg-ca.web.cern.ch/lcg-ca/distribution/current/meta/pro_software_meta_ca_policy_lcg.tpl http://cern.ch/lcg-ca/distribution/current/meta/pro_software_meta_ca_policy_lcg.tpl] (CDB) and can be included in the profile in parallel with the EGI core template. All packages needed are also included in the EGI repository, so only a single repository reference is necessary. <br />
<br />
= New distribution format (OpenSSL1 dual-hash mode) =<br />
<br />
The EGI release uses a new format in which to distribute the trust anchors. In OpenSSL version 1.0, as released for example in RedHat Enterprise Linux 6, Fedora Core 12+, or Debian5, the characteristic hash format ("HHHHHHHH.0") has changed. Although it superficially looks the same, each CAs gets a ''different'' hash in OpenSSL1 as compared to OpenSSL 0.x, or as compared to BouncyCastle or gLite TrustManager. Please review the [https://www.eugridpma.org/newsletter/eugridpma-newsletter-20100215.txt EUGridPMA news letter of February 15] for full technical details. <br />
<br />
To accommodate this changed hash format, the new distribution uses symbolic links for ''both hashes'', that jointly refer to the same physical file with the CA certificate, called ''alias''.pem. This ensures that the new trust anchor distribution works with both format simultaneously. You can install this distribution on all platforms (both OpenSSL1 as well as OpenSSL0.x) and both are supposed to work. <br />
<br />
However, old version of fetch-crl (the 2.x) series will retrieve CRLs for ''one version of OpenSSL only'', namely the version which is used by fetch-crl itself when it is run. To get CRLs downloaded for both versions of OpenSSL <br />
<br />
*run fetch-crl 2.x ''twice'', using a different version of OpenSSL each time. Use the <tt>FETCH_CRL_OPENSSL</tt> environment variable to specify an explicit OpenSSL version for use by fetch-crl. This is only needed if you actually use both versions of OpenSSL at the same time. <br />
*upgrade to fetch-crl 3, which has proper dual-hash support as well as many other features. Please refer to [http://www.nikhef.nl/grid/fetchcrl3/ http://www.nikhef.nl/grid/fetchcrl3/] for more information on fetch-crl3, or download it from [https://dist.eugridpma.info/distribution/util/fetch-crl3/ dist.eugridpma.info]. Fetch-crl 3 can also be obtained from your standard OS distribution repository (EPEL, Fedora, Debian).<br />
<br />
= Patches and work-arounds =<br />
<br />
== mod_ssl renegotiation timeouts ==<br />
<br />
We provide here a workaround for the issue [https://savannah.cern.ch/bugs/?func=detailitem&item_id=48458#comment57 summarised in comment #57 of bug #48458]. The following rpm has been added to the repository: dummy-ca-certs-20090630-1.noarch.rpm. Please note that: <br />
<br />
*This rpm is not added to the ca-policy-egi-core, lcg-CA or ca-policy-lcg metapackage dependencies <br />
*If you want to install it you should run: <tt>yum install dummy-ca-certs</tt> <br />
*The RPM contains 60 expired CAs that cannot be used for validation, but will ensure the mod_ssl renegotiation buffer is large enough<br />
<br />
For Quattor (QWG and CDB) setups, add <br />
<br />
pkg_repl("dummy-ca-certs","20090630-1","noarch");<br />
<br />
to your templates, preferably in a file ''different'' from the automatically-generated egi-ca-policy-core.tpl template. <br />
<br />
== VOMS-ADMIN server does not start (for VOMS-ADMIN service managers only) ==<br />
'''Note:''' ''This issue affects only the gLite versions of VOMS-ADMIN (up to version 2.5.5), it '''does not''' affect EMI/UMD version of VOMS-ADMIN.''<br />
<br />
<br />
A problem has been found where sites upgraded their VOMS server to the latest version of the trust anchors (CA 1.38) and subsequently the VOMS Administrative Interface (VOMS-ADMIN) fails to start. We are presently working to understand the issue. This does not affect the VOMS server itself, but solely the admin interface. <br />
<br />
'''Please [http://repository.egi.eu/sw/production/cas/1/current-old/README.txt read the full announcement]''' for specific warning and actions that you must take. Changing the repository '''is not recommended to anyone''' except for VOMS ADMIN service managers. <br />
<br />
The quick fix is for the VOMS server admins to replace the default EGI trust anchor repository by the following temporary repository <br />
<br />
http://repository.egi.eu/sw/production/cas/1/current-old/<br />
<br />
which can be configured using the Yum repo file as described in the special documentation.<br />
<br />
= Concerns, issues and verification =<br />
<br />
If you experience problems with the installation or upgrade of your trust anchors, or with the repository, please report such an issue through the GGUS system. For issues with the contents of the distribution, concerns about the trust fabric, or with questions about the integrity of the distribution, please contact the EGI IGTF liaison at egi-igtf-liaison@nikhef.nl. <br />
<br />
You can verify the contents of the EGI Trust Anchor (CA) release with those of the International Grid Trust Federation at [https://dist.eugridpma.info/distribution/igtf/current/ https://dist.eugridpma.info/distribution/igtf/current/], or its mirror at [https://www.apgridpma.org/distribution/ https://www.apgridpma.org/distribution/]. See the IGTF and EUGridPMA web pages for additional information. <br />
<br />
Make sure to verify your trust anchors with [https://www.tacar.org/ TACAR], the [http://www.terena.org TERENA] Academic CA Repository, where applicable.</div>Brucellihttps://wiki.egi.eu/w/index.php?title=SL5_retirement&diff=87134SL5 retirement2016-04-18T12:21:16Z<p>Brucelli: /* AfricaArabia */</p>
<hr />
<div>{{TOC_right}}<br />
<br />
The aim of this page is tracking the progressive decommissioning of SL5 from sites. <br />
<br />
UMD is getting ready to support CentOS7. Supporting a new platform will require to decommission a previously support O.S. to make available new resources. EGI Operations will like to decommission '''Scientific Linux 5'''. <br />
<br />
Please start tracking which sites are still using SL5 services: how many services, and for each service if still needed on SL5, if upgrades on SL5 services are expected). Also interesting to understand who is using Debian.<br />
<br />
From September 2015 on, UMD3 will support only security fixes for SL5. Security updates will be available until March 2016. <br />
<br />
'''All SL5 services must be decommissioned by April 2016.''' On February probes will start warning about SL5 services to be decommissioned.<br />
<br />
== Description of the process ==<br />
<br />
* Procedure is https://wiki.egi.eu/wiki/PROC16_Decommissioning_of_unsupported_software<br />
* Decommissioning deadline: April 30, 2016<br />
* Decommissioning start date: January 31, 2016<br />
* On Jan31 a new probe is deployed into the MW SAM and starts returning WARNING with SL5<br />
* '''On Feb28 the probe starts returning CRITICAL.''' <br />
* '''From Feb28 on, RODs follow up the service migration by creating operations ticket through Operations Dashboard (see https://wiki.egi.eu/wiki/PROC16_Decommissioning_of_unsupported_software#Escalation_phase)'''<br />
<br />
== Log ==<br />
<br />
[2016-03-01] Request to turn WARNINGs into CRITICAL: https://ggus.eu/?mode=ticket_info&ticket_id=118901#update#21<br />
<br />
[2016-02-08] SL5 Tests ready on [https://midmon.egi.eu/nagios/ midmon], with corresponding [https://wiki.egi.eu/wiki/MW_SAM_tests#SL5_tests documentation]<br />
<br />
[2016-01-15] Preparation of probe requested https://ggus.eu/?mode=ticket_info&ticket_id=118901<br />
<br />
[2016-01-15] UMD4 released with CentOS7<br />
<br />
[2015-12-17] SL5 retirement announced at OMB https://indico.egi.eu/indico/getFile.py/access?contribId=5&resId=0&materialId=slides&confId=2383<br />
<br />
[2015-07-13] SAM-nagios is still SL5, no SL6 available. ARGO will get fully centralized, there is no need to use SAM-nagios anymore, so regional instances won't be used anymore.<br />
<br />
== Services that are not probed by midmon ==<br />
<br />
*dCache '''HINT''': for installations exposing the web admin interface, you can go to: http:&#47;&#47;&lt;hostname&gt;:2288/info and check within the XML for the "&lt;os&gt;" tag <br />
*DPM <br />
*ARC<br />
*UNICORE<br />
<br />
== 2016-04-18 Overall status ==<br />
<br />
* 6 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_Top-BDII&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 Top-BDII]<br />
* 30 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_Site-BDII&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 Site-BDII]<br />
* 6 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_MyProxy&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 MyProxy]<br />
* 21 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_WMS&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 WMS] and 11 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_LB&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 LB]<br />
* 8 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_VOMS&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 VOMS]<br />
* 2 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_emi.ARGUS&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 ARGUS]<br />
* 27 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_CREAM-CE&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 CREAM-CE]<br />
* 2 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_QCG.Computing&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 QCG Computing]<br />
* 6 [https://midmon.egi.eu/nagios/cgi-bin/status.cgi?servicegroup=SERVICE_SRM&style=detail&servicestatustypes=16&hoststatustypes=15&serviceprops=0&hostprops=0 STORM]<br />
<br />
== Reports by NGIs ==<br />
<br />
Please report here which SL5 services are running, at which sites, and the corresponding dismission plan.<br />
<br />
===AfricaArabia===<br />
Only the regional SAM-Nagios box. This will be decommissioned as soon as the central monitoring is reliable.<br />
<br />
===AsiaPacific===<br />
No report.<br />
<br />
===CERN===<br />
No report.<br />
<br />
===EGI===<br />
No report.<br />
<br />
===IDGF===<br />
No report.<br />
<br />
===NGI_AEGIS===<br />
No report.<br />
<br />
===NGI_ARMGRID===<br />
No report.<br />
<br />
===NGI_BG===<br />
No report.<br />
<br />
===NGI_CH===<br />
No report.<br />
<br />
===NGI_CHINA===<br />
No report.<br />
<br />
===NGI_CZ===<br />
No report.<br />
<br />
===NGI_DE===<br />
No report.<br />
<br />
===NGI_FI===<br />
No report.<br />
<br />
===NGI_FRANCE===<br />
No report.<br />
<br />
===NGI_GE===<br />
No report.<br />
<br />
===NGI_GRNET===<br />
No report.<br />
<br />
===NGI_HR===<br />
No report.<br />
<br />
===NGI_HU===<br />
No report.<br />
<br />
===NGI_IBERGRID===<br />
No report.<br />
<br />
===NGI_IL===<br />
No report.<br />
<br />
===NGI_IT===<br />
No report.<br />
<br />
===NGI_MARGI===<br />
No report.<br />
<br />
===NGI_MD===<br />
No report.<br />
<br />
===NGI_NDGF===<br />
No report.<br />
<br />
===NGI_NL===<br />
No report.<br />
<br />
===NGI_PL===<br />
No report.<br />
<br />
===NGI_RO===<br />
The only SL5 is the one holding ngi.SAM (ngi-ro-nagios.nipne.ro).<br />
<br />
===NGI_SI===<br />
No report.<br />
<br />
===NGI_SK===<br />
Only NGI instances of SAM-nagios are on SL5.<br />
<br />
===NGI_TR===<br />
No report.<br />
<br />
===NGI_UA===<br />
No report.<br />
<br />
===NGI_UK===<br />
DPM: <br />
<br />
Several sites: we’d like to clarify what timescale would be appropriate if we wanted to decommission SL5 pool/head nodes over the coming months rather than migrate.<br />
<br />
Squids:<br />
<br />
With a note that squids are not covered in the probes/exceptions: are these included (some sites have SL5 squids)?<br />
<br />
Non-Squid/DPM services:<br />
<br />
BRUNEL:<br />
<br />
- BDII: SL5 BDII due for retirement<br />
<br />
RHUL:<br />
<br />
- CREAM<br />
- BDII: CentOS 7 being investigated<br />
<br />
BRISTOL:<br />
<br />
- CREAM: 1 VMHost, 2 x CREAM. CREAM to be moved to HTCondor CE (end of May)<br />
<br />
GLASGOW:<br />
<br />
- WMS/LB: Due for decommissioning shortly<br />
<br />
LANCASTER:<br />
<br />
- BDII: SL5 BDII due for upgrade after Easter<br />
<br />
OXFORD:<br />
<br />
- SAM/VO Nagios SL5 only as with others.<br />
<br />
T1:<br />
<br />
Castor SRM systems. Small number of internal service machines. Database systems on Red Hat Enterprise 5. Timeline: SRMs and others - still to be defined.<br />
<br />
===ROC_Canada===<br />
No report.<br />
<br />
===ROC_LA===<br />
No report.<br />
<br />
===Russia===<br />
No report.</div>Brucellihttps://wiki.egi.eu/w/index.php?title=Talk:HOWTO03_Site_Certification_GIIS_Check&diff=85911Talk:HOWTO03 Site Certification GIIS Check2016-02-19T10:42:06Z<p>Brucelli: minor typo</p>
<hr />
<div>There is an typo in <br />
<br />
For each SE, on the CEs the following values must be present: <br />
<br />
GueCESEBindSEUniqueID.<br />
GlueCESEBindCEAccesspoint and GlueCESEBindMountInfo. <br />
<br />
GueCESEBindSEUniqueID --> GlueCESEBindSEUniqueID (missing l)</div>Brucellihttps://wiki.egi.eu/w/index.php?title=CVMFS_Task_Force&diff=82982CVMFS Task Force2015-08-25T12:53:04Z<p>Brucelli: /* NGI Status */</p>
<hr />
<div>{{EGI_Activity_groups_menubar}}<br />
<br />
{{TOC_right}} <br />
<br />
[[Category:Special Interest groups]]<br />
<br />
'''Coordinator''': Catalin Condurache/NGI_UK <br />
<br />
'''Meetings page''': [https://indico.egi.eu/indico/categoryDisplay.py?categId=115 Agendas] <br />
<br />
'''Mailing list''': cvmfs-tf (at) mailman.egi.eu <br />
<br />
'''Members:''' <br />
<br />
*NGIs: <br />
**NGI FI - Ulf Tigerstedt, Luís Alves<br />
**NGI HR - Luko Gjenero, Emir Imamagic <br />
**NGI IBERGRID - Goncalo Borges <br />
**OSG - Scott Teige <br />
**NGI ZA - Bruce Becker <br />
**NGI IT - Paolo Veronesi, Alessandro Constantini <br />
**NGI GRNET - Dimitris Dellis, Kostas Koumantaros <br />
**NGI NL - Dennis van Dok<br />
**NGI ES - Victor Fernandez Albor<br />
*MPI VT - John Walsh <br />
*VOs: <br />
**VLEMED VO - Silvia Olabarriaga, Hurng-Chun Lee, Juan Luis Font<br />
**BIOMED - Johan Montagnat, Franck Michel, Sorina Pop<br />
**WeNMR - Alexandre Bonvin <br />
**AUGER VO - Jiri Chudoba<br />
**glast.org - Michael Kuss, Francesco Longo<br />
*EGI.eu - Tiziana Ferrari, Małgorzata Krakowian, Peter Solagna<br />
<br />
<br />
= Introduction =<br />
<br />
CVMFS (CERN Virtual Machine File System) has already proved to be a good solution for the distribution of application software across the resource centres, and several NGIs are offering CVMFS to national VOs. <br />
<br />
During the April 2013 OMB in Manchester the idea of offering CVMFS as a service for all EGI VOs was discussed. It is about to have a CVMFS infrastructure that not only can be used within EGI, but also in collaboration with OSG for VOs that access resources hosted by both infrastructures. <br />
<br />
<br><br />
<br />
= NGI Status =<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col" | NGI <br />
! scope="col" | Status<br />
|-<br />
| NGI Ibergrid <br />
| IBERGRID is already using CVMFS stratum 0 deployed at RAL as a service<br />
|-<br />
| AAROC<br />
| We were planning to deploy a stratum 0 in South Africa for VO sagrid applications, as well as those in use in other sub-Saharan countries. <br />
Update: We have finished the CI platform and are ready to include the Stratum 0 in the egi.eu distribution. Info at http://www.africa-grid.org/cvmfs and http://www.africa-grid.org/applications<br />
|-<br />
| NGI HR <br />
| We are running CVMFS for our regional VO.<br />
|-<br />
| NGI FI <br />
| We are one of the non-WLCG organizations running cvmfs.<br />
|-<br />
| OSG <br />
| We recently implemented a CVMFS based service for the OSG. Our intended use case is for our virtual organizations and software group to distribute their content by this mechanism. Our design is quite simple, we allow a very few people write access and everyone read access. We are actively adding resources with access enabled, wide adoption being the goal.<br />
|-<br />
| NGI IT <br />
| We have a very basic deployment for our catch-all VO, but it hasn't been very used until now.<br />
|-<br />
| NGI UK <br />
| <br />
We run stratum-0 repos (v2.0.15) for 5 VOs (mice, na62, hone, enmr.eu, phys.ibergrid.vo.eu). Our design allows installation jobs (run by VO_SGM) to write in an NFS area and then rsync to the CVMFS stratum-0 areas. For VOs not supported by GridPP UK (in terms of CPU allocations), we manually upload and maintain their CVMFS repos, but we are currently working to a web interface that will allow their own software management. <br />
<br />
Also we run a CVMFS stratum-1 service (part of the LHC CVMFS infrastructure) which also includes replicas for the above mentioned VOs. <br />
<br />
As plans, we look to migrate the stratum-0 nodes to v2.1.X on SL6. Also we work with CERN to replicate these 5 replicas on their stratum-1 service (3 out of 5 so far replicated). And looking to establish a network of stratum-1 servers to consolidate the non-LHC (or small) VOs cvmfs service infrastructure (tests to start soon with NIKHEF). <br />
<br />
|-<br />
| <br />
| <br />
|-<br />
| <br />
| <br />
|}<br />
<br />
= VO status =<br />
<br />
*(1) is your community already familiar with CVMFS and is CVMFS already used in some form to support production activities? <br />
*(2) are you interested in trying CVMFS?<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col" | VO <br />
! scope="col" | Status<br />
|-<br />
| VLEMED VO <br />
| (1) used in some form to support production activities? <br />
we were not until this email, but we asked around. The Dutch NGI is taking action already for non HEP users. we look forward to their findings. <br />
<br />
(2) yes. <br />
<br />
|-<br />
| Johan Montagnat <br />
| (1) No, we were not aware of this tool before. <br />
(2) There is a clear need for easily deploying software packages grid-wise in the LS community. The existing solution of populating VO software space per site is often considered tedious, and leading to incoherent state when software cannot be installed on some sites due to installation job issues. So an alternative and global scale solution would be welcome. We would need to know a bit more on CVMFS though. From the slides shown, it is not clear how the software registered on the central CVMFS root directory is accessible from the sites / worker nodes in particular. (Is the CVMFS root mounted from all worker nodes? What is the performance impact of accessing to this remote software?). <br />
<br />
|-<br />
| Alexandre Bonvin <br />
| 1. we are making use of it already. Very nice and simple. Only a few sites have that in place at this time<br />
|-<br />
| Jiri Chudoba - auger <br />
| 1. The auger VO plans to use CVMFS. We have not yet built our own system of servers and we would like to <br />
try "central" service. <br />
<br />
|-<br />
| Michael Kuss - glast.org <br />
| &nbsp;1. No <br />
2. Yes <br />
<br />
Comments to Catalin's questions/remarks in the 3-oct-2013 meeting: <br />
<br />
'''Dimension of software area''': 200k files in 15.4GB. These are 4 releases of the level-1 analysis package and 1 of the science analysis sw. 1GB each. The rest are common libraries, calibration db etc. The code is all rhel5 32bit compiled. This may change soon to rhel6 64bit. Hence, for a short transition period the amount may double. <br />
<br />
'''Update frequency''': right now 3-4 times a year, this may change to about once a month'''.''' <br />
<br />
'''Sites''': 8 active EGI sites. We also got enabled at two OSG sites. No sw installed (I was hoping for CVMFS). <br />
<br />
'''Max file size''': bummer! We have a few fits files up to 500MB, used to store the space-craft positions for long term simulations. Is 100MB a hard limit? <br />
<br />
'''No overwrite''': the analysis packages and libraries are versioned. I'm not sure about the calib db and other auxiliary files (like the huge fits files). What is the reasoning behind this design choice? What is about "delete"? <br />
<br />
|}<br />
<br />
= Objectives =<br />
<br />
= Milestones =<br />
<br />
= Actions =<br />
<br />
=== Initial working plan ===<br />
<br />
It has been proposed following CVMFS-TF kick-off meeting (15 August 2013): <br />
<br />
- Collect the expression of interest from VOs. <br />
<br />
- Understand sites availability to install clients. <br />
<br />
- Understand NGI availability to install regional squid. <br />
<br />
- Mirroring between sites hosting stratus0 repositories. Creating a network of stratum1 servers. <br />
<br />
=== Webinar - 5 September 2013 ===<br />
<br />
Aimed to provide needed information to NGIs/sites and user communities about the technical details and possible architecture. <br />
<br />
The complete abstract for the presentation and registration details are available on INDICO at: https://indico.egi.eu/indico/conferenceDisplay.py?confId=1809 <br />
<br />
QA webinar chat window: https://wiki.egi.eu/wiki/File:CVMFS_webinar_QA_chat_window.doc <br />
<br />
Recording - https://documents.egi.eu/public/ShowDocument?docid=1932 <br />
<br />
=== EGI Technical Forum - Madrid, 16 - 20 September 2013 ===<br />
<br />
A presentation on "CVMFS for EGI VOs" has been given during the User Community Board session (https://indico.egi.eu/indico/conferenceTimeTable.py?confId=1851#20130917) followed by Q&amp;A and other discussions about creating the EGI CVMFS infrastructure. <br />
<br />
Express of interest has been gathered from VOs representatives (biomed, auger, vlemed, glast.org) during the Technical Forum and steps of actions have been agreed. <br />
<br />
=== CHEP 2013 - Amsterdam, 14 - 18 October 2013 ===<br />
<br />
A poster on "CernVM-FS – Beyond LHC Computing" has been presented (http://indico.cern.ch/getFile.py/access?contribId=392&amp;sessionId=9&amp;resId=0&amp;materialId=poster&amp;confId=214784) within the "Distributed Processing and Data Handling: Infrastructure, Sites, and Virtualization" track. <br />
<br />
Express of interest in using CVMFS as s/w distribution mechanism has been gathered from cernatschool.org and t2k.org representatives. <br />
<br />
Further actions have been agreed regarding Stratum-1 cross-replication between RAL Tier-1 and OSG sites.<br />
<br />
=== Operations Management Board - 24 April 2014 ===<br />
<br />
A presentation on "CVMFS task force update" has been given during the April OMB meeting (https://indico.egi.eu/indico/materialDisplay.py?contribId=8&materialId=slides&confId=2162)<br />
<br />
=== EGI Community Forum - Helsinki, 19 - 23 May 2014 ===<br />
<br />
A workshop "EGI services for global software and common data distribution" (https://indico.egi.eu/indico/sessionDisplay.py?sessionId=37&confId=1994#20140520) took place on Tuesday 20 May. Presentations on various aspects of deploying and using the CernVM-FS and Frontier technologies were delivered.<br />
<br />
During the workshop, the necessity of a egi.eu CVMFS domain came into discussion. It was agreed to be hosted at RAL, but other stratum-0 sites are welcome to host *.egi.eu repositories (technical details TBC)<br />
<br />
Also a hackathon on "Getting Started with the CernVM FileSystem or the Frontier Distributed Database Caching System" (https://indico.egi.eu/indico/contributionDisplay.py?sessionId=37&contribId=55&confId=1994) followed the workshop. Users were assisted by specialists with trying out the CernVM FileSystem and/or the Frontier Distributed Database Caching System with their own applications. Also specific site CVMFS problems were discussed and suggestions for fixing them given.<br />
<br />
The poster "Software compatibility check framework for grid computing elements" (https://indico.egi.eu/indico/contributionDisplay.py?contribId=16&confId=2016) presented how usage of CernVM-FS overcame problems associated to the software distribution on the grid.<br />
<br />
Following discussions with maintainers of EGI AppDB, it was agreed to create a CVMFS repository that will contain bits of software currently hosted by AppDB. It will be located under the new 'egi.eu' CVMFS domain.<br />
<br />
=== New CVMFS 'egi.eu' domain active - September 2014 ===<br />
<br />
Work has been carried out and finalised on configuration of the new 'egi.eu' CVMFS domain. It is going to replace the 'gridpp.ac.uk' domain which accommodates the EGI VO repositories. All existing repositories (as /cvmfs/<repo_name>.gridpp.ac.uk) located at Stratum-0 (RAL) have been replicated as /cvmfs/<repo_name>.egi.eu and both domains are being replicated by Stratum-1s at RAL, NIKHEF, ASGC. Also TRIUMF is replicating the '*.egi.eu' repositories.<br />
<br />
Few sites across the Grid have been contacted and agreed to manually configure the new domain, and tests proved successfully.<br />
<br />
=== New cvmfs-keys v1.5 package available - 1 November 2014 ===<br />
<br />
A new cvmfs-keys v1.5-1 package has been made available (http://cernvm.cern.ch/portal/filesystem/cvmfs-keys-1.5). It mainly adds the public keys and Stratum-1 server addresses for the egi.eu and opensciencegrid.org CVMFS domains and its roll out will be of significant importance at sites supporting EGI VOs as it automatically configures the new 'egi.eu' domain. Therefore system administrators at sites are encouraged to install the package (https://cvmrepo.web.cern.ch/cvmrepo/yum/cvmfs/EL/5/x86_64/cvmfs-keys-1.5-1.noarch.rpm).<br />
<br />
= Results =<br />
<br />
{| class="wikitable"<br />
|+ EGI CVMFS Deployment Status <br />
|-<br />
! scope="col" | Site <br />
! scope="col" | Stratum-0 <br />
! scope="col" | Stratum-1 <br />
! scope="col" | Squid <br />
! scope="col" | Clients<br />
|-<br />
| RAL-LCG2 <br />
| <br />
mice, na62, hone, phys.vo.ibergrid.eu, enmr.eu, glast.org, hyperk.org, t2k.org, cernatschool.org, biomed, snoplus.snolab.ca, auger, km3net.org, pheno - yes on stratum-0 v2.1 (on both gridpp.ac.uk and egi.eu domains)<br />
<br />
comet.j-parc.jp - in progress <br />
<br />
| repositories replicated by dedicated EGI Stratum-1 <br />
<br />
vlemed, *.desy.de and oasis.opensciencegrid.org repos replicated by EGI Stratum-1 <br />
<br />
| yes <br />
| all VOs<br />
|-<br />
| Tier-2s UK <br />
| <br />
| <br />
| <br />
| as requested (mice, na62, hyperk.org, t2k.ork)<br />
|-<br />
| ZA_UJ <br />
| <br />
| <br />
| <br />
| enmr.eu<br />
|-<br />
| OSG <br />
| oasis.opensciencegrid.org <br />
| replicates the non-LHC (gridpp.ac.uk) repositories from RAL-LCG2 <br />
| <br />
| as requested, enmr, auger, geant4<br />
|-<br />
| CERN <br />
| <br />
| replicates mice, na62, hone, phys-ibergrid and wenmr (gridpp.ac.uk) repos from RAL-LCG2 <br />
| <br />
| <br />
|-<br />
| NIKHEF <br />
| vlemed on stratum-0 v2.1 <br />
| replicates all *.gridpp.ac.uk and *.egi.eu repos from RAL-LCG2 <br />
| <br />
| <br />
|-<br />
| DESY <br />
| ilc, calice, hermes, hone, olympus, xfel, zeus on stratum-0 v2.1 <br />
| <br />
| <br />
|-<br />
| ASGC <br />
|<br />
| replicates all *.gridpp.ac.uk and *.egi.eu repos from RAL-LCG2<br />
| <br />
|<br />
|-<br />
| TRIUMF<br />
|<br />
| replicates the entire 'egi.eu' domain from RAL-LCG2<br />
|<br />
|<br />
|}<br />
<br />
= Configurations =<br />
<br />
For the 'egi.eu' repositories (auger, biomed, cernatschool, glast, hyperk, km3net, mice, na62, pheno, phys-ibergrid, snoplus, t2k, wenmr) please install the latest cvmfs-keys v1.5-1 RPM (https://cvmrepo.web.cern.ch/cvmrepo/yum/cvmfs/EL/5/x86_64/cvmfs-keys-1.5-1.noarch.rpm). It practically automatically configures the 'egi.eu' domain by adding the public keys and Stratum-1 server addresses. It does the same things for the 'opensciencegrid.org' domain as well.<br />
<br />
For other repositories see below.<br />
<br />
{| width="783" class="wikitable"<br />
|+ Recommended Configurations at Replicas and Clients Level <br />
|-<br />
! scope="col" | VO <br />
! scope="col" | Variables <br />
! scope="col" | Values<br />
|-<br />
| rowspan="2" | ilc <br> <br />
| CVMFS_STRATUM0 <br />
| <pre>http://grid-cvmfs-null.desy.de:8000/cvmfs/ilc.desy.de</pre><br />
|-<br />
| CVMFS_SERVER_URL <br />
| <pre>http://grid-cvmfs-one.desy.de:8000/cvmfs/ilc.desy.de</pre> <pre>http://cvmfs-stratum-one.cern.ch/cvmfs/ilc.desy.de</pre><br />
|-<br />
| rowspan="2" | calice <br> <br />
| CVMFS_STRATUM0 <br />
| <pre>http://grid-cvmfs-null.desy.de:8000/cvmfs/calice.desy.de</pre><br />
|-<br />
| CVMFS_SERVER_URL <br />
| <pre>http://grid-cvmfs-one.desy.de:8000/cvmfs/calice.desy.de</pre> <pre>http://cvmfs-stratum-one.cern.ch/cvmfs/calice.desy.de</pre><br />
|-<br />
| rowspan="2" | hone <br> <br />
| CVMFS_STRATUM0 <br />
| <pre>http://grid-cvmfs-null.desy.de:8000/cvmfs/hone.desy.de</pre><br />
|-<br />
| CVMFS_SERVER_URL <br />
| <pre>http://grid-cvmfs-one.desy.de:8000/cvmfs/hone.desy.de</pre> <pre>http://cvmfs-stratum-one.cern.ch/cvmfs/hone.desy.de</pre><br />
|-<br />
| rowspan="2" | hermes <br> <br />
| CVMFS_STRATUM0 <br />
| <pre>http://grid-cvmfs-null.desy.de:8000/cvmfs/hermes.desy.de</pre><br />
|-<br />
| CVMFS_SERVER_URL <br />
| <pre>http://grid-cvmfs-one.desy.de:8000/cvmfs/hermes.desy.de</pre> <pre>http://cvmfs-stratum-one.cern.ch/cvmfs/hermes.desy.de</pre><br />
|-<br />
| rowspan="2" | vlemed <br> <br />
| CVMFS_STRATUM0 <br />
| <pre>http://mesthoop.nikhef.nl/cvmfs/vlemed.amc.nl</pre><br />
|-<br />
| CVMFS_SERVER_URL <br />
| <pre>http://cvmfs01.nikhef.nl/cvmfs/vlemed.amc.nl</pre> <pre>http://cvmfs-egi.gridpp.rl.ac.uk:8000/cvmfs/vlemed.amc.nl</pre><br />
|}<br />
<br />
= Useful Links =<br />
<br />
'''CVMFS home page''' http://cernvm.cern.ch/portal/filesystem <br />
<br />
'''CVMFS - Beyond LHC Computing''' https://indico.egi.eu/indico/getFile.py/access?contribId=7&amp;resId=0&amp;materialId=slides&amp;confId=1235 <br />
<br />
'''RAL Tier1 CVMFS''' https://www.gridpp.ac.uk/wiki/RAL_Tier1_CVMFS <br />
<br />
'''CVMFS for non LHC VOs''' https://www.gridpp.ac.uk/wiki/RALnonLHCCVMFS</div>Brucellihttps://wiki.egi.eu/w/index.php?title=SAM_Instances&diff=69478SAM Instances2014-08-15T08:17:24Z<p>Brucelli: /* NGI ROC instances */ Added Africa-Arabia Regional Operations Centre instance. (ex-NGI_ZA)</p>
<hr />
<div>{{Template:Op menubar}}<br />
{{Template:Tools menubar}}<br />
{{TOC_right}}<br />
[[category:SAM]]<br />
== Overview ==<br />
<br />
The page contains the official list of SAM which are responsible for monitoring individual NGIs and regions. <br />
<br />
In the first section you can find the list of NGIs which have deployed NGI SAM instance. In the second section are ROC instances which are covering sites in countries which haven't finished NGI creation process.<br />
<br />
== EGI MyEGI ==<br />
* MyEGI Central Instance: [https://mon.egi.eu/myegi https://mon.egi.eu/myegi]<br />
<br />
== Central OPS SAM Instances ==<br />
<br />
=== Operational tools monitoring ===<br />
<br />
Central [https://opsmon.egi.eu/nagios/ Nagios] monitoring central operational tools and NGI SAM instances<br />
<br />
=== MW monitoring ===<br />
<br />
Central [https://midmon.egi.eu/nagios/ Nagios] monitoring MW versions.<br />
<br />
== NGI SAM instances ==<br />
<br />
{| class="wikitable"<br />
!NGI<br />
!Country/ies<br />
!Nagios portal<br />
!MyEGI portal<br />
|-<br />
|NGI_AEGIS<br />
|Serbia<br />
|https://nagios.ipb.ac.rs/nagios/<br />
|https://nagios.ipb.ac.rs/myegi/<br />
|-<br />
|NGI_ARMGRID<br />
|Armenia<br />
|https://sam.grid.am/nagios/<br />
|https://sam.grid.am/myegi/<br />
|-<br />
|NGI_BA<br />
|Bosnia and Herzegovina<br />
|https://c04.grid.etfbl.net/nagios/<br />
|https://c04.grid.etfbl.net/myegi/<br />
|-<br />
|NGI_BG<br />
|Bulgaria<br />
|https://nagios.ipp.acad.bg/nagios/<br />
|https://nagios.ipp.acad.bg/myegi/<br />
|-<br />
|NGI_BY<br />
|Belarus<br />
|https://grid-monitoring.basnet.by/nagios/<br />
|https://grid-monitoring.basnet.by/myegi/<br />
|-<br />
|NGI_CYGRID<br />
|Cyprus<br />
|https://cygrid-nagios.grid.ucy.ac.cy/nagios/<br />
|https://cygrid-nagios.grid.ucy.ac.cy/myegi/<br />
|-<br />
|NGI_CZ<br />
|Czech Republic<br />
|https://nagios.egee.cesnet.cz/nagios/<br />
|https://nagios.egee.cesnet.cz/myegi/<br />
|-<br />
|NGI_DE, NGI_CH<br />
|Germany, Switzerland<br />
|https://ngi-de-nagios.gridka.de/nagios/<br />
|https://ngi-de-nagios.gridka.de/myegi/<br />
|-<br />
|NGI_FI<br />
|Finland<br />
|https://ping.fgi.csc.fi/nagios/<br />
|https://ping.fgi.csc.fi/myegi/<br />
|-<br />
|NGI_France<br />
|France<br />
|https://ccnagboxli01.in2p3.fr/nagios/<br />
|https://ccnagboxli01.in2p3.fr/myegi/<br />
|-<br />
|NGI_GE<br />
|Georgia<br />
|https://nagios.sg.grena.ge/nagios/<br />
|https://nagios.sg.grena.ge/myegi/<br />
|-<br />
|NGI_GRNET<br />
|Greece<br />
|https://nagios.hellasgrid.gr/nagios/<br />
|https://nagios.hellasgrid.gr/myegi/<br />
|-<br />
|NGI_HR<br />
|Croatia<br />
|https://mon.egi.cro-ngi.hr/nagios/<br />
|https://mon.egi.cro-ngi.hr/myegi/<br />
|-<br />
|NGI_HU<br />
|Hungary<br />
|https://grid19.kfki.hu/nagios/<br />
|https://grid19.kfki.hu/myegi/<br />
|-<br />
|NGI_IBERGRID<br />
|Spain, Portugal<br />
|https://rnagios.ibergrid.cesga.es/nagios/<br />
|https://rnagios.ibergrid.cesga.es/myegi/<br />
|-<br />
|NGI_UK<br />
|UK<br />
|https://gridppnagios.physics.ox.ac.uk/nagios/<br />
|https://gridppnagios.physics.ox.ac.uk/myegi/<br />
|-<br />
|NGI_IL<br />
|Israel<br />
|https://wipp-srs.weizmann.ac.il/nagios/<br />
|https://wipp-srs.weizmann.ac.il/myegi/<br />
|-<br />
|NGI_IT<br />
|Italy<br />
|https://mon-it.cnaf.infn.it/nagios/<br />
|https://mon-it.cnaf.infn.it/myegi/<br />
|-<br />
|NGI_MARGI<br />
|FYROM<br />
|https://grid-nagios.ii.edu.mk/nagios/<br />
|https://grid-nagios.ii.edu.mk/myegi/<br />
|-<br />
|NGI_MD<br />
|Moldova<br />
|https://node02-02.imi.renam.md/nagios/<br />
|https://node02-02.imi.renam.md/myegi/<br />
|-<br />
|NGI_ME<br />
|Montenegro<br />
|https://nagios.grid.ac.me/nagios/<br />
|https://nagios.grid.ac.me/myegi/<br />
|-<br />
|NGI_NDGF<br />
|Austria, Denmark <br> <br />
Estonia, Latvia <br> <br />
Lithuania, Norway, Sweden<br />
|https://ngi-sam.ndgf.org/nagios/<br />
|https://ngi-sam.ndgf.org/myegi/<br />
|-<br />
|NGI_NL<br />
|Belgium, Netherlands<br />
|https://sam-ngi.grid.sara.nl/nagios/<br />
|https://sam-ngi.grid.sara.nl/myegi/<br />
|-<br />
|NGI_PL<br />
|Poland<br />
|https://pl-mon.grid.cyf-kr.edu.pl/nagios/<br />
|https://pl-mon.grid.cyf-kr.edu.pl/myegi/<br />
|-<br />
|NGI_RO<br />
|Romania<br />
|https://ngi-ro-nagios.ici.ro/nagios/<br />
|https://ngi-ro-nagios.ici.ro/myegi/<br />
|-<br />
|NGI_SI<br />
|Slovenia<br />
|https://nagios.sling.si/nagios/<br />
|https://nagios.sling.si/myegi/<br />
|-<br />
|NGI_SK<br />
|Slovakia<br />
|https://nagmon.ui.savba.sk/nagios/<br />
|https://nagmon.ui.savba.sk/myegi/<br />
|-<br />
|NGI_TR<br />
|Turkey<br />
|https://nagios.ulakbim.gov.tr/nagios/<br />
|https://nagios.ulakbim.gov.tr/myegi/<br />
|-<br />
|NGI_UA<br />
|Ukraine<br />
|https://mon-ua.bitp.kiev.ua/nagios/<br />
|https://mon-ua.bitp.kiev.ua/myegi/<br />
|-<br />
|}<br />
<br />
== NGI ROC instances ==<br />
<br />
{| class="wikitable"<br />
!ROC<br />
!Country/ies<br />
!Nagios portal<br />
!MyEGI portal<br />
|-<br />
|Africa Arabia<br />
|African partners<br />
|https://nagios.c4.csir.co.za/nagios/<br />
|https://nagios.c4.csir.co.za/myegi/<br />
|-<br />
|Asia Pacific <br> <br />
|Asia Pacific partners<br />
|https://rocnagios.grid.sinica.edu.tw/nagios/<br />
|https://rocnagios.grid.sinica.edu.tw/myegi/<br />
|-<br />
|CERN<br />
|CERN<br />
|https://sam-cern-roc.cern.ch/nagios/<br />
|https://sam-cern-roc.cern.ch/myegi/<br />
|-<br />
|ROC_Canada <br><br />
(external partners)<br />
|Canada<br />
|https://roc-nagios.triumf.ca/nagios/<br />
|https://roc-nagios.triumf.ca/myegi/<br />
|-<br />
|ROC_LA <br><br />
(external partners)<br />
|LA partners<br />
|<!-- old instance https://nagios.roc-la.org/nagios/ --> https://nagios.cat.cbpf.br/nagios/<br />
|<!-- old instance https://nagios.roc-la.org/myegi/ --> https://nagios.cat.cbpf.br/myegi/<br />
|-<br />
|Russia<br />
|Russia<br />
|https://rnag1.grid.kiae.ru/nagios/<br />
|https://rnag1.grid.kiae.ru/myegi/<br />
|-<br />
|}<br />
<br />
== Analysis of SAM instances in GOCDB ==<br />
<br />
Instances in GOCDB and not in SAM:<br />
* NGI_FRANCE - https://ggus.eu/ws/ticket_info.php?ticket=101173 '''SOLVED - instance marked with scope Local'''<br />
* NGI_PL - https://ggus.eu/ws/ticket_info.php?ticket=101192 '''SOLVED - old instance removed, NGI instance left in GOCDB'''<br />
* Russia - https://ggus.eu/ws/ticket_info.php?ticket=101172 '''SOLVED instance left in GOCDB, once ready will be added to SAM'''<br />
<br />
Instances in GOCDB and in SAM but marked as non monitored:<br />
* NGI_CYGRID - https://ggus.eu/ws/ticket_info.php?ticket=101170 '''SOLVED - instance marked as monitored'''<br />
* NGI_IL - https://ggus.eu/ws/ticket_info.php?ticket=101168 '''SOLVED - instance marked as monitored'''<br />
<br />
Instances missing in GOCDB:<br />
* NGI_BY - https://ggus.eu/ws/ticket_info.php?ticket=101166 '''SOLVED - nagios-roles.conf corrected to point to the GOCDB instance'''<br />
* NGI_RO - https://ggus.eu/index.php?mode=ticket_info&ticket_id=101843 - '''SOLVED - secondary instance removed from GOCDB'''<br />
<br />
Instances in GOCDB assigned to non-Certified sites:<br />
* NGI_ARMGRID - https://ggus.eu/index.php?mode=ticket_info&ticket_id=101743 - '''SOLVED - instance installed and site is Certified'''<br />
<br />
Backup instances missing in GOCDB (not critical):<br />
* NGI_IT - instance mon-cnaf.cnaf.infn.it '''SOLVED - added: https://goc.egi.eu/portal/index.php?Page_Type=Service&id=5277'''<br />
* NGI_NL</div>Brucellihttps://wiki.egi.eu/w/index.php?title=SAM_Instances&diff=69477SAM Instances2014-08-15T08:15:10Z<p>Brucelli: /* NGI SAM instances */ - removed NGI_ZA due to decommissioning</p>
<hr />
<div>{{Template:Op menubar}}<br />
{{Template:Tools menubar}}<br />
{{TOC_right}}<br />
[[category:SAM]]<br />
== Overview ==<br />
<br />
The page contains the official list of SAM which are responsible for monitoring individual NGIs and regions. <br />
<br />
In the first section you can find the list of NGIs which have deployed NGI SAM instance. In the second section are ROC instances which are covering sites in countries which haven't finished NGI creation process.<br />
<br />
== EGI MyEGI ==<br />
* MyEGI Central Instance: [https://mon.egi.eu/myegi https://mon.egi.eu/myegi]<br />
<br />
== Central OPS SAM Instances ==<br />
<br />
=== Operational tools monitoring ===<br />
<br />
Central [https://opsmon.egi.eu/nagios/ Nagios] monitoring central operational tools and NGI SAM instances<br />
<br />
=== MW monitoring ===<br />
<br />
Central [https://midmon.egi.eu/nagios/ Nagios] monitoring MW versions.<br />
<br />
== NGI SAM instances ==<br />
<br />
{| class="wikitable"<br />
!NGI<br />
!Country/ies<br />
!Nagios portal<br />
!MyEGI portal<br />
|-<br />
|NGI_AEGIS<br />
|Serbia<br />
|https://nagios.ipb.ac.rs/nagios/<br />
|https://nagios.ipb.ac.rs/myegi/<br />
|-<br />
|NGI_ARMGRID<br />
|Armenia<br />
|https://sam.grid.am/nagios/<br />
|https://sam.grid.am/myegi/<br />
|-<br />
|NGI_BA<br />
|Bosnia and Herzegovina<br />
|https://c04.grid.etfbl.net/nagios/<br />
|https://c04.grid.etfbl.net/myegi/<br />
|-<br />
|NGI_BG<br />
|Bulgaria<br />
|https://nagios.ipp.acad.bg/nagios/<br />
|https://nagios.ipp.acad.bg/myegi/<br />
|-<br />
|NGI_BY<br />
|Belarus<br />
|https://grid-monitoring.basnet.by/nagios/<br />
|https://grid-monitoring.basnet.by/myegi/<br />
|-<br />
|NGI_CYGRID<br />
|Cyprus<br />
|https://cygrid-nagios.grid.ucy.ac.cy/nagios/<br />
|https://cygrid-nagios.grid.ucy.ac.cy/myegi/<br />
|-<br />
|NGI_CZ<br />
|Czech Republic<br />
|https://nagios.egee.cesnet.cz/nagios/<br />
|https://nagios.egee.cesnet.cz/myegi/<br />
|-<br />
|NGI_DE, NGI_CH<br />
|Germany, Switzerland<br />
|https://ngi-de-nagios.gridka.de/nagios/<br />
|https://ngi-de-nagios.gridka.de/myegi/<br />
|-<br />
|NGI_FI<br />
|Finland<br />
|https://ping.fgi.csc.fi/nagios/<br />
|https://ping.fgi.csc.fi/myegi/<br />
|-<br />
|NGI_France<br />
|France<br />
|https://ccnagboxli01.in2p3.fr/nagios/<br />
|https://ccnagboxli01.in2p3.fr/myegi/<br />
|-<br />
|NGI_GE<br />
|Georgia<br />
|https://nagios.sg.grena.ge/nagios/<br />
|https://nagios.sg.grena.ge/myegi/<br />
|-<br />
|NGI_GRNET<br />
|Greece<br />
|https://nagios.hellasgrid.gr/nagios/<br />
|https://nagios.hellasgrid.gr/myegi/<br />
|-<br />
|NGI_HR<br />
|Croatia<br />
|https://mon.egi.cro-ngi.hr/nagios/<br />
|https://mon.egi.cro-ngi.hr/myegi/<br />
|-<br />
|NGI_HU<br />
|Hungary<br />
|https://grid19.kfki.hu/nagios/<br />
|https://grid19.kfki.hu/myegi/<br />
|-<br />
|NGI_IBERGRID<br />
|Spain, Portugal<br />
|https://rnagios.ibergrid.cesga.es/nagios/<br />
|https://rnagios.ibergrid.cesga.es/myegi/<br />
|-<br />
|NGI_UK<br />
|UK<br />
|https://gridppnagios.physics.ox.ac.uk/nagios/<br />
|https://gridppnagios.physics.ox.ac.uk/myegi/<br />
|-<br />
|NGI_IL<br />
|Israel<br />
|https://wipp-srs.weizmann.ac.il/nagios/<br />
|https://wipp-srs.weizmann.ac.il/myegi/<br />
|-<br />
|NGI_IT<br />
|Italy<br />
|https://mon-it.cnaf.infn.it/nagios/<br />
|https://mon-it.cnaf.infn.it/myegi/<br />
|-<br />
|NGI_MARGI<br />
|FYROM<br />
|https://grid-nagios.ii.edu.mk/nagios/<br />
|https://grid-nagios.ii.edu.mk/myegi/<br />
|-<br />
|NGI_MD<br />
|Moldova<br />
|https://node02-02.imi.renam.md/nagios/<br />
|https://node02-02.imi.renam.md/myegi/<br />
|-<br />
|NGI_ME<br />
|Montenegro<br />
|https://nagios.grid.ac.me/nagios/<br />
|https://nagios.grid.ac.me/myegi/<br />
|-<br />
|NGI_NDGF<br />
|Austria, Denmark <br> <br />
Estonia, Latvia <br> <br />
Lithuania, Norway, Sweden<br />
|https://ngi-sam.ndgf.org/nagios/<br />
|https://ngi-sam.ndgf.org/myegi/<br />
|-<br />
|NGI_NL<br />
|Belgium, Netherlands<br />
|https://sam-ngi.grid.sara.nl/nagios/<br />
|https://sam-ngi.grid.sara.nl/myegi/<br />
|-<br />
|NGI_PL<br />
|Poland<br />
|https://pl-mon.grid.cyf-kr.edu.pl/nagios/<br />
|https://pl-mon.grid.cyf-kr.edu.pl/myegi/<br />
|-<br />
|NGI_RO<br />
|Romania<br />
|https://ngi-ro-nagios.ici.ro/nagios/<br />
|https://ngi-ro-nagios.ici.ro/myegi/<br />
|-<br />
|NGI_SI<br />
|Slovenia<br />
|https://nagios.sling.si/nagios/<br />
|https://nagios.sling.si/myegi/<br />
|-<br />
|NGI_SK<br />
|Slovakia<br />
|https://nagmon.ui.savba.sk/nagios/<br />
|https://nagmon.ui.savba.sk/myegi/<br />
|-<br />
|NGI_TR<br />
|Turkey<br />
|https://nagios.ulakbim.gov.tr/nagios/<br />
|https://nagios.ulakbim.gov.tr/myegi/<br />
|-<br />
|NGI_UA<br />
|Ukraine<br />
|https://mon-ua.bitp.kiev.ua/nagios/<br />
|https://mon-ua.bitp.kiev.ua/myegi/<br />
|-<br />
|}<br />
<br />
== NGI ROC instances ==<br />
<br />
{| class="wikitable"<br />
!ROC<br />
!Country/ies<br />
!Nagios portal<br />
!MyEGI portal<br />
|-<br />
|Asia Pacific <br> <br />
|Asia Pacific partners<br />
|https://rocnagios.grid.sinica.edu.tw/nagios/<br />
|https://rocnagios.grid.sinica.edu.tw/myegi/<br />
|-<br />
|CERN<br />
|CERN<br />
|https://sam-cern-roc.cern.ch/nagios/<br />
|https://sam-cern-roc.cern.ch/myegi/<br />
|-<br />
|ROC_Canada <br><br />
(external partners)<br />
|Canada<br />
|https://roc-nagios.triumf.ca/nagios/<br />
|https://roc-nagios.triumf.ca/myegi/<br />
|-<br />
|ROC_LA <br><br />
(external partners)<br />
|LA partners<br />
|<!-- old instance https://nagios.roc-la.org/nagios/ --> https://nagios.cat.cbpf.br/nagios/<br />
|<!-- old instance https://nagios.roc-la.org/myegi/ --> https://nagios.cat.cbpf.br/myegi/<br />
|-<br />
|Russia<br />
|Russia<br />
|https://rnag1.grid.kiae.ru/nagios/<br />
|https://rnag1.grid.kiae.ru/myegi/<br />
|-<br />
|}<br />
<br />
== Analysis of SAM instances in GOCDB ==<br />
<br />
Instances in GOCDB and not in SAM:<br />
* NGI_FRANCE - https://ggus.eu/ws/ticket_info.php?ticket=101173 '''SOLVED - instance marked with scope Local'''<br />
* NGI_PL - https://ggus.eu/ws/ticket_info.php?ticket=101192 '''SOLVED - old instance removed, NGI instance left in GOCDB'''<br />
* Russia - https://ggus.eu/ws/ticket_info.php?ticket=101172 '''SOLVED instance left in GOCDB, once ready will be added to SAM'''<br />
<br />
Instances in GOCDB and in SAM but marked as non monitored:<br />
* NGI_CYGRID - https://ggus.eu/ws/ticket_info.php?ticket=101170 '''SOLVED - instance marked as monitored'''<br />
* NGI_IL - https://ggus.eu/ws/ticket_info.php?ticket=101168 '''SOLVED - instance marked as monitored'''<br />
<br />
Instances missing in GOCDB:<br />
* NGI_BY - https://ggus.eu/ws/ticket_info.php?ticket=101166 '''SOLVED - nagios-roles.conf corrected to point to the GOCDB instance'''<br />
* NGI_RO - https://ggus.eu/index.php?mode=ticket_info&ticket_id=101843 - '''SOLVED - secondary instance removed from GOCDB'''<br />
<br />
Instances in GOCDB assigned to non-Certified sites:<br />
* NGI_ARMGRID - https://ggus.eu/index.php?mode=ticket_info&ticket_id=101743 - '''SOLVED - instance installed and site is Certified'''<br />
<br />
Backup instances missing in GOCDB (not critical):<br />
* NGI_IT - instance mon-cnaf.cnaf.infn.it '''SOLVED - added: https://goc.egi.eu/portal/index.php?Page_Type=Service&id=5277'''<br />
* NGI_NL</div>Brucellihttps://wiki.egi.eu/w/index.php?title=GGUS:AfricaArabia_FAQ&diff=64818GGUS:AfricaArabia FAQ2014-02-18T13:02:02Z<p>Brucelli: </p>
<hr />
<div>{{GGUS-FAQ<br />
|Unit= AfricaArabia<br />
|Interface= H<br />
|purpose= AfricaArabia provides support to sites registered in the Africa-Arabia Regional Operations Centre. These are in the geographical area spanning Africa and the countries served by the Arab States Regional Network (ASREN). It provides monitoring of these sites and assists with operational issues. It provides site administrator training and limited user support. <br />
|components= provides support for gLite components of the EMI and UMD middleware stack.<br />
|assigned by= TPM (or any SU) can assign general requests for support from users using the AfricaArabia resources. There are no special permissions required for this SU<br />
|responsible= Meraka Institute (ZA-MERAKA)<br />
|solved by= Tickets can be solved by the support unit, the sites themselves or can be solved by other Support Units, if the issue has been escalated.<br />
|documentation= https://roc.africa-grid.org<br />
|sortname=AfricaArabia<br />
}}</div>Brucellihttps://wiki.egi.eu/w/index.php?title=GGUS:NGI_ZA_FAQ&diff=56801GGUS:NGI ZA FAQ2013-06-21T12:33:51Z<p>Brucelli: </p>
<hr />
<div>[[Category:FAQ support units (GGUS)]]<br />
{{GGUS-FAQ<br />
|Unit= NGI_ZA<br />
|Interface= H<br />
|Updated= last updated 2013-MM-DD<br />
|purpose= NGI_ZA provides support to South African sites registered in the Africa-Arabia Regional Operations Centre. It provides monitoring of these sites and assists with operational issues. It provides site administrator training and limited user support<br />
What is the purpose of the UNIT?<br />
|components= NGI_ZA provides support for gLite components of the EMI and UMD middleware stack.<br />
|assigned by= TPM (or any SU) can assign general requests for support from users using the NGI_ZA resources. There are no special permissions required for this SU<br />
|solved by= Tickets can be solved by the support unit, the sites themselves or can be solved by other Support Units, if the issue has been escalated.<br />
|responsible= Meraka Institute, C.S.I.R.<br />
|documentation= https://ops.sagrid.ac.za/trac - available to SAGrid Site Admins. <br />
|more= Contact SAGrid Coordinator : Bruce Becker - bbecker@csir.co.za<br />
|sortname= NGI_ZA<br />
}}</div>Brucellihttps://wiki.egi.eu/w/index.php?title=GGUS:NGI_ZA_FAQ&diff=24843GGUS:NGI ZA FAQ2011-09-27T07:39:32Z<p>Brucelli: </p>
<hr />
<div>{{GGUS-FAQ<br />
|Unit= NGI_ZA<br />
|Interface= H<br />
|Updated= 2011-09-27<br />
|purpose= to coordinate and manage the support for the South African resources in EGI.<br />
|sortname=Ngi ZA<br />
|components= This support unit provides first-line support for South African resources, in response to tickets generated by South African or other users.<br />
|responsible= Bruce Becker - bbecker@csir.co.za<br />
|documentation= Documentation is maintained for internal purposes only.<br />
|assigned by=TPM, ROD, and alarm tickets for ZA sites<br />
|solved by=Tickets are typically reassigned to ZA sites or servies.<br />
}}</div>Brucellihttps://wiki.egi.eu/w/index.php?title=GGUS:NGI_ZA_FAQ&diff=24840GGUS:NGI ZA FAQ2011-09-27T07:39:05Z<p>Brucelli: </p>
<hr />
<div>{{GGUS-FAQ<br />
|Unit= NGI_ZA<br />
|Interface= H<br />
|Updated= <br />
|purpose= to coordinate and manage the support for the South African resources in EGI.<br />
|sortname=Ngi ZA<br />
|components= This support unit provides first-line support for South African resources, in response to tickets generated by South African or other users.<br />
|responsible= Bruce Becker - bbecker@csir.co.za<br />
|documentation= Documentation is maintained for internal purposes only.<br />
|assigned by=PM, ROD, and alarm tickets for ZA sites<br />
|solved by=Tickets are typically reassigned to ZA sites or servies.<br />
}}</div>Brucellihttps://wiki.egi.eu/w/index.php?title=GGUS:NGI_ZA_FAQ&diff=24836GGUS:NGI ZA FAQ2011-09-27T07:32:12Z<p>Brucelli: </p>
<hr />
<div>{{GGUS-FAQ<br />
|Unit= NGI_ZA<br />
|Interface= H<br />
|Updated= <br />
|purpose= to describe the national grid initiative in South Africa<br />
|sortname=Ngi ZL<br />
|components=<br />
|responsible=<br />
|assigned by=<br />
|solved by=<br />
}}</div>Brucellihttps://wiki.egi.eu/w/index.php?title=User:Brucelli&diff=24533User:Brucelli2011-09-15T13:25:46Z<p>Brucelli: Created page with 'This is the page describing Bruce Becker, Coordinator of SAGrid.'</p>
<hr />
<div>This is the page describing Bruce Becker, Coordinator of SAGrid.</div>Brucelli