Difference between revisions of "Configuration"
|Line 76:||Line 76:|
* core/project_auto_approval (boolean): submit project(<tt>false</tt>
* require_unique_email (boolean): whether to require that user's email addresses are unique among all users, or not
Revision as of 13:01, 14 May 2014
- 1 Configuration files
- 2 Configuration variables
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.
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 "extratabs" plugin are in section [extratabs], 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/zz_my_settings.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.
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".
- 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).
- custom_path : path to a directory containing customizations to index_std.php
- database_host: hostname or IP address of the database server (or empty if the DB is accessed through the Unix-domain sockets).
- database_name: name of the database to use.
- database_password: connection password for the database.
- database_port: connection port for the database.
- database_user: user for the database connection.
- extra_config_dirs: directories containing other configuration files to read.
- extra_config_files: other individual configuration files to read.
- forge_name: the "visible name" of the forge. Used in webpage titles, in emails, in feedback messages, and so on. Could be set to "YourCompanyForge" for instance.
- http_port: if your forge is on a non-standard HTTP port, you'll need to set this variable accordingly.
- https_port: ditto for HTTP.
- lists_host hostname of the mailing-lists. Set it to "$core/web_host" for instance, if you run mailman on the same domain as the rest for the forge (which needs other tuning to operate fully)
- core/project_auto_approval (boolean): if true, when users submit a project, it's automatically approved (no need for admin review). This requires project_registration_restricted=false.
- core/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 permission
- core/project_registration_restricted (boolean): if true, prevent users from registering projects - useful if you don't want to accept new project requests.
- core/require_unique_email (boolean): whether to require that user's email addresses are unique among all users, or not
- core/session_expire (int): set session validity in seconds. By default, it is not set.
- use_docman: whether to enable the document manager feature.
- use_forum: enable forums?
- use_frs: enable file release system?
- use_mail: Wether to use mailing-lists, and to allow responding to forum notifications by mail
- use_manual_uploads: allow the FRS and the docman to work on files uploaded by hand (SSH/SCP).
- use_news: use announcements.
- use_people : use the "Project Openings" /people/ feature (recruiting contributors, etc.)
- use_pm: use task trackers?
- use_project_full_list: allow displaying the full list of projects?
- use_project_tags: enable the tagging feature on projects (and the tag cloud).
- core/user_registration_restricted (boolean): only forge admins can registrate new users
- core/user_notification_on_activation (boolean): forge admins will receive emails when user has validated his account.
- use_scm: enable source control management?
- use_snippet: enable repository of code snippets?
- use_ssl (boolean): whether to use https:// URLs (instead of http:// ones) when possible.
- use_survey: enable project surveys?
- use_tracker: enable the generic bug/patch/support request/etc. tracker?
- use_trove: enable the project categorisation in the trove map?
- use_webdav: enable webdav support
- web_host: hostname of the webserver, used in many URLs.
- mediawiki/enable_uploads : enable file uploads
- use_dav (boolean) whether to use WebDAV to push changes to the repositories (mutual exclusive with use_ssh ?)
- use_ssh (boolean) whether to use SSH to push changes to the repositories (mutual exclusive with use_dav ?)
See also : Developer doc > Configuration