Last modified 12 years ago Last modified on 09/01/08 17:54:46

Plan for the Karlsruher grid-school

We plan to have multiple practical sessions.

Info about machines at GridKa

5 hosts for testing:,,,,, (with IP addresses like[1..5])

8 UIs for students:

  • Access is allowed for ssh certificate-based authentication.
  • Owen can login as
  • Paul can login on
  • 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:

There is a:

  • top-level BDII:
  • LFC:

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.
    • 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,
  1. 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),
  1. gPlazma and VOMS,
    • Ref:
    • 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
  1. 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.
  1. 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
  1. 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.



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.


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