App-Installation schlägt fehl und hängt.

    Moin!


    ich bin gerade über ein Problem gestolpert, das ich schon bei unserem ersten Test hatte.


    Wenn sich Web- und MySQL-Server auf verschiedenen Hosts befinden, muss in der my.cnf unbedingt bind-address 127.0.0.1 auskommentiert werden! (Ist das eigentlich irgendwo dokumentiert? Bin mir jetzt nicht sicher, ob ich das irgendwo gelesen habe)


    Das habe ich gerade vergessen und versucht Typo3 als App zu installieren. Nun wird unter Anwendungen diese Installation mit dem Status "Installatoin läuft..." angezeigt. Ich finde keine Möglichkeit das zu stoppen. Auch kann ich den Vertrag nicht mehr löschen, da ich die Datenbank nicht löschen kann. Sie wird nur durchgestrichen und das war's.


    Wie kommt man da wieder raus?


    Schönes Wochenende,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Hallo Herr Groh,


    zum Abbruch fehlerhafter/hängender App-Installationen gibt es in Kürze ein Update.
    Außerdem werden wir eine Prüfung einbauen, mit der LiveConfig sicherstellt dass es überhaupt eine Verbindung zum MySQL-Server aufbauen kann bevor versucht wird, dort eine neue Datenbank anzulegen.


    Das Update ist voraussichtlich ab Montag Nachmittag als Preview erhältlich.
    In manchen Fällen hilft ein Neustart von LiveConfig, da dort noch mal explizit viele "hängende" (nicht abgeschlossene) Aufgaben abgearbeitet werden.


    Viele Grüße


    -Klaus Keppler

    Okay, es scheint etwas komplexer zu sein.


    Ein Blick in die mysql-Datenbank des MySQL-Servers zeigt folgendes:


    während eine vom Nutzer angelegte Datenbank einen Nutzer erhält, der von allen eingetragenen IP-Ranges zugreifen darf:


    Beispiel: oskar@localhost, oskar@10.0.1.0/24 (internes Netz) und oskar@83.a.b.0/25 (externes Netz, eigenes SubNet)


    wird der Nutzer für die zu installierende Anwendung nur angelegt für den Zugriff von Localhost:


    Beispiel: lc15_typo3@localhost oder lc15_wordpress@localhost.


    So wird ein Zugriff vom WebServer des einen Hosts auf die Datenbanken des anderen Hosts unmöglich.


    Viele Grüße,


    Oskar Groh

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Hi Oskar,
    in LiveConfig gibt es in der Serververwaltung beim Punkt "Datenbanken" den Punkt "Bearbeiten" (oben links im hauptframe), dort kannst Du IP-Adressen angeben von denen aus der Zugriff auf den entsprechenden Datenkbanserver gewährt werden darf...


    vielleicht hilft es ja wenn Du hier mal die IP-Adresse von dem Web-Server angibst?...


    EDIT:
    Sehe gerade:

    Zitat

    während eine vom Nutzer angelegte Datenbank einen Nutzer erhält, der von allen eingetragenen IP-Ranges zugreifen darf:

    *Wenn* Du hiermit schon den Punkt meinst den ich anspreche hat es sich ja erledigt :)

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

    Hallo webby,


    so isses! :)


    Update: Nach einer kompletten Neuinstallation des Clusters funktioniert das nun problemlos. Ich habe es in allen erdenklichen Kombinationen probiert.


    Allerdings habe ich noch mit der /etc/hosts gespielt. Was genau, schreibe ich heute Abend noch hier rein.


    Grüße,


    Oskar

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Zitat von WebOscar


    Update: Nach einer kompletten Neuinstallation des Clusters funktioniert das nun problemlos. Ich habe es in allen erdenklichen Kombinationen probiert.


    Klasse, diese Konstellation habe ich nämlich auch vor, jedoch teste ich jetzt erstmal alles nur auf einem Server (da meine damaligen Versuche mit mehr als 2 zusätzlichen LiveConfig-Server nicht befriedigend waren). Sobald ich ich nicht mehr über weitere Dinge stolper, werde ich auch auf eine für jeden dienst dedizierte Umgebung umsteigen bzw. Testen. Dies entspricht unserem aktuellen Setup jedoch wird das meiste bei uns noch manuell gemacht...


    Zitat von WebOscar

    Allerdings habe ich noch mit der /etc/hosts gespielt. Was genau, schreibe ich heute Abend noch hier rein.


    Das Wäre klasse und würde vielleicht dem ein oder anderen helfen nicht auf die nase zu fallen. Je nachdem könnte dies vielleicht direkt seinen weg in LiveConfig finden.

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

    Hi Oskar,

    Zitat von WebOscar


    Allerdings habe ich noch mit der /etc/hosts gespielt. Was genau, schreibe ich heute Abend noch hier rein.


    Sag mal.... :) .. *freundlichfrag*: Hast Du das inzwischen schriftlich festgehalten und kannst uns an deinen erkenntnissen teilhaben lassen? ^^


    Mich würde insbesondere noch interessieren wie Kunden auf die Datenbanken zugreifen.


    Ich suche derzeit nach einer möglichkeit das jeder kunde egal auf welchem DB-Server sich seine Datenbank befindet innerhalb seiner anwendungen immer "localhost" verwenden kann. Falls sich das machen lässt würde ich diesen weg preferieren da heute noch die meisten kunden von uns auf den server immer "localhost" verwenden (was dann fehlschlägt) anstelle der entsprechend von uns angegebenen IP-Adresse des MySQL-Servers.


    < hierfür kann gern ein eigener Thread gestartet werden! >

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

    Hallo Webby!


    Eiskalt erwischt! Da war doch noch was...


    Also, ich muss jetzt auf die Autobahn aber vorher noch schnell aus dem Kopf:


    In unserem Netzwerk sind die Server jeweils ueber eine Netzwerkkarte in das Internet und ueber die andere Netzwerkkarte intern verbunden. Per DNS haben die Server dann jeweils zwei Namen.


    Beispiel:


    serv01.domain.ltd 83.x.x.11
    serv02.domain.ltd 83.x.x.12
    serv03.domain.ltd 83.x.x.13 usw


    Fuer das interne Netz dann jeweils noch ein '-l' hinter dem Hostnamen:


    serv01-l.domain.ltd 10.x.x.11
    serv02-l.domain.ltd 10.x.x.12 usw.


    Das Gleiche gilt fuer die virtualisierten Server. Auch die haben zwei (virtuelle) Netzwerkkarten die jeweils ueber die passende physikalische des Servers gebridged werden.


    Wenn ich nun moechte, dass vserv1 ganz schnell mit vserv2 Verbindung aufnehmen kann und zwar ohne erst den DNS zu fragen und ohne dazu die externen Netzwerkkomponenten zu stressen, dann trage ich direkt in die /etc/hosts ein und ueberschreibe so (ganz nebenbei) die eigentliche DNS-Eintraege.


    Wenn also vsrv1 der WebServer ist und vsrv2 der DB-Server dann sieht die /etc/hosts so aus:


    10.x.x.101 vsrv1 vsrv1.domain.tld
    10.x.x.102 vsrv2 vsrv2.domain.tld


    So werden also Anfragen von den eigenen Servern gar nicht erst ueber die oeffentlichen Adressen geroutet.


    Unter Confixx habe ich auch schon die Trennung von Web-, Mail- und DB-Server gehabt. Da es unter Confixx aber immer feste Cluster waren, habe ich den Host-Eintrag beim jeweiligen WebServer entsprechend noch so erweitert:


    10.x.x.102 vsrv2 vsrv2.domain.tld localbase


    bei einem anderen WebServer sah der Eintrag dann eben so aus


    10.x.x.106 vsrv6 vsrv6.domain.tld localbase


    Womit ich das "localhost"-Problem etwas umschifft habe. Soweit ich weiss, ist es nicht moeglich localhost auf einen anderen Server zeitgen zu lassen.


    Der Nutzer musste bei der Einrichtung einmal informiert werden, dass der Server localbase und nicht localhost heisst und das fuehrte auch nie zu Problemen.


    Unter LiveConfig stellt sich die Sache - zumindest mit "localbase" etwas anders da. Da dieser Cluster nicht statisch ist und sich fuer neue Kunden der DB-Server bei Bedarf aendern kann, arbeite ich hier mit dem tatsaechlichen Hostnamen des entsprechenden Servers. Ich leite sie nur ueber das interne Netz, damit - egal ob der Nutzer nun dbsrv1 oder dbsrv1.domain.tld benutzt, die externen Netzwerkkomponenten nicht von der internen Kommunikation gestresst werden.


    Hilft Dir das soweit weiter?


    Uh ich muss jetzt los!


    Viele Gruesse,


    Oskar

    Computer sind unglaublich dumme Geräte,
    die unglaublich intelligente Sachen können.
    Programmierer sind unglaublich intelligente Leute,
    die unglaublich dumme Sachen produzieren.
    ("Die Presse", 30.8.1999)

    Hi,


    Dank Dir für Deine mühe so kurz noch vor feierabend ^^


    Die von Dir beschriebene vorgehensweise nutzen wir in ähnlicher weise in der aktuellen umgebung - wo alles eigentlich gebastelt - ist auch schon.
    Es läuft vermutlich darauf hinaus das wir entweder auch weiterhin über diese art und weise die kommunikation der server untereinander steuern oder aber das ganze mit einem SSH-Tunnel lösen.
    Mit dem SSH-Tunnel kann man weiterhin localhost und den MySQL-Port verweden

    Code
    ssh -c arcfour -L 3306:<DBServer>:3306 user@DBServer


    So funktioniert zumindest bisher mein

    Code
    telnet localhost 3306

    auf dem WebServer und die anfragen wird offenbar zum dbserver weitergeleitet.
    Das "arcfour" ist die zu verwendet verschlüsselungsmethode (sehr gering) damit der server mit der ssh verbindung nicht zu sehr belastet wird.


    Eine andere Option wäre das ganze mit iptables zurecht zu biegen.. aber ich kriegs nicht hin und laut Mr. Google wäre das bei der Umsetzung sehr komplex.


    Auf unseren Windowsserver die ebenfalls per "localhost:3306" auf die mysql-Server weitergeleitet werden, verwenden wir einen dienst (ich glaub der heisst "tcptunnel" oder so - kostenlos) und da funktioniert das wunderbar.


    Danke noch einmal.

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

    Wenn ich mich hier mal kurz einklinken darf.


    Das geplante Setup wird so wohl nicht ganz funktionieren.


    Zitat von http://de3.php.net/mysql_connect

    Immer wenn sie "localhost" oder "localhost:port" als Server angeben, wird die MySQL Client Bibliothek dies überschreiben und versuchen, sich zu einem lokalen Socket (named pipe unter Windows) zu verbinden. Wenn sie TCP/IP nutzen möchten, nutzen sie "127.0.0.1" anstatt "localhost".


    Zitat von http://de3.php.net/manual/de/mysqli.quickstart.connections.php

    The hostname localhost has a special meaning. It is bound to the use of Unix domain sockets. It is not possible to open a TCP/IP connection using the hostname localhost you must use 127.0.0.1 instead.


    Kurz: Egal ob mysql oder mysqli localhost bedeutet für php immer connect via lokalem Dateisocket.


    Bevor hier gar zu viel Energie darauf verschwendet wird den externen Datenbankserver via localhost erreichbar zu machen. ;)


    Viele Grüße
    Christoph Russow

    Zitat von cr

    Wenn ich mich hier mal kurz einklinken darf.

    insgeheim wird das ganz bestimmt sogar gehofft :D


    vielen Dank für die nützlichen infos!!
    Das hat "einem" ;) sicher den ein oder anderen arbeitstag gerettet :)

    - LiveConfig 1.6.0-r2052 (Inaktiv) :: BETA: 1.6.1 - r2142 (Inaktiv)
    [HR][/HR] - CentOS 6.3 x64[HR][/HR]- Apache 2.2.15 - PHP 5.4.12* - mod_suphp 0.7.1** - MySQL 5.5.30*
    - Postfix 2.6.6 - dovecot 2.0.9 - Clamd 0.97.6** - clamav-milter 0.97.6**- postgrey 1.34**
    - vsFTPd 2.2.2 - AWStats 7.0**
    * Aus dem REMI-Repository :: ** Aus dem rpmforge-Repository

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden