A policy for removing named.conf options.

[Timothe Litt]

On 13-Jun-19 06:46, Matthijs Mekking wrote:
> Dear BIND 9 users,
>
> BIND 9 has a lot of configuration options.  Some have lost value over
> the years, but the policy was to keep the options to not break old
> configurations.
>
> However, we also want to clean up the code at some point.  Keeping these
> options increases the number of corner cases and makes maintenance more
> cumbersome.  It can also be confusing to new users.  We are trying to
> establish an orderly, staged process that gives existing users ample
> time to react and adapt to deprecated options.
>
> The policy below describes our proposal for the procedure for removing
> named.conf options. We would like to hear your feedback.
>
> Thanks, best regards,
>
> Matthijs
> [Snip]

Slowly catching-up from being off-line, I've reviewed the discussion on
this.  A couple of observations:

So far, the suggestions have included logging & making sure that
named-checkconf flags deprecated syntax.  While helpful, these all
suffer from a timing problem: notice is only provided after the new
software is installed.  For advance notification, they require someone
to look at "the" log file (or proactively run named-checkconf).  But if
it isn't going to bite now, there's a good chance that won't happen. 
And if it does bite now, the software has been installed - best case in
a test environment, worst case in production.  [The last may be more
likely with packaged distributions than with build-from source sites.] 
Further, "the" log file varies by startup mechanism (sysVinit, systemd,
named's logs, consoles, ...) - and in embedded cases, logs may be remote
and/or hard to access.

One approach to notification that hasn't been mentioned would be to
include a deprecation notice and scan of the default configuration file
in 'make install'.   This should be a separate script called from
install, that can also be used stand-alone.

This has limitations, but covers some interesting cases:

Advantages:

Proactive: can stop install if obsolete directives/syntax is detected -
before starting the test (or for the adventurous, production) environment.

Does not depend on logging, or on anyone reading the logs.

Does not depend on which startup mechanism is in use.

Should be caught by the packagers' build.  They are generally
responsible enough to pass on the deprecations to their users.  The
packagers can run the check script in their package's 'install' mechanism.

Works for most people who build from source.

Limitations:

Does not work for installations who use a non-default configuration
file. (e.g. named -c ...)

May be messy for chroot and enhanced security (selinux,apparmor,...)
environments

Will not inspect dynamic configurations (e.g. rndc addzone, modzone...)

Notes:

In all cases, make install could include a short notice of the form "See
<path>DEPRECATIONS for changes that may require changes in your
configuration files".   The README can also refer to this file to avoid
duplication.

Why install?  Eventually, even packaged distributions use install - it
may be buried in an RPM's spec file, but it's run somewhere.  Install
allows the newly built(or distributed) version to check before the new
version is activated.  "configure" is too soon - you don't have the new
images, and with packaged (and cross-compiled) distributions, it's never
run on the target.

Probably, running the check should be the default (maximum coverage),
but a make install-nocheck target would probably be necessary.

Another mechanism would be to add a --fix option to named-checkconf. 
This would generate a new file(s), commenting out options that no longer
serve a purpose - with an easily detectable marker (e.g. '# OBSOLETE -
named-checkconf V19.2').  For options that are simply renamed, it can
insert the new, equivalent syntax.  For options that can't be
automatically updated, create a marker "# ATTENTION: named-checkconf
V19.2 - The 'use-Klingon-names' option is not supported, see
DEPRECATIONS section 659.712 for details" - and don't comment out the
option!  A log file listing all files modified should be produced. 
--fix would shift the burden of finding the affected options from the
user to software - making it (a) more likely to happen (b) easier -
especially for configurations that span dozens (or hundreds) of
'include'd files.

I don't think there's a single universal solution to handling
deprecations, but I hope that these observations are helpful.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190707/eeb9bdec/attachment.bin>