Bug 1972022
Summary: | named-checkconf gives confusing depreciated 'managed-keys' message | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Todd <ToddAndMargo> |
Component: | bind | Assignee: | Petr Menšík <pemensik> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 34 | CC: | aegorenk, anon.amish, dns-sig, mruprich, msehnout, pemensik, pzhukov, vonsch, zdohnal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-06-15 20:04:35 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Todd
2021-06-15 04:50:33 UTC
/etc/named.root.key file is configuration file. If it was modified, it will stay the same. Please check command output of "rpm -V bind". It should list file /etc/named.root.key as modified. That means upgrade did not replace that file. Package bind-9.16.16-1.fc34.x86_64 following contents of named.root.key: trust-anchors { # ROOT KEYS: See https://data.iana.org/root-anchors/root-anchors.xml # for current trust anchor information. # # This key (20326) was published in the root zone in 2017. # Servers which were already using the old key (19036) should # roll seamlessly to this new one via RFC 5011 rollover. Servers # being set up for the first time can use the contents of this # file as initializing keys; thereafter, the keys in the # managed key database will be trusted and maintained # automatically. . initial-ds 20326 8 2 "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D"; }; Such configuration does not report any warning on named-checkconf /etc/named.root.key. Do you have copy of files in /var/named/chroot/etc in case named-chroot.service is stopped? Is /etc/named.root.key used from host root /etc and unmodified? I tried upgrade from f33 to f34 and it was smooth. It seems to me your /etc/named.root.key was modified manually, therefore it stayed in original way. If you remove that file and reinstall bind package, it should be installed fresh. For bind, which I am NOT running: # rpm -V bind ......G.. c /etc/named.conf ....L.G.. c /etc/named.root.key For bind-chroot, which I AM running: # rpm -V bind-chroot .....U... c /var/named/chroot/etc/named.conf OH POOP!!! I have TWO named.root.key's. The one in /etc/named.root.key is the good one from Fedora 34 and the one in /var/named/chroot/etc/named.root.key is the depreciated one from Fedora 33. I manually fixed the issue. Now I get: # named-checkconf -l -t /var/named/chroot /etc/named.conf abc.local IN _default master 255.168.192.in-addr.arpa IN _default master 0.0.127.in-addr.arpa IN _default master Question: was the named-chroot RPM post installation script suppose to update named.root.key in chroot, or was I suppose to do it manually? If I am suppose to do this manually, then, not-a-bug. If the post install script is suppose to do this, then change the title and make this the bug Many thanks, -T No, it was not supposed to update ANY file in /var/named/chroot, excluding few empty directories. bind-chroot uses mount --bind to make files from normal /etc available in chroot directory after named-chroot.service start. That means you should NOT copy any file into chroot directory. Instead, use just existing configuration and /etc/named directory for any new configuration snippets. Then the same config should work both for named.service as well as named-chroot.service, whatever you choose to use. I would recommend to stop named-chroot.service and move existing configuration and data copies to normal /etc and /var/named. Then start named-chroot.service again. Check both files point to the same file on file system: stat /etc/named.root.key stat /var/named/chroot/etc/named.root.key Their Device: and Inode: should match. Similar with other files. Make sure to backup it first. Target files in /var/named/chroot should not exist or be empty directory in order to be mounted this way. List of files configured this way is prepared by named-chroot-setup.service, open file /etc/named-chroot.files to get its list. Closing therefore as not bug was found. Anyway, unless you turn off selinux, I think there is no longer good reason for bind-chroot usage. SELinux offers much better protection than offers chroot. Consider using just named.service with SELinux enabled. Hi Oetr, I want to model what I have at my customer sites. One of them runs a peice of specialty software (meanming $$$$$) that does not get along with SELinux. (They won't fix it either.) Thank you for straightening me out. -T My latest. # stat /etc/named.root.key File: /etc/named.root.key Size: 686 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769d Inode: 60033354 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 25/ named) Context: system_u:object_r:etc_t:s0 Access: 2021-06-15 18:43:07.720811481 -0700 Modify: 2021-06-03 07:47:41.000000000 -0700 Change: 2021-06-15 18:42:54.638027506 -0700 Birth: 2021-06-11 23:39:43.081693863 -0700 # stat /var/named/chroot/etc/named.root.key File: /var/named/chroot/etc/named.root.key Size: 686 Blocks: 8 IO Block: 4096 regular file Device: fd01h/64769d Inode: 60033354 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 25/ named) Context: system_u:object_r:etc_t:s0 Access: 2021-06-15 18:43:07.720811481 -0700 Modify: 2021-06-03 07:47:41.000000000 -0700 Change: 2021-06-15 18:42:54.638027506 -0700 Birth: 2021-06-11 23:39:43.081693863 -0700 |