[On-Premise/hybride uniquement]{class="badge yellow" title="S’applique uniquement aux déploiements on-premise et hybrides"}

Prise en main de la configuration du serveur Campaign gs-campaign-server-config

Ce chapitre décrit les configurations côté serveur qui peuvent être exécutées en fonction de vos besoins et des spécificités de votre environnement.

Restrictions

Ces procédures sont limitées aux déploiements On-premise/hybrides et nécessitent des autorisations d’administration.

Pour les déploiements hébergés, les paramètres côté serveur ne peuvent être configurés que par Adobe. Cependant, certains paramètres peuvent être configurés dans le Panneau de contrôle de Campaign, comme la gestion des listes d’adresses IP autorisées ou les autorisations d’URL. En savoir plus.

Pour plus d’informations, consultez les sections suivantes :

Fichiers de configuration

Les fichiers de configuration de Campaign Classic sont stockés dans le dossier conf du dossier d’installation d’Adobe Campaign. La configuration est répartie sur deux fichiers :

Périmètre de la configuration

Configurez ou adaptez le serveur Campaign en fonction de vos besoins et de votre configuration. Vous pouvez ainsi :

Identifiant 'internal' internal-identifier

L'identifiant internal est un login technique à utiliser lors de la phase d'installation, pour les paramétrages techniques d'administration et de maintenance. Ce login n'est pas associé à une instance.

L'opérateur connecté avec cet identifiant possède tous les droits, sur toutes les instances. Après une nouvelle installation, cet identifiant n'a pas de mot de passe. Vous devez définir ce mot de passe manuellement.

Utilisez la commande suivante :

nlserver config -internalpassword

Les informations suivantes sont alors affichées. Saisissez et confirmez le nouveau mot de passe :

17:33:57 >   Application server for Adobe 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')

Activation des processus enabling-processes

L’activation (ou la désactivation) des processus Adobe Campaign se fait sur le serveur à partir des fichiers config-default.xml et config-<instance>.xml.

Pour appliquer les modifications dans ces fichiers, si le service Adobe Campaign est démarré, vous devez exécuter la commande nlserver config -reload.

On distingue deux types de processus : multi-instance et mono-instance.

Enregistrement de données Campaign

Vous pouvez configurer le répertoire de stockage (répertoire var) des données Adobe Campaign (logs, téléchargements, redirections, etc.). Pour cela, utilisez la variable système XTK_VAR_DIR  :

Sécurité et relais des pages dynamiques dynamic-page-security-and-relays

Par défaut, toutes les pages dynamiques sont automatiquement liées au serveur Tomcat local de la machine dont le module web a démarré. Cette configuration est saisie dans la section <url> de la configuration du relais de requête pour le fichier ServerConf.xml.

Vous pouvez relayer l’exécution de la page dynamique sur un serveur distant si le module Web n’est pas activé sur l’ordinateur. Pour ce faire, vous devez remplacer localhost par le nom de l’ordinateur distant pour JSP et JSSP, les applications web, les rapports et les chaînes.

Pour plus d’informations sur les différents paramètres disponibles, consultez le fichier de configuration serverConf.xml.

Pour les pages JSP, le paramétrage par défaut est le suivant :

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

Adobe Campaign utilise les pages JSP suivantes :

Les JSSP utilisées pour le canal des applications mobiles sont les suivantes :

Exemple:

Vous pouvez empêcher la connexion des postes clients de l'extérieur. Pour cela, il suffit de restreindre l'exécution de soaprouter.jsp et de n'autoriser que l'exécution des pages miroirs, des liens viraux, des formulaires web et des ressources publiques.

Les paramètres sont les suivants :

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

Dans cet exemple, la valeur <IP_addresses> correspond à la liste des adresses IP (séparées par des virgules) ayant la autorisation d'utiliser le module de relais pour ce masque.

Gérer les en-têtes HTTP managing-http-headers

Par défaut, tous les en-têtes HTTP ne sont pas relayés. Vous pouvez ajouter des en-têtes spécifiques dans les réponses transmises par le relais. Pour cela :

Restreindre les commandes externes autorisées restricting-authorized-external-commands

A partir du build 8780, les administrateurs techniques peuvent restreindre la liste des commandes externes autorisées pouvant être utilisées dans Adobe Campaign.

Pour ce faire, vous devez créer un fichier texte contenant la liste des commandes dont vous souhaitez empêcher l'utilisation, par exemple :

ln
dd
openssl
curl
wget
python
python3
perl
ruby
sh

Dans le nœud exec du fichier de configuration du serveur, vous devez référencer le fichier précédemment créé dans l'attribut blacklistFile.

Pour Linux uniquement  : dans le fichier de configuration du serveur, nous vous recommandons de spécifier un utilisateur dédié à l’exécution de commandes externes afin d’améliorer votre configuration de sécurité. Cet utilisateur est défini dans le nœud exec du fichier de configuration. Tous les paramètres disponibles dans le fichier serverConf.xml sont répertoriés dans cette section.

Par exemple :

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

Cet utilisateur doit être ajouté à la liste sudoer de l'opérateur 'neolane' Adobe Campaign.

Tracking redondant redundant-tracking

Lorsque plusieurs serveurs sont utilisés pour servir la redirection, ceux-ci devront pouvoir communiquer entre eux par des appels SOAP afin de partager les informations des URL à rediriger. Il se peut en effet qu'au moment du démarrage de la diffusion tous les serveurs de redirection ne soient pas disponibles, et qu'ils ne possèdent donc pas le même niveau d'information.

Les URL des serveurs redondants doivent être renseignées dans la configuration de la redirection, via le fichier serverConf.xml.

Exemple :

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

La propriété enableIf est optionnelle (vide par défaut) et permet de n’activer la connexion que si le résultat est vrai. Ceci afin d’obtenir une configuration identique sur tous les serveurs de redirection.

Pour connaître le hostname de la machine, exécutez la commande suivante : hostname -s.

Workflows en haute disponibilité et affinités high-availability-workflows-and-affinities

Vous pouvez configurer plusieurs serveurs de workflow (wfserver) et les répartir sur plusieurs machines. Si vous optez pour une architecture de ce type, paramétrez le mode de connexion des répartiteurs de charge en fonction de l'accès à Adobe Campaign.

Dans le cas d'un accès depuis le web, choisissez le mode load balancer afin de limiter les temps de connexion.

Si l'accès se fait depuis la console Adobe Campaign, préférez le mode hash ou sticky ip. Cela vous permet de maintenir la connexion entre le client riche et le serveur et d'éviter qu'une session utilisateur ne soit interrompue au cours d'une opération d'import ou d'export par exemple.

Vous pouvez choisir de forcer l'exécution d'un workflow ou d'une activité de workflow sur une machine particulière. Vous devez pour cela définir une ou plusieurs affinités au niveau du workflow ou de l'activité concernée.

Redémarrage automatique automatic-process-restart

Par défaut, les différents processus Adobe Campaign redémarrent automatiquement à 6h (matin, heure du serveur) chaque jour.

Il est néanmoins possible de modifier ce paramétrage.

Pour cela, accédez au fichier serverConf.xml, situé dans le répertoire conf de votre installation.

Chaque processus paramétré dans ce fichier dispose d'un attribut processRestartTime. Vous pouvez modifier la valeur de cet attribut afin d'adapter l'heure de redémarrage de chaque processus à vos besoins.