Ordonnancement.org

Communiquer avec le RCS

Installer OpenSSL

La communication se fait en SSL, la première étape consiste à télécharger OpenSSL pour disposer d’un client.

 Télécharger http://www.openssl.org/

L’installation est triviale et ne nécessite pas d’explication particulière, il n’est nul besoin de générer une clé ou quoi que ce soit pour pouvoir se connecter à l’agent.

Configuration de l’agent

Le RCS limite les connexions aux clients dument référencés dans le fichier validips.

Si vous souhaitez récupérer un fichier sur la machine distante, il faudra ajouter le répertoire dans le fichier valid_dirs.

Tout changement nécessite un arrêt/relance du RCS.

Connexion

Pour vous connecter a un agent host en utilisant le port host, vous devrez lancer la commande suivante :

openssl s_client -host {{host}} -port {{host}}

host	machine avec laquelle vous souhaitez communiquer
port	Port du RCS (par défaut : 4444

Les informations suivantes sont renvoyées :

La réponse de l’agent est la suivante :

Le EOS indique que l’agent est à l’écoute, il ne reste plus qu’à lui fournir les paramètres.

Pinger l’agent

Cette commande est simplement une garantie qu’on est correctement connecté, ce que l’on sait déjà puisque l’agent répond mais cela permet à l’interface Java de valider le bon fonctionnement.

Cette commande est la plus simple :

Envoyer PING puis Entrée

L’agent renvoit :

Stopper la connexion

La communication peut être stoppée à tout moment par la commande SHUTDOWN.

Récupérer un fichier

Récupérer un fichier permet à l’interface d’obtenir la sortie standard ou la sortie d’erreur du traitement ainsi que le log de l’agent (si vous le supprimez pas en cas de SUCCESS de job).

Pour cela, on a besoin de quatre paramètres et de la commande fin :
 L’action : JOBLOG
 L’instance : INS (on prendra l’instance par défait d’Autosys : ACE)
 Le fichier et son répertoire (le répertoire doit obligatoirement être dans le fichier valid_dirs).
 Un timestamp au format posix (nombre de secondes depuis le 1er Janvier 1970) mais on peut mettre n’importe quel nombre
 La commande de fin : OVERANDOUT

Si l’on veut récupérer un fichier toto dans le répertoire %AUTOUSER%\out de l’instance ACE, on tapera les 4 commandes suivantes :

L’agent répond :

FRESH indique que tout va bien, si l’agent est incapable de répondre vous obtiendrez STALE, il faut alors réessayer plus tard.

Le chiffre correspond à l’heure actuelle au format Posix. 26 est la taille du message renvoyé. Le contenu du fichier est compressé au format gzip (sans entête). EOS indique que vous pouvez continuer le dialogue.

La communication est loggé dans le répertoire logfiles de l’agent, le résultat de la communication précédente est le suivant :

On distingue les différents paramètres envoyés à l’agent et la manière dont celui ci résout la variable d’environnement pour retrouver le fichier.

Récupérer le log du demon

Pour récupérer le log du démon il faut dialoguer avec le RCS du serveur.

Les commandes snt un peut différentes :
 L’action devient EPLOG
 On indique toujours l’instance
 On indique ensuite de lignes que l’on veut récupérer
 Puis éventuellement la chaine de caractères que l’on veut trouver
 et enfin l’OVERANDOUT

Le format renvoyé est le même que pour le job log.

Exemple :

L’agent journalise les informaitons suivantes :

Executer le JIL

Le RCS permet aussi d’exécuter un JIL sur l’agent, il est ainsi possible de créer, de modifier ou de supprimer des traitements à partir d’une machine qui ne dispose d’aucun exécutable autosys.

Par contre, il est impératif que les binaires soit sur la partie RCS car il ne fera ni plus ni moins qu’un appel à ces binaires.

Les paramètres doivent permettre de s’authentifier avec un compte :
 L’action est JIL
 On indique l’instance
 Puis un utilisateur *
 Le compte OS
 Le mot de passe correspond qui correspond au compte OS
 La machine ou le domaine
 Le jil (en une seule ligne)
 et enfin l’OVERANDOUT**

* L’utilisateur n’apparait ni dans le champ owner ni dans l’autotrack. ** La commande ’exit’

Exemple :

Les logs Unix sont plus parlants que les logs windows :

Modifier le calendrier

Le RCS peut modifier le calendrier en appelant directement l’autocal_asc, cette fonctionnalité est malheureusement limitée car il n’est pas possible d’afficher les dates et on ne peut pas utiliser les heures.

Pour l’affichage on pourra lister les dates par une requête SQL mais la non prise en compte des heures est plus génante.

Les paramètres seront les suivants :
 l’action : CALENDAR_UPDATE
 l’instance
 le compte OS
 le mot de passe
 le nom du calendrier
 l’offset (décalage par rapport à l’heure locale)
 l’action à effectuer : A (pour ADD) ou D (pour Delete)
 la liste des dates au format Posix (nombre de secondes depuis le 1 Janvier 1970)
 OVERANDOUT pour terminer

Envoyer un évènement

Un évènement peut être envoyé à travers le RCS en exécutant l’utilitaire sendevent.

Les paramètres sont :
 l’action : SENDEVENT
 l’instance
 le compte OS
 le mot de passe
 les arguments du sendevent
 OVERANDOUT pour terminer

Si tout va bien, on obtient un Exit Code = 0, sinon il n’y a aucun message (il faut alors voir le log du RCS).

Exemple :

La réponse est l’exit code de l’exécutable :

Le log permet de voir le fonctionnement :
 un fichier temporaire est créé et sauvegardé dans le tmp du RCS
 la date posix est décalé avec l’offset
 elle est converti avec le format attendu par l’autocal_asc
 le fichier temporaore est envoyé

Exemple :

Log du RCS :

En cas d’erreur, la sortie est directement renvoyée au client :

Le log du RCS sera alors le suivant :

Obtenir l’heure de l’agent

Cette fonctionnalité est très intéressante quand on dispose d’agent sur différents fuseaux horaires.

Les paramètres sont :

 l’action : ASCLOCKTIME
 l’instance
 l’heure au format Posix (utiliser time0 pour les tests
 OVERANDOUT

La réponse est un exit code suivi de l’heure au format de l’autocal_asc.

Exemple :

Vérifier un compte à distance

La vérification permet d’authentifier un compte sur la machine distante, ce compte est utilisé dans

Message d’erreur si le mot de passe ne correspond pas au compte :

Log RCS :

Vérifier un groupe

Un autre exécutable permet de vérifier l’appartenance d’un compte à un groupe.

Si le compte appartient au groupe on n’obtient aucune réponse.

Log RCS :

Par contre, si le compte n’appartient pas au groupe, un false suivi d’un -1 est renvoyé.

Log RCS :

Thèmes
Au coeur du produit Les articles "au coeur du produit" s’intéressent à des points techniques particuliers. Voir aussi...

Le document issu de http://Ordonnancement.org est mis à disposition sous les termes de la licence Creative Commons, vous pouvez l'utilisez dans vos documents à condition de citer l'auteur E. Angenault, vous êtes aussi libre de le modifier. Par contre, vous devez le redistribuer dans les mêmes conditions et la commercialisation ne peut se faire qu'avec l'accord de l'auteur.