For our EESSI project I’m trying to make a new package to configure clients without using a cvmfs-config repo. I already have something that works, but I’m just curious if this is the right way to do it or if you have any suggestions for improvements:
In order to not having to distribute new packages (with new public keys) for every new future repo, we will reuse the master key for new repos, so that the current public keys should work for those as well;
Besides the public key(s), I’ve only added a domain configuration file that sets CVMFS_SERVER_URL, CVMFS_KEYS_DIR, CVMFS_USE_GEOAPI. Also, based on some configuration files I found in the Cern/EGI cvmfs-config repos, I’m also setting CVMFS_HTTP_PROXY="auto;DIRECT" in case it hasn’t been set yet and $CVMFS_CLIENT_PROFILE" = "single". Is this okay/safe to do that here in our domain config file as well?
Do we need / do you recommend any other parameters that we should set? We’re also thinking about having some cloud proxies that could be used as fallback, but that can be added later.
Are there any conventions w.r.t. the name of such a package, or can it still have a name like cvmfs-config-eessi-*.rpm, even though it doesn’t use a cvmfs-config repo?
That looks by and large good to me! The name cvmfs-config-eessi matches the existing packages (cvmfs-config-egi, cvmfs-config-osg, cvmfs-config-default).
Regarding the proxy settings, the auto keyword only makes sense if you also run a WPAD capable server that it able to provide a suitable proxy addresses to clients. There is a paper with some details. Otherwise, I would not set CVMFS_HTTP_PROXY but leave it up to the users to make a decision.
The CVMFS_CLIENT_PROFILE is supposed to be set consciously by the user. At the moment, it only has an effect for the config repositories, i.e. in your case the settings would not make a difference.
We were considering to set the proxy to DIRECT in the domain configuration if it’s unset, just to make it a little bit easier for clients like workstations to use our repository (but with a big warning in the documentation that larger groups of clients should set up / use their own proxy).
So you wouldn’t recommend doing that? Is that just to prevent people who are not reading the documentation properly from overloading the Stratum 1 servers?
So you wouldn’t recommend doing that? Is that just to prevent people who are not reading the documentation properly from overloading the Stratum 1 servers?
That’s the reason, yes. Of course, looking at your users and infrastructure, you might decide that a different trade-off makes sense. By convention, the CVMFS_CLIENT_PROFILE=single setting is meant to adjust the configuration for single, interactive users. So you could check for an unset CVMFS_HTTP_PROXY and CVMFS_CLIENT_PROFILE=single and in this case set the proxy to DIRECT.
Okay, thanks! That’s indeed more or less what I meant with the second item in my initial post, then we’ll probably use that (but without the auto keyword).
If you want the package to be widely available I suggest putting it into the cvmfs-contrib yum repository. There’s not yet an automated way for lots of people to add packages, but so far I have been doing it through the build.opensuse.org web interface. If someone is interested in maintaining their own packages there it would likely make sense to extend the credentials to more people, or I could do it for them. There are command line tools to do the builds as well but so far I have not tried them.
Of course, we could also add the EESSI configuration to the major infrastructure configuration repos so that those who are using one of them do not need to install an rpm.
I think that would be really nice, @dwd. Can we already do that for our current (pilot) repository, or do you want to wait until we have a production-ready repository?
I think it would make sense to add it at least to the EGI configuration repository, especially if you have people participating in the pilot at more than a couple of sites. Configurations are done on a per-domain basis so ideally that can be done once and not changed later; that would happen if you don’t change the domain name and keep the same domain signing key if you add repositories. On the other hand, it isn’t very difficult to change something in the configuration repository again in the future. You could make a request either by a ticket at https://ggus.eu or a github issue in https://github.com/cvmfs-contrib/config-repo.