Alternative zu Image::Magick / Bildmanipulation

[janni]

Halloele,

ich suche eine alternative zu Image:Magick. Es geht um Bildmanipulationen, im speziellen um die Erstellung von Thumbnails mit Perl. Gimp scheint auch keine vernuenftige Moeglichkeit zu bieten.
Wichtig zu wissen ist, dass ich ein Programm / eine Bibliothek auf einem Server nutzen muss, auf den ich nur per FTP komme, also auf dem ich sonst eher nichts ausfuehren kann. Also geht beispielsweise ImageMagick nicht, weil es erst kompiliert werden muss.

Kennt jemand ein Perl-Modul, das mir helfen kann?

Gruss.

[Christoph Zurnieden]

Hallo,

ich suche eine alternative zu Image:Magick. Es geht um Bildmanipulationen, im speziellen um die Erstellung von Thumbnails mit Perl. Gimp scheint auch keine vernuenftige Moeglichkeit zu bieten.

Neuere Versionen von Gimp sind mit Perl fernsteuerbar. Scheint mir für Deinen Zweck aber auch etwas übertrieben ;-)

Wichtig zu wissen ist, dass ich ein Programm / eine Bibliothek auf einem Server nutzen muss, auf den ich nur per FTP komme, also auf dem ich sonst eher nichts ausfuehren kann.

"eher nichts" ist eine Einschränkung aus der ich entnehmen könnte, das das eine oder andere tatsächlich läuft, statisch gelinkte Programme als eine evt Alternative sein könnten.

Also geht beispielsweise ImageMagick nicht, weil es erst kompiliert werden muss.

Wenn Du weißt, welche Architektur der Server hat, könntest Du das Dingen auch statisch linken.

Kennt jemand ein Perl-Modul, das mir helfen kann?

Ich nehmen mal an, daß Du auf http://search.cpan.org/ nicht fündig geworden bist? Dann sieht es wahrscheinlich schlecht aus. Obwohl theoretisch möglich wird doch meist etwas fertiges, wie ImageMagik o.ä. genutzt.

Wenn überhaupt nichts nützt und eine libjpeg installiert ist, sind höchstwahrscheinlich auch die entspr kleinen Hilfsprogramme installiert.
'djpeg' dekomprimiert das JPEG (kann dabei auch die Größe ändern)
'cjpeg' komprimiert ein JPEG.
Das ganze als Pipe:
'djpeg -fast -scale 1/8 image.jpg | cjpeg > thumbnail_of_image.jpg'

Nachteile:

• braucht einige Voraussetzungen, die Wahrscheinlichkeit ist aber recht groß, das sie vorhanden sind
• ist aufgrund des Systemoverheads relativ(!) langsam.
• als Scalefaktoren sind IMHO nur 1/1, 1/2, 1/4 und 1/8 möglich. 1/8 macht z.B. aus einem 800x600 Bild eines mit 100x75.
• funktioniert nur mit JPEG (cjpeg kann allerdings auch die meisten BMP Formate, TARGA, PPM und PGM bearbeiten. Mit einem kleinem Umweg wären diese dann auch zu verkleinern.)

so short

Christoph Zurnieden

[Michael Schröpl]

Wichtig zu wissen ist, dass ich ein Programm / eine Bibliothek auf einem Server nutzen muss, auf den ich nur per FTP komme, also auf dem ich sonst eher nichts ausfuehren kann. Also geht beispielsweise ImageMagick nicht, weil es erst kompiliert werden muss.

Wenn Du auf dem Server eine Bibliothek nutzen darfst, dann doch offenbar aus einem CGI-Skript heraus, richtig?

Na, dann kannst Du auch ein kleines CGI-Skript schreiben, welches nichts anderes tut, als den (wahrscheinlich) make-Aufruf für die Übersetzung von ImageMagick auszuführen.

An anderer Stelle im aktuellen Forum sind mehrere CGI-Skripte beschrieben, welche Dir eine abgemagerte Variante von telnet zur Verfügung stellen würden. Ich habe mir selbst mal so ein Ding geschrieben - das ist gar nicht so furchtbar schwer - im Wesentlichen leisten die Perl-backticks schon fast alles, was Du brauchst.

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo Zusammen,

Wenn Du auf dem Server eine Bibliothek nutzen darfst, dann doch offenbar aus einem CGI-Skript heraus, richtig?

Na, dann kannst Du auch ein kleines CGI-Skript schreiben, welches nichts anderes tut, als den (wahrscheinlich) make-Aufruf für die Übersetzung von ImageMagick auszuführen.

Sollte das funktionieren, ist der Provider unverzüglich zu wechseln.
Wer schon derartige Lücken in der Eigensicherung aufweist, bei dem ist anzunehmen, das auch noch verschiedene andere bestehen, die zu durchaus peinlichen Vorfällen führen könnten.
Siehe auch die doch arg auf Sicherheit bedachten Leute von Sourceforge.net, die letztes Jahr dann doch die Compiler vom Shellserver ganz entfernen mußten.

An anderer Stelle im aktuellen Forum sind mehrere CGI-Skripte beschrieben, welche Dir eine abgemagerte Variante von telnet zur Verfügung stellen würden.

Auch ein telnet ist ein Zeichen mangelnden Sicherheitsbewussteins. SSH ist hier die erste Wahl. Das wäre mal eine Idee für Perlprogrammierer ;-)
BTW: auf gut administrierten Servern läuft normalerweise erst gar kein telnetd mehr. Das sagt doch schon viel, oder? ;-)

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Na, dann kannst Du auch ein kleines CGI-Skript schreiben, welches nichts anderes tut, als den (wahrscheinlich) make-Aufruf für die Übersetzung von ImageMagick auszuführen.
Sollte das funktionieren, ist der Provider unverzüglich zu wechseln.

Ich kann mir nicht vorstellen, daß das nicht funktionieren sollte.

Um das klarzustellen: Ich meint natürlich nicht, das Programm in ein _Systemverzeichnis_ installieren zu können.

Aber das Zielverzeichnis steht ja in diesem Fall im Makefile drin.
Also kann ich
1. das Makefile editieren und per FTP hochladen und
2. ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.

Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann - aber ich würde mich sehr wundern, wenn mir ein Provider _das_ irgendwie unterbinden, aber gleichzeitig normale eigene CGI-Skripte erlauben würde.
(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen und per CGI-Skript ausführbar machen ...)

Der Provider kann seine Maschine ggf. so konfigurieren, daß die Default-Shell 'sh' nicht viel kann (restricted shell etc.). Aber damit macht er so viele Freeware-CGI-Skripts kaputt (die beispielsweise "sendmail" aufrufen statt ein gleichwertiges Perl-Modul), daß er es besser bleiben lassen sollte.

Wenn man den Benutzern CGI erlaubt, dann bleibt außer Benutzerkennungen nicht mehr arg viel übrig zur Absicherung. Das muß aber auch reichen!
UNIX-Benutzerkennungen sind für den parallelen, abgeschotteten Betrieb getrennter shell-Benutzer gedacht - und ein CGI-Skript ist nichts wesentlich Anderes als eben eine solche Shell. (Weshalb ein solcher Provider ohne "cgiwrapper" wahrscheinlich auch nicht glücklich werden wird.)

Wer schon derartige Lücken in der Eigensicherung aufweist, bei dem ist anzunehmen, das auch noch verschiedene andere bestehen, die zu durchaus peinlichen Vorfällen führen könnten.

Ich glaube nicht, daß der Provider eine realistische Chance (oder auch nur ein Interesse!) hat, das zu verhindern.
Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?
Die Frage ist doch eher, welche Privilegien meine Benutzerkennung hat, d. h. ob sie auf /usr/bin lesend zugreifen darf etc. Dafür gibt es Konzepte wie chroot und Benutzerkennungen/Gruppen; nichts davon stört mich aber dabei, in meinem _eigenen_ Webspace Programme zu übersetzen und zu installieren. Solange sich die UNIX-Kiste wie eine UNIX-Kiste anfühlt, kann ich mich darauf wie auf einer UNIX-Kiste bewegen.

Siehe auch die doch arg auf Sicherheit bedachten Leute von Sourceforge.net, die letztes Jahr dann doch die Compiler vom Shellserver ganz entfernen mußten.

Davon weiß ich nichts. Hatten die Compiler selbst irgendwelche Sicherheitslücken und waren privilegiert installiert? Ansonsten würde ich es nicht verstehen.

An anderer Stelle im aktuellen Forum sind mehrere CGI-Skripte beschrieben, welche Dir eine abgemagerte Variante von telnet zur Verfügung stellen würden.
Auch ein telnet ist ein Zeichen mangelnden Sicherheitsbewussteins. SSH ist hier die erste Wahl. Das wäre mal eine Idee für Perlprogrammierer ;-)

Genau wie oben geht es mir nicht darum, per CGI das telnet-_Protokoll_ nachzubilden (wozu auch?), sondern die telnet-_Semantik_ (nämlich eine Dialog-Shell). Und die ist identisch zur SSH-Semantik - als Benutzer interessiert mich doch gar nicht, wie die Kommandos übertragen werden, sondern lediglich, welche Kommandos ich zur Verfügung habe.

Ein solches Skript ist zwar unsicherer als ssh (immerhin kann man kaum Passworte belauschen, weil es sich mangels "su" gar nicht lohnt, welche einzugeben), aber es ist nicht zu verhindern, ein solches Skript zu betreiben, wenn ich eigene CGI-Skripte installieren darf - es _ist_ nämlich ein eigenes CGI-Skript und nichts anderes.
Es ist sogar ziemlich exakt so sicher wie telnet, wenn ich es per server authentification && "AuthType Basic" zugangsschütze (es völlig offen herum stehen zu lassen wäre natürlich in der Tat schrecklicher Leichtsinn - aber nicht vom Provider, sondern von mir,weil ein Besucher dann genau _meine_ Daten zernichten kann, sonst aber keine.)

Insofern finde ich es ziemlichen Unfug, wenn ein Provider einem Benutzer eigene CGI-Skripte erlaubt und SSH nicht. Das Einzige, was er damit bewirkt, ist, daß sich der Benutzer eine weniger sichere 'SSH-Emulation' als CGI-Skript installieren muß ...

BTW: auf gut administrierten Servern läuft normalerweise erst gar kein telnetd mehr. Das sagt doch schon viel, oder? ;-)

Wahr, aber irrelevant (siehe vorheriger Absatz). Es geht nicht um das verwendete Protokoll.
Und HTTP kann der Provider ja schlecht verbieten, wenn er CGI-Skripte erlaubt - nicht wahr? ;-)

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo Zusammen,

Na, dann kannst Du auch ein kleines CGI-Skript schreiben, welches nichts anderes tut, als den (wahrscheinlich) make-Aufruf für die Übersetzung von ImageMagick auszuführen.
Sollte das funktionieren, ist der Provider unverzüglich zu wechseln.

Ich kann mir nicht vorstellen, daß das nicht funktionieren sollte.

Es muß Zugriff auf das System möglich sein. Aus Sicherheitsgründen sollte das bei Perl/PHP und wie sie alle heißen beim Aufruf aus dem cgi-bin abgeschaltet sein.Bei PHP Anbietern habe ich das schon öfter gesehen (ist auch IMHO fest ein- oder besser gesagt auscompilierbar), bzw schmerzhaft festgestellt ;-)

Um das klarzustellen: Ich meint natürlich nicht, das Programm in ein _Systemverzeichnis_ installieren zu können.

Ist bei UNIX ja auch nicht nötig.

Aber das Zielverzeichnis steht ja in diesem Fall im Makefile drin.
Also kann ich

1. das Makefile editieren und per FTP hochladen und
2. ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.

Nach (1) sollte (2) schon nicht mehr nötig sein.
Na gut, das 'make install' zumindest ;-)

Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann

$PATH kannst Du direkt beim Aufruf setzen:
'PATH="$PATH:/Dein/Pfad/zum/Programm" Programm'
Wichtiger ist evt das Linking (so nur bei Linux):
'LD_LIBRARY_PATH="/Dein/Pfad/zur/Programmlib" Programm'
Läßt sich beides kombinieren, muß aber alles davor stehen.

»»aber ich würde mich sehr wundern, wenn mir ein Provider _das_ irgendwie unterbinden, aber gleichzeitig normale eigene CGI-Skripte erlauben würde.

Wenn Du Dein Programm lauffähig im cgi-bin hast, kann er das nur mit hohem Aufwand und selbst dann nicht vollständig. Da hast Du durchaus Recht.

(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen und per CGI-Skript ausführbar machen ...)

Ja, nur hast Du da das Problem, das Du evt auch noch einen Compiler, Linker, div Tools auch noch hochladen mußt _und_ so gebaut, daß sie auf der Serverarchitektur/Kernelversion/LibCversion... auch laufen!

Es geht, ja, kann aber zu einem ungeheurem Aufwand ausarten ;-)

Der Provider kann seine Maschine ggf. so konfigurieren, daß die Default-Shell 'sh' nicht viel kann (restricted shell etc.). Aber damit macht er so viele Freeware-CGI-Skripts kaputt (die beispielsweise "sendmail" aufrufen statt ein gleichwertiges Perl-Modul), daß er es besser bleiben lassen sollte.

'sendmail' ist mittlerweile durch die vielen Sicherheitslücken und die schlechte Skalierbarkeit vielerorts durch 'qmail' o.ä. ersetzt worden. Dummerweise ist die Syntax nicht exakt die Gleiche. 'postfix' wird auch viel benutzt, da ist sie die gleiche.
(Nur mal notiert, falls jemand irgendwelche merkwürdigen Fehlermeldungen bekommt ;-)

Wenn man den Benutzern CGI erlaubt, dann bleibt außer Benutzerkennungen nicht mehr arg viel übrig zur Absicherung.

Es bleibt noch einiges, ist aber nur mit viel zu viel Aufwand einsetzbar. Da spielt dann wahrscheinlich der Kunde nicht mehr mit.
Obwohl der sich schon viel zu viel gefallen läßt für sein gutes Geld!

»»Das muß aber auch reichen!

Meistens reicht es auch, aber leider wirklich nur meistens :-(

UNIX-Benutzerkennungen sind für den parallelen, abgeschotteten Betrieb getrennter shell-Benutzer gedacht - und ein CGI-Skript ist nichts wesentlich Anderes als eben eine solche Shell.

Das ist nur äußerlich.
Das würde jetzt aber doch zu arg in die Eingeweide gehen um in diesem Forum (zudem auch noch alles archiviert wird! Schade eigentlich, ich fand die Idee mit dem Vorschlagen sehr gut. Hat wahrscheinlich das Archiv um ca 99% entlastet, was? ;-) Platz zu haben.

(Weshalb ein solcher Provider ohne "cgiwrapper" wahrscheinlich auch nicht glücklich werden wird.)

Es gibt auch andere (bessere?) Möglichkeiten, aber ganz 'ohne' geht es auf keinen Fall! ;-)

Wer schon derartige Lücken in der Eigensicherung aufweist, bei dem ist anzunehmen, das auch noch verschiedene andere bestehen, die zu durchaus peinlichen Vorfällen führen könnten.

Ich glaube nicht, daß der Provider eine realistische Chance (oder auch nur ein Interesse!) hat, das zu verhindern.

Er hat:
Einfach keinen Compiler anzubieten ist wohl die einfachste.
Wenn einer etwas braucht, muß er den Code hergeben, der wird dann (kostenpflichtig natürlich!) kompiliert und installiert.

Er kann Sorge tragen, daß die Programme im cgi-bin ausschließlich durch Interpreter gestartet werden, es wäre also nötig den Aufruf in ein Script zu verpacken, das geht aber nicht, wenn solche Befehle wie system() o.ä. einfach nicht vorhanden sind.

Aber keine Angst, so etwas ist nicht mit ein paar Klicks getan, das erfordert Fachwissen, das keiner der normalen Sysadmins besitzt. (Bei UNIX Admins ist der Grund meist der, daß sie einfach nicht dafür bezahlt werden ;-)

Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?

In einen C-Programm kann man sehr viele Sachen machen, die in Perl gar nicht, oder nur mit sehr hohem Aufwand möglich sind. Z.B. sich mit gesteuerten Pufferüberläufen in einen anderen Speicherbereich vorzutasten, der ihn überhaupt nichts angeht.
(Diese Möglichkeit bestand in einigen Linuxkerneln (deren Nummern ich hier besser nicht nenne (sind aber bekannt(nein, ich kann kein LISP ;-))), die leider noch auf einigen Servern laufen)

Außerdem kann ich den Perlinterpreter beschränken, das C-Programm eher weniger.

Die Frage ist doch eher, welche Privilegien meine Benutzerkennung hat, d. h. ob sie auf /usr/bin lesend zugreifen darf etc. Dafür gibt es Konzepte wie chroot und Benutzerkennungen/Gruppen; nichts davon stört mich aber dabei, in meinem _eigenen_ Webspace Programme zu übersetzen und zu installieren.

Sehr schön. Woher nimmst Du aber den Kompiler, so Du ihn nicht mitbringst und keine Zugriff auf das System hast?

Solange sich die UNIX-Kiste wie eine UNIX-Kiste anfühlt, kann ich mich darauf wie auf einer UNIX-Kiste bewegen.

Schön formuliert ;-)
Leider nicht ganz wahr, dafür können viel zu viele (eigentlich sogar noch zu wenige) Beschränkungen auferlegt sein.

Siehe auch die doch arg auf Sicherheit bedachten Leute von Sourceforge.net, die letztes Jahr dann doch die Compiler vom Shellserver ganz entfernen mußten.

Davon weiß ich nichts. Hatten die Compiler selbst irgendwelche Sicherheitslücken und waren privilegiert installiert? Ansonsten würde ich es nicht verstehen.

Es wurde zuviel Schabernack damit getrieben.
Die Compilefarm ist aber noch in Betrieb. Da läßt sich aber nichts linken, daß auf den Shellserven laufen würde.

An anderer Stelle im aktuellen Forum sind mehrere CGI-Skripte beschrieben, welche Dir eine abgemagerte Variante von telnet zur Verfügung stellen würden.
Auch ein telnet ist ein Zeichen mangelnden Sicherheitsbewussteins. SSH ist hier die erste Wahl. Das wäre mal eine Idee für Perlprogrammierer ;-)

Genau wie oben geht es mir nicht darum, per CGI das telnet-_Protokoll_ nachzubilden (wozu auch?), sondern die telnet-_Semantik_ (nämlich eine Dialog-Shell). Und die ist identisch zur SSH-Semantik - als Benutzer interessiert mich doch gar nicht, wie die Kommandos übertragen werden, sondern lediglich, welche Kommandos ich zur Verfügung habe.

Sollte es aber eigentlich. Geht schließlich um Deine Daten!

Ein solches Skript ist zwar unsicherer als ssh (immerhin kann man kaum Passworte belauschen, weil es sich mangels "su" gar nicht lohnt, welche einzugeben), aber es ist nicht zu verhindern, ein solches Skript zu betreiben, wenn ich eigene CGI-Skripte installieren darf - es _ist_ nämlich ein eigenes CGI-Skript und nichts anderes.

Habe sie mir jetzt mal genauer unter die Lupe gelegt.
Es sind schon arge Krücken, aber immer noch besser als überhaupt nichts.
Schöne Idee das Ganze!

Es ist sogar ziemlich exakt so sicher wie telnet, wenn ich es per server authentification && "AuthType Basic" zugangsschütze (es völlig offen herum stehen zu lassen wäre natürlich in der Tat schrecklicher Leichtsinn - aber nicht vom Provider, sondern von mir,weil ein Besucher dann genau _meine_ Daten zernichten kann, sonst aber keine.)

War 'AuthType Basic' nicht einer der 'don't use it's? ;-)
Ein wenig besser kann und sollte es dann doch sein.

Insofern finde ich es ziemlichen Unfug, wenn ein Provider einem Benutzer eigene CGI-Skripte erlaubt und SSH nicht.

Da kann ich Dir nur voll und ganz beipflichten!

Warum bekomme ich für mein gutes Geld nur so einen Schrott?
Archaisches Upload per FTP, damit machen die Jungs sogar noch Werbung!
Da schütze ich meine Seiten mühsam per Passwort in PHP Scripten und beim Upload kann sie dann jeder,der möchte, lesen?

HA!

Was kostet denn den Provider so ein SSH Zugang?
Software: nix.
Installation: per RPM o.ä.: so gut wie nix, aus den Quellen: ca 1 Stunde.
Einrichtung pro User: läßt sich automatisieren, also auch so gut wie nix.
Einrichtung der Restricted Shell: ca 3 Stunden, wenn man's sorgfältig macht
Prozessorzeit: komm, haumichab ;-)

Summe der Kosten bei 1000 Usern pro User: so gut wie nix (deutlich unter 1¢)

(Ha, endlich kann ich mal den ¢ außerhalb von /. benutzen ;-)))

»»Das Einzige, was er damit bewirkt, ist, daß sich der Benutzer eine weniger sichere 'SSH-Emulation' als CGI-Skript installieren muß ...

Die zudem wahnsinnig an Prozessorzeit fressen wird.

BTW: auf gut administrierten Servern läuft normalerweise erst gar kein telnetd mehr. Das sagt doch schon viel, oder? ;-)

Wahr, aber irrelevant (siehe vorheriger Absatz). Es geht nicht um das verwendete Protokoll.

Nein, das war schon klar. Mein Beispiel war wohl schlecht gewählt oder zumindest zu mager von erklärenden Worten begleitet ;-)

Und HTTP kann der Provider ja schlecht verbieten, wenn er CGI-Skripte erlaubt - nicht wahr? ;-)

Ja, das stimmt ;-)
Die zugrunde liegende Idee der o.a. Telnetähnlichen Scripte ist wirklich interessant. Werde mich wohl bei Gelegenheit mal näher damit beschäftigen.

so short

Christoph Zurnieden

[Michael Schröpl]

Hi Christoph,

Also kann ich

1. das Makefile editieren und per FTP hochladen und
2. ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.
   Nach (1) sollte (2) schon nicht mehr nötig sein.
   Na gut, das 'make install' zumindest ;-)

Eben - genau um diese eine Zeile geht es aber, die kann ich ohne
Dialogzugang ja nicht eintippen.

Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen
aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann
$PATH kannst Du direkt beim Aufruf setzen:
'PATH="$PATH:/Dein/Pfad/zum/Programm" Programm'

Mir ging es aber um die Verwendung des installierten CPAN-Moduls in
einem später via CGI aufgerufenen Perl-Skript, dessen PATH wahrscheinlich
im Webserver gesetzt (bzw. eingeschränkt) wird. Das kann ich mit einer
Konfiguration meiner Benutzerkennung kaum beeinflussen - also muß ich
die installierte Bibliothek sicherheitshalber absolut bzw. relativ
adressieren.

(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen
und per CGI-Skript ausführbar machen ...)
Ja, nur hast Du da das Problem, das Du evt auch noch einen Compiler,
Linker, div Tools auch noch hochladen mußt

Nicht, um einen CPAN-Modul zu übersetzen - in vielen Fällen brauche
ich dazu wirklich nur "make" und "perl".

Das würde jetzt aber doch zu arg in die Eingeweide gehen um in diesem
Forum (zudem auch noch alles archiviert wird! Schade eigentlich, ich
fand die Idee mit dem Vorschlagen sehr gut. Hat wahrscheinlich das
Archiv um ca 99% entlastet, was? ;-) Platz zu haben.

Ich halte unsere Diskussion für sehr viel archivierungswürdiger als
jede einzelne 2-Frames-Frage.

Einfach keinen Compiler anzubieten ist wohl die einfachste.

Compiler != make.
Aber in der Tat ist bei vielen kommerziellen UNIXen (AIX, SunOS, ...)
heute der C-Compiler gar nicht mehr im Standardausbau mit drin, sondern
muß separat dazu gekauft werden. (Ich entwickele auf solchen Maschinen,
heul ...)

Er kann Sorge tragen, daß die Programme im cgi-bin ausschließlich
durch Interpreter gestartet werden,

Wie macht man das? (cgiwrap?)

es wäre also nötig den Aufruf in ein Script zu verpacken, das geht
aber nicht, wenn solche Befehle wie system() o.ä. einfach nicht
vorhanden sind.

Ich habe noch nie ein Perl gesehen, welches kein 'system' und keine
backticks und keine Pipes und keine ... besaß. Wie baut man das alles aus?

Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes
Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?
In einen C-Programm kann man sehr viele Sachen machen, die in Perl
gar nicht, oder nur mit sehr hohem Aufwand möglich sind ...

Yep, das ist klar.
Ich meinte: Wenn ich FTP darf und CGI, dann kann ich ein Binary hochladen
und per CGI das "chmod +x" drauf setzen und dann läuft es. (Schlimmsten-
falls mache ich das Einzeiler-Perl-Skript mit system() drum herum, wenn
der Perl-Interpreter nicht sämtliche Möglichkeiten, Prozesse zu starten,
ausgebaut bekommen hat - ein dermaßen abgemagertes wäre die einzige Mög-
lichkeit, den Start beliebiger Programme via CGI zu verhindern.)

Außerdem kann ich den Perlinterpreter beschränken, das C-Programm
eher weniger.

Details, bitte? Das interessiert mich sehr.

Die Frage ist doch eher, welche Privilegien meine Benutzerkennung
hat, d. h. ob sie auf /usr/bin lesend zugreifen darf etc.
Dafür gibt es Konzepte wie chroot und Benutzerkennungen/Gruppen;
nichts davon stört mich aber dabei, in meinem _eigenen_ Webspace
Programme zu übersetzen und zu installieren.
Sehr schön. Woher nimmst Du aber den Kompiler, so Du ihn nicht
mitbringst und keine Zugriff auf das System hast?

Das ist lediglich ein bootstrapping-Problem. Wenn ich CGI und system()
im Perl-Interpreter habe, dann bekomme ich (fast) alles zum Laufen
(in USA soll es diverse Provider geben, die socket-Zugriffe unterbinden

• das ist natürlich lästig, dann läuft kein Suchmaschinen-Crawler mehr);
  schlimmstenfalls dauert es halt eine Weile. ;-)

War 'AuthType Basic' nicht einer der 'don't use it's? ;-)
Ein wenig besser kann und sollte es dann doch sein.

Welche Browser unterstützen "AuthType Digest" schon, und ab welcher Version?
(Du könntest ja mal meinen Feature-Artikel auf den neuesten Stand bringen ... ;-)

Die zugrunde liegende Idee der o.a. Telnetähnlichen Scripte ist wirklich interessant. Werde mich wohl bei Gelegenheit mal näher damit beschäftigen.

Falls es Dich interessiert - ich habe eines hier.
(368 Zeilen Perl, davon knapp 60% Kommentare.)

Viele Grüße
      Michael

[Christoph Zurnieden]

Hallo,

Also kann ich

1. das Makefile editieren und per FTP hochladen und
2. ein CGI-Skript schreiben, welches das Programm in ein Verzeichnis innerhalb _meines_ Webspace installiert.
   Nach (1) sollte (2) schon nicht mehr nötig sein.
   Na gut, das 'make install' zumindest ;-)

Eben - genau um diese eine Zeile geht es aber, die kann ich ohne
Dialogzugang ja nicht eintippen.

Ein Dialog muß es nicht unbedingt sein, aber weniger Aufwand wäre es schon ;-)

Ich muß es dann wahrscheinlich über den vollständigen Pfadnamen
aufrufen, falls ich nicht sogar $PATH entsprechend setzen kann
$PATH kannst Du direkt beim Aufruf setzen:
'PATH="$PATH:/Dein/Pfad/zum/Programm" Programm'

Mir ging es aber um die Verwendung des installierten CPAN-Moduls in
einem später via CGI aufgerufenen Perl-Skript, dessen PATH wahrscheinlich
im Webserver gesetzt (bzw. eingeschränkt) wird.

Ach so, war Mißverständnis meinerseits. Sollte aber kein großes Problem werden, wenn alles im cgi-bin sitzt.
Man beachte aber den Gebrauch des Konjunktivs im letztem Satz ;-)

(Notfalls kann ich mir sogar ein eigenes "make" per FTP hochladen
und per CGI-Skript ausführbar machen ...)
Ja, nur hast Du da das Problem, das Du evt auch noch einen Compiler,
Linker, div Tools auch noch hochladen mußt

Nicht, um einen CPAN-Modul zu übersetzen - in vielen Fällen brauche
ich dazu wirklich nur "make" und "perl".

Im Falle des ImageMagik Paketes reicht das leider nicht, und darum ging es ja. Bei reinen Perlpaketen kannst Du das zu Hause bauen und dann hochschicken. Nach ein wenig ausprobieren und evt Pfaden anpassen sollte es klappen.

Zweite Möglichkeit:
Ein 'make' in Perl. ;-)

Das würde jetzt aber doch zu arg in die Eingeweide gehen um in diesem
Forum (zudem auch noch alles archiviert wird! Schade eigentlich, ich
fand die Idee mit dem Vorschlagen sehr gut. Hat wahrscheinlich das
Archiv um ca 99% entlastet, was? ;-) Platz zu haben.

Ich halte unsere Diskussion für sehr viel archivierungswürdiger als
jede einzelne 2-Frames-Frage.

Das ist aber diskutabel!
SCNR ;-)

Einfach keinen Compiler anzubieten ist wohl die einfachste.

Compiler != make.
Aber in der Tat ist bei vielen kommerziellen UNIXen (AIX, SunOS, ...)
heute der C-Compiler gar nicht mehr im Standardausbau mit drin, sondern
muß separat dazu gekauft werden. (Ich entwickele auf solchen Maschinen,
heul ...)

Sei froh, daß Du nicht mehr auf die Mitgelieferten angewiesen bist. Ich kenne den Schrott zur Genüge der bei verschiedenen Versionen von IRIX, AIX, UNIX, SunOS etc beigepackt wurde und teilweise noch wird.
Aber zur Not gibt es immer noch GCC und die GLibc, obwohl beide nicht gerade das Gelbe vom Ei sind, so sind sie doch besser als o.a. ;-)

Er kann Sorge tragen, daß die Programme im cgi-bin ausschließlich
durch Interpreter gestartet werden,

Wie macht man das? (cgiwrap?)

Ja, am einfachsten durch einen Wrapper. Ich persönlich würde auch einen User/Gruppe 'cgi-bin' einführen, erleichtert einiges.
Ich bin allerdings kein Sysadmin (die Nerven hätte ich nicht ;-) und würde mir eher selber etwas schreiben als erst die Vorhandenen mühsam zu prüfen.

es wäre also nötig den Aufruf in ein Script zu verpacken, das geht
aber nicht, wenn solche Befehle wie system() o.ä. einfach nicht
vorhanden sind.

Ich habe noch nie ein Perl gesehen, welches kein 'system' und keine
backticks und keine Pipes und keine ... besaß. Wie baut man das alles aus?

Auskommentieren.;-)
Aber hier spricht der Programmierer. Einfacher wäre da wohl ein Wrapper namens 'perl' der den auszuführenden Code auf Vorkommen bestimmter Funktionen prüft.
Das ließe sich dann aber evt umgehen, falls der Wrapper nicht sehr sorgfältig programmiert ist. Auskommentieren ist da wohl die sicherste Methode. Bei PHP4 läßt sich IMHO (habe das Dingen schon lange nicht mehr gebaut) einiges schon beim Bauen abschalten.

Was geht es ihn auch an, ob mein CGI-Skript in Perl ein anderes
Perl-Modul oder ein semantisch gleichwertiges C-Programm aufruft?
In einen C-Programm kann man sehr viele Sachen machen, die in Perl
gar nicht, oder nur mit sehr hohem Aufwand möglich sind ...

Yep, das ist klar.
Ich meinte: Wenn ich FTP darf und CGI, dann kann ich ein Binary hochladen
und per CGI das "chmod +x" drauf setzen und dann läuft es.

beckmesserisch, als was Du mich ja mittlerweise kennengelernt hast ;-), würde ich einwenden, das es möglich wäre, daß chmod nicht zur Verfügung steht. Und:ja, es geht auch ohne, daß die Dateien in cgi-bin ausführbar sind.
(einfach via perl starten. Sehr vereinfacht: 'perl script'. Aber wirklich _sehr_ vereinfacht ;-)

(Schlimmsten-
falls mache ich das Einzeiler-Perl-Skript mit system() drum herum, wenn
der Perl-Interpreter nicht sämtliche Möglichkeiten, Prozesse zu starten,
ausgebaut bekommen hat - ein dermaßen abgemagertes wäre die einzige Mög-
lichkeit, den Start beliebiger Programme via CGI zu verhindern.)

Ganz genau. Aber wer macht das schon? ;-)

Außerdem kann ich den Perlinterpreter beschränken, das C-Programm
eher weniger.

Details, bitte? Das interessiert mich sehr.

Den Perlinterpreter kannst Du in seinen Funktionen beschneiden. Auf mehr oder weniger einfache Weise. Siehe auch oben.
Bei Maschinenprogrammen sieht das schon anders aus. Entweder läßt Du sie gar nicht erst zu.oder mußt sie in eine vollständige Sandbox stecken. chroot inklusive aller paranoid-patches für den Kernel und noch einigem mehr.

Die Frage ist doch eher, welche Privilegien meine Benutzerkennung
hat, d. h. ob sie auf /usr/bin lesend zugreifen darf etc.
Dafür gibt es Konzepte wie chroot und Benutzerkennungen/Gruppen;
nichts davon stört mich aber dabei, in meinem _eigenen_ Webspace
Programme zu übersetzen und zu installieren.
Sehr schön. Woher nimmst Du aber den Kompiler, so Du ihn nicht
mitbringst und keine Zugriff auf das System hast?

Das ist lediglich ein bootstrapping-Problem. Wenn ich CGI und system()
im Perl-Interpreter habe, dann bekomme ich (fast) alles zum Laufen

Ja, wenn.

(in USA soll es diverse Provider geben, die socket-Zugriffe unterbinden

Brutal und unnötig.

• das ist natürlich lästig, dann läuft kein Suchmaschinen-Crawler mehr);

Ja, tut man denn sowas? ;-)))

schlimmstenfalls dauert es halt eine Weile. ;-)

Ja. Ich nehme auch kaum an, das irgendjemand seinen Server so zuschließt, wie ich es tun würde. Meist sind sie dazu fachlich auch gar nicht in der Lage. Aber ein geübter Unix-Sysadmin mit Erfahrung kostet natürlich ein Stange mehr Geld als die 10,50 EUR/Std (muß man sich aber auch erstmal dran gewöhnen EUR zu schreiben ;-), die ein MSCE erwartet >;->

War 'AuthType Basic' nicht einer der 'don't use it's? ;-)
Ein wenig besser kann und sollte es dann doch sein.

Welche Browser unterstützen "AuthType Digest" schon, und ab welcher Version?

Oh wei, jetzt hast Du mich! ;-)
Was ich vermute und auch mal nachprüfen könnte wären Mozilla, Konqueror, w3m, jeweils letzte Version. Bei den beiden Letzgenannten könnte ich es auch zur Not eben einbauen ;-)

(Du könntest ja mal meinen Feature-Artikel auf den neuesten Stand bringen ... ;-)

Na, gut, dann schau ich mal nach und sag es Dir. Kann aber ein paar Tage dauern.

Die zugrunde liegende Idee der o.a. Telnetähnlichen Scripte ist wirklich interessant. Werde mich wohl bei Gelegenheit mal näher damit beschäftigen.

Falls es Dich interessiert - ich habe eines hier.
(368 Zeilen Perl, davon knapp 60% Kommentare.)

Oh, sorgfältig kommentiert?
Dann schicks doch einfach. Kompression nach Belieben, BZip2 bevorzugt.
Adresse oben.

so short

Christoph Zurnieden