[Icinga-devel] Icinga: Review and IDOUtils (Oracle)

Michael Friedrich michael.friedrich at univie.ac.at
Tue May 12 18:13:16 CEST 2009


Hi there,

thanks for the Update, i have checked out an actual copy of the Icinga Core.

Here is what I've reviewed so far concerning your TODO tickets.

* in module/idoutils/src/ the old version of log2ndo.c ist still the 
original file and needs to be rewritten in case (vim log2ndo.c 
:%s/ndo/ido/g etc). This issue concerns most of the code in ido but it 
doesn't matter for functionality right now.
* ndo.h/ndo2db.h seem to be referenced in many files, renaming could 
lead to several problems
* main dir: INSTALLING seems to be the original version
* base/ contains file which include icinga.h but "Last modified" is not 
set (very little concern for this)
* includes/icinga.h consists of statement
#ifndef _NAGIOS_H
#define _NAGIOS_H
It shouldn't matter in this case but coding standards will tell that 
this define should look like the name of the headerfile.


I've tried to ./configure icinga-core, without flag it just does fine 
and tells at the end. If I run configure with -enable-idoutils (Note: 
would be better to name it --enable-idoutils or --with-idoutils like 
other configure flags), without having libdbi installed, a nice error is 
shown and configure breaks. So far what I expected.

Now for the difficult part using the idoutils (this has to be clearly 
inserted into INSTALLING because if the WebIF is setup onto the 
idoutils, users shouldn't get confused in the first place!).


First of all, installing the libdbi itsself [1] from CVS (anonymous 
without pw). Regarding the mailinglist on the same page you should 
definitely join it!

export CVSROOT=:pserver:anonymous at libdbi.cvs.sourceforge.net:/cvsroot/libdbi
cvs login
cvs -z3 co libdbi

./autogen.sh
./configure

If you do not happen to have the SGML Toolchain (whatever that is) installed, use the following, otherwise make will throw an error.

./configure --disable-docs


Second, install DB devel files fitting your needs (I will try mysql at 
first):

yum install mysql-devel


Third, getting the libdbi-drivers [2] from CVS. In RHEL Repo there is a 
package called libdbi-dbd-mysql for libdbi. Haven't tried that yet.

export CVSROOT=:pserver:anonymous at libdbi-drivers.cvs.sourceforge.net:/cvsroot/libdbi-drivers
cvs login
cvs -z3 co libdbi-drivers

AVAILABLE DRIVERS:
------------------

* Firebird/Interbase (experimental)
* mSQL (experimental)
* MySQL
* Oracle (experimental)
* PostgreSQL
* SQLite
* SQLite3
* Ingres 2006 (experimental)


./autogen.sh
./configure --with-mysql

OK this routine doesn't really work on an x64 RHEL, the ./configure script also ignores the proposed /usr/lib64/mysql as --with-mysql-libdir. 
I've removed the compiled versions and tried the libdbi-dbd-mysql Package for RHEL.

Ok and now for the Icinga part, I am stuck with the lib64 directory to hand over to the configure-script, or an automated check. 
I've tried hacking the configure file - doesn't work. Even tried to create softlinks from libdbi.so* from lib64 to lib - doesn't work.
So if there's a quick hack for configure on x64 it would be much appreciated :)

That's all for now concerning my first tests.


Talking about the DB-Scheme - in my opinion it is not a DB-Design, it's 
a Design by "How can I input data really fast without thinking too much 
and I don't care about organizing it and giving back to the user" or 
nuff said, seeing the picture of configs and logs and creating a schema 
of them.

For those who speak german, this article is kind of interesting:
http://www.linux-magazin.de/heft_abo/ausgaben/2008/06/ampel_koalition

In case of performance (not only reading from the DB but also cleaning 
up historical data) this design MUST be reworked. Working out PKs and 
FKs and avoiding that much joins by building single tables altogether 
with better relations should be the first step away from this "star 
based" DB design. Of course

I've also read several requests about Postgre or sqllite on the main 
blog and forums, mine is concerning Oracle.

As far as I have discussed with Hendrik via Email, a merge of ndoutils 
and ndoutils oracle would be the best to have. Implementing the libdbi 
into the IDOUtils with an abstracted database layer is a very good 
option (and writing correct SQL-statements which match to many database 
languages). libdbi is a wrapper and consists of several drivers as 
backend, iirc MySQL, Postgre are stable while Oracle remains unstable 
and kind of "huh where's the oracle guru?". For what it's worth, the 
IDOUtils will only require the libdbi installed and configured (first 
install libdbi, then the libdbi-driver, and then Icinga with IDOUtils 
enabled).
This is something I need to test after testing Icinga IDOUtils with 
libdbi on our Testingstage.

There are also some conventions using Oracle, I have mentioned some of 
them already at nagios-portal.org. The tablenames in the DB-Schema are a 
bit long, Oracle allows a maximum of 30 characters per tablename. The 
longest raw tablename in the design is 30 characters but using this 
scenario we cannot use the table prefix anymore - which is configurable 
within the cfg's for god's sake. That's a good solution for the first 
part concerning Oracle. Meanwhile other things to cleanup in the code, 
e.g. sql-queries and parameter binding.
Another task will be to remove significant language-specific keywords 
and be more abstract, even if we lose performance in this case. This 
stands mostly for conversions and concerns also the internal garbage 
collector which uses a lot of time build and compare functions.


Kind regards,
Michael


[1] http://libdbi.sourceforge.net/development.html
[2] http://libdbi-drivers.sourceforge.net/development.html


Hendrik Baecker wrote the following on 11.05.2009 15:36:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi List,
>
> YOU ARE RIGHT!
> It wasn't the best idea to announce a fork without showing the
> workprogress open to the public.
>
> The git is open now for the icinga-core.git subproject. web and api will
> follow as soon as possible - hopefully regardless of the first release
> dates ;)
>
> GitWeb: http://git.icinga.org/
> Issuetracking: http://dev.icinga.org/
> Pure Git: git clone git://git.icinga.org/icinga-core.git
>
> As promised in another thread I'm now going offline to write a small git
> howto for the whom who don't know it up to know.
> For the others: git formated patches are more welcome as the other ones ;)
>
> Regards,
> Hendrik
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoIKcsACgkQlI0PwfxLQjnrrQCggPUzR8qYPQzzCj27N04F24Yg
> fNsAoIXrYqV7D4CFNAnEo0cnrMGSpEt6
> =bL/t
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Icinga-devel mailing list
> Icinga-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/icinga-devel
>
>   

-- 
DI (FH) Michael Friedrich
michael.friedrich at univie.ac.at
Tel: +43 1 4277 14359

Vienna University Computer Center
Universitaetsstrasse 7 
A-1010 Vienna, Austria  





More information about the icinga-devel mailing list