Servidor de actualización Linux

Obtención del script

Para obtener los archivos necesarios en el servidor de actualización, proporcionamos un script Bash. Puede descargarlo en su navegador o desde una terminal:

curl

curl -O https://repos.passwork.pro/repository/linux/scripts/get_desktops.sh

wget

wget -O get_desktops.sh https://repos.passwork.pro/repository/linux/scripts/get_desktops.sh

Ventajas

• Descarga solo la versión requerida de nuestro repositorio — la que coincide con su backend. El repositorio remoto se utiliza como fuente de archivos, no de versión: aloja todas las versiones de la aplicación de escritorio. Qué XXYY descargar lo determina el script desde la API o un archivo local.
• Admite proxy (HTTP_PROXY / HTTPS_PROXY), importante en redes aisladas que acceden a internet mediante proxy.
• Puede ejecutarse según una programación (cron / Task Scheduler) para que el servidor de actualización se mantenga sincronizado con su backend.

De dónde proviene la versión (qué XXYY descargar):

1. API del backend — si se define PASSWORK_DOMAIN, el script solicita la versión de escritorio disponible mediante la API de su servidor Passwork y descarga el XXYY correspondiente.
2. Archivo local — el archivo LOCAL_VERSIONS_FILE contiene una línea con la versión.

No se utilizan otras fuentes de versión: el repositorio de archivos se usa solo para descargar, no para determinar la versión.

Cada ejecución descarga una versión XXYY. Si el backend cambia a una versión nueva — en la siguiente ejecución el script obtendrá el nuevo XXYY (desde la API o el archivo actualizado) y descargará los archivos de actualización.

Variables

Variable	Descripción
REPO_BASE_URL	URL del repositorio con los instaladores de escritorio (fuente de archivos).
OUTPUT_DIR	Directorio para los archivos guardados (raíz del servidor de actualización o una copia).
PASSWORK_DOMAIN	URL del backend para solicitar la versión vía API (recomendado si es accesible).
LOCAL_VERSIONS_FILE	Ruta al archivo de versiones cuando no se usa la API.
HTTP_PROXY	Proxy para peticiones salientes (ej. http://proxy:3128).
LOG_FILE	Ruta al archivo de registro (opcional).
STATUS_FILE	Ruta al archivo de estado para supervisión (opcional, véase «Supervisión»).
KEEP_RELEASES	Cuántos directorios XXYY antiguos mantener en OUTPUT_DIR (por defecto 2).
LOCK_FILE	Archivo de bloqueo para evitar ejecuciones simultáneas (cron); cadena vacía para desactivar.

Ejecución en modo prueba

shell

./get_desktops.sh --dry-run

Ejecución

shell

# Una vez o vía cron
export PASSWORK_DOMAIN="https://your-backend.example.com"
export OUTPUT_DIR="/var/www/updates"
export HTTP_PROXY="http://proxy.example.com:3128"   # si es necesario
./get_desktops.sh

El script comprueba el espacio en disco, crea un bloqueo si es necesario para evitar que dos instancias se ejecuten a la vez (p. ej. desde cron), compara los manifiestos con los archivos ya descargados y solo descarga cuando algo ha cambiado.

Supervisión

Para comprobar que la sincronización se ejecutó y el contenido está actualizado:

1. Código de salida del script

   • 0 — éxito; no se requiere actualización o actualización completada, o --dry-run.
   • 1 — error (red, repositorio, espacio en disco, etc.).
     Los sistemas de supervisión (cron + script de comprobación, Zabbix, Prometheus, etc.) pueden usar el código de salida del script.

2. Archivo de estado (STATUS_FILE)
   Si se define STATUS_FILE, el script sobrescribe este archivo tras cada ejecución con líneas en formato key=value:

   • status — ok o error;
   • version — versión XXYY actual (o vacío si error antes de determinar la versión);
   • timestamp — hora en UTC (ISO);
   • message — mensaje breve (ej. «Update complete for version 0002» o «All latest YAML unchanged»).

   Contenido de ejemplo tras una ejecución correcta:

shell

status=ok
version=0002
timestamp=2025-02-17T12:00:00Z
message=Update complete for version 0002

En caso de error (incluido antes de determinar la versión), el script escribe status=error y opcionalmente message=exit N. Para supervisión: leer STATUS_FILE, comprobar que status=ok y opcionalmente la vigencia vía timestamp o la existencia de OUTPUT_DIR/<version>/latest.yml.

3. Registro (LOG_FILE)
   Si se define LOG_FILE, todos los mensajes del script se escriben ahí. Puede buscar en el registro errores o líneas como «Update complete» / «Repository unreachable».

Ejemplo de comprobación para supervisión (Bash):

shell

STATUS_FILE="/var/www/updates/.sync_status"
export STATUS_FILE
./get_desktops.sh

# Comprobar tras la ejecución (o desde otro script programado):
grep -q '^status=ok$' "$STATUS_FILE" && echo "Sync OK" || echo "Sync FAIL"

# o por vigencia (ej. no más de 25 horas):
ts=$(grep '^timestamp=' "$STATUS_FILE" | cut -d= -f2)