Actualización y migración

Riversoft® STCP Gemini Rename se distribuye como paquete RPM (stcpren), en el repositorio Riversoft, y como paquete DEB. Se actualiza con el gestor de paquetes del sistema.

Buenas prácticas

• Lea las notas de la versión de todas las versiones entre la instalada y la de destino. Informan cambios de comportamiento, nuevos parámetros y procedimientos específicos.
• Actualice primero un entorno de homologación y repita las pruebas de los flujos críticos antes de actualizar producción.
• Planifique una ventana de mantenimiento y comunique a los socios cuando las transferencias no estén disponibles.
• Haga un backup de la configuración y de las bases de datos antes de cada actualización.
• Actualice a una versión de destino por vez y mantenga la misma versión en todos los servidores del entorno.
• Registre la versión anterior de cada paquete para poder revertir.

Antes de actualizar

Relevamiento

• Registre la versión instalada:

  stcpren -v

• En Enterprise Linux, verifique las versiones disponibles en el repositorio:

  dnf makecache
  dnf list --showduplicates stcpren

• Identifique los eventos, los comandos externos y los agendamientos que activan Riversoft STCP Gemini Rename durante la ventana de mantenimiento.

• Defina el responsable del cambio y el plan de reversión.

Backup

• Archivo de configuración /usr/local/stcpren/configs/config.json.
• Base de configuración, donde quedan los enrutamientos, según las políticas de backup de la organización. Para una copia rápida de un enrutamiento, use -export.
• En el modo archivo local, los archivos JSON de los enrutamientos.
• Los archivos de número secuencial (.seq) del directorio applLockDir.

Procedimiento de actualización

dnf clean all
dnf makecache
dnf upgrade stcpren

yum clean all
yum makecache
yum update stcpren

apt install ./stcpren-<versión>_amd64.deb

find /usr/local/stcpren -name "*.rpmnew"

stcpren -v
stcpren -db -rules <ENRUTAMIENTO> -scan <directorio-de-origen> -test

Validación después de la actualización

• stcpren -v muestra la versión de destino.
• La prueba de los enrutamientos (-test) muestra las reglas esperadas, sin MSG7003.
• Un enrutamiento activado por evento o por agendamiento procesa los archivos como se espera.
• Los agendamientos suspendidos se reactivaron.

Reversión (rollback)

Si la validación falla y la causa no puede corregirse dentro de la ventana de mantenimiento:

1. Suspenda nuevamente las ejecuciones.

2. Vuelva el paquete a la versión anterior registrada antes de la actualización:

   dnf downgrade stcpren-<versión-anterior>

   También es posible deshacer la transacción con dnf history undo <id>. Con yum, use yum downgrade y yum history undo. En Ubuntu, instale el paquete DEB de la versión anterior.

3. Restaure el archivo de configuración del backup.

4. Repita la validación y reactive los agendamientos.

Migración entre versiones principales

Cuando una versión exija migración, con cambios en parámetros, reglas o comportamiento, el procedimiento específico se publica en las notas de la versión. Siga ese procedimiento en lugar de la actualización simple descrita en esta página.

Conversión de reglas INI

Las reglas de versiones anteriores en formato INI pueden convertirse al formato JSON usado en esta versión:

stcpren -ini /ruta/reglas.ini -rules /usr/local/stcpren/configs/reglas.json

La conversión lee la sección General y la sección FileMatching, en la que las claves Rule0, Rule1 y siguientes indican las secciones con la definición de cada regla. El resultado se registra en los mensajes MSG7039 (éxito) o MSG7038 (falla).

Después de la conversión:

1. Revise el archivo generado. Vea Referencia de reglas.

2. Pruebe con -test sobre archivos de ejemplo:

   stcpren -rules /usr/local/stcpren/configs/reglas.json -scan <directorio-de-prueba> -test

3. Use el archivo en el modo archivo local o registre el enrutamiento en el Riversoft Console Portal para el modo base de datos.