Small feature suggestion - ports/brew/dpkg/etc collections
Couple of small feature suggestions
- Would be nice if we could rely on a
http://www.observium.org/observium-0.16.1.7533.tar.gz
in parallel to the standard
http://www.observium.org/observium-community-latest.tar.gz
for the varius dpkg/debian/freebd/brew port collections.
- Would be nice if the block in defaults.inc.php with:
// Location of executables $config['rrdtool'] = "/usr/local/bin/rrdtool”; ……. $config['file'] = "/usr/bin/file”;
could be overwridden by a <ROOTDIR>/config.os.php - and perhaps itself live separate from the defaults.
As this allows a puppet/ansible/chef recipe (or the various ports collections) to manage this file as an OS specific thing; and keep the per system configs strictly in config.php.
Making the latter the only thing to preserve across migrations (and not having to cross check it for OS specific ‘new’ things).
With more and more people using things like vagrant/docker/etc - that sort of abstraction becomes useful.
Dw.
If you’re going to generate something using a config management system; why not just template config.php itself?
jinja templating in Salt is my preference. Ansible should be the same.
Pretty certain Puppet and Chef support the same capability too. Probably in a slightly more archaic way but still usable.
e.g.
[~/SRC/salt/file_root/observium]$ cat init.sls | grep ^observium_config_file -A 10 observium_config_file: file.managed: - name: /etc/observium/config.php - user: root - group: root - mode: 0644 - source: salt://observium/files/config.php - template: jinja - require: - file: observium_config_dir
[~/SRC/salt/file_root/observium]$ head files/config.php <?php
// /etc/observium/config.php
// This file is managed by Salt Stack. Make changes to the state NOT this file.
// Database config $config['db_host'] = '{{ salt['pillar.get']('observium:db:host', 'localhost') }}'; $config['db_user'] = '{{ salt['pillar.get']('observium:db:user', 'observium') }}'; $config['db_pass'] = '{{ salt['pillar.get']('observium:db:pass', 'FIX_ME') }}'; $config['db_name'] = '{{ salt['pillar.get']('observium:db:name', 'observium') }}'; $config['db_extension'] = 'mysqli'; [~/SRC/salt/file_root/observium]$
On 4 February 2016 at 22:36, Dirk-Willem van Gulik dirkx@webweaving.org wrote:
Couple of small feature suggestions
Would be nice if we could rely on a http://www.observium.org/observium-0.16.1.7533.tar.gz in parallel to the standard http://www.observium.org/observium-community-latest.tar.gz for the varius dpkg/debian/freebd/brew port collections.
Would be nice if the block in defaults.inc.php with: // Location of executables $config['rrdtool'] = "/usr/local/bin/rrdtool”; ……. $config['file'] = "/usr/bin/file”; could be overwridden by a <ROOTDIR>/config.os.php - and perhaps
itself live separate from the defaults.
As this allows a puppet/ansible/chef recipe (or the various ports collections) to manage this file as an OS specific thing; and keep the per system configs strictly in config.php.
Making the latter the only thing to preserve across migrations (and not having to cross check it for OS specific ‘new’ things).
With more and more people using things like vagrant/docker/etc - that sort of abstraction becomes useful.
Dw.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
If you're doing a scripted install you can always include your own include() in config.php - it's php code after all.
As for the first request, that sounds like a good idea indeed.
Tom
On 04/02/2016 13:46, Colin Stubbs wrote:
If you’re going to generate something using a config management system; why not just template config.php itself?
jinja templating in Salt is my preference. Ansible should be the same.
Pretty certain Puppet and Chef support the same capability too. Probably in a slightly more archaic way but still usable.
e.g.
[~/SRC/salt/file_root/observium]$ cat init.sls | grep ^observium_config_file -A 10 observium_config_file: file.managed: - name: /etc/observium/config.php - user: root - group: root - mode: 0644 - source: salt://observium/files/config.php - template: jinja - require: - file: observium_config_dir
[~/SRC/salt/file_root/observium]$ head files/config.php <?php
// /etc/observium/config.php
// This file is managed by Salt Stack. Make changes to the state NOT this file.
// Database config $config['db_host'] = '{{ salt['pillar.get']('observium:db:host', 'localhost') }}'; $config['db_user'] = '{{ salt['pillar.get']('observium:db:user', 'observium') }}'; $config['db_pass'] = '{{ salt['pillar.get']('observium:db:pass', 'FIX_ME') }}'; $config['db_name'] = '{{ salt['pillar.get']('observium:db:name', 'observium') }}'; $config['db_extension'] = 'mysqli'; [~/SRC/salt/file_root/observium]$
On 4 February 2016 at 22:36, Dirk-Willem van Gulik <dirkx@webweaving.org mailto:dirkx@webweaving.org> wrote:
Couple of small feature suggestions - Would be nice if we could rely on a http://www.observium.org/observium-0.16.1.7533.tar.gz in parallel to the standard http://www.observium.org/observium-community-latest.tar.gz for the varius dpkg/debian/freebd/brew port collections. - Would be nice if the block in defaults.inc.php with: // Location of executables $config['rrdtool'] = "/usr/local/bin/rrdtool”; ……. $config['file'] = "/usr/bin/file”; could be overwridden by a <ROOTDIR>/config.os.php - and perhaps itself live separate from the defaults. As this allows a puppet/ansible/chef recipe (or the various ports collections) to manage this file as an OS specific thing; and keep the per system configs strictly in config.php. Making the latter the only thing to preserve across migrations (and not having to cross check it for OS specific ‘new’ things). With more and more people using things like vagrant/docker/etc - that sort of abstraction becomes useful. Dw. _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
On 04 Feb 2016, at 14:02, Tom Laermans tom.laermans@powersource.cx wrote:
If you're doing a scripted install you can always include your own include() in config.php - it's php code after all.
On 04/02/2016 13:46, Colin Stubbs wrote:
If you’re going to generate something using a config management system; why not just template config.php itself?
jinja templating in Salt is my preference. Ansible should be the same.
Pretty certain Puppet and Chef support the same capability too. Probably in a slightly more archaic way but still usable.
Absolutely agreed - and as a first order solution that is what one does (and note that the various brew/ports/etc pretty much all patch includes/defaults.inc.php to much the same effect).
Perfectly workable.
The reason for suggestion to separate it out is more for enterprise settings - where increasingly you want to separate the configuration as tied (and versioned) against the OS and the version of the OS versus that of the service/site specific installation.
As they may be maintained by different people, under different test or compliance regimens, or a ‘tripwire’ IDS scan.
In those cases you then have to make the ‘hard’ call in your templating system where you ‘pull’ in the other. And if ‘that team’ forgets to do that - which test/release process should pick it up, and when.
It is much !MUCH! nicer if config.php contains very service specific things; like they MySQL password and what pollers are enabled; but -not- things tied to the OS (which you may be sourcing from a third party).
Nor should the ‘os’ level templating/patching be too concerned (or close) to your MySQL password. Especially as increasingly we are moving one part of our installs under the control of IDS systems; and increasingly control the sensitive parts with pass/file-safe’s. And we want the latter to be minimal.
So in other words - this level of separating is useful in the enterprise world.
And increasingly useful in a world where docker/vagrant drive one set of configs - and puppet/chef another and so on.
Again - this suggestion is not because there are no other options — this suggestion is to make Observium better in this new cloudy world.
Kind regards,
Dw.
participants (3)
-
Colin Stubbs
-
Dirk-Willem van Gulik
-
Tom Laermans