Skip to content

Update 1.32.5 - Security Fixes!

Vaultwarden
  • Dani Garcia released Version 1.32.5. Die Version ist ein Security Fix. Bitte unbedingt aktualisieren!

    This release further fixed some CVE Reports reported by a third party security auditor and we recommend everybody to update to the latest version as soon as possible. The contents of these reports will be disclosed publicly in the future.

    @Nico Danke!

  • php8.2 secutity update

    PHP
    1
    0 Stimmen
    1 Beiträge
    86 Aufrufe
    Niemand hat geantwortet
  • Python - Interessante Packages

    Python3
    1
    0 Stimmen
    1 Beiträge
    85 Aufrufe
    Niemand hat geantwortet
  • Update 1.32.4 - Security Fixes!

    Vaultwarden
    1
    0 Stimmen
    1 Beiträge
    79 Aufrufe
    Niemand hat geantwortet
  • Debian Installer Bookworm RC3 released

    Linux
    2
    0 Stimmen
    2 Beiträge
    103 Aufrufe
    FrankMF

    Und da sind wir schon bei RC4

    Debian Installer Bookworm RC 4 release

    favicon

    (lists.debian.org)

  • Debian Buster 10.7 released

    Linux
    1
    0 Stimmen
    1 Beiträge
    215 Aufrufe
    Niemand hat geantwortet
  • LUKS verschlüsselte Platte mounten

    Linux
    2
    0 Stimmen
    2 Beiträge
    963 Aufrufe
    FrankMF

    So, jetzt das ganze noch einen Ticken komplizierter 🙂

    Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen.

    Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung.

    unbekannter Dateisystemtyp „LVM2_member“.

    Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen.

    root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7

    Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool.

    root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands.

    Das muss dann so aussehen!

    vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten!

    Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet.

    /etc/fstab

    # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0

    Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!!

    Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt 🙂

    Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

    Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren 😉

  • ROCKPro64 - Kamils neuer 0.10.x Release

    ROCKPro64
    1
    0 Stimmen
    1 Beiträge
    232 Aufrufe
    Niemand hat geantwortet
  • [HOWTO] Verschlüsseltes NAS aufsetzen

    Verschoben ROCKPro64
    12
    0 Stimmen
    12 Beiträge
    3k Aufrufe
    FrankMF

    Da btrfs bei mir ja nicht so der Bringer war, Fehler im Image vom Kamil?, Fehler in btrfs? Ich weiß es nicht, also weg damit! Da ich das NAS noch richtig produktiv genutzt hatte, waren die Daten schnell gesichert. Danach das NAS neugestartet, nun sind die beiden Platten nicht mehr gemountet und wir können damit arbeiten.

    ACHTUNG! Ich bitte wie immer darum, das Gehirn ab hier einzuschalten! Sonst droht Datenverlust! Aus Sicherheitsgründen gebe ich hier die Laufwerke so an = sdX1 Das X bitte entsprechend austauschen!

    Die beiden Platten mit

    sudo fdisk /dev/sdX

    neu einrichten. Alte Partition weg, neu einrichten usw. Im Detail gehe ich hier jetzt nicht drauf ein. Ich gehe davon aus, das das bekannt ist.

    Der Plan

    raid_pool0 = sdX1 = /dev/mapper/raid_pool0
    raid_pool1 = sdX1 = /dev/mapper/raid_pool1

    Verschlüsseln sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 sudo cryptsetup --key-size 512 --hash sha256 --iter-time 5000 --use-random luksFormat /dev/sdX1 Platten entschlüsseln sudo cryptsetup open /dev/sdX1 raid_pool0 sudo cryptsetup open /dev/sdX1 raid_pool1 RAID1 anlegen sudo mdadm --create /dev/md0 --auto md --level=1 --raid-devices=2 /dev/mapper/raid_pool0 /dev/mapper/raid_pool1 sudo mkfs.ext4 /dev/md0 Script zum Entschlüsseln und Mounten crypt.sh #!/bin/bash ###############################################################################$ # Autor: Frank Mankel # Verschlüsseltes Raid1 einbinden! # # Hardware: # ROCKPro64v2.1 # PCIe SATA Karte # 2St. 2,5 Zoll HDD Platten a 2TB # # Software: # bionic-minimal 0.7.9 # Kontakt: frank.mankel@gmail.com # ###############################################################################$ #Passwort abfragen echo "Passwort eingeben!" read -s password echo "Bitte warten......" #Passwörter abfragen echo -n $password | cryptsetup open /dev/sdX1 raid_pool0 -d - echo -n $password | cryptsetup open /dev/sdX1 raid_pool1 -d - #Raid1 mounten mount /dev/md0 /mnt/raid echo "Laufwerke erfolgreich gemountet!"

    Bis jetzt sieht das Raid ok aus, ich werde das die nächsten Tage mal ein wenig im Auge behalten.

    [ 82.430293] device-mapper: uevent: version 1.0.3 [ 82.430430] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com [ 108.196397] md/raid1:md0: not clean -- starting background reconstruction [ 108.196401] md/raid1:md0: active with 2 out of 2 mirrors [ 108.240395] md0: detected capacity change from 0 to 2000260497408 [ 110.076860] md: resync of RAID array md0 [ 110.385099] EXT4-fs (md0): recovery complete [ 110.431715] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) [57744.301662] md: md0: resync done.