ORS, ORS everywhere…

Oui bon je sais, je devais continuer mes tutos sur SIP Server. Mais “nécessité fait loi”, alors on va se faire une petite installation d’ORS, et ceci en mode cluster.

Pour rappel, le gros intérêt du mode cluster est que si vos besoins de traitement augmentent, vous pouvez très facilement rajouter un nouveau noeud et ainsi répartir la charge sur N+1 serveurs.

Bon, c’est pas le tout de papoter mais : let’s go !

PS : je pars du principe que vous partez d’un socle Genesys existant avec couches framework et management OK.

On commence par une installation classique

Bon tout d’abord, on rappelle la bible : https://docs.genesys.com/Documentation/OS/8.1.4/Deployment/General#Configuring_an_ORS_Cluster cette section de la doc est dédiée spécifiquement aux déploiements d’ORS en mode cluster et je dois dire que pour une fois, elle m’a semblé claire même si il faut bien faire attention aux petites lignes.De manière classique, on va commencer par récupérer le package d’installation correspondant à votre OS, récupérer les templates et créer le modèle d’application dans CME/GA/GAX.

Une fois celui-ci crée, on attaque la création de l’application elle-même. Dans le cas qui nous intéresse, je vais l’appeler ORS_N11_Pr. Petit point nomenclature, je vais le nommer comme ceci pour :

  • ORS_ : bon bah ça je pense que c’est clair
  • 1 car il s’agit du premier cluster ORS que je mets en place
  • 1 car il s’agit du premier noeud de ce cluster
  • _Pr pour indiquer que c’est le primaire. En effet, au sein de ce cluster, rien ne nous empêchera ensuite de mettre chaque noeud en primaire/backup. Overkill certes mais quand il faut…

Lors de la déclaration de l’application elle-même, pas de piège particulier. Juste bien penser dans les connexions à mettre URS, ainsi que les T-Server/SIP Server/Interaction Server pour lesquels votre ORS devra jouer des stratégies.

Ci-desssous, un exemple d’application configurée suite à son installation :

Un petit aparté durant l’installation, il vous sera demandé si vous souhaitez utiliser l'”Enhanced Orchestration Cluster Configuration”. Nous allons répondre “yes”, puis donner un nom de transaction list (ici “Cluster_ORS_1”), notons le bien.

On attaque la partie Cluster

Afin de préparer le fonctionnement en cluster, nous allons en effet créer une transaction list au nom de “Cluster_ORS_1” dans GAX. Dans les options de cette liste, nous créons une section au nom de “cluster” et qui contiendra des ensembles clé-valeur où la clé est le nom de votre application ORS membre du cluster, et la valeur le nom du datacenter où est localisé cette application. Si vous en avez un seul datacenter, vous pouvez laisser la valeur vide ou mettre un nom générique, comme “DC1” ci-dessous.

Dans cet exemple, j’ai donc un cluster constitué de 2 noeuds, mes applications ORS_11_Pr et ORS_12_Pr

N.B. : seuls les ORS primaires sont à indiquer dans la transaction list, pas les applications de backup.

Les plus attentifs auront noté l’application ORS_12_Pr indiqué dans le cluster, mais non créé. Et bien allons-y pour créer le nouvel objet ORS_12_Pr, le paramétrer et l’installer.

Ses paramètres étant très proches, le clonage est votre ami 😉

Une fois installé, démarrez vos 2 ORS et vous serez l’heureux “propriétaire” d’un joli cluster d’ORS 🙂

Quelques notes sur cette installation

Le but de ce tutorial était de faire une présentation rapide de l’installation d’un cluster ORS. Quelques notes additionnelles :
– Si dans les logs de votre ORS vous avez le message “Configuration error. Class [Cluster] : This node is not operational – it is not part of ORS Cluster“, il s’agit probablement d’une erreur de frappe dans votre transaction list. Partez à la chasse aux coquilles !
– Si vous avez besoin de plus de noeuds pour tenir la charge, cela n’est pas plus compliqué que d’installer un 3ème noeud puis d’indiquer celui-ci dans votre transaction list. Elle est pas belle la vie ?
– Cette transaction list vous permet également de stocker les options “autres” liées à vos ORS. Ces options prendront le pas sur celles configurées au niveau de chaque application. Pratique pour ne modifier qu’une seule fois les options, et non dans chaque application.
– En parlant des options, je n’ai pas configuré le persistent storage, qui utilise Cassandra. Pas forcément utile pour des flux froids, il peut être important pour la gestion de la persistence de session sur la voix. Mais cela sera pour un autre tuto 😉
– A l’inverse, si vous avez besoin d’ORS gérant des flux froids/tièdes, quelques options sont à modifier dans ORS (ou sa transaction list ;)) :

* orchestration\mcr-pull-by-this-node = true

* orchestration\switch-multi-links-enabled = true (si vous avez plusieurs Interaction Server gérant le même switch)
– Enfin, pour qu’URS utilise bien ORS, il est nécessaire d’ajouter à la configuration de celui-ci :
* default\Strategy = ORS

GAX en mode “PakSaAFaire”

Chacun sa nemesis. Ou ses nemesis. L’une des miennes est l’installation de Genesys Administrator eXtension (GAX pour les intimes). Malgré toute ma concentration et la lecture attentive de la documentation de Genesys, celle-ci me résiste encore et toujours. Ou plutôt me résistait !

5 minutes ? Chuis laaaaarge !

Et encore même en 5 minutes, j’exagère à peine.

Première étape, bien sûr télécharger l’IP de GAX qui convient à votre OS et votre envie de nouveauté. Pour cette étape désolé, mais je n’ai pas encore d’astuce pour l’accélérer 😉

Ensuite vous rendre sur https://docs.genesys.com/Documentation/GA/8.5.2/Dep/Deploying Bon que l’on soit clair, je ne peux rien pour vous pour le début. Mais rendez-vous tout de suite à la section “Deploying GAX via the Command Line”

Et là en résumé :

  1. Créez une base de données SQL de votre choix (MS SQL, Oracle ou Postgre), avec un user et mot de passe sélectionné avec soin, mais aucune initialisation de schéma
  2. Assurez-vous que JRE 7 ou 8 est installé sur le serveur où sera installé GAX, ainsi que notre bon vieux LCA
  3. Ajustez vos variables d’environnement JRE_HOME et PATH pour qu’elles incluent bien le JRE. Cf. https://docs.genesys.com/Documentation/GA/8.5.2/Dep/Deploying#setupHost
  4. Lancez l’installation de GAX elle-même
  5. Et maintenant la partie “magique”, nous allons simplement créer un fichier texte qui contiendra les informations nécessaires au paramétrage de GAX. Appelons ce fichier setup.ini pour faire original 🙂
Configuration_Server_Host=IP_DE_LA_MACHINE_QUI_PORTE_LE_CONFIGSERVER
Configuration_Server_Port=PORT_DU_CONFIGSERVER
Default_Client_Application_Name=default
Configuration_Server_Username=COMPTE_ADMINISTRATEUR_GENESYS
Configuration_Server_Password=MON_MOT_DE_PASSE
Application_Object_Name=GAX (En fait le nom de l'application GAX que vous souhaitez avoir)
Database_Server_Type=oracle (ou mssql ou postgre en fonction de votre base de données)
Database_Host=IP_DE_LA_MACHINE_QUI_PORTE_LA_BASE_DE_DONNEES
Database_Port=PORT_DE_LA_BASE DE _DONNEES
Database_Name=NOM_DE_LA_BASE_DE_DONNEES_CREE_AU_POINT_1
Database_Username=COMPTE_DE_LA_BDD_CREE_AU_POINT_1
Database_Password=MON_MOT_DE_PASSE

Bien sûr les parties entre parenthèses sont à supprimer 😉

Pour finaliser l’installation, il ne vous reste plus qu’à taper la commande suivante dans le répertoire où GAX est installé :

java -jar gax.war -setup gax setup.ini

Et maintenant patientez quelques instants et votre GAX est installé !

Il ne vous reste plus qu’à vous connecter avec votre compte “default” afin de créer un rôle permettant la connexion à GAX, l’associer à un groupe d’accès “qui va bien” et enfin ajouter ce groupe d’accès à vos administrateurs utilisant GAX.

Maintenant vous attend le paramétrage fin de GAX, et là, c’est sûr que c’est bien plus de 5 minutes… 🙂

SIP Server mon amour

C’est parti pour un nouveau tuto, en plusieurs parties. L’idée est de commencer par l’installation d’un SIP Server tout simple, et de le tester. Ensuite nous en installerons un second afin d’activer la haute disponibilité pour ce composant et enfin nous l’interfacerons avec Media Control Platform (MCP pour les intimes) afin de lui faire jouer quelques guides audio.

Mais commençons par le commencement, une installation de SIP Server dans le plus simple appareil…

Les bases, encore les bases, toujours les bases,…

Bon, nous commençons par les prérequis classiques sur ce blog : 1 serveur Linux CentOS7 d’aplomb, un framework fonctionnel, des sources téléchargées, du courage et… une licence avec des places SIP activées. Et oui, si l’on s’est amusé à installer un FlexLM précédemment, c’est pas pour rien.

Une fois les sources décompactées, on va de manière classique utiliser les fichiers templates proposés pour créer un nouveau modèle d’application. Je vous recommande chaudement d’importer également les métadonnées XML car les options de SIP Server sont nombreuses et pas forcément explicites…

Une fois le template créé, on crée immédiatement l’application liée pour notre premier SIP Server, ici nommée SIP_Server_1. Le 1 est bien sûr là car nous créerons ultérieurement le 2…

Je vous conseille de modifier de suite les options liées au log car vous risquez de passer quelques heures/jours à les lire. Chacun ses préférences mais personnellement c’est :

  • ‘verbose’ à ‘all’ quand le volume vous le permet. Toujours plus pratique quand vous devez investiguer sur un souci qui se présente de manière aléatoire
  • ‘keep-startup-files’ à ‘true’, pratique pour avoir rapidement les options de configuration de l’application en début de chaque fichier de log, et pas uniquement dans un seul dont vous aurez perdu la trace…
  • ‘segment’ à ’10 MB’ pour ne pas surcharger votre éditeur de texte préféré et sa coloration syntaxique
  • ‘expire’ à ’10/50/100′, bref à un chiffre et pas une durée. Alors certes, il est compliqué de se représenter la durée que vont couvrir vos logs. Mais au moins vous savez que votre application occupera avec ses logs au maximum ‘expire * segment’ Mo, et pas une tétrachiée d’octets qui rempliront votre disque et ramasseront votre installation. J’ai déjà vu un confserv mécontent des données que lui envoyait l’Interaction Server, et qui produisait un fichier de 10 Mo toutes les 3 secondes…

Pour les options autres que celles liées aux logs, je vais me concentrer sur la partie TServer. Je ne vais que les effleurer mais voici quelques unes qui me sont souvent utiles, ou m’ont déjà sorties du pétrin :

  • le tryptique agent-no-answer-timeout/agent-no-answer-overflow/agent-no-answer-action : avec celles-ci, vous décrivez dans l’ordre :
    • au bout de combien de temps on considère une absence de réaction d’un agent à un appel qui lui est présenté comme étant anormale
    • quelle action prendre pour l’appel (‘recall’ par exemple va le renvoyer au dernier objet de distribution, vous pouvez aussi spécifier un DN spécial “routage par défaut”)
    • enfin, que faire pour le statut de l’agent, et par exemple le mettre ‘notready’ ou le déconnecter avec ‘logout’. Ainsi il ne recevra plus d’appel si celui-ci s’est absenté…
  • wrap-up-time : le temps laissé à l’agent entre la conclusion d’un appel et la présentation du prochain
  • sip-port : par défaut à 5060, le port par lequel la signalisation SIP s’effectuera
  • sip-address : par défaut à vide, il faudra la remplir si vous avez plusieurs cartes réseaux sur votre serveur, afin de vous assurer que les communications SIP partent bien sur la bonne patte
  • dial-plan : pour spécifier l’objet à utiliser qui définira vos règles de numérotation vers l’extérieur ou même en interne

Une fois tout ceci paramétré, il ne vous reste plus qu’à installer le SIP Server avec le classique ‘./install.sh’ et répondre aux questions en ligne de commande.

Une fois l’installation terminée, votre application SIP_Server_1 aura dû être mise à jour et ressembler à ceci :

Vous noterez que j’ai mis à jour la valeur de l’option après ‘l’ afin que le SIP Server puisse vérifier sa licence auprès des 2 FlexLM installé, au cas où l’un d’entre eux aurait flanché…

C’est bientôt fini ?

Oui. Et non…

On va dire que la partie complexe est presque derrière nous, même si dans les faits, on peut passer des heures et des jours à parfaire les options du SIP Server.

Ils nous restent quelques étapes à faire, même si rien de très exceptionnel…

Tout d’abord, ouvrir le port SIP (le 5060 normalement). Cela se fera en 2 lignes de commandes :

sudo firewall-cmd --permanent --add-port=5060/udp
sudo firewall-cmd --reload

(Pour ceux qui voudraient de plus amples informations sur firewall-cmd, vous pouvez vous reporter à mon article “Trucs & astuces Linux eudbase – Partie 1 / …“)

Là vous serez tenté de démarrer votre SIP Server flambant neuf. Allez-y , je vous attends…

Alors, démarrage puis extinction ? Et oui, car SIP Server est “un peu” exigeant et ne voudra pas démarrer sans Switch associé. Et pour déclarer un switch, il faut d’abord un switching office

Comme vous pouvez le voir, rien de très original (ne vous focalisez pas sur le nom du T-Server différent, j’ai dû utiliser une autre VM pour ma capture…)
A ce moment là, votre SIP Server devrait démarrer. Mais tant que nous y sommes, autant créer le nécessaire pour le tester !
Nous allons donc créer 2 extensions sur le SIP Server qui serviront ensuite à enregistrer 2 SIP Phones.
Ces deux extensions seront 00001 et 00002. La configuration sera ultra-basique. Ici un exemple avec 00001 :

Rien de spécial à voir sur l’onglet général. Un peu plus intéressant est l’onglet “Options” :

L’option “contact” permet de spécifier l’adresse de contact de cette extension… ou alors en la laissant à *, celle-ci sera remplacée dynamiquement quand le softphone s’enregistera. Elle prendra alors pour valeur : sip:NUMERO_EXTENSION@NOM_MACHINE_CLIENTE:PORT_SIP_CLIENT
Cela permettra ainsi au SIP Server de savoir où adresser les appels qu’il recevra.

L’option “sip-cti-control” définira quant à elle les actions que le SIP Phone aura le droit d’effectuer. Dans cet exemple du “talk,hold,dtmf”, cela signifie que le téléphone vous permettra de passe un appel ^^, de mettre l’appel en attente et enfin d’envoyer des fréquences vocales.

Maintenant que les extensions sont définies, il ne nous reste plus qu’à démarrer le SIP Server et à le tester grâce à 2 SIP Phones. Dans l’exemple ci-dessous, j’utiliserai X-Lite de CounterPath.
Une fois celui-ci installé sur deux machines différentes ayant accès au serveur où vous avez installé SIP Server, il vous restera à créer un compte sur chaque X-Lite, un pour chaque extension.

Comme vous pouvez le constater, seules 2 options seront importantes :
– User ID qui sera en fait votre extension
et
– Domain qui sera l’adresse IP de votre SIP Server
Et là, sous vos yeux zébahis :

Le premier signe de la victoire

Et pour valider cela, passons un appel :

Deuxième signe de victoire

Et on peut même mettre, en attente, c’est génial 🙂

Nous voilà donc avec un SIP Server certes basique, mais fonctionnel.
Dans la prochaine partie de ce tuto, nous attaquerons un point plus “fun”, en tout cas plus complexe : la mise en place de la HA pour le SIP Server.

Installation de FlexLM sur CentOS7

Allez c’est parti, une premier tutorial bel et bien consacré à Genesys. Mais je vous rassure, pour faire une installation sous Linux. Et celui-ci m’a bien cassé les pieds pour avoir quelque chose de propre…

Bref, c’est parti pour l’installation de FlexLM sous CentOS 7 !

Ouverture des ports

On commence par du simple et classique : ouvrir le port nécessaire à FlexLM. Je suis parti sur le classique 7260, mais ensuite à vous de voir selon votre installation.

Pour ceux qui veulent aller vite :

sudo firewall-cmd --permanent --add-port=7260/tcp
sudo firewall-cmd --reload

Pour ceux qui veulent un peu plus d’infos, direction l’article qui explique un peu plus comment ouvrir les ports : https://www.grutt.org/2019/01/11/trucs-astuces-linux-eudbase-partie-1/

Installation de FlexLM

Petite spécificité pour ce logiciel tierce partie sous Linux, il ne s’installe pas techniquement. C’est une simple archive à décompresser dans le répertoire que vous souhaitez. En faisant par exemple :

tar -xvf lmgr11.13-i686-linux-rhe4.tar -C /opt/genesys/FlexLM_1113 

Souci, si vous essayez de lancer lmgrd immédiatement, vous aurez droit à un joli message d’erreur pour cause de dépendance manquante. Pour y remédier :

sudo yum install redhat-lsb

Suivi d’un :

sudo ln -s /lib/ld-linux.so.2 /lib/ld-lsb.so.3

Ayé, FlexLM démarre ! Enfin démarre, il est pas content sans son fichier de licence le petit gars. Allons donc le paramétrer 🙂

Paramétrer FlexLM

Première étape, on modifie son fichier de licence au niveau des deux premières lignes en remplaçant le nom du serveur (dans mon cas CentOS7-X, oui je manque d’imagination), ainsi que le chemin vers le démon genesys.d

SERVER CentOS7-2 001122334455 7260
DAEMON genesys.d /opt/genesys/FlexLM_1113

Maintenant que le fichier de licence est OK, la ligne de commande pour lancer FlexLM. Celle-ci se présente sous la forme :

./lmgrd -c licence.dat -l +/var/log/genesys/FlexLM/FlexLM.log

Où -c indique le lieu où trouver le fichier de licence, et -l où le fichier de log va être écrit.

Je vous conseille de lancer cette commande à ce moment là pour vérifier que FlexLM se lance bien, et que tout est OK au niveau du fichier de log.

Si tout est bon, tuons à coup de kill ce bon vieux lmgrd pour faire un système de lancement propre, à base de service.

Création d’un service en systemd

CentOS7 a été l’occasion pour RedHat de passer de System V à systemd pour la gestion des services. Alias : jetez à la poubelle ce que vous connaissiez de /etc/rc.d & co… Bon je suis méchant, dans les faits, il y a de la rétro-compatibilité, mais essayons de faire avec une techno “récente” (2010)

Nous allons commencer par créer le fichier flexlm.service dans /etc/systemd/system

Ce fichier va indiquer à systemd comment lancer FlexLM, depuis quel répertoire, à quel moment lors du démarrage… Bref c’est hyper puissant, j’ai pas encore tout compris mais ce qu’il y a ci-dessous, ça fonctionne 🙂

[Unit]
Description=FlexLM
After=network.target network.service

[Service]
User=genesys
Group=genesys
Type=forking
WorkingDirectory=/opt/genesys/FlexLM_1113
ExecStart=/opt/genesys/FlexLM_1113/lmgrd -c licence.dat -l +/var/log/genesys/FlexLM/FlexLM.log
# Restart=on-failure
# Delay before service is stopped forcefully
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target

Une fois le fichier créé, on va demander à systemd de recharger l’ensemble des fichiers .service disponibles, puis tester le démarrage de notre FlexLM.

systemctl daemon-reload
systemctl start flexlm.service
systemctl status flexlm.service

La dernière commande “status” vous permettra de voir si FlexLM s’est bien lancé, avec normalement une superbe ligne “Active: active (running) since Sat 2019-02-02 15:11:26 CET; 5s ago”

Etant donné que FlexLM est nécessaire à “quelques” composants Genesys, j’aime bien le mettre en démarrage automatique.

Pour cela, il ne vous reste plus qu’à taper

systemctl enable flexlm.service

Redémarrez votre serveur, et vérifiez au démarrage que FlexLM est bien présent.

Et maintenant c’est fini ? Non malheureux ! Maintenant, intégrons FlexLM à Genesys pour pouvoir le suivre et l’intégrer à nos solutions.

Monitoring de l’application

Vous avez déjà eu cette impression vous aussi ?

Tout d’abord de manière classique, nous allons créer un nouveau template d’application basé sur le modèle Third Party Server
Dans l’onglet général, les options les plus importantes sont Working Directory, Command Line et Command Line Arguments.
La concaténation de ces 3 options correspond à la chaîne de caractère qui sera recherchée par LCA pour déterminer si oui ou non FlexLM est lancé.
Dans mon exemple, cela donne quelque chose qui ressemble à cela :

Rien de bien sorcier, faites juste attention à une concordance parfaite

A partir de ce moment là, vous devriez pouvoir voir le statut de FlexLM dans Genesys. Mais il reste encore une étape

Démarrage/arrêt depuis Genesys

En effet, si vous essayez de le démarrer-arrêter tel quel, le résultat n’est pas terrible. Ainsi, si vous arrêtez FlexLM depuis Genesys, systemctl “perd les pédales” et ne voit plus bien son statut. Alors autant faire les choses bien.
Pour cela, nous allons créer des options dans l’annexe “start_stop”. start_command et stop_command vont remplacer l’usage habituel et nous allons y placer… les commandes systemctl précédemment créées 😉

On y est presque

Allez, une dernière étape. En effet, vous avez pu remarquer en tapant ces commandes dans un shell que celui-ci vous demande votre mot de passe. Pas pratique pour un appel non interactif.

C’est pourquoi nous allons modifier le fichier /etc/sudoers afin de lui indiquer que ces commandes SPÉCIFIQUEMENT ne requièrent pas de mots de passe. Pourquoi ce mot en majuscule ? Car on pourrait le faire pour l’ensemble des commandes. Mais comme c’est souvent, c’est plus simple, mais c’est pas propre niveau sécurité. Du coup, ajoutons gaiement dans ce fichier les 2 lignes suivantes :

genesys ALL=(ALL) NOPASSWD: /bin/systemctl start flexlm
genesys ALL=(ALL) NOPASSWD: /bin/systemctl stop flexlm

Où genesys représente l’utilisateur qui lancera votre FlexLM, alias l’utilisateur qui lance LCA 🙂

Et voici la fin de ce premier tuto concernant réellement Genesys, je suis à l’écoute de toutes vos suggestions 🙂

Trucs & astuces Linux eudbase – Partie 2 / …

Deuxième billet, et toujours pas du Genesys. Mais ça arrive. On reste dans les petits trucs et astuces sur RedHat 7.

Tu bluffes Martoni CentOS

Il dit qu’il voit pas le rapport…

Attention, cette manipulation est MAL ! Genre le support n’aime pas.
Mais imaginons que vous souhaitiez installer GAX sur votre CentOS tout beau tout propre en 7.6. Et bien vous n’irez pas bien loin ! A peine le script d’installation lancé que vous aurez le droit à un superbe “OS version 7.6.1810 is not supported.”
Diantre ! Que faire ?
En production ? Et bien il aurait mieux valu lire les listes de compatibilités avant.
Pour un lab ?… Allons donc faire une copie du fichier /etc/redhat-release par précaution.

sudo cp /etc/redhat-release /etc/redhat-release.bak

Celui-ci contient la chaîne de caractère suivante :

CentOS Linux release 7.6.1810 (Core)

Modifions cette chaîne de caractère en :

CentOS Linux release 7.5 (Core)

Et hop ! L’installation se passe désormais sans soucis 🙂

Installation de quelques pré-requis Genesys

Le début d’une installation classique

Toujours dans la série “installons moultes composants sous Linux”. Et bien pour commencer, on va installer un joli petit paquet de dépendances nécessaires

Tout d’abord, deux packages nécessaires pour les installeurs Genesys qui sont toujours en 32 bits..

yum install glibc.i686
yum install libstdc++.i686

Ensuite installons le JRE Java, celui-ci sera nécessaire par exemple pour le GAX, ou pour certains composants nécessaires à GIR :

yum install jre

D’ailleurs, en passant, si vous cherchez l’emplacement où se trouve la JRE JAVA :

alternatives --config java

Cette commande vous indiquera les différentes versions installées, où celles-ci le sont, et vous permettra même de sélectionner celle active.

Maintenant PostgreSQL. Si vous souhaitez vous connecter depuis une machine Linux ne portant pas une base PostgreSQL à une de ces bases, il vous suffit d’installer la libraire suivante :

sudo yum install postgresql-libs

Et de manière plus générale, quand un message d’erreur vous indique qu’il vous manque un paquet ou une librairie, vous pouvez utiliser :

sudo yum whatprovides NOM _DU_TRUC_QUI_MANQUE

Cette commande vous indiquera en retour quel paquet installer grâce à yum install 🙂

Ajouter un utilisateur en tant que sudoer

C’est qui le patron ?

Et oui, tout faire en root, c’est mâââââââl. Mais passer d’un utilisateur normal à root et inversement, au bout d’un moment c’est casse-pied. Pour éviter cela, vous pouvez déclarer votre utilisateur comme sudoer. Ainsi il pourra exécuter les commandes nécessitant d’être normalement root, en les préfixant d’un simple “sudo”.

Mais trève de blabla, comment rendre une personne sudoer ? Imaginons que nous souhaitions rendre l’utilisateur “genesys_user” sudoer. Commençons par passer root puis éditons le fichier sudoers :

nano /etc/sudoers

A la fin de ce fichier, sous la ligne root ALL=(ALL) ALL, rajoutez la ligne :

genesys_user ALL=(ALL) ALL

Sauvegardez le fichier et déconnectez-vous du compte root. Mission accomplie !

Et pour la source : https://www.pendrivelinux.com/how-to-add-a-user-to-the-sudoers-list/

Prochain article : installer proprement mon “grand ami”, FlexLM sous Linux.

Trucs & astuces Linux eudbase – Partie 1 / …

Quoi de mieux pour commencer un nouveau blog dédié à Genesys que de parler de … Linux !

Ok je peux comprendre votre surprise. Mais de plus en plus de clients souhaitent basculer en partie leur infrastructure sur une base Unix, et quand on a pratiqué que du Windows depuis 15 ans, et que Linux évoque juste les cuites de l’IUT… Et bien ça pique.
Donc dans cet article, et ceux qui le suivront, l’idée n’est pas de faire de vous un gourou barbu de Linux, mais au moins de connaître les bases nécessaires pour vos actions “de tous les jours”.

Etant donné les pré-requis Genesys, ces informations s’appliqueront à la distribution RedHat Enterprise Linux (RHEL) et son équivalent communautaire, CentOS. Et même, soyons fous, plus particulièrement à leurs versions 7.x, maintenant majoritairement supportées par les diverses solutions Genesys.

Maintenant, attaquons le vif du sujet !

Firewall, mon ami !

Vous ne passerez (presque) pas !

Et oui, commençons par laisser nos machines communiquer entre elles sur notre LAN.

Alors oui, je sais, une des solutions est de désactiver le firewall complètement. Mais déjà ça ne sera pas forcément autorisé dans l’environnement où vous travaillez, et ensuite laisser le pare-feu activé vous obligera à réfléchir aux ports que vous allez utiliser plutôt que de faire cela en mode “à l’arrache”.

Si malgré tout vous souhaitez le faire, ou pour tester si un problème vient bien du firewall :

systemctl stop firewalld 

Attention, cette manipulation, tout comme le démarrage du firewall, demande d’être admin sur la machine sur laquelle vous travaillez.

Allez, arrêtons les bêtises et réactivons le firewall :

systemctl start firewalld 

Pour vérifier que tout est revenu à la normale :

systemctl status firewalld

Cette commande devrait vous gratifier d’un joli : Active: active (running)

Petit aparté, “systemctl” est en fait la commande de gestion des services associé à Systemd, qui est le système utilisé par RHEL/CentOS 7. Mais nous aurons l’occasion d’en reparler.

Ajouter des ouvertures de ports proprement

Maintenant le vif du sujet, ouvrir un port.
Imaginons que l’on souhaite ajouter un port, au hasard le 2020 😉
Pour cela une commande toute simple :

firewall-cmd --permanent --add-port=2020/tcp
firewall-cmd --reload

Deux commandes toutes simples, la première ajoute donc le port 2020, et ceci en tcp, quand la seconde recharge la configuration du pare-feu.
A noter qu’il est aussi possible d’ouvrir une plage de ports (heureusement). Par exemple de 6000 à 6099 :

firewall-cmd --permanent --add-port=6000-6099/tcp 

Rien de bien sorcier comme vous pouvez le voir.

Pour vérifier votre travail :

firewall-cmd --list-ports

Qui nous affiche fièrement :
2020/tcp 6000-6099/tcp

Pour refermer des ports, rien de plus simple :

firewall-cmd --permanent --remove-port=6000-6099/tcp
firewall-cmd --reload

Et nous voici de nouveau avec uniquement le port 2020 tcp ouvert.

Forcer la mise à jour de l’heure système

C’est pourtant simple non ?

Ah les joies de lire les logs de plusieurs composants sur des serveurs différents, chacun décalés de quelques dizaines de secondes… Rien de plus pratique pour… s’arracher les cheveux.
Première étape si ce n’est pas déjà fait, installer un démon ntp. Mais si après l’installation de celui-ci l’heure serveur est fortement décalée de l’heure réelle, alors le démon ntp va corriger l’heure système par petites touches.
Vous n’avez pas envie d’attendre ?

ntpd -g

Ce petit “-g” indiquera de recaler l’offset entre les deux temps, en une seule fois et sans limite. Bien pratique ma foi 🙂

Voici pour ce premier “vrai” billet. Les notes pour le second dédié toujours aux astuces Linux est déjà commencé 😉

Sources :

https://blog.microlinux.fr/client-ntp-centos-7/
https://www.rootusers.com/how-to-open-a-port-in-centos-7-with-firewalld/

Hello World !

Ok, le titre de ce premier billet n’est pas le plus original qui soit mais :

  • Il est presque 22h
  • Ce blog est installé depuis 15 minutes à peine
  • Je ne sais pas encore par où commencer précisément

En conséquence, juste un petit teasing de ce qui devrait apparaître sur ce site dans les jours/semaines/mois/années (rayez les mentions inutiles) si la flemme ne prend pas le dessus 🙂

La première étape sera probablement de publier une suite de courts articles contenant des informations actuellement amoureusement stockées dans un fichier Word (c’est mal)

Pour les vieux de la vieille de Genesys, ces astuces pourront sembler triviales mais si j’ai pris la peine de les noter, c’est qu’elles m’auraient sûrement permis d’éviter quelques cheveux blancs.

Dans les faits, elles concerneront surtout Genesys, mais aussi RedHat, l’OS officiellement supporté par l’éditeur. Car quand on a pas touché à un Linux depuis 15 ans, l’atterrissage peut faire très mal 😉

Et sait-on jamais, si un jour j’ai le courage la folie de le faire, peut-être que je me lancerais sur un tutoriel dédié à l’installation de Genesys Interaction Recording (GIR pour les intimes), la solution d’enregistrement de Genesys.