Zurück zur G4W Startseite
Benutzer:
Passwort:
vergessen?
Wunschname noch frei?  
Unternehmen | Widerrufsrecht | AGB | Datenschutz | Kontakt | Impressum  
Start
Domains
Webhosting
Server
Extras
Rechenzentrum
Auszeichnungen
Reseller werden
Download
Webhosting Blog
HILFE + SUPPORT
Online-Hilfe - Sofort-Hilfe - F.A.Q. - Knowledge-Base - Häufig gestellte Fragen

Wir haben alle Webhosting-Server nun auf PHP5 umgestellt, d.h. PHP5 ist nun standardmäßig aktiviert und muss nicht mehr mittels .htaccess Datei aktiviert werden. Der vorhandene HILFE-Artikel ist somit veraltet.

Es gibt jedoch auch Fälle, bei denen gerade ältere Scripte mit PHP5 nicht mehr korrekt arbeiten. In solchen Fällen kann problemlos wieder PHP4 aktiviert werden. Legen Sie dazu im Verzeichnis html (oder in das Verzeichnis in dem Sie PHP4 benötigen) eine Datei namens .htaccess an, und fügen Sie folgende Zeilen ein:

RemoveType .php
AddHandler x-httpd-php4 .php

Wenn Sie bereits eine .htaccess in dem Verzeichnis haben, fügen Sie diese beiden Zeilen einfach der bestehenden Datei hinzu.

Wir möchten dennoch darauf hinweisen, dass PHP4 sich in der Auslaufphase befindet. Das Projekt wird nicht mehr weiterentwickelt. Eine Anpassung Ihrer Anwendungen an PHP5 ist damit also mehr als erstrebenswert.

Auch einige ältere Joomla-Versionen haben Probleme mit der neuen Umgebung. Ob das der Fall ist, können Sie testen, indem Sie versuchen sich in das Admin-Panel einzuloggen. Klappt das nicht, müssen Sie sich bei uns melden. Das Problem hängt mit den ACL-Tabellen (AccessControlLists) von Joomla zusammen. Die Datenbank muss von uns dann neu importiert werden, und das Problem ist behoben.

Weiterhin wird oft die Frage gestellt, warum einige selbst erstellte PHP-Seiten nicht mehr laufen, die die Variablen aus dem URL referenzieren. Ein Beispiel: Eine Webseite lädt in einem PHP-Skript verschiedene Unterseiten, und holt den Namen der Seite aus der URL-Variable seite:

http://www.domain.de/index.php?seite=impressum

Im Skript selbst wird die Seite via include geladen:

include($seite);

Obiges Beispiel setzt voraus, dass Variablen direkt aus dem URL im Skript erzeugt werden. Das ist aber nur der Fall, wenn register_globals auf On steht, was unsicher ist. Der sauberere Weg ist, die Variable aus $_GET zu holen:

$seite=$_GET['seite'];
include($seite);

Alternativ können Sie im Confixx unter Tools/Einstellungen->httpd-Spezial die Einstellung register_globals auf On stellen. Daraus könnten sich aber Sicherheitsprobleme ergeben! Also Vorsicht!

Sollten Sie Fragen oder Probleme mit der Umstellung haben, zögern Sie bitte nicht, uns per E-Mail oder Telefon zu kontaktieren. Wir stehen Ihnen gern hilfreich zur Seite.


Seit ein paar Tagen kommen keine Emails mehr bei mir an. Was kann ich tun? Wenn man mir eine Email senden will, kommt eine Email zurück mit einem komischen Code


Final-Recipient: rfc822; webxxxp1 @ webboxxxx.server-home.org
Original-Recipient: rfc822;
Action: failed
Status: 5.2.0
Diagnostic-Code: x-unix; can't create user output file

Wo liegt der Fehler?

Die Fehlermeldung “can’t create user output file” kommt immer dann, wenn ein Postfach voll ist. Der Server weist dann die Zustellung neuer Emails zurück.

Abhilfe: Loggen Sie sich auf Ihren Confixx-Serverbereich ein. Unter dem Punkt “Email” kann man nicht nur neue Emailadressen anlegen, sondern auch die Größe der Postfächer verwalten. Klicken Sie dazu auf “Mail-Quota”. Dort sehen Sie, welches Postfach wieviel MB Speicher verbraucht. Sie können für jedes Postfach individuell festlegen, wieviel Speicher dafür vorgesehen ist.

Vergrößern Sie sowohl das Soft-Limit, als auch das Hard-Limit. Das Hard-Limit muss größer als das Soft-Limit sein!


Es gibt mehrere verschiedene Ursachen für diesen “Internal Server Error” und folglich auch verschiedene Lösungsansätze, die einer nach dem anderen durchgearbeitet werden müssen, um den Fehler zu beseitigen.

1. Wenn das Skript sich nicht im Ordner cgi-bin befindet, sollten Sie im Confixx die Option CGI/Perl außerhalb cgi-bin aktivieren. Diesen Punkt finden Sie in der Confixx-Übersicht.

2. Scheidet diese erste Möglichkeit aus, sollten Sie die Rechte des Skriptes überprüfen. Diese sollten sowohl für das Verzeichnis (meistens cgi-bin), als auch für das Skript selbst 755 sein. Es ist darauf zu achten, dass die Datein per FTP-Programm im Binärmodus auf den Server geladen werden.

3. Ist auch das nicht die Ursache, kommt ein Problem mit den Zeilenenden in Frage. Sie müssen wissen, dass Windows anders als Unix Zeilenenden in Textdateien anders abspeichert. Windows verwendet dazu einen CarriageReturn (Wagenrücklauf) und ein NewLine (neue Zeile). Unix lediglich ein NewLine. In der Regel sieht die erste Zeile eines CGI-Skripts in etwa so aus:

#!/usr/bin/perl

Da Windows nun noch den Wagenrücklauf einfügt, “sieht” Unix diesen Pfad nun so:

#!/usr/bin/perl\CR

Diesen Intepreter gibt es jedoch nicht, die Shell gibt “Bad Interpreter” zurück, ohne einen Content-Type zu senden. Der Apache quittiert das dann mit einem “Premature end of script headers”, im Browser sieht man dann die besagte Fehlermeldung. Man kann das in diesem Beispiel verhindern, indem man einen unkritischen Parameter hinter den Interpreterpfad schreibt. Bei Perl ist das bspw. -X, um die Warnungen abzuschalten. Die erste Zeile sollte also folgendermaßen aussehen:

#!/usr/bin/perl -X


Die Vertragslaufzeit beträgt grundsätzlich 12 Monate. Auch bei allen anderen Anbietern. Wenn andere Anbieter eine kürzere Vertragslaufzeit anbieten, dann müssen sie die Kosten zwischen der Kündigung und dem Vertragsende selbst tragen und diese Kosten auf die anderen Produkte umlegen. Mit anderen Worten heißt das: Die Produkte werden teurer für Sie! Vergleichen Sie das mal!

Hinzu kommt, dass es sich in den meisten Fällen (beispielsweise Domains) gar nicht lohnt, monatliche Zahlungsweise einzuführen, weil die Beträge zu klein sind und mehr Kosten verursachen.

Bei Produkten mit höheren monatlichen Gebühren, wie beispielsweise bei unseren Servern, bieten wir die monatliche Zahlungsweise als Option an, welche Sie bei Bedarf einfach hinzubuchen können. Die Vertragslaufzeit bleibt jedoch unberührt.


Die Lösung ist einfach:
Es gibt auf Ihrem Webspace mehrere Ordner, die hauptsächlich vom System selber verwaltet bzw. benutzt werden. (z.B. .configs, atd, backup, log, phptmp, restore) Dateien im Ordner “files” können nur per FTP, nicht aber per http erreicht werden. Der Ordner, der für einen Kunden am interessantesten ist, ist der “html“-Ordner.

Alles, was im Ordner html liegt, ist von außen erreichbar. Wenn Sie sich das erste mal dort reinschauen, werden Sie eine Datei “index.html” finden. Dies ist die Datei, die Sie als erstes sehen, wenn Sie Ihre Domain aufrufen (“Hier entstehen die Internet-Seiten des Benutzers…”).

Wenn Ihre Dateien unter Ihrer Domain erreichbar sein soll, müssen sie also im Ordner html liegen, wo sich auch bereits ein weiterer Ordner namens “cgi-bin” befindet. Dieser wird u.a. benötigt, wenn Sie Perl-Scripte benutzen, ansonsten kann er ignoriert werden.

Es empfiehlt sich, verschiedene Projekte in Unterordnern des Ordners html zu legen, damit man die Übersichtlichkeit nicht verliert. Besonders dann, wenn Sie einen Webhosting-Account haben, aber mehrere Domains und Webseiten mit dem gleichen Account verwalten.



 

 

 

Hilfe durchsuchen:

Schlagwörter:
Email
Benutzer
Domain
Homepage
Providerwechsel
Programm
Registrieren
Subdomains
Sicherheit
Webspace
Serverstandort
Hosting
Verzeichnis
DNS
Server
Leistung
IDN
Unternehmen | Widerrufsrecht | AGB | Datenschutz | Kontakt | Impressum