Red Hat Enterprise Linux
 
Zastosowanie systemów opartych na jądrze Linux jest bardzo szerokie. Od urządzeń końcowych jak telefony, tablety, komputery, telewizory i pojazdy, przez serwery usługowe i aplikacyjne, systemy dyskowe i plików, po urządzenia przetwarzające i kontrolujące ruch w sieciach. Pełnią rolę serwerów pocztowych, nazw, plików, a także udostępniają dużą liczbę rożnych aplikacji, nie tylko webowych. Mają zastosowanie w każdym obszarze technologii informacyjnych. Do tego ich wykorzystanie będzie rosło wraz z popularyzacją technologii IoT (Internet of Things) oraz cyfryzacji, informatyzacji i automatyzacji, jaka ma obecnie miejsce w każdej części świata.
 

RHEL (Red Hat Enterprise Linux) jest bazą rozwiązań Red Hat, do których należą m.in.: Red Hat Virtualization, Red Hat Ansible Automation, Red Hat Satellite, Red Hat CloudForms, Red Hat OpenShift, Red Hat OpenStack, Red Hat Ceph, Red Hat Gluster, Red Hat Hyperconverged Infrastructure, Red Hat Certificate System, Red Hat Directory Server, Red Hat Identity Management czy Red Hat 3Scale.

Na bazie systemu RHEL może także działać system kopii zapasowej Storware vProtect, rozwiązania do budowy SDS (Software Defined Storage) LINBIT SDS, replikacji blokowej danych systemu dyskowego LINBIT DRBD, platformy wymiany plików i wspólnej kooperacji NextCloud, chmurowych pakietów biurowych Collabora Productivity i ONLYOFFICE oraz bardzo wielu innych dostępnych na rynku produktów.
 
 
Wszystko to sprawia, że całe nasze środowisko IT może być oparte o jedną spójną platformę. System RHEL można zainstalować wszędzie - na fizycznym serwerze, w środowisku do wirtualizacji, a także w chmurze publicznej i prywatnej. Pozwala to na zachowanie pewnego standardu i poziomu zgodność, który przekłada się na łatwiejsze zarządzanie oraz bezpieczniejszą i stabilniejszą infrastrukturę dla usług, danych i aplikacji.

Red Hat Enterprise Linux dostępny jest w formie subskrypcji dla fizycznego sprzętu, maszyn wirtualnych lub nieograniczonej ilości maszyn wirtualnych na hoście. Zainteresowanych zakupem systemu lub zakupem i wdrożeniem usług na bazie systemu Red Hat Enterprise Linux This email address is being protected from spambots. You need JavaScript enabled to view it..

Co daje subskrypcja dla systemu Red Hat Enterprise Linux (RHEL)?
 
Remontów nikt nie lubi, a zmiany w systemach IT bywają coraz bardziej odczuwalne i kosztowne. Powodem tego jest coraz większą złożoność środowisk IT, a także ilość danych oraz działających w nich usług i aplikacji. Więcej szczegółów na temat cyklu życia i wsparcia dla systemu RHEL można znaleźć TUTAJ.
 
W ramach subskrypcji dla systemu Red Hat Enterprise Linux otrzymujemy:
  • wsparcie producenta w ramach 10-letniego cyklu życia systemu,
  • wsparcie techniczne w wymiarze 8/5 lub 24/7, bez limitu ilości zgłoszeń,
  • ciągły dostęp do nowych wersji oprogramowania (poprawki bezpieczeństwa i nowe funkcjonalności),
  • dostęp do kodu źródłowego oprogramowania (jest to produkt o otwartym kodzie, ang. Open Source),
  • dostęp do bardzo dobrej dokumentacji technicznej, bazy wiedzy budowanej przez ekspertów Red Hat z wieloma sprawdzonymi studiami przypadków,
  • dostęp do Security Response Team (SRT), który produkuje zalecenia po każdych pojawiających się podatnościach, dzięki czemu administrator od razu wie jakie kroki powinien przedsięwziąć,
  • certyfikację zgodności między produktowej, zgodność z normami bezpieczeństwa oraz pewność poprawnego działania i kompatybilności ze sprzętem, oprogramowaniem i usługami chmurowymi wielu dostawców,
  • dostęp do Red Hat Insights, który analizuje stan systemu i jego usług oraz zdarzenia w nim zachodzące, a następnie koreluje te informacje z bazą wiedzy Red Hat Knowledge Base i najlepszymi praktykami w celu udostępnienia zaleceń poprawiających wydajność, stabilność oraz bezpieczeństwo systemu i jego usług.

Zakup takich subskrypcji to także wsparcie społeczności otwartego oprogramowania (ang. Open Source). Red Hat jest jednym z głównych sponsorów nie tylko jądra Linux, ale i wielu grup tworzących produkty o otwartym kodzie. Dzięki temu można z nich korzystać za darmo tam, gdzie zgodność z normami bezpieczeństwa, certyfikacja zgodności między produktowej, długi cykl życia i wsparcia, odpowiedni poziom bezpieczeństwa, pewność, stabilność oraz wysoka dostępność środowiska nie ma wystarczającego uzasadnienia biznesowego lub mamy na tyle duży oraz wyspecjalizowany dział IT, że możemy samodzielnie to zapewnić i wziąć za to odpowiedzialność.

Bardzo ważna jest długość życia systemu i jego wsparcia. Dla większości darmowych systemów są to 3-lata. Po roku, kiedy system staje się stabilny i można go wdrażać produkcyjnie, zostaje raptem 1-rok po którym znowu trzeba zacząć planować kolejny remont. Dla systemu Red Hat Enterprise Linux jest to aż 10-lat. 


Nowa wersja systemu, czyli Red Hat Enterprise Linux 8

W ramach posiadanych subskrypcji można także bezpłatnie dokonać aktualizacji do nowszego wydania systemu RHEL. 7 maja 2019 roku pojawił się Red Hat Enterprise Linux 8 (RHEL8).


Nowa wersja systemu to nie tylko nowsze wersje usług, oprogramowania i bibliotek dla budowanych aplikacji. Przy obecnym wykorzystaniu wirtualizacji i konteneryzacji, elementy te mają coraz mniejsze znaczenia w procesie podejmowania decyzji o aktualizacji lub zmianie systemu bazowego.

Duże znaczenie mają funkcje i możliwości poprawiające wydajność, bezpieczeństwo, stabilność, skalowalność i wygodną obsługę środowiska, takie jak m.in.:
  • wysokowydajne przetwarzanie pakietów na poziomie karty sieciowej z XDP i eBPF,
  • większa przepustowość i mniejsze opóźnienia dzięki algorytmowi BBR dla TCP,
  • nowa obsługa klasyfikacji i filtrowania pakietów (nftables zamiast iptables, ip6tables, ebtables i arptables),
  • większe bezpieczeństwo i automatyzacja usługi DNS (CDS/CDNSKEY, DNS Cookies i Catalog Zones),
  • ochrona poczty elektronicznej zgodna z decyzją UE z dnia 11 grudnia 2017 roku (DNSSEC i DANE),
  • większe bezpieczeństwo i łatwiejsze zachowanie zgodności (ang. compliance),
  • wydajniejsze i bezpieczniejsze środowisko graficzne (GNOME i Wayland),
  • nagrywanie sesji administracyjnych (ang. terminal session recording),
  • webowy interfejs do zarządzania (Cockpit i jego integracja z Red Hat Satellite),
  • uproszczenie obsługi zaawansowanych funkcji systemu dyskowego,
  • lepsze wykorzystanie przestrzeni dyskowej w XFS,
  • lepsza obsługa pakietów oprogramowania (moduły i strumienie oraz technologia DNF),
  • bardziej funkcjonalna oraz bezpieczniejsza obsługa kontenerów i obrazów (Podman, Buildah i Skopeo).
Więcej o wspomnianych wyżej funkcjach i możliwościach napisaliśmy w paragrafach znajdujących się niżej.
 
Razem z RHEL8 pojawiły się nowe możliwości, jak chmurowa weryfikacja zgodności, podatności oraz raportowanie i porównywanie systemów zarejestrowanych w Red Hat Insights, Red Hat Satellite i Red Hat OpenShift. Realizowane jest to przez Cloud Management Services, które dostępne jest pod adresem cloud.redhat.com.
 
Warto pamiętać, że Red Hat Insights dostępny jest za darmo w ramach wszystkich subskrypcji systemu RHEL. Zbiera on dane, a następnie analizuje je i koreluje z Red Hat Knowledge Base. Na tej podstawie dostarcza informacje na temat wykrytych podatności oraz możliwości poprawy, wydajności, stabilności i bezpieczeństwa produktów Red Hat. Dostarcza także gotowe playbook-i, które dają możliwość efektywnego wdrożenia tych zaleceń na dużej ilości systemów z użyciem Red Hat Ansible Automation.

Tak samo jak jego poprzednik RHEL7, nowy system RHEL8 ma bardzo dobrą integrację z Microsoft Active Directory oraz posiada bardzo wiele narzędzi umożliwiających diagnozowanie oraz monitorowanie aktualnej i historycznej wydajności systemu. Ich przykładem są narzędzia sysstat i PCP (Performance Co-Pilot). W wielu rozwiązaniach takich rzeczy brakuje, przez co jesteśmy ślepi na to co się dzieje i skazani całościowo na wsparcie i diagnozę producenta.

Wysokowydajne przetwarzanie pakietów na poziomie karty sieciowej z XDP i eBPF

XDP (eXpress Data Path) pozwala na uruchomienie programu eBPF (extended Berkeley Packet Filter) w obszarze sterownika karty sieciowej.

XDP i eBPF to dwa nowe elementy RHEL8. eBPF umożliwia uruchamianie w jądrze Linux małych programów (ang. bytecode) stworzonych w przestrzeni użytkownika. Programy te uruchamiane są w dedykowanej maszynie wirtualnej, która dołączana jest do punktów zaczepienia (ang. hooks) w jądrze. XDP dodaje dodatkowy punkt zaczepienia (ang. hooks) dla eBPF, który jest bezpośrednio w sterowniku karty sieciowej. Zatem eBPF dostarcza funkcji elastycznego programowania jądra do przetwarzania i analizy pakietów sieciowych, a XDP dostarcza funkcje bardzo wydajnego przetwarzania sieciowego.

Dzięki takiemu połączeniu, filtrowanie pakietów czy inne wykonywane na nich funkcje mogą być realizowane zaraz po tym, jak pakiet trafi do karty sieciowej. Omija to cały stos jądra systemu Linux, co pozwala filtrować i przeszukiwać bardzo dużą ilość ruchu. Testy z 2017 roku, które opisano na LWN, wykazują na możliwość odrzucania 28Mpps oraz modyfikacji 10Mpps z użyciem jednego CPU i jednej karty sieciowej o prędkości 40Gbps.

Połączenie to znalazło zastosowanie w realizacji usług anti-DDoS. Korzysta z niego produkcyjnie Facebook oraz CloudFlare. Ciekawe porównanie XDP względem innych mechanizmów zostało opisane na blog-u CloudFlare.

Innym zastosowaniem może być L4 Load Balancer, z którego korzysta Facebook. Otworzył on nawet kod swojego (ang. open-sourced) rozwiązania Load Balancer-a o nazwie katran, który wykorzystuje XDP/eBPF. 

W obu przedstawionych zastosowaniach XDP/eBPF nadają się świetnie do analizy, monitorowania, ochrony i rozkładu obciążenia ruchu kierowanego nie tylko do dużych sieci, ale także do dużej ilości maszyn wirtualnych i kontenerów. Potwierdzeniem tego jest projekt Open Source o nazwie Cilium, który opiera swoje działanie w obszarze rozkładu obciążenia i bezpieczeństwa aplikacji kontenerowych na XDP/eBPF.
 
Przerzucenie niektórych operacji na pakietach bezpośrednio do kart sieciowych jest także dobrym krokiem w kierunku rozwiązań NFV (Network Function Virtualization) oraz poprawy wydajności środowisk chmurowych i kontenerowych, takich jak Red Hat OpenStack i Red Hat OpenShift.
 
Należy pamiętać o tym, że XDP i eBPF otwiera tylko pewne możliwości, które dopiero z czasem zaczną być wykorzystać do budowy kolejnych rozwiązań. RHEL8 jest na nie przygotowany.

Większa przepustowość i mniejsze opóźnienia dzięki algorytmowi BBR dla TCP
 
O prędkości transmisji w dużym stopniu decydują algorytmy kontroli zatorów (ang. congestion control algorithms).
 
CUBIC jest powszechnie stosowanym algorytmem obsługi zatorów dla protokołu TCP (Transmission Control Protocol). Wykorzystywany do transmisji w TCP rozmiar okna (ang. window size), jest w nim funkcją sześcienną (ang. cubic function) w czasie od ostatniego wystąpienia zatoru. Miejscem zerowym/punktem załamania (ang. inflection point) tej funkcji jest rozmiar okna przed zatorem.

Przykład funkcji sześciennej

Ma ona przestrzeń wklęsłą (ang. concave - concave downward) i wypukłą (ang. convex - concave upward). Wklęsła daje możliwość szybkiego powrotu rozmiaru okna do stanu bliskiego przed ostatnim wykryciem zatoru w sieci i dalej powolny wzrost do tego miejsca. W ten sposób sieć dostaje czas na ustabilizowanie się. Zaraz po tym przechodzi do części wypukłej, która o ile początkowo rośnie powoli, to przyśpiesza coraz bardziej, jeżeli nie ma oznak zatoru.
 
Otrzymanie podwójnego potwierdzenia (zduplikowany ACK) lub jego brak w czasie RTO (Retransmission TimeOut), jest uznawany przez CUBIC jako objaw zatoru w sieci. O ile fakt ten oznacza zwykle zgubienie pakietu, to niekoniecznie musi oznaczać zator w sieci. Do czynienia możemy mieć z łączem 10Gbps, na którym z innych powodów niż obciążenie łącza ginie 0,01% pakietów. Zwalnianie transmisji w takim przypadku niekoniecznie ma sens.

Wykorzystanie CUBIC w TCP przyczynia się także do pełnego wysycania buforów interfejsów urządzeń sieciowych i co za tym idzie wzrostu opóźnień. Algorytm CUBIC nie bierze pod uwagę czasu RTT (Round Trip Time), stąd nie są faworyzowane ani połączenia o małych, ani o dużych opóźnieniach. Mają tą samą szansę wzrostu. Nagły wzrost opóźnień dla wszystkich połączeń 
ma negatywny wpływ na działanie aplikacji wymagających do pracy niskich opóźnień. Im większe są bufory, tym powstają większe opóźnienia. 
 
Podsumowując działanie algorytmu CUBIC w TCP, przy niewielkim rozmiarze buforów szybko dochodzi do złej interpretacji zatoru w sieci i znaczącego spadku prędkości transmisji, a przy dużym rozmiarze buforów do znaczącego wzrostu opóźnień.

Bufory obecnych urządzeń sieciowych są coraz większe, stąd proces wykrywaniu zatoru w sieci powinien brać pod uwagę wzrost opóźnień. Z drugiej strony, algorytm bazujący tylko na opóźnieniach nie byłby traktowany w sieci sprawiedliwie. Połączenia TCP stosujące inne algorytmy, jak dla przykładu CUBIC, przejęłyby całkowiecie łącze.
 
Z rozwiązaniem przyszedł BBR (Bottleneck Bandwidth and Round-trip propagation time), nowy algorytm wykrywania zatorów w TCP. W dużych skrócie, algorytm BBR stara się wysycać coraz bardziej łącze monitorując jednocześnie wzrost opóźnień. Kiedy dojdzie do momentu, w którym opóźnienia drastycznie wzrastają, stara się delikatnie zmniejszać transmisję do momentu w którym będą one miały rozsądne wartości. Dzięki temu, gdy:
  • transmisja nie gubi pakietów, przepustowość jest podobna z zachowaniem kilkukrotnie niższych opóźnień,
  • transmisja gubi pakiety, przepustowość potrafi być nawet kilkukrotnie większa.

Wykorzystanie nowego algorytmu obsługi zatorów w TCP pozwala utrzymać niską zajętość buforów urządzeń sieciowych i co za tym idzie zachować niskie opóźnienia przesyłanych pakietów, nawet przy dużej ilości ruchu. Dla niektórych usług jest to naprawdę bardzo istotne. 

Użycie BBR w TCP ma kluczowe znaczenia także dla ruchu HTTP/2, gdzie cała transmisja pomiędzy klientem, a serwerem może odbywać się w ramach jednego połączenia. Przy HTTP/1, nie ma to tak dużego znaczenia, gdyż pomiędzy klientem, a serwerem otwierana jest duża ilość relatywnie krótkich połączeń. BBR powinien być aktywowany od strony, która udostępnia dużą ilość danych, jak serwery usługowe.

Domyślnie w RHEL8 działa CUBIC. Aktywowanie BBR jest bardzo proste i zostało pokazane poniżej. Zaraz po tym jak to zrobimy, wszystkie kolejne nowe połączenia będą z niego korzystać.
Oczywiście, powyżej aktywowaliśmy BBR tylko tymczasowo. Docelowo należy zadbać też o to, aby ustawienia te działały po restarcie systemu.
 
Na koniec warto dodać, że Twórcą algorytmu BBR jest Google, które z powodzeniem stosuje go na swojej platformie chmurowej. Więcej na temat działania algorytmu BBR razem z ciekawymi porównaniami, testami i wykresami można znaleźć na blog-u Google oraz blog-u APNIC

Nowa obsługa klasyfikacji i filtrowania pakietów

W nowej wersji systemu znacząco uroszczony został sposób obsługi klasyfikacji i filtrowania pakietów. Poprzednio stosowane do tego celu 4-narzędzia (iptables, ip6tables, ebtables i arptables) zostały zastąpione jednym - nftables.
 
Zmiana ta zmniejszyła ilości kodu związanego z tą funkcjonalnością w jądrze Linux i wyeliminowała potrzebę zmiany jądra systemu za każdym razem, kiedy potrzebna jest obsługa nowych protokołów lub sposobu ich obsługi.

Z nftables obsługa nowych funkcji i protokołów będzie w większości przypadków wymagała tylko aktualizacji oprogramowania. Udało się to osiągnąć dzięki specjalnej maszyny wirtualnej w jądrze systemu, której zadaniem jest uruchamianie pseudokodu dostarczonego z przestrzeni użytkownika. Kod ten tworzony jest za pomocą narzędzia nft, a następnie po kompilacji dostarczany do niej poprzez gniazdo typu Netlink.

Struktura wewnętrzna iptables i nftables opiera się o tabele (ang. tables), w których znajdują się łańcuchy (ang. chains) zawierające reguły (ang. rules). W nftables nie ma wbudowanych tabel i łańcuchów, które w iptables są zawsze przetwarzane, czy ich potrzebujemy czy nie. W nftables strukturę tą musimy stworzyć sami.

Rzeczy, które nie uległy zmianie, to punkty zaczepienia (ang. hooks) do których mogą być podczepiane budowane łańcuchy, jak PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING, system obsługi nawiązanych połączeń (ang. Connection Tracking System, tzw. CONNTRACK), silnik translacji adresów (ang. NAT engine), obsługa logowania pakietów i połączeń (daemon ulogd2) oraz komponenty kolejkowania pakietów. W nftables mamy na wejściu dodatkowy punkt zaczepienia o nazwie INGRESS, który znajduje się przed PREROUTING i umożliwia wcześniejsze, znacznie wydajniejsze filtrowanie ruchu, jakie możliwe wcześniej było tylko z użyciem narzędzia tc (obsługa kolejkowania i modelowania ruchu nadal wymaga narzędzia tc).

nftables stosuje inną składnię poleceń, która bardziej przypomina strukturę poleceń znaną z narzędzia tcpdump. Nowa składnia umożliwia efektywniejsze i bardziej funkcjonalne tworzenie reguł, które oprócz wygodnego agregowania i grupowania, mogą teraz także realizować więcej niż jedno zadanie/cel (ang. target). Dla przykładu, jedna reguła może jednocześnie blokować i logować lub oznaczać i akceptować ruch, co wcześniej wymagało odpowiedniego ułożenia kilku reguł. Jest to tylko jeden z przykładów, bo nftables umożliwia elastyczne agregowanie i grupowanie bardzo wielu elementów.
 
Pomimo tylu zmian, z poziomu administratora systemu RHEL8 niewiele się zmienia. Nadal zalecanym narzędziem/interfejsem do konfiguracji jest firewalld. Zmianie uległo jedynie to co działa pod spodem (ang. backend). Interfejs ten (ang. frontend) możemy zmienić za pomocą systemctl z firewalld na nftables lub iptables. Natomiast to nie zmieni tego co działa pod spodem. Tam zawsze będzie nftables.
Kolejną zaletą nftables jest możliwość wprowadzania wszystkich zmian atomowo i szybko, bez względu czy dodajemy/usuwamy 1-regułę, czy wykonujemy długi skrypt.
 
W iptables można zlecić podmianę tylko całej tablicy reguł. Każde użycie polecenia iptables w skryptach zastępuje wszystkie działające reguły na nowo. Bez względu na to czy dodajemy, czy usuwamy tylko jedną z nich, budowana jest nowa konfiguracja zaktualizowana o tą 1-zmianę i następnie następuje przełączenie ze starej konfiguracji na nową. Z każdą kolejną regułą zmiana taka trwa dłużej, a dodatkowo zapora sieciowa jest przejściowo nie w pełni funkcjonalna - do czasu wykonał się całego skryptu. Stąd zalecanym sposobem wprowadzania zmian dla iptables jest wywołanie iptables-restore, które w momencie odczytania linii "COMMIT" realizuje zmianę całej konfiguracji. Niestety, nie mamy wtedy dostępnych funkcji, jakie dają nam języki skryptowe.
 
W nftables nawet obsługa całych skryptów jest realizowana atomowo. Po wskazaniu skryptu za pomocą opcji "-f" polecenia nft, jest on przetwarzany w pamięci, gdzię budowana jest konfiguracja nft. Po zakończeniu skryptu następuje podmiana zawartość konfiguracji nftables w sposób atomowy.

Większe bezpieczeństwo i automatyzacja usługi DNS 
 
W nowej wersji usługi serwera nazw BIND pojawiły się funkcje, które znacząco usprawniają oraz automatyzują obsługę DNSSEC i serwerów Secondary, a także zwiększają bezpieczeństwo.

Zautomatyzowana obsługa DNSSEC dzięki DNSSEC Key Manager, który na podstawie zdefiniowanej polityki zajmuje się tworzeniem nowych kluczy ZSK/KSK.

Automatyczna kooperacja z Parent Zone w obszarze obsługi DNSSEC, dzięki obsłudze rekordów zasobów CDS (Child DS) i CDNSKEY (Child DNSKEY).

Automatyzacja budowania i usuwania konfiguracji serwerów Secondary w momencie tworzenia nowych lub usuwania starych stref na serwerze Primary. Realizowane jest to poprzez specjalną strefę i dobrze znany mechanizm AXFR/IXFR. W strefie tej znajdują się informacje o strefach, jakie powinny być obsługiwane przez serwery Secondary. Funkcjonalność ta nazywa się Catalog Zones.

NTA (Negative Trust Anchor) dający możliwość wyłączenia walidacji wybranych stref DNS. Bardzo przydatna funkcja, dzięki której można chwilowo wykluczyć z walidacji źle skonfigurowane strefy DNS.

Obsługa DNS Cookies, która umożliwia wykrycie fałszywych odpowiedzi od niepytanych serwerów (ang. off-path spoofed responses) oraz określenie czy ktoś nie podszywa się pod legitymowanego klienta, wysyłając fałszywe zapytania (ang. spoofed-source queries).

Ochrona poczty elektronicznej zgodna z decyzją UE
 
Usługa do obsługi poczty elektronicznej w RHEL8 obsługuje DANE (DNS-based Authentication of Named Entities).
 
DANE umożliwia wskazanie prawidłowego certyfikatu dla usługi w strukturze DNS. Dzięki takiemu podejściu, zaufany certyfikat możemy podpisać samodzielnie (bez potrzeby korzystania z usług zaufanych CA). W związku z tym, że informacje te przetrzymywane są w strukturze DNS, do pełnego bezpieczeństwa wymagane jest także wdrożenie DNSSEC (Domain Name System Security Extensions), który jest również obsługiwany w RHEL8.
 
Bez odpowiednich zabezpieczeń, certyfikat dla naszej domeny może wystawić każde CA (zarówno te z największą, jak i te z najmniejszą renomą/reputacją). Dzięki DANE mamy możliwość wskazania dokładnie certyfikatu o który nam chodzi, przez co te wystawione przez inne lub skompromitowana CA nie będę wiarygodne.
 
Standard poczty elektronicznej nie wymusza także szyfrowania. Zatem fałszywy rekord MX jest w stanie przekierować wiadomości do złowrogiego serwera, który wymusza transmisję bez szyfrowania. Szyfrowana transmisja także nie jest w pełni bezpieczna, gdyż certyfikat którym przedstawia się serwer musi pasować do nazwy wskazanej w rekordzie MX (w tyn przypadku fałszywym), a nie nazwy domenowej z adresu e-mail (domena odbiorcy).
 
Z pomocą przychodzi DNSSEC, który dba aby dane DNS były prawdziwe oraz DANE, które pilnuje by transmisja odbywała się w sposób szyfrowany bez pośredników.
 
Komisja Europejska w swojej decyzji wykonawczej z dnia 11 grudnia 2017 roku, która dotyczyła implementacji technicznych rozwiązań teleinformatycznych pisze o wykorzystaniu m.in. DNSSEC i DANE, jako jednych z głównych mechanizmów do ochrony poczty elektronicznej. Standaryzacja jest głównym celem przyjętej przez Komisję Europejską strategii na 2020 rok. Więcej na ten temat można znaleźć na stronie EUR-Lex (Prawo UE).

Większe bezpieczeństwo i łatwiejsze zachowanie zgodności
 
W systemie RHEL8 o wiele łatwiej można zadbać o spójną politykę konfiguracji wykorzystywanych algorytmów i protokołów kryptograficznych (ang. System-wide Cryptographic Policy) oraz sposób obsługi uwierzytelnienia i autoryzacji w obszarze całego systemu.

W system zostało wbudowane narzędzie, które umożliwia centralne uspójnienie konfiguracji wielu różnych usług w obszarze stosowanych protokołów i algorytmów (TLS, IPSec, SSH, DNSSEC i Kerberos). Narzędziem tym jest update-crypto-policies. Więcej o nim można znaleźć na blog-u Red Hat. Dodatkowo zastąpiony został autoconfig. W jego miejsce wszedł authselect, dający możliwość budowy i wygodnego przełączania profili używanego przez składowe systemu rozwiązania uwierzytelnienia i autoryzacji. Oprócz gotowych profili dla NIS, Winbind oraz SSSD możemy także tworzyć własne.

Nowa wersja systemu Red Hat posiada także bardzo rozbudowane mechanizmy audytowania zdarzeń w systemie, wykrywania anomalii oraz weryfikacji zgodność z przyjętymi normami bezpieczeństwa. To ostatnie realizowane jest poprzez specjalne profile SCAP (Security Content Automation Protocol), które mogą podlegać cyklicznej weryfikacji na każdym z systemów. W ten sposób można sporo zaoszczędzić na bardzo drogich audytach. Dzięki odpowiedniemu audytowaniu, które wbudowane jest w każdy z produktów Red Hat dokładnie wiadomo co, kiedy i przez kogo zostało w systemie zrobione.

Automatyczna weryfikacja zgodności, zapobieganie i przywracanie systemów do prawidłowego stanu jest możliwe dzięki coraz lepszej integracji RHEL z Red Hat Ansible Automation, Red Hat Satellite i Red Hat CloudForms. Oczywiście dotyczy to także Red Hat Insights, o którym więcej pisaliśmy wyżej. Połączenie tych rozwiązań ze sobą umożliwia automatyzację oraz utrzymania zgodności i spójności środowiska informatycznego, co jest kluczowym elementy bezpieczeństwa. Obrazuje to dostępny na stronie Red Hat film

Wydajniejsze i bezpieczniejsze środowisko graficzne
 
W wersji 8 systemu RHEL znajdziemy tylko środowisko graficzne GNOME, które domyślnie działa na bazie Wayland.
 
 
Wayland i X11 są serwerami wyświetlania (ang. display server), które działają pomiędzy jądrem Linux, a interfejsem użytkownika takim jak GNOME czy KDE. Od wersji 8 Red Hat wycofał się ze wsparcia dla KDE. W nowym GNOME możemy znaleźć lepszą i wygodniejszą obsługę kilku przestrzeni pracy (ang. workspace) i monitorów. Pomimo tego, że od strony użytkownika różnic można nie dostrzec, to wykorzystanie serwera Wayland znacząco poprawia bezpieczeństwo i szybkość środowiska.
 
Wayland potrafi izolować każdą aplikację, co z X11 nie było możliwe. Dzięki temu czytanie wpisywanych z klawiatury znaków do okna innej aplikacji lub pobranie zawartości jej okna nie jest z Wayland możliwe. Podejście takie znacząco utrudnia efektywne wykorzystanie złowrogiego oprogramowania, co do tej pory przy serwerze X11 było za proste.
 
Wayland działa także bliżej jądra systemu i sprzętu oraz przystosowane jest tylko do systemów z rodziny Linux. Dzięki temu jest w stanie pracować oraz realizować przetwarzanie graficzne szybciej i efektywniej. X11 celuje w bycie niezależnym od systemu, stąd działa m.in. w systemach Linux, BSD, Plan9 i Solaris.
 
X11 jest na rynku znacznie dłużej od Wayland, stąd niektóre aplikacje mogą wymagać do działania uruchomienia środowiska graficznego na jego bazie. System RHEL8 zapewnia taką możliwość (wybór serwera wyświetlania przy logowaniu), niemniej w miarę postępu czasu coraz mniej powinno być to potrzebne.

Nagrywanie sesji administracyjnych
 
W nowej wersji systemu RHEL da się uruchomić nagrywanie sesji administracyjnych (ang. terminal session recording) dla wszystkich lub tylko wybranych użytkowników oraz grup.
 
Dla zachowania prywatności, domyślnie wyłączone jest zapamiętywanie wpisywanych haseł. Sesje są logowane w formacie tekstowym (JSON), dzięki czemu da się je wygodnie przeszukiwać. Dostępne jest także odtworzenie sesji w podobnej formie do filmu, gdzie krok po kroku widać co robi użytkownik. Oglądając nagrania mamy także możliwość zaznaczenia i skopiowania pojawiającego się w nim tekstu.
 
Nagrywanie sesji administracyjnych może być od teraz stosowane w celach regulacyjnych i kontrolnych. O ile nagrania da się przeszukiwać i odtwarzać bezpośrednio z CLI, to dostępny jest także wygodny interfejs webowy za pomocą którego możemy uzyskać dostęp do nagrań. Wbudowany jest on w interfejs do zarządzania webowego system RHEL o nazwie Cockpit.

Webowy interfejs do zarządzania
 
Cockpit jest webowym interfejsem do zarządzania, w którym dostępne jest w nim m.in.: zarządzanie serwisami, użytkownikami, interfejsami sieciowymi, dyskami twardymi i zaporą sieciową. Obsługuje on także wspomniane wyżej odtwarzanie nagrań sesji terminalowych. Posiada wbudowane narzędzia diagnostyczne, raporty i wykresy obrazujące obciążenie systemu.
 
Wayland z natury skupia się tylko na lokalnym systemie. Nie umożliwia pracy poprzez tak zwany "SSH Forwarding", który często było wykorzystywany do zdalnego zarządzania poprzez interfejs graficzny z X11. Do tego celu w RHEL8 powinno się stosować Cockpit.
 
Zmiana dotyczy także graficznego zarządzania maszynami wirtualnymi, która również powinna być w systemie RHEL8 realizowana poprzez Cockpit. O ile w nowym systemie jest jeszcze dostępny virt-manager, to jest on oznaczony jako "deprecated", stąd możemy się spodziewać, że niebawem całkiem zniknie.
 
Na koniec warto wspomnieć o możliwości obsługi wielu serwerów w jednym interfejsie Cockpit (obsługa lokalnego i zdalnego zarządzania) oraz integracji Cockpit z Red Hat Satellite. Dzięki niej z jednego miejsca, bezpośrednio z interfejsu Red Hat Satellite możemy przejść do GUI lub CLI obsługiwanych serwerów. Jest to płynne i bardzo wygodne, dzięki obsłudze SSO (Single Sign On).

Uproszczenie obsługi zaawansowanych funkcji systemu dyskowego
 
Pomimo bardzo dobrej obsługi i dużej ilości zaawansowanych funkcji systemu dyskowego w systemach z jądrem Linux, ich wzajemna wielowarstwowa integracja i późniejsza obsługa wcale nie jest łatwa.
 
Dlatego Red Hat zdecydował się na wprowadzenie narzędzia Stratis.
 
Stratis to VMF (Volume-Managing Filesystem), którego zadaniem jest uproszczenie obsługi zaawansowanych funkcji dyskowych, jakie udostępnia nam jądro systemu Linux. Tworzone przez Stratis pule przestrzeni dyskowej mogą zawierać urządzenia blokowe, jak i woluminy LVM. Następnie z takich puli tworzone są systemy plikowe, których dane rezydują w puli. Stosowanym przez nie systemem plików jest XFS. Obsługiwana jest także funkcja migawek (ang. snapshots) z systemu plików. Stworzone systemy plików mogą rosnąć dynamicznie i cyklicznie zwracać nieużywaną przestrzeń do puli (fstrim). To tylko ogólny zarys działania.
 
Stratis ma stać się narzędziem, które pozwoli nam w łatwy i spójny sposób konfigurować szyfrowanie, multipathing, tiering, kompresje, deduplikacje i wiele innych zaawansowanych funkcji systemu dyskowego.
 
Więcej szczegółów o działania oraz rozwoju kolejnych wersji Stratis znajduje się w Stratis Software Design.

Lepsze wykorzystanie przestrzeni dyskowej XFS
 
COW (Copy-on-Write) w XFS zapewnia oszczędność czasu i miejsca na dysku przy klonowaniu plików (nawet dużych plików maszyn wirtualnych). Nowa przestrzeń dyskowa konsumowana jest tylko w trakcie modyfikacji danych.
 
O ile funkcja ta jest podobna do twardych dowiązań (ang. hard links), to bardzo się od nich różni. W twardych dowiązaniach jest tylko 1-inode, stąd wszystkie jego metadane, jak uprawnienia, czy właściciel musiały być takie same. Także wszelkie modyfikacje mają wpływ na wszystkie "kopie" utworzone za pomocą twardego dowiązania.
 
COW tworzy tzw. reflink, w którym każdy klon oryginalnego pliku ma swój własny inode, stąd też może mieć inne metadane. Zmiany wprowadzone w jednym z plików nie modyfikują innych jego klonów. Tylko zmodyfikowane obszary są kopiowane i zajmują miejsce na dysku. Obszary, które są takie same pomiędzy klonami znajdują się na dysku tylko raz. Jest to coś, co można nazwać migawką pliku (ang. file snapshot).

Poprawiona obsługa pakietów i oprogramowania
 
System jest mało użyteczny bez dodatkowego oprogramowania, stąd w tym obszarze także dużo się zmieniło. Dzięki wykorzystaniu modułów i strumieni, udało się uprościć sposób pozyskiwania oprogramowania.
 
Moduły (ang. modules) są nowym sposobem grupowania pakietów, które wspólnie tworzą profil aplikacyjny. Jedno repozytorium może obsługiwać wiele takich modułów równolegle. Moduły mogą zawierać wiele strumieni, udostępniając możliwość instalacji różnych wersji tej samej aplikacji. Strumień (ang. stream) reprezentuje znacząco inną wersję tej samej aplikacji. Najczęściej nowy strumień tworzony jest, kiedy nowa wersja aplikacji przestaje być kompatybilna wstecz. W ramach modułu może być aktywny tylko jeden strumień aplikacyjny. Zainstalowanie jednego strumienia aplikacji całkowicie zastępuje poprzedni, bez względu czy jest to upgrade, czy downgrade.
 
Zatem nie możemy posiadać kilku wersji tej samej aplikacji w ramach jednej przestrzeni użytkownika, co było możliwe z RHSCL (Red Hat Software Collections). Na szczęście jest to obecnie rzadko potrzebne, ze względu na wszechobecną wirtualizację i konteneryzację. Za to plusem tego jest to, że aplikacja zawsze będzie instalowana w standardowych lokalizacjach struktury katalogowej systemu.
 
Moduły całkowicie zastępują RHSCL, dając możliwość oddzielenia cyklu życia systemu operacyjnego od cyklu życia używanych aplikacji. Moduły instalowane są niezależnie od systemu operacyjnego. Oznacza to, że wersje pakietów oprogramowania systemu operacyjnego nie mają wpływów na oprogramowanie modułów i odwrotnie.
 
Skutkiem tego w RHEL8 mamy tylko dwa główne repozytoria, które powinny w większości zastosowań wystarczyć:
  • BaseOS - pakiety wymagane do minimalnej instalacji systemu operacyjnego, które tworzą bazę przestrzeni użytkownika (ang. userspace) na wybranym sprzęcie, środowisku wirtualnym, w chmurze lub kontenerze.
  • AppStream - cała reszta pakietów oprogramowania wykorzystywanego w przestrzeni użytkownika, poza tymi, które wymagają dodatkowych subskrypcji (ang. add-on-ettitlements).

Mamy także oddzielne repozytorium z własnościowym oprogramowaniem i oddzielne dla deweloperów:

  • Supplemental - tak samo jak RHEL7, zawiera dodatkowo licencjonowane i własnościowe oprogramowanie.
  • CodeReady Linux Builder - pakiety wykorzystywane typowo w trakcie budowania kodu. Jest to repozytorium dedykowane dla deweloperów, którego elementów nie powinno się używać w środowisku produkcyjnym. 

Dodatkowo, 24 września 2019 roku zostało uruchomione repozytorium CentOS Stream. Zawiera ono wersje pakietów, które w najbliższym czasie ukażą się w systemie RHEL. CentOS Stream, to coś pomiędzy pakietami z Fedora, a RHEL. Repozytorium to powstało z myślą o deweloperach tworzących rozwiązania sprzętowe oraz oprogramowanie będące częścią ekosystemu Red Hat. Dzięki temu, mogą oni przygotować i dostosować swoje produkty do nowych wersji pakietów systemu RHEL o wiele wcześniej.

Na tym zamyka się zestaw repozytoriów dla samego systemu RHEL8. Wszystkie dodatki do systemu RHEL8, jak m.in.: High Availability, Resilient Storage, Real Time i Real time for NFV mają także swoje oddzielne repozytoria do których dostajemy dostęp po zakupieniu odpowiednich subskrypcji. Są to tak zwane add-on repositories.

Repozytoria Extras i Optional zostały usunięte. Pakiety z nich zostały przeniesione do AppStream lub odrzucone. Odrzucone mogą trafić w przyszłości do EPEL (Extra Packages for Enterprise Linux).

Zastosowanie modułów oraz strumieni jest nieco bardziej złożone, ale za to przemyślane i skalowalne. Dla przykładu, w ramach jednego strumienia możemy też mieć wiele profili tej samej wersji aplikacji z różną konfiguracją. Profile mają odzwierciedlać różne przypadki użycia tej samej wersji aplikacji, dając w ten sposób możliwość dostarczenia razem z aplikacją plików o różnej zawartości. Jeżeli funkcje modułów, strumieni i profili nie są nam potrzebne, możemy posługiwać się yum tak jakby ich nie było i robiliśmy to do tej pory.

RHEL8 używa yum w wersji 4, które stosuje wewnętrznie technologię DNF. Zalecanym poleceniem do zarządzania pakietami jest nadal yum, które jest dowiązaniem symbolicznym do polecenia dnf.


Bardziej funkcjonalna oraz bezpieczniejsza obsługa kontenerów i obrazów
 
Żegnamy Docker, a witamy Podman, Buildah i Skopeo:
- Podman - silnik do uruchamiania kontenerów bez daemona (ang. daemonless).
- Buildah - budowanie obrazów kontenerowych (ang. container images) (od zera lub z Dockerfile).
- Skopeo - kopiowanie i inspekcja obrazów kontenerów w rejestrach (ang. container registries).
 
Razem z nimi Red Hat udostępnił obraz UBI (Universal Base Image), który umożliwia każdemu tworzenie kontenerów w oparciu o system RHEL. O ile można z niego korzystać, to wsparcie dla niego od strony Red Hat będzie tylko, jeżeli zostanie uruchomiony od w systemie RHEL lub na platformie Red Hat OpenShift. Więcej o UBI można znaleźć na blog-u Red Hat

Jak już jesteśmy przy obrazach, to warto wspomnieć o wygodnej możliwość tworzenia spersonalizowanych obrazów RHEL8. Obecnie obsługiwane są takie wyjściowe formaty obrazów:
  • QEMU QCOW2 Image (*.qcow2)
  • Ext4 File System Image (*.img)
  • Raw Partitioned Disk Image (*.img)
  • Live Bootable ISO (*.iso)
  • TAR Archive (*.tar)
  • Amazon Machine Image (*.ami)
  • Azure Disk Image (*.vhd)
  • VMware Virtual Machine Disk (*.vmdk)
  • OpenStack (*.qcow2)
Możliwe jest to dzięki Image Builder, którego interfejs dostępny jest z poziomu CLI i poprzez Cockpit.

Kilka funkcjonalności dostępnych już od RHEL7, o których warto pamiętać
 
O ile piszemy tutaj o nowych możliwościach RHEL8, to nie można zapomnieć o tym wszystkim co obsługiwane było w RHEL7 i nadal będzie w RHEL8. Jest tego tyle, że nie sposób wypisać.
 
Do ciekawszych funkcjonalności na pewno należy:
  • VDO (Virtual Data Optimizer), który zapewnia bardzo dużą redukcję danych poprzez zastosowanie deduplikacji (ang. Deduplication ), kompresji (ang. Compression) i eliminacji bloków zerowych (ang. Zero-Block Elimination). Więcej o VDO można znaleźć na blog-u Red Hat.
  • LUKS2 (Linux Unified Key Setup v2), który daje możliwość szyfrowania danych dysku twardego.
  • NBDE (Network Bound Disk Encryption), który sprawia, że LUKS2 staje się skalowalne i wygodne w obsłudze na dużej ilości serwerach. Dzięki NBDE każdy serwer może pobrać klucz potrzebny do odszyfrowania dysku twardego z jednego lub jednego z kilku serwerów pracujących w HA (High Availability). Sprawia to, że nie musimy podawać ręcznie hasła do każdego z dysków w momencie startu systemu operacyjnego. Jeżeli tak zabezpieczony system zostanie wyniesiony i straci dostęp do serwera kluczy, jedyną opcją dostania się do jego danych będzie ręczne wprowadzenie hasła.
  • IEEE 802.1AE (MACSec), czyli szyfrowania pomiędzy kartą sieciową systemu RHEL, a urządzeniem do którego jest ona wpięta. Nowe modele przełączników dostępowych Cisco Catalyst 9000 obsługują IEEE 802.1AE (MACSec), stąd integracja z siecią w tym zakresie nie powinna sprawiać problemów. 
To na pewno nie wszystkie nowości, bo z każdą kolejną podedycją systemu RHEL8 będą pojawiały się nowe funkcjonalności i możliwości wykorzystania wcześniejszych.
 
Mamy nadzieję, że chociaż delikatnie udało nam się przybliżyć co nowego czeka już na nas w RHEL8. Szerzej o każdej z tych funkcjonalności będziemy pisali w osobnych artykułach.

Zapraszamy do kontaktu drogą mailową This email address is being protected from spambots. You need JavaScript enabled to view it. lub telefonicznie +48 797 004 932.