Known Issues

VOMS membership checker tasks fails with NullPointerException for VOs upgraded from gLite 3.1 VOMS

Affected versions: VOMS Admin 2.5.3. 2.5.5, 2.6.1, 2.7.0

Related JIRA issue: http://issues.cnaf.infn.it/browse/VOMS-76

Is solution available: solution available in VOMS Admin version 2.7.1 (to be released)

Workaround:

The following command fixes the database so that the exception is not raised and the AUP checking mechanism works as expected:

update usr set suspended = false where suspended is NULL;

VOMS Admin Sign AUP default grace period is too short

Affected versions: VOMS Admin 2.5.3, 2.5.5 and 2.6.1

Related savannah bug: https://savannah.cern.ch/bugs/index.php?93370

Is solution available: solution available in VOMS Admin version 2.7.0 that will be released in EMI 1 Update 17 on May, 17th, 2012 and in EMI 2.

Workaround:

The default grace period can be extended by setting the following option for a given VO:

voms.aup.sign_aup_task_lifetime = 7

The above setting is currently NOT supported by the VOMS YAIM module (support for it will be added in 2.7.0 version). An easy way to set this variable and not having it lost at each YAIM reconfiguration is by changing the voms.service.properties.template file found in

/usr/share/voms-admin/templates (VOMS Admin 2.6.1)

or

$GLITE_LOCATION/share/voms-admin/templates (VOMS Admin 2.5.x)

And then running a YAIM configuration for VOMS.

If YAIM is not used the setting mentioned above can be put into

/etc/voms-admin/VO_NAME/voms.service.properties (VOMS Admin 2.6.1)

or

$GLITE_LOCATION_VAR/etc/voms-admin/VO_NAME/voms.service.properties (VOMS Admin 2.5.x)

VOMS Admin does not send warning message before suspending users due to membership expiration

Affected versions: VOMS Admin 2.5.3, 2.5.5 and 2.6.1

Related savannah bug: https://savannah.cern.ch/bugs/?93255

Is solution available: solution available in VOMS Admin version 2.7.0 that will be released in EMI 1 Update 17 on May, 17th, 2012 and in EMI 2.

The bug prevents the sending of e-mail warnings to the VO manager before the user membership expiration. The lack of this e-mail notification compromises the capability to renew membership in due time, especially in case of large-scale VOs, and when for many users membership expires at the same time. This is the case for all VOs whose VOMS server was upgraded from gLite 3.1 to gLite 3.2 as during migration the user membership date is reset to the same time.

How to understand which users are about to expire

VOMS Admin version 2.5.3, 2.5.5 and 2.6.1 do not provide an easy way of finding out which users are about to expire. For VOs with limited numbers of users one could query the VOMS Admin web application, but for large VOs this approach is unbearable.

An easy way of knowing which users are about to expire in the next 30 days is by running a command similar to the one below on the VOMS MySQL database for a given VO (change the hostname and VO name accordingly to your VOMS installation):

select 
CONCAT('https://cert-voms-01.cnaf.infn.it:8443/voms/emi.saml-test/user/load.action?userId=',userid) as user, 
email_address, 
end_time as expiration_date 
from usr where end_time >= NOW() and end_time < (NOW() + INTERVAL 30 DAY);

+-------------------------------------------------------------------------------------+------------------------------+---------------------+
| user                                                                                | email_address                | expiration_date     |
+-------------------------------------------------------------------------------------+------------------------------+---------------------+
| https://cert-voms-01.cnaf.infn.it:8443/voms/emi.saml-test/user/load.action?userId=1 | andrea.ceccanti@cnaf.infn.it | 2012-04-25 00:00:00 | 
| https://cert-voms-01.cnaf.infn.it:8443/voms/emi.saml-test/user/load.action?userId=2 | andrea.ceccanti@cnaf.infn.it | 2012-04-18 00:00:00 | 
| https://cert-voms-01.cnaf.infn.it:8443/voms/emi.saml-test/user/load.action?userId=3 | andrea.ceccanti@cnaf.infn.it | 2012-04-18 00:00:00 | 
| https://cert-voms-01.cnaf.infn.it:8443/voms/emi.saml-test/user/load.action?userId=4 | andrea.ceccanti@cnaf.infn.it | 2012-04-18 00:00:00 | 
| https://cert-voms-01.cnaf.infn.it:8443/voms/emi.saml-test/user/load.action?userId=5 | andrea.ceccanti@cnaf.infn.it | 2012-04-18 00:00:00 | 
+-------------------------------------------------------------------------------------+------------------------------+---------------------+

How to extend membership for a large number of users that aren't yet expired or suspended

The following command can be used to extend membership to Sept. 30th, 2012 for large number of users that are not yet expired or suspended:

update usr set end_time = '2012-09-30' where suspended is False and end_time >= NOW() and end_time < '2012-09-30';

How to extend membership for a large number of users that have already expired

The following command can be used to extend membership to Sept. 30th, 2012 and restore a large number of users that have expired and have been suspended due to the membership expiration:

update usr 
set suspended=FALSE, 
end_time = '2012-09-30', 
suspension_reason = NULL, 
suspension_reason_code = NULL 
where 
suspended is TRUE 
and suspension_reason_code = 'MEMBERSHIP_EXPIRATION';

update certificate
set suspended=FALSE,
suspension_reason = NULL, 
suspension_reason_code = NULL 
where suspended is TRUE 
and suspension_reason_code = 'MEMBERSHIP_EXPIRATION';

VOMS does not register itself with chkconfig

Affected versions: VOMS server version 2.0.2-1

Related savannah bug: https://savannah.cern.ch/bugs/?83005

Is solution available: VOMS server v. 2.0.7 released in EMI 1 Update 14th correctly registers itself on clean install (but not on RPM upgrade). VOMS server v.2.0.8, released in EMI 1 Update 16th (May, 17th 2012) correctly register itself in both cases.

Workaround:

Run chkconfig by hand on the VOMS server node ( you must be root to do this):

/sbin/chkconfig --add voms

-- AndreaCeccanti - 2012-03-05