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