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

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.

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