Process model for running linbo-remote from the API

[TomlDev]

Following #29 and #31, the remaining LINBO gap on the API side is executing linbo-remote. Before writing anything I would rather ask how you want it shaped, because the answer commits the API to a process model that is awkward to change later.

Where things stand

linuxmusterTools.linbo.command.LinboRemote builds and validates the full command line — the 15 supported commands with their nr/msg rules, the mutual exclusion of group/room/ips, the wait-requires-wol rule. build() is complete. run() is:

def run(self):
    self.build()
    pass

(verified against the installed linuxmuster-tools7 7.4.6, not just git). The TODOs at the top of the module name the rest: run linbo command, add tmux support, add support for remote linbo server (per ssh).

So the missing piece is not the command construction, it is deciding what "running" means over HTTP.

The question

linbo-remote already has a process model: it runs each job in a tmux session, -l lists the sessions and -a <hostname> attaches to one. Two ways to expose that:

A — reuse the tmux sessions. run() starts linbo-remote detached, session names are the job IDs, -l is the job list. Cancellation and inspection come from upstream for free, and nothing is lost when the API restarts. Open question is how to surface output — tmux capture-pane versus a logfile written alongside.

B — a job store in linuxmusterTools. run() records state itself (in memory, or on disk under /srv/linbo). More control over status and output, at the cost of a second mechanism next to the tmux sessions that linbo-remote creates anyway, and state that has to survive a restart.

Whichever you prefer, the API side would be a thin set of routes over it — something like POST /linbo/remote returning a job id, plus GET/DELETE on /linbo/remote/jobs[/{id}], all RoleChecker("G") like the rest.

webui7's lmn_linbo_sync runs it synchronously (subprocess.Popen(...).stdout.read()), which is fine for a reboot and blocks for the length of a group sync, so we assumed that is not the pattern to copy here — but say if it is.

Two smaller things in the same area

• create_* and upload_* cannot be combined with host lists, -r or -g. Should the API reject that combination itself, or leave it to linbo-remote and pass the error back?
• Prestart commands are files (/srv/linbo/linbocmd/<host>.cmd) rather than a process. We were going to expose them as plain CRUD, separate from the job endpoints. Reasonable?

Happy to implement whichever direction you prefer, and to put the execution logic in linuxmuster-tools rather than the API, consistent with how linbo.py is written.

[kiarn]

Thanks, but I will write it myself ;)