Details
-
Improvement
-
Resolution: Unresolved
-
Major
-
None
-
Professional Edition
-
None
Description
Currently all static configuration is loaded only from `config.php`.
However, we commonly have some additions to Observium instance added to config.php. These include, for example, addition of some monitoring plugins not included by Observium Professional by default:
// DNS Probe
|
$config['probes']['check_dns']['enable'] = 1; |
$config['probes']['check_dns']['descr'] = 'Tests DNS'; |
$config['probes']['check_dns']['args']['default'] = "-s %hostname%"; |
|
// NTP Probe
|
$config['probes']['check_ntp_time']['enable'] = 1; |
$config['probes']['check_ntp_time']['descr'] = 'Tests NTP'; |
$config['probes']['check_ntp_time']['args']['default'] = "-H %hostname%"; |
Instead of managing these as custom modification (appended to) config.php file, it would be cleaner to have config.d/ directory. Directory can also be named conf.d/ to conform with linux/unix convention. Contents of this directory should be excluded from version control.
Observium would read config.php first and then include all .php files from config.d/*.php. Dotfiles should be ignored and files having non-php extension.
This way Observium users could dynamically, cleanly and bit more safely add instance specific customizations (or any other static configurations) such as
config.d/config.ntp-probe.php
// NTP Probe
|
$config['probes']['check_ntp_time']['enable'] = 1; |
$config['probes']['check_ntp_time']['descr'] = 'Tests NTP'; |
$config['probes']['check_ntp_time']['args']['default'] = "-H %hostname%"; |
This feature can currently be implemented as custom "footer code" appended to config.php, but it would nice if unmodified Observium Professional provided this.
Attachments
Activity
I don't think I really see the benefit. It's not intended for there to be a lot of configuration in config.php. Putting temporary additions in there where things aren't in the base distribution is meant to be temporary, and doesn't really warrant a more complex configuration handling system.
This seems like unnecessary complexity and only really adds scope for things to break, in the name of moving a couple of lines from config.php to config.d/?
Currently we have following config.d loader in config.php:
// Include custom configuration from config.d/*.php
|
if (is_dir(dirname(__FILE__) . "/config.d")) {
|
foreach (glob(dirname(__FILE__) . "/config.d/*.php") as $fn) {
|
include($fn);
|
}
|
}
|
I think similar could be implemented in get_defined_settings() @ functions.inc.php:
2372 function get_defined_settings($key = NULL) {
|
2373 $config = [];
|
2374 include($GLOBALS['config']['install_dir'] . "/config.php");
|
2375
|
2376 if ($key) {
|
2377 // return specific setting if defined
|
2378 return array_get_nested($config, $key);
|
2379 }
|
2380
|
2381 // never store this option(s) in memory! Use get_defined_settings($key)
|
2382 foreach ($GLOBALS['config']['hide_config'] as $opt) {
|
2383 if (array_get_nested($config, $opt)) { unset($config[$opt]); }
|
2384 }
|
2385
|
2386 return $config;
|
2387 }
|
.. and possibly in sql-config.inc.php (unless that is converted to use common get_defined_settings() function instead of custom implementation for loading config.php)
Note: Above were bad code examples as they are monitoring plugins already included and supported by Observium Professional by default.
The rationale behind this suggestion is that some of this custom configuration is coming from management framework injecting configuration files to servers.
It is much easier to bind to such configuration systems with dynamic conf.d structure than modifying/detecting modifications in monolithic configuration file. The same reasoning applies to common unix daemons configured from /etc files and providing conf.d parsers.
I do however see your point. Observium config.php can already be customized with conf.d loader easily if required by the customer.