Ich schreibe diese Anleitung aus dem einfachen Grund, dass die pyLoad Dokumentation für die Debian-Installation eher schlecht daher kommt. Zum Beispiel würde das init-Script den Prozess als root starten. Zwar kann der Prozess mittels der .config einem anderen Benutzer zugewiesen werden, was – bei mir – aber oft nicht richtig funktionierte. Irgendwann startete es einfach nicht mehr.

Zuerst die Paketquellen aktualisieren, gegenenfalls upgraden und sofort die Abhängigkeiten installieren:

apt-get update && apt-get upgrade
apt-get install python-crypto python-imaging python-openssl python-pycurl tesseract-ocr gocr python-django openssl unrar rhino

„python-qt4“ wird nicht benötigt, da pyload ohne GUI laufen wird. Wenn das Paket „unrar“ nicht gefunden wird, dann noch schnell folgendes ausführen, um „non-free“ zu den Repositorys hinzuzufügen und die Paket-Quellen neu einzulesen:

sed -i 's/wheezy main/wheezy main non-free/g' /etc/apt/sources.list && apt-get update

Das CLI-Paket von pyLoad herunterladen und installieren. Bemerkung: „–content-disposition“ speichert die Datei unter dem Namen ab, die sie tatsächlich nach der Umleitung hat. Ohne diesen Parameter, würde sie als „index.html“ gespeichert werden:

wget --content-disposition http://get.pyload.org/get/ubuntu-cli/
dpkg -i pyload-*.deb

Den pyload Benutzer erstellen und ein sicheres Passwort vergeben:

adduser pyload

Nun schnell das INIT-Script ändern, dazu dieses mit einem Editor öffnen, z.B. „nano /etc/init.d/pyload“, anschließend folgenden Inhalt einfügen (kleiner Tipp: in Nano kann mit STRG+K eine ganze Zeile ausgeschnitten werden. Einfach gedrückt halten):

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          pyload
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start or stop pyload.
### END INIT INFO

NAME=pyload
DAEMON=/usr/bin/pyLoadCore
USER=pyload
PIDFILE=/var/run/$NAME.pid
OPTIONS="--daemon"

export PATH="${PATH:+$PATH:}/sbin"

[ -x $DAEMON ] || exit 0

. /lib/lsb/init-functions

start_daemon () {
    start-stop-daemon --start --pidfile $PIDFILE --chuid $USER --exec $DAEMON -- $OPTIONS | cut -d" " -f 3 > $PIDFILE
}

stop_daemon () {
    start-stop-daemon --stop --retry="TERM/15/KILL/5" --pidfile "$PIDFILE" --user "$USER" --chuid "$USER" 
}

case "$1" in
    start)
        log_daemon_msg "Starting pyLoadCore" "$NAME"
        start_daemon
        log_end_msg 0
        ;;
    stop)
        log_daemon_msg "Stopping pyLoadCore" "$NAME"
        stop_daemon
        log_end_msg 0
        ;;
    restart)
        log_daemon_msg "Restarting pyLoadCore" "$NAME"
        stop_daemon
        start_daemon
        log_end_msg 0
        ;;
    *)
        echo "Usage: /etc/init.d/$NAME {start|stop|restart}"
        exit 2
        ;;
esac

exit 0

Anpassungen sind nicht notwendig. Die Start- und Stop-Level sind die selben, weshalb das Script einfach ausgetauscht werden kann.
Nun zum Benutzer pyload wechseln und die Konfiguration starten:

su pyload
pyLoadCore -s

Kurze Zusammenfassung der Abfragen mit meinen Antworten und Kommentaren:

Choose your Language / Wähle deine Sprache ([en], de, fr, it, es, nl, sv, ru, pl, cs, sr, pt_BR): de
Wenn du für den System-Check bereit bist, drücke enter. Enter
[…]
PyQt4: fehlt ## Wird nicht benötigt
[…]
Mit Setup fortfahren? ([j]/n): j
Config Pfad ändern? (j/[n]): n
Erstelle Grundeinstellungen? ([j]/n): j
Aktiviere Fernzugriff ([j]/n): n ## Hat nichts mit dem Web-Interface zu tun
Sprache ([en], de, fr, it, es, nl, sv, ru, pl, cs, sr, pt_BR): de
Download Ordner [Downloads]: /opt/Downloads ## Kann auch jeder andere Ordner sein, dieser müsste später aber auch für pyLoad nutzbar gemacht werden: chown pyload:pyload /opt/Downloads
Maximale parallele Downloads [3]: 5
Benutze Reconnect? (j/[n]): n
Konfiguriere SSL? (j/[n]): n ## Führt leider oft zu Problemen. Angeblich zu fixen, indem man den „threaded“ Server unten auswählt.
Konfiguriere Webinterface? ([j]/n): j
Aktiviere Webinterface? ([j]/n): j
Adresse [0.0.0.0]: 0.0.0.0 ## Auf jeder IPv4-Adresse zugänglich sein
Port [8000]: 9009 ## Lieber bei sowas nicht den Standardport benutzen.
Server ([builtin], threaded, fastcgi, lightweight): builtin

Setup erfolgreich beendet.

Bevor die Shell des Benutzers „pyload“ verlassen wird, wird pyLoadCore in der Konsole gestartet:

pyLoadCore

Sobald „*** Plugins have been updated, please restart pyLoad ***“ erscheint, STRG+C drücken und pyLoadCore erneut ausführen. Jetzt erst beginnt das Updaten der Plug-Ins. In der Konsole kann man den Fortschritt besser verfolgen, außerdem sollte vor dem Hinzufügen von Konten (uploaded.to etc.) gewartet werden, bis das Update fertig ist. Wieder erscheint die Aufforderung pyLoad zu beenden, ebenfalls mit STRG+C. Anschließend kann die Konsole verlassen werden und das INIT-Script gestartet werden:

exit
/etc/init.d/pyload start

Jetzt via Browser http://192.168.1.109:9009/ aufrufen und einloggen. Sollte oben rechts tatsächlich noch einmal um einen Neustart gebeten werden, kann der Service schnell neugestartet werden:

/etc/init.d/pyload restart

Alles Weitere ist entweder selbsterklärend oder wird in der pyLoad Dokumentation erklärt.

Nginx bietet mit „limit_req“ eine Funktion, die übermäßige Requests limitiert und so auch dazu eingesetzt werden kann, übermäßige PHP Auslastung zu verhindern.

Eine kurze Definition der Parameter vorab:

Zone: Quasi der Handler für die Limitierung. Es kann ein Limit in MB festgelegt werden. Der Benutzer wird bei mir via „$binary_remote_addr“ identifiziert, was etwa 64 Byte sind. 1 MB kann demnach 16384 Requests speichern. Die Zone kann benannt werden.

Rate: Die Anzahl an Requests, die ein einzelner Besucher pro Sekunde anfragen darf.

Burst: Burst ist sozusagen die Warteschlange für Requests, die das Limit übersteigen. Ist zum Beispiel ein Limit von 3 Requests pro Sekunde eingestellt, der Besucher stellt allerdings 5, so gehen 2 Requests in die Warteschlange und werden eine Sekunde ausgeführt. Stellt der Benutzer allerdings 9 Requests, so würden 3 sofort ausgeführt, gingen in den Burst und einer würde den Burst übersteigen. Das Resultat wäre, dass Nginx den Fehler „503 – Service Temporarily Unavailable“ anzeigt.

Delay: Hiermit wird beschrieben, ob Nginx die „quasi Warteschlange“ des Burst benutzt. „nodelay“ bewirkt, dass beim übersteigen der Requests unverzüglich „503 – Service Temporarily Unavailable“ angezeigt würde.

Zuerst wird die Datei /etc/nginx/nginx.conf geöffnet und eine Zone innerhalb von „http“ erstellt. Die Parameter sind nur Beispiele und sollten entsprechend angepasst werden:

http {
limit_req_zone  $binary_remote_addr  zone=one:3m   rate=7r/s;
...

Jetzt den jeweiligen Server bearbeiten, zum Beispiel „/etc/nginx/sites-available/default“. „limit_req“ muss innerhalb einer Location definiert werden, die das Limit erhält, zum Beispiel:

location / {
limit_req zone=one burst=5
}

Wer Nginx mit fastcgi für PHP benutzt, der kann sein Limit auch auf seine PHP-Scripts limitieren. Dazu wird einfach die vorhandene Location für PHP benutzt, zum Beispiel „location ~ \.php$“.

Achtung: Jedes Objekt stellt einen Request dar. Ein Bild auf einer Website würde also schon zwei Requests bedeuten. Es ist daher schlau, die Requests höher einzustellen oder sich direkt auf die Location für PHP (falls vorhanden) zu beziehen. Wird ein Delay eingesetzt, kann dies dem Besucher die Stimmung durch übermäßige Wartezeiten durchaus vermiesen.
Alternativ kann unterhalb von „limit_req“ mit „limit_req_log_level error;“ das Logging definiert werden, um abgewiesene Verbindungen zu analysieren. Ich persönlich verzichte auf das Delay.

Mit dem dotdeb Repository lassen sich auch in Debian die neuesten Versionen von (u.a.) Nginx, PHP und MySQL einfach installieren.

Das Repository lässt sich schnell einrichten:

echo "deb http://packages.dotdeb.org wheezy all" > /etc/apt/sources.list.d/dotdeb.list
echo "deb http://packages.dotdeb.org wheezy-php55 all" >> /etc/apt/sources.list.d/dotdeb.list
curl http://www.dotdeb.org/dotdeb.gpg | apt-key add -
apt-get update

„wheezy“ kann durch „squeeze“ ersetzt werden. Ältere Versionen werden nicht unterstützt. Wie man sieht, sind die PHP Pakete optional.

Mehr dazu auf www.dotdeb.org

Pure-FTPd ist schnell eingerichtet und lässt sich im Vergleich zu anderen FTPd sehr einfach bedienen. Die Administration über die Shell ist simpel, Konfigurationsdateien müssen eigentlich nur bei der erstmaligen Einrichtung bearbeitet werden. Die pure-* Werkzeuge – insbesondere „pure-pw“ – erleichtern dem Admin oft das Leben.

Changelog

• 29.11.2013 – Formatierung gefixt und SSL hinzugefügt

Erst einmal Pure-FTPd aus dem Repository installieren:

apt-get install pure-ftpd

Eigentlich die Standardeinstellung, sollte jedoch besser noch einmal überprüft werden: Die Datei „/etc/default/pure-ftpd-common“ öffnen und sichergehen, dass „STANDALONE_OR_INETD=standalone“ gesetzt ist. Wer später Symlinks im FTP-Client folgen möchte, der darf jetzt ebenfalls die Option „VIRTUALCHROOT=true“ setzen.
Da unser Pure-FTPd Benutzer sich quasi als www-data ausgeben soll, der in der Regel die UID 33 besitzt, muss folgender Befehl ausgeführt werden, um die Anmeldung zu ermöglichen:

echo "33" > /etc/pure-ftpd/conf/MinUID

Ich möchte die PureDB als Datenbank meiner Benutzer verwenden und außerdem PAM-Auth verbieten:

ln -s /etc/pure-ftpd/conf/PureDB /etc/pure-ftpd/auth
echo "no" > /etc/pure-ftpd/conf/PAMAuthentication

Und weil es gerade so Spaß macht, hier noch ein paar weitere Einstellungsmöglichkeiten, die eventuell interessant sind:

echo "20000 21000" > /etc/pure-ftpd/conf/PassivePortRange
echo "yes" > /etc/pure-ftpd/conf/IPV4Only
echo "500" > /etc/pure-ftpd/conf/MaxClientsNumber

Die PassivePortRange muss gegebenenfalls in der Firewall freigeschaltet werden. MaxClientsNumber darf maximal 500 betragen.

SSL (Implicit, AUTH TLS: Der aktuelle Standard) kann bei Bedarf ebenfalls aktiviert werden:

echo "1" > /etc/pure-ftpd/conf/TLS

Wobei 0 bedeuten würde kein TLS, 1 TLS + Klartext, 2 TLS erzwingen, 3 Datenkanal ebenfalls verschlüssen (erzwingen).
Der Schlüssel muss in der Datei „/etc/ssl/private/pure-ftpd.pem“ eingetragen sein. Liegen z.B. .crt, .key und .ca einzeln vor, können diese mit „cat“ zu einer Datei zusammengefügt werden. Ein eigenes self-signed Zertifikat kann alternativ ebenfalls erstellt werden. Vorab das entsprechende Verzeichnis erstellen, falls es nicht vorhanden ist:

mkdir -p /etc/ssl/private/
openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem

Den Key absichern vor fremden Zugriff:

chmod 600 /etc/ssl/private/pure-ftpd.pem

Soll beim Login eine eigene Willkommensnachricht angezeigt werden, etwa „Willkommen auf meinem FTP-Server“, müssen folgende Befehle ausgeführt werden:

echo "/etc/ftpwelcome" > /etc/pure-ftpd/conf/FortunesFile
echo "Willkommen auf meinem FTP-Server" > /etc/ftpwelcome

Via FortunesFile wird tatsächlich nur der Pfad zur Datei, die die eigentliche Nachricht enthält angegeben.

Jetzt wird der virtuelle Benutzer, der sich dem System gegenüber als www-data ausgibt erstellt. In diesem Fall erfolgt die Anmeldung am FTP also als Benutzer „ftpuser“, ein Passwort wird im Anschluss abgefragt. Am Ende des Befehls wird das Verzeichnis angegeben, in das der Benutzer sich einloggen wird:

pure-pw useradd ftpuser -u www-data -g www-data -d /var/www

Noch schnell die Datenbank aktualisieren, damit die Änderungen auch aktiv werden und im Anschluss den Pure-FTPd neustarten:

pure-pw mkdb
service pure-ftpd restart

Sind die Ports 20 und 21 (evtl. eben auch die PassivePorts) in der Firewall freigeschaltet, sollte die Verbindung nun hergestellt werden können. Alle Änderungen im Dateisystem werden als Benutzer „www-data“ ausgeführt.

Weitere Benutzer hinzufügen

Soll später ein neuer Benutzer hinzugefügt werden, reicht die Verwendung von „pure-pw useradd …“ im gleichen Format wie oben. Ganz wichtig: Anschließend immer pure-pw mkdb ausführen!