Beiträge von janxb

    Seit einigen Jahren fahre ich mit dem "Inbox Zero" Konzept ganz gut. Zusammenfassung:

    - Alle Mails im Posteingang sind noch zu bearbeiten oder warten auf Antwort

    - Sobald eine Mail abgeschlossen ist, wird sie archiviert

    - Ziel ist die sogenannte "Inbox Zero", d.h. keine Mails im Posteingang.

    - Es gibt (zumindest bei mir) keine Unterordner, man verlässt sich auf einen leistungsstarken Filter (Gmail z.B.)


    Privat schwanke ich zwischen 0 - 10 Emails in Bearbeitung, im Job liege ich meist bei 5 - 20. Leider habe ich auf der Arbeit die Null noch nie geschafft.. ;)

    Ich kann die 4mbit mit speedtest-cli nachvollziehen, mit einem anderen Tool allerdings nicht. Mit wget bekomme ich ca 800mbit (gemonitored mit ifperf).

    Scheint mir also ein Problem mit dem erstgenannten Tool zu sein.

    Code
    wget --post-file=1Gio.dat http://ov-h.net/files/ -O /dev/null

    burgvogt / eripek

    Meiner Meinung nach (ohne es mit einem Webhosting getestet zu haben) sollte auch das Verwenden eines Aliases weiterhin möglich sein. Dabei ist zu beachten, dass es einen Unterschied zwischen SMTP From und Envelope From gibt. Du kannst in deinem Mailprogramm einen anderen Absender anlegen, solange du dich weiterhin mit dem korrekten (existierenden) Account beim SMTP Server authentifizierst. So funktioniert das zumindest bei meiner Mailcow ohne Probleme. SMTP From ist dann dein Account, Envelope From wird der neu angelegte Absender. Angezeigt beim Empfänger wird meinst Envelope From.

    Warum sollte jemand eine Anleitung von infosec-handbook.eu durcharbeiten und dann zufällig ins netcup Forum gehen, um dort mit nichts Konkretem rumzupöbeln? ^^

    Weil er ein Neukunde ist, der im Forum die Anleitung gefunden hat. Nachdem er sich nach Abarbeitung des Dokuments ausgesperrt hat, möchte er nun an allen Stellen, wo ebenjenes erwähnt wird, seinem Ärger Luft machen. Doppelpostings finde ich suboptimal, allerdings muss man ihn ohne konkrete Hinweise auch nicht sofort als "Troll" darstellen.

    [..] 2FA-Secret mit allen zu teilen, und jedes mal wenn jemand die Firma verlässt, das Passwort zu ändern.

    Ein Improvement wäre hier, wenn man mehrere Secrets erstellen könnte. Wenn dann ein Mitarbeiter das Unternehmen verlässt, kannst du sein Secret löschen. Aber die korrekte Lösung ist das vermutlich nicht..

    Wenn du aber aus dem Container alle Snapshots löscht bevor du das Image erstellst, sollte diese Abhängigkeit auf Host B doch auch nicht mehr gegeben sein.

    Der Container enthält keine Snapshots.


    Du erstellt ein Image des (nackten) Containers auf Host A. Dieses Image exportierst du und importierst es auf Host B. Weiterhin gilt: Es sind keine Snapshots im Spiel. Jetzt löschst du das Image auf Host B. In der GUI ist es verschwunden, auf der Platte existiert das ZFS Volume aber weiterhin, da es ein von ihm abhängiges Volume (den neu erstellen Container) gibt. Das ist kein Bug, sondern die Arbeitsweise von ZFS.

    Was nutzt ihr für Fahrradtachos?

    Bin schon seit Jahren sehr zufrieden mit meiner Mi-Fit App in Verbindung mit dem Mi Band 3 (zuvor Mi Band 2). Erfasst alles an Kennzahlen, was ich benötige. Habe ich allerdings in der Gepäckträgertasche, schaue ich also während der Fahrt nicht drauf. Xiaomi hat in den letzten Monaten wirklich viele gute Updates in die App und auf das Band gebracht!


    Ansonsten zum Thema: Früher bin ich wirklich viel gefahren, min. 200km in der Woche. Meistens jeden Nachmittag die gleiche Strecke und ohne großen Genuss-Faktor. Nach einigen Jahren Pause läuft's jetzt wieder so langsam an, wo das Wetter bei mir endlich wieder wärmer und trockener geworden ist.. ;)

    pgloor


    Das von dir beschriebene Szenario ist ein anderes, als mein Beispiel.


    1. Image eines Container von Host A erstellen und dieses anschließend exportieren.

    2. Image in Host B importieren und davon einen neuen Container erstellen

    3. Image kann auf Host B jetzt nicht mehr gelöscht werden, da ein abhängiger Container existiert.


    Hinweis: Snapshots und Images sind verschiedene Dinge. Außerdem eine Einschränkung bei ZFS: Restores sind immer nur vom letzten Snapshot möglich. Um von einem älteren Snapshot wiederherzustellen, müssen alle neueren gelöscht werden. So zumindest laut LXD Doku.


    Edit: Ergänzung / Klarstellung: Natürlich kannst du das Image im Frontend von LXD löschen. Physikalisch auf der Platte bleiben die Daten allerdings noch vorhanden und belegen Speicherplatz.

    Ich benutze seit längerer Zeit und auf mehreren Systemen LXD mit ZFS

    Zumindest früher gab es bei LXD + ZFS die Einschränkung, dass ein Snapshot/Image solange weiter existieren muss. wie ein Container daraus erstellt wurde. Beispiel: Ich exportiere einen Container auf Host A und importiere ihn als Image in Host B. Das Image kann ich jetzt aber nicht löschen, da noch ein Container darauf referenziert. Diese Einschränkung gibt es bei BTRFS nicht, daher bin ich vor einiger Zeit umgestiegen.

    Habe die

    Zum selbst probieren: [..]

    Bei mir kommen die IPv4 Pakete beim Empfänger an, mit IPv6 erhalte ich beim Versender bereits einen connection timeout. Pingbar ist der Empfänger über IPv6 aber. Sieht irgendwie schon komisch aus, dass ich sowohl bei IPv4 als auch IPv6 einen Fehler angezeigt bekomme, aber IPv4 trotzdem durchgeht.

    Code
    root@blueberry:~# ncat --sctp -4 nc1.host.xxxxxxx.com 80
    Ncat: Protocol not available.                                                                                                                                             
    root@blueberry:~# ncat --sctp -6 nc1.host.xxxxxxx.com 80
    Ncat: Connection timed out.                                                                                                                                               
    root@blueberry:~# ping6 nc1.host.xxxxxxx.com                                                                                                                         
    PING nc1.host.xxxxxxx.com(nc1.host.xxxxxxx.com (2a03:xxxxxxx::1)) 56 data bytes                                                                             
    64 bytes from nc1.host.xxxxxxx.com (2a03:xxxxxxx::1): icmp_seq=1 ttl=63 time=0.360 ms                                                                            
    64 bytes from nc1.host.xxxxxxx.com (2a03:xxxxxxx::1): icmp_seq=2 ttl=63 time=0.389 ms

    Ich habe LXD auf mehreren Maschinen im Einsatz. Dabei nutze ich BTRFS mit loop-backed storage. Das ist laut LXD Docs nicht für den Produktiveinsatz geeignet, läuft bei uns aber problemlos. Alternativ kannst du natürlich auch eine eigene Partition einrichten. Vorteil: BTRFS kann (im Gegensatz zu ZFS) getrimmt werden, sodass im SCP die korrekte Festplattenbelegung angezeigt wird. Die Performance ist auf allen Storage-Technologien (HDD, Optane, SSD) ausreichend schnell, wobei HDD etwas langsamer ist. Zwischen Optane und SSD gibt es (gefühlt) keinen Unterschied in der alltäglichen Geschwindigkeit.


    Für Backups mache ich einen Offline-Snapshot der Container und exportiere diesen dann als Image auf den netcup Storage: https://github.com/janxb/ServerUtils/blob/master/lxd-backup

    jetzt mal ernst, welche Datenmenge¹ hat jeder, welche er um 'jeden Preis' vor Diebstahl, Feuer, ... bewahren will

    Anscheinend bin ich hier die Ausnahme, denn: Alle wichtigen Daten von mir liegen im Google Drive, das sind mittlerweile ca 20 GB (nein, ich habe keine Null vergessen.. ;) ). In diesen Daten sind Fotos schon mit einberechnet, die speichere ich in Originalgröße bei Google Fotos. Vielleicht habe ich allerdings auch bis jetzt einfach nur so wenig erlebt, an was es sich zu erinnern lohnt.. :P

    Es gibt verschiedene Abuse-Kulturen bei den Hosting-Anbietern. Anscheinend geht netcup hier relativ strikt vor, was die vollständige Blockierung der Maschine angeht. Das hat den Vorteil, dass so die gesamte, restliche Infrastruktur geschützt wird. Solltest du auf dem Node noch weitere Dienste von dir hosten, so ist das nicht empfehlenswert. Wie weiter oben schon gesagt, kann es immer vorkommen, dass ein Exit-Node für mehrere Stunden gesperrt wird.


    Um noch mal einen anderen Hoster aufzuführen: Dort wird eine Abuse-Meldung versendet, der Node allerdings noch nicht gesperrt. Das passiert erst, nachdem auch nach mehreren Stunden noch nicht auf die Meldung geantwortet wurde. Ist für uns als Serverbetreiber natürlich eine komfortablere Situation.


    Fazit: Sperrung der Maschine ist aus Sicht des Anbieters vollkommen korrekt, für dich jedoch nervig. Entweder du musst dich damit abfinden, oder für Exit-Nodes einen anderen Hoster auswählen.

    Es gehört sich für einen Exit-Node Betreiber eigentlich nicht, den darüber laufenden Traffic in irgendeiner Form zu filtern. Das widerspricht den Grundsätzen des Tor-Netzwerkes. Ich habe für meine damaligen Exit-Nodes das unten stehende Template für Antworten auf Abuse-Meldungen verwendet, zumindest bei He**ner viele Male ohne Probleme.


    Zusätzlich fand ich es angemessen, den ausgehenden Traffic auf die im Web verwendeten Ports zu beschränken, also HTTP, HTTPS und DNS. Dadurch lassen sich viele Dienste erreichen, du sperrst allerdings unkonventionelle Services wie z.B. Torrents aus.

    steht doch auf der Hauptseite dabei:

    Daraus, dass mindestens zwei User diesen Hinweis nicht gesehen haben, könnte man jedoch schließen, dass er eventuell prominenter platziert werden sollte. Beispielsweise innerhalb der jeweiligen Produktdetailseite.