Xfce: Start-Skript einrichten

Veröffentlicht am von
Antworten

Ein Start-Skript nach dem Anmelden eines Benutzers kann bestimmte Aufgaben wie z.B.: das Pullen von einem Git Repository oder das Öffnen von Anwendungen gleich beim Start ausführen.

Da ich mir unter Xfce ein solches Skript eingerichtet habe, möchte ich nun zeigen, wie das funktioniert. Als Beispielsystem werde ich Xfce unter Manjaro Linux verwenden.

Zuerst sollte man natürlich sein Skript (z.B.: als Bash-Skript) schreiben. Hierauf gehe ich allerdings in diesem Artikel nicht genauer ein. Seiten wie „ubuntuusers“ bieten dazu genügend gute Anleitungen.

Anschließend kann man über die Xfce-Einstellungen den Punkt „Sitzung- und Startverhalten“ auswählen.

Über „Automatisch gestartete Anwendungen“ kann man mit dem Button „Hinzufügen“ auch eine neue Startanwendung in die Liste aufnehmen.

Das anschließende Fenster möchte mit einem verständlichen Namen und dem Pfad zu unserem Skript gefüllt werden.

Nun sollte das Skript immer nach der Anmeldung automatisch ausgeführt werden.

Arch Linux: Bildschirmhelligkeit anpassen

Veröffentlicht am von
Antworten

Ich wollte heute unter Manjaro Linux meine Bildschirmhelligkeit anpassen. Leider gibt es direkt von Manjaro / Arch Linux hier keine GUI-Einstellung zum Regeln der Helligkeit.

Was es aber gibt, sind zwei nützliche Pakete: light und Clight. Mit light kann man die Helligkeit über die Konsole anpassen, Clight erkennt die aktuelle Umgebungshelligkeit über die Webcam und passt dementsprechend die Bildschirmhelligkeit an.

Da Clight aber nur über Arch AUR erhältlich ist, habe ich mal light ausprobiert und bin damit zufrieden.

Light kann man ganz einfach über pacman installieren:

pacman -S light

Anschließend kann man die aktuelle Helligkeit als Prozentwert ausgeben lassen:

$ light -G
23.99

Und die Helligkeit um x Prozent erhöhen:

$ light -A 70

Automatische Gitea Updates

Veröffentlicht am von
3

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:

  • Installiere mein Skript auf dem Zielsystem: 
    pip install gitea-auto-update
  • Erstelle eine settings.ini: 
    [Gitea]
site=https://your-gitea-instance.com/api/v1/version
apiUrl=https://api.github.com/repos/go-gitea/gitea/releases/latest
system=linux-amd64
file=/usr/local/bin/gitea
tmpDir=/tmp/
buildFromSource=None
sourceDir=/home/git/go/src/code.gitea.io/gitea
logFile=update.log
  • Führe den Befehl gite-auto-update --settings=/path/to/settings.ini 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

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.