NDOUtils 1.4b1 Released

[Andreas Ericsson]

Marlo Bell wrote:
> Hey Andreas,
> 
> I appreciate the feedback on my suggestions, but I was a little
> confused by your objection to point number two. If point number 1 is
> true, some form of point number 2 must also be true. Currently Hosts
> and Services are linked by name in the objects table
> objects.name1=Host Name, objects.name2=Service Desc. If these go away
> (which we both agree they should), either the services table then
> needs to hold a hostname field with hostname(s) and/or a regex for a
> group of hosts. While it is programmatically possible to then explode
> this, it doesn’t make sense in a relational database. To truly
> reflect what nagios is capable of doing with hosts and service
> relationships (i.e. “*”,”Router*”,”Router1,Router2”)  and maintain
> some degree of normality an association table is needed. I have
> attached a quick diagram that I drew up of how this would look.
> 

No it's not. The NDO database isn't intended to be modified. It's a 
read-only database for anyone but the Nagios daemon. As such, it doesn't 
make sense to store things in an unexploded state.

For a configuration tool that stores a nagios config in database it 
*might* be worth doing what you propose, but such a tool should have the 
capability to make copies of hosts and otherwise have simple mechanics 
for saving user-time other than forcing the user to learn regular 
expressions.

> 
> In looking at this a Service isn’t an object, a Host-Service is an
> object as well as a Host. By making it this way a Host can have many
> Services and a Service can exist on many hosts while still
> maintaining an optimized DB schema. It is a little bit of thought
> process change from using regex, but if the database is eventually
> going to become the authority on object configuration as well as
> logging, this is seems more appropriate.
> 

But it's not. The database objects *have* to be read-only as long as 
Nagios is running, otherwise you'd end up with a gui that tries to show 
hosts that Nagios has no clue about.

Implementing a webconfiguration interface that stores things in database 
isn't all that tricky, but for such things I'd imagine you'd be better 
off using some sort of templating scheme, letting the user say:

"I want to add a host named *this*, located *here* which does *this*. 
The type of the host is *windows-dmz*"[1]

The config gui would then just add the checks the user has previously 
decided are necessary for "windows-dmz" type hosts. Other checks should 
still be possible to add, ofcourse, but I would be appalled to see a 
configuration tool using regular expressions.

[1] Actually, this could be implemented in Nagios straight away, using a 
syntax such as this:

define host_type {
	type_name             windows-dmz
	contactgroup_name     windows-dmz-contacts
	icon                  windows-dmz-icon

	define service {
		blahblah...
	}

	define service {
		blahblah...
	}

	define service {
		blahblah...
	}
}

The real (as in "internal in nagios") objects could easily be created 
from info such as this.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel