I kinda also wonder why the command simply doesn't output to stdout by default. The *only* reason I've ever run the command "rndc secroots" is to look at the output, that is, checking for the correct DNSKEY root-anchors - which I then need to use "cat" to see... if the file is correctly created... and if I remember where to look for it. If I wanted the output in a file, I can always redirect stdout. Sending output to stdout allows me to easily "filter" the output as well with other tools.
Perhaps Evan can comment? On 09/07/2018 04:45 PM, Petr Mensik wrote: > Hi Mark, > > Dne 7.9.2018 v 10:49 Mark Elkins napsal(a): >> It would probably have been more helpful (speeded up finding the >> problem) if the error message "file 'named.secroots': permission denied" >> also gave the directory name that it was trying to write to? Just a thought. >> Sometimes we don't see the obvious. > It is sort of obvious, if you know the details. Bind changes current > directory to the directory listed in directory option. It actually tries > to open file path "named.secroots", in that directory. In that regard, > it is precise. It is documented, but not very obvious on the first > glance, what it really means. >> >> On 09/06/2018 10:58 PM, Brent Swingle wrote: >>> I moved the file from /etc to /var/named and now I get an additional error >>> line printed in /var/log/messages. >>> >>> Sep 6 15:44:40 ns3 named[15443]: received control channel command >>> 'secroots' >>> Sep 6 15:44:40 ns3 named[15443]: could not open secroots dump file >>> 'named.secroots': permission denied >>> Sep 6 15:44:40 ns3 named[15443]: dumpsecroots failed: permission denied >>> Sep 6 15:44:40 ns3 audit: <audit-1400> { write } for pid=15447 >>> comm="named" name="named.secroots" dev="dm-0" ino=135707451 >>> scontext=system_u:system_r:named_t:s0 >>> tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0 >>> >>> >>> This error also appears in the audit.log file and a search is pointing to >>> SELinux as the hangup. Any pointers on dealing with SELinux would be >>> appreciated. >>> >>> type=AVC msg=audit(1536266680.663:75671): avc: denied { write } for >>> pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 >>> scontext=system_u:system_r:named_t:s0 >>> tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0 >>> >>> >>> I left all of the permissions the same and I think they should be lenient >>> enough: >>> [root@ns3 named]# ls -lh named.secroots >>> -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots >>> >>> >>> >>> >>> -----Original Message----- >>> From: Hugo Salgado-Hernández [mailto:hsalg...@nic.cl] >>> Sent: Thursday, September 06, 2018 3:39 PM >>> To: Brent Swingle <br...@havilandtelco.com> >>> Cc: Evan Hunt <e...@isc.org>; bind-users@lists.isc.org >>> Subject: Re: [BIND] RE: KSK Rollover >>> >>> Hi Brent. >>> In out CentOS box, the named.secroots file is written on >>> /var/named/ >>> >>> You should check permissions there too. >>> >>> Hugo >>> >>> On 20:32 06/09, Brent Swingle wrote: >>>> Evan, >>>> >>>> I ran the command and followed the directions to build out rndc as you >>>> have suggested. However, I am not sure that it made much of a difference. >>>> I should have been a little clearer from the beginning. I had worked >>>> with rndc to issue other commands and had received what appeared to be >>>> valid responses as if rndc was functional. I had somewhat assumed that >>>> rndc was baked in behind the scenes and ready to go. Either way I it has >>>> a rndc.conf and is specified in named.conf at this point. >>>> >>>> I have two of these servers that are identical from an SW perspective. As >>>> a test, I issued "rndc secroots" on the server that I have modified to >>>> configure rndc and observed the following lines appear in the >>>> /var/log/messages file. When I issued "rndc secroots" from the >>>> non-modified file I get the same 3 lines. It acts like the process is >>>> running but it is unable to write output to the named.secroots file. >>>> >>>> Sep 6 14:33:13 ns2 named[31189]: received control channel command >>>> 'secroots' >>>> Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file >>>> 'named.secroots': permission denied Sep 6 14:33:13 ns2 named[31189]: >>>> dumpsecroots failed: permission denied >>>> >>>> >>>> As a test, I manually created named.secroots with weakened permissions to >>>> see if that made a difference but it still won't print output to it. >>>> [root@ns3 etc]# ls -lh named.secroots >>>> -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Evan Hunt [mailto:e...@isc.org] >>>> Sent: Thursday, September 06, 2018 1:22 PM >>>> To: Brent Swingle <br...@havilandtelco.com> >>>> Cc: bind-users@lists.isc.org >>>> Subject: Re: KSK Rollover >>>> >>>> On Thu, Sep 06, 2018 at 05:34:21PM +0000, Brent Swingle wrote: >>>>> This is the command that does not work and the output received: >>>>> [root@ns2 ~]# rndc secroots >>>>> rndc: 'secroots' failed: permission denied >>>>> [root@ns2 ~]# >>>> Have you set up your server to accept rndc commands? >>>> >>>> If not, run "rndc-confgen" and follow the directions. >>>> >>>> -- >>>> Evan Hunt -- e...@isc.org >>>> Internet Systems Consortium, Inc. >>>> >>>> _______________________________________________ >>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>>> unsubscribe from this list >>>> >>>> bind-users mailing list >>>> bind-users@lists.isc.org >>>> https://lists.isc.org/mailman/listinfo/bind-users >>>> >>> _______________________________________________ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users