Beiträge von Robert

Anscheinend fehlt die Konfigurationsdatei (config.php). Hast du die Installationsanleitung vollständig durchgearbeitet? Dabei müsste die Datei eigentlich erstellt werden.

Der Datenbankteil für Mysql:

Setting up the mysql database can be done by creating an empty database,
importing the table layout and granting the proper permissions to the
roundcube user. Here is an example of that procedure:




# mysql
> CREATE DATABASE roundcubemail /*!40101 CHARACTER SET utf8 COLLATE utf8_general_ci */;
> GRANT ALL PRIVILEGES ON roundcubemail.* TO roundcube@localhost
    IDENTIFIED BY 'password';
> quit




# mysql roundcubemail < SQL/mysql.initial.sql




Note 1: 'password' is the master password for the roundcube user. It is strongly
recommended you replace this with a more secure password. Please keep in
mind: You need to specify this password later in 'config/db.inc.php'.




Note 2: For MySQL version 4.1 and up, it's recommended to create the database for
RoundCube with utf-8 charset.

Dort wird davon ausgegangen, dass man Zugriff per Konsole hat, was ja beim Webspace nicht geht. Ich weiß nicht, ob man beim Webspace neue Benutzer in phpMyAdmin erstellen kann. Wenn ja: neuen Benutzer anlegen und dabei eine Datenbank mit gleichem Namen und allen Rechte anlegen lassen. Ansonsten muss es ja eine Möglichkeit geben, eine Datenbank zu erstellen... das Ergebnis sollte jedenfalls sein, dass du einen Benutzer hast, dessen Passwort du weißt und der alle Rechte auf eine Datenbank hat. Dann gehst du in phpMyAdmin in diese Datenbank, dort auf "Importieren" und wählst die Datei "SQL/mysql.initial.sql" aus.

Ich kenne diese Anwendung nicht. Allerdings finde ich auffällig, dass zwar das html-Verzeichnis im include_path angegeben ist, nicht jedoch "." (also ein Punkt), der für das momentane Verzeichnis steht. Auf meinem Server ist der include_path auf ".:/usr/share/php:/usr/share/pear'" gesetzt, was die Standardkonfiguration sein dürfte. Ich meine, dass PHP die Dateien (z.B. includes/translate.php) relativ zu den dort angegebenen Orten sucht, also in /var/www/webxxx/html/includes/translate.php und entsprechend beim anderen Ort - nicht jedoch im aktuellen Verzeichnis (.../html/webcal). Hier steht's auch nochmal, wo PHP sucht: http://php.net/manual/en/function.include.php. Dem dortigen Beispiel entsprechend würde also auch noch nach .../html/webcal/includes/includes/translate.php gesucht werden, bringt aber auch nichts.

Kurzum: Falls möglich kannst du versuchen, die Anwendung mal direkt ins html-Verzeichnis zu verschieben. Vielleicht gibt es ja auch in der Konfiguration der Anwendung eine Einstellung für den Unterpfad. Ansonsten wird es vermutlich zu beheben sein, indem du den Support bittest, "." dem include_path hinzuzufügen.

Ich würde die Datei einfach umbenennen, dabei möglichst keine Leer- und Sonderzeichen verwenden.

Ich glaub meine Lösung bestand in

aptitude purge klogd sysklogd

Zumindest sind die beiden Pakete bei mir nicht (mehr) installiert. Wenn es eh nicht funktioniert, braucht das auch nicht installiert zu sein.

Ich habe ganz am Anfang noch

deb http://hetzner:download@download.hetzner.de/debian/mirror/ lenny main non-free contrib

Dann können die Pakete auch direkt von Hetzner heruntergeladen werden.

In volatile werden (bisher) nur Daten für einen Virenscanner angeboten, oder?

koweto: SSH, FTP usw. liefen bei mir einwandfrei weiter.

Zitat von killerbees19;3067

Robert: Meinst du beim eAccelerator, wegen verschiedener PHP Versionen oder Linux Versionen? Denn bei mir lief und läuft nach wie vor PHP 5.2.x mit dem eAccelerator. Ich habe nichts neu kompiliert oder installiert seit dem Upgrade und trotzdem läuft alles problemlos

Immer wenn ich PHP update, kommt eine Meldung (die ich allerdings erst sehen konnte, als ich mal "php -v" ausprobiert habe), dass eAccelerator für die alte Version kompiliert wurde und man es neu kompilieren soll. Solange ich das nicht getan habe bzw. eAccelerator deaktiviere, funktioniert PHP nicht. Ist schon eine Weile her, dass ich das installiert habe, aber 0.9.5.3 ist ja immer noch die aktuelle Version und ich habe mir glaube ich damals einfach den Quellcode heruntergeladen, entpackt und kompiliert.

christian:
Ah, wieder was gelernt.

Eigentlich sollte das Skript nicht selbst auf diesen Pfad zugreifen, sondern wird die Funktion session_start() verwenden. Wäre ungünstig, wenn man dafür den Safemode oder open_basedir deaktivieren müsste, also würde ich das Problem woanders vermuten - z.B. eben bei den Rechten von /var und /var/lib. Der Safemode muss aber laut Voraussetzungen sowieso deaktiviert sein.

lighthttpd soll ziemlich ressourcenschonend sein, ich habe das allerdings selbst nicht eingesetzt bisher. Vielleicht setzt das jemand anders hier ein und kann kurz berichten. Letztendlich sollte es ausreichen, wenn der Service auf Port 80 auf jede Anfrage das hier zurückgibt:

HTTP/1.x 301 Moved Permanently
Location: http://www.deinedomain.de

Das könnte vielleicht auch ein Shellskript über inetd erledigen.

D.h. du hast die Domain weiterhin beim Webspace-Paket, erreichst den Server also über seine IP? Dann gibt es eben die Möglichkeit mit Squid, oder du nimmst einen Mini-Webserver, der eine Umleitung (301 Moved Permanently) auf den Webspace für jede Anfrage zurückgibt. Dann würde sich natürlich die URL in der Adresszeile ändern, aber wer ruft schon die IP direkt auf? Gibt es denn überhaupt jemanden, der die Webseite bei der Eingabe der IP erwartet?

Dem Apache bei der Zieldomain muss natürlich auch gesagt werden, dass er sich um diese Domain kümmern soll und was er für die Domain anzeigen soll. Das heißt, du müsstet die Domain als Alias (oder wie auch immer das bei Confixx heißen mag) für die eigentliche Domain eintragen. Damit habe ich allerdings keine Erfahrung. Wenn du aber das nicht willst/kannst/darfst, musst du einen Proxy wie eben Squid einsetzen, den du aber sehr sorgfältig konfigurieren solltest. In jedem dieser Fälle (auch mit rinetd) hast du natürlich beim vServer den doppelten Traffic der Webseite. Insofern wäre es äußerst sinnvoll, wenn du die Domain direkt dem Webspace zuordnen würdest.

EDIT: Achso, ich glaube, ich verstehe langsam, was du machen willst: Alle HTTP-Anfragen extern bearbeiten, aber sonstige Anfragen (FTP z.B.) lokal?

Sorry, hatte vorhin nur kurz Zeit. Der Thread hier könnte allerdings trotzdem mit dem anderen zusammengeführt werden.

Bei mir läuft Lenny nun seit dem Upgrade vor 2-3 Wochen problemlos. Was Apache und PHP angeht: Ich war, als ich den Server bekommen habe, die Konfiguration von den beiden von oben bis unten durchgegangen und hatte einiges angepasst. Beim Apache hatte ich dabei z.B. geändert, dass nicht die Konfigurationsdateien in sites-available und sites-enabled genutzt werden, sondern alle Dateien mit einer bestimmten Endung im Ordner sites. Beim Update hätte ich natürlich einfach die Konfigurationsdateien lassen können, allerdings wollte ich sehen, was sich an der Standardkonfiguration geändert hat, um evtl. sicherheitskritische Änderungen auch bei mir umzusetzen (bzw. Neuerungen in der neuen Version). Dementsprechend musste ich eben die Konfigurationen komplett vergleichen (lassen), was eben seine Zeit braucht. Bei PHP kam noch dazu, dass ich eAccelerator installiert habe, und das muss man für jede Version neu kompilieren. Tut man das nicht, funktioniert die Homepage einfach nicht und man fragt sich warum. Das gleiche gilt natürlich auch noch für andere Programme, deren Konfigurationsdateien man geändert hat. Ich persönlich habe mir eben die Zeit genommen, wenn man entweder alle seine Konfigurationsdateien beibehalten oder überschreiben will, geht das auch viel schneller.

Klogd musste ich auch ausschalten. Zu dem Thema kannst du hier bzw. hier nachlesen, warum das auf einem vServer nicht geht/gehen sollte. Allgemein ist der Zugriff auf den Kernel eine Sache, die einen Rootserver von einem vServer unterscheidet. Ich habe natürlich jetzt kein Etch-System mehr zum Vergleich, aber ich kann mich nicht daran erinnern, dass es vorher einen Kernel Log gab.

Wie sieht es mit den Rechten der Ordner /var und /var/lib aus? Vielleicht scheitert es daran, dass der Apache gar nicht erst in /var/lib reinkommt. Die Rechte für /var/lib/php5 sind bei mir drwx-wx-wt, wobei ich das "t" noch nie vorher gesehen habe... könnte vielleicht für "temporary" stehen oder so.

https://forum.netcup.de/showthread.php?t=453
https://forum.netcup.de/showthread.php?p=1687#post1687

Dass er die IP der Domain ("A-Record") auf die des vServers umstellen soll, das reicht dann. Der Nameserver gibt an, welcher Server die Domaininformationen verwaltet, und wenn das weiterhin dein alter Hoster tut, ändert sich daran nichts.

Falls du direkt die Domain ändern kannst, solltest du natürlich die auf den Webspace lenken, nicht auf deinen vServer. Ansonsten dürfte dir das hier weiterhelfen, mit

localhost	80 externer.webspace.de	80

RewriteBase...

• weglassen
• leer lassen (also ohne "/")
• erweitern um 1-2 Ordner, in dem die Datei auf dem Dateisystem liegt (die Subdomain liegt ja in einem eigenen Ordner)

Bei RewriteRule das "/index.php"..

• auf index.php ändern
• auf /ORDNER/index.php ändern
• auf ORDNER/index.php ändern

Und Kombinationen davon.

Das ist ja durchaus möglich, wenn es verschiedene php.ini's für die Haupt- und die Subdomain gibt. So gesehen ist eigentlich auch die Einstellung für die Subdomain korrekt, wenn im Paket nur 16 MB enthalten sind. Du kannst dich aber trotzdem an den Support wenden und anfragen, ob sie das Limit hochsetzen können.

Dann kann es eigentlich nur so sein, dass auf einen Ordner bzw. eine Datei umgeschrieben wird, auf den/die nicht zugegriffen werden darf. Und das kann nur an RewriteBase oder RewriteRule liegen. Also mal mit den beiden Angaben experimentieren.

Wenn die .htaccess direkt aus Wordpress heraus beschrieben werden soll, muss der Apache Schreibrechte auf die Datei haben. Wenn er der Besitzer der Datei ist (sollte man per FTP nachgucken können), dann müsste er die haben, ansonsten müssen die Rechte auf 666 oder 777 geändert werden (zumindest kurzzeitig).

Die Permalinks funktionieren nur mit der .htaccess. Allerdings wird dafür mod_rewrite benötigt. Geh mal in Confixx auf "Einstellungen", "Httpd Spezial" und schau nach, ob mod_rewrite für diese Domain eingeschaltet ist. Ansonsten könnte ich mir noch vorstellen, dass es am RewriteBase liegt.