Files
SvenandClaude Opus 5 99757361ef first commit
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-20 11:05:58 +02:00

178 lines
7.6 KiB
Markdown

# Windows-Rollout
Zwei Skripte:
| Datei | Laeuft auf | Zweck |
|-----------------------------|------------|-----------------------------------------------------------|
| `deploy-windows.sh` | macOS/Linux| Version hochzaehlen, `.xpi` bauen, per SSH ausrollen |
| `Install-SwyxTabBridge.ps1` | Windows | Die eigentliche Installation; auch allein verwendbar |
## Schnellstart
```bash
./deploy/deploy-windows.sh
```
Ohne Parameter: Version hochzaehlen, bei AMO signieren, auf den Testrechner
uebertragen, Policy schreiben und den laufenden Firefox beenden, damit die
Installation sofort greift. Die Voreinstellungen stehen als Konstanten oben im
Skript:
| Konstante | Wert |
|--------------------------|-----------------------------------------------|
| `DEFAULT_HOST` | `swyx-dev` (Alias aus `~/.ssh/config`) |
| `DEFAULT_FIREFOX_DIR` | `C:\Users\dev\AppData\Local\Mozilla Firefox` |
| `DEFAULT_SIGN` | `true` |
| `DEFAULT_ALLOW_UNSIGNED` | `false` |
| `DEFAULT_STOP_FIREFOX` | `true` |
Ziel ist die **Release**-Installation, und die nimmt ausschliesslich signierte
Add-ons — deshalb signiert jeder Lauf. Das kostet pro Aufruf eine Versionsnummer
bei AMO; die wird ohnehin bei jedem Lauf hochgezaehlt.
Der Firefox-Pfad steht fest, weil auf dem Rechner zusaetzlich die Developer
Edition liegt und die automatische Suche bei zwei Funden abbricht. Fuer einen
anderen Rechner:
```bash
./deploy/deploy-windows.sh --host admin@ws-042 --firefox-dir auto
```
Ein bereits signiertes Paket laesst sich ohne neuen AMO-Durchlauf erneut
ausrollen:
```bash
./deploy/deploy-windows.sh --xpi build/56806207b7434031914b-1.0.16.xpi --no-bump
```
Jeder Aufruf zaehlt die Version in `manifest.json` hoch (Default: Patch-Stelle).
Das ist keine Kosmetik: Firefox installiert ein Paket mit gleicher oder
kleinerer Version nicht erneut, und AMO nimmt eine Version nur einmal zum
Signieren an. Steuern laesst es sich mit `--bump major|minor|patch|build|none`,
`--set-version X.Y.Z` oder `--no-bump`.
## Die Signatur ist der Knackpunkt
Firefox **Release und Beta** installieren ausschliesslich signierte Add-ons —
`xpinstall.signatures.required` wird dort ignoriert. Damit bleiben zwei Wege:
**Signieren (empfohlen, funktioniert ueberall).** Kanal `unlisted` =
Selbst-Hosting ohne Store-Eintrag:
```bash
./deploy/deploy-windows.sh --firefox-dir auto --require-signed --sign
```
Die Zugangsdaten liegen in `deploy/.amo-credentials` (Konto *AppCreation GmbH*)
und werden vom Skript selbst eingelesen. Die Datei traegt `chmod 600`, steht in
`.gitignore` und ist nicht Teil des Pakets — der Schluessel gilt fuer das
**gesamte AMO-Konto**, nicht nur fuer dieses Add-on. Neu erzeugen laesst er sich
unter addons.mozilla.org → *Tools**Manage API Keys* → *Revoke and regenerate
credentials*.
Bereits gesetzte Umgebungsvariablen haben Vorrang, ein einzelner Lauf laesst sich
also uebersteuern:
```bash
WEB_EXT_API_KEY="user:…" WEB_EXT_API_SECRET="…" ./deploy/deploy-windows.sh --sign
```
Die `gecko.id` im Manifest muss ueber alle Versionen stabil bleiben, und AMO nimmt
jede Versionsnummer nur einmal an — dafuer zaehlt das Skript bei jedem Aufruf hoch.
**Unsigniert (nur ESR, Developer Edition, Nightly).** Mit `--no-sign
--allow-unsigned` hinterlegt das Skript eine autoconfig-Datei, die
`xpinstall.signatures.required` auf `false` sperrt. Auf Firefox Release oder Beta
warnt es, weil die Einstellung dort wirkungslos bleibt. Fuer den normalen Betrieb
wird das nicht gebraucht.
Das Manifest fuehrt ausserdem `data_collection_permissions` mit
`required: ["browsingActivity"]` — seit dem 3. November 2025 Pflicht fuer neue
Erweiterungen auf AMO. Begruendung siehe Haupt-README.
## Policy oder Profil
`--mode policy` (Default) schreibt `<FirefoxDir>\distribution\policies.json` mit
`installation_mode: force_installed`. Das Add-on wird beim naechsten Start ohne
Rueckfrage fuer alle Profile installiert und laesst sich nicht deaktivieren.
Vorhandene Policies bleiben erhalten (die Datei wird zusammengefuehrt und vorher
gesichert). Das `.xpi` landet in `%ProgramData%\SwyxTabBridge\`, bei einer
Benutzerinstallation in `%LOCALAPPDATA%\SwyxTabBridge\`.
`--mode profile` legt das `.xpi` direkt in `<Profil>\extensions\` ab. Das wirkt
nur fuer die Profile eines Benutzers, und Firefox fragt beim naechsten Start
einmal nach Bestaetigung.
Massgeblich fuer die Rechte ist nicht "Admin ja/nein", sondern das Schreibrecht
im Firefox-Verzeichnis: eine Benutzerinstallation unter `%LOCALAPPDATA%\Mozilla
Firefox` laesst sich ohne jedes Sonderrecht mit einer Policy versehen, eine
Installation unter `C:\Program Files` braucht Administratorrechte.
## Laufender Firefox
Voreingestellt beendet das Skript den laufenden Firefox, damit die Installation
sofort greift statt erst beim naechsten Neustart; `--keep-firefox` laesst ihn in
Ruhe. Beendet wird dabei nur, was aus dem Zielverzeichnis gestartet wurde —
liegen wie auf dem Testrechner zwei Installationen nebeneinander, laufen beide
als `firefox.exe`, und die nicht adressierte bleibt offen. Firefox stellt die
Sitzung beim naechsten Start wieder her.
## SSH ohne Passwort
Der Testrechner ist bereits auf Schluessel-Anmeldung eingerichtet:
- Schluessel: `~/.ssh/id_ed25519_swyx_deploy` (ohne Passphrase, damit das
Deployment ohne Rueckfrage durchlaeuft)
- `~/.ssh/config` enthaelt den Alias `swyx-dev` mit Benutzer und Schluessel
- Auf dem Windows-Rechner liegt der oeffentliche Schluessel in
`C:\ProgramData\ssh\administrators_authorized_keys`
Der letzte Punkt ist die uebliche Stolperfalle: fuer Mitglieder der
Administratorengruppe liest der Windows-SSH-Dienst **nicht**
`~/.ssh/authorized_keys`, sondern jene zentrale Datei — und nur dann, wenn deren
ACL auf SYSTEM und Administratoren beschraenkt ist:
```powershell
icacls C:\ProgramData\ssh\administrators_authorized_keys `
/inheritance:r /grant "*S-1-5-18:F" /grant "*S-1-5-32-544:F"
```
Die SIDs statt der Namen, damit es auf deutschem Windows genauso greift.
Fuer einen Rechner ohne Schluessel oder mit Jumphost laesst sich ein eigener
Aufrufer davorhaengen:
```bash
SSH_CMD="sshpass -e ssh" SCP_CMD="sshpass -e scp" SSHPASS='…' \
./deploy/deploy-windows.sh --host dev@192.168.180.135
```
Die Kommandos gehen als UTF-16LE-Base64 (`powershell -EncodedCommand`) ueber die
Leitung. Dadurch ist egal, ob auf dem Ziel `cmd.exe` oder PowerShell die
Standard-Shell ist, und es gibt kein Quoting-Problem mit Leerzeichen oder
Backslashes.
## Weitere Optionen
```
--no-sign nicht signieren (nur mit --allow-unsigned sinnvoll)
--keep-firefox laufenden Firefox nicht beenden
--firefox-dir Installationsverzeichnis vorgeben (bei mehreren Installationen noetig)
--target-user Windows-Benutzer fuer --mode profile
--uninstall Policy, hinterlegtes Paket und Profil-Kopien entfernen
--build-only nur bauen
--dry-run nur anzeigen, was passieren wuerde
```
Exitcodes von `Install-SwyxTabBridge.ps1`: `0` Erfolg, `1` Fehler, `2` Erfolg,
aber Firefox muss noch neu gestartet werden.
## Danach pruefen
- `about:addons` — ist das Add-on da und aktiv?
- `about:policies#active` — hat Firefox die Policy gelesen?
- Symbolleisten-Icon: kein Badge = verbunden, `…` = Verbindungsaufbau, `!` = getrennt.
- Die Server-Adresse (Default `ws://127.0.0.1:17655`) liegt in
`browser.storage.local` und laesst sich von aussen nicht vorbelegen — bei
abweichender Adresse einmal ueber *Einstellungen* im Popup setzen.