FIXED: Apache 2.4.41-4

Für Euch frisch aus der Werkstatt: Apache httpd 2.4.41-4 löst das Problem „Apache httpd 2.4.41 mit defektem PIPE support

Fedora User können schon updaten

und zwar mit folgendem Befehl für FC29:

dnf -y update https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/noarch/httpd-filesystem-2.4.41-4.fc29.noarch.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/mod_ssl-2.4.41-4.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.41/4.fc29/x86_64/httpd-tools-2.4.41-4.fc29.x86_64.rpm

Die Version ist jetzt erst einige Minuten alt und wurde extra für uns gebaut \o/

Die FC30 Version gibt dann hier: https://koji.fedoraproject.org/koji/buildinfo?buildID=1393459

Alle Tests sind positiv, also könnt Ihr die erst einmal bedenkenlos installieren, solange die noch nicht im Fedora Updates Repo ist. Das sollte zwar heute noch der Fall sein, aber wem das CGI-Problem jetzt schon wie ein Furunkel am Hintern klebt, der kann sich jetzt vorzeitig entlasten 😉

Apache httpd 2.4.41 mit defektem PIPE support

Die Apache Webserver Version 2.4.41 hat einen defekten PIPE Support, was die Ausführung von CGI Scripten wie PHP Prozessen behindert. Abhilfe schafft nur ein Downgrade auf die vorherige Version.

Voraussetzungen für den Fehler

Als Voraussetzungen für den Fehler braucht man lange Ausgaben und die Ausführung von PHP als CGI, aber das ist natürlich nicht auf PHP begrenzt, es darf auf ein eigenes C Exe oder Perl sein. Bei uns war es ein PDF erzeugendes Script.

  1. httpd 2.4.41
  2. Das Script wird per CGI ausgeführt
  3. Das Script erzeugt lange Ausgaben von ~500kb

Die Symptome

Die Symptome an denen Ihr erkennen könnt, daß Ihr betroffen seid:

  1. Der Aufruf eines PHP Scripts per Browser timed aus.
  2. es stappeln sich die PHP Prozesse auf dem Server
  3. ein „strace -f -p ..hier_php_pid_angeben..“  zeigt nur eine Zeile an:
    … write( ………………….. ) = xXxXxx   , wobei die Xxx eine 6-x stellige Anzahl haben wird
  4. kurze Ausgaben, wie bei WordPresswebseiten üblich, werden normal abgearbeitet

Die Lösung

Für Fedora 29 lautet die Lösung einfach Downgraden:

dnf -y downgrade https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/httpd-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/mod_ssl-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/x86_64/httpd-tools-2.4.39-3.fc29.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/httpd/2.4.39/3.fc29/noarch/httpd-filesystem-2.4.39-3.fc29.noarch.rpm

systemctl restart httpd

Das war es dann auch schon. GGf. müßt Ihr noch liegen gebliebene Prozesse killen, aber die sollten beim httpd restart eigentlich von alleine terminieren, weil die PIPE endlich beendet wird.

Bugreport an Fedora ist raus, hat aber unverständlicherweise noch keine Reaktion hervorgerufen.

Willkommen im Club der TLS Verweigerer: Apache Foundation!

Nachdem ich die Admins von Mozilla dies Jahr endlich dazu bewegen konnte, für den Mailserver Ihres Bugtrackers TLS zu aktivieren, muß ich leider feststellen, daß eine der größten Organisationen im FOSS Bereich derbe ins Klo gegriffen hat:

Willkommen im Club der TLS-Verweigerer: Apache Foundation!

Eigentlich sagen Bilder ja mehr als tausend Worte, aber in dem Fall erfüllt eine einzige Logzeile den gleichen Zweck:

2019-09-09 12:20:07 H=hermes.apache.org (mail.apache.org) [207.244.88.153] F=<bugzilla@apache.org> rejected RCPT <empfänger@empfängerdomain.de>: Sender did not use TLS secured connection. Sender benutzte keine TLS gesicherte Verbindung.

Damit reiht sich die Apache Foundation erfolgreich in den Club der TLS-Verweigerer ein. Ich vermute, daß, da auch der Mozilla Bugtracker das gleiche Problem hatte, eine gemeinsame Programmbasis vorliegt, mit den gleichen schlechten Default Einstellungen! Da ich schlecht fragen kann, weil Emailantworten ja nicht ankommen, werden wir nie rausfinden woran das liegt 😉

Fest steht, daß gerade für einen Bugtracker, der ja „Security related Content“ transportiert, die TLS-Verweigerung ein klarer Sicherheitsbruch ist. Wünschen wir dem Verantwortlichen daher ein böses Erwachen.

Natürlich werde ich versuchen, Apache zum Besseren zu bekehren, aber erfahrungsgemäß sind Admins, die das nicht selbst merken oder es für kein Problem halten, schwer in die Realität zu überführen. Bei Mozilla hat es 2 Jahre gedauert 😉

Update: 22:19

Entschuldigt die Ausdrucksweise, aber „boar ist das hart!“ . Ich habe ja die Geschichten von den störischen OO Entwicklern nicht sooo richtig geglaubt, aber was da heute an dämlichen Antworten auf Bugreports kam, das haut dem Fass den Boden raus!

„Was für eine unfassbare Scheiße.:!!“

Ich melde da einen Segmentation Fault, der seit einigen Tagen auftritt und bekomme als Antwort: „Das liegt an Deiner Maschine.“ . Die „latest“ Version von OpenOffice ist 4.1.6 , die ist von September 2018, also rund 1 Jahr alt. Das der Rest der Welt da mal ein paar Updates eingespielt haben könnte und OO deswegen crashed, ist zwar primär richtig, aber sowas von arrogante Scheiße, daß man dem Herrn gern mal eins zwischen die Ohren geben will. „Es ist natürlich nicht unser uralt Code der da failed, es ist das Security Update auf Deinem Rechner, daß nicht mitspielt.“ Was denkt sich so ein Depp eigentlich?

Ticket Nummer zwei war dann zu dem fehlenden TLS im Mailserver, kam als Antwort „ist kein OOO Problem“. Was zum Geier ist ein OOO Problem? OpenOfficeOrganisation oder was? Das ist doch dem Reporter egal, ob das vom Apache Admin, oder vom Projektleiter gelöst wird, Fakt ist, daß die mit dem mangelnden TLS Support technisch in der Steinzeit leben. Das wurde Anfang der 90er Jahre des letzten Jahrtausends eingeführt, immerhin ist das fast !!! 30 !!! Jahre her! Echt unglaublich.

Aber diese Mentalität paßt natürlich zur „unser Code ist steinalt, deswegen ist der gut“ Antwort. Konsequent sind die ja dann irgendwie 😀

Es gibt nur eine Lösung

Da kann man nur eins empfehlen: dnf erase openoffice;dnf install libreoffice

Auch wenn ich LibreOffice nicht mag, da dort bei Präsentationen die Medien Einbindung nicht richtig funktioniert. Aber immerhin schicken die häufiger Updates raus.

Apache – .htaccess: No comments are allowed here

Schock in der Morgenstunde. Apache Produktionswebserver ausgefallen.

„No comments are allowed here“

Was zunächst nach einer Anpassung an die EU Datenschutz Grundverordnung klingt, ist ein harter Apachefehler, der seit 2.4.33-4 auftritt. Zum Glück ist das ein echt seltener Fehler, der durch eine Änderung des Configparsers des Webservers ausgelöst wird.

Von so einen Kommentar in einer .htaccess wird es ausgelöst :

### Hijackenden Proxys sperren ###
order deny,allow
deny from 1.1.2.4 #Webseite klaut Inhalte
### Ende Hijackenden Proxys sperren ###

und so müßte das korrekt aussehen:

### Hijackenden Proxys sperren ### 
order deny,allow 
#Webseite klaut Inhalte
deny from 1.1.2.4  
### Ende Hijackenden Proxys sperren ###

Also wenn Euch seit neustem ein 500er Fehler Eurer Webseite entgegenblickt, dann denkt an diesen Beitrag 😉

Alle Apacheprozesse gleichzeitig stracen

Der Apache Webserver kommt ja mit mehreren Methoden daher, wie er effektiv möglichst viele Anfragen gleichzeitig beantworten kann. Die alte Prefork-Methode, die nicht mit HTTP2 kompatibel ist, startet dazu einen Prozess mit wenigen Kindern und splittet neue Prozesse ab, sobald eine Anfrage reinkommt.

Ein einfaches strace -f -p [pidvonerstemhttpd] reicht völlig aus um alle Zugriffe auf den Apachen zu tracen.

Das Event-Modell

Im Eventmodell , das für HTTP2 nötig ist, klappt das nicht mehr ganz so leicht. Hier müssen tatsächlich alle laufenden Prozesse gleichzeitig getraced werden, was in dem Beispiel hier:

├─httpd─┬─httpd(apache)
│ └─4*[httpd(apache)───63*[{httpd}]]

schon sehr,sehr viel Tipparbeit wäre ( > 240 pids) . Natürlich kann man das vereinfachen, indem man ein paar kleine Shellanweisungen nutzt:

strace -f -p `pidof httpd | sed -e "s/ /,/g"`

pidof als Befehl gibt uns leerzeichensepariert alle Prozessids zurück, die zum Httpd gehören. Leider kann strace die so nicht verarbeiten, also müssen wir die Ausgabe in kommasepariert umwandeln, dies macht der SED – Befehl. Die Backticks führen die Befehlsanweisung vor dem Aufruf von strace aus, so daß das Ergebnis direkt als Argument benutzt werden kann.

Tor vs. AfD – NSA Style

Könnt Ihr Euch noch an diese Artikel errinnern ?

Was ist los? – Bundestagswahl ohne russische Beeinflussungskampagne
Bundestagswahl: Innenminister sieht bislang keine Einmischung Russlands

An der falschen Stelle gesucht …

Seit dem 9.9. läuft eine bislang weitestgehend geheime Aktion im TOR Netz gegen die AfD, die fast völlig an der Öffentlichkeit, den Behörden und den politischen Organen( und wohl auch der AfD selbst) vorbei gelaufen ist.

Heise.de war mal mit dem Beitrag dicht dran, ist aber an dem Warum gescheitert:  Wahlwerbung ueber access.log War übrigens keine Wahlwerbung Herr Bundesmann, war politische „Hetze“ 🙂

Read More

Web Korrekturen und Erweiterungen

Moin,

es gab bei mir Blog ja mal eine Kategorie: „Diese Woche im Netz“ , wo ich Meldungen aus aller Welt gepostet habe.

Diese Woche werde ich das mal wieder aufleben lassen, da einiges der Korrektur oder zumindest der fachlichen Erweiterung bedarf. Ja, das klingt jetzt überheblich, aber Ihr werdet gleich sehen was gemeint ist:

Wie man Dateien verschlüsselt

Quelle: https://www.howtoforge.com/tutorial/how-to-hide-lock-encrypt-and-secure-your-files-on-linux/

In dem Artikel finden wir folgende Aussage :

„Encrypting is the best way to secure your file so I am mentioning this step as the final one of this quick guide. … If you delete the original file, then you are left with the encrypted one that needs your password to get decrypted with the “mcrypt -d” command as shown below.“

Was ist daran falsch ?

Nun, wenn man eine Datei löscht, dann wird lediglich der Platz auf der Festplatte den die Datei belegt hat, wieder als verfügbar gekennzeichnet und der Eintrag im Verzeichnisbaum entfernt, ansonsten passiert „nichts“.  Dies bedeutet, daß der Inhalt der Datei auf der Festplatte immer noch gefunden werden kann. Wer also sicher gehen will, daß die Daten wirklich weg sind, der muß die Datei „nullen“ z.B. dd in=/dev/zero out=/pfad/zur/datei  und sie dann löschen. So wird sichergestellt, daß der Inhalt eben nicht mehr auf der Platte zu finden ist.

Jetzt kommt natürlich gleich die Argumentation, daß ja das Schreiben von neuen Dateien den Platz der alten, gelöschten Dateien belegt und damit den Inhalt überschreibt. Das stimmt rein technisch irgendwann mal, ist aber leider eine irreführende Annahme, denn man kann sich nicht darauf verlassen. Besonders bei SSDs und USB Flashspeichern fällt das eher unter „theoretisch“, denn diese Medien verteilen das Schreiben von Daten gleichmäßig auf alle Zellen des Speichermediums, damit diese gleichmäßig abgenutzt werden. Es wird somit genau das ständige Beschreiben eines Sektors vermieden. Ein Filesystem, das sich bewußt ist, daß eine SSD oder ein USB-Stick genutzt werden, wird dies unterstützen und das baldige überschreiben von Sektoren zusätzlich vermeiden.

Bei Flashspeichern ist das sogar noch schlimmer, die können einen zusätzlichen Speicherblock in der Hardware haben, um eine längere Lebensdauer zu gewährleisten, da ist die Chance, das eine Information überschrieben wird noch geringer.

Daher muß der Hinweis folgendermaßen lauten:

  1. handelt es sich um eine Festplatte mit Magnetspeicher, so erzeuge nach dem Löschen des unverschlüsselten Originals, genug zufällig Daten um die gesamte freie Speicherkapazität des Mediums zu belegen. Nur so ist gewährleistet, daß die unverschlüsselten Daten wirklich weg sind.
  2. Wesentlich cleverer ist es, gleich eine Festplattenvollverschlüsselung zu benutzen, mit der ergibt sich das Problem gar nicht erst, weil von außen gesehen ist alles verschlüsselt, auch die gelöschten Daten.
  3. Bei USB-Flashdrives möchte ich auf diesen Artikel verweisen, weil das Thema zu lang wäre : Mit LUKS einen USB Stick verschlüsseln

Man kann festhalten, daß es clever ist, erst ein Medium zu verschlüsseln, bevor man etwas aufspielt, daß man später wieder sicher löschen möchte.

Wie man HTTP/2 in einem Apache aktiviert…

hat Chris in seinem Blog beschrieben. Nunja Chris, da fehlen leider noch Infos 😉

Quelle: https://musicchris.de/index.php?page=blog&id=88

Mit dem Artikel ist erstmal alles ok soweit, im Detail möchte ich noch etwas anfügen. Zunächst mal ist HTTP/2 bereits in einem modernen Apache aktiv :

[root ~]# cat /etc/httpd/conf.modules.d/10-h2.conf
LoadModule http2_module modules/mod_http2.so
[root ~]# cat /etc/httpd/conf.modules.d/10-proxy_h2.conf
LoadModule proxy_http2_module modules/mod_proxy_http2.so

Man kann das natürlich auch zentral in einer Datei machen :

[root ~]# cat /etc/httpd/conf.d/http2.conf
LoadModule http2_module modules/mod_http2.so
Protocols h2 h2c http/1.1
ProtocolsHonorOrder On

[Anmerkung: Wenn man das in eine eigene Datei schreibt, sollte man es in den anderen deaktivieren, gibt sonst blöde Warnungen beim Start]

Was meint h2 und h2c ?

h2 (HTTP/2 over TLS)     ist HTTP2 verschlüsselt, weil es TLS einsetzen möchte

h2c (HTTP/2 over TCP)  ist HTTP2 über eine normale, unverschlüsselte Verbindung.

Beides ist völlig valide, weil für die Verschlüsselung einer Webseite noch immer die Protokolle HTTPS://  oder HTTP:// entscheiden. Wer Klartext nicht benötigt, kann das auch weglassen. Beides tut dem Nutzprinzip von HTTP/2 keinen Abbruch.

Wann funktioniert H2 nicht, auch wenn ich es geladen habe ?

Diese Frage bringt uns zum eigentlichen Knackpunkt der Sache, denn H2 funktioniert im Apache nicht immer. Wer seinen Apache über Jahre eingesetzt hat, wird einen schleichenden Wandel bemerkt haben. Früher ™ haben Apachen im PreFork-Modus gearbeitet :

LoadModule mpm_prefork_module modules/mod_mpm_prefork.s

Dabei wurde eine bestimmte Anzahl von Prozessen gestartet und die warteten auf Verbindungen. Funktioniert solide, aber nicht mit H2 🙂 Für H2 braucht es das Worker Event Modell:

LoadModule mpm_event_module modules/mod_mpm_event.so

Das Gemeine ist, daß Apache einem beim Start nur einen dezenten Hinweis gibt, daß H2 nicht mit PreFork arbeitet, aber ansonsten problemlos startet. Einen „You configured Nonsense“-Error sucht man vergebens.

Bundestagswahl – Du verbreitest Fakenews – Wahlergebnissoftware komplett für die Tonne

Quellen:

https://www.heise.de/newsticker/meldung/PC-Wahl-Debakel-Wahlleiter-versprechen-Sicherheit-nennen-aber-wenig-Details-3824970.html

https://ccc.de/system/uploads/230/original/PC-Wahl_Bericht_CCC.pdf


https://v–i–m–e–o.com/232663968 ( — bitte entfernen )
https://ccc.de/de/updates/2017/pc-wahl/

Keine Ahnung wer sich von Euch das PDF von Thorsten Schröder , Linus Neumann & Martin Tschirsich angetan hat, ich habe es komplett gelesen. Der Eindruck der sich einem da aufdrängt ist, das der Hersteller noch nie was von Security gehört hatte, bzw. in Salamitaktik nur die Kosmetik behebt, aber das Problem nicht, weil die das Problem nicht verstehen.

Ohne im Detail jetzt auf jede einzelne der selten dämlichen Fehler einzugehen, halten wir mal fest was wir da hatten:

  • – Webserver, deren Zugangsdaten bekannt waren.
  • – Updateprozesse, die man manipulieren konnte
  • – keinen Plan wie man von oben nach unten Authentizität gewährleistet, wobei das mit Zertifikaten problemlos möglich gewesen wäre.

Wer sagt uns jetzt, daß a) nicht schon lange jemand Schadsoftware auf den Rechner abgekippt hat ? b) was passiert wohl, wenn das Szenario „Übermittlungsmanipulation“ Realität wird ? Das amtliche Endergebnis mag durch einen zweiten Kanal gesichert sein, ich tippe ja auf Boten mit Aktenkoffern und Handschellen, aber was passiert bis das auffliegt ?

Das könnte so ablaufen …

18 Uhr, die Wahllokale schliessen. Ersten Hochrechnungen zufolge, liegen NCDU und VPD vorn, bereit eine neue GroKo zu basteln, die wieder nichts als Unsinn anstellt. Gegen 19 Uhr kommen die ersten Ergebnisse… DER SCHOCK… RPD und LPD mit 38% und 32% vorn, VPD und NCDU geschlagen. Merkel springt aus dem Fenster des Kanzleramtes, Gabriel und Schulz reden das Ergebnis schön, fern jeder Realität und unter stetig steigendem Alkoholzufluß immer viskoser. Die Grünen sind so blass, daß selbst Westerwelle (RIP) dagegen noch Farbe im Gesicht gehabt hätte.

Die Wahlparties der RPD und der LPD geraten stark außer Kontrolle, diverse Asylbewerberheime gehen in Flammen auf, diverse Schredderaktionen bei Banken kommen ins Stocken. Bängster und anderes Spekulantenpack im Freudentaumel. Hochranige Beamte packen die Koffer und setzen sich noch mit dem ersten Abendflug ins Ausland ab, da die RPD im Ruf steht unter den bisherigen Strukturposteninhabern aufzuräumen. Unterdessen rollen erste Bautrupps in Mecklenburg den Stacheldraht ab und beginnen Holzbaracken auf den jetzt umzäunten Grundstücken zu errichten. Erste Kommandeure der Bundeswehr plannen den Sturz der neuen Regierung.

Ok, der Trubel hält nur bis Dienstag an, aber der Schaden an Gebäuden und Regierungspersonal wird beträchtlich sein. Auch wenn die Freunde-von-Merkel-Partei-Deutschlands am Ende doch an der Macht bleibt, weil das A in AFD doch nicht so alternativ war, kann uns das mehr kosten als uns das liebt ist.

Da fragen wir uns jetzt mal: Muß das alles sein ?

Auch wenn es nicht ganz so hart kommt wie beschrieben 😉 , allein die Tatsache, daß für 16-24h ein anderer Wahlgewinner feststehen könnte, sorgt doch bei allen Parteien für Bedenken, daß das Wahlergebnis manipuliert wurde. Wenn die Wahl nicht im Sinne der jeweiligen Partei verläuft, kommen doch die Verlierer gleich mit „Der CCC hat gesagt, daß die Wahl….“ .. Popkornfaktor mal außen vor, son Chaos bei der Wahl können wir nicht wollen. Oder ?

Apache – Alles umleiten außer einem Pfad

Wer schon einmal eine Domain komplett z.b. auf https://domain.name umgeleitet hat, der kennt so einen Vhost Eintrag:

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    Redirect 301 / https://domain.name
</VirtualHost>

Was aber wenn man einen Pfad nicht umleiten kann/darf/will, weil das zu Problemen führen würde z.b. mit Lets Encrypt ?

Im Falle von Let’s Encrypt ist die Lösung ein negativer Pfadausschluß :

<VirtualHost *:80>
    ErrorLog /etc/httpd/logs/error_log
    CustomLog /etc/httpd/domlogs/domain_name.log combined
    LogLevel error
    ServerName domain.name
    ServerAlias *.domain.name
    RedirectMatch 301 ^/((?!.well-known/acme-challenge).*)$ https://domain.name
</VirtualHost>

Damit wird alles, nur nicht der Pfad „/.well-kown/acme-challenge“ umgeleitet. Es ist für Lets Encrypt jetzt wieder möglich, die Challenges abzufragen.

PANIC: fatal region error detected; run recovery

Ok, vorweg, es geht nicht um GeoIPs, Zeitzonen oder andere Sachen die mit geografischen Regionen zutun hat 🙂

PANIC: fatal region error detected; run recovery

Das ist eine Meldung der BerkeleyDB, einer filebasierten einfachen Datenbank, die Programme gern benutzen, wenn Sie keinen richtigen Datenbankbackend brauchen/wollen. Eins der Programme ist der Webalizer, ein Analysetool , das jedem statistiksüchtigen  Apachenutzer  ein Begriff sein dürfte.

Es kann vorkommen, daß diese Datenbank beschädigt wird. Die Anwendung gibt dann die obige Fehlermeldung aus, oder auch nicht, weil nach >dev/null umgeleitet.

Woran merkt man das also, wenn dieser Fehler auftritt ?

Zunächst mal, macht Webalizer nichts mehr, er kommt nicht mehr voran, weil … keine Ahnung wie man so fehlerintolerant programmieren kann, ich weiß es nicht. Also das Teil bleibt einfach stehen. Das sieht dann so aus:

           |-sshd(878)-+-sshd(3593)---sshd(3619)---bash(3631)---webalizer(13066)---java(13074)-+-webalizer(16621)-+-webalizer(16623+
           |           |                                                                       |                  |-webalizer(16624+
           |           |                                                                       |                  |-webalizer(16625+
           |           |                                                                       |                  |-webalizer(16626+
           |           |                                                                       |                  |-webalizer(16627+
           |           |                                                                       |                  |-webalizer(16628+
           |           |                                                                       |                  |-webalizer(16629+
           |           |                                                                       |                  |-webalizer(16630+
           |           |                                                                       |                  |-webalizer(16631+
           |           |                                                                       |                  `-webalizer(16632+

im TOP und IOTOP sieht man Webalizer kann auch nicht mehr auftauchen, weil die Prozesse in einem QuasiSleep sind.

Wenn man jetzt auf den Hauptprozess (oben die PID 16621 ) ein strace anwendet mit „strace -s 1024 +f +p 16621“ bekommt man das zu sehen:

strace: Process 16621 attached
write(2, "BDB0060 PANIC: fatal region error detected; run recovery", 56

und nichts passiert mehr. In dem Fall kann man strace einfach abbrechen und getrost die dns_cache.db löschen:

rm -f /var/lib/webalizer/dns_cache.db

Dann bricht man den Webalizer Hauptprozess mit kill ab, und startet das Ganze von vorn. Fertig.

Android 3.2 und das Let’s Encrypt Problem

Ich hab ja neulich auf HTTPS-Only Blog umgestellt, aber so ganz „Only“ geht es dann doch nicht.

Da die meisten RSS Feedleser für Handies die Zertifikate aus dem Truststore von Android benutzen, in dem Sie den internen Webbrowser benutzen um die Feeds anzuzeigen, kommt es mit Let’s Encrypt Zertifikaten zu Problemen: Die stehen da schlicht nicht drin. Wer da nicht drin steht, wird nicht angezeigt.

Das Problem habe ich bei meinen eigenen Android Programmen durch einen eigenen Truststore gelöst, der einfach die aktuellen Firefox Zertifikate bekommt. Das dieser Trick zwangsweise nur für eigene Programme funktioniert, mußte ich meinem Blog leider sagen, das Android weiterhin per Port 80 abrufen darf.

Und so geht so eine Ausnahme :

RewriteCond %{HTTP_HOST} .*marius\.bloggt-in-braunschweig\.de
RewriteCond %{SERVER_PORT}   !^443$
RewriteCond %{HTTP_USER_AGENT} !.*Android.3\.2.*
RewriteRule  (.*)  https://%{HTTP_HOST}/$1   [L]