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:
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.
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:
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:
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.
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:
Script name
Script Description
Application Key
Application Secret
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.
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).
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.
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. 🙂
Ło panie, a dłuższej tej komendy się nie dało? Przeanalizujmy linia po linii co tu się dzieje:
podman run – uruchom kontener (możesz zmienić na docker run, jeżeli używasz dockera)
–rm – posprzątaj po zakończeniu życia kontenera
–name letsencrypt – kontener ma się nazywać letsencrypt
-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.
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’.
–non-interactive – nie chcemy być zbyt rozmowni i odpowiadać na pytania
–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.
–dns-ovh – odpal challenge dns01 z wykorzystaniem pluginu dns-ovh
–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.
–dns-ovh-propagation-seconds 10 – halt! Dajmy ovh 10 sekund, żeby się zdążyła dodać domena.
-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:
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.
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ę:
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.
GSS – Przy próbie połączenia się po ssh, dodaj -vvv do polecenia. Odpalisz w ten sposób szczegółowy debug. Jeżeli w logu zatrzymujesz się przy wpisach podobnych do tych:
debug1: Unspecified GSS failure. Minor code may provide more information
Ticket expired
Rozwiązaniem jest zedytowanie pliku /etc/ssh/sshd_config i ustawienie:
GSSAPIAuthentication no
Jeżeli pracujesz na Fedorze/RHEL/CentOS’ie, to ustawienie to bywa zdublowane w pliku /etc/ssh/sshd_config.d/50-redhat.conf. Również w nim zmień wartość na no.
RevDNS – Zdarza się, że opóźnienie powodowane jest sprawdzaniem nazwy hosta, z którego się łączysz. Żeby wyłączyć to sprawdzanie ustaw:
UseDNS no
W celu zatwierdzenia zmian, zrestartuj serwer sshd. Na Fedorze zrobisz to bezpiecznie komendą:
# systemctl restart sshd
btmp – powyższe nie pomogło? Sprawdź jak duży jest twój plik /var/log/btmp. Czemu? Przykładowo na Fedorach, w /etc/pam.d/postlogin skonfigurowane jest:
Opcja showfailed, sprawdza w btmp ile było nieprawidłowych prób zalogowania się na Twój login. Jeżeli serwer jest publiczny, to zapewne nie było ich mało. Rozwiązanie? Skasuj btmp, zainstaluj logrotate i skonfiguruj częstsze czyszczenie tego logu. Na Fedorze będzie wyglądać to tak.
