[Icinga-devel] Review and IDOUtils (Oracle) Part II

Michael Friedrich michael.friedrich at univie.ac.at
Wed May 13 13:26:24 CEST 2009

Hi there,

sorry for my mistaken first post to this list ;-)

I was a bit tired yesterday, so i didn't recognize that I forgot 
installing the libdbi-devel package for RHEL. I did not check the 
configure-script for Icinga on getting the dbi.h which was missing in 
the system.

So the quick'n'dirty install from repository is

yum install libdbi libdbi-devel libdbi-drivers libdbi-dbd-mysql

I've also seen a postgre-ready package for libdbi, so far postgre should 
also work as requested on the bugtracker (cannot test it myself meanwhile).

libdbi.i386 : Database Independent Abstraction Layer for C
libdbi.x86_64 : Database Independent Abstraction Layer for C
libdbi-dbd-mysql.x86_64 : MySQL plugin for libdbi
libdbi-dbd-pgsql.x86_64 : PostgreSQL plugin for libdbi
libdbi-devel.i386 : Development files for libdbi (Database Independent 
Abstraction Layer for C)
libdbi-devel.x86_64 : Development files for libdbi (Database Independent 
Abstraction Layer for C)
libdbi-drivers.x86_64 : Database-specific drivers for libdbi

Then a short configure with -enable-idoutils and everything is fine.

make as is doesn't work, maybe fix this to make all? Instead make help 
should give all available options - should be better imho.

Ok then, did make all. Then as suggested - make install. And here we go 
again with the bugtracker - user icinga not found in the system. Hmmm 
ok, that's nasty to add it manually. I would prefer by creating it 
during the configure routine, checking if sudo/root is enforced.

Both flags from configure only modify the user which is being used, but 
not creating it.

--with-icinga-user=<user> sets user name to run icinga
--with-icinga-group=<grp> sets group name to run icinga

We should discuss this in deep here, but meanwhile, i will add the user 
manually to step further.

# groupadd icinga
# useradd -g icinga icinga

Nice indeed, that there is no version discrepancy between version 2.x 
and 3.x which was really a pain in the ass using nagios

make isntall-idoutils
make install-config

So far, it seems to be fine. After a meeting break, I will succeed in 
further tests (and then try the big stuff with libdbi compile and oracle).
Others may try to install the IDOUtils with Postgre, I think this could 
be done really easy.

Besides, a little suggestion - why not registering a channel to 
irc.freenode.net called #icinga-devel ? Like #nagios-devel.

Kind regards,

Hendrik Baecker wrote the following on 12.05.2009 22:14:
> Hash: SHA1
> Hi Michael,
> thanks for the quick howto on installing libdbi from source. Up to now I
> was to lazy and worked with my debian packages. But I'm lazy with a
> reason: If I would code against the latest cvs snapshot, I possible
> break dependencies of common distributions.
> I'm happy enough to see libdbi in debian/ubuntu, rhel repositories. I
> think it wouldn't be much user friendly if we depend on the newest
> sources if we don't have to use the newest libdbi funcs cause they give
> us a significant benefit.
> But we can talk about it, as the time for that discussion comes.
> Michael Friedrich schrieb:
>> 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 :)
> hm... no problem here on my debian 5.0 64bit.
> Did you run a fresh, uncached configure after installing the packages?
> May be a simple "ldconfig" was missing?
>  >
>> 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.
> The db scheme is a complex one, yes. IMO, it's well normalized what
> should be good for a database. But I am NOT a database guys, I just
> remembering things from school time.
>> 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
> Are you only talking about keys and indizies or changing the structure?
> First I would like, second I won't (up to now).
> I know the cleaning up functions results in horrible performance lacks,
> since the communication from the core -> module -> ido2db -> database is
> more a blocking one, every longrun database operation will stale the
> monitoring.
> I would like to solve this, best way when we don't have to touch the
> structure what will result in breaking other already alive addons that
> are using this structure.
> I believe that we can bring more performance to the database with a
> clever set of keys and indizies, bring some buffer to ido2db to be more
> non-blocking. May be we can play with some funny threads if we can
> resist against duplicate writes, may be some partial table locking is
> needed for that.
> Btw: I've heard from a friend of mine, who tweaks the indizies in mysql
> and now he's able to work with "-1" broker options in a 3000+ objects
> environment without getting into trouble of blocking clean ups.
> I have to bring him a beer to tell me his secret indizies, but may be
> he's reading this and remembers for himself. ;)
> Regards,
> Hendrik
> Version: GnuPG v1.4.9 (GNU/Linux)
> URYAnA88LrQrqSh90BKUrbBHGdLt9cZ7
> =mjV+

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  

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  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.icinga.org/pipermail/icinga-devel/attachments/20090513/e6bcf3de/attachment.html>

More information about the icinga-devel mailing list