GOCDB/Input System User Documentation
|Main||EGI.eu operations services||Support||Documentation||Tools||Activities||Performance||Technology||Catch-all Services||Resource Allocation||Security|
|Tools menu:||• Main page||• Instructions for developers||• AAI Proxy||• Accounting Portal||• Accounting Repository||• AppDB||• ARGO||• GGUS||• GOCDB|
|• Message brokers||• Licenses||• OTAGs||• Operations Portal||• Perun||• EGI Collaboration tools||• LToS||• EGI Workload Manager|
<<Back to GOCDB/Documentation_Index
Scope of this documentation
This user documentation is about the GOCDB4 Input System, which is either:
- The regionally deployed instance of GOCDB, containing local information
- The centrally hosted instance that allows users of non regionalised NGIs to update their information
- Other documentation pages are listed from GOCDB/Documentation Index
Version and improvements
This documentation is meant to be useful and accurate. If you think it is not, please send us any improvement suggestions to gocdb-admins_at_mailtalk.ac.uk
GOCDB version supported in this documentation: 4.3 (April 2012)
Quick Orientation guide
Accessing GOCDB4 input system
To access the web interface, you need an X509 digital certificate installed in your browser, delivered by one of the recognised EU-Grid-PMA Certification Authorities.
You can access the system as soon as you have a recognised X509 certificate, however you will only be able to update information if you register and obtain a role. More information about roles and associated permission is available in the #Users and roles section.
All roles applications need to be validated by parent roles or administrators. Once this is done, you can access/modify relevant information according to the role you have been granted. You can learn more on roles and user accounts by reading the #Users and roles section of this documentation.
How is the information organised?
The following sets of information in GOCDB4 are organised in a similar way to GOCDB3:
- Sites and related information
- Service endpoints and related information
- Groups (NGIs, ROCs, Countries) and related information
- Users and related information
- Downtimes and related information
Main changes between GOCDB3 and GOCDB4 are related to:
- Nodes and related information: the notion of node disappears in GOCDB4 and is replaced by the notion of "service endpoints"
- Groups in GOCDB4 are a generic replacement of specific groups such as ROC or Country.
Users and roles
Understanding and manipulating user accounts
Registering a new user account
Any new users that would like a GOCDB account have to follow this procedure. Having a grid certificate installed in your browser is enough to have read-only access to all the public features of GOCDB. If you need to edit data in GOCDB you will need to fill in the registration form.
- Go to the GOCDB input system web portal
- In the sidebar, look out for the User status panel
- click on the "register a new account" link
- fill in the form and validate
Note: If you were registered in GOCDB but are not recognised anymore (e.g. because your certificate DN changed), do not register again! Instead, follow the steps described in the #Changing_your_certificate_DN section
Editing your user account
The editing process is the same as the registration process. To edit your use account, simply follow these steps:
- click on the "view details" link in the "User Status" panel on the sidebar. you should get a page showing your user account information
- click on the "edit" link on top of it.
Each user account has its own user details page which is accessible to anyone with a valid certificate.
There is currently no facility for listing all users in the database. List of users that have a role on a given site appears on site details pages (see section about sites). It is also possible to search for a user's account using the search feature on the sidebar.
Deactivating a user account
If you wish to unregister from GOCDB, follow these steps:
- click on the "view details" link in the "User Status" panel on the sidebar. you should get a page showing your user account information
- click on the "delete" link on top of it.
- confirm your choice
Your account will then be deactivated and all your roles revoked.
Understanding and manipulating roles
Registered users with a user account will need at least one role in order to perform any useful tasks. Main roles available in GOCDB are:
- At site level (C Users)
- Site Administrator - person responsible of maintaining a grid site and associated information in GOCDB
- At site level (C' Users)
- Note: C' users can grant roles over the site
- Site Security officer - official security contact point at site level
- Site Operations Deputy Manager - The deputy manager of operations at a site
- Site Operations Manager - The manager site operations
- At regional level (D Users)
- Regional Manager and deputy Regional manager - people that officially carry on NGI/Regional management
- Regional Operations Staff - staff involved in Operations Centre activities such as user/operations support and staff doing 1st line support as defined in operations procedure manual
- Security officer - official security contact point at regional level
- At project level (E Users)
- Chief Operations Officer (COO) EGI
- C-COD staff - Central-COD staff (as previously defined in EGEE-III operational model - need EGI equivalent)
- Security officer - official security contact point at project level
Note: This list of roles was inherited from the EGEE era and needs to be redefined within EGI
Permissions associated to roles
GOCDB roles and permissions are based on whether the considered object is owned or not. In the table below the following definitions apply:
- Owned group: a group on which the role applies (ROC, NGI, project)
- Owned site: a site on which the role applies, or belonging to an owned group
- Owned service endpoint: a service endpoint belonging to an owned site
Each role has a set of associated permissions which apply on the role's scope (site, region or project). Main permissions are summarised in the table below
|Action||A) Unregistered users||B) Registered users with no role||C) Site level users||D) Regional level users||E) Project level users|
|Add a site to an owned group||irr.||irr.||irr.||yes||irr.|
|Add a site to a non owned group||no||no||no||no||no|
|Add a service endpoint to an owned site||irr.||irr.||yes||yes||irr.|
|Add a service endpoint to a non owned site||no||no||no||no||no|
|Add a downtime to an owned service endpoint||irr.||irr.||yes||yes||irr.|
|Add downtime to a non owned service endpoint||no||no||no||no||no|
|Update information of an owned site||irr.||irr.||yes||yes||irr.|
|Update information of a non owned site||no||no||no||no||no|
|Update certification status of an owned site||irr.||irr.||no||yes||irr.|
|Update certification status of a non owned site||no||no||no||no||yes|
|Update information of a owned service endpoint||irr.||irr.||yes||yes||irr.|
|Update information of a non owned service endpoint||no||no||no||no||no|
|Update information of an owned group||irr.||irr.||irr.||yes||irr.|
|Update information of a non owned group||no||no||no||no||no|
|Update own user account details||irr.||yes||yes||yes||yes|
|Update other user's account||no||no||no||no||no|
|Update a downtime on an owned service endpoint||irr.||irr.||yes||yes||irr.|
|Update a downtime on a non owned service endpoint||no||no||no||no||no|
|Delete an owned site||irr.||irr.||no||no||no|
|Delete a non owned site||no||no||no||no||no|
|Delete an owned service endpoint||irr.||irr.||yes||yes||irr.|
|Delete a non owned service endpoint||no||no||no||no||no|
|Delete an owned group||irr.||irr.||irr.||no||irr.|
|Delete a non owned group||no||no||no||no||no|
|Delete a downtime on an owned service endpoint||irr.||irr.||yes||yes||irr.|
|Delete a downtime on a non owned service endpoint||no||no||no||no||no|
|Delete your own user account||irr.||yes||yes||yes||yes|
|Delete other user's account||no||no||no||no||no|
|Register a new user account||yes||irr.||irr.||irr.||irr.|
|Request a new role||no||yes||yes||yes||yes|
|Approve a role request on an owned site or group||irr.||irr.||yes||yes||irr.|
|Approve a role request on a non owned site or group||no||no||no||no||no|
|Reject a role request on an owned site or group||irr.||irr.||yes||yes||irr.|
|Reject a role request on a non owned site or group||no||no||no||no||no|
|Revoke an existing role on an owned object||irr.||irr.||yes||yes||irr.|
|Revoke an existing role on a non owned object||no||no||no||no||no|
|Retrieve an existing account/ change certificate DN||yes||yes||yes||yes||yes|
Requesting roles for your account
There are 2 ways to request new roles.
- By clicking on the manage role link (sidebar, user status panel)
- the first form allows you to choose the entity (site or group) on which you want to request a role
- the second form lets you choose the role you want to apply for
- By clicking on the request role link from site detail pages or group detail pages.
- displayed form lets you choose the role you want to apply for
Once made, role requests have to be validated before the role is granted to you. This part of the process is described in the next section.
Approving/revoking accounts, roles and other actions
Changing your certificate DN
If you change your certificate, it is possible that the certificate's distinguished name (DN) has also changed. This is what GOCDB uses to identify your user account.
- after having installed your new certificate
- If you enter GOCDB with your new certificate it will be as if you had no user account (as GOCDB will not know your new certificate).
- in the "user status" panel in the sidebar, click on the retrieve an old account link
- specify in the form the DN of your old certificate, and the e-mail address associated to your account
- upon validation, an e-mail will be sent to the specified address, which has to match the one registered with your account. This is to avoid identity theft. The e-mail contains a validation link
- click on the validation link or copy/paste in your browser. Once validated, changes are immediate.
If for any reason you were unable to complete these steps (e.g. mail confirmations problems) please do not register a new user account, but contact the GOCDB support helpdesk instead with your old and new certificate DNs.
Approving role and change requests
When a registered user applies for a role, the request has to be validated by someone who has the proper permissions to grant such a role. If you request a role on a given entity, any user with a valid role on that entity or above will be able to approve your request.
Example - If you request a "site administrator" role on site X, then the following users can approve your request:
- site administrators and security officers of site X
- regional operations staff, managers and deputies of the Operations Centre to which site X belongs
- GOCDB admins
Role requests you can approve are listed on the Manage roles page (accessible by clicking the Manage roles link in the user status panel in the sidebar).
In order to approve or decline role requests, simply click on the accept or deny links in front of each role request.
If a user within your scope has a role that needs to be revoked, you can do this from the user's page, where user's details are listed along with his/her current roles. To revoke a role, simply click on the view link in front of the concerned role, then on the revoke link at the top of the role's details page.
Note: This works for other users within your scope but also for yourself. However just note that if you revoke your own roles you may not have proper permissions to recover them afterwards.
A site is a grouping of grid resources collating multiple Service Endpoints (SEs). Down times are recorded on selected SEs of a site. GOCDB stores the following information about sites (non exhaustive list):
- A unique (short) site name
- An official (long) site name
- A domain name for the site
- The home web URL of the site
- A contact email address and telephone number
- Emergency e-mail for a fast response time in case of urgent problem
- Alarm e-mail is WLCG Tier1 site specific (used as part of a WLCG workflow for dealing with specific monitoring alarms)
- A security contact email address and telephone number
- The site timezone
- The site's GIIS URL
- A description of the site
- The site's latitude, longitude and location
- PRODUCTION_STATUS [GROUP] The site's intended production infrastructure, has one of the following values:
- Pre-production (PPS)
- ROC [GROUP] - The NGI or Region of the site
A site listing page shows a listing of all the sites in the database, with controls to page through the listing. The table headers can be clicked to set the ordering (ascending or descending).
Each site also has its own listing page. By clicking the link to view a site, you can see all of the site's information
- Site listing page is available from the sidebar by clicking on the Browse Sites link.
- sites belonging to a given Operations Centre are also listed from the group details pages (see below)
Adding a site
Provided you have proper permissions (check the permissions matrix in the #Permissions_associated_to_roles section), you can add a site by clicking on the Add a New Site link in the sidebar. Simply fill the form and validate.
Note: If you just registered as site admin and want your new site to be registered in GOCDB, please contact your NGI representative.
Editing site information
The editing process will show you the same form as the adding process. To edit a site, simply click the "edit" link on top of the site's details page.
Removing a site
Site deletion is not allowed in GOCDB. If a site stops operation, its certification status should be set to "closed". See the section on #Changing_Site_Certification_Status for more information
Changing Site Certification Status
For each site, GOCDB stores and shows information about its certification status. This reflects the different steps of the official SA1 site certification procedure which typically follows:
- Candidate -> Uncertified -> Certified.
The different possible certification statuses are:
- Candidate: the Resource Centre is in under registration according to the registration process described in the RC registration certification procedure. A site will have CANDIDATE status only during certification.
- Uncertified: site information has been validated by the Operations Centre and is ready to be moved to certified status (again). The certification status of a site can only be changed by a user with a higher level 'Regional' (or EGI 'Project') level role. This usually means that only regional managers/deputies/staff can update the status of a site that belongs to that region, see #Permissions_associated_to_roles.
- Certified: the Operations Centre has verified that the site has all middleware installed, passes the tests and appears stable.
- Suspended: Site does temporarily not conform to production requirements (e.g. minimum service targets - see the Resource Centre OLA, security matters) and requires Operations Centre attention. A site can be suspended for a maximum of 4 months after which it must be re-certified or closed.
- Closed: Site is definitely no longer operated by EGI and is only shown for historic reasons.
- The uncertified status would generally be an information that a site is ready to start certification procedure (again). "uncertified" can also be used as a timewise unlimited state for sites having to keep an old version of the middleware for the absolute needs of an important international VO or to flag a site coping with Operations Centre requirements but not with EGI availability/reliability thresholds.
- Suspended is always having a temporary meaning. It is used to flag a site temporarily not coping with with EGI availability/reliability thresholds or security requirements, and which should be closed or uncertified by its Operations Centre within 4 months. When being suspended, sites can express that they want to pass certification again. The suspened status is useful to EGI and to the Operations Centre themselves to flag the sites that require attention by the Operations Centre.
- The closed status should be the terminal one. Suspended is not a terminal state.
The following site state transitions are allowed:
- candidate -> uncertified
- candidate -> closed
- uncertified -> certified
- certified -> suspended
- certified -> closed (on site request)
- suspended -> uncertified
- suspended -> closed
The following transitions are explicitly forbidden:
- suspended -> certified
- candidate -> something else but uncertified and closed
- closed -> anything else
Going with the definition of the suspended status, Operations Centre managers have to regularly give their attention to all their suspended sites, so that they are processed within the given maximum time of four months. Sites being in suspended should either be set to closed or brought back in production via the uncertified status.
More information about site certification statuses can be found in SA1 certification and operation procedures documents:
- EGI Operations Procedures
- Resource Centre Decommissioning Procedure
- Production Service Decommissioning Procedure
Note: Site certification status cannot be changed by site administrators, and requires intervention of Operations Centre staff.
A service endpoint is a single entity formed by a hostname, a hosted service and a URL.
GOCDB stores the following information about service endpoints (non exhaustive list):
* The fully qualified hostname of the machine * The hosted service (see service types below) * The URL to reach the endpoint * The IP address of the machine * The machine's host certificate DN * A description of the node
As a machine can host many services, there can be many service endpoints per machine.
Example: the machine myhost.domain.org runs a CE, an UI and a UnicoreX service. This will show up in GOCDB as 3 Service Endpoints:
- myhost.domain.orgCE URL: http://myhost.domain.org/CE
- myhost.domain.orgUI URL: http://myhost.domain.org/UI
- myhost.domain.orgunicore6.UNICOREX URL: http://myhost.domain.org/UnicoreX
Manipulating service endpoints
Viewing service endpoints
There are different pages in GOCDB where service endpoints are listed:
- A full service endpoints listing page, that shows a listing of all the endpoints in the database, with controls to page through the listing. The table headers can be clicked to set the ordering.
- Site details page, where all the service endpoints belonging to this site are listed
Each endpoint also has its own listing page. By clicking the link to view a service endpoint, you can see all associated information.
- Service Endpoints listing page is available from the side menu in GOCDB4 by clicking on the Browse Service Endpoints link.
Adding Service Endpoints
There are 2 ways to add new service endpoints to GOCDB, provided you have proper permissions (check the permissions matrix in the #Permissions_associated_to_roles section):
- By clicking on the Add a New Service link in the sidebar. Simply select parent site, fill the form and validate.
- By clicking on the Add a New Service Endpoint link from a given site's details page (the link will only appear if you have proper permissions). This will lead you to the same form as above.
Editing service endpoint information
The editing process will show you the same form as the adding process. To edit a service endpoint, simply click the "edit" link on top of the endpoint's details page.
Removing a service endpoint from a site
to deactivate a service endpoint you have permissions on, simply clic on the "delete" link on top of the endpoint's details page. The interface asks for confirmation before proceeding.
Specific Service Endpoint fields and their impact
"beta" flag (t/f)
This indicates whether the service is a beta service or not (part of the staged rollout process). Beta is the equivalent at service level of the former EGEE Pre-Production Service (PPS)
"production" flag (t/f)
The SEs Production flag indicates if this service delivers a production quality service to the infrastructure it belongs to (EGI). Even if this flag is false, the service is still considered part of the EGI and so shows up in the dashboard. This is not to be confused with PRODUCTION_STATUS, which is a Site level flag that shows if the site delivers to the production, pre-production (PPS) or test infrastructure.
"monitoring" flag (t/f)
This flag is taken into account by monitoring tools. if it is set to "N" the endpoint won't be tested.
how "production" and "monitoring" are used
Production and monitoring are combined in the following way:
- All production resources have to be monitored.
- All other resources can be monitored or not following site administrators' choice.
Only test results for production+monitored services will be used for availability and reliability calculation.
A service group is an arbitrary grouping of existing service endpoints that can be distributed across different physical sites (also known as 'Virtual Sites'):
- Each service endpoint that appears in a group must already be a member of one hosting physical site (a service group cannot own its own services).
- A service group role does not extend any permissions over its child services.
- Currently, any GOCDB user can create their own service groups (everything is logged, including who created the service group).
- Service groups are typically used for monitoring a particular collection of services using the GOCDB get_service_group PI method.
- Service groups are a new feature. If you have any further use-cases or suggestions, please submit a ticket to RT.
A downtime is a period of time for which a grid resource is declared to be inoperable. Downtimes may be scheduled (e.g. for software/hardware upgrades), or unscheduled (e.g. power outages). GOCDB stores the following information about downtimes (non exhaustive list):
- The downtime classification (Scheduled or unscheduled)
- The severity of the downtime
- The date at which the downtime was added to GOCDB
- The start and end of the downtime period
- A description of the downtime
- The entities affected by the downtime
There are different pages on which downtimes are listed:
- An "archives" page, linked from the main menu, that allows to search through all downtimes
- A "recent and planned" page , linked from the main menu, that presents a search tool implemented by the EGI Operations Portal
- Site details page, where all the downtimes associated to the site are listed
- Service endpoint details page, where all the downtimes associated to the service endpoint are listed
Each downtime has its own listing page, accessible by clicking on the "view" link in downtime listing pages.
Provided you have proper permissions (check the permissions matrix in the #Permissions_associated_to_roles section), you can add a downtime by clicking on the Add a Downtime link in the sidebar.
This is done in 2 steps:
- enter downtime information
- specify the full list of impacted services in case there is more than one
- All dates have to be entered in UTC.
- downtime classification (scheduled/unscheduled) is determined automatically (see #Scheduled or unscheduled? section)
Editing downtime information
To edit a downtime, simply click the "edit" link on top of the downtime's details page.
Note there are some limitations to downtime edition, especially if it has already started or is completely finished. See #Downtime shortening and extension section for more details.
To delete a downtime, simply click the delete link on top of the downtime's details page. For integrity reasons, it is only possible to remove downtimes that have not started.
"Good practices" and further understanding
Scheduled or unscheduled?
depending on the planning of the intervention, downtimes can be:
- Scheduled: planned and agreed in advance
- Unscheduled: planned or unplanned, usually triggered by an unexpected failure or at a short term notice
EGI defines precise rules about what should be declared as scheduled or unscheduled, based on how long in advance the downtime is declared. These rules are described in https://wiki.egi.eu/wiki/MAN02#How_to_manage_an_intervention and are enforced as follows:
- All downtimes declared less than 24h in advance will be automatically classified as UNSCHEDULED
- All other downtimes will be classified as SCHEDULED
- Unscheduled downtimes can be retroactively declared up to 48h in the past.
- Although 24h in advance is enough for the downtime to be classified as "scheduled", it is good practice to declare it at least 5 working days before it starts.
WARNING or OUTAGE?
When declaring a downtime, you will be presented the choice of a "severity", which can be either WARNING or OUTAGE. Please consider the following definitions:
- WARNING means the resource is considered available, but the quality of service might be degraded. Such downtimes generate notifications, but are not taken into account by monitoring and availability calculation tools. In case of a service failure during the WARNING period an OUTAGE downtime has to be declared, cancelling the rest of the WARNING downtime. (The WARNING flag now replaces the former AT_RISK flag).
- OUTAGE means the resource is considered as unavailable. Such downtimes will be considered as "IN MAINTENANCE" by monitoring and availability calculation tools.
The whole downtime notification process is described on a document available in CERN EDMS:
Downtime shortening and extension
Limition rules to downtime extensions are enforced in GOCDB as follows:
- Once created, downtimes can be shortened but not extended
- If for any reason a downtime already declared needs to be extended, the procedure is to add another adjencent downtime, before or after.
- Any downtime can be shortened to any date which is not in the past.
- A downtime's start and end time cannot be changed once the downtime has finished
Service types include grid middleware and operational services. The naming scheme for new service types follow a reverse DNS style syntax, usually naming the technology provider followed by technology type, i.e. ‘<provider>.<type>’ (e.g. ‘unicore6.StorageFactory’). This style is consistent with GLUE2 which also defines a service type list [GLUE2 service types]. It would be preferable to rename all existing service types using the GLUE2 values, but this is potentially problematic for existing services that depend on established legacy names. Service types with the 'egi.' or 'ngi.' prefixes do not refer to scope, but instead are intended to distinguish between different functional implementations of a service (i.e. variations of a service type with different functions).
To request a new servcie type, please submit a request for a new service type (described below).
The current list consists of operational components and middleware:
Operational Components (middleware agnostic)
- Site-BDII: [Site service] This service collects and publishes site's data for the Information System. All sites MUST install one Site-BDII.
- Top-BDII: [Central service] The "top-level BDII". These collect and publish the data from site-BDIIs. Only a few instances per region are required.
- OpsTool: [Central service] generic service representing an operation tool (topology repository, dashboard, helpdesk system...)
RGMA-IC: [OBSOLETE Central service] A Registry for an R-GMA service. There will only ever be a few of these per grid.
- MyProxy: [Central service] MyProxy is part of the authentication and authorization system. Often installed by sites installing the WMS service.
- egi.APELRepository: [Central service] The central APEL repository
- egi.AccountingPortal: [Central service] The central accounting portal
- egi.GGUS: [Central service] The central GGUS
- egi.GOCDB: [Central service] The central GOCDB
- egi.MSGBroker: [Central service] The central message broker
- MSG-Broker: [Central service] A broker for the backbone messaging system.
- egi.MetricsPortal: [Central service] The central metrics portal
- egi.NetworkPortal: [Central service] The central network portal
- egi.OpsPortal: [Central service] The central operations portal
- egi.GRIDVIEW: [Central service] The central gridview portal
- egi.GSTAT: [Central service] The central GStat portal
- egi.SAM: [Central service] The central SAM monitoring
- ngi.SAM: [Regional Service] NGI-level SAM monitoring box
- vo.SAM: [Regional Service] VO-level SAM monitoring box
- site.SAM: [Regional Service] Site-level SAM monitoring box
- ngi.OpsPortal: [Regional service] NGI-level regional operations portal instance
EMI Middleware (ARC, gLite, Unicore)
- ARC-CE: [Site service] The Compute Element within the ARC middleware stack.
- SGAS: [Site service] An accounting service used by ARC.
- CE: [Site service] The LCG Compute Element. Currently the standard CE within the gLite middleware stack. Soon to be replaced by the CREAM CE.
gLite-CE: [OBSOLETE Site service] The gLite Compute Element is now obsolete and is not supported. Please avoid using this middleware service.
- CREAM-CE: [Site service] The CREAM Compute Element is the new CE within the gLite middleware stack.
- APEL: [Site service] This is a "dummy" Service Type to enable the monitoring tests for APEL accounting. All sites must have one instance of this Service Type, associated with a CE.
MON: [OBSOLETE Site service] The gLite MonBox hosts the site R-GMA services.
- UI: [User service] The User Interface. Can be installed by users but more commonly installed by a site.
- SRM: [Site service] Storage Resource Manager. Mandatory for all sites running an SRM enabled storage element.
Classic-SE: [OBSOLETE Site service] The Classic Storage Element is now obsolete and is not supported. Please avoid using this middleware service.
- Central-LFC: [Central service] An instance of the gLite file catalogue which holds entries for all files owned by a particular VO. NOTE: An LFC can be both Central and Local.
- Local-LFC: [Site service] An instance of the gLite file catalogue which holds entries for files owned by a particular VO, at your site. NOTE: An LFC can be both Central and Local.
- WMS: [Central service] gLite Workload Management Service. Acts as the broker for matching user jobs to available computing resources.
RB: [OBSOLETE Central service] The LCG Resource Broker is now obsolete and is not supported. Please avoid using this middleware service.
- VOMS: [Central service] VO Management System. Part of the authentication and authorization system. This service only needs to be installed on the request of a VO.
- LB: [Central service] gLite Logging and Bookkeeping. Usually installed by sites running a WMS. One LB service can support several WMS instances.
- AMGA: [Central service] gLite metadata catalogue. This service only needs to be installed on the request of a VO.
- FTM: [Site service] gLite File Transfer Monitor. Monitors the FTS service at a site.
- FTS: [Central service] The gLite File Transfer Service manages the transfer of files between sites. This service only needs to be installed on the request of a VO.
- VO-box: [Site service] The gLite VO box allows a VO to run their own services at a site. This service only needs to be installed on the request of a VO.
- gLite-APEL: [Site service] The gLite-APEL hosts the site Accounting client (3.2 replacement of the MonBox)
- gLExec: [Site service] A light-weight gatekeeper to authenticate and authorize credentials according to local site policy and execute commands. https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/GLExec
- emi.ARGUS: [Site service] The Argus Authorization Service renders XACML authorization decisions for distributed services, based on policies
- unicore6.Registry: [Central service] All UNICORE services register here; clients ask the registry for available services in the Grid. Normally one Registry per Grid infrastructure which collects URLs of services.
- unicore6.Gateway: [Site service] Sits in front of one or more UNICORE services as a gateway to the internet. Normally one Gateway per site.
- unicore6.TargetSystemFactory [Site service] used as an entry-point for submitting single jobs. It can create Target System Services (TSSs) and submit jobs to those TSSs.
- unicore6.StorageFactory [Site service] Creates StorageManagement instances. A user can create dynamic storage management services for own purposes with it. Often used to provide filespace during workflow execution.
- unicore6.StorageManagement [Site service] Provides an abstract filesystem-like view on a storage resource. A Storage Management Service (SMS) can be created by a Storage Factory or can be configured statically way by a config file.
- unicore6.ServiceOrchestrator [Site service] Handles dispatching of a workflow's atomic jobs, and brokering. Normally there is one per grid infrastructure.
- unicore6.WorkflowFactory [Site service] Used as an entrypoint for submitting workflow jobs. The Workflow factory is creating workflow instances and can submit workflows to them. It is the workflow submission equivalent to the Target System Factory used for single job submission.
- unicore6.UVOSAssertionQueryService [Site service] Provides data and user information via the SAML standard as needed for authorization and environment customization.
- GRAM5: [Site service] job submission service for Globus version 5.x (GRAM5).
- globus-GRIDFTP: [Site service] storage endpoint and data transfer service for the Globus middleware stack.
- globus-GSISSHD: [Site service] certificate based interactive login service for the Globus middleware stack.
- MyProxy: [Site service] MyProxy is part of the authentication and authorization system.
- globus-RLS: [Site service] The globus Replica Location Service.
QosCosGrid (QCG) Middleware
- QCG.Computing [Site service] A compute component based on the OGF Basic Execution Service (BES) with advanced reservation support.
- QCG.Notification [Site service] A notification middleware component using a brokered version of the OASIS WS-Notification standard.
- QCG.Broker [Site service] QosCosGrid resource management and brokering service.
EDGI Middleware (European Desktop Grid Initiative)
- dg.CREAM-CE CREAM gateway to Desktop Grid
- dg.ARC-CE ARC gateway to Desktop Grid
- dg.TargetSystemFactory UNICORE gateway to Desktop Grid
- org.irods.irods3 An Integrated Rule-Oriented Data System for grids.
Custom Service Types
These service types are used at some grid sites within EGI but aren't a part of the core middleware distributions (EMI, gLite, ARC, UNICORE, Globus etc).
- CUSTOM.org.squid-cache.Squid The Squid web proxy service. htp;//www.squid-cache.org. Original request: https://rt.egi.eu/rt/Ticket/Display.html?id=3482
- CUSTOM.ch.cern.frontier.FroNTier The Frontier system distributes data from central databases to many clients around the world. Used in ATLAS and CMS. http://frontier.cern.ch
- CUSTOM_SERVICE Global catch-all type for custom or proprietary services that are not described above. Important: in order to control the proliferation of custom service types, please consider submitting a request for a new service type (described below) before using CUSTOM_SERVICE.
Adding new services types
Please make a request to the EGI RT ticketing system if you would like a new service type to be registered in GOCDB. Please ensure that the ticket is submitted to the GOCDB Requirements queue in RT GOCDB RT Requirements Queue Tickets
- If a site or service endpoint is marked as being visible to EGI then they will be exposed to the central operational tools. For example, marking a site as being visible to EGI will mean that it can be monitored centrally and it will appear in the central operations portal.
- Un-ticking this box makes the selected object invisible to EGI; it will be hidden from the central operation tools (it will not show in the central dashboard and it will not be monitored centrally). This can be useful if you wish to hide certain parts of your infrastructure from EGI but still have the information stored and accessed from the same GOCDB instance.
- A use-case for non-EGI sites/SEs is to hide those entities from central EGI tools, but to include those sites/services for use by regional versions of the operational tools (such as regional monitoring). To enable regional monitoring of non-EGI sites/SEs using SAM see [original change request] and [Add support for GOCDB scope]
- Note that exposing a site / service endpoint as EGI does not override the production status or certification status fields. For example if a site isn't marked as production it won't be monitored centrally even if it's marked as visible to EGI.
A group is a grouping of sites in GOCDB. GOCDB stores the following information about groups:
- A group name
- A description of the group
- A group type (NGI, Country, Infrastructure...)
- An e-mail contact when relevant
Viewing Groups and Group information
The main page listing groups actually shows NGIs/ROCs, and is available from
- List of NGIs/ROCs and associated contacts, linked from the main menu
Groups are also listed from site details pages (all groups the site belongs to). Because groups are generic entities in GOCDB4, there are many logical notions that are presented in this way: NGIs, Countries, Production Infrastructure... pretty much everything that groups sites together is defined as a group.
Each group has its own listing page, accessible by clicking on the "view" link in group listing pages. A group details page shows users with a role on that group, as well as member sites and associated contacts and roles.
Adding groups is not possible through the Input System web interface. If you want to start the registration process of a new NGI, please follow the procedure described on:
Integration of the new group in GOCDB is part of the procedure but has to be done by GOCDB admins.
To edit a group, simply click on the "edit" link at the top of the group's details page
This operation is not allowed
How to and FAQ
What is so different between GOCDB3 and GOCDB4?
GOCDB3 and GOCDB4 are two animals with a similar shell but very different guts... you might want to browse the GOCDB4 architecture documentation to know more about what makes GOCDB4 special.
I get an "error 12227" message when accessing GOC portal with Mozilla/Firefox
This happens when no certificate has been uploaded to your browser. Refer to the "Access to GOCDB" section for more information about GOCDB and X509 certificates.
I am responsible for a site that has recently entered the EGI infrastructure. How do I register it?
Only registered users with an approved role on an NGI can add a new site. If you are the site administrator, the first thing to do is to contact your NGI staff and ask them to add the site for you. Then, register to GOCDB (see the user account section) and ask for a site admin role for your site (see the requesting a role section). Once your role approved, you will be able to edit and change your site information.
Why can't I declare downtimes for my whole site as I used to do in GOCDB3?
For data clarity reasons, it has been decided long ago to only link downtimes to services, thus avoiding the complication of having to check both site and service downtimes to determine whether a service is up or not. The way to declare a downtime for your site is to select all the services of the site in one go when inserting the downtime.
How do I extend a declared schedule downtime?
Because of EGI policies it is not possible to extend a downtime. Recommended good practice for any downtime extension is to declare a new unscheduled downtime, starting just when the frst one finishes. please refere to the downtimes section of this documentation for more information, especially the "downtime extension" paragraph.
I have declared a downtime "at risk", and it turns out to be an outage. How can I declare this properly?
If you have declared the downtime as being at risk and an outage actually happens half way through, you need to update GOCDB to reflect the fact that your site is now down. There is currently no way of doing this by updating the downtime on the fly without having the system considering the whole downtime as being an outage. The best way to proceed is:
- Modify end date of your "at risk" downtime, so that it ends in a few minutes
- Enter a new "outage" downtime, starting when the other ends
How do I switch monitoring on/off for my nodes?
Monitoring status in GOCDB cannot always be switched off. If a node is declared as delivering a production service, rules apply and the node has to be monitored. If you are running a test node and want to switch monitoring off, set both "monitoring" and "production" to "N".
Why nobody has approved my role request yet?
Someone has to approve any request you make, in order to ensure nobody is trying to get inappropriate roles. If yours is not getting approved, this can either be because your request was not legitimate, or most likely because the people that are supposed to do it forgot about it. Please refer to the Roles permissions definitions section of this documentation to determine who should validate your role, and try to get in touch with them. If you are requesting a site admin role, they are likely to be your fellow site admins or your NGI operators.
I am not an EGI user but need access to GOCDB backend to retrieve information for my project. What can I do?
Accessing GOCDB backend through another way than the GOC portal web interface is out of the scope of this documentation. please refer to the technical documentation instead, which is available from GOCDB Documentation Index.
Queries, contact and support
Before you make any request, check this is not already integrated to our development plans. Any suggestion, new feature or improvement request should be submitted to our Savannah support tracker. Suggestions will be discussed within GOCDB developers, the OTAG, EGI Inspire-JRA1, or any political body involved before inclusion into development plans. These bodies reserve the right to decline unsuitable requests.
- check GOCDB Documentation Index for up-to-date development plans
- Access GOCDB Savannah support tracker
Report a bug
First, check known bugs to see if this has not already been reported. If not, please create a new entry in our Savannah bug tracker, trying to be as precise and concise as possible.
Get some support
If you can't find what you are looking for in the documentation, as well as for all other enquiries including general questions, temporary problems reports or support requests, you can contact us using the mail below
- Contact GOCDB admins at gocdb-admins_at_mailtalk.ac.uk