opengnsys
/
ogagent
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

ogagent unification 2 #9

Merged
nserrano merged 53 commits from unification2 into main 2024-10-01 13:28:01 +02:00
Conversation 7 Commits 53 Files Changed 14
nserrano commented 2024-09-20 14:26:34 +02:00
Collaborator

Historia de usuario: https://ognproject.evlt.uma.es/redmine/issues/699

Requisitos

  • ogagent 1.3.7: ognproject:/mnt/srv/artefactos/ogagent/ogagent_1.3.7-1_all.deb
  • ogLive-noble: ognproject:/mnt/srv/artefactos/oglive/ogLive-noble-6.8.0-31-generic-amd64-r20240716.iso

Preparar entorno virtualbox

En el repo opengnsys, ir a la rama unification2.

En doc/VERSION.json poner ogagent a 1.3.7.

En el instalador installer/opengnsys_installer_devel_esxi.sh:

  • línea 57: cambiar el oglive por defecto: DEFAULT_OGLIVE="ogLive-noble-6.8.0-31-generic-amd64-r20240716.iso"
  • línea 233: cambiar la dependencia de mysql-server por mariadb-server
  • línea 1969 y siguientes: comentar la llamada a checkNetworkConnection y el bloque if a continuación

Colocar el paquete del agente y el oglive en un sitio donde el instalador va a recogerlos (el paquete debian primero hay que meterlo en un tgz):

$ cp ogLive-noble-6.8.0-31-generic-amd64-r20240716.iso installer/
$ tar -zcf installer/ogagentpkgs-1.3.7.tar.gz ogagent_1.3.7-1_all.deb

Desplegar servidor opengnsys

Es importante colocarse en el directorio del repo del agente. Esto es porque el contenido será visible dentro de la VM bajo /vagrant y nos va a hacer falta.

El "vagrant up" tarda unos 3 minutos.

$ ls
[…] ogagent […] opengnsys […]
$ cd ogagent
$ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox INSTALL_FROM_REPO=../opengnsys vagrant up ogAdministrator

Nos conectamos, instalamos flask y lanzamos ogcore-mock en el puerto 444:

$ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox INSTALL_FROM_REPO=../opengnsys vagrant ssh ogAdministrator
$ sudo -i
root@ogAdministrator:~# apt-get install python3-flask
root@ogAdministrator:~# pushd /vagrant/; FLASK_APP=./ogcore-mock.py FLASK_ENV=development FLASK_RUN_CERT=adhoc flask run --host 192.168.2.10 --port 444 & popd

Arreglamos algunos bugs:

En /opt/opengnsys/client/lib/engine/bin/System.lib línea 62 hay una llamada a logger. Dado que este archivo va a ser visible en los clientes y éstos no tienen /dev/log, la llamada a logger falla. Para solucionar posibles problemas, cambiamos logger -s -t por echo:

root@ogAdministrator:~# sed -i -e 's/logger -s -t/echo/' /opt/opengnsys/client/lib/engine/bin/System.lib

Los archivos /opt/opengnsys/client/interfaceAdm/CrearImagen y /opt/opengnsys/client/interfaceAdm/CambiarAcceso tienen una comprobación de caller que estorba con el desarrollo nuevo. Buscar ogGetCaller y comentar la línea, así como el if que hay a continuación.

Desplegar modelo

Lo provisionamos y dejamos una sola tarjeta de red:

$ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox vagrant up modelo
$ VBoxManage modifyvm modelo --nic1 intnet --nic2 none --macaddress1 0800270E65FF

Después de la provisión, la VM queda apagada (hay un poweroff en el script de provisión).

Nos vamos al UI de virtualbox y le ponemos un disco de 8 Gb a la VM. Seguro que se puede hacer con comandos de la cmdline pero no quise perder tiempo con eso.

El hecho de tener una sola tarjeta de red y que ésta sea "intnet" causa un conflicto con vagrant, por lo que este cambio nos impide hacer "vagrant up". Toca usar "VBoxManage startvm modelo".

$ VBoxManage startvm modelo

Debería arrancar por DHCP sin problema y llegar al oglive.

Nos conectamos al modelo. Debido al tema de las tarjetas de red, no podemos hacer "vagrant ssh", por lo que primero entramos en el servidor de OG y luego vamos al modelo:

$ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox INSTALL_FROM_REPO=../opengnsys vagrant ssh ogAdministrator
$ ssh root@192.168.2.199       ## password "og"

Para que no se nos apague dentro de 20 minutos, ejecutamos /opt/opengnsys/bin/poweroffconf no.

Configurar modelo

Particionamos el segundo disco: fdisk /dev/sdb. Creamos cuatro particiones primarias. Las tres primeras de aproximadamente 1.7 - 1.8 Gb, la última tomando el resto. Que quede aproximadamente así:

Device     Boot    Start      End Sectors  Size Id Type
/dev/sdb1           2048  3483647 3481600  1.7G 83 Linux
/dev/sdb2        3483648  6965247 3481600  1.7G 83 Linux
/dev/sdb3        6965248 10446847 3481600  1.7G 83 Linux
/dev/sdb4       10446848 16777215 6330368    3G 83 Linux

Esto debería valer:

root@modelo:~# echo $'n\np\n1\n\n+1700M\nn\np\n2\n\n+1700M\nn\np\n3\n\n+1700M\nn\np\n\n\nw' |fdisk /dev/sdb

Creamos filesystem en sdb1 y creamos un /etc/os-release dentro:

root@modelo:~# mkfs.ext4 /dev/sdb1; mount /dev/sdb1 /mnt; mkdir /mnt/etc; cp /etc/os-release /mnt/etc/; umount /mnt

Creamos filesystem en sdb4 con etiqueta y creamos ya un /opt/opengnsys/images dentro del caché:

root@modelo:~# mkfs.ext4 -L CACHE /dev/sdb4; mount /dev/sdb4 /mnt; mkdir -p /mnt/opt/opengnsys/images; umount /mnt

Configurar y lanzar agente

Por alguna razón en mis pruebas el ogagent aparece como no instalado. Para instalarlo, tenemos que hacer que el .deb esté visible en el agente y luego pegarle un dpkg -i:

root@ogAdministrator:~# cp /vagrant/ogagent_1.3.7-1_all.deb /opt/opengnsys/images/
root@modelo:~# dpkg -i /opt/opengnsys/images/ogagent_1.3.7-1_all.deb

En la configuración del agente (/usr/share/OGAgent/cfg/ogagent.cfg) nos aseguramos de que las líneas remote= apunta a 192.168.2.10 por HTTP (no HTTPS). Comprobamos también la IP en las líneas urlMenu=.

root@modelo:~# sed -i "/remote=/  s/192.168.[0-9].[0-9]*/192.168.2.10:444/" /usr/share/OGAgent/cfg/ogagent.cfg
root@modelo:~# sed -i "/urlMenu=/ s/192.168.[0-9].[0-9]*/192.168.2.10/"     /usr/share/OGAgent/cfg/ogagent.cfg

root@modelo:~# grep ^remote /usr/share/OGAgent/cfg/ogagent.cfg
remote=http://192.168.2.10:444/opengnsys/rest
remote=http://192.168.2.10:444/opengnsys/rest
remote=http://192.168.2.10:444/opengnsys/rest

root@modelo:~# grep ^urlMenu /usr/share/OGAgent/cfg/ogagent.cfg
urlMenu=https://192.168.2.10/opengnsys/varios/menubrowser.php
urlMenu=https://192.168.2.10/opengnsys/varios/menubrowser.php

Miramos el log y lanzamos el agente en primer plano:

root@modelo:~# touch /var/log/opengnsys.log; tail -f /var/log/opengnsys.log &
root@modelo:~# cd /usr/share/OGAgent
root@modelo:/usr/share/OGAgent# PYTHONPATH=. python3 opengnsys/linux/OGAgentService.py fg

Pruebas y validaciones

Arranque del agente

Al ejecutar el agente, en el log tiene que aparecer que se encontraron tres módulos:

DEBUG 2024-09-23 12:22:37,579 (MainThread) (doLoad) Found module package opengnsys.modules.server.CloningEngine
DEBUG 2024-09-23 12:22:37,581 (MainThread) (doLoad) Found module package opengnsys.modules.server.OpenGnSys
DEBUG 2024-09-23 12:22:37,608 (MainThread) (doLoad) Found module package opengnsys.modules.server.ogAdmClient
DEBUG 2024-09-23 12:22:37,610 (MainThread) (loadModules) Adding server classes
DEBUG 2024-09-23 12:22:37,610 (MainThread) (addCls) Found module class <class 'opengnsys.modules.server.CloningEngine.CloningEngineWorker'>
DEBUG 2024-09-23 12:22:37,610 (MainThread) (addCls) Found module class <class 'opengnsys.modules.server.ogAdmClient.ogAdmClientWorker'>
DEBUG 2024-09-23 12:22:37,610 (MainThread) (addCls) Found module class <class 'opengnsys.modules.server.OpenGnSys.OpenGnSysWorker'>

Al activar el módulo "opengnsys" tiene que salir una excepción controlada:

DEBUG 2024-09-23 12:22:43,971 (MainThread) (initialize) Activating module opengnsys
DEBUG 2024-09-23 12:22:43,972 (MainThread) (initialize) traceback follows: "Traceback (most recent call last):
  File "/usr/share/OGAgent/opengnsys/service.py", line 157, in initialize
    mod.activate()
  File "/usr/share/OGAgent/opengnsys/workers/server_worker.py", line 58, in activate
    self.onActivation()
  File "/usr/share/OGAgent/opengnsys/modules/server/OpenGnSys/__init__.py", line 115, in onActivation
    raise Exception ('Refusing to load within an ogLive image')
Exception: Refusing to load within an ogLive image
"
ERROR 2024-09-23 12:22:43,972 (MainThread) (initialize) Activation of opengnsys failed: Refusing to load within an ogLive image.

Abajo de todo debe poner que se activaron dos módulos:

DEBUG 2024-09-23 12:22:43,972 (MainThread) (initialize) Modules after activation: ['CloningEngine', 'ogAdmClient']

status

Desde el ogserver llamamos a status una vez por cada módulo. La primera debe dar error:

root@ogAdministrator:~# curl --insecure https://192.168.2.199:8000/opengnsys/status
{"error": "Module opengnsys not found"}

root@ogAdministrator:~# curl --insecure https://192.168.2.199:8000/ogAdmClient/status
{"ogAdmClient": "in process_status"}

root@ogAdministrator:~# curl --insecure https://192.168.2.199:8000/CloningEngine/status
{"CloningEngine": "in process_status"}

CrearImagen

Desde el ogserver llamamos a CrearImagen y obtenemos una respuesta inmediata:

root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"1", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen
{"job_id": "CrearImagen-6f583f5a"}

La consola de la VM tiene que mostrar varios mensajes, como los que muestra la versión 1.1.1d.

En el tail -f del agente debe aparecer abajo de todo que se devolvió un 200:

DEBUG 2024-09-23 12:29:14,946 (Thread-6 (process_request_thread)) (log_message) HTTP "POST /CloningEngine/CrearImagen HTTP/1.1" 200 -

En el ogserver podemos ir llamando a status repetidamente:

root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status | jq
{
  "CrearImagen-6f583f5a": {
    "running": true,
    "result": null
  }
}

root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status | jq
{
  "CrearImagen-6f583f5a": {
    "running": false,
    "result": {
      "nfn": "RESPUESTA_CrearImagen",
      "idi": "idimagen",
      "dsk": "2",
      "par": "1",
      "cpt": "partition_type",
      "ipr": "192.168.2.10",
      "res": 1,
      "der": ""
    }
  }
}

Y la salida de un ls /opt/opengnsys/images tiene que mostrar 5 archivos referentes a la imagen:

root@ogAdministrator:~# ls -l /opt/opengnsys/images/
drwxrwxr-x 2 root      opengnsys   4096 Sep 24 10:27 groups
-rwxr--r-- 1 opengnsys opengnsys 176555 Sep 30 15:30 imgname.img
-rw-r--r-- 1 root      root          33 Sep 30 15:31 imgname.img.full.sum
-rwxr--r-- 1 opengnsys opengnsys     34 Sep 30 15:30 imgname.img.info
-rw-r--r-- 1 root      root          33 Sep 30 15:31 imgname.img.sum
-rw-r--r-- 1 root      root         261 Sep 30 15:31 imgname.img.torrent

RestaurarImagen

Desde el ogserver hacemos un POST a RestaurarImagen y obtenemos respuesta:

root@ogAdministrator:~# curl --insecure -X POST --data '{"nfn":"RestaurarImagen", "dsk":"2", "par":"1", "idi":"idimagen", "ipr":"192.168.2.10", "nci":"imgname", "ifs":1, "ptc":"unicast", "ids":0}' https://192.168.2.199:8000/CloningEngine/RestaurarImagen
{"job_id": "RestaurarImagen-07706b89"}

La consola de la VM tiene que mostrar varios mensajes, como los que muestra la versión 1.1.1d.

Repetimos el polling a status y aparecen el trabajo anterior, ya finalizado, y el nuevo:

root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status |jq
{
  "CrearImagen-6f583f5a": {
    "running": false,
    "result": {
      "nfn": "RESPUESTA_CrearImagen",
      "idi": "idimagen",
      "dsk": "2",
      "par": "1",
      "cpt": "partition_type",
      "ipr": "192.168.2.10",
      "res": 1,
      "der": ""
    }
  },
  "RestaurarImagen-07706b89": {
    "running": true,
    "result": null
  }
}

root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status |jq
{
  "CrearImagen-6f583f5a": {
    "running": false,
    "result": {
      "nfn": "RESPUESTA_CrearImagen",
      "idi": "idimagen",
      "dsk": "2",
      "par": "1",
      "cpt": "partition_type",
      "ipr": "192.168.2.10",
      "res": 1,
      "der": ""
    }
  },
  "RestaurarImagen-07706b89": {
    "running": false,
    "result": {
      "nfn": "RESPUESTA_RestaurarImagen",
      "idi": "idimagen",
      "dsk": "2",
      "par": "1",
      "ifs": 1,
      "cfg": "disk=1\tpar=0\tcpt=1\tfsi=\tsoi=\ttam=104857600\tuso=0\ndisk=1\tpar=1\tcpt=83\tfsi=EXT4\tsoi=Debian GNU/Linux 12 (bookworm) \ttam=104856576\tuso=3\ndisk=2\tpar=0\tcpt=1\tfsi=\tsoi=\ttam=8388608\tuso=0\ndisk=2\tpar=1\tcpt=83\tfsi=EXT4\tsoi=Ubuntu 24.04 LTS \ttam=1740800\tuso=1\ndisk=2\tpar=2\tcpt=83\tfsi=EMPTY\tsoi=\ttam=1740800\tuso=0\ndisk=2\tpar=3\tcpt=83\tfsi=EMPTY\tsoi=\ttam=1740800\tuso=0\ndisk=2\tpar=4\tcpt=83\tfsi=CACHE\tsoi=\ttam=3165184\tuso=1",
      "res": 1,
      "der": ""
    }
  }
}

Limpieza

$ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox vagrant destroy -f
Historia de usuario: https://ognproject.evlt.uma.es/redmine/issues/699 ## Requisitos - ogagent 1.3.7: ognproject:/mnt/srv/artefactos/ogagent/ogagent_1.3.7-1_all.deb - ogLive-noble: ognproject:/mnt/srv/artefactos/oglive/ogLive-noble-6.8.0-31-generic-amd64-r20240716.iso ## Preparar entorno virtualbox En el repo opengnsys, ir a la rama `unification2`. En `doc/VERSION.json` poner `ogagent` a `1.3.7`. En el instalador `installer/opengnsys_installer_devel_esxi.sh`: - línea 57: cambiar el oglive por defecto: `DEFAULT_OGLIVE="ogLive-noble-6.8.0-31-generic-amd64-r20240716.iso"` - línea 233: cambiar la dependencia de `mysql-server` por `mariadb-server` - línea 1969 y siguientes: comentar la llamada a `checkNetworkConnection` y el bloque `if` a continuación Colocar el paquete del agente y el oglive en un sitio donde el instalador va a recogerlos (el paquete debian primero hay que meterlo en un tgz): ``` $ cp ogLive-noble-6.8.0-31-generic-amd64-r20240716.iso installer/ $ tar -zcf installer/ogagentpkgs-1.3.7.tar.gz ogagent_1.3.7-1_all.deb ``` ## Desplegar servidor opengnsys Es importante colocarse en el directorio del repo del agente. Esto es porque el contenido será visible dentro de la VM bajo `/vagrant` y nos va a hacer falta. El "vagrant up" tarda unos 3 minutos. ``` $ ls […] ogagent […] opengnsys […] $ cd ogagent $ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox INSTALL_FROM_REPO=../opengnsys vagrant up ogAdministrator ``` Nos conectamos, instalamos flask y lanzamos ogcore-mock en el puerto 444: ``` $ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox INSTALL_FROM_REPO=../opengnsys vagrant ssh ogAdministrator $ sudo -i root@ogAdministrator:~# apt-get install python3-flask root@ogAdministrator:~# pushd /vagrant/; FLASK_APP=./ogcore-mock.py FLASK_ENV=development FLASK_RUN_CERT=adhoc flask run --host 192.168.2.10 --port 444 & popd ``` Arreglamos algunos bugs: En `/opt/opengnsys/client/lib/engine/bin/System.lib` línea 62 hay una llamada a `logger`. Dado que este archivo va a ser visible en los clientes y éstos no tienen `/dev/log`, la llamada a `logger` falla. Para solucionar _posibles_ problemas, cambiamos `logger -s -t` por `echo`: ``` root@ogAdministrator:~# sed -i -e 's/logger -s -t/echo/' /opt/opengnsys/client/lib/engine/bin/System.lib ``` Los archivos `/opt/opengnsys/client/interfaceAdm/CrearImagen` y `/opt/opengnsys/client/interfaceAdm/CambiarAcceso` tienen una comprobación de caller que estorba con el desarrollo nuevo. Buscar `ogGetCaller` y comentar la línea, así como el `if` que hay a continuación. ## Desplegar modelo Lo provisionamos y dejamos una sola tarjeta de red: ``` $ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox vagrant up modelo $ VBoxManage modifyvm modelo --nic1 intnet --nic2 none --macaddress1 0800270E65FF ``` Después de la provisión, la VM queda apagada (hay un `poweroff` en el script de provisión). Nos vamos al UI de virtualbox y le ponemos un disco de 8 Gb a la VM. Seguro que se puede hacer con comandos de la cmdline pero no quise perder tiempo con eso. El hecho de tener una sola tarjeta de red y que ésta sea "intnet" causa un conflicto con vagrant, por lo que este cambio nos impide hacer "vagrant up". Toca usar "VBoxManage startvm modelo". ``` $ VBoxManage startvm modelo ``` Debería arrancar por DHCP sin problema y llegar al oglive. Nos conectamos al modelo. Debido al tema de las tarjetas de red, no podemos hacer "vagrant ssh", por lo que primero entramos en el servidor de OG y luego vamos al modelo: ``` $ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox INSTALL_FROM_REPO=../opengnsys vagrant ssh ogAdministrator $ ssh root@192.168.2.199 ## password "og" ``` Para que no se nos apague dentro de 20 minutos, ejecutamos `/opt/opengnsys/bin/poweroffconf no`. ## Configurar modelo Particionamos el segundo disco: `fdisk /dev/sdb`. Creamos cuatro particiones primarias. Las tres primeras de aproximadamente 1.7 - 1.8 Gb, la última tomando el resto. Que quede aproximadamente así: ``` Device Boot Start End Sectors Size Id Type /dev/sdb1 2048 3483647 3481600 1.7G 83 Linux /dev/sdb2 3483648 6965247 3481600 1.7G 83 Linux /dev/sdb3 6965248 10446847 3481600 1.7G 83 Linux /dev/sdb4 10446848 16777215 6330368 3G 83 Linux ``` Esto debería valer: ``` root@modelo:~# echo $'n\np\n1\n\n+1700M\nn\np\n2\n\n+1700M\nn\np\n3\n\n+1700M\nn\np\n\n\nw' |fdisk /dev/sdb ``` Creamos filesystem en sdb1 y creamos un `/etc/os-release` dentro: ``` root@modelo:~# mkfs.ext4 /dev/sdb1; mount /dev/sdb1 /mnt; mkdir /mnt/etc; cp /etc/os-release /mnt/etc/; umount /mnt ``` Creamos filesystem en sdb4 con etiqueta y creamos ya un `/opt/opengnsys/images` dentro del caché: ``` root@modelo:~# mkfs.ext4 -L CACHE /dev/sdb4; mount /dev/sdb4 /mnt; mkdir -p /mnt/opt/opengnsys/images; umount /mnt ``` ## Configurar y lanzar agente Por alguna razón en mis pruebas el ogagent aparece como no instalado. Para instalarlo, tenemos que hacer que el .deb esté visible en el agente y luego pegarle un dpkg -i: ``` root@ogAdministrator:~# cp /vagrant/ogagent_1.3.7-1_all.deb /opt/opengnsys/images/ root@modelo:~# dpkg -i /opt/opengnsys/images/ogagent_1.3.7-1_all.deb ``` En la configuración del agente (`/usr/share/OGAgent/cfg/ogagent.cfg`) nos aseguramos de que las líneas `remote=` apunta a 192.168.2.10 por HTTP (no HTTPS). Comprobamos también la IP en las líneas `urlMenu=`. ``` root@modelo:~# sed -i "/remote=/ s/192.168.[0-9].[0-9]*/192.168.2.10:444/" /usr/share/OGAgent/cfg/ogagent.cfg root@modelo:~# sed -i "/urlMenu=/ s/192.168.[0-9].[0-9]*/192.168.2.10/" /usr/share/OGAgent/cfg/ogagent.cfg root@modelo:~# grep ^remote /usr/share/OGAgent/cfg/ogagent.cfg remote=http://192.168.2.10:444/opengnsys/rest remote=http://192.168.2.10:444/opengnsys/rest remote=http://192.168.2.10:444/opengnsys/rest root@modelo:~# grep ^urlMenu /usr/share/OGAgent/cfg/ogagent.cfg urlMenu=https://192.168.2.10/opengnsys/varios/menubrowser.php urlMenu=https://192.168.2.10/opengnsys/varios/menubrowser.php ``` Miramos el log y lanzamos el agente en primer plano: ``` root@modelo:~# touch /var/log/opengnsys.log; tail -f /var/log/opengnsys.log & root@modelo:~# cd /usr/share/OGAgent root@modelo:/usr/share/OGAgent# PYTHONPATH=. python3 opengnsys/linux/OGAgentService.py fg ``` ## Pruebas y validaciones ### Arranque del agente Al ejecutar el agente, en el log tiene que aparecer que se encontraron tres módulos: ``` DEBUG 2024-09-23 12:22:37,579 (MainThread) (doLoad) Found module package opengnsys.modules.server.CloningEngine DEBUG 2024-09-23 12:22:37,581 (MainThread) (doLoad) Found module package opengnsys.modules.server.OpenGnSys DEBUG 2024-09-23 12:22:37,608 (MainThread) (doLoad) Found module package opengnsys.modules.server.ogAdmClient DEBUG 2024-09-23 12:22:37,610 (MainThread) (loadModules) Adding server classes DEBUG 2024-09-23 12:22:37,610 (MainThread) (addCls) Found module class <class 'opengnsys.modules.server.CloningEngine.CloningEngineWorker'> DEBUG 2024-09-23 12:22:37,610 (MainThread) (addCls) Found module class <class 'opengnsys.modules.server.ogAdmClient.ogAdmClientWorker'> DEBUG 2024-09-23 12:22:37,610 (MainThread) (addCls) Found module class <class 'opengnsys.modules.server.OpenGnSys.OpenGnSysWorker'> ``` Al activar el módulo "opengnsys" tiene que salir una excepción controlada: ``` DEBUG 2024-09-23 12:22:43,971 (MainThread) (initialize) Activating module opengnsys DEBUG 2024-09-23 12:22:43,972 (MainThread) (initialize) traceback follows: "Traceback (most recent call last): File "/usr/share/OGAgent/opengnsys/service.py", line 157, in initialize mod.activate() File "/usr/share/OGAgent/opengnsys/workers/server_worker.py", line 58, in activate self.onActivation() File "/usr/share/OGAgent/opengnsys/modules/server/OpenGnSys/__init__.py", line 115, in onActivation raise Exception ('Refusing to load within an ogLive image') Exception: Refusing to load within an ogLive image " ERROR 2024-09-23 12:22:43,972 (MainThread) (initialize) Activation of opengnsys failed: Refusing to load within an ogLive image. ``` Abajo de todo debe poner que se activaron dos módulos: ``` DEBUG 2024-09-23 12:22:43,972 (MainThread) (initialize) Modules after activation: ['CloningEngine', 'ogAdmClient'] ``` ### status Desde el ogserver llamamos a status una vez por cada módulo. La primera debe dar error: ``` root@ogAdministrator:~# curl --insecure https://192.168.2.199:8000/opengnsys/status {"error": "Module opengnsys not found"} root@ogAdministrator:~# curl --insecure https://192.168.2.199:8000/ogAdmClient/status {"ogAdmClient": "in process_status"} root@ogAdministrator:~# curl --insecure https://192.168.2.199:8000/CloningEngine/status {"CloningEngine": "in process_status"} ``` ### CrearImagen Desde el ogserver llamamos a CrearImagen y obtenemos una respuesta inmediata: ``` root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"1", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen {"job_id": "CrearImagen-6f583f5a"} ``` La consola de la VM tiene que mostrar varios mensajes, como los que muestra la versión 1.1.1d. En el `tail -f` del agente debe aparecer abajo de todo que se devolvió un 200: ``` DEBUG 2024-09-23 12:29:14,946 (Thread-6 (process_request_thread)) (log_message) HTTP "POST /CloningEngine/CrearImagen HTTP/1.1" 200 - ``` En el ogserver podemos ir llamando a status repetidamente: ``` root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status | jq { "CrearImagen-6f583f5a": { "running": true, "result": null } } root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status | jq { "CrearImagen-6f583f5a": { "running": false, "result": { "nfn": "RESPUESTA_CrearImagen", "idi": "idimagen", "dsk": "2", "par": "1", "cpt": "partition_type", "ipr": "192.168.2.10", "res": 1, "der": "" } } } ``` Y la salida de un `ls /opt/opengnsys/images` tiene que mostrar 5 archivos referentes a la imagen: ``` root@ogAdministrator:~# ls -l /opt/opengnsys/images/ drwxrwxr-x 2 root opengnsys 4096 Sep 24 10:27 groups -rwxr--r-- 1 opengnsys opengnsys 176555 Sep 30 15:30 imgname.img -rw-r--r-- 1 root root 33 Sep 30 15:31 imgname.img.full.sum -rwxr--r-- 1 opengnsys opengnsys 34 Sep 30 15:30 imgname.img.info -rw-r--r-- 1 root root 33 Sep 30 15:31 imgname.img.sum -rw-r--r-- 1 root root 261 Sep 30 15:31 imgname.img.torrent ``` ### RestaurarImagen Desde el ogserver hacemos un POST a RestaurarImagen y obtenemos respuesta: ``` root@ogAdministrator:~# curl --insecure -X POST --data '{"nfn":"RestaurarImagen", "dsk":"2", "par":"1", "idi":"idimagen", "ipr":"192.168.2.10", "nci":"imgname", "ifs":1, "ptc":"unicast", "ids":0}' https://192.168.2.199:8000/CloningEngine/RestaurarImagen {"job_id": "RestaurarImagen-07706b89"} ``` La consola de la VM tiene que mostrar varios mensajes, como los que muestra la versión 1.1.1d. Repetimos el polling a status y aparecen el trabajo anterior, ya finalizado, y el nuevo: ``` root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status |jq { "CrearImagen-6f583f5a": { "running": false, "result": { "nfn": "RESPUESTA_CrearImagen", "idi": "idimagen", "dsk": "2", "par": "1", "cpt": "partition_type", "ipr": "192.168.2.10", "res": 1, "der": "" } }, "RestaurarImagen-07706b89": { "running": true, "result": null } } root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status |jq { "CrearImagen-6f583f5a": { "running": false, "result": { "nfn": "RESPUESTA_CrearImagen", "idi": "idimagen", "dsk": "2", "par": "1", "cpt": "partition_type", "ipr": "192.168.2.10", "res": 1, "der": "" } }, "RestaurarImagen-07706b89": { "running": false, "result": { "nfn": "RESPUESTA_RestaurarImagen", "idi": "idimagen", "dsk": "2", "par": "1", "ifs": 1, "cfg": "disk=1\tpar=0\tcpt=1\tfsi=\tsoi=\ttam=104857600\tuso=0\ndisk=1\tpar=1\tcpt=83\tfsi=EXT4\tsoi=Debian GNU/Linux 12 (bookworm) \ttam=104856576\tuso=3\ndisk=2\tpar=0\tcpt=1\tfsi=\tsoi=\ttam=8388608\tuso=0\ndisk=2\tpar=1\tcpt=83\tfsi=EXT4\tsoi=Ubuntu 24.04 LTS \ttam=1740800\tuso=1\ndisk=2\tpar=2\tcpt=83\tfsi=EMPTY\tsoi=\ttam=1740800\tuso=0\ndisk=2\tpar=3\tcpt=83\tfsi=EMPTY\tsoi=\ttam=1740800\tuso=0\ndisk=2\tpar=4\tcpt=83\tfsi=CACHE\tsoi=\ttam=3165184\tuso=1", "res": 1, "der": "" } } } ``` ## Limpieza ``` $ VAGRANT_VAGRANTFILE=../opengnsys/installer/vagrant/Vagrantfile-devel-vbox vagrant destroy -f ```
nserrano added 25 commits 2024-09-20 14:26:35 +02:00
nserrano force-pushed unification2 from a67669b99f to 1864995066 2024-09-20 14:28:23 +02:00 Compare
nserrano added 26 commits 2024-09-20 14:29:20 +02:00
nserrano changed title from WIP: ogagent unification 2 to ogagent unification 2 2024-09-23 14:35:51 +02:00
nserrano requested review from lgromero 2024-09-23 14:36:18 +02:00
nserrano requested review from vtroshchinskiy 2024-09-23 14:36:18 +02:00
nserrano requested review from aguerrero 2024-09-23 14:36:18 +02:00
nserrano requested review from arantuna 2024-09-23 14:36:18 +02:00
narenas requested review from narenas 2024-09-27 08:02:25 +02:00
narenas self-assigned this 2024-09-27 08:02:34 +02:00
narenas commented 2024-09-27 08:21:26 +02:00
Collaborator

En la parte de prueba, todo lo que se refiere a arreglo de bugs, por qué no se arreglan estas cosas directamente en el código en lugar de modificar los ficheros al vuelo?

En la parte de prueba, todo lo que se refiere a arreglo de bugs, por qué no se arreglan estas cosas directamente en el código en lugar de modificar los ficheros al vuelo?
narenas commented 2024-09-27 08:23:01 +02:00
Collaborator

Al arrancar el modelo tenemos el siguiente error:

    modelo: 0 upgraded, 0 newly installed, 1 to remove and 7 not upgraded.
    modelo: After this operation, 1498 kB disk space will be freed.
    modelo: Do you want to continue? [Y/n] Abort.
    modelo: --2024-09-27 06:20:30--  https://192.168.2.10/opengnsys/descargas/ogagent_1.3.6-1_all.deb
    modelo: Connecting to 192.168.2.10:443... connected.
    modelo: WARNING: The certificate of ‘192.168.2.10’ is not trusted.
    modelo: WARNING: The certificate of ‘192.168.2.10’ doesn't have a known issuer.
    modelo: The certificate's owner does not match hostname ‘192.168.2.10’
    modelo: HTTP request sent, awaiting response... 404 Not Found
    modelo: 2024-09-27 06:20:30 ERROR 404: Not Found.
    modelo:
    modelo: Reading package lists...
    modelo: E: read, still have 8 to read but none left
    modelo: E: Internal error, could not locate member control.tar{.zst,.lz4,.gz,.xz,.bz2,.lzma,}
    modelo: E: Could not read meta data from /tmp/ogagent_1.3.6-1_all.deb
    modelo: E: The package lists or status file could not be parsed or opened.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Realmente lo que está pasando es que el paquete debian está disponible en un sitio al que no llega.

Al arrancar el modelo tenemos el siguiente error: ``` modelo: 0 upgraded, 0 newly installed, 1 to remove and 7 not upgraded. modelo: After this operation, 1498 kB disk space will be freed. modelo: Do you want to continue? [Y/n] Abort. modelo: --2024-09-27 06:20:30-- https://192.168.2.10/opengnsys/descargas/ogagent_1.3.6-1_all.deb modelo: Connecting to 192.168.2.10:443... connected. modelo: WARNING: The certificate of ‘192.168.2.10’ is not trusted. modelo: WARNING: The certificate of ‘192.168.2.10’ doesn't have a known issuer. modelo: The certificate's owner does not match hostname ‘192.168.2.10’ modelo: HTTP request sent, awaiting response... 404 Not Found modelo: 2024-09-27 06:20:30 ERROR 404: Not Found. modelo: modelo: Reading package lists... modelo: E: read, still have 8 to read but none left modelo: E: Internal error, could not locate member control.tar{.zst,.lz4,.gz,.xz,.bz2,.lzma,} modelo: E: Could not read meta data from /tmp/ogagent_1.3.6-1_all.deb modelo: E: The package lists or status file could not be parsed or opened. The SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed. The output for this command should be in the log above. Please read the output to determine what went wrong. ``` Realmente lo que está pasando es que el paquete debian está disponible en un sitio al que no llega.
nserrano commented 2024-09-27 09:32:15 +02:00
Poster
Collaborator

Los bugs los arreglamos temporalmente en el PR, y no les damos mejor solución en el repo, porque Antonio Guerrero está pasándolo todo a python y no tiene sentido arreglarlos en bash. Simplemente tocamos lo mínimo para que el PR se pueda validar y tiramos palante.

Este Internal error, could not locate member control.tar ocurre cuando el contenido del .deb es, por ejemplo, HTML. De hecho más arriba se ve un 404. Yo también tuve cosas raras con eso. Al final toca hacérselo llegar al cliente de otra manera y pegarle un dpkg -i.

Esa otra manera puede ser, por ejemplo, aprovechando que /opt/opengnsys/images es un sitio visible por ambas máquinas:

root@servidor # cp /vagrant/ogagent_1.3.6*all*deb /opt/opengnsys/images/
root@cliente # dpkg -i /opt/opengnsys/images/ogagent_*deb
Los bugs los arreglamos temporalmente en el PR, y no les damos mejor solución en el repo, porque Antonio Guerrero está pasándolo todo a python y no tiene sentido arreglarlos en bash. Simplemente tocamos lo mínimo para que el PR se pueda validar y tiramos palante. Este `Internal error, could not locate member control.tar` ocurre cuando el contenido del .deb es, por ejemplo, HTML. De hecho más arriba se ve un 404. Yo también tuve cosas raras con eso. Al final toca hacérselo llegar al cliente de otra manera y pegarle un dpkg -i. Esa otra manera puede ser, por ejemplo, aprovechando que /opt/opengnsys/images es un sitio visible por ambas máquinas: ``` root@servidor # cp /vagrant/ogagent_1.3.6*all*deb /opt/opengnsys/images/ root@cliente # dpkg -i /opt/opengnsys/images/ogagent_*deb ```
narenas commented 2024-09-27 09:57:54 +02:00
Collaborator

Por el tema de los discos para no hacerlos manuales, se puede simplemente incluir estas dos lineas en el Vagrantfile

index 663031a8..b7d27857 100644
--- a/installer/vagrant/Vagrantfile-devel-vbox
+++ b/installer/vagrant/Vagrantfile-devel-vbox
@@ -202,6 +202,8 @@ Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
       vb.memory = CLIENTMEM
       vb.cpus = 1
       vb.customize ['modifyvm', :id, '--boot1', 'net', '--boot2', 'disk']
+      vb.customize ['createhd', '--filename', 'modelo-8gb.vdi', '--size', 8192]
+      vb.customize ['storageattach', :id, '--storagectl', 'SATA Controller', '--port', 1, '--device', 0, '--type', 'hdd', '--medium', 'modelo-8gb.vdi']
     end
     v1.vm.synced_folder ".", "/vagrant", disabled: true
     v1.vm.provision "shell", inline: MODELSCRIPT
Por el tema de los discos para no hacerlos manuales, se puede simplemente incluir estas dos lineas en el Vagrantfile ``` index 663031a8..b7d27857 100644 --- a/installer/vagrant/Vagrantfile-devel-vbox +++ b/installer/vagrant/Vagrantfile-devel-vbox @@ -202,6 +202,8 @@ Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| vb.memory = CLIENTMEM vb.cpus = 1 vb.customize ['modifyvm', :id, '--boot1', 'net', '--boot2', 'disk'] + vb.customize ['createhd', '--filename', 'modelo-8gb.vdi', '--size', 8192] + vb.customize ['storageattach', :id, '--storagectl', 'SATA Controller', '--port', 1, '--device', 0, '--type', 'hdd', '--medium', 'modelo-8gb.vdi'] end v1.vm.synced_folder ".", "/vagrant", disabled: true v1.vm.provision "shell", inline: MODELSCRIPT ```
narenas commented 2024-09-27 11:35:27 +02:00
Collaborator

El funcionamiento al crear imagen por parte del ogagent debería no tener estado, es decir al realizar la llamanda:

curl --insecure -X POST --data '{"dsk":"2", "par":"1", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen
{"nfn": "RESPUESTA_CrearImagen", "idi": "idimagen", "dsk": "2", "par": "1", "cpt": "partition_type", "ipr": "192.168.2.10", "res": 1, "der": ""}

El proceso se queda esperando a que ogagent termine el trabajo. Realmente el ogagent debe devolver algo así como trabajo iniciado, y por detrás controlar el estado del proceso que crea la imagen, una vez que termina ese proceso, el cliente volverá a preguntar el estado y le devolerá el estado del proceso, que podría ser "en curso", "error", "acabado", etc.

El funcionamiento al crear imagen por parte del ogagent debería no tener estado, es decir al realizar la llamanda: ``` curl --insecure -X POST --data '{"dsk":"2", "par":"1", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen {"nfn": "RESPUESTA_CrearImagen", "idi": "idimagen", "dsk": "2", "par": "1", "cpt": "partition_type", "ipr": "192.168.2.10", "res": 1, "der": ""} ``` El proceso se queda esperando a que ogagent termine el trabajo. Realmente el ogagent debe devolver algo así como trabajo iniciado, y por detrás controlar el estado del proceso que crea la imagen, una vez que termina ese proceso, el cliente volverá a preguntar el estado y le devolerá el estado del proceso, que podría ser "en curso", "error", "acabado", etc.
nserrano added 1 commit 2024-09-30 17:36:30 +02:00
nserrano commented 2024-09-30 18:12:38 +02:00
Poster
Collaborator

Hecho. He actualizado el OP apuntando a una nueva versión del agente (1.3.7) y tocando la parte de las pruebas.

Hecho. He actualizado el OP apuntando a una nueva versión del agente (1.3.7) y tocando la parte de las pruebas.
nserrano commented 2024-10-01 12:06:10 +02:00
Poster
Collaborator

Ya tengo lo último que hablamos por zoom.

Lanzamos un CrearImagen seguido de otro. El primero va bien y el segundo se niega:

root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"21", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen
{"job_id": "CrearImagen-2aa1bebe"}

root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"21", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen
{"job_id": null, "message": "some job is already running, refusing to launch another one"}

Esto queda así forever. Solo al llamar a status se actualizan las cosas internamente y podemos volver a ejecutar cosas. Esto Manu lo tiene que tener claro.

El error ahora es un diccionario con res=2 según el código original.

root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status |jq
{
  "CrearImagen-2aa1bebe": {
    "running": false,
    "result": {
      "res": 2,
      "der": "got exception: (interfaceAdmin(InventarioSoftware) returned success but did not create file (/tmp/CSft-192.168.2.199-21))"
    }
  }
}

root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"21", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen
{"job_id": "CrearImagen-f83ffa82"}

Gracias por el review! Mergeo.

Ya tengo lo último que hablamos por zoom. Lanzamos un CrearImagen seguido de otro. El primero va bien y el segundo se niega: ``` root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"21", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen {"job_id": "CrearImagen-2aa1bebe"} root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"21", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen {"job_id": null, "message": "some job is already running, refusing to launch another one"} ``` Esto queda así forever. Solo al llamar a status se actualizan las cosas internamente y podemos volver a ejecutar cosas. Esto Manu lo tiene que tener claro. El error ahora es un diccionario con res=2 según el código original. ``` root@ogAdministrator:~# curl --silent --insecure -X POST --data '{}' https://192.168.2.199:8000/CloningEngine/status |jq { "CrearImagen-2aa1bebe": { "running": false, "result": { "res": 2, "der": "got exception: (interfaceAdmin(InventarioSoftware) returned success but did not create file (/tmp/CSft-192.168.2.199-21))" } } } root@ogAdministrator:~# curl --insecure -X POST --data '{"dsk":"2", "par":"21", "cpt":"partition_type", "idi":"idimagen", "nci":"imgname", "ipr":"192.168.2.10", "nfn":"CrearImagen", "ids":0}' https://192.168.2.199:8000/CloningEngine/CrearImagen {"job_id": "CrearImagen-f83ffa82"} ``` Gracias por el review! Mergeo.
nserrano added 1 commit 2024-10-01 12:09:02 +02:00
nserrano merged commit 1cf3c6bf2c into main 2024-10-01 13:28:01 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
lgromero
vtroshchinskiy
aguerrero
arantuna
narenas
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
narenas
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: opengnsys/ogagent#9
There is no content yet.
Delete Branch "unification2"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?