Die Ceph Foundation hat Ceph Squid veröffentlicht.

Mit dem aktuellen Update auf Brave 1.63 (Desktop) können Nutzer der Brave-Wallet auch native Bitcoin-SegWit-Adressen erstellen. Damit steht Dir eine native BTC-Adresse zur Verfügung, die im Vergleich zu den anderen Bitcoin-Kontotypen niedrigere Transaktionsgebühren und eine bessere Fehlererkennung bietet. Über die Brave Wallet kannst Du jetzt auch von allen Arten von Bitcoin-Adressen Geldmittel senden und empfangen, inklusive Legacy, Nested SegWit, Native SegWit und Taproot. Das gewährleistet die Kompatibilität mit Wallets von Drittanbietern. Damit Du Bitcoin in Deine Brave-Wallet einzahlen kannst, musst […]

Der Beitrag Brave Wallet unterstützt ab sofort Bitcoin / BTC ist von bitblokes.de.

Ein Reddit User fragt sich: “Wie konnte jemand meine Bitcoin stehlen?” Er hat sich schließlich an Best Practices gehalten und eine sogenannte Paper Wallet (Papiergeldbörse) genutzt. Das Cold Storage wurde aber vor wenigen Tagen komplett ausgeräumt. Für den User ist das natürlich mehr als ärgerlich, schließlich beträgt der Schaden zum derzeitigen Bitcoin-Preis circa 3500 US-Dollar. Für andere ist es eine gute Mahnung. Du solltest extrem aufpassen und auch skeptisch sein. Das gilt insbesondere, wenn Du Wallet-Generatoren benutzt. Persönlich halte ich […]

Der Beitrag Die Gefahr von Paper Wallets – Bitcoin von Reddit User gestohlen ist von bitblokes.de.

Handelst Du nicht mit BTC, solltest Du Deine Assets möglichst von dem Exchange oder der Kryptobörse nehmen. Eine Krypto-Weisheit lautet: Not your keys, not your coins! Das bedeutet: Bist Du nicht im Besitz der privaten Schlüssel, hast Du nicht die komplette Kontrolle über Deine Coins und Token. Geht eine Kryptobörse pleite oder wird gehackt, sind Deine Bitcoin und andere Kryptos in Gefahr. Deswegen hebst Du sie am besten in einer eigenen Wallet auf – im Idealfall in einer Hardware Wallet […]

Der Beitrag Cold Wallet mit Tails – beste Bitcoin Hardware Wallet – nah dran ist von bitblokes.de.

Willkommen zu Teil 6 meiner losen Reihe über die RHEL System Roles. In diesem Teil stelle ich euch die Rolle storage vor, mit welcher sich unpartitionierte Laufwerke und LVM-Volumes verwalten lassen.

Zuerst stelle ich meinen Anwendungsfall vor. Anschließend beschreibe ich, wie ich diesen mithilfe der RHEL System Role storage löse.

Während mir dieser Artikel zur Dokumentation dient, soll er euch den Einsatz von RHEL System Roles verdeutlichen.

Hinweis: Zum Zeitpunkt der Erstellung dieses Artikels unterstützt die Rolle die LVM-Konfiguration lediglich auf unpartitionierten Laufwerken, welche komplett als Physical Volume (PV) genutzt werden.

Wer sich an dieser Stelle fragt, was RHEL System Roles sind, wie man sie installiert und nutzt, dem empfehle ich am Anfang zu beginnen: Vorstellung der Red Hat Enterprise Linux (RHEL) System Roles.

Anwendungsfall

Mit der Ansible-Rolle kvm_provision_lab (siehe [1,2]) provisioniere ich virtuelle Maschinen (VM) auf KVM/QEMU-Hypervisoren. In „Labor-Umgebung mit Ansible in KVM erstellen“ habe ich die Anwendung dieser Rolle bereits detailliert beschrieben. Eine VM wird darin als ein YAML-Dictionary nach folgendem Muster definiert:

test-vm1:
    vm_ram_mb: 512
    vm_vcpus: 1
    vm_iftype: network
    vm_net: default
    os_type: rhel9
    file_type: qcow2
    base_image_name: rhel9-template
    vm_template: "rhel9-template"
    second_hdd: true
    second_hdd_size: "2G"

Das Beispiel im Code-Block provisioniert eine VM mit einem zweiten Blocklaufwerk. Dieses wird in der VM als /dev/vdb konfigruiert.

Um das zweite Laufwerk nutzen zu können, müssen zuerst eine Partitionstabelle und eine Partition erstellt und diese mit einem Dateisystem formatiert werden. Alternativ kann das Gerät auch für LVM verwendet werden.

Ich möchte aus /dev/vdb ein PV für LVM machen, um es einer Volume Group (VG) vg_data hinzuzufügen und ein Logical Volume (LV) zu erstellen, welches die gesamte Speicherkapazität von /dev/vdb nutzt.

Die Rolle

Durch die Installation des Pakets rhel-system-roles existiert diese Rolle storage bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.stroage/ und die Dokumentation in /usr/share/doc/rhel-system-roles/storage/README.md. Aus letzterer stammt auch folgendes Beispiel:

Example Playbook
----------------

```yaml
- hosts: all

  roles:
    - name: rhel-system-roles.storage
      storage_pools:
        - name: app
          disks:
            - sdb
            - sdc
          volumes:
            - name: shared
              size: "100 GiB"
              mount_point: "/mnt/app/shared"
              #fs_type: xfs
              state: present
            - name: users
              size: "400g"
              fs_type: ext4
              mount_point: "/mnt/app/users"
      storage_volumes:
        - name: images
          type: disk
          disks: ["mpathc"]
          mount_point: /opt/images
          fs_label: images

```

Da ich auf /dev/vdb ein LVM konfigurieren möchte, kopiere ich mir das Dictionary storage_pools aus obigen Beispiel und passe es für mein Playbook an.

Das Playbook

---
- hosts: test-vm1

  roles:
    - name: rhel-system-roles.storage
      storage_pools:
        - name: vg_data
          disks:
            - vdb
          volumes:
            - name: data1
              size: "2 GiB"
              mount_point: "/mnt"
              fs_type: ext4
              state: present

Obiges Playbook führt folgende Schritte auf dem Host test-vm1 durch:

1. Das Blockgerät /dev/vdb wird als PV für LVM konfiguriert.
2. Es wird die Volume Group (VG) vg_data auf dem PV /dev/vdb erstellt.
3. In der VG vg_data wird das LV data1 erstellt.
4. Das LV wird mit dem Dateisystem Ext4 formatiert.
5. Das LV wird unterhalb von /mnt eingehängt.

Innerhalb des Gast-Betriebssystems lässt sich mit folgenden Kommandos prüfen, dass die Konfiguration wie gewünscht durchgeführt wurde.

[root@test-vm1 ~]# lsblk vdb
lsblk: vdb: not a block device
[root@test-vm1 ~]# lsblk /dev/vdb
NAME            MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vdb             252:16   0   2G  0 disk 
└─vg_data-data1 253:0    0   2G  0 lvm  /mnt
[root@test-vm1 ~]# pvs
  PV         VG      Fmt  Attr PSize  PFree
  /dev/vdb   vg_data lvm2 a--  <2.00g    0 
[root@test-vm1 ~]# vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  vg_data   1   1   0 wz--n- <2.00g    0 
[root@test-vm1 ~]# lvs
  LV    VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data1 vg_data -wi-ao---- <2.00g                                                    
[root@test-vm1 ~]# mount | grep mnt
/dev/mapper/vg_data-data1 on /mnt type ext4 (rw,relatime,seclabel)
[root@test-vm1 ~]# echo "Hallo Welt!" >/mnt/world.txt
[root@test-vm1 ~]# cat /mnt/world.txt
Hallo Welt!

Fazit

Der betrachtete Anwendungsfall lässt sich mit der vorgestellten Ansible-Rolle schnell und einfach umsetzen. Man deklariert lediglich die Wunschkonfiguration im Ansible-Playbook und die Rolle kümmert sich um den Rest, wie die Installation der notwendigen Pakete auf den Zielsystemen.

Unterstützt werden als Zielsysteme aktuell EL 7-9 sowie Fedora. Damit ist sie für die Anwendung auf Debian bzw. darauf basierende Systeme nicht geeignet. Wie man auch für diese Systeme ein einfaches Playbook entwirft, um LVM für Blockgeräte zu konfigurieren, werde ich in einem folgenden Artikel zeigen.

Ich hoffe, dass euch auch die Vorstellung dieser Rolle gefallen hat und wünsche euch viel Spaß bei der Nutzung der RHEL System Roles.

Quellen und weiterführende Links

1. https://galaxy.ansible.com/Tronde/kvm_provision_lab
2. https://github.com/Tronde/kvm_provision_lab
3. https://github.com/linux-system-roles/storage
4. Vorstellung der Red Hat Enterprise Linux (RHEL) System Roles
5. RHEL System Roles: selinux
6. RHEL System Roles: timesync
7. RHEL System Roles: sshd
8. RHEL System Roles: firewall

Nachdem openmediavault 6 (Codename Shaitan) bereits seit November 2021 als Release Candidate verfügbar war, ist nun die finale Version des freien NAS-Betriebssystems freigegeben worden. Gleichzeitig wird das Ende der Unterstützung für openmediavault 5 angekündigt.

Verteiltes SQL ist die erste Wahl, wenn Unternehmen hochverfügbare, elastische und leicht skalierbare Datenbanken mit hoher Datenintegrität benötigen, erklärt Rob Hedgpeth, Director, Developer Relations bei MariaDB, in einem Gastbeitrag.

Das umfangreiche Release enthält Upgrades für jede Komponente der Plattform sowie die neue intelligente MariaDB Xpand-Engine für verteiltes SQL zur Ermöglichung einer globalen und lückenlosen Verfügbarkeit. MariaDB Platform X5 ist ab sofort für Kunden mit Abonnement verfügbar.