Beiträge von b3nn0

    Um mal eine etwas andere Meinung zu vertreten:
    Eine GUI auf Servern ist keineswegs unüblich. Als Freelancer im IT Bereich sehe ich viele Firmen von innen. Und bei einem Großteil dieser Firmen läuft auch auf Linux Servern eine Desktop Umgebung.
    Man muss es nur richtig machen, dann ist das sicherheitstechnisch absolut kein Problem. Ich empfehle hier nicht zusätzliche Dienste wie einen VNC Server zu installieren, sondern das komplett über SSH zu machen.
    Im wesentlichen gibt es da zwei sehr brauchbare Server:
    Nomachine NX oder das freie (und meiner Meinung nach inzwischen bessere) X2go. Verbindungen damit sind schnell, gehen ausschließlich über SSH und sind daher verschlüsselt und bringen keine öffentlichen Dienste (jedenfalls bei X2go ist das so. Bei NX soweit ich weiß ebenfalls, bin mir da aber nicht 100% sicher).
    Außerdem hast du (fast) keinen zusätzlichen Ressourcenverbrauch dadurch. Die GUI Startet hier nicht beim Systemstart, sondern wenn du dich anmeldest wird explizit für dich eine Session mit eigenem X-Server gestartet. Ist also eher vergleichbar mit dem Microsoft Terminal Server Prinzip. Nur eben, dass keine GUI beim Systemstart gestartet wird.



    Und zum Thema warum das ganze?:
    Wenn man produktiv auf dem Server arbeitet, hat man gut und gerne mal 3-5 SSH Sessions auf. Das kann gelegentlich unübersichtlich werden. Wenn man mehrere Server verwaltet werden aus diesen 3-5 auch gerne mal 10 - 15. Hier verliert man den Überblick sehr schnell. Wenn man nun einfach für jeden dieser Server eine X2go Session hat, sind diese vielen Terminalfenster schön gruppiert. Und man kann über einen Klick neue Sessions auf dem entsprechenden Server starten und muss nicht jedes mal eine neue Session aufmachen, was mit mehreren Klicks und/oder passphrase Eingabe verbunden ist.
    So eine X2go Session kann also enorm Effizienz steigernd sein.
    Auch lassen sich mit X2go sessions "einfrieren", so dass ich am nächsten Tag einfach in meine alte Session mit all den offenen Terminals zurück kehren kann. Es gibt natürlich auch tools wie "screen", die das ohne X erlauben. Effizient ist das aber nur bedingt.

    Hallo, ich denke das ist das Problem, ich habe die ausgabe mal nicht nach /dev/null sondern in eine Debug-Datei umgeleitet und darin steht:
    2014/06/11 10:24:44 socat[21526] E bind(3, {AF=2 ***.***.***.***:81}, 16): Permission denied


    muss ich mal schauen ob und wie ich dem Benutzer www-data rechte geben kann.

    Ah, das wird wohl daran liegen, dass du versuchst einen Port < 1024 zu forwarden. Unter Unix-Systemen ist dies generell nur root erlaubt. Andere nutzer dürfen nur Dienste, die auf Ports >1024 lauschen, verwenden.
    Sowas lässt sich wohl auf verschiedene Arten lösen. Vermutlich ist es am einfachsten/sichersten, wenn man socat einfach das binden sämtlicher Ports erlaubt:
    networking - Linux: allowing an user to listen to a port below 1024 - Unix & Linux Stack Exchange
    setcap 'cap_net_bind_service=+ep' /usr/bin/socat

    Hallo,
    Leider kenne ich mit mit Nginx nicht wirklich aus. Bei mir läuft das Script unter apache und funktioniert.
    Steht ggf. in deinem Webserver-Logfile eine Fehlerausgabe von PHP, die Aufklärung schaffen könnte? Sind die permissions korrekt gesetzt, so, dass das Script die entsprechenden Dateien auch schreiben kann? Gibt es eine rules.txt und pids.txt, die entsprechende Infos enthalten?


    Möglicherweise ist aber Nginx per default auch einfach restriktiver als apache. Kann ich leider nicht sagen. Da hilft dann vermutlich google weiter.

    Socat ist das richtige Stichwort. Sowas in dieser Art hier verwende ich um das Selbe zu erreichen:
    socat TCP-LISTEN:8088,fork,bind=<ipv4-addr-des-servers> TCP:<ipv6-addr-des-ziels>:8088


    Ich habe auch mal in ein paar freien Minuten ein kleines Webinterface (PHP) gebastelt, mit dem sich komfortabel solche Weiterleitungen einrichten lassen und verwaltet werden können, es findet sich hier:
    [PHP] <!DOCTYPE html> <html> <head><title>Router</title></head> <body> <?php co - Pastebin.com


    Das Script einfach in ein Verzeichnis auf dem Web-root werfen und chmod +rwx setzen. Die Einstellungen werden in eine Datei rules.txt im selben Verzeichnis gespeichert.
    Außerdem wird eine Datei pids.txt geschrieben, in der die Prozess-IDs der socat Prozesse stehen, um diese zu verwalten.


    Achtung: Die Tunnel existieren damit natürlich nur bis zum nächsten Server-reboot. Durch erneuten Klick auf den Submit-Button im Interface werden sie dann wieder gestartet.