nicht angemeldet
document_root unter FoxServ
Hallo,
habe mir eben FoxServ unter WIN NT 4.0 installiert.
Die einzige php.ini liegt im Verzeichnis F:\WINNT, das habe ich mit Dateisuche herausgefunden und die Auskunft erhalte ich auch nach Aufruf von <? phpinfo(); ?>
DOCUMENT_ROOT ist nach der Installation E:/FoxServ/www
Genau das habe ich in der php.ini geändert:
; doc_root = "e:\FoxServ\www"
doc_root = "f:"
Aber trotz Neustart von Apache und vom ganzen NT 4.0 bleibt er dabei:
document_root = "e:\FoxServ\www"
An welcher Schraube muss ich drehen ?
Liebe Grüße aus Worms, Kalle.
-
Hallo,
An welcher Schraube muss ich drehen ?
Aendere den Pfad in der httpd.conf unter DocumentRoot ein (in FoxServ\Apache\conf).
MfG, Thomas
-
hallo Thomas,
An welcher Schraube muss ich drehen ?
Ich habe den Eindruck, daß sich in den letzten Tagen Anfragen zu FoxServ häufen. Dabei gibts dann genau die "Verständigungsprobleme", die wir hier zu lesen bekommen haben. Meines Erachtens ist das, was in der php.ini mit "doc_root" gemeint ist, eben _nicht_ das DocumentRoot des Apache. In den Kommentaren der php.ini steht drin:
"The root of the PHP pages, used only if nonempty." Das heißt eigentlich, es ist sogar besser, in der php.ini gar keinen Wert für "doc_root" erst vorzugeben. Gibt man einen Wert vor, kanns passieren, daß Dateien mit der Extension .php nur dann ausgeführt werden, wenn sie in diesem "doc_root" liegen. Das möchte man aber gar nicht unbedingt.
Was dagegen phpinfo als "DocumentRoot" ausliest, ist eben _nicht_ der Wert, der in der php.ini steht, sondern das, was die httpd.conf des Apache dafür vorsieht.Aendere den Pfad in der httpd.conf unter DocumentRoot ein (in FoxServ\Apache\conf).
Man kann auch die default-Einstellung drin stehen lassen.
BTW: was ist denn ums Himmels willen an FoxServ so interessant? Gibt es irgendeinen Grund, weshalb ich meine Ablehnung von "bundle-Lösungen" revidieren müßte?
Grüße aus Berlin
Christoph S.
-
Hallo,
Ich habe den Eindruck, daß sich in den letzten Tagen Anfragen zu FoxServ häufen. Dabei gibts dann genau die "Verständigungsprobleme", die wir hier zu lesen bekommen haben. Meines Erachtens ist das, was in der php.ini mit "doc_root" gemeint ist, eben _nicht_ das DocumentRoot des Apache.
Das habe ich ja auch nicht behauptet.
Aendere den Pfad in der httpd.conf unter DocumentRoot ein (in FoxServ\Apache\conf).
Man kann auch die default-Einstellung drin stehen lassen.Wenn ein anderer lokaler Pfad gewunscht wird, dann aendert man den an der von mir genannten Stelle, so what?
BTW: was ist denn ums Himmels willen an FoxServ so interessant? Gibt es irgendeinen Grund, weshalb ich meine Ablehnung von "bundle-Lösungen" revidieren müßte?
Ich kann nichts Negatives zu Bundles wie FoxServ, PHPTriad, phpdev, WAMPP usw. berichten. Das prinzipielle Verstaendnis zum Zusammenwirken der Komponenten sollte aber durchaus vorhanden sein.
MfG, Thomas
PS: Man wird ja wohl mal noch helfen duerfen :-(.
-
n'abends,
Meines Erachtens ist das, was in der php.ini mit "doc_root" gemeint ist, eben _nicht_ das DocumentRoot des Apache.
Das habe ich ja auch nicht behauptet.Und ich habs dir auch nicht unterstellt ;-) Aber in der Anfrage von Kalle schien es mir so, daß er diesen Unerschied nicht hinreichend berücksichtigt/bemerkt hat.
Man kann auch die default-Einstellung drin stehen lassen.
Wenn ein anderer lokaler Pfad gewunscht wird, dann aendert man den an der von mir genannten Stelle, so what?Prinzipiell ist - je nach Geschmack - jeder Pfad möglich. Ich persönlich halte nix von "...FoxServ\Apache\conf", weil das "conf"-Verzeichnis ein paar Konfigurationsdateien für den Apache enthält. Die müssen für einen user nicht unbedingt zugänglich sein. default bringt der Apache "...\Apache\htdocs" mit. Kann sein, daß Foxserv das anders einstellt.
Ich kann nichts Negatives zu Bundles wie FoxServ, PHPTriad, phpdev, WAMPP usw. berichten. Das prinzipielle Verstaendnis zum Zusammenwirken der Komponenten sollte aber durchaus vorhanden sein.
Eben, um diese Sache mit dem "Zusammenwirken" gehts mir mit meiner Anmerkung. Außerdem gibts ja noch das, daß die "Komponenten" unterschiedliche Entwicklungszyklen haben. Ein Update von Komponenten ist, so weit ich das beurteilen kann, meist nicht möglich, irgendwas funktioniert dann meist nicht mehr.
PS: Man wird ja wohl mal noch helfen duerfen :-(.
Man "darf" nicht nur, man "soll" ja geradezu. Deswegen dachte ich, daß ein zusätzlicher Hinweis darauf, daß es zwischen "doc_root" in der php.ini und "DocumentRoot" in der httpd.conf Unterschiede gibt, für Kalle vielleicht hilfreich ist ...
Grüße aus Berlin
Christoph S.
-
Hallo,
Prinzipiell ist - je nach Geschmack - jeder Pfad möglich. Ich persönlich halte nix von "...FoxServ\Apache\conf", weil das "conf"-Verzeichnis ein paar Konfigurationsdateien für den Apache enthält. Die müssen für einen user nicht unbedingt zugänglich sein. default bringt der Apache "...\Apache\htdocs" mit. Kann sein, daß Foxserv das anders einstellt.
Ja und unter Apache 1.3.x gibt es bis x=27 diesen Pfad \htdocs offenbar nicht _unterhalb des Apache-Verzeichnisses_ (vielleicht macht das der 2.0.x so).
Ich habe aktuell diese Pakete in Benutzung und die Konfigurationsdateien bzw. DocumentRoot-Verzeichnisse wurden so abgelegt:
FoxServ 3.0: ..\FoxServ\Apache\conf
DocumentRoot: ..\FoxServ\www
http://www.foxserv.net/WAMPP 1.3a: ..\wamp13a\apache\conf
DocumentRoot: ..\wamp13a\htdocs
http://www.apachefriends.org/wampp.htmlphpdev423: ..\phpdev\Apache\conf
DocumentRoot: ..\phpdev\www
http://www.firepages.com.au/MfG, Thomas
-
hi Thomas,
default bringt der Apache "...\Apache\htdocs" mit. Kann sein, daß Foxserv das anders einstellt.
Ja und unter Apache 1.3.x gibt es bis x=27 diesen Pfad \htdocs offenbar nicht _unterhalb des Apache-Verzeichnisses_ (vielleicht macht das der 2.0.x so).Da haben wirs doch. Selbstverständlich gibt es dieses Unterverzeichnis für eine Windows-Installation - ich kenne es seit Jahren _ausschließlich_ als default-Einstellung in Apache 1.3.x. Aber eben _nicht_ als Einstellung in einem dieser bundle-Angebote, sondern von den jeweiligen Originalpaketen der Apache Group. Ich habe derzeit zum Vergleich noch einen Apache 1.3.19 unter Win98 laufen, da ist das zum Beispiel so.
Gut, ich persönlich nutze ebenfalls von Anfang an diesen Pfad nicht und stelle ihn mir in der htpd.conf anders ein, aber das ist unwichtig.Ich habe aktuell diese Pakete in Benutzung und die Konfigurationsdateien bzw. DocumentRoot-Verzeichnisse wurden so abgelegt: [...]
Siehst du, _das_ ist eben "bundle-Style", aber es ist nicht mehr "Apache-Style". Die Apache-Dokumentation baut aber konsequent darauf, daß man _ihren_ default-Vorgaben folgt, und das kann dann bei jemand, der das "Zusammenspiel der Komponenten" noch nicht richtig überblickt, zu - berechtigten - Rückfragen führen.
Verstehst du, was ich mit meinen Vorbehalten gegenüber bundle-Lösungen meine? Sie mögen allesamt "funktionieren", und man kann sich dann beruhigt zurücklehnen, weil man ja auf einen Rutsch "alles" bekommen hat. Der Teufel steckt dann, wie immer, im Detail.
Daher plädiere ich dafür, daß ein "Anfänger" sich eben nicht an diese bundles halten, sondern sich die Komponenten einzeln besorgen und installieren sollte. Den Apache, PHP, mySQL und Perl gibt es jeweils auch als einzelnes kostenloses download-Angebot. Man lernt besser, mit diesen Komponenten umzugehen, wenn man sie sich einzeln installiert, dann ist auch leichter zu verstehen, daß es zwischen "doc_root" in php.ini und "DocumentRoot" in httpd.conf Unterschiede gibt.Nur als Beispiel: bei mir gibts D:\Apache, D:\mySQL, D:\Perl und D.\PHP als Progrwmmverzeichnisse. DocumentRoot für den "main"-Server ist aber I:\root, diverse virtuelle Hosts haben andere DocumentRoot-Verzeichnisse. Ich habe dadurch die Möglichkeit, mein PERL nach Bedarf als Perl 5.6 oder Perl 5.8 zu fahren oder bei PHP diverse beta's auszuprobieren, ohne daß ich an den Konfigurationsdateien was ändern muß. Und wenn mir Apache 2.0.x unbedingt ein Verzeichnis D:\Apache2 einrichten möchte, benenne ich es einfach um, fertig (naja, in der registry muß ich eventuell auch was korrigieren).
Was ich sagen will: wenn man die Komponenten einzeln herunterlädt und installiert, hat man meiner bisherigen Erfahrung nach viel mehr Kontrolle darüber und versteht eben ihr Zusammenspiel besser. Bei einem bundle mußt du zwangsläufig für alle Komponenten Pfade nachjustieren, falls plötzlich der Platz auf deiner Platte nicht mehr ausreichen sollte oder du etwas im (lokalen) Netzwerk exportieren möchtest oder dir einfällt, das DocumentRoot eines virtuellen host auf die zweite Platte zu legen.
Wenn du die einzelnen komponenten bereits beherrschst, wird dir eine bundle-Installation auch keine Probleme mehr machen. In der Regel sind diese Pakete ja auch durchaus sorgfältig zusammengestellt und die Motivation derjenigen, die diese Lösungen vertreiben, ist sicher zu überwiegendem Teil absolut userfreundlich und ehrenhaft.
Zuletzt: wo soll man unterschiedliche Auffassungen und/oder Erfahrungen denn diskutieren, wenn nicht hier, im Forum?
Grüße aus Berlin
Christoph S.
-
D.\PHP
Nein! ich werde nicht über einen Tippfehler herziehen und fragen, ob denn jetzt Verzeichnisse unter Windows anders angegeben werden um nachfolgend kurze Dateinamen verwenden zu können. ;)
Siehst du, _das_ ist eben "bundle-Style", aber es ist nicht mehr "Apache-Style". Die Apache-Dokumentation baut aber konsequent darauf, daß man _ihren_ default-Vorgaben folgt, und das kann dann bei jemand, der das "Zusammenspiel der Komponenten" noch nicht richtig überblickt, zu - berechtigten - Rückfragen führen.
Damit hast Du (Christian) absolut recht. Es ist für die Nachgeborenen zwar sehr einfach das Bundle zu installieren (Solange Sie nicht bei der Installation einen abweichenden Pfad angeben statt den vorgeschlagenen zu benutzen), aber häufig haben die dann schon Probleme, wenn das Web auf einmal in c:\Foxserv2\www statt c:\Foxserv\www liegt. Noch schwieriger wird es, wenn dann Updates fällig sind oder wenn weitere Komponenten installiert werden sollen.
Der Teufel steckt dann, wie immer, im Detail.
Oh ja. Und dann kommt ein "never change a running system" trotz Sicherheitsloch...
Daher plädiere ich dafür, daß ein "Anfänger" sich eben nicht an diese bundles halten, sondern sich die Komponenten einzeln besorgen und installieren sollte.
Ich plädiere mit. Aber: Warum nur die?
Zuletzt: wo soll man unterschiedliche Auffassungen und/oder Erfahrungen denn diskutieren, wenn nicht hier, im Forum?
Eben!
fastix
-
Hallo,
Daher plädiere ich dafür, daß ein "Anfänger" sich eben nicht an diese bundles halten, sondern sich die Komponenten einzeln besorgen und installieren sollte. Den Apache, PHP, mySQL und Perl gibt es jeweils auch als einzelnes kostenloses download-Angebot. Man lernt besser, mit diesen Komponenten umzugehen, wenn man sie sich einzeln installiert, dann ist auch leichter zu verstehen, daß es zwischen "doc_root" in php.ini und "DocumentRoot" in httpd.conf Unterschiede gibt.
Das mag sein, aber ich habe andere Erfahrungen gemacht. Als ich vor drei Jahren mit PHP und MySQL anfing, war ich erstmal froh, dass das damals verfuegbare PHPTriad so schnell installiert war. Nachdem alles lief, habe ich mich dann mit php.ini, httpd.conf usw. vertraut gemacht.
Insofern habe ich keine Probleme, Anfaengern diese Pakete zu empfehlen und damit weiter zu lernen. So easy wie Du es beschreibst, ist die Installation der Einzelkomponenten nach meinen Erfahrungen nicht immer.
Die WAMPP-Entwickler halten sich AFAIK ziemlich genau an das Apache-Original, sind mit aktuellen Versionen dabei und liefern auch eine gut verstaendliche Anleitung mit.
MfG, Thomas
-
Hi Christoph,
Daher plädiere ich dafür, daß ein "Anfänger" sich eben nicht an diese bundles halten, sondern sich die Komponenten einzeln besorgen und installieren sollte. Den Apache, PHP, mySQL und Perl gibt es jeweils auch als einzelnes kostenloses download-Angebot. Man lernt besser, mit diesen Komponenten umzugehen, wenn man sie sich einzeln installiert, dann ist auch leichter zu verstehen, daß es zwischen "doc_root" in php.ini und "DocumentRoot" in httpd.conf Unterschiede gibt.
full Ack.
Mein Haupt-Argument gegen Bundles ist, daß die Installation der einzelnen Teile dem Anwender m. E. bewußter macht, wie sie zusammen spielen, damit bestimmte Fragen, die gerade in diesem Bereich aus mangelndem Verständnis resultieren ("Wie muß ich meinen Apache konfigurieren, damit er mit mySQL zusammen arbeiten kann?" - Antwort: Gar nicht, den Apache interessiert mySQL nicht - es sind die CGI- bzw. PHP-Skripte, die mit der Datenbank kommunizieren, nicht der Webserver selbst ... es sei denn, man hat exotische Fremdmodule installiert, welche mySQL z. B. zur Authentifizierung nutzen usw.) gar nicht erst gestellt werden.
Im Bereich von Webserver, Datenbank, Sprach-Interpreter etc. ist für das Zusammenspiel immer eigene Intelligenz (d. h. eigene Programmierung, sei es über CGI oder DBI oder was auch immer) erforderlich. Ein Bundle ist nach meinem Empfinden der Versuch, dem Anwender dies zu verbergen und ihm im besten M$-Stil eine "Fertiglösung" vorzugaukeln - das halte ich für kontraproduktiv, wenn es ums Verstehen geht.
Ich habe gegen solche Pakete dieselben Vorbehalte wie gegen Frontpage oder Dreamweaver.In dieser Hinsicht finde ich auch die Einbettung der entsprechenden Interpreters (egal ob Perl oder PHP) in den Webserver selbst für das _Verständnis_ nachteilig (Performance-Aspekte sind für die typischen Fragesteller hier im Forum ja meistens irrelevant).
Die CGI-Schnittstelle mit dem Informationstransport via Environment-Variablen bzw. stdin ist "greifbar" - ihre Einschalung hinter Sprachelementen macht das Verständnis, was da warum wie zusammenspielt, schwerer (wenngleich die Schreibarbeit beim Codieren teilweise geringer und die Code-Zuverlässigkeit in Bereichen wie "use CGI;" natürlich höher).Das klingt jetzt vielleicht so, als würde ich "den Fortschritt" generell ablehnen. Das tue ich natürlich nicht. Aber je mehr sich solche "Schein-Lösungen" verbreiten, um so mehr Fragen wird es hier und in anderen Foren geben, bei denen die Fragesteller aus allen Wolken fallen, weil sie jetzt plötzlich doch verstehen müssen, wie das funktioniert ("das will ich aber gar nicht, ich will blos, das die standart installation funzt").
Und mir ist bewußt, daß es ihnen weh tun wird, wenn ich sie _dann_ an die Hotline des Herstellers ihres "Produkts" verweisen muß, weil ich keine Lust habe, neben dem Apache auch noch 20 mehr oder weniger vermurkste Bundles (inklusive derjenigen der Linux-Packager) zu verstehen (davon kriege ich auf der mod_gzip-Mailingliste schon genug zu sehen).
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
-
-
Hallo,
Hallo!
Ja und unter Apache 1.3.x gibt es bis x=27 diesen Pfad \htdocs offenbar nicht _unterhalb des Apache-Verzeichnisses_ (vielleicht macht das der 2.0.x so).
Oh doch. Zumindest beim Original. Ich habe hier auf einem Rechner lokal einen sehr alten 1.3.20 laufen... der hat ein htdocs- Verzeichnis mit eingerichtet.
Übrigens: Asche auf mein Haupt!
Ich gebe zu, daß, wenn ich meine beliebten HTML-Seminare halte, ich dann den Foxserv durchaus benutze. Er ist eben in 5 Minuten installiert und ich kann nebenher noch meinen Kaffee trinken, bevor es los geht.
fastix
-
-
n'abends,
Hallo!
Man kann auch die default-Einstellung drin stehen lassen.
Wenn ein anderer lokaler Pfad gewunscht wird, dann aendert man den an der von mir genannten Stelle, so what?
Prinzipiell ist - je nach Geschmack - jeder Pfad möglich. Ich persönlich halte nix von "...FoxServ\Apache\conf", weil das "conf"-Verzeichnis ein paar Konfigurationsdateien für den Apache enthält. Die müssen für einen user nicht unbedingt zugänglich sein. default bringt der Apache "...\Apache\htdocs" mit. Kann sein, daß Foxserv das anders einstellt.Jungs! Ihr redet aneinander vorbei.
Thomas meinte wohl eher Kalle solle den Pfad in der Datei httpd.conf im Verzeichniss E:\FoxServ\Apache\conf auf E:/FoxServ/Apache/htdocs (DocumentRoot) beziehungsweise E:/FoxServ/Apache\ (ServerRoot) ändern, weil das Installationsprogramm dies nicht vornimmt. Nicht die Rede war davon E:\FoxServ\Apache\conf als DocumentRoot zu verwenden.
Kalle:
Es gibt noch mehr Probleme.
Neben der von Dir bereits gesehenen php.ini musst Du wohl auch die my.ini für mysql anpassen, so Du dieses auch mit Foxserv installiert hast.Ferner habe ich irgendwo gelesen, die mit foxserv gelieferte httpd.conf hätte ein kleines Problem (irgendwo "" statt "/")
... Immer diese Hitze bei Gefechten ...
fastix
-
-
-
-
-
Guten Morgen,
danke für die reichhaltige Diskussion auf meine Frage.
Habe das Bundle FoxServ genommen, um in einem Datenbank-Projekt Intranet-Technik auf einen Laptop zu bringen. Die alternative Lösung wäre MS ACCESS gewesen.
Nun hofft man als Programmierer auf funktionierende, verständliche Systeme. OK, es mag die "Reine Lehre" sein, jedes Bit persönlich zu kennen. Aber im Alltag, wenn Termine stehen, kannst du eben NICHT für jede Frage den Baukasten rausholen und alles nach IKEA-Manier selbst zusammenschrauben.
Übrigens, wenn ich die httpd.conf ändere in
DocumentRoot "e:\FoxServ\www"
DocumentRoot "f:"
mag Apache gar nicht erst starten. Mag er die andere Platte nicht ? Vielleicht war die Entscheidung gegen MS ACCESS doch nicht so clever. Denn was ist, wenn der Kunde später Probleme hat und ich kann blind am Telefon nicht so recht helfen ?
Ja, so ist die Welt. Wir können bekannte Probleme immer nur durch unbekannte Probleme ersetzen.
Lieben Gruß aus Worms, Kalle.
-
Guten Morgen,
tpd.conf ändere in
DocumentRoot "e:\FoxServ\www"
DocumentRoot "f:"
mag Apache gar nicht erst starten.
Schon wieder dieses Paket :)
#############Mach Das so: ##################DocumentRoot "f:/"
############Kein Backslash!#################
Am besten, Du besorgst Dir mal die deutsche httpd.conf:
http://selfaktuell.teamone.de/artikel/server/apacheconf/
Die ist übrigens von Christoph Schnauß...
-
hallo fastix,
#############Mach Das so: ##################
DocumentRoot "f:/"############Kein Backslash!#################
In den Kommentaren der httpd.conf steht dazu:
NOTE: Where filenames are specified, you must use forward slashes
instead of backslashes (e.g., "c:/apache" instead of "c:\apache").
was wir bisher im Verlauf des Threads nicht angesprochen hatten.
Am besten, Du besorgst Dir mal die deutsche httpd.conf:
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/
Die ist übrigens von Christoph Schnauß...
...und sollte längst upgedatet sein. Die Übersetzung selbst ist nach wie vor korrekt, aber das "Drumherum" bedarf einer Modernisierung. Ich komme bloß ewig nicht dazu
Grüße aus Berlin
Christoph S.
-
-
Hi Kalle,
Nun hofft man als Programmierer auf funktionierende, verständliche Systeme. OK, es mag die "Reine Lehre" sein, jedes Bit persönlich zu kennen. Aber im Alltag, wenn Termine stehen, kannst du eben NICHT für jede Frage den Baukasten rausholen und alles nach IKEA-Manier selbst zusammenschrauben.
doch - gerade als Programmierer bist Du der einzige, der dazu möglicherweise überhaupt noch die Möglichkeit hat, die eigene Technik zu beherrschen.
Nicht aber als "Engineer" oder "Operator" oder ... die haben nur noch die Hotline (sei es beim Hersteller oder beim Programmierer der mit diesen Werkzeugen gebauten eigenen Anwendung).Und das gilt auch im Alltag. Es gilt immer dann, wenn Du diese Werkzeuge wirklich als Werkzeuge einsetzen willst - und das länger als drei Wochen. Dann nämlich lohnt sich die Investition für jedes Folgeprojekt.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now. -
hallo Kalle,
danke für die reichhaltige Diskussion auf meine Frage.
Bittesehr. Übrigens: schön, daß du dich meldest. Manchmal wissen wir bei solchen Threads nicht, ob denn die Debatte dem ursprünglichen Fragesteller auch was bringt. Aber ich kann dir versichern: auch wenn es so scheint, als ob wir dein posting bloß zum Anlaß genommen hätten, untereinander zu diskutieren, hat doch keiner dabei übersehen, daß du den Thread gestartet hast.
Habe das Bundle FoxServ genommen, um in einem Datenbank-Projekt Intranet-Technik auf einen Laptop zu bringen. Die alternative Lösung wäre MS ACCESS gewesen.
Was ist an MS ACCESS so "alternativ"? Ich weiß (genausogut wie die anderen an diesem Thread bisher Beteiligten), daß Microsoft das als nahezu grundsätzliche "Datenbanklösung" ansieht, und daß es auch im Web transportierbar/nutzbar ist. Traffic (Netzlast), Fehleranfälligkeit und Benutzerführung stehen aber in keinem Verhältnis zu den "echten" Web-Lösungen.
Nun hofft man als Programmierer auf funktionierende, verständliche Systeme.
_Das_ hofft man als Programmierer grade eben nicht. Als Programmierer _weiß_ man, daß alle Systeme ihre Schwachpunkte haben. Als Programmierer ist man ja geradezu angetreten, um die _eigene_ einigermaßen funktionierende Lösung zusammenzustellen. Mag ein Peogramm nicht so, wie ich will, schreibe ich es mir eben neu ...
Aber im Alltag, wenn Termine stehen, kannst du eben NICHT für jede Frage den Baukasten rausholen und alles nach IKEA-Manier selbst zusammenschrauben.
Doch, gerade im Alltag _mußt_ du das sogar. Siehe die schöne Antwort von Michael. Und wenn dein Chef nicht versteht, weshalb er dich eben als Programmierer eingestellt hat, dann kündige.
Übrigens, wenn ich die httpd.conf ändere in
DocumentRoot "e:\FoxServ\www"
DocumentRoot "f:"
mag Apache gar nicht erst starten.Wenn dein Apache "nicht mag", starte ihn einfach mal vom DOS-Prompt aus, da siehst du dann eine Fehlermeldung, warum er nicht starten möchte. Mit diesen Fehlermeldungen hast du Orientierungsmöglichkeiten, was du korrigieren müßtest.
Mag er die andere Platte nicht ?
Doch, die "mag" er durchaus. Voraussetzung ist allerdings, daß diese Platte in der httpd.conf in einem <Directory>-Container angegeben wurde, ungefähr so:
<Directory "F:">
Options Indexes FollowSymLinks MultiViews ExecCGI
AddOutputFilter Includes html
AllowOverride None
Order allow,deny
Allow from all
</Directory>Dafür kannst du auch noch einen Alias-Namen vergeben, und dann bekommst du sie mit http://ServerName/AliasName auch angezeigt.
Andererseits: du kannst dem Thread entnehmen, daß es unerwartete Probleme geben kann, wenn du eine einzelne Komponente aus deiner FoxServ-Installation anzupassen versuchst - wenn du also deine httpd.conf manipulierst, und plötzlich die php.ini und die my.ini nicht mehr dazu kompatible Einträge aufweisen. Diese Probleme hast du nicht mehr, wenn du die Einzelteile eben auch separat installierst und wartest.
Ich habe dir zum Vergleich mal meine aktuelle (private) httpd.conf hochgeladen, nachzulesen unter http://home.arcor.de/schnauss/temp/httpd.conf. Die funktioniert prima, ist aber auch nicht ganz "sauber" - ich könnte sie noch optimieren, aber das ist nun meine eigene Spielwiese.
Vielleicht war die Entscheidung gegen MS ACCESS doch nicht so clever.
Ich glaube, du mußt das anders sehen. Du hast dich nicht "gegen" irgendwas, sondern "für" die eigentlich richtige Lösung entschieden, bloß beherrschst du sie noch nicht vollständig.
Denn was ist, wenn der Kunde später Probleme hat und ich kann blind am Telefon nicht so recht helfen ?
Dafür gibts doch "remote access"-Möglichkeiten. Eine sehr schöne Software dafür kannst du dir unter http://www.ntutility.com/rtm/ herunterladen.
Grüße aus Berlin
Christoph S.
-