Qu’est-ce que Ansible ?

Ansible est un outil écrit en Python qui permet de faire des déploiements.

Ansible se sert de deux fichiers de configuration pour fonctionner.

Le premier est l’inventory, il regroupe les adresses réseau des machines qu’on souhaite gérer.

Le second est un playbook, il agit comme un script qu’on pourra exécuter sur n’importe laquelle des machines de l’inventory.

Tous les fichiers de configuration d’Ansible sont au format YAML.

À partir de ces deux fichiers Ansible établit des connexions SSH sur les machines de notre choix (depuis l’inventory), transfert le playbook sur les machines connectées, l’exécute et enfin fait remonter les résultats.

Cette approche permet de facilement réaliser n’importe quel type de déploiement à petite comme à grande échelle en écrivant un seul script, et en utilisant une seule commande.

Les résultats et les erreurs (si il y en a) sont tous remontés une fois que tout est fini.


Ansible est écrit en Python et l’utilise également pour exécuter les playbooks sur les machines, il faut donc que ce dernier soit installé sur les systèmes où l’on veut faire des déploiements.

Les actions qu’on peut demander à Ansible de réaliser sont des modules, qui permettent de réaliser une tâche spécifique.

Chaque tâche dans le playbook utilise un module, et on peut ajouter autant de tâches qu’on a besoin, comme dans un script.

Parmi les modules fournis avec Ansible on peut par exemple exécuter des commandes shell, manipuler des fichiers, en télécharger, etc.

L’intérêt du fonctionnement par modules c’est que tout le monde peut en écrire et on peut utiliser ceux qui sont publiés sur Ansible Galaxy par la communauté.

Cette plateforme regroupe des centaines de collections, qui contiennent un ou plusieurs modules. Il en existe déjà pour énormément de services et applications de toutes sortes (bien trop pour tous les citer ici).

Il y a également des collections fournies par IBM pour interagir avec leurs systèmes, notamment l’IBM i avec la collection power_ibmi.


Pour réaliser des plus petites tâches rapidement il est possible d’exécuter des commandes dites ad hoc. L’exécution sera la même qu’avec un playbook, sauf qu’il n’y aura pas besoin de créer un playbook, à la place on donne les paramètres du module directement dans la ligne de commande.

Cette méthode est très utile pour des actions simples et moins fréquentes, par exemple pour redémarrer toutes les machines d’un inventory.

Quelques exemples simples

Voici à quoi ressemble un inventory très simple qui liste deux machines (machineA et machineB).

all:
    hosts:
        machineA:
            ansible_host: 10.0.0.1
        machineB:
            ansible_host: 10.0.0.2
    vars:
        ansible_ssh_user: root

La partie vars permet de donner des paramètres supplémentaires pour les connexions SSH et l’exécution des modules.

Le paramètre ansible_ssh_user permet d’indiquer en tant que quel utilisateur Ansible doit se connecter par SSH, ici nous serons root.


Voilà désormais un playbook très simple également qui ne fait qu’un simple ping, cela permet de vérifier si Ansible peut se connecter aux machines et exécuter un playbook.

- name: playbook ping
  gather_facts: no
  hosts: all
  tasks:
  - ping:

Le paramètre gather_facts est par défaut configuré sur yes. Le gather facts récupère des informations sur le système où le playbook s’exécute (système d’exploitation, environnement, versions de Python/Ansible, etc) qu’on peut ensuite utiliser dans le playbook ou afficher. Ici on ne souhaite faire qu’un ping pour vérifier qu’Ansible fonctionne bien, on peut désactiver le gather facts puisqu’on ne s’en sert pas.

Le paramètre hosts permet d’indiquer sur quels machines de l’inventory ce playbook doit être exécuté par défaut.

Le paramètre tasks liste chaque tâche à exécuter (avec le nom du module). Ici on utilise le module ansible.builtin.ping qu’on peut abréger en ping.


Pour exécuter ce playbook on utilise la commande ansible-playbook -i inventory.yml playbook.yml (en remplaçant bien entendu les noms des fichiers par ceux que vous avez).

Voici le résultat qu’on obtient avec l’inventory et le playbook précédents :

$ ansible-playbook -i inventory.yml ping.yml

PLAY [playbook ping] *****************************************************************

TASK [ping] **************************************************************************
ok: [machineA]
ok: [machineB]

PLAY RECAP ***************************************************************************
machineA  : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
machineB  : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Ansible nous rapporte que la tâche ping a réussi sur les deux machines. La partie PLAY RECAP résume les résultats de toutes les tâches.


L’équivalent de ce playbook en mode Ad Hoc est la commande :

$ ansible -i inventory.yml -m ping all

Le dernier paramètre all correspond au paramètre hosts du playbook, il indique d’exécuter la commande sur tous les hôtes présents dans l’inventory.

Le paramètre -m ping indique quel module utiliser (la documentation sur les commandes ad hoc est disponible ici).

Commande ad hoc de ping

Ansible for i

IBM fournit la collection power_ibmi qui contient beaucoup de modules pour interagir avec les IBM i, la documentation se trouve ici, et la référence des modules ici.

Cette collection est d’ailleurs disponible sur Github ici (avec plusieurs exemples et autres ressources).


Voici un exemple de playbook qui utilise cette collection, plus particulièrement le module ibmi_sysval. Ce playbook va récupérer une valeur système puis faire une assertion de sa valeur.

- hosts: all
  gather_facts: no
  collections:
   - ibm.power_ibmi

  tasks:
  - name: Vérification CCSID
    ibmi_sysval:
      sysvalue:
        - {'name': 'qccsid', 'expect': '1147'}

Le paramètre collections indique qu’il faut d’abord chercher le module ibmi_sysval dans les collections énumérées (dans l’ordre) mais cette partie est optionnelle (comme indiqué dans la documentation ici).

Puis on indique que l’élément nommé qccsid dans la variable de retour sysvalue doit correspondre à la valeur 1147.

Voilà le résultat qu’on obtient lorsque la valeur système correspond :

$ ansible-playbook -i inventory.yml assert_ccsid.yml

PLAY [all] ***************************************************************************

TASK [Vérification CCSID] ************************************************************
ok: [machineA]
ok: [machineB]

PLAY RECAP ***************************************************************************
machineB : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0
machineA : ok=1  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Et si le QCCSID ne correspond pas Ansible affiche une erreur à la place de ok: [machine], au format JSON :

fatal: [machineA]: FAILED! =>
{
	"changed": false,
	"fail_list": [{
		"check": "equal",
		"compliant": false,
		"expect": "1147",
		"msg": "Compliant check failed",
		"name": "QCCSID",
		"rc": -2,
		"type": "10i0",
		"value": "65535"
	}],
	"message": "",
	"msg": "non-zero return code when get system value:-2",
	"rc": -2,
	"stderr": "non-zero return code when get system value:-2",
	"stderr_lines": ["non-zero return code when get system value:-2"],
	"sysval": []
}

Note: Dans le terminal cette erreur est souvent affichée sans indentation ni retours à la ligne.

Ici on peut voir que l’assertion a échoué, la valeur système était 65535, mais le playbook s’attendait à ce qu’elle soit 1147.


Il y a de nombreux autres cas d’usage, plusieurs exemples sont disponibles sur le dépôt Github ansible-for-i.

Il y a quelques exemples pour des utilisations spécifiques ici, et d’autres exemples de playbooks ici.

Interfaces graphiques : AWX et Tower

Ansible est un outil qui s’utilise dans le terminal, mais il existe deux solutions qui fournissent une interface graphique plus intuitive en plus d’autres fonctionnalités (planification de tâches, gestion de plusieurs utilisateurs et de leurs droits, notifications).

Ces deux solutions sont AWX et Tower, les deux sont très similaires : AWX est un projet open-source (disponible ici), et Tower (disponible ici) est une solution qui est basée sur AWX mais qui nécessite une licence.

La principale différence entre les deux est que Tower subit beaucoup plus de tests pour être plus stable et vous pouvez recevoir de l’aide du support technique Red Hat si besoin. AWX en revanche est moins testé et donc plus susceptible de rencontrer des instabilités, il n’y a également pas de support technique pour AWX.

Si la stabilité est une nécessité (comme en environnement de production) mieux vaut s’orienter vers Tower.

AWX est compatible sur Linux (les distributions les plus populaires devraient toutes le faire fonctionner), Tower est également compatible sur Linux mais est beaucoup restreint. Actuellement ce dernier n’est compatible que sur Red Hat Enterprise Linux (RHEL), CentOS et Ubuntu.


Nous avons testé AWX sur Debian (Bullseye), l’installation peut être assez compliquée lorsqu’on découvre AWX et son environnement mais son utilisation est plutôt intuitive.

L’interface et le fonctionnement de Tower sont quasiment identiques à AWX.

Dashboard AWX

Il y a plusieurs différences dans la manière d’utiliser Ansible dans le terminal et depuis AWX.

La configuration des machines, de leurs identifiants et des inventory est similaire et très facile. En revanche pour les playbooks ce n’est pas la même méthode.


Premièrement on doit configurer un projet. Un projet est un groupe d’un ou plusieurs playbooks sous la forme d’un dépôt Git ou d’une archive.

Paramètres d’un projet

Ensuite il faut créer des templates, une template peut être considérée comme la commande pour exécuter un playbook : on choisit quel playbook exécuter depuis un projet, on choisit sur quel inventory l’exécuter et les identifiants à utiliser pour les connexions SSH sur les machines de l’inventory.

Paramètres d’une template

On peut ensuite exécuter les templates et suivre leurs avancements et résultats dans l’onglet Jobs ou depuis la page de la template.

Dans l’onglet des templates on peut aussi créer des workflows, un workflow permet d’exécuter plusieurs templates à la suite en y ajoutant des conditions.

On peut choisir d’exécuter certaines templates si une autre réussit, et d’autres si elle échoue.

Éditeur des workflows

Ressources et liens utiles pour apprendre Ansible

Cette courte présentation vise à vous faire découvrir Ansible et ne couvre donc que les bases (beaucoup de détails ont été omis pour éviter la surcharge d’informations). Ansible est un outil très complet et il existe de nombreuses ressources pour apprendre à le prendre en main et le maîtriser.

En voici quelques unes pour bien débuter :


Ansible est un outil très puissant aux applications nombreuses, et peut notamment faciliter l’administration des IBM i (surtout à grande échelle). Malheureusement il n’existe à l’heure actuelle aucune solution clé en main, apprendre à utiliser Ansible et créer ses propres playbooks est indispensable.

Cet apprentissage peut prendre du temps sans expérience préalable avec les environnements Unix et/ou Python. Mais si Ansible peut paraître difficile à prendre en main et maîtriser, des solutions plus guidées et faciles d’accès pourraient arriver à l’avenir, permettant à tous d’utiliser Ansible à son plein potentiel sans avoir à le maîtriser chaque aspect.

, , Liste de jobqs utilisées sur votre ibmi

Vous avez sans doute un grand nombre de jobqs sur votre système, mais savez vous réellement celles qui servent ?

Pour connaitre les liste des jobq utilisées, on va consulter les messages CPF11224 qui indiquent le début d’un travail et qui contiennent dans les données la jobq par lequel ils sont arrivés

j’ai utilisé dans mon exemple de table dans qtemp, vous pouvez un un with si vous préférez

Liste des jobqs utilisées

create table qtemp/lstjobqus as(
select distinct
cast(substr(message_tokens, 59, 10) as char(10)) as jobq,
cast(substr(message_tokens, 69, 10) as char(10)) as jobq_lib
FROM TABLE(qsys2.history_log_info(START_TIME => CURRENT TIMESTAMP –
30 days , END_TIME => CURRENT TIMESTAMP)) x
where message_id = ‘CPF1124’ ) with data

Liste des jobqs présentes sur le système

create table qtemp/lstjobq as (
SELECT OBJNAME as jobq, OBJLIB as jobq_lib
FROM TABLE(QSYS2.OBJECT_STATISTICS(‘ALL’, ‘JOBQ’)) ) with data

Liste des jobqs non utilisées

select a.jobq, a.jobq_lib from lstjobq as a exception join
lstjobqus as b on
a.jobq= b.jobq and a.jobq_lib = b.jobq_lib

remarque :

Avec cette liste vous pouvez faire du ménage et ne plus démarrer les sous systèmes inutiles par exemple.

, , , , Utiliser ACS pour produire des fichiers Excel depuis l’IBM i

Access Client Solutions (ACS)

Pour rappel, ACS est le successeur de Client Access et permet toujours les exports de données.

ACS est également un produit entièrement Java, et utilisable en mode ligne de commande.

Il est donc possible de le piloter sur l’IBM i. Pour cela il vous faut :

  • Avoir le produit sous licence 5770JV1 (Java) version 8 ou supérieur
  • Access Client Solutions sur l’IFS (désormais installé via PTF (7.4: SI71900 / 7.3: SI71934 / 7.2: SI71935) dans /QIBM/ProdData/Access/ACS/Base

Exemples

Il est alors possible de provoquer le transfert de données de deux façons :

  • le fichier complet
  • une requête SQL permettant la sélection, transformation, jointure …

Syntaxe :

/PLUGIN=cldownload /system=<system>
                          [/userid=<userid>]
                          {/hostfile=<library/filename> | /sql="statement"}
                          {/clientfile=<path><filename>.<extension> | /display}
                          [/<options>]

    /userid     - user id to use when connecting to the target system
    /hostfile   - Source library and file on the IBM i system for the download
                  e.g. /hostfile=QIWS/QCUSTCDT
    /sql        - specify an SQL statement
                  e.g. /sql="select CUSNUM,LSTNAM,INIT,ZIPCOD from QIWS/QCUSTCDT"
    /clientfile - Target file location for the download.
                  The format of this file will be determined by the specified
                  extension (for example, .csv .ods .xlsx .xlsx)
                  If the file extension is not specified or is of a type
                  not supported, the data will be formatted as a .csv file
    /display    - write the output to the terminal
    
    Valid options are:
       /colheadings=<1/0> - Include column headings as the first row. When specified, the column names will be the heading.
       /usecollabels      - Use column labels for the heading.

Puisque ACS est directement sur votre IBM i, on peut utiliser localhost pour la valeur /system. Cela permet également la portabilité de la commande d’une machine à l’autre.

Pour transférer tout un fichier on utilisera le paramètre /hostfile. Ici sous QSH :

cd /QIBM/ProdData/Access/ACS/Base

java -jar acsbundle.jar
/PLUGIN=cldownload /system=localhost
/hostfile=sqlsample/employee
/clientfile=/home/nb/export/employe.xlsx

Cela produit :

Remarquer le nom de l’onglet.

Pour transférer par une requête SQL :

cd /QIBM/ProdData/Access/ACS/Base

java -jar acsbundle.jar
/PLUGIN=cldownload /system=localhost
/sql="select trim(firstnme) concat ' ' concat trim(lastname), hiredate, current date - hiredate as \"Ancienneté\" from sqlsample.employee" /clientfile=/home/nb/export/employesql.xlsx

Attention à l’échappement des caractères spéciaux …

On obtient :

Des options supplémentaires vous permettent d’affiner la sortie :

  • /colheadings=<1/0> – Inclure ou non l’entête
  • /usecollabels – Utiliser les labels au lieu des noms de colonne

Ces fonctions nécessitent une version de ACS > 1.1.8.6 pour fonctionner correctement.

Comment automatiser ?

Il est relativement simple d’intégrer cette commande Java dans un programme CL. Ici en utilisant /clientfile.

Par exemple avec RUNJVA :

Ou par QSH :

Ici on a paramétré plus d’éléments pour avoir une base de programme plus générique.

Avantages ?

Access Client Solutions permet facilement d’automatiser vos conversions depuis l’IBM i, et non depuis un poste client. Cela beaucoup plus naturel l’intégration de ces traitements dans vos chaines, la maitrise des transferts par l’IT et non par les utilisateurs, la maitrise des flux, des versions de produits utilisées etc …

, , Comment administrer vos sessions NODEJS

Rappel

Nodejs est disponible en open source sur l’ibmi
vous pouvez l’installer à partir de l’option de ACS
Outils / Gestion des modules open source

Pour savoir si le produit est installé sur votre machine vous devez taper.
/QOpenSys/pkgs/bin/node -v
Si NODEJS est installé vous aurez la version installée qui s’affiche

Pour lancer une session nodejs, vous devez indiquer l’adresse ip et le port d’écoute
webserver.listen(port, ip)

L’astuce qui va vous simplifier la vie c’est de passer le port en paramètre, ce qui vous permettra de lancer plusieurs sessions du même scripte.

Pour lancer votre session nodejs avec votre scripte vous devez passer la commande suivante :

/QOpenSys/pkgs/bin/node votrescripte.js votreport

Pour réaliser ceci un scripte nodejs recoit un tableau d’argument
0 = node
1 = votre scripte
2 = premier paramètre dans votre cas le port

Pour le récupérer dans votre scripte vous devez indiquer

port = process.argv[2] ;

Vous pouvez lancer autant de scripte que vous le voulez en gérant le port à chaque lancement !

Quand vous soumettez une session nodejs, il lance plusieurs travaux

NODE2999 QSECOFR BATCH ACTIF
QP0ZSPWT QSECOFR BATCHI ACTIF
QZSHSH QSECOFR BATCHI ACTIF

Le plus simple serait donc de tout isoler dans un sous système pour gérer, les sessions, le démarrage et l’arrêt de l’environnement

Nous avons réalisé une console qui permet de gérer tous ces aspects, vous pouvez trouver le source de cette console à l’adresse suivante :

https://github.com/Plberthoin/PLB/tree/master/GNODE

Avec sql service vous pouvez administrer ses sessions

SELECT
* FROM TABLE(QSYS2.ACTIVE_JOB_INFO( JOB_NAME_FILTER => ‘xxx*’,
SUBSYSTEM_LIST_FILTER => ‘yyy’)) X
where job_type = ‘SBS’

xxx racine des travaux soumis

yyy sous système de votre environnement

Ci dessous quelques site web qui peuvent vous aider .

https://www.ibm.com/developerworks/ibmi/library/i-running-node-js-web-app-trs/index.htmlhttps://www.ibm.com/support/pages/node/1127733https://developer.ibm.com/components/ibm-i/articles/i-native-js-app-ibmi-with-nodejs/

Lancer une commande windows à partir de votre ibmi en session 5250

Vous pouvez exécuter une commande windows à partir de votre ibmi en session 5250

Pour cela vous devez d’abord démarrer l’intégrateur, c’est la commande STRPCO

STRCO
monmsg IWS4010 /* si déjà actif */

Ensuite vous demander l’exécution de la commande comme si vous étiez sous CMD, par la commande STRPCCMD

par exemple pour tester le bloc note

STRPCCMD PCCMD(‘%windir%\system32\notepad.exe’)

La commande doit être entre quotes

Conseil :

Préférer l’utilisation de la commande START qui associera automatiquement l’extension avec l’exécutable voulu.

exemple pour un pdf

STRPCCMD PCCMD(‘START votrepdf.pdf’) et non ‘C:\Program Files\PDFCreator\PDFCreator.exe votrepdfs.pdf’

STRPCCMD (‘calc.exe’) pour la calculatrice

Remarque :

Vous reprendrez la main quand vous aurez terminé votre session DOS
Vous ne pouvez pas intercepter de message d’erreur sur la commande STRPCCMD
La limitation de chaine de caractères est de 1023 de puis la V7R2, avant vous étiez limité à 123.
Vous pouvez monter des partages, avec netserver c’est la commande dos net use, vous pouvez aussi demander à exécuter des fonctions ACS transfert de fichier par exemple
Le paramètre PAUSE(*YES ou *NO) vous affichera une fenêtre dos par exemple sur un .bat , mais ne change rien sur un exécutable windows (calc.exe, notepad.exe)

Comment connaitre les tables ou PF Supprimés ?

Sur L’ibmi on a du mal à matérialiser la base de données

Pourtant en gros, elle a un catalogue c’est les fichiers QADB de QSYS…

Les fichiers SYS* de QSYS2 pointent dessus

On peut les voir par exemple

SELECT *
FROM SYSTABLESTAT where
TABLE_SCHEMA = ‘QSYS’ and TABLE_NAME
like(‘QADB%’)

Ses fichiers sont journalisés sur des journaux qui sont dans QRECOVERY

Les 2 principaux sont :

QDBJRNCOLM qui va contenir les modifications de zones
QDBJRNFILE qui va contenir les modifications de fichiers

Voici comment analyser pour connaitre les fichiers PF ou tables supprimés dans la journée.

Vous devez générer un table à partir de votre journal

DSPJRN JRN(QRECOVERY/QDBJRNFILE)
FROMTIME(votre_date 000001)
OUTPUT(*OUTFILE)
OUTFILE(QTEMP/LISTE1)

Vous devez effectuer cette requête sur le fichier que vous avez généré

SELECT JODATE, JOTIME, substr(joesd, 1, 10) as fichier ,
substr(joesd, 11, 10) as biblio ,
substr(joesd, 31, 10) as User ,
substr(joesd, 91, 2) as type ,
joesd
FROM qtemp/liste1
WHERE JOCODE = ‘R’ and JOENTT = ‘DL’
and substr(joesd, 91, 2) = ‘TB’

Conclusion :

On ne peut pas agir sur les fichiers du catalogue, c’est le système qui les gérent, les seules commandes qui permettent d’inter agir sur le catalogue sont

==>RCLDBXREF
==>QSYS/RCLSTG SELECT(*DBXREF)

Par exemple, dans le cas ou vous commencez à avoir des messages sur la base de données , ou un nombre très important d’enregistrements supprimés dans les fichiers du catalogue …

, , Comment suivre l’évolution des pools mémoire ?

Rappel


Les pools partagés sont des espaces mémoire dans lequel les sous systèmes place des travaux.
*MACHINE Utilisé par les fonctions internes du pool machine
liste des pools
*BASE Pool système par défaut
*INTERACT Travail interactif
*SPOOL Impression
*SHRPOOL1 à *SHRPOOL60 pools spécifiques
et sur ces pools il y a 2 valeurs importantes à ajuster, la taille et le niveau d’activité.

Ajustement

Il existe une valeur système pour ajuster automatiquement ces pools
La valeur systéme QPFRADJ à 2 ou à 3 permet de mettre en place cette ajustement automatique la différence étant un ajustementant à l’IPL avec la valeur 2.
Ce mécanisme fonctionne très bien …
l’ajustement par défaut est fait toutes les 60 secondes ce qui la plupart temps convient bien.
Si vous voulez ajuster ce temps vous pouvez créer une dtaara :
CRTDTAARA DTAARA(QUSRSYS/QPFRADJWT) TYPE(*DEC) LEN(3 0) VALUE(60) vous pouvez indiquer une valeur en seconde de 20 à 120.

Mais on a aucune visibilité sur l’ajustement sur une période données , exemple mon pool de base une journée.

Voici comment on peut faire :


il faut créer un récepteur de journal, il peut être dans une bibliothèque privée, et vous pouvez choisir son nom
CRTJRNRCV JRNRCV(QUSRSYS/QPFRADJ)
il faut créer le journal QPFRADJ qui pointe sur votre récepteur
CRTJRN JRN(QSYS/QPFRADJ) JRNRCV(QUSRSYS/QPFRADJ)
Il vous faut un fichier pour faire votre analyse le fichier qui contient la structure est QAWCTPJE
CRTDUPOBJ OBJ(QAWCTPJE) FROMLIB(QSYS) OBJTYPE(FILE) TOLIB(votrebib) NEWOBJ(QPFRADJ) récupérer les informations du journal DSPJRN JRN(QSYS/QPFRADJ) ENTTYP(TP) OUTPUT(OUTFILE) OUTFILE(votrebib/votrefic)
Créer un fichier à exporter.
create table qtemp/analyse as(
SELECT TPTIME as heure , TPCSIZ as taille
FROM votrebib/votrefic WHERE
TPPNAM = ‘*BASE ‘ and tpdate = ‘070320’
) with data
dans notre cas le pool de base, le 7 mars 2020
vous devez ensuite exporter ce fichier pour faire un diagramme, par exemple sous excel .

Remarque :

il ne faut pas utiliser des pools privés qui ne seront pas ajuster.
Vous devez faire le ménage sur les récepteurs de journaux que vous créer.
Et règle fondamentale, si on fait de l’ajustement, on fait une mesure avant et une mesure après sur des périodes significatives

Sauvegarde et Restauration des webservers

Pour Sauvegarder et Restaurer un server de webservices vous pouvez utiliser les scriptes QSH prévus à cet effet.

Sauvegarde

saveWebServicesServer.sh
-server ‘server’
-saveFile ‘savf’ (‘/qsys.lib/libsavf.lib/savf.file’)

Restauration

restoreWebServicesServer.sh
-fromServerDirectory ‘server-directory’ (‘/www/server’)
-saveFile ‘savf’ (‘/qsys.lib/libsavf.lib/savf.file’)

Remarque :

Le seul support est le SAVF

Mais comment restaurer un serveur de webservices, si vous n’avez que les répertoires de l’IFS.

Il faut savoir qu’un webserveur de webservices c’est 3 choses :

– des répertoires de configuration (dans /www/)
– une instance APACHE déclarée dans http server (fichier QATMHINSTC qui contient un membre pour chacun instance)
– un enregistrement dans LWI ou Liberty.

Il vous faudra donc respecter les étapes suivantes

1) Restauration des répertoires de L’IFS

  • RST DEV(‘/qsys.lib/qgpl.lib/savfIFS.file’)
    OBJ((‘/www/YOURSERVER’))
    Vous pouvez restaurer l’IFS à partir d’autres supports…

2) Autorisation de la branche du server au profil QTMHHTTP

Le profil QTMHHTTP est le profil utilisé par http server pour la plupart de ses opérations. Il doit avoir un droit explicite sur ces fichiers.

  • CHGAUT OBJ(‘/www/YOURSERVER/*’)
    USER(QTMHHTTP)
    DTAAUT(*RWX)
    OBJAUT(*ALL)
    SUBTREE(*ALL)

Remarque :

Cette étape peut être facultative si vous avez une sauvegarde avec les droits privées paramètres PVTAUT(*YES) de vos commandes SAVXXX.

Il vous faudra préciser dans la commande RST … le paramètre PVTAUT(*YES)

3) Création du membre de l’instance APACHE dans le fichier QATMHINSTC de QUSRSYS.

En utilisant la commande

wrkmbrpdm qusrsys/QATMHINSTC

Dupliquer un membre existant en lui donnant le nom de votre server YOURSERVER
puis modifier le contenu en lui indiquant le nom de votre serveur
-apache -d /www/YOURSERVER -f conf/httpd.conf

Cette modification peut-être faite, via l’option 18, par SQL, par script…

 

4) Enregistrement de votre serveur dans liberty ou LWI

Sous LWI

java -cp /QIBM/ProdData/OS400/jt400/lib/jt400Native.jar:/QIBM/ProdData/OS/OSGi/LWI81/native/iasadmin.jar com.ibm.lwi.admin.IntegratedServerAdmin -registerServer YOURSERVER /www

Remarque :
La version de votre lwi ici 8.1, dépend de votre système pour la connaitre :
Se mettre sous qsh
cd /QIBM/ProdData/OS/OSGi
puis ls
o


par exemple ici la version est 6.0
donc la commande devient
java -cp /QIBM/ProdData/OS400/jt400/lib/jt400Native.jar:/QIBM/ProdData/OS/OSGi/LWI60/native/iasadmin.jar com.ibm.lwi.admin.IntegratedServerAdmin -registerServer YOURSERVER /www

Sous Liberty

java -cp /QIBM/ProdData/OS400/jt400/lib/jt400Native.jar:/QIBM/ProdData/OS/OSGi/shared/lib/iasadmin.jar com.ibm.lwi.admin.IntegratedServerAdmin -registerServer YOURSERVER /www

Vous avez un fichier de propriétés, il est dans le répertoire LWI correspondant :

Votre serveur est opérationnel et vous pouvez l’utiliser à nouveau.

Les fichiers de référence des serveurs enregistrés se trouvent :
En 6.1, dans /QIBM/UserData/OS/OSGi/registry/registry.data pour Lwi

À partir de la 7.1,  dans /QIBM/UserData/OS/OSGi/registry/iasregistry.data pour Liberty

Vous pouvez désormais arrêter et redémarrer votre serveur.
ENDTCPSVR *HTTP HTTPSVR(YOURSERVER)
STRTCPSVR *HTTP HTTPSVR(YOURSERVER)

Exemple de requêtes SQL pour retrouver des informations

Liste des instances apaches démarrées

SELECT DISTINCT SERVER_TYPE
FROM TABLE(QSYS2.ACTIVE_JOB_INFO(
SUBSYSTEM_LIST_FILTER => ‘QHTTPSVR’)) X_table

WHERE function = ‘QZSRHTTP’

Liste des instances HTTP déclarées

SELECT TABLE_PARTITION as MEMBER FROM SYSPARTITIONSTAT
WHERE TABLE_NAME = ‘QATMHINSTC’ AND TABLE_SCHEMA = ‘QUSRSYS’

Remarque :

Admin n’a pas d’instance dans ce fichier

La jonction entre les tables pour voir celles qui ne sont pas démarrées

SELECT DISTINCT SERVER_TYPE, TABLE_PARTITION
FROM SYSPARTITIONSTAT a
Join TABLE(QSYS2.ACTIVE_JOB_INFO(
SUBSYSTEM_LIST_FILTER => ‘QHTTPSVR’)) B
on B.server_type = ‘QIBM_HTTP_’ concat TABLE_PARTITION
and TABLE_NAME = ‘QATMHINSTC’
AND TABLE_SCHEMA = ‘QUSRSYS’
where function = ‘QZSRHTTP’