Don't worry about the mistake/confusion with the terminology. It was clearly an innocent and quite understandable mistake; obvious when you already are familiar with the terms, less so when you are not.
I assume you are referring to named_chrootdir="..."? I set that (to named_chrootdir="/var/named") now and it seems to do the trick. I could not find an explanation of named_chroot_autoupdate= that I can understand however. By default it seems to be set to TRUE and that might just be fine?
Yes, that's pretty much it. As a general bit of advice, I suggest keeping
rc.conf(5) minimised to what is actually required to achieve the desired results. So, for this, something like the following (if it works for you):
Code:
named_enable="YES"
named_chrootdir="/var/named"
Only add additional settings if you actually need to change something else about the script's behaviour.
As is fairly common, the only real documentation for
named_chroot_autoupdate is in the script itself. For better or worse, there is a very old Unix tradition/practice of the only real documentation for such things being inside the script itself (both comments and just reading through what the script does). The base systems's settings do tend to be documented in the
rc.conf(5) man page (but might not always be fully in sync with the latest scripts), but ports are commonly documented inside the scripts themselves. Even with the base system, it is an extremely good practice to have a quick read through the relevant script(s), particularly when dealing with more advanced/complex/unusual configurations. Some of the scripts have very good documentation and the actual scripting is highly readable.
Code:
# If running in a chroot cage, ensure that the appropriate files
# exist inside the cage, as well as helper symlinks into the cage
# from outside.
#
# As this is called after the is_running and required_dir checks
# are made in run_rc_command(), we can safely assume ${named_chrootdir}
# exists and named isn't running at this point (unless forcestart
# is used).
#
chroot_autoupdate()
{
…
I.e. it tries to ensure that the chroot environment (directory tree) contains the minimum content required for named.
However, because I am a curious guy: is there a way to patch (or do something else) automagically after running pkg upgrade? Or (why) is that question evil?
Right now, it seems that
pkg(8) is lacking an easy way to add some scripting around its actions at the system level. The individual packages have a good scripting framework, just there doesn't seem to be a convenient way to do the same as part of the system configuration. The closest thing is the support that it has for plugins, but that is for plugin modules written in C (or another language capable of interfacing via the shared library / dynamic linking model), so not exactly convenient for a quick script.
The reasonably low-effort methods that I can see for achieving such a goal are:
- Copy /usr/local/etc/rc.d/named to /usr/local/etc/rc.d/named.local, changing
named_enable to named_local_enable so that the version from the package is disabled but your locally modified version runs. It is then your responsibility to keep your local version reasonably synced with changes to the default package version.
- (alternatively) Modify the port, where you do have a variety of patching options, and pre and post install hooks. Then maintain your own package build which includes the local modifications.
Not an evil question at all, we just deferred answering it while we answered the question we thought you really wanted to be asking.
