CRM und Zugriff von extern - 2

Question

Darf ich diese Frage bitte aufwärmen?

Auf 2 Servern habe ich das gleiche Problem.
Beide sind mit Ubuntu 12.04 und aktuell upgedatet. Lokal, also inhouse, funktioniert auf allen Stationen alles wunderbar. ERP und CRM alles gut und super.
Von extern über den Firefoxbrowser, funktioniert nur noch ERP und CRM hat ein Dauerwarten, obwohl beides ERP und CRM ja der Apache ausliefert.
Per X2Go Client, also sozusagen inhouse, alles gut: ERP und CRM funktioniert.
Der eine Router ist ein Speedport, der andere Router ein Linux. Auf beiden wird der Port von außen von 50080 auf 80 umgesetzt.
Wie kann so etwas sein? Woran könnte das liegen und wo suchen?
Eigentlich kann so etwas gar nicht auftreten, oder?

Viele Grüße
Ulrich

Answer 1

Hallo,

Da wirst du wohl nicht umhin kommen mal deine Router genauer unter die Lupe zu nehmen. Bei dem Linux-Router sollte das wohl auch kein Problem sein.

Wird der port von iptables umgeschrieben ?

Was sagen die Logs und logst du auch alles befor du abgelehnte Verbindungen mit DROP löschst ?

MfG

Comments

Vielen Dank Gerd für die Antwort.
Nein - es wird nichts gedropt.

Der Speedport kann das gar nicht selektieren und droppen, und der Linux macht das nicht. Der Speedport routet entweder weiter, oder nicht. Der Widerspruch ist: Bei ERP und anderen Programmen routet er ja, nur CRM hat Probleme.
Argument gegen Routerprobleme:
- zwei verschiedene Router mit dem gleichen Prob??
- ERP funktioniert tadellos und ist auch auf TCP Port 80 wie CRM auch. Wie sollte ein Router einen Unterschied zwischen ERP und CRM auf dem selben Protokoll machen? Andere Programme auf TCP und Port 80 funktionieren auch tadellos, nur CRM nicht.
- Vor ERP Update auf 3.0.0 funktionierte auch CRM über den Linux Router seit Jahren, der inzwischen nicht verändert wurde. Hier benötige ich den externen Zugriff nicht oft. Die andere Installation ist neu und ich weiß nicht, ob dort CRM auf extern schon jemals funktioniert hatte.

Was macht CRM auf dem Netz anders als ERP ????

Viele Grüße
Ulrich

---

Hallo,

ich hab das hier über einen ssh tunnel

ssh -L 50080:server:80 router....de

http://localhost:50080/kivitendo-erp/

das crm funktioniert bei mit erst nachdem ich es in den .../www/lx-office-crm (1.5.5_4.tgz) neben .../www/kivitendo-erp gelegt habe. Anscheinend ist da noch einiges was diesen Pfad erforderlich macht.

Aber wen's lockal funktioniert ist das schon etwas eigenartig.

MfG

---

Hallo Gerd,
gerade habe ich jetzt auch über ssh ausprobiert:
ERP funktioniert, CRM hat Dauerwarten und nach langem Warten kommt eine weiße Seite = Timeout
Jetzt ist der Router definitiv nicht mehr daran schuld !
Was macht das CRM eigentlich ??

---

Hallo,

Was macht das CRM eigentlich ??

wie jetzt, funktioniert das CRM den lokal ??

Wen du dich im .../kivitendo-erp/ angemeldet hast sollte im Menü auch der Punkt CRM da sein

--> CRM --> Kunde
        --> Lieferant
        --> Person
        --> Termin
        --> ..
            ..

Wie rufst du das den auf ?

ein http://localhost/kivitendo-erp/crm/ gibt auch bei mir ein

---

Forbidden
You don't have permission to access /kivitendo-erp/crm/ on this server.
---------

MfG

---

Hallo Gerd,
CRM funktioniert lokal schon lange. Auf der einen Installation schon seit 2009, die andere Installation ist neu.
Es gibt eine ausgezeichnete Anleitung wie man das CRM installiert, erst die nötigen Pakete installieren, php config kontrollieren, dann Entpacken, Menü erweitern, die inc/config.php richtig einstellen und --> läuft!
Alles klasse!

Nur seit Neuestem nicht mehr über das Internet nach extern und wie ich seit jetzt gerade weiß nicht mal mehr über ssh, obwohl ssh mit dem Tunnel schon fast wieder lokal ist - aber eben doch nicht.
Da ERP und CRM mit TCP und http auf Port 80 nichts anderes als Get und Put machen (hoffe ich), bezieht sich die Frage "Was macht CRM eigentlich?" auf das Netz, das ja offensichtlich im Apache irgendetwas anders macht als das ERP.

Viele Grüße
Ulrich

---

Hallo,

ok, an der Stelle muß ich passen, so tief steck ich da in der Entwichlung nicht drin.

kann nur sagen bei mir tut's

Debian squeeze mit kivitendo 3.0.0 und lx-office-crm_1.5.5_4.tgz und apache2

instaliert sind
apache2 2.2.16-6+squeeze11
apache2-mpm-prefork 2.2.16-6+squeeze11
apache2-utils 2.2.16-6+squeeze11
apache2.2-bin 2.2.16-6+squeeze11
apache2.2-common 2.2.16-6+squeeze11

keine Ahnung welche Konstelation da Schwierigkeiten macht. Irgendwas muß sich ja veränder haben wenn's vorher ging! Automatische Updats instaliert ? Welche ?
Geben die logs irgendwelche Anhaltspunkte ?

MfG

---

Hey,
schaue oder poste doch mal das Error-File des Webservers.
Testweise kann auch mal ERP_BASE_URL in inc/conf.php gesetzt werden.
In der neusten git-Version der CRM sind viele Fehler beseitigt und einige nützlich Features hinzugekommen.

Viele Grüße Ronny

---

Herzlichen Dank für Deine Antwort.
ERP_BASE_URL = /var/www/kivitendo habe ich schon ausprobiert - es gibt für das Symptom leider keinen Unterschied.

Die Apache Error-Logs machen genauso viele und die gleichen Meldungen, egal ob ich aus dem Netz, oder aus dem Internet darauf zugreife. Die lange Liste der php-Meldungen muss ich wohl nicht posten. Ich habe beide Fälle schon vorher genau verglichen.
Mir fehlt tatsächlich die Fantasie, dass ich mir einen Unterschied im Apache zum internen Netz und Internet vorstellen kann. Ob Apache nun eine Antwort an 192.168.1.1 (Speedport Router) oder an 192.168.1.100 (Arbeitsplatz) schickt, sollte ja eigentlich egal sein - ist es aus irgendeinem Grunde aber nicht. Ob außer Port 80 noch etwas anderes ist?

Im ersten Thread "crm und Zugriff von extern" vom 29. Januar 13 hat Christian ja viel mehr heraus gefunden, als meine Kenntnisse ausreichen. Allerdings hat er keine Lösung gefunden.

Dann warte ich eben auf eine neue stabile Version.
Schade eigentlich, dass in einer neuen Version ab und zu etwas nicht mehr funktioniert, was vorher tadellos funktioniert hatte.
Viele Grüße Ulrich

---

Also wenn es am Server und am Clientem im internen Netz fuktioniert sollte der Fehler im Router liegen.

Schade eigentlich, dass in einer neuen Version ab und zu etwas nicht mehr funktioniert, was vorher tadellos funktioniert hatte.

Das lässt sich nicht immer vermeiden. Den Fehler einfach melden dann wird er umgehend beseitigt.

---

Hier wird kein Pfad eingetragen: ERP_BASE_URL
sondern wie der Name vermuten lässt eine URL.

Das Problem ist, dass die CRM mit der ERP per JSON kommunizieren muß. Wenn nun ein Proxy zwischen geschaltet wird, stimmen die übergebenen Daten nicht. Hier kommt dann die Variable zum Einsatz

---

Hallo Holgi,
vielen Dank für Dein Kommentar.
ERPBASEURL ist bei mir nicht eingetragen. Wie gesagt, es macht auch keinen Unterschied. Ein Proxy ist auch nirgends installiert.
Früher ging CRM über das Internet problemlos - nun nicht mehr.
Falls Du mehr darüber wissen willst, werde ich alle Deine Anweisungen gerne befolgen und die Ergebnisse mitteilen. Ich könnte auch einen Fernzugang einrichten, falls es etwas hilft.
Vielen Dank für Deine Mühe.

---

Ok, das mit dem Proxy hab ich mir wohl nur eingebildet und dann muß die Variable natürlich leer sein.

Über das I-Net geht die CRM selbstverständlich. Wenn Du möchtest gebe ich Dir einen Link auf eine funktionierende Demo mit das Version 1.5.5. Eine aktuellere Version ohne Xajax, dafür mir JQuery wird kommen. Bitte PN.

---

Habe ERP und CRM (beide aus GIT) auf einen VServer installiert. ERP läuft, bei der CRM nur Dauerwarten. Eine lokale Version (ERP & CRM) funktioniert ohne Probleme, insofern das gleiche Problem. Gibt es schon irgendeine Lösung oder ist bei einer Installation auf einen VServer mit Plesk irgend etwas zu beachten?.
Ansonsten Lob an die Entwickler der CRM. Die aktuelle Version aus GIT hat mächtig gewonnen.

---

Hey Dete,

starte doch den Webserver mal neu und schaue die error.log.
Wenn das nicht hilft poste die error.log des Webservers.

VG Ronny

---

Hallo Ronny,

Neustart hat nichts gebracht. error.log wirft haufenweise Meldungen aus, am besten gebe ich Dir den Zugang zum Server (reine Testumgebung zum austoben!). Anzumerken bleibt nur noch, dass es bis zur Version 1.6 auch auf VServern keine Probleme gab.

VG Dete

---

Falls es eine Lösung gib, wäre ich sehr daran interessiert diese auch kennen zu lernen. Bitte schreibe sie also hier auf.
Ganz herzlichen Dank.
VG
Ulrich