Etherpad unter Ubuntu installieren

Bei Etherpad handelt es sich um einen Editor für kollaboratives Schreiben, welcher selbst gehostet werden kann. Soll Etherpad unter Ubuntu gehostet werden, muss im ersten Schritt Node.js installiert werden:

apt install -y libssl-dev
curl -sL https://deb.nodesource.com/setup_14.x | bash -
apt install -y nodejs

Anschließend wird ein Nutzer für Etherpad angelegt und in diesen gewechselt werden und dort der Quellcode für Etherpad heruntergeladen und initial einmal gestartet und dann mittels Strg + C wieder beendet:

adduser --disabled-login --gecos "" etherpad
su - etherpad
git clone --branch master https://github.com/ether/etherpad-lite.git
cd etherpad-lite
npm install sqlite3
src/bin/run.sh

Nun werden einige Konfigurationen vorgenommen. Im Groben werden die Datenbank, die Authentifikation, Vorbereitungen für den Reverse Proxy, die Nutzer und die maximale Länge von einzufügendem Inhalt und das Log konfiguriert:

nano etherpad-lite/settings.json

Die Änderungen sind in ihrer Reihenfolge in der Konfigurationsdatei angegeben:

...

"dbType": "sqlite",
"dbSettings": {
  "filename": "var/sqlite.db"
},

...

"requireAuthentication": true,

...

"trustProxy": true,

...

"users": {
"admin": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": true
},
"user": {
  // 1) "password" can be replaced with "hash" if you install ep_hash_auth
  // 2) please note that if password is null, the user will not be created
  "password": "example",
  "is_admin": false
}
},

...

"socketIo": {
/*
 * Maximum permitted client message size (in bytes). All messages from
 * clients that are larger than this will be rejected. Large values make it
 * possible to paste large amounts of text, and plugins may require a larger
 * value to work properly, but increasing the value increases susceptibility
 * to denial of service attacks (malicious clients can exhaust memory).
 */
"maxHttpBufferSize": 1048576
},

...

"logconfig" :
{ "appenders": [
    { "type": "console"
    //, "category": "access"// only logs pad access
    }

  , { "type": "file"
  , "filename": "etherpad.log"
  , "maxLogSize": 1024000
  , "backups": 3 // how many log files there're gonna be at max
    }

...

Anschließend wird der Kontext des Nutzers etherpad verlassen und eine neue Service-Unit für systemd angelegt:

exit
nano /etc/systemd/system/etherpad.service

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Etherpad
After=syslog.target
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
Environment="NODE_ENV=production"
ExecStart=/home/etherpad/etherpad-lite/src/bin/run.sh
Restart=always

[Install]
WantedBy=multi-user.target

Nachdem die Datei angelegt wurde, kann der Service aktiviert und gestartet werden:

systemctl enable etherpad
systemctl start etherpad

Lokal ist der Service nun per HTTP unter dem Port 9001 erreichbar. Damit der Service auch von außen erreichbar ist, kann Nginx als Reverse Proxy konfiguriert werden. Dazu muss die entsprechende Konfiguration hinterlegt werden:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    ssl_certificate        /etc/letsencrypt/live/example.org/fullchain.pem;
    ssl_certificate_key    /etc/letsencrypt/live/example.org/privkey.pem;

    server_name example.org;

    client_max_body_size 512m;

    location / {

        # Set proxy headers
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # These are important to support WebSockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        # Make sure to set your Etherpad port number
        proxy_pass http://localhost:9001;
    }
}

Damit steht Etherpad auch von außen unter der entsprechenden Domain zur Verfügung und kann benutzt werden.

Aktuelle Prozesse einer MariaDB-Installation anzeigen

Manchmal ist es interessant in einer MariaDB-Installation hinter die Fassade zu schauen. So kann ermittelt werden, welche Prozesse und Queries aktuell abgearbeitet werden. Um diese Liste einzusehen, sollte die Kommandozeile der MariaDB-Installation geöffnet werden:

mariadb

Anschließend kann der Befehl show processlist eingegeben werden:

MariaDB [(none)]> show processlist;

Die Ausgabe enthält die entsprechenden Nutzer und die aktuell ausgeführten Queries:

+--------+-------------+-----------+------+---------+------+--------------------------+------------------+----------+
| Id     | User        | Host      | db   | Command | Time | State                    | Info             | Progress |
+--------+-------------+-----------+------+---------+------+--------------------------+------------------+----------+
|      1 | system user |           | NULL | Daemon  | NULL | InnoDB purge coordinator | NULL             |    0.000 |
|      2 | system user |           | NULL | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|      3 | system user |           | NULL | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|      4 | system user |           | NULL | Daemon  | NULL | InnoDB purge worker      | NULL             |    0.000 |
|      5 | system user |           | NULL | Daemon  | NULL | InnoDB shutdown handler  | NULL             |    0.000 |
| 179949 | root        | localhost | NULL | Query   |    0 | Init                     | show processlist |    0.000 |
+--------+-------------+-----------+------+---------+------+--------------------------+------------------+----------+

Cachify-Cache per Cronjob bereinigen

Cachify ist ein WordPress-Plugin zum einfachen und effektiven Cachen der eigenen WordPress-Instanz. Das Plugin bietet unterschiedliche Methoden für das Caching an. So kann der Cache z.B. in der Datenbank oder auf der Festplatte angelegt werden. Meine bevorzugte Methode ist die Ablage des Caches auf der Festplatte.

Cachify
Preis: Kostenlos

Dies hat einige Vorteile. So kann der Cache, wenn vorhanden, direkt über den Webserver ausgeliefert werden. Die Ausführung von PHP oder die Anfrage auf der Datenbank entfällt. Dies wirkt sich extrem positiv auf die Geschwindigkeit aus. Allerdings funktioniert der automatische Ablauf des Caches bei der Festplatten-Methode leider nicht. Hier muss stattdessen ein Cronjob eingerichtet werden:

sudo -u www-data crontab -e

Im Cronjob soll einmal der Cache bereinigt werden und anschließend die Hauptseite geöffnet werden, damit für diese wieder ein Objekt im Cache angelegt wird:

rm -rf /var/www/example/main/wp-content/cache/cachify/*
curl --silent https://example.net > /dev/null

Beim ersten Befehl wird der Ordner, in welchem der Cache liegt, gelöscht. Anschließend wird mit cURL die Hauptseite aufgerufen, um den Cache wieder aufzufüllen. In der Crontab-Datei sieht dies wie folgt aus:

0    *    * * *   rm -rf /var/www/blankensee/main/wp-content/cache/cachify/* & curl --silent https://blankensee.net > /dev/null

Damit wird der Cache einmal in der Stunde gelöscht und der Cache der Hauptseite wieder neu aufgebaut.

ownCloud und Nextcloud

Mit ownCloud gab es ab 2010 eine Lösung Daten in der Cloud zu lagern, welche nicht bei einem dritten Dienstleister, wie z.B. Dropbox, hinterlegt werden mussten. Im Gegensatz zu anderen Lösungen aus der damaligen Zeit ließ sich ownCloud relativ unkompliziert auf einem einfachen Webspace, welcher über PHP und eine Datenbank verfügte, installieren. Einige Jahre entwickelte sich ownCloud prächtig, bis es zu Meinungsverschiedenheiten über die Ausrichtung von ownCloud kam. Darauf hin verließen Frank Karlitschek, der Hauptentwicker von ownCloud, und einige weitere Entwickler die Firma ownCloud GmbH und spalteten das Projekt unter dem Namen Nextcloud ab.

Eine ownCloud-Installation wird zu Nextcloud migriert

Damit lief die Entwicklung der beiden Lösungen eine Weile parallel, wobei die Community und ein Großteil der Entwicklerkapazitäten gefühlt in Nextcloud steckten. Vor ein paar Tagen kündigte die ownCloud GmbH an, seine Architektur komplett umzustellen, womit die ursprüngliche ownCloud wohl tot ist und Nextcloud der mehr als legitime Nachfolger ist.

Passwort eines MariaDB-Nutzers zurücksetzen

Um sich mit einer MariaDB-Datenbank zu verbinden wird ein Nutzer und ein Passwort benötigt. Wenn das Passwort verloren gegangen ist, ist dies allerdings kein Beinbruch, solange es sich um die eigene Installation handelt. In diesem Fall kann das Passwort einfach auf der Konsole zurückgesetzt werden. Dazu muss sich per SSH auf dem entsprechenden Server eingeloggt werden und dort das mysql-Tool mit dem Nutzer root gestartet werden:

mysql -u root

Nachdem dies geschehen ist, wird in der Kommandozeile auf die Tabelle mysql geschwenkt:

use mysql;

In dieser Tabelle finden sich die Verwaltungsdaten des Datenbanksystems. Über diese Tabelle ist es nun möglich den Nutzer mit einem neuen Passwort zu versehen:

update user set password=PASSWORD("geheim123") where User='username';
flush privileges;

Damit ist das Passwort für den entsprechenden Nutzer zurückgesetzt und das mysql-Tool kann mittels:

exit

verlassen werden. Anschließend kann der Nutzer mit dem neuen Passwort genutzt werden.