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.

Planeta – reaktywacja

Po nieco ponad kwartale od zatrzymania Planety Joggera, dojrzałem do jej przywrócenia. Nie jest to ta sama planeta, co wcześniej. Główna zmiana to silnik. Skręciłem w stronę o której pisałem czyli prosta planeta, gdzie będą tylko tytuły i daty wpisów. Może tekstowy fragment opisu, bez formatowania HTML.

Zmiana silnika spowodowała też parę zmian. Jest też kilka niedoróbek:

  • Lista blogów w stopce jest generowana dynamicznie. Tylko jeśli uda się pobrać feed, to blog się pojawi na liście źródeł. Wynika z pewnego uproszczenia działania po stronie silnika, może kiedyś zmienię. Albo może i nie zmienię, bo po co oszukiwać, że wpisy z danego źródła są pobierane, skoro nie są?
  • W przeciwieństwie do poprzedniej wersji nie są prezentowane pełne wpisy, a jedynie zajawki. Czyli wykorzystuję pole description z feedu. Powodów jest wiele, ale w sumie przy poprzedniej wersji była sugestia, żeby właśnie tylko zajawkę dawać i… wg mnie jest OK.
  • Nie będą pojawiały się obrazki/zdjęcia. Trochę jest to pokłosie punktu wyżej, a trochę ze względu na bezpieczeństwo.
  • Nie działa feed planety (choć jest linkowany). Nie zrobiłem na razie, ale będzie.

Z niewidocznych zmian: wylatuje kontener LXC, nie ma całego Planet Venus. Nie ma cache. Całość to obecnie jest jeden plik konfiguracyjny (YAML), dwa pliki template i jeden plik z kodem (Python). Uruchomić z crona, najlepiej z wykorzystaniem venv i… to wszystko. Działa szybciej. KISS

Jeśli chodzi o jak to jest zrobione, to silnik – albo raczej: silniczek – opublikuję wkrótce. Na razie przetestowałem działanie ręcznie, teraz uruchomiłem automatyczne odświeżanie z crona. Jeśli zauważycie błędy liczę na informację. Gdy wszystko będzie działało i dorobię generowanie feedu planety, wtedy publikacja kodu. Repo nanoplanet – chwilowo puste – już linkuję, żeby nie musieć aktualizować wpisu.

Dajcie znać jak się podoba i czy widzicie jakieś usterki.

abcc3.py

Wieki po projekciku, który robiłem w ramach projektu DSP2017, po którym chyba już nic w sieci nie zostało, doznałem natchnienia. Stwierdziłem, że teraz jest łatwo, można popytać LLMa, więc może łatwiej będzie znaleźć bibliotekę do ping pod Pythonem. Ostatnio opornie to szło…

Nie zawiodłem się, podał od ręki, wraz z kodem. Oczywiście przerobiłem, by bardziej pasowało. Przy okazji przy testowaniu (w zasadzie: testach uruchamiania) wynikło trochę błędów, które poprawiłem.

Po co to zrobiłem? Nie wiem. Chyba dla porządku. Drażnił mnie ten Python 2 w wymaganiach. A wyrzucić szkoda było. Chociaż raczej nikt nie używa. Choć IIRC ktoś się przymierzał, ale nie chciał poświęcić czasu, tylko „zrób mi”. Oczywiście za darmo. Trochę nie miałem czasu, weny i… to tak nie działa.

Warto po latach przypomnieć czym jest abcc? Na dzień dzisiejszy to rzeźbiarstwo figurowe – program do wybierania najlepszego łącza z kilku dostępny z wykorzystaniem zadanych wag, na podstawie strat i opóźnień. W sumie kiedyś, w czasach routerów na Linuksie miało to sens. Chociaż nic nie stoi na przeszkodzie by i dziś podpiąć dowolny skrypt i sterować np. przy pomocy SNMP routerem operatorskim. Istniało komercyjne rozwiązanie, które mniej więcej robiło to samo. Oczywiście z ładnym inferfejsem i opakowaniem.

Albo można użyć na jakimś OpenWrt do balansowania łącza czy też raczej wyboru lepszej ścieżki do danej sieci. Bez BGP, na podstawie wyżej wspomnianych metryk. Przy LTE itp. może być użyteczne.