Exporter une VM depuis un ESXi

Hello world,

Un billet hyper rapide pour une astuce toute simple.

Si vous avez besoin d’exporter une VM présente sur un ESXi, par exemple pour la réimporter ensuite dans un VMWare Workstation, il vous suffit de télécharger depuis le site de VMWare l’outil « OVFTool ».

Une fois celui-ci installé, il vous suffira de lancer en ligne de commande :

ovftool.exe « vi://LOGIN_ESXI:MDP_ESXI@IP_ESXI/NOM_DE_LA_VM » c:\DESTINATION\NOM_DE_LA_VM.ovf

Cet outil propose plein d’autres options, mais je vous laisse découvrir cela par vous même 😉

ORS et les grosses données, featuring Elasticsearch

He is back !

Et non, ce blog n’est pas mort ! Mais oui je dois avouer que le contexte actuel qui chamboule nos vies ne laisse pas beaucoup de temps aux tests/bidouillages et encore moins à la rédaction de billets de blogs…

Non, vraiment, 2020 ne nous aura rien amené de bon…

Du coup, l’idée va être de faire différemment, plutôt que de ne pas faire du tout 🙂 On pourrait presque parler de méthode Agile en fait. Plutôt que de ne rien livrer du tout, je vais faire un post en mode « work in progress ». En fonction du moment où vous lirez ce texte, il sera plus ou moins complet et/ou modifié. Mais :

  1. Ça peut toujours à servir à quelqu’un, même en l’état
  2. C’est pour moi une forme de bloc-notes qui me permettra de me rappeler de mon état d’avancement
  3. Si jamais un « sachant » (3 points au bingo réunion suivi de projet) passe par ici et veut me filer un coup de main en commentaires, je suis preneur

Bref, après tout ce blabla, attaquons donc l’intégration d’ORS au « stack » Elastic

On attaque avec un gros mot : « ELK »

Qu’est-ce que signifie donc « ELK » :

  • Elasticsearch
  • LogStash
  • Kibana

Il s’agit des 3 principaux composants nécessaires dans une majorité des cas quand on monte une suite Elasticsearch. Ah oui j’ai oublié de préciser : je ne suis pas un expert concernant Elastic. Pour tout dire, je découvre même Elastic avec ce side project. Donc j’espère que vous saurez être magnanime 😉

Elasticsearch est la base même de cette suite. Il s’agit d’un ensemble base de données + moteur de requêtes + API permettant d’y accéder. En comparaison avec d’autres bases de données, il a comme caractéristiques d’être facilement scalable en ajoutant des noeuds en fonction de vos besoins de redondance et/ou de performance, et de permettre de stocker des données non déterminées à l’avance. Oubliez les types précis associés aux colonnes des moteurs SQL habituels. Ici du moment que vous envoyez du JSON, il saura quoi en faire 🙂

LogStash est en approximation un ETL. Vous allez lui fournir des fichiers de logs et le mapping qui va bien, et il va en extraire les données qui vous intéresse, avant de les envoyer à Elasticsearch. Cette explication est plus « pour information » car dans le cas qui nous intéresse, ORS va se charger lui-même d’envoyer les données en base de données. Mais bon, on sait jamais… 🙂

Kibana enfin va vous permettre d’effectuer des requêtes en KQL sur la base de données, et de créer de jolies visualisations de toutes ces données, afin de les expliciter

C’est beau hein ? Mais c’est pas de moi 🙂

Hop, on commence l’installation

Bon contrairement à d’habitude, je ne vais pas vous faire les installations d’Elasticsearch et Kibana pas à pas car elles sont relativement simples, pas loin du « Next – Next – Next » que l’on aurait sous Windows. La page qui va bien : https://www.elastic.co/guide/en/elastic-stack/current/installing-elastic-stack.html

Quelques conseils cependant en passant :

  • Vous avez peut-être entendu parler de fuites de données récentes où les pirates se sont simplement servis sur des Elasticsearch exposés sur Internet et avec les logins/mots de passe par défaut. Et bien vous savez quoi, ça me surprend pas … J’ai trouvé que la partie modification des mots de passe par défaut était pas forcément explicité. Du coup, pour sécuriser un peu le bazar : https://www.elastic.co/guide/en/elasticsearch/reference/7.11/setup-passwords.html A faire idéalement dès que vous aurez fini l’installation d’Elasticsearch, cela vous évitera d’avoir à reprendre vos fichiers de configuration après coup
  • Les options que j’ai modifié dans les fichiers de configuration d’Elasticsearch et Kibana. Pas exhaustif mais une base de départ. Et pour rappel, ce sont des fichiers au format yaml donc l’oeuvre du démon où le moindre espace d’indentation en trop invalidera l’ensemble du fichier. Donc faites très attention à vos modifications, et backup des fichiers d’origine avant de faire quoi que ce soit
    • elasticsearch.yml :
      • cluster.name: my-cluster-test
      • node.name: ES-RHEL8-1
      • network.host: AdresseIPdeMonServeur
      • http.port: 9200
      • discovery.seed_hosts: [« 127.0.0.1 », « [::1] », »AdresseIPdeMonServeur« ]
      • cluster.initial_master_nodes: [« ES-RHEL8-1 »]
    • kibana.yml :
      • server.host: « AdresseIPdeMonServeur« 
      • server.name: « RHEL8-1 »
      • elasticsearch.hosts: [« http://AdresseIPdeMonServeur:9200″]
  • Enfin pour valider le bon fonctionnement d’ELK (EK même techniquement) avant de s’attaquer au paramétrage d’ORS, je vous conseille d’installer une des sources de données proposées par défaut dans Kibana dans l’onglet « Add data ». Me concernant j’ai installé MetricBeat qui permet de suivre l’activité de ses serveurs et s’installe très simplement
Oui, je n’ai aucune originalité dans le choix de mes noms de serveurs 🙂

Et si on faisait quelque chose d’utile maintenant ?

Maintenant que notre suite Elastic est installé, on va pouvoir paramétrer ORS pour qu’il s’interface avec celle-ci. Mais pourquoi faire déjà ? De base, ORS propose 3 fonctions de suivi de son activité qui peuvent ensuite être reportés dans Elastic :

  • Session reporting : ORS va stocker des informations sur chaque session créée. Le numéro appelant, la stratégie utilisée, heure de début et de fin,… Apparemment, on peut customiser ces informations en modifiant sa stratégie Composer 🙂
  • Performance reporting : ORS dispose d’une fonction de suivi de ses « constantes vitales », qu’il peut de base afficher dans les logs, et créer des alarmes Genesys associées en fonction de seuils. L’intégration à Elasticsearch permet de les monitorer pour suivre l’état de santé de ses nœuds ORS.
  • Node reporting : Ici ORS fournira des informations sur les différents nœuds actifs, ainsi que le host sur lequel ils tournent, ainsi que ses ports d’écoute TCP principaux

Activer ces 3 fonctionnalités se fait au niveau du paramétrage d’ORS (ou de la transaction list qui contient ses paramètres, cf. mon article sur l’installation d’ORS) dans la section elasticsearch

  • ors-es-session-report = true
  • ors-es-perfsnapshot-report = true
  • ors-es-node-info-report = true
  • ors-es-nodes = http://AdresseIPdeMonServeur:9200
  • username = elastic
  • password = changeme

Les 3 premières options permettent d’activer les 3 fonctions de suivi présentées précédemment, et les 3 suivantes de vous connecter à votre Elasticsearch. Le username et le password présentés sont ceux par défaut, avant modification

Une fois ces options paramétrées, redémarrez votre ORS et vous devriez voir des données remonter dans Kibana. Pour cela, connectez-vous à celui-ci et allez dans Stack Management > Index Management et vous trouverez de nouveaux « Indices » (l’équivalent d’une base de données dans Elasticsearch) nommés nodes, performance-YYYY.MM.DD et session-YYYY.MM.DD, chacun correspondant encore une fois aux 3 fonctions de reporting proposées.

Ingestion des données

Récapitulons : on a un Elasticsearch fonctionnel, un ORS configuré et des données qui remonte dans Elasticsearch. Maintenant, il pourrait être pratique d’effectuer des requêtes sur celles-ci.

Pour cela, nous allons rester sur la page « Stack Management » mais aller désormais dans Kibana\Index Patterns, puis « Create index pattern »

Sur la seconde page, on va indiquer les index que l’on souhaite « regrouper ». En effet par exemple, les index de session vont être suffixés par la date du jour. Mais bien sûr, on veut pouvoir consolider les données de plusieurs périodes sur un seul graphique. C’est pourquoi par exemple pour consolider les informations de sessions, on va indiquer dans Index pattern name « session-*

L’étape suivante va consister à indiquer s’il s’agit de données basées sur des informations de date, et auquel cas quelle donnée nous servira « d’abscisse ». Dans le cas des informations de session, on peut ainsi par exemple sélectionner la date de début de session, ou celle de fin :

Maintenant que l’index pattern est créé, on va pouvoir requêter les données présentes dans Elastic grâce à la page Analytics > Discover puis en sélectionnant l’index pattern qui nous intéresse

Visualisation des données

Voilà, comme annoncé au début de cet article, ce n’est pas encore fini. Il me reste maintenant à faire de beaux graphiques avec tout cela…

Stay tuned !

Euh, on est large hein ? (feat. FlexLM)

Qui ne s’est jamais posé cette question ? Reste-t-il des licences pour continuer à déployer ou non. Et bien sûr, les outils Genesys sont là pour nous aider </ironie>

Cette méthode marche également…

Pour répondre à cette question pourtant simple, une petite astuce que je n’ai découvert qu’hier, du moins en version Linux. Et pour savoir où nous en sommes en termes de licences, nous allons aller voir notre ami FlexLM avec une commande toute simple :

cd /MON_REPERTOIRE_FLEXLM
./lmstat -c MON_FICHIER_DE_LICENCE.dat -a > recap.txt

Rien de très sorcier dans cette ligne de commande. Derrière l’option « -c » vous devez donc préciser l’emplacement de votre fichier de licence et « -a » est un alias pour « all ».
Comme vous pouvez le constater, j’ai ensuite redirigé sa sortie vers un fichier texte afin de pouvoir l’analyser simplement.
Exemple ci-dessous pour mon HomeLab :

lmstat - Copyright (c) 1989-2015 Flexera Software LLC. All Rights Reserved.
Flexible License Manager status on Sat 5/23/2020 11:28

License server status: 7260@CentOS7-1
    License file(s) on CentOS7-1: /opt/genesys/FlexLM_1113/licence.dat:

 CentOS7-1: license server UP (MASTER) v11.13.1

Vendor daemon status (on CentOS7-1):

 genesys.d: UP v11.13.1
Feature usage info:

Users of 3GP82419ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP21278ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP21747ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP08807ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP09014ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP09017ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP08812ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP21843ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP20166ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP21844ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of 3GP20364ACAA:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of ISDK_FACTORY:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Users of router_seats:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of tserver_iscc:  (Total of 999999 licenses issued;  Total of 1 license in use)

  "tserver_iscc" v8.0, vendor: genesys.d, expiry: 1-jan-00
  floating license

    SIP_Server_1 CentOS7-1 /dev/tty (v8.0) (CentOS7-1/7260 202), start Sat 5/23 11:26

Users of DESKTOP_SUPERVISOR:  (Total of 15 licenses issued;  Total of 0 licenses in use)

Users of tserver_tdn:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Users of ics_multi_media_agent_seat:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of ics_custom_media_channel:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of occ_preview:  (Total of 156 licenses issued;  Total of 0 licenses in use)

Users of cti_ha_option:  (Total of 999999 licenses issued;  Total of 1 license in use)

  "cti_ha_option" v8.0, vendor: genesys.d, expiry: 1-jan-00
  floating license

    SIP_Server_1 CentOS7-1 /dev/tty (v8.0) (CentOS7-1/7260 302), start Sat 5/23 11:26

Users of tserver_sdn:  (Total of 312 licenses issued;  Total of 312 licenses in use)

  "tserver_sdn" v8.0, vendor: genesys.d, expiry: 1-jan-00
  floating license

    SIP_Server_1 CentOS7-1 /dev/tty (v8.0) (CentOS7-1/7260 105), start Sat 5/23 11:27, 312 licenses

Users of CLDistributed:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Users of ha_redundancy:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Users of lds:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Users of MLDistributed:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Users of router_ha_option:  (Total of 999999 licenses issued;  Total of 0 licenses in use)

Reste à l’interpréter. La question que je rencontre la plus fréquemment étant « On peut encore ajouter du monde ? », nous allons regarder plus précisément deux lignes :

  • Users of tserver_sdn: (Total of 312 licenses issued; Total of 312 licenses in use) –> on a ici le nombre de connexions de types TServer/SipServer que l’on peut avoir en simultané. Commencez par le comparer au nombre de DN de type extensions dont vous disposez. Si vous en créez plus que ce nombre, ceux-ci ne seront de toute façon pas utilisables car le serveur refusera de les enregistrer
    N.B. : on est ici sur une infrastructure assez simple. Si vous aviez plusieurs SIPServer et/ou TServer, la répartition entre ceux-ci serait indiquée
  • Users of router_seats: (Total of 156 licenses issued; Total of 0 licenses in use) –> là ça sera le nombre de places occupées que vous pourrez avoir simultanément. La différence ? Rien ne vous empêche par exemple d’avoir dans le cas présent 200 places déclarées dans Genesys, dont 156 permettant la connexion au canal voix (les 312 licences tserver_sdn ci-dessus, divisées par deux car je suis en HA) et 44 places permettant de se connecter à un autre media tel que le chat. Par contre attention, quelque soit le mix entre « places voix » et « places chat », le total ne pourra pas dépasser les 156 router_seats indiqués

Voilà un petit article rapide mais que je serai sûrement amené à faire évoluer en fonction de mes pérégrinations licencesques ^^

Superviser une application Linux dans SCI/GA/GAX

Mise à jour du 31/03/2020 :
Pardonnez moi cher lecteurs car j’ai pêché. En effet, et contrairement à mes habitudes, j’ai écrit cet article en me basant sur mes notes et sur mes souvenirs, ce qui fait que certaines parties étaient trop rapides ou absentes. D’où cette mise à jour. Décidément, Cassandra est bien compliqué à comprendre 😉

Sur les applications les plus récentes de Genesys, on note de plus en plus l’utilisation de solutions « libres ». Je veux parler par exemple d’applications telles que les bases de données Cassandra, les serveurs web Apache ou Tomcat, Kafka,… Problème, ces solutions, telles qu’elles, ne sont pas intégrées aux outils de supervision de Genesys que sont SCI, GA ou GAX. Or si elles plantent, votre solution sera tout aussi inutilisable que si c’était un composant Genesys qui se vautrait… Nous allons donc remédier à cela, en prenant pour exemple cette bonne vieille Cassandra !

Oui faire du NoSQL, ça peut rendre ronchon !

Le modèle, c’est important

Tout d’abord, il faut savoir que Genesys propose de créer des modèles d’application pour ces serveurs tierces parties, alias comme le disent nos amis d’outre manche « Third Party Server« .
Rien de spécial dans la création de ce template, je vais donc me limiter à une capture d’écran.

Oui, je déborde d’imagination pour mes noms de templates…

Maintenant que le template est créé, nous pouvons attaquer la création de l’application elle-même. Bien sûr celle-ci sera basée sur ce nouveau template « Cassandra Node ».

C’est toujours up ?

Pour vérifier que notre composant est toujours bien en mémoire, nous allons devoir nous assurer que le LCA de la machine hôte retrouve bien dans les process ce composant qui nous intéresse. Ici plusieurs écoles existent sous Linux, voici la mienne :

  • Répertoire de travail : « / » (oui, simplement /)
  • Ligne de commande : « bin/sh » (à adapter bien sûr si vous utilisez un autre shell). Celui-ci sera donc combiné avec notre répertoire de travail pour faire un bon vieux « /bin/sh »
  • Arguments de ligne de commande : ici on arrive dans la partie intéressante où on va spécifier le chemin vers nos exécutables. Cela dépendra forcément de votre installation mais vous devriez arriver à quelque chose du genre : « /LE_REPERTOIRE_D_INSTALLATION_DE_MON_CASSANDRA/bin/cassandra -f »

Avec ces options, vous devriez… pas pouvoir faire grand chose ! En effet, quand vous lancez cassandra en ligne de commande avec cette commande, il s’agit en fait d’un script qui s’exécute et qui va lancer la ligne de commande java « qui va bien » avant de disparaître tout en lui redonnant son PID. Nous allons donc modifier le script « cassandra » de lancement afin qu’il ne disparaisse pas.
Pour cela, éditez ce script et remplacez dedans :

# The cassandra-foreground option will tell CassandraDaemon not
# to close stdout/stderr, but it's up to us not to background.
if [ "x$foreground" != "x" ]; then
    cassandra_parms="$cassandra_parms -Dcassandra-foreground=yes"
    if [ "x$JVM_ON_OUT_OF_MEMORY_ERROR_OPT" != "x" ]; then
        exec $NUMACTL "$JAVA" $JVM_OPTS "$JVM_ON_OUT_OF_MEMORY_ERROR_OPT" $cassandra_parms -cp "$CLASSPATH" $props "$class"
    else
        exec $NUMACTL "$JAVA" $JVM_OPTS $cassandra_parms -cp "$CLASSPATH" $props "$class"
    fi
# Startup CassandraDaemon, background it, and write the pid.
else
    if [ "x$JVM_ON_OUT_OF_MEMORY_ERROR_OPT" != "x" ]; then
        exec $NUMACTL "$JAVA" $JVM_OPTS "$JVM_ON_OUT_OF_MEMORY_ERROR_OPT" $cassandra_parms -cp "$CLASSPATH" $props "$class" <&- &
        [ ! -z "$pidpath" ] && printf "%d" $! > "$pidpath"
        true
    else
        exec $NUMACTL "$JAVA" $JVM_OPTS $cassandra_parms -cp "$CLASSPATH" $props "$class" <&- &
        [ ! -z "$pidpath" ] && printf "%d" $! > "$pidpath"
        true
    fi
    true
fi

par :

# The cassandra-foreground option will tell CassandraDaemon not
# to close stdout/stderr, but it's up to us not to background.
if [ "x$foreground" != "x" ]; then
    cassandra_parms="$cassandra_parms -Dcassandra-foreground=yes"
    $NUMACTL "$JAVA" $JVM_OPTS $cassandra_parms -cp "$CLASSPATH" $props "$class"
# Startup CassandraDaemon, background it, and write the pid.
else
    $NUMACTL "$JAVA" $JVM_OPTS $cassandra_parms -cp "$CLASSPATH" $props "$class" <&- &
    [ ! -z "$pidpath" ] && printf "%d" $! > "$pidpath"
    true
fi

(Oui c’est barbare et je n’y comprends pas grand chose. Merci à mon collègue Antoine qui m’a filé cette astuce, un barbu par l’esprit, même sans la pilosité).
L’idée générale est la suppression des commandes « exec » qui vont permettre de ne plus faire disparaître le script cassandra après qu’il ait lancé cassandra même.

Pour confirmer le bon fonctionnement de cette manipulation, allez faire un tour en ligne de commande sur votre hôte et faites un bon vieux « ps -aux | grep cassandra » (avec Cassandra actif).
Ainsi vous devriez retrouver la ligne de commande que cherche LCA (en plus de la ligne commençant par « java »), et qui doit correspondre à la concaténation de « Répertoire de travail » + « Ligne de commande » + « Arguments de ligne de commande ». Si ce n’est pas le cas, faites les ajustements nécessaires.

Dans le doute, reboot !

Bon, maintenant on peut voir si l’état de notre application, et ça c’est bien. Mais pas moyen de l’allumer/éteindre via notre interface !
Rien de plus simple :

  • Un tour dans l’onglet « Options » de l’application (et non dans « Options de l’application »). OK en anglais c’est plus simple avec « Annex » et non « Options »…
  • Création d’une section nommée « start_stop »
  • Création des options start_command et stop_command Celles-ci devront correspondre aux commandes vous permettant de lancer et arrêter votre application

Sous Red Hat/CentOS 7, j’essaye de créer systématiquement un service pour gérer le process Cassandra. Ainsi ces fameuses options ont pour valeur « systemctl start cassandra » et « systemctl stop cassandra ».
Attention, en fonction de l’utilisateur qui fait tourner votre process LCA, il sera peut-être nécessaire d’ajouter « sudo » avant, et de rajouter ce fameux utilisateur à la liste des sudoers (voir /etc/sudoers).
Et vu que je suis dans un jour de bonté, un exemple de fichier .service servant de définition :

[Unit]
Description=Cassandra
After=network.target

[Service]
User=genesys
Group=genesys
Type=simple
WorkingDirectory=/LE_REPERTOIRE_D_INSTALLATION_DE_MON_CASSANDRA/bin
ExecStart=/LE_REPERTOIRE_D_INSTALLATION_DE_MON_CASSANDRA/bin/cassandra -f 

[Install]
WantedBy=multi-user.target

Avec tout ceci, vous devriez donc désormais pouvoir voir l’état de vos base de données Cassandra, contrôler leur arrêt/démarrage et même les ajouter à des solutions. Elle est pas belle la vie ?
Et pour rappel, cette méthode générale est applicable à d’autres process Linux 🙂

PS : dans la mythologie, Cassandra a toujours raison, mais personne ne la comprend. En l’appliquant à ma propre relation avec cette base de données, je trouve le nom très bien choisi 😀

Bonus CentOS6 :
Et oui forcément, une fois qu’on a une méthode pour un OS, il faut le faire sur un autre… Bref. Me voici sur une CentOS6 et pas de service à l’horizon.
Du coup, j’ai remplacé la valeur de start_command par :
– « /LE_REPERTOIRE_D_INSTALLATION_DE_MON_CASSANDRA/bin/cassandra -f « 
et celle de stop_command par :
– « /LE_REPERTOIRE_D_INSTALLATION_DE_MON_CASSANDRA/bin/stop_cassandra »
Votre esprit affuté remarque que « stop_cassandra » n’existe pas par défaut. C’est un mini script que j’ai placé à cet endroit et dont le contenu est le suivant :

user=`whoami`
pgrep -u $user -f cassandra-pidfile | xargs kill

ATTENTION : celui-ci va par contre couper TOUS les Cassandra tournant actuellement sur votre host et avec le user utilisé par LCA. Moche si vous avez des noeuds co-localisés…
Si vous avez une solution, la zone commentaire sera ravie de l’accueillir 🙂

Genesys Administrator, proprement

Et non, toujours pas de tuto SIP. Après tout, c’est mon blog alors je fais ce que je veux 🙂 Et surtout, je vais en profiter pour faire un petit tuto pour installer proprement ce composant pas forcément très original qu’est Genesys Administrator, mais qui propose ses petits pièges

Lire les pré-requis, toujours

Et oui, cela peut sembler tout bête, mais la plupart de mes soucis étaient dû à une lecture incomplète des pré-requis.
Genesys Administrator nécessite Microsoft IIS, ça on est d’accord. D’ailleurs si celui-ci est absent, l’installation s’interrompt avec une erreur.
Le problème est qu’elle peut très bien s’effectuer avec IIS mais sans les autres modules nécessaires. La conséquence ?
Genesys Administrator ne sera pas déclaré dans IIS et même si vous le déclarez « à la main », pas forcément fonctionnel. Donc on coche bien les cases suivantes (cas d’une installation sous Windows Server 2012 R2) dans le Server Manager de Windows :
Roles :

  • Application Server [.NET Framework 4.5, Web Server (IIS) Support, Windows Process Activation Service Support (Select HTTP Activation]
  • File and storage Services [File Server]
  • Web Server (IIS) [Web Server [Common HTTP Features, Health and Diagnostics, Performance, Security, Application Development [.NET Extensibility 3.5, .NET Extensibility 4.5, ASP.NET 3.5, ASP.NET 4.5, ISAPI Extensions, ISAPI Filters]], Management Tools [IIS6 Management Compatibility]]

Features :

  • .NET Framework 3.5 Features [.NET Framework 3.5]
  • .NET Framework 4.5 Features [.NET Framework 4.5, ASP.NET 4.5, WCF Services [HTTP Activation, TCP Port Sharing]]
  • Windows Process Activation Service [Process Model, Configuration APIs]

Après avoir installé l’ensemble de ces composants, l’installation ET la déclaration de Genesys Administrator devrait être OK. Mais on ne va pas en rester là…

Windows Server 2012, 2016, …

Et oui, GA n’est pas spécialement jeune. Et la doc va donc bien vous expliquer comment l’installer sous Windows Server 20003 & 2008. Mais au-delà, pas de son, pas d’images.
Heureusement une autre documentation existe pour les versions 2012 et 2016 : https://docs.genesys.com/images/Repo/genadmin81dp.html
Vous retrouverez ici les pré-requis nécessaires, mais aussi les modifications à effectuer sur le fichier web.config après installation pour que tout se déroule bien.

Y a shall not pass

Bon votre GA est bien installé, tout est bien qui finit bien ?
Et bien… ça dépend.
Vous vous connectez avec le compte « default » : tout passe comme sur des roulettes
Vous vous connectez avec un autre compte Super Administrator :

C’est moche de se faire jeter de chez soi

Dans les faits c’est assez simple. Pour accéder à GA, votre compte doit avoir les privilèges nécessaires, ou être le fameux « default ». Mais pour affecter ces privilèges, il faut accéder à GA… Donc si vous n’avez pas le compte default, vous êtes dans une belle boucle.
Bien sûr, une solution existe. Vous pouvez désactiver temporairement cet accès via privilèges.

Pour cela,rendez vous dans l’application « default », créez une section « security » et l’option « disable-RBAC » à « true »

RBAC : Role Based Access Control

Une fois cette option créée, vous pourrez vous connecter avec n’importe quel compte sur GA. Et ainsi :

1) Création d’un rôle avec affectation à un groupe d’accès qui va bien

2) Ajout des privilèges nécessaires pour l’accès (si vous ne les voyez pas, pensez bien à cocher « Genesys Administrator » en haut)

3) Sauvegarde et modification du réglage [security]disable-rbac à false. Et oui, je pense que vous ne voulez pas laisser tout le monde entrer sur votre GA tout beau 🙂

One SCS to rule them all

Maintenant que vous pouvez accéder à Genesys Administrator, à vous les joies de la création de campagne d’appels ou de LRG avec des assistants 🙂 (Dis Mr Genesys, ça arrive quand dans GAX ?)
Mais il vous manque peut-être quelquechose, la possibilité de voir l’état de vos applications et de les arrêter/démarrer.
Si c’est le cas, pensez simplement à ajouter dans l’application « default » (toujours elle) une connexion vers votre SCS.
Il vous suffira ensuite de vous connecter/déconnecter et tout ira bien 🙂

Voici pour ce tuto rapide, quand j’aurai le temps (plus de promesses) je rajouterai l’accès à la base de log, et la supervision de GA au sein de SCI/GA/GAX. De la supervisionception en gros 😉

Sources :

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.

N.B. : précision de mon collègue Blackeyed : une fois le script lancé, celui-ci reste « bloqué » dans les faits, la configuration a été effectuée et il s’agit uniquement du process GAX qui vous attend gentiment. Vous pouvez donc soit l’utiliser tel quel (bof) ou le couper puis relancer proprement, a minima avec ce bon vieux ./run.sh & 😉

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.