logo operations poral

logo egi


Operations Portal is an EGI service provided by CCIN2P3,
co-funded by EGI.eu and EGI-Engage



Release Version : 4.1 - September 13th

For any contact, use this section: Contact Us



The Operations Portal is a central portal for the EGI operations management that offers a different capabilities, such as the broadcast tool, VO management facilities and various of dashboards (Security, VO and Operations) to facilitate infrastructure oversight.

Latest news

The problem with the Apel Pub and Sync tests has been fixed and the tests are now reporting again.

The Accounting Portal is also now updating again.

Apologies for the inconvenience.
Hello,

 I would like to announce the DPM workshop 2016, which will
take place on the 23th and 24th of November 2016 at LPNHE(Paris),
with the kind support of the French DPM community.

https://indico.cern.ch/event/559673/

 You are invited to participate to the workshop and to the discussions, where we cover news and updates on the status of DPM:
releases, distributions, development directions, involvement of
the DPM collaboration, new components, new setup, old
components revisited, performance evaluations and experiences
in general.

 The workshop will cover news and updates on experiences and
best practices, user reports, administration tools,
federations, data access and community talks.

 The agenda is almost complete and the registration is now open.

 Please get in touch if you would like to contribute.
If you have ideas or suggestions for specific topics and contributions,
then please let us know, we are very interested in your opinions.

 We hope to see you all there. Please feel free to forward this announcement
to any potentially interested person.

Cheers
Fabrizio Furano
furano@cern.ch
Dear all,

after the changes of the EGI monitoring tools, all the monitoring tools are centralized and managed by EGI and the NGI SAM/Nagios tools are no longer considered and supported by EGI.

For these reasons we are starting the decommissioning of mon-it.cnaf.infn.it.

Decommissioning timeline:

21 Sept 2016 Ticket GGUS IGI-BOLOGNA --> NGI_IT
21 Sept 2016 Broadcast with decommissioning timeline
5 Oct 2016 Start downtime from broadcast +15 days for 15 days
19 Oct 2016 End downtime, prod=N and mon=N on GOCDB, remove from BDII
19 Gen 2017 90 days of log retention
19 Gen 2017 Remove mon-it from GOCDB
19 Gen 2017 Close ticket

All the best 
Diego for NGI_IT
There is a temporary problem with the APEL Pub and Sync tests. They are not reflecting recent data received by the APEL repository. Please rest assured  that data  sent by sites is still being successfully received by APEL. It is the tests that are at fault, not your accounting publishing. 


The production accounting portal also looks as if it is not receiving the latest data. If you urgently wish to check on your sites publishing, take a look at the new portal which is close to being released.  It gets its data by a different route which is still working. https://accounting-next.egi.eu/
Dear *,
we are decommissioning two ARC-CEs connected to our PBS/torque Grid farm:

  grid-arc0.desy.de
  grid-arc4.desy.de

Please refer to the info system for information of available CEs for your VO.

Best regards,
Andreas Gellrich for the Grid team at DESY
The storage element cmsse02.na.infn.it at INFN-NAPOLI-CMS site is going to be decommissioned. 
VOs and users who have their data on the storage element are asked to move them elsewhere before Sep.27.

>>> More news <<<

Due to an ongoing service outage on the ~okeanos cloud infrastructure since Friday night, we have disabled the hourly availability and reliability computations. 

This outage does not affect the ARGO monitoring instances or the monthly A/R computations. As soon as the services are back online, A/R is going to be computed for the whole period retrospectively.
The DPM SE se01.isabella.grnet.gr (site: HG-01-GRNET) will be decommissioned on 30 Sep 2016.

Kyriakos Gkinis
HG-01-GRNET
Dear site managers, Starting from the 3rd November 2015 the INFN CA is using a new root certificate. Unfortunately this change, in particular the fact that there is a *change of the CA DN*, creates issues to the VOs managed through VOMS servers that acquired new server certificates released recently by the INFN CA.

At this moment we have a new server certificate for the vomsIGI-NA.unina.it, that is supporting the following VOs:

    calet.org
    d4science.org
    drihm.eu
    gerda.mpg.de
    icarus-exp.org
    net.egi.eu
    vo.ingv.it

Therefore the configuration of grid services (SEs, CEs, UIs, WNs, ...) must be updated to ensure the correct function with the VO proxy certificates. We would like to kindly ask you to update the LSC files (in /etc/grid-security/vomsdir/"vo_name"/) to match the configuration described here: https://vomsigi-na.unina.it:8443/voms/"vo_name"/configuration/configuration.action
Please replace "vo_name" with the actual VO name from the ones listed above You get this email because your site supports at least one VO hosted on this server or you are a VO-manager of one of the interested VOs (just for information). Bellow there are some details that can help you.

The steps to be followed in order to update the .lsc file are the following:

a. For services whose configuration is done using *YAIM*:

    Update the /"path_to"/"your_site_info.def" or /"path_to"/vo.d/"vo_name_file" to contain the new CA_DN, for the respective VOs. For example, for the VO drihm.eu, there should be present the following lines:

        SW_DIR=$VO_SW_DIR/drihm.eu DEFAULT_SE=$SE_HOST STORAGE_DIR=$CLASSIC_STORAGE_DIR/drihm.eu
        VOMS_SERVERS="'vomss://vomsmania.cnaf.infn.it:8443/voms/drihm.eu?/drihm.eu' ' vomss://vomsigi-na.unina.it:8443/voms/drihm.eu?/drihm.eu' 'drihm.eu vomsmania.cnaf.infn.it 15005 /C=IT/O=INFN/OU=Host/L=CNAF/CN=vomsmania.cnaf.infn.it drihm.eu'"
        VOMSES="'drihm.eu vomsmania.cnaf.infn.it 15005 /C=IT/O=INFN/OU=Host/L=CNAF/CN=vomsmania.cnaf.infn.it drihm.eu' 'drihm.eu vomsIGI-NA.unina.it 15005 /C=IT/O=INFN/OU=Host/L=Federico II/CN=vomsIGI-NA.unina.it drihm.eu'"
        VOMS_CA_DN="'/C=IT/O=INFN/CN=INFN Certification Authority' '/C=IT/O=INFN/CN=INFN Certification Authority'"

    Reconfigure the node by using only the config_vomsdir function:

        # /opt/glite/yaim/bin/yaim -d 6 -r -s /"path_to"/"your_site_info.def" -f config_vomsdir 

    Check that the resulted .lsc file is correct

        # cat /etc/grid-security/vomsdir/drihm.eu/vomsIGI-NA.unina.it.lsc
        /C=IT/O=INFN/OU=Host/L=Federico II/CN=vomsIGI-NA.unina.it
        /C=IT/O=INFN/CN=INFN Certification Authority


b. For services whose configuration is *NOT done through YAIM*, please update your configuration tools, if any, to correctly set the content of the .lsc file for the respective VOs and the VOMS server indicated, like in the example:

        # cat /etc/grid-security/vomsdir/drihm.eu/vomsIGI-NA.unina.it.lsc
        /C=IT/O=INFN/OU=Host/L=Federico II/CN=vomsIGI-NA.unina.it
        /C=IT/O=INFN/CN=INFN Certification Authority


All the Best,
SCoPE Admin
Dear site managers, Starting from the 3rd November 2015 the INFN CA is using a new root certificate. Unfortunately this change, in particular the fact that there is a *change of the CA DN*, creates issues to the VOs managed through VOMS servers that acquired new server certificates released recently by the INFN CA.

At this moment we have a new server certificate for the vomsIGI-NA.unina.it, that is supporting the following VOs:
    * calet.org
    * d4science.org
    * drihm.eu
    * gerda.mpg.de
    * icarus-exp.org
    * net.egi.eu
    * vo.ingv.it
Therefore the configuration of grid services (SEs, CEs, UIs, WNs, ...) must be updated to ensure the correct function with the VO proxy certificates. We would like to kindly ask you to update the LSC files (in /etc/grid-security/vomsdir/"vo_name"/) to match the configuration described here: https://vomsigi-na.unina.it:8443/voms/"vo_name"/configuration/configuration.action
Please replace "vo_name" with the actual VO name from the ones listed above You get this email because your site supports at least one VO hosted on this server or you are a VO-manager of one of the interested VOs (just for information). Bellow there are some details that can help you.

The steps to be followed in order to update the .lsc file are the following:

a. For services whose configuration is done using *YAIM*:

    - Update the /"path_to"/"your_site_info.def" or /"path_to"/vo.d/"vo_name_file" to contain the new CA_DN, for the respective VOs. For example, for the VO drihm.eu, there should be present the following lines: 
        SW_DIR=$VO_SW_DIR/drihm.eu DEFAULT_SE=$SE_HOST STORAGE_DIR=$CLASSIC_STORAGE_DIR/drihm.eu
        VOMS_SERVERS="'vomss://vomsmania.cnaf.infn.it:8443/voms/drihm.eu?/drihm.eu' ' vomss://vomsigi-na.unina.it:8443/voms/drihm.eu?/drihm.eu' 'drihm.eu vomsmania.cnaf.infn.it 15005 /C=IT/O=INFN/OU=Host/L=CNAF/CN=vomsmania.cnaf.infn.it drihm.eu'"
        VOMSES="'drihm.eu vomsmania.cnaf.infn.it 15005 /C=IT/O=INFN/OU=Host/L=CNAF/CN=vomsmania.cnaf.infn.it drihm.eu' 'drihm.eu vomsIGI-NA.unina.it 15005 /C=IT/O=INFN/OU=Host/L=Federico II/CN=vomsIGI-NA.unina.it drihm.eu'"
        VOMS_CA_DN="'/C=IT/O=INFN/CN=INFN Certification Authority' '/C=IT/O=INFN/CN=INFN Certification Authority'" 

    - Reconfigure the node by using only the config_vomsdir function:

        # /opt/glite/yaim/bin/yaim -d 6 -r -s /"path_to"/"your_site_info.def" -f config_vomsdir 

    - Check that the resulted .lsc file is correct 

        # cat /etc/grid-security/vomsdir/drihm.eu/vomsIGI-NA.unina.it.lsc
        /C=IT/O=INFN/OU=Host/L=Federico II/CN=vomsIGI-NA.unina.it
        /C=IT/O=INFN/CN=INFN Certification Authority

b. For services whose configuration is *NOT done through YAIM*, please update your configuration tools, if any, to correctly set the content of the .lsc file for the respective VOs and the VOMS server indicated, like in the example:

        # cat /etc/grid-security/vomsdir/drihm.eu/vomsIGI-NA.unina.it.lsc
        /C=IT/O=INFN/OU=Host/L=Federico II/CN=vomsIGI-NA.unina.it
        /C=IT/O=INFN/CN=INFN Certification Authority

All the Best,
SCoPE Admin
Hi,
we have an hardware problem on the Storage part of the our SE prod-se-02.pd.infn.it 

We saw the are old data inside the Storage element, and we suggest to do not take the data if it not necessary.

The data has been accessed by SE interface, but may be some error could be thrown when you try to retrieve the data.

If the data is very important we could try to extract them from a copy we have and provide to give the data to end users.

If you have a replica please do not try to retrieve data. 

The SE will be put out of production on 20th of October. 

Cheers
Sergio
Hi,
we have an hardware problem on the Storage part of the our SE prod-se-02.pd.infn.it
We saw the are old data inside the Storage element, and we suggest to do not give the data if it not necessary.

The data has been accessed by SE interface, but may be some error could be thrown when you try to give data.

If the data is very important we could try to extract them from a copy we have and provide to give the data to end users.  If you have a replica please do not try to retrieve data.

The SE will be put out of production on 20th of October.

Cheers
Sergio
Starting from the 3rd November 2015 the INFN CA is using a new root certificate.
Unfortunately this change, in particular the fact that there is a *change of the CA DN*, creates issues to the VOs managed through VOMS servers that acquired new server certificates released recently by the INFN CA.
At this moment we have a new server certificate for the voms2.cnaf.infn.it, that is supporting the following VOs:

- ams02.cern.ch 
- comput-er.it 
- enmr.eu 
- euchina 
- euindia 
- eumed 
- glast.org 
- ipv6.hepix.org 
- pacs.infn.it 
- superbvo.org acive
- vo.dampe.org
- vo.padme.org

Therefore the configuration of grid services (SEs, CEs, UIs, WNs, ...) must be updated to ensure the correct function with the VO proxy certificates.
We would like to kindly ask you to update the LSC files (in /etc/grid-security/vomsdir/"vo_name"/ to match the configuration described here:
https://voms2.cnaf.infn.it:8443/voms/"vo_name"/configuration/configuration.action
Please replace "vo_name" with the actual VO name from the ones listed above

You get this email because your site supports at least one VO hosted on this server or you are a VO-manager of one of the interested VOs (just for information). 

Bellow there are some details that can help you:
The steps to be followed in order to update the .lsc file are the following:
a. For services whose configuration is done using *YAIM*:
- Update the /"path_to"/"your_site_info.def" or /"path_to"/vo.d/"vo_name_file" to contain the new CA_DN, for the respective VOs.
For example, for the VO calet.org, there should be present the following lines:
SW_DIR=$VO_SW_DIR/glast.org
DEFAULT_SE=$SE_HOST
STORAGE_DIR=$CLASSIC_STORAGE_DIR/glast.org
VOMS_SERVERS="'vomss://voms2.cnaf.infn.it:8443/voms/glast.org?/glast.org 'vomss://voms-02.pd.infn.it:8443/voms/glast.org?/glast.org'"
VOMSES="'glast.org voms2.cnaf.infn.it 15018 /C=IT/O=INFN/OU=Host/L=CNAF/CN=voms2.cnaf.infn.it glast.org' 'glast.org voms-02.pd.infn.it 15018 /C=IT/O=INFN/OU=Host/L=Padova/CN=voms-02.pd.infn.it glast.org'"
VOMS_CA_DN="'/C=IT/O=INFN/CN=INFN Certification Authority' '/C=IT/O=INFN/CN=INFN Certification Authority'"

- Reconfigure the node by using only the config_vomsdir function:
# /opt/glite/yaim/bin/yaim -d 6 -r -s /"path_to"/"your_site_info.def" -f config_vomsdir 

- Check that the resulted .lsc file is correct
# cat /etc/grid-security/vomsdir/glast.org/voms2.cnaf.infn.it.lsc
/C=IT/O=INFN/OU=Host/L=CNAF/CN=voms2.cnaf.infn.it
/C=IT/O=INFN/CN=INFN Certification Authority

b. For services whose configuration is *NOT done through YAIM*, please update your configuration tools, if any, to correctly set the content of the .lsc file for the respective VOs and the VOMS server indicated, like in the example:
# cat /etc/grid-security/vomsdir/calet.org/voms2.cnaf.infn.it.lsc
/C=IT/O=INFN/OU=Host/L=CNAF/CN=voms2.cnaf.infn.it
/C=IT/O=INFN/CN=INFN Certification Authority

All the Best,
Diego Michelotto
for the NGI_IT
Dear all, 

This is to inform you that the certification infrastructure will be decommissioned by 05/10/2016. The Catch All Certification Services include the following hosts:

Top Level BDII (cert-bdii.hellasgrid.gr)
WMS/LB (cert-wms.hellasgrid.gr)
Site Certification Portal (http://site-certification.egi.eu/)

The downtime will start at 13/09/2016.

With regards,
Pavlos Daoglou
The gLite services CREAM, LFC, SE and WMS of site SCAI will be decommissioned in Octobre. Starting from 15th of September, the services will go into downtime until being disabled and removed on Oct 5th in case no further extension is required by users. 
Please contact us in case you need any assistance.