--- title: Editar, comprobar y trasladar los ajustes url: https://doc2.pstreamer.tv/es/manual/extras/config_editing.html lang: es product: Perfect Streamer version: 2.0.1.264 --- # Editar, comprobar y trasladar los ajustes El procedimiento para editar `pss.json` a mano, para trasladar los ajustes a otra versión de Perfect Streamer y para reutilizarlos en otro nodo. Lea antes [El archivo de configuración pss.json](config_file.md#extras-config-file), al menos las secciones sobre la [escasez del archivo](config_file.md#extras-config-file-sparse), sobre la [lectura del archivo](config_file.md#extras-config-file-reading) y sobre las [reglas invisibles](config_file.md#extras-config-file-hidden). Aquí está escrito qué hacer; allí, por qué, y las razones no son evidentes. En resumen: el archivo guarda solo las diferencias respecto a los valores por defecto, el servicio ignora una clave desconocida sin detenerse, y un solo valor inaceptable descarta todo el archivo. Editar el archivo cambia el **siguiente** arranque. Para cambiar un servicio en funcionamiento, utilice la interfaz web o la API HTTP ([Gestión mediante la API HTTP](api.md#extras-api)). ## Qué hará falta ### El esquema Con la documentación se suministran dos archivos: el esquema estricto `pss.schema.json` y el permisivo `pss.compat.schema.json`. En qué se diferencian y qué comprueba cada uno está en [Dos archivos de esquema](config_file.md#extras-config-file-schema-files); allí mismo se dice por qué una comprobación permisiva por sí sola no basta. Los esquemas son parte de la documentación, no del producto. En el nodo no están, y en el directorio de ajustes no existe copia alguna: buscarla allí no tiene sentido. Ambos están en el sitio de la documentación, en el directorio de su versión: ``` https://doc2.pstreamer.tv/schema/ ``` Tome el esquema de **su** versión y guárdelo en la máquina donde edita el archivo. Compruebe la línea de versión dentro del esquema antes de fiarse de él. Una comprobación con el esquema de otra entrega da respuestas seguras y equivocadas. ### El validador Sirve cualquier validador de JSON Schema con soporte del draft 2020-12. El esquema usa construcciones condicionales, así que un validador limitado a ediciones anteriores aceptará un archivo que debería haber rechazado; conviene comprobarlo al elegir otra herramienta. El recomendado es `jv`, un programa independiente de código abierto bajo licencia Apache 2.0; las compilaciones se publican en la [página de versiones del proyecto jsonschema](https://github.com/santhosh-tekuri/jsonschema/releases). Tome el archivo comprimido para su plataforma, descomprímalo y ponga el programa en un directorio que ya esté en `PATH`: ```sh $ tar xzf jv-v-linux-amd64.tar.gz $ sudo install -m 0755 jv /usr/local/bin/jv $ jv --version ``` Se publican compilaciones para Linux, Windows y macOS. > **Nota** > > La compilación para Linux exige un conjunto de bibliotecas del sistema bastante reciente: funciona en RHEL, AlmaLinux y Rocky 9, Debian 12, Ubuntu 22.04 y posteriores, y en una distribución más antigua no arranca en absoluto. No es un obstáculo: compruebe el archivo en una estación de trabajo y lleve al nodo uno ya comprobado. Además, así es más correcto: el archivo es pequeño y en el nodo no hace falta un validador. ### Una herramienta para las comprobaciones que el esquema no hace Dos reglas no son expresables en JSON Schema en absoluto: la unicidad de los identificadores y la igualdad de longitud de las matrices emparejadas. Los comandos de Las comprobaciones que el esquema no hace usan `jq`, que está en el repositorio de cualquier distribución: En RHEL, AlmaLinux y Rocky: ```sh $ sudo dnf install jq ``` En Debian y Ubuntu: ```sh $ sudo apt install jq ``` ## Cambiar un parámetro Realice la secuencia entera. Los pasos que suelen omitirse son el 5 y el 7, y son precisamente los que atrapan los errores silenciosos. 1. **Detenga el servicio.** ```sh $ sudo systemctl stop pss ``` El archivo de un nodo en funcionamiento no se debe editar: el servicio sobrescribe `pss.json` según su propio calendario con lo que mantiene en memoria, y la edición desaparecerá sin un solo mensaje. 2. **Guarde una copia**, con un nombre que todavía no exista. ```sh $ cp pss.json pss.json.$(date +%Y%m%d_%H%M%S) ``` Es el único camino de vuelta: el servicio no mantiene una copia de seguridad automática de la configuración en uso. No use dos veces el mismo nombre de copia: en una segunda pasada por esta secuencia sobrescribiría el único archivo sano con lo que dejó un intento fallido. 3. **Edite.** Cambie los valores en su sitio. No mueva las claves ni mueva las entradas de las matrices; el porqué, en [El orden de las claves dentro de un objeto importa](config_file.md#extras-config-file-order) y [El orden de las entradas en una matriz no se conserva](config_file.md#extras-config-file-entry-order). Al añadir una entrada a una matriz, dele un `id` explícito y único: nadie se lo asignará por usted ([Los identificadores se ponen a mano](config_file.md#extras-config-file-ids)). Dele también a la entrada sus claves de anclaje: `stream-name` en un flujo, `type` y la dirección en una entrada y una salida, `name` en una tarjeta y un almacén, y así sucesivamente ([Estructura del documento](config_file.md#extras-config-file-structure)); sin ellas el archivo se rechazará entero. 4. **Elimine sus comentarios.** La lectura admite solo los de bloque `/* ... */`, las herramientas JSON estrictas no admiten ni esos, y el servicio borrará los comentarios de todos modos en el primer guardado ([Los comentarios se leen pero no se conservan](config_file.md#extras-config-file-comments)). 5. **Compruebe el archivo con el esquema.** ```sh $ jv pss.schema.json pss.json ``` Un código de retorno cero significa que la comprobación se ha superado. En caso contrario se imprime una línea por cada error, y cada una nombra el lugar exacto: ``` jsonschema validation failed with 'pss.schema.json#' - at '/stream/3/input/1/passphrase': false schema ``` Se lee así: la segunda entrada del cuarto flujo tiene una clave `passphrase` que no pertenece al transporte elegido por su clave `type`. Las posiciones se cuentan desde cero. 6. **Realice las comprobaciones de la sección** Las comprobaciones que el esquema no hace. 7. **Inicie el servicio y lea el registro.** ```sh $ sudo systemctl start pss $ grep -iE 'ignore|clamped|config' /var/log/pss/main.log ``` El servicio escribe el registro en un archivo; el directorio lo fija la clave `log-dir` de `pss.properties`, por defecto `/var/log/pss`. Esas líneas no estarán en `journalctl -u pss` mientras en `pss.properties` no se active `log-to-console` o `log-to-syslog`. Una línea sobre una clave ignorada significa que el esquema no coincide con la compilación instalada: por lo general es más antiguo o más nuevo. Una línea sobre un valor llevado al límite significa que un número salió del rango y se corrigió en silencio, y que el archivo ya se ha vuelto a guardar con el valor corregido. Si el servicio no ha arrancado, mire en el directorio `bad/`: Recuperación tras un archivo rechazado. 8. **Compruebe el resultado a través de la interfaz, no por el archivo.** El archivo no muestra los ajustes que se han quedado en su valor por defecto, así que por él no se puede confirmar nada. Lea la configuración de vuelta por la API HTTP: allí se devuelven todas las claves. ## Trasladar los ajustes a otra versión En el archivo no hay marca de versión, y el servicio no realiza conversión alguna. Una configuración de otra entrega se aplica tal cual: las claves que ya no existen se ignoran; las claves que aún no existían toman sus valores por defecto. De ninguna de las dos cosas se informa. El procedimiento de abajo hace visibles ambas. 1. Tome `pss.schema.json` de la versión **de destino**: la que va a leer el archivo, no la que lo escribió. 2. **Primera pasada, permisiva.** Comprueba tipos, rangos y claves obligatorias, pero tolera las claves a las que la versión de destino ha renunciado: ```sh $ jv pss.compat.schema.json pss.json ``` Todo lo que aquí se informa es un problema de verdad: un valor fuera de rango, una clave que ha cambiado de forma, un identificador ausente. 3. **Segunda pasada, estricta.** Enumera las claves que la versión de destino ya no conoce: ```sh $ jv pss.schema.json pss.json ``` Cada queja nueva respecto al segundo paso es una clave que la nueva versión ignorará en silencio. Decida en cada caso si el ajuste se ha renombrado, se ha sustituido por otro mecanismo o se ha suprimido, y en cualquier caso elimine la clave del archivo: dejada ahí no cuesta nada en funcionamiento, pero oculta el hecho de que el ajuste ya no hace nada. La pasada estricta responde también de la pertenencia de una clave a una variante, que el esquema permisivo no comprueba; por eso no cabe limitarse a una sola pasada permisiva. 4. **Compare los valores por defecto de las dos versiones.** El archivo guarda solo las diferencias respecto a los valores por defecto, así que un ajuste que nunca ha tocado no está en el archivo; y si su valor por defecto ha cambiado, el comportamiento cambiará junto con la actualización, en silencio. El archivo y el esquema son ciegos a esto por construcción: el esquema de la versión de destino no mostrará ese cambio. Solo se ve en la configuración vigente, porque la API HTTP devuelve todas las claves, incluidas las que se han quedado en su valor por defecto. Léala en el nodo de origen **antes** de la actualización y en un nodo de la versión de destino: las discrepancias en las claves que nunca ha definido son precisamente los valores por defecto que han cambiado. 5. Continúe desde el paso 4 de Cambiar un parámetro. > **Advertencia** > > No traslade `pss.json` hacia atrás, a una versión más antigua. Una clave aparecida después se ignorará, pero un valor que hoy es admisible y antes no lo era se llevará al límite o descartará todo el archivo. ## Trasladar los ajustes a otro nodo La configuración es portable, pero parte de las claves identifican el nodo o abren el acceso a él, y copiarlas sin cambios en el mejor caso confunde y en el peor se convierte en una filtración. 1. **Sustituya todos los secretos.** Su lista es [Valores que no se deben enviar](config_file.md#extras-config-file-secrets). No los deje vacíos: parte de las claves no admiten un valor vacío y descartarán todo el archivo. Ponga una sustitución evidente de longitud verosímil, y fije los valores reales a través de la interfaz web tras el primer arranque. 2. **Cambie los datos identificativos del nodo:** el nombre del nodo debe ser único dentro del dominio, y la nota, el rol y la región describen esta máquina, no aquella de la que se copiaron. 3. **Revise todo lo que nombra una máquina concreta:** direcciones de escucha, nombres de interfaces, rutas de los almacenes, números de tarjetas. Una ruta inexistente y una tarjeta no instalada el esquema no las atrapará. 4. **Revise la sección Meshwork.** Las direcciones, los nombres y los secretos de los pares son matrices emparejadas que se corresponden por posición ([Las matrices emparejadas se corresponden por posición](config_file.md#extras-config-file-parallel)): al eliminar una entrada, elimine la entrada correspondiente de cada matriz. Aquí una diferencia de longitud descarta el archivo entero, así que cotéjelas de antemano: La igualdad de longitud de las matrices emparejadas. 5. **Coteje las licencias de los dos nodos.** Los ajustes de aquello que la licencia de destino no incluye resultarán ser claves desconocidas: la sección saldrá del archivo con una sola advertencia en el registro. Se nota sobre todo en la recepción DVB. 6. Continúe desde el paso 4 de Cambiar un parámetro. ## Las comprobaciones que el esquema no hace ### Identificadores repetidos Dos entradas de una misma matriz con el mismo `id` descartan todo el archivo. La unicidad de una clave entre las entradas de una matriz no es expresable con JSON Schema, así que se comprueba aparte: ```sh $ jq '[paths(type=="array") as $p | {at: ($p|join(".")), duplicated: (getpath($p) | map(select(type=="object") | (.id // 0)) | group_by(.) | map(select(length>1)) | map(.[0]))} | select(.duplicated|length>0)]' pss.json ``` Un resultado vacío es lo que hace falta. Todo lo demás nombra la matriz y los identificadores repetidos en ella. Un `id` ausente el comando lo cuenta como cero: así lo lee el servicio en la matriz `stream`, donde dos entradas sin identificador chocan. En cualquier otra matriz una entrada sin `id` descarta el archivo por sí sola, de modo que un identificador cero fuera de `stream` ya es un hallazgo. ### La igualdad de longitud de las matrices emparejadas Allí donde las matrices se corresponden por posición, el número de entradas en ellas debe coincidir. Para la sección Meshwork: ```sh $ jq '.cluster | {addresses: (.["cluster-node-address"]|length), names: (.["cluster-node-name"]|length), secrets: (.["cluster-node-secret"]|length)}' pss.json ``` Los tres números deben ser iguales. La comprobación aquí no es higiénica: el servicio detecta él mismo una diferencia de longitud y descarta todo el archivo, tanto en los pares Meshwork como en las variables de entorno, en las listas «antes — después» de la reasignación de PID (`mpegts-pid-old` y `mpegts-pid-new`), en las listas de cambio de idioma (`mpegts-lang-set-pid` y `mpegts-lang-set`) y en la pareja `biss-pnr` y `biss-key`. En el cuarteto de direcciones RIST (`rist-addr-*`) el archivo no se descarta, pero la entrada no se abre y el motivo va al registro. ### El orden de las claves El esquema no ve el orden de las claves, y este importa en tres sitios: [El orden de las claves dentro de un objeto importa](config_file.md#extras-config-file-order). No hay comando para esto: la regla consiste en no mover nada y, en una entrada nueva añadida a mano, poner `type`, `mpts` y `mode` los primeros. ### Referencias entre secciones Los números que apuntan a otra parte del archivo —un almacén, una fuente de la guía de programas, una tarjeta de recepción, un flujo de origen— no los comprueba el esquema. Si el destino no existe, el servicio lo comunicará al arrancar. ## Recuperación tras un archivo rechazado Si `pss.json` no se ha podido leer, el servicio lo **traslada** al directorio `bad/` con un nombre con fecha y hora y arranca con la configuración restaurada anteriormente o, en su ausencia, con los ajustes por defecto (`pss_default.json`, [Comportamiento en el arranque y ante errores de configuración](../install/files.md#startup-config-errors)). Estos no contienen flujo alguno, así que en ese estado el nodo funciona vacío. De que los ajustes no se han podido cargar y de que el nodo funciona con los de reserva informa una alerta al arrancar. 1. **No reinicie el nodo otra vez.** Un reinicio no daña la copia archivada, pero la configuración en funcionamiento ahora mismo son los ajustes por defecto, y no hay motivo para dejar que se guarden encima de nada. 2. **Busque el archivo archivado en el directorio** `bad/`. El más reciente es su configuración. 3. **Averigüe qué le pasa:** ```sh $ jv pss.schema.json bad/pss_20260809_101500.json ``` El registro del arranque fallido también nombra la clave y el motivo. 4. **Corríjalo, compruebe hasta obtener un resultado limpio, cópielo de vuelta encima de** `pss.json` **y arranque.** Si la copia archivada ha desaparecido o también está dañada, la última esperanza es la copia hecha en el paso 2 de Cambiar un parámetro. Para eso existe ese paso. ## Sugerencias en el editor La mayoría de los editores sugerirán los nombres de las claves, mostrarán los valores admisibles y subrayarán un error sobre la marcha, si se les indica el esquema. Vincule el esquema por nombre de archivo, en los ajustes del propio editor: en los editores que trabajan a través del servidor de lenguaje JSON es la entrada `json.schemas`, que asocia el nombre `pss.json` con el esquema. El esquema se puede indicar tanto con un archivo local como con la dirección de la versión publicada. El archivo local es preferible: funciona sin red y fija la versión de forma rígida, mientras que en una dirección es fácil teclear una versión equivocada. > **Advertencia** > > No añada una clave `$schema` dentro del propio `pss.json`. Parece que funciona: el servicio la acepta como clave desconocida, con una advertencia en el registro, pero en el primer guardado la clave desaparece, porque el documento se construye de nuevo a partir de la memoria. Todo lo que el producto no ha declarado vive en el archivo exactamente hasta el siguiente guardado. ## En resumen - Detenga el servicio antes de editar: el archivo de un nodo en funcionamiento se sobrescribirá desde la memoria. - Guarde una copia: no hay copia de seguridad automática de la configuración en uso. - No mueva las claves ni las entradas de las matrices. - Dé a cada entrada añadida un identificador explícito y único. - Compruebe el archivo con el esquema de la versión que va a leerlo. - Compruebe aparte los identificadores repetidos y las longitudes de las matrices emparejadas. - Lea el registro tras el primer arranque: las claves ignoradas y los valores llevados al límite solo se ven allí. - Confirme el resultado a través de la interfaz, no releyendo el archivo.