Was ich schon immer aufschreiben wollte
Seit Seafile 4.3 können nun auch die bisher nach außen offenen Ports geschlossen werden. Über einen Proxy (z.B. Apache oder Nginx) waren sie schon früher nicht erforderlich, aber leider nicht abstellbar. Folgende Änderungen müssen in den angegebenen Datein durchgeführt werden:
ccnet/ccnet.conf:
[Network] #PORT = 10001
seafile-data/seafile.conf:
[network] #port = 12001
Unit-Files für systemd für seafile und seahub sind im Seafile-Manual zu finden. Für FastCGI muss das Skript für seahub entsprechend angepasst werden. Siehe den dortigen Kommentar
Das Major-Versionsupgrade von 4.2 auf 5.0 welches hier anstand hat mit der Methode "Schritt für Schritt jeden einzelnen Upgradeschritt aus ./update durchführen" problemlos funktioniert.
Mit der Version 5.0 hat sich die Wiki-Syntax für Links geändert. Leider werden bestehende Links nicht immer automatisch konvertiert.
Oft darf von einem Bash Script nur eine Instanz laufen. Beispiele sind ein Backup oder ein Datei-Transfers, welche bei gleichzeitigem Lauf der selben Scripte evtl. nicht korrekt durchgeführt würden. Mit einfachen bash-Mitteln lässt sich dies jedoch verhindern.
Ganz einfach könnte man auf das Vorhandensein einer Datei testen und sie anlegen, falls sie nicht existiert. Allerdings hätte man sich damit auch eine sogenannte RaceCondition geschaffen, der Vorgang zwischen Test und Anlegen ist nicht atomar. Ein nicht funktionierendes Beispiel:
LOCKFILE=/var/lock/test.lock [[ -f $LOCKFILE ]] && exit 1 > $LOCKFILE
Nehmen wir an, zwei Instanzen eines Skripts mit diesem Schnipsel kommen gleichzeitig an die Stelle des Tests auf das Vorhandensein des Lockfiles. Beide finden das Lockfile nicht und werden weiter ausgeführt!
Atomar hingegen ist das Anlegen von Verzeichnissen. mkdir legt ein Verzeichnis an und testet gleichzeitig, ob es bereits vorhanden ist. Mit folgendem Schnipsel am Scriptanfang kann ein gleichzeitiges Ausführen des selben Scripts verhindert werden:
LOCK=/var/lock/mylock if ! mkdir $LOCK 2>/dev/null; then echo Already running or stale lock exists. >&2 exit 1 fi trap -- "rmdir $LOCK" EXIT # do work
trap sorgt dafür, dass bei Beendigung des Scripts das Lock-Verzeichnis wieder entfernt wird.
Eins sei noch erwähnt: wenn der Prozess in dem das Script läuft, also die bash, mit "kill -9" abgewürgt wird, wird der Befehl hinter trap nicht mehr ausgeführt. Das Lock-Verzeichnis muss dann manuell entfernt werden.
Update vom 16.02.2016: Hinweis auf RaceCondition und Lösung mit mkdir hinzugefügt.
Munin wird dazu verwendet, Laufzeitwerte über verschiedene Dienste oder Rechner zu sammeln und diese statistisch in Grafiken auf einer eigenen Webseite aufzubereiten. Bei Über- oder Unterschreiten eines Grenzwertes können entsprechende E-Mails versenden. Die gesammelten Daten werden rollierend in RRDs (Robin-Round-Database) festgehalten.
In der Standardkonfiguration wird in den meisten RRDs nur jeweils ein Wert gespeichert. Das ergibt z.B. bei 10 Hosts á 20 zu speichernden Werten 200 RRDs, die von Munin alle 5 Minuten (dem Standard-Abfrageintervall) fast gleichzeitig geschrieben werden. Diese Häufung von IOs, zumal sie nicht gestreckt über den gesamten Zeitraum sondern punktuell auftritt, kann für große Installationen schnell zum Problem werden. Im Folgenden wird eine Methode vorgestellt, wie diese Festplatten-Last um den Faktor 10 gesenkt werden kann. ...weiterlesen "Munin: Optimierung der Festplatten-IOs"
Die von Let's Encrypt kostenlos erhältlichen Zertifikate sind aktuell 90 Tage gültig. Bei vielen Zertifikaten, so z.B. bei vielen Subdomains mit eigenen Zertifikaten, fällt der Überblick schwer, wann welches Zertifikat in Kürze abläuft und erneuert werden muss. Eine automatische Erinnerung muss her.
Eine Methode, um automatisiert alle Zertifikate auf ihren bevorstehenden Ablauf zu testen, kann mit dem folgenden Bash-Script realisiert werden. ...weiterlesen "Let’s Encrypt: Erinnerung vor Zertifikatablauf"
