Tag Archives: geht nicht

Linux – wenn ssh nicht portforwarden will

Posted on by

Wenn SSH Euren Port trotz richtiger Angabe der Parameter nicht forwarden will, könntet Ihr Opfer des Fortschritts geworden sein.

Das Problem

Der Befehl :

ssh -g -R *:24007:192.168.178.1:24007 root@remoteserver.de

sagt dem entfernen Server normalerweise, daß der Remote-Server einen Port 24007 für alle zugänglich auf 0.0.0.0 binden soll und alles was reinkommt, soll an die lokale IP 192.168.178.1 Port 24007 weitergeleitet werden.

Wenn das aber immer im Netstat auf 127.0.0.1 angezeigt wird:

tcp 0 0 127.0.0.1:24007 0.0.0.0:* LISTEN 13927/sshd: root@pt….

dann ist Eure SSHD-Config zu alt 🙂 Vor einigen Jahren wurde eine neue Option eingeführt, so daß der SSHD zwingend konfiguriert sein muß, globale Ports binden zu können.

Die Lösung

Fügt in die /etc/ssh/sshd_config  die folgende Zeile ein und startet den Dienst neu:

GatewayPorts yes

Damit darf der SSHD das wieder für Euch erledigen und die Tunnelwelt funktioniert für Euch wieder.

Das könnte auch interessant sein:

SSH VPN mit den iproute2 Tools
UDP Traffic per SSH tunneln
TAR erfolgreich per SSH tunneln

Tomcat: Manager App nicht verfügbar

Posted on by

Kleine Ursache, großes Tralala

Einer meiner Tomcats hat mich heute mit der Meldung beglückt, daß er die Resource „/manager/html“ nicht zur Verfügung stellen könne, obwohl die Anwendung installiert ist. Das ist ist immer, da diese zum Defaultzustand eines Tomcats dazugehört. Darüber lassen sich Webanwendungen als WAR File installieren.

Jetzt findet man im Netz alle erdenklichen Ansätze, leider half heute nicht einer.

Das erste was auffiel war, daß das Manager Verzeichnis zwar da war, aber die anderen normalen Verzeichnisse im webapps Verzeichnis  nicht:

drwxr-xr-x  5 root root     4096 13. Aug 2013  host-manager
drwxr-xr-x  5 root root     4096 13. Aug 2013  manager
drwxr-xr-x  3 root root     4096 18. Feb 2012  plattform
drwxr-xr-x  3 root root     4096 13. Aug 2013  ROOT

Wenn das nicht der Fall ist, kann es gehen, muß aber nicht. Diese holt man sich aus dem Tomcat ZIP/TGZ File. Wenn man dies nicht mehr zur Hand hat, einfach nochmal von der Webseite runterladen.

Die eigentliche Störungsquelle

Damit habe ich dann nicht gerechnet. Die eigentliche Störungsquelle war trivialer Natur. Die früher installierte Webanwendung war defekt und verhinderte den korrekten Start des Tomcats, obwohl im Logfile dazu kein Hinweis stand! Mit sowas rechnet man nicht, daß bis dato die Webanwendung lief.

In dem Fall einfach von Hand die alte WAR Datei aus dem Webapps Verzeichnis entfernen und den Tomcat neustarten.

Danach war auch der Manager wieder erreichbar.