Résumé

  • La RFC 3179 reliait l’agent SNMP, qui exposait la Script MIB, à des moteurs propres à chaque langage. Une réponse 231 pouvait confirmer l’état running, suspended ou repris ; elle ne disait pas que le travail était terminé.
  • Les résultats intermédiaires, les erreurs fatales ou non fatales et la terminaison possédaient des messages distincts. Les réduire à une seule couleur supprimait l’ordre nécessaire pour expliquer une automatisation incomplète.
  • Même une terminaison propre et un résultat conservé restaient en deçà de l’effet final. L’invocateur devait comprendre les octets, puis une observation indépendante devait établir ce qui avait réellement changé sur le réseau.

Le moteur n’était pas l’objet administré

La RFC 3179 fut publiée en octobre 2001 avec le statut Experimental. Elle décrivait la version 1.1 du Script MIB Extensibility Protocol, SMX, et précisait qu’elle ne constituait pas une norme Internet. Le texte pouvait donc spécifier un mécanisme exact sans démontrer son déploiement, son adoption ni son efficacité dans un réseau nommé.

Son point de départ était la RFC 3165. La Script MIB fournissait à un gestionnaire SNMP une interface indépendante du langage pour connaître des scripts, transmettre des arguments, lancer plusieurs instances, agir sur leur exécution et récupérer leurs résultats. Il aurait toutefois été coûteux de placer chaque interpréteur dans l’agent. SMX séparait l’implémentation de la MIB des moteurs Java, Tcl ou autres.

Cette architecture ne créait pas seulement deux processus. Elle créait deux autorités d’observation. L’agent savait quelle opération le gestionnaire avait demandée et quel objet de la MIB devait évoluer. Le moteur savait s’il pouvait charger le code, appliquer le profil choisi et faire passer une instance à un état d’exécution. Le message échangé entre les deux prouvait ce franchissement précis. Il n’observait ni le sens métier du résultat ni l’état ultérieur de l’équipement administré.

Après l’établissement de la connexion et l’échange hello, SMX proposait notamment start, suspend, resume, abort et status. Les réponses à trois chiffres avaient une grammaire compacte. Cette brièveté n’autorisait pas à leur donner un sens plus large : le code identifiait une transition du protocole, non une promesse générale de réussite.

Le code 231 fermait une transition

Pour start, le moteur devait vérifier la syntaxe, identifier le script et le profil de sécurité, puis créer l’instance. La réponse 231 n’était envoyée qu’après l’arrivée à l’état running. Si le lancement échouait, une réponse d’erreur remplaçait cet acquittement.

Le 231 était donc plus solide qu’un simple accusé de réception du transport. Le moteur avait compris la commande et une instance existait. Mais cette preuve restait temporellement précoce. Le script pouvait ensuite calculer, attendre, se bloquer, produire plusieurs observations, rencontrer une erreur récupérable ou mourir. Il pouvait aussi finir normalement tout en renvoyant une valeur que l’invocateur interpréterait mal.

Les autres commandes confirmaient la même limite. suspend aboutissait à 231 lorsque l’état suspendu était atteint ou existait déjà. resume aboutissait à 231 lorsque l’instance fonctionnait de nouveau. status décrivait l’état vu par le moteur. abort utilisait 232 après l’arrêt forcé ou lorsque l’instance était déjà abandonnée. Chaque code répondait à une question de contrôle. Aucun ne répondait à la question « l’objectif réseau est-il atteint ? ».

Un tableau de bord moderne peut facilement écraser ces distinctions. L’ordre « demandé, accepté, en cours, fini, effectif » devient une icône verte. La RFC résistait à cette compression en donnant à chaque reçu un producteur et un moment. Pour avancer dans la preuve, il fallait attendre le message suivant au lieu de réinterpréter le précédent.

Un résultat pouvait précéder la fin

Le protocole réservait 532 à un résultat intermédiaire. Le code 533 indiquait en plus que ce résultat devait provoquer une notification smScriptResult à travers la Script MIB. Ainsi, la donnée envoyée sur la connexion moteur-agent et son exposition au gestionnaire n’étaient pas confondues.

Le qualificatif « intermédiaire » était essentiel. Un script de diagnostic pouvait livrer la première partie d’un inventaire avant d’avoir parcouru le reste. Un script de modification pouvait décrire une étape puis échouer à la suivante. Recevoir une valeur ne fermait donc pas l’intervalle d’exécution. L’absence d’un message ultérieur ne transformait pas cette valeur en résultat final.

La RFC 3165 ajoutait une limite sémantique. Les arguments et le résultat direct étaient des OCTET STRING. L’invocateur devait connaître leur format et leur signification. Le protocole pouvait transporter fidèlement des octets sans savoir si ceux-ci exprimaient une mesure, une décision ou une erreur applicative. Pour une sortie volumineuse, le script pouvait même renvoyer une URL : la référence ne prouvait ni téléchargement, ni intégrité, ni lecture correcte du contenu désigné.

La Script MIB conservait un historique des scripts achevés afin qu’un gestionnaire puisse collecter les résultats plus tard. Ce mode différé avait une contrepartie : les tables vieillissaient et pouvaient supprimer des entrées. Il fallait donc distinguer l’exécution passée, la persistance du reçu et la collecte effective. Une politique de rétention trop courte pouvait rendre vraie l’affirmation « le script a fini » tout en rendant impossible l’examen de ce qu’il avait produit.

L’erreur et la terminaison formaient deux événements

SMX 1.1 séparait également l’erreur de la fin. Le code 536 portait une erreur. Le code 537 portait une erreur qui devait aussi déclencher smScriptException. L’erreur pouvait être fatale ou non fatale. Dans le second cas, le script continuait ; dans le premier, un événement de terminaison devait suivre.

Cette structure obligeait l’observateur à conserver trois informations : l’erreur a-t-elle existé, a-t-elle été projetée vers l’interface de gestion, et a-t-elle arrêté l’instance ? Une notification perdue ne changeait pas nécessairement l’état du moteur. Une erreur visible ne signifiait pas nécessairement que le travail était fini. Sans ordre temporel, les mêmes lignes de journal pouvaient raconter des histoires opposées.

La version 1.1 introduisit 538 comme reçu général de terminaison. Elle déclara obsolètes 534, ancienne terminaison normale, et 535, ancienne terminaison anormale. Résultat et erreur pouvaient désormais être exprimés par leurs propres messages, puis suivis d’un événement unique signalant la fin. La modification empêchait un seul adjectif terminal de devoir résumer à la fois la sortie, la cause et l’état final.

Le 538 restait pourtant un reçu du moteur. Il prouvait que l’instance ne s’exécutait plus selon ce moteur. Pour juger le travail, il fallait encore relier l’événement au bon code, aux bons arguments, aux résultats ou erreurs précédents et au schéma employé pour les interpréter. Pour juger l’effet, il fallait lire l’autorité finale : configuration effective, compteurs, trafic, accessibilité ou autre observation propre à la tâche.

Le profil limitait l’autorité sans garantir le raisonnement

La délégation de scripts déplaçait aussi une capacité d’action. La RFC proposait d’associer le propriétaire du lancement à un profil de sécurité du système d’exploitation et à un profil du moteur. Le premier pouvait préparer un environnement de processus restreint ; le second pouvait imposer les limites d’une machine virtuelle ou d’un interpréteur sûr.

Ces contrôles répondaient à « que peut toucher cette exécution ? ». Ils ne validaient pas l’algorithme. Un script bien confiné pouvait compter faux. Un script correct pouvait recevoir la mauvaise cible. Un propriétaire autorisé pouvait lancer une version périmée. Une fin normale pouvait coïncider avec le refus ultérieur de l’équipement destinataire.

Le stockage local constituait un autre point de garde. La RFC exigeait de le protéger de manière que seul l’agent SNMP puisse écrire les fichiers. Sans cette protection, un attaquant pouvait substituer du code et profiter des privilèges du moteur. Le nom administratif du script devait donc rester lié aux octets exécutés ; reconnaître une étiquette ne suffisait pas.

La version 1.1 modifia aussi le transport. Elle conserva TCP mais ajouta le tube bidirectionnel comme méthode préférée, parce que la version 1.0 transmettait un secret partagé dans une variable d’environnement du système d’exploitation. Supprimer ce mode d’exposition réparait un risque déterminé. Cela ne rendait pas automatiquement fiables les permissions, l’identité du processus, le stockage et la décision d’accès SNMP.

Les RFC 3411, 3414 et 3415 donnent un contexte ultérieur sur l’architecture SNMPv3, l’authentification des utilisateurs et le contrôle d’accès par vues. Elles ne prouvent pas qu’une mise en œuvre SMX donnée les employait. Elles ne prouvent pas non plus que l’autorisation d’appeler un objet couvrait chaque effet produit ensuite par le script.

Une preuve utile conservait toute la séquence

Le registre commence avec l’identité immuable du code, son propriétaire, ses arguments, sa cible, le profil demandé et l’heure. Il lie ensuite l’identifiant de l’instance au reçu qui établit running. Il conserve dans l’ordre chaque 532 ou 533, chaque 536 ou 537 avec son caractère fatal ou non, puis le 538. Enfin, il indique si l’entrée d’historique a survécu et si l’invocateur l’a effectivement collectée.

L’interprétation forme une étape suivante. Le consommateur doit nommer le schéma qui donne sens à l’OCTET STRING. Une URL doit être suivie d’un reçu de récupération ; un fichier récupéré doit être lié à son intégrité et à sa lecture. Une notification annoncée doit être distinguée de sa réception par le gestionnaire.

L’effet réseau arrive encore après. Une commande de configuration demande une relecture sur la surface autoritaire, et parfois une seconde observation de l’état en fonctionnement. Un diagnostic demande une fenêtre et un dénominateur. Une modification de trafic demande des compteurs ou des paquets ultérieurs. Le reçu de lancement ne peut pas produire rétroactivement ces preuves.

La valeur historique de la RFC 3179 tient à cette modestie. Le texte ne disait pas que le script rendait l’administration autonome. Il attribuait des messages différents à la commande, à l’état, à la sortie, à l’erreur et à la fin. Le sens du résultat demeurait chez l’invocateur ; la réalité du réseau demeurait au-delà. Une automatisation devient responsable lorsque chaque reçu garde cette portée limitée.

Sources et limites

Le statut, les procédures, les réponses asynchrones, les transports et la sécurité sont établis par le texte de la RFC 3179, sa notice RFC Editor, son édition HTML, son historique IETF et la recherche d’errata. Le modèle voisin, la sémantique des résultats et l’historique d’exécution viennent du texte de la RFC 3165, de sa notice et de son édition HTML. La comparaison avec la version remplacée est bornée par le texte de la RFC 2593 et sa notice.

Le contexte SNMP ultérieur provient de l’architecture SNMP, du modèle de sécurité par utilisateur et du contrôle d’accès par vues. La séparation analytique entre commande, état, preuve et effet s’appuie sur les essais de Lu Heng consacrés à la primauté du code exécuté, aux couches de réalité et à la spécification initiale minimale. Les seize URL ont été gelées le 2 octobre 2026 en Asia/Shanghai.

Ces sources prouvent un dessin protocolaire, pas son adoption. Elles n’établissent aucune implémentation, aucun opérateur, script, appareil, profil, incident, gain de travail, modification réseau ou résultat de service. L’analyse de la chaîne de preuve est une lecture éditoriale de Sofia Ren, non une affirmation des auteurs des RFC ou des institutions citées.