gLite 3.0
glite-SE_dcache_pool - Update to version 3.0.4-0
IMPORTANT NOTE: It is recommended that both client and server are updated at the same time. Otherwise following kind of problems may occur:
If sites run dCap doors within their dCache service and don't synchronize the upgrade of the client and the server then SRM transfers using the dCap protocol may suffer. The dCache client srmcp, from the older dCache client rpms will use dCap as the default transfer protocol with the new server. If sites are using dCap they should already know that dCap is rsh-like with respect to authentication. The implication is that users files will be written with the UID the client who initiated the transfer (root is blocked). This can cause issues when users have different UID's on the client from the UID they are mapped to on the server via the gridmap file. This will only happen when dCap as a running dCache door. The implications of using dCap transfers writing to one UID and gsiftp writing to another UID is unlikely at most sites as most sites do not have this complexity, but if this is the case sites will find that some data transfers initiated with srmcp will fail due to PNFS permissions as PNFS is UNIX like in its file system permissions. Some sites may have enabled dCap only as a read protocol, in this case all data transfers to dcache will fail when started with srmcp without specifying the preferred data transfer protocol.
Update details
The new DPM info provider is configured. YAIM introduces two new variables:
The new infoprovider is called by the edguser, and, in order to have the permission, the host certificate gets installed in its .globus directory.
The new version (d-cache-lcg-6.2.0) provides the following improvements:
Please also have a look at the list of known issues.
glite-SE_dcache_pool - Update to version 3.0.4-0
| Date | 20.06.07 |
|---|---|
| Priority | Normal |
Description
dCache update
IMPORTANT NOTE: It is recommended that both client and server are updated at the same time. Otherwise following kind of problems may occur:
If sites run dCap doors within their dCache service and don't synchronize the upgrade of the client and the server then SRM transfers using the dCap protocol may suffer. The dCache client srmcp, from the older dCache client rpms will use dCap as the default transfer protocol with the new server. If sites are using dCap they should already know that dCap is rsh-like with respect to authentication. The implication is that users files will be written with the UID the client who initiated the transfer (root is blocked). This can cause issues when users have different UID's on the client from the UID they are mapped to on the server via the gridmap file. This will only happen when dCap as a running dCache door. The implications of using dCap transfers writing to one UID and gsiftp writing to another UID is unlikely at most sites as most sites do not have this complexity, but if this is the case sites will find that some data transfers initiated with srmcp will fail due to PNFS permissions as PNFS is UNIX like in its file system permissions. Some sites may have enabled dCap only as a read protocol, in this case all data transfers to dcache will fail when started with srmcp without specifying the preferred data transfer protocol.
Update details
- Client now sends by default for srm get and put operations, protocols in a different priority order. The order has changed from {http,dcap,gsiftp} to {gsiftp,dcap,http}.
- Staging bug fix. The initial state of the pin was set to PINNED for previous releases, this prevented files being staged, as the PIN manager believed the files where on disk, this has been resolved.
- Access two different accounts with the same kerberos ticket or x509 cert now supported.
- dCap door can now be run in the read only mode.
- Bug fixes to the resilience manger so that 0 byte files will not replicate in an uncontrolled way.
YAIM update
The new DPM info provider is configured. YAIM introduces two new variables:
DPM_INFO_USERDPM_INFO_PASS
The new infoprovider is called by the edguser, and, in order to have the permission, the host certificate gets installed in its .globus directory.
d-cache-lcg update
The new version (d-cache-lcg-6.2.0) provides the following improvements:
- Ensure sgm and prd pool accounts also use the first regular pool account of their VO (fixes problem reported on LCG-Rollout list).
- Besides "001" allow the first pool account to end in "01" for small or "0001" for large VOs.
- Handle observed e-mail address attribute name conversion to "EMAILADDRESS" and also allow for "emailAddress" (OpenSSL 0.9.7 and later).
Please also have a look at the list of known issues.
Updated rpms
| Name | Version | Full RPM name | Description |
|---|---|---|---|
| dcache-client | 1.7.0-35 | dcache-client-1.7.0-35.i586.rpm | dCache Client |
| d-cache-lcg | 6.2.0-1 | d-cache-lcg-6.2.0-1.noarch.rpm | d-cache-lcg |
| dcache-server | 1.7.0-35 | dcache-server-1.7.0-35.noarch.rpm | dCache Server |
| glite-SE_dcache_pool | 3.0.4-0 | glite-SE_dcache_pool-3.0.4-0.noarch.rpm | glite SE dcache pool node |
| glite-yaim | 3.0.1-16 | glite-yaim-3.0.1-16.noarch.rpm | glite-yaim |
The RPMs can be updated using apt via
- via apt: apt-get dist-upgrade
- or via a download from:
http://glitesoft.cern.ch/EGEE/gLite/APT/R3.0/rhel30/RPMS.updates/
Service reconfiguration after update
Not needed.
Service restart after update
Service must be restarted.
How to apply the fix
- Update the RPMs (see above)
- Update configuration (see above)
- Restart the service if necessary (see above)