NRPE enhancement
Stephen Milton
milton at isomedia.com
Tue Jan 7 16:13:09 CET 2003
Another option is NRPEP (one of the older NetSaint based tools) which
was a perl replacement for the old NRPE. The perl version already has
encryption. I have been able to use it in my Nagios installation with
only trivial modifications to the check_nrpep program (change the
config default directory).
I suppose it is possible that the perl interpreter is less scalable
than the check_by_ssh, not really sure, but it works well for me.
-Steve
On Tue, Jan 07, 2003 at 07:03:59AM -0500, Jolet, John eloquently stated:
> works fine for me!
>
> -----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 http://www.vasoftware.com
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
--
Stephen Milton - Vice President (425) 881-8769 x102
ISOMEDIA.COM - Premium Internet Services (425) 869-9437 Fax
milton at isomedia.com http://www.isomedia.com
-------------------------------------------------------
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