Installationsproblem bitte helfen
am 31.07.2006 - 06:52 Uhr in
Hi Leute,
ich habe probiert drupal zu installieren. Dazu bin ich der Installationsanleitung gefolgt.
Also das Datenbankschema eingelesen, die settings.php verändert, das ganze auf meine Server in den "html" ordner geladen (hab meine Site auf dem Server von nem Freund und er meinte alles kommt in den "html" odner)und hab die Schreibrechte für den notwendigen file Ordner vergeben.
Wenn ich jetzt meine Homepag ansurfe, kommt folgende Fehlermeldung:
Warning: main(includes/bootstrap.inc): failed to open stream: No such file or directory in /srv/www/htdocs/web23/html/index.php on line 12
Warning: main(): Failed opening 'includes/bootstrap.inc' for inclusion (include_path='.:/usr/share/php') in /srv/www/htdocs/web23/html/index.php on line 12
Fatal error: Call to undefined function: drupal_page_header() in /srv/www/htdocs/web23/html/index.php on line 13
Was hab ich falsch gemacht?????
Schon mal vielen Dank für eure Antworten
MFG
Stefan
- Anmelden oder Registrieren um Kommentare zu schreiben
Bist Du sicher, daß Du alle
am 31.07.2006 - 08:11 Uhr
Bist Du sicher, daß Du alle Dateien hochgeladen hast?
Manchmal kommt es vor, daß eine FTP-Verbindung unterbrochen wird, bevor alle Dateien oben sind.
vg
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Hi
am 31.07.2006 - 13:18 Uhr
also ich hab nochmal alle Dateien gelöscht und dann mit webftp von confixx hochgeladen. Vorher hab ich das mit WT_FTP95 LE gemacht. Danach hab ich alle Dateien überprüft. ein paar haben gefehlt. Eine .jpg-Datei konnte ich nur mit WT_FTP95 LE hochladen. Doch leider kam dann nach dem aufrufen meiner Homepage der Fehler 500. Wie in einem Forum-Gespräch empfohlen hab ich .htaccess-Datei gelöscht. Jetzt kommt wieder der alte Fehler wie schon in meinem alten Post beschrieben, d.h. das alles hat nix gebracht.
Weiß jemand eine andere Lösung? Ich beschäftige mich erst seit kurzem mit Internet-Sites etc. Villt gibt es irgendwelche Anfängerfehler???
Kann mir vllt jemand das Drupal installieren??? Wenn es dann funktioniert, weiß ich wenigstens, dass es an mir lag.
Freu mich über jegliche Hilfe. Bin seit ein paar Tagen da dran und verzweifle bald.
Grüße
Stefan
Hi
am 31.07.2006 - 13:26 Uhr
also ich hab mir auch das Installation-Video von drupal.org angeschaut. Komischer Weise hat die Person im Video viel weniger Dateien in seinem Ordner, wenn er das ganze hochläd. Zwar hat er Version 4.7 und ich probier gerade 4.6 zu installieren, aber ich habe 4.7 auch mal extrahiert und da hatte ich auch viel mehr Dateien. (Ich will 4.6 installieren, weil ich mich mit der Version auskennen will. Ich habe eine Drupal-Site in auftrag gegen bei der 4.6 benutzt wird und ich will das eben bald selber beherschen)
Grüße
Stef
Ich kann mir den Fehler oben
am 31.07.2006 - 13:45 Uhr
Ich kann mir den Fehler oben immer noch nicht erklären.
Anstelle die komplette .htaccess zu löschen versuche doch mal nur die folgenden Zeilen auszukommentieren:
# Set some options.
Options -Indexes
Options +FollowSymLinks
sollte dann so aussehen:
# Set some options.
# Options -Indexes
# Options +FollowSymLinks
vg
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Hi Sanduhrs
am 31.07.2006 - 13:53 Uhr
ich hab es auskommentiert. Dann kommt leider wieder der Fehler 500 :(
Kannst du mir vllt das ganze mal installieren?
Würde mich sehr freuen.
MfG
Stefan
Installation mit Confixx
am 31.07.2006 - 15:48 Uhr
Servus, Stefan.
Seit Mai bin ich unfreiwilliger Sysop und habe deine Erfahrungen mit Confixx schon hinter mir :)
Also: zuerst musst du im Confixx in der Abteilung "Einstellungen" die httpd Einträge richtig stellen, sonst wird jede Änderung (oder auch nur die Erstellung) der .htaccess zum Serverfehler 500 führen. Wenn du an das Serverlog
locate error.log
kommst, kannst du genau sehen, was das Problem ist. Aber wahrscheinlich schützt dich dein Provider auch vor dieser Information...
Bei mir habe ich in Confixx :: Einstellungen :: httpd folgendes:
<Directory /var/www/##user##/html/>
php_admin_flag safe_mode Off
php_admin_flag allow_url_fopen On
php_admin_value open_basedir /var/www/##user##/html/:/var/www/##user##/phptmp/:/var/www/##user##/files/:/var/www/##user##/atd/:/var/lib/php5/
Options -Indexes +FollowSymLinks
AllowOverride All
</Directory>
Wenn du diesen httpd Eintrag in Confixx nicht selbst bearbeiten kannst, musst du deinen Provider fragen. Wenn der's nicht machen will - hm - den Provider wechseln. Die gesamte Problematik ist als "mod_rewrite" des Apache-Servers gut dokumentiert (Google...), aber Confixx legt einen drauf und verhindert, dass man die Konfigurationsdatei in Apache selbst ändert. Deshalb muss Confixx informiert werden, und in Apache muss rewrite kompiliert sein.
Ich hatte eine 24 stündige Nervenkrise, weil der Provider nicht wahrhaben wollte, dass da ein Problem im Apache ist und erst nachdem ich ihm das baldige Ende des gerade erst geschlossenen Vertrags prognostiziert hatte, wurde der Sysop im Rechenzentrum eingeschaltet, der hat freundlich Apache neu kompiliert und voilá, seither rennt's.
Ich hoffe, das hilft etwas.
Wenn du keinen Provider findest, habe ich auf meinem Super-Duper Server noch ein paar hundert GB frei. Allerdings mache ich kein "mainstream hosting", sondern nur für handverlesene Kunden meiner eigenen Agentur. Wenn es interessiert -> PM...
Hi norfue
am 31.07.2006 - 18:34 Uhr
Also ich habs doch installiert bekommen bzw. Sanuhrs hat es gemacht. Trotzdem danke für deine Hilfe.... :)
fehlerquellenanalyse?
am 03.08.2006 - 18:15 Uhr
Bei mir kommt er gar nicht erst so weit...Direkt nach der Installation sagt mir de browser trotz mehrfacher re-installation immer den selben Fehler, ohne fehler code. Im Confixx sehe ich auch keine Fehler, denn es ist eingestellt wie immer...:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
woran könnte es liegen?
Ich nehme an, das ist der
am 03.08.2006 - 18:22 Uhr
Ich nehme an, das ist der Fehler mit der Nummer 500?!
Versuche in der .htaccess die Zeilen
# Set some options.
Options -Indexes
Options +FollowSymLinks
und
RewriteEngine on
und wenn es ganz hart kommt auch
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
auszukommentieren. Jeweils einfach ein # davor setzen.
vg
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
alles gemacht...
am 03.08.2006 - 19:03 Uhr
war schon in den grundeinstellungen so, wie du es mir vorgegeben hattest...danke...bloß leider immer noch der Selbe Fehler... ich sitze jetzt schon den gaanzen Tag daran und versuche verzweifelnd, dahinterzukommen, was falsch konfiguriert sein mag, aber nach 4 installationen und nachdem ich chmod bei allen files auf 777 gesetzt habe, ist es immer noch nicht anders..
Nein, in der
am 03.08.2006 - 19:24 Uhr
Nein, in der Grundeinstellung sind die oben genannten Zeilen, wie oben angegeben, Du musst sie auskommentieren, das sieht dann so aus:
# Set some options.
# Options -Indexes
# Options +FollowSymLinks
und
# RewriteEngine on
und wenn es ganz hart kommt auch
# php_value magic_quotes_gpc 0
# php_value register_globals 0
# php_value session.auto_start 0
Bitte beachte auch, dass die php_value Angaben mehrfach - 9 mal - vorkommen.
Mach das chmod bitte rückgängig - das stellt ein deutliches Sicherheitsrisiko dar.
vg
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Nicht mit dem Hammer
am 06.08.2006 - 21:16 Uhr
Servus.
Der Vorschlag, die htaccess praktisch abzuschalten, kann nur für Testzwecke gelten. Immerhin ist die Datei dazu da, böse Menschen an ihrem Tun zu hindern. Wie mein System mit Confixx funktioniert, habe ich oben bereits dargelegt. Solange die geposteten Einträge nicht im Confixx im httpd Eintrag stehen, stürzt der Server mit Fehler 500 ab und das war's dann.
Auf meinem Server laufen derzeit acht oder so Websites mit zwei verschiedenen CMSs und seit ich diese Settings drinnen habe, problemlos. Drupal hat auch seine eigenen Einträge brav in die .htaccess geschrieben, also liegt's an der Einstellung von Confixx und nirgendwo sonst.
Da Confixx auch die httpd.conf von Apache kontrolliert, ist auch dort keine der üblichen Lösungen wirksam -- bei jedem Webserver-Neustart wird die originale Datei wieder hergestellt...
Norbert
Re: Nicht mit dem Hammer
am 06.08.2006 - 22:43 Uhr
Der Vorschlag, die htaccess praktisch abzuschalten, kann nur für Testzwecke gelten. Immerhin ist die Datei dazu da, böse Menschen an ihrem Tun zu hindern. Wie mein System mit Confixx funktioniert, habe ich oben bereits dargelegt. Solange die geposteten Einträge nicht im Confixx im httpd Eintrag stehen, stürzt der Server mit Fehler 500 ab und das war's dann.
Die .htaccess ist definitiv nicht dazu da, "böse Menschen an ihrem Tun zu hindern". Die .htaccess dient zur Steuerung des Server-Verhaltens und das auch nur als Ergänzung zur serverweit geltenden httpd.conf oder apache.conf, die vom Serverbetreiber so konfiguriert ist, dass er glaubt sie sei sicher.
In diesem Falle ist es offensichtlich so, dass der Serverbetreiber dem Kunden nicht gestattet
Da man davon ausgehen können sollte, dass die Grundkonfiguration des Servers für die Sicherheit sorgt, dass ein Aussenstehender keine Möglichkeit hat, Unsinn anzustellen, ist es völlig in Ordnung, in der .htaccess innerhalb der vom Serverbetreiber erlaubten Parameter Änderungen vorzunehmen - oder auch nicht.
Zudem stürzt der Server bei einem Error 500 nicht ab, er gibt diese Meldung lediglich aus - ein relevanter Unterschied!
Auf meinem Server laufen derzeit acht oder so Websites mit zwei verschiedenen CMSs und seit ich diese Settings drinnen habe, problemlos. Drupal hat auch seine eigenen Einträge brav in die .htaccess geschrieben, also liegt's an der Einstellung von Confixx und nirgendwo sonst.
Dass es an den Einstellungen liegt, die Confixx vornimmt ist völlig richtig. Leider haben die wenigsten Shared-Hosting-Kunden Zugang zu diesen sensiblen Einstellungen, als dass sie das selbst anpassen könnten - was vom Standpunkt der Sicherheit auch völlig richtig ist.
Da Confixx auch die httpd.conf von Apache kontrolliert, ist auch dort keine der üblichen Lösungen wirksam -- bei jedem Webserver-Neustart wird die originale Datei wieder hergestellt...
Dass Confixx kein sinnvolles System ist, wusste ich vorher.
vg
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Confixx und Apache
am 07.08.2006 - 14:27 Uhr
Servus, Sanduhrs.
Also wenn du meinst, dass .htaccess nicht für die Sicherheit zuständig ist, darf ich anregen, das Handbuch von Apache zu konsultieren. Zugegeben, sie muss nicht, wird aber dazu benutzt, den Zugriff auf die Seite (Password Schutz), Dateien und Ordner zu beschränken, wenn der User keinen Zugriff auf die Konfigurationsdateien (wie bei Shared Serves üblich) hat. Dazu wird eben das Modul rewrite (mod_rewrite) eingebunden und konfiguriert. Die Konfiguration von mod_rewrite kann entweder in den Konfigurationsdateien von Apache oder eben auch in der .htaccess auf Verzeichnis-Niveau stattfinden. Aber das gehört ins Kapitel Serveradministration, da gibt es geeignetere Foren.
Dass User von Shared-Server-Providern "beschützt" werden, ist notwendig -- vor allem das mod_rewrite kann bei fehlerhafter Konfiguration der .htaccess zu netten Endlos-Schleifen führen, die den gesamten Server so auslasten, dass keine Leistung für Web-User übrig bleibt. Und wenn man als Admin dann das auslösende Statement unter hunderten Kunden und Verzeichnissen suchen muss, und bis dahin der Server praktisch down ist, wird's mühsam. Darum drehen die Admins das rewrite gerne ab, dann kann der Kunde keine Umleitungen in htaccess definieren, und fertig.
Allerdings ist es dem Provider recht einfach möglich, die von mir oben geposteten Settings für den User in dessen Confixx-httpd Eintrag zu stellen, wenn er von der Zuverlässigkeit überzeugt werden kann. Wenn der User dann ein rewrite Statement verbockt, wird's halt Zoff geben :)
Tipp dazu:
Die .htaccess als htaccess (ohne Punkt) anlegen und bearbeiten, auf den Server per FTP raufladen, mit Punkt umbenennen, FTP offen lassen, in den Browser wechseln und schauen, ob alles noch läuft. Antwortet der Server plötzlich sehr lahm, zurück in den FTP Client und die htaccess löschen. So kann man Endlosschleifen einigermassen schmerzfrei aus der Welt schaffen...
Deine Meinung zum Absturz bei Fehler 500 ist vielleicht manchmal richtig, bei meiner Konfiguration mit Confixx jedenfalls nicht. Nach jedem 500 gab es im error.log die Absturz- und Wiederanlauf-Einträge. In der Zwischenzeit hingen alle Online-User frei in der Luft und es hagelte Bildschirme voller obskurer Fehlermeldungen, bis der Server wieder angelaufen war -- was glücklicherweise recht rasch geht :)
Und Confixx ist wirklich ein ziemlich übles Ding, selbst wenn man root Zugriff hat :)
Schönen Tag noch,
Norbert
Re: Confixx und Apache
am 07.08.2006 - 15:44 Uhr
Also wenn du meinst, dass .htaccess nicht für die Sicherheit zuständig ist, darf ich anregen, das Handbuch von Apache zu konsultieren. Zugegeben, sie muss nicht, wird aber dazu benutzt, den Zugriff auf die Seite (Password Schutz), Dateien und Ordner zu beschränken, wenn der User keinen Zugriff auf die Konfigurationsdateien (wie bei Shared Serves üblich) hat. Dazu wird eben das Modul rewrite (mod_rewrite) eingebunden und konfiguriert. Die Konfiguration von mod_rewrite kann entweder in den Konfigurationsdateien von Apache oder eben auch in der .htaccess auf Verzeichnis-Niveau stattfinden. Aber das gehört ins Kapitel Serveradministration, da gibt es geeignetere Foren.
Zugriffschutz und Athentifizierung sind ein absolut anderes Thema als Serversicherheit, ich fürchte Du wirfst da was durcheinander.
Dazu vielleicht auch nochmal im Apache-Handbuch nachlesen ;) http://httpd.apache.org/docs/2.0/howto/auth.html
Da wird übrigens nicht einmal am Rande die RewriteEngine erwähnt.
Zum Thema .htaccess, Zugriffsschutz und Sicherheit haben die übrigens ebenfalls was zu sagen:
In general, you should never use .htaccess files unless you don't have access to the main server configuration file. There is, for example, a prevailing misconception that user authentication should always be done in .htaccess files. This is simply not the case. You can put user authentication configurations in the main server configuration, and this is, in fact, the preferred way to do things.
und
The second consideration is one of security. You are permitting users to modify server configuration, which may result in changes over which you have no control. Carefully consider whether you want to give your users this privilege. Note also that giving users less privileges than they need will lead to additional technical support requests. Make sure you clearly tell your users what level of privileges you have given them. Specifying exactly what you have set AllowOverride to, and pointing them to the relevant documentation, will save yourself a lot of confusion later.
quelle: http://httpd.apache.org/docs/2.0/howto/htaccess.html
Ebenso weiss ich nicht was - besonders im konkreten Fall der Drupal .htaccess - die Rewrite-Engine mit Sicherheit zu tun haben soll. Denn diese regelt lediglich das Umschreiben der normalen URL q=node/1 in node/1 um die Lesbarkeit und Suchmaschinenfreundlichkeit zu erhöhen.
Dass User von Shared-Server-Providern "beschützt" werden, ist notwendig -- vor allem das mod_rewrite kann bei fehlerhafter Konfiguration der .htaccess zu netten Endlos-Schleifen führen, die den gesamten Server so auslasten, dass keine Leistung für Web-User übrig bleibt. Und wenn man als Admin dann das auslösende Statement unter hunderten Kunden und Verzeichnissen suchen muss, und bis dahin der Server praktisch down ist, wird's mühsam. Darum drehen die Admins das rewrite gerne ab, dann kann der Kunde keine Umleitungen in htaccess definieren, und fertig.
Aus meiner Sicht wird nicht der Kunde, sondern der Server geschützt. Der Kunde wird eingeschränkt.
Allerdings ist es dem Provider recht einfach möglich, die von mir oben geposteten Settings für den User in dessen Confixx-httpd Eintrag zu stellen, wenn er von der Zuverlässigkeit überzeugt werden kann. Wenn der User dann ein rewrite Statement verbockt, wird's halt Zoff geben :)
dito.
Tipp dazu:
Die .htaccess als htaccess (ohne Punkt) anlegen und bearbeiten, auf den Server per FTP raufladen, mit Punkt umbenennen, FTP offen lassen, in den Browser wechseln und schauen, ob alles noch läuft. Antwortet der Server plötzlich sehr lahm, zurück in den FTP Client und die htaccess löschen. So kann man Endlosschleifen einigermassen schmerzfrei aus der Welt schaffen...
Danke.
Deine Meinung zum Absturz bei Fehler 500 ist vielleicht manchmal richtig, bei meiner Konfiguration mit Confixx jedenfalls nicht. Nach jedem 500 gab es im error.log die Absturz- und Wiederanlauf-Einträge. In der Zwischenzeit hingen alle Online-User frei in der Luft und es hagelte Bildschirme voller obskurer Fehlermeldungen, bis der Server wieder angelaufen war -- was glücklicherweise recht rasch geht :)
Das ist nicht meine Meinung. Die Vorgehensweise von Apache ist
Wenn Dein Server nach dem Ausliefern des Fehlerdokuments abstürzt, solltest Du definitiv die Konfiguration überarbeiten!
Und Confixx ist wirklich ein ziemlich übles Ding, selbst wenn man root Zugriff hat :)
Na, wenigstens da sind wir uns einig ;)
vg
--
sanduhrs · Stefan Auditor · Drupalcenter
http://drupal.org/user/28074 · http://association.drupal.org/user/646
Confixx
am 08.08.2006 - 00:05 Uhr
Ich bin bestimmt kein Unix/Linux Crack, hab aber auch einen Provider der mir Confixx als "admin" Oberfläche bietet, Die nutze ich aber nie, sondern mache alles über die shell. Und damit habe ich noch nie Probleme gehabt. Ich betreibe damit eine Multisite-Installation von Drupal.
Confixx als Oberfläche zum bedienen des Servers ist "ein mehr als übles Ding".
md - drupalcenter
-----------------
www.mdwp.de
vg
md - DrupalCenter.de
mdwp* Drupal Consulting & Services
Re: Confixx
am 08.08.2006 - 08:50 Uhr
Ich bin bestimmt kein Unix/Linux Crack, hab aber auch einen Provider der mir Confixx als "admin" Oberfläche bietet, Die nutze ich aber nie, sondern mache alles über die shell. Und damit habe ich noch nie Probleme gehabt. Ich betreibe damit eine Multisite-Installation von Drupal.
Confixx als Oberfläche zum bedienen des Servers ist "ein mehr als übles Ding".
Ich weiß, wir kommen vom Thema ab...
Confixx ist nicht gut, ich will auch nichts beschönigen aber es ist dennoch eine (von vielen) Möglichkeiten, unerfahrenen Usern ihren Webaccount einzurichten. Mal abgesehen davon, dass nicht jeder Provider seinen Kunden einen Shellzugang gewährt, kommen die meisten User mit einer netten und bunten Oberfläche (auch noch bitte in Deutsch) am Besten zurecht. Ich kann mal auf Anhieb gute 50 Leute mit Namen(!) nennen, die OHNE eine entsprechende GUI verloren sind (sind sie ja teilweise auch schon mit).
Confixx ist nicht DIE Lösung aber dennoch eine Möglichkeit - und wie ich inzwischen weiß, nicht einmal die schlimmste ;)
Gruß, Frank
Hu-hu...
am 08.08.2006 - 14:54 Uhr
Servus, Sanduhrs.
Die Zitate sind mir alle bekannt, steht ja so in den docs :) Trotzdem ist und bleibt die .htaccess ein viel und gern genutztes Tool, um den Zugriff auf Dateien und Ordner vermittels rewrite zu unterbinden. Wenn diese Feststelung ein "durcheinander werfen" darstellt, lebe ich unbeschwert damit weiter -- es ist die Realität, ungeachtet dessen, was im Handbuch steht. Auch Drupal, siehe install.txt 4.7.2f, will eine Änderung der .htaccess, um ein Sicherheitsproblem zu lösen :) Aus diesem Grund sollte man an der htaccess nicht beliebig herumschrauben, denn wie du selber zitierst, hat diese Datei einen nicht unerheblichen Einfluss auf den gesamten Server. Mein Ansatz bei der Diskussion ist und bleibt, dass der User, der über Confixx verwaltet wird, keine andere Möglichkeit zur Konfiguration hat, da ihm http.conf und apache.conf verwehrt bleiben.
Dass ich "beschützt" unter Gänsefüßchen stelle, hat seinen Grund. Trotzdem ist ein Shared Server eben keine beliebige Spielwiese für jeden, der sich im Monat 5 Euro für's Hosting leisten will -- da sind noch hunderte andere "Non-Hackers" am selben Server, und der Admin riskiert nicht freiwillig deren Zorn, nur weil er einem Einzelnen die Türen und Tore weit öffnet.
Und: wenn der Apache-Prozess "abstürzt" (oder neu gestartet wird), ist das für den Kunden schon der ganze Apache. Ich leg's hier nicht auf Haare spalten an, und klar ist es so, wie du es schilderst, aber der Kunde, dessen Website nicht mehr erreichbar ist, erlebt alle Symptome eines "Absturzes". Da sich "mein" System so wohl verhält, habe ich keinen weiteren Handlungsbedarf :)
So, und jetzt weiter mit produktiveren Sachen,
Norbert
Hi, also mit .htaccess
am 15.03.2008 - 11:43 Uhr
Hi,
also mit .htaccess läuft bei mir gar nichts. Immer Serverfehler 500. Folgende Datei war mein letzter Versuch damit:
#
# Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
#
# Order allow,deny
#
# Don't show directory listings for URLs which map to a directory.
#Options -Indexes
# Follow symbolic links in this directory.
#Options +FollowSymLinks
# Customized error messages.
ErrorDocument 404 /index.php
# Set the default handler.
DirectoryIndex index.php
# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.
# PHP 4, Apache 1.
# php_value magic_quotes_gpc 0
# php_value register_globals 0
# php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
# PHP 4, Apache 2.
# php_value magic_quotes_gpc 0
# php_value register_globals 0
# php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
# PHP 5, Apache 1 and 2.
# php_value magic_quotes_gpc 0
# php_value register_globals 0
# php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
# Requires mod_expires to be enabled.
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
# Do not cache dynamically generated pages.
ExpiresByType text/html A1
# Various rewrite rules.
# RewriteEngine on
# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# adapt and uncomment the following:
# RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
# RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment and adapt the following:
# RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
# RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /
# Rewrite URLs of the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
# $Id: .htaccess,v 1.90 2007/10/05 14:43:23 dries Exp $
Habe einen vServer am laufen mit Suse 9 und Confixx. Dort läuft schon länger Typo3 und seit kurzem Joomla 1.5.1 sowie mehrer Foren. Für Typo3 musste ich im httpd schon safe mode auf off stellen sowie symbol links erlauben.
Brauche ich jetzt die .htaccess Datei noch für Drupal?
Bin nur Hobby Admin und eigentlich im Windows daheim.
Gruß