- 1 Meeting
- 2 News
- 3 Updates from Technical Providers
- 4 Preview
- 5 AOB
- Calendar: https://indico.egi.eu/indico/categoryDisplay.py?categId=107
- meetings are on GoToMeeting
Under Staged Rollout
Ready to be Released
In Staged Rollout
Ready to be released
In Staged Rollout
Ready to be released
Updates from Technical Providers
Data management clients
products that need to download from VOMS the list of users
VOMS allows to every owner of a IGTF certificate to download the list of users. This is not compliant with the European GDPR, since VO membership is considered sensitive data., so that VOMS needs to implement a stricter ACL to the users list.
In order to understand how to proceed, first of all we need to figure out all the use cases: please let us know if any of your products needs to get the users DN for performing the authentication and authorisation mechanism (i.e. grid-mapfile generation containing the users certificate subject).
For some products it would be possible switching to the VOMS-based authentication/authorisation. In particular there are these cases:
- ARC-CE: is there any documentation describing this setting that the site-administrators can look at for applying the change? Any particular use-case preventing this change?
- Maiken will check and get back to it.
- DPM/LFC: the grid-mapfile with users' DNs is necessary for allowing the web access, but for the usual functionalities it isn't (would not): is that correct? is there any way for changing the access through web browser? I seem to remember that for example STORM doesn't need the users DN grid-mapfile for making the user access via webdav (I don't know exactly the access mechanism), but maybe this is just a webdav feature...
- dCache: it can be configured for using VOMS-based authentication, but the web access would still require the users' DNs
- WLCG VOBOX: I haven't understand if it can switch to the new grid-mapfile stile. In any case, there are (should be) few VOBOX instances around, compared to the amount of other products servers, so adding their certificate DNs into Voms-admin and maintaining them could be only a little blood bath...
- EOS is not voms aware (how many VOs are using it, and how many instances?)
- OSG GUMS: to be phased out
- VO-specific services: few instances, few VOs; it should be quite manageable
noarch packages depend on x86-64
when trying to install the following “noarch” packages on ppc64le system, some of them still required x86-64 dependency:
fts-rest-3.5.4-1.el7.centos.noarch.rpm fts-rest-cloud-storage-3.5.4-1.el7.centos.noarch.rpm fts-rest-http-authz-signed-cert-3.5.4-1.el7.centos.noarch.rpm fts-rest-oauth2-3.5.4-1.el7.centos.noarch.rpm fts-rest-selinux-3.5.4-1.el7.centos.noarch.rpm glexec-wrapper-scripts-0.0.7-1.el7.noarch.rpm mkgltempdir-0.0.5-1.el7.noarch.rpm nordugrid-arc-aris-5.3.1-1.el7.centos.noarch.rpm nordugrid-arc-ca-utils-5.3.1-1.el7.centos.noarch.rpm nordugrid-arc-client-tools-1.0.7-1.el7.centos.noarch.rpm nordugrid-arc-compute-element-1.0.7-1.el7.centos.noarch.rpm nordugrid-arc-doc-2.0.15-1.el7.centos.noarch.rpm nordugrid-arc-gridmap-utils-5.3.1-1.el7.centos.noarch.rpm nordugrid-arc-information-index-1.0.7-1.el7.centos.noarch.rpm nordugrid-arc-ldap-infosys-5.3.1-1.el7.centos.noarch.rpm nordugrid-arc-ldap-monitor-5.3.1-1.el7.centos.noarch.rpm nordugrid-arc-nagios-plugins-doc-1.9.1-0.rc1.el7.centos.noarch.rpm nordugrid-arc-nagios-plugins-egi-1.9.1-0.rc1.el7.centos.noarch.rpm nordugrid-arc-ws-monitor-5.3.1-1.el7.centos.noarch.rpm qcg-appscripts-4.0.0-18.centos7.noarch.rpm qcg-broker-4.2.0-6.centos7.noarch.rpm qcg-broker-client-4.2.0-4.centos7.noarch.rpm qcg-comp-egi-is-provider-4.0.0-5.centos7.noarch.rpm qcg-egi-is-conf-4.0.0-1.centos7.noarch.rpm qcg-ntf-egi-is-provider-4.0.0-1.centos7.noarch.rpm qcg-ntf-nagios-probe-4.0.0-1.noarch.rpm
- Next meeting: April 23th, 2017 https://indico.egi.eu/indico/event/3935/