Migration from GSI to SSL

This page is used to document the work done on removal of GSI from EMI software and its substitution with SSL

High Level Workplan

1. Get a list of components that will undergo migration.
2. Find the points where the migration may encounter obstacles.
3. Discuss the problems discovered in the previous step to find possible solutions.
4. Plan the migration, with proper procedures for each component.
5. (not in our scope -- should be done by PTs with their own timing) Actual migration.

Minutes from the Meetings

• notes-16-9-10.txt: minutes of the face to face meeting at the EGI TF
• gsi-notes-revised.txt: minutes of the 20/10 GSI removal phoneconf

Additional Statements:

Aleksandr Konstantinov

Currently ARC uses GSI in following components:

"Classic Storage Element" - GridFTP server with virtual file system backend.

"Arc Computing Element" (old edition) - it has GridFTP frontend for job submission and data staging and also uses GridFTP for accepting delegated credentials.

Data Management plugins to allow clients contact data services, which use GSI - GridFTP, SRM, HTTPg.

MyProxy client integrated into Computing Element for proxy reniewal () and into proxy generation utility.

The "Classic Storage Element" is deprecated product. It is almost not used in production and will be gone soon.

The "ARC Computing Element" with GridFTP frontend is being replaced by HTTPS and WS-base A-REX service and eventually converted to EMI ES interface. So this dependency on GSI wil be gone. AFAIR it is going to happen around EMI1. Although I'm not sure how loong GridFTP interface will be kept for backward compatibility.

The clients with various GSI-based protocols will evolve together with those protocols. So as soon as GSI is abandoned there it will be removed from ARC clients.

Daniel Kouril

I had to leave shortly after Paul, unfortunately my microphone got stuck somehow so you couldn't hear me . I'm adding a short summary about the components that CESNET is responsible for at least here:

L&B

---

- speaks plain SSL on the wire, no need for delegation - implemented using Globus libraries and the GSS-API

Proxy renewal

---

- no network interface exposed, the daemon only uses a local unix socket to talk o the WMS components. No delegation - proxies are passed as files via the filesystem. - actual renewal done via the APIs of VOMS and MyProxy (see below) acting as a client to these services.

GridSite

---

- implemented using OpenSSL API. Only plain SSL used whenever a network communication is involved.

MyProxy

---

- Does use GSI for communication in its "simplest" form, with the "0" magic byte being sent after SSL handshake. Communication handled by the Globus libraries - if they provide the "ssl-friendly" variant mentioned today, MyProxy would automatically benefit from it. - Delegation done on the level of MyProxy protocol.

Paul Millar

Third party transfers are an important consideration but, with redirection, what I meant was redirection within the same site. A common deployment has a few front-end nodes (ones that a user initially connects to) and many, many pool nodes (ones that actually store the data).

Some protocols, like GridFTP v1, effectively tie together the computer-you- connect-to-initially with the computer-you-get-the-data-from. This means that the (few) front-end nodes have to relay data from the (many) pool nodes. This forms a performance bottleneck (one can mitigate against, but its awkward).

GridFTP v2 gives the front-end node the ability to say "get the data from over there", redirecting the client to the pool node. The HTTP protocol also support this (with various 30x HTTP return codes), as does NFSv4.1 / pNFS.

Third-party transfers are also interesting: FTP supports them directly but HTTP doesn't. With SRM, there is the option of requesting a 3rd party transfer that is then scheduled. This allows 3rd party transfers between sites using protocols that don't support it natively (like HTTP).

However, current practice is to use (Grid-)FTP and to use that protocol's native support for 3rd party transfers, so the SRM's ability to schedule transfers is largely unused.

-- VincenzoCiaschini - 08-Jul-2010

• notes-16-9-10.txt: minutes of the face to face meeting at the EGI TF

• gsi-notes-revised.txt: minutes of the 20/10 GSI removal phoneconf