Microsoft na GitHub - czyli przyszła koza do woza

Mikrosoft z miłości do open source ;)

Ostatnio pracowałem nad artykułem na temat projektu Docker. W tamtym czasie wiadomo było jedynie, że Microsoft zamierza wdrożyć technologie Docker do swojej najnowszej wersji systemu Windows Server, nie było jednak wiadomo, czy chodzi tylko o klienta czy również o demona twz. Docker Engine. Dziś już wiadomo, że Microsoft przeportował kod projektu Docker na swój system, a kod umieścił na GitHub. Tak więc Microsoft ma natywnego Dockera. Przyznam się szczerze, że nie śledzę nowości związanych z Microsoft Windows, chyba że ma to coś wspólnego z systemem Linux jak tym razem.

Podczas oglądania prezentacji "Windows Containers: What, Why and How" popadłem w dość znaczne zdziwienie. Oglądając to co prezentują, i co ważniejsze w jaki sposób o tym mówią, pomyślałem sobie "oni wszystko ściągają z GNU/Linux i jeszcze na dodatek udają że to ich inicjatywa". Prezentacje Dockera na ich systemie zaczynają od tego, że jest to ich technologia i nazywa się Windows Server Containers, słowo Docker pada tylko wtedy gdy musi - podczas odpalenia dema i omawiania poleceń, które należy wpisać (polecenia nazywa się "docker").



Moja ocena tej prezentacji jest następująca. Microsoft goni GNU/Linux i Open Source. Starsi linuksiarze pamiętają co o otwartych technologiach i systemie Linux mówił założycie Microsoft. Dziś Microsoft jest na GitHub, który to jest hostingiem systemu rozwijania oprogramowania Git stworzonym przez Linusa Torvaldsa. Co za ironia losu.

Mało tego, Microsoft stworzył .NET na system Linux również w natywny sposób, jak sam tłumaczy na prezentacji "Taking .NET Cross-Platform: Building .NET Applications on Linux and Mac" głównym powodem jest to, iż obecnie rozwój nowych technologi odbywa się na otwartej platformie Linux. Wydaje się, że Mikrosoft już poją że walkę na systemy serwerowe już przegrał, ostatnią przewagą jaką mu zostało jest oprogramowanie. Mikrosoft woli się otworzyć i nakłaniać deweloperów w ten sposób do wyboru ich technologi, póki jeszcze większość oprogramowania użytkowego jest zaimplementowana główne na platformę Windows. Pojęli, że jak poczekają jeszcze dekadę to oprogramowanie zostałoby przepisane na otwarte platformy, a wtedy Mikrosoft zszedłby do roli naprawdę "mikro" oprogramowania.



Kolejną ciekawostką jest to, iż Mikrosoft ma zamiar wprowadzić natywną obsługę SSH do swojego systemu, rewelacja! Tymczasem jest rok 2015. Wygląda na to, iż pojęli to, że w wielu zadaniach interfejs CLI jest efektywniejszy, dlatego już jakiś czas temu wprowadzili PowerShell. Swoją drogą jego stworzenie to kolejny dowód na to, że kopiują sprawdzone rozwiązania z GNU/Linux, który jest na czele rozwiązań Cloud. Jak wspomniałem Mikrosoft ich goni, ale to już nie ta pozycja co 10-15 lat temu. Poza tym przyglądając się prezentacji kontenerów w Windows Server to owszem, przenieśli Dockera, ale Linux oferuje wiele więcej z tym związanych mechanizmów, chociażby to nad czym teraz RedHat tak intensywnie pracuje, czyli wsparcie SELinux dla kontenerów. Swoją drogą jestem ciekaw jakie rozwiązania zastosowali w swoim systemie, które spełniają te same funkcje co cgroups i namespaces w jądrze systemu Linux. Poza tym, to czym Mikrosoft się teraz fascynuje użytkownicy GNU/Linux już dawno wdrożyli w swoich serwerowniach. Puenta jest oczywista, Mikrosoft uczy się od GNU/Linux i próbuje naśladować, to też dobra informacja ;)

Na koniec wspomnę jakie pytania padły po prezentacji kontenerów z publiczności:

• "Czy wspierają domeny?" - No tak, cała filozofia Mikrosoftu, teraz ich obsesja domen nie współgra z koncepcją kontenerów Docker z prostego powodu - to zupełnie dwa różne światy.
• "Co z licencjami?" - Haa, i wszyscy w śmiech wraz z prowadzącym. Wiadomo, że licencje w Mikrosoft są kuriozalne, a tu można tworzyć bardzo wiele i bardzo szybko, a co z haraczem?
• "Co z ochrono przed wirusami?" - Yyy, zapomniałem, oni się bez nich nigdzie nie ruszają ;) Spokojnie Twój antywirus będzie szukał wirusów również wewnątrz kontenerów, także idź się pobawić tylko nie wychodź poza domenę ;)

https://github.com/Microsoft/docker

Re: "Na cztery anteny"

Internet jest zadziwiającym medium informacji. Jeszcze nigdy dostęp do informacji nie był tak prosty. To zadziwiające, że siedząc wygodnie w domu mogę zapoznać się z wynikami opracowań, które przeprowadzono w jednej z najlepszych uczelni na świecie. Tak więc sam dostęp do informacji nie jest dziś problemem, ale czy to znaczy, że potrzeba już tylko chęci do nauki? Hyy, tak, chociaż jest jedno "ale", o którym chciałbym wspomnieć.

Otóż łatwość i otwartość z jaką można umieszczać informacje w internecie (czego oczywiście nie krytykuje) powoduje pewien efekt uboczny zwany - jakością informacji. Ostatnio coraz częściej tego doświadczam. Tytuł tego wpisu nawiązuje do artykułu z PC Format 12/2014, który znalazłem na ich stronie. Moim celem nie jest robienie obciachu dla tej gazety, lecz dementowanie niekompletnych informacji, które tworzą fałszywe diagnozy. Otóż wspomniany artykuł opisuje nowy router WiFi, a dokładnie Nighthawk X4 AC2350 WiFi Router model R7500 firmy NETGEAR, który to podobno jest pierwszym routerem obsługującym nowy standard 802.11ac, co niestety również prawdą nie jest :(.

Przejdźmy jednak do danych technicznych i sposobu przeprowadzenia testu. Otóż jedno i drugie jest nijakie. Nawet na stronie producenta dane techniczne nie zawierają wszystkich szczegółów, które decydują o możliwych do osiągnięcia prędkości. Za to pełno jest tam danych marketingowych. Z kolei prezentowanie wyników testów prędkości z użyciem routera WiFi z czterema antenkami i nie wspomnienie przy tym ile anten ma nasz klient jest totalnym nieporozumieniem. Z całego artykułu najbardziej zapamiętałem to, iż urządzenie to wyglądem przypomina gadżet z gier komputerowych i kosztuje ponad 1000 zł, co jest totalną porażką. Nawet sam autor stwierdził:

"Mimo tak silnej specyfikacji router wcale nie okazał się najszybszym z testowanych przez nas urządzeń – przepustowość była nawet o połowę niższa niż najszybszych routerów."

No właśnie, ciekawe tylko dlaczego :) W tym artykule zabrakło mi odpowiedzi na to pytanie, więc postanowiłem sam o tym napisać. O wspomnianym routerze możemy przeczytać:

"Ma pięć interfejsów gigabit ethernet, interfejs Wi-Fi pracujący w pasmie 2,4 GHz (z przepustowością do 600 Mb/s), a także w pasmie 5 GHz (cztery kanały o teoretycznej łącznej przepustowości 1733 Mb/s)."

Natomiast autor osiągną 79 Mbit/s w standardzie 802.11n 2.4 GHz i 251 Mbit/s w 802.11ac 5 GHz.
Niestety nie wiemy jaka była szerokość kanału, jaki GI ani QAM, ale z przedstawionych danych wnioskuje, że autor miał laptopa z jedną anteną i przeprowadzał testy w zaśmieconej przestrzeni, co wydaje się dziwne, gdy mowa o częstotliwości 5 GHz, ale z drugiej strony skoro miał taką antenę w laptopie to i pewnie nadajnik też miał.

Do pierwszego wyniku (79 Mbit/s) pasuje kanał 40 MHz, GI 800 ns, 16-QAM i kodowanie 3/4, oczywiście w konfiguracji anten 1x1. Wniosek z tego taki że 2.4 GHz jest bardziej zaśmiecony, lub zła/brak konfiguracji kanałów.
Do drugiego wyniku w standardzie 802.11ac (251 Mbit/s) pasuje kanał 80 MHz, GI 400 ns, 64-QAM i kodowanie 2/3, również w konfiguracji anten 1x1.

Więc, jaki jest sens przedstawiania urządzenia z czterema antenami, jeżeli posiadamy klienta tylko z jedną, no chyba że zrobiono by to z czterema takimi klientami. Aby użyć MIMO 4x4 to trzeba mieć w kliencie kartę z czterema antenami, nie wiem czy takie w ogóle się praktykuje na rynku. Natomiast test z użyciem wielu klientów byłby jak najbardziej na miejscu w sensie pojemnościowym, gdyż i tak każdy z nich nie osiągną by więcej niż 433 Mbit/s w teorii. A na pewno nie osiągnęliby tyle wszyscy czterej na raz, gdyż ta puszka ma tylko interfejs LAN 1 Gbit/s :) Nawet gdyby pobierać dane z dysku podłączonego do tej puszki, to i tak na moje oko nie wyciągnęłoby się więcej niż ok. 640 Mbit/s. Dlaczego? Prędkość odczytu dysku przenośnego.

Na koniec wspomnę słów parę o zapisie stosowanym przez producenta, który podaje przepustowość jako "600 + 1733 Mbps" i wychodzi mu 2.33 Gbps. Hehe powiem tak, takie stwierdzenia osiąga się następującą metodą: znajdźmy dwie największe liczby i jeszcze je zsumujmy, będzie dużo :). Teoretycznie, można by go uruchomić jako AP w dwóch standardach i pasmach 2.4 i 5 GHz, ale co z tego jak po pierwsze nawet połowa tej sumy nie przejdzie przez kabel, z którego ta puszka za tysiaka bierze internet/sieć, a po drugie są to prędkości warstwy fizycznej, do aplikacji dochodzi może jakieś 70% tego, reszta zużywana jest na organizacje ruchu - czyli protokoły sieciowe służące do transportu.

Jeżeli ktoś zapytałby się mnie, czy warto kupić taki router WiFi, to odpowiedziałby mu chyba na głowę upadłeś :) No chyba, że chcesz zapłacić za cztery a używać jednej - parafrazując do tytułu ;)

DIME - w obronie prywatności

W ostatniej dekadzie amerykanie stracili części swojej prywatność na rzecz bezpieczeństwa, z czym nie wszyscy do końca zdołali się pogodzić. Jedną z takich osób jest Ladar Levison. W 2013 roku został on zmuszony przez władze U.S. do zamknięcia swojego biznesu, który rozwijał przez 10 lat. Jego firma Lavabit oferowała hosting dla usługi szyfrowanej poczty, która zapewniała prywatność jej użytkownikom. Głównym powodem zamknięcia Lavabit było to, że z jej usług korzystał Edward Snowden’s, w wyniku czego nawet FBI było bezradne. Otóż poczta była zaszyfrowana w taki sposób, że nawet administrator serwisu (Ladar Levison) nie mógł jej podejrzeć bez znajomości odpowiedniego hasła ustalanego przez użytkownika skrzynki.

Ladar Levison zaprzestał hostowania szyfrowanej poczty pod naciskami władz i nowego prawa, ale nie porzucił marzeń o wolności i prywatności użytkowników poczty elektronicznej. Niedługo po tych wydarzeniach utworzył nowy projekt o nazwie Dark Mail, który był kontynuacją rozwoju usługi szyfrowanej poczty jako projektu open source, którą wcześniej oferowała jego firma. Na konferencji DEF CON 22 Levison zaprezentował nowości w projekcie Dark Mail i ogłosił jego nową nazwę Dark Internet Mail Environment (DIME), która ma oznaczać nową bezpieczną architekturę poczty.

Levison chce, aby DIME stał się domyślnym standardem poczty. Trwają prace nad opracowaniem standardu w formie dokumentów RFC. Obecnie nie można nazwać projektu standardem, ale raczej prototypem, a jego rozwój dopiero się rozpoczyna. Ponieważ DIME to nie tylko serwer ale i klient poczty, więc przed autorami jeszcze dużo pracy, dlatego Levison zachęca do współpracy. Obecny klient poczty dla DIME to Volcano, który jest forkiem Thunderbirda, natomiast serwerem jest fork serwera magma używanego wcześniej przez firmę Lavebit. Większość kodu jest dostępna na GitHub Lavabit.

Zanim przejdziemy do omówienia architektury i zasady działania DIME warto wspomnieć na czym polega zasadnicza różnica, pomiędzy pocztą elektroniczną a innymi usługami. Otóż obecnie króluje architektura klient-server, jest tak w przypadku HTTP, FTP, czy DNS. Poczta natomiast w uproszczonym ujęciu działa w architekturze server-server. Jest to chyba jedyna usługa, która do prawidłowego działania wymaga zgodnej konfiguracji dwóch niezależnych serwerów. Innymi słowy mówiąc, nie można wysłać e-maila za pomocą DIME, jeżeli jego odbiorca również nie posiada konta na serwerze obsługującym taką architekture. Poza tym, taki e-mail może przejść przez więcej niż dwa serwery zanim trafi do serwera odbiorcy.

Nie bez znaczenia jest sama architektura serwerów poczty, które implementują kilka protokołów. I tak na przykład do wysłania przeciętnego e-maila zostaną użyte następujące protokoły: SMTP -> SMTP -> POP3/IMAP. Ponieważ jest to dość złożony model, to serwery poczty posiadają modułową budowę, pomijając fakt, że zazwyczaj serwer poczty wychodzącej i przychodzącej to dwa oddzielne serwery (demony). Z grubsza możemy wyróżnić trzech najważniejszych agentów. Mail User Agent (MUA) zajmuje się obsługą swojego użytkownika, ma tu miejsce komunikacja klienta poczty z serwerem poczty. Mail Transport Agent (MTA) zajmuje się transportem listów pomiędzy serwerami nadawcy i odbiorcy. Mail Delivery Agent (MDA) zajmuje się przechowywaniem i dostarczaniem poczty przychodzącej z serwera docelowego do klienta poczty, czyli MUA.  W wysyłce przytoczonego wcześniej przeciętnego e-maila wezmą udział następujące moduły: MUA -> MTA -> MTA -> MDA -> MUA. Jak widać jest to dość złożony proces w porównaniu do HTTP, mimo iż jest to najprostszy model. Dlatego implementacja DIME wcale nie jest prosta.

Architektura DIME składa się z wielu niezależnie zaszyfrowanych warstw oraz menadżera kluczy szyfrujących. Poza tym, jest tak przemyślany, aby każdy podmiot biorący udział w dostarczaniu listu
miał dostęp tylko do minimum potrzebnych mu danych aby wykonać swoje zadanie. Z grubsza możemy wydzielić trzy niezależnie szyfrowane warstwy: koperta (zawiera dane dla serwera źródłowego i docelowego), nagłówek i treść listu. Mimo, iż w warstwie koperty znajdują się dane dla obu serwerów, to są one szyfrowane oddzielnymi kluczami, w wyniku czego serwer nadawcy (Origin) nie ma dostępu do danych przeznaczonych dla serwera odbiorcy (Destination).

Warstwa Envelope (koperta) obsługiwana jest głównie przez agenta MTA, nagłówek obsługiwany jest zarówno przez MUA i MDA, w zależności po której stronie przetwarzanie ma miejsce (nadawca SMTP i odbiorca POP3). Warto nadmienić, że w DIME mamy odczynienie z protokołami Dark Mail Transfer Protocol (DMTP), a nie SMTP i będziemy mieli odczynienia z DMAP zamiast IMAP. W wyniku takiej architektury serwer nadawcy (MTA) nie ma dostępu (klucza) do warstwy nagłówka listu i nie zna adresu odbiorcy. Z kolei serwer odbiorcy nie zna adresu e-mail nadawcy, ponieważ znajduje się on w zaszyfrowanej dla niego warstwie nagłówka, do której klucze posiadają tylko nadawca i odbiorca listu. Dzięki takiemu podejściu nie wystarczy dostęp do któregokolwiek z serwerów poczty aby rozszyfrowaną treść wiadomości, a nawet adresata lub odbiorce w zależności od tego, który serwer został skompromitowany. Do treści listu dostęp mają tylko nadawca i odbiorca listu. DIME korzysta również opcjonalnie z DNSSEC w celu weryfikowania autentyczności domen biorących udział w procesie transportu poczty.

Głównym założeniem projektu Dark Mail jest stworzenie ogólnodostępnego (na zasadach open source) standardu przesyłania szyfrowanej poczty w łatwy do użycia sposób, który w przyszłości zastąpiłby obecny standard poczty elektronicznej. Zaszyfrowany list w architekturze DIME podczas przesyłania przez otwarty Internet dostarcza tylko informacji na temat serwera (hosta) docelowego i źródłowego, nic poza tym. Całość mechanizmu przypomina rosyjską matrioszkę, im głębiej tym mniej podmiotów posiada do niej klucz. Takie podejście gwarantuje nienaruszalność treści listu, co zaczyna budzić duże kontrowersje, zarówno po stronie przeciwników jak i zwolenników. Jednak jak zostało napisane wcześniej, obecnie implementacja DIME ma bardziej charakter demonstracyjny niż produkcyjny, ale już istnieją plany jego implementacji w serwerze Postfix. Nie mniej jednak do upowszechnienia się DIME czeka go jeszcze długa droga, być może nie tylko techniczna ale i prawna, a raczej polityczna.

Dark Internet Mail Environment: Architecture and Specifications [pdf]

Proces nr 1 systemu Linux - systemd

Od ponad 18 lat procesem nr 1 w systemie GNU/Linux jest init, którego obecnie zastąpić ma niejaki systemd. Zmiana tego procesu wywołuje znaczną różnice w korzystaniu z systemu Linux. Zapewne to jest powodem tego, iż wielu użytkowników system Linux znienawidziło go oraz jego autora. W tym tekście postaram się wyjaśnić jaki jest cel wymiany procesu init na systemd oraz co z tego wynika.

Otóż po załadowaniu jądra do pamięci musi zostać uruchomiony jakiś program aby coś robić. W Linuksie pierwszym procesem, który może, a nawet musi uruchomić inne procesy - głównie powłokę - jest init. Gdyby w procesie uruchamiania systemu nie została uruchomiona powłoka poprzez proces login to niemożna byłoby w żaden sposób sterować systemem - chyba, że zostanie uruchomiona usługa SSH. Jak widać pierwszy proces pełni bardzo ważną rolę w systemie i co najważniejsze działa najdłużej w systemie - w sensie czasu, a nie czasu zużycia procesora. Tak więc nie dość, że init jest pierwszym procesem, który zostaje uruchomiony i ostatnim, który jest zamykany to wszystkie pozostałe procesy w systemie są mu podrzędne w hierarchii procesów. Oczywiście nadal można oderwać się poprzez podwójnego forka, ale to już inny temat. Chodzi o to, że proces init będąc rodzicem wszystkich usług system może wykonywać prace, których nie mógłby wykonywać żaden inny proces - jest tylko jeden taki proces - jest nim proces nr 1.

Chodzi o to, że 20 lat temu wymyślono proces init, który był uruchamiany przez jądro, następnie sam odpalał skrypty z lokalizacji /etc/init.d/ i na tym jego praca się "kończyła" - mimo iż działa nadal. Przez wiele lat to wystarczało i nikt nawet nie myślał to zmieniać. Więc dlaczego dziś musimy to zmieniać?

Więc, po pierwsze to wcale nie musimy tego robić, ale obecnie system Linux używany jest do wielu różnych zadań, a jego jądro jest wyposażone w wiele mechanizmów, których wcześniej nie było. Taka kombinacja nowych możliwości i potrzeb zainicjowała poszukiwanie nowych sposobów na usprawnienie systemu. W systemie Linux bardzo często pewne jego części są przepisywane w całości na nowo, to się dzieje cały czas, tylko nie wszystkie te zmiany są widoczne gołym okiem. Z procesem init jest inaczej - dostrzeżono jego potencjał, który może rozwiązać problemy do tej pory nierozwiązane i zdecydowano się to zrobić. Mało tego, wymyślono nowe sposoby wykorzystywania pierwszego procesu i wszystkie te pomysły wcielono do systemd. Wielu uważa, że są to durne pomysły i krytykuje je, ale co ciekawe to tak naprawdę to wszystkie one wcale nie są nowe. Gdyby dokładnie to przeanalizować to okazałoby się że większość z nich doczekała się swojej implementacji w jakiś sposób. Tu różnica polega na tym, że zrobiono to kompleksowo i centralnie. Mało tego, systemd nie jest wcale pierwszy i nie mam tu na myśli Upstart lecz launchd.

Launchd to zamiennik procesu init w systemie Mac OS X, okazał się sukcesem i ktoś po prostu postanowił zrobić to samo w systemie Linux - w wyniku czego został skrytykowany - własnie tak. Jednak krytyka z czasem milknie i największe dystrybucje zaczynają wdrażać nową implementację procesy init - czyli systemd. Launchd nie miał być tylko lepszą wersją pierwszego procesu, lecz całym framework-iem służącym do zarządzania usługami. Tak też zbudowany jest systemd. Systemd to nie jeden demon lecz wiele demonów, dlatego, że koncepcja systemd obejmuje zastąpienie innych demonów takich jak inetd, acpid, udev, syslog, watchdog, cron i atd. Z pomysłu rozbudowania procesu init powstała całą warstwa, która oddzielała jądro od userlandu, i tak należy traktować systemd. Poniższy schemat obrazuje jak wiele elementów system zostało wcielone do tej warstwy.

Architektura systemd - Wikipedia

Systemd to pierwszy krok do podziału demonów na te służące do zarządzania systemem i te oferujące usługi systemowe, takie jak poczta, www itp.. Nawet proces logowania i sesji będzie realizowany w ramach frameworku systemd. Wcześniej pisałem o podwójnym forku, otóż systemd maksymalnie używa mechanizmu cgroups, który uniemożliwia dla uruchamianych procesów ucieczkę od rodzica, a tym samym brak kontroli nad takim procesem. W systemd poszczególne grupy cgroups nazywane są odcinkami (ang. slice) i możemy zobaczyć ich podział chociażby wydając poniższe polecenie.

ps xaf -eo pid,user,args,cgroup

Zabawne, bo podstawową cechą systemd miała być szybkość uruchamiania. Mimo. iż osiągnięto to poprzez mechanizm jednoczesnego uruchamiania usług, to nie ta cecha jest najbardziej widoczną dla użytkowników. Wręcz przeciwnie, jest to jedna z tych zmian, które nie są widoczne gołym okiem. Nie znaczy to, że system wcale nie uruchamia się szybciej dzięki systemd, bo to możemy dokładnie sprawdzić i przeanalizować wydając poniższe polecenie.

systemd-analyze plot> s.svg

Wynikiem jego działania będzie schemat w postaci obrazu, który przedstawia analizę procesu botowania.

Warto tu króciutko wspomnieć ja osiągnięto taki efekt, ale ważniejsze jest w tym to jakie dodatkowe możliwości daje systemd dla usług. Otóż kluczem do uruchamiania wielu usług jednocześnie jest to, że systemd tworzy sockety np. typu AF_INET dla swoich usług, następnie uruchamia te usługi. Jednak już w tym czasie inne usługi (np. B), które również zostały uruchomione ale potrzebują tej pierwszej (np. A) mogą normalnie startować, ponieważ poprzez dostępny socket usługi A myślą, że ta usługa już jest dostępna, podczas gdy tak naprawdę to systemd przetrzymuje w swojej kolejce wszystkie pakiety, które zostały wysłane do tego socketu i przekaże je do jeszcze uruchamianej usługi A, gdy ta zakończy swoje uruchamianie. Efekt będzie taki, że usługa B będzie już gotowa do działania ale brakuje jej jeszcze tylko odpowiedzi od usługi A, czyli ubocznym efektem będzie długi czas oczekiwania, co nie znaczy, że w ostatecznym rozrachunku i tak wszystkie usługi uruchomią się szybciej.
Teraz warto wspomnieć co z tego wynika. Wcześniej jeszcze tylko dodam, że koncepcja centralnego demona zarządzającego socketami to nic innego niż stary inetd. Ale powodem, dla którego komercyjne dystrybucje klasy enterprise wprowadziły systemd jest to, że dzięki takiej centralizacji wykonanej w pierwszym procesie teraz możemy zresetować serwer Apache bez utraty nawiązanych sesji np. https. Mało tego dzięki integracji demona D-Bus z systemd proces, który się zawiesi może automatycznie zostać zrestartowany.

Ciekawą sprawą jest też to, że w systemd nie tylko sockety AF_INET zostały zrównoleglone, ale zrobiono to również z socketami D-Bus (AF_UNIX), a nawet z systemem plików. O systemd można napisać jeszcze bardzo dużo, ale w tym tekście chciałem przekazać ogólną koncepcję, którą realizuje ten projekt.

Więcej informacji:
- Rethinking PID 1
- Wykipedia - systemd
- Why systemd?
- Here We Go Again, Another Linux Init: Intro to systemd
- Understanding and Using Systemd
- Intro to Systemd Runlevels and Service Management Commands

Debian LTS - przedłużone wsparcie dla poprawek bezpieczeństwa

Parę miesięcy temu zakończył się okres wsparcia poprawek bezpieczeństwa dla systemu Debian 6 Squeeze, co wielu użytkowników bardzo martwi, zwłaszcza tych, którzy używają system w firmach i instytucjach. Debian należy do bardzo popularnych dystrybucji wybieranych przez wielu największych graczy w świeci sieciowych usług, np. hostingi.

Niestety świat idzie szybko do przodu i stara polityka systemu Debian zaczyna niektórych irytować. Mniej więcej rok temu oraz mniej więcej rok przed zakończeniem wsparcia łatek bezpieczeństwa dla Debian Squeeze (czyli w czasie wydania nowej wersji stabilnej Debian 7 Wheezy) jeden z większych hostingów [1] oświadczył, iż zamierza porzucić Debiana przez krótki okres wsparcia łatek bezpieczeństwa. Wieść ta wywołała długą dyskusję wśród developerów Debiana [2], której wynikiem było wprowadzenie inicjatywy dłuższego wsparcia zwanej Debian LTS (Long Term Support) [3].

Z jednej strony to dobra wiadomość ale z drugiej Ubuntu oraz CentOS od dawna posiadają wersje LTS swoich dystrybucji. Jednak między Debianem a wymienionymi dystrybucjami istnieje zasadnicza różnica. Debian jest w pełni projektem społecznościowym, natomiast ze Ubuntu LTS stoi Canonical, a CentOS pobiera łatki z FTP RedHat. Jak widać posiadanie wersji LTS to wspólna cecha dystrybucji oferowanych w modelu enterprise, czyli dla biznesu.

Mimo to deweloperzy Debiana podjęli wyzwanie i od paru miesięcy możemy dodać nowe repozytoria dla wersji 6 (oldstable), aby pobierać nadal łatki bezpieczeństwa po oficjalnym wsparciu:

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free 

deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

Projekt LTS rozszerza standardowe wsparcie oferowane przez zespół deweloperów Debiana o dwa lata. Oznacza to, że dzięki tej inicjatywie Debian będzie oferował w sumie 5-cio letnie wsparcie dla łatek bezpieczeństwa. Harmonogram dostępny jest na poniższej stronie [4].

Na tym można by zakończyć i cieszyć się z nowości jaką jest wsparcie LTS w Debianie, ale projekt ten dopiero raczkuje i daleko mu do swoich konkurentów. Otóż na jego realizacje potrzebne są pieniądze, bo jak stwierdzili deweloperzy nie ma co się okłamywać, że w naszym ekonomicznym świecie każdy musi z czegoś żyć. Na dzień dzisiejszy projekt LTS ma kilku sponsorów, których dotacje wystarczają zaledwie na ok 25% potrzeb. Co to oznacza, a no to, że na niektóre łatki bezpieczeństwa w tej chwili trzeba trochę poczekać, ponieważ jest więcej pracy niż pieniędzy (błędy, które nie zostały jeszcze poprawione [5]).

Powstaje więc pytanie, czy Projekt Debiana LTS poradzi sobie ze wyzwaniem, zanim inni zaczną przechodzić na Ubuntu LTS tak jak DreamHost? Czy w czasach, w których system GNU/Linux coraz bardziej asymiluje się ze światem biznesu całkowicie społeczna dystrybucja pozbawiona komercyjnego wsparcia nadąży za konkurencją? Czas pokaże.

[1] http://www.dreamhost.com/dreamscape/2013/06/03/change-is-in-the-air-dreamhost-upgrades/
[2] https://lists.debian.org/debian-devel/2013/08/msg00346.html
[3] https://wiki.debian.org/LTS
[4] http://www.freexian.com/services/debian-lts.html
[5] http://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?revision=HEAD&view=co

SELinux - rozwalające porady

To nic nowego, że w internecie najwięcej porad o SELinux dotyczy jego wyłączenia. Również prezentacje typu ~"Przestańcie wyłączać SELinux" itp. były na porządku dziennym. Red Hat próbuje walczyć z tym, a sposób po jaki już sięgnął nie powstrzymał mnie od napisania tego wpisu - bo już nie wytrzymam :] Zanim zaprezentuje perełki tego tematu słowo wstępu.

Zapewne spotkaliście się z 'wyznawcami' najsłuszniejszego systemu jakim jest GNU/Linux, jaki to on jest bezpieczny itp. oraz z ich przeciwnikami, którzy często podają przykłady typu "gdyby był taki bezpieczny to nie włamali byś się do ..." itp.

Teraz przedstawię genezę jak dochodzi do włamań w najbezpieczniejszym systemie świata :)

Zapewne słyszeliście o tym, że w GNU/Linux konkretną rzecz można zrobić na wiele sposobów (w końcu o co Linuksiarze kłóciliby się ze sobą!). Oto 4 efektywne sposoby na wyłączenie SELinux.

Nikt teraz nie powie, że Linuksa nie można przystosować do swoich potrzeb. Do każdego gustu znajdzie się metoda na to :)

Wracając do tematu, znacie taką firmę IBM, tak, tak, to ta co promuje Linuksa i rozwiązania otwarte. Oferują również świetną dokumentację do swoich produktów, np. jak zainstalować na wirtualnej maszynie RHEL.

Oczywiście instalacja nie mogłaby się powieść bez ptk. 8

Tak zainstalowany system można z powodzeniem zaoferować klientom :)

Skoro jesteśmy przy temacie RHEL, słyszeliście o takim oprogramowaniu cPanel do zarządzania hostingiem - działa głównie na RHEL. Otóż oni też wiedzą jak dobrze postawić swój produkt na 'relku' - najbardziej podoba mi się tytuł podręcznika instalacyjnego - "Installation Guide - Disable SELinux".

Warto zwrócić uwagę na pogrubione stwierdzenie, że do instalacji niezbędne jest wyłączenie SELinux. Nie ma co się dziwić, przecież nie napiszą do swojego produktu (najlepszy ponoć) polityki, nie!

Dan Walsh chyba się załamał bo sięgnął już po metodę jaką jest kolorowanka dla "dzieci" :) Proszę Państwa przedstawiam SELINUX COLORING BOOK.

Książka powstała aby pomóc zrozumieć jak działa SELinux.

Wyjaśniono w niej, iż są procesy różnego typu (kotek i piesek).

Oraz, iż istnieją obiekty różnego typu (jedzenie dla kotka i pieska).

W końcu, wyjaśniono na czym polega mechanizm wymuszanie typów (piesek nie może jeść karmy dla kotka, system go powstrzyma).

Piesek może jeść tylko jedzenie przeznaczone dla niego.

I tak sprawy się mają z bezpieczeństwem w GNU/Linux - miłego kolorowania.

Debian Squeeze bug 668174 with SELinux - workaround for this problem

Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668174

I use Debian Squeeze on server and want set permissive mode from some domain.
In newer version policycoreutils this bug is repaired, but in Debian Squeeze max version is 2.0.82-3.

So I change code in two place:


1. Problem with '/var/lib/selinux'

semanage permissive -a smbd_t
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 460, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 363, in process_args
    OBJECT.add(target)
  File "/usr/lib/pymodules/python2.6/seobject.py", line 275, in add
    os.chdir(dirname)
OSError: [Errno 2] No such file or directory: '/var/lib/selinux'

Change:

head -n 280 /usr/lib/pymodules/python2.6/seobject.py|tail -n 10
    def add(self, type):
               import glob
               name = "permissive_%s" % type
               #dirname = "/var/lib/selinux"
               dirname = "/usr/share/selinux"
               os.chdir(dirname)
               filename = "%s.te" % name
               modtxt = """
module %s 1.0;


2. Problem with '/usr/share/selinux/devel/'

semanage permissive -a smbd_t
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 460, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 363, in process_args
    OBJECT.add(target)
  File "/usr/lib/pymodules/python2.6/seobject.py", line 291, in add
    mc.create_module_package(filename, 1)
  File "/usr/lib/pymodules/python2.6/sepolgen/module.py", line 172, in create_module_package
    self.refpol_build(sourcename)
  File "/usr/lib/pymodules/python2.6/sepolgen/module.py", line 186, in refpol_build
    raise RuntimeError("compilation failed:\n%s" % self.last_output)
RuntimeError: compilation failed:
make: /usr/share/selinux/devel/Makefile: Nie ma takiego pliku ani katalogu
make: *** Brak reguł do wykonania obiektu `/usr/share/selinux/devel/Makefile'. Stop.

Change:

 head -n 128 /usr/lib/pymodules/python2.6/sepolgen/module.py |tail -n 10
        self.checkmodule = "/usr/bin/checkmodule"
        self.semodule_package = "/usr/bin/semodule_package"
        self.output = output
        self.last_output = ""
        #self.refpol_makefile = "/usr/share/selinux/devel/Makefile"
        self.refpol_makefile = "/usr/share/selinux/default/include/Makefile"
        self.make = "/usr/bin/make"

    def o(self, str):
        if self.output:


This is works for me :)