Contents

Configuration files

Location

The most common location for the configuration files will be /etc/fusionforge/config.ini and the files under /etc/fusionforge/config.ini.d/*. Note that in that directory, only files with extension ".ini" and those without an extension will be taken into account (so that files such as foo.old, foo.bak and so on are ignored). Note also that you can reference other files and directories by adding extra_config_files and extra_config_dirs variables (see below) to one of the standard files.

If you're upgrading from a version of FusionForge before 5.1, the migrate-to-ini-files.sh script should take care of migrating your setting from the previous system. In this case, you'll get /etc/fusionforge/config.ini.d/zzz-migrated-old-config and /etc/fusionforge/config.ini.d/zzz-migrated-old-secrets.

Syntax

The config files are standard *.ini files as widely used in Windows, PHP and other systems. It's basically a key/value store, where there are different namespaces for the keys called sections. The variables controlling the features in the core of FusionForge are in section [core], the variables controlling the "headermenu" plugin are in section [headermenu], and so on.

For values storing a string, quoting is required when the string contains spaces, or quotes, or any kind of special character. For boolean variables, some flexibility is available, and the value can be stored as "true", "1", "on", "yes", "false", "0", "off" or "no".

Comments start with a semicolon and extend to the end of the line. Empty lines are ignored.

Variables can reference one another with the "$section/variable" syntax. For instance, in section [scmsvn], the default value for repos_path is defined in relation to the value of chroot in section [core] with the following syntax: repos_path = "$core/chroot/scmrepos/svn". If the chroot variable is set to /srv/fusionforge/chroot, then the repos_path value will automatically contain /srv/fusionforge/chroot/scmrepos/svn; other variables will also be updated accordingly, without needing to set their individual values in the config files.

Overriding defaults for a local installation

Instead of changing the contents of the defaults.ini file (or other files shipped with the distribution), it may be better to add a /etc/fusionforge/config.ini.d/zzzz-local.ini (or a similar name to make sure it is the last one in alphabetical order) which will contain local settings overriding the defaults defined earlier in other files.

Included in the /etc/fusionforge/config.ini.d directory is one of two "ini" files, which depending on your installation host will be either debian-install.ini or rpm-install.ini. These are maintained exclusively by the packaging system (DEB or RPM).

Access and debugging

If you're confused as to what value a configuration variable ends up with at the end of the parsing of the (possibly many) config files and the interpolation of variables, there's a helper script forge_get_config (available in the utils directory) that displays this value. Its usage is: "forge_get_config web_host core" (change the location of the script if it's installed elsewhere, of course). The arguments are the variable name, and the section; the section can be omitted if it's "core". Another possible invocation is "forge_get_config list-all-variables", which will give you a list of all the configuration variables, and "forge_get_config list-all-variables-values" which will display all of their values too.

Note that this script tries to behave exactly like the rest of the forge in order for the returned results to be accurate. In some cases, though, the user running the script may not have the appropriate rights to read all configuration files, and the script will exit with an error because it tries to access the database. The fix is to run the script with a environment variable that disables the loading of plugins (and the database access): "FUSIONFORGE_NO_PLUGINS=true forge_get_config web_host".

Configuration variables for section core

allow_project_without_template (boolean): allow users to not choose a template project when registering a new project. If false, then new projects will always be based on a template (unless no such template exists, of course).

apache_group (string): automatically set by install script or distribution package. Adjust if you need to use specitif linux group.

apache_user (string): automatically set by install script or distribution package. Adjust if you need to use specitif linux user.

chroot (string): path where all chrooted elements are located. (See groupdir_prefix for instance). Default is $core/data_path/chroot

project_auto_approval_user: if project_auto_approval=true, username of the effective FusionForge user that approves the project internally (default admin); this user needs to have approve_projects privilege.

project_registration_restricted (boolean): if true, prevent users from registering projects - useful if you don't want to accept new project requests.

require_unique_email (boolean): whether to require that user's email addresses are unique among all users, or not

restrict_users_visibility (boolean): limit visibility on user detail to users that are sharing projects. meaning: a user must be part of a same project to see detail of another user. Default value: no.

session_key (string): set session key use by hash_mac in cookie session. Must be >4 characters. Automatically generated by installer.

session_expire (int): set session validity in seconds. By default, it is not set.

shell_host: host users connect to in order to manage their group htdocs/ and incoming/ shared directories; used for documentation only

sitestats_projects_count (all | visible): some site admins are pretty obnoxious about hiding any trace of private projects; all shows the real number of hosted projects, visible shows the number of projects that are visible to the current user.