Skip to content

Podman - Netzwerke prunen

Podman
  • Ich hatte nach der ganzen Spielerei noch ein paar alte Netzwerke vom Testen über.

    root@forgejo:~# podman network ls
    NETWORK ID    NAME                  DRIVER
    2f259bab93aa  podman                bridge
    780eab060b6c  root_forgejo          bridge
    9ea4062e11b7  root_forgejo-network  bridge
    

    Die unbenutzten kann man aber ganz einfach entfernen.

    podman network prune
    

    Ausgabe

    root@forgejo:~# podman network prune
    WARNING! This will remove all networks not used by at least one container.
    Are you sure you want to continue? [y/N] y
    root_forgejo-network
    root_forgejo
    

    Danach sieht das so aus.

    root@forgejo:~# podman network ls
    NETWORK ID    NAME        DRIVER
    2f259bab93aa  podman      bridge
    

    Network Settings ausgeben lassen

    podman container inspect <container_name> | grep -A 10 NetworkSettings
    

    Ausgabe

    root@forgejo:~# podman container inspect forgejo | grep -A 10 NetworkSettings
              "NetworkSettings": {
                   "EndpointID": "",
                   "Gateway": "10.88.0.1",
                   "IPAddress": "10.88.0.2",
                   "IPPrefixLen": 16,
                   "IPv6Gateway": "",
                   "GlobalIPv6Address": "",
                   "GlobalIPv6PrefixLen": 0,
                   "MacAddress": "d6:68:ef:27:ab:92",
                   "Bridge": "",
                   "SandboxID": "",
    

    Oder, die IP-Adresse des Containers herausfinden

    root@forgejo:~# podman container inspect forgejo | grep -e IPAddress
                   "IPAddress": "",
                             "IPAddress": "10.89.1.3",
    

    Dazu folgendes von der AI

    podman inspect -f '{{ .NetworkSettings.Networks.<netName>.IPAddress }}' <container-id>
    

    Geht auch so

    root@forgejo:~# podman exec -it forgejo ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host 
           valid_lft forever preferred_lft forever
    2: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
        link/ether d6:68:ef:27:ab:92 brd ff:ff:ff:ff:ff:ff
        inet 10.88.0.2/16 brd 10.88.255.255 scope global eth0
           valid_lft forever preferred_lft forever
        inet6 fe80::d468:efff:fe27:ab92/64 scope link 
           valid_lft forever preferred_lft forever
    
  • Update 1.33.2

    Vaultwarden vaultwarden linux
    1
    0 Stimmen
    1 Beiträge
    130 Aufrufe
    Niemand hat geantwortet
  • Restic feiert 10. Geburtstag

    Restic restic linux
    1
    1
    0 Stimmen
    1 Beiträge
    160 Aufrufe
    Niemand hat geantwortet
  • Ansible - Hetzner Server erstellen

    Verschoben Ansible ansible linux hcloud
    1
    3
    0 Stimmen
    1 Beiträge
    320 Aufrufe
    Niemand hat geantwortet
  • Debian Bookworm 12 - Btrfs Installation

    Linux debian bookworm linux
    3
    1
    0 Stimmen
    3 Beiträge
    2k Aufrufe
    FrankMF
    Das mit den Namen der btrfs Subvolumes ist bekannt bei Timeshift. Im Readme steht dazu folgendes. BTRFS volumes BTRFS volumes must have an Ubuntu-type layout with @ and @home subvolumes. Other layouts are not supported. Systems having the @ subvolume and having /home on a non-BTRFS partition are also supported. Text file busy / btrfs returned an error: 256 / Failed to create snapshot can occur if you have a Linux swapfile mounted within the @ or @home subvolumes which prevents snapshot from succeeding. Relocate the swapfile out of @ or *@home, for example into it's own subvolume like @swap.
  • Konsolentext in Englisch

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

    Linux linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k 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
  • Proxmox - Offline

    Linux linux proxmox
    1
    0 Stimmen
    1 Beiträge
    292 Aufrufe
    Niemand hat geantwortet
  • NodeBB auf dem Raspberry3 B+ installieren

    RaspberryPi nodebb raspberrypi linux
    1
    0 Stimmen
    1 Beiträge
    869 Aufrufe
    Niemand hat geantwortet