Alle Besucher haben IP 127.0.0.1

[Layzee]

Hallo zusammen,

ich bin neu hier und wende mich in der Hoffnung an dieses Forum, dass mir jemand bei meinem (in meinen Augen ungewöhnlichen und merkwürdigen) Problem helfen oder mir zumindest einen Tipp geben kann.

Wir sind jüngst von einem Rootserver von S4Y auf einen grösseren Rootserver bei Strato umgezogen. Der Umzug ging relativ leicht vonstatten und auf den ersten Blick hat auch nahezu Alles auf Anhieb funktioniert.

Für einige hier mag dieses Problem nun ganz banal klingen, aber genau an diese User richtet sich meine Frage, denn wenn man sowas schonmal hatte und lösen konnte, sollte ja eine kompetente und sachliche Antwort kein Problem sein ;)

Das Problem ist, dass seit dem Umzug auf den neuen Server alle User auf den Webseiten (CMS) die IP 127.0.0.1 bekommen. Abgerufen wird diese im CMS selbst über "REMOTE_ADDR", also wie es eigentlich in PHP-Scripts üblich ist. Ein ebenfalls installiertes Analysetool (Piwik) zeigt hingegen die richtigen IPs. Da auf dem Root innerhalb der CMS-Installation auch ein Chat läuft bzw laufen soll und wir schlechte Erfahrungen machen mussten bezüglich Spambots, brauchen wir wieder die Anzeige der richtigen IPs im CMS.

Auf meine Anfrage bei Strato per Mail/Ticket bekam ich leider nur die Antwort, dass man mir bei Problemen bzw dem Einsatz von PHP-Scripts nicht helfen kann (oder auch will).

Kann mir hier vielleicht jemand helfen oder sagen wo ich ansetzen muss/kann/soll um das Problem zu lösen?

MfG
Layzee

[Joe User]

Ihr habt vermutlich einen Reverse-Proxy vor den Apache geklemmt, somit sollte http://www.thomas-krenn.com/de/wiki/Apache_mod_rpaf helfen.

[ddm3ve]

Oder alternativ den HTTP Header auswerten.
X-FORWARDED-FOR müsste es meines wissens sein.

-> woebi die Liste , Seperiert auch mehrere Proxy Ips enthalten kann.
Der Letzte Eintrag in der Liste ist die Client IP.

mod_rpaf hat leidr das Problem, dass es weitere ggf. vorgelagerte Proxys nicht kennt / erkennt.

Grundsätzlich ist die eindeutige und zweifelsfreie Erkennung der Client IP, nicht immer 100% zuverlässig und einfach zu lösen.

Typische Beispiel:

Bei uns im Haus läuft ein Proxy, die Clients haben nur lokale ips.

Also könnte beim aufgerufenen Webserver in Forwarded-for die lokale und private IP des Client Rechners zu finden sein.


Mit einer 192.168.115. Adresse wiederum kannst du auch nicht wirklich etwas anfangen.

Daher muss man die privaten IP Ranges bei der Ermittlung heraus filtern.
http://en.wikipedia.org/wiki/Private_network

Ob das Deine eingesetzte Software zuverlässig und richtig macht und unterstützt, weiss ich nicht.

[Layzee]

Zunächst vielen Dank für die Antworten.
Zwischenzeitlich konnte ich das Problem eingrenzen und schlussendlich auch lösen.

Plesk hat bei der Installation "nginx" (wie hier schon vermutet ein Reverse-Proxy-Server-Dienst) zusätzlich zum Apache Webserver installiert und gestartet. Nachdem ich den Dienst über Plesk beendet hatte wurden die IPs wieder korrekt dargestellt. Apache sollte doch als Webserver genügen oder?

Gut zu wissen, dass man hier kompetente Hilfe bekommt und nicht mit "Nicht unser Problem, sie haben einen Rootserver, sie sind allein verantwortlich" abgespeist wird.

Nun weiss ich wenigsten wohin ich mich wenden kann wenn ich mal Probleme habe die ich nicht alleine lösen kann oder auf deren Lösung man nicht gleich kommt.

DANKE!

[ddm3ve]

Plesk hat bei der Installation "nginx" (wie hier schon vermutet ein Reverse-Proxy-Server-Dienst) zusätzlich zum Apache Webserver installiert und gestartet. Nachdem ich den Dienst über Plesk beendet hatte wurden die IPs wieder korrekt dargestellt. Apache sollte doch als Webserver genügen oder?

Auf Stark frequentierten Webseiten kann es sich schnell lohenn den Statischen Content durch einen leichgewichtigen Webserver / Cache wie nginx ausliefern zu lassen.
Unterschätzen würde ich das Thema nicht.

[Layzee]

Naja, momentan hat die Hauptseite ca 600-800 Klicks am Tag, ich denke das geht noch und das sollte der Apache noch alleine handlen können oder?

Wir haben aber noch ein recht kurioses Problem, auf dessen Lösung ich nicht komme:

Wir nutzen für die Webseite ein CMS, welches ich vom alten auf den neuen Rootserver umgezogen habe, sprich auf dem neuen Root eine neue MySQL-Datenbank angelegt, die Daten und Tabellen über phpMyAdmin importiert, die Daten des CMS auf den Webspace kopiert und die config.php entsprechend angepasst. Das CMS funktioniert auch einwandfrei, man kann ins Forum posten, Pinnwände vollschreiben, User können sich einloggen, ausloggen und registrieren und halt all die Dinge, die man so mit einem CMS tun kann.
Was jetzt NICHT mehr funktioniert ist das Installieren von Addons über das System (Adminbereich). Das Addon wird nach der Installation als installiert angezeigt, wechselt man aber zum Einstellen der Parameter des Addons in das backend, wird dort angezeigt, dass die Tables nicht existieren, sprich es werden bei der Installation von Addons keine Tables in die Datenbank geschrieben.

Ich habe dann mal versucht, in einem Unterverzeichnis eine neue Installation des CMS durchzuführen, was auch ohne Probleme funktionierte. hier wurden alle Tables korrekt angelegt und keinerlei Fehler angezeigt.
Allerdings habe ich auch bei DIESER CMS-Installation genau das gleiche Problem: Es werden bei der Installation von Addons keine Tabellen geschrieben...

Woran könnte das liegen?!

[ddm3ve]

Vermutlich hat der dB User nicht mehr ausreichende rechte. Z.b. Als root installiert aber danach als anderer Benutzer betrieben.

Eine andere Ursache könnte ein für die neue dB Version inkompatibler SQL Slang sein. Zwischen MySQL 5.0 und 5.1/5.5 hat sich die Syntax nicht unerheblich geändert.

[Layzee]

Hm... also wenn es an den Rechten läge, könnte ich doch über das CMS selbst auch keine Daten in die Tabellen schreiben oder?
Darüber hinaus ist die Datenbank natürlich über Plesk als "Root" angelegt worden, aaaaber: Die Installation des CMS selbst funktioniert ja als Webuser ohne Probleme, das bedeutet dort werden Tabellen angelegt bei der Installation und auch die entsprechenden Daten (zb die Daten des "Hauptadmin") in die Tabellen geschrieben. Selbst die Systemeigene "Shoutbox" kann ohne Probleme über das CMS direkt installiert werden, die Tabellen werden korrekt erzeugt. Einzig die "systemfremden" Addons lassen sich aus bereits genanntem Grund nicht mehr installieren.

Nichts desto trotz:
Könnte es helfen wenn ich über Plesk zuerst einen "normalen" Webuser anlege, übder dessen Login in Plesk dann die Datenbank anlege und DANN die Sicherung des CMS in diese Datenbank zurückspiele? Die notwendigen Berechtigungen sollten doch dann korrekt sein oder?
Wobei es ja bei Plesk so ist, dass man zuerst den Webuser (Host) auswählt und dann dort entsprechend die Datenbank anlegt...

Ich habe mit dieser Pleskversion (11.x) bisher noch nicht gearbeitet und es gibt da wesentlich mehr Funktionen und Settings als noch in der 9er oder 10er Version.

Noch einige Infos zum System:
Version: Parallels Plesk Panel v11.0.9_build110120608.16 os_Ubuntu 12.04
OS: Ubuntu 12.04 LTS
MySQL: 5.5.24
PHP: 5.3.10

[Joe User]

Klingt nach einem Rechteproblem auf Filesystemebene (unterschiedliche User/Group und/oder Zugriffsrechte). Da ich von Plesk keine Ahnung habe, muss Dir dabei jemand Anderes helfen.

[Layzee]

Naja, Rechte kann man ja auch direkt in der Konsole vergeben/ändern...

Angenommen der User "root" legt eine Datenbank an, die "cms_" heisst, dazu einen User "Layzee" und das entsprechende Passwort.
Wie müsste der Befehl in der Konsole lauten um dem Webuser "Layzee" die entsprechenden Rechte für diese Datenbank zu geben? Betriebssystem ist wie oben schon gesagt Ubuntu.

[Joe User]

Einen Datenbankbenutzer und eine Datenbank legt man zum Beispiel so manuell an:

Code: Select all

[root@hostname:~] # mysql -uroot -ppass
-- 
-- MySQL-Konsole betreten
-- 
-- Datenbankbenutzer cms_user erstellen (Zugriff per UNIX Socket erlaubt, Passwort = PaSsWoRd)
-- Datenbankbenutzer cms_user erstellen (Zugriff per TCP/IP 127.0.0.1 erlaubt, Passwort = PaSsWoRd)
CREATE USER 'cms_user'@'localhost' IDENTIFIED BY 'PaSsWoRd';
CREATE USER 'cms_user'@'127.0.0.1' IDENTIFIED BY 'PaSsWoRd';
-- 
-- Notwendigen Lesezugriff auf Datenbank mysql geben
GRANT USAGE ON `mysql`.* TO 'cms_user'@'localhost';
GRANT USAGE ON `mysql`.* TO 'cms_user'@'127.0.0.1';
-- 
-- Datenbank cms_database anlegen
CREATE DATABASE IF NOT EXISTS `cms_database` DEFAULT CHARACTER SET utf8;
-- 
-- Vollen Zugriff auf Datenbank cms_database geben
GRANT ALL PRIVILEGES ON `cms_database`.* TO 'cms_user'@'localhost';
GRANT ALL PRIVILEGES ON `cms_database`.* TO 'cms_user'@'127.0.0.1';
-- 
-- Rechtesystem neu laden
FLUSH PRIVILEGES;
-- 
-- MySQL-Konsole verlassen
QUIT;
[root@hostname:~] # _

Zugangsdaten für Webapps:
* DB: cms_database
* User: cms_user
* Pass: PaSsWoRd
* Host: localhost


Hoffe, das hilft.

[ddm3ve]

Um auf Layzees frage ein wenig ein zu gehen...

Ich glaub dam Name ist auch irgendwie Programm ;-) Mysql Doku ist eine herrliche Lektüre.

Also Du solltest Dir grundlegende das Kapitel zum Befehle grant ansehen.
Alternativ ein kleiner Tip:
Als Beispiel:
show grants for 'root'@'localhost';

Dann kommt folgendes Ergebnis bei raus:

Code: Select all

mysql> show grants for 'root'@'localhost';
+---------------------------------------------------------------------+
| Grants for root@localhost                                           |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
| GRANT PROXY ON ''@'' TO 'root'@'localhost' WITH GRANT OPTION        |
+---------------------------------------------------------------------+
2 rows in set (0.00 sec)

Also pro Zeile genau die Befehle, für die Zuteilung der Rechte des Benutzers.
Auch wenn Du Eingangs eine Lobhymne angestimmt hast, Eigeninitiative erwarten wir schon auch. Denn von Consulting, und das ist nichts anderes als Consulting was hier hier grad betreiben, leben wir i.d.R. und verlangen dafür auch Geld.

Und nur damit da kein Irrtum mehr besteht, natürlich kann ich mit einem typichen User Account Daten in meine Tabellen pumpen, aber Admin Rechte wie z.B. zum Anlegen von Tabellen "grant create table" muss er deshalb nicht haben.
Bei Plesk lautet der von mir gemeinte root User "admin" und bezieht sich nur auf den Datenbankbenutzer.

[Layzee]

Erst noch einmal recht herzlichen Dank für die Hilfestellungen.

Es entsteht vielleicht gerade auch ein bisschen der falsche Eindruck von mir und meiner grundlegenden Einstellung. Natürlich gehört zu kompetentem Support auch immer Eigeninitiative und im "Normalfall" bin auch ich ein Mensch, der seine "Problemchen" lieber im stillen Kämmerlein so für sich löst und sich durch Tuts und Manuals gräbt - und so ist mein Nick in der Regel eigentlich so garnicht "Programm" ;)

Ich habe offensichtlich einfach den Fehler gemacht, zu früh mit dem Rückspielen der Daten anzufangen, nämlich noch bevor ich dem Server die Hauptdomain zugewiesen habe. So habe ich über Plesk zwar einen Webuser angelegt, allerdings erst NACHDEM ich die entsprechenden Datenbanken angelegt habe - bzw ich habe diese über den User "admin" angelegt, statt einen entsprechenden reinen Webuser mit entsprechend eingeschränkten Rechten anzulegen und mich mit diesen Daten einzuloggen.

Wie man so schön sagt: Hinterher ist man immer schlauer.
Mir ging es jetzt darum, nicht komplett von vorne anfangen zu müssen, denn das sind knapp 11 Gigabytes an Daten die ich erneut "hochschaufeln" müsste. Letztendlich gibt es auch für dieses Problem somit mehrere Lösungsansätze und ich versuche halt den zu finden, der mit dem geringsten (zeitlichen) Aufwand zum gewünschten Ergebnis führt bzw mich sicher sein lässt, auf dem richtigen Weg zu sein.

Im Zweifelsfalle müsste ich also noch einmal die Datenbanken sichern, den angelegten Webuser löschen, die Domain einem neuen Webuser zuweisen, mich dann als dieser User anmelden und die erforderlichen Schritte noch einmal als dieser User durchführen. Damit sollte aber dann die Datenbank für diesen User auch die entsprechenden Rechte haben.

Was mich einfach stutzig macht ist schlussendlich die Tatsache, dass ich als der gleiche Webuser Tabellen bei der Installation eines CMS ohne Probleme anlegen kann (in einer leeren Datenbank), über die gleiche Installation (CMS) aber dann im Nachhinein plötzlich nicht mehr (Addons).
Das ist was ich nicht so ganz verstehe bzw nachvollziehen kann.

Testen kann ich das leider nur in der Praxis, sprich ich muss darauf vertrauen, dass die Aussage von erfahreneren Admins als ich es (leider) zu sein scheine auch passen, denn sonst wäre die ganze Arbeit ja letztendlich umsonst. Deshalb war meine Frage so "direkt" gestellt.
(Ich werde 41, vielleicht lerne ich auch einfach mit zunehmendem Alter etwas langsamer ;) )

Tut mir leid :(

[ddm3ve]

Führe doch wie oben beschrieben einfach mal das Show Grants aus. Alternativ noch select User,Host from MySQL.user; ich möchte daran ermitteln, ob es ggf. Mehrere Benutzer mit gleichem namenngibt und ob auchndie rechte dabeinstimmen.

[quote=ddm3ve]Ich hasse diese sich selbst austricksende Recht-Schreibungskorrektur von Betriebsystem und Browser. Und warum zur Hölle, schlagt ihr mir Dinge vor und ändert Texte bevor ich fertig bin mit schreiben? Warum häh?[/quote]

[Layzee]

Sorry, ich hatte mich jetzt erst einmal eingehender mit "nginx" und der IP-Problematik befasst, weil ich eigentlich auch kein wirklicher Freund von Kompromiss- oder "Brechstangen"-Lösungen bin.

Ich habe das jetzt gelöst, indem ich den hier schon genannten Weg über "X-FORWARDED-FOR" gegangen bin.

Dazu habe ich in die config.php des CMS, die ja bei jedem Aufruf ausgeführt wird, folgende Zeilen geschrieben:

$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];

Damit funktioniert das - zumindest bei mir - ohne erkennbare Probleme und der Reverse-Proxy ist wieder aktiv.

Ich werde mich morgen Vormittag dann noch eingehender mit der MySQL-Geschichte beschäftigen und bedanke mich nochmals für die Hilfestellungen.

[ddm3ve]

Achte aber bitte darauf, wie hier beschrieben, http://www.rootforum.org/forum/viewtopi ... 99#p325421
dass in dem Header auch eine Komma separierte Liste zurück kommen kann.

[Joe User]

Und ohne mod_rpaf oder ein ähnliches Modul hast Du auch keine brauchbaren Webserverlogs mehr. Das kann später zu erheblichen Problemen bei anderen Fehlersuchen oder gar beim Analysieren etwaiger Hacks beziehungsweise Hackversuchen.

[ddm3ve]

Du kannst aber das Logging entsprechend umstellen, so dass auch dort die Ips aus dem Header auftauchen. Auf Seite lighttpd, habe ich das zumindest so gelöst:http://fak3r.com/2008/01/09/howto-log-t ... ccess-log/.

Ich hab auf anhieb nicht die gleiche Funktion für den Apache gefunden.
http://httpd.apache.org/docs/1.3/mod/mo ... onfig.html

Damit wäre das Modul rpaf jedoch verzichtbar.