Hello --
Hopefully the answers below will provide some insight into this issue:
sounds like a missing database driver. sure you installed the required
php-mysql or whatever your rdbms is driver for php (rpm -qa | grep php)?
btw - tell us about your database setup. as well as how icinga and idoutils are
setup, any specialities?
The output from the rpm -qa |grep php command is the following:
php-mysql-5.3.3-3.el6_2.8.x86_64
php-xmlrpc-5.3.3-3.el6_2.8.x86_64
php-common-5.3.3-3.el6_2.8.x86_64
php-pdo-5.3.3-3.el6_2.8.x86_64
php-pear-1.9.4-4.el6.noarch
php-ldap-5.3.3-3.el6_2.8.x86_64
php-xml-5.3.3-3.el6_2.8.x86_64
php-gd-5.3.3-3.el6_2.8.x86_64
php-cli-5.3.3-3.el6_2.8.x86_64
php-5.3.3-3.el6_2.8.x86_64
php-soap-5.3.3-3.el6_2.8.x86_64
The database set up via a yum installation. The packages that were installed
were the following:
mysql-libs-5.1.61-1.el6_2.1.x86_64
php-mysql-5.3.3-3.el6_2.8.x86_64
mysql-server-5.1.61-1.el6_2.1.x86_64
mysql-5.1.61-1.el6_2.1.x86_64
libdbi-dbd-mysql-0.8.3-5.1.el6.x86_64
libdbi-0.8.3-3.1.el6.x86_64
libdbi-drivers-0.8.3-5.1.el6.x86_64
libdbi-devel-0.8.3-3.1.el6.x86_64
libdbi-dbd-pgsql-0.8.3-5.1.el6.x86_64
libdbi-dbd-mysql-0.8.3-5.1.el6.x86_64
The icinga and icinca-web applications utilize the mysql database. The
following packages were
also installed for use with monitoring a remote postgresql server. Admittedly
this could be overkill.
postgresql-libs-8.4.9-1.el6_1.1.x86_64
postgresql-8.4.9-1.el6_1.1.x86_64
postgresql-server-8.4.9-1.el6_1.1.x86_64
Aside from the above, there were no specialties configured during the
installation process.
did you read that error? it clearly states that /usr/local/icinga-web/app/cache
is not writable by the apache webserver. so the next step would be to check how
the permissions are set on that dir, as well as verify that the apache user has
grants on that.
would be interesting, how you did call configure - which params, setting a
different web user, and such. might be an uid problem as well - who knows. be
more verbose.
When I ran the configure script for the application, there was a series of
options that were used to complete the process. The following is taken from the
config.status file from the installation directory:
ac_cs_config="'--prefix=/usr/local/icinga-web' '--with-web-user=apache'
'--with-web-group=apache' '--with-web-path=/icinga-web'
'--with-web-apache-path=/etc/httpd/conf.d' '--with-db-type=mysql'
'--with-db-host=localhost' '--with-db-port=3306' '--with-db-name=icinga_web'
'--with-db-user=icinga_web' '--with-db-pass=icinga_web'
'--with-conf-dir=etc/conf.d' '--with-log-folder=log'
'--with-api-subtype=driver' '--with-api-host=localhost' '--with-api-port=3306'
'--with-api-socket-path=none'"
ehm. this is a joke right? 777 for _all_ dirs plus recursive? why did you do
that dangerous setting?
This change was made in attempt to allow the necessary write access to the
/usr/local/icinga-web/app/cache directory. If this problem can be solved, I
will readily
change the permissions back to 644 on both directories.
be more verbose on your system. god knows which php version is being installed
on your centos 6.2 system, which php modules are installed, etc
and ever since it's a rhel based system, selinux comes to mind. especially on
the log side - there must be a reason being logged why apache is prohibited to
write to the cache dir.
btw - you did never show sort of ls -la on those dirs (and no, 777 is not a
choice. never. not even for testing. get to know your linux permissions.)
Hopefully the list that I provided earlier concerning php is exhaustive as to
what is installed on the server. I made sure to check the configuration of
selinux, and initially
it was set to enforcing mode. I reconfigured it to be disabled, and
subsequently rebooted the system. The output of the ls -la command for the
icinga and icinga-web folders is
the following:
[root@icinga local]# ls -la icinga
total 40
drwxrwxrwx. 10 root root 4096 May 21 16:47 .
drwxr-xr-x. 14 root root 4096 May 21 16:01 ..
drwxrwxrwx. 2 icinga icinga 4096 May 21 18:14 bin
drwxrwxrwx. 5 icinga icinga 4096 May 21 15:51 etc
drwxr-xr-x. 2 root root 4096 May 21 16:47 include
drwxrwxrwx. 2 icinga icinga 4096 May 21 15:40 lib
drwxrwxrwx. 3 icinga icinga 4096 May 21 16:47 libexec
drwxrwxrwx. 2 icinga icinga 4096 May 21 15:50 sbin
drwxrwxrwx. 11 icinga icinga 4096 May 21 16:47 share
drwxrwxrwx. 5 icinga icinga 4096 May 21 19:24 var
[root@icinga local]# ls -la icinga-web
total 36
drwxrwxrwx. 9 root root 4096 May 21 16:09 .
drwxr-xr-x. 14 root root 4096 May 21 16:01 ..
drwxrwxrwx. 8 root bin 4096 May 21 16:21 app
drwxrwxrwx. 2 root bin 4096 May 21 16:21 bin
drwxrwxrwx. 2 root bin 4096 May 21 16:21 doc
drwxrwxrwx. 4 root bin 4096 May 21 16:21 etc
drwxrwxrwx. 10 root root 4096 May 21 16:04 lib
drwxrwxrwx. 2 apache apache 4096 May 21 16:09 log
drwxrwxrwx. 6 root bin 4096 May 21 16:36 pub
[root@icinga local]#
The decision to make the directory permissions 777 is simply part of the
troubleshooting process that I conducted on my end. I do not intend to keep the
permissions as such when the server goes into production.
________________________________
From: Michael Friedrich [mailto:michael.friedr...@univie.ac.at]
Sent: Monday, May 21, 2012 6:51 PM
To: icinga-users@lists.sourceforge.net
Subject: Re: [icinga-users] Problem installing the new icinga-web interface
On 22.05.2012 00:31, Kaplan, Andrew H. wrote:
Hello --
Thank-you for your reply. I decided to start over and do a scratch installation
with CentOS 6.2 64 bit distribution. Everything appeared to install properly
but I am still having problems accessing the icinga-web interface. The error
message that I am seeing now is the following:
-> 500 internal server error!
=== Error ===
Uncaught exception AgaviDatabaseException thrown!
=== Message ===
Unknown driver driver
=== Stacktrace ===
#0
/usr/local/icinga-web/app/modules/AppKit/lib/database/AppKitDoctrineDatabase.class.php(39):
AgaviDoctrineDatabase->initialize(Object(AgaviDatabaseManager), Array)
#1
/usr/local/icinga-web/app/modules/Api/lib/database/IcingaDoctrineDatabase.class.php(41):
AppKitDoctrineDatabase->initialize(Object(AgaviDatabaseManager), Array)
#2
/usr/local/icinga-web/app/cache/config/databases.xml_production__d456b1c7b5b6f4555af532308cccdc6e4f0d873e.php(49):
IcingaDoctrineDatabase->initialize(Object(AgaviDatabaseManager), Array)
#3
/usr/local/icinga-web/lib/agavi/src/database/AgaviDatabaseManager.class.php(142):
require('/usr/local/icin...')
#4
/usr/local/icinga-web/app/cache/config/factories.xml_production_web_acd19321d1da3485b30f625f8f339c317a2a9ac5.php(52):
AgaviDatabaseManager->initialize(Object(AppKitAgaviContext), Array)
#5
/usr/local/icinga-web/app/cache/config/compile.xml_production__119920113a175a2dcea22e33a36de83ba298e663.php(384):
include('/usr/local/icin...')
#6
/usr/local/icinga-web/app/cache/config/compile.xml_production__119920113a175a2dcea22e33a36de83ba298e663.php(3549):
AgaviContext->initialize()
#7
/usr/local/icinga-web/app/cache/config/compile.xml_production__119920113a175a2dcea22e33a36de83ba298e663.php(370):
AppKitAgaviContext->initialize()
#8 /usr/local/icinga-web/pub/index.php(49): AgaviContext::getInstance('web')
#9 {main}
sounds like a missing database driver. sure you installed the required
php-mysql or whatever your rdbms is driver for php (rpm -qa | grep php)? btw -
tell us about your database setup. as well as how icinga and idoutils are
setup, any specialities?
I did a check of the error_log file for the apache server, and here is what I
found:
[Mon May 21 16:44:44 2012] [error] [client 132.183.12.230] PHP Fatal error:
Uncaught exception 'AgaviCacheException' with message 'Failed to write cache
file
"/usr/local/icinga-web/app/cache/config/config_handlers.xml_production__d98552ff67d2d50d8def4e3ddb970ba8e8e151fc.php"
generated from configuration file
"/usr/local/icinga-web/app/config/config_handlers.xml".\n\nPlease make sure you
have set correct write permissions for directory
"/usr/local/icinga-web/app/cache".' in
/usr/local/icinga-web/lib/agavi/src/config/AgaviConfigCache.class.php:544\nStack
trace:\n#0
/usr/local/icinga-web/lib/agavi/src/config/AgaviConfigCache.class.php(95):
AgaviConfigCache::writeCacheFile('/usr/local/icin...', '/usr/local/icin...',
'<?php??// This ...', false)\n#1
/usr/local/icinga-web/lib/agavi/src/config/AgaviConfigCache.class.php(243):
AgaviConfigCache::callHandler('/usr/local/icin...', '/usr/local/icin...',
'/usr/local/icin...', NULL)\n#2
/usr/local/icinga-web/lib/agavi/src/config/AgaviConfigCache.class.php(475):
AgaviConfigCache::checkConfig('/usr/local/icin...')\n#3
/usr/local/icinga-web/lib/agavi/src/co in
/usr/local/icinga-web/lib/agavi/src/config/AgaviConfigCache.class.php on line
544
I verified the timezone setting on the php.ini file was set to my location as
opposed to the Default setting. Additionally, I did a search for all instances
of php.ini
on the server, and the only one that came up was at the /etc directory. The
icinga and icinga-web databases are present, and both are populated with tables.
did you read that error? it clearly states that /usr/local/icinga-web/app/cache
is not writable by the apache webserver. so the next step would be to check how
the permissions are set on that dir, as well as verify that the apache user has
grants on that.
would be interesting, how you did call configure - which params, setting a
different web user, and such. might be an uid problem as well - who knows. be
more verbose.
The icinga and icinga-web directories are both owned by the root user and
group, but have 777 permissions on them, and all their respective
subdirectories.
ehm. this is a joke right? 777 for _all_ dirs plus recursive? why did you do
that dangerous setting?
What do I need to do now?
be more verbose on your system. god knows which php version is being installed
on your centos 6.2 system, which php modules are installed, etc
and ever since it's a rhel based system, selinux comes to mind. especially on
the log side - there must be a reason being logged why apache is prohibited to
write to the cache dir.
btw - you did never show sort of ls -la on those dirs (and no, 777 is not a
choice. never. not even for testing. get to know your linux permissions.)
i'm wondering though why you do not use the repoforge rpms, or at least build
the rpms on your very own, as described in the wiki howto space. having fun
with sources ... well.
________________________________
From: Markus Frosch [mailto:mar...@lazyfrosch.de]
Sent: Monday, May 21, 2012 4:37 PM
To:
icinga-users@lists.sourceforge.net<mailto:icinga-users@lists.sourceforge.net>
Subject: Re: [icinga-users] Problem installing the new icinga-web interface
Hello Andrew,
One thought that came to me was whether or not the IDOutils software was
installed in the first place. The system in question
is a running Nagios 3.3.1 installation that is being migrated to the Icinga 1.7
standard. The procedure that I am following to do
the migration includes downloading the icinga-1.7.0.tar.gz file from the
sourceforge website.
This brought several questions to mind:
1. Does the file in question include the idoutils software?
2. How can I determine if the IDOutils software has been installed on the
server?
3. If the answer to the first question is no, what steps can I take to install
the appropriate software on the server?
The IDOutils are distributed with the Icinga Core software and yes, that means
the 1.7.0 release tarball.
For beginners with Icinga I strongly recommend to have a look on the
Debian/Ubuntu packages. Afaik there are no official releases of 1.7.0 for
Ubuntu yet. But there are nightly builds of the newest packages on the Icinga
Buildserver. For Debian itself 1.7.0 is available via backports and the newest
unstable tree (since last weekend).
IDO consists of serveral components, a plugin in Icinga, a daemon to handle the
data, and the database to store it.
Software like Icinga Web accesses this database to evaluate the status of your
monitoring system.
Useful resources should be:
http://docs.icinga.org/latest/en/quickstart-idoutils.html
http://icingabuild.dus.dg-i.net/ (The nightly buildserver with builds for lucid)
Regards
Markus
--
Markus Frosch
mar...@lazyfrosch.de<mailto:mar...@lazyfrosch.de>
http://www.lazyfrosch.de
The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net<mailto:icinga-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/icinga-users
--
DI (FH) Michael Friedrich
Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria
email: michael.friedr...@univie.ac.at<mailto:michael.friedr...@univie.ac.at>
phone: +43 1 4277 14359
mobile: +43 664 60277 14359
fax: +43 1 4277 14338
web: http://www.univie.ac.at/zid
http://www.aco.net
Lead Icinga Core Developer
http://www.icinga.org
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users
