gLite 3.1

gLite VOMS server (Oracle backend) known issues

"--uri" voms-core parameter not configured properly


1. The value set for '--uri' does not contain the ':vomsd_port' suffix,
   which is important for voms-proxy-info. 

Possible workarounds:

a) After each execution of 'glite-voms-server-config.py --configure' the 
   voms.conf file for each VO should be adjusted to that the '--uri' 
   option value is in the form:

   voms_server_hostname:vomsd_port

   This could be done automatically with the following script:

   for vo in /opt/glite/etc/voms/*; do
     if [ -d $vo -a -f $vo/voms.conf ]; then
     PORT=$(grep "\-\-port" $vo/voms.conf | cut -f 2 -d "=");
     sed -i -e "s/--uri=\([^:]*\).*/--uri=\1:$PORT/" $vo/voms.conf;
     fi;
   done;

b) Another solution is to patch the glite-voms-server-config.py. This could 
   be done with the following command (copy everything on a single line):

   sed -i -e 
     's/\(\ *\)input\.write("--uri.*/\1input\.write("--uri=%s\:%s\\n" 
     % (self.voms_hostname, self.voms_port))/' 
     /opt/glite/etc/config/scripts/glite-voms-server-config.py

The known configuration issue has also been reported as the savannah bug #37372:

https://savannah.cern.ch/bugs/?37372

Database upgrade problems

Tracked via

Bug 31943

Description

Database upgrade procedure failures were observed during the ACL migration phase on Oracle. These problems are not fully understood yet. It was found out that they are non-deterministic (database containing the same ACL entries sometimes upgrades fine and sometimes not). One of the suspicions is that the order in which the database upgrade code processes the entries leads to different results. This behaviour was observed with ACL entries that grant a specific right (add, create, remove, delete, etc.) for a specific user (DN/CA pair), and has only been observed on Oracle. Despite the rare occurrence of this bug it is dangerous because if the upgrade program fails the database is left in an inconsistent state !!!

Known workaround

Please backup your database before doing the upgrade !!! You would have to restore the database and remove the offending ACL. Therefore it is recommended that you remove your custom ACL entries before upgrading the database. This can be done from the voms-admin web interface.

Just leave the standard entries in the Global ACL list:

allow    all    The Local Database Administrator
allow    all    Anyone with role /<VO_NAME>/Role=VO-Admin
allow    all    <VOMS_HOST_SUBJECT>    <VOMS_HOST_CA_SUBJECT>
allow    all    <DEFAULT_ADMIN_SUBJECT>    <DEFAULT_ADMIN_CA_SUBJECT>

and remove the rest (in the Global ACL and those created for groups and roles).

A FAQN specified with --voms does not appear first.

Tracked via

Bug 38506

Description

The previously predictable order that a voms-proxy-init --voms fqan1 would return fqan1 as the first fqan was lost.

Known workaround

None, downgrade to packages mentioned in bug.

With no Role the Role=NULL in the generated proxy is no longer present.

Tracked via

Bug 37008

Description

This has been seem to cause problem for the current glite-proxy-renewd.

Known workaround

None, downgrade voms core to the packages mentioned in Bug 38506

gLite wide known issues

Please also check the gLite wide known issues.