Posts by ThomasL

    Da fehlt aber noch was, ... nach dem Ausschalten, den PI runterfahren.

    Nein, warum? Was ist an der WLAN-Verbindung (technisch) anders, als bei einem Laptop, den man unterwegs willkürlich verbindet oder abmeldet... den schalte ich doch auch nicht ab, nur weil ich das WLAN getrennt habe. Und wenn man ausserhalb der User-Fenster kein WLAN braucht, der Pi aber noch andere Dienste erfüllt, was spricht dagegen, WLAN zu deaktivieren, ihn aber trotzdem einfach laufen zu lassen.

    Machs einfach vollständig, dann klappts auch:


    Ausschalten:

    Code
    /sbin/ip link set dev wlan0 down
    /sbin/dhclient -r wlan0
    /usr/bin/pkill -f DG8BR_AP.conf


    Einschalten:

    Code
    /sbin/ip link set dev wlan0 up
    /sbin/wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/DG8BR_AP.conf
    /sbin/dhclient wlan0

    Pfad und Name der wpa-conf anpassen.

    Ja, das geht, kein Problem.... dann muss Du Dich allerdings auch mit den Basics befassen..... anders gehts nicht. Guckstu:

    https://wiki.ubuntuusers.de/mount/

    https://jankarres.de/2013/11/r…amba-server-installieren/

    https://blog.jonaspasche.com/2…ehen-samba-rechtevergabe/

    https://wiki.ubuntuusers.de/Samba_Server/


    Und wenn Du beim Googlen auf englische Texte stößt, ist das die Lösung:

    https://www.deepl.com/translator


    Und das wichtigste am Schluss:

    Wie Frage ich nach Hilfe?

    hat jemand eine idee?

    Ja, vermutlich schreibst Du die Daten auf den leeren Mountpoint. Der Samba-Share verwendet zwar das Verzeichnis, was Du als Mountpoint siehtst, aber aus Sicht von Samba ist das erst mal nur ein Verzeichnis... soll heissen, Samba ist es egal, ob das ein Verzeichnis oder ein echter Mountpoint ist.


    Die Lösung ist einfach... bei der unbedingt die Reihenfolge einzuhalten ist:

    1. auf dem Server den USB-Stick einstecken und auf den entsprechenden Mountpoint mounten

    2. die Samba-Freigabe starten (Samba restarten)

    3. auf dem Client die Samba-Freigabe mounten.


    Wenn ein USB-Stick nachträglich eingesteckt wird, bezieht sich die Samba-Freigabe nur auf das Verzeichnis, welches erst mit dem eingesteckten USB-Stick ein Mountpoint wird. Aber... und das ist die Falle... Verzeichnis und Mountpoint sind zwei unterschiedliche Objekte... und wenn Samba einmal das Verzeichnis hat, bleib es dabei, weil das Verzeichnis dann als Mountpoint zu einem neuen Objekt wird. In diesem ist die Lösung zwar unbequem, aber einfach: Samba stoppen und anschließend erneut starten. Oder den Stick immer "drin" lassen.

    Aber wofür braucht man nun wirklich schnelleres Lan. Als Cloud oder NAS. Aber das sollte man ja um die SD zu schonen auf ein externes Medium auslagern, also z.B. eine Festplatte. Welche aber wiederum am USB2 hängt. Also ich finde das jetzt nicht die Bomben Neuerung.

    Ich sehe das ähnlich...und zumindest diese Neuerung ist für mich auch nur wieder solche Werbung wie "Neue und verbesserte Rezeptur in neuen moderneren Karton der ... es schmeckt viel besser als zuvor". Irgendwie bewerte ich das als stagnierende Innovation ... neu verkaufen , ohne wirklich was verändert zu haben.


    Ein richtiger Kracher-Fortschritt wäre mal 2GB RAM und jeweils eigene Controller für SATA, USB und ETH. Dafür dann ohne WLAN und fertig wäre ein billiges NAS mit geringst möglichen Betriebskosten und voll ausreichender Leistungsfähigkeit. Da würde ich sofort 2 mal zuschlagen.


    Jm2c

    Ich habe imho sehr "harte", aber ich denke, auch sehr unkomplizierte Regeln, völlig ohne Schnörkel... knallhart alles fliegt raus... *fg*.. meine Regeln zielen mehr auf die Kontrolle des Clients ab, und weniger auf Attacken von außen... was Aufgabe des Routers ist... entsprechend meiner Meinung, dass die Kompromittierung immer von innen heraus erfolgt oder ermöglicht wird.

    Da sind nur ne Handvoll expliziter Ports als einzige Ausnahmen erlaubt. Der Policy-DROP sollte eigentlich wg. dem letzten REJECT gar nicht greifen. Alles, was nicht related oder established ist, und auchg nicht als Port erlaubt ist, fliegt raus. Mit anderen Worten, es ist alles verboten, was nicht ausdrücklich erlaubt ist. Ich prüfe nicht mal auf NEW ab, ich verbiete einfach alles... und bei den Ports, die ich erlaube, ist es mir egal, ob NEW oder nicht NEW.


    Die INPUT-Rules sind prinzipiell genauso aufgebaut, aber noch weniger geöffnete Ports.... alles ist verboten... nur sehr wenige Ports sind erlaubt.... ebenfalls völlig schnörkellos.

    Nein, so wie bei FTP muss das nicht sein. Die Verbindungen werden nur vom Client initiiert und vom Server kommt keine NEW-Verbindung.

    Merkwürdig.... related und established ist IN und OUT und FORW erlaubt. Damit funktioniert es sofort:

    iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m conntrack --ctstate NEW -j ACCEPT

    Dukriegs kein Mecker und wens erledigt ist können wirs auch nicht mehr kaputt machen... *lol*


    rpi444, das war die Ursache, related Ports... also kann ich das mit meinem Paketfilter nicht nutzen, weil ich das Öffnen der unprivilegierten Ports >1024 ausschließe. Sachen gibts.... :conf:

    Hast Du in der INPUT chain, die RELATED/ESTABLISHED-Verbindungen evtl. auch blockiert?

    Das ist die große Frage.... ich habe das mittlerweile auch festgestellt, dass anscheinend related Ports geöffnet werden. Und wenn das im übertragenen Sinne auch so sein muss, wie das früher bei FTP war, dass Ports >1024 mit NEW accept sein müssen, dann funktioniert das bei mir natürlich nicht....


    Speziell für FTP ist das bei mir heute über das Application-Layer-Gateway geregelt, weswegen diese Regel nicht enthalten ist... ich probiere das mal

    80 und 443 sind offen... und es macht keinen Unterschied, ob ich die 666* Ports öffne oder nicht ... sobald ich den Paketfilter aktiviere, kommt diese Socket-Fehlermeldung bei der Anmeldung und die Anmeldung failed. Flush ich den Paketfilter, dann gehts. Das ist merkwürdig...

    Testweise habe ich die Öffnung noch mal rausgenommen, um zu sehen, dass das mit Iptables tatsächlich einen Unterschied macht. Dann ist die Antwort:

    Code
    # nc -zv irc.cob.de.euirc.net 6667
    irc.cob.de.euirc.net [185.134.45.106] 6667 (ircd) : No route to host
    # nc -zv irc.cob.de.euirc.net 6697
    irc.cob.de.euirc.net [185.134.45.106] 6697 (ircs-u) : No route to host

    Mit ACCEPT diese Ports oder ohne Paketfilt ist die Antwort "open"

    Ja, sind beide erreichbar, und dennoch bleibt die Meldung.

    Code
    # nc -zv irc.cob.de.euirc.net 6697
    irc.cob.de.euirc.net [185.134.45.106] 6697 (ircs-u) open
    # nc -zv irc.cob.de.euirc.net 6667
    irc.cob.de.euirc.net [185.134.45.106] 6667 (ircd) open

    ich möchte von meinem Raspberry Pi gerne einmal Täglich + Wöchentlich Backups machen.

    Ich würde gerne ein volles Image der SD karte ziehen und auf mein NAS legen.

    Ich möchte mich llutz anschließen und ebenfalls anmerken, dass das auch meiner Meinung nach kein wirklich sinnvoller Weg ist. Die Nutzerdaten zu sichern steht ausser Frage, dass muss man bestmöglich tun. Aber mit dem Image des Betriebssystem sicherst Du hundertausende von Dateien, die bei einer Neuinstallation automatisch einfach wieder da sind... die man also quasi gar nicht verlieren kann.


    Ich würde -wie llutz vorgeschlagen hat- auch nur Einstellungsdateien, Konfigurationen und Infos zu Paketen sichern. Das kann man inkrementell oder versioniert machen... bei der Größe von nur 1/2 MB (< 500k) ist das wirklich egal. Mein letztes OS-Server-Backup ist exakt 484 KB groß.