I am new to CVMFS and it is not quite clear to me how to manage a custom config repo via a package. I am using a CentOS-7 system if that is important. First off, the cvmfs package depends on the cvmfs-config-default package, which I think I want to override. Do I create an RPM modeled after that package? Would my modified package replace that one or install in tandem but override the settings?
This is not so much for my setup, as my cluster uses puppet to set the configuration, but providing an easy way to access the repository by others on systems that I do not control.
Yes, creating an rpm modeled after the cvmfs-config-default package should do it. The expectation is that it would be replaced since you are creating your own configuration repository and cvmfs clients can only be configured with one of them. It might be a little simpler to start with the source code of cvmfs-config-egi because that is standalone rather than being part of the cvmfs package.
If you intend to retain access to cern.ch, egi.eu, and opensciencegrid.org repositories I would recommend to either ask to have your additional systems added to the existing widely used configuration repositories (instead of creating your own) or to participate in the github config-repo source repository where we keep the full source of each of the big 3 cvmfs config repositories in separate branches and can easily merge changes between the branches to keep them up to date.
Okay, thanks. I have a follow up question. I am not yet sure if the repository will be made available globally. My plan is to make the repository available to our campus, with a couple of proxy servers set up. These would be separate from the cluster network proxy servers. I was thinking that the campus proxy servers could be set as part of the configuration repo to ensure that they are used as opposed to people hitting the stratum-1 server. Is the best way to manage that with WPAD?
If you’re only trying to manage access to campus-shared cvmfs repositories, I don’t think think using the configuration repository feature is likely to be the right tool. That will prevent anyone from using one of the global configuration repositories, unless you also import those global settings into your campus configuration repository. Maybe using a supplementary rpm for configuring campus-shared cvmfs repositories, or perhaps a shared git repository between the various system administrators would be easier.
Likewise, if there are different proxies for different clusters on a campus, it is typically easiest to just set the appropriate proxies in /etc/cvmfs/default.local on each cluster rather than setting up a campus WPAD server. WPAD is more useful for application-level access to proxies, where applications can run on multiple clusters and need a way to find out which proxies they should use. On the other hand, if you want to be able at any time to adjust which proxies are used by which clusters without having to involve the cluster administrators, you might still want to set up a WPAD server, or a pair for reliability. I also have flexibility in configuring the WLCG WPAD servers (running at CERN and Fermilab) to return different proxies for different IP address ranges within a campus, if needed, although I would rather that the servers do not get used for high volumes. WLCG jobs that use WPAD are supposed to look first for http://grid-wpad/wpad.dat and http://wpad/wpad.dat to give priority to a local server if there is one.