<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Hi there,<br>
<br>
sorry for my mistaken first post to this list ;-)<br>
<br>
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. <br>
<br>
So the quick'n'dirty install from repository is<br>
<br>
yum install libdbi libdbi-devel libdbi-drivers libdbi-dbd-mysql<br>
<br>
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).<br>
<br>
-------------------------------------------------------------------------------------------------------<br>
libdbi.i386 : Database Independent Abstraction Layer for C<br>
libdbi.x86_64 : Database Independent Abstraction Layer for C<br>
libdbi-dbd-mysql.x86_64 : MySQL plugin for libdbi<br>
libdbi-dbd-pgsql.x86_64 : PostgreSQL plugin for libdbi<br>
libdbi-devel.i386 : Development files for libdbi (Database Independent
Abstraction Layer for C)<br>
libdbi-devel.x86_64 : Development files for libdbi (Database
Independent Abstraction Layer for C)<br>
libdbi-drivers.x86_64 : Database-specific drivers for libdbi<br>
</tt><tt>-------------------------------------------------------------------------------------------------------<br>
<br>
Then a short configure with -enable-idoutils and everything is fine.<br>
<br>
make as is doesn't work, maybe fix this to make all? Instead make help
should give all available options - should be better imho.<br>
<br>
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. <br>
<br>
Both flags from configure only modify the user which is being used, but
not creating it.<br>
<br>
--with-icinga-user=<user> sets user name to run icinga<br>
--with-icinga-group=<grp> sets group name to run icinga<br>
<br>
We should discuss this in deep here, but meanwhile, i will add the user
manually to step further.<br>
<br>
# groupadd icinga<br>
# useradd -g icinga icinga<br>
<br>
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<br>
<br>
make isntall-idoutils<br>
make install-config<br>
<br>
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).<br>
Others may try to install the IDOUtils with Postgre, I think this could
be done really easy.<br>
<br>
<br>
Besides, a little suggestion - why not registering a channel </tt><tt>to
irc.freenode.net </tt><tt>called #icinga-devel ? Like #nagios-devel.<br>
<br>
Kind regards,<br>
Michael<br>
<br>
</tt><br>
<br>
Hendrik Baecker wrote the following on 12.05.2009 22:14:
<blockquote cite="mid:4A09D897.9040307@process-zero.de" type="cite">
  <pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----
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:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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 :)

    </pre>
  </blockquote>
  <pre wrap=""><!---->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?

 >
  </pre>
  <blockquote type="cite">
    <pre wrap="">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.

    </pre>
  </blockquote>
  <pre wrap=""><!---->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.

  </pre>
  <blockquote type="cite">
    <pre wrap="">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

    </pre>
  </blockquote>
  <pre wrap=""><!---->
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoJ2JcACgkQlI0PwfxLQjm6XgCcDNCnptnZjTirhNhQUn29JRbG
URYAnA88LrQrqSh90BKUrbBHGdLt9cZ7
=mjV+
-----END PGP SIGNATURE-----

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
DI (FH) Michael Friedrich
<a class="moz-txt-link-abbreviated" href="mailto:michael.friedrich@univie.ac.at">michael.friedrich@univie.ac.at</a>
Tel: +43 1 4277 14359

Vienna University Computer Center
Universitaetsstrasse 7 
A-1010 Vienna, Austria  
</pre>
<br>
<pre class="moz-signature" cols="72">-- 
DI (FH) Michael Friedrich
<a class="moz-txt-link-abbreviated" href="mailto:michael.friedrich@univie.ac.at">michael.friedrich@univie.ac.at</a>
Tel: +43 1 4277 14359

Vienna University Computer Center
Universitaetsstrasse 7 
A-1010 Vienna, Austria  
</pre>
</body>
</html>