Beiträge von m_ueberall

    Sofern die opnsense sicher konfiguriert ist, bin ich also ganz safe mit der Deaktivierung der ersten NIC, korrekt?

    Meines Wissens ist es leider bislang nicht möglich, die primäre Netzwerkschnittstelle im SCP zu deaktivieren (womit sie vom Betriebssystem nicht mehr sichtbar und auch nicht mehr reaktivierbar wäre). Wenn also ein Programm softwaremäßig in der Lage ist, diese Windows-seitig zu reaktivieren, ist es mit der Abschottung vorbei.

    (Ein älterer Diskussionsfaden mit obengenanntem Funktionswunsch und Linux-seitiger Absicherungsmöglichkeit findet sich hier.)

    Ufff. Also wenn wirklich *alle* Rechnungen bezahlt sein müssen wäre das etwas doof.

    Traue mich das gerade nicht zu testen da der Server aktuell noch in voll produktiv Betrieb ist..

    Sofern eine Rechnung gerade offen ist, kann schon der Transfercode nicht erzeugt werden (eigene Erfahrung). Und ein erzeugter Transfercode wird kaum funktionieren, wenn zwischenzeitlich eine neue Rechnung zu begleichen ist. Ich bin mir ziemlich sicher, dass Netcup hier aus gesetzlichen Gründen genau getestet hat …

    Wenn 20 € im Monat schon zu viel sind?

    Es geht hier aber ggf. (wenn wirklich jedem Mitglied eine E-Mail-Adresse zugeordnet werden soll) um 6-7x 20€:

    Etwas viel günstigeres als diese Groupware (100 Nutzer für 19,99/Monat sind ja dann nur 20 cent pro Nutzer) wirst du m.E. nicht finden.

    das größte Paket mit 100 Nutzern, wird bei ca 580 Mitgliedern bald voll sein.

    Und die Kosten wären unseren Verein zu hoch.

    Analog zur Definition von Transport-Regeln für Microsoft-E-Mailkontenbesitzer (wiederkehrendes Thema in diesem Forum) sollte es beispielsweise mit Rspamd für "problematische Dienstleister" doch möglich sein, abweichende/keine DKIM-Schlüssel einzusetzen (es gibt ja u. a. mit ARC eine weitere Möglichkeit für den Empfänger, die Authentizität zu verifizieren)? Da es sich um einzelne DNS-Einträge handelt, können diese ja nebeneinander existieren.

    Ein alternativer Ansatz für die Nutzung von nicht via API verfügbarer Funktionen wäre der Einsatz von Selenium; michaelvo hat hiermit offenbar Erfahrungen gesammelt, vielleicht wäre eine Nachfrage bei ihm/in diesem Diskussionsfaden nützlich, wenn das noch nicht in den Netcup Community Tutorials thematisiert wurde?


    Unabhängig davon empfiehlt es sich immer, den QEmu Guest Agent zu installieren, wobei man hier aus Sicherheitsgründen einige Funktionen clientseitig blockieren kann (vergleiche diesen Diskussionsfaden). Hierfür würde man etwa folgende Liste als Anhaltspunkt verwenden, die auch irgendwo in diesem Forum diskutiert wurde (neuere Versionen des Agenten erweitern dessen Funktionen regelmäßig):

    Zitat von /etc/systemd/system/qemu-guest-agent.service

    [Service]

    ExecStart=-/usr/sbin/qemu-ga --blacklist=guest-exec,guest-exec-status,guest-set-user-password,guest-file-close,guest-file-flush,guest-file-open,guest-file-read,guest-file-seek,guest-file-write,guest-get-users,guest-get-osinfo,guest-ssh-get-authorized-keys,guest-ssh-add-authorized-keys,guest-ssh-remove-authorized-keys

    Restart=always

    RestartSec=0

    Würdet ihr einen (auf Root-Server bezogen) Intel 6230 (2,1GHz) gegen den aktuellen AMD tauschen?

    Coreanzahl (6 Stück) würde gleich bleiben.

    Abgesehen von den Benchmarks stellen sich bei gemieteten virtuellen Umgebungen in diesem Fall doch die Fragen nach

    1. Kosten/Nutzen erneut verbundener Mindestlaufzeit bei Vertragswechsel,
    2. Auswirkungen der größeren Zahl von Mitnutzern (die allesamt Lastspitzen generieren können) dank erhöhter Integration,
    3. Nutzungsmöglichkeit der speziellen, in die KVM weitergereichten Fähigkeiten neuer CPU-Modelle,
    4. Weitere mit einem Vertragswechsel verknüpfte Änderungsmerkmale (Netzwerkanbindung, Standort(garantie), …).

    Never change a running system (that satisfies your needs (without regrets)).

    m_ueberall


    Hast du einen speziellen Grund, warum du bei den fio-Parametern für deine Benchmarkliste --rwmixread=75 verwendest, statt des defaults 50 ?

    (yabs.sh belässt es ja z.B auch bei diesem Halbe/Halbe)

    Die ersten Benchmarkergebnisse, die hier im Forum veröffentlicht wurden und die Grundlage für die Vergleichstabelle legten, haben allesamt diesen Wert verwendet. Und von der Gesamt-Charakteristik der eigenen Anwendungen her überwiegen auch Lesezugriffe. Deswegen erschien es naheliegend, das einfach so fortzuführen.

    (Einen Konsens bzgl. der Gewichtung wird man eh' kaum finden.)

    Damit wir uns nicht missverstehen: Aber das ist schon möglich…

    mypool -> otherpool/mypool

    Das mache ich nämlich seit fast einem Jahr mit den Backups :/

    Was tatsächlich nicht geht, vor allem wenn eine Verschlüsselung im Spiel ist: mypool -> otherpool

    Hm, ich glaube, bei der Migration habe ich tatsächlich vor dem letzteren Problem gestanden und die "Kind-Datensets" dann einzeln in den neuen Pool auf die oberste Ebene transferiert. Mal die eigenen Logdateien durchforsten und die Notizen im Wiki abgleichen. Für Neuinstallationen halte ich inzwischen für die jeweils verwendeten Architekturen eine "Basispooldefinition" ([bpool*+]rpool) vor (mit der alles evtl. Existierende überschrieben wird), welche gleichzeitig als Testumgebung für neue Kernel-/ZFS-Treiber-Kombinationen dient, bevor diese Pakete in der Produktivumgebung verteilt werden. Individuelle Datasets sollten danach einzeln migrierbar sein.

    * leider noch nicht für aarch64/arm64, weil auf den ODROID N2+ standardmäßig Petitboot anstelle von Grub2 zum Einsatz kommt und ich nicht mit U-Boot herumkämpfen will

    Zum Beispiel ist der gesamte Pool verschlüsselt und somit auch das Root-Dataset, was in vielen Situationen absolut nicht ideal ist. Es macht aber auch keinen Sinn, wenn ich jetzt zig Datasets einzeln verschlüsseln und somit auch entsperren müsste, weil die Einstellung nicht mehr vererbt werden kann. […]

    Ich könnte also eigentlich 1:1 das alte Root-Dataset als RAW-Stream zum neuen Pool senden und würde alle alten Snapshots behalten können? :/

    Code
    zfs snapshot -r mypool@snapshot
    zfs send -Rw mypool@snapshot | zfs recv -Fusv mypool-new/encryptedroot

    Die Übertragung verschlüsselter Datasets ist derzeit definitiv noch eine ZFS-Baustelle, und auch Dokumentation im eigenen Wiki hat hier leider noch Lücken, was die Nutzung von zfs-change-key usw. zur Anpassung von Schlüsseln betrifft (openzfs/zfs issue #12000 ist hier ein guter Einstiegspunkt, um sich die Probleme zu verdeutlichen). ;(

    Das obige Beispiel zur Übertragung eines gesamten Pool-Inhalts vom Root-Dataset ausgehend in die Dataset-Hierarchie eines anderen Pools ist meines Wissens derzeit (gerade) (noch) nicht möglich, man müsste notfalls über alle direkten Kind-Datasets iterieren (ich hatte vor über einem Jahr ein Problem mit den "zfs recv"-Filtern/-Parametern); entsprechende Tests liegen seit den eigenen letzten Migrationen allerdings allesamt noch auf einer TODO-Liste. (Eigene Backups gesamter Pools und Datasets „in die Cloud“ laufen derzeit – dank des konkurrenzlos günstigen Speicher-Angebots derzeit noch präferiert – via WebDAV, sodass sich dieses Problem hier nicht stellt, auch wenn obiges Szenario ZFS-Pool1→ZFS-Pool2/new-path langfristig erwünscht ist.)

    Ich freue mich allerdings schon über zusätzliche Erfahrungsberichte hier im Forum! ^^

    Code
    root@pc:~# ls -al /usr/share/help/C/eog/
    ls: Zugriff auf '/usr/share/help/C/eog/figures' nicht möglich: Datei oder Verzeichnis nicht gefunden
    insgesamt 18
    drwxr-xr-x  3 root root  3 Mai 12 17:42 .
    drwxr-xr-x 22 root root 22 Jun 13  2021 ..
    d?????????  ? ?    ?     ?            ? figures
    root@pc:~# 


    Das ist beim Update von Ubuntu 21.10 auf Ubuntu 22.04 passiert. […] Reboot hilft nicht. Das Dateisystem ist ein ZFS, ein Scrub auf den zpool ist ohne Probleme durchgelaufen. Gelöscht bekomme ich das Verzeichnis auch nicht, weil es ja angeblich nicht existiert.


    Eh ich es jetzt einfach so lasse... irgendwelche Ideen, was ich da machen könnte? ^^

    Man könnte sicherlich den vor dem Update erstellten Snapshot verwenden und es nochmals versuchen.

    Alternativ findet sich hier eine potenzielle Lösung (mehrere scrub-/clear-Durchläufe; Workaround: Oberverzeichnis verschieben): Repairing a Corrupted File or Directory

    Wenn beides nicht funktioniert, würde ich den Pool schon aus Sicherheitsgründen neu anlegen, wobei auch der Workaround nicht wirklich gefällt.

    Irgendwo gab es wohl einmal einen Diskussionsfaden mit Hilfswerkzeugempfehlungen in diesem Forum; ich bin mit einiger Verzögerung gestern auf plocate als Ersatz für mlocate gestoßen und sehr zufrieden damit (wird von Fedora36 standardmäßig verwendet und kann bei Verfügbarkeit auch die io_uring-Schnittstelle nutzen).