There are several tables/databases involved in nagiosxi.
Where are the permissions for the databases? What are they suppose to be?
Does nagiosxi support MySQL database?
Database Permissions
Re: Database Permissions
I don't mean to harp on this, but you asked and it's hard to say any part of this w/o first explaining the choices made from an overall view.
Our web page(s)/PHP and daemon(s) all need access to the database and there is no way to give them access while at the same time not exposing the password to any user that has shell access. Thus any password that's set is unable to perform it's function as a measure of security. As the database should only be accessible VIA UNIX Domain sockets the database will be unacceptable from any one that does not have a shell level access. Thus any shell access is treated as having a permissions level of God. We do take care to guard against users escalating to root.
There permissions on the database are open. For audits and compliance we are looking at removing the passwords so that ppl don't have to change any password from a default as the audits requiter. This will further simplify our applications and avoid a needless password exchange.
If you were referring to the database files and there UNIX/POSIX permissions, we don't alter these from what MySQL/PostgresSQL configure.
The MySQL database is not where the fun/important parts of NagiosXI live, though there is some information here. The configuration is mostly stored in Postgres. We don't recommend accessing this database directly, though there are a handful of ppl on these forums that have.
I hope I was able to answer whatever it was you wanted to know, if you need more information I'd be happy to elaborate.
Our web page(s)/PHP and daemon(s) all need access to the database and there is no way to give them access while at the same time not exposing the password to any user that has shell access. Thus any password that's set is unable to perform it's function as a measure of security. As the database should only be accessible VIA UNIX Domain sockets the database will be unacceptable from any one that does not have a shell level access. Thus any shell access is treated as having a permissions level of God. We do take care to guard against users escalating to root.
There permissions on the database are open. For audits and compliance we are looking at removing the passwords so that ppl don't have to change any password from a default as the audits requiter. This will further simplify our applications and avoid a needless password exchange.
If you were referring to the database files and there UNIX/POSIX permissions, we don't alter these from what MySQL/PostgresSQL configure.
The MySQL database is not where the fun/important parts of NagiosXI live, though there is some information here. The configuration is mostly stored in Postgres. We don't recommend accessing this database directly, though there are a handful of ppl on these forums that have.
I hope I was able to answer whatever it was you wanted to know, if you need more information I'd be happy to elaborate.
Re: Database Permissions
What databases/tables/files are updated when a configuration change is made from the GUI. The configuration changes are never completed and hang forever.
Alternately, is there a log that will tell me what is going wrong?
So I can answer my own question.
Alternately, is there a log that will tell me what is going wrong?
So I can answer my own question.
Re: Database Permissions
Hi, I think the config is in the mysql, as part of nagiosql db. when the config is applied it will create nagios config files.
But me myself still wondering why xi used 2 different database: postgres for xi and mysql for nagios. if it needs transaction and advanced feature of sql, is mysql is not sufficient?
But me myself still wondering why xi used 2 different database: postgres for xi and mysql for nagios. if it needs transaction and advanced feature of sql, is mysql is not sufficient?
Re: Database Permissions
MySQL is not a real Database(IMHO). On top of that it's slow in most cases. Postgres's features don't necessarily come from it's implementation of SQL, though there are a great number of things that(last I checked) don't exist in MySQL. Postgres's main feature is it's non-overwriting data-storage technique, this contributes to both it's worthiness of being considered a database and it's great speed.
Still IMHO PostgresSQL is still a far cry from competing with Orical's Database products.
To answer the question here, we have bundled several different product together and wrote our own interface to make this look seamless. Thus the separation you are looking at stems from each component having it's own DB requirements, though I rather think it's just that this is the default DB for that project.
Still IMHO PostgresSQL is still a far cry from competing with Orical's Database products.
To answer the question here, we have bundled several different product together and wrote our own interface to make this look seamless. Thus the separation you are looking at stems from each component having it's own DB requirements, though I rather think it's just that this is the default DB for that project.
Re: Database Permissions
I think comparing MySql and Postgres will subject for debate. But MySQL is not a real DB can be easily tacked. if we are talking MyISAM yes, but not for InnoDB. But in the case of XI, if one of the DB fail say mysql, we can access XI but we can not use the system, it is no difference if we are using 1 db, if mysql down, then all XI system will fail, its the same result and we know the problem is in the DB.
Re: Database Permissions
InnoDB may be ACID, but that does not make a real database. A real database does not use journals or pre-sorted record placement, InnoDB has both.
As for databases failing, each component uses just one. So the DB that fails will take out one component. However the real task is Nagios Core and this does not use either DB. After the DB failed you can export the Nagios Core configuration and import it into NagiosQL and the other DBs will automatically be populated from Nagios Core. Save nagvis and perhaps other addon projects.
As for databases failing, each component uses just one. So the DB that fails will take out one component. However the real task is Nagios Core and this does not use either DB. After the DB failed you can export the Nagios Core configuration and import it into NagiosQL and the other DBs will automatically be populated from Nagios Core. Save nagvis and perhaps other addon projects.