check_bind.sh pluguin
Re: check_bind.sh pluguin
++ Name Server Statistics ++
598 IPv4 requests received
250 requests with EDNS(0) received
598 responses sent
250 responses with EDNS(0) sent
479 queries resulted in successful answer
15 queries resulted in authoritative answer
581 queries resulted in non authoritative answer
31 queries resulted in nxrrset
2 queries resulted in SERVFAIL
86 queries resulted in NXDOMAIN
46 queries caused recursion
Yes, the nagios user can read the file. One thing I did notice, and this may or may not be releated, is that I have a file system loop in the /var/named folder. For instance if I were to run " find -type f -name rndc" I would get back "File system loop detected; `/var/named/chroot/var/named' is part of the same file system loop as `/var/named'."
I wonder how that happened and how I can safely fix it.
598 IPv4 requests received
250 requests with EDNS(0) received
598 responses sent
250 responses with EDNS(0) sent
479 queries resulted in successful answer
15 queries resulted in authoritative answer
581 queries resulted in non authoritative answer
31 queries resulted in nxrrset
2 queries resulted in SERVFAIL
86 queries resulted in NXDOMAIN
46 queries caused recursion
Yes, the nagios user can read the file. One thing I did notice, and this may or may not be releated, is that I have a file system loop in the /var/named folder. For instance if I were to run " find -type f -name rndc" I would get back "File system loop detected; `/var/named/chroot/var/named' is part of the same file system loop as `/var/named'."
I wonder how that happened and how I can safely fix it.
Re: check_bind.sh pluguin
I don't think the chroot loop is a problem according to this:
http://unix.stackexchange.com/questions ... p-detected
Also the nagios user has access to all the files under chroot that it needs.
http://unix.stackexchange.com/questions ... p-detected
Also the nagios user has access to all the files under chroot that it needs.
-
jdalrymple
- Skynet Drone
- Posts: 2620
- Joined: Wed Feb 11, 2015 1:56 pm
Re: check_bind.sh pluguin
I'm not 100% clear - if you just run the plugin from the command line (no nrpe or nagios involved at all) do you get output besides a bunch of zeros?
Did you note these comments from the Exchange?
Did you note these comments from the Exchange?
The script required a few tweeks to work. 1-put nagios in the named group, 2-add "sudo rndc stats"
That was it and it worked fine.
Re: check_bind.sh pluguin
No, command line run only still returns all values zeroed out.
I did see that comment, however I took it to mean that it took him a couple weeks to get it to work at all. Thanks for pointing that out I suppose I'll just wait it out.
I did see that comment, however I took it to mean that it took him a couple weeks to get it to work at all. Thanks for pointing that out I suppose I'll just wait it out.
Re: check_bind.sh pluguin
Let us know if there is anything else we can do, in the mean time we'll be waiting for your feedback.
Thanks!
Thanks!
Former Nagios Employee.
me.
me.
Re: check_bind.sh pluguin
Actually yes. Apparently I am misreading stuff all over the place. In the quote that jdalrymple posted, I read "tweeks" as weeks. I Have already done these 2 things. My nagios user is in the "named" group and the nagios user can sudo rndc stats. Now, I may be misinterpreting something again, and would like more help.
What exactly does the person mean when they say "add sudo rndc stats"? Add that to what? Where?
What exactly does the person mean when they say "add sudo rndc stats"? Add that to what? Where?
Re: check_bind.sh pluguin
I really don't think what I described above is the problem. I have verified those 2 things. However - I was looking back over the check_bind.sh script and noticed it said something about using this in a chroot-bind environment, which I am doing. It says:
"If you're running BIND in a chroot environment, use this"
echo " option to define a path to be chrooted. Please adjust also"
echo " your sudo configuration to enable the Nagios user to chroot!"
Could this be the problem? If so how do I enable the nagios user to "chroot"?
"If you're running BIND in a chroot environment, use this"
echo " option to define a path to be chrooted. Please adjust also"
echo " your sudo configuration to enable the Nagios user to chroot!"
Could this be the problem? If so how do I enable the nagios user to "chroot"?
- Box293
- Too Basu
- Posts: 5126
- Joined: Sun Feb 07, 2010 10:55 pm
- Location: Deniliquin, Australia
- Contact:
Re: check_bind.sh pluguin
Check the permissions on /tmp/named.stats.tmp and make sure the nagios user has permission to update it. This problem can occur because you may have originally tested it as the root user and the nagios user does not have permission to access that file. Just delete it if you want and then execute it via check_nrpe and see if it works.linuser wrote: Problem is, this still does not append data to /tmp/named.stats.tmp and /var/named/data/named.stats.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Re: check_bind.sh pluguin
Yea, I got that to work several posts back. The nagios user has access and can dump stats to the files in both the /tmp and the /var/named/data folders. The problem now is that when nagios polls or when I manually run the check_bind.sh scripts all the performance data has "0" values.Box293 wrote: Check the permissions on /tmp/named.stats.tmp and make sure the nagios user has permission to update it. This problem can occur because you may have originally tested it as the root user and the nagios user does not have permission to access that file. Just delete it if you want and then execute it via check_nrpe and see if it works.
For example:
Bind9 is running. 0 successfull requests, 0 referrals, 0 nxdomains since last check. | 'success'=0 'referral'=0 'nxrrset'=0 'nxdomain'=0 'recursion'=0 'failure'=0 'duplicate'=0 'dropped'=0
So zeros across the board even though stats are being dumped in /tmp/named.stats.tmp and /var/named/data/named.stats.
Re: check_bind.sh pluguin
Now here is something interesting. When there is a stat dump, the named.stats.tmp file in /tmp get modified however the "statistics dump" at the timestamp has no data compared to the statistics dump in /var/named/data/named.stats.
i.e., from named.stats.tmp at 1443039719
This is the last line of the file, no data after that. However, in /var/named/data/named.stats I see this at that same timestamp.
Now I wonder if this is normal or a problem.?
i.e., from named.stats.tmp at 1443039719
Code: Select all
+++ Statistics Dump +++ (1443039719)Code: Select all
+++ Statistics Dump +++ (1443039719)
++ Incoming Requests ++
15 QUERY
++ Incoming Queries ++
15 A
++ Outgoing Queries ++
[View: default]
44 A
7 NS
36 AAAA
3 DS
8 DNSKEY
12 DLV
[View: _bind]
++ Name Server Statistics ++
15 IPv4 requests received
15 responses sent
15 queries resulted in successful answer
15 queries resulted in non authoritative answer
2 queries caused recursion
++ Zone Maintenance Statistics ++
2 IPv4 notifies sent
++ Resolver Statistics ++
[Common]
[View: default]
64 IPv4 queries sent
46 IPv6 queries sent
62 IPv4 responses received
2 NXDOMAIN received
43 query retries
2 query timeouts
22 IPv4 NS address fetches
24 IPv6 NS address fetches
13 DNSSEC validation attempted
9 DNSSEC validation succeeded
4 DNSSEC NX validation succeeded
43 queries with RTT 10-100ms
19 queries with RTT 100-500ms