Probleme beim Verkleinern von Bildern

[Diesmal anonym... :-/]

Liebe SelfHTMLer,

ausnahmsweise moechte ich dieses Mal anonym posten, denn es geht um technische Probleme auf meiner etwas größeren Seite, die ich nicht gleich öffentlich an die große Glocke hängen möchte... Und zwar nicht, weil es etwa sicherheitskritisch wäre, sondern weil es meine Kernkompetenz betrifft, und man mir darum eigentlich abverlangen könnte, dass der Laden problemlos läuft... :-/

Erstmal zu den technischen Rahmenbedingungen, weiter unten dann zu den eigentlichen Problemen!

===========================================================
  VERFÜGBARE UMGEBUNG:

- Linux infong 2.4 #1
   - Apache 1.3.37 (Unix)
   - PHP Version 4.4.4
   - GD Version: bundled (2.0.28 compatible)

Das Ganze läuft auf einem L64-ManagedServer, bei dem ich nur begrenzte Einstellungsmöglichkeiten habe.
Aber folgende Servereinstellungen darf ich ändern:

Einbindung von PHP als: CGI-Programm
   Speichernutzung pro Prozess: 196608 kB (insg. habe ich 1GB)
   Prozesslaufzeit: 60 Sekunden
   Anzahl gleichzeitig ausführbarer Prozesse: 100

In der php.ini steht ausserdem Folgendes:
   memory_limit = 50M
   upload_max_filesize = 5M

===========================================================

Konkret handelt es sich um zwei Probleme, zu denen ich, um das Ganze übersichtlicher zu halten, zwei Threads anhänge!

Hier erstmal danke für eure Zeit und Mühe! Wenn ihr euch mit einem der beiden Probleme auskennt, bitte schaut rein!
Danke euch,
Anonymous ;-)

[Diesmal anonym... :-/]

Oh, wie gerne würde ich meinen Benutzern das Drehen von Bildern ermöglichen!!! :-(

GD-LIBRARY:
Aber mit der aktuellen Version der GD-Library bzw. der Art ihrer PHP-Einbindung geht das nicht:
"Diese Funktion steht nur zur Verfügung, wenn PHP mit der GD Bibliothek übersetzt wurde, die mit PHP zusammen erhältlich ist.".
Kennt ihr da vielleicht einen Ausweg?

IMAGEMAGICK:
Alternativ stünde möglicherweise ImageMagick zur Verfügung, nur kann ich halt leider auf dem ManagedServer nicht selbst kompilieren. Und ich habe nicht die geringste Ahnung, ob diese bereits kompilierten Releases für mein obiges Linux-System in Frage kommen?
Vor allem kann ich es nur live testen, wenn mir also der Server abschmiert, ist die Hoelle los! Was meint ihr? Und wenn ja, welches der Releases passt am ehesten?

ALTERNATIVEN?
Kennt ihr welche?

[Sven Rautenberg]

Moin!

Oh, wie gerne würde ich meinen Benutzern das Drehen von Bildern ermöglichen!!! :-(

Gib ihnen Irfanview zum Download. Das dreht Bilder, und skaliert sie, und all das noch vor dem Upload. Freeware für Windows, leicht zu installieren.

Kennt ihr da vielleicht einen Ausweg?

Der wird dir aber nicht gefallen.

Vor allem kann ich es nur live testen, wenn mir also der Server abschmiert, ist die Hoelle los! Was meint ihr? Und wenn ja, welches der Releases passt am ehesten?

Einen Testserver zu haben ist Grundvoraussetzung für eine "große und bekannte Website, bei der es peinlich ist, wenn bekannt wird, dass deren Hauptverantwortlicher anonym im SELF-Forum Hilfe nachfragt".

ALTERNATIVEN?
Kennt ihr welche?

Vernünftigeres Serverhosting, bei dem Eingriffe der beschriebene Art möglich sind. Identischer Testserver, auf dem alle Eingriffe vorher durchgespielt werden können. Ein Admin, der die Systeme im Griff hat.

- Sven Rautenberg

[Diesmal anonym... :-/]

Hallo Sven,

ich wollte mich ja eigentlich nicht verteidigen, aber du hast aus einer generellen Perspektive natuerlich schon soweit Recht mit deiner Äußerung:

Einen Testserver zu haben ist Grundvoraussetzung für eine "große und bekannte Website, bei der es peinlich ist, wenn bekannt wird, dass deren Hauptverantwortlicher anonym im SELF-Forum Hilfe nachfragt".

Generelle Perspektive deshalb, weil natürlich alles relativ ist:
das obige "bekannt" kannst du eigentlich wieder streichen, bekannt ist Spiegel Online (und das hatte ich ja so auch nicht geschrieben). Und der "Hauptverantwortliche" ist in Wahrheit der "einzig Verantwortliche", der darum auch alles gleichzeitig im Griff haben muss. Nur ist es leider nicht machbar, auf jedem Gebiet Spezialist zu sein - man hat halt nur zwei Hände. Auch kann man erst dann ein Spezialist sein, wenn man die Probleme bereits mal hatte - oder eine entsprechende Ausbildung erhalten hat.
Da die Seite aber sehr evolutionär gewachsen ist, mit einem anfänglich kaum messbaren Wissensstand, und trotzdem was draus geworden ist, mache ich mir da eher wenig Vorwürfe. Trotzdem danke für deine Kritik, ein wenig Aufrütteln hat noch keinem geschadet ;-)

Vernünftigeres Serverhosting, bei dem Eingriffe der beschriebene Art möglich sind. Identischer Testserver, auf dem alle Eingriffe vorher durchgespielt werden können.

Stimmt, ich entwickle unter Windows, das geht als Testserver kaum durch. Aber ein identischer (!) Testserver kostet halt leider auch Geld, ist ja nicht so, dass ich hier YouTube am Laufen hätte und Google mir die Kohle hinterherwirft... :-/

Ein Admin, der die Systeme im Griff hat.

Ok, klingt verlockend. Zwei Varianten:
a) ich stelle einen ein, der das drauf hat. Gib mir noch ein bisschen Zeit ;-)
b) ich lern's selber, oh-oh, die Stimme der Vernunft. Ich weiss, solche Fragen sind kaum pauschal zu beantworten, aber trotzdem:

wie hoch schätzt ihr den zeitlichen Lernaufwand ein, bis ich in der Lage bin, einen Lamp-Webserver eigenständig zu managen - ohne große Kunststücke, aber so, dass das Teil stabil, aktuell und sicher ist?
Vergleicht das doch mal bspw. mit dem erstmaligen Erlernen einer Programmiersprache (inkl. aller wichtigen OOP-Konzepte) - falls sich das irgendwie abschätzen lässt.

Und gleich noch eine Frage: gibt es ein Buch, dass du/ihr empfehlen könnt? Speziell zum Thema "Wartung eines Webservers unter Unix".

(Immer noch) Anonymous

[Diesmal anonym... :-/]

Hallo Sven, hallo alle,

nochmal ich ;-) Unabhängig von oben geäußerter Einsicht würde ich das aktuelle Problem natürlich trotzdem gerne lösen.

Soweit ich das sehe, ließen sich sowohl das Verkleinerungs- als auch das Dreh-Problem mit ImageMagick in den Griff bekommen.

Bedeutet das, wenn mein "Linux infong 2.4 #1" in dieser Liste nicht steht, brauche ich es auch garnicht erst probieren?
Oder andersrum gefragt: welches würdet ihr am ehesten probieren?

Vor allem kann ich es nur live testen, wenn mir also der Server abschmiert, ist die Hoelle los!

Natuerlich koennte ich es irgendwann um 4 Uhr Nachts machen, das wuerde schon gehen. Was wäre denn der WorstCase, mit dem ich rechnen muss?
Wir wollen jetzt mal davon ausgehen, dass das kein Schadprogramm ist, sondern nur eine unpassende Installation.
Kann ich den Server damit endgültig lahmlegen?
Würdet ihr mir eher abraten?

Danke euch,
Anonymous

[dedlfix]

echo $begrüßung;

Bedeutet das, wenn mein "Linux infong 2.4 #1" in dieser Liste nicht steht, brauche ich es auch garnicht erst probieren?

infong ist nur der Name eines Servers bei S+P. Als Distribution müsste Debian zum Einsatz kommen. Jedenfalls liegt auf dem infong117 in /etc eine Datei namens debian_version mit dem Inhalt "3.0" rum.

echo "$verabschiedung $name";

[Diesmal anonym... :-/]

Beim Hochladen von Bildern sollen diese automatisch verkleinert werden. Das funktioniert auch soweit, erst bei großen Bildern beginnen die Probleme. Dabei betrifft das ganz offenbar nicht die Dateigröße der JPGs, sondern ihre Abmasse. Beim Bearbeiten werden sie ja unkomprimiert geladen!

Ab einer gewissen Größe bekomme ich dementsprechend eine Fehlermeldung, hier ein kurzes (relativ extremes) Beispiel:

VERWENDETES BILD:
      - JPEG, 12 MegaPixel (4048 x 3040 Pixel)
      - Dateigröße: 213 kB (!!!)
      - Größe entkomprimiert: ca. 35 MB
      - Servereinstellungen: wie oben

ERZEUGTER FEHLER:
      Fatal error: Allowed memory size of 52428800 bytes exhausted
      (tried to allocate 4048 bytes) in /homepages/[...]/resize.php on line 10

AUSLÖSER:
   $img_src = ImageCreateFromjpeg ($imgname);

Die angegebenen "52428800 bytes" entsprechen exakt der 50M-Angabe in der php.ini (s.o.). Die angegebenen "4048 bytes" entsprechen jedoch mitnichten dem fehlenden Speicher! Denn auch mit 10 MegaPixeln kommt diese Meldung, der Overhead scheint also wesentlich größer zu sein als nur 15 MB (50MB verfügbar minus 35MB für das entkomprimierte Bild).
Obige Servereinstellung ("Speichernutzung pro Prozess: 196608 kB") scheint dabei überhaupt keine Relevanz zu haben...

Hier die Frage:
Was kann ich tun, um einem Benutzer MINDESTENS die Verwendung eines 10-MegaPixel-Bildes zu ermöglichen?

(Für den Fall, dass jetzt kommt, ich solle die php.ini-Einstellung erhöhen: ist das der einzige Weg? Ich habe etwas Angst, dass das die Serververfügbarkeit einschränken könnte!!!)

[Sven Rautenberg]

Moin!

ERZEUGTER FEHLER:
      Fatal error: Allowed memory size of 52428800 bytes exhausted
      (tried to allocate 4048 bytes) in /homepages/[...]/resize.php on line 10

PHP verwaltet seinen Speicher ja automatisch und nimmt sich immer bei Bedarf ein weiteres Stück. An dem Punkt der Fehlermeldung wollte PHP weitere 4048 byte haben, geriet damit aber über die Grenze von 50 MB. Deshalb der Skriptabbruch.

Hier die Frage:
Was kann ich tun, um einem Benutzer MINDESTENS die Verwendung eines 10-MegaPixel-Bildes zu ermöglichen?

PHP ist nicht dafür geeignet, riesige Megapixel-Bilder kleinzurechnen. Der Grund dafür liegt schlicht in der Art, wie PHP Bilder mittels gdlib verarbeitet, nämlich unkomprimiert im Speicher. 10 Megapixel mit 3 Byte pro Pixel sind eben 30 Megabyte Speicher. Plus den Speicher für das Zielbild (auch wenn das deutlich kleiner sein dürfte), plus den Speicher, den PHP für den Rest des Skriptes und sich selbst noch so braucht.

Die Lösung wäre natürlich, einfach den Speicher für PHP soweit hochzuschrauben, dass PHP einfach nicht mehr an die Grenze stößt, aber wirklich befriedigend ist das nicht.

Die Lösung ist eigentlich simpel: Entweder kriegst du alternative Skalierungssoftware an den Start (ImageMagick ist brauchbar), oder du stellst sicher, dass die User ihre Bilder gefälligst vor dem Upload schon kleiner machen.

(Für den Fall, dass jetzt kommt, ich solle die php.ini-Einstellung erhöhen: ist das der einzige Weg? Ich habe etwas Angst, dass das die Serververfügbarkeit einschränken könnte!!!)

Die Angst ist sicher berechtigt. Apache erlaubt im Standardfall 150 Prozesse, mithin wäre also 150 * 50 MB Speicher (= 7,5 GB) für PHP belegt, plus das, was der Apache, die restlichen Prozesse und das Betriebssystem noch so benötigen.

Auch wenn das nicht der Normalzustand ist - aber ein Angreifer könnte ja einfach parallel 150 Bilder hochladen (jeweils 200 KB groß - das stört niemanden), und wenn PHP dann anfängt, die Bilder zu skalieren, steigt mit Sicherheit dein Server aus, indem er im Thrashing verreckt.

- Sven Rautenberg

[Diesmal anonym... :-/]

Danke Sven, diese Antwort hat mir sehr geholfen!!!

[Felix Riesterer]

ausnahmsweise moechte ich dieses Mal anonym posten

Ich hätte da 'nen Verdacht, wer das sein könnte... aber ich sollte fair bleiben. :-(

Liebe Grüße aus Ellwangen,

Felix Riesterer.