Grid : CVMFS Repository Usage

Generische Accounts

Example

#
# sw.desy.de / monlic / sw-cvmfs
#
> ssh monlic@sw-cvmfs

[monlic@sw-cvmfs]~% cvmfs_server transaction sw.desy.de
[monlic@sw-cvmfs]~% date >> /cvmfs/sw.desy.de/test
[monlic@sw-cvmfs]~% cvmfs_server publish sw.desy.de


pal53: [~] ls -l /cvmfs/sw.desy.de
total 1
-rw-r--r-- 1 cvmfs cvmfs  40 14. Dez 2018  new_repository
-rw-rw-r-- 1 cvmfs cvmfs 319  8. Dez 2020  test

Explanation

Changes to a CVMFS repository can be made from the repo librarians. Please open a ticket for the grid team to add a specific user to the list of repo librarians.

A repo librarian can ssh into the repo account on their VOs release machine. In the example on the right, a librarian user for the sw repository became the monlic user, who can update the repository under /cvmfs/sw.desy.de.

Workflow for a CVMFS Update

• unlock the repository for updates with `cvmfs_server transaction reponame`
• apply any changes like adding, removing or changing files under /cvms/reponame
  • for large directory trees it can be beneficial to create a nested catalogue, i.e., to split the file meta data into sub-catalogues
    • for example , creating an empty file like `touch /cvmfs/reponame/anewcontainerdir/.cvmfscatalog` would tell CVMFS during the publishing to keep all the file metadata under that directory in a separate catalogue - instead of blowing up the base catalogue
• commit and finalize the changes with `cvmfs_server publish reponame`
  • before doing the final publishing, move outside of `/cvmfs/reponame`

General Hints

• do not add large files to CVMFS to avoid scaling issues
  • Apptainer containers should be in a sandbox dir format
  • data files or transient data do not belong into CVMFS
• updates are not to be done in a high frequency
• a client needs the DESY CVMFS public signing key to trust the CVMFS server - see DESY CVMFS Repositories
• a client should use a local squid and should not access the stratum-1 directly

Global Set Up

As quick sketch of the CVMFS architecture: the global CVMFS system consists of a hierarchy of servers

• a stratum-0 and repository server, where the data are maintained by the repo librarians
• one or more stratum-1 servers locally and at other sites, that replicate the stratum-0 data and serve to caching squids
• per site a number of squid servers, that act as intermediate caches and serve a site's nodes
• a CVMFS client node like a user desktop or batch system server, where users request files. The client asks its squid, if a requested file is already cached and retrieves it if the squid knows it. If not, the squid asks its stratum-1 and then serves it to the clients.
• due to the tiered structure, updates to a repository can take several minutes to be known at a client