Plan for the Karlsruher grid-school

We plan to have multiple practical sessions.

Info about machines at GridKa

5 hosts for testing: gks-1-101.fzk.de, gks-1-102.fzk.de, gks-1-103.fzk.de, gks-1-104.fzk.de, gks-1-105.fzk.de, (with IP addresses like 141.52.174.10[1..5])

8 UIs for students:

• Access is allowed for ssh certificate-based authentication.
• Owen can login as gks100@gks-1-135.fzk.de
• Paul can login on gks099@gks-1-135.fzk.de
• The account has a file passwords that contains the a/c and grid certificate passphrase.

There are 2 VOs students are a member of:

• /gks /gks/gks08 /gks/dech (i.e., group "gks08" and "dech")
• /dech

Two VO have different VOMS servers, which are:

• "gks"  https://dgrid-voms.fzk.de:8443/voms/gks/services/VOMSCompatibility?method=getGridmapUsers&container=/gks
• "dech"  https://glite-io.scai.fraunhofer.de:8443/voms/dech/services/VOMSCompatibility?method=getGridmapUsers&container=/dech

There is a:

• top-level BDII: gks-0-060.fzk.de
• LFC: gks-0-061.gridka.de

Layout of sessions

Each session follows the following format:

1. Introduction part: a talk w/ slides (these are marked Intro part below).
2. Practical hands-on part (with hand-outs),
3. QA part.

The following sessions:

1. Basic install of dCache,
   • Ref.
     • manuals/Layout
     • manuals/Yum
   • Intro part:
     • What is an SE?
     • Protocols & FTS,
     • pools: storage of files in a directory,
     • domains: a component of dCache, a Java VM.
   • writing site-info.def (See: manuals/site-info.def)
   • do install,
   • starting and stopping dCache,
   • Introducing the web interface,
   • verify working correctly using dCache protocols,
     • gsi-dccp,
   • Adding a new pool,
     • YAIM based
     • Gerd-o-matic pool.
     • Show new pool in web interface,

2. Fun with the Admin. interface
   • Intro part:
     • domains & cells,
     • Important cells: PoolManager, Doors and Pools,
     • Navigation (cd and ..), info, help, ps -f in System cell,
     • taking a pool off-line requires draining, which is an issue.
   • Basic orientation within the admin interface,
   • Assigning a directory to a set of pools (dir --> tag --> links --> pgroup --> pools),

3. gPlazma and VOMS,
   • Ref:
     • manuals/SRM_2.2_Setup
   • Intro part:
     • dcap 'not' secure, gsidcap is.
     • grid-proxy-init is deprecated, should disappear within a year.
     • Some vague about VOMS, VO, groups and roles, FQANs.
     • Mapping VO+group & roles to uid & gid.
     • Broken/Limitations? of dCache:
       • Members of same VO have identical uid/gid when writing.
       • If more than one matches, first one selected.
       • dcap using uid/gid from client.
     • Third-party copy (means we need host cert. on each pool node).
     • Host certificates expiring.
     • Waffle about ACLs on name-space coming "soon".
   • voms-proxy-init (et al.)
   • host certificates (checks)
   • /etc/grid-security/grid-vorolemap
     • walk through structure of file.
   • /etc/grid-security/storage-authzdb
     • walk through structure of file.
   • dcachesrm-gplazma.policy
     • walk through structure of file.
   • dcacheVoms2Gplasma.conf
     • Add gks groups as different dCache (abstract) users.
     • Note that this is run out of cron
     • Note that this is a good check of hostcerts and VOMS-server- or VO- misconfiguration.
   • Demonstrate it working:
     • edg-gridftp-*
     • globus-url-copy
     • gsidcap

4. Space management & SRM,
   • Intro part:
     • What is SRM,
     • What is a space,
   • Student mystified by configuration
   • Student baffled by inexplicable behaviour
   • Time for session exceeded.
   • Verify it works.

5. Info provider and GLUE,
   • Intro part:
     • What is GLUE,
     • What is LDAP,
     • How LCG information is structured, architecturally.
     • How to query LDAP,
     • Which grid components use GLUE?
     • A glimpse from the future (info service, et al)
   • What to edit in the static LDIF
   • Which attributes need maintenance.
   • How to check it is working

6. LCG & talking to the wider world.
   • Intro part:
     • VO computing models (DQ2, Phedex, ...)
     • VO Calalog(ue)s,
   • lcg-* commands
   • Verify it is working:
     • lcg-cr ...
     • SAM tests

Hand-outs available as PDF and HTML: achieved either using DocBook or using the wiki.

Slides introducing a session (part a. in general format for a session) have the following format:

1. theoretical background,
2. introduction to hands-on-session,
3. a simple list of activities (4 or 5 items) and the goal for each activity.

Deadlines

AUGUST

Tue 19th

• Know what hardware is being provided (32 machines)
  • we have 32 student machines at least 1GiB memory, single UI

• Know login credentials for a sample hardware *identical* to what students will use:
  • Done

• Know what is provided for student: a desktop machine or network access (with expectation that students provide a laptop)
  • students are expected to bring a laptop

Wed 20th

• Know whether we have a cloning system we can use
  • They have some kind of cloning system (using rsync?), we cannot rely on it.

• Know whether a VOMS server available
  • In principle, yes.

• Know whether students will have a group or roll, or be member of a second VO
• Verify dCache on a student machine:
  • Have login access to a sample student machine,
  • Have installed dCache on that machine,
  • Have verified dcap commands work,
  • If have student certificate:
    • demonstrated voms-proxy-init works else
    • use Owen's certificate
  • Have verified SRM commands work.
  • If have site- & top-level BDII & LFC:
    • working lcg-* commands
• Know when we will have example student certificate
• Know when we shall have a working VOMS server to test against.

Fri 22st

• Produced 2nd level items for each session
• Gathered existing hand-out material
• Verify dCache on a student machine:
  • Have verified SRM commands work.
  • If have site- & top-level BDII & LFC:
    • working lcg-* commands
• Know whether we will have an LFC and when this will be available.

Mon 25th

• Know whether we have two beamers/projectors in room.
• Gather exiting slides from previous talks

Wed 27th

• Written 1st draft of hand-outs
• Have a script that checks basic functionality; for example, grid-certs are present, postgres, java, basic networking connectivity, resource-level BDII running.

SEPTEMBER

Mon 1st

• Have completed 1st draft of slides

Tue 2nd

• Each section of the handouts has been verified
• Slides have been verified

Wed 3rd

• Final version of slides completed

Thrs 4th

• Final version of handouts, based on feedback.
• Practice run through slides