opengnsys
/
ogboot
2
0
Fork 0
Code Issues Pull Requests 2 Packages Projects Releases Wiki Activity

refs #222 #243 #244 #245 adds ipxe configuration to the boot engine #1

Closed
lgromero wants to merge 25 commits from ipxe-study into main
pull from: ipxe-study
merge into: opengnsys:main
Conversation 15 Commits 25 Files Changed 7
lgromero commented 2024-03-08 13:31:09 +01:00
Collaborator

Introducción

Esta PR cierra los tickets #222 #243 #244 #245. El objetivo general es hacer un estudio de nuevas tecnologías para el arranque de máquinas. Se ha estudiado el uso de ipxe como motor de arranque en el nuevo componente ogboot. Además se ha probado el motor de ipxe sobre clientes montados por opengnsys, cargando el oglive sobre ellos. Las pruebas se han llevado a cabo tanto para clientes con sistemas BIOS y UEFI como en servidores dhcp isc-dhcp y kea dhcp. El objetivo de esta PR es testear cada prueba que se ha llevado a cabo y confirmar que se abarca cualquier casuística posible para su posterior integración con ogboot. Mientras se lleva a cabo el desarrollo del componente ogboot, utilizaremos el tftpboot de opengnsys para servir los scripts de ipxe.

Script embebido en ipxe

En una carga inicial del ipxe por dhcp se produce un bucle infinito debido a que la carga del ipxe vuelve a llamar al dhcp solicitando un boot-file, enviando este otra vez el mismo ipxe y este volviendo a solicitar boot-file. Para corregir el problema ipxe ofrece dos soluciones: la primera es añadir un nuevo condicional en la configuración dhcp para controlar la segunda llamada al dhcp, ofreciendo el siguiente script ipxe con la lógica a seguir con el arranque:

    if exists user-class and option user-class = "iPXE" {
      filename "ipxe_scripts/dhcp_boot.ipxe";
    } elsif option arch = 00:07 {
      filename "ipxe.efi";
    } else {
      filename "undionly.kpxe";
    }

La segunda opción sería modificar los ficheros de arranque undionly.kpxe y ipxe.efi, generandolos de nuevo y embebiendo un script que contendría la lógica de los siguientes pasos en el arranque. Para generar estos archivos se requiere descargar el siguientes repositorio: https://github.com/ipxe/ipxe

Una vez descargado ejecutar make para montar los componentes necesarios. Por último generar los ficheros de arranque necesarios de la siguiente forma:

  • Arquitectura BIOS:

make bin/undionly.kpxe EMBED=/opt/opengnsys/tftpboot/ipxe_scripts/dhcp_boot.ipxe

  • Arquitectura UEFI:

make bin-x86_64-efi/ipxe.efi EMBED=/opt/opengnsys/tftpboot/ipxe_scripts/dhcp_boot.ipxe

Hemos optado por esta segunda opción ya que de esta forma no requeriría de una segunda llamada al DHCP, ahorrandonos alrededor de 30 segundos en entornos reales que es lo que suele durar una consulta DHCP en las aulas al llevar a cabo el arranque.

Scripts de arranque

Actualmente estamos embebiendo el script dhcp_boot.ipxe que será el siguiente paso que ejecutará el cliente al arrancar por el boot-file. Este script tiene como objetivo emular la forma de arranque que tenemos a día de hoy en opengnsys:

  • Configuración de red inicial net0
  • Búsqueda del fichero de configuración que tiene por nombre 01-{$mac} siendo $mac la mac de la máquina cliente
  • En caso de no encontrar el fichero de configuración ejecuta default.ipxe

Estos ficheros de configuración contienen los siguientes pasos en el arranque que es la carga del kernel, carga de imagen de inicialización y por último arranque de la máquina. Hemos documentado los tiempos al usar protocolos HTTP o TFTP, se pueden ver en el ticket https://ognproject.evlt.uma.es/redmine/issues/222

Por ahora default.ipxe y los scripts con MAC son iguales, en el futuro se pensará mejor que lógica tendrán cada uno.

DHCP

Se ha probado con dos servidores de DHCP: isc-dhcp y kea dhcp. Se han llevado a cabo pruebas con ambas tecnologías pero para esta PR nos centraremos únicamente en kea-dhcp. De todos modos queda documentado en esta PR como sería la configuración de ipxe para isc-dhcp Lo único que cabe destacar es que para ambos servicios hay que implementar una lógica condicional de modo que ejecute undionly.kpxe para sistemas BIOS o ipxe.efi para sistemas UEFI en sus ficheros de configuración.

Para isc-dhcp la configuración sería la siguiente:



    # 0007 == x64 EFI boot
    if option arch = 00:07 {
        filename "ipxe.efi";
    } else {
        filename "undionly.kpxe";
    }

Para kea-dhcp es un poco mas complicado, debemos definir perfiles de configuración que use dependiendo de la arquitectura del cliente:

"client-classes":
    [
      {
        "name": "UEFI-64",
        "test": "substring(option[60].hex,0,20) != 'PXEClient:Arch:00009'",
        "boot-file-name": "ipxe.efi"
      },
      {
        "name": "Legacy",
        "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'",
        "boot-file-name": "undionly.kpxe"
      }
]

Nota: no procederá pero en caso de que quisiesemos resolver el problema del bucle infinito por dhcp en kea habria que añadir:

      {
        "name": "XClient_iPXE",
        "test": "substring(option[77].hex,0,4) == 'iPXE'",
        "boot-file-name": "ipxe_scripts/dhcp_boot.ipxe"
      },

Pruebas en Jenkins

Se ha desarrollado dos ramas para poder probar la PR de forma óptima. A continuación listaremos los principales cambios que llevan a cabo:

Repositorio Opengnsys, rama ogboot-installer-jenkins:

  • installer/opengnsys_installer_devel_esxi.sh

    • Instalación de Kea DHCP
    • Montaje de la configuración de Kea DHCP a partir de una plantilla

  • installer/vagrant/Vagrantfile-esxi

    • Incluir los clientes creados en el campo "reservations" de la configuración de kea dhcp con su respectivas IPs y MAC
    • Instalación del componente ogboot en caso de que sea indicado en los parámetros de Jenkins

Repositorio Ogboot, rama ipxe-study:

  • ogboot/installer/ogboot_installer.sh

    • Descarga del repositorio ogboot
    • Añadir directorios tftpboot a la instalación de opengnsys
    • Generación de scripts con la lógica de arranque de los oglives que serán embebidos a los script de arranque que ejecutará el cliente
    • Montaje de sistema NFS que guarda el artefacto ipxe para la compilación de scripts de arranque
    • Compilación de los scripts de arranque tanto para EFI como para BIOS, embebiendo los respectivos scripts con la logica de arranque de los oglives

Nota: Se hará otra PR para la rama ogboot-installer-jenkins de Opengnsys que tendrá como objetivo incluir los cambios de la instalación de Kea DHCP y la instalación del componente ogboot si lo precisa.

Pruebas a Realizar

  • Para probarlo crear trabajo en Jenkins con los siguientes parámetros:

    • BRANCH : "ogboot-installer-jenkins"
    • EXTRA_NAME el que uno quiera.
    • Añadir 2 ordenadores
    • OGBOOT_BRANCH: "ipxe-study"

  • Al terminar buscar la IP para acceder a la máquina más adelante

  • Ir al Vmware ESXI y buscar las máquinas creadas

  • Desde el Vmware ESXI encender un cliente creado

  • Confirmar que se ha levantado el cliente correctamente

  • Modificar el cliente para que levante por EFI, para ello, desde Vmware ESXI selecciona uno de los clientes creados, click derecho:

    • Editar Configuración > Opciones de Máquina Virtual > Opciones de arranque > Firmware a EFI
    • Volver a arrancar el cliente y confirmar que levanta correctamente
### Introducción Esta PR cierra los tickets #222 #243 #244 #245. El objetivo general es hacer un estudio de nuevas tecnologías para el arranque de máquinas. Se ha estudiado el uso de ipxe como motor de arranque en el nuevo componente ogboot. Además se ha probado el motor de ipxe sobre clientes montados por opengnsys, cargando el oglive sobre ellos. Las pruebas se han llevado a cabo tanto para clientes con sistemas BIOS y UEFI como en servidores dhcp isc-dhcp y kea dhcp. El objetivo de esta PR es testear cada prueba que se ha llevado a cabo y confirmar que se abarca cualquier casuística posible para su posterior integración con ogboot. Mientras se lleva a cabo el desarrollo del componente ogboot, utilizaremos el tftpboot de opengnsys para servir los scripts de ipxe. ### Script embebido en ipxe En una carga inicial del ipxe por dhcp se produce un bucle infinito debido a que la carga del ipxe vuelve a llamar al dhcp solicitando un boot-file, enviando este otra vez el mismo ipxe y este volviendo a solicitar boot-file. Para corregir el problema ipxe ofrece dos soluciones: la primera es añadir un nuevo condicional en la configuración dhcp para controlar la segunda llamada al dhcp, ofreciendo el siguiente script ipxe con la lógica a seguir con el arranque: ``` if exists user-class and option user-class = "iPXE" { filename "ipxe_scripts/dhcp_boot.ipxe"; } elsif option arch = 00:07 { filename "ipxe.efi"; } else { filename "undionly.kpxe"; } ``` La segunda opción sería modificar los ficheros de arranque `undionly.kpxe` y `ipxe.efi`, generandolos de nuevo y embebiendo un script que contendría la lógica de los siguientes pasos en el arranque. Para generar estos archivos se requiere descargar el siguientes repositorio: https://github.com/ipxe/ipxe Una vez descargado ejecutar `make` para montar los componentes necesarios. Por último generar los ficheros de arranque necesarios de la siguiente forma: - Arquitectura BIOS: `make bin/undionly.kpxe EMBED=/opt/opengnsys/tftpboot/ipxe_scripts/dhcp_boot.ipxe` - Arquitectura UEFI: ` make bin-x86_64-efi/ipxe.efi EMBED=/opt/opengnsys/tftpboot/ipxe_scripts/dhcp_boot.ipxe` Hemos optado por esta segunda opción ya que de esta forma no requeriría de una segunda llamada al DHCP, ahorrandonos alrededor de 30 segundos en entornos reales que es lo que suele durar una consulta DHCP en las aulas al llevar a cabo el arranque. ### Scripts de arranque Actualmente estamos embebiendo el script `dhcp_boot.ipxe` que será el siguiente paso que ejecutará el cliente al arrancar por el boot-file. Este script tiene como objetivo emular la forma de arranque que tenemos a día de hoy en opengnsys: - Configuración de red inicial net0 - Búsqueda del fichero de configuración que tiene por nombre 01-{$mac} siendo $mac la mac de la máquina cliente - En caso de no encontrar el fichero de configuración ejecuta default.ipxe Estos ficheros de configuración contienen los siguientes pasos en el arranque que es la carga del kernel, carga de imagen de inicialización y por último arranque de la máquina. Hemos documentado los tiempos al usar protocolos HTTP o TFTP, se pueden ver en el ticket `https://ognproject.evlt.uma.es/redmine/issues/222` Por ahora default.ipxe y los scripts con MAC son iguales, en el futuro se pensará mejor que lógica tendrán cada uno. ### DHCP Se ha probado con dos servidores de DHCP: isc-dhcp y kea dhcp. Se han llevado a cabo pruebas con ambas tecnologías pero para esta PR nos centraremos únicamente en kea-dhcp. De todos modos queda documentado en esta PR como sería la configuración de ipxe para isc-dhcp Lo único que cabe destacar es que para ambos servicios hay que implementar una lógica condicional de modo que ejecute undionly.kpxe para sistemas BIOS o ipxe.efi para sistemas UEFI en sus ficheros de configuración. Para isc-dhcp la configuración sería la siguiente: ``` # 0007 == x64 EFI boot if option arch = 00:07 { filename "ipxe.efi"; } else { filename "undionly.kpxe"; } ``` Para kea-dhcp es un poco mas complicado, debemos definir perfiles de configuración que use dependiendo de la arquitectura del cliente: ``` "client-classes": [ { "name": "UEFI-64", "test": "substring(option[60].hex,0,20) != 'PXEClient:Arch:00009'", "boot-file-name": "ipxe.efi" }, { "name": "Legacy", "test": "substring(option[60].hex,0,20) == 'PXEClient:Arch:00000'", "boot-file-name": "undionly.kpxe" } ] ``` Nota: no procederá pero en caso de que quisiesemos resolver el problema del bucle infinito por dhcp en kea habria que añadir: ``` { "name": "XClient_iPXE", "test": "substring(option[77].hex,0,4) == 'iPXE'", "boot-file-name": "ipxe_scripts/dhcp_boot.ipxe" }, ``` ## Pruebas en Jenkins Se ha desarrollado dos ramas para poder probar la PR de forma óptima. A continuación listaremos los principales cambios que llevan a cabo: #### Repositorio Opengnsys, rama ogboot-installer-jenkins: - installer/opengnsys_installer_devel_esxi.sh - Instalación de Kea DHCP - Montaje de la configuración de Kea DHCP a partir de una plantilla - installer/vagrant/Vagrantfile-esxi - Incluir los clientes creados en el campo "reservations" de la configuración de kea dhcp con su respectivas IPs y MAC - Instalación del componente ogboot en caso de que sea indicado en los parámetros de Jenkins #### Repositorio Ogboot, rama ipxe-study: - ogboot/installer/ogboot_installer.sh - Descarga del repositorio ogboot - Añadir directorios tftpboot a la instalación de opengnsys - Generación de scripts con la lógica de arranque de los oglives que serán embebidos a los script de arranque que ejecutará el cliente - Montaje de sistema NFS que guarda el artefacto ipxe para la compilación de scripts de arranque - Compilación de los scripts de arranque tanto para EFI como para BIOS, embebiendo los respectivos scripts con la logica de arranque de los oglives Nota: Se hará otra PR para la rama ogboot-installer-jenkins de Opengnsys que tendrá como objetivo incluir los cambios de la instalación de Kea DHCP y la instalación del componente ogboot si lo precisa. # Pruebas a Realizar - Para probarlo crear trabajo en Jenkins con los siguientes parámetros: - BRANCH : "ogboot-installer-jenkins" - EXTRA_NAME el que uno quiera. - Añadir 2 ordenadores - OGBOOT_BRANCH: "ipxe-study" - Al terminar buscar la IP para acceder a la máquina más adelante - Ir al Vmware ESXI y buscar las máquinas creadas - Desde el Vmware ESXI encender un cliente creado - Confirmar que se ha levantado el cliente correctamente - Modificar el cliente para que levante por EFI, para ello, desde Vmware ESXI selecciona uno de los clientes creados, click derecho: - Editar Configuración > Opciones de Máquina Virtual > Opciones de arranque > Firmware a EFI - Volver a arrancar el cliente y confirmar que levanta correctamente
lgromero added 1 commit 2024-03-08 13:31:09 +01:00
lgromero requested review from nserrano 2024-03-08 15:04:41 +01:00
lgromero commented 2024-03-21 13:53:15 +01:00
Poster
Collaborator

Pasos a seguir:

  • Modificar el instalador de Opengnsys para que instale Kea DHCP
  • El script de instalación ejecutado por el pipeline deberá incluir la copia de los ficheros al tftpboot
  • Además también hay que incluir la bajada del ipxe para la generación de scripts embebidos
  • Script de Vagrant para que añada los PCs creado al reservations de la configuración de Kea DHCP
Pasos a seguir: - Modificar el instalador de Opengnsys para que instale Kea DHCP - El script de instalación ejecutado por el pipeline deberá incluir la copia de los ficheros al tftpboot - Además también hay que incluir la bajada del ipxe para la generación de scripts embebidos - Script de Vagrant para que añada los PCs creado al reservations de la configuración de Kea DHCP
lgromero commented 2024-03-21 16:43:01 +01:00
Poster
Collaborator

Investigar tambien si se puede cargar por WIFI

Investigar tambien si se puede cargar por WIFI
lgromero added 1 commit 2024-04-11 12:56:35 +02:00
lgromero added 1 commit 2024-04-23 13:19:24 +02:00
lgromero added 1 commit 2024-04-23 14:29:44 +02:00
lgromero added 1 commit 2024-04-23 14:53:53 +02:00
lgromero added 1 commit 2024-04-24 10:55:34 +02:00
lgromero added 1 commit 2024-04-24 12:40:57 +02:00
lgromero added 1 commit 2024-04-24 12:42:10 +02:00
lgromero added 1 commit 2024-04-24 14:10:50 +02:00
lgromero added 1 commit 2024-04-24 14:33:43 +02:00
lgromero added 1 commit 2024-04-25 07:14:36 +02:00
lgromero added 1 commit 2024-04-25 07:45:47 +02:00
lgromero added 1 commit 2024-04-25 08:13:11 +02:00
lgromero added 1 commit 2024-04-25 08:38:16 +02:00
lgromero added 1 commit 2024-04-25 09:44:48 +02:00
lgromero added 1 commit 2024-04-25 10:35:25 +02:00
lgromero added 1 commit 2024-04-25 11:45:07 +02:00
lgromero commented 2024-04-26 14:14:00 +02:00
Poster
Collaborator

Tenemos un bug que hace que hace que le estamos pasando al kernel los mismos parámetros independientemente de los atributos del cliente. Por ejemplo los parámetros de kernel del PC12 son los mismos que el PC11 (ip incluida) y oglives muestra los datos iguales.

Tenemos un bug que hace que hace que le estamos pasando al kernel los mismos parámetros independientemente de los atributos del cliente. Por ejemplo los parámetros de kernel del PC12 son los mismos que el PC11 (ip incluida) y oglives muestra los datos iguales.
lgromero commented 2024-04-26 14:14:54 +02:00
Poster
Collaborator

Una solución es pasar como parámetro de entrada desde el Vagrant un array tal que así
declare -a clientes=(
"pc11:00:00:00:00:11:192.168.1.11"
"pc12:00:00:00:00:12:192.168.1.12"

)

Y luego setear los parametros del kernel

Una solución es pasar como parámetro de entrada desde el Vagrant un array tal que así declare -a clientes=( "pc11:00:00:00:00:11:192.168.1.11" "pc12:00:00:00:00:12:192.168.1.12" ) Y luego setear los parametros del kernel
lgromero added 1 commit 2024-04-30 08:18:43 +02:00
lgromero added 1 commit 2024-04-30 08:46:09 +02:00
lgromero added 1 commit 2024-04-30 10:38:01 +02:00
lgromero added 1 commit 2024-04-30 12:20:18 +02:00
lgromero added 1 commit 2024-04-30 12:41:28 +02:00
lgromero added 1 commit 2024-04-30 13:34:18 +02:00
lgromero removed review request for nserrano 2024-04-30 15:05:47 +02:00
lgromero requested review from nserrano 2024-04-30 15:05:57 +02:00
lgromero commented 2024-05-06 11:02:04 +02:00
Poster
Collaborator

Se ha corregido unos errores al generar la plantilla del script ipxe para cada cliente donde se le debía pasarle al kernel la ip y el nombre del PC como parámetro de entrada.

Se ha corregido unos errores al generar la plantilla del script ipxe para cada cliente donde se le debía pasarle al kernel la ip y el nombre del PC como parámetro de entrada.
nserrano commented 2024-05-06 11:54:57 +02:00
Collaborator

Después de seguir estos pasos:

  • BRANCH : "ogboot-installer-jenkins"
  • EXTRA_NAME el que uno quiera.
  • Añadir 2 ordenadores
  • Al terminar buscar la IP para acceder a la máquina más adelante
  • Ir al Vmware ESXI y buscar las máquinas creadas
  • Encender un cliente creado
  • Confirmar que se ha levantado el cliente correctamente

el cliente no levanta, ver captura adjunta. Trabajo de jenkins http://ognproject.evlt.uma.es:8080/jenkins/job/Deploy-devel-environment/270/console

Después de seguir estos pasos: - BRANCH : "ogboot-installer-jenkins" - EXTRA_NAME el que uno quiera. - Añadir 2 ordenadores - Al terminar buscar la IP para acceder a la máquina más adelante - Ir al Vmware ESXI y buscar las máquinas creadas - Encender un cliente creado - Confirmar que se ha levantado el cliente correctamente el cliente no levanta, ver captura adjunta. Trabajo de jenkins http://ognproject.evlt.uma.es:8080/jenkins/job/Deploy-devel-environment/270/console
Screenshot_2024-05-06_11-53-24.png
26 KiB
Screenshot_2024-05-06_11-53-24.png
nserrano commented 2024-05-06 11:55:46 +02:00
Collaborator

otra cosa, la rama que hay que usar en jenkins es "ogboot-installer-jenkins" pero la rama de este PR es "ipxe-study"? ¿cómo se come eso?

otra cosa, la rama que hay que usar en jenkins es "ogboot-installer-jenkins" pero la rama de este PR es "ipxe-study"? ¿cómo se come eso?
lgromero commented 2024-05-06 12:37:36 +02:00
Poster
Collaborator

Después de seguir estos pasos:

  • BRANCH : "ogboot-installer-jenkins"
  • EXTRA_NAME el que uno quiera.
  • Añadir 2 ordenadores
  • Al terminar buscar la IP para acceder a la máquina más adelante
  • Ir al Vmware ESXI y buscar las máquinas creadas
  • Encender un cliente creado
  • Confirmar que se ha levantado el cliente correctamente

el cliente no levanta, ver captura adjunta. Trabajo de jenkins http://ognproject.evlt.uma.es:8080/jenkins/job/Deploy-devel-environment/270/console

Me falto incluir la rama de OGBOOT_BRANCH: "ipxe_study". Ya lo he añadido, fallo mío. Vuelve a probar

> Después de seguir estos pasos: > > - BRANCH : "ogboot-installer-jenkins" > - EXTRA_NAME el que uno quiera. > - Añadir 2 ordenadores > - Al terminar buscar la IP para acceder a la máquina más adelante > - Ir al Vmware ESXI y buscar las máquinas creadas > - Encender un cliente creado > - Confirmar que se ha levantado el cliente correctamente > > el cliente no levanta, ver captura adjunta. Trabajo de jenkins http://ognproject.evlt.uma.es:8080/jenkins/job/Deploy-devel-environment/270/console > Me falto incluir la rama de OGBOOT_BRANCH: "ipxe_study". Ya lo he añadido, fallo mío. Vuelve a probar
lgromero commented 2024-05-06 12:39:58 +02:00
Poster
Collaborator

otra cosa, la rama que hay que usar en jenkins es "ogboot-installer-jenkins" pero la rama de este PR es "ipxe-study"? ¿cómo se come eso?

El motivo es que en la rama de Opengnsys usamos ogboot-installer-jenkins que incluye los cambios en el Vagrant para poder instalar el ogboot. Pero los cambios que hay que validar estan en la rama ipxe_study del repositorio ogboot.

> otra cosa, la rama que hay que usar en jenkins es "ogboot-installer-jenkins" pero la rama de este PR es "ipxe-study"? ¿cómo se come eso? El motivo es que en la rama de Opengnsys usamos ogboot-installer-jenkins que incluye los cambios en el Vagrant para poder instalar el ogboot. Pero los cambios que hay que validar estan en la rama ipxe_study del repositorio ogboot.
nserrano commented 2024-05-06 12:46:45 +02:00
Collaborator

y el PR de los cambios del Vagrantfile es... este? opengnsys/opengnsys#12

y el PR de los cambios del Vagrantfile es... este? https://ognproject.evlt.uma.es/gitea/opengnsys/opengnsys/pulls/12
lgromero commented 2024-05-06 13:12:10 +02:00
Poster
Collaborator

y el PR de los cambios del Vagrantfile es... este? opengnsys/opengnsys#12

esos cambios tengo que revisar unos conflictos con el vagrant, por ahora dejo cerrada la PR. Utiliza esa rama "ogboot-installer-jenkins" de opengnsys para validar la rama "ipxe-study" de ogboot que es la que estamos revisando en esta PR

> y el PR de los cambios del Vagrantfile es... este? https://ognproject.evlt.uma.es/gitea/opengnsys/opengnsys/pulls/12 esos cambios tengo que revisar unos conflictos con el vagrant, por ahora dejo cerrada la PR. Utiliza esa rama "ogboot-installer-jenkins" de opengnsys para validar la rama "ipxe-study" de ogboot que es la que estamos revisando en esta PR
nserrano commented 2024-05-06 13:21:02 +02:00
Collaborator

Bueno, tiene que haber dos PRs en tandem, uno en cada repo. Trabajar con varios repos, es lo que tiene.

Bueno, tiene que haber dos PRs en tandem, uno en cada repo. Trabajar con varios repos, es lo que tiene.
nserrano commented 2024-05-06 13:38:46 +02:00
Collaborator 
    og-ogboot-installer-jenkins-natipr2-admin: https://unizar:****@ognproject.evlt.uma.es/gitea/opengnsys/ogboot/raw/branch/ipxe_study/installer/ogboot_installer.sh
    og-ogboot-installer-jenkins-natipr2-admin:   % Total    % Received % Xferd  Aver
    og-ogboot-installer-jenkins-natipr2-admin: age Speed   Time  
    og-ogboot-installer-jenkins-natipr2-admin:   Time     Time  Current
    og-ogboot-installer-jenkins-natipr2-admin:               
    og-ogboot-installer-jenkins-natipr2-admin:                    Dloa
    og-ogboot-installer-jenkins-natipr2-admin: d  Upload   Total   S
    og-ogboot-installer-jenkins-natipr2-admin: pent    Left  Speed
    og-ogboot-installer-jenkins-natipr2-admin: 
  0     
    og-ogboot-installer-jenkins-natipr2-admin: 0    0     0    0    
    og-ogboot-installer-jenkins-natipr2-admin:  0      0      0 --:
    og-ogboot-installer-jenkins-natipr2-admin: --:-- --:--:-- --:--:
    og-ogboot-installer-jenkins-natipr2-admin: --     0
    og-ogboot-installer-jenkins-natipr2-admin: 
  0     0    0   
    og-ogboot-installer-jenkins-natipr2-admin:   0    0     0      0 
    og-ogboot-installer-jenkins-natipr2-admin:      0 --:--:-- --:--:-- --:--:-
    og-ogboot-installer-jenkins-natipr2-admin: -     0
    og-ogboot-installer-jenkins-natipr2-admin: curl: (22
    og-ogboot-installer-jenkins-natipr2-admin: ) The requ
    og-ogboot-installer-jenkins-natipr2-admin: ested URL returned error
    og-ogboot-installer-jenkins-natipr2-admin: : 404 Not Found
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.
Build step 'Ejecutar linea de comandos (shell)' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
An attempt to send an e-mail to empty list of recipients, ignored.
Finished: FAILURE

Por favor, pruébalo primero y cuando lo tengas funcionando avísame.

http://ognproject.evlt.uma.es:8080/jenkins/job/Deploy-devel-environment/271/console

``` og-ogboot-installer-jenkins-natipr2-admin: https://unizar:****@ognproject.evlt.uma.es/gitea/opengnsys/ogboot/raw/branch/ipxe_study/installer/ogboot_installer.sh og-ogboot-installer-jenkins-natipr2-admin: % Total % Received % Xferd Aver og-ogboot-installer-jenkins-natipr2-admin: age Speed Time og-ogboot-installer-jenkins-natipr2-admin: Time Time Current og-ogboot-installer-jenkins-natipr2-admin: og-ogboot-installer-jenkins-natipr2-admin: Dloa og-ogboot-installer-jenkins-natipr2-admin: d Upload Total S og-ogboot-installer-jenkins-natipr2-admin: pent Left Speed og-ogboot-installer-jenkins-natipr2-admin: 0 og-ogboot-installer-jenkins-natipr2-admin: 0 0 0 0 og-ogboot-installer-jenkins-natipr2-admin: 0 0 0 --: og-ogboot-installer-jenkins-natipr2-admin: --:-- --:--:-- --:--: og-ogboot-installer-jenkins-natipr2-admin: -- 0 og-ogboot-installer-jenkins-natipr2-admin: 0 0 0 og-ogboot-installer-jenkins-natipr2-admin: 0 0 0 0 og-ogboot-installer-jenkins-natipr2-admin: 0 --:--:-- --:--:-- --:--:- og-ogboot-installer-jenkins-natipr2-admin: - 0 og-ogboot-installer-jenkins-natipr2-admin: curl: (22 og-ogboot-installer-jenkins-natipr2-admin: ) The requ og-ogboot-installer-jenkins-natipr2-admin: ested URL returned error og-ogboot-installer-jenkins-natipr2-admin: : 404 Not Found 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. Build step 'Ejecutar linea de comandos (shell)' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any An attempt to send an e-mail to empty list of recipients, ignored. Finished: FAILURE ``` Por favor, pruébalo primero y cuando lo tengas funcionando avísame. http://ognproject.evlt.uma.es:8080/jenkins/job/Deploy-devel-environment/271/console
lgromero added 1 commit 2024-05-10 09:24:47 +02:00
lgromero commented 2024-05-10 10:48:36 +02:00
Poster
Collaborator

Se ha probado con la siguiente configuración:

  • BRANCH : "ogboot-installer-jenkins"
  • EXTRA_NAME lgromeropr2.
  • Añadir 2 ordenadores
  • OGBOOT_BRANCH: "ipxe-study"

Y funciona correctamente, levantando el ordenador por ipxe e iniciando ogbrowser

Se ha probado con la siguiente configuración: - BRANCH : "ogboot-installer-jenkins" - EXTRA_NAME lgromeropr2. - Añadir 2 ordenadores - OGBOOT_BRANCH: "ipxe-study" Y funciona correctamente, levantando el ordenador por ipxe e iniciando ogbrowser
Captura desde 2024-05-10 10-42-11.png
54 KiB
Captura desde 2024-05-10 10-47-27.png
56 KiB
Captura desde 2024-05-10 10-42-11.png Captura desde 2024-05-10 10-47-27.png
lgromero added 1 commit 2024-05-13 11:03:55 +02:00
nserrano commented 2024-05-14 14:24:57 +02:00
Collaborator

En el jenkins job aparece muchas veces "echoAndLog: command not found".

En etc/mac_script.ipxe.tmpl hay set kernelargs ip=IP_ADDRESS:192.168.2.1:192.168.2.1:255.255.255.0:HOSTNAME:eth0:none ogrepo=192.168.2.1 oglive=192.168.2.1 oglog=192.168.2.1 ogshare=192.168.2.1. Esas direcciones IP no pueden estar puestas a capón. Dependen del entorno de cada universidad.

En las plantillas, en general, es buena costumbre poner __IP_ADDRESS__ y __HOSTNAME__ con un par de subrayados antes y después del texto a reemplazar. O con porcentajes %HOSTNAME%. Pero sin nada, despista y queda frágil.

En installer/ogboot_installer.sh, ¿por qué comprobar cada dependencia una por una y llamar a apt dentro de un bucle? ¿por qué no instalar todo de golpe?

El propio instalador ¿debe ejecutarse como root o como usuario? Veo llamadas a sudo…

Algunas líneas tienen tabuladores y otras tienen espacios. Por favor revísalo todo y que sea consistente.

Veo que se hace mount -t nfs ognartefactos.evlt.uma.es:/ /mnt. Esto, ¿cuándo se desmonta? ¿queda montado? ¿y al reiniciar qué ocurre? Pero no importa, porque nadie en el mundo puede montar ognartefactos. No se puede hacer así.

Considera la alternativa de usar set -e en lugar de andar comprobando $? en cada paso. De hecho se suele recomendar set -euo pipefail.

En la función generate_ipxe_script() hay una llamada a eval. Por favor intenta no usar eval en código nuevo.

¿Qué es el archivo tftpboot/ipxe_scripts/01-00:50:56:22:11:11 con esa MAC específica?

En tftpboot/ipxe_scripts/default.ipxe hay set kernelargs ip=192.168.2.11:192.168.2.1:192.168.2.1:255.255.255.0:pc11:eth0:none ogrepo=192.168.2.1 oglive=192.168.2.1 oglog=192.168.2.1 ogshare=192.168.2.1. Lo mismo que antes, esas IP no pueden estar puestas así.

Los archivos binarios tftpboot/ipxe.efi y tftpboot/undionly.kpxe ¿hacen falta? No es buena práctica subir binarios a los repositorios de código.

En el servidor veo que existe /tmp/ipxe. Esto ¿no habría que borrarlo al terminar de instalar ogboot?

Y el ogboot propiamente dicho, ¿dónde queda instalado? No existe /opt/ogboot o similar.

En el jenkins job aparece muchas veces "echoAndLog: command not found". En `etc/mac_script.ipxe.tmpl` hay `set kernelargs ip=IP_ADDRESS:192.168.2.1:192.168.2.1:255.255.255.0:HOSTNAME:eth0:none ogrepo=192.168.2.1 oglive=192.168.2.1 oglog=192.168.2.1 ogshare=192.168.2.1`. Esas direcciones IP no pueden estar puestas a capón. Dependen del entorno de cada universidad. En las plantillas, en general, es buena costumbre poner `__IP_ADDRESS__` y `__HOSTNAME__` con un par de subrayados antes y después del texto a reemplazar. O con porcentajes `%HOSTNAME%`. Pero sin nada, despista y queda frágil. En `installer/ogboot_installer.sh`, ¿por qué comprobar cada dependencia una por una y llamar a apt dentro de un bucle? ¿por qué no instalar todo de golpe? El propio instalador ¿debe ejecutarse como root o como usuario? Veo llamadas a sudo… Algunas líneas tienen tabuladores y otras tienen espacios. Por favor revísalo todo y que sea consistente. Veo que se hace `mount -t nfs ognartefactos.evlt.uma.es:/ /mnt`. Esto, ¿cuándo se desmonta? ¿queda montado? ¿y al reiniciar qué ocurre? Pero no importa, porque nadie en el mundo puede montar ognartefactos. No se puede hacer así. Considera la alternativa de usar `set -e` en lugar de andar comprobando `$?` en cada paso. De hecho se suele recomendar `set -euo pipefail`. En la función `generate_ipxe_script()` hay una llamada a `eval`. Por favor intenta no usar eval en código nuevo. ¿Qué es el archivo `tftpboot/ipxe_scripts/01-00:50:56:22:11:11` con esa MAC específica? En `tftpboot/ipxe_scripts/default.ipxe` hay `set kernelargs ip=192.168.2.11:192.168.2.1:192.168.2.1:255.255.255.0:pc11:eth0:none ogrepo=192.168.2.1 oglive=192.168.2.1 oglog=192.168.2.1 ogshare=192.168.2.1`. Lo mismo que antes, esas IP no pueden estar puestas así. Los archivos binarios `tftpboot/ipxe.efi` y `tftpboot/undionly.kpxe` ¿hacen falta? No es buena práctica subir binarios a los repositorios de código. En el servidor veo que existe `/tmp/ipxe`. Esto ¿no habría que borrarlo al terminar de instalar ogboot? Y el ogboot propiamente dicho, ¿dónde queda instalado? No existe `/opt/ogboot` o similar.
lgromero closed this pull request 2024-09-26 10:26:22 +02:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
nserrano
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
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/ogboot#1
There is no content yet.
Delete Branch "ipxe-study"

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?