Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#36 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
backend, databases

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
Python
Estrelas
3
Forks
5
Nenhum PR com merge em 30d

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de linuxmuster/linuxmuster-tools

Todas as issues de linuxmuster/linuxmuster-tools

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.