Area: Server

###########################
# server
###########################
backup_files=50
cyclicReferenceSaveTime=60

backup_files

Number of backup versions saved to the internal structure files. This affects only the store and structure data and not the content data. All content data are under separate version control. Increasing the value improves the possibility of error correction, but also results in a higher amount of disk space allocated on the computer (default value is 50).

cyclicSaveTime

Specifies the time in seconds after saving changes to the history, statistics, tasks or user settings, for instance. Cyclical saving only takes place when the relevant data has been modified (default value is 60 sec.).

JNLP_SERVLET_URL

The value defined here is required for generating FirstSpirit URLs as links for starting the client within e-mail messages. Example:

JNLP_SERVLET_URL=${URL}/start/FIRSTspirit.jsp

DTO_LRU_SIZE

This parameter defines the size of the DTO cache for a project on the server. Here the last project tree objects used are preserved. The value defines the number of objects managed in the cache (default value is 512 store elements).

CLIENTAPP_PATH

This parameter is required only for the rollout of native client applications (see Roll-out process for native applications). Default value: FirstSpirit5\data\clientapp.

CLIENT_HOME_DIR

This specifies the path to the directory in the workstation file system that is to be used for storing the client applications, log messages of ServerManager and SiteArchitect and other content (see Roll-out process (workstation computer)). Absolute (e.g. CLIENT_HOME_DIR=C:/test) or relative paths can be used. For relative paths, the character ~ can be used as a placeholder at the beginning of the path, e.g. ~/myclientapps. ~ is then replaced by the current user home directory that is specific to the operating system.

If the parameter is not specified, client applications are rolled out to a directory within the user home directory specific to the operating system by default, e.g.

c:\users\username\.firstspirit_5.2R1904 

Each release of FirstSpirit has its own directory. The directory name contains the particular FirstSpirit major, minor, and release version numbers (.firstspirit_5.2R<version>), e.g.~\.firstspirit_5.2R1904

Default value:

CLIENT_HOME_DIR=~/.firstspirit_${FS_MAJOR}.${FS_MINOR}${FS_RELEASE}

Old versions of the FirstSpirit Home directories .firstspirit_* are automatically cleaned up if no file has been changed in them for longer than 30 days.

CLIENT_HOME_DIR_WINDOWS

Path to the directory in the file system where the client applications (and log messages of ServerManager and SiteArchitect) are to be rolled out to Windows operating system workstations. Example:

CLIENT_HOME_DIR_WINDOWS=C:/.test

If only CLIENT_HOME_DIR_WINDOWS is specified, the client application is rolled out to the specify operating system user home directory.

CLIENT_HOME_DIR_LINUX

Path to the directory in the file system where the client applications (and log messages of ServerManager and SiteArchitect) are to be rolled out to Linux operating system workstations (see parameter CLIENT_HOME_DIR_WINDOWS).

CLIENT_HOME_DIR_MAC

Path to the directory in the file system where the client applications (and log messages of ServerManager and SiteArchitect) are to be rolled out to Macintosh operating system workstations (see parameter CLIENT_HOME_DIR_WINDOWS).

workflow.task.cache / workflow.model.cache

The type defined here specifies how long a task or workflow model is to be retained in the cache. A distinction is made here between WEAK and SOFT. If WEAK is specified, the objects are deleted directly from the cache as soon as they become obsolete. When SOFT is specified, the objects are retained in the cache, regardless of the VM used, as long as there is sufficient disk space. (If there is a large amount of disk space, it is usually advantageous to use WEAK as the type.) The LRU size is appended to the type in KB, separated with an underscore character. (Default values:
workflow.task.cache=SOFT_1024 and 
workflow.model.cache=SOFT_128.)

Configuring queues for schedules

Executing schedules, e.g. generations, backups etc., can lead to a high load on the server and thus cause performance problems.

Backups: By default, a maximum of 4 backup schedules are run simultaneously. This includes both schedules of type Project backup and Enterprise backup schedules.
Note: Manually started project exports are not affected by this setting and continue to be executed immediately.

Generation: By default, a maximum of 10 generation schedules are run simultaneously.

Beyond this, other schedule types are executed via the so-called Default Thread Queue. This is a general execution queue that is not restricted to schedules. The number of schedules that may be executed simultaneously in this queue is by default the number of cores * 6.

Use the following parameters to define how many schedules may be executed at the same time. One separate queue can be configured for

• backup schedules (backupQueue)
• generation schedules (generateQueue)
• all other schedule types (defaultQueue)

• The maxRunning parameters limit the simultaneous execution of the respective schedule type. If schedules exceeding this limit are started, they are queued and executed only when the number of running schedules falls below the maxRunning value.
  If maxRunning is set to -1, the general “Default Thread Queue” will be used.
• If no explicit values are specified for the parameters (“empty”), the value of the general “Default Thread Queue” will be used.

schedule.generateQueue.maxRunning: Specifies how many generation schedules may be executed simultaneously.
Default value is 10.

schedule.generateQueue.queueCapacity: Specifies the maximum number of generation schedules that can be added to the queue.
Default value is empty.

schedule.backupQueue.maxRunning: Specifies how many backup schedules may be executed simultaneously.
Default value is 4.

schedule.backupQueue.queueCapacity: Specifies the maximum number of backup schedules that can be added to the queue.
Default value is 128.

schedule.defaultQueue.maxRunning: Specifies how many schedules of this queue may be executed simultaneously.
Default value is -1.

schedule.defaultQueue.queueCapacity: Specifies the maximum number of schedules that can be included in this queue.
Default value is empty.

schedule.maxInactivityTimeout: Specifies the time period within which a schedule task is considered blocked and cancelled if no CPU time has been consumed.
Default value (in seconds) is 600, which corresponds to 10 minutes.

indexing.extendedDatasetKeys

This parameter can be used to adjust the format of the search index when using external databases.

If indexing.extendedDatasetKeys=true is set, the format of the search index is changed so that datasets from different tables with the same primary key can be found via the search. 

The default value is indexing.extendedDatasetKeys=false. With this setting, only one of these datasets is found when using external databases.

After changing the parameter, the search index must be recalculated for all projects that use external databases (see Rebuilding the Search Index). Otherwise, the old versions can still be found when changes are made to datasets.

For further information on searching and indexing in FirstSpirit projects, see Search (→FirstSpirit Online Documentation).

generate.defaultMaxStackSize

For security reasons, stack size is limited in FirstSpirit. Occasionally, this may lead to an “Endless loop” exception when nesting of templates would cause the stack to overflow. See also page Preview-specific (→FirstSpirit Online Documentation).

The default value for the stack size is 75.
Use the generate.defaultMaxStackSize parameter to customize this default value server-wide.

indexing.relationshipPathLengthToFollow

A dataset can be linked to datasets from other tables in particular in the case of complex data structures with several tables. Linking datasets across several tables in this way can also be described as a “path”.

Indexing of datasets that are referenced via FS_DATASET or FS_INDEX (used for dataset selection via DatasetDataAccessPlugin) may be configured such that the path length will be considered. For a dataset which references other datasets, this controls whether the contents of only this “origin” dataset should be indexed or the contents of this dataset and of the datasets it references should be indexed. If contents of referenced datasets should be indexed as well, the parameter allows specification of the path length to which references should be considered. For example, a path length “2” means that, in addition to the contents of the “origin” dataset, the contents of datasets referenced by this “origin” dataset as well as the contents of datasets referenced by these datasets will be indexed.

By default, a path length “1” is assumed such that, for the input components mentioned above, datasets and the datasets they immediately reference are indexed. If no referenced datasets should be indexed, the parameter's value must be set to “0”, e.g.

indexing.relationshipPathLengthToFollow=0

Other path lengths may be specified by setting the desired value.

Datasets which are stored in the same table will not be indexed.

The indexing behavior illustrated here only applies to the input components mentioned above. For other input components which may reference datasets via CMS_INCLUDE_OPTIONS, contents of referenced datasets will not be indexed, but the ID of the referenced dataset, the label (tag LABELS), and the key (tag KEY) will be added to the index.

The indexing behavior illustrated here also applies to referenced datasets in pages and sections. The page or section in which the dataset-referencing input component is located is considered to be path length “0”. With indexing.relationshipPathLengthToFollow=0, only the contents of the page or the section would be indexed. In order to also index contents of the referenced dataset, indexing.relationshipPathLengthToFollow must be set to a value of “1”.

This configuration is applied server-wide for all projects.

The configuration via indexing.relationshipPathLengthToFollow may be overwritten for an individual project, see interface SearchIndexAgent (Package de.espirit.firstspirit.agency, FirstSpirit Access API).

On a project/component level, the parameter indexTreatment may be used to manually extend the path length specified by indexing.relationshipPathLengthToFollow across certain tables, thereby practically increasing the value of the parameter indexing.relationshipPathLengthToFollow for certain input components.

Contents in input components for which the parameter searchRelevancy="none" is set will not be indexed, regardless of the configuration of indexing.relationshipPathLengthToFollow and/or indexTreatment.

webserver.conf-migration

This parameter is set automatically. It is managed by the FirstSpirit server and must not be modified or deleted.

externalServerAdminGroup

Use this parameter to assign server administrator permissions to one or more external groups (e.g. from LDAP). To do this, specify the respective group name. All members of this external group will then receive server administrator permissions in FirstSpirit.
In order to create more than one external server administrator group, a unique extension is attached to the “externalServerAdminGroup” key, e.g.

externalServerAdminGroup.1=
externalServerAdminGroup.2=

Example for the LDAP definition of two external server administrator groups:

externalServerAdminGroup.1=CN=fs-crew,OU=FIRSTspirit,OU=Projekte,DC=e-spirit,DC=de
externalServerAdminGroup.2=CN=fs-dev,OU=FIRSTspirit,OU=Projekte,DC=e-spirit,DC=de 

This configuration overwrites configurations that may have been set in ServerManager for the relevant users (see User).

The “server administrator” property is set for external users and group members every time they log in.

For more information please see also

• Information about the different types of administrators
• Server administrator permissions for internal users    
• Creating external groups

devProjectAdminPermissions

If this parameter is set to true,

devProjectAdminPermissions=true

project administrators will be able to create new projects via API or via the corresponding fs-cli commands. They are automatically added as users in the new project and included in the Administrators group so that they are able to further configure it.

Note: Project administrators are all users who are members of a respective group in an already existing project on the server.

The parameter does not allow project administrators a new project to be created via the FirstSpirit ServerManager.

maxProjectCount

This parameter can be used to limit the maximum number of projects on the server.

Note: The number of projects specified in the licence cannot be exceeded!

externalUserGroup

If this parameter is set, only external users belonging to an external group matching the specified value can log in.
The specified value must be a substring of the complete group name.

Example:

externalUserGroup.1=CN=admin,OU=FIRSTspirit,OU=Projekte,DC=e-spirit,DC=de

If the external user is not included in the required groups to log in successfully, this will be recorded in the log as follows:

WARN  22.07.2022 13:29:38.101 (de.espirit.firstspirit.server.sessionmanagement.SessionManagerImpl): login failed (authentication for 'xyz' successful but the the user is not a member of an allowed group)!

externalGroupFilter

By default, when a user authenticates via an external provider (e.g. LDAP, SAML Identity Provider), the complete group information that is transmitted is stored in FirstSpirit.

This parameter can be used with the help of a regular expression to define which subset of the group information should be taken over by FirstSpirit.

Example:

externalGroupFilter=.*(csm_admin|FirstSpirit).*

localGroupManagementDisabled

By default, project administrators can create, edit and delete (internal) groups (see also page Groups).

To remove this permission from project administrators, the following parameter can be set:

localGroupManagementDisabled=true

In this case internal groups can be modified only by server administrators.
For project administrators, the corresponding context menu in the Groups area is hidden, and a java.lang.SecurityException is recorded in the log.

External groups are not affected by this restriction and can still be modified by project administrators, even if the parameter is set to true.

externalLauncherGroup

As of FirstSpirit 2021-02, SiteArchitect and ServerManager are automatically started for all users via the FirstSpirit Launcher. The option to start the FirstSpirit desktop applications via Java Web Start is no longer available. If the externalLauncherGroup parameter is used, the following message is output in the log when starting the FirstSpirit server:

WARN(...): External launcher groups are configured. This is deprecated since the launcher is always active for all users (...) 

The parameter should be removed from the configuration.

Until FirstSpirit 2021-02: This parameter can be used to change the connection settings for one or more external groups (e.g., from LDAP) so that SiteArchitect and ServerManager are started via the FirstSpirit Launcher instead of via Java Web Start (default) (see FirstSpirit Launcher ). This involves specifying the relevant group name. All the members of this external group then start the applications via the FirstSpirit Launcher. The parameter should be set if the FirstSpirit Launcher is distributed centrally by means of a group policy (see “Introduction (→Installation Instructions)”). If the externalLauncherGroup parameter is not set, every user can still download the Launcher via the start page. The use of the Launcher can be activated locally via the start page connection settings (Use FirstSpirit Launcher option).