Difference between revisions of "DPM End of legacy-mode support"
Line 7: | Line 7: | ||
related to the deprecation of the lcg-utils clients, which already happened years ago. | related to the deprecation of the lcg-utils clients, which already happened years ago. | ||
(5 June 2019) | (5 June 2019) '''UPDATE''': The DPM team has agreed to extend support for security updates for the DPM legacy functionality until 30 September 2019. However, affected service providers should still plan to disable legacy mode well before this date. | ||
== Why? == | == Why? == |
Revision as of 10:29, 5 June 2019
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
Documentation menu: | Home • | Manuals • | Procedures • | Training • | Other • | Contact ► | For: | VO managers • | Administrators |
What's happening?
DPM (Disk Pool Manager) is the most widely deployed solution for storage of large data repositories on Grid sites for a wide range of applications. In May 2018 during the DPM Workshop the announcement was made that from June 2019 it would be deprecating its so-called "legacy" mode. This includes its support for SRM (Storage Resource Broker) and the old rfio protocol. It's also related to the deprecation of the lcg-utils clients, which already happened years ago.
(5 June 2019) UPDATE: The DPM team has agreed to extend support for security updates for the DPM legacy functionality until 30 September 2019. However, affected service providers should still plan to disable legacy mode well before this date.
Why?
The new DPM core, known as DOME (Disk Operations Management Engine) brings significant enhancements and is based on the secure, industry-standard HTTPS protocol and web services. Discontinuing the legacy mode allows the developers to concentrate on the new scalable and future-proof DOME, without the overhead of maintaining the legacy functionality.
What do I need to do?
End users
Traditionally, users interacted with DPM through its SRM service. With DOME, end users should rather interact with DPM via different protocol frontends, e.g. HTTP/WebDAV, gridFTP or xrootd (see below), that make use of DOME in the background.
For a comprehensive guide to DOME and its design, please refer to the DOME guide (that is more for site admins).
End users should be interacting with DPM and related storage services through the GFAL2 libraries and CLI tools.
DPM administrators and site admins
System administrators interact with the system using a frontend protocol (e.g. with a Web browser) or in a root session in the head node running the tool named dmlite-shell, instead of the older command-line executables dpm-* or dpns-*. The main authentication mechanism remains X.509 with (or without) VOMS extensions, and the new system architecture will allow an easier integration path with possible future alternate authentication systems (e.g. OpenID-Connect).
To see whether end users are making use of legacy tools (e.g. lcg-utils), an easy rule of thumb is to check the contents of your srmv2.2 logfile /var/log/srmv2.2/log
. If this file only records routine reports (e.g. daemon stop/start, ping etc.) then that indicates that SRM is not being actively used by users.
Information about installing DPM and enabling DOME may be found here: [1]. Please note that the site does not necessarily need to use the configuration management tool puppet.
To determine whether lcg-utils clients are being used, please look for occurrences of PASV
in the gridftp logfile /var/log/dpm-gsiftp/gridftp.log
and /var/log/dpm-gsiftp/dpm-gsiftp.log
. (Newer clients such as gfal2 use STOR
instead, meaning a delayed passive ftp.)