EGI QC Testing

From EGIWiki
Jump to: navigation, search

This page describes testing procedures for the Quality Criteria Release 6.



The product must be installable from the UMD repository (+ epel if using RH based distros) with no extra packages coming from other sources. All packages must be signed.

Ideally a meta-package fetches all dependencies. Installing should be done with the regular package management tools of the distro (rh based):

yum install <meta-package>

or (debian based):

apt-get install <meta-package>

The packages should not create any files outside the regular OS locations: use of /opt is discouraged, if files are created there, the QC passes, but as WARNING, and a comment should be included in the report (except for yaim packages)


SHA-2 certificates

If you do not have valid SHA-2 certificates, you can get one using a provider like CILogon, using their (unaccredited) OpenID provider like Google

(instructions from D. Groep)

  1. Go to
  2. Select "Google" from the list of IdPs.
  3. After signing in to Google and typing in a password, you can download a pkcs#12 file with your new certificate and private key.
  4. To get the conventional usercert.pem and userkey.pem, use openssl:
openssl pkcs12 -in myfile.p12 -info -out usercert.pem -nokeys
openssl pkcs12 -in myfile.p12 -info -out userkey.pem -nocerts
chmod 0600 userkey.pem

Services to test need to have the OpenID CA just like the other IGTF CAs, which is available from the experimental repository. A RPM package is also provided.

SA2 VM images also include SHA-2 certificates into /etc/grid-security directory (hostcert-SHA2.pem and hostkey-SHA2.pem). These certificates could replace /etc/grid-security/hostcert.pem and /etc/grid-security/hostkey.pem to check SHA-2 service support. First of all backup the old certificates:

cp /etc/grid-security/hostcert.pem /etc/grid-security/hostcert.pem.orig
cp /etc/grid-security/hostkey.pem /etc/grid-security/hostkey.pem.orig

And replace them by the new SHA2 certificates:

cp /etc/grid-security/hostcert-SHA2.pem /etc/grid-security/hostcert.pem
cp /etc/grid-security/hostkey-SHA2.pem /etc/grid-security/hostkey.pem

An then reconfigure/restart the service.

RFC proxies

RFC proxies can be created by using the -rfc option in voms-proxy-init:

$ voms-proxy-init -rfc --voms dteam
Your identity: /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
Creating temporary proxy .......................................... Done
Contacting [/C=GR/O=HellasGrid/] "dteam" Done
Creating proxy ...................................... Done
Your proxy is valid until Thu Aug  2 01:01:26 2012

You can check if the proxy has RFC format with voms-proxy-info:

$ voms-proxy-info --all
subject   : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo/CN=3300543
issuer    : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
identity  : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
type      : RFC compliant proxy
strength  : 1024 bits
path      : /nfs4/home/local/enol/.x509up_u7056
timeleft  : 11:59:52
=== VO dteam extension information ===
VO        : dteam
subject   : /DC=es/DC=irisgrid/O=ifca/CN=Enol-Fernandez-delCastillo
issuer    : /C=GR/O=HellasGrid/
attribute : /dteam/Role=NULL/Capability=NULL
timeleft  : 11:59:51
uri       :

ARGUS integration

This criterion needs to be checked for every product that requires some sort of authorization. You will need a working ARGUS instance where the policies are defined. The verification testbed includes one ARGUS instance at that can be used for this test.

Configure the service with the following values for testing a policy where any user from ops, dteam or VOs is allowed to perform any action (".*"):

Argus endpoint

For testing banning policies, there is another resource that lets users from and ops, but bans dteam users. This resource can be configured with:

Argus endpoint

If you don't belong to those VOs or want to test other banning policies (e.g. on your user DN), you need to contact the verification team for adding new rules into the ARGUS instance.

World writable files

An easy way to find world-writable files is using the find command:

find / -type f -perm -002 -exec ls -l {} \;

For finding world-writable files in the packages contents:

rpm -qalv | egrep "^[-d]([-r][-w][-xs]){2}[-r]w"

Passwords in world readable files

There is no generic way to test this criterion. Verifier should check permissions on any known configuration files of the product and assure that if they contain any sensitive information (passwords), they are not world readable.

Information Model

GlueSchema 1.3 & GlueSchema 2.0

Use GlueValidator for testing the validity of both Glue1.3 and Glue2. More info about GLUEValidator is available here

GLUEValidator UMD3 installation:

yum install glue-validator

Testing the compliance:

glue-validator -H <host> -p <port> -b o=grid -g glue1 -s general -v 3
glue-validator -H <host> -p <port> -b o=glue -g glue2 -s general -v 3
glue-validator -H <host> -p <port> -b o=glue -g egi-glue2 -v 3

Warnings may be allowed specially for certain value ranges (that are not realistic in verification), e.g.:

I086 Description: Total capacity size less than 1000 GB
I086 Affected DN:
I086 Affected attribute: GLUE2StorageServiceCapacityTotalSize
I086 Published value: 0

A complete list of glue-validator Error Codes is available here.

Middleware Version

The basic query would be something like:

ldapsearch -x -h <hostname> -p 2170 -b GLUE2GroupID=resource,o=glue objectclass=GLUE2Endpoint

That should return one or more Endpoint objects, containing attributes like

GLUE2EndpointImplementationVersion: 2.7.0
GLUE2EntityOtherInfo: MiddlewareVersion=2.5.1-1
Personal tools