Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

LINBO hardware groups have no school ownership: LinboConfigManager ignores its school argument

Abierto
  • ¿Algo no está bien?
#36 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, databases

Línea de trabajo

Examine linuxmusterTools/linbo/config.py to understand the LinboConfigManager class and how it currently ignores the school argument. Look at the file paths in /srv/linbo/ to see the flat structure. Check the linuxmuster-api routers_v1/linbo.py for the TODO comment. Determine if LINBO's TFTP/PXE boot process requires a flat layout or can support per-school directories. The goal is to modify the config manager to respect the school argument, potentially changing file paths and updating enumeration logic.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What we ran into

LinboConfigManager accepts a school argument and then never uses it, so the LINBO hardware groups are one flat, server-wide set rather than per-school data.

In usr/lib/python3/dist-packages/linuxmusterTools/linbo/config.py (branch lmn74):

LINBO_PATH = '/srv/linbo'

class LinboConfigManager:
    def __init__(self, school='default-school'):
        self.school = school
        ...

    def _list_group_ids(self):
        group_ids = []
        for config in sorted(glob(os.path.join(LINBO_PATH, 'start.conf.*'))):
            ...

self.school is stored and never read; enumeration globs LINBO_PATH directly. The same holds for reading and writing a group's start.conf — every path is /srv/linbo/start.conf.<id>, with no school component.

linuxmuster-api already documents this as the blocker for opening the routes up, in routers_v1/linbo.py:

# TODO: startconfs/configs (this section) stay G-only on purpose — group_id has
# no school ownership anywhere in linuxmusterTools.linbo (raw, flat, global
# /srv/linbo/start.conf.<id>), same gap as the legacy lmn_linbo4 plugin. Opening
# to school-admins needs real per-school ownership in lmntools first, not a
# quick RoleChecker flip.

So this issue is just the concrete request behind that TODO, filed where the ownership would have to live.

Why it matters to us

We build the LINBO UI in edulution-ui. It has a school selector, and on a multi-school server a user reasonably reads that selector as scoping the hardware groups they are editing. It does not — a change to a group applies to every school on the server.

Passing school through to the API endpoints would not have changed that; it would only have made our code look school-correct while upstream ignored the value. So we shipped an explicit notice in the UI instead, telling the user the groups are server-wide wherever a server runs more than one school. That is the honest behaviour for today's data model, but it is a workaround for a limitation, not the outcome we want.

What would help

Real per-school ownership of the LINBO group configuration in linuxmusterTools.linbo, so that LinboConfigManager(school=...) enumerates, reads and writes only that school's groups. Concretely, the two questions we cannot answer from the outside:

  1. Is a per-school layout on the table at all — e.g. /srv/linbo/<school>/start.conf.<id>, or a school prefix in the group id — or is the flat set a deliberate property of how LINBO serves clients over TFTP/PXE, where a single boot path has to resolve without knowing a school?
  2. If a per-school layout is possible, what would the migration look like for existing installations, and would school='default-school' keep meaning "the flat set" for compatibility?

Happy to help with whichever direction you prefer — including doing the work, if you can say which layout you would accept. If the answer is that the flat set is intentional and permanent, that is a useful answer too: we would then document the server-wide scope as the designed behaviour rather than carry it as a known gap.

Versions

  • linuxmuster-tools branch lmn74, linuxmusterTools/linbo/config.py
  • linuxmuster-api branch lmn74, routers_v1/linbo.py
Lenguaje dominante
Python
Estrellas
3
Forks
5
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de linuxmuster/linuxmuster-tools

Todos los issues de linuxmuster/linuxmuster-tools

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.