Zusammenfassung

  • RFC 3179 setzte ein schmales Protokoll zwischen die sprachunabhängige Script MIB eines SNMP-Agenten und sprachspezifische Laufzeitsysteme. Antwort 231 konnte einen erreichten Zustand wie laufend, angehalten oder fortgesetzt belegen; sie erklärte das Skript nicht für beendet.
  • Zwischenergebnis, nicht fataler oder fataler Fehler, Ende und aufbewahrte Historie waren verschiedene Belege. Wer sie zu einem einzigen Erfolgsfeld verdichtete, verlor genau die Reihenfolge, die eine unvollständige Automatisierung erklärbar machte.
  • Auch ein ordentliches Ende mit gespeichertem Resultat bewies keine Netzwirkung. Der Aufrufer musste die Ergebnisbytes verstehen, und eine unabhängige Beobachtung musste zeigen, ob das verwaltete Ziel den gewünschten Zustand angenommen hatte.

Die Schnittstelle endete vor der Netzwirkung

RFC 3179 erschien im Oktober 2001 und beschrieb Version 1.1 des Script MIB Extensibility Protocol, kurz SMX. Das Dokument war als Experimental eingestuft und erklärte ausdrücklich, keinen Internetstandard festzulegen. Es belegt daher einen sorgfältigen Entwurf, aber weder die Verbreitung in Produkten noch den Betrieb bei einem bestimmten Netzbetreiber.

Sein Nachbardokument RFC 3165 definierte die Script MIB. Über sie konnte ein SNMP-Manager Skripte verwalten, Argumente übergeben, Instanzen starten, ihre Ausführung steuern und Ergebnisse abholen, ohne die Sprache in die Managementoberfläche einzubauen. SMX löste das darunterliegende Problem: Der Agent musste nicht selbst jede virtuelle Maschine oder jeden Interpreter beherbergen. Java, Tcl oder eine andere Umgebung konnte als separater Prozess mit einem gemeinsamen Protokoll angebunden werden.

Damit entstanden bewusst zwei Wissensbereiche. Der Agent wusste, was ein Manager beantragt und welche MIB-Objekte er anbietet. Das Laufzeitsystem wusste, ob es den Code laden, starten, anhalten, fortsetzen, abbrechen oder seinen Zustand melden konnte. Eine Antwort zwischen beiden war ein Beleg für diese Grenze. Sie war keine automatische Aussage darüber, was das Skript außerhalb der Laufzeit bewirken sollte.

Nach Verbindungsaufbau und hello-Austausch standen Befehle wie start, suspend, resume, abort und status zur Verfügung. Dreistellige Codes trennten erfolgreiche Verarbeitung, Fehler und asynchrone Mitteilungen. Gerade diese knappe Grammatik zwang zur Genauigkeit: Ein Code konnte nur nützlich sein, wenn sein Geltungsbereich nicht nachträglich vergrößert wurde.

231 bestätigte einen Zustand, keine Vollendung

Bei start prüfte das Laufzeitsystem Syntax, Skript und Sicherheitsprofil. Konnte es fortfahren, erzeugte es eine Instanz und antwortete mit 231, nachdem diese den Zustand running erreicht hatte. Solange die Verarbeitung noch lief, wartete die Antwort auf diesen Zustand. Schlug der Start fehl, galten andere Fehlercodes.

Das war mehr als ein Transportbeleg. Der Empfänger hatte den Befehl verstanden und eine laufende Instanz hergestellt. Doch 231 bedeutete nicht, dass die Verwaltungsaufgabe abgeschlossen war. Das Skript konnte lange weiterarbeiten, Teilwerte liefern, einen behebbaren Fehler erfahren, fatal enden oder hängen bleiben. Es konnte auch normal enden, während der Aufrufer die zurückgegebenen Bytes mit der falschen Semantik las.

Bei suspend kam 231 nach dem Übergang in den angehaltenen Zustand oder wenn dieser bereits bestand. Bei resume folgte der Code auf die Rückkehr zu running oder bestätigte den schon bestehenden Zustand. status beschrieb eine Beobachtung. Für abort gab es 232 nach dem Abbruch oder wenn die Instanz bereits abgebrochen war. Jede Antwort schloss eine Steuerungsoperation; keine bescheinigte von selbst deren Zweck außerhalb der Laufzeit.

Heutige Übersichten machen daraus leicht nur eine Ampel. Angenommen, gestartet, laufend, beendet und wirksam erscheinen als Abstufungen desselben Grüns. SMX widerspricht dieser Vereinfachung: Produzent, Befehl und Zustandsübergang eines Belegs waren benennbar. Für eine spätere Behauptung brauchte man ein späteres Ereignis.

Ein Ergebnis konnte vor dem Ende eintreffen

Version 1.1 gab asynchronen Beobachtungen eigene Codes. 532 transportierte ein Zwischenergebnis. 533 transportierte ebenfalls ein Zwischenergebnis und verlangte zusätzlich eine smScriptResult-Benachrichtigung über die Script MIB. Interner Datentransport und Sichtbarkeit an der Managementoberfläche blieben dadurch verwandte, aber getrennte Tatsachen.

Ein Zwischenergebnis beendete nichts. Ein Diagnoseskript konnte eine erste Zählung liefern und danach weiter prüfen. Eine Änderung konnte einen gelungenen Teilschritt melden, bevor der nächste scheiterte. Wer den ersten Wert als Endergebnis behandelte, schnitt den verbleibenden Ausführungszeitraum ab. Wer nachfolgende Stille als Erfolg las, konnte Stillstand, Ende und Beobachtungsverlust nicht auseinanderhalten.

RFC 3165 setzte eine weitere Grenze: Direkte Argumente und das eine direkte Resultat waren OCTET STRING. Format und Bedeutung gehörten dem Aufrufer. Umfangreiche Ausgaben konnten über eine andere MIB bereitgestellt oder per URL referenziert werden. Eine empfangene URL bewies keinen Abruf; ein Abruf bewies keine gültige Interpretation.

Abgeschlossene Instanzen konnten zur späteren Sammlung in einer Historie verbleiben. Das half bei zeitversetzter Arbeit, schuf aber kein ewiges Archiv. Alterungsregeln entfernten Einträge aus einer vollen Tabelle. Ein Beleg hatte damit eine Aufbewahrungsfrist: Zu spätes Abholen konnte die Kenntnis hinterlassen, dass etwas lief, aber nicht mehr das Material, um das Ergebnis zu prüfen.

Fehler war kein Synonym für Ende

536 meldete einen Fehler. 537 meldete einen Fehler und verlangte eine smScriptException-Benachrichtigung. Beide konnten eine fatale oder nicht fatale Bedingung beschreiben. Bei einer nicht fatalen Bedingung lief die Instanz weiter. Bei einer fatalen folgte auf den Fehler eine Endemeldung.

Die Beobachtung zerfiel damit in drei Fragen: Trat ein Fehler auf? Wurde er über die breitere Managementoberfläche gemeldet? Beendete er die Instanz? Ein Protokolleintrag beantwortete nicht alle drei. Eine verlorene Benachrichtigung konnte die Sicht des Empfängers ändern, ohne den tatsächlichen Laufzeitzustand zu verändern. Deshalb war die Ereignisfolge aussagekräftiger als das Wort „Fehler“.

Version 1.1 führte 538 für die Beendigung ein und erklärte die früheren Codes 534 für normales sowie 535 für abnormales Ende für veraltet. Ergebnis und Fehler konnten nun in ihren eigenen Nachrichten erscheinen, gefolgt von einem eindeutigen terminalen Ereignis. So musste ein Schlusscode nicht zugleich Ausgabe, Fehlerklasse und Lebenszyklus ausdrücken.

Auch 538 war kein fachliches Urteil. Es belegte, dass die Laufzeit die Instanz als beendet betrachtete. Ob das Ende brauchbar war, hing von Ergebnis oder Fehler, Argumenten, Codeidentität und Datensemantik ab. Ob das Netz verändert wurde, verlangte eine Beobachtung am Ziel: Konfigurationsrücklesung, Zähler, Erreichbarkeit, Verkehrsverhalten oder eine andere passende Nachbedingung.

Ein Sicherheitsprofil schrieb kein richtiges Programm

Delegierte Ausführung verlagerte Autorität. RFC 3179 ordnete den Startinhaber einem Betriebssystemprofil und einem Laufzeitprofil zu. Das Betriebssystem konnte einen beschränkten Prozess erzeugen; ein sicherer Interpreter oder eine virtuelle Maschine konnte sprachspezifische Grenzen durchsetzen. Das waren wichtige Schutzflächen für aus der Ferne ausgewählten Code.

Sie beantworteten jedoch die Frage nach dem erlaubten Zugriff, nicht die nach der Richtigkeit. Ein stark begrenztes Skript konnte falsch rechnen. Richtiges Skript mit falschen Argumenten konnte das Falsche tun. Ein berechtigter Besitzer konnte die falsche Fassung starten. Eine normal beendete Instanz konnte am Ziel nichts bewirken, weil dieses eine Anfrage ablehnte.

Auch die lokale Ablage war eine Vertrauensgrenze. Nur der SNMP-Agent sollte dort Dateien schreiben können; sonst könnte eine andere Partei Code austauschen und ihn mit besonderen Rechten ausführen lassen. Der Verwaltungsname eines Skripts brauchte daher eine überprüfbare Bindung an die tatsächlich ausgeführten Bytes.

Beim Transport zeigt sich derselbe Gedanke. SMX 1.1 behielt TCP und ergänzte eine bidirektionale Pipe als bevorzugte Zuordnung. Version 1.0 hatte ein gemeinsames Geheimnis über eine Umgebungsvariable des Betriebssystems weitergegeben und damit ein Risiko eröffnet. Die Pipe beseitigte diesen Mechanismus, aber nicht jede Vertrauensfrage. Dateirechte, Prozessidentität, Endpunktbesitz und die vorgelagerte SNMP-Zugriffsentscheidung mussten weiterhin zusammenpassen.

Die späteren Dokumente zur SNMPv3-Architektur, zur benutzerbasierten Sicherheit und zur sichtbasierten Zugriffskontrolle geben Kontext. Sie beweisen nicht, dass eine konkrete SMX-Verbindung diese Verfahren nutzte, dass ihr Aufrufer den Start ausführen durfte oder dass die nachgelagerte Aktion innerhalb des erlaubten Bereichs blieb. Transportschutz, Startrecht und Ergebnis sind getrennte Ebenen.

Ein belastbares Journal brauchte mehrere Erfolge

Ein prüfbarer Vorgang beginnt vor 231. Er nennt unveränderliche Skriptbytes oder Version, Besitzer, Argumente, Ziel, angeforderte Profile und Startzeit. Er speichert Instanzkennung und die Antwort, die running belegte. Sämtliche 532/533-Ergebnisse, 536/537-Fehler mit Fatalität und das 538-Ereignis bleiben geordnet erhalten. Danach wird der Historieneintrag mit dem tatsächlich abgeholten Resultat verbunden.

Erst dann folgt die Deutung. Der Aufrufer erklärt, welches Format der OCTET STRING hatte und welche Schema- und Skriptfassung diese Deutung tragen. Bei einer URL trennt das Journal die Referenz vom Abruf und den Abruf von der gültigen Auswertung. Bei einer erwarteten Benachrichtigung trennt es Erzeugung von Zustellung.

Schließlich kommt die Netznachbedingung. Eine Konfigurationsänderung erfordert Rücklesung von der maßgeblichen Oberfläche und gegebenenfalls eine Prüfung des Betriebszustands. Eine Diagnose braucht Zeitfenster und Bezugsgröße. Ein Eingriff in Verkehr braucht spätere Zähler oder Paketbeobachtung. Kein früher Befehlsbeleg darf diese Felder nachträglich ausfüllen.

Die historische Stärke des RFC 3179 ist seine Choreografie. Er versprach keine unfehlbare Automatisierung, sondern verteilte Anfrage, Laufzeitzustand, Teilausgabe, Fehler und Ende auf unterschiedliche Belege. An der Laufzeitgrenze hörte er auf und überließ die Bedeutung dem Aufrufer. Rechenschaft entsteht, wenn jeder Beleg genau eine Transition trägt und nicht zu einer Wirkung befördert wird, die er nie beobachtet hat.

Quellen und Grenzen

Protokoll, Status, Verfahren, asynchrone Antworten, Transport und Sicherheitsüberlegungen stehen im Text von RFC 3179, im Datensatz des RFC Editor, in der HTML-Fassung, in der IETF-Historie und in der Errata-Abfrage. Das angrenzende Script-MIB-Modell, Ergebnissemantik und Ausführungshistorie stammen aus dem Text von RFC 3165, seinem Datensatz und der HTML-Fassung. Für den Versionsvergleich dienen der abgelöste Text von RFC 2593 und dessen Datensatz.

Späteren Kontext liefern die SNMP-Architektur, das benutzerbasierte Sicherheitsmodell und das sichtbasierte Zugriffskontrollmodell. Die analytische Trennung von Befehl, Zustand, Beleg und Wirkung ist von Lu Hengs Essays über den Vorrang laufenden Codes, Realitätsebenen und minimale Anfangsspezifikation geprägt. Die sechzehn Quellen wurden am 2. Oktober 2026 nach Schanghai-Zeit eingefroren.

Diese Unterlagen belegen Entwurf und Status, nicht Einführung oder Erfolg. Sie nennen keine heutige Implementierung, keinen Betreiber, kein Gerät, Skript, Profil, Ereignis, keine Fehlerquote, Arbeitsersparnis, Netzänderung oder Dienstwirkung. Die Codes werden nur in ihren spezifizierten Übergängen gelesen. Die Belegkettenanalyse ist Sofia Rens redaktionelle Auslegung, keine Aussage der RFC-Autoren oder der genannten Institutionen.