FusionForge/Suggestions/Unified config

From FusionForge Wiki
Revision as of 11:41, 15 December 2009 by Olenz (talk | contribs) (Added remarks)

Jump to: navigation, search

Goal: simplify configuration no more gforge-config (than needed) no more setup no more local.inc + local.pl + plugins/foo/config.{php,pl} no more huge list of global variables $sys_use_this and $sys_use_that!

Means: one centralised point for config

While we're at it: that point could be different across instances (fusionforge.ini or database)

But: that mustn't mean changes in the code to change the configuration source

So: simple API to get configuration options concentrate intelligence of gathering the data in one point

API: get_config(section,variable) to get a value

Preferred solution: config is split into several files, for example /etc/fusionforge/config.d/*.ini -- actually $FUSIONFORGE_CONFIG_DIR/*.ini with FUSIONFORGE_CONFIG_DIR coming from environment


Get secrets (database access + passwords) from *.ini files if readable, overridden by Apache headers. Provide is a way to override config from the *.ini files with config stored in the DB.

Ship a set of pristine *.ini files in the packages' /usr/share/doc/fusionforge/examples/. Generate the initial files in /etc from those, to fill out the most frequently variable parts (hostname, IP address, DB password, session_key, etc.) but leave rarely-changed values to their default.

TODO: finish writing config.php; pick one of the appropriate Perl modules (popcon?); implement the configuration for Perl scripts; implement a gforge-get-config command to be used in shell scripts; on upgrade, parse existing config files, write new ones if needed, merge with ucf.

Some Remarks (Alain Peyrat)
Having the possibilities for plugins to provide web configuration is important for me.
For example, the configuration of the ldapextauth plugin should be possible using the browser.

Some Remarks (Christian Bayle)

  • I'm an extremist that think that only db access config should be out of the db, and that probably db access should be user controlled with some kind of kerberos mecanism with good grants in the db.
  • Why taking the risk of having a password, if we can get rid of it.
  • All use_<something> are probably hidden "service" plugin that should be in group_plugin table, disabling the plugin meaning

disabling the feature, with the subtility a plugin can be active or not at the project level

  • Should also be a subclass for "service" plugin, service meaning a tab in the project web page
  • Codendi implement a nice plugin interface and plugin priority management, so better to wait the availability of the code.
  • Rather prefix the var name with FF_ ( FF_CONFIG_DIR, FF_CONFIG_SECRET, ...) less FUSIONFORGE colored and shorter

Some Remarks (Olaf Lenz)

  • I agree with Christian: most config should be in the DB.
  • This makes it easier to configure it via the web interface than rewriting the config file (which is a security risk, anyway)
  • However, the following things should not be in the DB (and not configurable via the web interface):
    • DB credentials (obviously)
    • All data that is connected to the server OS:
      • Dirs used by FF: Config dir, Source dir, Var dir
      • Paths for executables: mailman, postgres

Back to the Roadmap