Maciej[cc]

Pastéis de nata

maciej — Tue, 22 Jul 2025 19:19:00 +0000

Przepis na pyszne babeczki z budyniowym nadzieniem

Składniki

6 żółtek jaj
3 łyżki mąki przennej
1 i 1/4 szklanki mleka (osobno użyjemy 1 a osobno 1/4)
Niecała szklanka cukru
2/3 szklanki wody
Rolka ciasta francuskiego lub filo (z filo wychodzi trochę inny smak)

Potrzebna będzie też brytfanka do babeczek, 2 garnki i sitko.

Przygotowanie

Do 1/4 szklanki mleka wsyp 3 łyżki mąki i rozmieszaj dokładnie, np. ubijaczką do piany, tak aby nie było grudek. Pozostawiamy na później. Do garnka wlewamy wodę z cukrem i gotujemy. Po zagotowaniu należy dodać mleko i zagotować. Po zagotowaniu wyłączamy palnik i dodajemy po kolei mąkę zmieszaną z mlekiem oraz żółtka jajek. Cały czas należy mieszać, aby nie zrobiły się grudki. Jeśli jeszcze nie wyłączyłeś gazu zrób to teraz, nadzienie szybko się przypala. Po dokładnym rozmieszaniu całość należy przelać przez sitko do drugiego garnka aby pozbyć się grudek.

Następnie wykładamy kubeczki w brytfance kawałkami ciasta francuskiego lub filo tak, aby były dokładnie wyłożone aż do brzegów. W powstałe miejsca wlewamy przygotowany budyń. Całość należy dać do piekarnika na ok. 250-270*C, na 8-10 minut. Budyń powinien się lekko zarumienić podczas pieczenia. Jeśli robisz z ciasta filo, to wystające ponad budyń brzegi spalą się. Należy je później odkroić.

Po wystygnięciu babeczki są gotowe do jedzenia

Debugowanie kontenerów w kubernetesie – część 2

maciej — Tue, 12 Mar 2024 10:02:11 +0000

Po poprzedniej części zapraszam na kolejną, pokazującą jak poradzić sobie z ograniczeniami które wprowadza Kubernetes podczas debugowania aplikacji sieciowych.

Wykonanie pojedynczego polecenia/shelll

kubectl -n my_namespace exec -it pod -- /bin/some_command

Gdzie zwykle /bin/some_command można zastąpić /bin/bash

Kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest /bin/bash

Powyższe spowoduje uruchomienie nowego kontenera w tym samym podzie. Dzięki temu możemy połączyć się do localhost (127.0.0.1) i sprawdzić jak działają nasze serwisy za pomocą curl/wget. W trybie debug mamy też dostęp do roota, dzięki czemu hardening właściwej aplikacji nie jest aż tak straszny i nie ogranicza nas, np. w zainstalowaniu nowych paczek. Taki kontener nie współdzieli też systemu plików z oryginalnymi kontenerami z poda, dzięki temu nie namieszamy zbyt dużo.

Lepszy kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest --share-processes -c container_name --copy-to=mg-debug

Jest to trochę bardziej rozbudowana wersja poprzedniego polecenia. Odpalając taki kontener do debugowania możemy wybrać jeden z istniejących kontenerów i kubectl skopiuje jego konfiguracje (zamontowane volumes, sieć i przestrzeń procesów). Zabawa w takim środowisku daje już dość duże możliwości interakcji z innymi kontenerami. Można wysłać przyjacieski sygnał -KILL do procesów, pogrzebać w podmontowanych wolumenach lub sprawdzić sieć, również bez ograniczeń hardeningu.

Shell noda

Link dla zdesperowanych: https://github.com/kvaps/kubectl-node-shell. Skrypt potrafi uruchomić shell na nodzie kubernetesa. Dzięki niemu możemy dostać się jako root na dowolnego noda z klastra jako root i wprost pogrzebać w systemie. Chyba najbardziej “wszechmocna” opcja do zabawy w szukanie dziury w całym.

Miłego debugowania!

Co zrobić gdy nie mamy w kontenerze roota i trzeba debugować sieć

maciej — Wed, 27 Dec 2023 08:24:13 +0000

Często debugowanie kontenerów w kubernetesie wymaga przeanalizowania ruchu, jaki wchodzi lub wychodzi do systemu. Nie ma z tym problemu jeśli mamy dostęp do konta administratora u możemy uruchomić netstat lub tcpdump aby popatrzeć w pakiety. Co jeśli nie ma do tego dostępu?

Znajdź proces

Na początek zacznijmy od znalezienia procesu, który obsługuje ruch na porcie 80:

$ ps
bash: ps: command not found

Będzie trudniej… przejdźmy to katalogu /proc. Część z podkatalogów odpowiada procesom. Zwykle w kontenerach oraz w Linuksie proces z PID o numerze 1 odpowiada pierwszemu procesowi w systemie/kontenerze (np. /bin/init). Mamy zatem sporo różnych wpisów w proc:

$ ls -l /proc
total 0
dr-xr-xr-x 9 root root 0 Dec 19 11:59 1
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 29
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 30
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 31
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 32
dr-xr-xr-x 9 root root 0 Dec 27 08:05 33
dr-xr-xr-x 9 root root 0 Dec 27 08:06 55
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 56
dr-xr-xr-x 9 nginx nginx 0 Dec 27 08:09 63
drwxrwxrwt 2 root root 40 Dec 19 11:59 acpi
dr-xr-xr-x 13 root root 0 Dec 19 11:59 asound
...

Każdy z nich odpowiada osobnemu procesowi. Po nazwie właściciela można stwierdzić co to za proces, ale aby upewnić się, sprawdźmy wpis exe w takim katalogu:

$ ls -lh /proc/29/exe
lrwxrwxrwx 1 nginx nginx 0 Dec 27 08:10 /proc/29/exe -> /usr/sbin/nginx

exe to link symboliczny do pliku wykonywalnego w systemie plików. Mamy zatem ustalonego podejrzanego oraz jego proces.

Jakie porty są otwarte przez proces

Aby sprawdzić z czego korzysta dany proces zwykle można urzyć lsof lub netstat. W dobrze zabezpieczonych systemach nie mamy takiej możliwości. Zamiast tego możemy podglądnąć listę otwartych prze nginx plików:

$ ls -lh /proc/29/fd/
total 0
lrwx------ 1 nginx nginx 64 Dec 27 08:13 0 -> /dev/null
l-wx------ 1 nginx nginx 64 Dec 27 08:13 1 -> 'pipe:[37844]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 10 -> 'anon_inode:[eventfd]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 11 -> 'anon_inode:[eventfd]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 12 -> 'socket:[40105]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 13 -> 'socket:[40107]'
l-wx------ 1 nginx nginx 64 Dec 27 08:13 2 -> 'pipe:[37845]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 3 -> 'socket:[40103]'
l-wx------ 1 nginx nginx 64 Dec 27 08:13 4 -> 'pipe:[37845]'
l-wx------ 1 nginx nginx 64 Dec 27 08:13 5 -> 'pipe:[37844]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 6 -> 'socket:[40099]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 7 -> 'socket:[40100]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 8 -> 'socket:[40102]'
lrwx------ 1 nginx nginx 64 Dec 27 08:13 9 -> 'anon_inode:[eventpoll]'

Pliki z numerami (dokładniej deskryptorami, możliwe, że kojarzysz to z funkcji open w C) 0 i 1 to standardowe wejście i wyjście. Za ich pomocą program komunikuje się z użytkownikiem w konsoli. Tutaj jest wejście jest ustawione na /dev/null a wyjście przekierowane do pipe. To, co nas interesuje, to pliki opisane jako socket:[numer]. Są to połączenia sieciowe. Nazwa symlinka to deskryptor pliku/socketu widziany po stronie aplikacji. Numer widoczny po socket:… to identyfikator obiektu po stronie jądra systemu, tzw. inode.

Jak sprawdzić który inode odpowiada socketowi, nasłuchującemu na porcie 80? Popatrzmy w plik /proc/net/tcp:

$ cat /proc/net/tcp
 sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode 
 0: 00000000:0050 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 40099 1 0000000000000000 100 0 0 10 0

Pokazuje on otwarte połączenia sieciowe. Ostatnia kolumna to inode połączenia (socketu). Jeśli poszukasz jej w /proc/29/fd, to znajdziesz podobny wpis, dla deskryptora pliku nr 6. Teraz wystarczy popatrzeć na local_address i zamienić numer portu 0050 na wartość dziesiętną i wyjdzie port 80, na którym słucha nasza aplikacja.

Wszystko to używając jedynie ls oraz cat z konta zwykłego użytkownika, które zwykle nie są usuwane podczas zabezpieczania kontenerów

Debugowanie kontenerów w chmurze

maciej — Fri, 24 Sep 2021 08:29:21 +0000

Czasami coś nie działa i przyczyna tego za diabła nie chce dać się znaleźć. Poniżej kilka pomocnych rad w debugowaniu w środowisku chmury i kontenerów, czyli “u mnie działa, a na cudzym komputerze nie”

Problem

Moja strona nie działa, a devops skomplikował sprawę. Na wejściu do naszego serwisu stoi ELB, ALB lub inny load balancer, który przekierowuje ruch do kontenera zarządzanego przez ECS lub kubernetes. Żeby było trudniej, nie mamy dostępu do czeluści load balancera i wejście na noda klastra też jest ograniczone. Możemy jedynie dostać się do kontenera.

Porblem pojawia się gdy frontend (UI) wysyła żądanie do backendu. Nie dostajemy poprawnej odpowiedzi, a jedynie błąd 503 Service Unavailable.

Rozwiązanie

Znajdź problem i napraw :)

Rozwiązanie 2

Zanim zaczniesz grzebać, upewnij się, że zepsucie danego kontenera nie pociągnie za sobą negatywnych konsekwencji. W przypadku Kubernetesa, ECS lub innych orchestratorów (jakkolwiek to się tłumaczy) usunięcie zepsutego kontenera powinno spowodować automatyczne utworzenie nowego, takiego samego. Oprócz tego dobrą rzeczą będzie kawałek papieru lub gedit do notowania co robimy, aby łatwo dało się zrobić rollback zmian, które są trwałe lub odtworzyć całą ścieżkę.

Ponadto pomyśl czy żądanie/request, które będziemy naprawiać nie niszczy czegoś po stronie backendu. Jeśli problem sprawia guzik “skasuj konto” to dwukrotne debugowanie tego samego requestu będzie problematyczne…

Sprawdź co nie bangla

Na początek znajdź z użyciem developer tools jakie żądanie sprawia problem. Otwórz developer tools w przeglądarce i popatrz co się dzieje gdy strona wysyła do backendu request. W dalszej części bardzo pomocne będzie skopiowanie polecenia cURL z dokładnymi parametrami żądania, które wysyła przeglądarka. W zakładce z listą połączeń sieciowych z developer tools możesz wybrać skopiowanie requestu m.in. jako polecenie programu cURL.

Ponadto, w ulubionym edytorze tekstu, jakim jest oczywiście pico albo gedit, zapisz powyższe polecenie. Często bedzie ono zawierało całą masę nagłówków, id sesji, ciasteczek i innych rzeczy, które weryfikuje backend w celu uwierzytelnienia człowieka. Jako użyteczny dodatek możesz zamienić w takim poleceniu nagłówek User Agent na własny string. W większości logów user agent pojawia się w każdej linijce logowanego requestu i dzięki temu będzie nam łatwiej przeszukać logi tylko z naszego curla.

Mając powyższe sprawdź czy curl dostaje tak samo niepoprawną odpowiedź od serwera. Możliwe że już na tym etapie otrzymasz komunikat z błędem i dalsze debugowanie stanie się zbędne.

Logi

Chyba podstawowa rzecz, dużo grepa, a jeśli to AWS to dużo scrollowania i szukania w cloudwatch. Jeśli nie ma w logach aplikacji z backendu, to możliwe że jest w logach load balancera. Jeśli nie, to…

Czas na grubszy kaliber

Czasami błąd jest tak uciążliwy, że ani w logach ani w odpowiedzi backendu nie da się znaleźć jego przyczyny. Pozostaje więc kilka cięższych dział:

Wewnątrz kontenera – netstat

Odpal netstat z pakietu net-tools w Ubuntu/Debianie. Polecenie netstat -ntap powinno wypisać wszystkie nawiązane połączenia i otwarte porty. Sprawdź czy wszystko jest tak jak powinno, tj. czy serwer nasłuchuje na odpowiednim porcie, czy widać połączenie z bazą etc.

Jeśli wszystko jest ok, to spróbuj wykonać to samo podczas wykonywania żądania przez cURL. Jeśli takie żądanie wykonuje się za szybko i nie nadążasz klikać, to wrzuć gdzieś sleep 10, tylko nie zapomnij go usunąć :) Ponieważ często po zmodyfikowaniu kodu potrzebny jest restart serwisu, a ubicie głównego procesu spowoduje restart kontenera, spróbuj kill -HUP [proces]. Dawno dawno temu, gdy komputery obsługiwało się bez myszki (i nie przez touch screen) zdarzało się, że coś zerwało połączenie z terminalem, na którym mieliśmy uruchomiony interaktywny proces. Przez SIGHUP można było poinformować taką odłączoną aplikacje, że straciliśmy z nią połączenie i chcemy aby się zakończyła. Serwery zwykle nie reagowały na to, jednak przez lata SIGHUP stał się sygnałem do reloadu konfiguracji i często również skryptów, które są wykonywane przez serwer. Dzięki temu prawdopodobnie nie zrestartujesz kontenera, w którym pracujesz.

Wracając do tematu – mając już wrzuconego gdzieś sleep 10 spróbuj netstat ponownie i zobacz czy nic nie wygląda podejrzanie

cURL do kontenera

Kolejnym punktem do odhaczenia jest wysłanie żądania przez cURL bezpośrenio z kontenera do niego samego. Możemy wykorzystać wcześniejsze polecenie cURL. Możemy też dodać opcje wymuszającą na cURL’u wyświetlenie nagłówków. Jeśli się powiedzie, to problem prawdopodobnie pojawia się gdzieś wcześniej, np. między load balancerem a kontenerem. Jeśli masz taką możliwość, wykonaj to samo z load balancera.

nc do innych usług

Jeśli to zadziała, dobrze jest sprawdzić połączenie z bazą lub innymi wymaganymi serwisami bezpośrednio z kontenera: nc nazwa_hosta port ( apt install netcat). W przypadku bazy można doinstalować jej klienta i spróbować się połączyć, przy okazji wykonując jakiś prosty select na tabelach, do których aplikacja ma mieć dostęp.

Udawanie innych serwisów

Kolejnym trikiem, który może się przydać jest odpalenie czegoś, co udaje bazę lub inny serwis. Pozwoli to poznać nam jakie żądania są wysyłane do sąsiednich usług. Może to być przydatne gdy nie mamy możliwości zainstalowania tcpdump lub jest to zabronione.

Jak to zrobić aby stało się to tylko lokalnie, bez psucia całej infrastruktury? Sprawdź jaki host jest ustawiony jako np. mikroserwis, który chcesz podsłuchać (jeśli używasz po IP, to sorry…). Następnie wpisz w /etc/hosts nowy wpis: 127.0.0.1 [nazwa hosta] i odpal w kontenerze nc -l [port usługi]. W Linuksie pierwszeństwo w ustalaniu adresów przypisanych do hostów ma plik /etc/hosts, dzięki czemu dodając do niego nowy wpis wymusimy aby nasz kontener połączył się z localhost zamiast właściwego hosta. Uruchomiony program nc pozwoli wypisać to, co miało zostać wysłane przez aplikację z naszego kontenera do serwisu. Pamiętaj, aby usunąć później wpis z /etc/hosts :)

Podglądnięcie zmiennych środowiskowych

Często zanim połączymy się z bazą lub podglądniemy ruch sieciowy do danego hosta warto sprawdzić jakie zmienne znają aplikacje, które są już uruchomione w kontenerze. Czasami przez błąd w konfiguracji aplikacja może nie mieć możliwości uzyskania tych zmiennych, bo np. zabrakło uprawnienia IAM do odpytania Secret Parameter Store. Może też to wynikać ze zmienionego API lub biblioteki – zamiast jednego requestu o listę wszystkich parametrów odpytuje o każdy z osobna, do czego IAM już nie uprawnia.

Wykonaj ps aux. Zwykle pierwszy proces będzie znał tylko te parametry, które są przekazywane bezpośrednio przez dockera. Wszelkie inne, uzyskiwane z chmury są znane późniejszym procesom, po pełnej inicjalizacji środowiska. Możesz podglądnąć jeden z wyższych PID’ów (ale nie z naszej sesji!) przez wpis w /proc/[pid]/environ:

sudo cat /proc/123/environ | tr ‘\0’ ‘\n’

Poszczególne zmienne są rozdzielone zerami (znakami o kodzie zero), stąd tr, który zmieni zera na nowe linie. Jeśli wygląda ok, to pijemy kolejną kawę i szukamy dalej

Ponownie netstat, lsof

Sprawdź ulimit i porównaj z ilością połączeń i otwartych plików w kontenerze. W zależności od konfiguracji ten parametr przy dużej ilości połączeń może stwarzać problemy

Podglądanie z czym się łączy aplikacja

Sprawdzisz to przez tcpdump udp port 53. W trakcie działania sniffera możesz wykonać żądanie przez cURL i sprawdzić co się dzieje i z czym się łączy aplikacja. Jeśli używasz IP, to zapytanie tcpdump będzie trochę inne.

strace do czytania logów

Jeśli cloudwatch szczególnie uwiera tu i ówdzie, przez co nie możesz znaleźć logów, warto sprawdzić co aplikacja wypisuje na standardowe wyjście. Nightmare w kontenerze? Nie :) Spróbuj:
strace --attach=[pid serwera] -e write=1,2
Powyższe podłączy “debuger” strace do procesu i będzie wyłapywało jedynie wywołania systemowe funkcji write do plików o fd=1 i 2. Oznaczają one odpowiednio stdout i stderr.

Nie jest to najwygodniejsza metoda oglądania logów, ale pozwala użyć ukochanego grepa i awk’a, co w przypadku cloudwatch nie zawsze jest najwygodniejsze i najszybsze.

Dla przykładowego ls wykonanego przez ssh:

otrzymamy wynik ze strace:

Nie jest to najczytelniejsze, ale odpowiednio okraszając to grep’em i wycinając wszystkie znaki sterowania terminalem (kolory, znaki specjalne etc.) możemy uzyskać dość czytelny wgląd w to, co się dzieje. Powyższa metoda zadziała też na połączeniach sieciowych, w tym na tych, któ©e są już odszyfrowane i idą np. do fcgi po systemowym sockecie.

Na koniec

Jeśli nie udało się nic znaleźć, a aplikacja dalej się sypie, to pozostaje stara dobra metoda… wyłącz i włącz kontener, później instancje, a na koniec pogadaj z frontendowcami i backendowcami którzy muszą wysyłać to problematyczne żądanie. Chociaż pogadać i zrozumieć jest dobrze przed całym powyższym szukaniem dziury w całym ;)

Nowy adres

maciej — Tue, 31 Aug 2021 09:55:17 +0000

Od dzisiaj można przeglądać bloga pod adresem nabozny.io. Stara domena (jak również maile, jeśli ktoś do mnie pisał na nią :) ) przestanie być aktywna z końcem listopada.

Przepis na makowiec

maciej — Mon, 02 Nov 2020 12:08:29 +0000

Do zrobienia będą potrzebne:

Puszka maku
Około 500-600g mąki tortowej
150g stopionego masła
180ml mleka (+/- szklanka)
6 żółtek
Saszetka suchych drożdży lub pół kostki świeżych (chyba 50g)
6 łyżek cukru
Pół łyżeczki soli
Papier do pieczenia jeśli chcemy zawinąć

Mieszamy po kolei: żółtka, cukier (na tym etapie można zrobić kogel mogel :), masło (jeszcze lepszy kogel mogel), drożdże, sól i letnie/lekko ciepłe mleko. Następnie dosypujemy mąkę tak, żeby ciasto przestało się lepić i dało się je jako tako rozłożyć na papierze. Jeśli potrzeba, mąki można dosypać nawet więcej niż 500-600g, byle tylko dało się to rozwałkować.

Można (ale nie trzeba) całość ostudzić w lodówce przez ok. pół godziny, aby było łatwiej rozwałkować. Następnie bierzemy kawałęk, ok 70cm papieru do pieczenia i rozwałkowujemy na nim ciasto w podłużny placek. Na taki placek wykładamy mak z puszki (połowę lub 1/3, w zależności na ile kawałków podzieliliśmy ciasto) i delikatnie, równomiernie rozsmarowywujemy. na koniec z pomocą drugiej osoby zwijamy: jedna osoba unosi jeden koniec papieru do pieczenia, a druga zaczyna zrolowywać ciasto z makiem. W ten sposób powstaje zawijane ciasto o przekroju: (@). Taką roladę należy luźno zawinąć w papier do pieczenia, aby się nie rozerwała podczas pieczenia – wystarczy zostawić luz na około dwa palce. W ten sposób z powyższego przepisu da się zrobić 2-3 rolady makowe. Na koniec zabezpieczamy papier, np. zszywkami i wkładamy na pół godziny do piekarnika na 180*C.

Druga, prostsza wersja polega na wyłożeniu połowy ciasta do szerokiej brytfanki, nałożeniu na to maku i położeniu drugiej warstwy rozwałkowanego ciasta na wierzch. Jest mniej roboty, ale nie można tym poszpanować przed rodziną. Pieczemy mniej więcej tyle samo.

Szyfrowany dysk sieciowy dla potrzeb serwerowych

maciej — Mon, 26 Oct 2020 07:05:44 +0000

Poniżej przedstawiam kilka sposobów na wykorzystanie przestrzeni dyskowej zdalnej maszyny w sposób zabezpieczający w pełni nasze dane. Założenie konfiguracji jest jedno – maszyna udostępniająca swój dysk nie może mieć wglądu w nasze dane, które przechowujemy ani w klucze, którymi dane są szyfrowane. Całość komunikacji ma być w pełni bezpieczna, a jedyny dostęp do danych ma być możliwy jedynie po ich odszyfrowaniu w locie, już na komputerze klienta.

Dzięki temu przejęcie docelowej maszyny nie będzie oznaczało od razu wycieku naszych danych. Ma to być zapewnione począwszy od dostępu do samego jej dysku, aż po grzebanie w RAM’ie, gdzie mogą być przechowywane klucze szyfrujące, gdyby szyfrowanie odbywało się po zdalnej stronie. Kolejnym wymogiem jest aby sposób przechowywania danych był możliwy w środowisku serwerowym, gdzie chcemy zautomatyzować cały proces montowania i dostępu do danych, a więc bez żadnych UI oraz webowych interfejsów.

Duplicity

Najprostszym i zarazem najmniej funkcjonalnym na codzień rozwiązaniem jest zaprzęgnięcie narzędzia do backupów duplicity. Instalujemy go za pomocą:

sudo apt install duplicity

i od razu możemy korzystać. Jest to jeden z wygodniejszych sposobów na tworzenie backupów:

export PASSPHRASE="ala ma kota"
duplicity full /home/shrek rsync://shrek@remote-host//backups/shrek

Plusy:

Wsparcie dla przeróżnych backendów, od ssh, S3 aż po różne egzotyczne chmury
Pozwala tworzyć pełne kopie jak również przyrostowe, co może ograniczyć ilość używanego miejsca

Wady:

Działa jedynie jako backup na żądanie, nie da się wykorzystywać do bieżących operacji, tak jak system plików
Potrafi się wysypać przy dużych ilościach plików

Ecryptfs po NFS

Kolejnym, trochę wygodniejszym do codziennego użytku narzędziem jest połączenie NFS i ecryptfs. Z racji, że jest to połączenie dwóch różnych systemów plików, potrafi sprawiać problemy podczas usypiania komputera lub gdy wystąpią problemy z siecią.

Instalacja i uruchomienie po stronie klienta (zakładam, że gdzieś stoi serwer NFS):

sudo apt install ecryptfs-utils nfs-utils

mkdir /.backup
mkdir /backup

sudo mount -t nfs zdalny_host:/zasob_nfs /.backup
sudo mount -t ecryptfs /.backup /backup
# Tutaj ecryptfs poprosi o podanie nowego hasła, metody szyfrowania i kilku innych detali

Korzystając z takiego połączenia systemów plików nasz lokalny komputer pokaże w katalogu /backup odszyfrowaną zawartość katalogu /.backup. Każdy plik lub katalog w /backup odpowiada w ten sposób zaszyfrowanemu plikowi lub katalogowi w /.backup. Dzięki zastosowaniu NFS wszelkie dane, które zapisujemy w /backup są w formie zaszyfrowanej przesyłane przez sieć do hosta, który udostępnia swój katalog przez NFS.

Plusy:

Działa na żywo, jak zwykły system plików
Szyfrowanie jest wykonywane w całości po stronie klienta
Nie angażuje sterownika plików, dzięki czemu trudniej o uszkodzenie plików na poziomie systemu plików
Łatwe wykonywanie bezpiecznego backupu zaszyfrowanych danych – wystarczy rsync

Wady:

Czasami potrafi mocno zwolnić, zwłaszcza gdy mamy duży ping lub powolne łącze
Zawieszenie się lub zerwanie połączenia NFS skutecznie blokuje szyfrowany system plików, przez co procesy utykają na dostępie do plików w przypadku problemów sieciowych

NBD i LUKS

Ostatnim rozwiązaniem jest wykorzystanie serwera Network Block Device, który udostępni przez sieć całe urządzenie blokowe oraz systemu LUKS, który potrafi szyfrować całe urządzenia blokowe, ponad systemem plików. Dla zestawienia powyższych narzędzi nasz serwer będzie jedynie udostępniać pojedynczą partycję przez NBD, a my jako klient wykorzystamy mapowanie i odszyfrowanie jej przez driver LUKS, a następnie zamontujemy tak odszyfrowane urządzenie jako partycję ext4.

Instalacja po stronie klienta:

sudo apt install cryptsetup nbd-client

Instalacja po stronie serwera:

sudo apt install nbd-server

Następnie trzeba dodać plik eksportujący urządzenie (np. partycja /dev/sda4) do pliku /etc/nbd-server/conf.d/backup:

[backup]
 exportname = /dev/sda4

Pierwsze montowanie i formatowanie partycji po stronie klienta:

sudo nbd-client -N backup 10.11.22.33 /dev/nbd0

# Sformatowanie dysku do luks i odszyfrowanie go. Po obu poleceniach cryptsetup zapyta o hasło
sudo cryptsetup luksFormat /dev/nbd0
sudo cryptsetup luksOpen /dev/nbd0 backup

# cryptsetup stworzy plik backup, który reprezentuje odszyfrowane urządzenie /dev/nbd0:
sudo mkfs.ext4 /dev/mapper/backup

# Na koniec stwórzmy katalog, gdzie będziemy montować naszą partycję
mkdir /backup

sudo cryptsetup luksClose backup

Montowanie i odszyfrowanie za każdym kolejnym razem:

sudo nbd-client -N backup 10.11.22.33 /dev/nbd0
sudo cryptsetup luksOpen /dev/nbd0 backup
sudo mount /dev/mapper/backup /backup

i gotowe!

Zalety:

W mojej opini najszybsze i najbardziej odporne na problemy sieciowe rozwiązanie
Pozwala w pełni wykorzystać dowolny system plików
W razie problemów dane można również odszyfrować na hoście lub dowolnym innym komputerze

Wady:

Duże ryzyko uszkodzenia systemu plików w razie problemu z siecią
Utrudniony backup całego dysku

Podsumowanie

Kombinacji i różnych narzędzi umożliwiających podobne zabezpieczenie jest cała masa, zwłaszcza, jeśli nie ograniczymy się do tych typowo konsolowych. Powyższe jednak pozwolą w miarę dobrze zabezpieczyć się na wypadek przejęcia maszyny hostującej nasze dane i to w sposób dość “paranoiczny”. Zarówno dane jak i klucze deszyfrujące nie są znane po stronie serwera. Może to być zetem sposób na ochronę nawet w najbardziej ekstremalnych przypadkach – zapobiega wyciągnięciu kluczy np. z pamięci wirtualnej maszyny po uśpieniu jej. Natomiast z racji tego, że nasz klient nie posiada samych zaszyfrowanych danych bezpośrednio u siebie, to w przypadku przejęcia fizycznej maszyny, która te dane przetwarza pozostają one dalej bezpieczne, w formie zaszyfrowanej.

Do przechowywania dużych ilości danych można w tym przypadku wykorzystać na przykład tanie serwery z oferty kimsufi (nie, nie płacą mi za to :), z dyskami do 2TB w parze z raspberry pi hostowanym u siebie pod biurkiem lub wirtualną maszyną w innej chmurze.

Sejf w sejfie vs. Sejf z kilkoma drzwiczkami – jak kontrolować dostęp za pomocą kryptografii

maciej — Wed, 14 Oct 2020 15:06:24 +0000

Czasami potrzeba zabezpieczenia dostępu do danych na różne sposoby, tak aby tylko powołane osoby mogły je odczytać. Standardowym, dość powszechnym sposobem jest zaprzęgnięcie do tego celu dedykowanego serwisu, który kontroluje co kto może zrobić (np. LDAP) i podpięcie do niego serwisu zarządzającego danym zasobem (np. dostęp do systemu). Zaletą takiego podejścia jest oczywiście skalowalność i kontrola nad tym co się dzieje, jednak takie podejście zwiększa ilość słabych punktów, które mogą zawieść. Po pierwsze outage dowolnego z nich powoduje niedostępność całej usługi. Po drugie, znalezienie podatności w dowolnym z nich może doprowadzić do nieautoryzowanego dostępu do danych.
Zamiast powyższego podejścia chciałbym pokazać jak można uzyskać podobną “funkcjonalność” dotyczącą dostępu do danych za pomocą kryptografii. Zamiast kontrolować dostęp aktywnie, przez dedykowany serwis, zaszyfrujemy nasze dane w odpowiedni sposób, za pomocą ogólnodostępnych funkcji.

Jest kilka różnic w takim podejściu w stosunku do metody opartej o dedykowany serwis. Po pierwsze kryptografia działa offline, więc dostęp do danych będzie miała nawet osoba, która dostała je w zaszyfrowanej formie i jest offline, zatem można udostępnić je bezpiecznie nawet przez pendrive. Po drugie dostęp do danych jest dawany na zawsze. To znaczy, że jeśli raz damy dostęp do nich, to nie możemy go odebrać, a jedynie zaszyfrować dane ponownie, nowymi kluczami, nieznanymi danej osobie, jednak nie mamy gwarancji, że nie dostanie ich w starej formie. W przypadku serwisu typu LDAP wiemy czy ktoś się logował i prosił o dostęp do danego zasobu. Jeśli nie, to możemy mu go najzwyczajniej odebrać.

Na potrzeby tego wpisu i aby było łatwiej zrozumieć podejście kryptograficzne załóżmy, że nasze dane są trzymane w sejfie, a posiadanie dostępu tego sejfu pozwala odczytać te dane (odszyfrować).

Sejf

Po prostu – dostęp do zasobu ma mieć jedynie uppawniona osoba. Dane szyfrujemy, a klucz dajemy zainteresowanemu. Albo zainteresowany daje nam swój publiczny klucz, a my nim szyfrujemy dane i tylko on może je odszyfrować. Jest to najprostsze podejście, które równocześnie pozwala dać dostęp grupie (przez skopiowanie tego samego klucza symetrycznegoosób bez kontroli w czyje ręce się dostanie. W przypadku szyfrowania kluczem asymetrycznym ten problem odpada – zakładamy, że nikt nie chce udostępniać swojego prywatnego klucza innym tylko po to aby mogli odszyfrować jednorazowo dane.

Sejf w sejfie

Wyobraźmy sobie sytuację, gdzie do dostęp do danych ma być uzyskany jedynie za zgodą wszystkich zainteresowanych na raz. Nikt nie dostanie się do naszego sejfu bez wiedzy pozostałych osób. Najprostszym przykładem może być nasz testament. Podczas jego odszyfrowania my będziemy “offline” z wiadomych względów, natomiast chcemy aby wszyscy zainteresowani (spadkobiercy) zostali powiadomieni i wzięli udział w jego otwarciu.

Aby uzyskać taką konfigurację musimy zaszyfrować dane (testament) za pomocą wielu różnych kluczy (lub kluczy publicznych różnych osób), które odpowiadać będą wszystkim zainteresowanym:

zabezpieczone_dane = Sa(Sb(Sc(dane)))

gdzie Sx jest szyfrowaniem za pomocą klucza należącego do osoby x. W ten sposób każda osoba musi odszyfrować swoją “warstwę” aby dostać się do właściwych danych. Oczywiście istnieje tutaj ryzyko, że osoba posiadająca klucz Sa ze względu na niechęć do ujawnienia danych zablokuje ten proces i osoby b oraz c nie dowiedzą się co było w środku. Również Sc może nie podzielić się swoimi odszyfrowanymi danymi, po dowiedzeniu się co jest w środku.

Analogią jest tu oczywiście zamknięcie małego sejfu w większym, a tego w jeszcze większym. Aby dostać się do najmniejszego z nich otwarte muszą być wszystkie wcześniejsze drzwiczki większych sejfów, a więc wszyscy posiadacze kluczy muszą współpracować. W przypadku kryptografii współpraca (oraz przebywanie w jednym miejscu) nie jest już tak oczywiste i może częściowo zablokować dostęp do danych tak jak w opisanym przypadku.

Innym, dość chamskim przykładem takiego zabezpieczenia wymagającego współpracę dwóch lub więcej osób jest przypięcie komuś roweru dodatkowym zapięciem. Bez Was nie odjedzie swoim jednoślaedm ]:-> Pozdrowienia dla Moniki z Motoroli. Pół biura Cie szukało żeby odpiąć mój rower :D

Natomiast jeśli dane są bardzo duże, to możemy użyć tymczasowego klucza (de)szyfrującego, który jest zamknięty w sejfach. Dopiero po otrzymaniu tego klucza można dostać się do właściwych dancyh, zamkniętych w innym, pojedynczym sejfie (zaszyfrowanych tym kluczem).

Sejf z wieloma drzwiczkami

Kolejnym podejściem jest zezwolenie na dostęp do dancyh/sejfu dowolnej osobie z grupy, ale z założeniem, że każdy ma swój inny, unikalny klucz. Najpopularniejszym rozwiązaniem tego problemu jest szyfrowanie dysków w naszych komputerach (halo windows, u Was też?). Każdy użytkownik systemu może ustawić swoje hasło do szyfrowania dysku, którym zaszyfrowany jest docelowy klucz. Podczas startu systemu podając jedno z haseł odszyfrowujemy tak na prawdę docelowy klucz symetryczny, którym jest zaszyfrowany cały dysk. Dzięki temu, oprócz możliwości udzielenia dostępu dla wielu osób, możemy w dowolnym momencie dodać lub usunąć hasło do odszyfrowania systemu plików, bez konieczności re-szyfrowania całego dysku. Zmieniając hasło, zapisujemy jedynie kilkadziesiąt/kilkaset bajtów zaszyfrowanego głównego klucza za pomocą naszego nowego hasła.

Jak takie coś wygląda w prawdziwym życiu? Ano tak:

https://www.geograph.org.uk/photo/5932928

Aby dostać się za taką bramkę trzeba odpiąć łańcuch. Aby to zrobić zdjęta musi być jedna z kilku kłódek. Każda z nich odpowiada konkretnemu mieszkańcowi posesji. Co jeśli ktoś zgubi klucz? Tylko ta osoba kupuje nową kłódkę i zakłada na swoje miejsce, bez zawracania głowy innym osobom dorabianiem nowego klucza.

W przypadku analogi do sejfu mielibyśmy skrzynkę nie z jednymi, a z wieloma drzwiczkami, każde z osobnym kluczem.

Otwarcie N z M zamków

Moim zdaniem najciekawszym sposobem zabezpieczenia danych jest otwarcie sejfu (odszyfrowanie) przy dostępnych jedynie M kluczach z N, gdzie oczywiście M < N. Czyli mamy coś pomiędzy drugim a trzecim opisywanym rozwiązaniem: do otwarcia nie muszą być obecni wszyscy, ale nie może to być też jedna osoba. Sytuacja taka może być wymagana gdy na przykład bank wymaga do wysłania przelewu potwierdzenia od większości udziałowców firmy. Czyli mogą to być na przykład dowolne 4 z 7 osób. Zaimplementowanie tego mając centralny serwis jest oczywiście proste. Natomiast jak to zrobić z użyciem kryptografii? Wróćmy do czasów liceum albo nawet gimnazjum (lub końca podstawówki, jeśli gimb tu nie ma :) Jedna z mniej „pożytecznych” rzeczy, która była przez bardzo długi czas wałkowana, nawet jeszcze na studiach, to wielomiany. Gdzieś w tym okresie nauki pojawiało się też twierdzenie, że przez dowolne X punktów przechodzi dokładnie jeden wielomian X+1 stopnia. Aby to dobrze zwizualizować, wyznacz dwie kropki obok siebie i spróbuj przez nie narysować kilka paraboli. Działa? Tak! Parabola jest wielomianem 2-go stopnia. Jeśli wyznaczysz gdzieś pomiędzy trzecią kropkę, okaże się, że da się tamtędy przeprowadzić jedynie jedną parabolę (bez znaczącego jej wyginania :D ) Uff, dowód matematyczny za nami.

Źródło: Wikipedia

W czym to pomoże?

Osoba trzymająca pieczę nad sejfem (lub danymi) może ustawić jako jego kod dostępu (klucz szyfrujący) miejsca zerowe wielomianu (czyli tam, gdzie linia przecina się z poziomą osią na wykresie). Wielomian taki musi być stopnia odpowiadającego ilości wymaganych osób do otwarcia lub odszyfrowania danych. Czyli jeśli będziemy potrzebowali jednoczesnej współpracy 4 osób, to musimy „wylosować” wielomian 3 stopnia. Następnie dajemy każdej zainteresowanej osobie jeden punkt leżący na tym wielomianie. Punktów możemy wylosować do woli, bez ograniczeń, gdyż taki wielomian ciągnie się od -oo do +oo, a powyższe twierdzenie działa dla dowolnych punktów. Dzięki temu jeśli znajdą się wymagane 4 osoby chcące znaleźć klucz do odszyfrowania danych, to uda im się to przez wyznaczenie miejsc zerowych wielomianu, bazującego na ich 4 punktach, przez które przechodzi ten wielomian.

Dużo danych i cyferek… wracając do przykładu potwierdzaniem przelewu w banku dla większości z 7-osobowego zarządu:

“Większość” to dowolne 4 osoby z 7
Zatem wielomian musi być stopnia 4-1, czyli trzeciego
Potrzebujemy 7 różnych punktów dla 7 różnych członków zarządu
Mając taki wielomian losujemy dowolne 7 punktów X,Y leżące na tym wielomianie, które nie są miejscami zerowymi

Zatem po spotkaniu się 4 dowolnych osób, dostają one zadanie matematyczne polegające na znalezieniu wielomianu trzeciego stopnia przechodzącego przez ich punkty i wyznaczenia jego miejsc zerowych. Dla niewtajemniczonych, miejsce zerowe to tam, gdzie wykres wielomianu przecina się z osią poziomą. Dla mniej wtajemniczonych: narysuj dowolną parabolę przecinającą oś poziomą – to tam gdzie się przecina :) Wyznaczone miejsca zerowe, na przykład po zamianie na stringi i konkatenacji stają się naszym kluczem do odszyfrowania danych.

Skomplikowane… ale z drugiej storny pomyśl o tym gdy z kolegą będziesz szukał miejsc zerowych aby gdzieś w sercu Bieszczad potwierdzić bankowi przelew, a zasięgu i komputera akurat brak ;)

Bonus: Otwarcie N z M zamków z bossem :)

Manipulując odpowiednio stopniem wielomianu oraz ilością punktów, jakie dostają poszczególne osoby możemy też przydzielić odpowiednie „wagi” tym osobom. Jeśli do dostępu do danych chcemy co najmniej jedną osobę z zarządu firmy i dowolnych 3 pracowników, lub dowolne dwie osoby z zarządu bez udziału pracowników, to każdy z zarządu może wtedy dostać odpowiednio więcej punktów leżących na wielomianie, ale w taki sposób, aby dalej brakowało mu trzech z nich.

Tak więc „boss” mający X-3 punkty potrzebuje co najmniej 3 pracowników do uzyskania klucza do odszyfrowania danych (tj. wyznaczenia tego wielomianu). Jeśli natomiast znajdzie innego „bossa”, to razem mają wręcz nadmiar punktów niezbędnych do ustalenia miejsc zerowych i odszyfrowania danych. Dzięki takiemu mechanizmowi możemy w prosty sposób kontrolować ile jakich osób będzie wymaganych do dostępu do danych.

Co jeszcze

Do powyższych metod dochodzą też sposoby na usuwanie poszczególnych posiadaczy częściowego klucza lub aktualizacje kluczy, jak również cała matematyka polegająca na określeniu złożoności i bezpieczeństwa takich kluczy. Do tego polecam już jednak bardziej techniczne dokumenty.

Większość powyższych metod jest zaimplementowana w frameworku dinemic, który za pomocą podobnych mechanizmów kontroluje i zarządza dostępem do rozproszonej bazy danych.

Wakacje Tyrol vs. Beskid Sądecki

maciej — Sun, 13 Sep 2020 09:26:12 +0000

Porównanie pobytu tu i tam, z nastawieniem na to aby nie zbankrutować i mieć fajne wakacje.

Krynica – znaleziony nocleg w pokoju 20m2 z łazienką i TV, niedaleko centrum po dość długich poszukiwaniach z widokiem na sąsiadującą plebanie. Tyrol – apartament znaleziony na Interhome, z promocją last minute. Ok. 70m2, z 3 pokojami, łazienką, w pełni wyposażoną kuchnią, TV i 3 balkonami na wszystkie strony z pięknym widokiem. Porównanie cen dla 2 dorosłych, dwójki dzieci do 6 lat, na 14 dni. Wszystkie ceny w zł.

Nocleg i mieszkanie

Austria – Zillertal		Polska – Krynica
Nocleg 2 dorosłych i 2 dzieci	2700	Mieszkanie 60m2 z kuchnią i łazienką, 3 balkony, z Interhome	2100	Pokój 20m2 z łazienką, 1 okno
Dojazd	500		70
Parking	0	Duży parking przy domu w cenie	140	10zł/dzień, płatne ekstra
Podatek lokalny	259	2,2eur za dorosłą osobę, sąsiedzi nie palą śmieciami	246	4,4zł za osobę
Razem:	3459zł		2556zł

Atrakcje

Tutaj Tyrol niestety przegrywa. Nie ma górali, na próżno również szukać parkingowych czychających za każdym rogiem, ulicznych wysokiej klasy artystów z krupówek lub misia. Rekompensuje to natomiast uprzejmość lokalnych mieszkańców. Nie pozna się też wielu ciekawych ludzi, ich kultury i historii czekając od 5 do 9 w kolejce do kolejki na Kasprowy.

Wyjazd kolejką na dużą górę	160	Ahorn, brak kolejek do wejścia, parking pod kolejką w cenie	240	Kasprowy, czekanie w kilkugodzinnej kolejce, parking i dojazd pod kolejkę ekstra
Wjazd kolejką na małą górę	ok. 70	Żeby przejechać się małą kolejką pokroju tej z Jaworzyny, trzeba najpierw wjechać na dużą górę	64	Jaworzyna Krynicka, parking gratis!
Wjazd na lodowiec	250	Hintertux, parking gratis	0	Brak lodowców
Atrakcja – punkt widokowy	32	Przejazd ponad 30km przez Hohenstrasse na ponad 2000m, w tym zwiedzanie parku świstaków, liczne wodospady, trasa nad chmurami. Opłata jedynie za wjazd samochodu. Należy doliczyć paliwo	208	Wejście na wieżę widokową z wjazdem kolejką na Jaworzynę
Wyjście na szlak	0	Niektóre fajne szlaki zaczynają się tak wysoko, że opłaca się wjechać na nie kolejką, żeby nie marnować czasu. Sporo jest też tych z samego dołu	15	Cena za wstęp na 3 korony
Parking pod szlakiem	20-40	za pozostawienie samochodu wysoko w górach, na całą dobę	20zł	Zapłacone jakiś czas temu za pozostawienie auta gdzieś na błocie, na prywatnym polu
Dojazd pociągiem do miasta	13	Zillertal bahn	13	Krynica – Piwniczna
Godzina parkingu	5	ok. 1-1.5eur blisko centrum	2	SPP w Krynicy
Dojazd do większego miasta	24	Innsbruck, 70km	38	Kraków, 130km
Jezioro z plażą i placem zabaw	22	Achensee, 4eur za 4 godziny parkingu, wstęp i atrakcje gratis	45	Kryspinów, dorośli po 15zł, auto 15zł. Jedyne znane mi jezioro, które choć trochę przypomina standardem darmowe Achensee. Dodatkowa atrakcja – Krakowskie towarzystwo
Razem	549		1153

Jedzenie

Z powodu braku kuchni pobyt w większości “apartamentów” w Krynicy wiąże się z wykupieniem wyżywienia lub chodzeniem od knajpy do knajpy. Za to w Tyrolu nie uświadczymy bezmięsnych parówek podawanych na każdą kolację na przemian z rozmoczonymi płatkami z mlekiem. Z drugiej strony w Krynicy nie musimy udawać weganina i unikać mięsa ze względu na jego ceny, możemy za to rozkoszować się własnym niezbyt smacznym jedzeniem, jeśli średnio gotujemy.

Jedzenie	1200	Przywiezione w większości kupione gotowe, konserwowe dania.	2100	Wykupione w pensjonacie, porównywalnej jakości do konserw wywiezionych do Austrii
Kilo mięsa	40-50	Lokalne sklepy nie mają dużego wyboru, zwykle pakowane kawałki kurczaka lub świni	15-25zł	Zwykle nie ma na czym ugotować
Kawa na mieście W dobrej kawiarni/knajpie	15		12
Kawa w trasie w schronisku lub na górnej stacji kolejki	16		10
Dobry chleb żytni	6		6
Szynka, 100g Pakowane w plasterkach, tanie coś, bez makulatury w składzie	8		5
Masło	5		5
Jajka, 20szt	20		15
Słodka bułka	5	Croissant	3	Drożdżówka z makiem
Razem:	ok. 1300		ok. 2153

Powyższe ceny są orientacyjne. Niektórzy chcą pozostać przy diecie “polskiej”, inni będą wcinać lokalne specjały, które są droższe, a jeszcze inni zmontują obiad z tego, co jest lokalnie najtańsze. Warto też wiedzieć, że większość knajp w Tyrolu ma zwykle kilka miejsc parkingowych dla gości gratis.

Inne

Diesel	4,7	4,2
Benzyna	4,9	4,5
LPG	3,5	2,2

Jak widać, może mamy wysokie podatki, ale za to ceny są wyższe :) Atrakcje również nieporównywalnie wyższe, co za tym idzie człowiekowi nawet przez myśl nieprzejdzie rozkoszowanie się widokami gór, na które w Tyrolu żeby popatrzeć, trzeba odginać głowę do góry. W Polsce to nie grozi, bo co chwile schyla ją do portfela po kolejne opłaty to tu to tam.

Jadąc za granicę opłaca się wybrać w więcej osób. Zwykle apartamenty kosztują tyle samo niezależnie od ilości gości, co w Polsce jest żadkością i kasuje się od głowy.

Czemu mi srand nie działa

maciej — Fri, 26 Jun 2020 09:37:47 +0000

Czasami człowiek spędzi dwa tygodnie na durny błąd, którego testy ani wszelkie debugowanie w żaden sposób nie zweryfikują. O co poszło tym razem? Wcisnąłem parę dinemic i jego wrapper dla pythona do Flaska. Ot co, alternatywa dla ORM Django i SqlAlchemy, w dodatku nie trzeba się martwić o uprawnienia, wewnętrzne API i tak dalej…

Wszystko szło dobrze, natomiast po dłuższym użytkowaniu zauważyłem, że czasami obiekty w bazie nie chcą się tworzyć, może w 1 na 10 lub na 20 przypadkach. Winny oczywiście Sync processor, który prawdopodobnie miał lukę gdzieś w zawiłej logice odpowiedzialnej za procesowanie zmian w klastrze. Zwykle takich problemów nie ma, gdy za każdym mikroserwisem stoi baza danych i tylko ten mikroserwis ją modyfikuje (ewentualnie kilka jego wątków, korzystając z locków). Dinemic daje nieco inne podejście, gdzie każdy może rozesłać zmianę bazy, a dopiero logika naszego programu ma stwierdzić, czy taką zmianę akceptuje, czy nie. W praktyce, ciąg zmian związany ze stworzeniem i cyklem życia obiektu zamiast tak:

wygląda tak:

Każdy bloczek w powyższym to mała wiadomość wędrująca po całym klastrze z informacją np. w polu A zmień wartość na X. Kto ją dostanie, może zaaplikować u siebie, zweryfikować podpis obiektu, który zmianę wykonał lub sprawdzić ciągłość całego łańcucha (lub drzewka). Taka komplikacja frameworka miała na celu umożliwienie pracy w niekonsystentnym środowisku, na rozproszonej bazie. Czemu zmiany są aż tak pokomplikowane? Pomyśl, że chcesz się umówić na piwo z 10 znajomymi. Wysyłasz wszystkim SMS, że w piątek o 20 idziecie na piwo. 6 odpisze, że ok, 1 w między czasie umówi się na inne piwo i za godzine odpisze, że jest zajęty, a pozostałych trzech jest poza zasięgiem. To jesteście umówieni? Na piwo trzeba iść, a z pozostałą czwórką umówić się w innym terminie lub skontaktować inaczej. Zwykle rozwiązanie zależy od “mózgu” operacji i tego co zrobi z pozostałą czwórką. Ot, takie życie. Podobne założenia były w dinemic – kto dostanie informacje o zmianie w bazie, ten (jakoś) zareaguje, a kto nie dostanie, ten musi radzić sobie sam. W takiej architekturze już na wstępie mamy mocno niekonsystentną bazę w obrębie klastra, a jedyne co powinno się zgadzać to cała historia zmian.

Wróćmy do naszych wiadomości o zmianach (sms z zaproszeniem na piwo). Jako, że wspólnego, konsystentnego indeksu nie mamy, to każda zmiana ma losowy ID, do tego hash poprzedniej zmiany oraz swój podpis. Problem z Flaskiem rozpoczął się dość niewinnie – jakby niektóre zmiany nie były poprawnie procesowane i ignorowane. Po prostu system twierdził, że wiadomość była już przetworzona.

Wróćmy na chwilę do Flaska i tego, jak działa serwer www. Flask przy uruchamianiu serwera przez skrypt pythona tworzony jest główny wątek. W nim można m.in. zainicjalizować framework dinemic (lub cokolwiek innego) i przygotować wszystko co potrzeba do odpalenia serwisu. Po otrzymaniu nowego połaczenia od klienta serwer tworzy proces potomny i w nim obsługuje request.

Niby proste, a jednak nie. Jeśli wszystko inicjalizujemy w głównym wątku, to również generator liczb losowych (pseudolosowych), czyli srand(time(NULL)). Niezależnie od tego jaką wartość podamy do srand, to powinien dać pseudolosowe liczby, o dobrym rozkładzie. Jeśli jednak zainicjalizujemy go dwukrotnie tą samą wartością, to zawsze dostaniemy taką samą serię liczb.

W czym zatem problem? Srand inicjalizujemy w głównym wątku i generuje on X liczb pseudolosowych. Dla każdego klienta Flask tworzy nowy wątek, w którym również potrzebne są nowe liczby losowe (bo na przykład każdy update generowany w takim wątku potrzebuje swoje ID). Czym to skutkuje? Po forku proces potomny generuje X+1 liczbę losową. Dla drugiego klienta fork również generuje liczbę, uwaga uwaga: X+1. I tak dalej… rand wypluwa zawsze pseudolosową, kolejną liczbę z generowanego ciągu. Jeśli skopiujemy proces (przez fork, pthread z odseparowaną pamięcią lub jakikolwiek sposób), to licznik zaczyna się dublować z innymi procesami. W ten sposób każdy proces potomny dostaje ten sam ciąg kolejnych liczb pseudolosowych, dla danej wartości początkowej z srand.

Dzięki temu możnaby ze 100% skutecznością zgadywać z procesu-brata jakie liczby wylosuje drugi proces. Na zakończenie warto jeszcze opowiedzieć jak udało się to rozwiązać (chociaż po znalezieniu problemu nie było to trudne). Rand z C++ został zamieniony na generator liczb losowych z libsodium. Praktycznie bez zmiany logiki, algorytmów i dużego grzebania w kodzie. Dużym plusem jest to, że libsodium nie wymaga inicjalizowania generatora liczb pseudolosowych i zwraca za każdym razem losowe wartości, co w przypadku biblioteki takiej jak dinemic ma duże znaczenie – nigdy nie wiadomo czy aplikacja macierzysta nie zacznie się forkować.

Ot, głupi błąd, 2 tygodnie szukania i przy okazji zrefactorowany najpaskudniejszy kawałek logiki frameworka.