skript mit dem online-angemeldeten user starten - wie?

[ich++]

Hallo,

hab schon letzten Monat mein Problem angesprochen, und zwar Folgendes:

Ich habe ein per-script, was eine html-Seite generiert.
Nachdem sich der user online anmeldet (.htaccess) auf dieser Seite anmeldet(.htaccess) erscheint diese Seite und er kann mithilfe des Skripts einige Dateien in seinem Home-verzeichnis modifizieren (lesen, schreiben, erstellen, löschen)
Als Lösung wurde mir Suexec vorgeschlagen. So weit ich es aber mittlerweile verstanden habe, setzt dies voraus, dass die aufrufbare Datei Eigentum des Users ist und sich in seinem home-verzeichnis befindet.
Das wäre für mich ziemlich unpraktisch, da das gleiche Skript mehrfach (für jeden User ) erstellt werden muss und vor allem von dem jeweiligen user erstellt sein muss...
Ist es so oder sehe ich da was falsch?

[Alexander (HH)]

Moin Moin!

Hallo,

hab schon letzten Monat mein Problem angesprochen,

Such doch bitte mal den Thread-Link aus dem Archiv, damit wir nicht wieder von vorne anfangen müssen.

Ich habe ein per-script, was eine html-Seite generiert.

Warum gibt es nicht einfach HTML aus? HTML-Resourcen müssen nicht zwingend HTML-Dateien sein.

Nachdem sich der user online anmeldet (.htaccess) auf dieser Seite anmeldet(.htaccess) erscheint diese Seite und er kann mithilfe des Skripts einige Dateien in seinem Home-verzeichnis modifizieren (lesen, schreiben, erstellen, löschen)

Apache-Benutzer (per .htaccess) und System-Benutzer sind zwei vollkommen getrennte Dinge. Es sei denn, Du ignorierst die Warnung in der Apache-Doku, tunlichst nicht die /etc/passwd für die Anmeldung am Apachen zu benutzen.

Als Lösung wurde mir Suexec vorgeschlagen. So weit ich es aber mittlerweile verstanden habe, setzt dies voraus, dass die aufrufbare Datei Eigentum des Users ist und sich in seinem home-verzeichnis befindet.
Das wäre für mich ziemlich unpraktisch, da das gleiche Skript mehrfach (für jeden User ) erstellt werden muss und vor allem von dem jeweiligen user erstellt sein muss...

suEXEC führt Dateien eines System-Benutzers aus, sofern sie an passender Stelle im Dateibaum liegen und dem System-Benutzer gehören. Apache-User haben damit immer noch nichts zu tun.

Das Script kann allerdings komplett schmerzlos ein Dreizeiler sein, der den gemeinsamen Programmcode aus einem Modul nachlädt. Das Modul selbst ist dazu so installiert, dass Perl es ohne weiteres Theater findet.

  
#!/usr/local/bin/perl -T  
use Pierce::My::Feet qw(run);  
run();  

Ist es so oder sehe ich da was falsch?

Erklär bitte nochmal, warum Du Dir so umständlich in den Fuß schießen willst, oder verlinke auf die alte Erklärung.

Alexander

[ich++]

moin Alexander

Du hattest mir damals schon geduldig geantwortet ;)

Such doch bitte mal den Thread-Link aus dem Archiv, damit wir nicht wieder von vorne anfangen müssen.

Hier der Link
http://forum.de.selfhtml.org/archiv/2011/7/t206040/

Ich habe ein per-script, was eine html-Seite generiert.

Warum gibt es nicht einfach HTML aus? HTML-Resourcen müssen nicht zwingend HTML-Dateien sein.

Weil Inhalte von Dateien ausgelesen werden.
Du hast natürlich Recht. Man muss das Rad nicht immer wieder neu erfinden..
werds angehen

Nachdem sich der user online anmeldet erscheint diese Seite und er kann mithilfe des Skripts einige Dateien in seinem Home-verzeichnis modifizieren (lesen, schreiben, erstellen, löschen)

Apache-Benutzer (per .htaccess) und System-Benutzer sind zwei vollkommen getrennte Dinge. Es sei denn, Du ignorierst die Warnung in der Apache-Doku, tunlichst nicht die /etc/passwd für die Anmeldung am Apachen zu benutzen.

Stimmt, das hast du damals auch so gesagt.
Ok, da hab ich mich ein bißchen knapp gefasst. Es werden neue apache-user (mit vershclüsselten passwörter )wie folgt erzeugt:
wobei es so ist, dass jeder system-benutzer, der dieses perl-skript nutzen möchte, sich als einen neuen apache-benutzer anmeldet.
Warum es so ist? weil es mir so vorgegeben worden ist.

Als Lösung wurde mir Suexec vorgeschlagen. So weit ich es aber mittlerweile verstanden habe, setzt dies voraus, dass die aufrufbare Datei Eigentum des Users ist und sich in seinem home-verzeichnis befindet.
Das wäre für mich ziemlich unpraktisch, da das gleiche Skript mehrfach (für jeden User ) erstellt werden muss und vor allem von dem jeweiligen user erstellt sein muss...

suEXEC führt Dateien eines System-Benutzers aus, sofern sie an passender Stelle im Dateibaum liegen und dem System-Benutzer gehören. Apache-User haben damit immer noch nichts zu tun.

Das Script kann allerdings komplett schmerzlos ein Dreizeiler sein, der den gemeinsamen Programmcode aus einem Modul nachlädt. Das Modul selbst ist dazu so installiert, dass Perl es ohne weiteres Theater findet.

#!/usr/local/bin/perl -T
use Pierce::My::Feet qw(run);
run();

>   

Das habe ich noch nicht ganz verstanden..Du meinst das Skript, was sich in dem jeweiligen Homeverzeichnis des users befindet  
  

> > Ist es so oder sehe ich da was falsch?  
>   
> Erklär bitte nochmal, warum Du Dir so umständlich in den Fuß schießen willst, oder verlinke auf die alte Erklärung.  
>   

weil ich ein blutiger Anfänger bin und noch nicht weiss, wie ich folgendes löse:  
System-user sollen online (und nicht über system-anmeldung) gewisse Dateien in ihrem Verzeichnis ändern..  
hier noch der alte thread  
http://forum.de.selfhtml.org/archiv/2011/7/t206040/  

> Alexander

[CPAN]

Alexander (HH) sollte schlau/erfahren genug sein, dir von deinem Ansatz abzuraten und einfach mit der Sprache rauszurücken, wie man's richtig macht. Präzendenz gibt's ja reichlich, und das ist ein immer wiederkehrendes, wohlbekanntes und wohlgelöstes Problem. Leider ist dieses Forum voller Psychopathen, die ihr Vergnügen daraus beziehen, lieber mit den unbedarften Neulingen wie eine Katze mit einem Singvogel ihr grausames Spiel zu treiben.

Es folgt fast das gleiche, was ich schon in </archiv/2010/5/t197977/#m1328649> gesagt habe:
{
Die korrekte Lösung benutzt Entkopplung vom Web, somit wird auch das Thema suexec am Webserver hinfällig. Statt einem Programm, das alles macht, spalte die Funktionalität auf, so dass jede Komponente genau eine Sache macht:

1. Ein Webprogramm, das Anfragen zur Änderung einer Datei zu einem gewissen Nutzer entgegennimmt und in eine Warteschlange einreiht.
2. Die Jobwarteschlange. Dies kann auch einfacherweise eine dumme Datei sein, wenn du korrektes Locking beherrschst.
3. Ein Systemprogramm, das aus der Warteschlange liest und die Änderung einer Datei ausführt. Dieses kann dann mit normalen Root-Rechten laufen, wahlweise als Daemon oder regelmäßig (Cron), und entsprechend der Aufgabe je nach Geschmack den Benutzer wechseln, sein Werk tun und beenden, oder als Root hantieren und hinterher evtl. Besitzerschaft/Dateirechte anpassen.

Garniere mit Fehlerbehandlung und Logging. Es gibt für alles Module.
}
In Zunkunft findest du gute und kompetente Hilfe unter den bei </archiv/2011/4/t204504/#m1385877> angegebenen Links.

[ich++]

Präzendenz gibt's ja reichlich, und das ist ein immer wiederkehrendes, wohlbekanntes und wohlgelöstes Problem.

Das baut mich schon mal auf :)

Die korrekte Lösung benutzt Entkopplung vom Web, somit wird auch das Thema suexec am Webserver hinfällig.

Baut mich noch mehr auf, obwohl ich zuviel zeit mit suexec verschwendet habe und es mich ein bißchen ärgert, dass mir damals suexec geraten worden ist...

3. Ein Systemprogramm, das aus der Warteschlange liest und die Änderung einer Datei ausführt. Dieses kann dann mit normalen Root-Rechten laufen, .., sein Werk tun und beenden, oder als Root hantieren und hinterher evtl. Besitzerschaft/Dateirechte anpassen.

Garniere mit Fehlerbehandlung und Logging. Es gibt für alles Module.
}

Man muss eben nur wissen wie man sucht ;)

Danke für alle Tipps. werds angehen

[ich++]

3. Ein Systemprogramm, das aus der Warteschlange liest und die Änderung einer Datei ausführt. Dieses kann dann mit normalen Root-Rechten laufen, wahlweise als Daemon oder regelmäßig (Cron), und entsprechend der Aufgabe je nach Geschmack den Benutzer wechseln, sein Werk tun und beenden, oder als Root hantieren und hinterher evtl. Besitzerschaft/Dateirechte anpassen.

Garniere mit Fehlerbehandlung und Logging. Es gibt für alles Module.

Ich hab mich für das Modul SetUser entschieden (http://search.cpan.org/~dmartin/Unix-SavedIDs-0.4.1/lib/Unix/SetUser.pm)
Noch eine allgemeine Frage. Wenn es soviele Module zur Auswahl gibt, für welche sollte man sich entscheiden?

In Zunkunft findest du gute und kompetente Hilfe unter den bei </archiv/2011/4/t204504/#m1385877> angegebenen Links.

Ich finde dieses Forum hier viel angenehmer. ich hab leider die Erfahrung gemacht, dass die Atmosphäre in perl-community irgendwie sehr streng und von "oben herab" ist. Die anderen Foren sind englischsprachig und so gut ist mein Englisch leider nicht.
Trotzdem danke für dein Tipp

[ich++]

3. Ein Systemprogramm, das aus der Warteschlange liest und die Änderung einer Datei ausführt. Dieses kann dann mit normalen Root-Rechten laufen, wahlweise als Daemon oder regelmäßig (Cron), und entsprechend der Aufgabe je nach Geschmack den Benutzer wechseln, sein Werk tun und beenden, oder als Root hantieren und hinterher evtl. Besitzerschaft/Dateirechte anpassen.

wollte das Modul setUser installieren -> geht nicht -> will Modul Build haben
hab versucht Modul Build zu installieren -> geht nicht da "not in gzip format"
hab ein anderes Modul ausgewählt Privileges-Drop-1.01 -> Meldung "Null filename used at Makefile.PL line 2" (Zeile 2 besagt require >= 5.8.0 (hab ich eigentlich ) habs auch sein gelassen
hab versucht ein anderes Modul zu installieren: Proc-UID -> Fehlermeldung "not in gzip Format"

ich werd wahnsinnig, qäul mich damit und komme keinen Schritt vorwärts :(

[CPAN]

wollte das Modul setUser installieren -> geht nicht -> will Modul Build haben

$ corelist Module::Build
    Module::Build was first released with perl v5.9.4

Du hast also ein Perl, das so alt ist (von 2006‽), dass es nicht mehr unterstützt wird.

ich werd wahnsinnig, qäul mich damit und komme keinen Schritt vorwärts :(

Kein Wunder, dass du frustriert bist. Installiere v5.14.1, perlbrew macht es einfach, und genieße die Möglichkeiten und Vorzüge einer modernen Umgebung.

[ich++]

$ corelist Module::Build
    Module::Build was first released with perl v5.9.4

Du hast also ein Perl, das so alt ist (von 2006‽), dass es nicht mehr unterstützt wird.

Danke für die Info. Wo erfahre ich sowas? Ich habe auch versucht, Abhängigkeiten und Voraussetzungen für die Module herauszufinden. Leider erfoglos..

Kein Wunder, dass du frustriert bist. Installiere v5.14.1, perlbrew macht es einfach, und genieße die Möglichkeiten und Vorzüge einer modernen Umgebung.

Ich hoffe es ;)

[CPAN]

Wo erfahre ich sowas?

perldelta lesen ist Pflicht. Das hatten wir schon mal. Ich rate auch dir, Teil der Community zu werden, so bleibst du auf dem Laufenden. Der nächste Workshop kommt bald. Ich kann dich geografisch nicht einordnen, womöglich bist in der Nähe einer Benutzergruppe.

Abhängigkeiten und Voraussetzungen für die Module herauszufinden.

Steht in der Metadatei, z.B. http://search.cpan.org/dist/Unix-SavedIDs/META.yml. Willst du das etwa wissen, um die Abhängigkeiten manuell zu installieren? Das ist nicht notwendig, es gibt nämlich Werkzeuge wie cpan, cpanplus und cpanminus, die das ganze automatisieren. Probier's mal aus, wenn du dein v5.14.1 fertig hast.

[ich++]

Du hast also ein Perl, das so alt ist (von 2006‽), dass es nicht mehr unterstützt wird.

Es gibt jedoch eine Module, die noch installiert werden können, z.B. File::HomeDir. Darauf bezog sich meine Frage, welche Module welche Perl-Versionen voraussetzen, also genau diesen Satz, den du geschrieben hast:
Module::Build was first released with perl v5.9.4

[CPAN]

Du hast also ein Perl, das so alt ist (von 2006‽), dass es nicht mehr unterstützt wird.
Es gibt jedoch […] Module, die noch installiert werden können

Das habe ich nicht gemeint. Es geht um was anderes. Ich persönlich bin gerne bereit, dir für die jeweils zwei stabilen Serien (also derzeit 5.14 oder 5.12) Hilfe zu leisten, inklusive Installation einer solchen. Ältere ignoriere ich. Dies stimmt grob mit den Grundzügen der oben verlinkten offiziellen Richtlinien überein. Das heißt "unterstützt", verstehst du? Dies ist vollkommen unabhängig von der tatsächlichen Möglichkeit, CPAN-Module auf älteren Versionen von Perl zu installieren, siehe dazu nächsten Absatz.

Darauf bezog sich meine Frage, welche Module welche Perl-Versionen voraussetzen

Das steht auch in der Metadatei, siehe dazu meine Ausführungen im Nachbarposting. Wenn die Angabe zu Perl (Schlüssel namens "perl") fehlt, bedeutet das theoretisch "irgendeine Version von Perl 5". In der Praxis gibt's aber einige harte Grenzen bedingt durch Module, die häufige Abhängigkeiten sind, z.B. Test::More braucht 5.6, Moose braucht 5.8.3. Eine größer werdende Minderheit von Modulen möchte 5.10 wegen der vielen modernen Merkmale, die erst ab dann verfügbar sind.

also genau diesen Satz, den du geschrieben hast:
Module::Build was first released with perl v5.9.4

Das hast du in den falschen Hals gekriegt. Nachdem du impliziert hattest, dass Module::Build fehlt, habe ich versucht, herauszufinden, ab wann es in der Perl-Distribution ("core") verfügbar war. Nun ist mir aber aufgefallen, dass es genauso gut hätte sein können, dass M::B vorhanden war, aber in einer zu alten Version, und dann installiert man das eben vom CPAN nach. Egal. Es ist überhaupt nicht wichtig, sowas vorher wissen zu wollen. Man lässt einfach ein Werkzeug wie cpan die Abhängkeiten auflösen und durchlaufen. Wenn's klappt, gut. Wenn's nicht klappt, weil die Mindestversion von Perl nicht erfüllt ist, installiert man einfach ein neues.

Statt tagelang zu lamentieren und zu wundern, hättest du einfach mal meiner Expertise folgen und 5.14.1 installieren sollen, das dauert weniger als 30 Minuten und ist auf lange Sicht sowieso die bessere Idee.

[ich++]

Hey :)
Danke für die ganzen Infos

Statt tagelang zu lamentieren und zu wundern, hättest du einfach mal meiner Expertise folgen und 5.14.1 installieren sollen, das dauert weniger als 30 Minuten und ist auf lange Sicht sowieso die bessere Idee.

Ich zögere nur deswegen, weil ich Angst habe, die zur Zeit (unter der veraltetenden Version )laufende Module kaputt zu machen, da ich jene nicht selbst installiert habe.
Daher werde ich dein Rat perlbrew lokal in meinem Home-verzeichnis zu installieren, nachgehen.
Verstehe mich nicht falsch, ich hinterfrage lieber vorher alles, als dass ich in diesen weniger als 30 minuten-Update irgendwo hängen bleibe, nicht mehr weiter weiß und vor allem nichts mehr rückgängig machen kann