Hi All,
Thank you all for the enormous help in me getting bind-chroot working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Broken bind-chroot repair after upgrading to Fedora 34:
# means root $ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to # search your_domain # nameserver your_IP nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service breaking a server https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service # systemctl start named-chroot.service
Other useful command(s):
# systemctl stop named-chroot.service # systemctl status named-chroot.service # systemctl restart named-chroot.service
3) the new version of bind-chroot enables "dns security validation" by default.
To repair, place the following in your named.conf:
by itself at the bottom: include "/etc/named.root.key";
add the following to your "options" block: dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds $ delv @208.67.222.123 com ds ; fully validated ...
4) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is deprecated`
it is a bug in named-checkconf.
See the following I posted on 2021-06-14. Just ignore the message.
named-checkconf gives confusing depreciated 'managed-keys' message https://bugzilla.redhat.com/show_bug.cgi?id=1972022
Zones: # named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf zone, not `domainname`. For example:
zone "abc.local" { type master; file "slaves/rent-a-nerd.hosts"; allow-update { key DHCP_UPDATER; }; }; The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts zone abc.local/IN: loaded serial 265 OK
# named-checkzone -t /var/named/chroot/var/named/slaves 255.168.192.in-addr.arpa abc.hosts.rev zone 255.168.192.in-addr.arpa/IN: loaded serial 213 OK
5) restart the bind-chroot service:
Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service # tail -f /var/log/messages
On 6/14/21 11:21 PM, Samuel Sieb wrote:
On 2021-06-14 10:00 p.m., ToddAndMargo via users wrote:
# systemctl enable named-chroot.service # systemctl start named-chroot.service
In case you didn't know, "enable --now" will enable and also start the service and "disable --now" will disable and stop it.
Cool! :-)
On 6/14/21 10:00 PM, ToddAndMargo via users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Well, if at first you don't succeed, revise! See changes to named.root.key
Broken bind-chroot repair after upgrading to Fedora 34:
# means root $ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to # search your_domain # nameserver your_IP nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service breaking a server https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service # systemctl start named-chroot.service
Other useful command(s):
# systemctl stop named-chroot.service # systemctl status named-chroot.service # systemctl restart named-chroot.service
3) the new version of bind-chroot enables "dns security validation" by default.
Make sure you do not have two `named.root.key` kicking around. One in /etc/named.root.key and one in /var/named/chroot/etc/named.root.key
The bad one is the one that starts with `managed-keys {`, which is depreciated. The good one starts with `trust-anchors {`
If the one in chroot is bad: # mv /var/named/chroot/etc/named.root.key /var/named/chroot/etc/named.root.key.deprediated # mv /etc/named.root.key /var/named/chroot/etc/named.root.key # ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key
To repair, place the following in your named.conf:
by itself at the bottom: include "/etc/named.root.key"; Note: the actual location is: /var/named/chroot/etc/named.root.key
add the following to your "options" block: dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds $ delv @208.67.222.123 com ds ; fully validated ...
4) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is deprecated`
you may have to seperate named.root.conf files. This will read the one in chroot.
Zones: # named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf zone, not `domainname`. For example:
zone "abc.local" { type master; file "slaves/rent-a-nerd.hosts"; allow-update { key DHCP_UPDATER; }; }; The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts zone abc.local/IN: loaded serial 265 OK
# named-checkzone -t /var/named/chroot/var/named/slaves 255.168.192.in-addr.arpa abc.hosts.rev zone 255.168.192.in-addr.arpa/IN: loaded serial 213 OK
5) restart the bind-chroot service:
Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service # tail -f /var/log/messages
On 16/06/2021 03:54, ToddAndMargo via users wrote:
- the new version of bind-chroot enables "dns security validation" by default.
Make sure you do not have two `named.root.key` kicking around. One in /etc/named.root.key and one in /var/named/chroot/etc/named.root.key
I think you may be missing some key points as to how named-chroot works.
If you look at the named-chroot.service file you'd see.....
Requires=named-chroot-setup.service Before=nss-lookup.target After=named-chroot-setup.service
This means that named-chroot-setup.service runs prior to ExecStart in named-chroot.service
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named) You can see the mounts after starting named-chroot.
Thus you'd have.....
[root@f33g ~]# systemctl stop named-chroot [root@f33g ~]# ll /var/named/chroot/etc/named.root.key /etc/named.root.key ls: cannot access '/var/named/chroot/etc/named.root.key': No such file or directory -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key
[root@f33g ~]# systemctl start named-chroot [root@f33g ~]# ll /var/named/chroot/etc/named.root.key /etc/named.root.key -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key -rw-r--r--. 1 root named 686 Jun 3 22:47 /var/named/chroot/etc/named.root.key
To repeat what I've said in another thread. I've upgraded 2 F33 VMs. One running named.service the other named-chroot.service. Both upgraded without any problems you noted.
On 6/15/21 2:30 PM, Ed Greshko wrote:
On 16/06/2021 03:54, ToddAndMargo via users wrote:
- the new version of bind-chroot enables "dns security validation" by
default.
Make sure you do not have two `named.root.key` kicking around. One in /etc/named.root.key and one in /var/named/chroot/etc/named.root.key
I think you may be missing some key points as to how named-chroot works.
If you look at the named-chroot.service file you'd see.....
Requires=named-chroot-setup.service Before=nss-lookup.target After=named-chroot-setup.service
This means that named-chroot-setup.service runs prior to ExecStart in named-chroot.service
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named) You can see the mounts after starting named-chroot.
Thus you'd have.....
[root@f33g ~]# systemctl stop named-chroot [root@f33g ~]# ll /var/named/chroot/etc/named.root.key /etc/named.root.key ls: cannot access '/var/named/chroot/etc/named.root.key': No such file or directory -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key
[root@f33g ~]# systemctl start named-chroot [root@f33g ~]# ll /var/named/chroot/etc/named.root.key /etc/named.root.key -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key -rw-r--r--. 1 root named 686 Jun 3 22:47 /var/named/chroot/etc/named.root.key
To repeat what I've said in another thread. I've upgraded 2 F33 VMs. One running named.service the other named-chroot.service. Both upgraded without any problems you noted.
Hi Ed,
Hmmmmm. I screwed up pretty good. I will do this again.
Thank you, -T
On 6/14/21 10:00 PM, ToddAndMargo via users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
Here are my revised, revised note. Ed had to straighten me out on some boo-boos:
Broken bind-chroot repair after upgrading to Fedora 34:
# means root $ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to # search your_domain # nameserver your_IP nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Bind-chroot upgrade from FC3 to FC34 disables the service breaking a server https://bugzilla.redhat.com/show_bug.cgi?id=1972000
To repair:
# systemctl enable named-chroot.service # systemctl start named-chroot.service
Other useful command(s):
# systemctl stop named-chroot.service # systemctl status named-chroot.service # systemctl restart named-chroot.service
3) position named.conf and named.root.key:
When the bind-chroot service starts, it the following into the chroot directory. Don't you do it!
cp /etc/named.conf /var/named/chroot/etc/. cp /etc/named.root.key /var/named/chroot/etc/.
So the ones in your /etc/ directory are your masters.
To trigger this:
a) make sure /etc/named/conf and /etc/named.root.key are your masters b) stop name-bind # systemctl stop named-chroot c) make sure the follow do not exist: /var/named/chroot/etc/named.conf /var/named/chroot/etc/named.root.key d) restart the service # systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by default.
Make sure you do not have two `named.root.key` kicking around. One in /etc/named.root.key and one in /var/named/chroot/etc/named.root.key
The bad one is the one that starts with `managed-keys {`, which is depreciated. The good one starts with `trust-anchors {`
If the one in chroot is bad: # mv /var/named/chroot/etc/named.root.key /var/named/chroot/etc/named.root.key.deprediated # mv /etc/named.root.key /var/named/chroot/etc/named.root.key # ln -s /var/named/chroot/etc/named.root.key /etc/named.root.key
To repair, place the following in your named.conf:
by itself at the bottom: include "/etc/named.root.key"; Note: the actual location is: /var/named/chroot/etc/named.root.key
add the following to your "options" block: dnssec-validation yes;
Other useful command(s):
Validation check:
$ delv @$IP com ds $ delv @208.67.222.123 com ds ; fully validated ...
5) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Note: if you get the following error message,
`/etc/named.root.key:1: option 'managed-keys' is deprecated`
you may have to seperate named.root.conf files. This will read the one in chroot.
Zones: # named-checkzone -t directory domain filename
Note: the "domain name" in the following comes from named.conf zone, not `domainname`. For example:
zone "abc.local" { type master; file "slaves/rent-a-nerd.hosts"; allow-update { key DHCP_UPDATER; }; }; The "domain" is the name of the "zone". "abc.local" in the above
# named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts zone abc.local/IN: loaded serial 265 OK
# named-checkzone -t /var/named/chroot/var/named/slaves 255.168.192.in-addr.arpa abc.hosts.rev zone 255.168.192.in-addr.arpa/IN: loaded serial 213 OK
6) restart the bind-chroot service:
Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123
# systemctl restart named-chroot.service
check for and repair errors with:
$ systemctl status named-chroot.service # tail -f /var/log/messages
On 16/06/2021 09:57, ToddAndMargo via users wrote:
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Well, that didn't happen all my cases of upgrades. So, I doubt that was done by the maintainers.
On 15/06/2021 13:00, ToddAndMargo via users wrote:
Bind-chroot upgrade from FC3 to FC34 disables the service breaking a server https://bugzilla.redhat.com/show_bug.cgi?id=1972000
Since that BZ lacks much in the area of detail why don't you:
1. Install F33 in VM. 2. Configure a named-chroot server 3. Make sure the F33 VM is then fully updated. 4. Collect information on what files you found you needed to fix. 5. Collect information on the status of named-chroot.service 6. Perform an upgrade from F33 to F34 in the attempt to recreate the issue.
Problems which are reproducible have a better chance of being fixed.
On 6/15/21 6:57 PM, ToddAndMargo via users wrote:
On 6/14/21 10:00 PM, ToddAndMargo via users wrote:
Hi All,
Thank you all for the enormous help in me getting bind-chroot working after upgrading to Fedora 34. Here are my notes.
Hope this helps someone else.
-T
I hope this is the last time I hvae to revise this!
add the following to your "options" block: dnssec-validation yes; Broken bind-chroot repair after upgrading to Fedora 34:
# means root $ means user
1) temporary workaround so you can surf the Internet for help:
Change /etc/resolv.conf to # search your_domain # nameserver your_IP nameserver 208.67.222.123
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it.
To repair:
# systemctl enable named-chroot.service # systemctl start named-chroot.service
Other useful command(s):
# systemctl stop named-chroot.service # systemctl status named-chroot.service # systemctl restart named-chroot.service
3) position named.conf and named.root.key:
When the bind-chroot service starts, it copies the following into the chroot directory. Don't you do it! This will fail if it find them there already. Then things get really confusing.
/etc/named.conf copies to /var/named/chroot/etc/. /etc/named.root.key copies to /var/named/chroot/etc/.
The ones in your /etc directory are your masters.
When the named-chroot service is stopped. Make sure you do not have two copies of either or both `/named/conf` and `named.root.key` kicking around:
/etc/named.conf /var/named/chroot/etc/named.conf <-- should not be there when stopped
/etc/named.root.key /var/named/chroot/etc/named.root.key <-- should not be there when stopped
The ones in the chroot directory should have disappeared. Make sure you only have one /etc/named.conf and /etc/named.root.key.
If you have two named.root.key's kicking around, the one that starts with trust-anchors { is the good one.
To trigger the copy:
a) make sure /etc/named/conf and /etc/named.root.key are your masters
b) stop name-bind # systemctl stop named-chroot
c) make sure the follow do not exist: /var/named/chroot/etc/named.conf /var/named/chroot/etc/named.root.key
d) update /etc/named.conf and /etc/named.root.key as desired
e) restart the service # systemctl start named-chroot
4) the new version of bind-chroot enables "dns security validation" by default.
Note: make sure /etc/named.root.key starts with `trust-anchors {`. `managed-keys {` is depreciated.
Note: you should only have one named.root.key. /etc/named.root.key is your master. If the named-chroot service is stopped, the one in /var/named/chroot/etc should disappear.
To properly configure (repair), place the following in your named.conf:
add the following to your "options" block: dnssec-validation yes;
by itself at the bottom: include "/etc/named.root.key";
Then restart the service: # systemctl restart bind-named.service
Other useful command(s):
Validation check:
$ delv @$IP com ds $ delv @208.67.222.123 com ds ; fully validated ...
5) check (and repair) your configurations:
named.conf:
# named-checkconf -l -t /var/named/chroot /etc/named.conf
Zones: # named-checkzone -t directory domain filename
Note: the "domain name" is theh "zone" name from named.conf zone, not `domainname`. For example:
zone "abc.local" { type master; file "slaves/abc.hosts"; allow-update { key DHCP_UPDATER; }; }; The "domain" is the name of the "zone". "abc.local" in the above. You should check both your forward and reverse zones.
Examples: # named-checkzone -t /var/named/chroot/var/named/slaves abc.local abc.hosts zone abc.local/IN: loaded serial 265 OK
# named-checkzone -t /var/named/chroot/var/named/slaves 255.168.192.in-addr.arpa abc.hosts.rev zone 255.168.192.in-addr.arpa/IN: loaded serial 213 OK
6) restart the bind-chroot service:
Change /etc/resolv.conf back to search your_domain nameserver your_IP # nameserver 208.67.222.123
Restart the service: # systemctl restart named-chroot.service
Check for and repair startup errors with:
$ systemctl status named-chroot.service # tail -f /var/log/messages
On 16/06/2021 09:55, ToddAndMargo via users wrote:
Hmmmmm. I screwed up pretty good. I will do this again.
I believe you've made mistakes in other areas.
I believe you've added files, with named stopped in (for example) /var/named/chroot/etc.
This is a normal running named-chroot system.
[root@f33g etc]# ll -i /etc/named.root.key /var/named/chroot/etc/named.root.key 486885 -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key 486885 -rw-r--r--. 1 root named 686 Jun 3 22:47 /var/named/chroot/etc/named.root.key
Notice they have the sam inode. They are, the same file.
If I stop named-chroot then one sees this....
[root@f33g etc]# systemctl stop named-chroot
[root@f33g etc]# ll total 0 drwxr-x---. 1 root named 18 Jun 3 22:46 crypto-policies drwxr-x---. 1 root named 0 Jun 3 22:46 named drwxr-x---. 1 root named 22 Jun 3 22:46 pki
I then copy the named.root.key from /etc into that directory and modify it to contain a "test" line.
[root@f33g etc]# cp /etc/named.root.key . [root@f33g etc]# vi named.root.key [root@f33g etc]# grep -i test named.root.key # Test
And you can see these are not different files.
[root@f33g etc]# ll -i /etc/named.root.key /var/named/chroot/etc/named.root.key 486885 -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key 570722 -rw-r--r--. 1 root root 721 Jun 16 10:41 /var/named/chroot/etc/named.root.key
[root@f33g etc]# ll total 708 drwxr-x---. 1 root named 18 Jun 3 22:46 crypto-policies -rw-r--r--. 2 root root 761 Jan 26 10:35 localtime drwxr-x---. 1 root named 0 Jun 3 22:47 named -rw-r-----. 1 root named 2215 Jun 15 18:44 named.conf -rw-r-----. 1 root named 1029 Jun 3 22:47 named.rfc1912.zones -rw-r--r--. 1 root root 721 Jun 16 10:41 named.root.key drwxr-x---. 1 root named 22 Jun 3 22:46 pki -rw-r--r--. 1 root root 6568 Jun 23 2020 protocols -rw-r-----. 1 root named 100 Apr 21 11:00 rndc.key -rw-r--r--. 1 root root 692252 Jun 23 2020 services
But we still have
[root@f33g etc]# ll -i /etc/named.root.key /var/named/chroot/etc/named.root.key 486885 -rw-r--r--. 1 root named 686 Jun 3 22:47 /etc/named.root.key 570722 -rw-r--r--. 1 root root 721 Jun 16 10:41 /var/named/chroot/etc/named.root.key
Bottom line. Unless one has a special reason for this they should not be adding files into /var/named/chroot/etc/. As they will not be superseded by files which are updated by the dnf operation. If you do manually add files, you should make a note of it and then if necessary manually fix those files to take into account the upgraded files from the rpm.
On 6/15/21 7:00 PM, Ed Greshko wrote:
On 16/06/2021 09:57, ToddAndMargo via users wrote:
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Well, that didn't happen all my cases of upgrades. So, I doubt that was done by the maintainers.
It happens on all of mine. And this is not the first time I have complained about it. I doubt I will be able to prove it to them. I look at my own notes first anyway.
The prior time, they told me I should know I have to enable it, so my problem, not theirs. They said it nicer though.
On 16/06/2021 10:49, ToddAndMargo via users wrote:
On 6/15/21 7:00 PM, Ed Greshko wrote:
On 16/06/2021 09:57, ToddAndMargo via users wrote:
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Well, that didn't happen all my cases of upgrades. So, I doubt that was done by the maintainers.
It happens on all of mine. And this is not the first time I have complained about it. I doubt I will be able to prove it to them. I look at my own notes first anyway.
Another person responding to the BZ also was unable to reproduce.
So, the issue doesn't seem to be very common.
So, best to reproduce in a VM and collect all the information possible.
On 6/15/21 7:54 PM, Ed Greshko wrote:
On 16/06/2021 10:49, ToddAndMargo via users wrote:
On 6/15/21 7:00 PM, Ed Greshko wrote:
On 16/06/2021 09:57, ToddAndMargo via users wrote:
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Well, that didn't happen all my cases of upgrades. So, I doubt that was done by the maintainers.
It happens on all of mine. And this is not the first time I have complained about it. I doubt I will be able to prove it to them. I look at my own notes first anyway.
Another person responding to the BZ also was unable to reproduce.
So, the issue doesn't seem to be very common.
So, best to reproduce in a VM and collect all the information possible.
Those kind of error follow me around like a storm cloud. I am use to it.
I once fixed a problem where five different things affect each other.
A --> affected B --> affected C --> affected D--> affected E --> affected A
I had to fix all five. Drove me nuts for a few hours. I was not the first to have tried either.
On 16/06/2021 11:01, ToddAndMargo via users wrote:
On 6/15/21 7:54 PM, Ed Greshko wrote:
On 16/06/2021 10:49, ToddAndMargo via users wrote:
On 6/15/21 7:00 PM, Ed Greshko wrote:
On 16/06/2021 09:57, ToddAndMargo via users wrote:
2) in their "ultimate wisdom", the rpm maintainers disabled the service after upgrading it. See the following bug I posted on 2021-06-14:
Well, that didn't happen all my cases of upgrades. So, I doubt that was done by the maintainers.
It happens on all of mine. And this is not the first time I have complained about it. I doubt I will be able to prove it to them. I look at my own notes first anyway.
Another person responding to the BZ also was unable to reproduce.
So, the issue doesn't seem to be very common.
So, best to reproduce in a VM and collect all the information possible.
Those kind of error follow me around like a storm cloud. I am use to it.
I once fixed a problem where five different things affect each other.
A --> affected B --> affected C --> affected D--> affected E --> affected A
I had to fix all five. Drove me nuts for a few hours. I was not the first to have tried either.
Fine. But that still doesn't provide enough detail to track down and fix the issue if nobody else can reproduce it.
In other words, help them to help you by reproducing it and collecting as much relevant data.
On 16/06/2021 11:02, ToddAndMargo via users wrote:
On 6/15/21 7:50 PM, Ed Greshko wrote:
On 16/06/2021 10:47, Ed Greshko wrote:
And you can see these are not different files.
I *mean* "are not the same file".
Oh I screwed up a bunch. What did I post four revisions?
My "mistake" was tying brain-fart.
I think you have more configuration issues that are more important.
On 6/15/21 2:30 PM, Ed Greshko wrote:
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named)
You can see the mounts after starting named-chroot.
Hi Ed,
Is this the case with your zone files in the chroot directory too?
-T
A fun double check:
Double check that the idondes are the same:
# stat /etc/named.root.key Device: fd01h/64769d Inode: 60033354 Links: 1
# stat /var/named/chroot/etc/named.root.key Device: fd01h/64769d Inode: 60033354 Links: 1
# stat /etc/named.conf Device: fd01h/64769d Inode: 27396278 Links: 1
# stat /var/named/chroot/etc/named.conf Device: fd01h/64769d Inode: 27396278 Links: 1
inodes match.
:-)
On 17/06/2021 02:25, ToddAndMargo via users wrote:
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named) You can see the mounts after starting named-chroot.
Hi Ed,
Is this the case with your zone files in the chroot directory too?
Yes.
On 6/16/21 11:52 AM, Ed Greshko wrote:
On 17/06/2021 02:25, ToddAndMargo via users wrote:
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named)
You can see the mounts after starting named-chroot.
Hi Ed,
Is this the case with your zone files in the chroot directory too?
Yes.
Thank you!
How about the zone journal files too?
On 17/06/2021 02:59, ToddAndMargo via users wrote:
On 6/16/21 11:52 AM, Ed Greshko wrote:
On 17/06/2021 02:25, ToddAndMargo via users wrote:
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named) You can see the mounts after starting named-chroot.
Hi Ed,
Is this the case with your zone files in the chroot directory too?
Yes.
Thank you!
How about the zone journal files too?
I don't know about those and have never checked. One wouldn't be manually modifying them in any case.
On 6/16/21 12:10 PM, Ed Greshko wrote:
On 17/06/2021 02:59, ToddAndMargo via users wrote:
On 6/16/21 11:52 AM, Ed Greshko wrote:
On 17/06/2021 02:25, ToddAndMargo via users wrote:
named-chroot-setup.service performs a series of bind-mounts (not be confused with bind/named)
You can see the mounts after starting named-chroot.
Hi Ed,
Is this the case with your zone files in the chroot directory too?
Yes.
Thank you!
How about the zone journal files too?
I don't know about those and have never checked. One wouldn't be manually modifying them in any case.
I have been know to delete them at times, but I don't remember why. Maybe because I wanted to advance the serial manually.
Thank you!
On Wed, 2021-06-16 at 12:15 -0700, ToddAndMargo via users wrote:
I have been know to delete them at times, but I don't remember why. Maybe because I wanted to advance the serial manually.
I think if you want to modify *anything* in the zone files, you'll first need to stop the service then delete their journal files, before editing them.
I know I have to do that if I want to modify my zone files, which are also auto-modified by my DHCP server.
Once upon a time, Tim via users users@lists.fedoraproject.org said:
I think if you want to modify *anything* in the zone files, you'll first need to stop the service then delete their journal files, before editing them.
Or just freeze/thaw them - no need to stop the server, and you should never delete the journal files.
On 16/06/2021 11:44, ToddAndMargo via users wrote:
On 6/15/21 8:03 PM, Ed Greshko wrote:
In other words, help them to help you by reproducing it and collecting as much relevant data.
If I ever get it figured out, I will report back
OK.... Just as another date point.
I rebuilt the bind-9.16 source for f33. I had named-chroot enabled, and running. I then did "dnf update *rpm" in a directory containing the new version. I then did "systemctl restart named-chroot".
So I have...
[egreshko@f33x ~]$ cat /etc/fedora-release Fedora release 33 (Thirty Three) [egreshko@f33x ~]$ rpm -q bind bind-9.16.16-1.fc33.x86_64
Everything running just fine and the named-chroot service still shows "enabled".
On 6/16/21 10:27 PM, Ed Greshko wrote:
Everything running just fine and the named-chroot service still shows "enabled".
Every time I have upgraded Fedora to a new release, I have had to "enable" named-chroot. If I ever figure it out, I will definitely get back.
:'(
Maybe it is the universe testing my troubleshooting skills. The tip off is when ping by IP works.
On 17/06/2021 13:41, Todd Chester via users wrote:
On 6/16/21 10:27 PM, Ed Greshko wrote:
Everything running just fine and the named-chroot service still shows "enabled".
Every time I have upgraded Fedora to a new release, I have had to "enable" named-chroot. If I ever figure it out, I will definitely get back.
Did you check your upgrade logs?
On 6/16/21 10:45 PM, Ed Greshko wrote:
On 17/06/2021 13:41, Todd Chester via users wrote:
On 6/16/21 10:27 PM, Ed Greshko wrote:
Everything running just fine and the named-chroot service still shows "enabled".
Every time I have upgraded Fedora to a new release, I have had to "enable" named-chroot. If I ever figure it out, I will definitely get back.
Did you check your upgrade logs?
Don't remember, it has been years between. I did fix them all though.
Tim:
I think if you want to modify *anything* in the zone files, you'll first need to stop the service then delete their journal files, before editing them.
Chris Adams:
Or just freeze/thaw them - no need to stop the server, and you should never delete the journal files.
I can't remember where I found out I had to delete the journals to get changes to the zone files accepted, it's just too many years ago. But if the journals were present, the moment the server started, it re-read the journals to rewrite the zone files.
In the stopped state, the zone files are in their most updated state, and the journal files are not needed. So you shouldn't need to keep them, and I've never been able to detect any adverse effects from deleting them. But keeping them presents the problem I just outlined.
I'm talking about hand-editing the zone file, here. If you were changing records through some interface belonging to BIND, like rndc, that's a different matter. It will be doing it for you, or should be.
On 6/17/21 9:47 PM, Tim via users wrote:
Tim:
I think if you want to modify *anything* in the zone files, you'll first need to stop the service then delete their journal files, before editing them.
Chris Adams:
Or just freeze/thaw them - no need to stop the server, and you should never delete the journal files.
I can't remember where I found out I had to delete the journals to get changes to the zone files accepted, it's just too many years ago. But if the journals were present, the moment the server started, it re-read the journals to rewrite the zone files.
In the stopped state, the zone files are in their most updated state, and the journal files are not needed. So you shouldn't need to keep them, and I've never been able to detect any adverse effects from deleting them. But keeping them presents the problem I just outlined.
I'm talking about hand-editing the zone file, here. If you were changing records through some interface belonging to BIND, like rndc, that's a different matter. It will be doing it for you, or should be.
That is my memory too
-
Chris Adams -
Ed Greshko -
Samuel Sieb -
Tim -
Todd Chester -
ToddAndMargo