- deploy.sh zweistufig: Sperre, laufende Update-Jobs verschieben den Deploy, fast-forward, dann laeuft die NEUE Fassung als Stufe 2 (Aenderungen am Skript wirken sofort). Stufe 2: Prueftor, Abhaengigkeiten, llama-swap-Config nur bei Aenderung des Abzugs in diesem Deploy (ohne Motor-Neustart, -watch-config reicht; 5 Sicherungen), alle Repo-Units und Drop-ins, Cron-Skripte nach ~/.hermes/scripts, Skills/Plugins, Neustart, Nachpruefung. Scheitert etwas: zurueck auf den alten Stand (inkl. llama-swap-Config), Dienste neu, dringende Meldung, Eintrag in /srv/models/mc2-deploy.log. - deploy/pruefen.sh ersetzt die tote CI-Ampel: Shell-/Python-Syntax, ruff, Importe, pytest. Laeuft am PC vor dem Push und auf der Box vor dem Umschalten (pytest via requirements-dev.txt). - Units, die nur auf der Box lagen, jetzt im Repo: projekte-sync.*, lucy-stimme.service, mission-control-2-Override. - Tot und entfernt: Werkstatt-/Projektstart-/Betrieb-SOULs, worker.sh, Agent-Hooks, Ampel-CI (samt .gitea-Workflow und Saat in gitea-repo-create.sh), gitea-pr, Governor-Plugin, Specs, Selbst-Inventur, Self-Smoke, venv-Audit, setup_autonomous_crons.sh (haette alte Jobs neu angelegt), Einmal-Skripte, alte Bench-Skripte, .agents/mcp_config.json, client/ide-skills, mcp/requirements.txt. Gitea-Host-Notizen nach docs/archiv/gitea-host. - morgenmeldung.sh begrenzt das Melde-Log (ueber 3 MB bleiben die letzten 2 MB). - AGENTS.md: Prueftor und neuer Deploy beschrieben. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
Security Memo: Gitea Registrierung deaktivieren
Status
Aktuell: Registrierung ist OFFEN (Standard-Gitea-Setup)
Ziel: DISABLE_REGISTRATION = true in [security] Abschnitt der app.ini setzen
Risiko
- DDNS-Endpunkt (
git.tobisniceshomelab.ddnsfree.com) ist öffentlich erreichbar - Version im Footer (1.26.2) identifizierbar — potenziell anfällige Version
- Jeder kann sich ohne Genehmigung registrieren → potenzielle Angreifer/Spammer
Empfohlene Maßnahme
- Auf dem Gitea-Server (Proxmox LXC
192.168.178.153) in/etc/gitea/app.iniim Abschnitt[security]die ZeileDISABLE_REGISTRATION = truehinzufügen - Gitea neu starten:
sudo systemctl restart gitea(oder wie auch der Service heißt)
Commander-Approval notwendig
- ⚠️ Diese Änderung ist nur im laufenden Betrieb auf dem Gitea-Server vorzunehmen
- Branch
wartung/gitea-disable-registrationenthält eine Beispielkonfiguration und Dokumentation - Bitte bestätige mit "JA", dass du die Änderung freigibst, damit sie auf dem Server umgesetzt werden kann
Hinweis
Ohne Commander-Ja: keine Änderung an der Gitea-Instanz vornehmen. Die Sicherheitslücke bleibt bestehen, bis die Freigabe erfolgt.
Erstellt am: 2026-07-17
Branch: wartung/gitea-disable-registration