ÃÛ¶¹ÊÓƵ

[On-premise/hybrid only]{class="badge yellow" title="Applies to on-premise and hybrid deployments only"}

Get started with Campaign server configuration gs-campaign-server-config

This chapter details server-side configurations that can be performed to match your needs and your environment specificities.

Restrictions

These procedures are restricted to on-premise/hybrid deployments and require Administration permissions.

For hosted deployments, server-side settings can be configured by ÃÛ¶¹ÊÓƵ only. However, some settings can be set up within Campaign Control Panel, such as IP allowlist management or URL permissions. Learn more.

For more information, refer to these sections:

Configuration files

Campaign Classic configuration files are stored in the conf folder of the ÃÛ¶¹ÊÓƵ Campaign installation folder. The configuration is spread over two files:

Configuration scope

Configure or adapt Campaign server depending on your needs and configuration. You can:

Internal identifier internal-identifier

The internal identifier is a technical login to be used for installation, administration and maintenance purposes. This login is not associated with an instance.

Operators connected using this login will have all the rights on all instances. This login won’t have a password in the case of a new installation. You must manually define this password.

Use the following command:

nlserver config -internalpassword

The following information is then displayed. Enter and confirm the password:

17:33:57 >   Application server for ÃÛ¶¹ÊÓƵ Campaign Classic (7.X YY.R build XXX@SHA1) of DD/MM/YYYY
Enter the current password.
Password:
Enter the new password.
Password: XXXX
Confirmation: XXXX
17:34:02 >   Password successfully changed for account 'internal' (authentication mode 'nl')

Enable processes enabling-processes

ÃÛ¶¹ÊÓƵ Campaign processes on the server are enabled (and disabled) via the config-default.xml and config-<instance>.xml files.

To apply the changes to these files, if the ÃÛ¶¹ÊÓƵ Campaign service is started, you must run the nlserver config -reload command.

There are two types of processes: multi-instance and single instance.

Campaign data storage

You can configure the storage directory (var directory) of ÃÛ¶¹ÊÓƵ Campaign data (logs, downloads, redirections, etc.). To do this, use the XTK_VAR_DIR system variable:

Dynamic page security and relays dynamic-page-security-and-relays

By default, all dynamic pages are automatically related to the local Tomcat server of the machine whose Web module has started. This configuration is entered in the <url> section of the query relay configuration for the ServerConf.xml file.

You can relay execution of the dynamic page on a remote server; if the Web module is not activated on the computer. To do this, you must replace the localhost with the name of the remote computer for JSP and JSSP, Web applications, reports and strings.

For more on the various parameters available, refer to the serverConf.xml configuration file.

For JSP pages, the default configuration is:

<url relayHost="true" relayPath="true" targetUrl="http://localhost:8080" urlPath="*.jsp"/>

ÃÛ¶¹ÊÓƵ Campaign uses the following JSP pages:

The JSSPs used for the Mobile App Channel are as follows:

Example:

It’s possible to prevent client machine connections from the outside. To do this, simply restrict the execution of soaprouter.jsp and only authorize the execution of mirror pages, viral links, web forms and public resources.

The parameters are as follows:

<url IPMask="<IP_addresses>" deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="*.jsp"/>
<url IPMask="<IP_addresses>" deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="*.jssp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true" relayPath="true" targetUrl="http://localhost:8080" timeout="" urlPath="m.jsp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true" relayPath="true" targetUrl="http://localhost:8080" timeout="" urlPath="s.jsp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true" relayPath="true" targetUrl="http://localhost:8080" timeout="" urlPath="webForm.jsp"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/webApp/pub*"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/jssp/pub*"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/strings/pub*"/>
<url IPMask=""               deny=""     hostMask="" relayHost="true"  relayPath="true"  targetUrl="http://localhost:8080" timeout="" urlPath="/interaction/pub*"/>
<url IPMask=""               deny="true" hostMask="" relayHost="false" relayPath="false" targetUrl="http://localhost:8080" timeout="" urlPath="*.jsp"/>
<url IPMask=""               deny="true" hostMask="" relayHost="false" relayPath="false" targetUrl="http://localhost:8080" timeout="" urlPath="*.jssp"/>

In this example, the <IP_addresses> value coincides with the list of IP addresses (separated by comas) authorized to use the relay module for this mask.

Manage HTTP headers managing-http-headers

By default, all HTTP headers are not relayed. You can add specific headers in the replies sent by relay. To do this:

Restrict authorized external commands restricting-authorized-external-commands

From build 8780, technical administrators can restrict the list of authorized external commands that can be used in ÃÛ¶¹ÊÓƵ Campaign.

To do that, you need to create a text file with the list of commands that you want to prevent from using, for example:

ln
dd
openssl
curl
wget
python
python3
perl
ruby
sh

In the exec node of the server configuration file, you need to reference the previously created file in the blacklistFile attribute.

For Linux only: in the server configuration file, we recommend that you specify a user dedicated to executing external commands to enhance your security configuration. This user is set in the exec node of the configuration file. All the parameters available in the serverConf.xml are listed in this section.

For example:

<serverConf>
 <exec user="theUnixUser" blacklistFile="/pathtothefile/blacklist"/>
</serverConf>

This user needs to be added to the sudoer list of the ‘neolane’ ÃÛ¶¹ÊÓƵ Campaign operator.

Redundant tracking redundant-tracking

When multiple servers are used for redirection, they must be able to communicate with each other via SOAP calls in order to share information from the URLs to be redirected. At the time of delivery start-up, it is possible that not all the redirection servers will be available; therefore they might not have the same level of information.

The URLs of the redundant servers must be specified in the redirection configuration, via the serverConf.xml file.

Example:

<spareserver enabledIf="$(hostname)!='front_srv1'" id="1" url="http://front_srv1:8080" />
<spareserver enabledIf="$(hostname)!='front_srv2'" id="2" url="http://front_srv2:8080" />

The enableIf property is optional (empty by default) and allows you to enable the connection only if the result is true. This lets you obtain an identical configuration on all redirection servers.

To obtain the hostname of the computer, run the following command: hostname -s.

High availability workflows and affinities high-availability-workflows-and-affinities

You can configure several workflow servers (wfserver) and distribute them on two or more machines. If you choose this type of architecture, configure the connection mode of the load balancers according to the ÃÛ¶¹ÊÓƵ Campaign access.

For access from the web, select the load balancer mode to limit connection times.

If accessing via the ÃÛ¶¹ÊÓƵ Campaign console, choose hash or sticky ip mode. This lets you maintain the connection between the rich client and the server and prevent a user session from being interrupted during an import or export operation, for example.

You can choose to force the execution of a workflow or a workflow activity on a particular machine. To do this, you must define one or more affinities for the concerned workflow or activity.

Automatic restart automatic-process-restart

By default, the different ÃÛ¶¹ÊÓƵ Campaign processes restart automatically at 6am (server time) every day.

However, you can change this configuration.

To do this, go to the serverConf.xml file, located in the conf repository of your installation.

Each process configured in this file has a processRestartTime attribute. You can modify the value of this attribute to adapt the restart time of each process according to your needs.