Automatische Gitea Updates

Bereits im Januar dieses Jahres habe ich über meine Erfahrungen mit Gitea Updates berichtet. Das große Problem von Gitea ist, dass es sich nicht automatisch selbst aktualisiert. Ein Issue für das Problem ist schon seit fast 2 Jahren offen: https://github.com/go-gitea/gitea/issues/518#issuecomment-441742904

Ich hasse es wirklich, wenn sich eine sicherheitskritische Webanwendung nicht von selbst aktualisiert – das erlaubt Hackern ein leichtes Spiel. Vor vier Monaten habe ich nun schon die Entwicklung eines automatischen Gitea Update Skripts begonnen, welches ich nun vorstellen möchte.

Hinweise vor der Benutzung

Wie ich bereits erwähnt habe, bin ich kein Fan von manuellen Updates und schreibe deshalb für viele meiner Systeme Skripts zum automatischen Aktualisieren. Diese Programme sind schnell erstellt worden und auf meine Bedürfnisse angepasst und können unsauberen Code enthalten. Ich bin allerdings für Verbesserungsvorschläge in Form von Issues und Pull-Requests offen!

Manche Entwickler – wie der Ersteller von Kanboard – haben eine grundsätzliche Skepsis gegenüber automatischen Updates. Es gibt hierfür gute Gründe – du möchtest ja sicher nicht, dass deine Anwendung plötzlich aufgrund eines fehlerhaften Upgrades nicht mehr geht – deshalb empfehle ich automatische Upgrades nur, wenn auch automatische Backups eingerichtet sind.

Das Skript

Die veröffentliche Version meines Skripts kann auf GitHub gefunden werden: https://github.com/CMiksche/gitea-auto-update

Ich habe das Skript nur für mein Debian System entwickelt und getestet. Wenn das Skript einfach so auf Windows, MacOS oder Linux Systemen ohne Systemd ausgeführt wird, können Fehler nicht vermieden werden! Für diese Systeme muss das Skript definitv angepasst werden.

Wenn das Design von Gitea angepasst wurde, kann es sein, dass ein automatisches Upgrade dieses Template zerstört. Hierauf wird im Skript nicht geprüft.

Wie man mein Skript benutzt

Bitte zuerst die oberen Absätze lesen, ohne Beachtung dieser Hinweise kann es schnell in die Hose gehen!

Die Anwendung ist recht einfach:

  • Klone mein Skript auf das Zielsystem:
    git clone https://github.com/CMiksche/gitea-auto-update.git
  • Installiere requests:
    sudo pip install requests
  • Passe die Einstellungen in der settings.py Datei an
  • Führe den Befehl python updater.py aus, um das erste Upgrade zu testen
  • Wenn die Updates regelmäßig automatisch ausgeführt werden sollen, bearbeite die /etc/crontab Datei und rufe dort einen Aufruf des Skripts aus

So einfach geht das. Wenn du auf Probleme stößt, zögere nicht einen Issue oder Pull-Request auf Github zu erstellen oder hier einen Kommentar zu hinterlassen.

Diesen Beitrag habe ich auch auf Englisch veröffentlicht.

Automatische Backups bei Shared Webhosting

Bei Shared Webhosting Angeboten ist es oft schwierig, kostenlose automatische Backups zu realisieren. Oft sind Backups sowie Cron Jobs (soweit überhaupt verfügbar) kostenpflichtig.

Zudem funktionieren viele der im Internet verfügbaren Skripts nur auf Servern und die, die auch bei Webhosting Services funktionieren, gehen manchmal nicht mehr …

Deshalb habe ich ein Skript für automatische Dateisystem & Datenbank Backups erstellt. Nachfolgend möchte ich die Funktionen sowie die Anwendung des Skriptes erläutern.

Link zum Projekt: https://git.kernel.fun/cmiksche/php-sharedhost-backup

Funktionen / Features

  • Erstellt Datenbank-Backups
  • Erstellt Dateisystem-Backups, die entweder mit ZIP oder GZ komprimiert werden können
    • Bei der Komprimierung mit ZIP können auch Verzeichnisse ausgeschlossen werden
  • Backups können nach X Tagen automatisch gelöscht werden
  • Das Skript kann von extern aufgerufen werden
  • Lizenziert unter der GNU General Public License 3.0

Anwendung

  • Zuerst sollte die Konfiguration wie Datenbankzugangsdaten in den Konstanten der backup.php Datei eingetragen werden
  • Anschließend können die Dateien auf dem Webspace hochgeladen werden
    • Sicherheitshinweise
      • Nicht das .git Verzeichnis hochladen!
      • Im Standardbackupverzeichnis „backup“ ist nur ein Schutz der Dateien unter Apache eingerichtet – unter nginx und anderen Webservern bitte selbst absichern!
  • Nun kann man einen Cron Job auf einem externen System (z.B.: heimischer Raspberry Pi) einrichten, der die backup.php Datei täglich aufruft.

Anregungen, Fehler oder Verbesserungsvorschläge?! Schreibe einen Kommentar!