Dies ist das Archiv zu der Kategorie 'Debian'.

Apache2 + PHP5-FPM + FastCGI und apache_request_headers() für Z-Push

Abgelegt unter Code, Debian, EDV, IT am 25.05.2014

(oder wie wird man langsam aber sicher in den Wahnsinn getrieben)

Nach dem neuesten Umzug mußte ich mich mit der Tatsache auseinandersetzen, daß mod_php zwar total unsicher, aber dafür sehr bequem ist, und suphp einem das Datei- und Ordner-Rechte-Thema sehr einfach macht.

Neuer Server läuft allerdings mit FastCGI, und da bei PHP ohnehin alles, was CGI-irgendwas ist, total Krätze läuft, war ich nicht erstaunt, als z-push in der Version 2.1 nicht mehr so tat wie es sollte.

Für suphp oder fcgid war das ja noch mit der compat.php getan, und schon hatte man das fehlende apache_request_headers() (oder getallheaders).

Problem bei FastCGI ist, laut PHP.net sollte mit Version 5.4 diese von so vielen Scripten genutzte Funktion nativ mit dabei sein, bei PHP5-FPM wohl noch nicht.
(wie immer bei den Dev’s von PHP; zuerst ja ja, kein Problem, dann wieder kräftig zurückrudern… oh, das erinnert mich ja noch an den full email disclosure… 😀 )

Wie dem auch sei, simples Script, um zu testen ob der Häuptling in der Lage ist, die nötigen Header auszuwerten:

<?php
if (empty($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');
echo "Need auth!";
exit;
}

list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode( ':', base64_decode(substr($_SERVER['PHP_AUTH_USER'], 6)) );
echo "<pre>";
print_r($_SERVER);
echo "</pre>";
?>

So, wer jetzt hier in der Endlos-Schleife landet, obwohl er die vielen tollen Tips aus dem Zarafa-Forum durchprobiert hat, die nötigen Aliase oder Rewrite-Rules in den entsprechenden .htaccess-Dateien durchgepfriemelt hat:
es liegt nicht an Euch.

Ich habe ein Wochenende damit verbracht, per trial & error eine funktionsfähige Lösung zusammenzuschrauben, was allerdings total unnötig ist.

Wenn Ihr shared Hosting gebucht habt, dann tut mir das leid, denn da könnte es sein, daß Euer Provider aus welchen Gründen auch immer Euch die nötige Konfiguration verweigern wird.
Für einen eigenen Server ist die Lösung so banal einfach:


FastCgiExternalServer /var/www/php-fpm/fpm.external -socket /var/lib/apache2/fastcgi/domain-fpm.socket -idle-timeout 400 -pass-header Authorization

(bitte auf die eigenen Gegebenheiten anpassen…)

Man kann ja ewig versuchen, einen Workaround für die Authentifizierung zu basteln; wenn der Apache die Header nicht bekommt, kann er auch nix auswerten.
Mit dem -pass-header Authorization, welches übrigens am Ende stehen muß, bekommt er wenigstens die User/Pass Daten übermittelt, was für z-Push ja ausreicht, denn der Rest ist ohnehin in der .htaccess hinterlegt:


RewriteEngine on
RewriteRule .* - [E=HTTP_MS_ASPROTOCOLVERSION:%{HTTP:Ms-Asprotocolversion}]
RewriteRule .* - [E=HTTP_X_MS_POLICYKEY:%{HTTP:X-Ms-Policykey}]
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

Tja, hätte man doch gleich mal auf die manpage geguckt…

Für mod_fcgid verhält es sich im Übrigen ähnlich, nur lautet es da:
FcgidPassHeader Authorization

Das eigentliche Problem ist der Indianer, der sich weigert den Authorization-Header an CGI-Skripte weiterzugeben.
Wenn man sein System eh from source baut, dann kann man das aber auch gleich mit:

export CFLAGS="-DSECURITY_HOLE_PASS_AUTHORIZATION $CFLAGS"
./configure [...]
make

abdrehen (bei shared Hosting wohl schwerlich möglich 😉 ).


Bildoptimierung (JPG und PNG) auf der Linux-Konsole

Abgelegt unter Code, Debian, EDV, IT am 24.05.2014

So, als erstes:

apt-get install jpegoptim pngcrush optipng

Danach wechselt man ins Verzeichnis, in dem die jpegs oder pngs liegen, und mit:

find . -name "*.jpg" -exec jpegoptim {} +

erzielt man für jpg durchaus passable Schrumpfung bei akzeptabler Qualität.
Ja, damit werden die Originale überschrieben, d.h. ein Backup ist vorher sinnvoll.

Und mittels:
find . -name "*.png" -exec pngcrush {} +

oder wahlweise:
find . -name "*.png" -exec optipng -o7 {} +

schrumpft man dann auc seine PNG’s ein.
Auch hier, ja das Original is futsch…


suPHP 0.7.2 unter Debian

Abgelegt unter Code, Debian, EDV, IT am 19.11.2013

Egal ob Squeeze oder Wheezy, suPHP sollte man immer selbst kompilieren.
(davon mal abgesehen, ob suPHP jetzt toll ist oder nicht, oder warum jemand noch immer nicht auf fcgid umgestiegen ist…)

Tja, dummerweise wird das nur mit:

autoreconf -vif

./configure --prefix=/usr --sysconfdir=/etc --with-apache-user=www-data --with-setid-mode=paranoid --with-apxs=/usr/bin/apxs2

make

make install

funktionieren 😉



blog powered by wordpress
Design by Office and IT - Business Solutions
Optimiert durch suchmaschinen-freundlich

Cookie Preference

Please select an option. You can find more information about the consequences of your choice at Help.

Select an option to continue

Your selection was saved!

Help

Hilfe

Um meine Seite zu besuchen, mußt Du eine Wahl bzgl. der Cookies treffen.

  • Ale Cookies akzeptieren:
    Da kommt der ganze Tracking-Scheiss...
  • Nur first-party Cookies akzeptieren:
    Nur die Cookies meiner Wordpress-Installation.
  • Alle Cookies ablehnen >:-):
    Gar keine Cookies außer vielleicht so Session-Kram (ansonsten deaktiviere bitte Cookies im Webbrowser).

Mein Versprechen: Datenschutz.

Back