Przegraj (uszkodzony) dysk na dysk używając Linuxa

Scenariuszy do rozwiązania tego tematu jest sporo. Przetrenowałem ostatnio dwa.
A zaczęło się od wyzwania – dostałem stary dysk HDD, który trzeba było sklonować na SSD. Dysponowałem laptopem i jednym adapterem SATA<->USB. Niestety nie mogłem przez to przegrać danych bezpośrednio z dysku na dysk.

Podejście pierwsze – Zrób spakowaną kopię dysku do pliku, a następnie wypakuj na nowe urządzenie.

Zdecydowałem się na pakowanie w locie, ponieważ chciałem, aby obraz klonowanego dysku zajmował możliwie mało miejsca. Mam bardzo dobre doświadczenia z pakowaniem danych programem zstd. Postanowiłem więc z niego skorzystać. Stworzenie spakowanej kopii dysku do pliku:

$  zstd -16 -v -T0 </dev/sdX >/katalog/backup.zst
(-16 <- poziom kompresji, -v <- opowiadaj co robisz, -T0 <- policz ile jest cpu w komputerze i używaj ich)

Wypakowanie na nowy dysk:

$ zstdcat -v /katalog/backup.zst >/dev/sdX

    Wszystko by było super, gdyby nie okazało się, że dysk źródłowy ma bad sectory.

    Podejście drugie – lekko uszkodzone źródło

    Podejście drugie – Skorzystaj z ddrescue

    W moim przypadku źródłowy dysk został wyjęty z działającego komputera. Założyłem więc, że utrata kilku sektorów danych nikomu nie zaszkodzi. Postanowiłem użyć ddrescue – narzędzia, które potrafi ponowić próbę odczytu danych (-r3 <- trzykrotnie), ale też zignorować błędy i kopiować dalej to co warte uratowania. Nowa komenda to:

    $ ddrescue -d -r3 /dev/sdX /katalog/backup.img /katalog/backup.logfile

    A następnie wgrałem tak przygotowany obraz na nowy dysk:

    $ ddrescue -f /katalog/backup.img /dev/sdX /katalog/clone.logfile

    Mission accomplished 🙂

    Benchmark karty graficznej na Linuksie z użyciem superposition

    Chcesz zweryfikować jak wydajnie działa twoja karta graficzna na Linuksie? W 2024 polecam Unigine Superposition od unibenchmark. Oczywiście ten benchmark jest dostępny w wersji natywnej dla systemu linux.

    Benchmarkowanie karty graficznej wymaga poprawnej konfiguracji systemu. Pamiętaj o konieczności instalacji driverów.

    W celu zainstalowania superposition pobierz go z tego adresu https://benchmark.unigine.com/superposition. a następnie uruchom plik Unigine_Superposition-x.x.run. Program wypakuje się do podkatalogu z którego go uruchomisz. Stworzy też skrót na pulpicie, z którego można go odpalać.

    Jak używać? Jeżeli testowane GPU jest to jedyna karta w Twoim komputerze, to najzwyczajniej odpal benchmark.

    Przy kilku kartach graficznych sprawdź ich numery, np. korzystając z vulkaninfo. Zapewne numer 0 to będzie Twoją zintegrowaną kartą graficzną, potem kolejny numer lub numery to karty dodatkowe, z akceleracją 3d.

    Gdy chcesz przetestować kartę NVIDIA, uruchom benchmark definiując wcześniej zmienne środowiskowe __GLX_VENDOR_LIBRARY_NAME i __NV_PRIME_RENDER_OFFLOAD. W RENDER_OFFLAD podajemy numer karty odczytany z vulkaninfo.

    __GLX_VENDOR_LIBRARY_NAME=nvidia __NV_PRIME_RENDER_OFFLOAD=1 ./Superposition

    Dla karty AMD, należy zmienną DRI_PRIME z numerem karty odczytanym z vulkaninfo. W moim przypadku było to:

    DRI_PRIME=2 ./Superposition

    Oczywiście powyższe komendy należy wpisywać w konsoli. Jeżeli jednak nie lubisz takiego podejścia, to możesz zedytować skrót, który superposition założyło na pulpicie. Na KDE wygląda to tak:

    Zapełniony /boot na Fedorze?

    Fedora i wiele innych dystrybucji zakłada przy instalacji dedykowaną partycję /boot. Nie jest ona jakoś przesadnie wielka, bo i nie musi. Gdy jednak wgrywamy aktualizacje na bieżąco, może dojść do sytuacji w której dojdzie do jej przepełnienia. Przy próbie aktualizacji systemu komendą dnf może to wyglądać jak poniżej:

    Error Summary
    -------------
    Disk Requirements:
       At least 29MB more space needed on the /boot filesystem.
    

    Co więc zrobić gdy /boot ma twoim jest pełny? Komenda poniżej skasuje wszystkie kernele inne niż ten na którym pracujesz:

    sudo dnf remove --oldinstallonly -y

    A może nie chcesz kasować wszystkich na wypadek konieczności powrotu do starszej wersji? Możesz skasować bez np. dwóch najnowszych:

    dnf remove --oldinstallonly --setopt installonly_limit=2 kernel

    Komendy te możesz zastosować też na Amazon Linux 2023, Nobara Linux, czy Red Hat Enterprise Linux od wersji 8 w górę.

    Logo Linux Fedora
    Fedora Linux

    Nobara Linux Logo
    Nobara Linux

    logo programu Podman

    docker/podman search

    docker search – przydatna funkcjonalność, do przeszukiwania repozytoriów.

    Osobiście używam główne do znalezienia dostępnych kontenerów UBI od red hata. 🙂

    docker search registry.access.redhat.com/ubi

    Inne używane czasami zastosowanie, to wyszukanie przygotowywanych przez fedoraproject kontenerów np. w danej wersji fedory:

    [root@laPtak ~]# podman search registry.fedoraproject.org/f39
    NAME                                                 DESCRIPTION
    registry.fedoraproject.org/f39/flatpak-kde5-runtime  
    registry.fedoraproject.org/f39/flatpak-kde5-sdk      
    registry.fedoraproject.org/f39/flatpak-kde6-runtime  
    registry.fedoraproject.org/f39/flatpak-kde6-sdk      
    registry.fedoraproject.org/f39/flatpak-runtime       
    registry.fedoraproject.org/f39/flatpak-sdk  

    Tak znalezione kontenery można pobrać później korzystając z komendy docker/podman pull.

    Moduły nvidia nie ładują się

    Po reinstalacji systemu na Fedora 38, zainstalowałem jak zawsze drivery nvidii. Niestety tym razem okazało się, że po reboocie moduły się nie załadowały, a próba skorzystania z karty graficznej o większej mocy kończy się błędami, w których przewijało się słowo 'key’, oraz

    X Error of failed request:  BadValue (integer parameter out of range for operation)

    Przyczyna? Nieoczywista. Włączyłem secure boot, a moduły kernela nie były podpisane.

    Weryfikacja:

    [root@laPtak ~]# mokutil --sb-state
    SecureBoot enabled

    Naprawa:

    sudo dnf remove kmod-nvidia-*
    sudo dnf install akmod-nvidia
    
    

    Następnie wykonaj instrukcję z pliku:

    /usr/share/doc/akmods/README.secureboot
    Logo Linux Fedora
    Logo projektu Let's Encypt i firmy OVH

    SSL/TLS z Let’s Encrypt dla domen w OVH.

    Let’s Encrypt ma plugin dla OVH, skorzystamy więc z niego w poniższym tutorialu. Opisuje w nim krok po kroku jak skonfigurować automatyczne generowanie i odświeżanie certyfikatów z wykorzystaniem dns-01 challenge.

    Instrukcja ta ma zastosowanie tylko gdy Twoja domena hostowana jest przez OVH, wykorzystywać bowiem będziemy API tej firmy.

    Pokazane rozwiązanie pozwala na generowanie certyfikatów dla pojedynczych domen, oraz wildcardów.

    Żeby było jeszcze ciekawiej, skorzystamy z oficjalnego obrazu certbot/dns-ovh, także tutorial ten można zastosować praktycznie na każdym linuxie z dockerem lub podmanem. No i przy okazji jest szansa, że będzie przez jakiś czas aktualny. 😉

    1. Generowanie credentiali w OVH

    Na stronie https://api.ovh.com/createToken/ musimy wypełnić formularz w celu wygenerowania danych używanych później do tworzenia i kasowania wpisów dns. Zgodnie z dokumentacją pluginu certbot-dns-ovh, by móc potwierdzić bycie właścicielem domeny na potrzeby uzyskania certyfikatu Let’s Encrypt, będziemy potrzebować dostępu do następujących metod udostępnionych przez API OVH:

    • GET /domain/zone/*
    • PUT /domain/zone/*
    • POST /domain/zone/*
    • DELETE /domain/zone/*

    Tak wygląda formularz, który wypełniłem dla swojego rozwiązania:

    OVH API, Creating API Keys for your script

    Klikamy na 'Create keys’, jeżeli macie skonfigurowane 2FA OVH poprosi o zatwierdzenie akcji, a rezulatem będzie tabelka zawierająca:

    1. Script name
    2. Script Description
    3. Application Key
    4. Application Secret
    5. Consumer Key

    Notujemy z boku te wartości, będą za chwilkę potrzebne.

    2. Konfiguracja certbota

    Kolejny krok polega na stworzeniu pliku zawierającego dane pozwalające na autentykację w api OVH. Muszą się w nim znaleźć cztery kluczowe informacje – dns_ovh_endpoint, dns_ovh_application_key, dns_ovh_application_secret, dns_ovh_consumer_key.

    Ja założyłem ten plik w /etc/certbot/ovh-secrets.conf. Pamiętajcie, że raczej nie chcecie, żeby ktoś mógł tworzyć, czy kasować subdomeny w waszym imieniu, także zabezpieczcie ten pliczek. Powiedzmy, że wystarczy chmod 0600 /etc/certbot/ovh-secrets.conf.

    Przykładowy plik konfiguracyjny:

    dns_ovh_endpoint = ovh-eu
    dns_ovh_application_key = 7rPawafweAJYWNvhH
    dns_ovh_application_secret = 4SFtGD012npocan90nc0qkTWBflirSEf8oo
    dns_ovh_consumer_key = Et3lLNe2fthx3MeMFaHe3ssoS71qQZHZ
    
    Jeżeli przygotowujesz konfigurację dla infrastruktury zarządzanej przez OVH w Ameryce Północnej, parametr dns_ovh_endpoint powinien mieć wartość ovh-ca. 

    3. Katalogi, uprawnienia, selinux

    Przygotuj potrzebne do działania katalogi i ustaw odpowiednie uprawnienia. W tym tutorialu przyjmuję, że certbot będzie uruchamiany jako root i chcemy trzymać certyfikaty w głównej strukturze systemu (/etc, /var).

    mkdir /etc/letsencrypt /var/lib/letsencrypt /var/log/letsencrypt
    chmod 0700 /etc/letsencrypt /var/lib/letsencrypt /var/log/letsencrypt
    

    3.1 SELinux?

    Na Fedorze SELinux zablokował mi certbota przy próbie zapisu do powyższych katalogów. Jako, że będzie do nich pisać tylko ta aplikacja, ustawiłem/dodałem im kontekst container_file_t.

    # semanage fcontext -a -t container_file_t '/etc/letsencrypt'
    # restorecon -v /etc/letsencrypt/
    # semanage fcontext -a -t container_var_lib_t /var/lib/letsencrypt
    # restorecon -v /var/lib/letsencrypt
    # semanage fcontext -a -t container_file_t /var/log/letsencrypt
    # restorecon -v /var/log/letsencrypt
    

    3.2 Logrotate

    Jak można się domyślić po tym, że zakładamy dedykowany katalog w /var/log, będziemy zbierać logi. Logi zbyt długo trzymane to zło, także dodaj sobie do katalogu /etc/logrotate.d pliczek certbot, którego zawartość to:


    Dzięki temu będziemy trzymać logi przez 60 dni, no i log będzie 'łamany’ codziennie. Co oczywiste chcemy też starsze logi pakować, a użyjemy do tego komendy xz.

    4. Pierwsze uruchomienie

    Podman czy Docker?

    To zależy… Ja pracuję na Fedorze, lubię podmana i w tutorialu będę używał komendy podman.

    Co gdy używasz Dockera?
    Składnia jest identyczna, także zamień słówko podman na docker i wszystko będzie działać bez problemu. 🙂

    podman run \
     --rm \
     --name letsencrypt \
     -v /etc/certbot/ovh-secrets.conf:/ovh-secrets.conf \
     -v /etc/letsencrypt:/etc/letsencrypt \
     -v /var/lib/letsencrypt:/var/lib/letsencrypt \
     -v /var/log/letsencrypt:/var/log/letsencrypt \ 
     certbot/dns-ovh:latest certonly \
       --non-interactive \
       --agree-tos -m twój@email.pl \ 
       --dns-ovh
       --dns-ovh-credentials /ovh-secrets.conf \
       --dns-ovh-propagation-seconds 10 \
       -d example.com -d *.example.com -d innadomena.pl

    Ło panie, a dłuższej tej komendy się nie dało? Przeanalizujmy linia po linii co tu się dzieje:

    1. podman run – uruchom kontener (możesz zmienić na docker run, jeżeli używasz dockera)
    2. –rm – posprzątaj po zakończeniu życia kontenera
    3. –name letsencrypt – kontener ma się nazywać letsencrypt
    4. -v ścieżka_na_serwerze:ścieżka_w_kontenerze – te pliki i katalogi z serwera będą dostępne w kontenerze. Tam gdzie sobie zażyczyliśmy.
    5. certbot/dns-ovh:latest certonly – uruchamiamy najnowszą wersję kontenera dns-ovh. To w nim zainstalowany jest certbot, wraz z naszym pluginem do ovh. Instruujemy certbota, że ma działać w trybie 'certonly’.
    6. –non-interactive – nie chcemy być zbyt rozmowni i odpowiadać na pytania
    7. –agree-tos -m twój@email.pl – zgadzamy się na licencję i podajemy swojego maila, żeby Let’s Encrypt wiedziało z kim gadać na temat domen, którym wystawi certyfikat. W praktyce mail jest używany do powiadomienia, że certyfikat niedługo wygaśnie.
    8. –dns-ovh – odpal challenge dns01 z wykorzystaniem pluginu dns-ovh
    9. –dns-ovh-credentials /ovh-secrets.conf – plugin musi wiedzieć jak się zalogować do OVH, także pokazujemy mu gdzie leży przygotowany przez nas config.
    10. –dns-ovh-propagation-seconds 10 – halt! Dajmy ovh 10 sekund, żeby się zdążyła dodać domena.
    11. -d, -d, -d, -d itd. – Lista domen dla których chcemy dostać certyfikaty.

    Przykładowy log:

    # podman run --rm --name letsencrypt -v /etc/certbot/ovh-secrets.conf:/ovh-secrets.conf -v /etc/letsencrypt:/etc/letsencrypt -v /var/lib/letsencrypt:/var/lib/letsencrypt certbot/dns-ovh:latest certonly --agree-tos -m mój@email.pl  --dns-ovh --dns-ovh-credentials /ovh-secrets.conf --dns-ovh-propagation-seconds 10 -d example.com -d *.example.com
    
    Requesting a certificate for example.com and example.com
    Waiting 10 seconds for DNS changes to propagate
    
    Successfully received certificate.
    Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
    Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
    This certificate expires on 2021-10-28.
    These files will be updated when the certificate renews.
    
    NEXT STEPS:
    - The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    If you like Certbot, please consider supporting our work by:
     * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
     * Donating to EFF:                    https://eff.org/donate-le
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    5. Mamy certyfikat, co dalej?

    Zapewne po coś ten certyfikat był ci potrzebny. Apache httpd? Nginx? Haproxy? W tym tutorialu nic o nich nie będzie, ale tak. To są programy w których możesz użyć uzyskane właśnie certy.

    5.1 Odnawianie

    Po przeczytaniu loga na 100% (jak nie na 100000!) rzuciła ci się w oczy informacja, że certyfikaty trzeba odnawiać, i są raczej dość krótko ważne. Co z tym zrobić?

    Stwórz sobie pliczek /usr/local/bin/certbot_renew.sh (albo o innej nazwie!) i nadaj mu prawa do wykonywania (chmod +x /usr/local/bin/certbot_renew.sh).
    Do środka wrzuć wywołanie certbota w trybie 'renew’, oczywiście w stylu dns-ovh. Żeby mieć pewność, że korzystam z najnowszej wersji kontenera dns-ovh, dorzuciłem jeszcze podman pull na początku:


    Odpalamy testowo:

    # vi /usr/local/bin/certbot_renew.sh
    # chmod +x /usr/local/bin/certbot_renew.sh
    # /usr/local/bin/certbot_renew.sh
    Trying to pull docker.io/certbot/dns-ovh:latest...
    Getting image source signatures
    ...
    Copying blob 0b99e4c5dcd1 [--------------------------------------] 0.0b / 0.0b
    Copying config be6f9c73b8 done  
    Writing manifest to image destination
    Storing signatures
    be6f9c73b8127bdd5983728deba3644efffb6826ff4d9be6757b2cf60c4aef5f
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Processing /etc/letsencrypt/renewal/example.com.conf
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Certificate not yet due for renewal
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    The following certificates are not due for renewal yet:
      /etc/letsencrypt/live/example.com/fullchain.pem expires on 2021-10-28 (skipped)
    No renewals were attempted.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    

    5.2 systemd service i timer

    Mamy już działający skrypcik, który gdy będzie czas odnowi certyfikaty. Wypadałoby teraz go uruchamiać cyklicznie. Cron jest trochę passe, także treningowo zróbmy to przy użyciu systemd.

    Stwórz plik /etc/systemd/system/certbot_renew.service:


    Następnie timer, który będzie go uruchamiać (/etc/systemd/system/certbot_renew.timer):


    Pozostaje nam już tylko przeładować ustawienia i włączyć timer:

    # systemctl daemon-reload
    # systemctl enable certbot_renew.timer 
    Created symlink /etc/systemd/system/timers.target.wants/certbot_renew.timer → /etc/systemd/system/certbot_renew.timer.
    

    Podsumowanie i aftercare Let’s Encrypt + OVH

    Raz zdefiniowany proces odświeżania certyfikatów powinien być bezobsługowy, pamiętajmy jednak, że dobrze jest czasem zajrzeć do logów:

    • journalctl -u certbot_renew.service
    • cat /var/log/letsencrypt/letsencrypt.log

    No i na szczęście Let’s encrypt jest o tyle miłe, że w razie czego ostrzeże mailowo, gdy odnowienie certa nie wykona się o czasie.

    Logo Windows 10

    Czas do zablokowania ekranu, Windows 10

    To totalne wariactwo, ale okazuje się, że standardowo w Windows 10 nie ma opcji pozwalającej na ustawienie po jakim czasie ma się zablokować ekran. Na szczęście da się ją włączyć w rejestrze.
    Jak więc ustawić czas do zablokowania ekranu? Odpalamy regedit’a i szukamy klucza:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\7516b95f-f776-4464-8c53-06167f40cc99\8EC4B3A5-6868-48c2-BE75-4F3044BE88A7

    Następnie w parametr Attributes ustawiamy na 2. Standardowo będzie tam 1. W rezultacie odblokuje nam się opcja 'Limit czasu wyłączenia ekranu blokady konsoli’. Znaleźć ją można też bardzo prosto, ścieżka to:

    Panel sterowania -> Sprzęt i dźwięk -> Opcje zasilania -> Edytowanie ustawień planu -> Zmień zaawansowane ustawienia zasilania

    W nowo otwartym okienku, szukamy na liście rozwijanej:

    Ekran -> Limit czasu wyłączenia ekranu blokady konsoli

    I wreszcie możemy ustawić sobie taki czas, jaki nam odpowiada.

    Ściana z czerwonej cegły, a za nią monitor. Obok napis firewalld

    firewalld – przekierowywanie portów

    Lubię firewalld. Nie zawsze jednak pamiętam składnię firewall-cmd.
    Szybka notatka jak zestawić przekierowanie portu na inne ip i port.

    Uruchom jako root:

    # firewall-cmd --permanent --zone=public --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.1.1.10

    Rezultatem tej komendy będzie ustanowienie przekierowania z portu 80(port) twojej maszyny, na port 8080(toport) maszyny o adresie 10.1.1.10(toaddr). Jeżeli chcesz przekierować porty wewnątrz jednego hosta, pomiń część 'toaddr’.

    Co dalej? Standardowo:

    # firewall-cmd --reload
    # firewall-cmd --list-all

    Pamiętaj, że samo przekierowanie portu może nie wystarczyć. Musisz go mieć otwartego. W tym celu wykonaj dodatkowo komendę:

    # firewall-cmd --add-port=80/tcp --permanent
    # firewall-cmd --reload

    I zweryfikuj czy pojawia się na liście otwartych portów:

    #firewall-cmd --list-all

    Przekierowanie oczywiście można też usunąć.
    Wystarczy zamienić w komendzie dodawania słówko add na remove:

    # firewall-cmd --permanent --zone=public --remove-forward-port=port=80:proto=tcp:toport=8080:toaddr=10.1.1.10
    

    Firewalld powinien ogłosić sukces, a nam pozostaje tylko załadować zmiany do pamięci komendą firewall-cmd –reload.

    Logo Linux Fedora

    Jak zaktualizować Fedorę?

    Kolejnych kilka komend, których notorycznie zapominam. Jak zaktualizować Linux Fedora?

    Chyba najprościej z terminala. Co prawda jest też jakiś kreator graficzny, ale nie jestem fanem.

    # dnf upgrade --refresh
    # dnf install dnf-plugin-system-upgrade
    # dnf system-upgrade download --releasever=XX*
    # dnf system-upgrade reboot
    • W miejsce XX wpisujemy numerek wersji. Supportowany jest upgrade o 1 lub 2 oczka w górę. Szczerze mówiąc na skok o dwa się jeszcze nie odważyłem, ale o 1 idzie bez problemów.