Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #3652] PHP-Problem when "Don't allow critical commands (like disabling host checks)" is enabled #1017

Closed
icinga-migration opened this issue Feb 7, 2013 · 13 comments

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/3652

Created by gbotti on 2013-02-07 19:55:59 +00:00

Assignee: mfrosch
Status: Resolved (closed on 2013-02-11 16:24:26 +00:00)
Target Version: 1.8.2
Last Update: 2013-02-11 16:24:26 +00:00 (in Redmine)

Icinga Version: 1.8.4
Icinga Web Version: 1.8.1
IDO Version: 1.8.4
OS Version: Debian Squeeze
DB Type: MySQL
DB Version: 5.1.66
Browser Version: Chrome, Firefox and Safari

I have created a user, that should be allowed to maintain some servers without critical commands.

The user is in role "appkit_user" only. Everything works fine until I activate the "Don't allow critical commands (like disabling host checks)" option.

To reproduce it I enabled this option. When I open the "services ok" tab and press "Refresh" I get the message "Request failed" (see Icinga-Web-Error.tiff). In the logfile the line

[Thu Feb  7 20:39:44 2013] [fatal] Uncaught AppKitDoctrineException: Class  for target not found! (/usr/local/icinga-web/app/modules/AppKit/lib/database/models/NsmTarget.php:56)

If I try to open "Host Details" the complete Interface freezes and the mentioned Error appears 4 times.

Changesets

2013-02-07 21:43:53 +00:00 by mfrosch 0d565b1

Fix missing change on the DB model of NsmTarget

The sql files have been fixed for 1.8.1, but not
the PHP class models.

(refs #3652)

2013-02-11 14:17:16 +00:00 by mfrosch 72f9533

Merge branch 'mfrosch/bug-3652' into mfrosch/1.8.2

(fixes #3652)

2013-02-11 18:39:56 +00:00 by mfrosch ac56d25

Fix missing change on the DB model of NsmTarget

The sql files have been fixed for 1.8.1, but not
the PHP class models.

(refs #3652)

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-02-07 20:05:49 +00:00

hm, and this relates to the reporting module in which way?

@icinga-migration
Copy link
Author

Updated by gbotti on 2013-02-07 20:18:24 +00:00

I am sorry.

I just saw, that I opened this Ticket in the wrong Project. But I cannot change that myself. I kindly ask an admin to move this Ticket to the "Web" - Project.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-02-07 20:22:49 +00:00

  • Project changed from 29 to Web

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-02-07 20:29:56 +00:00

  • Status changed from New to Feedback
  • Assigned to set to mfrosch

Well actually that sounds like an error we fixed in Web 1.8.1.

Please verify that your database has been updated to its 1.8.1 version, because its a database definition of the actual permission.

This is the change:
https://git.icinga.org/?p=icinga-web.git;a=commit;h=d7d04f4418555b734360b1a5511d00ee19e72991

@icinga-migration
Copy link
Author

Updated by gbotti on 2013-02-07 21:14:22 +00:00

I didn't update this server. I made a fresh installalation about a week ago. It was the first time I installed Icinga Web.

Anyway. You were right, the value 'IcingaDataCommandRestrictionPrincipalTarget' was not in my database. After I have added it the Error message is gone.

Thank you very much for your support.

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-02-07 21:15:50 +00:00

That is very strange, how did you install Icinga Web and its database?

@icinga-migration
Copy link
Author

Updated by gbotti on 2013-02-07 21:34:17 +00:00

First I installed some depencies with

apt-get install php5 php5-cli php-pear php5-xmlrpc php5-xsl php5-gd php5-ldap php5-mysql

then I downloaded the file icinga-web-1.8.1.tar.gz from sourceforge and unpacked it.

I ran

./configure --with-db-pass=MYPASS --with-api-db-pass=MYPASS --with-web-user=www-data --with-web-group=www-data
make install
make install-apache-config
make install-done

I also ran "make testdeps". There were no errors shown.

Then I created the database with:

mysql -u root -p
GRANT USAGE ON *.* TO 'icinga_web'@'localhost' IDENTIFIED BY 'MAPASS' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX ON icinga_web.* TO 'icinga_web'@'localhost';
quit

I checked the rights and the database with phpmyadmin.

Then "make db-initialize", where I confirmed the db-user specified-question with yes...

a2enmod rewrite
/etc/init.d/apache2 restart

After that I could log in with root and "password" into icinga-web.

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-02-07 21:46:52 +00:00

  • Category set to Database & Queries
  • Status changed from Feedback to Assigned
  • Target Version set to 1.8.2
  • Done % changed from 0 to 60

Ah i see, I missed to fix the model itself.

Guess the most users either don't use that feature, or install the db schema via the sql files.

dnsmichi: Please merge into 1.8.2
mhein: please check if that change is sufficent

Btw. there are Debian packages of 1.8.1 for squeeze - see http://www.debmon.org

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-02-07 21:47:42 +00:00

Git branch: mfrosch/bug-3652 based on r1.8

@icinga-migration
Copy link
Author

Updated by gbotti on 2013-02-07 22:09:13 +00:00

Thanks for your help! In future I will use the other way for importing schemes or I will try the repos from debmon.org ;)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-02-07 22:59:01 +00:00

ok, so this make db-initialize command will use those generated models. likely there could be other null'ed targets as well which may have been fixed in sql, but not in the nsm targets.

how about this one?

                array( 
                        'target_id'=>20,
                        'target_name'=>"icinga.cronk.custom",
                        'target_description'=>"Allow user to create and modify custom cronks",
                        'target_class'=> null,
                        'target_type'=>"credential"),

plus - i see ^M windows style here.

                array(^M
                        'target_id'=>22,^M
                        'target_name'=>"IcingaService",^M
                        'target_description'=>"Limit data access to specific services",^M
                        'target_class'=> "IcingaDataServicePrincipalTarget",^M
                        'target_type'=>"icinga"^M
                ),
                array(^M
                        'target_id'=>23,^M
                        'target_name'=>"IcingaHost",^M
                        'target_description'=>"Limit data access to specific hosts",^M
                        'target_class'=> "IcingaDataHostPrincipalTarget",^M
                        'target_type'=>"icinga"^M
                )

so i guess there's a little more to review here, so marius decides to merge/fix then as it's not obvious to me how this should look like.

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-02-11 13:56:31 +00:00

So, I diffed the mysql.sql file with the schema created my "make db-initialize" and it looks quite good.

Not all of these principals have an actual target - only those handled by specific permission classes.

I'd say this issue should be fixed with my commit.

@icinga-migration
Copy link
Author

Updated by mfrosch on 2013-02-11 16:24:26 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 60 to 100

Applied in changeset 72f9533.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant