NRPE enhancement
Tim Shouldice
tim at mintoskatingclub.com
Mon Jan 13 02:28:57 CET 2003
To me, one of Nagios' main strengths is its ability to be deployed in many different types of configurations. A central server configuration with one Nagios agent polling information from other servers via NRPE is extremely powerful because of the centralized view the single agent gives via the web interface. Adding parameter support to NRPE would represent a significant step forwards for Nagios because its current implementation prevents central configuration. I believe the security implications raised by Ethan would be adequately addressed by his proposal. Overall in terms of priorities with Nagios, I would rank this fairly high.
I would suggest that strong consideration also be given to creating a port of this next version of NRPE to the NT/WIN2K/XP platforms. It seems that NSClient has been orphaned and a single model for remote checking of all servers would ease installation, configuration and on-going maintenance of a Nagios monitoring environment. Plugins would also of course have to follow for these platforms but I believe users would be quick to develop them.
While I probably have as many issues with the NT/WIN2K/XP platforms as other users of Nagios I still have to deal with the presence of these platforms in my environment and need to monitor them.
What issues would be involved in such a port, are there any real show-stoppers (technical) and has this been discussed in the past?
Tim Shouldice
----- Original Message -----
From: Ethan Galstad
To: nagios-users
Sent: Tuesday, January 07, 2003 12:48 AM
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 http://www.vasoftware.com
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20030112/273dae3f/attachment.html>
More information about the Users
mailing list