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]
Wednesday, January 21, 2015
Sunday, November 30, 2014
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.
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
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 |
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.
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
Sunday, November 16, 2014
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
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].
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
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
Thursday, November 13, 2014
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.
Saturday, November 8, 2014
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 :)
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 :)
Friday, October 10, 2014
Migration old system from single disk to mirrored LVM volume
Last time I create procedure how to convert standalone system (install on the single disk without any replication) to LVM volume with replication on two hard drive. I can't found in Internet how do this, so I decided published this on my blog.
Scenario
I have old server installed on one hard drive, without hardware/software RAID and without LVM - summarizing without any protection for system files. I would like to protect this system from disk hardware damages. How? I want implement LVM volume, exactly mirror volume. Now I have one hard drive for system, I need a second hard drive. With two hard drive we can create mirrored LVM logical volume.
Of course I would like to do this migration in the most possible easy way and which not taking too long. All procedure which it I presented here I doing in the test installation system on virtual environment (KVM) using Debian distribution.
Main problem
The biggest problem in this migration process is the low capabilities between GRUB bootloader and LVM volumes format. Of course GRUB have "lvm" module and LVM developers work to LVM more compatible with GRUB, but today GRUB can't start from e.g. LVM raid1 volume, so we must use mirrored volume.
Our main goals is to creating replication system from standalone (single disk) system.
LVM migration procedure
So we have system installed on single disk 2GB and this installation using only one partition for all system points e.g. /home, /var.
Before we start move the old system (vda) to the new second disk (vdb) we must reconstruct structure of original disk (vda). Intention, on this is only creates the same type and count partitions, but not size of specific partitions.
In this particular examples we have 2GB partition, but we can create more or less capacity partition. Because I want continue to use old disk (vda) with new bigger disk (vdb has 3GB) in mirror, I can't create greater partition in vdb than has vda, because in vda can fit only <= 2GB mirror images (both images of mirror must by the same size). Furthermore LVM to create mirrored volume require small amount of free space.
So, for this reason we create smallest partitions that has vda < 2GB, exactly 1990MB.
In contrast to vda, vdb has different type of partition - "Linux LVM". Before we can copy system to the new disk with LVM volume we must create PV, VG and LV on vdb1 (if you don't know what it is you must read the LVM documentation).
Scenario
I have old server installed on one hard drive, without hardware/software RAID and without LVM - summarizing without any protection for system files. I would like to protect this system from disk hardware damages. How? I want implement LVM volume, exactly mirror volume. Now I have one hard drive for system, I need a second hard drive. With two hard drive we can create mirrored LVM logical volume.
 |
| Convertion single disk to LVM mirrored volume. |
Of course I would like to do this migration in the most possible easy way and which not taking too long. All procedure which it I presented here I doing in the test installation system on virtual environment (KVM) using Debian distribution.
Main problem
The biggest problem in this migration process is the low capabilities between GRUB bootloader and LVM volumes format. Of course GRUB have "lvm" module and LVM developers work to LVM more compatible with GRUB, but today GRUB can't start from e.g. LVM raid1 volume, so we must use mirrored volume.
Our main goals is to creating replication system from standalone (single disk) system.
LVM migration procedure
So we have system installed on single disk 2GB and this installation using only one partition for all system points e.g. /home, /var.
root@host1:~# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 2.0G 593M 1.3G 31% /
udev 10M 0 10M 0% /dev
tmpfs 49M 180K 49M 1% /run
/dev/disk/by-uuid/993c1a89-40b6-456a-8478-d1c2915782fd 2.0G 593M 1.3G 31% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 97M 0 97M 0% /run/shm
root@host1:~# fdisk /dev/vda
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
244 heads, 47 sectors/track, 365 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
/dev/vda1 * 2048 4192255 2095104 83 Linux
Command (m for help): q
In this particular examples we have 2GB partition, but we can create more or less capacity partition. Because I want continue to use old disk (vda) with new bigger disk (vdb has 3GB) in mirror, I can't create greater partition in vdb than has vda, because in vda can fit only <= 2GB mirror images (both images of mirror must by the same size). Furthermore LVM to create mirrored volume require small amount of free space.
So, for this reason we create smallest partitions that has vda < 2GB, exactly 1990MB.
root@host1:~# fdisk /dev/vdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xbb09b322.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): p
Disk /dev/vdb: 3221 MB, 3221225472 bytes
16 heads, 63 sectors/track, 6241 cylinders, total 6291456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xbb09b322
Device Boot Start End Blocks Id System
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-6291455, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-6291455, default 6291455): +1990M
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): L
0 Empty 24 NEC DOS 81 Minix / old Lin bf Solaris
1 FAT12 27 Hidden NTFS Win 82 Linux swap / So c1 DRDOS/sec (FAT-
2 XENIX root 39 Plan 9 83 Linux c4 DRDOS/sec (FAT-
3 XENIX usr 3c PartitionMagic 84 OS/2 hidden C: c6 DRDOS/sec (FAT-
4 FAT16 <32M 40 Venix 80286 85 Linux extended c7 Syrinx
5 Extended 41 PPC PReP Boot 86 NTFS volume set da Non-FS data
6 FAT16 42 SFS 87 NTFS volume set db CP/M / CTOS / .
7 HPFS/NTFS/exFAT 4d QNX4.x 88 Linux plaintext de Dell Utility
8 AIX 4e QNX4.x 2nd part 8e Linux LVM df BootIt
9 AIX bootable 4f QNX4.x 3rd part 93 Amoeba e1 DOS access
a OS/2 Boot Manag 50 OnTrack DM 94 Amoeba BBT e3 DOS R/O
b W95 FAT32 51 OnTrack DM6 Aux 9f BSD/OS e4 SpeedStor
c W95 FAT32 (LBA) 52 CP/M a0 IBM Thinkpad hi eb BeOS fs
e W95 FAT16 (LBA) 53 OnTrack DM6 Aux a5 FreeBSD ee GPT
f W95 Ext'd (LBA) 54 OnTrackDM6 a6 OpenBSD ef EFI (FAT-12/16/
10 OPUS 55 EZ-Drive a7 NeXTSTEP f0 Linux/PA-RISC b
11 Hidden FAT12 56 Golden Bow a8 Darwin UFS f1 SpeedStor
12 Compaq diagnost 5c Priam Edisk a9 NetBSD f4 SpeedStor
14 Hidden FAT16 <3 61 SpeedStor ab Darwin boot f2 DOS secondary
16 Hidden FAT16 63 GNU HURD or Sys af HFS / HFS+ fb VMware VMFS
17 Hidden HPFS/NTF 64 Novell Netware b7 BSDI fs fc VMware VMKCORE
18 AST SmartSleep 65 Novell Netware b8 BSDI swap fd Linux raid auto
1b Hidden W95 FAT3 70 DiskSecure Mult bb Boot Wizard hid fe LANstep
1c Hidden W95 FAT3 75 PC/IX be Solaris boot ff BBT
1e Hidden W95 FAT1 80 Old Minix
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
Command (m for help): p
Disk /dev/vdb: 3221 MB, 3221225472 bytes
16 heads, 63 sectors/track, 6241 cylinders, total 6291456 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xbb09b322
Device Boot Start End Blocks Id System
/dev/vdb1 2048 4077567 2037760 8e Linux LVM
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Now we can create a normal LVM volume, but before this first we must install LVM.
root@host1:~# aptitude install lvm2
root@host1:~# pvcreate /dev/vdb1
Writing physical volume data to disk "/dev/vdb1"
Physical volume "/dev/vdb1" successfully created
root@host1:~# vgcreate system /dev/vdb1
Volume group "system" successfully created
root@host1:~# lvcreate -n rootfs -L 1900MB system
Logical volume "rootfs" created
root@host1:~# lvs -a
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
rootfs system -wi-a--- 1.86g
Now we got LVM volume and we can create the file system on this volume.
root@host1:~# mkfs.ext4 /dev/system/rootfs
In this point we have all we need to start copy system files to the new partition. But as you know you can't copy from the mounted system, so we must run server from another system. For this goal we use SystemRescueCd. SystemRescueCd has the advantage of it has built in LVM supports.
But before we start copy system files, first we do other things which minimize counts of server restart. Now we create the new GRUB menu entry which allows boot our system from vdb1 (VG system, LV rootfs). Please note that boot the bootloadrer installed in vda will boot system storage in vdb (LVM volume). We don't have there system yet, but first we creates this entry in GRUB menu.
root@host1:~# blkid /dev/system/rootfs
/dev/system/rootfs: UUID="7fa359c8-6bde-4ecd-835b-2f753fd16a49" TYPE="ext4"
root@host1:~# vim /boot/grub/grub.cfg
/dev/system/rootfs: UUID="7fa359c8-6bde-4ecd-835b-2f753fd16a49" TYPE="ext4"
root@host1:~# vim /boot/grub/grub.cfg
 |
| Add new menu entry to GRUB |
You must copy the first menu entry and changes the four things:
Of course this value depends of how you name your LVM groups nad volumes, in this cases it is 'system' and 'rootfs'. The last thing you need to do now is change the name of menu entry e.g. append " LVM".
- add load LVM module ('insmod lvm') before load DOS partition
- change 'set root' value to LVM style: 'system-rootfs'
- update UUID in command 'search' on '--set' parameter
- change is in 'linux' command, the 'root' parameter - also must write to LVM style: '/dev/mapper/system-rootfs'.
Of course this value depends of how you name your LVM groups nad volumes, in this cases it is 'system' and 'rootfs'. The last thing you need to do now is change the name of menu entry e.g. append " LVM".
Now we can back to the copy system files process.
First we must boot our server from CD/DVD and choose default boot options. SystemRescueCd automation scans available drive to LVM metadata, but I do this manually to show that system detect our VG.
Next step we mount both partitions vda1 and vdb1, and copy all system files from it to new LVM volume.
 |
| Run server from SystemRescueCd and work on LVM volume. |
After we copy system files to the new volume we can boot our system from it. So reboot Live system and this time select from menu options 'Run from first hard drive' then we see our new entry in GRUB menu.
 |
| Boot system from vdb using bootloader on vda. |
Now we boot our system from the new copy and you can see different root system file mount point.
root@host1:~# df -hT
Filesystem Type Size Used Avail Use% Mounted on
rootfs rootfs 1.9G 596M 1.2G 34% /
udev devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 49M 188K 49M 1% /run
/dev/mapper/system-rootfs ext4 1.9G 596M 1.2G 34% /
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 97M 0 97M 0% /run/shm
root@host1:~# lvs -a -o +devices
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
rootfs system -wi-ao-- 1.86g /dev/vdb1(0)
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
rootfs system -wi-ao-- 1.86g /dev/vdb1(0)
To have a complete system on our new hard drive with LVM volume yet we miss only bootloader on this disk. So now we install GRUB on the new disk (vdb).
root@host1:~# grub-install /dev/vdb
/usr/sbin/grub-probe: error: no such disk.
Auto-detection of a filesystem of /dev/mapper/system-rootfs failed.
Try with --recheck.
If the problem persists please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <bug-grub@gnu.org>
root@host1:~# grub-install --recheck /dev/vdb
Installation finished. No error reported.
I have done yet command 'update-grub' but this is not necessary, even unnecessary!
root@host1:~# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
Found Debian GNU/Linux (7.4) on /dev/vda1
done
Ok, from this moment we have all completed system with bootloader in new disk, totally independent from original hard drive. In this moment we finished the migration process to LVM. Now we start new process - convert normal LVM volume to mirrored LVM volume.
But first, it is the good moment to check if all service in system work properly, in particular if this is a productions server. You can now reboot system from new disk and try boot them from new disk (vdb).
If all work properly on new disk, then you can go to the next step witch is destroy original disk - yes we need second disk to create LVM mirror volume. For this goal we delete existing data and partition on vda.
root@host1:~# fdisk /dev/vda
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
244 heads, 47 sectors/track, 365 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
/dev/vda1 * 2048 4192255 2095104 83 Linux
Command (m for help): d
Selected partition 1
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
root@host1:~# fdisk /dev/vda
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-4194303, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4194303, default 4194303):
Using default value 4194303
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
/dev/vda1 2048 4194303 2096128 8e Linux LVM
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Next we create identical LVM structure on vda like we have on vdb - first create the new PV, extend VG (system) for new PV (vda1) and last convert exist LV volume (rootfs) to the mirrored volume. LVM automatically use new free PV (vda1) from 'system' VG.
root@host1:~# pvcreate /dev/vda1
Writing physical volume data to disk "/dev/vda1"
Physical volume "/dev/vda1" successfully created
root@host1:~# vgextend system /dev/vda1
Volume group "system" successfully extended
root@host1:~# vgs -a -o +devices
VG #PV #LV #SN Attr VSize VFree Devices
system 2 1 0 wz--n- 3.94g 2.08g /dev/vdb1(0)
root@host1:~# pvs -a
PV VG Fmt Attr PSize PFree
/dev/root --- 0 0
/dev/vda1 system lvm2 a-- 2.00g 2.00g
/dev/vdb1 system lvm2 a-- 1.94g 88.00m
/dev/vdc --- 0 0
/dev/vdd --- 0 0
root@host1:~# lvconvert -m1 system/rootfs
system/rootfs: Converted: 0.6%
system/rootfs: Converted: 74.7%
system/rootfs: Converted: 100.0%
root@host1:~# lvs -a -o +devices
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
rootfs system mwi-aom- 1.86g rootfs_mlog 100.00 rootfs_mimage_0(0),rootfs_mimage_1(0)
[rootfs_mimage_0] system iwi-aom- 1.86g /dev/vdb1(0)
[rootfs_mimage_1] system iwi-aom- 1.86g /dev/vda1(0)
[rootfs_mlog] system lwi-aom- 4.00m /dev/vdb1(475)
In this moment we have the same data in two disk (vda1 and vdb1), to fully happy we miss only bootloader on vda.
root@host1:~# grub-install /dev/vda
Installation finished. No error reported.
Now we can reboot our system and boot it from original disk (vda).
root@host1:~# reboot
Broadcast message from root@host1 (pts/0) (Mon Oct 6 18:44:54 2014):
The system is going down for reboot NOW!
root@host1:~# Connection to 192.168.122.248 closed by remote host.
Connection to 192.168.122.248 closed.
grzesiek@probook:~$ ssh root@192.168.122.248
root@192.168.122.248's password:
Linux host1 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Oct 6 18:34:20 2014 from 192.168.122.1
root@host1:~# df -hT
Filesystem Type Size Used Avail Use% Mounted on
rootfs rootfs 1.9G 596M 1.2G 34% /
udev devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 49M 200K 49M 1% /run
/dev/mapper/system-rootfs ext4 1.9G 596M 1.2G 34% /
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 97M 0 97M 0% /run/shm
root@host1:~# lvs -a -o +devices
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
rootfs system mwi-aom- 1.86g rootfs_mlog 100.00 rootfs_mimage_0(0),rootfs_mimage_1(0)
[rootfs_mimage_0] system iwi-aom- 1.86g /dev/vdb1(0)
[rootfs_mimage_1] system iwi-aom- 1.86g /dev/vda1(0)
[rootfs_mlog] system lwi-aom- 4.00m /dev/vdb1(475)
root@host1:~# grub-install /dev/vdb
Installation finished. No error reported.
root@host1:~#
The last, what we must do, it is install GRUB on vdb, this operaions overwrite existing menu entry witch adds command 'update-grub'.
So now we have identical two disk with LVM mirrored volume. Also we have on each fo them installed bootloader so we can boot from any of them. When one of it is crashed we can boot server from SystemRescueCd and convert missing pair mirrored volume to normal LVM volume from one good disk, and we have our system.
Remember, each time you update kernel or GRUB you must also install GRUB on vdb to be able boot your system from vbd in future. I test this and is working properly :)
 |
| Boot from new disk. |
 |
| Bootloadre in new disk. |
If all work properly on new disk, then you can go to the next step witch is destroy original disk - yes we need second disk to create LVM mirror volume. For this goal we delete existing data and partition on vda.
root@host1:~# fdisk /dev/vda
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
244 heads, 47 sectors/track, 365 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
/dev/vda1 * 2048 4192255 2095104 83 Linux
Command (m for help): d
Selected partition 1
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
root@host1:~# fdisk /dev/vda
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-4194303, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-4194303, default 4194303):
Using default value 4194303
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
Command (m for help): p
Disk /dev/vda: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders, total 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b7ab3
Device Boot Start End Blocks Id System
/dev/vda1 2048 4194303 2096128 8e Linux LVM
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Next we create identical LVM structure on vda like we have on vdb - first create the new PV, extend VG (system) for new PV (vda1) and last convert exist LV volume (rootfs) to the mirrored volume. LVM automatically use new free PV (vda1) from 'system' VG.
root@host1:~# pvcreate /dev/vda1
Writing physical volume data to disk "/dev/vda1"
Physical volume "/dev/vda1" successfully created
root@host1:~# vgextend system /dev/vda1
Volume group "system" successfully extended
root@host1:~# vgs -a -o +devices
VG #PV #LV #SN Attr VSize VFree Devices
system 2 1 0 wz--n- 3.94g 2.08g /dev/vdb1(0)
root@host1:~# pvs -a
PV VG Fmt Attr PSize PFree
/dev/root --- 0 0
/dev/vda1 system lvm2 a-- 2.00g 2.00g
/dev/vdb1 system lvm2 a-- 1.94g 88.00m
/dev/vdc --- 0 0
/dev/vdd --- 0 0
root@host1:~# lvconvert -m1 system/rootfs
system/rootfs: Converted: 0.6%
system/rootfs: Converted: 74.7%
system/rootfs: Converted: 100.0%
root@host1:~# lvs -a -o +devices
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
rootfs system mwi-aom- 1.86g rootfs_mlog 100.00 rootfs_mimage_0(0),rootfs_mimage_1(0)
[rootfs_mimage_0] system iwi-aom- 1.86g /dev/vdb1(0)
[rootfs_mimage_1] system iwi-aom- 1.86g /dev/vda1(0)
[rootfs_mlog] system lwi-aom- 4.00m /dev/vdb1(475)
 |
| Synchronization two volume. |
root@host1:~# grub-install /dev/vda
Installation finished. No error reported.
Now we can reboot our system and boot it from original disk (vda).
root@host1:~# reboot
Broadcast message from root@host1 (pts/0) (Mon Oct 6 18:44:54 2014):
The system is going down for reboot NOW!
root@host1:~# Connection to 192.168.122.248 closed by remote host.
Connection to 192.168.122.248 closed.
grzesiek@probook:~$ ssh root@192.168.122.248
root@192.168.122.248's password:
Linux host1 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Oct 6 18:34:20 2014 from 192.168.122.1
root@host1:~# df -hT
Filesystem Type Size Used Avail Use% Mounted on
rootfs rootfs 1.9G 596M 1.2G 34% /
udev devtmpfs 10M 0 10M 0% /dev
tmpfs tmpfs 49M 200K 49M 1% /run
/dev/mapper/system-rootfs ext4 1.9G 596M 1.2G 34% /
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 97M 0 97M 0% /run/shm
root@host1:~# lvs -a -o +devices
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert Devices
rootfs system mwi-aom- 1.86g rootfs_mlog 100.00 rootfs_mimage_0(0),rootfs_mimage_1(0)
[rootfs_mimage_0] system iwi-aom- 1.86g /dev/vdb1(0)
[rootfs_mimage_1] system iwi-aom- 1.86g /dev/vda1(0)
[rootfs_mlog] system lwi-aom- 4.00m /dev/vdb1(475)
root@host1:~# grub-install /dev/vdb
Installation finished. No error reported.
root@host1:~#
The last, what we must do, it is install GRUB on vdb, this operaions overwrite existing menu entry witch adds command 'update-grub'.
So now we have identical two disk with LVM mirrored volume. Also we have on each fo them installed bootloader so we can boot from any of them. When one of it is crashed we can boot server from SystemRescueCd and convert missing pair mirrored volume to normal LVM volume from one good disk, and we have our system.
Remember, each time you update kernel or GRUB you must also install GRUB on vdb to be able boot your system from vbd in future. I test this and is working properly :)
Tuesday, May 20, 2014
System plików XFS dla enterprise
Ostatnimi czasy publikowane jest coraz więcej informacji na temat nowej wersji systemu Red Hat Enterprise Linux 7. Jedną z zastanawiających nowości jest domyślny system plików, którym w RHEL7 będzie XFS. Wielu użytkowników systemu GNU/Linux może to dziwić, gdyż już tak bardzo przyzwyczailiśmy się do Ext3 i Ext4, że trudno się odzwyczaić. Prędzej spodziewalibyśmy się BTRFS jako nowego domyślnego systemu plików niż XFS. Dlatego ta informacja tak pobudza ciekawość, co takiego jest w XFS, iż to właśnie on został wybrany?
Dla niektórych XFS może wydawać się nową nazwą, ale tak naprawdę system jest ten o wiele starszy od BTRFS, który wystartował w 2007 roku. System plików XFS został opracowany przez Silicon Graphics do swojego systemu IRIX, który używał XFS już od 1994 roku. Do Linuksa przeprotowano go ok. 2000 roku. Od tej pory ciągle ulepszano jego wydajność i to zapewne jest przyczyna tego że to właśnie XFS jest bardziej dopracowany niż obiecujący lecz nie dopracowany BTRFS. W XFS od dłuższego czasu znajduje się mniej błędów, niż w innych popularnych systemach plików. Kolejną różnicą do BTRFS jest to, że XFS ogranicza się do funkcjonalności mieszczących się w tradycyjnym pojęciu systemu plików, tzn. nie zamierza on oferować mechanizmu RAID czy snapshot z poziomu systemu plików. Z drugiej strony, mimo iż jest on od BTRFS starszy niemal o 20 lat to do realizacji podstawowej funkcjonalności użyto w nim równie, a może i bardziej skomplikowanych rozwiązań.
XFS może wydawać się na "staroć" ale takie rozumowanie jest błędne. Otóż ten system plików był projektem realizowanym jako daleko-wyprzedzająca wizja. Widocznie wizja, przyświecająca jego twórców była tak daleka, że dopiero przyszły czasy, w których systemy rzeczywiście będą wykorzystywać jego możliwości. Najlepiej podsumować to tak, że system plików XFS opracowany przez Silicon Graphics był wielką wizją, której celem było obsłużenie wielkich systemów plików, wielkich plików, wielkiej ilości plików i katalogów oraz wielkiej przepustowości I/O. Przy dzisiejszym "zachmurzeniu" najwięksi producenci dystrybucji GNU/Linux zostali zmuszeni do obsługi wielkich systemów plików i wybrali XFS.
Największą cechą XFS jest jego skalowalność. Ext4 jest bardzo szybki i dostatecznie dopracowany, ale do zarządzania danymi używa ciągłych struktur danych co przy większych ilościach zaczyna być problemem. Jeżeli porównasz prędkość operacji Ext4 z XFS na systemie plików o wielkości 2 TB to nie wiele będą się różnić, ale gdy zrobimy to na systemie plików o wielkości 20 TB, to zacznie wychodzić na jaw lepsze przystosowanie XFS do takich systemów. XFS od początku był projektowany na wielką skalę, i dlatego jest zaprojektowany tak, aby korzystać z różnicy budowy takich systemów plików. Do zbudowania systemu plików o wielkości 20 TB trzeba użyć wielu dysków, również maszyna będzie dysponowała wieloma procesorami/rdzeniami. XFS używa struktur AG (grupy alokacyjne) i drzew B+ do reprezentacji systemu plików. Większość operacji może wykonywać niezależnie dla konkretnego dysku twardego i AG, co dzięki dostępności wielu rdzeni pozwala wykonywać wiele operacji jednocześnie na tym samym systemie plików.
XFS wykorzystuje logiczną jednostkę danych zwaną extent, która w zależności od wielkości pliku może składać się z bloków o zmiennej wielkość. Dzięki temu, w jednym systemie plików XFS może używać małych jednostek alokacyjnych (4 kiB) i wielkich do 8 GiB. XFS używa 64-bitowej przestrzeni adresowej i 64-bitowego dziennika transakcji (file system journaling), który wykonuje operacje w sposób niepodzielny, co oznacza że operacja będzie zaksięgowana tylko w przypadku, gdy całość operacji zostanie wykonana. Kolejnym problemem z wielkimi systemami plików jest czas ich sprawdzania po niepoprawnym wstrzymaniu pracy, w XFS znacznie skrócono ten czas do minimum.
Oczywiście XFS wspiera większość podstawowych funkcji, tj. ACL, atrybuty rozszerzone, czy limity (quota). XFS oferuje nie tylko limity na użytkownika i grupę ale również na projekt, co jest raczej niespotykane w innych systemach plików. Można stworzyć jakiś projekt (ID), potem przypisać do niego określone lokalizacja (folder) i nałożyć ograniczenia.
XFS oferuje masę zaawansowanych mechanizmów podnoszących przepustowość I/O w dużych systemach plików. Czy to oznacza, że powinieneś przejść na XFS? Jeżeli nie tworzysz wielkich przestrzeni dyskowych, tylko używasz dysków 2-3 TB to nie ma sensu. Cztery dyski 2 TB, dwa w striping i na dwa kolejne RAID0 - czyli partycja o wielkości 4 TB to użycie XFS nic nie przyśpieszy. XFS należy interesować się przy 10+ TB. Oczywiście wykorzystanie XFS w przytoczonym przykładzie również nie zaszkodzi.
[1] Scalability in the XFS File System
Dla niektórych XFS może wydawać się nową nazwą, ale tak naprawdę system jest ten o wiele starszy od BTRFS, który wystartował w 2007 roku. System plików XFS został opracowany przez Silicon Graphics do swojego systemu IRIX, który używał XFS już od 1994 roku. Do Linuksa przeprotowano go ok. 2000 roku. Od tej pory ciągle ulepszano jego wydajność i to zapewne jest przyczyna tego że to właśnie XFS jest bardziej dopracowany niż obiecujący lecz nie dopracowany BTRFS. W XFS od dłuższego czasu znajduje się mniej błędów, niż w innych popularnych systemach plików. Kolejną różnicą do BTRFS jest to, że XFS ogranicza się do funkcjonalności mieszczących się w tradycyjnym pojęciu systemu plików, tzn. nie zamierza on oferować mechanizmu RAID czy snapshot z poziomu systemu plików. Z drugiej strony, mimo iż jest on od BTRFS starszy niemal o 20 lat to do realizacji podstawowej funkcjonalności użyto w nim równie, a może i bardziej skomplikowanych rozwiązań.
XFS może wydawać się na "staroć" ale takie rozumowanie jest błędne. Otóż ten system plików był projektem realizowanym jako daleko-wyprzedzająca wizja. Widocznie wizja, przyświecająca jego twórców była tak daleka, że dopiero przyszły czasy, w których systemy rzeczywiście będą wykorzystywać jego możliwości. Najlepiej podsumować to tak, że system plików XFS opracowany przez Silicon Graphics był wielką wizją, której celem było obsłużenie wielkich systemów plików, wielkich plików, wielkiej ilości plików i katalogów oraz wielkiej przepustowości I/O. Przy dzisiejszym "zachmurzeniu" najwięksi producenci dystrybucji GNU/Linux zostali zmuszeni do obsługi wielkich systemów plików i wybrali XFS.
Największą cechą XFS jest jego skalowalność. Ext4 jest bardzo szybki i dostatecznie dopracowany, ale do zarządzania danymi używa ciągłych struktur danych co przy większych ilościach zaczyna być problemem. Jeżeli porównasz prędkość operacji Ext4 z XFS na systemie plików o wielkości 2 TB to nie wiele będą się różnić, ale gdy zrobimy to na systemie plików o wielkości 20 TB, to zacznie wychodzić na jaw lepsze przystosowanie XFS do takich systemów. XFS od początku był projektowany na wielką skalę, i dlatego jest zaprojektowany tak, aby korzystać z różnicy budowy takich systemów plików. Do zbudowania systemu plików o wielkości 20 TB trzeba użyć wielu dysków, również maszyna będzie dysponowała wieloma procesorami/rdzeniami. XFS używa struktur AG (grupy alokacyjne) i drzew B+ do reprezentacji systemu plików. Większość operacji może wykonywać niezależnie dla konkretnego dysku twardego i AG, co dzięki dostępności wielu rdzeni pozwala wykonywać wiele operacji jednocześnie na tym samym systemie plików.
XFS wykorzystuje logiczną jednostkę danych zwaną extent, która w zależności od wielkości pliku może składać się z bloków o zmiennej wielkość. Dzięki temu, w jednym systemie plików XFS może używać małych jednostek alokacyjnych (4 kiB) i wielkich do 8 GiB. XFS używa 64-bitowej przestrzeni adresowej i 64-bitowego dziennika transakcji (file system journaling), który wykonuje operacje w sposób niepodzielny, co oznacza że operacja będzie zaksięgowana tylko w przypadku, gdy całość operacji zostanie wykonana. Kolejnym problemem z wielkimi systemami plików jest czas ich sprawdzania po niepoprawnym wstrzymaniu pracy, w XFS znacznie skrócono ten czas do minimum.
Oczywiście XFS wspiera większość podstawowych funkcji, tj. ACL, atrybuty rozszerzone, czy limity (quota). XFS oferuje nie tylko limity na użytkownika i grupę ale również na projekt, co jest raczej niespotykane w innych systemach plików. Można stworzyć jakiś projekt (ID), potem przypisać do niego określone lokalizacja (folder) i nałożyć ograniczenia.
XFS oferuje masę zaawansowanych mechanizmów podnoszących przepustowość I/O w dużych systemach plików. Czy to oznacza, że powinieneś przejść na XFS? Jeżeli nie tworzysz wielkich przestrzeni dyskowych, tylko używasz dysków 2-3 TB to nie ma sensu. Cztery dyski 2 TB, dwa w striping i na dwa kolejne RAID0 - czyli partycja o wielkości 4 TB to użycie XFS nic nie przyśpieszy. XFS należy interesować się przy 10+ TB. Oczywiście wykorzystanie XFS w przytoczonym przykładzie również nie zaszkodzi.
[1] Scalability in the XFS File System
Subscribe to:
Posts (Atom)