Skip to content

checkmk - Debian Bullseye Release

checkmk
  • Seit heute ist Version 2.0.0p13 draußen. Diese Version soll auf Debian Bullseye laufen. Wie ich selber getestet hatte, lief die alte Version nicht auf Debian Buster. Wenn ich mal Langeweile habe, werde ich das mal testen.

  • Proxmox 8.3 released

    Proxmox proxmox linux
    2
    0 Stimmen
    2 Beiträge
    192 Aufrufe
    FrankMF
    Ich habe gestern mal eine Neuigkeit ausprobiert, den Import einer Anwendung mittels OVA. Dazu habe ich irgendwo im Netz ein File für OpenProject gefunden (steht schon sehr lange auf meiner Testliste). Der Import war langweilig einfach. Nach Import ein paar Dinge eingestellt, Netzwerk usw. und die VM gestartet. Ok, die Installation war so alt, das ich sie danach wieder gelöscht habe, aber das soll ja kein Problem sein. Man kann OpenProject ja auch mittels .deb Package installieren. Zweiter Test war der "Tag View". Interessantes Feature, was ich auch mal direkt angewendet habe, auch wenn fast alle meine VMs Debian sind
  • Ansible - host_key_checking

    Ansible ansible linux hcloud
    1
    0 Stimmen
    1 Beiträge
    193 Aufrufe
    Niemand hat geantwortet
  • Nextcloud - Upgrade auf Bookworm 12

    Angeheftet Verschoben Nextcloud nextcloud linux debian
    1
    4
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet
  • LUKS Key Derivation Function

    Linux luks linux
    1
    0 Stimmen
    1 Beiträge
    81 Aufrufe
    Niemand hat geantwortet
  • ZFS - Wichtige Befehle

    Linux zfs linux
    2
    0 Stimmen
    2 Beiträge
    789 Aufrufe
    FrankMF
    Unter dem Beitrag sammel ich mal ein paar Beispiele, für mich zum Nachlesen Den Anfang macht die ZFS-Replication Ich hatte Am Anfang ein wenig Verständnisprobleme, bis es klar war, das diese Replication von Pool zu Pool funktioniert. Also brauchen wir zwei vorhandene ZFS-Pools. root@pbs:/mnt/datastore/datapool/test# zfs list NAME USED AVAIL REFER MOUNTPOINT Backup_Home 222G 677G 222G /mnt/datastore/Backup_Home datapool 2.36G 1.75T 2.36G /mnt/datastore/datapool Wir erzeugen ein Dataset im datapool zfs create datapool/docs -o mountpoint=/docs Wir erzeugen eine Datei mit Inhalt echo "version 1" > /docs/data.txt Wir erzeugen einen Snapshot zfs snapshot datapool/docs@today Kontrolle root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 0B - 96K - Wir replizieren den vorhandenen Snapshot zum ZFS-Pool Backup_Home und speichern ihn da im Dataset test. zfs send datapool/docs@today | zfs receive Backup_Home/test Nun befinden sich die Daten in dem anderen ZFS-Pool root@pbs:/mnt/datastore/datapool/test# ls /mnt/datastore/Backup_Home/test/ data.txt Und was mich am meisten interessiert, ist wie man das zu einem anderen Server schickt zfs send datapool/docs@today | ssh otherserver zfs receive backuppool/backup Den Test reiche ich dann später nach. Quelle: https://www.howtoforge.com/tutorial/how-to-use-snapshots-clones-and-replication-in-zfs-on-linux/ ZFS inkrementelle Replication Als, nur die geänderten Daten senden! Wir erzeugen ein paar Dateien root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data1.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data2.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data3.txt root@pbs:/mnt/datastore/datapool/test# echo "data" > /docs/data4.txt Neuer Snapshot zfs snapshot datapool/docs@17:02 Liste der Snapshots root@pbs:/mnt/datastore/datapool/test# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT datapool/docs@today 56K - 96K - datapool/docs@17:02 0B - 112K - Wir senden dieinkrementelle Replication zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K cannot receive incremental stream: destination Backup_Home/test has been modified since most recent snapshot Dazu schreibt die Anleitung, die ich unten verlinkt habe, das die Daten verändert wurden. Warum, verstehe ich aktuell noch nicht. Mit -F im send Befehl erzwingt man einen Rollback zum letzten Snapshot. zfs send -vi datapool/docs@today datapool/docs@17:02 | zfs receive -F Backup_Home/test send from datapool/docs@today to datapool/docs@17:02 estimated size is 38.6K total estimated size is 38.6K Und Kontrolle ls /mnt/datastore/Backup_Home/test/ data1.txt data2.txt data3.txt data4.txt data.txt Quelle: https://klarasystems.com/articles/introduction-to-zfs-replication/
  • Wireguard 1.0.0

    Wireguard linux wireguard
    1
    0 Stimmen
    1 Beiträge
    302 Aufrufe
    Niemand hat geantwortet
  • Restic & Rclone & Nextcloud

    Linux nextcloud rclone linux restic
    3
    0 Stimmen
    3 Beiträge
    782 Aufrufe
    FrankMF
    Hier mal eine Ausgabe vom ersten Durchgang root@frank-MS-7C37:~# restic --password-file /root/passwd -r rclone:Nextcloud:HOME_UBUNTU backup --files-from /root/includes.txt repository 99xxxxa0 opened successfully, password is correct created new cache in /root/.cache/restic rclone: 2020/05/08 17:47:57 ERROR : locks: error listing: directory not found rclone: 2020/05/08 17:47:58 ERROR : index: error listing: directory not found rclone: 2020/05/08 17:47:58 ERROR : snapshots: error listing: directory not found Files: 3503 new, 0 changed, 0 unmodified Dirs: 2 new, 0 changed, 0 unmodified Added to the repo: 16.872 GiB processed 3503 files, 21.134 GiB in 1:02:56 snapshot fdxxxxec saved Der erste Durchgang hat also etwa eine Stunde benötigt. Durch die Deduplikation der Daten, ist der Vorgang beim zweiten Durchgang viel schneller weil nur neue oder geänderte Daten gesichert werden. Und außerdem sind alle Daten AES-256 verschlüsselt. Also perfekt zur Ablage in irgendeiner Cloud root@frank-MS-7C37:~# restic --password-file /root/passwd -r rclone:Nextcloud:HOME_UBUNTU backup --files-from /root/includes.txt repository 99xxxxa0 opened successfully, password is correct Files: 57 new, 41 changed, 3449 unmodified Dirs: 0 new, 2 changed, 0 unmodified Added to the repo: 22.941 MiB processed 3547 files, 21.137 GiB in 0:13 snapshot c6xxxxe4 saved Wie ihr seht, hat der zweite Durchgang nur ein paar neue und geänderte Daten gesichert. Der Rest ist ja schon vorhanden. Und das kann man dann auch problemlos täglich, wöchentlich oder was auch immer mal eben schnell durchführen. Eines meiner absoluten Lieblingstool
  • Redis oder MongoDB?

    Verschoben Redis nodebb linux redis
    1
    0 Stimmen
    1 Beiträge
    497 Aufrufe
    Niemand hat geantwortet