Gemeldet von der ersten Pilotkunden-VM: "Missing privilege separation
directory: /run/sshd". Ubuntu 24.04 startet sshd ueber ssh.socket erst bei
der ersten Verbindung; /run/sshd legt systemd dabei an (RuntimeDirectory).
Auf einer frisch installierten VM, an der bisher nur die Hyper-V-Konsole
benutzt wurde, existiert das Verzeichnis deshalb nicht - und sshd -t bricht
ab, obwohl die Konfiguration einwandfrei ist. Auf der Test-VM fiel das nicht
auf, weil dort per SSH gearbeitet wurde.
Das Skript legt /run/sshd jetzt selbst an (0755, wie die Unit), laedt sshd
nur neu, wenn er ueberhaupt als Dienst laeuft, und gibt die wirksamen Werte
aus sshd -T aus. Sind sie nicht auslesbar, ist die Haertung unbewiesen und
der Lauf ein Fehler.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Einheitlich zum Rest des Vorhabens: /srv/espo, espo-deploy, espo-fleet-ops,
ESPO-xx, espo_*-Felder. Das Praefix nennt ausserdem das Produkt statt einer
Kategorie - 'crm' steht ohnehin schon im FQDN.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Unique Id ist in den Stammdaten ein Pflichtfeld und laut Dialog eindeutig -
kurz, stabil und vom Firmennamen unabhaengig: glasfaktor statt
glasfaktor-ingenieure-gmbh. Der Task uebergibt kuenftig %companyuniqueid%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der haengende ScreenConnect-Client wird ueber die Default-Policies geloest, damit
er gar nicht erst installiert wird - nicht im Skript. ESPO-01 ist damit wieder
auf seine neun Schritte zurueck, ESPO-02 auf die knappe Fehlerzeile.
Aus der offiziellen Docker-Doku bleibt, was dorthin gehoert: das Entfernen
konkurrierender Pakete vor der Installation und ca-certificates/curl vor dem
Schluessel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auf der Test-VM liegt der ScreenConnect-Client des Agenten im Zustand iU
(entpackt, nie konfiguriert), weil ihm java5-runtime fehlt. In diesem Zustand
blockiert er jede apt-Operation; ESPO-02 scheiterte daran, nicht an den
Docker-Pins.
ESPO-01 entfernt den Client jetzt als erstes (Paketname traegt je Geraet ein
anderes Suffix, daher Mustersuche), raeumt mit --fix-broken auf und bricht ab,
wenn apt danach immer noch gebrochene Abhaengigkeiten meldet. Damit ist O-20
im Skript erledigt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei apt-Fehler ohne eine einzige Zeile aus dem Skript liessen offen, ob
ueberhaupt die Repo-Fassung gelaufen ist. Die Standzeile beantwortet das
kuenftig in der ersten Ausgabezeile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Task entscheidet per If/Then auf espo_zustand, ob er laufen darf; die
Skripte brauchen den Wert dann nicht mehr. ESPO-01 nimmt nur noch den
Kundennamen, ESPO-02 kein Argument, ESPO-03 fqdn und ring.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz - sie beruht auf
Tatsachen auf der VM, nicht auf einem Feldwert, und verhindert eine Migration
ohne geprueftes Backup.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Statt lokaler Merkmale steuert das Custom Field espo_zustand zentral, was laufen
darf. Jedes der drei Skripte nimmt den Wert als Argument und bricht ohne
Aenderung ab, wenn er nicht NEU ist.
In ESPO-03 bleibt die Pruefung auf eine vorhandene Instanz als Rueckfall
erhalten: Der Zustand im RMM ist von Hand aenderbar, eine laufende Instanz ist
es nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
