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: forge_get_config(variable, section) 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

Alternative: one $FUSIONFORGE_CONFIG_FILE and maybe a
$FUSIONFORGE_CONFIG_SECRETS

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 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

Some Remarks (Thorsten Glaser)

If we have /path/to/config/*.ini the files themselves should NOT be in the “Windows INI” format. We could keep them ASCIIbetically sorted and SCM managed, even, to ease merges.

Not only DB, some people like Unix principles and text files. But this is (mostly) about the API, so it’s not important, just a sample implementation.

We must, as part of the API, specify valid section and variable values. My suggestion: valid=[A-Za-z0-9_]+ but handled case-INsensitively. This would be mostly in line with shell/PHP which already exists.