The dropdown is built from the hardcoded MODEL_CHOICES list in app.py, not from
OmniRoute, so 'ollama/qwen2.5*' existed upstream but could never appear in DSH.
- add ollama/qwen2.5:14b and ollama/qwen2.5-coder:14b to MODEL_CHOICES + MODEL_LABELS
- labels note that Ollama must be started first, since it now boots off on .27
- docs/dsh-architecture.md: new section on model selection, incl. the rebuild
requirement (app.py is baked into the image via COPY . .) and the ordering trap
that a model can be live in OmniRoute yet invisible in DSH
Verified: /api/models lists both ids on 3081-3084, and real streamed replies come
back from both local models through DSH.
The ollama card was wired to 'systemctl --user', but the .27 user unit was
removed when Ollama moved to services.ollama (NixOS system service). The panel
therefore reported Stopped while the service was Running and its buttons failed.
- new controller kind 'systemd-system' -> sudo -n <canonical systemctl> ...
- resolve systemctl to its store path first: NixOS puts a symlink on PATH but
the NOPASSWD sudoers rule names the store path, so bare 'sudo systemctl' does
not match (verified: full path exit=0, bare name 'a password is required')
- _remote() now shlex.join()s the remote command; ssh joins trailing argv with
spaces, which was word-splitting the 'sh -c' wrapper and failing with a sudo
usage error
- services.toml: ollama -> kind=systemd-system, target=ollama (matches the
sudoers rule verbatim), default_state=running
- docs/portal-architecture.md: document the three controller kinds + gotchas
Verified end-to-end from .13: start->running, stop->stopped, start->running,
real systemctl agrees, and /v1/models lists both qwen2.5 models over the LAN.
