[part of a series of meetings]

Participants

Tigran: pools, NFS

Antje: looked at old tickets several tickets needing an answer. Coming around with a big stick.

Tanja: tickets, reading about NFS spec. Want our NFS server to work in a federated NFS deployment.

Gerd: visited DESY, tried to learn about NFS 4, wrote replacement for gPlazma cell + small stuff.

Dmitry: mostly looked at ticket.

Timur: wrote configuration parser for PAM style ... factories. Started working on implementaiton of strategy

Jan: fought on username/pw plugin, web-admin work. PNFS migration to Chimera.

Paul:

Owen: parser for layout.conf. Applies diffs to layout.conf. Can parse site-info.def now. About 80% done now. Should be submitting some code at end of the week. Other task is EMI certification. Unfortunately had another 3 test suites dumped that doesn't work at DESY. Other task is migration of our gLite hosts onto a new virtualisation service.

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 :)

Adapters in FTP

CDF system: security scanners would cause

detect that the connection isn't from a pool and close the connection.

For the pool, this is something you can do, but one cannot

Clients connect directly but pools queue, so this would fix

Luckily there is already MoverProtocolv2 send a message mover back to the door. We can extend this to also report source ip of the pool.

You can have a race-condition between pool connect and pool's message arriving: if the message is too slow then

We could have a token between pool and door, so that door sends token to the pool and will only accept a connection with this token sent as first n-bytes.

We could share the same server socket on the door for all pools.

Plans for patch-releases

Should we make a new patch release?

RB 1796

Timur requests feedback on backporting patch ​RB #1796 to production branches.

Tigran says it isn't urgent, so not back-porting.

Trunk activity

Progress with new features...

gPlazma

kpwd

Jan: moved the kpwd to commons directory to use it. There are legacies classes that are dependencies of kpwd parser.

We don't have doors depending on kpwd. The KpwdLoginStrategy? is the only dependency.

Yes, we do need kpwd parser as some sites

If we just want to use kpwd ...

Do we use what's already in dCache or do we write a new.

Plugins should go in gPlazma module.

Can you update kpwd parser to remove

Commons is probably not the right location.

To show the true independence of gPlazma, separate module for plugins and package as separate JARs.

Tigran and Jan to look into it tomorrow.

parser and configuration classes

Timur asks whether we should discuss the gPlazma parser and configuration classes: ​RB #1922.

Timur: I don't think it's controversial.

Multiple parsers because we hope to support the old gPlazma.policy file format.

Strategy interface

Timur says ​RB #1927 shows this is currently broken.

We want the strategy to be aware of the linkage between

Issues from yesterday's Tier-1 meeting

tape protection

PIC have deployed 1.9.20-rc1

Expired certificates

Doris reports problems.

GridFTP Create server-context for each connection

Ticket to be assigned to Gerd.

Outstanding RT Tickets

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

​RT 5636: [Fwd: Incident INC000000027923 has been assigned to you. Priority: Low. Description: how to delete a file in dcache]

Not needed to be discussed.

Review of RB requests

Please discard your patches.

DTNM

Same time, next week.