gocryptfs

Dawno, dawno temu przestałem używać EncFS. Przestałem z kilku powodów. Po pierwsze, pojawiło się ostrzeżenie o tym, że nie jest to rozwiązanie do końca bezpieczne. Niby nic i w moich zastosowaniach nie przeszkadzało[1], ale jakaś tam zadra w pamięci i niechęć zostały. Po drugie, zwykłe dyski zacząłem szyfrować „normalnie” przy pomocy LUKS. A backupy itp. przy pomocy GPG. Dziś odkryłem godnego następcę: gocryptfs.

Mimo zmian w używanym szyfrowaniu, po EncFS została jedna dziura: dyski zdalne typu Dropbox czy Google drive. Miło by było móc z nich korzystać „normalnie”, ale tak, żeby dane na tych dyskach były zaszyfrowane. LUKS tu nie pomoże, bo działa dla dysków lokalnych. Szyfrowanie przez GPG dla pojedynczych plików jest niewygodne, a pakowanie w jakieś archiwa jest dobre do backupów, nie do normalnego korzystania. EncFS jako overlay dostępny poprzez FUSE ze swoim szyfrowaniem per katalog był idealny. Nie trzeba z góry określać rozmiaru szyfrowanych danych, dostęp online do pojedynczych plików, z zachowaniem ich struktury.

Okazuje się, że jest godny następca dla EncFS i nazywa się gocryptfs. Nie wiem czemu nie znalazłem go wcześniej. Może odrzuciłem, bo był świeży i w golang? Może przeważył brak realnej potrzeby?

W każdym razie: jest i wygląda bardzo dobrze. Przeczytałem opis projektu i zasadę działania. Posiada sensowne założenia, był audytowany, brak przypadłości EncFS. Do tego jest bardzo szybki. Instalacja w Debianie z pakietu – żadnych kompilacji. Do tego świetna dokumentacja, proste użycie i… dopracowanie. Oczywiście open source. Działa na Linuksie, macOS, istnieją nieoficjalne porty dla Windows i Androida.

Żeby przybliżyć o czym mowa. Weźmy takie utworzenie szyfrowanego katalogu. Jedno proste polecenie, podajemy hasło, powtarzamy je i… dostajemy master key, wraz z przeznaczeniem i jak się z nim obchodzić. Aż pokażę[2], bo na stronie tego nie ma:

$ gocryptfs -init cipher/
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

d28966ae-f39ff48a-695993f9-a5e354eb-
3d31e7a1-29c834c5-31b2cb3b-b38b6cec

If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipher MOUNTPOINT

Prawda, że piękne? Bardzo możliwe, że przyda się i wkrótce wrócę do tematu zdalnych dysków.

[1] Moje zastosowania: nie będą mi dyski sieciowe w stylu Dropbox grzebać po plikach, nawet jeśli nic tajnego tam nie ma.
[2] Jakby ktoś zaczynał panikować, że „ojej, master key podał” to spieszę donieść, że to z testowego katalogu utworzonego na potrzeby tego wpisu, żadnych danych tam nie ma i nie będzie.

Dostęp tymczasowy

Zaczęło się niewinnie, bo od obrazkowego komentarza. Kumpel DJ pochwalił się w firmie, że okazyjnie kupił mixer, więc jako komentarz poleciała od razu stosowna scena z filmu Nienawiść (La Heine):

DJ scene La Heine

Fanem francuskiego hip-hopu/rapu nie jestem, ale… jest trochę kawałków, które doceniam. Albo wręcz lubię. Przypomniało mi się, że całkiem niedawno odkryłem pewien godny uwagi kawałek i chciałem się nim podzielić.

Tylko był „drobny” problem – nie pamiętałem ani tytułu, ani wykonawcy. Co gorsza, zupełnie nie kojarzyłem, kiedy go ostatnio słyszałem na liście na Spotify. Więc się nie podzieliłem.

Jednak nie dawało mi to spokoju. Stwierdziłem, że może dodałem go jeszcze w Tidalu, a migracja playlisty ciągle czeka, podobnie jak wpis na ten temat, więc może jest tam? Zalogowałem się na Tidal i… zaczęło się przeglądanie.

Mam tam ponad pięćset utworów w jednym worku. Niby jest chronologiczna kolejność dodawania do listy, ale jakoś nie kojarzyłem, kiedy dokładnie dodałem ten utwór. W trakcie przeglądania zwróciłem uwagę na coś innego. Niektóre utwory były oznaczone innym kolorem. I nie dawały się odtworzyć. Początkowo sądziłem, że to jakiś problem techniczny, konieczność załadowania z wolniejszego storage albo covery, które w jakiś sposób łamią prawa autorskie, bo dotyczyło to raczej niszowych utworów.

Jednak nie. To samo dotyczyło oryginalnych utworów pewnych, zupełnie nie niszowych, wykonawców. I – z tego co zaobserwowałem – raczej właśnie całej twórczości artysty, a nie poszczególnych kawałków. Czyli w Tidal mamy dokładnie tę samą sytuację, co np. w Netflix: płacimy jedynie za możliwość korzystania z platformy w danym okresie czasu. Nie kupujemy dostępu do konkretnej treści. Nie mamy żadnej gwarancji, że za parę miesięcy będziemy mogli posłuchać naszych ulubionych utworów. Ani że nasze playlisty będą takie, jakimi je stworzyliśmy[1].

W przypadku filmów powiedzmy, że istnieją jakieś przesłanki techniczne, żeby ograniczać ilość contentu. Jednak muzyka jest znacznie mniejsza. Licząc na bogato 5MB na utwór, tysiąc kawałków to raptem 5 GB. Wrzucam to na telefon – o komputerze nie wspominając – i nawet nie zauważam zużycia miejsca…

Oczywiście nie chodzi o przyczyny techniczne. I nie powinienem być zaskoczony. Artysta zerwał umowę z platformą, więc utwory nie są dostępne, proste. Ale jestem zaskoczony, bo o ile filmy nie są „legalnie” dostępne wszędzie, w tym na największym pirackim portalu, to muzyka jak najbardziej dostępna jest. Czyli mamy paradoksalną sytuację, że płacąc nie dostaniemy dostępu do rzeczy, które są dostępne za darmo.

Czy coś w związku z tym zamierzam zrobić? Z płatnych platform nie zrezygnuję, bo jestem na doczepkę, z rodziną, a pod wieloma względami są wygodne. Ale zapewne zacznę zbierać muzykę offline. Przynajmniej to, co trafia do ulubionych na platformach streamingowych. Niekoniecznie na żywo, ale okresowa synchronizacja, raz na kwartał – czemu nie?

Na pewno motywuje mnie to też do uruchomienia – w końcu – self hosted storage. Pewnie jakiś Nextcloud. Zresztą, w przypadku muzyki mówimy o ilościach danych, które mieszczą się na darmowych dyskach webowych – zwykle dostępne jest 10-20GB za darmo.

Utwór, którego szukałem, ostatecznie znalazłem. Po prostu przypomniałem sobie tytuł na tyle, że wpisanie w wyszukiwarkę pozwoliło go znaleźć. Okazało się, że przeoczyłem go na liście w Tidalu, choć był chronologicznie dokładnie tam, gdzie się go spodziewałem.

La Rage – Keny Arkana

Cloud is fraud!

[1] Tzn. playlisty będą istniały w oryginalnej, tylko nie będzie można ich odtworzyć w pierwotnej formie, bo nie będzie „wsadu”.

Zmiany we free tier w Google Cloud Platform

Tytułem wstępu: Google ma swoją chmurę, czyli Google Cloud Platform, a w ramach niej coś takiego jak free tier, czyli zasoby dostępne bez opłat[1]. Zasoby są niewielkie, dodatkowo podlegające pewnym ograniczeniom, raczej do zabawy. Ale do testów, nauki czy właśnie zabawy – idealne. Między innymi można mieć uruchomioną w ramach compute engine najsłabszą VMkę, czyli f1-micro.

Mail

Jeśli ktoś korzysta z GCP, to zapewne dostał już maila. Dla tych, co maila przeoczyli, krótkie podsumowanie. Od pierwszego sierpnia 2021 instancje e2-micro są bezpłatne (w określonej ilości czasu), natomiast od pierwszego września instancje f1-micro będą płatne. Regiony pozostają bez zmian. Instrukcja zmiany linkowana w mailu dostępna jest tu.

To różne platformy, więc ciężko porównać dokładnie, ale:
f1-micro to 0.2 VCPU i 0.6 GB RAM w cenie $0.0076 (us-central1)
e2-micro to 0.25 VCPU i 1 GB RAM w cenie $0.008376 (us-central1)
Dodatkowo w przypadku e2-micro możliwy jest burst do 2 VCPU.

Google pisze[2]:

As we improve the experience of the Free Tier, we will be introducing the E2-micro VM, which is a part of a second generation VM family.

Wydajność

W przypadku RAM zysk jest oczywisty, natomiast w przypadku CPU – niekoniecznie. Wiele zależy od tego, na jakiej platformie CPU znajduje się obecnie VMka, i na jakiej wyląduje po przeniesieniu. Tabela platform CPU dla serii N1 i E2 jest dość skomplikowana. Jednak patrząc na base frequency, przeciętnie powinno być szybciej.

I jeszcze wynik cat /proc/cpuinfo z mojej instancji f1-micro:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping : 0
microcode : 0x1
cpu MHz : 2299.998
cache size : 46080 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology n$
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips : 4599.99
clflush size : 64

Jak się zmigruję to uzupełnię wpis, co dostałem po migracji i jak wrażenia.

Migracja

Wczoraj zmigrowałem maszynę na e2-micro. Migracja błyskawiczna i bezproblemowa. Zgodnie z instrukcją zatrzymać instancję, wyedytować typ, zapisać zmianę, uruchomić maszynę.

Po migracji dostałem dokładnie ten sam procesor. Tyle, że teraz cat /proc/cpuinfo pokazuje dwa. Jeśli chodzi o osiągi i wydajność w praktyce, to najlepiej widać to na obrazku.

Wykorzystanie CPU na f1-micro i po migracji na e2-micro w GCP free tier
Wykorzystanie CPU na f1-micro vs e2-micro

Migracja chwilę przed 12:00, później wzrost obciążenia spowodowany porządkami, chwilę po 18:00 koniec ostatnich ręcznych prac. Jak widać, główny zysk wynika ze wzrostu mnożnika z 0.2 do 0.25 VCPU. Ponieważ przydział jest dynamiczny, procesy jednowątkowe także skorzystają na zmianie parametrów.

Podsumowując, warto migrować, bo e2-micro w stosunku do f1-micro oferuje 66% więcej RAM i 25% więcej CPU.

[1] Wymagane jest podpięcie karty debetowej, a po przekroczeniu puli darmowych zasobów jest automatycznie naliczana opłata za przekroczoną część.
[2] Nawiasem, wysłaniem tego maila Google Cloud Platform zdobyło u mnie sporo punktów sympatii. Mogli przecież np. zamieścić info o zmianie cenników free tier na blogu i billować nieuważnych, albo wysłać suchego maila o zmianach w cenniku. Wiele firm tak właśnie by postąpiło. A tu osobne, czytelne powiadomienie, z instrukcją migracji. Miło.