Difference between revisions of "URT:Agenda-2018-05-14"
(→FTS) |
|||
Line 232: | Line 232: | ||
== other AOB == | == other AOB == | ||
*Next meeting: ''' | *Next meeting: '''May 28th, 2018''' | ||
[[Category:URT]] | [[Category:URT]] |
Latest revision as of 15:36, 14 May 2018
Meeting
- Calendar: https://indico.egi.eu/indico/categoryDisplay.py?categId=107
- meetings are on GoToMeeting
News
UMD4
In Verification
- StoRM v1.11.13
- APEL update 1.6.2
- ARC 5.4.2 (15.03u18)
Under Staged Rollout
- davix 0.6.7
Ready to be Released
NA
CMD-OS
In Verification
- OOI 1.2.0
- Gridsite 2.3.4
- rocci cli 4.10.2
In Staged Rollout
- cloudkeeper 1.6.0
- cloudkeeper-os 0.9.9
- cloud-info-provider 0.9.1
Ready to be released
NA
CMD-ONE
In verification
- cloudkeeper 1.6.0
- cloudkeeper-one 1.3.0
- cloud-info-provider 0.9.1
In Staged Rollout
- gridsite 2.3.4
- cloud-info-provider 0.8.4
- rocci-cli 4.10.2
- rocci-server 2.0.4
- cloudkeeper 1.5.1
- cloudkeeper-one 1.2.5
- keystorm 1.1.0
Ready to be released
- site-bdii 1.2.1
Updates from Technical Providers
APEL
Frontier
Indigo-DataCloud
dCache
DPM/LFC
NTR
Data management clients
New gfal2 major release in EPEL ( 2.15.4 )
- http://dmc.web.cern.ch/release/gfal2-2154
- http://dmc.web.cern.ch/release/gfal2-2153
- http://dmc.web.cern.ch/release/gfal2-2152
- http://dmc.web.cern.ch/release/gfal2-2.15.1
- http://dmc.web.cern.ch/release/gfal2-2.15.0
FTS
FTS 3.7.8 in EPEL
ARC
Nothing to report for ARC 5.
We are working on ARC 6. Hope for a release candidate before summer. Testing during summer. Release fall.
CREAM
- Broken link on SL6 ( https://issues.infn.it/jira/browse/CREAM-186 )
QCG
Globus
Globus Toolkit update in EPEL testing 2018-04-09, in EPEL stable 2018-04-25:
- EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8dfeea4e1b
- EPEL 6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1017874535
Updated packages:
- globus-gridftp-server-control (6.1)
- Don't error if acquire_cred fails when vhost env is set
- globus-ftp-control (8.3)
- Default to host authz when using tls control channel
- globus-xio (5.17)
- Fix udp dual stack sockets when ipv6only is the default
- globus-xio-udt-driver (1.29)
- globus-gsi-sysconfig (8.1)
- globus-gssapi-gsi (13.5)
- globus-common (17.4)
- globus-gridftp-server (12.5)
- Minor fixes, mostly related to windows
Globus Toolkit update in EPEL testing 2018-05-05, not yet in EPEL stable:
- EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2c0106fe5e
- EPEL 6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-e852ebea3f
Updated packages:
- globus-net-manager (0.18)
- Fix pre-connect not using changed remote contact
- myproxy (6.1.29)
- Fix -Werror=format-security errors
xrootd
xrootd 4.8.2 in EPEL testing 2018-04-15, in EPEL stable 2018-04-30:
- EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f676b11c72
- EPEL 6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-362e34159c
xrootd 4.8.3 in EPEL testing 2018-05-03, not yet in EPEL stable:
- EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-484cbdbb17
- EPEL 6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8bf5d1f8de
caNl
Preview
AOB
bouncycastle updates in EPEL
The bouncycastle updates in EPEL are now in EPEL stable since 2018-04-08:
- EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-50d69f64bd
- EPEL 6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-71db8f6f28
These updates also contain updated canl-java, voms-api-java and voms-clients-java packages.
Despite spending more than two month in EPEL testing and the testing that had been done on the voms-clients-java update in EPEL 6, a minor glitch when upgrading from the old UMD package was discovered when the update was pushed to EPEL stable:
An updated voms-clients-java package (3.3.0-2.el6) was created to address this issue:
Available in EPEL testing 2018-04-12 and in EPEL stable 2018-04-27.
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
- QCG may be configured to use VOMS, however the primary authentication/authorization mechanism (configured in majority of current deployments) is based on grid-mapfiles.
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
other AOB
- Next meeting: May 28th, 2018