Ponad rok na Kali Linux z punktu widzenia 15 lat pracy na Ubuntu Linux

Kali Linux, jak każda dystrybucja bazująca na Ubuntu Linux, który z kolei bazuje na bazie Debian Linux to sprawa dość nieskomplikowana w codziennym użyciu dla DevOps, developerów i adminów. Linux kernel, jest tam aktualizowany, można używać pełnego zestawu narzędzi wizualnych np: gnome i to się spina bez bólu na desktopie. Nie zauważymy różnicy na desktopie w codziennym użytkowaniu.

 

Nie to jednak jest w Kali Linux fajne i praktyczne, że działa podobnie do Ubuntu Linux. Jak większość z was wie, Kali Linux stał się ulubioną dystrybucją: ludzi z gimnazjum, "hackjerów" ;-), white hackerów, testerów penetracyjnych,  red teamów i wielu innych profesji skoncentrowanych wokół bezpieczeństwa systemów i aplikacji w IT, ale też amatorów różnych rozrób i problematycznych sytuacji. 

To jest temat na odrębny wątek, jak ludzie - w tym dzieci - mogą uszkodzić coś lub wpaść w kłopoty, kiedy "przyhaczą" coś na Kali Linux. 

Musimy zdawać sobie sprawę, że z natury zawód związany z tzw. SECURITY w IT to ludzie często na tyle zaawansowani technicznie, że żarty to nie jest ich główne zajęcie a niesamowite analizy włamań/malware/trojanów/wirusów/skany sieci/diagnozy powłamaniowe/predykcje ryzyk/odkrywanie ukrytych otwartych portów i usług/szybkie i trafne decyzje. Szacunek! 

Natomiast, kiedy czasami czytam i słucham różnych opowieści, jak przysłowiowy Janusz "przyhaczył" dzięki Kali coś grubego ... ja tego nie popieram i tym wpisem nie zachęcam do takich działań. Chiałem to napisać, aby z pełną świadomością oznajmić, że jeśli używasz Kali Linux, to nie jest tak, że jesteś bezpieczny i niewidzialny. Po prostu masz w rękach narzędzia, którymi możesz też zrobić z wirtualnego problemu namacalny realny incydent. Tego nie popieram i ten wpis jest nie jest instrukcją użycia narzędzi a subiektywną opinią, którą przedstawiam w celach edukacyjnych. Bawicie się Kali Linux na własne ryzyko, wszelkie poniesione szkody, komplikacje, inne zdarzenia są wyłącznie Waszą odpowiedzialną decyzją. A za dzieci odpowiadają rodzice w większości cywilizowanych krajów.  

Jak pewnie większość z Was zdaje sobie sprawę, w Kali Linux mamy wielki potencjał do testów bezpieczeństwa. Tzn. są tam fantastycznie skatalogowane zestawy narzędzi do różnych typów działań w obszarze tzw. bezpieczeństwa IT. Oto lista kategorii, w których w Kali Linux możemy dotrzeć do profesjonalnych narzędzi pentesterskich tzn. otwartego oprogramowania, wolnego od licencji, dzięki któremu możemy wyszukiwać różne informacje, dane, błędy, naruszenia i wady systemów operacyjnych, protokołów oraz aplikacji.

Do czego ja używałem Kali Linux - wyłącznie do rozwiązywania na nim zadań w ramach tzw. konkursów CTF, czyli "capture the flag". Są to odbywające się weekendowo wyzwania dla zaawansowanych użytkowników komputerów, w których zagadki zaczynają się od banalnych binarnych trickach, poprzez rekonesans na gotowych wirtualnych maszynach, analizę obrazów i ukrytych w nich szyfrów, zagadnienia sieciowe, XSS, SQL Incection, wady serwerwów www, autorskie dekodowanie kart perforowanych i wiele na prawdę ambitnych zagadek  a kończą na odnajdywaniu przy pomocy dekompilacji kodu asemblera nieznanego procesora jakich instrukcji, które zawieszą kod programu :-)

Tak, około roku zabawy na takich konkursach potrafi wzmocnić umiejętności rozwiązywania "różnych" incydentów w IT. Spokojnie polecam dołączenie do zespołu lub indywidualne startowanie w konkursach CTF - co ciekawe, odkrywając flagę za każdym razem uczymy się czegoś nowego o IT. Tak, to zajęcie uczy tzw. szacunku do problemów zawodowych oraz postrzegania tego, co jest na prawdę ważne, wnikliwości i tego jak szybko jesteśmy w stanie nauczyć się np: nowego języka programowania w kilka godzin, aby móc zdebugować w nim quasi-program. 

Kali Linux to nie tyle system operacyjny do CTFów, ale przede wszystkich zwykły Linuxowy OS do codziennego użytku dla ludzi z branży IT. Chciałem w dalszej części skoncentrować się na jednym ciekawym przypadku, który rozgrzebałem technicznie i stał się na tyle podejrzany dla mnie w dystrybucji Kali Linux w odniesieniu do Ubuntu Linux, że zechciałem o nim wspomnieć.

Jakiś czas temu zrobiłem ciekawy switch i mając Ubuntu 20.04 LTS wykonałem niniejsze polecenia, które zamieniły mojego Ubuntu w Kali - to bardzo fajne tricki możliwe w Linuxowym świecie :-) 

Tak na marginesie: jak wiemy Windows zamieni się niebawem w Lindowsa i możliwe, że też jednym pstryczkiem, ale za tym stoi wielka maszyneria biznesowa, aby nie utrzymywać swojego dość wadliwego jądra. Tak mam na myśli M$, który porzuciłem ~20 lat temu w domu i pracy, co bardzo otworzyło mi oczy i nie to była dość trafiona decyzja. Tak, wiem Azure to już w większości Linux od wielu lat i M$ też wie jak kompilować jądro i dopisują swoje rzeczy do kernela ... ale ta firma nie robi nic bezinteresownie, bo każda firma z założenia zarabia. Nawet wtedy, kiedy musi porzucić swój plan budowy jądra systemu operacyjnego a bierze Linux Kernel z Open Source, pisząc wszem i wobec, że "my też to stworzyliśmy". I mają prawo tak rzec, bo commitują swoje zmiany do kernela LInuxa, ale jak wiemy, w tych czasach marketing może robić z takimi działaniami cuda.

Powracając do myśli przewodniej, jestem zadowolony z Kali Linux jako desktopowego Linuxa i polubiłem ten zestaw narzędzi do CTFów, którego używam czasami do rozwiązywania problem, które zdarzają się przy produkcji oprogramowania. Jedna sprawa mnie zmartwiła w wersji Kali 2020.3:

$ lsb_release -a

No LSB modules are available.

Distributor ID: Kali

Description: Kali GNU/Linux Rolling

Release: 2020.3

Codename: kali-rolling

Otóż po jakimś czasie - odtwarzalne na trzech różnych maszynach - pojawiły się nierozwiązywalne metodą "--fix-*" z apt-get konflikty, przy poleceniu standardowym aktualizacji paczek systemowych:

sudo apt-get upgrade

Wygląda to mniej więcej tak:

$ sudo apt-get upgrade 

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Należy uruchomić "apt --fix-broken install", aby je naprawić.

Następujące pakiety mają niespełnione zależności:

 gnome-control-center : Wymaga: gnome-control-center-data (>= 1:3.36.4-1) ale 1:3.36.4-0ubuntu1 jest zainstalowany

 gnustep-base-runtime : Wymaga: libobjc4 (>= 4.2.1) ale nie jest zainstalowany

 libgnustep-base1.27 : Wymaga: libobjc4 (>= 4.6) ale nie jest zainstalowany

E: Niespełnione zależności. Proszę spróbować wykonać "apt --fix-broken install" bez pakietów (lub podać rozwiązanie).

i co najgorsze zachowuje się bardzo słabo w naprawie i skutki są dość słabe. Po kolei:

- wykonanie w/w apt'a z zalecanym "--fix-broken" powoduje, że nie może wykonać się do końca poprawnie, brakuje mu obrazka

$ sudo apt --fix-broken install

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Naprawianie zależności... Gotowe

Następujące pakiety zostały zainstalowane automatycznie i nie są już więcej wymagane:

  cryptsetup-nuke-password efibootmgr finalrd fonts-wine gnome-control-center-faces gparted-common

  grub-efi-amd64-bin humanity-icon-theme kpeople-vcard libboost-filesystem1.67.0 libboost-system1.67.0

  libboost-thread1.67.0 libcapi20-3 libdb5.3:i386 libebml4v5 libfaudio0 libfprint-2-tod1

  libgsoap-2.8.91 libgtkmm-2.4-1v5 libgtkspell0 libhogweed5 libigdgmm11 libkaccounts1

  libkf5contacts-data libkf5contacts5 libkyotocabinet16v5 liblz1 libmatroska6v5 libmng2 libnettle7

  libnfsidmap2 libnumbertext-1.0-0 libnumbertext-data libopenshot-audio6 libopenshot16 libopenvdb7.0

  libpcre2-8-0:i386 libplacebo7 libpoppler82 libprotobuf-lite22 libprotobuf22 libqrcodegencpp1

  libqxp-0.0-0 libsrt1 libstaroffice-0.0-0 libstb0 libtokyocabinet9 libtsk13 libvkd3d1 libvolume-key1

  libwagon-http-shaded-java libwhisker2-perl libwine libzmf-0.0-0 node-normalize.css

  python-backports.functools-lru-cache python-bs4 python-html5lib python-lxml python-numpy

  python-soupsieve python-webencodings python3-ecdsa python3-entrypoints python3-pycryptodome rpcbind

  shim ssh-import-id ubuntu-mono wine64

Aby je usunąć należy użyć "sudo apt autoremove".

The following additional packages will be installed:

  gnome-control-center-data guile-2.2-libs inkscape libgc1 libgdl-3-5 libgdl-3-common libgsl25

  libgslcblas0 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4 mailutils mailutils-common

  mariadb-common

Sugerowane pakiety:

  inkscape-tutorials libsvg-perl libxml-xql-perl pstoedit python3-uniconvertor gsl-ref-psdoc

  | gsl-doc-pdf | gsl-doc-info | gsl-ref-html mailutils-mh mailutils-doc

Polecane pakiety:

  python3-scour

Następujące pakiety zostaną USUNIĘTE:

  libgc1c2 libgsl23 libmailutils6

Zostaną zainstalowane następujące NOWE pakiety:

  libgc1 libgdl-3-5 libgdl-3-common libgsl25 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4

  mariadb-common

Następujące pakiety zostaną zaktualizowane:

  gnome-control-center-data guile-2.2-libs inkscape libgslcblas0 mailutils mailutils-common

6 aktualizowanych, 9 nowo instalowanych, 3 usuwanych i 763 nieaktualizowanych.

841 nie w pełni zainstalowanych lub usuniętych.

Konieczne pobranie 0 B/28,4 MB archiwów.

Po tej operacji zostanie dodatkowo użyte 25,4 MB miejsca na dysku.

Kontynuować? [T/n] T

Konfigurowanie pakietu libgcc-s1:amd64 (10.2.0-9) ...

Konfigurowanie pakietu libseccomp2:amd64 (2.4.4-1) ...

(Odczytywanie bazy danych ... 647544 pliki i katalogi obecnie zainstalowane.)

Przygotowywanie do rozpakowania pakietu .../gnome-control-center-data_1%3a3.36.4-1_all.deb ...

Rozpakowywanie pakietu gnome-control-center-data (1:3.36.4-1) nad (1:3.36.4-0ubuntu1) ...

dpkg: błąd przetwarzania archiwum /var/cache/apt/archives/gnome-control-center-data_1%3a3.36.4-1_all.deb 

(--unpack):

 próba nadpisania "/usr/share/pixmaps/faces/bicycle.jpg", który istnieje także w pakiecie gnome-control-center-data

enter-faces 1:3.36.4-0ubuntu1

dpkg-deb: błąd: podproces wklej został zabity sygnałem (Przerwany potok)

- uruchamia się w nieskończoność appport raportujący te błędy, przez co syslog osiąga GB wielkości i zapycha dysk, dalej jest już wiadomo bardzo trudno pracować na systemie z 0 miejsca na partycji systemowej !

- problem jest słabo opisany w sieci i jedyny motyw na odzyskanie miejsca na dysku to usunięcie z /var/crash/ plików !!!

$ ll /var/crash/gnome-control-center-data.0.crash 

-rw------- 1 root whoopsie 386566 paź  9 17:42 /var/crash/gnome-control-center-data.0.crash

$ sudo rm /var/crash/gnome-control-center-data.0.crash 

Uważam, że to jest dość ważny aspekt, aby takie narzędzie jak apt działało poprawnie i tutaj w Kali Linux spotkałem się z mega blokadą, nie pomaga dist-upgrade, nie pomaga szukanie dziury w całym przy pomocy strace, kończy się tym, co kojarzę z RedHat sprzed 20 lat, tzn. chcesz mieć spełnione zależności, to sobie je spełnij sam :-) Rozumiem, że osoba która jest wydawca pakietu mogłaby mnie wspomóc w temacie, o ile to problem z pakietem - nie wydaje mi się, bo próbowałem też dpkg i efekt jest identyczny.

Inny drobny brak w distro Kali Linux - tak mogę to określić - to niedziałająca domyślna obsługa filesystemów takich jak vboxfs (chciałbym sobie na vagrancie i virtualbox zrobić testy), czy LUKS (chciałbym odczytywać szyfrowane wolumeny). Rozumiem, że to sobie mogę doinstalować, ale niespodzianką było dla mnie włożenie pendrive z zaszyfrowanymi danymi przy pomocy LUKS w Kali Linux nie skutkuje automontowaniem i pytaniem o hasło. W Ubuntu Linux takie rozwiązania działają z paczki. Tak, wiem Kali Linux nie do tego celu był stworzony i nie chcę się o to spierać :-) Nadmieniam tylko, że nie zawsze potrzebujemy specjalnej dystrybucji, która rozwiązuje nasze potrzeby. Twierdzę, że czysta (z linii LTS) wersja Ubuntu jest na tyle wytestowana przez userów i naprawiana na bieżąco przez devów, że o wiele prościej rozwiązuje się takie codzienne zagadki jak te z aptem opisane powyżej w Kali Linux.

Reasumując - polecam pomimo opisanych incydentów Kali Linux zaawansowanym użytkownikom i profesjonalistom, zniechęcam amatorów i noobów :-)

Ubuntu Linux po kilkunastu latach trenowania/testowania/używania/pracy/zabawy/odkrywania przedstawił mi się w wersji 20.04 LTS jako system dość dobrze ustabilizowany w codziennym użytkowaniu do pracy i w zastosowaniach  domowych. Polecam Ubuntu Linux, bo jeśli z Windows znane są Wam nadmiarowe programy ochronne, które musicie tam posiadać, bo trojan i wirus czeka, aby się zemścić - to w Ubuntu Linux firewalle, snorty, auditlogi są dość uproszczone i nie wyżerają 30% CPUs a pozwalają na bezpieczną pracę i zabawę również na desktopie.

Kontenerowe systemy operacyjne - porównanie (Container OS)

Pamiętam, jak kiedyś stawiałem FreeBSD na maszynie i486 DX jako bramka do neostrady z 1 CPU. To była niezła przygoda, bo maszynka ta działała kilka lat bezawaryjnie, system na niej również. Tak, to był czysty przypadek :-), bo w serwerowniach normalnie nie zdarzają się takie "cuda" :-) Ponadto instalacja na każdej maszynie oddzielnie to byłaby zwykła robota głupiego. Minęło od opisywanego wyżej dzieła >18 lat i doczekaliśmy się dojrzałej konteneryzacji, całe szczęście dla utrzymania rozwiązań w IT. 

Kontenery

Kontenery szybko stały się niezbędną częścią nowoczesnych centrów danych. Kontenery można budować na dowolnej bazie z wielu podstaw systemu operacyjnego. 

W jaki sposób więc wybrać kontener?

W kontekście wdrażania kontenera kierownicy ds. rozwoju systemów muszą wiedzieć, które cechy i funkcje systemu operacyjnego są krytyczne dla wydawanych aplikacji i czy istnieją inne czynniki - takie jak łatwość zarządzania i elastyczność konfiguracji - które skłoniłyby organizację do wybrania jednego systemu operacyjnego zamiast wielu. Oczywiście łatwo utrzymuje się stan wiedzy inżynierów, jak i stack technologiczny jeśli systemy operacyjne w nim są liczone w kilka a nie kilkanaście.

Jak wypada porównanie różnych systemów operacyjnych pod względem funkcji i podstawowych funkcji? Jak te różnice wpływają na sposób, w jaki będą obsługiwać aplikacje? Oto podstawowe pytania, którym przyjrzymy się na reprezentatywnym przykładzie trzech szerokich typów systemów operacyjnych:

• Tradycyjne, w pełni funkcjonalne systemy operacyjne
• Minimalne systemy operacyjne ogólnego przeznaczenia
• Systemy operacyjne zbudowane specjalnie dla kontenerów

W każdej kategorii wybrałem dwa przykłady, które będą reprezentować wszystkie dystrybucje i produkty w grupie.

Po przeczytaniu tego artykułu powinniście mieć znacznie wyraźniejszy obraz różnic między typami systemów operacyjnych. Zakładam, że poprawi się zrozumienie, dlaczego programiści mogą wybrać jeden kontenerowy system operacyjny zamiast innego dla aplikacji kontenerowych i dlaczego mogą wspierać te wybory lub kwestionować je.

W pełni funkcjonalne systemy operacyjne

Co oznacza „w pełni funkcjonalny system operacyjny”? I dlaczego w kontekście wdrożenia kontenera wszystkie funkcje miałyby znaczenie? W tej sekcji przyjrzymy się, dlaczego ten sam system operacyjny, który może być używany w tradycyjnym wdrożeniu serwera, może być najlepszą odpowiedzią na platformę kontenerową.

Przede wszystkim trzeba wiedzieć, że te systemy operacyjne potrafią to wszystko. Jeśli aplikacja potrzebuje funkcji, istnieje prawdopodobieństwo, że któryś z nich ją będzie miała. Elastyczność ma jednak swoją cenę: te systemy operacyjne wymagają od systemu najwięcej, jeśli chodzi o pamięć masową, pamięć RAM i zasoby procesora. Funkcje te zwiększają również powierzchnię ataku systemu operacyjnego, zapewniając potencjalnym napastnikom znacznie więcej zakamarków, w których mogą wykonywać swoją pracę. Są to koszty, które należy ponieść, jeśli te funkcje są potrzebne aplikacjom. Czasami cena staje się bardzo wysoka, jeśli wymagana jest tylko niewielka liczba funkcji.

Te w pełni funkcjonalne systemy operacyjne mogą być najbardziej odpowiednie w środowisku, w którym wiele różnych aplikacji jest wdrażanych w kontenerach na jednej instancji systemu operacyjnego. W takich przypadkach szeroki zakres funkcji może być najbardziej ekonomicznym sposobem obsługi floty aplikacji.

Ubuntu

Ubuntu stał się domyślnym systemem operacyjnym na serwerze, w chmurze, a nawet na komputerze stacjonarnym dla wielu organizacji. Dobrze wspierany przez firmę Canonical, Ubuntu jest dostępny w wielu różnych formatach do pobrania z pakietami narzędzi, powłokami, funkcjami i zestawami funkcji niezbędnymi do wdrożeń obsługujących IoT, kontenery, serwery lub chmury.

Ubuntu przeniosło się w przestrzeń zajmowaną niegdyś wyłącznie przez Red Hat Linux: jest to bezpieczny wybór dla wdrożeń w przedsiębiorstwach, z obsługą i reputacją, które sprawiają, że wybór jest uznawany przez większość komitetów wykonawczych za „rozsądny”. Należy jednak pamiętać, że rozsądek nie przekłada się na najlepszy w każdych okolicznościach - to wciąż duży, pełny system operacyjny z wieloma zbędnymi preinstalowalnymi pakietami.

CentOS

Tam, gdzie Ubuntu stał się najbardziej zaawansowanym wyborem dla przedsiębiorstw spośród w pełni funkcjonalnych systemów operacyjnych, CentOS jest otwartą, kierowaną przez społeczność wersją innego „bezpiecznego” wyboru - Red Hata. CentOS kładzie nacisk na wsparcie społeczności i wkład w rozszerzający się zestaw funkcji i funkcji w systemie operacyjnym, jednocześnie budując stabilność swojego fundamentu Red Hat. Nie oznacza to, że CentOS nie jest używany przez duże organizacje - znajdziesz go na serwerach w laboratoriach krajowych i u głównych dostawców chmury. Ale Ubuntu ma tendencję do oferowania szybszych aktualizacji niż CentOS, który zawiera pakiety, które wydają się być starsze, ale bardzo dobrze przetestowane.

Minimalne systemy operacyjne

Kontenery powstały jako zbiory minimalnych funkcji zebranych razem w kompletną aplikację. Jakich funkcji w „pełnych” dystrybucjach Linuksa brakuje w tych minimalnych systemach operacyjnych - i czy ma to znaczenie dla Twojej aplikacji? Z drugiej strony, jakie są zalety opierania aplikacji na pakietach zredukowanych do absolutnego minimum?

Najlepsze odpowiedzi znajdują się na przecięciu wymagań aplikacji i funkcjonalności systemu operacyjnego. Bez przemyślanego przygotowania można utracić korzyści związane z rozmiarem i złożonością, których oczekuje się od minimalnych systemów operacyjnych, poprzez dodanie indywidualnych narzędzi, funkcji i apletów wymaganych dla określonych aplikacji.

W tej sekcji omówiono dwie dystrybucje, BusyBox i Alpine Linux, oraz korzyści, jakie mogą one przynieść w odpowiednich okolicznościach. Te dwa systemy operacyjne są ze sobą powiązane - Alpine jest oparty na BusyBox - ale istnieją kluczowe różnice, które mogą skłonić zespół do wybrania jednego z nich dla poszczególnych wdrożeń. Różnice te dotyczą nie tylko określonych zdolności, ale także społeczności wsparcia i ekosystemu każdego z nich.

BusyBox

BusyBox jest stosowany powszechnie we wdrożeniach kontenerów, ponieważ nie został zaprojektowany z myślą o kontenerach. Nazwany przez twórców jako „szwajcarski scyzoryk wbudowanego systemu Linux”, BusyBox miał być pojedynczym plikiem wykonywalnym o niewielkich rozmiarach, który zawierał wszystkie funkcje wymagane przez większość wbudowanych aplikacji. To zmusiło go do przyjęcia podejścia zbliżonego do kontenera do wdrożenia, zanim kontenery powstały.

BusyBox można wdrożyć przy użyciu Linuksa lub innych systemów operacyjnych POSIX jako podstawy. Łączy się z wieloma popularnymi narzędziami Linuksa w uproszczonej formie. Rezultatem jest kompaktowy, jednoplikowy plik wykonywalny, który zawiera wiele funkcji „pełnej” dystrybucji Linuksa, chociaż wiele opcji funkcjonalnych dostępnych w tych pełnych wersjach zostało pominiętych w BusyBox w imię zaoszczędzonego miejsca.

Alpine Linux

Jak wspomniano, Alpine Linux jest oparty na BusyBox, ale opiera się na wcześniejszej dystrybucji zarówno pod względem celu, jak i szczegółów. Tam, gdzie BusyBox jest zaprojektowany z niewielkimi rozmiarami, jako jedyny cel, Alpine Linux używa wzmocnionego jądra, aby dodać bezpieczeństwo do kompaktowych, prostych celów swojego poprzednika.

Alpine Linux ułatwia również programistom dodawanie funkcji. Opierając swoją dystrybucję na BusyBox i bibliotece musl, Alpine Linux daje programistom przewagę nad dodawaniem funkcji i budowaniem kompaktowych pakietów dystrybucyjnych. Jest to minimalny system operacyjny zdolny do tworzenia bardzo małych obrazów kontenerów do wdrożenia, a wzmocnione jądro sprawia, że ​​nadaje się on do zastosowań produkcyjnych, a także programistycznych.

Kontenerowe systemy operacyjne

System operacyjny kontenera jest dostarczany po wyjęciu z pudełka z wbudowaną automatyzacją i orkiestracją kontenerów. Są one zaprojektowane i zbudowane jako systemy operacyjne „hosta” - system operacyjny, na którym są hostowane systemy operacyjne kontenerów, takie jak Alpine i BusyBox. Dlaczego więc nie są one automatycznym wyborem dla każdego wdrożenia kontenera?

Kontenerowe systemy operacyjne wyróżniają się tym, że nie są po prostu oprogramowaniem obsługującym kontenery, ale oprogramowaniem wdrażanym przy użyciu kontenerów. Architektura oparta na „kontenerach do samego końca” może zapewnić poziom dostosowania do wdrożenia, który jest znacznie bardziej złożony niż tradycyjne wdrożenie systemu operacyjnego. Z drugiej strony, dla organizacji na wczesnym etapie przechodzenia na kontenery lub we wdrożeniach aplikacji, które przekraczają granice architektur kontenerów, architektura „całkowicie kontenerowa” może być pomostem za daleko, jeśli chodzi o komfort zarządzania.

Rancher OS i Container Linux to dwie główne opcje dla osób poszukujących kontenerowych systemów operacyjnych. Zrozumienie, co każdy system wnosi pozytywnego, pomoże programistom zrozumieć zalety, które posiadają, oraz sytuacje, w których są jedynym logicznym wyborem.

RancherOS

Każdy proces w RancherOS jest uruchamiany w oddzielnym kontenerze zarządzanym przez Docker. Optymalizacja i zależność od Dockera pozwala RancherOS być bardzo małym z bardzo krótkim czasem rozruchu. Oprócz podstawowych korzyści związanych z wydajnością istnieją jednak czynniki związane z wdrażaniem, które mogą przemawiać na korzyść RancherOS.

Usługi systemowe RancherOS są definiowane i konfigurowane przez Docker Compose. Ta zależność oznacza, że ​​tylko usługi potrzebne dla aplikacji są ładowane i wdrażane, co dodatkowo przyspiesza i upraszcza wdrażanie. Wdrażanie jest ponownie uproszczone dzięki integracji z cloud-init, która umożliwia zautomatyzowaną konfigurację i wdrażanie na szeroką skalę i z dużą szybkością.

CoreOS Container Linux

CoreOS Container Linux jest przeznaczony do wdrażania kontenerów w skali chmurowej. Teraz, jako część Red Hat, Container Linux jest zoptymalizowany pod kątem wdrożeń klastrów w publicznych lub prywatnych infrastrukturach chmurowych.

Container Linux jest wdrażany z jądrem i niezbędnymi narzędziami w jednym pliku wykonywalnym, a wszystkie inne narzędzia i funkcje są wdrażane w kontenerach.

Container Linux jest od dawna w powszechnym użyciu, a wsparcie jest dostępne do wdrażania w większości chmur publicznych. Przejęcie go przez firmę Red Hat nie spowolniło jego wdrażania i sprawiło, że niektóre organizacje są bardziej zadowolone z pomysłu wdrożenia na platformie. Container Linux jest rozpowszechniany z licencją typu open source i ma aktywną społeczność programistów.

Podsumowanie

Biorąc pod uwagę trzy szerokie typy systemów operacyjnych dostępnych do wdrażania kontenerów, który system operacyjny kontenera powinien wybrać zespół programistów? Jeśli jedynym celem konkretnego serwera jest hosting kontenerów, to systemy operacyjne kontenerów, takie jak RancherOS i Container Linux, mają wiele do polecania. Ich automatyzacja, szybkość wdrażania i spójna architektura kontenerów sprawiają, że są one logicznym wyborem dla tych, którzy chcą zoptymalizować środowisko hostingu kontenerów. Po przejściu o jeden poziom w górę do systemów operacyjnych dla samych kontenerów, wybory stają się bardziej zniuansowane.

Kiedy bierzemy pod uwagę zarówno aplikacje kontenerowe, jak i inne niż kontenerowe, nie ma wątpliwości, że tradycyjne wdrożenia Linuksa, takie jak Ubuntu i CentOS, mogą być używane jako platforma kontenerowa. Ich architektura oraz lista narzędzi i funkcji spowodują, że będą wolniej uruchamiać się i będą wymagały więcej zasobów systemowych, ale mogą wykonać zadanie, jeśli szybkość rozruchu i minimalne zużycie zasobów nie są kluczowymi kwestiami.

Pośrodku znajdują się minimalne systemy operacyjne, takie jak BusyBox i Alpine Linux. Mogą to być same w sobie solidne opcje kontenerów, ale naprawdę mogą się przydać, jeśli istnieją ograniczone zasoby aplikacje niebędące kontenerami, takie jak te dla IoT, które również należy uznać za część całego środowiska aplikacji.

Zrozumienie różnicy między możliwościami i ograniczeniami różnych typów systemów operacyjnych ma kluczowe znaczenie dla każdej produktywnej dyskusji na temat platformy systemu operacyjnego. W przypadku nowoczesnych systemów operacyjnych prawdziwa rozmowa nie powinna wtedy dotyczyć tego, który system operacyjny będzie działał, ale który będzie wykonywał pracę najbardziej wydajnie i efektywnie.

Clonezilla - narzędzie OpenSource do kopiowania, klonowania dysków i partycji + backupów

W okolicy w roku 2000 kiedy poznawałem na co dzień system FreeDOS, FreeBSD oraz zalążek systemu Linux - a precyzyjniej MINIXa - używałem jeszcze wtedy Windows.

Bardzo wygodnym narzędziem do zamrażania stanu systemu był wtedy Norton Ghost.

Jego głównym zadaniem był backup (kopia) całego obrazu dysku lub partycji systemowej do pliku. Mając taki plik, można było odtworzyć system do stanu z momentu backupu. To nowatorskie narzędzie - jak na tamte czasy działające z własnym GUI w konsoli systemu DOS - pozwoliło po zainstalowaniu systemu obraz w sterowników do niego, zrobić kopię całego obrazu, która mogła być wykorzystywana wielokrotnie. Było to wtedy związane z tym, że rejestr systemu Windows łatwo się zaśmiecał wraz z instalacją oprogramowania.

Po około 20 latach okazało się, że zechciałem zrobić klon dysku inną metodą niż przy pomocy programu disk dump w skrócie dd.

Po drodze sprawdziłem GParted oraz gnome-disks, jednak te narzędzia służą do zarządzania dyskami i partycjami, nie specjalizują się w klonowaniu dysków, czy też partycji.

Jak wiadomo podszedłem do tego od razu tak, że poszukałem oprogramowania otwartego i moim oczom ukazał się obraz systemu operacyjnego Linux pod nazwą Clonezilla - dedykowana dystrybucja Linuxa do klonowania, kopiowania, backupowania dysków i partycji.

Zanim jednak użyłem dedykowanego narzędzie Clonezilla, postanowiłam próbować wykorzystać program disk dump w skrócie dd i zrzucić obraz systemu na którym pracuje.

Wiedziałem że będzie w domu skazane na niepowodzenie ale nie widziałem żadnego komunikatu z kernela Linuksa który zabezpiecza system w takich sytuacjach.

Najprostsze użycie:

dd if=/dev/sda of=/dev/sda bs=16MB



Oczywiście, jak się spodziewacie efektem ubocznym nie był sławetny blue screen, lecz alarm z jądra systemu Linux dotyczący naruszenia obszarów, które mapują fizyczny dysk na logiczny File system. Poniżej zrzut ekranu wraz z komunikatem:

Na tyle mi wystarczyło rozgrzewki potwierdzającej, że w systemie Linux są zabezpieczenia, które nie pozwalają w trakcie działania żywego systemu robić klon dysku. Na pewno nie taką prymitywną metodą z użyciem polecenia dd.

Każdy eksperyment daje nam pewność w hipotezie, którą sobie stawiamy. Ja zakładałem, że tak właśnie się to powinno zakończyć i wróciłem do softu Clonezilla.

Jak przebiega proces klonowania dysku z użyciem Clonezilla?

Na początku warto zorientować się, jakie oznaczenia w /dev mają dyski, które podłączyliśmy fizycznie do komputera. Ja wykorzystywałem adapter serwisowy dla dysku docelowego, źródłowy był w komputerze zamontowany.

Polecenia Linuxa, które odsłania nam listę urządzeń dyskowych to:


df -h - pokazuje dyski, partycje wraz z zajętością oraz podmontowane

lsblk - pokazuje urządzenia przenośne, pendrive lub karty SD

lsusb - pokazuje, czy nasz kabelek lub narzędzie do podłączenia dysku na USB jest widoczne.


Oczywiście warto wspomnieć o poleceniu dmesg, dzięki któremu w logu systemowym zobaczymy fakt fizycznego podłączenia dysku oraz nadaną ścieżkę dla dysku np: /dev/sdb.


Na wstępie pobieramy obraz systemu ISO dla Clonezilla z oficjalnej strony.

Po czym używając np: dd lub gnome-disks zapisujemy na pendrive lub innym dysku obraz z systemem backupującym Clonezila, z którego następnie uruchamiamy komputer. Naszym oczom pojawia się taki komunikat i po wybraniu w konfiguracji właściwych opcji (źródłowy dysk, docelowy dysk, czy kopiujemy MBR) wygląd klonowania przedstawiają poniższe zdjęcia:

Dla dysku źródłowego SSD na docelowy 320GB 5400 WD BLUE, proces trwał ok. 45 minut, na laptopie DELL z 4 core CPU i 16GB RAM.


Po wykonaniu klona, restartu i uruchomeniu z laptopa ze sklonowanego dysku, po ok. 10 minutach cały system wystartował pomyślnie i można go używać bez żadnych problemów.

Polecam narzędzie Clonezilla jako świetne i wygodne narzędzie warsztatowe do backupów dysków. Oczywiście, o czym nie wspomniałem, tak jak Norton Ghost to narzędzie potrafi zapisać obraz dysku do pliku, a nawet wykonywać przyrostowe backupy.

Warto nadmienić, że Clonezilla można zainstalować niezależnie oraz uruchomić z dysku jako Clonzilla Live, w powyżej opisanym przypadku używałem wersji Live z odrębnego dysku.

Jest jeszcze jedna ważna kwestia - Clonzilla potrafi zaszyfrować plik backupem :-) Powodzenia podczas buckupowania lub / i klonowania dysków / partycji.