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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users