Jak zapewne wiecie, Go został zaprojektowany tak, żeby budować binaria specyficzne dla konkretnej architektury i systemu operacyjnego. Te specyficzne dla architektury i OS binaria nazywamy targetem. Możliwość cross-compile (kompilacji krzyżowej) to jedna z najfajniejszych funkcji Go – można na przykład użyć GOARCH=ppc64 GOOS=aix go build, żeby na Linuxie czy Windowsie zbudować aplikację dla systemu AIX działającego na procesorach Power. Oczywiście też nic nie stoi na przeszkodzie, żeby skompilować program bezpośrednio na AIX.
Jest jednak jeden dodatkowy trik, który bierze pod uwagę wersję architektury i optymalizuje wybór kodu ASM (assembler), używanego podczas budowania. 😉
PowerPC na AIX i zmienna GOPPC64
Żeby używać architektury Power ppc64 dla AIX z konkretnym targetem procesora, możesz skorzystać ze zmiennej GOPPC64. Oto dostępne opcje:
power10 – działa tylko z Power 10
power9 – działa z Power 9 i Power 10
power8 (domyślna) – działa z wersjami 8, 9 i 10
Przykładowo:
GOARCH=ppc64 GOOS=aix GOPPC64=power9 go build
Dlaczego to ma sens w środowisku AIX? Systemy AIX często działają na konkretnych, znanych konfiguracjach serwerowych IBM. Jeśli wiesz, że Twoja aplikacja będzie działać tylko na nowszych procesorach Power (np. power9 lub power10), możesz wykorzystać dodatkowe instrukcje procesora niedostępne w starszych wersjach. Go automatycznie wybierze zoptymalizowany kod assemblerowy dla danej wersji.
Specyfika środowiska AIX
AIX to system, który często działa latami na tych samych maszynach, więc optymalizacja pod konkretny procesor może mieć długoterminowy sens. W przeciwieństwie do środowisk chmurowych, gdzie nie wiesz na czym będzie działać Twoja aplikacja, w AIX zazwyczaj masz pełną kontrolę i wiedzę o sprzęcie.
Co oczywiste, jeśli masz farmy serwerów z różnymi generacjami Power, lepiej zostać przy domyślnym ustawieniu. 🏭
Czy to rzeczywiście coś zmienia?
W typowych aplikacjach biznesowych różnica może być niewielka, ale przy:
Intensywnych obliczeniach matematycznych (typowe dla środowisk AIX)
Przetwarzaniu dużych zbiorów danych
Aplikacjach real-time
różnica może być zauważalna. Jak zawsze z optymalizacjami – najpierw zmierz, potem optymalizuj. 🔧
Pro tip dla adminów AIX: Możesz sprawdzić wersję swojego procesora Power używając komendy prtconf | grep -i processor. Dzięki temu będziesz wiedzieć, jaką wartość GOPPC64 możesz bezpiecznie użyć.
Klucze SSH to podstawa bezpiecznego połączenia z serwerami. Zaskakująco dużo osób nadal nie wykorzystuje tej możliwości lub generuje nadal klucze RSA. Tak więc ściągawka – jak wygenerować nowoczesną parę kluczy SSH Ed25519 w środowisku Windows przy użyciu PuTTY, a następnie skonfigurować je na zdalnym serwerze Linux lub AIX.
Ten tutorial pozwoli Ci całkowicie wyeliminować konieczność wpisywania hasła przy każdym logowaniu SSH, używając najnowocześniejszej technologii kryptograficznej.
Dlaczego Ed25519, a nie RSA?
Ed25519 to przyszłość SSH! Oto dlaczego warto porzucić RSA:
🚀 15x mniejszy klucz (68 vs 1024+ znaków) ⚡ Błyskawiczna generacja i weryfikacja 🛡️ Wyższe bezpieczeństwo przy mniejszym rozmiarze 🔒 Odporność na ataki timing i side-channel ✅ Wspierany przez wszystkie nowoczesne systemy (OpenSSH 6.5+, 2014)
Jeżeli jeszcze nie masz zainstalowanego PuTTY, pobierz pełny pakiet ze strony: https://www.putty.org/
Uwaga: Pobierz cały pakiet (MSI Installer, najpewniej 64bit), nie tylko putty.exe. Będziemy potrzebować dodatkowo PuTTYgen do generowania kluczy.
Po instalacji powinny być dostępne następujące programy:
PuTTY – klient SSH
PuTTYgen – generator kluczy
Pageant – agent kluczy SSH
PSCP/PSFTP – narzędzia do transferu plików
2. Generowanie pary kluczy Ed25519 w PuTTYgen
2.1 Uruchamianie PuTTYgen
Znajdź i uruchom PuTTYgen z menu Start lub z katalogu instalacji PuTTY.
2.2 Wybór typu klucza Ed25519
W głównym oknie PuTTYgen:
W sekcji „Parameters” z dropdown menu „Type of key to generate” wybierz EdDSA
W polu „Curve to use for generating this key” zostaw Ed25519 (domyślna opcja)
Usuń/zignoruj wartość w polu „Number of bits” – Ed25519 ma stały rozmiar klucza (256 bitów, ale bezpieczeństwo jak RSA 4096!)
Kliknij przycisk „Generate”
Dlaczego Ed25519? To najnowocześniejszy standard używany przez GitHub, GitLab i wszystkie wielkie firmy technologiczne. Oferuje maksymalne bezpieczeństwo przy minimalnym rozmiarze.
2.3 Generowanie entropii
Po kliknięciu „Generate” pojawi się pasek postępu, a PuTTYgen poprosi Cię o poruszanie myszką nad pustym obszarem okna.
Ed25519 generuje się błyskawicznie – wystarczy kilka sekund poruszania myszką!
2.4 Konfiguracja wygenerowanego klucza
Po zakończeniu generowania zobaczysz znacznie krótszy klucz publiczny – to normalne i właściwe dla Ed25519!
Pole z kluczem publicznym
Pole „Key comment” – wpisz tutaj opisową nazwę, np.: szydell@laptop-ed25519-2025
Pole „Key passphrase” – wpisz tutaj silne hasło zabezpieczające klucz prywatny lub nie wpisuj, jeżeli nie chcesz podawać hasła do klucza przy logowaniu (mniej bezpieczna opcja).
Przykład komentarza: Użyj opisowej nazwy jak szydell@laptop-ed25519-2025 – pozwoli Ci to łatwo identyfikować klucze w przyszłości.
2.5 Zapisywanie kluczy
To jest kluczowy moment – zapisz oba klucze!
Kliknij „Save public key” i zapisz jako id_ed25519.pub
Kliknij „Save private key” i zapisz jako id_ed25519.ppk
Uwaga: PuTTY zapisuje klucze prywatne w formacie .ppk (PuTTY Private Key), który jest specyficzny dla tego narzędzia.
BONUS: Zaznacz i skopiuj cały tekst z górnego pola (klucz publiczny) – przyda się za chwilę!
Zanim przejdziemy dalej, sprawdźmy czy Twój serwer obsługuje Ed25519:
3.1 Sprawdzenie wersji SSH
Zaloguj się na serwer przez PuTTY (jeszcze hasłem) i wykonaj:
# Sprawdź wersję OpenSSH
ssh -V
# Sprawdź dostępne algorytmy kluczy
ssh -Q key
Ed25519 jest obsługiwany od: ✅ OpenSSH 6.5+ (2014) – praktycznie wszystkie nowoczesne systemy ✅ Linux: wszystkie aktualne dystrybucje ✅ AIX 7.2+ z najnowszymi aktualizacjami ✅ Stare systemy: jeśli masz OpenSSH starszy niż 6.5, użyj ECDSA P-256
Jeśli widzisz ssh-ed25519 na liście – jest dobrze! 🎉
4. Kopiowanie klucza publicznego na serwer docelowy
4.1 Logowanie na serwer przez PuTTY
Uruchom PuTTY i zaloguj się na swój serwer Linux/AIX przy użyciu hasła (jeszcze ostatni raz! 😉).
4.2 Tworzenie katalogu .ssh (jeśli nie istnieje)
# Sprawdź czy katalog .ssh istnieje
ls -la ~/.ssh
# Jeśli nie istnieje, stwórz go
mkdir ~/.ssh
# Ustaw odpowiednie uprawnienia (BARDZO WAŻNE!)
chmod 700 ~/.ssh
Dlaczego 700? Katalog .ssh może być dostępny tylko dla właściciela. Inne uprawnienia to poważny problem bezpieczeństwa.
4.3 Dodawanie klucza publicznego do authorized_keys
Teraz dodamy Twój klucz Ed25519 do pliku authorized_keys:
# Przejdź do katalogu .ssh
cd ~/.ssh
# Stwórz/edytuj plik authorized_keys
vi authorized_keys
4.4 Wklejanie klucza publicznego Ed25519
W edytorze:
Wklej skopiowany wcześniej klucz publiczny (powinien zaczynać się od ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...)
Jeden klucz = jedna linia – Ed25519 jest krótki, więc łatwo się mieści
Zapisz i zamknij plik
Przykład zawartości pliku authorized_keys z kluczem Ed25519:
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.
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:
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:
