Beiträge von m_ueberall

    Nee, ich komme schon noch aus Deutschland. Thüringen. ;)

    Externer Inhalt youtu.be
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    Ich fände die Möglichkeit, per EFI booten zu können, ebenfalls ein nützliches Feature und würde mich freuen, wenn es umsetzbar ist. Schön dass daran bereits gearbeitet wird! :thumbup:

    Darüberhinaus würde ich mich freuen, wenn dieses Feature in einer Testphase vorab in der nclabs-Umgebung zur Verfügung stünde, um ggf. Rückmeldungen zu beschleunigen…

    [...] Bei der Mozilla Intermediate Config steht dieser nämlich auch auf off, nur bei der old Config ist dieser auf on. [...]

    Fürs Protokoll: Mit dem "off" (nutze ich derzeit auch selbst) hat es folgende Bewandtnis:

    Modern TLS configuration: Let clients choose the cipher suite again.

    Why? Because all modern cipher suites (which support AEAD and PFS) are considered "secure" at the moment. This means that [there] isn't a risk of downgrade attacks to insecure legacy cipher suites like before. Besides, clients without AES hardware acceleration can use smaller key sizes and/or EC-based cipher suites. [...]

    (Wenn man das übernimmt, sollte man natürlich entsprechende Änderungen/neue Erkenntnisse im Auge behalten…)

    [...] allerdings bekomme ich immer einer Parsing Error von Wireguard, wenn ich "Postup" in der conf habe - seltsam.

    Vielleicht einmal die o.g. Zeilen direkt hineinkopieren (Groß-/Kleinschreibung spielt bei meiner Wireguard-Version keine Rolle) und sicherstellen, dass eine aktuelle Version installiert ist (für ältere Debian-/Ubuntu-Distributionen sind Dritt-Repositories upstream verfügbar)?

    Code
    # dpkg --list wireguard | grep "^ii"
    ii  wireguard      1.0.20200206-0ppa1~16.04 all          fast, modern, secure kernel VPN tunnel (metapackage)

    Zwei zusätzliche Anmerkungen:

    1. Um die Default-Route auf Client-Seite kümmert sich beispielsweise die Android-Wireguard-App.
    2. Auf Serverseite lässt sich die vorgenannte Einstellung "net.ipv4.ip_forward = 1" in einer Datei unter /etc/sysctl.d/ unterbringen (bei Systemstart ausgeführt, d.h. im laufenden Betrieb wie von H6G beschrieben zunächst von Hand durchführen) und die iptables-Einträge lassen sich direkt über die Konfigurationsdatei (/etc/wireguard/wg0.conf o.ä.) verwalten; im Nachfolgenden ist "ens3" ggf. durch "eth0" zu ersetzen:
    Code: /etc/wireguard/wg0.conf
    [Interface]
    Address = 192.168.123.1/24
    SaveConfig = false
    #NB: Do specify all required interfaces ("-o interface") here
    PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
    #[...]

    Ich denke, jeder sollte sich mal vor Augen führen, wie viele Abusemeldungen netcup versendet bei der Kundenzahl. Da sind die Beschwerden zu dem Thema hier im Forum wirklich selten.

    Sofern die Anzahl der Meldungen hoch genug ist, spricht das aber eher dafür, dass ein semi-automatisches Matching mit vom Kunden gemieteten Ressourcen stattfinden und keine – manuell adressierte – Mail verschickt werden sollte, bevor sich ein expliziter Treffer (Domänenname, IP-Adresse) findet.

    Wie an anderer Stelle ausgeführt: Ja, Fehler passieren, aber dem Image des Hosters ist das angesichts eines öffentlichen Forums auch bei wenigen Vorfällen dieser Art nicht zuträglich (insbesondere, wenn es Mitbewerber schaffen, sich diesbezüglich zumindest bedeckt zu halten), auch wenn Offenheit andererseits durchaus positiv zu bewerten ist. Die Kalkulation eines Gewerbetreibenden, insbesondere, wenn er die Fallbearbeitung an Angestellte/Dritte delegiert, kann hier im Vorfeld zur Abschreckung führen.

    Unabhängig davon kann man IMHO davon ausgehen, dass wirklich die wenigsten Kunden im Kundenforum Abuse-Meldungen diskutieren.

    Ich habe aber weder ein Webhosting bei Netcup, noch ein Wordpress und [Zum Schutz persönlicher Daten von der Foren-Moderation entfernt] hab ich noch nie gehört....
    […] Die Domain [Zum Schutz persönlicher Daten von der Foren-Moderation entfernt] löst auch nicht auf eine meiner IPs auf.

    Sofern die Abuse-Nachricht weder eine gebuchte Domäne noch eine zugewiesene IP-Adresse enthält, würde ich umgehend den Support kontaktieren, um nachzufragen, ob hier ggf. eine Verwechslung vorliegt. Wenn nicht, sollte der Support direkt aufzeigen können, welche vertraglich gemietete/*dokumentierte* Ressource hier involviert war, welche unter die Verantwortung des Kunden fällt.

    Kommerzieller Storage mit ZFS und Deduplizierung: https://www.computerbase.de/2020-02/es2486…ll-flash-arrays . Wie sind die nur an eine praktible Lizenz für ZFS gekommen? :/

    Das ist kein Hexenwerk (Hervorhebung von mir; schon länger der Standardansatz bei einschlägigen Angeboten):

    […] Das Betriebssystem QES (QNAP Enterprise Storage) basiert auf dem einfachen und effizienten FreeBSD Kernel und dem ZFS Dateisystem […]

    PS: Die neuen ACL-Einträge oben beziehen sich auf existierende Dateien/Verzeichnisse. Eine Vererbung der Zugriffsrechte auf neue Dateien/Verzeichnisse kann nur über das "sticky bit" erfolgen. Sofern erforderlich, muss man Änderungen (lies: Erstellung neuer Dateien/Unterverzeichnisse) beobachten, etwa mittels inotifywait ...

    Wie funktioniert das mit den ACLs? Apache vHost Konfigurationen können sich schlecht über die Berechtigungen des Dateisystems hinwegsetzen.

    Die Berechtigungen müssen von außen vergeben werden; wenn der Apache-Prozess unter Nutzer/Gruppe www-data operiert, kann man entweder "klassisch" den Nutzer den o.g. Gruppen seiteN zuordnen (via groupadd, vgl. Zeile zwei unten), oder die ACLs werden etwa wie folgt eingesetzt (siehe POSIX Access Control Lists on Linux) :

    Code
    $ setfacl -Rm user:www-data:rwx /var/www/seiteN
    $ setfacl -d -Rm group:www-data:r-x /var/www/seiteN

    Nochmal aus der Theorie heraus die Idee - würde es dann Sinn machen, die tarballs alle unkomprimiert zu speichern und dann alle per Script in einen großen Tarball "reinzukomprimieren"? Oder was würde sich hier anbieten?

    Bzgl. Komprimierung würde das theoretisch etwas bringen. Ich rate aber davon ab, einen einzigen großen/geschachtelten Tarball zu erstellen, da dies im Falle der Extraktion mit zusätzlichem Zeitaufwand, Verlust an Komfort (schnelle Durchsuchung von Tarball-Inhalten etwa bei Verwendung von pixz, wodurch ans Dateiende ein Index angehängt werden kann–hier verliert man durch Komprimierung des äußeren Tarballs jeglichen Zeitvorteil) und Risiko behaftet ist (ein gekipptes Bit am Dateianfang und alle Container-Backups sind unbrauchbar). Gegen kippende Bits ("bitrot") ist ein Kraut gewachsen (siehe PAR2), aber auch die Korrektur großer Dateien nimmt Zeit in Anspruch.

    Ich selbst sichere u.a. auch sehr große Dateisammlungen/Mailboxinhalte (im Original dank Cluster/ZFS-Dateikopien mehrfach redundant vorliegend) auf "Nicht-ZFS-Datenspeicher" (ansonsten käme zfs send/recv mit Snapshots und Bookmarks zum Einsatz[*]) unter Verwendung von tar, tausche hier jedoch Speicherplatz gegen ein geringeres Risiko von Datenverlusten durch o.g. bitrot, indem ich die resultierenden vollständigen/inkrementellen Archive bei Erstellung in Teildateien aufteile und einzeln komprimiere/verschlüssele/"prüfsummensichere" (selbst im worst case beschleunigt dies Restaurationsversuche deutlich und beschränkt bei Einzelfehlern die Anzahl verlorener Dateien).

    [*] Das eine schließt das andere hier nicht aus, man könnte durchaus einen Stream in einem Tarball sichern, aber dann kommt man auch nur unter Verwendung eines (kompatiblen) ZFS-Pools mit genügend Platz an seine Backupinhalte. Das bringt in einem Fall jedoch zusätzlichen Platzgewinn: Wenn nämlich viele Container geklont werden, sollten 5th-Generation-COW-Dateisysteme wie Btrfs und ZFS ja nur die Differenzen zwischen den Clones auf der Platte ablegen (tar könnte das nicht erkennen/ausnutzen).

    (1) Jetzt mal rein theoretisch... wenn man LXC Container betreibt, dann hat man ja irgendwo die Platten der Container im Filesystem gemountet und kann vom Hostsystem aus direkt darauf zugreifen.

    (2) Könnte man dann also hergehen und die Container direkt per Borg sichern, indem man den entsprechenden Ordner angibt, in den dessen rootfs gemountet ist?

    Ad (1): Eingebunden sind die "Platten der Container" in der Regel genau dann, wenn die Container laufen; das muss man ansonsten ggf. selbst temporär nachholen. Während die Container laufen, ist zu überlegen, wie sinnvoll/konsistent eine Sicherung zu diesem Zeitpunktist, also sind diese ggf. zu stoppen oder "kontrolliert" einzufrieren.

    Ad (2): LXC/LXD arbeitet mit Namespaces, d.h. man muss bei der manuellen Einbindung auch darauf achten, dass dies im Kontext des Archiv-Prozesses berücksichtigt wird, sonst bleiben die Mountpoints "leer" (das ist genau das, was bei Verwendung der LXC/LXD-eigenen Archivierung im Hintergrund gemacht wird).

    Abgesehen von diesen beiden Punkten/nach deren Adressierung lassen sich natürlich jegliche Arten von Backups/Werkzeugen einsetzen, um inkrementelle Backups zu erzeugen…

    Manchmal spiel nur ein Punkt eine Rolle. Hat jemand einen Rat?

    In den Zeilen 8–11 sollten in der Tat keine Punkte hinter "[…]mailbox.org" stehen. Andersherum: Mit den aktuellen Eintragungen sollte man auf keinen Fall vorgenannte abschließenden Punkte hinter ".org" sehen, wenn man host meinedomain.de eingibt. Außerdem sollten die gezeigten "MX"-Einträge links im CCP ein "@" stehen haben, sie beziehen sich ja auf die Hauptdomäne…