About external or technical configuration files

[Andreas Kempe]

On Sat, Apr 16, 2022 at 12:41:10PM +0200, Julien ÉLIE wrote:
> Hi all,
> 

Hello Julien,

I was meaning to answer this mail, but it slipped my mind so here's a
rather late response.

> Do you think something should be done for the following configuration 
> files in <pathetc>, that are not automatically updated with a new INN 
> version?
> - control.ctl
> - innwatch.ctl
> - moderators
> - nocem.ctl
> 
> Currently, a news admin needs taking care manually of possible changes.
> 
> I doubt people really modify innwatch.ctl...  It may be a file to move 
> into <pathlib> so that bug fixes are automatically taken into account 
> during an update.
> We could have the following behaviour:  use <pathetc>/innwatch.ctl.local 
> if present.  Otherwise, use <pathlib>/innwatch.ctl.
> Any opinion about that?
> 

I think that any file that needs a new version from the INN project
for the software to work as intended should be moved away from the etc
directory and be unconditionally updated when the software is updated.
In your innwatch.ctl case, I think your suggestion sounds reasonable.

> 
> Changes to control.ctl and nocem.ctl are not always straight-forward, as 
> a manual intervention in PGP keys could be needed.  So I would be 
> inclined not to change anything, unless someone has an interesting idea.
> 
> Besides, changes to these "external" files can happen at any time, and 
> are not linked to an INN release.  Same thing for the moderators file.
> 
> Maybe a simple tool that the admin could manually start, or put in cron, 
> that just download the reference file (from ftp.isc.org or the GitHub 
> INN repository for instance) and output the diff between the local 
> installed file could be useful and be an improvement?
> 

My take is that INN should strive to own and separate out anything
that might need updates from the upstream without worrying about local
changes.

To make an example, we can look at nocem.ctl. If INN wants to provide
a base nocem.ctl file that recognises some keys, I think that both
nocem.ctl and the keys needed should be provided and installed by the
installation process in the library directory. There would then be a
configuration directive to either disable or enable the bundled keys.
If the keys change upstream, INN would make a new release with updated
bundled keys and configuration.

The nocem.ctl provided under etc would only contain formatting
instructions, but otherwise be empty and would not be touched by
updates to INN. Both files would then be read and used, unless the
bundled nocem.ctl is explicitly disabled in the configuration.

If INN does not want to take responsibility and do releases of INN to
update the bundled nocem.ctl and keys, I don't think it should bundle
them at all. Instead, I think either a separate package should be
provided for them or, as you suggested, a little script that
automatically fetches these files could be provided.

They way CA certificates are handled on most systems is a good
example. Firefox needs these to function, but on FreeBSD they are
shipped as the ca_root_nss package that is installed independently of
the browser itself. If one wants to use local CA certificates, one
simply adds them as separate files in the CA root directory and these
local files are untouched by any updates.

> Incidentally, this tool may also download/compare the installed version 
> of other common packages like Cleanfeed, PyClean or like.
> 

On FreeBSD, cleanfeed is provided as its own package that installs it
with a rudimentary configuration in the correct place in the INN
directory hierarchy. I think package and software management is best
left to the system's own distribution method.

In short, I think INN should work towards drawing a clear line between
configuration that is managed by the administrator and configuration
that is managed by the upstream. It should then be free to update the
upstream configuration without regard for local changes.

Cordially,
Andreas Kempe