Acht der vierzehn Units starteten ihr Programm ueber
/usr/local/bin/bullpen-*. Dorthin darf ein .deb nicht schreiben -
/usr/local gehoert dem Administrator (Debian Policy 9.1.2), und das
bullpen-Paket legt seine Einstiegspunkte folgerichtig nach /usr/bin.
Wer das Paket installiert und eine dieser acht Units aktiviert, bekam
203/EXEC. Sechs Units machten es schon richtig; jetzt alle vierzehn:
ExecStart=/usr/bin/env bullpen-<rolle>
`env` sucht ueber PATH und traegt damit BEIDE Aufstellungen - Paket
unter /usr/bin und Arbeitskopie mit Verweisen unter /usr/local/bin. Ein
fester /usr/bin-Pfad haette die Arbeitskopie gebrochen. Die
PATH=-Zeilen, die /usr/local/bin ENTHALTEN, bleiben genau deshalb
stehen: dort ist der Pfad eine Suchreihenfolge, keine Festlegung.
Dazu systemd/bullseye-server.service. Die Weboberflaeche lief seit dem
Umbau auf eine Unit, die es nur im Container gab - nicht im Repo, nicht
im Paket, also nirgends wiederherstellbar. Sie loest dasselbe
Zwei-Aufstellungs-Problem ueber PYTHONPATH statt ExecStart, weil
`python3 -m bullseye.server` das Verzeichnis UEBER bullseye/ braucht:
/usr/share/bullpen (Paket), /opt/bullpen-src (Container), %h/src/bullpen
(Arbeitskopie). Nicht vorhandene Eintraege ueberspringt Python still,
also darf alles dreifach dastehen. Nachgemessen am ausgepackten Paket:
`PYTHONPATH=/usr/share/bullpen python3 -c "import bullseye.server"` traegt.
marfrit
20416ff7e2