On 6/27/2014 10:58 PM, Matthew Harmsen wrote:
CAVEAT 1:
Although this patch contains changes to multiple PKI subsystem's 'CS.cfg' configuration files, an upgrade script should not be specifically required for legacy instances since the parameter that is added, 'archive.configuration_file=true', is presumed even if the parameter is missing (as it would be on any legacy instance). In this case, it would only be necessary to add this parameter to a legacy instance's CS.cfg, and set the value to 'false' in order to turn off 'CS.cfg' configuration file archival (explicit instructions detailing this are found in the 'operations' script). However, if this is desired for completeness, I don't mind adding it.
Since by default archive.configuration_file=true, it's not necessary to add the parameter in the CS.cfg.in for new instances. If we remove the parameter from this patch, it is not necessary to write an upgrade script since old and new CS.cfg will be identical (in terms of this parameter). We just need to document the parameter in the man page in case the admin wants to change the behavior. I think in general we shouldn't put parameters in CS.cfg that have the same value as the default value. That will defeat the purpose of having a default value in the first place, will add more things to maintain, and also will be difficult to change later because we won't be able to tell whether the value was intentionally set by the admin. This is more of a long term goal. The CS.cfg itself should not be a place to document or define default values because of the reasons above. The CS.cfg should only be used to customize Dogtag behavior if it's different from the standard behavior. If someone uses Dogtag mostly with the default settings, the CS.cfg should be very small. -- Endi S. Dewata