Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Content imported from a Scroll Translations translation file.
Sv translation
languageen

Table of Contents
maxLevel3
printablefalse

Necessary adjustments of the configuration

Note: in case of redundancy, this is done on BOTH NODES.

The configuration file /etc/haproxy/haproxy.cfg must now be adapted to the environment using a text editor. The file contains various areas that require adjustment.

Adjustment of the users for the haproxy administration

Via the URL http(s)://acd-store:7777 an administration interface of the haproxy service can be accessed. For example, backend servers can be excluded from distribution for maintenance or testing purposes. In the standard configuration there is one read-only user (user name: user, password: <password>) and two configuration-authorized users (admin and jtel). Both have the same (known) password. If, for example, you want to change the password for the user admin so that, for example, a Kudnen or partner administrator also has access, you can generate a new password hash with a special command:

Translations Ignore


Code Block
languagebash
titleGenerate a password hash
python -c 'import crypt; print crypt.crypt("<password>", "$5$jhaProxy")'



 This command generates a new SHA256 hash for the password "F1r3ball2016" using the salt value "jhaProxy". This hash can then be used for the corresponding user. The user area in the configuration file looks like this:

Translations Ignore


Code Block
titleUser area in /etc/haproxy/haproxy.cfg
userlist stats-auth
        user  admin     password $5$jhaProxy$rd33gRtd4Wt5UyIclODlyjinSeH4N2DjLtKk33PNZH.
        user  jtel      password $5$jhaProxy$rd33gRtd4Wt5UyIclODlyjinSeH4N2DjLtKk33PNZH.
        user  user      password $5$jhaProxy$.saE3wsZ9AzbDMk2jW9WWQqm.4.vgyZCjFdCf5dAKD6
        group admin     users admin,jtel
        group readonly  users user



Adjustment of the URL redirections

The configuration template provides three URL redirections to allow convenient access to the login masks for the system administrator login, the normal user login and the normal user login for the Mini Client. However, this requires an adjustment to the acdportal_http or acdportal_https area:

Translations Ignore


Code Block
titleAdjustment of URL redirects
        redirect        location /CarrierPortal/login/RESELLER/CLIENT if root_req
        redirect        location /CarrierPortal/mclogin/RESELLER/CLIENT if mini_req



Here the character strings RESELLER or CLIENT must be replaced with the "Reseller UID" and the "Client UID" of the standard client. If these are not specifically adapted when the customer system is set up, both are "default".

Adjustment of the backend lists

The list of Web application servers to which the request is to be distributed is maintained in the configuration file in two separate areas. The following area is responsible for distributing all calls to the portal:

Translations Ignore


Code Block
titleBackend area for the web portal
backend jtel_portal
        mode            http
        compression     algo gzip
        compression     type text/xml text/html text/plain text/css text/javascript
        cookie          SERVERID insert indirect nocache
        appsession      JSESSIONID len 32 timeout 3600000
        balance         leastconn # roundrobin
        server          jboss1 192.168.1.31:8080 weight 1 cookie jboss1 check inter 1m
        server          jboss2 192.168.1.32:8080 weight 1 cookie jboss2 check inter 1m



In accordance with the system architecture, all web application servers that the web portal should provide (including Mini Client) are to be entered here. A "server" line must be created for each server. Make sure to use unique internal name identifiers and cookie values (in the above case "jbossX" where X is numbered consecutively).

The following area is responsible for the distribution of all SOAP requests:

Translations Ignore


Code Block
titleBackend area for the SOAP interface
backend jtel_soap
        mode            http
        compression     algo gzip
        compression     type text/xml text/html text/plain text/css text/javascript
        balance         leastconn # roundrobin
        stick-table     type ip size 20k
        stick           on src
        server          jboss1 192.168.1.31:8081 weight 1 cookie jboss1 check inter 1m
        server          jboss2 192.168.1.32:8081 weight 1 cookie jboss2 check inter 1m



Here, too, all web application servers that are to provide the SOAP interface must be entered in accordance with the system architecture. A "server" line must be created for each server.Make sure to use unique internal name identifiers and cookie values (in the above case "jbossX" where X is numbered consecutively). These servers are usually the same as those used for portal access. In large installations, however, dedicated Web application servers can also be specified for this purpose.

Note
titleWichtiger Hinweis

An important difference between the HTTP under HTTPS version of the configuration file is the port to which SOAP requests are forwarded. If access is via HTTPS, all requests are forwarded to the Web application server on port 8081. This connector is configured so that the JBOSS server knows that the original requests came in over HTTPS and provides the returned URLs (like in WSDL) with the appropriate scheme, even if the communication between haproxy and backend is only over HTTP.

In the pure HTTP version of the configuration template, however, the requests are forwarded to port 8080.

Starting the haproxy service

After all configuration adjustments have been made, the haproxy service can be started:

Translations Ignore


Code Block
languagebash
titleStart the haproxy service
service haproxy start



Subsequently, it should be checked whether the service is actually running. If this is not the case, the log file can provide information about possible configuration errors.

In case of configuration changes the haproxy service can update its configuration during operation with the following command:

Translations Ignore


Code Block
languagebash
titleUpdate the configuration during operation
service haproxy reload



A final test provides information about the success of the installation. Since the UID values of the Reseller and Client have not yet been renamed at this time, it is recommended to call the URL for the admin login: http://acd-lb.example.com/admin which, if successful, leads to the login mask of the portal.

Further links


Sv translation
languagede

Table of Contents
maxLevel3
printablefalse

Erforderliche Anpassungen der Konfiguration

Hinweis: bei Redundanz, wird dies auf BEIDE NODES ausgeführt.

Die Konfigurationsdatei /etc/haproxy/haproxy.cfg muss nun mit einem Text-Editor der Umgebung entsprechend angepasst werden. Die Datei enthält verschiedene Bereiche, die der Anpassung bedürfen.

Anpassung der Benutzer für die haproxy-Administration

Über die URL http(s)://acd-store:7777 kann auf eine Administrationsoberfläche des haproxy-Dienstes zugegriffen werden. Hier können z.B. Backend-Server aus der Verteilung zu Wartungs- oder Test-Zwecken ausgeschlossen werden. In der Standardkonfiguration gibt es einen Read-Only-Benutzer (Benutzername: user, Passwort: <password>) und zwei Konfigurations-berechtigte Benutzer (admin und jtel). Beide haben das gleiche (bekannte) Passwort. Möchte man z.B. das Passwort für den Benutzer admin ändern, so dass z.B. ein Kudnen- oder Partner-Administrator auch Zugriff hat, so kann man mittels einem speziellen Befehl einen neuen Passwort-Hash generieren:

Translations Ignore


Code Block
languagebash
titleGenerate a password hash
python -c 'import crypt; print crypt.crypt("<password>", "$5$jhaProxy")'



Dieser Befehl generiert ein neues SHA256 Hash für das Passwort "F1r3ball2016" unter Benutzung des Salt-Wertes "jhaProxy". Dieser Hash kann dann für den entsprechenden Benutzer eingesetzt werden. Der Benutzerbereich in der Konfigurationsdatei sieht folgendermaßen aus:

Translations Ignore


Code Block
titleUser area in /etc/haproxy/haproxy.cfg
userlist stats-auth
        user  admin     password $5$jhaProxy$rd33gRtd4Wt5UyIclODlyjinSeH4N2DjLtKk33PNZH.
        user  jtel      password $5$jhaProxy$rd33gRtd4Wt5UyIclODlyjinSeH4N2DjLtKk33PNZH.
        user  user      password $5$jhaProxy$.saE3wsZ9AzbDMk2jW9WWQqm.4.vgyZCjFdCf5dAKD6
        group admin     users admin,jtel
        group readonly  users user



Anpassung der URL Umleitungen

Die Konfigurationsvorlage stellt drei URL-Umleitungen zu Verfügung um den komfortablen Zugriff auf die Login Masken für den System-Administrator Login, den normalen Benutzer-Login und den normalen Benutzer-Login für den Mini Client zu ermöglichen. Dies erfordert allerdings eine Anpassung an dem Bereich acdportal_http bzw. acdportal_https:

Translations Ignore


Code Block
titleAdjustment of URL redirects
        redirect        location /CarrierPortal/login/RESELLER/CLIENT if root_req
        redirect        location /CarrierPortal/mclogin/RESELLER/CLIENT if mini_req



Hier sind die Zeichenketten RESELLER bzw. CLIENT respektive mit der "Reseller UID" und der "Client UID" des Standardmandanten zu ersetzen. Werden diese bei der Einrichtung des Kundensystems nicht spezifisch angepasst, so lauten beide "default".

Anpassung der Backend-Listen

Die Liste der Web-Applikationsserver auf die die Anfrage verteilt werden sollen, wird in der Konfigurationsdatei in zwei getrennten Bereichen gepflegt. Der folgende Bereich ist zuständig für die Verteilung aller Aufrufe auf das Portal:

Translations Ignore


Code Block
titleBackend area for the web portal
backend jtel_portal
        mode            http
        compression     algo gzip
        compression     type text/xml text/html text/plain text/css text/javascript
        cookie          SERVERID insert indirect nocache
        appsession      JSESSIONID len 32 timeout 3600000
        balance         leastconn # roundrobin
        server          jboss1 192.168.1.31:8080 weight 1 cookie jboss1 check inter 1m
        server          jboss2 192.168.1.32:8080 weight 1 cookie jboss2 check inter 1m



Hier sind entsprechend der Systemarchitektur alle Web-Applikationsserver einzutragen, die das Web-portal (auch Mini Client) zur Verfügung stellen sollen. Für jeden Server ist eine "server"-Zeile zu erstellen. Dabei ist darauf zu achten, eindeutige interne Namenskennzeichnungen und cookie-Werte zu verwenden (im obigen Fall "jbossX" wobei X durchnummeriert wird).

Der folgende Bereich ist hingegen zuständig für die Verteilung aller SOAP Anfragen:

Translations Ignore


Code Block
titleBackend area for the SOAP interface
backend jtel_soap
        mode            http
        compression     algo gzip
        compression     type text/xml text/html text/plain text/css text/javascript
        balance         leastconn # roundrobin
        stick-table     type ip size 20k
        stick           on src
        server          jboss1 192.168.1.31:8081 weight 1 cookie jboss1 check inter 1m
        server          jboss2 192.168.1.32:8081 weight 1 cookie jboss2 check inter 1m



Auch hier sind entsprechend der Systemarchitektur alle Web-Applikationsserver einzutragen, die das SOAP Interface zur Verfügung stellen sollen. Für jeden Server ist eine "server"-Zeile zu erstellen. Dabei ist darauf zu achten, eindeutige interne Namenskennzeichnungen und cookie-Werte zu verwenden (im obigen Fall "jbossX" wobei X durchnummeriert wird). Diese Server sind in der Regel die gleichen, die auch für den Portal-Zugriff verwendet werden. In großen Installationen können hierfür aber auch dedizierte Web-Applikationsserver angegeben werden.

Note
titleWichtiger Hinweis

Ein wichtiger Unterschied zwischen der HTTP under HTTPS Version der Konfigurationsdatei, liegt in dem Port zu dem SOAP Anfragen geleitet werden. Erfolgt der Zugriff über HTTPS, so werden alle Anfrage zu den Web-Application Server auf Port 8081 geleitet. Dieser Connector ist so konfiguriert, dass der JBOSS-Server weiss, dass die originalen Anfragen über HTTPS hereingekommen sind, und die zurück gegebene URLs (wie z.B. im WSDL) mit dem entsprechenden Schema versieht, auch wenn die Kommunikation zwischen haproxy und Backend nur über HTTP läuft.

In der reinen HTTP-Version der Konfigurationsvorlage werden die Anfragen hingegen zu Port 8080 geleitet.

Starten des haproxy-Dienstes

Nach dem alle Konfigurationsanpassungen getätigt wurden, kann der haproxy-Dienst gestartet werden:

Translations Ignore


Code Block
languagebash
titleStart the haproxy service
service haproxy start



Im Anschluss sollte geprüft werden, ob der Dienst auch tatsächlich läuft. Ist dies nicht der Fall, kann die Log-Datei Aufschluß über eventuelle Konfigurationsfehler geben.

Bei Konfigurationsänderungen kann der haproxy DIenst im laufenden Betrieb mittels folgendem Befehl seine Konfiguration aktualisieren:

Translations Ignore


Code Block
languagebash
titleUpdate the configuration during operation
service haproxy reload



Ein finaler Test gibt Aufschluss über den Erfolg der Installation. Da zu diesem Zeitpunkt die UID Werte des Reseller und Mandanten noch nicht umbenannt wurden, empfiehlt sich der Aufruf der URL für den Admin-Login: http://acd-lb.example.com/admin welcher im Erfolgsfall zur Login-Maske des Portals führt.

Weiterführende Links


Sv translation
languagefr

Table of Contents
maxLevel3
printablefalse

Les ajustements nécessaires de la configuration

Note : en cas de licenciement, cela se fait sur LES DEUX NODES.

Le fichier de configuration /etc/haproxy/haproxy.cfg doit maintenant être adapté à l'environnement à l'aide d'un éditeur de texte. Le fichier contient différentes zones qui doivent être adaptées.

Adaptation des utilisateurs pour l'administration du haproxy

Via l'URL http(s)://acd-store:7777 une interface d'administration du service haproxy est accessible. Par exemple, les serveurs dorsaux peuvent être exclus de la distribution à des fins de maintenance ou de test. Dans la configuration standard, il y a un utilisateur en lecture seule (nom d'utilisateur : user, mot de passe : <password>) et deux utilisateurs autorisés par la configuration (admin et jtel). Les deux ont le même mot de passe (connu). Si, par exemple, vous souhaitez modifier le mot de passe de l'utilisateur admin pour que, par exemple, un administrateur Kudnen ou partenaire y ait également accès, vous pouvez générer un nouveau hachage de mot de passe avec une commande spéciale :

Translations Ignore


Code Block
languagebash
titleGénérer un hachage de mot de passe
python -c 'import crypt; print crypt.crypt("<password>", "$5$jhaProxy")'



 Cette commande génère un nouveau hachage SHA256 pour le mot de passe "F1r3ball2016" en utilisant la valeur de sel "jhaProxy". Ce hachage peut ensuite être utilisé pour l'utilisateur correspondant. La zone utilisateur dans le fichier de configuration ressemble à ceci :

Translations Ignore


Code Block
titleEspace utilisateur dans /etc/haproxy/haproxy.cfg
userlist stats-auth user admin password $5$jhaProxy$rd33gRtd4Wt5UyIclODlyjinSeH4N2DjLtKk33PNZH. user jtel password $5$jhaProxy$rd33gRtd4Wt5UyIclODlyjinSeH4N2DjLtKk33PNZH. user user password $5$jhaProxy$.saE3wsZ9AzbDMk2jW9WWQqm.4.vgyZCjFdCf5dAKD6 group admin users admin,jtel group readonly users user



Ajustement des redirections URL

Le modèle de configuration fournit trois redirections URL pour permettre un accès pratique aux masques de connexion pour la connexion de l'administrateur système, la connexion de l'utilisateur normal et la connexion de l'utilisateur normal pour le mini-client. Toutefois, cela nécessite un ajustement de la zone acdportal_http ou acdportal_https :

Translations Ignore


Code Block
titleAjustement des redirections URL
 redirect location /CarrierPortal/login/RESELLER/CLIENT if root_req redirect location /CarrierPortal/mclogin/RESELLER/CLIENT if mini_req



Ici, les chaînes de caractères RESELLER ou CLIENT doivent être remplacées par le "Reseller UID" et le "Client UID" du client standard. Si ceux-ci ne sont pas spécifiquement adaptés lors de la configuration du système client, les deux sont "par défaut".

Ajustement des listes de backend

La liste des serveurs d'application Web auxquels la demande doit être distribuée est maintenue dans le fichier de configuration dans deux zones distinctes. Le domaine suivant est responsable de la distribution de tous les appels au portail :

Translations Ignore


Code Block
titleZone de backend du portail web
backend jtel_portal mode http compression algo gzip compression type text/xml text/html text/plain text/css text/javascript cookie SERVERID insert indirect nocache appsession JSESSIONID len 32 timeout 3600000 balance leastconn # roundrobin server jboss1 192.168.1.31:8080 weight 1 cookie jboss1 check inter 1m server jboss2 192.168.1.32:8080 weight 1 cookie jboss2 check inter 1m



Conformément à l'architecture du système, tous les serveurs d'application web que le portail web doit fournir (y compris le mini-client) doivent être saisis ici. Une ligne "serveur" doit être créée pour chaque serveur. Veillez à utiliser des identificateurs de nom internes uniques et des valeurs de cookie (dans le cas ci-dessus "jbossX" où X est numéroté consécutivement).

Le secteur suivant est responsable de la distribution de toutes les demandes SOAP :

Translations Ignore


Code Block
titleZone de backend pour l'interface SOAP
backend jtel_soap mode http compression algo gzip compression type text/xml text/html text/plain text/css text/javascript balance leastconn # roundrobin stick-table type ip size 20k stick on src server jboss1 192.168.1.31:8081 weight 1 cookie jboss1 check inter 1m server jboss2 192.168.1.32:8081 weight 1 cookie jboss2 check inter 1m



Ici aussi, tous les serveurs d'applications web qui doivent fournir l'interface SOAP doivent être saisis conformément à l'architecture du système. Une ligne "serveur" doit être créée pour chaque serveur. Assurez-vous d'utiliser des identificateurs de noms internes uniques et des valeurs de cookies (dans le cas ci-dessus "jbossX" où X est numéroté consécutivement). Ces serveurs sont généralement les mêmes que ceux utilisés pour l'accès au portail. Dans les grandes installations, cependant, des serveurs d'applications Web dédiés peuvent également être spécifiés à cette fin.

Note
titleNote importante

Une différence importante entre le HTTP sous la version HTTPS du fichier de configuration est le port vers lequel les requêtes SOAP sont transmises. Si l'accès se fait via HTTPS, toutes les demandes sont transmises au serveur d'application Web sur le port 8081. Ce connecteur est configuré de manière à ce que le serveur JBOSS sache que les requêtes originales sont arrivées par HTTPS et fournisse les URL retournées (comme dans le WSDL) avec le schéma approprié, même si la communication entre l'haproxy et le backend se fait uniquement par HTTP.

Dans la version purement HTTP du modèle de configuration, cependant, les requêtes sont transmises au port 8080.

Démarrer le service haproxy

Une fois que tous les ajustements de configuration ont été effectués, le service haproxy peut être lancé :

Translations Ignore


Code Block
languagebash
titleDémarrer le service haproxy
service haproxy start



Ensuite, il faut vérifier si le service fonctionne effectivement. Si ce n'est pas le cas, le fichier journal peut fournir des informations sur d'éventuelles erreurs de configuration.

En cas de changement de configuration, le service haproxy peut mettre à jour sa configuration en cours de fonctionnement avec la commande suivante :

Translations Ignore


Code Block
languagebash
titleMise à jour de la configuration en cours de fonctionnement
service haproxy reload



Un test final fournit des informations sur la réussite de l'installation. Étant donné que les valeurs d'UID du revendeur et du client n'ont pas encore été renommées pour le moment, il est recommandé d'appeler l'URL pour le login de l'administrateur : http://acd-lb.example.com/admin qui, en cas de succès, conduit au masque de connexion du portail.

Autres liens