miércoles, 17 de junio de 2020
Pues hoy tenía planeado efectuar un cambio de versión en el sistema operativo del servidor principal, el de odoo, y más bien va a ser que no.
El servidor está funcionando con Ubuntu Server 16.04 LTS que deberíamos haber actualizado tiempo atrás sobre todo por cosa de la seguridad y, tal vez, por una ganancia en el rendimiento del sistema pero que no hemos hecho porque primero una consultora (mal), luego otra (fatal) y ahora el chico externo (que ya no sé qué pensar) y, bueno, que bastante han tenido con que el ERP se sostenga para andar cambiando versiones de sistema operativo.
Con el nuevo horario después del ERTE -y el confinamiento y el consiguiente apocalipsis y demás- la empresa cierra a las tres de la tarde así que me he venido un poco antes y he estado preparando la cosa para ver si era fácil o no. El chico externo me dijo que OK en un correo cuando se lo pregunté y ya no sé si me dijo que bien al intento o bien a que emplease mi tiempo en ello o bien a que le llamase si algo fuese mal.
Antes de proceder me he asegurado de que la última copia estuviese correcta y luego he intentando actualizar el sistema empleando una herramienta de Ubuntu llamada do-release-upgrade que facilita el cambio. Y no, primero he tenido que ponerme al día con las actualizaciones de seguridad, lógico, y luego volver a intentarlo. Y nada, que no ha habido manera.
osr@erp:~$ sudo do-release-upgrade [sudo] password for osr: Checking for a new Ubuntu release ... authenticate 'bionic.tar.gz' against 'bionic.tar.gz.gpg' gpg exited 1 Debug information: gpg: Firmado el jue 30 ene 2020 10:28:11 CET usando clave RSA ID C0B21F32 gpg: /tmp/ubuntu-release-upgrader-wn_s5tfn/trustdb.gpg: se ha creado base de datos de confianza gpg: Firma INCORRECTA de «Ubuntu Archive Automatic Signing Key (2012) ftpmaster@ubuntu.com» Authentication failed Authenticating the upgrade failed. There may be a problem with the network or with the server.
Así que he pensado que una transición sencilla no iba a ser porque por lo que he leído en las notas de versión hay muchos cambios en los sistemas y los saltos entre versiones de este tipo no están recomendados. Tendría primero que arreglar lo de arriba, luego pasar a la versión LTS siguiente que sería la 2018.04 y después a la 2020.04 y mira, no, porque podría echarle horas y horas y no tendría forma alguna de volver atrás antes de que mañana a las siete se pongan en marcha.
He empezado a pergeñar un plan de migración para el que necesito algunas respuestas.
- ¿ Funciona odoo 8 con python 3 ?
- ¿ Funciona odoo 8 con postgresql 11 ?
Por lo que he visto en foros de soporte, con mensajes desde 2014 en adelante, es que había muchas dificultades en el cambio a la rama 3 y que la propia versión 10 de odoo ya tenía planeado una ruptura de compatibilidad y pensaban aprovecharlo para migrar. No sé en qué ha quedado la cosa pero supongo que tras tanto tiempo no habrá migración de nuestro ERP a versiones superiores de odoo. Será más económico en tiempo y horas hacer algo nuevo o cambiar a otra cosa totalmente distinta.
Lo del cambio de versión de Python, en mi opinión, es un cambio de lenguaje al estilo de Perl 6; no se le debería llamar actualización porque rompe demasiadas cosas a muchos niveles y así no se puede. Una cosa es que tu programa emplee cosas tan pero tan antiguas que son peligrosas o muy ineficientes. Otra que tengas que repasar todo el código porque a alguien necesitaba un olvido y perdón de sus pecados y lo llamó progreso y nos jodió a los demás.
Así que con respecto a Python sé que tengo las dos versiones instaladas en el sistema y que se puede hacer que funcione una u otra con entornos virtuales y demás. De hecho el chico externo va a poner en marcha una aplicación para el fichaje de empleados (sí, estamos así todavía) y está usando la rama 10 de odoo y va a hacerlo en ese mismo servidor. Así que asumo que es posible instalar una versión moderna del sistema operativo, con todos las variantes de python necesarias y ejecutar las aplicaciones sin interferirse. Y si no, siempre nos quedan los benditos contenedores. Claro que para eso yo tendría que aprender cómo crear las imágenes, cómo tener un repositorio propio con ellas y cómo hacerlos funcionar sin que estalle todo. Esto último está más logrado ya por mi parte pero sigue siendo tedioso. Es más, si se lo encargo a él, con la falta de interés que tiene en documentar nada de lo que hace sería una mina de sorpresas y decepciones.
Pero a lo que iba. No, no va a haber actualización esta tarde. Este muchacho ya podría haberme dicho algo pero tampoco ha sido una pérdida de tiempo. He aprendido cosas por el camino y ahora, mientras aprovecho para actualizar algunos Windows 10 de los homínidos, procedo a escribir esto y el informe posterior que debo enviar (con las preguntas, que no se me olvide).
El sistema operativo tiene la siguiente disposición de discos:
root@erp:/etc/apt# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1,8T 0 disk └─sda1 8:1 0 1,8T 0 part └─md0 9:0 0 1,8T 0 raid1 /var sdb 8:16 0 1,8T 0 disk └─sdb1 8:17 0 1,8T 0 part └─md0 9:0 0 1,8T 0 raid1 /var sdc 8:32 0 298,1G 0 disk ├─sdc1 8:33 0 953M 0 part /boot ├─sdc2 8:34 0 1K 0 part ├─sdc5 8:37 0 7,5G 0 part [SWAP] ├─sdc6 8:38 0 2,8G 0 part ├─sdc7 8:39 0 3,7G 0 part /home └─sdc8 8:40 0 283,2G 0 part /
En el RAID está todo el directorio de datos de PostgreSQL y permanece en buen estado. El sistema está en un disco de 300Gb en el que también se incluye toda la aplicación bajo el directorio /opt. La configuración también está repartida entre ese directorio y el del sistema en /etc.
Visto lo visto, creo que se podría perfectamente instalar en un disco una versión de sistema operativo reciente (Debian si es posible), traspasar el código y migrar la base de datos si es necesario. ¿ Funcionará con PostgreSQL versión 11 ? ¡ Ah ! Eso también tengo que preguntarlo. En caso contrario debería mantener la versión 9 que es la que corresponde con el servidor actual.
Lo que pretendo con todo esto es que las aplicaciones clave estén en un sistema con el menor número posible de agujeros de seguridad y con el mayor número de optimizaciones de código base. Para que la aplicación actual funcione mejor, además de un milagro, haría falta que alguien metiese mano de verdad al servidor de bases de datos y optimizase lo que hiciese falta. Que no se ha hecho y se nota muchísimo.