Downloads über youtube-dl per Bash-Funktion in der Z shell unter macOS nutzen

Vor ein paar Tagen hatte ich darüber geschrieben, wie es möglich ist mittels youtube-dl nur den MP4-Stream eines Videos herunterzuladen. Wenn das Kommando öfter benutzt werden soll, ist es etwas umständlich und wenig einprägsam.

Um das Kommando einfacher zugänglich zu machen, kann eine Bash-Funktion definiert werden. Unter macOS muss diese in der entsprechenden Konfigurationsdatei der Z shell angelegt werden:

nano ~/.zshrc

Anschließend kann die entsprechende Funktion in der Datei definiert werden:

yd ()
{
  youtube-dl -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]' "$1"
}

Nachdem das Terminal neugestartet wurde, kann das Kommando wie folgt benutzt werden:

yd YouTubeID123

Anschließend startet der Download wie gehabt und das Kommando geht in Zukunft wesentlich einfacher von der Hand.

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.

Foundry VTT unter Ubuntu als Service installieren

Bei Foundry VTT handelt es sich um eine Virtual Tabletop-Plattform, welche selbst gehostet werden kann. Daneben existieren Versionen für macOS und Windows. Soll Foundry VTT 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 kann ein Nutzer für Foundry VTT angelegt werden und in diesen gewechselt werden:

adduser --disabled-login --gecos "" foundryvtt
su - foundryvtt
mkdir foundry

Nachdem das aktuelle Release von Foundry VTT heruntergeladen wurde, sollte dieses im Ordner foundry entpackt werden:

cd foundry
unzip foundryvtt.zip
rm foundryvtt.zip

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

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

Diese wird mit folgendem Inhalt befüllt:

[Unit]
Description=Foundry VTT
After=syslog.target
After=network.target

[Service]
Type=simple
User=foundryvtt
Group=foundryvtt
ExecStart=/usr/bin/node /home/foundryvtt/foundry/resources/app/main.js --dataPath=/home/foundryvtt/foundrydata
Restart=always

[Install]
WantedBy=multi-user.target

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

systemctl enable foundryvtt
systemctl start foundryvtt

Lokal ist der Service nun per HTTP unter dem Port 30000 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 Foundry VTT port number
        proxy_pass http://localhost:30000;
    }
}

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

Probleme mit dem Upload von SVG-Dateien unter WordPress

Medien können über die Medienverwaltung unter WordPress hochgeladen werden. Dabei findet eine Überprüfung statt, ob ein bestimmter Dateityp erlaubt ist. Schlägt diese Überprüfung fehl, so wird dies mit einer entsprechenden Fehlermeldung quittiert.

Der Upload ist fehlgeschlagen

Die entsprechende Meldung:

Dieser Dateityp ist aus Sicherheitsgründen leider nicht erlaubt.

bzw. das Verhalten, welches zu dieser Meldung führt, kann dabei über einen Parameter in der Datei wp-config.php deaktiviert werden:

define( 'ALLOW_UNFILTERED_UPLOADS', true );

In der Theorie werden hiermit alle Uploads in WordPress zugelassen. Dies sollte natürlich nur getan werden, wenn dies explizit gewünscht ist. Daneben existieren Plugins, um nur bestimmte Dateien zum Upload zuzulassen.

In meinem Fall konnte ich eine spezielle SVG-Datei, trotz aktivierter ALLOW_UNFILTERED_UPLOADS-Option, allerdings immer noch nicht hochladen. Das Problem ist hier, das bei SVG-Dateien Sicherheitsbedenken bestehen, da es sich um XML-Dateien handelt; genaueres kann im entsprechenden Ticket nachgelesen werden.

In meinem Fall half in es der SVG-Datei folgenden Header:

<?xml version="1.0" encoding="utf-8"?>

an den Anfang der Datei zu setzen; anschließend konnte die entsprechende SVG-Datei hochgeladen und verarbeitet werden.

Same-Origin-Policy im Firefox für lokale Dateien deaktivieren

Der Zugriff auf lokale Dateien im Firefox ist aufgrund der Same-Origin-Policy im Normalfall nicht möglich. So kann z.B. eine lokale Datei nicht per AJAX nachgeladen werden:

Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf file:///path/to/file/test.json. (Grund: CORS-Anfrage war nicht http).

Das Feature an sich ist sinnvoll, doch manchmal soll dieses für Entwicklerzwecke abgeschaltet werden. Dies kann über den Aufruf von about:config erreicht werden.

about:config wird aufgerufen

In den Einstellungen findet sich das Attribut:

privacy.file_unique_origin

Wird dieser Wert auf false gesetzt können die Dateien lokal unter Aufhebung der Same-Origin-Policy geladen werden.