Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

KEDB

From EGIWiki
Revision as of 13:03, 10 February 2017 by Spinoso (talk | contribs)
Jump to navigation Jump to search


This page provides a central database for Known Errors, namely identified problems for which an underlying cause has been identified already and a workaround is available. Known errors are shared on EGI wiki for the following reasons:

  • known errors are tracked here for use by HelpDesk team, espacially 1st and 2nd line support, so that known issues can be referenced on new GGUS tickets reporting correlated incidents
  • the HelpDesk team can suggest new known errors and add them to the shared KEDB and make use of them in case of shifts
  • users, VO members, RC/OC operators can be referenced with known errors a slong as they are in use
  • workarounds can be referenced/reported together with each known error (the known error will be included in this page even if no workarounds are available yet)
  • an ID is provided in order to identify easily the known error
  • a quick reference to an incident is always associated to a known error, in order to switch to a concrete example of incident related to the known err

This page can host also problems who root cause is known, but no workaround is yet available, in order to proactively provide a reference to the EGI HelpDesk.

Known errors and corresponding workarounds are also provided:

  • by Technology Providers in the Release Notes of their products,
  • by service providers that are part of EGI in the documentation provided for their services

For these cases, the references are not provided in the Central database for Known Errors and no other central source of information, as aligning the original source and the central replication of information would lead to synchronisation issues and useless information maintenance overload. Instead, references to direct sources are provided in the Product Documentation Guidepost.

From time to time Known Errors are moved below in the Archived Known Errors section as soon as they are not affecting anymore the infrastructure.

Updating the KEDB:

Please use the following template (just copy/paste): 

== [$CREATION-DATE-(YYYY/MM/DD)] $TITLE (SOLVED) ==
*'''Services affected:''' 
*'''Entities impacted:''' 
*'''Description:''' 
*'''References:''' 
*'''Mitigations/Workarounds:''' 
*'''Resolved:'''


Known Error Data Base

[2017-02-10] apt returns "Unable to find expected entry 'main/binary-i386/Packages'on CMD-OS for Trusty

  • Services affected: CMD-OS 1.0.0 for Ubuntu Trusty
  • Entities impacted: Resource Centres using CMD-OS (OpenStack based cloud sites)
  • Description: sources.list distributed with cmd-os-release makes apt default to i386 instead of amd64, preventing from fetching the correct repositories; as a consequence apt cannot fetch Ubuntu Trusty CMD-OS repository and returns "Unable to find expected entry 'main/binary-i386/Packages' in Release file (Wrong sources.list entry or malformed file)"
  • References: Email reported to UMD team list
  • Mitigations/Workarounds: Add [arch=amd64] manually to repo line in sources.list:
 $ cat CMD-OS-1-base.list

    # CMD-OS-1-base

    deb [arch=amd64]
    [http://repository.egi.eu/sw/production/cmd-os/1/ubuntu/ http://repository.egi.eu/sw/<wbr></wbr>production/cmd-os/1/ubuntu/] trusty main
  • Resolved: Fix in progress (new cmd-os-release)

[2016-12-13] Services using JGlobus fail with RFC proxies from certificates from some CAs (SOLVED)

  • Services affected: dCache < v2.14, BeStMan
  • Entities impacted:
  • Description: Services using JGlobus fail with RFC proxies having Non-Repudiation key usage flag set, e.g. those created by usual voms-proxy-init from Grid Canada certificate
  • References: https://ggus.eu/?mode=ticket_info&ticket_id=124650
  • Mitigations/Workarounds: two stage proxy (plain RFC proxy, then voms-proxy-init -noregen) works
  • Resolved: dCache>=2.14, unknown for BeStMan

[2016-10-10] canL upgrade of UMD 3.14.4 and UMD 4.2.1 can break proxy renewal on CREAM (SOLVED)

[2016-09-06] clock skew on client FedCloud UI causes authentication problems on well-working sites (SOLVED)

  • Services affected: FedCloud UI https://wiki.egi.eu/wiki/HOWTO11
  • Entities impacted: All users using FedCloud command line tools https://wiki.egi.eu/wiki/HOWTO11
  • Description: the problems are observed when (re)using a VM used as UI to access the FedCloud resources; restarting a VM from a snapshot/suspension can very easily bring to unsynced CRL and clock skew on the VM
  • References: This problem was recurring:

https://ggus.eu/index.php?mode=ticket_info&ticket_id=119839 https://ggus.eu/index.php?mode=ticket_info&ticket_id=120343 https://ggus.eu/index.php?mode=ticket_info&ticket_id=123580 https://ggus.eu/index.php?mode=ticket_info&ticket_id=125530

As a workaround, run fetch-crl at start time and every 6 hours and install and configure ntp to avoid clock skews

  • Resolved: Fetch CRLs is done at the moment of installation. fetch-crl package includes a cron for updating them. In any case the UI already has this to run on boot. For clock-skew, the image needed ntpd, it has been added to the image usually users use to start the VM. Eventually all running VMs will have fetch-crl and ntp correctly configured.

[2016-09-06] clock skew on client FedCloud UI causes authentication problems on well-working sites (SOLVED)

  • Services affected: FedCloud UI https://wiki.egi.eu/wiki/HOWTO11
  • Entities impacted: All users using FedCloud command line tools https://wiki.egi.eu/wiki/HOWTO11
  • Description: the problems are observed when (re)using a VM used as UI to access the FedCloud resources; restarting a VM from a snapshot/suspension can very easily bring to:

- unsynced CRL - clock skew on the VM

https://ggus.eu/index.php?mode=ticket_info&ticket_id=120343 https://ggus.eu/index.php?mode=ticket_info&ticket_id=123580 https://ggus.eu/index.php?mode=ticket_info&ticket_id=125530

As a workaround, run fetch-crl at start time and every 6 hours and install and configure ntp to avoid clock skews

  • Resolved: Fetch CRLs is done at the moment of installation. fetch-crl package includes a cron for updating them. In any case the UI already has this to run on boot. For clock-skew, the image needed ntpd, it has been added to the image usually users use to start the VM. Eventually all running VMs will have fetch-crl and ntp correctly configured.

Archived Known Errors

Retrieved from "https://wiki.egi.eu/w/index.php?title=KEDB&oldid=93129"