Bug 226932 - dns/bind9-devel, dns/bind91?: Add a function for flush cache to rcscript.
Summary: dns/bind9-devel, dns/bind91?: Add a function for flush cache to rcscript.
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Mathieu Arnold
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-26 02:18 UTC by Tatsuki Makino
Modified: 2022-03-26 16:06 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (mat)


Attachments
patch for dns/bind9-devel (685 bytes, patch)
2018-03-26 02:18 UTC, Tatsuki Makino
no flags Details | Diff
patch for dns/bind9-devel (828 bytes, patch)
2018-03-26 02:24 UTC, Tatsuki Makino
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tatsuki Makino 2018-03-26 02:18:15 UTC
Created attachment 191821 [details]
patch for dns/bind9-devel

It can counteract a poison just by typing "service named flush".
This patch can be applyed for dns/bind91? as well as dns/bind9-devel.
Comment 1 Tatsuki Makino 2018-03-26 02:24:28 UTC
Created attachment 191822 [details]
patch for dns/bind9-devel

Alternatively, this makes rndc directly usable.
It does not need to type "-k /usr/local/etc/namedb/rndc.key" when using rndc.
Comment 2 Mathieu Arnold freebsd_committer freebsd_triage 2018-03-26 09:38:27 UTC
what prevents you from running rndc directly?
Comment 3 Tatsuki Makino 2018-03-27 02:47:31 UTC
(In reply to Mathieu Arnold from comment #2)

/var/named and /var/run/named are listed in the /usr/src/ObsoleteFiles.inc.
https://svnweb.freebsd.org/base/head/ObsoleteFiles.inc?revision=331353&view=markup#l4137
I use named_chrootdir not to be affected by make delete-old.
It is not good that /usr/local/etc/namedb is a directory when using named_chroot.
rndc written in rcscript will automatically complement argument.
To use rcscript is more convenient if files are scattered across different paths.
Comment 4 Mathieu Arnold freebsd_committer freebsd_triage 2018-03-30 12:01:46 UTC
I still do not understand.
The chroot code in etc/rc.d/named makes sure you have this symlink: /usr/local/etc/namedb -> /var/named/usr/local/etc/namedb

So, when you run rndc, it finds /usr/local/etc/namedb/rndc.conf and just works.

Also, as your patch runs rndc without any options, it works exactly the same as if you run it directly.  I do not see the point of having to type "/usr/local/etc/rc.d/named flush" where "rndc fluch" works.
Comment 5 Tatsuki Makino 2018-03-31 01:12:55 UTC
(In reply to Mathieu Arnold from comment #4)
> The chroot code in etc/rc.d/named makes sure you have this symlink...

/usr/local/etc/namedb is created as a Directory at the same time that /usr/local/etc/rc.d/named is installed.
The directory /usr/local/etc/namedb interferes with the creation of symlink.
(cf. https://svnweb.freebsd.org/ports/head/dns/bind9-devel/files/named.in?revision=458413&view=markup#l113 )
It can not be deleted because the file inside is registered in local.sqlite.

If we create a symlink before installing bind9-devel, the directory ahead of the symlink will be deleted by pkg delete -y bind9-devel.

It is strange, so I don't concern the default directory. And I want to do "/usr/sbin/service named flush" like "/usr/sbin/service named reload".
Comment 6 Mathieu Arnold freebsd_committer freebsd_triage 2018-06-05 12:24:14 UTC
(In reply to Tatsuki Makino from comment #5)
> (In reply to Mathieu Arnold from comment #4)
> > The chroot code in etc/rc.d/named makes sure you have this symlink...
> 
> /usr/local/etc/namedb is created as a Directory at the same time that
> /usr/local/etc/rc.d/named is installed.

This is true.

> The directory /usr/local/etc/namedb interferes with the creation of symlink.
> (cf.
> https://svnweb.freebsd.org/ports/head/dns/bind9-devel/files/named.
> in?revision=458413&view=markup#l113 )

This is not.  The existence of /usr/local/etc/namedb will interfere with the creation of the symlink if it exists while <chroot>/usr/local/etc/namedb also exists, I could not reproduce the case where the configuration directory exists and the symlink does not.  The only way this can happen is if you create the directory in the chroot hierarchy manually, or remove the symlink yourself.
The whole point of the function you are pointing to is automatically create the chroot, the symlinks, and everything.

> It can not be deleted because the file inside is registered in local.sqlite.

It is never deleted, it is automatically moved, and a symlink is created, which never interferes with what is in local.sqlite.

> 
> If we create a symlink before installing bind9-devel, the directory ahead of
> the symlink will be deleted by pkg delete -y bind9-devel.

It will, yes, but only if no file have been modified in etc/namedb/, which is the point, if nothing was configured, it most certainly means it was never used, and nothing needs to be kept, but it does not matter, because if you install it again, everything will be created again correctly.

> It is strange, so I don't concern the default directory. And I want to do
> "/usr/sbin/service named flush" like "/usr/sbin/service named reload".

I still do not understand why you cannot use rndc flush.  You must have a quite heavily modified system for everything to break the way it does.
Comment 7 Tatsuki Makino 2018-06-07 07:20:05 UTC
(In reply to Mathieu Arnold from comment #6)
> You must have a quite heavily modified system for everything to break the way it does.

Yes. I do not understand why the system was set up like the present situation :)
And I posted this without remembering it :)
However, I surveyed and grasped.

I used bind on 9.x-STABLE. And I moved from 9.x-STABLE to 10.x-STABLE.
9.x had chroot environment by default but 10.x did not exist.
I copied named_chrootdir from 9.x.
I avoided using /var/named because make -C /usr/src delete-old reports directories that can not be removed.
==> As a result, the config files installed in /usr/local/etc/namedb did not move into named_chrootdir.
I changed the location of the config file because /etc/namedb became a place to be deleted by make -C /usr/src delete-old.
Also, the config file exists in /usr/local/etc/namedb and the checksum is recorded.
I thought that I don't want to mix my config files with /usr/local/etc/namedb, so I installed my config files elsewhere.
==> As a result, a quite heavily modified system (omit) was completed perfectly.

In 9.x, I created symlink /usr/local/etc/namedb/rndc.key -> /etc/namedb/rndc.key so that /usr/local/sbin/rndc could find rndc.key.
However, in 1[0-2].x /usr/local/etc/namedb may move, so I don't want to make a symlink in /usr/local/etc/namedb.
Won't you add attachment 191821 [details] for someone whose prefix of $named_conf is not /usr/local/etc/namedb?
Comment 8 Mathieu Arnold freebsd_committer freebsd_triage 2018-06-08 13:31:32 UTC
What do you mean "/usr/local/etc/namedb may move"?  It will absolutely not move.

The easiest way for you to fix your problem, if for some reason, you do absolutely cannot have your BIND9 configuration in /usr/local/etc/namedb, would be to create a symlink to where your configuration actually is.
Comment 9 Tatsuki Makino 2018-06-11 01:27:24 UTC
(In reply to Mathieu Arnold from comment #8)
> What do you mean "/usr/local/etc/namedb may move"?

I mean... Immediately after installation, /usr/local/etc/namedb is a directory, which mv under $named_chrootdir when chroot_autopudate is run for the first time.

> The easiest way for you to fix your problem, if for some reason, you do absolutely cannot have your BIND9 configuration in /usr/local/etc/namedb, would be to create a symlink to where your configuration actually is.

The reason is that I just don't want to mix my config files and the bind9-devel's default config files in the same directory.
But, when the symlink of /usr/local/etc/namedb points to my config files directory, pkg check -qsa executed every day by 460.pkg-checksum requires that the bind9-devel's default config files exist.
Comment 10 Daniel Engberg freebsd_committer freebsd_triage 2022-03-26 16:06:39 UTC
Any progress on this one?