Alle Beiträge von adlerweb

Software

Aria2 als Daemon mit Webinterface unter Arch Linux

Schreibe einen Kommentar

Kurz und knapp: Aria2 ist ein Downloadmanager für Linux, welcher ein sehr großes Funktionsspektrum bietet – Downloads werden per HTTP/HTTPS, FTP, BitTorrent oder Metalink abgewickelt. Im HTTP-Bereich ist es möglich Downloads in mehrere Parts zu stückeln und diese von verschiedenen Mirror-Servern zu laden.

In meinem Fall soll das Ganze auf einem (GUI-losen) Linux-System laufen und von einem PC verwaltbar sein – so kann z.B. die neue Linux-Distro gemächlich über meine alte DSL-Leitung vor sich hin laden ohne meine Kabel-Hauptleitung zu belasten oder mich zu Zwingen den Rechner durchlaufen zu lassen. Als Host genügt dabei durchaus ein Linux-Embedded-System wie z.B. viele Router oder auch der Raspberry Pi.

Aria2 findet sich in den offiziellen Arch-Repos und lässt sich entsprechend direkt installieren. Für den Daemon-Modus nutze ich einen eigenen Benutzer namens „aria2“. Im Home-Verzeichnis des Nutzers wird (wenn nicht vorhanden) ein Ordner .aria2 erstellt (führenden Punkt nicht vergessen). Dort wiederum eine Datei namens aria2.daemon mit folgendem Inhalt:

continue
daemon=true
dir=/home/aria2/Downloads
file-allocation=falloc
log-level=warn
max-connection-per-server=4
max-concurrent-downloads=3
max-overall-download-limit=0
min-split-size=5M
enable-http-pipelining=true

enable-rpc=true
rpc-listen-all=true
rpc-user=rpcuser
rpc-passwd=rpcpass

Die Konfiguration weist Aria2 an als Daemon zu starten und alle Downloads in /home/aria2/Downloads zu speichern. Pro Server werden maximal 4 Verbindungen geöffnet, insgesamt 3 Downloads werden parallel geladen. Eine Bandbreitenbeschränkung für den Download ist nicht hinterlegt. In den letzten Zeilen werden die Zugangsdaten für das Frontend hinterlegt.

Anm: rpc-user und rpc-pass sind „deprecated“ und sollten nicht mehr verwendet werden, zum aktuellen Zeitpunkt wurde das hier verwendete Frontend jedoch noch nicht auf die neue Authentifizierungsmethode portiert

Anm2: file-allocation=falloc weist aria2 an den für den Download nötigen Platz im Vorfeld zu reservieren, dies verhindert Fragmentierung der Daten, jedoch kann es beim Start des Download einige Sekunden bis Minuten dauern bis die ersten Daten übertragen werden. falloc ist nur auf neueren Dateisystemen wie ext4, btrfs oder xfs nutzbar, bei älteren Systemen kann prealloc genutzt werden. Mit none wird die Reservierung abgeschaltet.

Um den Daemon automatisch beim Boot zu starten wird zudem die Datei /etc/systemd/system/aria2c.service erstellt:

[Unit]
Description=Aria2c download manager
After=network.target

[Service]
Type=forking
User=aria2
RemainAfterExit=yes
ExecStart=/usr/bin/aria2c --conf-path=/home/aria2/.aria2/aria2.daemon

[Install]
WantedBy=multi-user.target

Auch hier ggf. die Pfade an das eigene Setup anpassen.

Per systemctl start aria2c wird der Dienst gestartet – läuft dies ohne Fehlermeldung kann er mit systemctl enable aria2c in den „Autostart“ des Servers gelegt werden. Alles ist auch nochmal in der Arch-Wiki zu finden.

Für das Webinterface verwende ich webui-aria2. Es nutzt ausschließlich Javascript/HTML5 (Websockets/AJAX) für die Kommunikation, daher ist es weder notwendig die Daten auf dem selben System abzulegen, PHP/Python/Perl… zu installieren oder einen Webserver zu nutzen. Theoretisch kann die Datei auf der lokalen Festplatte des verwaltenden PCs/Laptops liegen und dort geöffnet werden. In meinem Fall liegen die Dateien auf einem bereits vorhandenen Webserver, so muss ich bei Updates nicht immer zwischen all meinen Geräten hin und her kopieren.

Beim öffnen der HTML-Datei werden die Zugangsparameter abgefragt. Bei Host wird die IP des Servers mit Aria2 eingetragen, der Port ist bereits hinterlegt. User/Passwort wurden in der zuvor erstellten Konfigurationsdatei eingerichtet.

Im Anschluss sollte die Verbindung aufgebaut werden können – am besten Prüft man das über Settings->Server Info, sind hier Daten hinterlegt konnte die Verbindung aufgebaut werden. Lasset die Downloads starten!

Bild: https://adlerweb.info/blog/wp-content/uploads/2014/05/aria2-300×195.png

Downloads direkt auf einem kleinen Linux-System? Check.

Zur Referenz: Der gezeigte Download ist Star Trek Phase II: Kitumba von startrekphase2.de.

Restmüll

btrfs und die delayed allocations (btrfs-delalloc)

Schreibe einen Kommentar

Vor etwa einem Jahr hatte btrfs bei mir den Status „beste wo (derzeit für mich) gibt“ erhalten. RAID-Funktionen sind mir zwar im erprobten MD-Code lieber, aber endlich ein Dateisystem mit Kompression ohne Lizenzgewürge. Leider hält die Praxis der damaligen Erwartung – zumindest bei mir – nicht stand. Offenbar gibt es derzeit lediglich einen Thread namens „btrfs-delalloc-„, welcher sich um das Schreiben der Daten kümmert – und das nicht sonderlich schnell. Vor allem bei größeren Datenmengen macht sich dieses Konzept negativ bemerkbar: Vor etwa 15 Minuten beispielsweise wanderten 15GB eines Videoprojektes per NFS auf meienen Server. Der Vorgang lief schön flott, aber kurz drauf war Schluss. Keine HTTP-Antworten, keine neuen SSH-Verbindungen. Auf einer bereits offenen Konsole zeigt sich das gewohnte Bild: Ein Prozess namens „btrfs-delalloc-“ hängt auf 100% CPU, IO-Wait an der Decke und nichts reagiert mehr. (Anm: WWW und System liegen auf einem physikalisch separaten Speicher, da hängts sicher nicht…). Mir erscheint es so, als ob dieser Prozess sich um alle btrfs-Mounts kümmert – ist einer ausgelastet ist auch für alle anderen Sendepause. Sehr unschön.

Bis jetzt habe ich noch nicht so ganz raus, was es mit dem Prozess auf sich hat, aber wenn sich da keine Abhilfe findet muss auf dauer wohl doch wieder fusecompress mit einem reiferen Dateisystem aushelfen :/.

Software

PHP: Gekürzte var_dump()-Ausgaben abschalten

Schreibe einen Kommentar

„Mal schnell“ ein paar Daten im PHP-Code lesbar ausgeben funktioniert üblicherweise sehr zuverlässig mit var_dump(). Auf einem System zeigte sich das Phänomen, dass lange Strings oder verschachtelte Arrays nicht vollständig angezeigt wurden. Ursache ist die Standardkonfiguration vieler Distros der PHP-Extension xdebug. In der entsprechenden ini-Datei lässt sich das Kürzen mit folgenden Zeilen unterbinden:

xdebug.var_display_max_data=-1
xdebug.var_display_max_children=-1
xdebug.var_display_max_depth=-1

Software

Gentoo: tcpdump -w kann keine Dateien schreiben / Dateien nicht auffindbar

Schreibe einen Kommentar

Mit tcpdump kann man sehr einfach auf der Konsole Netzwerkverbindungen mitlesen und so Fehler genauer betrachten. Üblicherweise lässt sich mit der Option „-w datei.pcap“ dieser Mitschnitt auch als pcap-Datei speichern, welche beispielsweise mit Wireshark geöffnet und weiter analysiert werden kann.

Unter Gentoo zeigten sich heute 2 seltsame Verhaltensmuster:

Mit absoluten oder relativen Pfaden:


tcpdump -i br0 -w /tmp/test.pcap
tcpdump: /tmp/test.pcap: No such file or directory

Ohne Pfad erscheint keine Fehlermeldung, die Datei wird aber augenscheinlich auch nicht erstellt:


host tmp # tcpdump -i br106 -w test.pcap
tcpdump: WARNING: br106: no IPv4 address assigned
tcpdump: listening on br106, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel
host tmp # ls -l test.pcap
ls: cannot access test.pcap: No such file or directory
host tmp #

Auslöser ist das USE-Flag „chroot“ – hierdurch wird der Prozess in ein virtuelles Root gesperrt, sodass Fehler (hoffentlich) nicht zu viel Schaden anrichten können. Alle Pfade beziehen sich auf /var/lib/tcpdump/ – entsprechend sind dort auch die ohne Pfadangabe generierten pcap-Dateien zu finden.

Software

./adb: No such file or directory

Schreibe einen Kommentar

Da Eclipse/Java auf all meinen Produktivsystemen – mal wieder – nur am abstürzen ist sollte es „mal schnell“ eine VM richten. Leider gab es bei der Installation der Android Developer Tools den o.g. Fehler. Etwas seltsam, denn die Datei ist vorhanden und lässt sich auch mit less & co lesen. Auch ldd ist keine große Hilfe – statisch gelinkt.

Lösung ist aber in der selben Richtung: Tatsächlich müssen die 32-Bit-Libraries installiert sein. Für Debian/Ubuntu/Mint hilft ein

sudo apt-get install ia32-libs

Software

Eclipse: „Workspace in use“ nach Absturz

Schreibe einen Kommentar

Nach einem Absturz konnte Eclipse nicht mehr auf den zuletzt geöffneten Workspace zugreifen. Um den Workspace wieder freizugeben muss im zugehörigen Verzeichnis die Datei .metadata/.lock gelöscht werden. Natürlich sollte man vorher mit ps o.Ä. sicherstellen, dass tatsächlich kein Eclipse mehr läuft, andernfalls könnten simultane Zugriffe zu Datenverlust führen.

Software

SSH: X11 connection rejected because of wrong authentication.

Schreibe einen Kommentar

„Mal schnell“ eine GUI über SSH aufrufen – normal kein Problem: Wenn auf dem Server X11Forwarding in der Datei /etc/ssh/sshd_config auf yes steht lässt sich mit ssh -vCXY user@host eine Verbindung starten, welche GUI-Aufrufe auf dem lokalen Rechner darstellt.

Heute leider nicht: GUI-Aufrufe verabschiedeten sich mit folgender Meldung:

X11 connection rejected because of wrong authentication.

An der SSH-Verbindung konnte man nichts sehen, diese Endete mit

debug1: Requesting X11 forwarding with authentication spoofing.

, also ohne Fehler.

Das Problem ist mal wieder aus der Kategorie „so einfach, dass man es übersieht“: Die Platte war voll…

df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 29G 28G 0 100% /

Nachdem wieder etwas Platz verfügbar war ging auch x11 per SSH wieder fehlerfrei.

Software

Arch Linux: Schlüsselfehler bei Update

Schreibe einen Kommentar

Nur „mal kurz“ updaten – „pacman -Syu“, paar mal Enter und schon ist das notwenige Übel von der Todo-Liste verschwunden. Nunja, üblicherweise. Auf einem System trat heute nach dem Download folgender Fehler auf:

Fehler: key "B02854ED753E0F1F" could not be looked up remotely
Fehler: Erforderlicher Schlüssel fehlt im Schlüsselbund
Fehler: Konnte den Vorgang nicht durchführen (Unerwarteter Fehler)
Fehler sind aufgetreten, keine Pakete wurden aktualisiert.

Ursache ist ja schon recht gut beschrieben: Ein Paket ist offenbar mit einem Key signiert, den das System noch nicht kennt. Üblicherweise versucht pacman dann diesen von den Arch-Servern(?) nachzuladen. In meinem Fall erfolglos – der Rechner hat keinen direkten Internetzugang und kommt nur per HTTP-Proxy nach draußen.

Um den Fehler zu beheben sollte man vor dem Systemupdate das Paket archlinux-keyring neu installieren. Dieses bringt alle aktuellen Schlüssel mit und aktualisiert die lokale Datenbank, danach sollten auch die restlichen Aktualisierungen problemlos laufen.

Software

WordPress, HTTPs optional und die SEO-Leute

Schreibe einen Kommentar

OK, Zertifikate erneuert, dann auch noch „schnell mal“ HTTPs im Blog einschalten. Oder auch nicht…

Ich habe bereits seit langem den Adminbereich meines Blogs über HTTPS eingebunden, hierzu ist lediglich ein einfaches

define('FORCE_SSL_ADMIN', true);

in der wp-config.php notwendig. Den Blog selbst hatte ich seinerzeit auf HTTP gelassen, denn nicht jeder hat die von mir verwendete Zertifizierungsstelle CACert installiert was zu unschönen Warnungen führen würde. Optional wäre toll, aber damals zeigte sich schnell, dass die SEO-Funktionen von WordPress aus dieser einfachen Sache mal wieder eine lange Geschichte machen. Anstatt Anfragen einfach zu verarbeiten wird zur Optimierung der Suchmaschinenplatzierung alles unbekannte auf die konfigurierte Hauptadresse umgeleitet – incl. dem für WordPress unbekannten https://….

Im Netz findet man häufig kleine Codefragmente, welche in der wp-config.php die interenen Adressen bei HTTPS-Zugriffen umbiegen sollen. In meinem Fall biss sich diese Methode leider mit dem verwendeten Cache-Plugins. Fündig geworden bin ich im Plugin „WP-SSL„. Über wenige Filter werden die Adressen direkt über die API ersetzt. Da so auch die Cacher entsprechende Ausgaben erhalten ist auch der parallele Einsatz kein Problem. Das Plugin ist für mich eher Vorlage als Fertiglösung gewesen – einige Zeilen für alternative URLs und Plugins musste ich ergänzen, aber generell ist die Methode praktisch und schnell zu verstehen.

Rekonfiguration erfolgreich – somit ist diese Seite jetzt auch offiziell (auf Wunsch) per HTTPS erreichbar – selbstverständlich auch mit PFS und paranoiden Schlüssellängen, auch wenn es wohl für einen einfachen Blog nicht wirklich etwas zur Sache tut ;).

Anm: Offenbar gibt es doch noch den ein oder anderen Client (IE auf WinXP, Android 2.3), welche noch kein SNI unterstützen – für die heißt es: „Sorry, aber ohne Update geht’s nur ohne“…