Troubleshooting
- ¿Cómo compruebo la versión de los paquetes de mi instalación de OpenGnsys Enterprise?
- Ha ocurrido algún problema mientras ejecutaba una operación administrativa
¿Cómo compruebo la versión de los paquetes de mi instalación de OpenGnsys Enterprise?
Puedes obtener la versión de cualquiera de los paquetes asociados a OpenGnsys Enterprise:
- ogserver
- ogclient
- ogcli
- ogcp
- oge-memtest
- tiptorrent-static
- tiptorrent-client-static
- python3.8-libfdisk-og
- python3-hivex-og
- webconsole
Para listar la versión de cualquiera de los paquetes de OpenGnsys Enterprise
instalados puedes usar el siguiente comando en la terminal: apt list
--installed <paquete> Por ejemplo para ver la versión de ogClient:
$ apt list --installed ogclient Listing... Done ogclient/now 1.3.1-4 amd64 [installed,local]
Ha ocurrido algún problema mientras ejecutaba una operación administrativa
A continuación se indican pautas cuando alguna operación administrativa ejecutada no termina correctamente sobre un cliente administrado tales como:
- particionar y formatear
- crear una imagen
- restaurar una imagen sobre equipos
Si surge algún problema durante la ejecución de una operación administrativa, ogClient mostrará en sus mensajes de log mensajes de utilidad al usuario que describen qué ha sucedido y cuando (además de incluir un stack trace para los desarrolladores). Puedes ver cómo consultar el log de un cliente aquí.
Tengo un problema con la restauración de un imagen de un equipo.
Puedes consultar el log histórico del cliente a través de la opción dentro del
subapartado "Logs" en la vista de comandos en ogCP, o directamente en la
carpeta /opt/opengnsys/log/clients/<ip cliente>.log del servidor (el
nombre del fichero es la dirección ip del cliente seguido de .log).
En el log histórico del cliente puedes identificar si el problema se ha dado durante la transferencia de la imagen, o por otro lado, el problema ha sucedido durante la ejecución de partclone o pasos posteriores a la transferencia por red de la imagen.
Diagnóstico de problemas durante la transferencia de una imagen
En caso de problemas durante la transferencia es importante asegurar que la la red y su infrastructura se encuentran en buen estado, sin cortes ni otras transferencias en paralelo que pueda estar saturando el canal de comunicación.
Un programa habitual para la comprobación del estado de ancho de banda de un
enlace es iperf. A continuación mostramos un ejemplo de uso de iperf para
comprobar el ancho de banda disponible entre un equipo cliente y el servidor de
OpenGnsys.
En un punto ejecutaremos iperf como servidor con el siguiente comando iperf
-s. Además podemos usar el parámetro -fm para que la velocidad se indique
en Mbit/s. Se podrá observar en la salida por pantalla el momento en el que un
cliente inicie una transferencia.
$ iperf -s -fm ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 0.12 MByte (default) ------------------------------------------------------------ [ 4] local 10.141.10.1 port 5001 connected with 10.141.10.104 port 43196 [ ID] Interval Transfer Bandwidth [ 4] 0.0-45.9 sec 5120 MBytes 935 Mbits/sec
En la otra máquina que ejecuta iperf como cliente se utiliza el siguiente
comando iperf -c {direccion servidor}. En caso de querer transferir una
cantidad de datos predeterminada se utiliza el parámetro -n. En este ejemplo
se han transferido 5GB de datos a la máquina que ejecuta iperf como servidor
(en este ejemplo la máquina con iperf servidor tiene la dirección ip
10.141.10.1).
$ iperf -c 10.141.10.1 -n 5GB ------------------------------------------------------------ Client connecting to 10.141.10.1, TCP port 5001 TCP window size: 638 KByte (default) ------------------------------------------------------------ [ 3] local 10.141.10.104 port 43196 connected with 10.141.10.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-45.9 sec 5.00 GBytes 936 Mbits/sec
Para este ejemplo podemos observar que entre cliente y servidor existe un ancho de banda que se acerca al nivel de saturación de un enlace de 1Gbps. Valores muy por debajo al de saturación podría indicarnos un problema en la red.
$ iperf -c 10.141.10.1 -t 30 ------------------------------------------------------------ Client connecting to 10.141.10.1, TCP port 5001 TCP window size: 986 KByte (default) ------------------------------------------------------------ [ 3] local 10.141.10.104 port 43198 connected with 10.141.10.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.0 sec 3.27 GBytes 936 Mbits/sec
Si el resultado se aleja del máximo teórico del ancho de banda de nuestra infrastructura entonces habremos detectado un problema de configuración de red o congestión dentro del segmento entre servidor y cliente.
Diagnóstico de problemas después de la transferencia de una imagen
Si, en otro caso, el problema ha surgido durante el volcado de la imagen a disco será pertinente comprobar el log del cliente, donde puedes encontrar un stack trace con la excepción que ha lanzado ogClient al ocurrir el error.
También es importante asegurar que el hardware del cliente se encuentra en buen estado, en el pasado hemos podido comprobar como equipos con RAM en mal estado provocaban error al transferir y restaurar la imagen.
Recuerda que OpenGnsys Enterprise incluye una plantilla de arranque donde puedes arrancar los clientes con un memtest para comprobar masivamente el estado de la memoria RAM.
El equipo cliente no arranca el ogLive
En primer lugar, asegúrate de que ogClient tiene disponibles todos los requisitos para su ejecución, ogClient en la rama 1.2.1 requiere python versión 3.8 o posterior, por tanto recuerda utilizar ogLive basado en Ubuntu Focal, ogLive basado en Ubuntu Bionic ya no está soportado.
Los problemas en el arranque se pueden dar en tres etapas:
- Arranque PXE
- Transferencia de plantilla de arranque y bootloader
- Arranque de sistema operativo live: ogLive.
A continuación se describe los posibles problemas asociados a estas etapas.
Arranque PXE
Asegúrate de que las opciones DHCP (next-server y filename) para iniciar el arranque por PXE son correctas.
A través de PXE el equipo obtiene una IP a través del servidor DHCP que también debe tener configurados correctamente las opciones.
La configuración del servidor DHCP se encuentra en /etc/dhcp/dhcpd.conf
Si nuestro servidor de OpenGnsys (donde debe estar alojado el servidor TFTP) se encuentra en la dirección 10.141.10.1, entonces nuestra configuración del servidor DHCP debe al menos incluir la siguiente información:
next-server 10.141.10.1;
# 0007 == x64 EFI boot
if option arch = 00:07 {
filename "shimx64.efi.signed";
} else {
filename "grldr";
}
Transferencia de plantilla de arranque y bootloader
Podemos comprobar que se han transferido correctamente la plantilla PXE y los ficheros indicados en ella revisando el log del servidor TFTP.
Podemos revisar el log del servidor TFTP de la siguiente manera:
- Primero, asegurar que ejecutamos el servidor de TFTP con mayor
verbosidad. Para ello debemos comprobar que se incluye el parámetro
-ven el apartadoTFTP_OPTIONSdentro del fichero de configuración/etc/default/tftpd-hpa. En caso de no encontrar esta opción debemos añadirla y reiniciar el servicio consystemctl restart tftpd-hpa.service.
~$ cat /etc/default/tftpd-hpa # /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/var/lib/tftpboot" TFTP_ADDRESS=":69" TFTP_OPTIONS="--secure -v"
Necesitamos ejecutar el servidor TFTP con la opción -v ya que en otro caso no
podremos observar las peticiones RRQ en el log del servidor TFTP.
A la hora de diagnosticar el tráfico TFTP deberíamos poder encontrar que se han recibido peticiones RRQ para la plantilla PXE (01-{MAC del cliente}), ogvmlinuz (en arranque de ogLive) y oginitrd.img (en arranque de ogLive).
El log TFTP para un cliente que debe arrancar ogLive debería tener las siguientes peticiones que figuran en el cuadro de ejemplo
sep 26 14:38:45 oge-server in.tftpd[50491]: RRQ from 10.161.7.5 filename shimx64.efi.signed sep 26 14:38:45 oge-server in.tftpd[50491]: tftp: client does not accept options sep 26 14:38:45 oge-server in.tftpd[50492]: RRQ from 10.161.7.5 filename shimx64.efi.signed sep 26 14:38:46 oge-server in.tftpd[50495]: RRQ from 10.161.7.5 filename grubx64.efi sep 26 14:38:47 oge-server in.tftpd[50496]: RRQ from 10.161.7.5 filename /grub/x86_64-efi/command.lst sep 26 14:38:47 oge-server in.tftpd[50497]: RRQ from 10.161.7.5 filename /grub/x86_64-efi/fs.lst sep 26 14:38:47 oge-server in.tftpd[50498]: RRQ from 10.161.7.5 filename /grub/x86_64-efi/crypto.lst sep 26 14:38:47 oge-server in.tftpd[50499]: RRQ from 10.161.7.5 filename /grub/x86_64-efi/terminal.lst sep 26 14:38:47 oge-server in.tftpd[50500]: RRQ from 10.161.7.5 filename /grub/grub.cfg sep 26 14:38:47 oge-server in.tftpd[50501]: RRQ from 10.161.7.5 filename /grub/01-a8:5e:45:12:f7:ee sep 26 14:39:06 oge-server in.tftpd[50584]: RRQ from 10.161.7.5 filename ogLive/ogvmlinuz.sum sep 26 14:39:06 oge-server in.tftpd[50597]: RRQ from 10.161.7.5 filename ogLive/oginitrd.img.sum
Un cliente que arranca directamente una partición debería mostrar mensajes similar al siguiente cuadro de ejemplo
sep 26 14:54:17 oge-server in.tftpd[52835]: RRQ from 10.163.29.6 filename shimx64.efi.signed sep 26 14:54:18 oge-server in.tftpd[52837]: RRQ from 10.163.29.6 filename grubx64.efi sep 26 14:54:28 oge-server in.tftpd[52862]: RRQ from 10.163.29.6 filename /grub/x86_64-efi/command.lst sep 26 14:54:28 oge-server in.tftpd[52863]: RRQ from 10.163.29.6 filename /grub/x86_64-efi/fs.lst sep 26 14:54:28 oge-server in.tftpd[52864]: RRQ from 10.163.29.6 filename /grub/x86_64-efi/crypto.lst sep 26 14:54:28 oge-server in.tftpd[52865]: RRQ from 10.163.29.6 filename /grub/x86_64-efi/terminal.lst sep 26 14:54:28 oge-server in.tftpd[52866]: RRQ from 10.163.29.6 filename /grub/grub.cfg sep 26 14:54:28 oge-server in.tftpd[52867]: RRQ from 10.163.29.6 filename /grub/01-24:4b:fe:2d:9f:2f sep 26 14:54:55 oge-server in.tftpd[52914]: RRQ from 10.161.6.58 filename shimx64.efi.signed
Si el intervalo de tiempo entre transferencias TFTP es alto esto puede indicar un tráfico TFTP lento. El tráfico TFTP lento suele ser debido a una alta latencia entre servidor y cliente.
Asegúrate siempre de que el tiempo de ida y vuelta (siglas en inglés RTT) entre servidor y clientes se mantiene por debajo de 1ms, puedes usar ping para comprobar estos valores.
$ ping 10.141.10.1 PING 10.141.10.1 (10.141.10.1) 56(84) bytes of data. 64 bytes from 10.141.10.1: icmp_seq=1 ttl=64 time=0.112 ms 64 bytes from 10.141.10.1: icmp_seq=2 ttl=64 time=0.122 ms 64 bytes from 10.141.10.1: icmp_seq=3 ttl=64 time=0.113 ms 64 bytes from 10.141.10.1: icmp_seq=4 ttl=64 time=0.122 ms 64 bytes from 10.141.10.1: icmp_seq=5 ttl=64 time=0.124 ms 64 bytes from 10.141.10.1: icmp_seq=6 ttl=64 time=0.145 ms 64 bytes from 10.141.10.1: icmp_seq=7 ttl=64 time=0.126 ms 64 bytes from 10.141.10.1: icmp_seq=8 ttl=64 time=0.127 ms 64 bytes from 10.141.10.1: icmp_seq=9 ttl=64 time=0.113 ms ^C --- 10.141.10.1 ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8171ms rtt min/avg/max/mdev = 0.112/0.122/0.145/0.009 ms rtt min/avg/max/mdev = 0.112/0.122/0.145/0.009 ms
Puedes leer más detalles respecto al arranque PXE y ogLive aquí.
Arranque de sistema operativo live: ogLive.
Durante esta fase se transfieren por red el resto de elementos para poder arrancar ogLive. En el monitor del cliente se mostrarán mensajes del proceso que podrán ayudar a determinar el problema.
En nuevo equipamiento, es un problema habitual que una tarjeta de red no haya sido reconocida por no estar soportada por el kernel que ofrece el ogLive.
Cuando esto ocurre, el proceso de arranque de ogLive se quedará bloqueado durante la detección de la interfaz de red. Es habitual ver un mensaje como el siguiente repetidas veces, hasta terminar en un kernel panic.
exportando variable DEVICE con valor = y DEVICECFG con valor
¿Cómo identifico si hay un error de programación en ogClient?
Puede seguir el siguiente enlace para leer al respecto de cómo consultar el log de un cliente.
Al encontrar una situación de error durante la ejecución de una operación administrativa, ogClient escribe a través de sus mensajes de log un resumen de su estado en el momento del fallo. A un nivel más técnico, incluye una porción del código y función que se estaba ejecutando y detalles más técnicos respecto al motivo del error.
Un stack trace a causa de una excepción durante la ejecución de una operación administrativa tiene el siguiente aspecto:
(2023-07-24 16:53:28) ogClient: [ERROR] - Unexpected error
Traceback (most recent call last):
File "/opt/opengnsys/ogClient/src/live/ogOperations.py", line 162, in _restore_image_tiptorrent
tip_client_get(repo, name)
File "/opt/opengnsys/ogClient/src/utils/tiptorrent.py", line 97, in tip_client_get
raise ValueError('Tiptorrent download failed')
ValueError: Tiptorrent download failed
Al requerir ayuda por parte de Soleta Networks para depurar algún problema durante la ejecución de alguna operación administativa debes adjuntar el stack trace junto con el resto de la información para facilitar la tarea de soporte.