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

oglivecli-no-daemon #5

Open
lgromero wants to merge 0 commits from oglivecli-no-daemon into main
pull from: oglivecli-no-daemon
merge into: opengnsys:main
Conversation 7 Commits - Files Changed -
lgromero commented 2024-08-08 10:17:02 +02:00
Collaborator

Pull Request: Probar y Validar Funciones de oglivecli como Usuario ogboot

Resumen

Este pull request cierra las historias #404 y #478 .tiene como objetivo probar y validar la funcionalidad de cada comando de oglivecli cuando es ejecutado por el usuario ogboot. El objetivo principal es asegurar que todos los comandos se ejecutan sin problemas sin necesidad de utilizar el demonio oglive, y confirmar que el usuario ogboot tiene los permisos necesarios para ejecutar cada comando exitosamente. A mayores incluye la instalación swagger como módulo en el composer.json en vez de descargarlo desde un repositorio externo. Esta rama se ha creado a partir de la rama de ogboot_installer ya que incluye el instalador de python que es necesario para aplicar los cambios de swagger+symfony y probarlo en Jenkins

Antecedentes

Actualmente, los comandos de oglivecli son ejecutados por un demonio con privilegios elevados. Para mejorar la seguridad y optimizar las operaciones, necesitamos validar que el usuario ogboot puede ejecutar todos los comandos de oglivecli directamente. Este cambio también implicará verificar los permisos sudo necesarios para el usuario ogboot.

Cambios

  1. Modificaciones en el Script: Ajustar el script de oglivecli para asegurar la compatibilidad y la correcta ejecución con los permisos adecuados.
  2. Actualización del Archivo sudoers: Asegurar que el usuario ogboot tiene los permisos necesarios para ejecutar los comandos requeridos sin solicitar la contraseña.
  3. Incorporación del Instalador ogboot_installer.py: Se ha añadido el instalador, ogboot_installer.py, para facilitar la instalación del entorno Symfony y el paquete actualizado de nelmio/api-doc-bundle, que incluye Swagger para la documentación.
  4. Cambios en permisos de directorios`: Dentro del instalador se incluye varios cambios de permisos en directorios necesarios para, por ejemplo, el montaje de oglives sin necesidad de sudo

Plan de Pruebas

  1. Creación de Máquinas Virtuales para Pruebas:

    Para crear y configurar las máquinas virtuales necesarias para las pruebas, lanzar un job en Jenkins con los siguientes parámetros:

    • OPENGNSYS_BRANCH: multivm-ogboot-installer
    • OGBOOT_BRANCH: oglivecli-no-daemon
    • VM1_COMPONENTS: componentes generales
    • VM2_COMPONENTS: ogboot

    Estos parámetros permiten configurar correctamente el entorno necesario para las pruebas.

  2. Validación de Swagger UI:
    Una vez completada la instalación y configuración, revisar la ip de la nueva máquina. Se puede comprobar entrando al vmware-esxi y accediendo a la máquina en cuestión. Ejecutar para obtener la ip de la máquina:

ip a

Abrir Swagger UI en el navegador usando la siguiente URL:

```
http://<SERVER_IP_OGBOOT>/api/doc
```

Revisar que toda la documentación de la API esté presente y que los endpoints funcionen correctamente.

  1. Validar endpoints:

    Para cada comando listado:

    • Ejecutar el comando como usuario ogboot.
    • Verificar que el comando se ejecuta correctamente y produce la salida esperada.
    • Documentar cualquier error o comportamiento inesperado.

Ejemplo de flujo de pruebas:

  1. Revisa las iso disponibles para descargar usando el endpoint GET /ogboot/v1/oglives/isos
  2. Instala el cliente ogLive usando el endpoint POST /ogboot/v1/oglives/install con el URL "iso_url": "https://ognproject.evlt.uma.es/trac/downloads/ogLive-focal-5.11.0-22-generic-amd64-r20210413.992ebb9.iso".
  3. Consulta la instalación usando GET /ogboot/v1/oglives/f7a8ba47d27d0fbceb82b55d8b5f8ccc.
  4. Configura el cliente como predeterminado con PUT /ogboot/v1/oglives/default/f7a8ba47d27d0fbceb82b55d8b5f8ccc.
  5. Desinstala el cliente utilizando DELETE /ogboot/v1/oglives/f7a8ba47d27d0fbceb82b55d8b5f8ccc.
### Pull Request: Probar y Validar Funciones de `oglivecli` como Usuario `ogboot` #### Resumen Este pull request cierra las historias #404 y #478 .tiene como objetivo probar y validar la funcionalidad de cada comando de `oglivecli` cuando es ejecutado por el usuario `ogboot`. El objetivo principal es asegurar que todos los comandos se ejecutan sin problemas sin necesidad de utilizar el demonio `oglive`, y confirmar que el usuario `ogboot` tiene los permisos necesarios para ejecutar cada comando exitosamente. A mayores incluye la instalación swagger como módulo en el composer.json en vez de descargarlo desde un repositorio externo. Esta rama se ha creado a partir de la rama de ogboot_installer ya que incluye el instalador de python que es necesario para aplicar los cambios de swagger+symfony y probarlo en Jenkins #### Antecedentes Actualmente, los comandos de `oglivecli` son ejecutados por un demonio con privilegios elevados. Para mejorar la seguridad y optimizar las operaciones, necesitamos validar que el usuario `ogboot` puede ejecutar todos los comandos de `oglivecli` directamente. Este cambio también implicará verificar los permisos sudo necesarios para el usuario `ogboot`. #### Cambios 1. **Modificaciones en el Script**: Ajustar el script de `oglivecli` para asegurar la compatibilidad y la correcta ejecución con los permisos adecuados. 2. **Actualización del Archivo `sudoers`**: Asegurar que el usuario `ogboot` tiene los permisos necesarios para ejecutar los comandos requeridos sin solicitar la contraseña. 3. **Incorporación del Instalador `ogboot_installer.py`**: Se ha añadido el instalador, `ogboot_installer.py`, para facilitar la instalación del entorno Symfony y el paquete actualizado de `nelmio/api-doc-bundle`, que incluye Swagger para la documentación. 3. **Cambios en permisos de directorios`**: Dentro del instalador se incluye varios cambios de permisos en directorios necesarios para, por ejemplo, el montaje de oglives sin necesidad de sudo #### Plan de Pruebas 1. **Creación de Máquinas Virtuales para Pruebas**: Para crear y configurar las máquinas virtuales necesarias para las pruebas, lanzar un job en Jenkins con los siguientes parámetros: - **OPENGNSYS_BRANCH**: `multivm-ogboot-installer` - **OGBOOT_BRANCH**: `oglivecli-no-daemon` - **VM1_COMPONENTS**: componentes generales - **VM2_COMPONENTS**: `ogboot` Estos parámetros permiten configurar correctamente el entorno necesario para las pruebas. 2. **Validación de Swagger UI**: Una vez completada la instalación y configuración, revisar la ip de la nueva máquina. Se puede comprobar entrando al vmware-esxi y accediendo a la máquina en cuestión. Ejecutar para obtener la ip de la máquina: ``` ip a ``` Abrir Swagger UI en el navegador usando la siguiente URL: ``` http://<SERVER_IP_OGBOOT>/api/doc ``` Revisar que toda la documentación de la API esté presente y que los endpoints funcionen correctamente. 3. **Validar endpoints**: Para cada comando listado: - Ejecutar el comando como usuario `ogboot`. - Verificar que el comando se ejecuta correctamente y produce la salida esperada. - Documentar cualquier error o comportamiento inesperado. ### Ejemplo de flujo de pruebas: 1. **Revisa las iso disponibles para descargar** usando el endpoint `GET /ogboot/v1/oglives/isos` 2. **Instala el cliente ogLive** usando el endpoint `POST /ogboot/v1/oglives/install` con el URL `"iso_url": "https://ognproject.evlt.uma.es/trac/downloads/ogLive-focal-5.11.0-22-generic-amd64-r20210413.992ebb9.iso"`. 3. **Consulta la instalación** usando `GET /ogboot/v1/oglives/f7a8ba47d27d0fbceb82b55d8b5f8ccc`. 4. **Configura el cliente como predeterminado** con `PUT /ogboot/v1/oglives/default/f7a8ba47d27d0fbceb82b55d8b5f8ccc`. 5. **Desinstala el cliente** utilizando `DELETE /ogboot/v1/oglives/f7a8ba47d27d0fbceb82b55d8b5f8ccc`.
lgromero added 104 commits 2024-08-08 10:17:02 +02:00
lgromero added 1 commit 2024-08-13 13:23:08 +02:00
lgromero added 2 commits 2024-08-13 14:36:24 +02:00
lgromero added 1 commit 2024-08-20 00:47:17 +02:00
lgromero added 1 commit 2024-08-20 12:47:04 +02:00
lgromero added 1 commit 2024-08-20 15:46:14 +02:00
lgromero added 2 commits 2024-08-21 10:01:22 +02:00
lgromero added 1 commit 2024-09-02 12:19:08 +02:00
lgromero requested review from nserrano 2024-09-04 09:14:35 +02:00
nserrano commented 2024-09-04 12:31:17 +02:00
Collaborator

apt

El instalador hace 49 llamadas a apt-get install:

[…]
    og-multivm-ogboot-installer-natipr1-boot: INFO	libjansson-dev installed correctly.
    og-multivm-ogboot-installer-natipr1-boot: INFO	liblz4-tool installed correctly.
    og-multivm-ogboot-installer-natipr1-boot: INFO	libssl-dev installed correctly.
    og-multivm-ogboot-installer-natipr1-boot: INFO	netpipes installed correctly.
[…]

Esto ya lo comenté en otro sitio. ¿Realmente no se puede instalar todo de una sola vez?

Igual también sería interesante ponerle --no-install-recommends para meter menos morralla en el sistema, pero hay que evaluarlo.

apache

Sale esto en la instalación:

    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: Starting apache2.service - The Apache HTTP Server...
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.2.1. Set the 'ServerName' directive globally to suppress this message
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: no listening sockets available, shutting down
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: AH00015: Unable to open logs
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: apache2.service: Failed with result 'exit-code'.
    og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: Failed to start apache2.service - The Apache HTTP Server.

Sistema

Esto habría que borrarlo:

$ ls /home/vagrant/
ogboot  ogboot.zip

Mejor sería crear un directorio temporal (usando mktemp), meter el instalador ahí y por último borrarlo. Sobre todo cuando luego existe un /tmp/ogboot_installer/ogboot que no es más que un symlink a la home.

API

GET /ogboot/help

Da un 500.

GET /ogboot/v1/status

{
  "disk_usage": {
    "total": "11G",
    "used": "7.7G",
    "available": "2.6G",

Habíamos comentado que el api no tiene que devolver valores presentables, sino los números duros.

    "oglive_daemon": "not installed",

Esto está bien así? ¿O igual lo deberíamos quitar?

GET /ogboot/v1/oglives/isos

Tarda bastante. ¿Es porque se conecta a la nube?

GET /ogboot/v1/oglives

Aparece información que ya aparece en /ogboot/v1/status. ¿Nos han pedido que aparezca lo mismo en los dos sitios?

GET /ogboot/v1/oglives/default

Estaría bien que apareciera el id del oglive.

POST /ogboot/v1/oglives/install

Sale un error:

{
  "details": {
    "status": "error",
    "error": "setsmbpass failed with SAMBAPASS."
  }

Si le doy otra vez, tarda lo mismo que la primera vez. Parece que vuelve a hacer todo el proceso a ciegas sin comprobar si ya está en local.

PUT /ogboot/v1/oglives/default

Con datos { "checksum": "hola" } devuelve "500 not found" pero debería ser 404 según la propia docu del endpoint.

GET /ogboot/v1/oglives/.

(ojo al /. final)

Devuelve lo mismo que GET /ogboot/v1/oglives. Creo que no es correcto, debería devolver que el oglive "." no existe. O mejor aún, que no es válido.

GET /ogboot/v1/oglives/..

Devuelve esto:

{
  "type": "https://tools.ietf.org/html/rfc2616#section-10",
  "title": "An error occurred",
  "status": 404,
  "detail": "Not Found"
}

¿De dónde sale?

DELETE /ogboot/v1/oglives/6153d21e7bd7f2486c027c5b9b3b93b6

Me deja borrar el oglive que está puesto por defecto. A partir de este momento, GET /ogboot/v1/oglives dice que el default es uno que ya no existe, y GET /ogboot/v1/oglives/default devuelve uno que ya no está instalado.

GET /ogboot/v1/pxes

La docu dice que en un 200 devuelve {"boot_files": ["string"]} pero obtengo {"boot_files": []}. ¿Es correcto en una instalación nueva?

POST /ogboot/v1/pxes

Con datos { "mac": "00:50:56:22:11:../../../../../../etc/passwd" } me ha dado un "500 Failed to create PXE boot file". Sospecho que el código se ha ido a escribir en /etc/passwd y le dio un pete de permisos.

Hay que validar los datos de entrada siempre.

GET /ogboot/v1/pxes/00%3A50%3A56%3A22%3A11%3A12..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd

No está documentado que el método devuelva 400, pero devuelve 400 seguido de HTML (no JSON).

GET /ogboot/v1/pxes/00%3A50%3A56%3A22%3A11%3A11%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd

(la misma que la anterior, pero con menos ../)

No está documentado que el método devuelva 404, pero devuelve 404 seguido de HTML (no JSON).

Además, que devuelva 400 en un caso y 404 en otro, significa que el código está haciendo cosas distintas. Sospecho que está yendo a /etc.

GET /ogboot/v1/pxes/00%3A50%3A56%3A22%3A11%3Amac

El PXE existe (lo he creado anteriormente) pero en la respuesta obtengo "template_name": "". Creo que debería haber algo en template_name.

GET /ogboot/v1/pxe-templates/.

Igual que antes, el /. final hace que el método se comporte como GET /ogboot/v1/pxe-templates.

GET /ogboot/v1/pxe-templates/pxe_default%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd

400 Bad request

GET /ogboot/v1/pxe-templates/pxe_default%2F

404 Not found, seguido de HTML.

Contenido del repo

Scripts de instalación

ls -l installer/
total 124
-rw-r--r-- 1 nati nati   297 20240904:094639+0200 config.json
-rwxr-xr-x 1 nati nati 40061 20240904:094639+0200 ogboot_devel_installer.sh*
-rwxr-xr-x 1 nati nati  2725 20240904:094639+0200 ogboot_devel_uninstall.sh*
-rwxr-xr-x 1 nati nati 43287 20240904:094639+0200 ogboot_installer.py*
-rwxr-xr-x 1 nati nati 30810 20240904:094639+0200 ogboot_installer.sh*

Los scripts de shell creo que no deberían existir.

Configuración del instalador

En installer/config.json pone

    "ogCore_ServerIP": "172.17.8.82",

Esa IP es un dato concreto de alguna instalación en particular que no debe estar en el repo.

Instalador

El instalador va como root. No debe haber sudo para hacer cosas como root.

Las llamadas a if subprocess.run(["echo", "$?"]) provocan esto en la salida de jenkins:

    og-multivm-ogboot-installer-natipr1-boot: $?

Es decir, que la comprobación de error no está funcionando bien. Lo que tienes que hacer, dado que estamos usando python, es hacer que servicesCompilation() y compañía provoquen una excepción si algo va mal, y luego en el código que las llama usar try/except.

## apt El instalador hace 49 llamadas a apt-get install: ``` […] og-multivm-ogboot-installer-natipr1-boot: INFO libjansson-dev installed correctly. og-multivm-ogboot-installer-natipr1-boot: INFO liblz4-tool installed correctly. og-multivm-ogboot-installer-natipr1-boot: INFO libssl-dev installed correctly. og-multivm-ogboot-installer-natipr1-boot: INFO netpipes installed correctly. […] ``` Esto ya lo comenté en otro sitio. ¿Realmente no se puede instalar todo de una sola vez? Igual también sería interesante ponerle `--no-install-recommends` para meter menos morralla en el sistema, pero hay que evaluarlo. ## apache Sale esto en la instalación: ``` og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: Starting apache2.service - The Apache HTTP Server... og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.2.1. Set the 'ServerName' directive globally to suppress this message og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80 og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80 og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: no listening sockets available, shutting down og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot apachectl[15793]: AH00015: Unable to open logs og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: apache2.service: Failed with result 'exit-code'. og-multivm-ogboot-installer-natipr1-boot: Sep 04 07:52:33 og-multivm-ogboot-installer-natipr1-boot systemd[1]: Failed to start apache2.service - The Apache HTTP Server. ``` ## Sistema Esto habría que borrarlo: ``` $ ls /home/vagrant/ ogboot ogboot.zip ``` Mejor sería crear un directorio temporal (usando `mktemp`), meter el instalador ahí y por último borrarlo. Sobre todo cuando luego existe un `/tmp/ogboot_installer/ogboot` que no es más que un symlink a la home. ## API ### `GET /ogboot/help` Da un 500. ### `GET /ogboot/v1/status` ``` { "disk_usage": { "total": "11G", "used": "7.7G", "available": "2.6G", ``` Habíamos comentado que el api no tiene que devolver valores presentables, sino los números duros. ``` "oglive_daemon": "not installed", ``` Esto está bien así? ¿O igual lo deberíamos quitar? ### `GET /ogboot/v1/oglives/isos` Tarda bastante. ¿Es porque se conecta a la nube? ### `GET /ogboot/v1/oglives` Aparece información que ya aparece en /ogboot/v1/status. ¿Nos han pedido que aparezca lo mismo en los dos sitios? ### `GET /ogboot/v1/oglives/default` Estaría bien que apareciera el id del oglive. ### `POST /ogboot/v1/oglives/install` Sale un error: ``` { "details": { "status": "error", "error": "setsmbpass failed with SAMBAPASS." } ``` Si le doy otra vez, tarda lo mismo que la primera vez. Parece que vuelve a hacer todo el proceso a ciegas sin comprobar si ya está en local. ### `PUT /ogboot/v1/oglives/default` Con datos `{ "checksum": "hola" }` devuelve "500 not found" pero debería ser 404 según la propia docu del endpoint. ### `GET /ogboot/v1/oglives/.` (ojo al `/.` final) Devuelve lo mismo que GET /ogboot/v1/oglives. Creo que no es correcto, debería devolver que el oglive "." no existe. O mejor aún, que no es válido. ### `GET /ogboot/v1/oglives/..` Devuelve esto: ``` { "type": "https://tools.ietf.org/html/rfc2616#section-10", "title": "An error occurred", "status": 404, "detail": "Not Found" } ``` ¿De dónde sale? ### `DELETE /ogboot/v1/oglives/6153d21e7bd7f2486c027c5b9b3b93b6` Me deja borrar el oglive que está puesto por defecto. A partir de este momento, `GET /ogboot/v1/oglives` dice que el default es uno que ya no existe, y `GET /ogboot/v1/oglives/default` devuelve uno que ya no está instalado. ### `GET /ogboot/v1/pxes` La docu dice que en un 200 devuelve `{"boot_files": ["string"]}` pero obtengo `{"boot_files": []}`. ¿Es correcto en una instalación nueva? ### `POST /ogboot/v1/pxes` Con datos `{ "mac": "00:50:56:22:11:../../../../../../etc/passwd" }` me ha dado un "500 Failed to create PXE boot file". Sospecho que el código se ha ido a escribir en /etc/passwd y le dio un pete de permisos. Hay que validar los datos de entrada **siempre**. ### `GET /ogboot/v1/pxes/00%3A50%3A56%3A22%3A11%3A12..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd` No está documentado que el método devuelva 400, pero devuelve 400 seguido de HTML (no JSON). ### `GET /ogboot/v1/pxes/00%3A50%3A56%3A22%3A11%3A11%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd` (la misma que la anterior, pero con menos `../`) No está documentado que el método devuelva 404, pero devuelve 404 seguido de HTML (no JSON). Además, que devuelva 400 en un caso y 404 en otro, significa que el código está haciendo cosas distintas. Sospecho que está yendo a /etc. ### GET `/ogboot/v1/pxes/00%3A50%3A56%3A22%3A11%3Amac` El PXE existe (lo he creado anteriormente) pero en la respuesta obtengo `"template_name": ""`. Creo que debería haber algo en template_name. ### `GET /ogboot/v1/pxe-templates/.` Igual que antes, el `/.` final hace que el método se comporte como `GET /ogboot/v1/pxe-templates`. ### `GET /ogboot/v1/pxe-templates/pxe_default%2F..%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd` 400 Bad request ### `GET /ogboot/v1/pxe-templates/pxe_default%2F` 404 Not found, seguido de HTML. ## Contenido del repo ### Scripts de instalación ``` ls -l installer/ total 124 -rw-r--r-- 1 nati nati 297 20240904:094639+0200 config.json -rwxr-xr-x 1 nati nati 40061 20240904:094639+0200 ogboot_devel_installer.sh* -rwxr-xr-x 1 nati nati 2725 20240904:094639+0200 ogboot_devel_uninstall.sh* -rwxr-xr-x 1 nati nati 43287 20240904:094639+0200 ogboot_installer.py* -rwxr-xr-x 1 nati nati 30810 20240904:094639+0200 ogboot_installer.sh* ``` Los scripts de shell creo que no deberían existir. ### Configuración del instalador En installer/config.json pone ``` "ogCore_ServerIP": "172.17.8.82", ``` Esa IP es un dato concreto de alguna instalación en particular que no debe estar en el repo. ### Instalador El instalador va como root. No debe haber `sudo` para hacer cosas como root. Las llamadas a `if subprocess.run(["echo", "$?"])` provocan esto en la salida de jenkins: ``` og-multivm-ogboot-installer-natipr1-boot: $? ``` Es decir, que la comprobación de error no está funcionando bien. Lo que tienes que hacer, dado que estamos usando python, es hacer que `servicesCompilation()` y compañía provoquen una excepción si algo va mal, y luego en el código que las llama usar `try`/`except`.
lgromero added 1 commit 2024-09-05 06:57:31 +02:00
lgromero added 1 commit 2024-09-06 09:43:42 +02:00
lgromero added 10 commits 2024-09-06 11:18:49 +02:00
lgromero added 1 commit 2024-09-06 11:21:14 +02:00
lgromero added 1 commit 2024-09-06 11:28:55 +02:00
nserrano commented 2024-09-06 14:58:00 +02:00
Collaborator

Más cositas:

Sistema

$ ls -l /opt/
drwxrwxr-x 15 ogboot ogboot 4096 Sep  4 07:54 ogboot
lrwxrwxrwx  1 root   root     12 Sep  4 07:56 opengnsys -> /opt/ogboot/

¿Podemos quitar el symlink y cambiar todas las referencias de "opengnsys" a "ogboot"?

Seguridad

Ser usuario ogboot es equivalente a ser root:

$ id
uid=1002(ogboot) gid=1002(ogboot) groups=1002(ogboot)
$ sudo cp /usr/bin/find /usr/bin/find.real
$ sudo cp /bin/bash /usr/bin/find
$ sudo /usr/bin/find
# id
uid=0(root) gid=0(root) groups=0(root)

Contenido del repo

.env

Diría que APP_SECRET hay que ponerlo en tiempo de instalación, no un valor fijo en el repo.

DATABASE_URL apunta a un postgresql. ¿Se usa el módulo dbal?

Sobre MESSENGER_TRANSPORT_DSN, ¿se usa el módulo messenger?

bin/composer.phar

¿Por qué usar este en lugar de /usr/bin/composer?

composer.lock

Debe estar en el repo, y el instalador no tiene que tocarlo. Ahora mismo el archivo no está, y el instalador lo borra como parte del despliegue.

bin/oglive_daemon.py

A partir del commit 7412653ebb creo que este no debe estar.

bin/oglivecli

oglivecli version no funciona:

ogboot@og-multivm-ogboot-installer-natipr1-boot:~$ /opt/ogboot/bin/oglivecli version
/opt/ogboot/bin/oglivecli: line 625: version: command not found

oglivecli help funciona de carambola. No está soportado, y al gestionar el error el código ejecuta raiseError usage.

Las siguientes funciones creo que no se usan:

  • check
  • list
  • show
  • search
  • download_old
  • update_json
  • add_message

bin/setsmbpass

Parece que no funciona, salen varios warnings y errores:

ogboot@og-multivm-ogboot-installer-natipr1-boot:/opt/ogboot/tftpboot$ id
uid=1002(ogboot) gid=1002(ogboot) groups=1002(ogboot)

ogboot@og-multivm-ogboot-installer-natipr1-boot:/opt/ogboot/tftpboot$ ls -l
total 1092
-rwxrwxr-x 1 tftp   ogboot 1030144 Sep  4 07:59 ipxe.efi
drwxrwxr-x 3 tftp   ogboot    4096 Sep  4 09:22 ipxe_scripts
lrwxrwxrwx 1 ogboot ogboot      23 Sep  4 09:02 ogLive -> ogLive-5.13.0-r20210706
drwxr-xr-x 2 ogboot ogboot    4096 Sep  4 08:57 ogLive-5.8.0-r20210413
drwxr-xr-x 2 ogboot ogboot    4096 Sep  4 08:56 ogLive-5.8.0-r20210413.old
lrwxrwxrwx 1 ogboot ogboot       6 Sep  4 08:57 ogclient -> ogLive
-rwxrwxr-x 1 tftp   ogboot   69785 Sep  4 07:56 undionly.kpxe

ogboot@og-multivm-ogboot-installer-natipr1-boot:/opt/ogboot/tftpboot$ /opt/ogboot/bin/setsmbpass ogLive-5.8.0-r20210413
Clave del usuario Samba: 
Confirmar clave: 
Configurando cliente "ogLive-5.8.0-r20210413" ...
Warning : using stdout as default output. Do not rely on this behavior: use explicit `-c` instead ! 
226802 blocks
jq: error: Could not open file /opt/opengnsys/etc/opengnsys.json: No such file or directory
jq: error: Could not open file /opt/opengnsys/etc/opengnsys.json: No such file or directory
chown: warning: '.' should be ':': ‘root.root’
/tmp/oglive68769
226803 blocks
/opt/opengnsys/tftpboot/ogLive-5.8.0-r20210413/oginitrd.img
dd: failed to open '/opt/opengnsys/tftpboot/ogLive-5.11.0-r20210413/oginitrd.img': No such file or directory
Error: No se pudo escribir el archivo comprimido en el destino.

Creo que por eso me topé con el error "setsmbpass failed with SAMBAPASS" anteayer.

config/

Aquí dentro no tengo mucha idea, pero en config/packages/framework.yaml yo descomentaría la línea #csrf_protection: true.

etc/dhcp_boot.ipxe.tmpl

set prefix tftp ...

Si esto es ipxe (a juzgar por el nombre del archivo) creo que ya puede usar http en lugar de tftp, ¿correcto?

etc/kea-dhcp4.conf.tmpl

La IP 192.168.2.1 sé de dónde viene y, aunque no me gusta tenerla ahí a capón, está puesta en más sitios y de momento tiene que quedarse.

Pero las IPs 192.168.8.1 y 192.168.9.1, ¿qué son? ¿Estaban ya puestas con el ISC dhcpd?

etc/mac_script.ipxe.tmpl

También usa tftp en lugar de http.

Tiene los kernelargs puestos a capón.

etc/nginxServer.conf.tmpl

        proxy_read_timeout 600;
        proxy_connect_timeout 600;
        proxy_send_timeout 600;
        send_timeout 600;

Esto habrá que quitarlo.

        fastcgi_pass unix:/run/php/php__PHPVERSION__-fpm.sock; # Asegúrate de que esto sea correcto

Este comentario en el repo, mejor quitarlo.

    location /tftpboot {  
        alias /opt/ogboot/tftpboot;
        autoindex on;               # Permitir listado de directorios

Yo quitaría el autoindex.

etc/oglive_daemon.service

A partir del commit 7412653ebb creo que este no debe estar.

tftpboot/ipxe_scripts/01-00:50:56:22:11:11

Este creo que hay que borrarlo.

tftpboot/ipxe_scripts/default.ipxe

Usa tftp en lugar de http.

Tiene los kernelargs puestos a capón.

Más cositas: ## Sistema ``` $ ls -l /opt/ drwxrwxr-x 15 ogboot ogboot 4096 Sep 4 07:54 ogboot lrwxrwxrwx 1 root root 12 Sep 4 07:56 opengnsys -> /opt/ogboot/ ``` ¿Podemos quitar el symlink y cambiar todas las referencias de "opengnsys" a "ogboot"? ## Seguridad Ser usuario `ogboot` es equivalente a ser `root`: ``` $ id uid=1002(ogboot) gid=1002(ogboot) groups=1002(ogboot) $ sudo cp /usr/bin/find /usr/bin/find.real $ sudo cp /bin/bash /usr/bin/find $ sudo /usr/bin/find # id uid=0(root) gid=0(root) groups=0(root) ``` ## Contenido del repo ### `.env` Diría que `APP_SECRET` hay que ponerlo en tiempo de instalación, no un valor fijo en el repo. `DATABASE_URL` apunta a un postgresql. ¿Se usa el módulo `dbal`? Sobre `MESSENGER_TRANSPORT_DSN`, ¿se usa el módulo `messenger`? ### `bin/composer.phar` ¿Por qué usar este en lugar de `/usr/bin/composer`? ### `composer.lock` Debe estar en el repo, y el instalador no tiene que tocarlo. Ahora mismo el archivo no está, y el instalador lo borra como parte del despliegue. ### `bin/oglive_daemon.py` A partir del commit 7412653ebb1248c3068c82ade5c18707a81fdc47 creo que este no debe estar. ### `bin/oglivecli` `oglivecli version` no funciona: ``` ogboot@og-multivm-ogboot-installer-natipr1-boot:~$ /opt/ogboot/bin/oglivecli version /opt/ogboot/bin/oglivecli: line 625: version: command not found ``` `oglivecli help` funciona de carambola. No está soportado, y al gestionar el error el código ejecuta `raiseError usage`. Las siguientes funciones creo que no se usan: * `check` * `list` * `show` * `search` * `download_old` * `update_json` * `add_message` ### `bin/setsmbpass` Parece que no funciona, salen varios warnings y errores: ``` ogboot@og-multivm-ogboot-installer-natipr1-boot:/opt/ogboot/tftpboot$ id uid=1002(ogboot) gid=1002(ogboot) groups=1002(ogboot) ogboot@og-multivm-ogboot-installer-natipr1-boot:/opt/ogboot/tftpboot$ ls -l total 1092 -rwxrwxr-x 1 tftp ogboot 1030144 Sep 4 07:59 ipxe.efi drwxrwxr-x 3 tftp ogboot 4096 Sep 4 09:22 ipxe_scripts lrwxrwxrwx 1 ogboot ogboot 23 Sep 4 09:02 ogLive -> ogLive-5.13.0-r20210706 drwxr-xr-x 2 ogboot ogboot 4096 Sep 4 08:57 ogLive-5.8.0-r20210413 drwxr-xr-x 2 ogboot ogboot 4096 Sep 4 08:56 ogLive-5.8.0-r20210413.old lrwxrwxrwx 1 ogboot ogboot 6 Sep 4 08:57 ogclient -> ogLive -rwxrwxr-x 1 tftp ogboot 69785 Sep 4 07:56 undionly.kpxe ogboot@og-multivm-ogboot-installer-natipr1-boot:/opt/ogboot/tftpboot$ /opt/ogboot/bin/setsmbpass ogLive-5.8.0-r20210413 Clave del usuario Samba: Confirmar clave: Configurando cliente "ogLive-5.8.0-r20210413" ... Warning : using stdout as default output. Do not rely on this behavior: use explicit `-c` instead ! 226802 blocks jq: error: Could not open file /opt/opengnsys/etc/opengnsys.json: No such file or directory jq: error: Could not open file /opt/opengnsys/etc/opengnsys.json: No such file or directory chown: warning: '.' should be ':': ‘root.root’ /tmp/oglive68769 226803 blocks /opt/opengnsys/tftpboot/ogLive-5.8.0-r20210413/oginitrd.img dd: failed to open '/opt/opengnsys/tftpboot/ogLive-5.11.0-r20210413/oginitrd.img': No such file or directory Error: No se pudo escribir el archivo comprimido en el destino. ``` Creo que por eso me topé con el error "setsmbpass failed with SAMBAPASS" anteayer. ### `config/` Aquí dentro no tengo mucha idea, pero en `config/packages/framework.yaml` yo descomentaría la línea `#csrf_protection: true`. ### `etc/dhcp_boot.ipxe.tmpl` ``` set prefix tftp ... ``` Si esto es ipxe (a juzgar por el nombre del archivo) creo que ya puede usar http en lugar de tftp, ¿correcto? ### `etc/kea-dhcp4.conf.tmpl` La IP 192.168.2.1 sé de dónde viene y, aunque no me gusta tenerla ahí a capón, está puesta en más sitios y de momento tiene que quedarse. Pero las IPs 192.168.8.1 y 192.168.9.1, ¿qué son? ¿Estaban ya puestas con el ISC dhcpd? ### `etc/mac_script.ipxe.tmpl` También usa tftp en lugar de http. Tiene los kernelargs puestos a capón. ### `etc/nginxServer.conf.tmpl` ``` proxy_read_timeout 600; proxy_connect_timeout 600; proxy_send_timeout 600; send_timeout 600; ``` Esto habrá que quitarlo. ``` fastcgi_pass unix:/run/php/php__PHPVERSION__-fpm.sock; # Asegúrate de que esto sea correcto ``` Este comentario en el repo, mejor quitarlo. ``` location /tftpboot { alias /opt/ogboot/tftpboot; autoindex on; # Permitir listado de directorios ``` Yo quitaría el autoindex. ### `etc/oglive_daemon.service` A partir del commit 7412653ebb1248c3068c82ade5c18707a81fdc47 creo que este no debe estar. ### `tftpboot/ipxe_scripts/01-00:50:56:22:11:11` Este creo que hay que borrarlo. ### `tftpboot/ipxe_scripts/default.ipxe` Usa tftp en lugar de http. Tiene los kernelargs puestos a capón.
nserrano commented 2024-09-10 15:58:08 +02:00
Collaborator

Instalador

Libs

import platform, os, sys, subprocess, datetime, shutil, pwd, glob, zipfile, urllib.request, logging, distro, re, json

Creo que zipfile y urllib.request no se usan.

Globales

Hay que usar el menor número de variables globales en general.

PROGRAM_NAME = os.path.basename(sys.argv[0])
OGCORE_SERVER = config["ogCore_Server"]
TFTPSERV = "tftpd-hpa"
INETDCFGDIR = "/etc/xinetd.d/"
INETDSERV = "xinetd"

Estas variables no se usan.

INSTALL_OGBOOT_TARGET = config["ogBoot_Dir"]
INSTALL_TARGET = config["ogBoot_Dir"]

Dos globales con el mismo valor.

Funciones

El sudo para hacer cosas como root sobra en todas partes.

Hay mucho código comentado. Yo lo borraría.

Los comentarios inútiles de chatgpt no aportan nada.

Cosas como subprocess.run(["mv", subprocess.run(["chown" y otros, se pueden hacer con python en lugar de llamar a comandos externos.

cidr2mask

Esta función está definida dos veces y no se usa.

get_missing_packages

Esta función hace:

    OSDISTRIB = distro.name()
    OSVERSION = distro.version()

Pero eso ya lo hace también autoConfigure() y no veo por qué hay que hacerlo otra vez.

En lugar de llamar a dpkg -s decenas de veces, se puede llamar una sola vez.

>>> import subprocess
>>> PACKAGES_TO_INSTALL = [ "nfs-common", "xorriso", "genisoimage", "syslinux", "liblzma-dev", "nginx", "arp-scan", "automake", "build-essential", "btrfs-progs", "composer", "curl", "ctorrent", "debootstrap", "g++-multilib", "gawk", "gettext", "graphviz", "grub-efi-amd64-signed", "jq", "libdbi-dev" ]
>>> installed = []
>>> for l in subprocess.run (['dpkg', '-s'] + PACKAGES_TO_INSTALL, capture_output=True, text=True).stdout.splitlines():
...     if l.startswith ('Package:'):
...         installed.append (l.split (':')[1].strip())
>>> to_install = list (set(PACKAGES_TO_INSTALL) - set(installed))

downloadComposer

No se usa.

og_core_create_user

El parámetro de esta función (OPENGNSYS_CLIENT_USER) coincide con una global. No es una buena práctica.

og_boot_create_dirs

El chown -R está en esta función y en otras, y no hace falta repetirlo. Se hace una sola vez al terminar la instalación.

og_boot_composer_install

¿Por qué una llamada a composer y luego otra a composer.phar?

backupFile

Esta función solo se usa una vez. Igual tiene sentido dejar el código inline allá donde se use.

testPxe

No se usa.

run_command

Se usa muchas veces, pero también hay muchas llamadas a subprocess.run. Hagámoslo de una manera o de otra.

tftpConfigure

    run_command("sudo mkdir -p /var/lib/tftpboot")
    run_command("sudo chown -R tftp:tftp /var/lib/tftpboot")
    run_command("sudo chmod -R 775 /var/lib/tftpboot")

Diría que /var/lib/tftpboot hay que dejarlo sin tocar, porque a) al instalar tftpd-hpa creo que ya debería aparecer con los permisos que el sistema necesita. Y si tocamos esas cosas y luego actualizamos tftpd-hpa, probablemente perdamos los cambios que le hagamos.

Yo quizá añadiría al usuario ogboot al grupo del directorio /var/lib/tftpboot y con eso quizá basta.

    run_command("sudo systemctl status tftpd-hpa")

Esto por qué se ejecuta? Luego no se comprueba nada...

        subprocess.run(["chown", "-R", "tftp:ogboot", TFTPCFGDIR])

Otro chmod sobre el mismo directorio?

        os.lchown(symlink_target, pwd.getpwnam("tftp").pw_uid, pwd.getpwnam("ogboot").pw_gid)
            os.lchown(symlink_target_ogLive, pwd.getpwnam("tftp").pw_uid, pwd.getpwnam("ogboot").pw_gid)
            os.lchown(symlink_target_ogclient, pwd.getpwnam("tftp").pw_uid, pwd.getpwnam("ogboot").pw_gid)

En linux los permisos de los symlinks no importan.

    iso_url = "https://ognproject.evlt.uma.es/trac/downloads/ogLive-focal-5.13.0-27-beta-amd64-r20210706.5b4bf5f.iso"

El oglive que se descarga no debería estar puesto a capón.

mask2cidr

No se usa.

getNetworkSettings

No se usa.

openGnsysConfigure

    CONSOLEURL = ""
    CONSOLEURL = f"https://{OGCORE_IP}/opengnsys"

Quitar la línea que sobra...

    TZ = subprocess.check_output(["timedatectl", "status"]).decode().split("\n")[2].split(":")[1].strip()

Seguro que hay otra forma de hallar la tz sin llamar a un comando externo y parsear la salida.

mount_NFS

Esta función hace mucho más que montar NFS.

    if subprocess.call(["sudo", "mount", "-t", "nfs", "ognartefactos.evlt.uma.es:/", "/mnt"]) == 0:

Esto no puede estar en el repo. Quien se clone el repo no puede montar el servidor de artefactos de la UMA.

    if subprocess.call(["sudo", "make", "-s", "-j", "4"]) == 0:

No hay que ponerle -j 4 sin saber el número de cores de la CPU del sistema destino.

smbConfigure

    subprocess.run(["perl", "-pi", "-e", "s/WORKGROUP/OPENGNSYS/; s/server string \\=.*/server string \\= ogBoot Samba Server/", f"{SAMBACFGDIR}/smb.conf"])

Esto que se hace con perl, seguro que también se puede hacer con python.

        nginx_conf_content = nginx_conf_content.replace("user www-data;", "user ogboot;")

Esto podría estar ya puesto en la plantilla y luego no sustituir nada. O en la plantilla podría poner __USER__ y luego sustituir el usuario.

(fuera de ninguna función)

if subprocess.run(["echo", "$?"]).returncode != 0:

Esto no funciona así.

# Instalador ## Libs ``` import platform, os, sys, subprocess, datetime, shutil, pwd, glob, zipfile, urllib.request, logging, distro, re, json ``` Creo que zipfile y urllib.request no se usan. ## Globales Hay que usar el menor número de variables globales en general. ``` PROGRAM_NAME = os.path.basename(sys.argv[0]) OGCORE_SERVER = config["ogCore_Server"] TFTPSERV = "tftpd-hpa" INETDCFGDIR = "/etc/xinetd.d/" INETDSERV = "xinetd" ``` Estas variables no se usan. ``` INSTALL_OGBOOT_TARGET = config["ogBoot_Dir"] INSTALL_TARGET = config["ogBoot_Dir"] ``` Dos globales con el mismo valor. ## Funciones El `sudo` para hacer cosas como root sobra en todas partes. Hay mucho código comentado. Yo lo borraría. Los comentarios inútiles de chatgpt no aportan nada. Cosas como `subprocess.run(["mv"`, `subprocess.run(["chown"` y otros, se pueden hacer con python en lugar de llamar a comandos externos. ### `cidr2mask` Esta función está definida dos veces y no se usa. ### `get_missing_packages` Esta función hace: ``` OSDISTRIB = distro.name() OSVERSION = distro.version() ``` Pero eso ya lo hace también `autoConfigure()` y no veo por qué hay que hacerlo otra vez. En lugar de llamar a `dpkg -s` decenas de veces, se puede llamar una sola vez. ``` >>> import subprocess >>> PACKAGES_TO_INSTALL = [ "nfs-common", "xorriso", "genisoimage", "syslinux", "liblzma-dev", "nginx", "arp-scan", "automake", "build-essential", "btrfs-progs", "composer", "curl", "ctorrent", "debootstrap", "g++-multilib", "gawk", "gettext", "graphviz", "grub-efi-amd64-signed", "jq", "libdbi-dev" ] >>> installed = [] >>> for l in subprocess.run (['dpkg', '-s'] + PACKAGES_TO_INSTALL, capture_output=True, text=True).stdout.splitlines(): ... if l.startswith ('Package:'): ... installed.append (l.split (':')[1].strip()) >>> to_install = list (set(PACKAGES_TO_INSTALL) - set(installed)) ``` ### `downloadComposer` No se usa. ### `og_core_create_user` El parámetro de esta función (`OPENGNSYS_CLIENT_USER`) coincide con una global. No es una buena práctica. ### `og_boot_create_dirs` El `chown -R` está en esta función y en otras, y no hace falta repetirlo. Se hace una sola vez al terminar la instalación. ### `og_boot_composer_install` ¿Por qué una llamada a `composer` y luego otra a `composer.phar`? ### `backupFile` Esta función solo se usa una vez. Igual tiene sentido dejar el código inline allá donde se use. ### `testPxe` No se usa. ### `run_command` Se usa muchas veces, pero también hay muchas llamadas a subprocess.run. Hagámoslo de una manera o de otra. ### `tftpConfigure` ``` run_command("sudo mkdir -p /var/lib/tftpboot") run_command("sudo chown -R tftp:tftp /var/lib/tftpboot") run_command("sudo chmod -R 775 /var/lib/tftpboot") ``` Diría que `/var/lib/tftpboot` hay que dejarlo sin tocar, porque a) al instalar tftpd-hpa creo que ya debería aparecer con los permisos que el sistema necesita. Y si tocamos esas cosas y luego actualizamos tftpd-hpa, probablemente perdamos los cambios que le hagamos. Yo quizá añadiría al usuario ogboot al grupo del directorio /var/lib/tftpboot y con eso quizá basta. ``` run_command("sudo systemctl status tftpd-hpa") ``` Esto por qué se ejecuta? Luego no se comprueba nada... ``` subprocess.run(["chown", "-R", "tftp:ogboot", TFTPCFGDIR]) ``` Otro chmod sobre el mismo directorio? ``` os.lchown(symlink_target, pwd.getpwnam("tftp").pw_uid, pwd.getpwnam("ogboot").pw_gid) os.lchown(symlink_target_ogLive, pwd.getpwnam("tftp").pw_uid, pwd.getpwnam("ogboot").pw_gid) os.lchown(symlink_target_ogclient, pwd.getpwnam("tftp").pw_uid, pwd.getpwnam("ogboot").pw_gid) ``` En linux los permisos de los symlinks no importan. ``` iso_url = "https://ognproject.evlt.uma.es/trac/downloads/ogLive-focal-5.13.0-27-beta-amd64-r20210706.5b4bf5f.iso" ``` El oglive que se descarga no debería estar puesto a capón. ### `mask2cidr` No se usa. ### `getNetworkSettings` No se usa. ### `openGnsysConfigure` ``` CONSOLEURL = "" CONSOLEURL = f"https://{OGCORE_IP}/opengnsys" ``` Quitar la línea que sobra... ``` TZ = subprocess.check_output(["timedatectl", "status"]).decode().split("\n")[2].split(":")[1].strip() ``` Seguro que hay otra forma de hallar la tz sin llamar a un comando externo y parsear la salida. ### `mount_NFS` Esta función hace mucho más que montar NFS. ``` if subprocess.call(["sudo", "mount", "-t", "nfs", "ognartefactos.evlt.uma.es:/", "/mnt"]) == 0: ``` Esto no puede estar en el repo. Quien se clone el repo no puede montar el servidor de artefactos de la UMA. ``` if subprocess.call(["sudo", "make", "-s", "-j", "4"]) == 0: ``` No hay que ponerle `-j 4` sin saber el número de cores de la CPU del sistema destino. ### `smbConfigure` ``` subprocess.run(["perl", "-pi", "-e", "s/WORKGROUP/OPENGNSYS/; s/server string \\=.*/server string \\= ogBoot Samba Server/", f"{SAMBACFGDIR}/smb.conf"]) ``` Esto que se hace con perl, seguro que también se puede hacer con python. ``` nginx_conf_content = nginx_conf_content.replace("user www-data;", "user ogboot;") ``` Esto podría estar ya puesto en la plantilla y luego no sustituir nada. O en la plantilla podría poner `__USER__` y luego sustituir el usuario. ### (fuera de ninguna función) ``` if subprocess.run(["echo", "$?"]).returncode != 0: ``` Esto no funciona así.
nserrano commented 2024-09-10 15:59:14 +02:00
Collaborator

Ah, y me olvidé de apt-get --allow-change-held-packages. ¿Por qué ese parámetro peligroso?

Ah, y me olvidé de `apt-get --allow-change-held-packages`. ¿Por qué ese parámetro peligroso?
lgromero added 1 commit 2024-09-11 11:48:18 +02:00
nserrano commented 2024-09-11 15:08:17 +02:00
Collaborator 
$ grep user /etc/fstab
UUID=C336-DC38                            /media/pendrive16gb        vfat    user,noauto     0 0

"user" significa que los usuarios pueden montar el filesystem UUID=C336-DC38 en /media/pendrive16gb.

``` $ grep user /etc/fstab UUID=C336-DC38 /media/pendrive16gb vfat user,noauto 0 0 ``` "user" significa que los **usuarios** pueden montar el filesystem `UUID=C336-DC38` en `/media/pendrive16gb`.
nserrano commented 2024-09-11 15:12:14 +02:00
Collaborator

Comandos que están en el instalador, en add_sudoers_permissions(), que proporcionan root instantáneo y por tanto hay que quitar sí o sí.

/usr/bin/mount, /usr/bin/cp, /usr/bin/tee, /usr/bin/sed, /usr/bin/gzip, /usr/bin/lz4, /usr/bin/cpio, /bin/tee, /usr/bin/dd, /usr/bin/rsync

Otros comandos no los veo obvios (eg. find) pero quizá también habría que quitarlos.

Idealmente deberíamos tirar sin sudo.

Comandos que están en el instalador, en `add_sudoers_permissions()`, que proporcionan root instantáneo y por tanto hay que quitar sí o sí. /usr/bin/mount, /usr/bin/cp, /usr/bin/tee, /usr/bin/sed, /usr/bin/gzip, /usr/bin/lz4, /usr/bin/cpio, /bin/tee, /usr/bin/dd, /usr/bin/rsync Otros comandos no los veo obvios (eg. `find`) pero quizá también habría que quitarlos. Idealmente deberíamos tirar sin sudo.
nserrano commented 2024-09-11 15:26:28 +02:00
Collaborator

mount con "user" en fstab:

/home/nati/Downloads/work/opengnsys/ogLive-focal-5.13.0-27-beta-amd64-r20210706.5b4bf5f.iso /home/nati/punto-de-montaje iso9660 user 0 0

Esto permite montar /home/nati/.../ogLive-focal...iso en /home/nati/punto-de-montaje.

Una línea similar se mete en el fstab en tiempo de instalación. Somos root así que no hay problema. No copies a ciegas todo. Lee la documentación (man fstab como punto de partida) y entiende qué significa "iso9660", "user", "0" y el otro "0".

Lo siguiente ya es simplemente crear el punto de montaje, montar, disfrutar y desmontar.

$ mkdir ~/punto-de-montaje
$ mount ~/punto-de-montaje
mount: /home/nati/punto-de-montaje: WARNING: source write-protected, mounted read-only.
$ ls ~/punto-de-montaje
isolinux/  ogclient/
$ umount ~/punto-de-montaje
mount con "user" en fstab: ``` /home/nati/Downloads/work/opengnsys/ogLive-focal-5.13.0-27-beta-amd64-r20210706.5b4bf5f.iso /home/nati/punto-de-montaje iso9660 user 0 0 ``` Esto permite montar `/home/nati/.../ogLive-focal...iso` en `/home/nati/punto-de-montaje`. Una línea **similar** se mete en el fstab en tiempo de instalación. Somos root así que no hay problema. No copies a ciegas todo. Lee la documentación (`man fstab` como punto de partida) y entiende qué significa "iso9660", "user", "0" y el otro "0". Lo siguiente ya es simplemente crear el punto de montaje, montar, disfrutar y desmontar. ``` $ mkdir ~/punto-de-montaje $ mount ~/punto-de-montaje mount: /home/nati/punto-de-montaje: WARNING: source write-protected, mounted read-only. $ ls ~/punto-de-montaje isolinux/ ogclient/ $ umount ~/punto-de-montaje ```
lgromero added 1 commit 2024-09-20 12:43:37 +02:00
lgromero added 1 commit 2024-09-24 10:28:49 +02:00
lgromero added 1 commit 2024-09-26 12:34:41 +02:00
lgromero added 1 commit 2024-09-27 08:31:37 +02:00
lgromero added 1 commit 2024-10-07 12:55:05 +02:00
lgromero added 1 commit 2024-10-14 17:53:23 +02:00
lgromero added 1 commit 2024-10-15 14:52:03 +02:00
lgromero added 1 commit 2024-10-15 16:44:01 +02:00
lgromero added 1 commit 2024-10-17 08:07:15 +02:00
lgromero added 1 commit 2024-10-18 08:24:44 +02:00
lgromero added 1 commit 2024-10-18 15:29:39 +02:00
lgromero added 1 commit 2024-10-21 12:32:08 +02:00
nserrano added 1 commit 2024-10-21 18:06:50 +02:00
lgromero added 1 commit 2024-10-22 09:46:13 +02:00
lgromero added 1 commit 2024-10-22 10:02:20 +02:00
nserrano added 1 commit 2024-10-22 11:55:58 +02:00
nserrano added 1 commit 2024-10-22 11:58:04 +02:00
nserrano added 1 commit 2024-10-22 12:23:48 +02:00
nserrano added 1 commit 2024-10-22 12:34:48 +02:00
nserrano added 1 commit 2024-10-22 13:18:40 +02:00
nserrano added 1 commit 2024-10-22 17:18:15 +02:00
nserrano added 1 commit 2024-10-22 17:28:06 +02:00
nserrano added 1 commit 2024-10-22 17:31:31 +02:00
lgromero added 1 commit 2024-10-22 21:30:44 +02:00
lgromero added 1 commit 2024-10-23 07:44:26 +02:00
lgromero added 1 commit 2024-10-24 10:59:21 +02:00
This pull request has changes conflicting with the target branch.
  • .env
  • bin/composer.phar
  • bin/console
  • bin/oglivecli
  • bin/setsmbpass
  • composer.json
  • config/bundles.php
  • config/services.yaml
  • installer/ogboot_installer.sh
  • lib/ogfunctions.sh
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b oglivecli-no-daemon main
git pull origin oglivecli-no-daemon

Step 2:

Merge the changes and update on Gitea.
git checkout main
git merge --no-ff oglivecli-no-daemon
git push origin main
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#5
There is no content yet.
Delete Branch "oglivecli-no-daemon"

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?