It really isn't that simple. I'd refer you to my own work (http://www.usenix.org/media/events/lisa07/tech/videos/josephsen.mp4, and http://media.defcon.org/dc-15/video/Defcon15-Dave_Josephsen-Homeless_Vikings.mp4 ) or that of Nick Feamster at Georgia tech.
They've been hijacking address space via short-lived BGP prefix hijacks for at least 5 years now, and It is exactly the attitude of "we'll just block X" that got us here in the first place.
If you use RBL's and make the arms race about IP's , then the most direct response is to attack the network layer and/or IP space.
Further there are real world reasons why IP filters just aren't going to work on a global scale. For that I'd refer you to the work of Mohit Lad at UCLA. There is an economic layer on top of BGP. The effect of no-valley routing is that you're going to get route propagation from folks you think you can trust but cannot. It's a bit much to get into here, but off-handedly blacklisting more shit isn't the answer here, it's the problem.
I'm an *OLD* Netsaint and Nagios user, and have contributed to both. Guides are great, playing with it is great, and it does a lot of things very well. But what Nagios has never had is a way to publish the URL's of specific queries or reports in a way that can be bookmarked and sent to someone else for reference. It's a big, big, big flaw in the system, common to a lot of web-based projects.
I'm also an "OLD" Nagios user, as well as the author of the Addison Wesely Nagios book, so I might be biased, but I think you're kind of missing the point. Nagios is just a task efficient scheduling and notification engine. It's job is to schedule the execution of monitoring plugins, interpret their output, and take user-defined actions based on that output. It's flexability derives from this core minimilist approach. The plugins, and web front end are separate entities, and shouldn't really be considered "Nagios" in any meaningful way. So, in general, if you are saying something like "Nagios has no way of doing X", then Nagios probably isn't doing that by design, and you should be looking elsewhere for that functionality. If you spend some time on the nagios-users list, you get a good feel for what other people are doing to solve your sorts of problems. Based on my experience therein, I can tell you that the NLG (nagios looking glass) is probably what most people are using for the type of problem you list above.
The other huge, huge flaw of Nagios is configuring it. It shouldn't take a reference book from O'Reilly to do this efficiently, but I'm afraid it does.
I certainly hope that it doesn't take an oreilly book, because they don't have one yet;-) (only apress, no starch, and awp respectively). I've noticed an important difference between the kinds of programs I enjoy working with, and those that I do not. The programs I most enjoy (the programs that stick with me for decades) have in common a complicated initial setup. This comes from the fact that the programs are themselves complex and flexable, and the fact that I am opinionated about how I'd like them to work. If you read the online Nagios docs, and decide how you want it to work for you, then you will have a few hours of initial setup, followed by a decade of trouble-free operation. If you read the docs, and plan well, then adding new hosts, services, etc.. will take less time than making the ssh connection. On the other hand, if you install MOM, Patrol, Openview, or hyperwhatever, you will be running in a halve hour, and you will be lost in a infinitely recursive system of menus filling out web forms for every host and service change for the next year or two until the compulsory upgrade comes along. Then you will rip it all apart and start over.
That having been said, the initial setup with Nagios is really not all that hard guys. I'd tell you to go install Monarch if I thought that filling out webforms was easier, but I don't think having an input field on a webpage called "host" is necessarily easier than having some text in a file called "host". I will recommend however that you checkout NACE, which makes host configuration as simple as "nmap -sP 192.168.X.0/24 | grep 'Status: UP' | cut -d\ -f2 | WriteHosts.pl"
There are easily a dozen different configuration tools at www.nagiosexchange.org and sourceforge.net, and *every single one of them* has major problems that could be solvd with 10% of the time spent on Nagios itself. Most are abandonware, exciting but uncompleted projects that are never going to be completed. Others rely on hand-compiling Nagios itself with strange local modifications and local configurations that are very difficult to import a working Nagios to, or export from.
Again, some time on the lists would give you a good feel for what is wheat and what is chaff on NagiosExchange. Not all contributions are equal, and that's to be expected in any community. When someone does it right, other people use
Guys, It really doesn't need to be that hard. The primary nagios.cfg allows you to arrange the configuration any way you choose. Most people use large, object-specific config files, but there's no reason you couldn't break your config's down into host-based entities which contain a host, the services on that host, and the contacts/contactgroups for that host. A really lightweight shell wrapper could be used to cat together pre-configured "templates" into a hostX.cfg file. It could ask you questions like "what is the name of the host?" and you could answer the questions and have a config.
Check out NACE, which can create a configuration for you given piped output from Nmap.
In general, in Nagios land, if things are hard, it's because you're making them hard. Stop for a second and think about how you want things to work, and Nagios can be made to operate in the manner that you specify. All it takes is a bit of thought on your part.
Slashdot Mirror
It really isn't that simple. I'd refer you to my own work (http://www.usenix.org/media/events/lisa07/tech/videos/josephsen.mp4, and http://media.defcon.org/dc-15/video/Defcon15-Dave_Josephsen-Homeless_Vikings.mp4 ) or that of Nick Feamster at Georgia tech. They've been hijacking address space via short-lived BGP prefix hijacks for at least 5 years now, and It is exactly the attitude of "we'll just block X" that got us here in the first place. If you use RBL's and make the arms race about IP's , then the most direct response is to attack the network layer and/or IP space. Further there are real world reasons why IP filters just aren't going to work on a global scale. For that I'd refer you to the work of Mohit Lad at UCLA. There is an economic layer on top of BGP. The effect of no-valley routing is that you're going to get route propagation from folks you think you can trust but cannot. It's a bit much to get into here, but off-handedly blacklisting more shit isn't the answer here, it's the problem.
I'm an *OLD* Netsaint and Nagios user, and have contributed to both. Guides are great, playing with it is great, and it does a lot of things very well. But what Nagios has never had is a way to publish the URL's of specific queries or reports in a way that can be bookmarked and sent to someone else for reference. It's a big, big, big flaw in the system, common to a lot of web-based projects.
I'm also an "OLD" Nagios user, as well as the author of the Addison Wesely Nagios book, so I might be biased, but I think you're kind of missing the point. Nagios is just a task efficient scheduling and notification engine. It's job is to schedule the execution of monitoring plugins, interpret their output, and take user-defined actions based on that output. It's flexability derives from this core minimilist approach. The plugins, and web front end are separate entities, and shouldn't really be considered "Nagios" in any meaningful way. So, in general, if you are saying something like "Nagios has no way of doing X", then Nagios probably isn't doing that by design, and you should be looking elsewhere for that functionality. If you spend some time on the nagios-users list, you get a good feel for what other people are doing to solve your sorts of problems. Based on my experience therein, I can tell you that the NLG (nagios looking glass) is probably what most people are using for the type of problem you list above.
The other huge, huge flaw of Nagios is configuring it. It shouldn't take a reference book from O'Reilly to do this efficiently, but I'm afraid it does.
I certainly hope that it doesn't take an oreilly book, because they don't have one yet ;-) (only apress, no starch, and awp respectively). I've noticed an important difference between the kinds of programs I enjoy working with, and those that I do not. The programs I most enjoy (the programs that stick with me for decades) have in common a complicated initial setup. This comes from the fact that the programs are themselves complex and flexable, and the fact that I am opinionated about how I'd like them to work. If you read the online Nagios docs, and decide how you want it to work for you, then you will have a few hours of initial setup, followed by a decade of trouble-free operation. If you read the docs, and plan well, then adding new hosts, services, etc.. will take less time than making the ssh connection. On the other hand, if you install MOM, Patrol, Openview, or hyperwhatever, you will be running in a halve hour, and you will be lost in a infinitely recursive system of menus filling out web forms for every host and service change for the next year or two until the compulsory upgrade comes along. Then you will rip it all apart and start over.
That having been said, the initial setup with Nagios is really not all that hard guys. I'd tell you to go install Monarch if I thought that filling out webforms was easier, but I don't think having an input field on a webpage called "host" is necessarily easier than having some text in a file called "host". I will recommend however that you checkout NACE, which makes host configuration as simple as "nmap -sP 192.168.X.0/24 | grep 'Status: UP' | cut -d\ -f2 | WriteHosts.pl"
There are easily a dozen different configuration tools at www.nagiosexchange.org and sourceforge.net, and *every single one of them* has major problems that could be solvd with 10% of the time spent on Nagios itself. Most are abandonware, exciting but uncompleted projects that are never going to be completed. Others rely on hand-compiling Nagios itself with strange local modifications and local configurations that are very difficult to import a working Nagios to, or export from.
Again, some time on the lists would give you a good feel for what is wheat and what is chaff on NagiosExchange. Not all contributions are equal, and that's to be expected in any community. When someone does it right, other people use
Guys, It really doesn't need to be that hard. The primary nagios.cfg allows you to arrange the configuration any way you choose. Most people use large, object-specific config files, but there's no reason you couldn't break your config's down into host-based entities which contain a host, the services on that host, and the contacts/contactgroups for that host. A really lightweight shell wrapper could be used to cat together pre-configured "templates" into a hostX.cfg file. It could ask you questions like "what is the name of the host?" and you could answer the questions and have a config. Check out NACE, which can create a configuration for you given piped output from Nmap. In general, in Nagios land, if things are hard, it's because you're making them hard. Stop for a second and think about how you want things to work, and Nagios can be made to operate in the manner that you specify. All it takes is a bit of thought on your part.