Please consider this alongside the server tools refactoring.
The configuration scheme for clients is quite nice: default settings are inherited from well-defined place(s) , and there is flexibility to override them domain-wise or repo-wise in hierarchical levels (.conf, .local, config repo etc).
But for servers there are values hardcoded in the /usr/bin/cvmfs_server script which end up as de-facto defaults placed into the server.conf and/or replica.conf files for every repository.
The challenge we have been facing is that it is difficult to manage the server repo config in a coherent way using configuration management/deployment tools (e.g. Ansible). Depending on which setting we want to change, a different approach is needed: we either add line(s) to the file (using a template), or we need to detect and modify in place an existing line in the config file.
My suggestion is mainly to eliminate the de-facto defaults that are initially added to every server.conf file. Instead they could be inherited from a config file of server defaults (preferably moving all the defaults out of the /usr/bin/cvmfs_server script).
From my point of view the desired outcome is that the server.conf files (and client.conf and replica.conf) would be basically empty except for settings that are specified or detected/determined when doing mkfs. This splits the two distinct roles of config files into separate places: default values that are required for baseline functionality (inherited from some defaults) , and customization by admins so they can adjust settings according to their needs.
I think there are only a few CVMFS_DEFAULT* variables, mostly chunking-related, that this would apply to.
As a side note it would also be nice to have an easy way to determine if a given server setting applies to stratum 0, 1 , or both. (And for that matter, GW or publisher).
There are a few different ways to go about this, this is just one possibility; let me know what you think.