Wpisy

Opublikowane w

GitHub backup

Od dłuższego czasu poruszany jest w różnych miejscach temat niezależności technologicznej od firm z… innych obszarów prawnych, że tak to ujmę. W szczególności chodzi o firmy spoza Europy. Jest też – nieco niezależny, choć w praktyce często zbieżny – temat uniezależnienia się do wielkich korporacji. Bo jakoś tak się złożyło, że wielkie korporacje nie są europejskie.

Przyznaję, że kibicuję obu tematom. I o ile nie czuję, że muszę koniecznie już teraz przenieść wszystkie zabawki do Europy, to… chcę mieć w razie czego taką możliwość. Pomału się rozglądam, wykonuję pewne drobne – póki co – ruchy. W szczególności jeśli z jakiegoś powodu rezygnuję z jakiejś usługi, to szukam alternatywy w Europie.

Tyle kontekstu, ale przecież miało być o backupie GitHub. Jak powszechnie wiadomo, jest to usługa Microsoftu, czyli podlegająca prawu USA. I w dodatku należąca do jednej z największych korporacji na świecie. Znaczy mogą zrobić z kodem co chcą, w tym… zniknąć go. Zamknąć dowolne konto. Usunąć dowolne repozytorium (i wszystkie jego forki). Bo tak.

Zapewne się to nie wydarzy, jeśli chodzi o moje repozytoria ale… Nie wiadomo. Bo już różne rzeczy były z GitHub usuwane. Więc ktoś kiedyś może wpaść na pomysł, że np. bruteforce PESELi to groźne narzędzie i trzeba repozytorium – albo i całe konto – usunąć. Wolę więc mieć możliwość przywrócenia swojego kodu z backupu. Backup serwerów i tak robię, wiele własnego kodu nie mam. Więc zrobienie kopii repozytoriów do katalogu, który jest objęty backupem wygląda jak proste, lekkie rozwiązanie.

Jeśli chodzi o ewentualne zastępstwo dla GitHuba, wybrałem popularną alternatywę w postaci europejskiego Codeberg.org[1]. Na którym i tak założyłem już wcześniej konto z uwagi na pewien pull request, który chciałem zrobić.

Repozytoriów trochę mam, są one publiczne, więc postanowiłem zautomatyzować robienie backupu, żeby nie musieć pamiętać o dodaniu każdego nowego repozytorium do skryptu robiącego backup. Po prostu robię backup wszystkich publicznych repozytoriów należących do danego użytkownika GitHub. Oczywista konsekwencja – i wada rozwiązania – jest taka, że jeśli zrobię fork jakiegoś większego projektu, to także on trafi do backupu. Jednak nie jest to częsta sytuacja, a nawet te większe projekty nie są aż tak duże, żeby mi to przeszkadzało.

Skrypt github-backup jest – jak widać – bardzo prosty. Wymaga zewnętrznego programu git i tylko jednej biblioteki – requests. Zasada działania skryptu github-backup jest prosta. Przechodzimy do katalogu ze skryptem. Podajemy usera jako parametr. W katalogu, w którym jest uruchamiany skrypt, najpierw tworzony jest katalog o takiej nazwie, jak nazwa użytkownika[2]. Następnie pobierana jest lista publicznych repozytoriów użytkownika. A w końcu dla każdego z nich tworzona jest kopia przy pomocy zewnętrznego polecenia git clone –mirror. I tyle. Tak utworzone kopie można przywrócić na innym serwerze przy pomocy git push –mirror. Przykład w readme.

Skrypt ma wady, których nie potrzebowałem poprawiać. Po pierwsze, robi mirror do bieżącej lokalizacji. Nie jest to problem przy planowanym użyciu, czyli z użyciem cron – po prostu wcześniej trzeba zmienić katalog. Po drugie, nie obsługuje prywatnych repozytoriów. Cóż, trochę nie miałem takiej potrzeby. Poza tym, o ile dodanie klucza, który ma do nich dostęp w trybie odczyt nie jest problemem, to nad listowaniem musiałbym się zastanowić[3]. Może kiedyś, bo jak wspomniałem, obecnie nie mam takiej potrzeby.

Plany rozwoju skryptu? Dodanie obsługi innych platform przydało by się najbardziej, bo żaden dostawca ani jurysdykcja nie dają gwarancji, że konto czy repozytorium nie zniknie. Przy czym pewnie w najbliższej przyszłości skończy się na Codeberg, bo tylko tego aktualnie używam i będę miał jak przetestować. Może jednak dodanie obsługi prywatnych repozytoriów?

W każdym razie jeśli rozwiązanie komuś się przyda, to zachęcam do używania. I oczywiście robienia backupów, w tym przypadku własnego kodu. Niezależnie od metody.

UPDATE: To naprawdę prosty skrypt i główną zaletą jest brak potrzeby jakiegokolwiek uwierzytelniania, jeśli ktoś potrzebuje więcej, to istnieje np. ghorg.

[1] Ogólnie jest to serwis godny rozważenia, choć community o wiele mniejsze.
[1] Uwaga, najpierw jest usuwana cała zawartość katalogu o takiej nazwie, jeśli istnieje!
[2] No dobra, sprawdziłem, wystarczy dodać obsługę PAT (personal access token) i stosownie skonfigurować ich uprawnienia.

Opublikowane w

Krzyk Czarnobyla

Raczej nie piszę o przeczytanych książkach. Ostatnio przeczytałem[1] jednak książkę Czarnobylska modlitwa. Kronika przyszłości i uznałem, że zasługuje na wpis. Zacznijmy od tego, że nie wiedziałem, czego się spodziewać. Nie znałem ani – nieco kontrowersyjnej – autorki, choć noblistka, ani tytułu. Oczywiście sama nazwa Czarnobyl dawała jasną wskazówkę.

Szybko nadrobiłem zaległości na Wikipedii, dowiedziałem się też, że pierwotnie książka została wydana jako Krzyk Czarnobyla. Nadal nie wiem, czy to nie lepszy tytuł. Stąd oczywiście tytuł wpisu.

Zniszczony reaktor w Czarnobylu
Zniszczony blok reaktora w Czarnobylu Zdjęcie autorstwa IAEA Imagebank – 02790015, CC BY-SA 2.0

Książka powstała na podstawie wywiadów z ludźmi i pokazuje awarię (mniej) i jej skutki (bardziej) z perspektywy różnych ludzi, głównie mieszkańców Białorusi. Różnych ludzi. Bardzo różnych. Są rodziny ofiar, są likwidatorzy, osoby, które zostały w strefie, są wysoko postawieni działacze, naukowcy, lekarze… Sporo tzw. zwykłych ludzi.

Czego się dowiedziałem, o czym nie wiedziałem? Przede wszystkim, przed lekturą miałem wrażenie, że skażenie obejmowało strefę powiedzmy małych kilkudziesięciu km i dotyczyło wyłącznie Ukrainy. Tymczasem najbardziej w wyniku skażenia ucierpiała Białoruś (nawet 20% powierzchni kraju).

Kolejna rzecz, o której nie wiedziałem, to fakt, że awaria i jej skutki były zatajane przed ludnością. Nie chodzi tylko o likwidatorów, którzy w prowizorycznych ochraniaczach (albo i bez nich) walczyli z bezpośrednimi skutkami wybuchu. O ile w Polsce poinformowano o awarii i podano ludziom roztwór jodu[2], to w ZSRR tego nie zrobiono. Nawet, gdy były możliwości.

Zupełnym zaskoczeniem była dla mnie liczba ludzi zaangażowanych w skutki usuwania awarii. Myślałem, że mówimy o setkach, może tysiącach…

Jest też trochę szokujących informacji o tym, jak wykonywano plan, czyli siano, sadzono ziemniaki i przetwarzano skażone mięso. Były nawet instrukcje jak postępować przy określonym poziomie skażenia. Jest też o chciwości jednostek – domy ze skażonej strefy były szabrowane, a nawet rozbierane i przewożone w inne miejsca kraju, by je sprzedać. Podobnie samochody. Skoro mowa o chciwości – warto pamiętać, że reaktory RBMK, czyli typu używanego w Czarnobylu, były najbardziej efektywnym typem. Choć też najbardziej niebezpiecznym.

W książce znaleźć można sporo krytyki ZSRR i polityków czy też raczej rządzących. Sporo o działaniach, by się komuś nie narazić, sporo o tak trzeba. W tym o ignorowaniu procedur i braku poszanowania dla ludzkiego życia.

Nie jest to lekka lektura, znaczna część to opisy chorób, śmierci itd. Podczas lektury miałem trochę skojarzeń z pandemią i wrażenie, że niczego się – jako ludzkość – nie nauczyliśmy. Ani na poziomie zachowań pojedynczych ludzi, ani w kwestii przygotowania służb, ani działań na poziomie państwowym, ani informowania społeczeństwa. Podobny jest też podział na przed pandemią i po pandemii, tak jak przed katastrofą i po katastrofie.

Zdecydowanie warto się zapoznać, choć jest to też książka uświadamiająca jak niebezpieczna jest energia jądrowa. I o tym, że mimo zabezpieczeń, różnego rodzaju wypadki będą się zdarzać. Ludzie popełniali, popełniają i będą popełniać błędy.

Niezwiązana z książką informacja, ale: akurat gdy skończyłem lekturę, dotarła do mnie informacja, że w wojnie w Ukrainie została zabita żona pierwszej ofiary awarii w Czarnobylu.

[1] Tak naprawdę przesłuchałem audiobooka w Legimi. Kiedyś rozdawali sporo kodów, a nie zawsze chcę używać oczu i wtedy ich używam.
[2] Możliwe, że w Polsce było to zbędne, ale nie zaszkodziło.

Opublikowane w

Dezinformacja

Dezinformacja to coś, co działa w różne strony. Dziś spotkałem się z dezinformacją wymierzoną przeciw Chinom. A w zasadzie chińskim pojazdom. Zaczęło się od social mediów i informacji:

A Norwegian bus company wants to know if their buses could be abused by China in the case of war.

So they drive two buses deep into a limestone mine to isolate them from the internet and forensically investigate how they work.

In the mine, investigators discover a Chinese kill switch which could destroy all Chinese buses.

No sensacja na miarę afery Newagu, który umieścił w oprogramowaniu blokadę wymierzoną przeciw innym serwisom, prawda?

Tylko, że niekoniecznie. Oryginalny, podlinkowany artykuł, w mało popularnym języku (pszypadek? nie sądzę) twierdzi bowiem rzeczy dokładnie odwrotne (Google Translate):

Na przykład, czy możliwe jest, aby chiński rząd uzyskał dostęp do licznych kamer w autobusach miejskich, gdyby pewnego dnia, w nie do pomyślenia przyszłości, chciał wykorzystać je do monitorowania na przykład Chińczyków w Norwegii? Tor Indstøy i jego zespół nie znajdują na to żadnych dowodów. I to jest pozytywne. Ale odkrywają coś jeszcze. Chiński autobus elektryczny zawiera komputer, który między innymi steruje akumulatorem i silnikiem autobusu, aby autobus mógł jak najefektywniej poruszać się po Oslo. Komputer ten – za pośrednictwem małej karty SIM – jest podłączony do internetu, dzięki czemu może wysyłać informacje, a czasami pobierać aktualizacje. Bo tak, autobus można aktualizować dokładnie tak samo, jak telefon. Śledczy doszli do następującego wniosku: taka aktualizacja umożliwia chińskiej firmie stworzenie funkcji, która całkowicie uniemożliwia jazdę autobusowi. Ponownie musimy wyobrazić sobie przyszłość, w której nasze relacje z Chinami będą bardziej napięte niż obecnie, a chiński rząd chce doprowadzić do upadku Oslo, blokując kilkaset autobusów miejskich na środku ulicy w godzinach szczytu. To prawdopodobnie się nie wydarzy. Ale może się wydarzyć.

Czyli nie znaleziono funkcji szpiegujących. Nie znaleziono – dokładnie odwrotnie, niż w przypadku afery Newagu – killswitcha umożliwiającego unieruchomienie sprzętu. To, co znaleziono, to jedynie łączność i możliwość pobierania aktualizacji. Typowe funkcjonalności.

Oczywiście, każda aktualizacja oprogramowania może całkowicie zmienić jego działanie. Czy to w sposób zamierzony, czy niezamierzony – w wyniku błędnej aktualizacji urządzenie może przestać działać. Ale czy o każdym pojeździe z łącznością poprzez kartę SIM i aktualizacją softu napiszemy, że ma killswitcha? Czy systemy Windows i macOS mają killswitcha? Android? iOS? W końcu czy killswitcha ma mój Debian, na którym zainstalowałem unattened-upgrades? Nie, nikt rozsądny tego w ten sposób nie nazwie.

Tymczasem lawina dezinformacji i antychińskiego FUD ruszyła i np. polskie (ale nie tylko) media krzyczą już nagłówkami w stylu Chińskie autobusy mogą być zdalnie sterowane. Szokujące wyniki testu czy Chińczycy mogli sterować autobusami w Danii? Te same pojazdy jeżdżą w Polsce. No i oczywiście po drodze już dorobiły się killswitchy.

Warto sprawdzać źródła[1], tym bardziej, jeśli w grę wchodzi lobbing, kontrakty na sprzęt i duże pieniądze.

I dla jasności, doceniam model zagrożeń, który przewidują Norwegowie. Uważam, że urządzenia (nie tylko pojazdy, instalacje fotowoltaiczne czy lodówki też mogą dać bardzo ciekawe efekty) generalnie nie powinny mieć dostępu do sieci, a użytkownik powinien mieć możliwość samodzielnego decydowania fakcie i czasie wykonywania aktualizacji. Czym może się skończyć aktualizacja w nieodpowiednim momencie – wiadomo.

Warto też zwracać uwagę na ile bliskie politycznie są firmy mające kontrolę nad urządzeniami. Bo czy np. Tesle w Europie mogą szpiegować kamerami? Czy mogą dostać oprogramowanie, które w określonych okolicznościach uniemożliwi otwarcie drzwi, zablokuje możliwość kierowania i rozpędzi pojazd do maksymalnej prędkości? Cytując artykuł: To prawdopodobnie się nie wydarzy. Ale może się wydarzyć.

[1] Tak, mam świadomość, że duński artykuł powstał na bazie norweskiego. Niestety, paywall.