Beiträge von Robert

Was genau erhoffst du dir davon, den Dienst selbst zu betreiben? Da du von htaccess etc. sprichst, scheint es mir, als würdest du DynDNS falsch einschätzen. Wie der Name schon sagt, kümmern die sich um DNS, sprich die Zuordnung des gewünschten Domainnamens zu einer IP. Das ist normalerweise eine einmalige Einrichtung, da Server praktisch immer eine feste IP haben. Betreibt man einen Homeserver und hat eine IP, die häufig wechselt, kann man DynDNS benutzen. Das einzige was da passiert, ist, dass dein NAS in regelmäßigen Abständen seine IP schickt, damit das DNS aktualisiert werden kann. Sobald jemand die Domain eingibt, wird die zugehörige IP ermittelt - und die ist durch DynDNS eben immer aktuell. Sobald die IP ermittelt ist, ist der Dienst von DynDNS beendet, denn mit der wendet sich der Client (z.B. Browser) direkt an den Server. Das heißt: Wenn du selbst einen Dienst wie DynDNS einrichten willst, sollte das schon gehen, du musst halt dafür sorgen, dass immer die IP aktuell ist und an Clients mit einer geringen Gültigkeitsdauer herausgegeben wird. Aber es bringt dir bzgl. Absicherung nichts, die muss direkt am Server (bei dir NAS) geschehen.

Ich weiß nicht, ob sich das auf meine Frage bezog - ich meinte eigentlich, ob das Update auf Lenny generell geklappt hat, trotz eventueller Einschränkungen durch die Virtualisierung. Mir ist aber danach noch aufgefallen, dass auf dem vServer bereits der Kernel "2.6.22-3-vserver-amd64" installiert ist. In den Entwürfen der Release Notes zu Lenny (noch eine Woche :)) war vom Upgrade von 2.4 auf 2.6 die Rede. Also muss der Kernel da überhaupt aktualisiert werden? Wenn nicht, dürfte es ja keine vServer-spezifischen Probleme geben, ein Testupgrade auf einer VM hat gut funktioniert bei mir.

Zitat von B. Bachmann;1687

Hat sich erledigt. Ich hab mir nen Backup gezogen und einfach mal nen apt-get dist-upgrade gemacht (hat auch soweit ichs nbis jetzt beurteilen kann geklappt :o)

Jetzt wo ein halbes Jahr rum ist: Gab es doch noch Komplikationen damit? Die größten Bedenken habe ich, dass es Einschränkungen dadurch gibt, dass es eben "nur" ein vServer ist, z.B. beim Upgrade des Kernels...

Scheinbar geht das tatsächlich: http://en.gentoo-wiki.com/wiki/Fail2ban#…ead_of_iptables
Ausprobiert habe ich es noch nicht, werde das aber denke ich morgen mal tun.

Oh ok. Ich dachte nur, weil man ja verschiedene Benutzer mit dem gleichen Namen, aber unterschiedlichem Host anlegen kann, die völlig unabhängig voneinander sind, also auch unterschiedliche Rechte haben können und unterschiedliche Passwörter (die user-Tabelle hat Host und User als Primärschlüssel). Da wäre es ja durchaus hinderlich, wenn der Host einfach ignoriert wird und das Passwort für alle Benutzer mit dem gleichen Namen gesetzt wird.

Darum geht es mir ja nicht, sondern um die Frage, ob auch in der user-Tabelle "localhost" steht. Wenn er sagt, dass der Benutzer grundsätzlich in der Tabelle zu finden ist, dann könnte es ja sein, das die zweite Bedingung bei der Suche, nämlich die Host-Angabe, nicht übereinstimmt, warum auch immer. Das wäre dann eine Erklärung dafür, warum der Benutzer trotz des vermeintlichen Tabelleneintrags nicht gefunden wird.

Ich selbst habe generell auch localhost eingetragen, außer bei kleinen Projekten, bei denen ich per XAMPP lokal entwickle und teste, aber auf eine einheitliche Datenbank zugreifen möchte.

Mir fällt gerade noch die Angabe "localhost" auf - ist der Benutzer tatsächlich dafür angelegt oder vielleicht für alle Rechner freigegeben (%)?

Zitat von killerbees19;2586

Die genannte Zeile kann dann bei Bedarf einfach auskommentiert werden.

Eher andersrum, oder? Also wenn sie auskommentiert ist, wird InnoDB nicht übersprungen, sondern geladen. Da das mehr Speicher braucht, kann man die Einstellung anschalten.

Zitat von benny;2528

Okay, habs gefunden: Der rewrite Mod war nicht installiert.

Code

[B][COLOR=Red]/etc/apache2/mods-enabled[/COLOR][/B]$ ln -s ../mods-available/rewrite.load rewrite.load

ausführen und apache2 neu starten

Für Anlegen (und spätere Löschen) der Links gibt es sogar spezielle Befehle: http://www.digipedia.pl/man/a2enmod.8.html
Die machen allerdings auch nichts anderes. Und statt Neustart reicht auch "/etc/init.d/apache2 reload".

Den Owner ändert man mit chown (change owner):

chown benutzer datei

bzw.

chown benutzer:gruppe datei

Bei WinSCP dürfte das gleiche erscheinen wie per SSH. Es wird für die Datei nicht der Besitzername gespeichert, sondern dessen User-ID. Für die Anzeige wird dann dazu wieder der Name rausgesucht, und diese Verbindung muss es irgendwo geben. Bei SSH und allgemein in der Shell dürfte das über /etc/passwd laufen, bei ProFTPd (das verwende ich) allerdings z.B. nicht. Ich habe das selbst konfiguriert, sodass ich nichts dazu sagen kann, wie Syscp damit umgeht. Jedenfalls gibt es bei mir eine Textdatei, in der die Benutzer im Format wie bei /etc/passwd drinstehen. Meine Vermutung: Es gibt keinen FTP-Benutzer, der die User-ID dieser Datei (bei dir anscheinend 33) hat, also wird ein Fragezeichen angezeigt (ist bei mir in FileZilla so). Ich habe deshalb am Anfang dieser Datei ein paar Dummy-Zeilen eingefügt, also die Benutzer www-data und root, mit denen man sich zwar nicht anmelden kann, die ProFTPd aber bei der Suche nach den Benutzernamen findet. Damit waren bei mir die Fragezeichen verschwunden.

Zitat von Littlerat;2486

Das gibt nur eine weiße Seite...:(

Richtig - alles, was das Skript macht, ist den Fehler-Code 404 zu senden. Das siehst du nicht, aber z.B. Suchmaschinen werten das aus. Von dem was du bisher geschrieben hast, erfüllt das genau seinen Zweck, es wird 404 statt 403 erzeugt. Nach dem ?> kannst du ganz normales HTML hinschreiben. Ich weiß nicht, ob man irgendwie die Standard-Apache-Fehlerseiten erzeugen kann. Notfalls kannst du ja den Quelltext reinkopieren.

Ja, denn Stabilität ist bei Servern oft wichtiger als die allerneusten Features.

Ich benutze Syscp nicht, daher weiß ich nicht, welcher Ordner dafür vorgesehen ist. Allerdings müsste Syscp in /etc/apache2 die Konfigurationen ablegen, vielleicht gibt es da eine mit "default" im Namen. Dort stände dann der "DocumentRoot" drin. Vielleicht wird das auch irgendwo in Syscp direkt angezeigt, entweder direkt oder z.B. als Bestandteil vom open_basedir. Oder es steht in der Syscp-Datenbank. Falls es allgemeine error.log-Dateien gibt (als von allen Hosts auf dem Server), steht da glaube ich auch genauer drin, was die Ursache für das Berechtigungsproblem war.

Wenn du den Pfad dann erstmal hast, einfach die Datei per FTP/SSH (je nachdem, was dafür verfügbar ist) abspeichern als index.php.

Was genau machen? Die PHP-Datei?

[PHP]
<?php
header("HTTP/1.0 404 Not Found");
?>
[/PHP]

Was für eine Distribution ist das? Debian Etch? Dann ist das die neueste: http://packages.debian.org/etch/php5
Für Mysql: http://packages.debian.org/etch/mysql-server

Das liegt daran, dass Debian auf hohe Stabilität und viele Tests anstatt immer topaktueller Versionen setzt. Diese speziellen Debian-Pakete enthalten wohl auch Anpassungen an Debian, vermutlich auch Fixes von bekannten Bugs, die in den regulären Versionen erst später behoben wurden.

Man kann erzwingen, dass unstable-Pakete installiert werden. Zum einen geht man damit aber das Risiko von weniger getesteten Versionen ein, zum anderen musste ich selbst feststellen, dass das jede Menge andere Updates nach sich zieht, womit man letztendlich sein ganzes System auf unstable-Pakete updaten muss. Das war es mir nicht wert, deshalb habe ich jetzt alles wieder auf stable downgegradet (was übrigens auch gar nicht mal so einfach war). Alternativ dürfte ein Distributionsupgrade helfen, womit ich mich allerdings noch nicht beschäftigt habe.

Wenn ich das richtig in Erinnerung habe, wird im Fall einer nicht existierenden (= gar nicht angelegten) Subdomain der Standardhost genommen. Das dürfte eigentlich die Seite sein, die auch bei der Eingabe der IP kommt, ich weiß aber nicht, wie Syscp das strukturiert. Vermutlich ist der Ordner, auf den das letztendlich geleitet wird, so eingerichtet, dass die Dateiauflistung verboten ist, daher 403. Dort könntest du vielleicht eine PHP-Datei speichern, die per header() tatsächlich eine 404 erzeugt. Am besten wäre es natürlich, dafür gar keinen DNS-Eintrag anzulegen, aber ich habe bei meiner auch Catch-All drin.

Klingt gut. Und beim Soft-Limit bekomme ich einfach eine Mail zugeschickt, ohne dass der Server heruntergefahren wird?

Das mit den Zeichensatzproblemen wollte ich auch gerade schreiben.

Das mit der Domain hängt nur vom Anbieter ab, bei dem du die Domain hast. Falls du dort eine IP-Adresse einstellen kannst, dann geht es. Dem Apachen kannst du auch sagen, wie er Anfragen für microsoft.com beantworten soll - wenn ihn denn jemand danach fragen würde. Und wenn du halt bei deiner Domain einstellst, dass bei subdomain1.domain.tld dein Server gefragt werden soll, dann wird das auch gemacht und der kann die Anfrage beantworten.

Du hättest denen bei WP auch den Screenshot zeigen sollen, dann hätten die hoffentlich gesehen, dass das Problem nichts mit dem Open_Basedir (und somit dem Hoster) zu tun hat. es wird versucht, auf JS-Dateien zuzugreifen, die sich angeblich auf allerhöchster Verzeichnisebene befinden sollen. Da sind die nie im Leben, es wird der Pfad falsch zusammengebaut von der Datei, vermutlich ein Fehler in deinen Einstellungen. Schau dir mal die post.php an, dort wird kurz vor den angegebenen Zeilen der Pfad zusammengesetzt. Meine Vermutung ist, dass WP_PLUGIN_URL oder WP_PLUGIN_DIR nicht korrekt gesetzt sind. Schau mal bitte, ob du beim Update auch die wp-settings.php aktualisiert hast, bzw. lass dir mal nach den einzelnen Schritten der Pfadkonstruktion ausgeben, wie der momentane Pfad aussieht.

Ich habe gerade festgestellt, dass der Transfer Lock bereits eingestellt war - trotzdem vielen Dank für die Antwort!