Hola.

Comparto la solución a la que llegué para este asunto.Se trata de una solución 'rebuscada' temporal hasta que actualicen el etl.

Resumen del problema:
El etl de carga de datos para SIU Querandies utiliza el comando gpg con  parámetros no compatibles con la última versión de gpg, es decir, este problema surgirá en todos sistemas operativos actualizados.

Nota:
Este problema NO se solucionó actualizando SIU Wichi a la versión 6.4.0

Solución temporal:
Es necesario modificar la forma en la que el etl utiliza el comando gpg. La creación de un alias de comando no funciona debido a que el etc utiliza el binario '/usr/bin/gpg' directamente.
Entonces, primero renombramos el binario gpg de esta manera:

sudo su
cd /usr/bin
mv gpg gpg_original
luego creamos un script bash:

vim gpg

con el siguiente contenido:

#!/bin/bash
/usr/bin/gpg_original --pinentry-mode loopback $@
modificamos los permisos del script:

chmod 755 gpg
exit
De esta forma cuando el etl utilice '/usr/bin/gpg' se ejecutará el script el cual llama al binario original pasando el parámetro que  aporta la solución y añadiendo todos los demás parámetros que se le pase al script.

Claro que cuando el sistema operativo actualice GnuPG, va a sobre escribir el script '/usr/bin/gpg' y el etl volverá a dejar de funcionar, así que hay que estar atentos a eso.

Saludos.

Que tal?

Comparto mi experiencia migrando Comdoc 3.0.6 (funcionando sobre jboss-4.2.3.GA) de un servidor antiguo con Debian 6 y openjdk-6-jdk a un nuevo servidor con Debian 9 y openjdk-8-jdk. Las versiones de Comdoc y JBoss se mantienen iguales.

Notas:

• reemplazar [mi-us-admin] por tu usuario LDAP o tu usuario PAM de cada servidor.
• reemplazar '[host-db-anterior]' por la URL al servidor de base de datos anterior
• reemplazar '[host-app-anterior]' por la URL al servidor de aplicación anterior
• En nuestro caso JBoss se encuentra en el directorio /opt/jboss-4.2.3.GA y Comdoc en el directorio /var/comdoc

En el servidor de aplicación anterior (Debian 6, openjdk-6-jdk)

Se comprimen los directorios y archivos a migrar. El resultado es el archivo /tmp/comdoc_app_dump.tar.gz listo para ser descargado vía scp desde el servidor nuevo:

cd /opt
sudo tar -czf opt_jboss.tar.gz jboss-4.2.3.GA
sudo mv opt_jboss.tar.gz /tmp/
cd /var
sudo tar -czf var_comdoc.tar.gz comdoc
sudo mv var_comdoc.tar.gz /tmp/
cd /tmp
sudo cp -a /etc/init.d/jboss_init.sh /etc/init.d/xvfb-daemon /etc/init.d/xvfb-daemon2 .
sudo tar -czf comdoc_app_dump.tar.gz jboss_init.sh opt_jboss.tar.gz var_comdoc.tar.gz xvfb-daemon xvfb-daemon2
sudo rm jboss_init.sh opt_jboss.tar.gz var_comdoc.tar.gz xvfb-daemon xvfb-daemon2

En el servidor de base de datos anterior (PostgreSQL 9.1.14)

pg_dump -h localhost -U comdoc -W produccion > /tmp/comdoc_produccion.pgsql

En el nuevo servidor de base de datos (PostgreSQL 9.6.7)

Se descarga y se importa el dump de la base de datos

scp [mi-us-admin]@[host-db-anterior]:/tmp/comdoc_produccion.pgsql .
psql -h localhost -U comdoc produccion < /tmp/comdoc_produccion.pgsql
Se agrega la IP del nuevo servidor de aplicación al archivo pg_hba.conf:

sudo vim /etc/postgresql/9.6/main/pg_hba.conf
  '-»  (add application host ips)

Para solucionar un problema que evita que los usuario puedan ingresar al sistema es necesario ejecutar:

sudo su postgres
psql -d produccion
y dentro de psql (puede ser necesario que edites el nombre de la base de datos):

ALTER DATABASE produccion SET bytea_output TO 'escape';
En caso de encontrarse con el error "ERROR:  el operador no existe: integer = character varying en carácter 53" en el log de PostgreSQL, también se deberá ejecutar:

CREATE OR REPLACE FUNCTION pg_catalog.varchartoint(character varying)
 RETURNS integer
 STRICT IMMUTABLE LANGUAGE SQL AS 'SELECT
 int4($1::text);';

 CREATE CAST (character varying AS integer) WITH FUNCTION
 pg_catalog.varchartoint(character varying) AS IMPLICIT;

Finalmente se reinicia el servidor de base de datos:

exit
sudo systemctl restart postgresql.service
En el nuevo servidor de aplicación (Debian 9, openjdk-8-jdk)

sudo apt-get install openjdk-8-jdk xvfb vim
cd /tmp
scp [mi-us-admin]@[host-app-anterior]:/tmp/comdoc_app_dump.tar.gz .

sudo tar xzf comdoc_app_dump.tar.gz
sudo rm comdoc_app_dump.tar.gz

sudo mv opt_jboss.tar.gz /opt/
sudo mv var_comdoc.tar.gz /var/
sudo mv jboss_init.sh xvfb-daemon xvfb-daemon2 /etc/init.d/

sudo chmod a+x /etc/init.d/jboss_init.sh
cd /opt
sudo tar xzf opt_jboss.tar.gz
sudo rm -f opt_jboss.tar.gz
cd /var
sudo tar xzf var_comdoc.tar.gz
sudo rm -f var_comdoc.tar.gz
Se edita la configuración de conexión al servidor de base de datos, en caso de ser necesario:

sudo vim /opt/jboss-4.2.3.GA/server/comdoc/deploy/comdoc-ds.xml
Para solucionar un problema de JBoss en Debian 9 al utilizar el servicio Xvfb, es necesario:

sudo vim /etc/init.d/jboss_init.sh
remplazar:
export DISPLAY=localhost:0.0por:
export DISPLAY=:0.0
Se crean los unit files para systemd:

JBoss:

sudo vim /lib/systemd/system/jboss.service

[Unit]
Description=JBoss

[Service]
Type=forking
User=root
Group=root
ExecStart=/etc/init.d/jboss_init.sh start
ExecStop=/etc/init.d/jboss_init.sh stop
TimeoutSec=300

[Install]
WantedBy=multi-user.target
sudo ln -s /lib/systemd/system/jboss.service /etc/systemd/system/multi-user.target.wants/jboss.service
Xvfb:

sudo vim /lib/systemd/system/xvfb.service
[Unit]
Description=X Virtual Frame Buffer Service
After=network.target

[Service]
ExecStart=/usr/bin/Xvfb :0 -screen 0 800x600x8

[Install]
WantedBy=multi-user.target
sudo ln -s /lib/systemd/system/xvfb.service /etc/systemd/system/multi-user.target.wants/xvfb.service
Xvfb2:

sudo vim /lib/systemd/system/xvfb2.service
Description=X Virtual Frame Buffer Service 2
After=network.target

[Service]
ExecStart=/usr/bin/Xvfb :1 -screen 0 800x600x8

[Install]
WantedBy=multi-user.target
sudo ln -s /lib/systemd/system/xvfb2.service /etc/systemd/system/multi-user.target.wants/xvfb2.service
Se recarga y se reinician los servicios:

sudo systemctl daemon-reload
sudo systemctl start xvfb.service
sudo systemctl start xvfb2.service
sudo systemctl start jboss.service
o bien directamente:

sudo reboot
EXTRA: Para ejecutar JBoss con un usuario distinto a root

sudo adduser comdoc
El puerto debe ser mayor a 1000 para que el usuario comdoc pueda utilizarlo, en nuestro caso tenemos un proxy escuchando el puerto 80 el cual redirecciona el tráfico al puerto 8080 en Comdoc. Por lo tanto se edita el puerto de 80 a 8080 en:

sudo vim /opt/jboss-4.2.3.GA/server/comdoc/deploy/jboss-web.deployer/server.xml
Quedando dicho fragmento así:

<Connector port="8080" address="${jboss.bind.address}"   
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true" />

En el caso de que el sistema se encuentre detrás de un proxy con un certificado TLS/SSL para el acceso vía https, será necesario agregar una línea extra, quedando así el fragmento:

<Connector port="8080" address="${jboss.bind.address}"   
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         scheme="https" secure="true" proxyName="comdoc.[URL_UNIVERSIDAD]" proxyPort="443"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true" />

Nota: reemplazar [URL_UNIVERSIDAD] por la URL que corresponda. Será la URL del proxy, es decir, la URL externa que los usuarios utilizarán para ingresar a ComDoc.

Luedo se edita el unit file configurando el usuario y grupo:

sudo vim /lib/systemd/system/jboss.service
reemplazar:
User=root
Group=rootpor:
User=comdoc
Group=comdoc
luego:

sudo systemctl daemon-reload
Se modifican el propietario para los directorios clave:

sudo chown -R comdoc:comdoc /opt/jboss-4.2.3.GA/
sudo chown -R comdoc:comdoc /var/comdoc/
Reiniciamos el servicio:

sudo systemctl stop jboss.service
sudo systemctl start jboss.service
---

Solo restaría configurar las tareas cron.

Saludos.

Hola, gracias por la respuesta.

Funcionó pero solo ejecutando manualmente:

sudo /usr/bin/gpg --batch --yes --passphrase "ParaElWichi620" --output "/tmp/querandies/6r1ee90ugeacm/paquete.zip" --decrypt "/tmp/querandies/6r1ee90ugeacm/temp_extraccion_wichi.gpg"
en ese momento me vuelve a consultar la passphrase. Luego vuelvo a ejecutar el etl y funciona correctamente, pero en la siguiente importación vuelve a fallar.

Leyendo la documentación de GnuPG en:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options

veo que el problema puede estar relacionado a la opción passphrase, cito:

--passphrase-file file
Read the passphrase from file file. Only the first line will be read from file file. This can only be used if only one passphrase is supplied. Obviously, a passphrase stored in a file is of questionable security if other users can read this file. Don’t use this option if you can avoid it.

Note that since Version 2.0 this passphrase is only used if the option --batch has also been given. Since Version 2.1 the --pinentry-mode also needs to be set to loopback.

Como mi versión de GnuPG es 2.1.18, debo agregar la opción --pinentry-mode loopback al comando gpg y entonces el mismo se ejecuta sin que me vuelva a consultar la passphrase.

Conclusión: como yo lo veo habría que agregar la opción --pinentry-mode loopback al etl o bien tendría que instalar una versión anterior de GnuPG.

¿Cuál será la mejor solución?

Gracias, saludos.

Hola Mariano, gracias por la respuesta.

Te adjunto los datos de las tablas. La versión de Wichi es 6.3.1

Saludos.