introduce "config-local.php" with only the adapted parts of the configuration

[bernisys]

Feature Request

Is your feature request related to a problem? Please describe

When ever we upgrade, we have to merge the configuration manually, which means that things can be overseen accidentally.

Describe the solution you'd like

Introducing a separate config file "include/config-local.php" for only the adapted parts would allow to handle the configuration much cleaner and easier.

The main config file just holds the defaults and stays untouched, and any recently added configurations will be taken directly from that file with their defaults. If needed, we can override them in the local config.

Benefits:

• keeps the local configuration small, as only the necessarily adapted things are listed there
• you can review the actual configuration a lot better (i.e. you see only the parts that were actually adapted)
• you can keep the original config unmodified in git and put an entry in .gitignore for the local config
• upgrades are easier, because the local configuration stays unchanged when you assemble the files
• config.php could be distributed across the environment

Cacti code includes first "include/config.php" with all the defaults. Then it processes (if available) "include/config-local.php" which contains the actual configuration. Existing variables would simply be overwritten with the local config's contents.

(Dokuwiki for example uses the same approach, works perfectly.)

[TheWitness]

We are going to take a slightly different track, for Linux/UNIX anyway. It'll be /etc/cacti.conf more than likely.

[TheWitness]

BTW, I overwrote mine over the weekend too ;)

[bernisys]

ouch :D ok you see the necessity then ;)

Probably you want to make the location of the config file configurable, because in our setup for example we have no root-access, so /etc is taboo for us. But as the paths to other files, i believe this can be added as a value in the DB easily.

Will you then follow also the approach of defaults in one file and the actual config in the other?

[bernisys]

Just reading my comment again points out my stupidity ... Having a DB configuration in a file, the path of which is configured in the DB makes pretty much no sense ... But we could place a symlink in /etc then once, that should do the trick.

Edit: better approach: Let cacti search also in its own folder for en /etc file, where this config can be placed. So if /etc/cacti.conf is not there, look into ./etc/cacti-conf "./" in this case being the current script evocation folder, maybe also cascading upwards ./etc ../etc ../../etc and so on at least a reasonable amount of levels

[netniV]

I would prefer that configuration files are just that. At the moment, our configuration file is actually executable which I dislike. We should also follow best practices and most systems these days seem to be adopting /etc/<software>.d/*.conf as a method of dynamic configuration.

This is something we are considering for 1.3 as we would like to be consistent there. It's too much work for the patch branch imho.

[bernisys]

/etc/cacti.d/ is actually a good solution, as the config can be split into separate parts and an admin could provide write permissions to that folder for a specific application user. This should work perfectly for such setups.

And +1 from my side, executable configs are a source of potential danger. Someone could add malicious code, and in case cacti is running as apache user, they could compromise the complete apache environment, parts of which are initially executed in a root context ...

KISS method with good old ini-file concept? ( [section] / key=value ) I honestly prefer that over yml and similar and i think that'd be sufficient for what cacti needs, as most values i can see are just key/value pairs. There should be ready to use parsers, making your life easy.

[TheWitness]

Sold!

[netniV]

Let me think on it