Die AMD Turion CPU kann die Frequenz nicht wechseln und hängt bei 800 MHz fest

Seit einiger Zeit habe ich ein Problem mit meinem alten HP Compaq 6715s. Dort ist eine AMD Turion 64 X2 Mobile TL-60 CPU verbaut. Seit dem Linux Kernel 4.2 kann diese AMD CPU die Frequenz nicht mehr skalieren. Durch die Verwendung von Linux 4.1 oder älter lässt sich das Problem leicht beheben, aber eine Lösung auf dauert ist das nicht.

Es scheint ein Problem mit ACPI zu geben, genauer gesagt mit ACPI IRQ. Eine Möglichkeit ist den Kernel mit acpi=noirq zu starten. Das führt unter Kernel 4.9 jedoch dazu, dass nur noch ein Core erkannt wird und der Laptop nicht mehr richtig herunterfahren kann. Für mich ist das keine zufrieden stellende Lösung.

Es gibt auf Launchpad von Ubuntu einen Bug Report und auch beim Linux Bugzilla. Bei Bugzilla Kommentar 25 werden weitere Lösungsvorschläge gemacht.

Den ersten Vorschlag habe ich mit Kernel 4.9.46 ausprobiert und es funktioniert nun alles wunderbar. Wer sowieso seinen Kernel kompiliert kann folgenden Patch werden.

AMD-Turion-IRQ.patch.xz

Virtualbox VDI Dateien verkleinern

Vor kurzem ist mir aufgefallen, dass die VDI Dateien meiner VMs in Virtualbox relativ viel Platz auf dem Host System verbrauchen. Die VDIs sind dynamisch, jedoch wachsen die Dateien nur an und werden nicht automatisch verkleinert.

In einem Linux Gast muss man dazu den freien Platz mit Nullen überschreiben. Das geschieht relativ einfach mit

dd if=/dev/zero of=wipefile bs=1024x1024; rm wipefile

Man kann das auch mit Root Rechten durchführen um ggf. für Root reservierten Speicherplatz auch mit Nullen zu beschreiben.

Danach die VM ausschalten um auf dem Host System mit folgendem Befehl die VDI Datei verkleinern.

VBoxManage modifyvdi --compact /pfad/zur/datei/file.vdi

Sollte man einen Windows Gast betreiben empfiehlt sich das kleine Programm sdelete welches direkt bei Microsoft verfügbar ist. Die neuere 2.01 Version ist endlich wieder ähnlich schnell wie 1.61. Für ältere Windows Version gibt es auch eine alte Version von sdelete, jedoch nur noch im web archive.

Das Programm verwendet man auf der Befehlszeile cmd oder mit der PowerShell.

sdelete64.exe -z c:

Danach auch mit VBoxManage die VDI Datei verkleinern.

Escape-Sequenz in for Schleifen mit find

Bei der Verwendung von for Schleifen in der bash wollte ich das find Programm benutzen. Doch leider funktionierte es nicht wie erwartet. Da es im Pfad auch Leerzeichen gab wurde, nach jedem Leerzeichen eine neue Schleife durchlaufen. Ich wollte aber nur für jeden Treffer von find das Kommando in der for Schleife ausführen.

for i in `find ./ -name "*.txt" -type f`
do 
    echo "$i"
done

Der Trick war vorher die Escape-Sequenz mittels

IFS=$'\n'

auf eine „newline“ umzustellen. Dann wurde in dem obigen Beispiel auch nur pro Treffer der echo Befehl ausgeführt und nicht schon nach jedem Leerzeichen.

In Postfix ganze Netzwerkbereiche sperren

In Postfix kann man mit check_client_access in den smtpd_recipient_restrictions sehr einfach IP Adressen direkt mit einem 554-Fehler ablehnen. Die meisten Anleitungen die man finden kann binden dann mit

 check_client_access btree:/etc/postfix/access_client,

oder

 check_client_access hash:/etc/postfix/access_client,

die zu sperrenden IP Adressen in die main.cf ein. Das funktioniert bei einzelnen Adressen auch sehr gut. Wenn man allerdings ganze Netzbereiche sperren will läuft man häufig in ein Problem. Denn diese Hash-Tables können nicht mit der CIDR-Notation umgehen. Es gibt die Möglichkeit immer mit ganze Adressblöcke zu sperren, aber oft ist das nicht genau genug.

 # KOMMENTAR
 192.168.1     REJECT
 192.168.1.100 OK

Dieses Beispiel würde 192.168.1.0/24 sperren, bis auf die Ausnahme 192.168.1.100/32.

Um dieses Problem zu beseitigen kann man in Postfix auch CIDR-Tables einbinden. Das geschieht mit

 check_client_access cidr:/etc/postfix/access_client_cidr,

Es ist kein Problem mehrere check_client_access in der main.cf zu haben. Der Aufbau ist folgender

 # KOMMENTAR
 192.168.1.100  OK
 192.168.1.0/24 REJECT

Wichtig ist hier, dass die Reihenfolge nicht egal ist. Genauere Einträge müssen vor allgemeineren Einträgen kommen. Das bedeutet das einzelne IP Adressen über den dazugehörigen Netzbereichen stehen müssen. Bei Hash-Tables spielt das keine Rolle.

Mit FFmpeg mehrere Dateien zusammenführen

Vor kurzem musste ich mehrere mp4 Dateien zu einer großen zusammen führen. Die mp4 Dateien mussten nicht bearbeitet werden und enthielten alle den selben Codec und auch die Parameter waren die selben. Mit FFmpeg konnte ich das Problem sehr einfach lösen.

ffmpeg -safe 0 -f concat -i mylist.txt -c copy output_file.mp4

Die Option concat fügt die einzelne Dateien, die in mylist.txt definiert sind, zusammen. Die safe Option wird nur bei absoluten Pfaden benötigt.

# this is a comment
file '/path/to/file1'
file '/path/to/file2'
file '/path/to/file3'

Die mylist.txt muss dieses Format enthalten. Die Datei und der Pfad in einfachen Anführungszeichen und davor „file“.

Da es etwas nervig sei kann jedesmal eine extra Datei anzulegen kann man die mylist.txt Inputdatei auch dynamisch erzeugen. Es ist darauf zu achten das man sich im selben Verzeichnis befindet wie die mp4 Dateien. Es wäre kein Problem die neue mp4 Datei von FFmpeg im selben Verzeichnis anlegen zu lassen.

ffmpeg -safe 0 -f concat -i <(printf "file '$PWD/%s'\n" *.mp4) -c copy ../output.mp4

Wenn die Dateien unterschiedliche Codec Parameter haben sollte man nicht mit copy arbeiten. Stattdessen müssen die Dateien dann mit neuen Parametern neu encodiert werden. Gerade bei x264 passiert es häufig, dass ein einfaches copy nicht funktioniert.  In der Output-Datei ist alles ab der ersten Input-Datei unbrauchbar. Wenn das passiert muss alles mit der concat Option neu encodiert werden. Dazu einfach copy durch die gewünschten Codec Optionen austauschen.

Zum Beispiel

ffmpeg -safe 0 -f concat -i <(printf "file '$PWD/%s'\n" *.mp4) -c:v libx264 -crf 22 -c:a aac -b:a 128k ../output.mp4

Apache Mod Substitute bei einem Reverse Proxy

Der Proxy für den mp3 Feed funktioniert sehr gut. Das Herunterladen der mp3-Dateien klappt gut, da der Podcast ein CDN verwendet. Die Shownotes werden in Podcast Addict per Android Webview dargestellt, und dieses hat auf meinem Huawei P9 kein Problem mit secp384r1 bei ECDH Chiffren. Nur das initiale Coverart Bild im Feed wird auch per interner URL Routine heruntergeladen.

Damit dieses Bild und die Episoden Bilder auch per Proxy heruntergeladen werden, muss der Inhalt des mp3 Feeds verändert werden. Da es sich nicht um HTML sondern um eine XML Datei handelt, kann man nicht den Mod „proxy_html“ verwenden sondern muss auf den Mod „substitute“ ausweichen.

Nachdem man mittels

a2enmod substitute

das Modul geladen hat kann man innerhalb von <Location …> damit arbeiten. Es ist zu beachten das wirklich jede Stelle ersetzt wird und das die Substitution nur auf die XML Datei des Feeds angewandt wird.

<Location "/podcast-ssl-problem/feed/mp3">
 SetOutputFilter INFLATE;SUBSTITUTE;DEFLATE
 AddOutputFilterByType SUBSTITUTE text/xml
 Substitute "s|https://problempodcast.de/wp-content/cache/|https://URL/podcast-ssl-problem/cache/|inq"
 ProxyPassReverse /
</Location>

Durch „SetOutputFilter“ wird die für die Übertragung komprimierte Datei, entpackt, verändert und wieder komprimiert.  Als Alternative könnte man auch

RequestHeader unset Accept-Encoding

setzten. Allerdings wird die XML Feed Datei dann nicht komprimiert übertragen.

Durch „AddOutputFilterByType“ werden nur Dateien verändert die als Type „text/xml“ haben. Normalerweise sollte in der <Location …> sowieso nichts anders vorkommen, aber man weiß ja nie.

Die Syntax von Substitute ist sehr ähnlich zu der von sed. Nach dem ersten Teil wird gesucht und mit dem zweiten Teil ersetzt. Die Option i am Ende bedeutet das Groß- und Kleinschreibung beachtet wird, n sucht nur nach dem Muster und verwendetet keine regulären Ausdrücke. Die Option q kann die Operation ein wenig beschleunigen.

Am Schluss sollte man nicht vergessen die Bilder auch per Reverse Proxy zugänglich zu machen.

ProxyPass "/podcast-ssl-problem/cache/" "https://problempodcast.de/wp-content/cache/"
ProxyPassReverse "/podcast-ssl-problem/cache/" "https://problempodcast.de/wp-content/cache/"

<Location "/podcast-ssl-problem/cache/">
 ProxyPassReverse /
</Location>

Einfacher Reverse Proxy mit dem Apache Webserver

Nachdem auch mit Kontaktaufnahme keine Lösung für mein Podcastfeed Problem gefunden werden konnte, habe ich mich entschlossen den Feed über einen Proxy abzurufen. Genauer gesagt handelt es sich um einen Reverse Proxy. Ich benutze dafür einen Apache Webserver, der auch noch andere Aufgaben erfüllt. Ziel war es eine möglichst einfache Konfiguration zu verwenden, die in einen bestehenden VirtualHost eingebaut werden kann.

Es müssen drei zusätzliche Module geladen werden, wobei „proxy_http2“ optional ist.

a2enmod proxy proxy_http proxy_http2

in die bestehende VirtualHost Konfiguration musste ich nur folgenden Inhalt hinzufügen

SSLProxyEngine on
ProxyPass "/podcast-ssl-problem/feed/mp3" "https://problempodcast.de/feed/mp3"
ProxyPassReverse "/podcast-ssl-problem/feed/mp3" "https://problempodcast.de/feed/mp3"

<Location "/podcast-ssl-problem/feed/mp3">
         ProxyPassReverse /
</Location>

Damit wird der mp3 Feed des Podcasts unter einer komplett neuen URL verfügbar gemacht. Das „SSLProxyEngine on“ muss in jedem Fall mit in die Konfiguration, auch wenn man den Proxy Feed nicht über TLS anbieten möchte. Da der original Feed eine automatische Weiterleitung auf https hat und der Proxy eine TLS Verbindung zum eigentlichen Webserver aufbauen muss.  Der Feed für meinen Podcastclient ist dann über https://URL/podcast-ssl-problem/feed/mp3 verfügbar.

TLS mit ECDH und secp384r1 auf dem Huawei P9

Vor kurzem ist mir aufgefallen das mein lieblings Podcastclient auf meinem Smartphone einen Podcastfeed nicht mehr abrufen kann. Der Test mit dem integrierten Browser zeigte aber kein Problem. Chrome konnte auf meinem Huawei P9 mit EMUI 5.0 den Feed ohne Probleme abrufen.

Nachdem ich mit dem SSL Server Test von www.ssllabs.com die URL getestet habe, ist mir aufgefallen, dass der Server nur TLS 1.2 mit ECDH Chiffren unterstütz. Das sollte eigentlich kein Problem sein, den auch die interne URL Routine unterstützt TLS 1.2 und ECDH Chiffren. Jedoch scheint es so zu sein, dass der Server nur secp384r1 anbietet, die interne URL Routine jedoch nur secp256r1 als Elliptische Kurve (EC) verwendeten kann.

Ähnlich wie bei den TLS Chiffren müssen auch bei den EC der Server und der Client sich auf eine bestimmte Kurve einigen. Wenn das nicht klappt kann eine verschlüsselte Verbindung aufgebaut werden. Neben secp256r1 gibt es eine ganze Reihe von EC die in Verbindung mit ECDH verwendet werden können.  Weitere sind z.B. secp384r1, secp521r1 oder brainpoolP512r1. Moderne Browser unterstützen relative viele verschiedene Elliptische Kurven, daher kann ich den Feed mit Chrome auf meinem Smartphone abrufen. Der interne URL Handler jedoch unterstützt wirklich nur die einfachste aller zulässigen Kurven, secp256r1. 

Um das Problem zu lösen, gibt es eine ganze Reihe von Möglichkeiten. Die einfachste ist neben dem Anbieten von secp256r1 serverseitig, auch die Aktivierung von alternativen Chiffren die den Diffie-Hellman-Schlüsselaustausch ohne Elliptischen Kurven verwenden. Wenn man allerdings keinen Zugriff auf den Server hat, bleibt nur der Reverse Proxy.

Greylisting für ausgewählte Clients

Auf der deutschen Postfix-user Mailingliste gab es einen interessanten Tipp zum greylisting.  Mich hat immer gestört, dass die meisten Mails erst sehr verzögert ankommen, allerdings ist greylisting immer noch ein effektives Mittel gegen Spam. Die Idee in dem Tipp ist greylisting nur für bestimmte Clients einzusetzen. Dabei geht man wie folgt vor.

Man fügt in smtpd_recipient_restrictions folgende Abfrage hinzu:

smtpd_recipient_restrictions =
      ...
      check_client_access pcre:/etc/postfix/greylisting.pcre,
      ...

und zusätzlich noch in der main.conf

smtpd_restriction_classes = greylisting
greylisting = check_policy_service inet:127.0.0.1:10023

Die Datei greylisting.pcre hat folgenden Inhalt:

# these look like IPs or are domain names with lots of labels
/(\-.+){4}$/ greylisting
/(\..+){4}$/ greylisting
# these look like dynamically assigned hostnames
/(^|[0-9.x_-])(abo|br(e|oa)dband|cabel|(hk)?cablep?|catv|cbl|cidr|d?client2?|cust(omer)?s?|dhcp|dial?(in|up)?|d[iu]p|[asx]?dsld?|dyn(a(dsl|mic)?)?|home|in-addr|modem(cable)?|(di)?pool|ppp|ptr|rev|static|user|YahooBB[0-9]{12}|c[[:alnum:]]{6,}(\.[a-z]{3})?\.virtua|[1-9]Cust[0-9]+|AC[A-Z][0-9A-F]{5}\.ipt|pcp[0-9]{6,}pcs|S0106[[:alnum:]]{12,}\.[a-z]{2})[0-9.x_-]/ greylisting
# these do not have a matching hostname->rdns mapping
/^unknown$/ greylisting
# these are countries with higher than average spam appearance
/\.br$/ greylisting
/\.cn$/ greylisting
/\.hk$/ greylisting
/\.id$/ greylisting
/\.in$/ greylisting
/\.kz$/ greylisting
/\.ru$/ greylisting
/\.th$/ greylisting
/\.tw$/ greylisting
/\.ua$/ greylisting
/\.vn$/ greylisting

Die Domains sollten natürlich den eigenen Bedürfnissen angepasst werden.

Fail2ban IPv4 sperren wieder rückgängig machen

Fail2ban ist ein sehr praktischer Dienst. Es werden Logs von Server Diensten durchsucht und IPv4 Adressen bei zu vielen Fehlern geblockt. Das blocken geschient normalerweise mittels iptables. Leider versteht Fail2ban in der Versin 0.9.x nichts von IPv6.

Trotz sorgfältig konfigurierten Filtern, kann es passieren das eine IPv4 Adresse irrtümlich gesperrt wird. Solange man sich noch am Server anmelden kann, kann man die Sperre sehr einfach rückgängig machen. Dazu einfach mit

fail2ban-client set JAIL unbanip MEINEIP

die IPv4 Adresse wieder frei schalten. JAIL muss durch den in der jail.conf definierten Jailnamen ersetzt werden. Ein Beispiel mit dem sshd Jail und dem apache-noscript Jail

fail2ban-client set sshd unbanip  203.0.113.124
fail2ban-client set apache-noscript unbanip 203.0.113.125