Debian: Shell nach Neuinstallation umgänglicher machen

Jetzt wird es etwas subjektiv. Es geht um die Grundeinstellung der Bash.

1. Ganz zu Anfang wird die Dash durch Bash als Standard-Shell ersetzt. Das kann sehr hilfreich sein, da man mit der Zeit auf unerklärliche Fehler in Skripten stoßen könnte. Nämlich dann, wenn mit „#!/bin/sh“ als Kopfzeile gearbeitet wird.

dpkg-reconfigure dash

Dash als Standard-Systemshell (/bin/sh) verwenden? „Nein

2. Bash-Completion wird als Standard-Werkzeug installiert, allerdings nicht aktiviert. Bash-Completion ist für die Autovervollständigung zuständig, kennt man durch die TAB-Funktion: apt-get ins[TAB] linux-hea[TAB]“ etc. Für alle jetzigen- und zukünftigen Benutzer zu aktivieren in der Datei „/etc/bash.bashrc„:

#if ! shopt -oq posix; then
#  if [ -f /usr/share/bash-completion/bash_completion ]; then
#    . /usr/share/bash-completion/bash_completion
#  elif [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#  fi
#fi

Alle Rauten entfernen! Anschließend entweder neu einloggen oder die die bash.bashrc „sourcen“:

source /etc/bash.bashrc

3. Die Bash-Prompt farbig machen! …und den Hostnamen anzeigen. Der Fantasie sind keine Grenzen gesetzt. Meine Prompts sehen so aus:
prompt
Einzufügen mit folgendem Befehl (die BEIDEN „>“ sind wichtig, da sonst die Datei überschrieben würde):

echo 'export PS1="[\u@\[\e[32;1m\]\H \[\e[0m\]\w]\$ "' >> /etc/bash.bashrc

„Sourcen“, um die Änderungen aktiv werden zu lassen. Weitere Anzeigebeispiele findet Google.

4. „ls“ mit farbiger Darstellung und „ll“ als Alias für ausführliches Listing inkl. Farbe und aller Dateien einrichten:

echo "alias ls='ls --color=auto'" >> /etc/bash.bashrc
echo "alias ll='ls -la --color=auto'" >> /etc/bash.bashrc

„Sourcen“.

Debian Wheezy: pyLoad nur mit Webinterface, neues Init-Script

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.

FFmpeg – Videos HTML5-kompatibel mit FFmpeg konvertieren (webm, mp4, ogv)

Seit HTML5 können Videos nativ, also ohne zusätzliche Software eingebunden werden. Um vorhandene Video-Dateien zu konvertieren, benutze ich FFmpeg. Irgendwann habe ich die Commands mal niedergeschrieben, um mir das Getippe zu ersparen:

## WEBM:
ffmpeg -i movie.file -vcodec libvpx -b:v 600k -acodec libvorbis -ac 2 -b:a 96k -ar 44100 -vf scale=480:-1 -map 0 out.webm
## MP4:
ffmpeg -i movie.file -vcodec libx264 -b:v 600k -acodec libfdk_aac -ac 2 -ar 48000 -b:a 96k  -vf scale=480:-1 -map 0 out.mp4
## OGV:
ffmpeg -i movie.file -vcodec libtheora -b:v 600k -acodec libvorbis -b:a 96k -vf scale=480:-1 -map 0 out.ogv

Ist „libfdk_aac“ nicht vorhanden, so kann auch ein anderer ACC Encoder verwendet werden. Laut FFmpeg ist die Reichenfolge bezüglich der Qualität folgende:
libfdk_aac > libfaac > Native FFmpeg AAC ≥ libvo_aacenc

Mit „-map 0“ werden alle Streams der Datei verarbeitet. „-vf scale=480:-1“ gibt an, dass die Höhe unter Berücksichtung der Aspect Ratio selbstständig ausgewählt wird. Die Breite beträgt 480. Die Bitrates sind natürlich immer anpassbar, für kleine Web-Videos halte ich 480*x und 600k für das Bild für annehmbar.

Natürlich könnte man noch viel mehr einstellen. FFmpeg ist sehr gut dokumentiert, weshalb man auf (fast) jede Frage eine Antwort findet.

Welcher Browser welche Formate unterstützt, wird unter anderem hier beschrieben: http://www.w3schools.com/html/html5_video.asp

Nginx vor Floods schützen (limit_req)

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.