[part of a series of meetings]

Participants

Agenda

[see box on the right-hand side]

Postcards

Up to two minutes (uninterrupted) per person where they can answer two questions:

• What I did last week (since the last meeting),
• What I plan to do in the next week.

No questions until we get through everyone :)

Christian: put our release and certified it. Now we are supposed to change the RPM packaging; Christian is working on this; RC-4 needed to be deployed on test-bed. Vilnius. We are providing (except for server & srmclient) src RPMs.

Tanja: ill + tickets

Gerd: pretty busy with Debian packaging. Upgrading prod. to latest 1.9.12. Last week continued doing gPlazma updates.

Dmitry: mostly worked on tickets and debugging PNFS and Linux 2.6.18 / problem is with encp the latest version hangs the machine .. there is a log message (file-ID has changed triggering NFS stale handle). Working on the person with an Isralae-CA-issued certificate. Was not able to reproduce the problem. The user can do transfers to test-site. If Dmitry takes his cert. (valid for 1 week) Initially able to run srmls against BNL but then it started to fail. This appears to coincide with BNL updating their CRLs, the transfers start to fail. The error happens in cog-jglobus.

Could it be the GUMS server? Nope, it happens during establishing the secure connection, within Tomcat.

Patrick: Vilnius, Karlsruhe (funding meeting). Completed how to attach an HSM to dCache. (+lots of meetings).

Antje: documentation, tickets and a day off!

Karsten: looking at Gerd's gPlazma updates; adjusting Argus plugin to match; some documentation for the manual.

Paul: Vilius, patches, reviewing.

Tigran: fixing things.

Plans for patch-releases

Should we make a new patch release?

New release of 1.9.12.

A couple of fixes on other branches but nothing that urgent.

Trunk activity

Progress with new features...

gPlazma

Kerberos support for NFSv4.1/pNFS is waiting for review.

There's other pieces needed for gPlazma.

Tigran has got this working for dCache using gridmapfile + NIS.

Is it possible

Tigran wants plugins:

1. map X509 to some name ("/.../.." --> "fred")
2. map Kerberos to name (e.g. "fred@…" --> "fred")
3. map NIS lookup for this name.

GridKa? school in September. dCache is giving tutorials; it would be nice to have NFSv4.1 mounted and work exactly as with other filesystems.

Packaging

Because we are funded by EMI, we must follow the FHS.

From now on, we will have two different packages: FHS-compliant and traditional (/opt/d-cache).

There is this German support group. They will try this out. Based on German Tier-1 may choose to migrate to the new format and, on th

However, sites may refuse and we would have to support both formats.

Sites shouldn't work RPMs from dCache.org will continue to support /opt/d-cache while

Tigran: update the Solaris packages? It depends...

Have to distinguish between what we need to do right now, to build packages.

For whom are we doing this? If it's EMI then they don't support Solaris, so there's no strong motivation to change the format.

The discussion on Solaris packaging is perhaps too early, wait until we have conforming packages.

Gerd wants Solaris packages to have a consistent storage with instructions over all NDGF pools.

Fedora Debian file-hierarchy differences? Nope, not really.

Gerd: you should be able to use the format from the debian packaging. There shouldn't be anything debian-specific.

Gerd: What we have now works and we build a FHS-compliant Debian package.

We can just remove dCacheConfigure.

We can keep it for our test system. The standard 4-node dCache deploys uses dCacheConfigure.

If we want dCacheConfig to survive we some resources diverted into understanding it.

We want RPM as quickly as possible.

Everything is working: still need to test the WebDAV door.

Christian to start working on a new spec file, using deb packaging files as a starting point / example.

Logging hostnames

If instead of name we log IP then it's impossible to understand with current format.

Just logging the hostname allows an attacker to by-pass our logging by setting up a reverse-IP to claim to be google.com.

The correct thing is to log both (IP and host) but this introduces a compatibility.

How about adding an IP field?

Adding a new column: add column.

The problem is more with the billing files. There are tonnes of scripts that take.

The original motivation was to cut latency: avoid the reverse-DNS lookup.

Further investigation what are the effects of such a change is needed.

Currently the database schema is created by the billing database. We want to move away from this and use external tools.

Issues from yesterday's Tier-1 meeting

Problem with RT 6248. File is removed from the trash table but is not deleted from pool. As file stays in pool, the space-manager.

It seems that sometimes the cleaner fails; for example, a pool removes some, but not all, of the files but the cleaner

What is the strategy? Go through the code.

The temp-work-around extract the PNFS-IDs from database and remove them using the space-manager link-manager command (one-by-one).

If you remove the file the replica on the pool by hand then nothing happens.

If you do a "rep remove" on the pool then does this trigger removing the file from the space-manager? No.

FileRemove? message send from pool.

PnfsManager deletes the file, puts entry in trash.

Cleaner takes from trash, and sends it to pool.

Pool replies when it has deleted the file

Cleaner hears that the file is deleted and sends FileDeleted? to broadcaster.

Issues from EMI

Chimera and Linux

Outstanding RT Tickets

[This is an auto-generated item. Don't add items here directly]

 RT 6107: SRM transfer failure with Israel CA

 RT 6167: bringonline failed due to pinning failed:finding read pool failed

 RT 6197: Feature Request: move dCache files from disk to tape and viceversa

 RT 6227: different files/one pnfsid

Review of RB requests

DTNM

Proposed: same time, next week.