Solved Applying a patch after pkg install or pkg upgrade

I have a feeling that I miss the obvious here, but I failed to find an answer in this forum, the handbook or the man pages.

Is there a way to (automagically) apply a patch after pkg install or pkg upgrade?

The current situation is that I have a script in /usr/local/etc/rc.d that needs tweaking after every upgrade. It's named in this case (because it runs in a jail and cannot find the pid file). But the question is general.

So I guess what I am asking is if there is a "post upgrade" hook in pkgng?


Cheers
fwy...
 
What exactly is wrong? There's rarely a need to touch any of those scripts.
 
Here is the patch (I do not remember where I got it from...):

Code:
$ diff -u /usr/local/etc/rc.d/named.orig /usr/local/etc/rc.d/named
--- /usr/local/etc/rc.d/named.orig    2015-08-15 22:37:54.000000000 +0200
+++ /usr/local/etc/rc.d/named    2015-08-15 22:39:35.000000000 +0200
@@ -208,6 +208,8 @@
{
    find_pidfile

+    test "${named_flags#*-t}" != "$named_flags" && pidfile="/var/named${pidfile}"
+
    # This duplicates an undesirably large amount of code from the stop
    # routine in rc.subr in order to use rndc to shut down the process,
    # and to give it a second chance in case rndc fails.
 
Well, there are a few issues I can see here.

Firstly, if you do actually need to fix the pidfile path, you should be doing that inside the find_pidfile() function, not in only one of the several places that it is used. I.e. that looks like a bad patch to me.

Secondly, chroot(2) and jail(2) are two quite different things. You shouldn't need the -t flag if you are actually trying to run it in a FreeBSD jail. The named(8) man page is wrong (in FreeBSD terms) to refer to a "chroot jail".

The script, as supplied with dns/bind910, does have support for a chroot setup, so you probably shouldn't need to change it if you configured the relevant variables in rc.conf(5).

Please tell us the versions of FreeBSD and BIND that you are running; and whether it is a chroot setup, jail setup, or chroot inside a jail.
 
Although it should be possible, I really wonder what the added (security) benefit of a setup like that would be.

Indeed. I can't really imagine why someone would want to do that, I just added it for completeness and because we have a description of "it runs in a jail", but we also have multiple pointers towards chroot (-t flag and pidfile path issues).
 
Omg, you guys are - awesome. Or scary, depending on how I look at it. In any case, you are spot on. I dug up the URL for the tutorial I was following then: Setup chroot for bind 9 in FreeBSD 10.

So in fact I was taking/thinking/meaning a chrooted bind, not a jailed. Sorry!

...you probably shouldn't need to change it if you configured the relevant variables in rc.conf(5).

Exactly. Iff. But I did not (because the tutorial does 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?

To be complete: I am using FreeBSD 10.1 and just upgraded bind to bind910-9.10.4P2.

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?


Thank you so much!
fwy...
 
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:
  1. 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.
  2. (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. ;)
 
Last edited:
I suggest keeping rc.conf(5) minimised
That sounds like a good idea (and is what I generally try to do). And it explains why I had two -t /var/named showing up in ps... I had both, named_flags and named_crootdir set in /etc/rc.conf.

Thank you also for getting back to the "other part" of the question :)

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.

Is that something that is generally possible (copying to <whatever>.local and using an rc variable with <whatever>_local_enable)? I use(d) a PDF copy of "The Design and Implementation of the NetBSD rc.d system" for reference, to no avail.
 
Is that something that is generally possible (copying to <whatever>.local and using an rc variable with <whatever>_local_enable)? I use(d) a PDF copy of "The Design and Implementation of the NetBSD rc.d system" for reference, to no avail.

In general, yes. The rc scripts should generally be completely dormant (in terms of actions) without their specific *_enable="YES" configured. They should also mostly not care about the name of the script itself. On the other hand, there could easily be some badly written or oddball scripts out there in ports land which don't play nicely in such circumstances. You have to evaluate it on a case by case basis, but the technique should generally work for many cases.
 
Back
Top