Re: [Nagios-users] Monitor Fileserver
Oh yeah been there done that ...Still should be enough to monitor the diskspace issue.There you go Josh, install one of the common SNMP toolsets (most linux distros have it already) and if unsure do an snmpwalk to see what infos you might get. Cheers,HansOn 2/27/06, Frank, Jason [EMAIL PROTECTED] wrote: NetApp certainly has SNMP support. It's not wonderful, it only supports v1. As a result, it has the usual problems with overflowing COUNTER32's. But, it's fairly easy to set up and will let you monitor just about anything you want. Jason From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Hans EngelenSent: Monday, February 27, 2006 4:01 PMTo: Nagios Users MailinglistSubject: Re: [Nagios-users] Monitor Fileserver Ah, i see. Question ... is there no SNMP access for these blackboxes ? Most blackboxes do from my experience (though I usually steer clear of them so I haven't used that many of them really). SNMP access will most likely allow you to poll a fair number of interesting metrics. Free space, network utilization, load ... that kind of thing. Worth checking into should my other suggestion fail. Incidentally don't forget to give the service-user enough rights to do its work, i.e. on the share and also for other checks it might have to do or you might get other unexplained errors. Start out with adding it to the local admins group to test the general idea first (and get a baseline check)then bump it down to normal user and add rights as you need. But I am sure you know that drill. Cheers, Hans On 2/27/06, Josh [EMAIL PROTECTED] wrote: Hans / Ryan,Thanks for your input...I thought the question might arise about why don't I monitor the server housing the shares... well, theproblem there is the machine is a NetApp device (notrunning windows and won't allow me to install anythingon it of course... it's an appliance).I've tried touching the /root/.smb/smb.conf...theproblem is most likely related to the nagios usercan't even see inside /root.I like your idea of mapping the drives under thenagios user and then running the service as the nagios user... I'll give that a shot.On a side note, I did try getting the nrpe checks towork on the windows server but am getting thefollowing error:CScript Error: Execution of the Windows Script Host failed. (Catastrophic failure)A little research shows it is most likely related to asoftware security policy in place.Anyone on thislist know what I need to change?Thanks again for all your help. Josh--- Hans Engelen [EMAIL PROTECTED] wrote: Dangit replied privately and not to the list, anyway heres a forward. Also just checked the /root/.smb/smb.conf reference is actually a workaround for a problem with samba's libsmbclient in the perl module Filesys::SmbClient (used by check_smb_shares.pl). Aparantly libsmbclient segfaults if it does not exist. Therefor if it does not exist the perl module Filesys::SmbClient tries to make one (an empty one) but has no permission to do so from what you wrote. I supose you could make it yourself (touch /root/.smb/smb.conf; chmod og+r /root/.smb/smb.conf). Maybe that will solve your issues with that particular check allowing you to use it to monitor the remote shares you spoke of Cheers, Hans On 2/27/06, Hans Engelen [EMAIL PROTECTED] wrote: For mapped drives that is quite normal since mapped drives are, barring a small number of special cases, only accessible for the user that did the actual mapping. It's the same problem you get for other NT services trying to access a drive mapping made from another user. Also most likely your pNSClient (or NC_Net or NSClient++) or whatever agent you have running on the Windows box is running under the System security setting. This security context is only valid for that windows box internally and as such has no credentials to access anything beyond that machine. This includes (but is not limited to) shares. Theoretically you could of course run your Nagios Agent under an actual user account, log in interactively on that same account and create a persistent mapping (net use * \\server\share /persist:yes, if memory serves) to the shares in question. Since the service will use the same profile when logging in that should solve the issue. But why even monitor a remote disk in this way. Just install the Nagios Agent on the server that houses the share and monitor it directly instead of indirectly (with all the quirks and pitfalls that come with it).Of course in this case the check_smb_shares is a solution too. As to why it insists on writing to /root/.smb/smb.conf is a bit strange. Possibly this was defined somewhere in the check_smb_shares.pl file. Open it up in a text editor and see. Cheers, Hans Cheers, Hans On 2/27/06, Ryan Wilcox [EMAIL PROTECTED] wrote: yeah... i got the same error as you did with a mapped drive. we aren't
RE: [Nagios-users] Monitor Fileserver
-Original Message- From: [EMAIL PROTECTED] [mailto:nagios-users- [EMAIL PROTECTED] On Behalf Of Josh Sent: Monday, February 27, 2006 10:19 AM To: nagios-users@lists.sourceforge.net Subject: [Nagios-users] Monitor Fileserver Does anyone have any suggestions as to how to monitor network drive (fileserver) status from Nagios? I'm trying to get the check_smb_shares.pl (from nagiosexchange.org) but keep getting the following error when Nagios executes the check: **ePN 'check_smb_shares.pl' Can't create /root/.smb/smb.conf : Permission denied Not sure why when the Nagios binary executes the script it wants to use /root/ (Nagios runs as the user nagios). Any other suggestions on monitoring network drives? we use something like this to check disks on Windows machines: check_nt_disk!M!70!90 where M is the drive we are checking and 70/90 are our limits. there are other nt commands that can be used like: check_nt_cpuload check_nt_procstate and so on... not sure this answers your question, would need to know exactly what you want to monitor. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
RE: [Nagios-users] Monitor Fileserver
I'm assuming you are using NRPE and executing the check_nt_disk from a windows machine... I might end up doing that. I was attempting to use smb checks directly from the linux box running Nagios. --- Ryan Wilcox [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:nagios-users- [EMAIL PROTECTED] On Behalf Of Josh Sent: Monday, February 27, 2006 10:19 AM To: nagios-users@lists.sourceforge.net Subject: [Nagios-users] Monitor Fileserver Does anyone have any suggestions as to how to monitor network drive (fileserver) status from Nagios? I'm trying to get the check_smb_shares.pl (from nagiosexchange.org) but keep getting the following error when Nagios executes the check: **ePN 'check_smb_shares.pl' Can't create /root/.smb/smb.conf : Permission denied Not sure why when the Nagios binary executes the script it wants to use /root/ (Nagios runs as the user nagios). Any other suggestions on monitoring network drives? we use something like this to check disks on Windows machines: check_nt_disk!M!70!90 where M is the drive we are checking and 70/90 are our limits. there are other nt commands that can be used like: check_nt_cpuload check_nt_procstate and so on... not sure this answers your question, would need to know exactly what you want to monitor. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Monitor Fileserver
Dangit replied privately and not to the list, anyway heres a forward.Also just checked the /root/.smb/smb.conf reference is actually a workaround for a problem with samba's libsmbclient in the perl module Filesys::SmbClient (used by check_smb_shares.pl). Aparantly libsmbclient segfaults if it does not exist. Therefor if it does not exist the perl module Filesys::SmbClient tries to make one (an empty one) but has no permission to do so from what you wrote. I supose you could make it yourself (touch /root/.smb/smb.conf; chmod og+r /root/.smb/smb.conf). Maybe that will solve your issues with that particular check allowing you to use it to monitor the remote shares you spoke of Cheers,HansOn 2/27/06, Hans Engelen [EMAIL PROTECTED] wrote: For mapped drives that is quite normal since mapped drives are, barring a small number of special cases, only accessible for the user that did the actual mapping. It's the same problem you get for other NT services trying to access a drive mapping made from another user. Also most likely your pNSClient (or NC_Net or NSClient++) or whatever agent you have running on the Windows box is running under the System security setting. This security context is only valid for that windows box internally and as such has no credentials to access anything beyond that machine. This includes (but is not limited to) shares. Theoretically you could of course run your Nagios Agent under an actual user account, log in interactively on that same account and create a persistent mapping (net use * \\server\share /persist:yes, if memory serves) to the shares in question. Since the service will use the same profile when logging in that should solve the issue. But why even monitor a remote disk in this way. Just install the Nagios Agent on the server that houses the share and monitor it directly instead of indirectly (with all the quirks and pitfalls that come with it). Of course in this case the check_smb_shares is a solution too. As to why it insists on writing to /root/.smb/smb.conf is a bit strange. Possibly this was defined somewhere in the check_smb_shares.pl file. Open it up in a text editor and see. Cheers,HansCheers,HansOn 2/27/06, Ryan Wilcox [EMAIL PROTECTED] wrote: yeah... i got the same error as you did with a mapped drive. we aren'tmonitoring any mapped drives right now, hence the confusion. not sure about the mapped drives... anyone else have an idea for josh? -Original Message- From: Josh [mailto: [EMAIL PROTECTED]] Sent: Monday, February 27, 2006 11:38 AM To: Ryan Wilcox; nagios-users@lists.sourceforge.net Subject: RE: [Nagios-users] Monitor Fileserver Hmm...Got it working for local drives on the windows box but I get an Invalid drive error from the check_nt script when I check a drive that is mapped. Any way to check networked drives on that windows box?Or will I have to go with nrpe checks for that? --- Ryan Wilcox [EMAIL PROTECTED] wrote: actually i am using check_nt right from the nagios (fedora core 4) box. ./check_nt -H 10.0.0.32 -v USEDDISKSPACE -lc -w 75 -c 90 output looks like: c:\ - total: 74.52 Gb - used: 52.98 Gb (71%) - free 21.54 Gb (29%) | 'c:\ Used Space'=52.98Gb;55.89;67.07;0.00;74.52 -Original Message- From: Josh [mailto:[EMAIL PROTECTED]] Sent: Monday, February 27, 2006 10:57 AM To: Ryan Wilcox; nagios-users@lists.sourceforge.net Subject: RE: [Nagios-users] Monitor Fileserver I'm assuming you are using NRPE and executing the check_nt_disk from a windows machine...I might end up doing that. I was attempting to use smb checks directly from the linux box running Nagios. --- Ryan Wilcox [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED][mailto: nagios-users- [EMAIL PROTECTED]] On Behalf Of Josh Sent: Monday, February 27, 2006 10:19 AM To: nagios-users@lists.sourceforge.net Subject: [Nagios-users] Monitor Fileserver Does anyone have any suggestions as to how tomonitor network drive (fileserver) status from Nagios?I'm trying to get the check_smb_shares.pl (from nagiosexchange.org) but keep getting thefollowing error when Nagios executes the check: **ePN 'check_smb_shares.pl' Can't create /root/.smb/smb.conf : Permission denied Not sure why when the Nagios binary executes the script it wants to use /root/ (Nagios runs as theuser nagios). Any other suggestions on monitoring networkdrives? we use something like this to check disks on Windowsmachines: check_nt_disk!M!70!90 where M is the drive we are checking and 70/90 areour limits. there are other nt commands that can be used like: check_nt_cpuloadcheck_nt_procstate and so on... not sure this answers your question, would need toknow exactly what you want to monitor
Re: [Nagios-users] Monitor Fileserver
Hans / Ryan, Thanks for your input... I thought the question might arise about why don't I monitor the server housing the shares... well, the problem there is the machine is a NetApp device (not running windows and won't allow me to install anything on it of course... it's an appliance). I've tried touching the /root/.smb/smb.conf... the problem is most likely related to the nagios user can't even see inside /root. I like your idea of mapping the drives under the nagios user and then running the service as the nagios user... I'll give that a shot. On a side note, I did try getting the nrpe checks to work on the windows server but am getting the following error: CScript Error: Execution of the Windows Script Host failed. (Catastrophic failure) A little research shows it is most likely related to a software security policy in place. Anyone on this list know what I need to change? Thanks again for all your help. Josh --- Hans Engelen [EMAIL PROTECTED] wrote: Dangit replied privately and not to the list, anyway heres a forward. Also just checked the /root/.smb/smb.conf reference is actually a workaround for a problem with samba's libsmbclient in the perl module Filesys::SmbClient (used by check_smb_shares.pl). Aparantly libsmbclient segfaults if it does not exist. Therefor if it does not exist the perl module Filesys::SmbClient tries to make one (an empty one) but has no permission to do so from what you wrote. I supose you could make it yourself (touch /root/.smb/smb.conf; chmod og+r /root/.smb/smb.conf). Maybe that will solve your issues with that particular check allowing you to use it to monitor the remote shares you spoke of Cheers, Hans On 2/27/06, Hans Engelen [EMAIL PROTECTED] wrote: For mapped drives that is quite normal since mapped drives are, barring a small number of special cases, only accessible for the user that did the actual mapping. It's the same problem you get for other NT services trying to access a drive mapping made from another user. Also most likely your pNSClient (or NC_Net or NSClient++) or whatever agent you have running on the Windows box is running under the System security setting. This security context is only valid for that windows box internally and as such has no credentials to access anything beyond that machine. This includes (but is not limited to) shares. Theoretically you could of course run your Nagios Agent under an actual user account, log in interactively on that same account and create a persistent mapping (net use * \\server\share /persist:yes, if memory serves) to the shares in question. Since the service will use the same profile when logging in that should solve the issue. But why even monitor a remote disk in this way. Just install the Nagios Agent on the server that houses the share and monitor it directly instead of indirectly (with all the quirks and pitfalls that come with it). Of course in this case the check_smb_shares is a solution too. As to why it insists on writing to /root/.smb/smb.conf is a bit strange. Possibly this was defined somewhere in the check_smb_shares.pl file. Open it up in a text editor and see. Cheers, Hans Cheers, Hans On 2/27/06, Ryan Wilcox [EMAIL PROTECTED] wrote: yeah... i got the same error as you did with a mapped drive. we aren't monitoring any mapped drives right now, hence the confusion. not sure about the mapped drives... anyone else have an idea for josh? -Original Message- From: Josh [mailto:[EMAIL PROTECTED] Sent: Monday, February 27, 2006 11:38 AM To: Ryan Wilcox; nagios-users@lists.sourceforge.net Subject: RE: [Nagios-users] Monitor Fileserver Hmm... Got it working for local drives on the windows box but I get an Invalid drive error from the check_nt script when I check a drive that is mapped. Any way to check networked drives on that windows box? Or will I have to go with nrpe checks for that? --- Ryan Wilcox [EMAIL PROTECTED] wrote: actually i am using check_nt right from the nagios (fedora core 4) box. ./check_nt -H 10.0.0.32 -v USEDDISKSPACE -lc -w 75 -c 90 output looks like: c:\ - total: 74.52 Gb - used: 52.98 Gb (71%) - free 21.54 Gb (29%) | 'c:\ Used Space'=52.98Gb;55.89;67.07;0.00;74.52 -Original Message- From: Josh [mailto:[EMAIL PROTECTED] Sent: Monday, February 27, 2006 10:57 AM To: Ryan Wilcox; nagios-users@lists.sourceforge.net Subject: RE: [Nagios-users] Monitor Fileserver I'm assuming you are using NRPE and executing the check_nt_disk from a windows machine... I might end up doing that. I was attempting to use smb checks directly from the linux box running Nagios. --- Ryan Wilcox [EMAIL
Re: [Nagios-users] Monitor Fileserver
Ah, i see. Question ... is there no SNMP access for these blackboxes ? Most blackboxes do from my experience (though I usually steer clear of them so I haven't used that many of them really). SNMP access will most likely allow you to poll a fair number of interesting metrics. Free space, network utilization, load ... that kind of thing. Worth checking into should my other suggestion fail. Incidentally don't forget to give the service-user enough rights to do its work, i.e. on the share and also for other checks it might have to do or you might get other unexplained errors. Start out with adding it to the local admins group to test the general idea first (and get a baseline check)then bump it down to normal user and add rights as you need. But I am sure you know that drill. Cheers, Hans On 2/27/06, Josh [EMAIL PROTECTED] wrote: Hans / Ryan,Thanks for your input...I thought the question might arise about why don't I monitor the server housing the shares... well, theproblem there is the machine is a NetApp device (notrunning windows and won't allow me to install anythingon it of course... it's an appliance). I've tried touching the /root/.smb/smb.conf...theproblem is most likely related to the nagios usercan't even see inside /root.I like your idea of mapping the drives under thenagios user and then running the service as the nagios user... I'll give that a shot.On a side note, I did try getting the nrpe checks towork on the windows server but am getting thefollowing error:CScript Error: Execution of the Windows Script Host failed. (Catastrophic failure)A little research shows it is most likely related to asoftware security policy in place.Anyone on thislist know what I need to change?Thanks again for all your help. Josh--- Hans Engelen [EMAIL PROTECTED] wrote: Dangit replied privately and not to the list, anyway heres a forward. Also just checked the /root/.smb/smb.conf reference is actually a workaround for a problem with samba's libsmbclient in the perl module Filesys::SmbClient (used by check_smb_shares.pl). Aparantly libsmbclient segfaults if it does not exist. Therefor if it does not exist the perl module Filesys::SmbClient tries to make one (an empty one) but has no permission to do so from what you wrote. I supose you could make it yourself (touch /root/.smb/smb.conf; chmod og+r /root/.smb/smb.conf). Maybe that will solve your issues with that particular check allowing you to use it to monitor the remote shares you spoke of Cheers, Hans On 2/27/06, Hans Engelen [EMAIL PROTECTED] wrote: For mapped drives that is quite normal since mapped drives are, barring a small number of special cases, only accessible for the user that did the actual mapping. It's the same problem you get for other NT services trying to access a drive mapping made from another user. Also most likely your pNSClient (or NC_Net or NSClient++) or whatever agent you have running on the Windows box is running under the System security setting. This security context is only valid for that windows box internally and as such has no credentials to access anything beyond that machine. This includes (but is not limited to) shares. Theoretically you could of course run your Nagios Agent under an actual user account, log in interactively on that same account and create a persistent mapping (net use * \\server\share /persist:yes, if memory serves) to the shares in question. Since the service will use the same profile when logging in that should solve the issue. But why even monitor a remote disk in this way. Just install the Nagios Agent on the server that houses the share and monitor it directly instead of indirectly (with all the quirks and pitfalls that come with it). Of course in this case the check_smb_shares is a solution too. As to why it insists on writing to /root/.smb/smb.conf is a bit strange. Possibly this was defined somewhere in the check_smb_shares.pl file. Open it up in a text editor and see. Cheers, Hans Cheers, Hans On 2/27/06, Ryan Wilcox [EMAIL PROTECTED] wrote: yeah... i got the same error as you did with a mapped drive. we aren't monitoring any mapped drives right now, hence the confusion. not sure about the mapped drives... anyone else have an idea for josh? -Original Message-From: Josh [mailto: [EMAIL PROTECTED]]Sent: Monday, February 27, 2006 11:38 AMTo: Ryan Wilcox; nagios-users@lists.sourceforge.netSubject: RE: [Nagios-users] Monitor Fileserver Hmm...Got it working for local drives on the windowsbox but I get an Invalid drive error from thecheck_nt script when I check a drive that is mapped.Any way to check networked drives on that windows box? Or will I have to go with nrpe checks for that? --- Ryan Wilcox [EMAIL PROTECTED] wrote:actually i am using check_nt right from the nagios (fedora core 4) box. ./check_nt -H 10.0.0.32 -v USEDDISKSPACE -lc -w 75 -c 90 output looks
RE: [Nagios-users] Monitor Fileserver
NetApp certainly has SNMP support. It's not wonderful, it only supports v1. As a result, it has the usual problems with overflowing COUNTER32's. But, it's fairly easy to set up and will let you monitor just about anything you want. Jason From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hans EngelenSent: Monday, February 27, 2006 4:01 PMTo: Nagios Users MailinglistSubject: Re: [Nagios-users] Monitor Fileserver Ah, i see. Question ... is there no SNMP access for these blackboxes ? Most blackboxes do from my experience (though I usually steer clear of them so I haven't used that many of them really). SNMP access will most likely allow you to poll a fair number of interesting metrics. Free space, network utilization, load ... that kind of thing. Worth checking into should my other suggestion fail. Incidentally don't forget to give the service-user enough rights to do its work, i.e. on the share and also for other checks it might have to do or you might get other unexplained errors. Start out with adding it to the local admins group to test the general idea first (and get a baseline check)then bump it down to normal user and add rights as you need. But I am sure you know that drill. Cheers, Hans On 2/27/06, Josh [EMAIL PROTECTED] wrote: Hans / Ryan,Thanks for your input...I thought the question might arise about "why don't I monitor the server housing the shares"... well, theproblem there is the machine is a NetApp device (notrunning windows and won't allow me to install anythingon it of course... it's an appliance).I've tried touching the /root/.smb/smb.conf...theproblem is most likely related to the nagios usercan't even see inside /root.I like your idea of mapping the drives under thenagios user and then running the service as the nagios user... I'll give that a shot.On a side note, I did try getting the nrpe checks towork on the windows server but am getting thefollowing error:"CScript Error: Execution of the Windows Script Host failed. (Catastrophic failure)"A little research shows it is most likely related to asoftware security policy in place.Anyone on thislist know what I need to change?Thanks again for all your help. Josh--- Hans Engelen [EMAIL PROTECTED] wrote: Dangit replied privately and not to the list, anyway heres a forward. Also just checked the /root/.smb/smb.conf reference is actually a workaround for a problem with samba's libsmbclient in the perl module Filesys::SmbClient (used by check_smb_shares.pl). Aparantly libsmbclient segfaults if it does not exist. Therefor if it does not exist the perl module Filesys::SmbClient tries to make one (an empty one) but has no permission to do so from what you wrote. I supose you could make it yourself (touch /root/.smb/smb.conf; chmod og+r /root/.smb/smb.conf). Maybe that will solve your issues with that particular check allowing you to use it to monitor the remote shares you spoke of Cheers, Hans On 2/27/06, Hans Engelen [EMAIL PROTECTED] wrote: For mapped drives that is quite normal since mapped drives are, barring a small number of special cases, only accessible for the user that did the actual mapping. It's the same problem you get for other NT services trying to access a drive mapping made from another user. Also most likely your pNSClient (or NC_Net or NSClient++) or whatever agent you have running on the Windows box is running under the System security setting. This security context is only valid for that windows box internally and as such has no credentials to access anything beyond that machine. This includes (but is not limited to) shares. Theoretically you could of course run your Nagios Agent under an actual user account, log in interactively on that same account and create a persistent mapping (net use * \\server\share /persist:yes, if memory serves) to the shares in question. Since the service will use the same profile when logging in that should solve the issue. But why even monitor a remote disk in this way. Just install the Nagios Agent on the server that houses the share and monitor it directly instead of indirectly (with all the quirks and pitfalls that come with it).Of course in this case the check_smb_shares is a solution too. As to why it insists on writing to /root/.smb/smb.conf is a bit strange. Possibly this was defined somewhere in the check_smb_shares.pl file. Open it up in a text editor and see. Cheers, Hans Cheers, Hans On 2/27/06, Ryan Wilcox [EMAIL PROTECTED] wrote: yeah... i got the same error as you did with a mapped drive. we aren't monitoring any mapped drives right now, hence the confusion. not sure about the mapped drives... anyone else have an idea for josh? -Original Message-From: Josh [mail
