RootForum Community

Hallo!

Ich hab einen SuSE 8.2 Server und hab folgendes Problem:

CGI will nicht laufen. Confixx ist auch installiert.

In der SuExec steh folgendes drinnen:

[2003-10-26 02:28:24]: error: command not in docroot (/home/www/web1/html/cgi-bin/test.pl)

Was kann das sein?

Kann mir wer helfen?

mach doch mal ein

suexec -v und post was kommt

besser suexec -V

und lass mich raten da wird statt: (richtig)

folgendes stehen: (falsch)

Da hilft Quick'n'Dirty:

Aktuelles Apache Source Paket laden und installieren (aktuell: ftp://ftp.rediris.es/sites/ftp.gwdg.de/ ... -0.src.rpm ) , im /usr/src/packages/SPECS/apache.spec bzw. /usr/src/packages/SPECS/apache2.spec file die SuExec ./configure Optionen entsprechend anpassen (müsste ca. Zeile 350 sein): (Leerzeichen nach dem gehört da nicht hin, phpbb-Fehler)
dann rpm -ba apache.spec bzw. rpm -ba apache2.spec, warten, gebautes Paket installieren, fertig.

Edit: Bei neueren SuSE-Version rpmbuild -ba

Hallo!

Danke für das Tut :D

ich hab die oben genannten Schritte durchgeführt , bzw. die Ã?nderungen in der apache.spec gemacht

wenn ich nun "rpm -ba apache.spec" mache , dann kommt diese Meldung:

Unable to open icon /usr/src/packages/SOURCES/mod_ssl.xpm: No such file or directory

Was will mir der Autor damit sagen ??


Für Hilfe wäre ich sehr dankbar


Gruss
Zak

Meine Güte, man kann doch nicht pauschal einfach "richtige" und "falsche" Pfade angeben? Das ist abhängig von der Konfiguration!

gibt es nun ne Lösung oder nich ??

Meckern hilft ja keinem weiter , mir schon gar net :?


Ich kann auch als Quick & Dirty die User / Group Einträge aus den Virtuellen Hosts rausnehmen , dann läuft es , aber das ist wohl mehr als nur ne Krücke ..

die einstellung ist abhängig vom provider... leider konfigurieren die teilweise anders. bei mir wäre zum beispiel /srv/www/ richtig!

das suexec-problem ist aber schon naheliegend, da hat oxygen recht.
hast du vielleicht nach einem tutorial hier ein "update" des apachen durchgeführt? teilweise sind da rpms angegeben, die auf die 1&1-konfiguration passen, aber für andere nicht.

ist mir selbst schon passiert :oops:

Obige Verzeichnis sind die 1&1 Standardkonfiguration. Diese wird jedoch von fast allen Anbietern verwendet.

Zak: Welches Source Paket hast du verwendet? Ich hab diese Schritte schon oft und mit verschiedenen Versionen gemacht und hatte nie Probleme.

@zak: wo liegen denn die htdocs? und welcher provider?

@headdown
Document Root ist "/home/www" ansonsten unter dem jeweilgen virtual host z.B jeweils unter /home/www/webx

Das is ne 1&1 Root Server Muehle :lol:


@oxigen
ich hab mir "apache-1.3.27-54.src.rpm" besorgt die Ã?nderungen gemacht
wenn ich dann das rpm erstelle dann läuft auch alles einwandfrei durch unter /usr/src/packages/RPMS/i386 liegen dann auch die erstellten rpm's

wenn ich die nu installieren will kommt (rpm -Uhv)
apache = 1.3.26 is needed by mod_ssl-2.8.10-130

Hab ich da was grundlegend nicht verstanden ?? oder bin ich zu doof ??
ich will doch auf 1.3.27 updaten und nich die alte behalten ?!?



Gruss
Zak

du machst erstmal
rpm -e --no-deps apache apache-devel apache-doc apache-contrib mod_ssl
dann in /usr/src/packages/RPMS/i386 einfach rpm -i * ausführen

wenn ich jetzt den apache starte dann kommt
Invalid command 'php_admin_value', perhaps mis-spelled or defined by a module not included in the server configurat...


HILFE!!!

*** schwitz ***

fehlte nur die php load module direktive , dann ging es wieder ...

Danke nochmal für den o.g. Tipp :-D

Auch bei mir laufen seit dem Yast Update keine CGIs mehr, selbes Problem!

Nur jetzt die Frage:
Welches Source soll ich nutzen wenn ich weiterhin apache per yast apache pachten will?

Wenn ich jetzt die .27 oder gar .29 nehme geht das ja wohl nicht mehr :(

Und wenn ich die .26 vom 1&1 Update Server nehme ist der Yast Securtiy patch wieder weg!

also: Wie / wo gibts eine sichere Apache Version die sich weiter per yast updaten lässt und trotzdem auf dem 1&1 rootie mit confixx (bzw der Verzeichnisstruktur) zusammenarbeitet?

Danke :)

Hier noch die Infos:

in suexec log:

[2004-02-27 21:10:10]: emerg: cannot get docroot information (/srv/www/htdocs)
[2004-02-27 21:10:11]: info: (target/actual) uid: (web3/web3) gid: (ftponly/ftponly) cmd: guestbook.cgi

httpd -V
Server version: Apache/1.3.26 (Linux/SuSE)

Server built: Nov 11 2003 17:08:36
Server's Module Magic Number: 19990320:13
Server compiled with....
-D EAPI
-D EAPI_MM
-D EAPI_MM_CORE_PATH="/var/lib/httpd/mm"
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HTTPD_ROOT="/srv/www"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="/var/run/httpd.pid"
-D DEFAULT_SCOREBOARD="/var/run/httpd.scoreboard"
-D DEFAULT_LOCKFILE="/var/run/httpd.lock"
-D DEFAULT_ERRORLOG="/var/log/httpd/error_log"
-D TYPES_CONFIG_FILE="/etc/httpd/mime.types"
-D SERVER_CONFIG_FILE="/etc/httpd/httpd.conf"
-D ACCESS_CONFIG_FILE="/etc/httpd/access.conf"
-D RESOURCE_CONFIG_FILE="/etc/httpd/srm.conf"

Also: Frage: Wie am einfachsten beheben OHNE damit neue Probleme zu machen (nicht supportete Apache Version)?

Danke danke danke
sag ich schonmal *g*[/quote]

Hallo,

anstatt ihr den Apache etc. neu installiert und die Pakete neu kompiliert setzt doch einfach einen Link und CGI funzt wieder. Er verweisst ja nach dem Update auf /srv/www/htdocs. Aber sein Verzeichnis soll ja eigentlich /home/www sein.

also:
mv /srv/www/htdocs /srv/www/htdocs.alt
ln -sf /home/www /srv/www/htdocs


.....danach funzt auch wieder cgi

Grüsse Macin

Ich wusste das es noch eine andere Lösung geben muß .. auf diese einfache bin ich natürlich nicht gekommen ;)

Funktioniert super, danke!
Und schönes WOchenende!

Hallo Leute,
ich habe ein ähnliches Problem.
Ich habe gestern über yast auf meiner Linix Suse 8.1. Kiste ein php Update installiert und seit dem läuft â??cgi perlâ?? nicht mehr. Es kommt auch â??Fehler 500 Interner Serverfehlerâ??. Weiß da jemand was ich machen kann? Ist recht dringen.
Ich habe schon gehört, das es da ein kleines Tool für gibt, welches man Installieren muss damit der bug behoben wird?

Vielen Dank für eure Hilfe.

Hallo,
ich habe wohl ein ähnliches Problem.

Es trat bei mir auf, als ich über yast â??phpâ?? aktualisiren wollte. Seit dem läuft â??cgp perlâ?? nicht mehr.

Ich habe auch mal â??suexec â??Vâ?? eingetippt.

Er hat bei mir folgendes angezeit:

server2:~ # suexec -V
-D DOC_ROOT="/srv/www/htdocs"
-D GID_MID=96
-D HTTPD_USER="wwwrun"
-D LOG_EXEC="/var/log/httpd/suexec.log"
-D SAFE_PATH="/bin:/usr/bin"
-D UID_MID=96
-D USERDIR_SUFFIX="public_html"

Muss ich bei mir dann auch nur aus

-D DOC_ROOT="/srv/www/htdocs"

-

/home/www /srv/www/htdocs

machen, damit cgi wieder geht?

Wenn ja in welcher Datei?

Also für ganz doofe :roll:

Danke!
[/quote]

Das Problem ist ja dass du den Verweis im Apache nur durch neukompilieren (also aus sources komplett neuinstallieren) lösen kannst!

Die folgende Lösung vom MAC ist eine Befehlslösung die aber gut funktioniert:

Wenn Du als root auf Deiner Kiste bist folgendes eingeben

mv /srv/www/htdocs /srv/www/htdocs.alt dann ENTER drücken
ln -sf /home/www /srv/www/htdocs dann ENTER drücken

dann haste einen Link (sowas wie eine Verknüpfung nur unter Linux) von dem Verzeichnis welches im Apache eingetragen ist auf das richtige Verzeichnis gemacht! Dann sollte alles wieder funktionieren

Der erste Befehl ist übrigens um dein original htdocs Verzeichnis nach htdocs.alt zu sichern ... wenns leer ist brauchste das aber auch nich...

Ahhhh,
vielen Dank für deine Hilfe und ausführliche Beschreibung!

Es geht wieder einwandfrei.

Gut, das es das root Forum und solche freundlichen Leute im Netz gibt.

MfG, Christian

Hi to all,

hatte bis eben auch das problem, nun nicht mehr ;-))

Also wie es aussieht bin ich zu blöde dafür ...


ich wollte diesen weg auch gehen

mv /srv/www/htdocs /srv/www/htdocs.alt dann ENTER drücken
ln -sf /home/www /srv/www/htdocs dann ENTER drücken

ich kann auch die verknüpfung sehen und die htdocs.alt is auch da

aber die pl scripte laufen immer noch nicht ich bekomme immer noch die fehler meldung

(target/actual) uid: (b26020410245160/b26020410245160) gid: (www/www) cmd: env.pl
[2004-03-05 01:01:41]: emerg: cannot get docroot information (/srv/www/htdocs)



dabei habe ich doch das selber hier :

D DOC_ROOT="/srv/www/htdocs"
-D GID_MID=96
-D HTTPD_USER="wwwrun"
-D LOG_EXEC="/var/log/httpd/suexec.log"
-D SAFE_PATH="/bin:/usr/bin"
-D UID_MID=96
-D USERDIR_SUFFIX="public_html

was zum teufel nicht noch mal habe ich den da noch falsch gemacht ist doch idoten sicher ?

Hallo,

ln -sf /home/www /srv/www/htdocs

gilt nur, wenn das tatsächliche DocRoot /home/www ist, Du hast aber ein anderes (http://www.rootforum.org/forum/viewtopic.php?p=166093):

ln -sf /home/k /srv/www/htdosc

Was bedeutet eigentlich das /k, ich hoffe, das gilt für alle User, sonst wird's komplizierter.

Gruß, Wolfgang