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.

Debian 9 Upgrade mit nginx und PHP 7.2

Ich habe nun alle meine Debian Systeme auf die neueste Version „Stretch“ ohne größere Probleme aktualisieren können.

Da ich in den letzten Jahren allerdings immer größere Probleme hatte und weiß, dass eine gute Anleitung hilfreich sein kann, möchte ich hier meine Vorgehensweise anhand eines Webservers mit Debian 8 beschreiben.

Hintergrund

Gerade bei Webservern ist eine Aktualisierung wichtig, da Sicherheitslücken den Server schnell zu einer Virenschleuder verwandeln können.

Sollte PHP auf dem Webserver verwendet werden, führt kaum ein Weg an einem Upgrade vorbei, da Debian 8 keine aktuelle PHP-Version ausliefert. (Debian 9 zwar auch nicht wirklich aber dazu später mehr …)

Vorbereitung

Folgende Punkte führe ich immer vor einer Webserver-Aktualisierung durch:

  • Wartungsmodus in WordPress / anderen CMS aktivieren
    • Bei größeren Projekten die Nutzer über das Upgrade informieren
  • Wichtige Verzeichnisse sichern (sollte man generell regelmäßig machen), z.B.:
    • Webserver-Verzeichnis (/var/www)
    • /opt Verzeichnis (bei manuell hinzugefügter Software)
    • /home Verzeichnisse (Daten der Unix-Nutzer)
  • Wichtige Dateien sichern
    • z.B.: /etc/crontab mit regelmäßig ausgeführten Skripten
  • Alle Datenbanken sichern

Aktuelle Pakete herunterladen

Mit

apt update

und danach

apt upgrade

aktualisiert man die aktuellen Pakete.

Alte Sources sichern

Damit man bei Problemen schnell wieder auf Debian Jessie wechseln kann, ist eine Sicherung der alten Sources List hilfreich:

cp /etc/apt/sources.list /etc/apt/sources.list_backup

Wichtig: Sollte es auch Dateien unter /etc/apt/sources.list.d geben, ist auch eine Sicherung dieser Dateien nicht überflüssig!

Neue Sources pflegen

Nun sollte man den Namen der alten Version durch den Namen der neuen Version in der Sources.list und allen anderen Dateien unter z.B.: /etc/apt/sources.list.d aktualisieren. sed ist für solche Aufgaben perfekt geeignet:

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

Pakete aktualisieren

Nachdem wir nun die Quellen auf die neue Version geändert haben, können wir die Paketquellen mit den folgenden Befehl aktualisieren:

apt update

Anschließend aktualisieren wir die Pakete wieder mit:

apt upgrade

Hier kann es sein, dass wir den Befehl mehrmals ausführen müssen und gefragt werden, ob wir die aktuellen Konfigurationsdateien behalten wollen oder neue Konfigurationsdateien übernehmen (letzteres sollte nur gemacht werden, wenn nichts an den Konfigurationen geändert wurde).

Systemupgrade abschließen

Mit den bisherigen Befehlen wurden noch nicht alle Pakete aktualisiert. Um das Systemupgrade abzuschließen, benötigen wir eine Ausführung des folgenden CLI-Befehls:

apt dist-upgrade

Systemupgrade prüfen

Nach einem großen Upgrade empfiehlt sich ein Neustart, welcher mit

reboot

durchgeführt werden kann.

Um festzustellen, ob wir die gewünschte Version haben, kann man diese mit cat ausgeben lassen:

cat /etc/issue

PHP aktualisieren

Zum Zeitpunkt dieses Posts gibt es noch keinen mir bekannten Weg, um PHP direkt von den Debian Sources zu beziehen. Deshalb müssen für PHP 7.2 Fremdquellen genutzt werden. Bei Fremdquellen sollte immer auch auf das Sicherheitsrisiko geschaut werden.

Vorerst sollten wir PHP deinstallieren:

apt purge php*

Anschließend den Schlüssel des fremden Repos importieren:

wget -qO - https://packages.sury.org/php/apt.gpg | sudo apt-key add -

Um dann die Quelle in eine Sources List zu speichern:

sudo echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Die Paketquellen aktualisieren wir wieder mit:

apt update

Nun können wir endlich die neue Version von PHP installieren:

sudo apt install php7.2

(hier können natürlich auch noch weitere Pakete wie php7.2-imap gewählt werden)

nginx anpassen

Da ich gerne nginx als Webserver verwende, musste ich für die neue PHP-Version auch den Socket in den sites-available aktualisieren.

Dafür wechseln wir erst in das Verzeichnis der virtual Hosts:

cd /etc/nginx/sites-available/

Danach bearbeiten wir die gewünschte Website mit einem Editor unserer Wahl – z.B.: nano.

Wir suchen erst nach fastcgi_pass und passen die Zeile dann wie folgt an:

fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;

Um die Änderung aktiv zu schalten, müssen wir den Webserver noch neu starten:

systemctl restart nginx.service

Ich hoffe, meine Erklärung des Debian Upgrades war hilfreich. Wenn ihr zukünftig Tutorials zu Themen wie Debian Webserver erhalten möchtet, könnt ihr mir gerne auf Twitter folgen.

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!

Piwik / WordPress Remote Update

Wie ich teilweise bereits auf meinem persönlichen Blog erwähnt habe, wurden von mir in letzter Zeit Python Scripts zum Aktualisieren von WordPress und Piwik über die Kommandozeile geschrieben.

Wenn man diese z.B.: als Cronjob laufen lässt, kann man von einem entfernten Gerät die Piwik- oder WordPress Instanz automatisch aktualisieren lassen.

Das ist in manchen Fällen recht nützlich.

Downloaden kann man die beiden Programme von GitHub, eine Installationsanleitung ist in der jeweiligen README.md Datei:

Bei Fehlern / Problemen kann gerne im jeweiligen GitHub Repo ein Issue erstellt werden.

Tutorial: Einen Debian Server absichern

In letzter Zeit werden immer wieder Server für Projekte von „Wronnay“ eingerichtet. Um das Ganze etwas bequemer zu machen, wurde von mir ein Bash-Script erstellt, dass die Grundeinrichtung etwas vereinfacht. Ich möchte jetzt eine kleine Anleitung veröffentlichen, die die Verwendung dieses Scripts erklärt.

Informationen über das Script:

  • Es steht unter der GNU General Public License
  • Es aktualisiert die installieren Pakete
  • Es installiert folgende Pakete: ufw rkhunter fail2ban nano sudo htop whois
  • Es setzt einen Cronjob für tägliche Paket-Updates
  • Es erstellt eine Grundkonfiguration für die Firewall „ufw“
  • Es erstellt einen neuen Benutzer
  • Der Standard-Port für SSH wird geändert und der Login mit dem „root“ – User verboten

Verwendung:

Bevor das Script heruntergeladen werden kann, müssen erst die nötigen Pakete zur Verwendung installiert werden:

Zuerst benötigen wir Root-Rechte:

su

Jetzt installieren wir die benötigten Pakete:

apt-get install nano git

Nun können wir das Script downloaden:

git clone https://github.com/CMiksche/DebianServerBasicConfig.git

Anschließend wechseln wir in das Verzeichnis:

cd DebianServerBasicConfig

Und geben in der config.sh – Datei unsere gewünschten Daten (Benutzername, Passwort, SSH-Port) ein:

nano config.sh

Nach dem Abspeichern der Datei geben wir der Install-Datei noch die passenden Rechte:

chmod 0777 install.sh
chown root install.sh

So. Jetzt können wir die Datei auch ausführen:

./install.sh

Danach müssen wir nur noch das Script löschen:

cd ..
rm -R DebianServerBasicConfig

Fertig. Bei dem nächsten Einloggen über SSH ist jetzt nur noch zu beachten, das man den neuen Port, Benutzer und das neue Passwort verwenden muss.

Wronnay Software Lizenz

Wie bereits unter CMS.Wronnay.net angekündigt, wird die nächste Version (2.0) des WronnayCMS einige Änderungen mit sich bringen. Eine davon wird sein, dass die Software nicht mehr kostenlos verfügbar sein wird. (Davon ausgenommen sind von WebPage4.Me gehostete Varianten)

Das Content Management System wird die Basis aller anderen Websysteme von Wronnay. (Also auch für z.B.: das Wronnay Board – der Weiterentwicklung der Forensoftware)

Um nun ein Exemplar dieser Software erwerben zu können, wird man eine Lizenz benötigen. Diese wird man bei einer Firma, die noch gegründet wird, kaufen können.

Die Bedingungen der Lizenz werden immer auf dem aktuellsten Stand in Englisch unter dem nachfolgenden Link aufrufbar sein: http://license.wronnay.net/ (Bevor das WronnayCMS verkauft wird, werden diese Bedingungen allerdings noch überarbeitet werden)

Diese Bedingungen werden in Zukunft in jeder kostenpflichtigen Software von Wronnay als Kopie enthalten sein.

Tutorial: Benutzername und E-Mail Überprüfung

Ich habe ein Script gebastelt, dass alle Benutzernamen auf verbotene Usernamen und alle E-Mail-Adressen auf E-Mail-Adressen von Wegwerf-Email-Diensten überprüft.

Wer es verwenden will und nicht mehr als 25 Mal am Tag ausführt, kann es gerne nutzen:

<?php
/* Check for illegal Usernames and / or Emails
* Created: 15.02.2015 by Christoph Daniel Miksche (Wronnay)
* Uses the Wronnay Database for illegal Usernames and Emails
* More Informations: check.wronnay.net
*/
function wcms_namecheck($username, $email){
$username = str_replace(' ', '_', $username); // Wandelt Leerzeichen in _ um
$username = strtolower($username); // Wandelt alle Buchstaben in Kleinbuchstaben um
$email = str_replace(' ', '_', $email);
$email = strtolower($email);
// Nur die Domain wird benötigt
$email = substr(strrchr($email, "@"), 1);
// Wronnay E-Mail-Check API-URL
$locked_email = file_get_contents('http://check.wronnay.net/locked_email.php?domain='.$email);
// Leerzeichen raus!
$locked_email = str_replace(' ', '', $locked_email);
// Wronnay Username-Check API-URL
$locked_username = file_get_contents('http://check.wronnay.net/locked_username.php?username='.$username);
// Leerzeichen raus!
$locked_username = str_replace(' ', '', $locked_username);
// Default Wert für den Check setzen
$found = false;
// Username: Check
if($locked_username == 'true') {
$found = true;
}
// E-Mail-Check
elseif($locked_email == 'true') {
$found = true;
}
return $found;
}
?>

Update: ForenSoftware 0.7

Heute habe ich die neueste Version meiner ForenSoftware (PHP-Script für das Erstellen eines Forums) veröffentlicht. Es wurden vor allem neue Funktionen hinzugefügt, die von so manchem User gewünscht wurden.

Wichtigste Neuerungen:

  • Automatische Suche nach Aktualisierungen
  • E-Mail-Aktivierung bei Registrierung (Im Admin-Bereich aktivierbar)
  • E-Mail bei Antworten auf das Thema an den Threadersteller
  • E-Mail bei neuen Nachrichten
  • E-Mail bei neuem Passwort
  • Besucherzähler

Diese Neuheiten werden wohl auch in der nächsten Version meines Content Management Systems (des WronnayCMS) zu finden sein.

Downloaden kann man die ForenSoftware hier: http://scripts.wronnay.net/?s=php&id=3

Eigentlich wollte ich solche Neuheiten ausschließlich auf der Webseite meiner ForenSoftware veröffentlichen, aber die existiert seit meinem Problem mit Dot.tk nicht mehr.

Spam unter WordPress ohne Plugins verhindern!

Ich habe bei einem meiner Projekte das Problem, dass ich WordPress verwende, allerdings keine Plugins oder Themes verwenden kann. Wie verhindert man also bei so einem Projekt Kommentar-Spam?

Es ist eigentlich ganz einfach: Man baut in die functions.php ein paar neue Funktionen gegen Spam ein:

1. Webseiten-Feld entfernen!

Spammer / Spam-Bots wollen ihre Webseite bekannter machen, gibt es kein -Webseiten-Feld ist das Risiko niedriger, dass Spam gepostet wird.

PHP-Code:

function remove_comment_fields($fields) {
    unset($fields['url']);
    return $fields;
}
add_filter('comment_form_default_fields','remove_comment_fields');
 
function rkv_url_spamcheck( $approved , $commentdata ) {
   return ( strlen( $commentdata['comment_author_url'] ) > 1 ) ? 'spam' : $approved;
}
 
add_filter( 'pre_comment_approved', 'rkv_url_spamcheck', 99, 2 );

Diese Funktion entfernt das Webseiten-Feld und markiert Kommentare mit Webseite automatisch als Spam. (Quelle: catswhocode.com)

2. Kommentare mit Links entfernen

Als Nächstes weist man die Besucher des Blogs darauf hin, dass Links in den Kommentaren verboten sind und baut die folgende von mir erstellte Funktion ein, die Kommentare mit Links erkennt.

PHP-Code:

// BBCodes und HTML-Links erkennen - Wronnay.net
function wy_link_on_comment() {
if(stristr($_POST['comment'],"[link=") || stristr($_POST['comment'],"[url=") || stristr($_POST['comment'],"a href=") || stristr($_POST['comment'],"http://")){
wp_die( __('Bitte keine Links posten!') );
}
}
add_action('pre_comment_on_post', 'wy_link_on_comment');

Die Funktion erkennt sogenannte BBCodes, die eigentlich gar nicht in WordPress verwendet werden und normale HTML-Links und weist den Autor darauf hin, dass Links nicht erlaubt sind.

Update (23.04): Ich habe jetzt „ || stristr($_POST[‚comment‘],“http://“)“ hinzugefügt. Der Code erkennt jetzt alle Links.

Server-Status

Da ich in letzter Zeit immer wieder mit Ausfällen zu kämpfen hatte, habe ich jetzt eine Webseite bei einem anderen Webhoster erstellt, die anzeigt, ob meine Projekte online sind oder nicht.

Die Webseite prüft meinen vServer und meine einzelnen Projekte und zeigt deren Status an. Der Server wird mit einer anderen Methode geprüft wie die einzelnen Webseiten.

Die Seite ist unter Status.Wronnay.net erreichbar. Allerdings gibt es auch ein kleines Problem: sollte mein DNS-Server ausfallen, ist auch die Status-Seite nicht mehr erreichbar.

Vielleicht baue ich auch eine kleine Funktion zum Zählen von den Ausfällen an – so könnte ich ermitteln, ob ich vielleicht zu einem anderen Hoster wechseln sollte. Sollte es vermehrt zu Ausfällen kommen, werde ich wohl meine Projekte auf verschiedene Webhoster aufteilen. Allerdings bin ich derzeit mit meinem Server zufrieden, außerdem will ich (frühestens) ab Mai einen zweiten Server in Österreich betreiben. (Dieser wird dann natürlich auch von der Status-Webseite überwacht)