Hey Andy: I sent a response yesterday but it got held up do to size. I trimmed the thread below.
I have LRP running nrpe. I only have a few plugins running on it though. I hacked nrpe to use the same encryption that nsca uses. I made a few more mods also. It gave me what I needed which was the ability to monitor servers inside my firewalls. Below is a thread that was never responded to by Ethan or anyone on the Netsaint list. He had helped me out on the new nsca stuff so I was a little surprised that I heard nothing from him. He must have a life :-) I'm using it in production on Eigerstein. I have all the plugins compiled on slink but I sure many will have problems running on eigerstien due to libs. Also, it's quite large because of the encryption libs. Akso worth mentioning: You have to build and install it on the Netsaint server as I have changed the protocol. While testing it I used the old and new version on my server. I used the old for monitoring things outside my firewall and I used the new on for things inside my firewall. I just named the new binary something else like nrpe1.3.0 I now support getting the password from a file as opossed to supplying it on the command line. (READ Below for context) I haven't worked on the Configure script. I just tweaked the Makefiles by hand as well as tweaking the config.h. I lost steam when noone seemed interested in what I was doing. No need to create a config script when I'm the only one using it. Let me know if you want to try it. Glenn "Glenn A. Thompson" wrote: > Hey Netsaint developers: > > I have been modifying "nrpe" based on the "PREVIOUS THREAD" information included > below. > > What I have now is as follows: > > 1. I have a working version of nrpe that uses the mcrypt module used in nsca. I > have attempted to make it work as close to 1.2 nsca as I know how. The password and > encryption method, on check_nrpe, are passed as an argument. I'm going to change > the password to be passed as a filename which contains the password. The file could > then be made read only for "netsaint and root". I forgot that "ps" would show the > commandline content. > > 2. If a command begins with a configurable prefix say "PA_" it will allow Passing > one Argument to the command specified in the nrpe.cfg file. The argument is simply > tacked onto the end of the nrpe.cfg entry. I was going to allow for a $ARGn$ type > syntax but ran into a little trouble parsing when commands contained other > commands. See EXAMPLES below. If people really want that, I'm sure I can prevail. > > a. The reason for the prefix is that I was concerned that some will view > commands within commands as a security hazard. > b. If you exclude the "PA_ in the command name, the processing works > exactly as before except for the new mcrypt stuff. > c. You can still "restrict" the command by defining certain arguments in > the nrpe.cfg file. > d. The reason I wanted a pass thru is described in the PREVIOUS THREAD(s) > section below. All I need on my LRP firewall is nrpe, mcrypt encryption (I include > only DES libs in my libmcrypt dir) , check_ping, check_nrpe. > > 3. I'm looking for questions/comments. I didn't want to alter development plans > without the Developer(s) weighing in. Right now it is still called nrpe. I can > release it as a new version or as something else if my mods offend :-) I still need > to do more testing. I don't know anything about "configure" but I can give it a > shot. > > EXAMPLES: > > add'l nrpe.cfg entries > ... > password=daPassword > > # > # PASS_ARGS_PREFIX (32 chars or less) > # > # Any command begining with pa_prefix will be > # found/matched through the last non blank char before a pa_suffix is found. > # The pa_suffix must be preceded by a blank char. > # What remains is tacked onto the end of the command supplied in the config > # file. (MACRO substitution must occur at the originating Netsaint host) > # > #default > pa_cmd_prefix=PA_ > > # > # PASS_ARGS_DELIMITER (1 char) > # > # Any command begining with pa_prefix will be > # found/matched through the last non blank char before a pa_delim is found. > # What remains is tacked onto the end of the command supplied in the config > # file. (MACRO substitution must occur at the originating Netsaint host) > # > #default > pa_delim=! > > # encryption method like nsca > encryption_method=2 > > command[PA_check_ping]=/usr/local/netsaint/libexec/check_ping -w 50,40% -c 60,100% > -p 5 -H > command[PA_check_50_nrpe]=/usr/local/netsaint/libexec/check_nrpe 192.168.10.50 -pw > daPassword -em 9 -c > command[PA_check_wideopen_nrpe]=/usr/local/netsaint/libexec/check_nrpe > .... > > for explanation purposes 100.1.1.254 is a masqerading LRP firewall box > > running check_nrpe: > ask firewall to ping 192.168.10.183 > ./check_nrpe 100.1.1.254 -c "PA_check_ping! 192.168.10.183" -pw password -em 9 > > ask firewall to ask 192.168.10.50 to ping 192.168.10.183 > ./check_nrpe 100.1.1.254 -c "PA_check_50_nrpe! \"PA_check_ping! 192.168.10.183\"" > -pw password -em 9 > > ask firewall to ask 192.168.10.50 to ping 192.168.10.183 > ./check_nrpe 100.1.1.254 -c "PA_check_wideopen_nrpe! 192.168.10.50 -pw daPassword > -em 9 -c \"PA_check_ping! 192.168.10.183\"" -pw password -em 9 > > OK so that last one is insane. But I works. I haven't tried it directly from > netsaint yet but it appears to allow the quoting if you believe the comments. > > Anyway please comment, > > Thanks, > Glenn Thompson > > ******************************************************************** > PREVIOUS THREAD(s): > > Hey Ethan: > I'm not sure if you got the following. > I went ahead and started the work described below. I'm starting with mcrypt. > I'm making it look as much like the new nsca stuff as I know how. So anyway, if > I'm going down the wrong road or doing something you're already working on, let > me know. I'll stop. > > Thanks, > Glenn > > PS I've been trying to build on an old release of Debian slink. This is the env > I was told to use to build LRP packages. Plugins are good. Small problem with > nsca. He uses uint32_t. In this old old debian release, types.h does not > define uint32_t. It does however have u_int32_t. I hacked in a typedef for > now. Any history on this? > > "Glenn A. Thompson" wrote: > > > Hey Ethan: > > > > A while back, I sent the following to the user list and had no responses. I > > have a development ENV for LRP now. So I' ready to start the mods listed > > below. Could you coment on what I want to do. Also, it seems like I should > > add the encryption used in nsca while I'm at it. What do you think? > > > > Thanks, > > Glenn > > > > "Glenn A. Thompson" wrote: > > > > > Hey: > > > I'm looking for comments/suggestions on this blithering mess below: > > > > The Blithering I refer to is my writing not netsaint :-) > > > > > > > > > > > > > > > > I've been diging my way through mailing list archives and have found > > > many people discussing how to go about monitoring through firewalls. > > > I'm in a bit of a mental deadlock. I have a situation where I have a > > > need to go through a firewall. Behind that firewall is a hierarchy of > > > machines/networks that lends itself well to the parent definitions > > > provided by netsaint. All machines behind the firewall are on private > > > IP's. > > > > > > Crudely it looks something like this: > > > > > > Internet <-->ACL type firewall <--> Internet servers, Netsaint, and > > > bastion firewall<--> workstations and (routers with local loop > > > connectivity). > > > > > > For the Bastion firewall I use a Linux Router Project (LRP) machine to > > > provide masqerading and some limited port forwarding from my internet > > > servers to some custom backend services. For those of you not familiar > > > with LRP its a Linux floppy based firewall. Very lightweight and > > > requires nothing but a floppy drive or two. no harddrive no CD. You > > > can use them if needed. > > > > > > Anyhooooo > > > In the far reaches of this internal network I have servers I want to > > > monitor with the Netsaint box that lives between the ACL firewall and > > > the bastion firewall. > > > > > > I want to be able to represent a correct parenting tree so that when one > > > of the internal (local loop routers) goes down the services behind it > > > will be seen as unreachable. > > > > > > Currently, I have no (24x7 servers) between the bastion firewall and the > > > router(s) that service the localloop to the "far reaching corners". I'm > > > thinking I may have to bite the bullet and put in a box that can run > > > Netsaint and use distributed monitoring. I don't have all that many > > > machines and services to check. So I feel a little reluctant to add > > > more machines. I haven't checked into the check_by_ssh module so I may > > > want to go that route. I have ruled out the perl based nrpe because I > > > would like it to run on the LRP box. Perl won't fit on a floppy to > > > easy. I use nrpe now for disk checks etc. I like it. I don't have a > > > whole bunch of machines so I don't mind setting up the nrpe.cfg on > > > needed hosts. When monitoring the new machines however, both the > > > host_checks and the remote services will all have to be configured > > > without the benefit of macros as enforced by nrpe. I little more > > > painful:-) > > > > > > I think I want to do as follows: > > > > > > I want to build a modified nrpe daemon. Specifically, it would do two > > > things. > > > > > > First it would allow for a check_ping command to match on only the first > > > word of the command passed to it and use the second word as the host to > > > ping. The current find_command() function matches exactly the name of > > > the command and runs the comand part read from the config file. Maybe I > > > could do something even more sophisticated but this is the minimum I > > > need. This would allow me to use the $HOSTADDRESS$ macro to ping any > > > number of hosts behind the firewall without having a specific nrpe.cfg > > > entry on the LRP box as well as the intended target box. > > > > > > Second he would be able to "forward" check_nrpe requests. The check_nrpe > > > comand entry would look like: > > > command[check_nrpe]=/usr/local/netsaint/libexec/check_nrpe $USER1$ -fc > > > $HOSTADDRESS$ $ARG1$ > > > > > > USER1 would be set to the IP address of this modified nrpe daemon. -fc > > > is a forward command and would be supported as well as the -c command. > > > > > > This would not support configurable ports as shown , but you get the > > > idea. > > > > > > Essentially, I'm trying to do the second example listed in the > > > documentaion under "Indirect Host and Service Checks". > > > > > > I think I can get check_ping,check_nrpe and nrpe to run under LRP and > > > have them fit on my existing floppies. Maybe a few more. The rest can > > > live on one of the boxes on the other side of my localloop > > > > I have them compiled and working without any mods to the software, configs > > or Makefiles. > > > > > > > > > > > I can use the existing nrpe daemon but it becomes a bit of a pain in the > > > butt to add nrpe.cfg items. LRP runs from RAM. What it does is load > > > tgz files named with a lrp suffix into a ram disk and it's off to the > > > races. So, if I add nrpe.cfg items I have to backup to the floppy. No > > > biggie. Well, one Plus to LRP is that you can write protect the > > > floppies so that if someone breaks in they can't alter your > > > configuration permanently. I live and work 250 miles from these boxes > > > so I can't flip the write protect tab on the floppy in the middle of the > > > night when I get most my real work done. So I came up with the changes > > > above. > > > > > > What do you Netsaints think? > > > > > > Thanks, > > > Glenn Thompson > > > > > _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
