Resumen

  • RFC 3179 situó un protocolo entre la Script MIB del agente SNMP y entornos especializados por lenguaje. El 231 acreditaba que una orden había llegado a running, suspended o al estado reanudado; no acreditaba el final del script.
  • Los mensajes 532/533, 536/537 y 538 separaban resultado provisional, error y terminación. Perder su orden convertía incidentes distintos en un único estado ambiguo.
  • El final del entorno tampoco probaba el resultado operativo. El invocador debía interpretar los octetos, recoger la salida y comparar una condición posterior en el sistema administrado.

La primera frontera estaba entre el agente y el motor

RFC 3179 apareció en octubre de 2001 como documento Experimental. Definía la versión 1.1 de Script MIB Extensibility Protocol y aclaraba que no era un estándar de Internet. La descripción era detallada, pero ese detalle no demuestra adopción, despliegue ni interoperabilidad en una red real.

La Script MIB de RFC 3165 ofrecía a un administrador SNMP una superficie común para almacenar scripts, lanzar instancias, enviar argumentos, controlar la ejecución y recoger resultados. El problema era la diversidad de lenguajes. Integrar cada intérprete dentro del agente habría unido la interfaz de administración con todos los entornos de ejecución. SMX permitió separarlos.

El agente y el entorno quedaron así con conocimientos distintos. El primero veía objetos de la MIB y solicitudes del administrador. El segundo sabía si un código concreto podía ejecutarse bajo un perfil y en qué estado se encontraba su instancia. Una respuesta entre ambos probaba una transición en esa relación. No observaba automáticamente lo que sucedía después en un router, servidor o servicio.

La conversación comenzaba con conexión y hello, y continuaba con órdenes como start, suspend, resume, abort y status. El protocolo asignó códigos breves a respuestas y avisos asíncronos. Esa economía era útil solo si el operador no ampliaba el significado de cada código para llenar las casillas que todavía estaban vacías.

El 231 acreditaba presencia en un estado

Al recibir start, el entorno validaba sintaxis, script y perfil. Si podía crear la instancia, respondía 231 cuando esta llegaba a running. Por tanto, el mensaje no era un mero acuse de transporte: existía una instancia reconocida por el motor.

Pero el trabajo apenas había empezado. El script podía tardar, esperar una dependencia, emitir valores parciales, topar con un error recuperable o finalizar sin lograr el propósito exterior. El 231 no contenía el resultado, no indicaba terminación y no miraba la condición del recurso administrado.

Las operaciones de pausa y continuación reforzaban esa lectura. suspend producía 231 cuando se alcanzaba el estado suspendido o ya se estaba en él. resume lo producía al volver a running. status obtenía el estado observado. abort utilizaba 232 después de abortar o si el script ya estaba abortado. Son recibos de control, no certificados de efecto.

En un registro serio, «orden enviada», «orden aceptada» y «estado alcanzado» deben conservarse por separado. Si una pantalla transforma el primer verde en finalización, los scripts atascados desaparecen de la estadística. Si transforma running en eficacia, elimina todo lo que debía ocurrir después.

La salida tenía su propio reloj

El 532 transportaba un resultado intermedio. El 533 hacía lo mismo y además pedía generar una notificación smScriptResult mediante la Script MIB. La distinción importaba: producir datos dentro del vínculo SMX y exponerlos al plano de administración no eran el mismo evento.

Una salida provisional podía ser correcta y, aun así, no ser la respuesta final. Un inventario podía informar los primeros elementos antes de fallar. Una secuencia de cambios podía completar un paso y no el siguiente. El consumidor debía conservar orden, instante e identidad de la instancia para no promover el primer fragmento recibido a conclusión.

RFC 3165 dejaba la semántica fuera del transporte. Argumentos y resultado directo eran OCTET STRING, y el invocador debía conocer su formato. Para salidas complejas, el script podía publicar objetos por otra MIB. Para datos grandes, podía devolver una URL. En ambos casos aparecía otra cadena: referencia, recuperación, integridad, lectura y uso. Ningún eslabón podía representar a los demás.

El historial de ejecuciones terminadas permitía recoger resultados con retraso. Eso ayudaba cuando el administrador no permanecía conectado, pero introducía caducidad. Las tablas podían envejecer entradas. Que una instancia hubiera terminado no garantizaba que su prueba siguiera disponible cuando llegara el auditor.

Un error podía dejar vivo al script

La versión 1.1 reservó 536 para un error y 537 para un error que también debía originar smScriptException. Ambos podían describir una condición fatal o no fatal. Si no era fatal, la ejecución continuaba. Si lo era, la terminación venía después.

Así, la presencia de un error no respondía por sí sola si el script seguía activo. Tampoco la generación de una notificación probaba que un receptor la hubiera recibido. El diagnóstico exigía mantener tres superficies: el hecho dentro del entorno, su proyección a la MIB y el estado posterior de la instancia.

El 538 fue la pieza terminal añadida por RFC 3179. Sustituyó conceptualmente los antiguos 534 y 535, que separaban terminación normal y anormal. El nuevo diseño permitía que resultados y errores viajaran como hechos propios, seguidos por un único aviso de que la instancia había acabado. La terminación dejaba de cargar por sí sola con la explicación completa.

Incluso entonces faltaba el juicio. Un 538 podía cerrar una ejecución que produjo un resultado inválido. Podía seguir a un error fatal, a un resultado útil o a una salida que nadie recogió. El invocador debía unirlo con código, versión, argumentos y mensajes anteriores. La red debía producir la prueba exterior: lectura de configuración, estado efectivo, contador, tráfico o respuesta del servicio.

La autoridad también necesitaba varios recibos

RFC 3179 vinculaba el propietario del lanzamiento con un perfil del sistema operativo y otro del entorno. El primero limitaba el proceso; el segundo aplicaba restricciones del intérprete o máquina virtual. Esa división ayudaba a contener código delegado.

Contener no es validar. Un script con privilegios mínimos puede ejecutar una lógica incorrecta. Un script correcto puede apuntar a un objeto equivocado. Una identidad autorizada puede escoger una versión antigua. La política de ejecución prueba alcance permitido, no verdad del cálculo ni éxito de la acción remota.

La custodia de archivos era crítica. Solo el agente SNMP debía poder escribir en el almacén local. De otro modo, un atacante podía sustituir el contenido asociado a un nombre conocido y conseguir ejecución bajo privilegios especiales. El control debía enlazar nombre administrativo, bytes reales y momento de carga.

SMX 1.1 añadió un conducto bidireccional como transporte preferido y mantuvo TCP. El cambio respondió al riesgo de versión 1.0, que pasaba un secreto compartido mediante una variable de entorno del sistema operativo. El nuevo transporte eliminó esa exposición concreta; no certificó permisos locales, identidad de proceso ni autorización SNMP.

Las RFC 3411, 3414 y 3415 describen posteriormente arquitectura, seguridad basada en usuarios y acceso por vistas en SNMPv3. Sirven para entender capas de control. No prueban que una implementación SMX las usara ni que una autorización sobre la MIB cubriera todos los efectos posibles de un script.

La prueba completa terminaba fuera de SMX

Un expediente operativo necesita el hash o versión inmutable del script, propietario, argumentos, objetivo, perfil y hora. Después debe registrar la instancia, la llegada a running, cada resultado 532/533, cada error 536/537 con su fatalidad y el 538. También necesita saber cuánto tiempo sobrevivió el historial y quién recogió la salida.

El consumidor añade un recibo de interpretación. Debe declarar el esquema aplicado a los octetos. Si recibió una URL, debe acreditar descarga y objeto recuperado. Si esperaba una notificación, debe distinguir su creación de su llegada.

Por último, la autoridad administrada habla por sí misma. Una automatización de configuración requiere relectura. Una tarea de diagnóstico requiere ventana, universo observado y límites. Una acción sobre tráfico requiere observaciones posteriores. El protocolo del motor no puede fabricar esos hechos porque no los mira.

El valor histórico de RFC 3179 no fue prometer administración mágica. Fue impedir que una sola respuesta fingiera contener toda la historia. La orden, el estado, la salida, el error y el final recibieron mensajes diferentes; el sentido quedó en manos del invocador y el efecto quedó en la red. Esa arquitectura todavía ofrece una regla exigente: un recibo solo debe cerrar la frontera que realmente observó.

Fuentes y límites

El protocolo, su condición Experimental, los procedimientos, avisos, transportes y riesgos se documentan en el texto de RFC 3179, su registro, la edición HTML, el historial IETF y la consulta de erratas. La Script MIB, la interpretación del resultado y el historial proceden del texto de RFC 3165, su registro y su edición HTML. La versión anterior queda acotada por el texto de RFC 2593 y su registro.

El contexto posterior usa la arquitectura SNMP, el modelo de seguridad basado en usuarios y el modelo de acceso por vistas. La separación entre solicitud, estado, evidencia y realidad se apoya en los ensayos de Lu Heng sobre la primacía del código en ejecución, las capas de realidad y la especificación inicial mínima. El conjunto de dieciséis URL se congeló el 2 de octubre de 2026 en Asia/Shanghai.

Las fuentes establecen diseño, no adopción. No prueban implementación, operador, script, equipo, perfil, incidente, ahorro, cambio de red o resultado de servicio. El análisis de la cadena de recibos es lectura editorial de Sofia Ren y no una afirmación atribuida a los autores o instituciones citados.