NRPE enhancement
Carroll, Jim P [Contractor]
jcarro10 at sprintspectrum.com
Wed Jan 8 23:25:18 CET 2003
Sounds great! I can see myself checking into the crypto option.
jc
> -----Original Message-----
> From: Ethan Galstad [mailto:nagios at nagios.org]
> Sent: Monday, January 06, 2003 11:48 PM
> To: nagios-users
> Subject: RE: [Nagios-users] NRPE enhancement
>
>
> I've thought about this for a while now and have decided that I will
> allow arguments to be passed to plugins in future versions of NRPE.
> I've gotten a lot of requests for this feature and I understand that
> it makes configuring things on the central server much easier.
> However, because of the security implications this will have, I will
> also be doing the following:
>
> 1. Incorporate encryption similar to NSCA that gives the NRPE daemon
> some assurance of a trust level with the client
>
> 2. Strip all potentially dangerous shell metacharacters from the
> arguments before they're passed to the plugin for exection
>
> Incorporating crypto into NRPE will affect performance a bit, but it
> will still probably scale better than check_by_ssh. If the user
> decides to disable native crypto support (and tunnel traffic through
> stunnel, etc. instead), the NRPE daemon will refuse to accept
> arguments for plugins unless the user specifically supplies a --dont-
> blame-nrpe option to the configure script before compiling. If the
> daemon gets compiled with this option, it will loudly complain in the
> logs and elsewhere that is running in an insecure mode.
>
> Does this approach sound reasonable to people?
>
>
>
> On 30 Dec 2002 at 16:43, Carroll, Jim P [Contractor] wrote:
>
> > If you have 500 machines, and among those machines there
> are no two disks
> > alike, then I can only imagine the grief ahead of you. To
> take a page out
> > of www.infrastructures.org, it's desireable to maintain a
> convergence, not
> > divergence, among the various systems. Homogeneity is A
> Good Thing ®.
> >
> > Having said that, rather than maintaining 500 config files,
> why not maintain
> > a single config file containing all the similar and
> dissimilar config
> > particulars? Edit that one file, and either push it out
> from a trusted host
> > ("gold server", in Infrastructures.org parlance). Better
> still, set up an
> > rsync server (or some other server that you can live with,
> and set up a cron
> > job to pull down the latest nrpe.cfg file. (As has been
> emphasized on their
> > list, pull, never push. But take your pick. :)
> >
> > In our location, I maintain a single nrpe.cfg file,
> complete with all the
> > unique disk definitions. I'm not sure if it matters to
> you, but for the
> > most part, I've elected to use the percentage option of
> check_disk. 5% free
> > on the root partition of an 18GB disk isn't going to be a whole lot
> > different from 5% free on root of a 36GB disk. Sure,
> mathematically they're
> > different, so if exacting differences is critical in your
> environment,
> > create unique definitions for the different root
> partitions. (I'm also
> > specifying mount points, not device filenames.) On a
> related note, we have
> > partitions on our database servers which follow a fairly
> straightforward
> > naming scheme for the mount points, and since I don't expect those
> > partitions to change, I can either exclude them, or I can
> set a trivial
> > threshold for each of the warning and critical, but in
> those cases I specify
> > kbytes. (I do the latter; this lets anyone with the
> appropriate permissions
> > at the web interface view all the defined partitions.)
> >
> > [Sidebar: I noticed at one point that there's a limit to
> the length of the
> > command token in nrpe.cfg. As a result, I simplified all
> the names. Lesson
> > learned: Be economical with the keystrokes.]
> >
> > If you like, I can send you the nrpe.cfg file that I
> install on all our
> > hosts.
> >
> > You might find that instead of one master nrpe.cfg file,
> that you'd rather
> > manage a handful of dissimilar files. Might still want to use the
> > gold/config server, as above.
> >
> > Food for thought.
> >
> > jc
> >
> > > -----Original Message-----
> > > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > > Sent: Monday, December 30, 2002 2:43 PM
> > > To: Carroll, Jim P [Contractor]; 'nagios-users'
> > > Subject: RE: [Nagios-users] NRPE enhancement
> > >
> > >
> > > Ok, so check_by_ssh doesn't scale well, and nrpe is scalable
> > > cpu-wise, but
> > > has problems configuration-wise. (Imagine 500 machines all
> > > of which have 5
> > > disks, and different check_disk arguments for each. That's 2500
> > > configuration lines that need to be maintained over 500
> > > machines in 500
> > > files.)
> > >
> > > Perhaps there is room for something more secure than the
> > > current nrpe, but
> > > more scalable than check_by_ssh. Does that seem reasonable?
> > > If so, does
> > > anyone have suggestions for low cost security implementations
> > > that could
> > > enhance the security of nrpe without the cost of ssh?
> > >
> > > dave
> > >
> > >
> > > -----Original Message-----
> > > From: nagios-users-admin at lists.sourceforge.net
> > > [mailto:nagios-users-admin at lists.sourceforge.net]On
> Behalf Of Carroll,
> > > Jim P [Contractor]
> > > Sent: Monday, December 30, 2002 10:49 AM
> > > To: 'nagios-users'
> > > Subject: RE: [Nagios-users] NRPE enhancement
> > >
> > >
> > > The general consensus is that check_by_ssh isn't a solution
> > > which will scale
> > > well, due to the nature of the number-crunching crypto beast.
> > > This is where
> > > NRPE has the advantage.
> > >
> > > check_by_ssh has the advantage when it comes to punching
> > > through a firewall,
> > > assuming that an appropriate port is open. Sure, you could
> > > open port 5666
> > > for NRPE, but has has been discussed, that doesn't quite
> > > leave the same warm
> > > fuzzies.
> > >
> > > HTH.
> > >
> > > jc
> > >
> > > > -----Original Message-----
> > > > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > > > Sent: Monday, December 30, 2002 12:14 PM
> > > > To: 'Ethan Galstad'; 'nagios-users'
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > Let me ask a second question that might help me understand
> > > > more clearly the
> > > > situation. Check_by_ssh allows for the passing of arbitrary
> > > > arguments to
> > > > arbitrary command from the centralized Nagios server to any
> > > > remote machine
> > > > which has sshd running. NRPE allows for executing a specific
> > > > command with
> > > > specific arguments on any remote machine which has nrpe running.
> > > >
> > > > As someone setting up monitoring, when should I use
> > > > check_by_ssh and when
> > > > should I use nrpe?
> > > >
> > > > dave
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nagios-users-admin at lists.sourceforge.net
> > > > [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
> > > > Dave Viner
> > > > Sent: Monday, December 30, 2002 9:07 AM
> > > > To: Tom Welsh; 'Ethan Galstad'; 'nagios-users'
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > I don't think that my enhancement allows an arbitrary
> command to be
> > > > executed. I think the code that I wrote will only allow one
> > > > of the commands
> > > > already listed in the nrpe.cfg file to be executed. The
> > > > arguments passed
> > > > are arbitrary, but not the command. (The code even checks to
> > > > ensure that the
> > > > command requested, without any arguments, exists before
> > > > executing it to
> > > > prevent malicious usage of arguments.)
> > > >
> > > > dave
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Tom Welsh [mailto:twelsh at square-box.com]
> > > > Sent: Saturday, December 28, 2002 5:02 PM
> > > > To: 'Dave Viner'; 'Ethan Galstad'; 'nagios-users'
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > In my humble opinion an option that allows an arbitary
> command to be
> > > > executed and which by "default" is switched off is an
> > > accident waiting
> > > > to happen.
> > > >
> > > > It only takes 1 security breach via a plugin to completely
> > > destroy the
> > > > good name Nagios and its associated plugins have.
> > > >
> > > > There is a good truism that states "good news travels fast,
> > > > but bad news
> > > > travels even faster"
> > > >
> > > > I for one would not be too happy having a command
> available on my
> > > > network, trusted or not that would allow commands to be executed
> > > > remotely pon a box. For one. It's the kind of thing im
> > > always looking
> > > > for when im "playing on my " networks.
> > > >
> > > > Well that's my two cents worth
> > > >
> > > > Cheers
> > > >
> > > > Tom Welsh
> > > > twelsh at square-box.com
> > > >
> > > > -----Original Message-----
> > > > From: nagios-users-admin at lists.sourceforge.net
> > > > [mailto:nagios-users-admin at lists.sourceforge.net] On
> Behalf Of Dave
> > > > Viner
> > > > Sent: 28 December 2002 21:46
> > > > To: Ethan Galstad; nagios-users
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > > These are excellent arguments for not incorporating the
> > > > enhancement I am
> > > > suggesting. However, I suspect that there are lots of
> > > > installations of
> > > > Nagios and NRPE that run on completely trusted network. (Or
> > > > the risk of
> > > > network intrusion through NRPE is worth the benefit of reduced
> > > > configuration
> > > > management.)
> > > >
> > > > What do you think about incorporating this enhancement
> but have it
> > > > turned
> > > > off by default, and enabled only at configure time?
> > > >
> > > > dave
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: nagios-users-admin at lists.sourceforge.net
> > > > [mailto:nagios-users-admin at lists.sourceforge.net]On
> Behalf Of Ethan
> > > > Galstad
> > > > Sent: Friday, December 27, 2002 7:38 PM
> > > > To: nagios-users
> > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > >
> > > >
> > > > There are several reasons why I have not added support
> for arguments
> > > > to checks in NRPE. Most have been touched on in the past on the
> > > > list, but I'll reiterate them here. The main issue is not
> > > overruning
> > > > the 2K packet that the check_nrpe plugin and NRPE
> daemon pass back
> > > > and forth - that can be easily avoided...
> > > >
> > > > 1.
> > > > Users connecting to the NRPE are not authenticated.
> Sure, you can
> > > > restrict connection based on IP address using TCP
> wrappers, but they
> > > > are still not authenticated. Also, I am not too
> familiar with IP
> > > > spoofing, but I'm sure its possible for someone to fake the
> > > > originating address of the connection and get the NRPE daemon to
> > > > accept the packet and execute the necessary plugin
> without too much
> > > > trouble.
> > > >
> > > > 2.
> > > > Some plugins (like check_dhcp) may (have to) be
> installed suid root.
> > > > Regardless of what user the NRPE daemon is running as,
> these plugins
> > > > will be executed with higher privs.
> > > >
> > > > 3.
> > > > Plugins can be made to segfault under the right conditions.
> > > Sure, we
> > > > can try and eliminate this possibility, but it will
> probably always
> > > > exist to some extent since many plugins call system
> commands to get
> > > > their data.
> > > >
> > > > ---
> > > >
> > > > Most remote exploits rely on buffer overflows/segfaults
> to get their
> > > > work done, so allowing unauthenticated users to pass arbitrary
> > > > arguments/data to plugins that might be running suid
> commands is a
> > > > very bad idea indeed.
> > > >
> > > > Stunnel would provide some security, but there is no
> guarantee that
> > > > everyone would use it. There would undoubtably be many
> people that
> > > > would put off implementing it until they finished "testing"
> > > NRPE. In
> > > > the worst case, they might never get around to
> implementing stunnel
> > > > at all. In the likely best case scenario, there is at
> > > least a window
> > > > of opportunity. I just don't want to be responsible for
> > > the possible
> > > > carnage that happens at that point. :-)
> > > >
> > > > Also, incorporating native encryption into NRPE
> involves reinventing
> > > > the wheel called "check_by_ssh", so I'm really
> interested in doing
> > > > that.
> > > >
> > > >
> > > >
> > > > On 27 Dec 2002 at 13:46, Carroll, Jim P [Contractor] wrote:
> > > >
> > > > > I'm not a C programmer by profession, so I defer your
> > > query to those
> > > > who
> > > > > have a strong background, both in C code and system/network
> > > > security.
> > > > It
> > > > > does presume that every other link in the chain is
> bulletproof.
> > > > [Insert
> > > > > ObRef to Bugtraq here.]
> > > > >
> > > > > At any rate, I'm curious to hear why Ethan didn't choose
> > > > that approach
> > > > to
> > > > > begin with.
> > > > >
> > > > > jc
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > > > > > Sent: Friday, December 27, 2002 12:49 PM
> > > > > > To: Nagios-users at lists.sourceforge.net
> > > > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > > > >
> > > > > >
> > > > > > This sounds interesting, but I have a question about the
> > > > > > security implications of this code. I'm not a security
> > > > > > expert, so please excuse the somewhat basic question. The
> > > > > > struct packet as defined in common/common.h has an argv
> > > > > > member which is a character array of length 2048.
> I believe
> > > > > > this means that if the incoming packet has an argv member
> > > > > > whose length is greater than 2048 chars, then the
> > > > > > rc=recvall(sock,(char
> > > > > > *)&receive_packet,&bytes_to_recv,socket_timeout);
> > > > > > should fail, should it not?
> > > > > >
> > > > > > However, I think your suggestions regarding stunnel, and
> > > > > > encryption are good ones, regardless of the inclusion of
> > > > this code.
> > > > > >
> > > > > > thanks
> > > > > >
> > > > > > dave
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Carroll, Jim P [Contractor]
> > > > [mailto:jcarro10 at sprintspectrum.com]
> > > > > > Sent: Friday, December 27, 2002 10:20 AM
> > > > > > To: 'Dave Viner'; Nagios-users at lists.sourceforge.net
> > > > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > > > >
> > > > > >
> > > > > > I think it's a good idea, but with the following provisions:
> > > > > >
> > > > > > - This should not be enabled by default.
> > > > > >
> > > > > > - The configure script, the Makefile and any/all NRPE docs
> > > > > > should explicitly
> > > > > > state the security risks in forcing the non-default
> > > > (added feature)
> > > > > > behaviour.
> > > > > >
> > > > > > - If the daemon is compiled with this option, anytime the
> > > > > > daemon starts, it
> > > > > > should briefly mention that it has been compiled for this
> > > > > > behaviour, and a
> > > > > > quick remark about the increased risks. (Sent to stderr if
> > > > > > standalone, else
> > > > > > sent to syslog if running under (x)inetd). It should scream
> > > > > > loud and clear
> > > > > > if it's started under root; preferably it would simply not
> > > > > > run as root, full
> > > > > > stop.
> > > > > >
> > > > > > - Perhaps a reference to implementing NRPE with stunnel (and
> > > > > > only permitting
> > > > > > connections from localhost, as defined in nrpe.cfg) would be
> > > > > > desireable.
> > > > > >
> > > > > > I'm not a security guru, but it seems to me that
> facilitating
> > > > > > this feature
> > > > > > would open oneself up to a buffer overflow attack.
> If you're
> > > > > > on a trusted
> > > > > > network, it's a non-issue.
> > > > > >
> > > > > > On a related note, I'd be much more comfy with this feature
> > > > > > if there were a
> > > > > > facility to enforce some level of native encryption, such as
> > > > > > what NSCA uses.
> > > > > > If you don't have the keys to the house, you get dropped on
> > > > > > the floor. (I
> > > > > > have a similar wish for NSClient.)
> > > > > >
> > > > > > Food for thought.
> > > > > >
> > > > > > jc
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Dave Viner [mailto:dviner at yahoo-inc.com]
> > > > > > > Sent: Friday, December 27, 2002 11:48 AM
> > > > > > > To: Nagios-users at lists.sourceforge.net
> > > > > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > > > > >
> > > > > > >
> > > > > > > In order to clarify the idea that I'm proposing,
> I've made a
> > > > > > > patch to the nrpe source that implements what I'm
> describing.
> > > > > > > This patch is made against the nrpe-1.5.tar.gz from
> > > > sourceforge.
> > > > > > >
> > > > > > > Essentially, these changes allow us to specify in the
> > > > > > > nrpe.cfg file lines like this:
> > > > > > >
> command[check_disk_gen]=/usr/local/libexec/nagios/check_disk
> > > > > > >
> > > > > > > Then when invoking check_nrpe, you can invoke it
> like this:
> > > > > > > ./check_nrpe 127.0.0.1 -V 2 -c check_disk_gen
> -a "-w 50000
> > > > > > > -c 10000 -p /dev/ad0s1e"
> > > > > > >
> > > > > > > And the effect is that
> /usr/local/libexec/nagios/check_disk
> > > > > > > is invoked with the -w 50000 -c 10000 -p
> /dev/ad0s1e as the
> > > > > > > argument string. For example:
> > > > > > >
> > > > > > > ~/nagios/nrpe-1.5.new/src>./check_nrpe 127.0.0.1 -V 2 -c
> > > > > > > check_disk_gen -a "-w 50000 -c 10000 -p /dev/ad0s1e"
> > > > > > > DISK OK - [1484108 kB (9%) free on /dev/ad0s1e]
> > > > > > > ~/nagios/nrpe-1.5.new/src>
> > > > > > >
> > > > > > > I think this is really useful and would greatly reduce the
> > > > > > > size of the nrpe.cfg and, more importantly, would
> reduce the
> > > > > > > number of times you'd need to modify that
> configuration file.
> > > > > > > Instead the modifications would occur on the centralized
> > > > > > > Nagios server's configuration file.
> > > > > > >
> > > > > > > What does everyone think? Should we add this to the main
> > > > > > > source for NRPE-1.6?
> > > > > > >
> > > > > > > dave
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: nagios-users-admin at lists.sourceforge.net
> > > > > > >
> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
> > > > > > > Dave Viner
> > > > > > > Sent: Monday, December 23, 2002 8:51 AM
> > > > > > > To: Naios Users
> > > > > > > Subject: RE: [Nagios-users] NRPE enhancement
> > > > > > >
> > > > > > >
> > > > > > > Hi Rue,
> > > > > > > Security is a great reason for limiting the commands
> > > > > > > that NRPE is able to execute. But my suggested
> enhancement
> > > > > > > wouldn't allow NRPE to execute any command that
> isn't listed
> > > > > > > in the cfg file. That is, the NRPE would still
> need to find
> > > > > > > the path to the executable in the nrpe.cfg file,
> then use any
> > > > > > > remaining information as arguments passed to the
> executable.
> > > > > > > It is true that this is less secure that forcing
> the entire
> > > > > > > command line (executable and arguments) in the
> config file.
> > > > > > > But, so long as the executables are well authored
> and handle
> > > > > > > unexpected arguments well, I think this
> enhancement would not
> > > > > > > significantly decrease security. Do you think that
> > > > > > > specifying arguments would make NRPE significantly
> > > less secure?
> > > > > > >
> > > > > > >
> > > > > > > Dave
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: nagios-users-admin at lists.sourceforge.net
> > > > > > >
> [mailto:nagios-users-admin at lists.sourceforge.net]On Behalf Of
> > > > > > > Rue Turner
> > > > > > > Sent: Friday, December 20, 2002 1:33 PM
> > > > > > > To: Naios Users
> > > > > > > Subject: Re: [Nagios-users] NRPE enhancement
> > > > > > >
> > > > > > >
> > > > > > > dave,
> > > > > > >
> > > > > > > I think the reson for this choice of configuration is
> > > > > > security. If the
> > > > > > > nrpe was allowed to run whatever it was asked it would
> > > > be easy to
> > > > > > > compromise your machines. This way although your
> configs are
> > > > > > > hefty (mine
> > > > > > > have almost a hundred lines in) you can only ask it to run
> > > > > > > commands from
> > > > > > > this library.
> > > > > > >
> > > > > > > rue
> > > > > > >
> > > > > > >
> > > > > > > On Fri, 2002-12-20 at 17:35, Dave Viner wrote:
> > > > > > > > Hi,
> > > > > > > > I'd like to suggest an enhancement to
> NRPE, and if
> > > > > > > people think this is a
> > > > > > > > good idea, I'll try to make a patch to support my
> > > > > > > suggestion. Currently the
> > > > > > > > nrpe.cfg file specifies all the commands in
> this fashion:
> > > > > > > >
> > > > > > >
> command[check_disk1]=/usr/local/nagios/libexec/check_disk 80
> > > > > > > 95 /dev/hda1
> > > > > > > > As result of this design is that if you want to check
> > > > > > something like
> > > > > > > > /dev/hda1 and /dev/hdb1, you need two seperate
> lines in the
> > > > > > > nrpe.cfg file.
> > > > > > > > So, I'd like to propose that we extend
> NRPE to allow
> > > > > > > for the arguments to a
> > > > > > > > command to be specified by the central Nagios server
> > > > > > > instead of in the
> > > > > > > > nrpe.cfg. The idea is that the nrpe.cfg would have one
> > > > > > > command line which
> > > > > > > > maps a key, 'check_disk', to a local executable,
> > > > > > > > '/usr/local/nagios/libexec/check_disk'. The
> rest would be
> > > > > > > specified from
> > > > > > > > the central Nagios server in some manner.
> > > > > > > > I think this would great simplify the
> nrpe.cfg files,
> > > > > > > and reduce a lot of
> > > > > > > > redundant command definitions that differ only in the
> > > > > > arguments they
> > > > > > > > require. Also, it would mean that you'd need to update
> > > > > > > your nrpe.cfg very
> > > > > > > > rarely. In fact, you'd only need to update it
> when you add
> > > > > > > a new plugin.
> > > > > > > > I don't have a concrete suggestion for
> implementing
> > > > > > > this yet, because I
> > > > > > > > want to see if the community is interested in this idea
> > > > > > > first. Has this
> > > > > > > > idea been suggested previously? Is anyone currently
> > > > > > > interested in the idea
> > > > > > > > or would I be the only consumer of such a service?
> > > > > > > >
> > > > > > > > thanks
> > > > > > > > dave
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------
> > > > > > > > This SF.NET email is sponsored by: The Best Geek
> > > > Holiday Gifts!
> > > > > > > > Time is running out! Thinkgeek.com has the coolest
> > > gifts for
> > > > > > > > your favorite geek. Let your fingers do the
> > > typing. Visit
> > > > Now.
> > > > > > > > T H I N K G E E K . C O M
> > > http://www.thinkgeek.com/sf/
> > > > > > > > _______________________________________________
> > > > > > > > Nagios-users mailing list
> > > > > > > > Nagios-users at lists.sourceforge.net
> > > > > > > >
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > > > > >
> > > > > > >
> > > > > > > r u e t u r n e r
> > > > > > > · t · h · i · n · l · a · y · e · r ·
> > > > > > >
> > > > > > > -- index, n.: Alphabetical list of words of no possible
> > > > > > interest where
> > > > > > > an alphabetical list of subjects with references
> ought to be.
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------
> > > > > > > This SF.NET email is sponsored by: The Best Geek
> > > Holiday Gifts!
> > > > > > > Time is running out! Thinkgeek.com has the
> coolest gifts for
> > > > > > > your favorite geek. Let your fingers do the typing.
> > > > Visit Now.
> > > > > > > T H I N K G E E K . C O M
> http://www.thinkgeek.com/sf/
> > > > > > > _______________________________________________
> > > > > > > Nagios-users mailing list
> > > > > > > Nagios-users at lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------
> > > > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > > > Welcome to geek heaven.
> > > > > > > http://thinkgeek.com/sf
> > > > > > > _______________________________________________
> > > > > > > Nagios-users mailing list
> > > > > > > Nagios-users at lists.sourceforge.net
> > > > > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > > Welcome to geek heaven.
> > > > > > http://thinkgeek.com/sf
> > > > > > _______________________________________________
> > > > > > Nagios-users mailing list
> > > > > > Nagios-users at lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > > > >
> > > > >
> > > > >
> > > > > -------------------------------------------------------
> > > > > This sf.net email is sponsored by:ThinkGeek
> > > > > Welcome to geek heaven.
> > > > > http://thinkgeek.com/sf
> > > > > _______________________________________________
> > > > > Nagios-users mailing list
> > > > > Nagios-users at lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > > >
> > > >
> > > >
> > > >
> > > > Ethan Galstad,
> > > > Nagios Developer
> > > > ---
> > > > Email: nagios at nagios.org
> > > > Website: http://www.nagios.org
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Nagios-users mailing list
> > > > Nagios-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Nagios-users mailing list
> > > > Nagios-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Nagios-users mailing list
> > > > Nagios-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Nagios-users mailing list
> > > > Nagios-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Nagios-users mailing list
> > > Nagios-users at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nagios-users
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Nagios-users mailing list
> > Nagios-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-users
> >
>
>
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
More information about the Users
mailing list