Re: [BIND] RE: KSK Rollover
On Fri, Sep 07, 2018 at 06:15:59PM +0200, Mark Elkins wrote: > 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? For a long time, the text that could be sent back over the rndc channel from named was limited to a smallish fixed-size buffer -- I think it was 2K or something. If an rndc command produced output, but we couldn't be sure the output would be smaller than that buffer, we'd write it to a file instead. At some point -- in 9.11, I think? -- it occurred to us that the size limitation wasn't a law of physics, and we could get rid of it. So now there are several rndc commands that print useful amounts of text, but since "secroots" already existed before that change, we left its default behavior the same as it had been before, and added a "-" option to return text over the command channel. -- 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
Re: [BIND] RE: KSK Rollover
I'm aware of: rndc managed-keys status
I'm also aware of: rndc secroots -
(a Hypen at the end of "rndc secroots" will send output to stdout)
I'm just not sure how long the 'hyphen' argument has been around for but
vaguely remember a similar discussion from long ago.
It looks like someone else also asked the same question but wasn't
allowed to change the default behaviour. :-(
So, if you are having issues running "rndc secroots", a quick suggestion
would be to try appending a 'hyphen' ('-') as an additional argument and
see if that helps.
On 09/07/2018 06:46 PM, Tony Finch wrote:
> Mark Elkins wrote:
>
>> I kinda also wonder why the command simply doesn't output to stdout by
>> default.
> Historical reasons :-) BIND 9.11 and later have `rndc managed-keys` which
> is rather more user-friendly. I get the impression that the root rollover
> guides are using `rndc secroots` because that works in all the versions
> that support RFC 5011 so it ends up being simpler to explain.
>
> Tony.
--
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
Re: [BIND] RE: KSK Rollover
Mark Elkins wrote: > I kinda also wonder why the command simply doesn't output to stdout by > default. Historical reasons :-) BIND 9.11 and later have `rndc managed-keys` which is rather more user-friendly. I get the impression that the root rollover guides are using `rndc secroots` because that works in all the versions that support RFC 5011 so it ends up being simpler to explain. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet, Irish Sea: Northwest backing southwest 4 or 5, increasing 6 at times. Moderate throughout in southwest Fastnet, but elsewhere slight or moderate. Rain later. Good, occasionally poor later. ___ 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
Re: [BIND] RE: KSK Rollover
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: { 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
>>> Cc: Evan Hunt ; 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[31
Re: [BIND] RE: KSK Rollover
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: { 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
>> Cc: Evan Hunt ; 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
>>> Cc: bind-users@lists.isc.org
>>> Subject: Re: KSK Rollover
>>>
>>> On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote:
>>>> This is the command that does not
Re: [BIND] RE: KSK Rollover
Hi, also a few notes to it. Dne 7.9.2018 v 04:05 Brent Swingle napsal(a): > This matter has been resolved with input from Evan. I was able to add a file > path for secroots to the named.conf file and push the output file to a temp > directory that was not permission restricted. > > secroots-file "/tmp/named.secroots" ; Instead, "/var/named/data/named.secroots" or maybe "/run/named/named.secroots" should be used. In Fedora, it should already have write access to /var/named directory itself also from daemon. Should be already for update on supported releases. > > > Ultimately when I ran "rndc secroots" it created the output file here: > > /tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots > > > The data in the file seems to be as desired if I understand the KSK Rollover > test correctly, I should see 20326 which pertains to the new key: > > [root@ns3 tmp]# cat named.secroots > 06-Sep-2018 18:47:16.190 > > Start view internal-in > > ./RSASHA256/20326 ; managed > ./RSASHA256/19036 ; managed > dlv.isc.org/RSASHA1/19297 ; managed > > Start view external-in > > ./RSASHA256/20326 ; managed > ./RSASHA256/19036 ; managed > dlv.isc.org/RSASHA1/19297 ; managed > > Start view external-chaos > > dumpsecroots failed: not found > > > > > I did not fully try Carl's input below but I believe it would have worked as > well. I had performed a "chmod 770 /var/named" but I did not follow it up > with the SELinux modification. The last error I had was SELinux barking so > I'd anticipate his suggestion was the correct one. > > Does the 'named' user have write access to /var/named? The default > redhat setup has /var/named as 0750, with /var/named/data as 0770. Also, > the default redhat selinux config prevents named writing to /var/named. > > chmod 770 /var/named > setsebool -P named_write_master_zones=true > rndc secroots It should not be required on upcoming RHEL 7 versions. named_write_master_zones would be turned on by default in next minor release. Also permissions would be fixed to allow writing by default. It would save us to replace all paths in config file to write into /var/named/data subdirectory. I hope also to reduce the confusion. > > > > > Thanks everyone for assisting with this matter. > > > > ___ > 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 > -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 ___ 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
Re: [BIND] RE: KSK Rollover
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.
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: { 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
> Cc: Evan Hunt ; 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
>> Cc: bind-users@lists.isc.org
>> Subject: Re: KSK Rollover
>>
>> On Thu, Sep 06, 2018 at 05:34:21PM +, 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
>>
> __
RE: [BIND] RE: KSK Rollover
The kicker was probably this line:
Sep 6 15:44:40 ns3 audit: { 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
The SELinux context that BIND runs in on a red hat system doesn't have access
to write to a file of etc_t. After moving the file to /var/named somewhere, a
restorecon should have reset it to something like var_named_t or
var_named_cache_t which it would have had access to write to.
>From the line, 'permissive=0' so it suggests a SELinux-enforcing environment.
Stuart
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Brent
Swingle
Sent: Friday, 7 September 2018 12:05 PM
To: bind-users@lists.isc.org
Subject: Re: [BIND] RE: KSK Rollover
This matter has been resolved with input from Evan. I was able to add a file
path for secroots to the named.conf file and push the output file to a temp
directory that was not permission restricted.
secroots-file "/tmp/named.secroots" ;
Ultimately when I ran "rndc secroots" it created the output file here:
/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots
The data in the file seems to be as desired if I understand the KSK Rollover
test correctly, I should see 20326 which pertains to the new key:
[root@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190
Start view internal-in
./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed
Start view external-in
./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed
Start view external-chaos
dumpsecroots failed: not found
I did not fully try Carl's input below but I believe it would have worked as
well. I had performed a "chmod 770 /var/named" but I did not follow it up with
the SELinux modification. The last error I had was SELinux barking so I'd
anticipate his suggestion was the correct one.
Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.
chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots
Thanks everyone for assisting with this matter.
___
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
Re: [BIND] RE: KSK Rollover
This matter has been resolved with input from Evan. I was able to add a file path for secroots to the named.conf file and push the output file to a temp directory that was not permission restricted. secroots-file "/tmp/named.secroots" ; Ultimately when I ran "rndc secroots" it created the output file here: /tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots The data in the file seems to be as desired if I understand the KSK Rollover test correctly, I should see 20326 which pertains to the new key: [root@ns3 tmp]# cat named.secroots 06-Sep-2018 18:47:16.190 Start view internal-in ./RSASHA256/20326 ; managed ./RSASHA256/19036 ; managed dlv.isc.org/RSASHA1/19297 ; managed Start view external-in ./RSASHA256/20326 ; managed ./RSASHA256/19036 ; managed dlv.isc.org/RSASHA1/19297 ; managed Start view external-chaos dumpsecroots failed: not found I did not fully try Carl's input below but I believe it would have worked as well. I had performed a "chmod 770 /var/named" but I did not follow it up with the SELinux modification. The last error I had was SELinux barking so I'd anticipate his suggestion was the correct one. Does the 'named' user have write access to /var/named? The default redhat setup has /var/named as 0750, with /var/named/data as 0770. Also, the default redhat selinux config prevents named writing to /var/named. chmod 770 /var/named setsebool -P named_write_master_zones=true rndc secroots Thanks everyone for assisting with this matter. ___ 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
RE: [BIND] RE: KSK Rollover
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2018-09-06 at 20:58 +, Brent Swingle wrote: > 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 Does the 'named' user have write access to /var/named? The default redhat setup has /var/named as 0750, with /var/named/data as 0770. Also, the default redhat selinux config prevents named writing to /var/named. chmod 770 /var/named setsebool -P named_write_master_zones=true rndc secroots -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAluRnR8ACgkQL6j7milTFsF2FgCfSt7RIVrO8lK8izQlNn9TadPp F58Anj81TEmtg34Cpjhh3DqMWEQFUCxA =NwIr -END PGP SIGNATURE- ___ 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
RE: [BIND] RE: KSK Rollover
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: { 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
Cc: Evan Hunt ; 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
> Cc: bind-users@lists.isc.org
> Subject: Re: KSK Rollover
>
> On Thu, Sep 06, 2018 at 05:34:21PM +, 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
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 > Cc: bind-users@lists.isc.org > Subject: Re: KSK Rollover > > On Thu, Sep 06, 2018 at 05:34:21PM +, 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 > signature.asc Description: PGP signature ___ 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
