Posts by kungel

    nicht unbedingt.


    rsync kann man so aufrufen, dass er nur auf dem Rechner läuft, auf den er gestartet wurde


    Eine andere Möglichkeit ist, dass der gestartete rsync-Prozeß einen rsync-Dämon auf einen anderen Rechner anspricht, diese beiden sich austauschen und anschließend die Synchronisation startet.
    Ich habe gerade keinen Unix-Rechner im Zugriff, um die man-pages aufzurufen. Sonst könnte ich die passenden Parameter sagen. sorry.

    Wieso fragst du eigentlich immer. Du weißt die Antworten doch schon selber. ;)


    Aber sicher muss irgendwo angegeben werden, was wohin gesichert werden soll.


    Habe hier zufällig keine Synology, um dir haarklein zu sagen wie das geht.
    Wer aber die richtigen Fragen stellt, kann das Problem auch selber lösen.


    Wenn das NAS den rsync-Dämon auf dem Pi nicht erkennt, noch mal alles kontrollieren. Gibt es log-files (z.b. auf dem NAS)? Läuft der Dämon? (ps ax | grep rsync)
    Auf dem Pi: dmesg aufrufen bzw. dmesg | grep rsync
    Was liefert /var/log/messages?

    Wenn du nichts geändert hast sollte auf dem Pi die Datei interfaces so aussehen wie meine:


    Code
    root@rubus:/etc/network# more interfaces
    auto lo
    
    
    iface lo inet loopback
    iface eth0 inet dhcp
    allow-hotplug wlan0
    iface wlan0 inet manual
    wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
    iface default inet dhcp



    Das heißt, der Pi sollte per DHCP alles notwendige bekommen und das auch in "fremden" Netzen.


    Dein nmap läßt nichts Gutes hoffen. Bei mir sieht es so aus:




    Wichtig ist hier der Port 22 für ssh, der bei dir nicht offen ist.


    Ich schätze, ohne Monitor kommst du nicht weit.


    Ansonsten klinke ich mich für heute aus.

    Auch wenn du nach eigener Aussage nicht der Netzwerkcrack bist, hast du doch an der Netzwerkkonfiguration des Pis rumgefummelt. Sofern ich das aus der Aussage, der Pi "kann mittels ddclient sogar seine IP auf einen DNS-Eintrag mappen" richtig schließe. ;)



    Wie sieht denn die Netzkonfiguration aus?

    Ja, dann sollte ein Dämon auf dem Pi laufen.


    Zuerst mal testen, ob es funktioniert.


    In einem Terminal eingeben:



    Quote


    service rsync start


    Damit startet der Dienst.


    Soll es permanent sein.


    Code
    update-rc.d /etc/init.d/rsync defaults

    Natürlich muss man angeben, was man machen will. Woher soll der Pi oder NAS wissen, was zu tun ist.


    Deine Frage ist übrigens missverständlich.


    Wo wird denn rsync angestoßen? Auf dem NAS (Synology kann das) oder du auf dem Pi?
    Wenn es das NAS ist, gibt es zwei Möglichkeiten:
    Die Verzeichnisse auf dem Pi sind von dem NAS erreichbar und rsync läuft nur auf dem NAS.
    Oder NAS spricht auf dem Pi mit einen rsync-Dämon, der natürlich auf dem Pi laufen muss.
    Oder du hast z.B. ein script auf dem Pi laufen, das rsync mit seinen tausend Optionen aufruft.


    Beschreib mal genauer, was du wo machen willst.

    Wenn ein Desktop auf einem Linux-Rechner gestartet ist, geschieht die Kommunikation der grafischen Oberfläche mit dem Betriebssystem über einen X-Server. Er bildet vereinfacht gesagt, eine Zwischenschicht zwischen Desktop und Betriebssystem. Er verwendet dabei grundsätzlich das Netzwerk, auch wenn der Rechner nicht in einem Netzwerk steht.
    Das Geniale an dem X-Protokoll ist seine Netzwerktransparenz: Ein X-Server ist nicht auf den lokalen Rechner angewiesen, man kann mit ihm auf andere Rechner zugreifen und andere Rechner können den lokalen X-Server verwenden.


    Laufen der remote-Rechner und der Lokale mit unixoiden Betriebssystemen, dann sind dadurch zusätzliche Protokolle wie VNC oder RDP überflüssig.


    Zusätzlich bietet X einen weiteren Vorteil:
    Während bei VNC oder RDP erst die Ausgabe erzeugt wird und dann das Ergebnis über das Netzwerk geschickt wird, geschieht das Rendern bei X erst auf dem Zielrechner. Der remote-Rechner wird damit nicht belastet, er muss die grafische Oberfläche lokal nicht gestartet haben.


    Das X-Protokoll hat einen Nachteil, es schickt die Daten unverschlüsselt über das Netz (liegt wohl am Alter des Protokolls). Aber dieses Problem läßt sich lösen.


    Dieses Tuturial beschreibt die Konfiguration des lokalen Rechners und des Pis mit Rasbian und LXDE.


    Drei Arten des Zugriffs werden beschrieben:

    • Öffnen einzelner Fenster bzw. Anwendungen auf dem lokalen Desktop
    • Anzeigen des remote-Desktop mit einen zweiten (oder dritten) lokalen X-Server
    • Anzeigen des remote-Desktops innerhalb eines Fensters (geschachtelter X-Server)


    Öffnen von Fenstern auf dem lokalen Desktop


    Hier gibt es zwei Möglichkeiten.

    • Ich wähle mich mit ssh auf einen remote-Rechner ein und rufe dann ein Programm auf
    • Ich rufe das Programm mit Hilfe von ssh direkt auf.


    Da beides über ssh aufgerufen wird, ist der Netzwerkverkehr auch verschlüsselt.


    1.)
    In einem Terminalfenster führe ich aus:


    Code
    ssh -X username@remote-rechner


    Gegebenenfalls muss ich ein Passwort eingeben und bin anschließend auf dem remote-Rechner. Jetzt kann ich beliebige Programme aufrufen. Sollte das Programm ein eigenes Fenster aufmachen, geschieht dies auf dem lokalen Desktop.


    2.)
    Man muss sich nicht erst auf dem Rechner einwählen und anschließend das Programm aufrufen. Es geht auch direkt:


    Code
    ssh -X username@remote-rechner /pfad/programm-aufruf


    Voraussetzung für beide Arten ist, dass auf dem remote Rechner das X11 forwarding aktiviert
    ist. In der Datei /etc/ssh/sshd_config muss stehen:


    Code
    X11Forwarding yes


    Dies ist die von mir bevorzugte Methode. Da ich meistens nur bestimmte Programme verwende, ist der komplette remote-Desktop überflüssig. Und so habe
    ich auf meinem Desktop ein schönes Durcheinander von lokalen und remote-Anwendungen.


    Empfehlenswert ist übrigens Folgendes nicht:


    Code
    ssh -X username@remote-rechner lxsession


    Dann geht es wirklich durcheinander.



    Anzeigen des des remote-Desktop in einem zweiten X-Server


    Man kann auf seinem Rechner noch weitere X-Server starten.


    Spaßeshalber in einem Terminal mal eingegeben:


    Code
    X :1


    Der Desktop scheint zu verschwinden und der Bildschirm ist schwarz, vielleicht blinkt links oben etwas.
    Mit STRG ALT F7 kommt man zurück zum Desktop. Mit STRG c im Terminal den X-Server wieder beenden.
    Der neu gestartete X-Server kann natürlich nichts anzeigen, da wir ihm nicht gesagt haben, was er anzeigen soll. Machen wir das:


    Vorausgesetzt wir haben einen fertig eingerichten remote Rechner, z.B. einen Pi mit Rasbian und der LXDE-Oberfläche.


    Code
    X :1 -terminate -query user@remote-machine


    Nach einer kurzen Denkpause kann man sich auf dem Pi einloggen.
    Zwischen den X-Servern wechselt man mit STRG ALT Fn. Mal anfangen mit F7 und F2


    Die Option -terminate bewirkt, das der X-Server beendet wird, wenn ich mich
    auf dem Pi abmelde. Ohne diese Option hängt die Einwahl in der Schleife und
    ich kann den X-Server nur von einem lokalen Fenster aus beenden.



    Richten wir den Pi ein (oder einen anderen Rechner mit LXDE)


    Zuerst nehmen wir uns die Datei /etc/lightdm/lightdm.conf vor, denn hier muss stehen:



    Desweiteren muss der Dienst lightdm gestartet sein.
    In einem Terminal als root eingeben:


    Code
    service lightdm start


    Man kann den Dienst auch immer starten lassen.


    Code
    update-rc.d /etc/init.d/lightdm defaults



    Anzeigen des Desktops in einem Fenster


    In der zuvor beschriebenen Methode habe ich den remote-Desktop auf dem ganzen Bildschirm und umschalten muss ich mit STRG ALT Fn. Das ist nicht immer praktisch.
    Und wenn ich einen Monitor mit großer Auflösung habe auch nicht notwendig (was soll der Pi mit 2560x1440 schon machen?).
    Wenn man zwei Monitore betreibt, läuft der X-Server zuerst nur mit der kleineren Auflösung der beiden Monitore und der Desktop ist gespiegelt auf beiden
    Monitoren.
    Natürlich kann man sich jetzt hinsetzen und eine Konfigurationsdatei für den zweiten X-Server erstellen. Dies ist aber aufwändig und imho nicht notwendig. Denn es gibt eine weitere Lösung: den geschachtelten X-Server, mit dem ich einen remote-Desktop in einem Fenster laufen lassen kann.


    Hierfür gibt es zwei Programme: Xnest und Xephyr. Letztere ist der Neuere und die Beschreibung bezieht sich auf ihn.
    Zuerst muss ich Xephyr lokal installieren.


    z.B. Debian


    Code
    apt-get install xserver-xephyr


    z.B. OpenSuse


    Code
    zypper install xorg-x11-server-extra


    Gib es auch für Mac OSX



    Jetzt kann man z.B. folgende Befehle in einem Terminal ausführen (root-Rechte nicht notwendig):


    Code
    Xephyr :1 -screen 1200x1200 -dpi 96 -keybd ephyr,,,,xkblayout=de &
    DISPLAY=:1 ssh -X username@remote-machine lxsession &


    Zunächst erscheint ein Fenster, dass 1200x1200 Pixel groß ist (plus Umrandung und Menüleiste).
    Mit dem zweiten Befehl erscheint in diesem Fenster der Desktop des remote Rechners.


    Der Aufruf von Xephyr sieht erstmal furchtbar aus. Im Einzelnen:


    • Da der laufende X-Server die Nummer :0 hat, muss der Neue die :1 bekommen (der nächste dann :2)
    • -screen 1200x1200 ist selbsterklärend. Es lassen sich beliebige Auflösungen angeben, muss natürlich zum eigenen Monitor passen.
    • -dpi 96 sollte sein, da Xephyr die Monitordaten nicht abfragen kann. Ohne diese Angabe ist u.U. die Schrift zu klein. Ausprobieren, welche Auflösung am besten passt. Sie muss nicht identisch mit der Auflösung des eigenen Monitors sein.
    • -keybd sollte sein, das sonst die Tastaturbelegung englisch ist. Die Mühe herauszubekommen, was die einzelnen Parameter der Option bedeuten, habe ich mir nicht mehr gemacht. Wer Spass daran hat, ...


    Der nächste Befehl ist der Aufruf des Desktop auf dem remote-Rechner:

    • Mit DISPLAY=1 weise ich die Ausgabe des folgenden Befehls den X-Server :1 zu, also den zuvor aufgerufenen Xephyr.
    • Der ssh-Befehl ruft auf dem remote-Rechner das Programm lxsession auf, also den Desktop, der dann im Fenster erscheint.


    Das Ganze ist jetzt auch verschlüsselt, da es über ssh läuft.


    Schön ist auch: Bei dieser Lösung braucht lediglich das X11Forwarding erlaubt sein.
    /etc/lightdm/lightdm.conf muss nicht angepasst werden. Genauso wenig muss der Dienst lightdm laufen.





    Aber aufgepasst!
    Der remote-Desktop läuft in einem Fenster. Schliesse ich es, dann ist auch der Inhalt weg. Pech gehabt, wenn da etwas nicht gespeichert ist.


    Viel Spaß

    Richtig


    Aber schau doch noch mal genau die technische Spezifikation des Pis an, insbesondere die USB/Netzwerkschnittstelle.
    Ist hier im Forum hinreichend diskutiert worden, inklusive Probleme mit den Durchsatzraten ua.


    Für dein Projekt ist der Pi nicht nur Flaschenhals, sondern Nadelöhr.


    Wenn du dir selbst was bauen willst, nimm z.B. dies.


    Oder warte bis Intel die neue Atom-Generation herausgebracht hat. Mit voll nutzbaren Gigabit-Netzwerk und USB 3(!).

    Wenn du schon Geld in die Hand nehmen willst, dann nimm doch gleich ein richtiges NAS von Synology, Qnap, Thecus u.a.
    Dann hast du mehr Leistung, Gigabit und und und.


    Der Pi ist ist viel zu schwach für diese Dimension von Daten. Der Stromverbrauch ist auch kein Argument, da dein Gehäuse mit Platten ja auch reichlich Strom verbraucht.

    Das geht.


    Bei postfix gibt es die Datei /etc/postfix/sender_canonical


    Über sie lassen sich lokale Mail-Adressen auf eine öffentliche Mail-Adresse mappen.
    Postfix leitet die Mails dann entsprechend weiter.

    Sorry, hatte ich vergessen.
    Den Fehler hatte ich auch.


    Ich habe mir einen Standardbenutzer eingerichtet und ihm die Rechte explizit gegeben.
    Über Gruppenmitglieder oder Administratoren ging es nicht.
    Warum wissen nur die Windows-Jünger.


    Edit:
    Damit man diesen Benutzer nicht auf dem Startbildschirm sieht, habe ich ihm das lokale und remote Anmelden verboten. So ist er quasi "unsichtbar"
    und kann nur remote Herunterfahren.

    Ist denn der Windows 7 überhaupt dafür konfiguriert?


    Computerverwaltung - Dienste:


    Den Dienst "Remoteregistrierung" starten.
    Für den ständigen Gebrauch den Starttyp auf "automatisch" setzen.



    Systemsteuerung - Verwaltung - Lokale Sicherheitsrichtlinie - Zuweisen von Benutzerrechten:


    Hier muss der Anwender, der den Rechner remote herunterfahren darf, eingetragen sein in:


    "Erzwingen des Herunterfahrens von einem Remotesystem aus"
    "Herunterfahren des Systems"




    good luck

    Natürlich haben Switche, insbesondere billige, Sicherheitslücken. Aber diese zu verwenden, um nur den Verkehr zu messen? Das geht doch weit über das hinaus, was der TE wollte.


    Ansonsten picke ich nicht einzelne Wörte heraus und ignoriere den Rest! Ich habe nur den Teil zitiert, der mir besonders negativ aufgefallen ist. Ich mag nicht den ganzen Post zitieren, ist imho eh eine Unsitte.


    Im Post #17 bestätige ich dich nicht. Im Post #16 bestreitest du den Sinn von Freetz, weil man nicht an einem Switch hören kann. Ich schreibe aber, das man auf der Fritzbox auf dem WAN-Port hören kann und Freetz damit Sinn macht. DAS ist der gewaltige Unterschied.


    Und: der inflationäre Gebrauch von "Gefällt mir" nervt mich sowieso. Diese Sanktion greift nicht.

    Beim vorletzten Satz muss ich leicht wiedersprechen - das eine hat mit dem anderen nichts zu tun..
    Mithören geht auch mit billigen Switches bzw hat das mit dieser Sachlage nichts zu tun, denn sonst würde es ja kein Sinn machen Freetz o.ä. zu installieren um den Traffic aufzuzeichnen :-/


    Bei Routern ist die Sachlage anders als bei nackten Switches - sicherlich hat auch eine Fritzbox nen Switch verbaut, aber dennoch sorgt eine abgespeckte Linux Software dafür zu sagen "das Datenpaket kommt da hin und dieses schick ich hier hin oder jenes wird ignoriert"



    Falsch!


    An billigen Switchen kann man nicht mithören! Bitte bei Wikipedia z.B. nachlesen. Dies geht nur mit einem Hub, der die eigentliche Bus-Topologie des Ethernet auf eine Stern-Topologie abbildet. Ein Switch macht das eigentlich auch, aber er schickt die Daten nicht an alle Ports, sondern nur an die Ports, die Ziel oder Quelle sind. An anderen Ports sieht man daher diesen Verkehr nicht.


    Freetz auf dem dem Router zu installieren macht Sinn, da hier der WAN-Port abgehört werden kann, über den der gesamte Internet -Verkehr läuft.
    Ob hier auch der interne Verkehr gemessen werden kann, der nur über den eingebauten Switch läuft, weiß ich nicht.


    Dazu muß man den Verkehr über einen dafür eingerichteten Rechner laufen lassen. Der pi bietet sich hier nicht an, da er nur Fastethernet kann

    Wenn man den Netzwerkverkehr messen will, kommt man nicht umhin, ihn über ein spezielles Gerät laufen zu lassen.
    Natürlich bietet sich der hier der Router an, über den der Internetverkehr ohnehin geht.


    Viele Router bieten hier was an, aber vielleicht nicht genau genug.


    Wer es genauer haben will, kann auf einer Fritzbox freetz installieren und entsprechende Tools laufen lassen. Mit dem Nachteil, dass man dann keinen Support von AVM bei Problemen hat.


    Will man das nicht, muss man den Verkehr komplett über z.B. den Pi laufen lassen.
    Einfach den Verkehr mithören geht nicht, da heutzutage Switche verwendet werden. Mithören geht nur bei Hubs, aber die hat ja kaum noch einer und für Gigabit gibt es die m.W. nicht. Oder man verwendet professionelle und entsprechend teure Switche. Aber wer hat die schon zuhause.