How-To: suexec neu kompilieren

[bszom]

Warum du das machst?

Auf einmal laufen auf deinem Server keine CGI und/oder auch andere Scripts mehr. Im Browser kriegst du "Error 500" Meldungen.
Im Error-Log deines Apache Servers ist was wie "Premature end of script headers: <dein Script> ...
Im suexec.log ist etwas ähnliches wie hier:
[2005-11-23 20:58:36]: uid: (639/web3) gid: (102/102) cmd: enquiry.pl
[2005-11-23 20:58:36]: command not in docroot (/home/htdocs/web3/html/cgi-bin/enquiry.pl)

Der Grund dafür?

1. Du hast YOU (Yast Online Update) benutzt um deinem Server die letzten Updates zu verpassen. Hierbei wurde leider suexec durch eine neue Version ersetzt, welche die falschen Einstellungen hat.

ODER

2. Na ja, irgendwie wirst du's schon verbockt haben oder?

------

So, als allererstes machen wir folgendes, damit wir uns auch sicher sind das das Problem bei suexec liegt:

Code: Select all

/usr/sbin/suexec2 -V

Es kann sein das suexec sich woanders befindet und es kann auch sein das es statt suexec2 einfach suexec heißt. Um suexec zu finden, folgendes:

Code: Select all

locate suexec

Einmal gefunden und "suexec2 -V" ausgeführt kriegst du dies zu sehen:

-D AP_DOC_ROOT="/home/htdocs"
-D AP_GID_MIN=96
-D AP_HTTPD_USER="wwwrun"
-D AP_LOG_EXEC="/var/log/apache2/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=96
-D AP_USERDIR_SUFFIX="public_html"

Stimmt der DOC_ROOT auch wirklich? Liegen in diesem Verzeichness und in dessen Unterverzeichnissen die scripts/html/etc deiner Website?
Stimmt der HTTPD_USER?
Wahrscheinlich nicht, sonst würdest du o.g. Fehler auch nicht haben.

------
SO KOMPILIERST DU SUEXEC NEU
------

1. Feststellen welche Version des Apache Servers du hast

Code: Select all

/usr/sbin/httpd2 -V

httpd kann sich auch woanders befinden und kann auch nur httpd heißen! Um httpd zu finden:

Code: Select all

locate httpd

2. Apache holen

http://httpd.apache.org/download.cgi
Ã?ltere Versionen gibt es hier - http://archive.apache.org/dist/httpd/

Code: Select all

lynx http://httpd.apache.org/download.cgi

ODER

Code: Select all

wget http://direkter.link.zum.tar.gz.download

3. Entpacken

Code: Select all

tar -xvzf httpd-x.x.x.tar.gz

4. Warten und dann...

Code: Select all

cd httpd-x.x.x

Dann...

Code: Select all

vim config.layout

Dies ist wichtig weil man NUR SO den späteren Pfad für die suexec Log festlegen kann. Du wirst später sehen was ich meine. Falls du vi/vim nicht hast, krieg raus was dir für ein Editor zur verfügung steht.
Du musst für diesen Schritt wissen wo normalerweise deine suexec.log ist. Also benutze falls nötig erst "locate suexec". Merke dir den Pfad.
Unter <Layout Apache>:
"logfiledir" in den Pfad deiner suexec.log umändern, z.B:
Statt "${localstatedir}/logs" machst du "/var/log/apache2"
Alles speichern und raus.

5. Configure und make

Code: Select all

./configure

Warten...

Code: Select all

make

AUF KEINEN FALL MAKE INSTALL
Warten...

6. suexec Parameter festlegen

Code: Select all

cd support

Dann...

Code: Select all

vim suexec.h

Folgendes musst du ggf. ändern:
#define AP_HTTPD_USER "www" - Statt "www" deinen httpd-User eintragen. z.B. "wwwrun".
#define AP_UID_MIN 100 - Wenn du nicht weißt was hier hin soll dann lass es so. Das gleiche gilt für:
#define AP_GID_MIN 100

#define AP_LOG_EXEC DEFAULT_EXP_LOGFILEDIR "/suexec_log" /* Need me? */ - Statt "/suexec_log" den Namen deiner suexec Log eintragen. z.B. "/suexec.log"
Wenn du Schritt 4 verpatzt hast dann bringt dir diese Einstellung nichts, da der Pfad dort festgelegt wird. Selbst wenn du hier das DEFAULT_EXP_LOGFILEDIR entfernst, kannst du hier nur den Namen der Log festlegen.

#define AP_DOC_ROOT DEFAULT_EXP_HTDOCSDIR - Statt DEFAULT_EXP_HTDOCSDIR deinen "docroot" hier eintragen. z.B. "/home/htdocs".
Alles speichern und raus.

7. Die letzten schritte

Code: Select all

make suexec

Hat alles geklappt? Super! Wenn nicht, gehe zu Schritt 1.

Code: Select all

chmod 4755 suexec

Kopieren und umbenennen:

Code: Select all

cp suexec /usr/sbin/suexec2

Pfad und name könnten anders sein. Vergewissere dich vorher wo dein suexec liegt und wie es heißt. Am besten vom alten auch ein Backup machen.

Apache neu starten:

Code: Select all

rcapache2 restart

Kann bei dir anders sein.

Hat alles geklappt?

Code: Select all

/usr/sbin/suexec2 -V

Ja? Super!

Wenn nicht versuch's mal mit diesem (ähnlichen) howto:
http://www.serversupportforum.de/forum/ ... ieren.html

[webmassa]

Hallo,
vielen Dank für dieses feine Howto. Grundsätzlich funktioniert diese Anleitung prima. Mein spezifisches Problem:
suexec für die Frontpage Server Extensions neu kompilieren.
SWSoft bietet zwar zwei RPMs an für die Extensions und ein angepasstest suexec, nur entspricht das suexec nicht der aktuell benötigten Version, soll heissen DOC_ROOT passt nicht.
suexec -V bringt nach Installation folgende Ausgabe:

Code: Select all

 -D AP_DOC_ROOT="/srv/www/htdocs"
 -D AP_GID_MIN=96
 -D AP_HTTPD_USER="wwwrun"
 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=96
 -D AP_USERDIR_SUFFIX="public_html"
 -D FPSTUBDIR="/usr/local/frontpage/version5.0/apache-fp/_vti_bin"
 -D CONFIXX_HOME_NAME="confixx"

Korrekt müsste DOC_ROOT aber auf /home/htdocs/ verweisen.
Also nach Anleitung vorgegangen und suexec modifiziert und -V bringt folgendes Ergebnis:

Code: Select all

 -D AP_DOC_ROOT="/home/htdocs"
 -D AP_GID_MIN=96
 -D AP_HTTPD_USER="wwwrun"
 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=96
 -D AP_USERDIR_SUFFIX="public_html"

Damit stimmt zwar DOC_ROOT, aber mir fehlen alle anderen Angaben.
Ich habe vor dem Kompilieren versucht diese Angaben für die suexec einzubauen, aber irgendwie wirds ignoriert.
Mein Confixx arbeitet einwandfrei, legt FP-User an, erstellt Zugangsdaten und so weiter, aber mit FP ist kein Zugriff möglich (Error 500). Habe auch die fpexe bereits mit wrapper auf wwwrun geändert, weil im Log angemeckert wurde, dass root eigentlich wwwrun sein soll, aber das allein war es wohl nicht.
Ein weiteres Indiz, welches ziemlich eindeutig ist:

Code: Select all

Server:/ # /usr/local/frontpage/version5.0/bin/owsadm.exe -o usage

Starting usage, port: 80.

Error: The FrontPage Server Extensions are not installed on '80'.

Im Apache2 ist es aber als Modul grundsätzlich integriert, die so-Datei vorhanden und auch in der conf aufgeführt.
Ich weiß im Moment nicht mehr, wo ich eigentlich noch gucken soll. Habe im Laufe der Zeit schon dreimal Confixx abgedatet und immer wieder die gleichen Probleme gehabt. Bisher halfen die RPMs, aber diesmal scheiterte das.Habe mir seit gestern mindestens 50 threads hier aus dem Forum und auch anderen reingezogen, aber keine Lösuung gefunden.
Der Support von Firma X+X kommt auch irgendwie nicht in die Puschen und redet mit einigen Tagen, bis der Support sich meines Problems annehmen will. Irgendwie ist das nicht so richtig akzeptabel.
Hat hier jemand den Durchblick und kann mir schnell und unkonventionell helfen?
Vielen Dank,
webbie
P.S.: Hoffe der Post ist an dieser Stelle richtig, sonst bitte passend verschieben. Danke.

[bszom]

Gern geschehen.

Damit stimmt zwar DOC_ROOT, aber mir fehlen alle anderen Angaben.

Wenn du dir die "Code" Box über diesem Quote aus deiner Nachricht anschaust, dann siehst du das DOC_ROOT nicht stimmt. Aber ich nehme an du hast dort irgendwas falsches eingefügt.

Mit FSE kenne ich mich leider nicht aus, aber hast du versucht die fehlenden Variablen etwa so in die suexec.h einzubauen: ?

#ifndef CONFIXX_HOME_NAME
#define CONFIXX_HOME_NAME "confixx"
#endif

Ein Versuch ist's wert.
Ansonsten bin ich mir sicher das dir jemand anders weiterhelfen kann.

[webmassa]

Hallo,
danke für den Hinweis. Ja, das war ein Flüchtigkeitsfehler. Schade eigentlich, wär so schön einfach gewesen :-)
In der von Dir beschriebenen Art habe ich versucht das in suexec zu implementieren. Also so:

Code: Select all

#ifndef CONFIXX_HOME_NAME 
#define CONFIXX_HOME_NAME "confixx" 
#endif 

#ifndef FPSTUBDIR
#define FPSTUBDIR "/usr/local/frontpage/version5.0/apache-fp/_vti_bin"
#endif 

Das wird leider ignoriert, keine Ahnung warum. Es kommt auch keine Fehlermeldung. Einfach nichts, als hätte ich nicht hinzugefügt. Ich habe das vor die letzte zeile in die suexec.h eingefügt und diese fehlenden Parameter nach diesem Muster so aufgeführt.
Mir fiel gerade eine andere Sache auf. Im error.log finde ich folgende Meldung:

Code: Select all

[Thu Nov 24 16:30:48 2005] [error] Incorrect permissions on stub "/usr/local/frontpage/version5.0/apache-fp/_vti_bin/fpexe" in FrontPageCheckup().  Until this problem is fixed, the FrontPage security patch is disabled and the FrontPage extensions may not work correctly.
[Thu Nov 24 16:30:48 2005] [notice] Apache/2.0.49 (Linux/SuSE) configured -- resuming normal operations

Jetzt komme ich richtig ins grübeln, denn die Anpassung der Rechte habe ich definitiv vorgenommen. Sollte 755 sein und auch die übergeordnete Verzeichnisstruktur weist da keine Auffälligkeiten auf. Hab nochmal gegoogled und finde überall das, was ich bereits ausgeführt habe und auch nach Ã?berprüfung vorfinde: User wwwrun, Gruppe bin, Rechte 755.
Also irgendwie hat mich mein Rootie nicht mehr richtig lieb.

Edit:

Ok, also letztere Meldung kann ich wieder vergessen. Hatte vergessen

Code: Select all

/usr/local/frontpage/version5.0/set_default_perms.sh

wieder auszuführen, nachdem ich alles nochmal gemacht hatte. Ist ja nicht so, dass ich es nicht schon tausendmal von vorn versucht hätte ;-). Nun ist das Errorlog wiede sauber, aber das Problem besteht nach wie vor. Warum bloß?

Noch ein Edit:

Ich stelle gerade fest, dass sich hier wohl die Katze in den Schwanz beisst. Rufe ich das Script auf, dann gibt es beim Restart des Indianers keinen Eintrag im Fehlerlog, wohl aber im suexec.log:

Code: Select all

user mismatch (root instead of wwwrun)

Wenn ich dann für fpexe den Benutzer doch wieder auf wwwrun ändere, dann steht wieder der Fehler im error.log drin aber suexec ist zufrieden.
Kann das mit meiner inkorrekten suexec zusammenhängen?

[bszom]

Habe gerade etwas gegoogelt und habe folgendes gefunden:

http://faq.swsoft.com/article_44_909_en.html
und
http://faq.swsoft.com/article_44_831_en.html

Die wollen also das der Owner root ist.
Ich nehme an das es an suexec liegt, den die fehlende "FPSTUBDIR" Variable führt bestimmt zum "user mismatch" suexec Fehler.

Jetzt musst du nur noch rauskriegen wie du FPSTUBDIR und CONFIXX_HOME_NAME mit suexec kompiliert kriegst.

[webmassa]

Danke für deine Antwort. Genauso sehe ich es auch. Deshalb meine leider bisher vergeblichen Versuche.
Mich irritiert, dass es einfach nicht implementiert wird, völlig kommentarlos. Ob ich versuchen sollte den Pfad zu FP in config.layout mit zu integrieren? Hab allerdings immo noch keinen Plan, ob das überhaupt Sinn macht.
Gruß
webbie

[wgot]

Hallo,

Code: Select all

vim config.layout

Dies ist wichtig weil man NUR SO den späteren Pfad für die suexec Log festlegen kann.

mit welcher Apacheversion tritt das Problem auf?

Gruß, Wolfgang

[webmassa]

Hallo Wolfgang,

das Problem tritt mit Apache2 V.2.049 auf und zwar in Verbindung mit der aktuellsten Confixxversion. Der Apache ist nicht erneuert, nur Confixx per Update auf die neue Version gebracht. Release ist 3.1.1.


Gruß
webbie

[bszom]

Hallo Wolfgang,

mit welcher Apacheversion tritt das Problem auf?

Welches Problem meinst du jetzt? Falls du das mit dem Logpfad meinst, dieses problem habe ich mit dem letzten Apache release bemerkt, da ich den benutzte um mein suexec neu zu kompilieren.
Anhand meiner Google-Nachforschung glaube ich das es aber schon länger existiert - das Problem des "hardcoded" Pfades wird viel besprochen.

[wgot]

Hallo,

Falls du das mit dem Logpfad meinst, dieses problem habe ich mit dem letzten Apache release bemerkt, da ich den benutzte um mein suexec neu zu kompilieren.

das meinte ich, und was soll das Problem sein wenn man den Logpfad nur in suexec.h ändert? Zeigt dann ./suexec -V nicht den in suexec.h gesetzten Pfad an, oder zeigt es ihn an aber schreibt die suexec.log nicht dorthin?

Gruß, Wolfgang

[webmassa]

Hallo Wolfgang,

schade, ich hatte Dich also missverstanden. Zu Deiner Frage:
Beides. suexec schreibt das Log woandershin und zeigt es auch anders an. In diesem Falle mit Apache 2.052.
So sollte es sein:

Code: Select all

-D AP_LOG_EXEC="/var/log/apache2/suexec.log" 

Ã?ndert man vorher in config.layout nichts, dann siehts so aus:

Code: Select all

-D AP_LOG_EXEC="/usr/local/apache2/suexec.log" 

Das geht natürlich in die Hose, weil der Pfad eigentlich nicht existiert und suexec nur läuft, wenn es seine Logs schreiben kann.

Mein Problem besteht weiterhin. Kann nur hoffen, dass keiner meiner Kunden zurzeit mit FP arbeiten will. Zum Glück habe ich nicht so sehr viele die das tun. FTP-Zugang ist auch keine Alternative, weil die Leute zu träge sind und das nicht raffen ohne dass ich da mindestens 3 Stunden Unterricht pro Kunde erteile. Urgs, das muss ich mir nicht antun. Vor allem weil ich weiß, dass da alle paar Wochen Nachschulungen angesagt sind und einige Kunden auch noch einige hundert Kilometer weg wohnen. Das wöre dann eh auf meine Kosten, versteht sich. Sind leider alles langjährige Kunden die nicht auf FP verzichten wollen/werden und teils überdies wirklich mit den Extensions als Hilfsmittel für die Navigation usw. umgehen.
Gruß
Detlev

[wgot]

Hallo,

Beides. suexec schreibt das Log woandershin und zeigt es auch anders an. In diesem Falle mit Apache 2.052.

dann wird es wohl dorthin schreiben wie es anzeigt. :roll: Ich wollte wissen, ob es genügt die Ausgabe von suexec -V zu prüfen ohne das frisch compilierte suexec tatsächlich im Apachen zu nutzen.

Ich hab vorhin Suexec von Apache 2.0.55 compiliert, Logpfad ausschließlich in suexec.h gesetzt, suexec -V gefragt und den von mir in suexec.h angegebenen Pfad und Dateinamen (den ich für den Test bewußt deutlich anders gewählt habe als üblich) angezeigt bekommen.

So sollte es sein:

Code: Select all

-D AP_LOG_EXEC="/var/log/apache2/suexec.log" 

So braucht's mein Server auch.

In suexec.h

Code: Select all

#ifndef AP_LOG_EXEC
#define AP_LOG_EXEC "/var/log/apache2/suexec.log"
#endif

und ich bekomme das, ohne config.layout zu bearbeiten.

Mein Problem besteht weiterhin. Kann nur hoffen, dass keiner meiner Kunden zurzeit mit FP arbeiten will.

ich arbeite nicht mit FP. Könnte mir allerdings vorstellen, daß das benötigte Suexec nur mit Ã?nderungen am Suexec-Quelltext (und nicht nur an der Konfiguration) erstellt werden kann. In den Releasenotes von Swsoft steht patched, nicht configured.

Gruß, Wolfgang

[bszom]

Hi Wolfgang,

das ist allerdings merkwürdig. Ich habe jedenfalls das suexec aus dem Apache 2.0.55 Package kompiliert.

Na ja, für die bei denen es auch ohne config.layout zu ändern klappt, bin ich glücklich.

Ciao

Edit:

Ohne o.g. zu ändern sieht suexec2 -V statt so

Code: Select all

 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"

etwa so aus:

Code: Select all

-D AP_LOG_EXEC="/blah/blah/blah/blah/var/log/apache2/suexec.log"

Die "blahs" entsprechen dem in config.layout gesetzten default Pfad.

[wgot]

Hallo,

Na ja, für die bei denen es auch ohne config.layout zu ändern klappt, bin ich glücklich.

ich glaube, Du gehörst auch gleich zu den Glücklichen. :roll:

AP_LOG_EXEC="/blah/blah/blah/blah/var/log/apache2/suexec.log"
Die "blahs" entsprechen dem in config.layout gesetzten default Pfad.

Die Originalzeile in suexec.h sieht so aus:

Code: Select all

#define AP_LOG_EXEC DEFAULT_EXP_LOGFILEDIR "/suexec_log" /* Need me? */

Wenn man hier den Pfad mit reinschreiben will muß der DEFAULT_EXP_LOGFILEDIR natürlich raus:

Code: Select all

#define AP_LOG_EXEC  "/var/log/apache2/suexec_log"

Gruß, Wolfgang

[webmassa]

Hallo Wolfgang,

nach der Schilderung von bszom würde ich auch zu Deiner Ansicht tendieren. Ich habe in keinem Falle den Pfad in suexec.h zusätzlich eingetragen oder geändert. Meine Ausgabe ist dennoch abweichend in der oben dargestellten Form.

Ã?ber config.layout ist das änderbar, allerdings wahrscheinlich auch durch eine absolute Angabe in suexec.h, wenn ich DEFAULT_EXP_LOGFILEDIR entfernen würde, was ich allerdings noch nicht versucht hatte.

Das ist auch nicht mein grundsätzliches Problem, (würde mir immerhin das editieren einer zusätzlichen Datei sparen und ich werds beim nächsten Versuch mal so testen) aber ich kriege dennoch die anderen Variablen nicht in suexec eingebaut.
Du hast da nicht eventuell eine Idee?

Gruß
webbie

[bszom]

Also, ganz dumm bin ich auch nicht!

#define AP_LOG_EXEC DEFAULT_EXP_LOGFILEDIR "/suexec_log" /* Need me? */ - Statt "/suexec_log" den Namen deiner suexec Log eintragen. z.B. "/suexec.log"
Wenn du Schritt 4 verpatzt hast dann bringt dir diese Einstellung nichts, da der Pfad dort festgelegt wird. Selbst wenn du hier das DEFAULT_EXP_LOGFILEDIR entfernst, kannst du hier nur den Namen der Log festlegen.

Habe ich ja versucht. Nix da.

[wgot]

Hallo,

Ã?ber config.layout ist das änderbar, allerdings wahrscheinlich auch durch eine absolute Angabe in suexec.h, wenn ich DEFAULT_EXP_LOGFILEDIR entfernen würde

richtig, geht sicher beides.

aber ich kriege dennoch die anderen Variablen nicht in suexec eingebaut.

IMHO brauchst Du ein gepatchtes Suexec, also eines mit modifiziertem Quelltext, wirf Google an und suche danach. Ich würde als erstes das FP-Installationspaket (für Linux-Server) suchen, da könnte es drin sein.

Gruß, Wolfgang

[wgot]

Hallo,

Selbst wenn du hier das DEFAULT_EXP_LOGFILEDIR entfernst, kannst du hier nur den Namen der Log festlegen.

warum bist Du der einzige, bei dem das nicht funktioniert? :roll:

Gruß, Wolfgang

[webmassa]

IMHO brauchst Du ein gepatchtes Suexec, also eines mit modifiziertem Quelltext, wirf Google an und suche danach. Ich würde als erstes das FP-Installationspaket (für Linux-Server) suchen, da könnte es drin sein.

Hallo Wolfgang, das war 'ne sehr interessante Theorie, bin gleich dabei und habe das Paket fp50.linux.tar.gz mal auseinandergepflückt und mir angeschaut, was FP sich da unter suexec.h so wünschenswert vorstellt.
Ich muss allerdings zugeben, dass mir da etwas die Augen rollten. Da steht ja gar nix drin, in der suexec.h von FP...

Code: Select all

#include "unixd.h"

typedef struct {
    ap_unix_identity_t ugid;
    int active;
} suexec_config_t;

..das wars schon. Der geneigte Leser könnte jetzt zu der Vermutung tendieren, dass unixd.h frontpagespezifische Dinge enthält. Mitnichten, denn das wird nicht mitgeliefert, sondern im Original vom Apache übernommen. Pfffft....
Insofern war der Tipp gut, aber nicht der Weisheit letzter Schluss und Google hilft mir nicht wirklich weiter, jede Menge Fragen und viel weniger Antworten. Auch bei der Firma Winzigweich ist (natürlich) nichts zu finden.
Im Paket enthalten ist noch die fpcgid.h, welche sowohl mod_frontpage.h, als auch suexec.h inkludiert, aber daraus irgendwelche Erkenntnisse ableiten zu können, das liegt für mich noch in gaaaanz weiter Ferne. Weitere Verweise gibt es bei dem FP-Paket nicht, soll heissen ich weiß nicht, wie FP sich "Seine" suexec zusammenbaut.
Hülfää und 'nen schönen 1.Advent,
Detlev

[webmassa]

Gepatchter Quelltext... ich habe gerade die suexec.c modifiziert.
Danach eine suexec erstellt. Das Ergebnis:

suexec2 -V

-D AP_DOC_ROOT="/home/htdocs"
-D FPSTUBDIR="/usr/local/frontpage/version5.0/apache-fp/_vti_bin"
-D CONFIXX_HOME_NAME="confixx"
-D AP_GID_MIN=96
-D AP_HTTPD_USER="wwwrun"
-D AP_LOG_EXEC="/var/log/apache2/suexec_log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=96
-D AP_USERDIR_SUFFIX="public_html"

Nun muss es nur noch laufen...


Edit:

Ok, nun habe ich beim Versuch ein web mit FP zu öffnen keinen Error 500 mehr, sondern einen 404. Sieht so aus, als wenn's läuft und ich nur FP erst deaktivieren muss und dann erneut für den Kunden einrichten. 'Er' meckert über _vti-Verzeichnisse die 'ihm' fehlen.
Das stimmt mich aber schonmal erheblich fröhlicher....
Mal gucken und suchen :-)

[bszom]

warum bist Du der einzige, bei dem das nicht funktioniert?

Bin ich nicht! :?

http://www.google.de/search?hl=de&q=sue ... uche&meta=

:-D

[webmassa]

Bin ich nicht!

Vielleicht hängt das auch von anderen Faktoren ab. Betriebssystem, Apache-Version etc., dazu die unterschiedlichen Revisionen. Man soll ja niemals nie sagen.

Ich habe jetzt auf mein Problem bezogen folgendes gemacht:
Mit Confixx FP vom Web entfernt, danach neu eingerichtet.
Confixx macht beides problemlos und berichtet keinen Fehler.

Fehlermeldung beim Versuch mit FP zum Web zu verbinden:
404 Not Found
Not Found The requested URL /_vti_bin/shtml.exe/_vti_rpc was not found on this server.
Additionally, a 406 Not Acceptable error was encountered while trying to use an ErrorDocument
to handle the request. Apache/2.0.49 (Linux/SuSE) Server at web3.xyz.de Port 80

Error-Log des Apache:
[Sat Nov 26 00:21:43 2005] [error] Incorrect permissions on webroot "/home/htdocs/web3/html/_vti_pvt" and webroot's _vti_pvt directory in FrontPageAlias().
[Sat Nov 26 00:21:43 2005] [error] Incorrect permissions on webroot "/home/htdocs/web3/html/_vti_pvt" and webroot's _vti_pvt directory in FrontPageAlias().
[Sat Nov 26 00:21:43 2005] [error] [client 84.245.166.xxx] File does not exist: /home/htdocs/web3/html
[Sat Nov 26 00:21:43 2005] [error] [client 84.245.166.xxx] no acceptable variant: /usr/share/apache2/error/HTTP_NOT_FOUND.html.var
[Sat Nov 26 00:21:43 2005] [error] Incorrect permissions on webroot "/home/htdocs/web3/html/_vti_pvt" and webroot's _vti_pvt directory in FrontPageAlias().
[Sat Nov 26 00:21:43 2005] [error] Incorrect permissions on webroot "/home/htdocs/web3/html/_vti_pvt" and webroot's _vti_pvt directory in FrontPageAlias().
[Sat Nov 26 00:21:43 2005] [error] [client 84.245.166.xxx] File does not exist: /home/htdocs/web3/html
[Sat Nov 26 00:21:43 2005] [error] [client 84.245.166.xxx] no acceptable variant: /usr/share/apache2/error/HTTP_NOT_FOUND.html.var

Access-Log des Webs:
84.245.166.xxx - - [26/Nov/2005:00:21:42 +0100] "OPTIONS / HTTP/1.1" 200 - "-" "Microsoft Data Access Internet Publishing Provider Protocol Discovery"
84.245.166.xxx - - [26/Nov/2005:00:21:43 +0100] "GET /_vti_inf.html HTTP/1.1" 200 1754 "-" "Mozilla/4.0 (compatible; MS FrontPage 6.0)"
84.245.166.xxx - - [26/Nov/2005:00:21:43 +0100] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 - "-" "MSFrontPage/6.0"
84.245.166.xxx - - [26/Nov/2005:00:21:43 +0100] "GET /_vti_inf.html HTTP/1.1" 200 1754 "-" "Mozilla/4.0 (compatible; MS FrontPage 6.0)"
84.245.166.xxx - - [26/Nov/2005:00:21:43 +0100] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 - "-" "MSFrontPage/6.0"
84.245.166.xxx - - [26/Nov/2005:00:21:43 +0100] "OPTIONS / HTTP/1.1" 200 - "-" "Microsoft Data Access Internet Publishing Provider Protocol Discovery"

Suexec-Log:
[2005-11-26 00:22:23]: user mismatch (root instead of wwwrun)

Rechte:
---x-xx-xx-x = 40755 Owner: root Group: bin /usr/local/frontpage/version5.0/_vti_bin/
x--xxxx-xx-x = 104755 Owner: root Group: bin /usr/local/frontpage/version5.0/_vti_bin/fpexe

Im Verzeichnis /usr/local/frontpage/version5.0/apache-fp wurde eine Datei erstellt:
suidkey.11373 mit Binär-, Hex- oder sonstigen Daten und den Rechten ---xx------- 100600 Owner+Group= root

Auf das Web bezogen lauten die Rechte Owner und Groups der einzelnen Dateien und Verzeichnisse wie folgt:
/home/htdocs/web3 ---xxxx-xx-x 40755 root root
/home/htdocs/web3/html ---xxxxxxxxx 40777 web3 www
/home/htdocs/web3/html/_vti_inf.html ---xx-x--x-- 100644 web3 web3
/home/htdocs/web3/html/_vti_bin ---xxxx-xx-x 40755 web web3
/home/htdocs/web3/html/_vti_cnf ---xxxx-xx-x 40755 web3 web3
/home/htdocs/web3/html/_vti_pvt ---xxxx-xx-x 40755 web3 www

Ich sehe zwar die Probleme, aber bin irgendwie völlig von der Rolle.
Ich habe augenblicklich nicht mal im Ansatz eine Idee, was ich jetzt machen soll. Hat jemand noch einen Tipp für mich?

Gruß
Detlev

Edit:

Nachdem ich jetzt nochmal die set_default_perms.sh ausgeführt habe, habe ich das ganze nochmal wiederholt und folgende Abweichungen festgestellt:


Error-Log
[Sat Nov 26 01:30:00 2005] [error] Incorrect permissions on webroot "/home/htdocs/web3/html/_vti_pvt" and webroot's _vti_pvt directory in FrontPageAlias().
[Sat Nov 26 01:30:00 2005] [error] Incorrect permissions on webroot "/home/htdocs/web3/html/_vti_pvt" and webroot's _vti_pvt directory in FrontPageAlias().
[Sat Nov 26 01:30:00 2005] [error] [client 84.245.166.xxx] File does not exist: /home/htdocs/web3/html
[Sat Nov 26 01:30:00 2005] [error] [client 84.245.166.xxx] no acceptable variant: /usr/share/apache2/error/HTTP_NOT_FOUND.html.var
[Sat Nov 26 01:30:01 2005] [error] [client 84.245.166.xxx] no acceptable variant: /usr/share/apache2/error/HTTP_METHOD_NOT_ALLOWED.html.var

Access-Log
84.245.166.xxx - - [26/Nov/2005:01:30:00 +0100] "GET /_vti_inf.html HTTP/1.1" 200 1754 "-" "Mozilla/4.0 (compatible; MS FrontPage 6.0)"
84.245.166.xxx - - [26/Nov/2005:01:30:00 +0100] "POST /_vti_bin/shtml.exe/_vti_rpc HTTP/1.1" 404 - "-" "MSFrontPage/6.0"
84.245.166.xxx - - [26/Nov/2005:01:30:01 +0100] "PROPFIND / HTTP/1.1" 405 - "-" "Mozilla/4.0 (compatible; MS FrontPage 6.0)"

---x-xx-xx-x = 40555 Owner: root Group: bin /usr/local/frontpage/version5.0/apache-fp/_vti_bin/

Und jetzt weiß ich zumindest, was ich machen muss: Ich geh jetzt ins Bett... ;-)

[webmassa]

Es ist zum Haare raufen....

1) ich find keine Lösung
2) es kommt keinerlei Unterstützung durch den Support der Firma XuX
3) hier hat anscheinend auch keiner eine weiterführende Idee

Muss ich wegen der blöden FP Erweiterungen jetzt meinen Rootie komplett neu aufsetzen? Das kann's eigentlich nicht sein, oder?
Gruß
Detlev