Invario/Key-service-Server
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Refactor and streamline project setup and management scripts

Browse Source 
- Removed `run.sh` and `test.sh` scripts to simplify the project structure.
- Added `setup-first-install.sh` to handle initial setup tasks with options to skip specific steps.
- Updated `invario-stack-autostart.service` to use `gitea.sh` for starting the stack on boot.
- Removed `start-stack-on-boot.sh` as its functionality is now integrated into the service.
- Enhanced `admin_system.html` with a new live logs panel, including automatic updates and log source selection.
- Improved CSS styles for the new logs panel for better UI consistency.
- Added JavaScript functionality to fetch and display live logs from the server.
This commit is contained in:
Aiirondev
2026-04-18 20:09:44 +02:00
parent 09cb8306ff
commit d9b812812f
12 changed files with 815 additions and 848 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+108 -134
View File
@@ -1,173 +1,119 @@
# Key Service Server
Dieses Repo nutzt zwei zentrale Shell-Skripte:
- `gitea.sh`: Start/Stop/Status der Docker-Services (Gitea + Website)
- `nginx.sh`: Nginx Reverse Proxy, SSL-Zertifikate und Aktivierung/Deaktivierung der Sites
Dieses Repository ist auf einen schlanken, Docker-first Betrieb ausgerichtet.
## Voraussetzungen
- Docker + Docker Compose Plugin
- Docker Engine + Docker Compose Plugin
- Nginx
- OpenSSL
- Optional: UFW (wird automatisch fuer 80/443 konfiguriert, wenn aktiv)
- Optional: UFW (Ports 80/443 werden bei aktivem UFW automatisch freigegeben)
## 1) Docker Services (`gitea.sh`)
## Script Matrix
### Core-Skripte (aktiv)
- [gitea.sh](gitea.sh)
- Start/Stop/Restart/Status für Gitea + Website-Stack
- [nginx.sh](nginx.sh)
- Nginx-Konfiguration anwenden/deaktivieren
- [Website/provision_instance.sh](Website/provision_instance.sh)
- Instanz-Provisioning für Inventarsystem (release-basiert, Multiinstancing-aware)
- [Website/launch_dev.sh](Website/launch_dev.sh)
- Dev-Start der Website inkl. Host-Sync
- [Website/launch_prod.sh](Website/launch_prod.sh)
- Prod-Start der Website inkl. Host-Sync
- [Website/start_docker_build.sh](Website/start_docker_build.sh)
- Build/Start-Helfer für Website-Container
- [Website/sync_dev_hosts.sh](Website/sync_dev_hosts.sh)
- Synchronisiert dynamische Subdomains in /etc/hosts
### Setup-Skripte (optional, aktiv)
- [setup-first-install.sh](setup-first-install.sh)
- Führt Erstinstallation in einem Ablauf aus (Start, Nginx, Hosts-Sync-Service, Autostart-Service)
- [setup-hosts-sync.sh](setup-hosts-sync.sh)
- Installiert den systemd-Service für automatische Hosts-Synchronisierung
- [setup-stack-autostart.sh](setup-stack-autostart.sh)
- Installiert den systemd-Service für Stack-Autostart über gitea.sh
### Legacy-Skripte (entfernt)
- start-stack-on-boot.sh (durch direkten systemd-ExecStart auf gitea.sh ersetzt)
- provision_instance.sh im Repo-Root (Duplikat, Website-Version ist Single Source)
- Website/run.sh (alt, nicht Teil des aktuellen Flows)
- Website/test.sh (alt, nicht Teil des aktuellen Flows)
## Core Betrieb
### Docker Services
Datei: [gitea.sh](gitea.sh)
### Befehle
Befehle:
- `sudo ./gitea.sh start`
- Erstellt/aktualisiert Gitea Compose unter `/opt/gitea-server/docker-compose.yml`
- Startet Gitea und Website Docker Services
- Schreibt Runtime-Werte nach `/opt/gitea-server/runtime.env` fuer Nginx
- sudo ./gitea.sh start
- sudo ./gitea.sh stop
- sudo ./gitea.sh restart
- sudo ./gitea.sh status
- `sudo ./gitea.sh stop`
- Stoppt Gitea und Website Docker Services
Wichtige Ports:
- `sudo ./gitea.sh restart`
- Entspricht `stop` gefolgt von `start`
- Gitea intern: 127.0.0.1:3001
- Gitea SSH: 2222
- Website Upstream: 4999
- `sudo ./gitea.sh status`
- Zeigt laufende Container fuer Gitea/Website an
### Wichtige Ports
- Gitea intern: `127.0.0.1:3001` (fix)
- Gitea SSH: `2222`
- Website Upstream: `4999`
## 2) Nginx (`nginx.sh`)
### Nginx
Datei: [nginx.sh](nginx.sh)
### Befehle
Befehle:
- `sudo ./nginx.sh apply`
- Liest Runtime-Werte aus `/opt/gitea-server/runtime.env`
- Erstellt Nginx Site-Konfigurationen fuer:
- `update.meine-domain` -> Gitea
- `meine-domain` -> Website
- Prueft Zertifikate im Ordner `/etc/nginx/certs`
- Falls Zertifikate fehlen: erzeugt self-signed Zertifikate automatisch
- Testet Nginx-Konfiguration und laedt Nginx neu
- sudo ./nginx.sh apply
- sudo ./nginx.sh disable
- sudo ./nginx.sh deactivate
- `sudo ./nginx.sh disable`
- `sudo ./nginx.sh deactivate`
- Deaktiviert die verwalteten Nginx Sites (`gitea`, `website`)
- Testet und laedt Nginx neu
## Typischer Ablauf
1. Docker Services starten:
```bash
sudo ./gitea.sh start
```
2. Nginx konfigurieren/aktivieren:
```bash
sudo ./nginx.sh apply
```
3. Status pruefen:
```bash
sudo ./gitea.sh status
```
4. Nginx bei Bedarf deaktivieren:
```bash
sudo ./nginx.sh disable
```
## Nginx Templates
Die Nginx-Vorlagen liegen unter [nginx](nginx):
Nginx-Templates:
- [nginx/gitea.http.conf.template](nginx/gitea.http.conf.template)
- [nginx/gitea.https.conf.template](nginx/gitea.https.conf.template)
- [nginx/website.http.conf.template](nginx/website.http.conf.template)
- [nginx/website.https.conf.template](nginx/website.https.conf.template)
## Admin: Schul-Instanzen fuer Subdomains
## Inventarsystem Instanzen
Die Website hat jetzt eine Admin-Seite zum Starten von Inventarsystem-Instanzen pro Schule:
Admin-Oberfläche:
- Route: `/admin/instances`
- Admin-Menue: `Schul-Instanzen`
- Ziel-Repository (Standard): `https://github.com/AIIrondev/legendary-octo-garbanzo`
- Route: /admin/instances
- Menu: Schul-Instanzen
### Ablauf
Provisioning-Flow:
1. Admin gibt Schulname (und optional Subdomain) ein.
2. Admin weist die Instanz einem konkreten Nutzer zu.
3. Admin wählt eine Version (Image-Tag) pro Nutzer/Instanz.
4. Admin kann das Bibliotheksmodul für die Instanz aktivieren/deaktivieren.
5. Backend ruft `provision_instance.sh` auf.
6. Skript klont/aktualisiert die Instanz unter dem Basisverzeichnis.
7. Skript startet die Instanz (`start.sh --no-cron`) und versucht eine Nginx-Site fuer die Subdomain anzulegen.
8. Status wird in MongoDB (`school_instances`) gespeichert und im Admin-Fenster angezeigt.
1. Admin wählt Nutzer, Schule, Version und optional Subdomain.
2. Backend ruft [Website/provision_instance.sh](Website/provision_instance.sh) auf.
3. Provisioning installiert release-basiert aus GitHub-Releases.
4. Wenn verfügbar, wird docker-compose-multitenant.yml bevorzugt genutzt.
5. Instanzstatus wird in school_instances gespeichert.
Hinweis: Die Zuweisung ist auf `eine Instanz pro Nutzer` begrenzt.
Wichtige Website-Variablen:
### Wichtige Environment-Variablen (Website)
- INSTANCE_REPO_URL (default: https://github.com/AIIrondev/legendary-octo-garbanzo)
- INSTANCE_PARENT_DOMAIN (default: meine-domain)
- INSTANCE_BASE_DIR (default: /opt/inventarsystem-instances)
- INSTANCE_PROVISION_SCRIPT (default: Website/provision_instance.sh)
- `INSTANCE_REPO_URL` (default: `https://github.com/AIIrondev/legendary-octo-garbanzo`)
- `INSTANCE_PARENT_DOMAIN` (default: `meine-domain`)
- `INSTANCE_BASE_DIR` (default: `/opt/inventarsystem-instances`)
- `INSTANCE_PROVISION_SCRIPT` (default: `Website/provision_instance.sh`)
Berechtigungen für Provisioning:
### Berechtigungen
- Docker-Zugriff
- Schreibrechte auf /etc/nginx/sites-available und /etc/nginx/sites-enabled
- nginx -t und nginx reload/signal-Rechte
Das Provisioning-Skript fuehrt Docker- und Nginx-Operationen aus. Der Prozess, der die Website ausfuehrt, braucht daher:
## Betriebsmodi Website
- Zugriff auf `docker` (Docker Socket / Gruppe)
- Schreibrechte auf `/etc/nginx/sites-available` und `/etc/nginx/sites-enabled`
- Recht zum `nginx -t` und `nginx -s reload`
- Development: [Website/launch_dev.sh](Website/launch_dev.sh)
- Production: [Website/launch_prod.sh](Website/launch_prod.sh)
Wenn diese Rechte fehlen, wird die Instanz ggf. trotzdem gestartet, aber die Nginx-Verknuepfung muss manuell erfolgen.
### Nutzerfenster: Eigene Instanz verwalten
Eingeloggte Nutzer haben im Nutzerbereich jetzt den Punkt `Meine Instanz`.
- Route: `/my/instance`
- Funktion: Nur zugewiesene Instanz einsehen und nutzen (read-only)
- Zuordnung: ueber `owner_username`
## Admin: System-Tools
Neue Admin-Seite fuer Betriebsaufgaben:
- Route: `/admin/system`
- Funktionen:
- Core-Services neu starten (`website`, `mongodb`)
- Core-Logs als Datei herunterladen
- Pro Instanz: Backup, Update, Restart
- Pro Instanz: Logs als Datei herunterladen
## Betriebsmodi: Development und Production
Im Ordner `Website/` gibt es zwei Launcher-Skripte:
- `./launch_dev.sh`
- setzt `INSTANCE_TLS_MODE=development`
- erzeugt pro Subdomain self-signed Zertifikate (wenn moeglich)
- synchronisiert die Dev-Hosts jetzt beim Start und danach regelmaessig neu
- setzt `SESSION_COOKIE_SECURE=0`
- `./launch_prod.sh`
- setzt `INSTANCE_TLS_MODE=production`
- nutzt Wildcard-Zertifikat ueber:
- `INSTANCE_WILDCARD_CERT_FILE`
- `INSTANCE_WILDCARD_KEY_FILE`
- setzt `SESSION_COOKIE_SECURE=1`
Beispiel Production-Start mit eigener Domain:
Beispiel Production:
```bash
cd Website
@@ -175,4 +121,32 @@ export INSTANCE_PARENT_DOMAIN=example.de
export INSTANCE_WILDCARD_CERT_FILE=/etc/nginx/certs/wildcard.example.de.crt
export INSTANCE_WILDCARD_KEY_FILE=/etc/nginx/certs/wildcard.example.de.key
./launch_prod.sh
```
```
## Empfohlener Ablauf
1. sudo ./gitea.sh start
2. sudo ./nginx.sh apply
3. sudo ./gitea.sh status
## Erstinstallation (automatisiert)
Für eine neue Maschine kann die Erstinstallation in einem Schritt ausgeführt werden:
```bash
sudo ./setup-first-install.sh
```
Standardmäßig macht das Skript:
1. Startet den Stack über gitea.sh.
2. Wendet nginx.sh apply an.
3. Installiert den Hosts-Sync-systemd-Service.
4. Installiert den Stack-Autostart-systemd-Service.
Optionen:
- --skip-start
- --skip-nginx
- --skip-hosts-sync
- --skip-autostart