Debian 9 Upgrade mit nginx und PHP 7.2

Veröffentlicht am von
Antworten

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.

nginx: upstream sent too big header

Veröffentlicht am von
Antworten

Beim Einloggen in einen WordPress Blog hatte ich vor Kurzem nach einem Upgrade von Debian und PHP einen 502 Bad Gateway Error. Dieser wurde von einem „upstream sent too big header“ Fehler ausgelöst.

Da ich zu diesem Fehler nur englische Beiträge gefunden habe, möchte ich hier mal einen Lösungsweg auf Deutsch teilen.

In der nginx Error Log, welche man unter Debian unter /var/log/nginx/error.log finden kann, fand ich die folgende Zeile:

[error] upstream sent too big header while reading response header from upstream, client: ***.***.***.***, server: *****.***, request: "GET /wp-login.php

(Domain und IP-Adresse aus Datenschutzgründen unkenntlich gemacht)

Eine Lösung, um diesen Fehler zu beheben, ist unter Debian die /etc/nginx/fastcgi.conf zu bearbeiten und die folgenden Zeilen hinzuzufügen, um die Buffer Size festzulegen: 

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

(Stack Overflow Post dazu)

Natürlich muss man selbst ermitteln bzw. wissen, welche Buffergrößen notwendig sind. Nginx selbst hat hierzu auch eine gute Dokumentation online: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffer_size

Twitch Livestream aufnehmen

Veröffentlicht am von
Antworten

Nachfolgend zeige ich, wie man einen Twitch Livestream aufnehmen kann. Die Funktionsweise funktioniert aber auch bei Konkurrenten wie YouTube Live und anderen Streaming-Anbietern ganz einfach.

Programme installieren

Bevor wir mit dem Streamen anfangen können, benötigen wir zwei Programme:

Den VLC Media Player kann man auf fast allen Betriebssystemen wie gewohnt installieren, für Streamlink empfiehlt sich eine Installation über die Paketverwaltung pip von Python im jeweiligen Terminal oder der Kommandozeile des Betriebssystems:

(sudo) pip install streamlink

Wem das zu kompliziert ist, kann auch eine ausführbare Datei von Streamlink herunterladen und so das Programm auch wie gewohnt unter z.B.: Windows installieren: https://github.com/streamlink/streamlink/releases

Stream starten

Mit den folgenden Befehl kann der Stream in VLC geöffnet werden (nachfolgend am Beispiel des Twitch Presents Streams von Twitch):

streamlink https://www.twitch.tv/twitchpresents best

Das „best“ steht hierbei für die Qualität des Streams. Es gibt hier natürlich auch noch weitere Optionen, die der Dokumentation von Streamlink entnommen werden können.

Stream speichern

Nun einfach in VLC unter dem Menüpunkt „Wiedergabe“ den Punkt „Aufnehmen“ anhaken. VLC speichert anschließend automatisch die Wiedergabe in Video-Dateien – unter macOS werden die Streams standardmäßig als .ts-Dateien im Download-Ordner gespeichert.

Ich hoffe, ich konnte verständlich erklären, wie man einen Twitch Livestream aufnehmen kann. Falls noch Fragen dazu offen sind, kann gerne ein Kommentar hinterlassen werden.

AltCoins vom Source Code kompilieren

Veröffentlicht am von
Antworten

Oft macht es Sinn, AltCoins vom Source Code zu kompilieren. Das mache ich z.B.: da ich AltCoins auf einem Computer ohne grafische Oberfläche schürfen will und manche AltCoins ohne GUI nur in Form von Quellcode angeboten werden.

Nachfolgend will ich deshalb in einer Schritt-für-Schritt-Anleitung zeigen, wie man die meisten Kryptowährungen vom Quellcode kompilieren kann.

Schritt 1: Source Code ermitteln

Der Pfad zum Source Code auf GitHub ist bei den meisten Coins auf der Website verlinkt. Bei Peercoin ist das z.B.: https://github.com/peercoin/peercoin

Schritt 2: Build Doc ermitteln

Bei fast allen Kryptowährungen ist der Pfad zur Doku der folgende:

coin/doc/build-XX.md

XX steht dabei für das Betriebssystem. In meinem Fall Unix. Diese Markdown-Datei ist die Dokumentation, wie man den jeweiligen Coin vom Source Code erstellt. Advanced User reicht die Anleitung bis hier hin aus und können alleine weitermachen 😉

Schritt 3: Abhängigkeiten installieren

Hier kommt es oft darauf an, wie alt die Dokumentation ist. Moderne AltCoins haben ein paar Befehle, um alles zu installieren. Bei älteren Dokumentationen kann es aber sein, dass man z.B. die folgenden Pakete (z.B.: unter Debian / Ubuntu) installieren muss:

sudo apt-get install build-essential
sudo apt-get install libssl-dev
sudo apt-get install libdb++-dev
sudo apt-get install libboost-all-dev
sudo apt-get install libqrencode-dev

Schritt 4: Source Code von GitHub klonen

Sehr einfach: einfach in das gewünschte Verzeichnis wechseln und den Coin von GitHub klonen:

git clone https://PFAD-ZUM-COIN

Schritt 5: Den Coin kompilieren

Auch dieser Code kann natürlich je nach Coin unterschiedlich ausfallen.

cd src/
make -f makefile.unix

Das Kompilieren dauert etwas länger als normale Installationen durch z.B.: Paketmanager – also evtl. einen Kaffee machen 😉
Fehlermeldungen / Notizen sind oft normal. Wenn das Skript aber nicht abbricht, sondern bis zum Ende durchhält, ist das ein gutes Zeichen 😀

Schritt 5: Coin nutzen

Auch nach der Installation ist das Nutzen eines Coins ohne grafische Oberfläche natürlich etwas aufwendiger.

Man kann den Coin z.B.: als Dienst (Daemon) starten. Das geht oft so:

/PFAD-ZU-COIN/src/Coind -daemon -datadir=/PFAD-ZUM-SPEICHERN-DER-COIN-DATEN

Um eine grobe Übersicht zu bekommen, kann man z.B.: den folgenden Befehl nutzen:

/PFAD-ZU-COIN/src/Coind -datadir=/PFAD-ZUM-SPEICHERN-DER-COIN-DATEN getinfo

Dokumentation zur original Bitcoin API: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

Automatische Backups bei Shared Webhosting

Veröffentlicht am von
Antworten

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!

MECSA: SPF, DKIM und DMARC bei Mailservern

Veröffentlicht am von
Antworten

Ich bin gestern über das Projekt My Email Communications Security Assessment (MECSA) der Europäischen Union gestoßen. Mit dem Online-Dienst, welcher unter https://mecsa.jrc.ec.europa.eu/ erreichbar ist, kann man die Sicherheit der E-Mail-Kommunikation zwischen Providern testen.

Da ich meinen Mailserver gestern umgezogen habe und dessen Bewertung bei anderen Providern verbessern sowie den E-Mail-Verkehr sichern wollte, fand ich dieses Tool recht hilfreich.

Im Grunde sind drei Verfahren / Techniken für eine gute Bewertung bei MECSA wichtig. Diese Verfahren müssen alle als TXT-Records beim DNS-Server der jeweiligen Domain eingerichtet werden.

SPF

Sender Policy Framework – gibt aus, welche Server E-Mails für die Domain versenden dürfen. In den meisten Fällen reicht der folgende TXT-Record hierfür völlig aus:

@                   IN TXT     "v=spf1 mx ~all"

Wer sich mehr damit befassen will, sollte am besten einfach mal seine Suchmaschine verwenden.

DKIM

DomainKeys Identified Mail –  hiermit will man im Grunde sicherstellen, dass die E-Mails auch wirklich von angegeben Absender kommen und nichts verändert wurde. Hierfür gibt es einen privaten und einen öffentlichen Schlüssel. Den öffentlichen Schlüssel hinterlegt man als TXT-Record auf den DNS-Server und der private Schlüssel wird auf dem Mailserver verstaut.

Manche Mailserversoftware wie z.B.: Mailcow haben zur Erzeugung der Schlüssel eine grafische Benutzeroberfläche.

DMARC

DMARC ist im Endeffekt das Verbindungsstück von  SPF und DKIM. Man gibt damit an, was passieren soll, wenn die E-Mail nicht SPF und DKIM entspricht und wer über die E-mail informiert werden soll.

MXToolBox bietet einen guten Generator die Erzeugung des TXT-Records an: https://mxtoolbox.com/DMARCRecordGenerator.aspx

Übrigens verwenden aktuell GMX, Web und 1&1 sowie viele andere deutsche Provider kaum die in diesem Post veröffentlichen Methoden und haben daher eine eher schlechte MECSA Bewertung.

Gitea Update

Veröffentlicht am von
Antworten

Gitea ist im Grunde etwas wie GitHub, nur selbst gehostet. (Ähnlich zu GitLab nur nicht so intensiv im Verbrauch von RAM und CPU)

Gitea ist ein Fork von Gogs – allerdings mit einer offeneren Mentalität der Community als Gogs …

Nun verwende ich diese Software auf einem meiner Server und wollte es heute aktualisieren. Bei einer „normalen“ Anwendung klickt man dazu einfach auf einen Button wie „Update suchen“. Leider gibt es diesen Button bei Gitea aktuell nicht.

Was also tun?

Ich habe das gemacht, was man an der Stelle wahrscheinlich oft als Erstes macht: Googeln!

Google brachte mir das Ergebnis: https://geeklabor.de/archives/207-Gitea-source-update.html

Dieses Ergebnis brauchte mich aber nicht weiter, da ich nicht einmal die Programmiersprache Go auf meinem System installiert hatte … (Ich erwähne es hier trotzdem, vielleicht hilft es ja jemand weiter ….)

Die Lösung!

Ich hatte Gitea als Binary auf meinem Server installiert. Gitea bietet auf GitHub neue Versionen auch als Binary an.

Die Lösung war also recht einfach: Neue Binary mit wget ziehen, mit mv umbenennen, die Berechtigungen mit chmod und chown ändern und wie gewohnt ausführen!

Vor solchen Updates sollte man übrigens mit ./gitea dump eine Sicherung erstellen …

Wronnay Pics eingestellt

Veröffentlicht am von
Antworten

Seit 2013 konnte man unter pics.wronnay.net kostenlos Bilder hochladen.

Ich habe heute nach einer Neuinstallation eines Webservers den Dienst erneut geprüft und festgestellt, dass das Hosting in letzter Zeit für unseriöse Dinge missbraucht wurde. Zudem wird die verwendete Software nicht mehr weiterentwickelt.

Deshalb habe ich nun, nach fast 5 Jahren, den Dienst eingestellt. Da dieser allerdings nicht wirklich populär war, wird es wenige tote Bilder geben.

Der ursprüngliche Zweck war das Anbieten einer Möglichkeit zum Hochladen von Bildern für Nutzer von WebPage4.Me, ForenHosting.net und Homepage-versammlung. Unter WebPage4.Me kann man allerdings jetzt direkt Bilder hochladen und die anderen Dienste existieren aktuell nicht mehr.

Raspberry Pi: WLAN geht nicht „Driver does not support …“

Veröffentlicht am von
Antworten

Nachdem auf meinem alten Raspberry Pi 1 Model B noch Raspbian „Jessie“ läuft, wollte ich heute mein System auf Stretch aktualisieren.

Nach der Aktualisierung ging nun aber leider kein WLAN über meinem Stick mit Realtek-Chip mehr. Die Fehlermeldung war die folgende:

nl80211: Driver does not support authentication/association or connect commands
wlan0: Failed to initialize driver interface

Nach einer längeren Suche bin ich auf eine Lösung gestoßen: Wenn man der wpa_supplicant den Treiber „wext“ mitgibt, dann funktioniert WLAN auch mit Realtek-Sticks. Den Treiber kann man über die Datei /etc/network/interfaces mitgeben. Bei mir sieht diese Konfiguration etwa so aus (die IPs habe ich angepasst):

auto wlan0
iface wlan0 inet static
        address 192.168.0.97/24
        gateway 192.168.0.1
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

MacBook Air 2008: Gerät muss neugestartet werden

Veröffentlicht am von
Antworten

Vor Kurzem hatte ich bei einem MacBook Air von 2008 (das erste MacBook Air Modell) mit Mac OS X Snow Leopard das Problem, dass jedes Mal nach dem Starten die Meldung „Sie müssen den Computer neu starten. Halten Sie den Ein- Ausschalter gedrückt bis das Gerät ausgeschaltet ist und drücken Sie ihn dann erneut.“ kam. Diese Meldung kann man leider nicht wegklicken …

Es war komplett irrelevant, wie oft ich das Gerät neu gestartet, die Festplatte formatiert oder das Betriebssystem neu installiert habe – auch das Zurücksetzen von SMC und PRAM (SMC:
http://support.apple.com/kb/ht3964, PRAM: http://support.apple.com/kb/ht1379) hat nichts gebracht. Das Problem hatte ich solange, bis ich nach einem Neustart in die Details des Fehlerberichts geschaut hatte. Dort stand folgendes:

Invalid backlight duty cycle value"@/SourceCache/GraphicsDrivers/GraphicsDrivers-5.48.6/Common/GLKernel/Inte l/IntelIntegratedFramebuffer/IntelGMAX3100FB.cpp

Aha. Es hat also etwas mit der Hintergrundbeleuchtung zu tun. Nach einer kurzen Suche fand ich den folgenden Beitrag: https://discussions.apple.com/thread/4246550?tstart=0

In diesem Beitrag wird auf zwei Lösungen hingewiesen und das Problem beim Namen genannt – es ist eine „Kernel Panic“. Bei der einen Lösung muss eine Datei von einem älteren OS X Betriebssystem mit dem aktuellen Betriebssystem ausgetauscht werden, in der anderen Lösung wird ein Ordner (bzw. eine Kernel Erweiterung – KEXT steht für „Kernel Extension“) einfach gelöscht. Dadurch lässt sich zwar die Helligkeit des Bildschirms nicht mehr einstellen, das MacBook zeigt aber auch keine Fehlermeldungen mehr an und funktioniert. Diese Lösung möchte ich nun präsentieren.

Schritt 1:

Beim Starten des MacBooks die Tasten „cmd“ und „s“ gedrückt halten, bis weißer Text auf schwarzen Hintergrund angezeigt wird. Hierdurch kommt man in den „Singel-User-Mode“ (FreeBSD-Nutzer kennen das ^^)

Schritt 2:

Da wir Änderungen an Dateien machen wollen, geben wir folgendes ein:

Zuerst: 

/sbin/fsck -fy

Anschließend: 

/sbin/mount -uw /

Schritt 3:

Nun erstellen wir ein Backup-Verzeichnis zum Sichern des Ordners: 

mkdir /oldext

Schritt 4:

Danach kopieren wir das Verzeichnis entweder mit 

mv /System/Library/Extensions/com.apple.AppleBacklightExpert.kext /oldext

oder (bei mir) mit 

mv /System/Library/Extensions/AppleBacklightExpert.kext /oldext

Schritt 5:

Wir haben den Ordner nun gesichert und können ihn löschen: 

rm -rf /System/Library/Extensions/com.apple.AppleBacklightExpert.kext

oder 

rm -rf /System/Library/Extensions/AppleBacklightExpert.kext

Schritt 6:

So. Mit 

reboot

starten wir – danach sollte der Fehler verschwunden sein. (Wenn er nicht verschwunden ist, hilft evtl. ein Zurücksetzen des SMC und PRAM)