WLCG DOMA BDT Meeting

Wednesday 17 Aug 2022, 16:30 → 17:30 Europe/Zurich

Brian Paul Bockelman (University of Wisconsin Madison (US)), Maria Arsuaga Rios (CERN), Petr Vokac (Czech Technical University in Prague (CZ))

Topic: WLCG DOMA BDT Meeting (twiki)

16:30 → 16:35 News

• Rucio now have a developer who will work on token support
  • improving support for data replication with FTS should not take too much time
    • definitely fine with our WLCG Token Transtion Timeline and DC24
  • new workflows (download / upload) will require more work
  • wlcg vs. escape testbed
• We started to discuss with EGI mass migration of DPM sites
  • most probably all active DPM registered in EGI GOCDB will get GGUS ticket within next month or two
  • provide sites info about DPM EOL and supported migration path to the dCache
    • dCache migration support provided by EGI officially ends in summer 2023
• Add privileges to update github WLCG AuthZ documentation
  • not necessary - people can create pull requests without being added to this project
  • we can add privileges to these contributors to the main documentation repository to make their live / contribution easier

16:35 → 16:50 Transfers with tokens

Speaker: Francesco Giacomini (INFN CNAF)

Compliance tests

• Improvements in recent compliance tests results
  • can we keep slightly longer history, e.g. a month
• RAL testbed configuration updated and passing all tests except storage.create that doesn't work by design in XRootD 4.4.x
• New XRootD 5.5rc1 comes with correct storage.create implementation, but returns wrong (default) HTTP 500 error issue#1752
  • compliance tests expect HTTP 403 but gets HTTP 500 Internal Server Error
  • patches already exists issue#1763 and they should be released with XRootD 5.5
  • necessary to be able to pass compliance tests with XRootD, Echo, EOS

Transfers with tokens and X.509

Basic informations in the July 6 BDT Notes, non-official configuration ideas for dCache, XRootD

• Is it possible to avoid using ACLs with dCache? Example of minimalist per-experiment configuration?
• What would be the StoRM configuration for normal experiment storage configuration?
• EOSATLAS already use ACLs (at least for atlasscratchdisk) to give access to normal users and also Rucio with production role

It seems to me storage either have everything mapped to one identity + access restriction for given path configuration (e.g. simple XRootD configuration) or in case VO groups/roles are mapped to different storage identities than ACLs are necessary to give right access permissions to multiple identities.

Common configuration

This WLCG experiment storage access configuration requirements moved to the WLCG AuthZ documentation.

ATLAS

Rucio file replication with FTS always use production role when writing files in the "rucio" subdirectory and while deleting files. For jobs using rucio upload the identity used while writing files differs for production (/atlas/Role=production identity) and analysis jobs (/atlas identity). Also user can store own files with rucio upload and normal /atlas identity.

• /basepath/atlas ... read only for /atlas group
• /basepath/atlas/atlasscratchdisk ... inheritable read for /atlas and write for /atlas + /atlas/Role=production
• /basepath/atlas/atlasdatadisk ... inheritable read for /atlas and write for role /atlas/Role=production
• /basepath/atlas/atlaslocalgroupdisk ... inheritable read for /atlas and write for group /atlas/country_code + /atlas/Role=production

All files can be read with basic /atlas identity.

CMS

• /basepath/cms ... everything readable by /cms identity
• /basepath/cms/{data,mc,...} ... write for role /cms/Role=production
• /basepath/cms/group ... write for role /cms/Role=priorityuser
• /basepath/cms/group/rucio ... write for role /cms/Role=production
• /basepath/cms/user ... only for local users from same home institute (may even provide per-user access permissions)

ALICE

• easy, everything is already mapped to just one account / no access with X.509

LHCb

• /basepath/lhcb ... readable/writeable by production user
• /basepath/lhcb/user ... writeable for normal users

Required storage features

• dCache - (efficient) recursive ACL updates

Action point

• Petr: add these details in the WLCG AuthZ github pages and ask via TPC mailing list (+ add developers) to contribute recommended per-experiment configuration for each storage type

IAM Scope Policies

• don't try to test this functionality if you are IAM administrator - admin account gives you "unexpected" privileges with tokens
• impossible to define scope policies for clients that are not associated with user accounts(?)
• restrict client access to the specific path, e.g. /atlasdatadisk
• defined policy must end with a slash, e.g. storage.create:/atlasdatadisk/
  • otherwise client gets access also to the arbitrary path in a format /atlasdatadiskwhatever
• anybody plans to use this functionality for storage.*:/home/username/(?)
  • performance with thousands of policies defined in IAM(?)
  • not completely crazy idea, but we have to think more about this use-case
    • may be not an performance issue, but managing thousands of rules is also not optimal
    • may be we'll need support for some kind of templates in policy definition
  • its also a question if user "home" directory permission should be enforced by IAM or storage should just simply apply token identity mapping (e.g. as done by CERN EOS)

Action point:

• Petr: create WLCG JWT Profile github issue to make clear behavior without trailing slash in the storage.*:/path scope

16:50 → 17:05 Tape REST access

Speaker: Cedric Caffy (CERN)

17:05 → 17:20 Packet marking

Speakers: Marian Babik (CERN), Shawn Mc Kee (University of Michigan (US))

Not a lot to report today.    Planning a Supercomputing 2022 packet tagging demo (Tristan Sullivan leading this).   Marian is working on the flowd service which will support Firefly and packet tagging plugins, plus augmenting with netstat information.   Next packet marking / flow labeling meeting is planned for September.

17:20 → 17:30 AOB