Jesień Linuksowa 2009 Materiały konferencyjne

Transkrypt

1 Jesień Linuksowa 2009 Materiały konferencyjne Polska Grupa Użytkowników Linuxa

2 Spotkanie zorganizowali: Dariusz Grzesista, Iwo Graj, Filip Kłębczyk, Łukasz Porębski, Artur Przybyła, Jarosław Jan Pyszny, Wojciech Rakszawski, Michał Sawicz. Imprezę wsparli: Google, Linux Magazine, Wydawnictwa Naukowo-Techniczne. Patronat medialny: Echo Dnia, Radio Kielce. Dziękujemy tym wszystkim, którzy wnieśli szczególny wkład do imprezy. Są to: Andrzej Boczek skarbnik PLUG, potwierdzający wpłaty na konto, Karol Kreński grafik, autor Tukso-Jagi, Krzysztof Leszczyński autor systemu rejestracji elektronicznej PLUG, edytor książki jesiennej.

3 3 Wstępniak Ahihihihihiiii...! demoniczny śmiech wiedźmy zdawał się dobiegać wprost z pobliskiej Łysej Góry. Doigrali się wreszcie, Jesieni im się zachciało! Tyle lat na zlotach kombinowałyśmy, jak ich dopaść, a tu proszę: sami u nas zlot zrobili! Oj będzie się, działo, bęęędzie. Hihihihihi! Witam was, drodzy uczestnicy, na kolejnej, siódmej już edycji Jesieni Linuksowej. Po raz pierwszy w powitaniu wyręczam Panią Prezes, zajętą intensywnie dwoma współbieżnymi procesami potomnymi, które sforkowała była w tym roku. Gratuluję jej z całego serca, życzę wytrwałości w byciu master-procesem i tego, by childy za wiosen kilka również szerzyły idee GNU. A co na imprezie? Prawie wszystko będzie inne. I miejsce, upiorne jak nigdy dotąd, i hotel, odmienna także i mniej napięta agenda, w której po raz pierwszy pojawią się lightning talks oraz czas na krótką wycieczkę. Piwo pojawi się aż w dwóch postaciach: Potężnego Indeksowanego Wyświetlacza Oknowego oraz złotego płynu bogów. Jesień Linuksowa 2009 ma w tym roku studencko-turystyczny charakter, bo i sponsorów, jak na lekarstwo. Mniejszą dawkę gadżetów jesiennych niech zrekompensuje wam czas, który będzie można spędzić na świeżym powietrzu. W końcu Góry Świętokrzyskie jesienią to jedno z najpiękniejszych miejsc w Polsce! Kto zechce wybrać się na spacer, powinien w pierwszej kolejności odwiedzić Łysą Górę, klasztor na Świętym Krzyżu, kryptę Wiśniowieckiego oraz zerknąć na okazałe gołoborze. Spokojny marsz w jedną stronę, asfaltem od bramy parku, to niespełna godzina. Miłego pobytu i do zobaczenia za rok! Dariusz Grzesista

4 Redakcja: Dariusz Grzesista, Filip Kłębczyk, Łukasz Porębski Autorzy: Mariusz Drozdziel, Marcin Hłybin, Borys Musielak, Robert Partyka, Piotr Praczyk, Wojciech Sleńska, Dominik Tomaszuk, Michał Wysocki, Arkadiusz Zieliński Wydawca: Polska Grupa Użytkowników Linuxa, Warszawa, ul. Bartycka 18 Projekt graficzny okładki: Dariusz Grzesista Skład i łamanie: Krzysztof Leszczyński Składu dokonano z wykorzystaniem: OpenOffice.ux.pl, TEX, fonty z dystrybucji TeX-Gyre Druk: Qprint ( Warszawa, ul. Emilii Plater 47

5 5 piątek, 2 października Dojazd do ośrodka, zakwaterowanie Budowanie tanich, wysokowydajnych i wysokodostępnych systemów pod Linuksem (strona 8) Mariusz Droździel Omówienie budowania tanich systemów redundantych active-active i active-passive w oparciu o rozwiązania takie jak vrrp, lvs, keepalived, heartbeat, drbd. Dokładniejsze omówienie ostatnich dwóch zagadanień. Omówienie możliwości, propozycji implementacji oraz ewentualnych problemów. Omówienie zasad działania DRBD active-active przy wykorzystaniu GFS2 i OCFS Kolacja Prezentacja projektu P.I.W.O. (strona 23) A. Zieliński, M. Wysocki, W. Sleńska Projekt PIWO liczy sobie już trzy lata. Historia ta rozpoczęła się jednak jeszcze rok wcześniej. W 2006 roku, pewnego czerwcowego wieczoru kolega Filip Rus, ówczesny student specjalności Aparatura Elektroniczna na wydziale Elektroniki, wracając z zajęć, mijał osiedle studenckie na Wittigowie. Ponieważ słońce chyliło się już ku zachodowi, w części pokoi w akademikach było włączone światło. W sumie to nic nadzwyczajnego podobne obrazki mijamy bezrefleksyjnie każdego dnia. Potrzebny jest nieszablonowy umysł, by w przypadkowym układzie okien zobaczyć coś więcej. A gdyby tak móc panować nad światłem?. To był pomysł jeden z wielu, jakie zazwyczaj kotłowały się w jego głowie, ten jednak nie dał o sobie zapomnieć...

6 6 sobota, 3 października 9 00 Śniadanie Przyszłość WWW oparta o nowe standardy sieciowe HTML5 i XHTML2 Dominik Tomaszuk Przedstawienie nowości w językach HTML5 i XHTML2. Omówienie zmian w podejściu do budowania stron WWW, proponowanych w szkicach W3C. Pokazanie relacji między innymi otwartymi standardami a HTML5 i XHTML Rysowanie po stronach Canvas i Canvas:3D w użyciu (strona 40) Robert Partyka Przedstawienie nowości w językach HTML5 i XHTML2. Omówienie zmian w podejściu do budowania stron WWW, proponowanych w szkicach W3C. Pokazanie relacji między innymi otwartymi standardami a HTML5 i XHTML Postfix my MTA is better than yours! (strona 50) Marcin Hłybin Wycieczka w głąb Postfiksa. Od DNS-ów, przez logi pocztowe do menedżera kolejek. Mapy, filtrowanie, restrykcje, transporty, narzędzia, analiza nagłówków i ciekawe zabawki umilające adminowi pracę z pocztą i utrudniające życie spamerom. Ponadto prezentacja interaktywna z pracą w konsoli i omówieniem konfiguracji i logów Obiad Wyjazd i zwiedzanie ruin pałacu Krzyżtopór w Ujeździe Lightning Talks * Robert Partyka: Słów kilka na temat Mozilla Jetpack, * Marcin Hłybin: Zarządzanie czasem dla adminów i geeków, * Michał Wysocki: FARMER jednopłytkowy komputer z Linuksem na pokładzie, * Andrzej Nowrot: PLVX Polski Węzeł Wymiany Ruchu VoIP Kolacja wieczór przy grillu

7 7 niedziela, 4 października Śniadanie Projekt Apache Hadoop (strona 63) Piotr Praczyk Hadoop jest jednym z projektów rozwijanych przez Apache. Celem jest dostarczenie narzędzi do łatwego tworzenia aplikacji rozproszonych zgodnie z paradygmatem Map Reduce (który jest z powodzeniem wykorzystywany przez Google przy przetwarzaniu ogromnych ilości danych). W swoim wystąpieniu chciał bym przedstawić podstawowe założenia Hadoop a, pokazać możliwe zastosowania oraz przedstawić projekty z nim powiązane, dostarczające często potrzebnych funkcjonalności OpenServices na przykładzie serwisu Filmaster (strona 71) Borys Michuk Musielak Wolne oprogramowanie święci tryumfy na serwerach i desktopach, ale to powoli relikty przeszłości. Przyszłość należy do Internetu, a tu nie jest już tak różowo. Wykład stanowi krótki wstęp do tworzenia otwartych (zgodnych z definicją OSSD) serwisów internetowych na żywym przykładzie serwisu Filmaster.pl Know your tools: OpenSSH Dariusz Puchalak OpenSSH wszystko co chciałbyś wiedzieć o SSH, tylko boisz się zapytać, bo nie wiesz, że można to zrobić. Po pierwsze OpenSSH jest narzędziem, bez którego nie byłbym w stanie wykonywać swojej pracy. Po drugie OpenSSH jest słabo znane. Śmiem twierdzić, że wiedza użytkowników rzadko wykracza poza użycie użycie SSH jako bezpieczengo telnetu/ftp i uwierzytelnianie przy pomocy klucza publicznego. O SSH opowiadałem kilka razy na konferencjach poświęconych bezpieczeństwu IT. Co ciekawe, większość osób wcześniej nie wiedziała, że tak można i że SSH jest przydatne o wiele bardziej, niż im się wydaje Opcjonalny obiad / Czułe pożegnania

8 Budowanie tanich, wysoko wydajnych i wysoko dostępnych systemów pod Linuksem Mariusz Drozdziel «mdrozdziel@novacorp.pl» Klasyfikacja klastrów Pojęcie klastra komputerowego ewoluuje od początków systemów informatycznych razem z rozwojem technologii. Istnieje wiele mniej lub bardziej ścisłych definicji określających co nazywamy klastrem, a co jedynie przypomina go swoją charakterystyką. W dość luźny sposób mianem klastra określana jest grupa komputerów ściśle ze sobą współpracujących, wykonujących to samo lub zbliżone zadanie. Często dla odbiorcy świadczonej usługi stwarzają one pozornie pojedynczą maszynę. Sama nazwa klastrów obliczeniowych (compute cluster) w dość oczywisty sposób wyjaśnia przeznaczenie tego typu systemów. Głównym celem podczas budowania takich rozwiązań jest uzyskanie jak najwyższej mocy obliczeniowej. Wydajność klastrów obliczeniowych mierzona jest w ilości operacji zmiennoprzecinkowych, którą zespół komputerów jest w stanie wykonać na sekundę. Dalszy luźny podział klastrów obliczeniowych bazuje na tym, jak ściśle powiązane są ze sobą poszczególne węzły. W klastrach nazywanych Beowulf węzły połączone są sieciami o wysokich przepustowościach i przystosowane są do wymiany dużych ilości informacji. Na drugim końcu klasyfikacji umieszczone są klastry typu grid, nazywane również rozproszonymi (distributed), gdzie węzły okresowo wymieniają porcje danych i skupiają się na obróbce otrzymanych danych. Najbardziej znanym przykładem klastrów ostatniej kategorii jest projekt Seti@Home.

9 Budowanie tanich, wysoko wydajnych... 9 W ramach drugiej dużej grupy można wyodrębnić klastry usługowe. Przeznaczeniem takich rozwiązań jest najczęściej budowanie systemów świadczących różnego rodzaju usługi. Dzięki rozproszeniu na wiele pojedynczych maszyn, serwery są w stanie obsłużyć większą ilość klientów jednocześnie (load balancing), co pozwala zwiększyć wydajność. Z drugiej strony ważnym zastosowaniem tego typu klastrów jest budowanie systemów wysoko dostępnych (high-availability) i zapewnienie redundancji. Dzięki rozproszeniu systemów i zastosowaniu odpowiednich mechanizmów cała usługa uodporniona jest na awarie pojedynczych elementów. Tego typu rozwiązania pozwalają na zminimalizowanie czasu niedostępności usług podczas planowanych akcji serwisowych. Przy odpowiednio zaplanowanych pracach można dokonać modyfikacje na poszczególnych węzłach, cały czas zapewniając ciągłość pracy usług. Dostępne obecnie nowoczesne rozwiązania pozwalają łączyć funkcjonalność load-balancingu oraz high-availability. Awarie poszczególnych komponentów usług są przeźroczyste dla klientów i powodują jedynie zmniejszenie wydajności całego rozwiązania. Jednocześnie rozwiązania tego typu są zupełnie niewidoczne po stronie odbiorcy usługi i nie muszą być przez niego obsługiwane w specjalny sposób. Przez cały czas klient ma wrażenie, że pracuje na pojedynczym serwerze, co jest podstawową zasadą budowania rozwiązań klastrowych tego typu. Dość trudno w jasny sposób wyodrębnić ogólne metody budowania klastrów zapewniających wysoką wydajność i wysoką dostępność usług. Konkretne usługi można rozpraszać na bardzo wiele sposobów stosując różne mechanizmy. Często najtrudniejszym elementem konfiguracji klastrów jest dobre przeanalizowanie usług i dobór odpowiedniego rozwiązania. Oprócz obecnej sytuacji należy również wziąć pod uwagę ewentualną rozbudowę aplikacji w przyszłości. Dobrze dobrane rozwiązanie powinno być skalowalne w poziomie, czyli pozwalać na łatwe zwiększenie wydajności całego rozwiązania poprzez dodanie kolejnych węzłów bez konieczności skomplikowanych rekonfiguracji. Load balacing (load sharing) przy użyciu wielokrotnych wpisów DNS Najprostszym i jednocześnie najłatwiejszym sposobem rozłożenia obciążenia (load balancing) na wiele maszyn są wielokrotne rekordy A/CNAME w konfiguracji DNS. Oczywiście samo umożliwienie funkcjonowania usług na kliku maszynach jednocześnie może być skomplikowane. W sytuacji kiedy zostanie to osiągnięte, skierowanie ruchu od klientów na kilka maszyn jest bardzo proste w konfiguracji. To rozwiązanie jest sensowne, kiedy do usługi łączy się duża liczba klientów, co w praktyce oznacza usługi udostępnione w Internecie. Przy odpowiednio dużych ilościach połączeń ruch powinien być statystycznie równo rozłożony na poszczególne węzły. Oczywistą wadą takiego rozwiązania jest brak możliwości kontrolowania obciążenia czy funkcjonowania węzłów. Mocno obciążone serwery nadal będą otrzymywały takie same ilości połączeń, jak pozostałe maszyny. W przypadku kompletnej awarii, usługa stanie się niedostępna dla części klientów. Przykładowo, jeżeli w takim rozwiązaniu awarii ulegnie 1 z 5 serwerów, wówczas 20% odbiorców nie będzie mogło korzystać z usługi. Korzystanie z load-balacingu opartego o DNS ma wiele innych wad. Podstawowe z nich to brak kontroli nad sposobem wysyłania zapytań przez klientów DNS

10 10 Mariusz Drozdziel i metod cache-owania wpisów oraz utrudnione rekonfiguracje puli serwerów (albo konieczność stosowania bardzo niskich wartości TTL dla rekordów). Na przestrzeni lat powstawało kilka różnych projektów, których zadaniem była rozbudowa i usprawnienie load-balancingu opartego o DNS (lbnamed). Ponieważ jednak samo wykorzystanie DNS do tego celu stwarza wiele problemów aplikacje te nigdy nie rozwinęły się do bardzo zaawansowanego poziomu. Redundancja i mechanizmy load balancing/high-availabilty zostały rozbudowane na innych warstwach i w innych obszarach infrastruktury. Obecnie load balancing oparty o DNS jest powszechnie wykorzystywany głównie w przypadku bardzo dużych (w skali światowej) serwisów, które odwiedzane są przez miliony klientów. Często mechanizm ten wykorzystuje się do geograficznego rozproszenia zapytań, a same adresy wskazują na różne centra danych. Pod samymi adresami IP kryją się natomiast nie pojedyncze węzły, a kolejne systemy klastrowe, oparte już o bardziej zaawansowane mechanizmy. W przypadku serwerów WWW lub innych serwerów treści wpisy w DNS wskazują często na rozproszone systemy cache. VRRP Z założenia VRRP (Virtual Router Redundancy Protocol) to protokół opracowany w celu zapewnienia wysokiej dostępności default gateway-a w segmentach sieci IP. Dwa (lub więcej) fizyczne routery są skonfigurowane aby poprawnie pełnić tą funkcję w segmencie. Jeden z nich rozgłasza faktyczny adres bramy i obsługuje ruch, podczas gdy pozostałe są gotowe przejąć jego zadania w razie potrzeby. Kiedy aktywny router (master) przestaje rozgłaszać pakiety VRRP oznacza to, że utracił możliwość poprawnego routowania ruchu. Wówczas jeden z zapasowych routerów (backup) przejmuje jego funkcję. Wybór nowego mastera odbywa się bazując na podstawie prekonfigurowanych priorytetów. Idea działania i same implementacje VRRP są stosunkowo proste. Również sama konfiguracja i zarządzanie nie są skomplikowane. W praktyce najczęściej spotyka się konfiguracje złożone z dwóch routerów, co w większości przypadków zapewnia wystarczającą niezawodność. Architektura VRRP ma typową charakterystykę protokołów active-passive. Przy odpowiedniej konfiguracji można jednak z powodzeniem aktywnie wykorzystywać więcej niż jedno urządzenie, zapewniając zarówno równoważenie obciążenia, jak i wysoką dostępność. Mimo że pole działania VRRP mieszczą się w obrębie warstwy sieciowej, to elastyczność protokołu pozwala wykorzystać go jako element klastrowania aplikacji. Najprostszym tego przykładem może być rozszerzenie opisywanego wcześniej rozwiązania równoważenia obciążenia wykorzystującego DNS. Ograniczeniem VRRP w tej kwestii jest konieczność umiejscowienia wszystkich węzłów w jednym segmencie (domenie kolizyjnej) sieci LAN. W przykładowej realizacji domena, pod którą zlokalizowana jest usługa, powinna zawierać kilka równoważnych rekordów A/CNAME wskazujących na różne urządzenia. Wszystkie te adresy powinny być skonfigurowane jako funkcjonujące wirtualne adresy w różnych grupach VRRP [1]. Wszystkie elementy takiego klastra powinny być we wszystkich grupach VRRP, a każda z tych grup powinna mieć innego mastera. Dla przykładowego rozwiązania składającego się z 5 serwerów w stanie początkowym przychodzący ruch będzie zrównoważony na wszystkie. Jeżeli jeden z nich zostanie wyłączony, wówczas dzięki wykorzystaniu VRRP jego adres IP

11 Budowanie tanich, wysoko wydajnych Rys 1 Przykład load-balacingu opartego o DNS + VRRP zostanie przypisany do któregoś z pozostałych 4 węzłów. Od tej chwili 3 elementy będą obsługiwały po 20% ruchu, a jeden z nich 40%. Optymalnym stanem wyjściowym byłaby sytuacja, kiedy po awarii jednego z węzłów jego ruch zostanie równo rozłożony na działające serwery. Niestety powyższe rozwiązanie uniemożliwia taką konfigurację. Jeżeli jeden z węzłów nie będzie w stanie nagle obsłużyć dwukrotnie większego ruchu trzeba wykorzystać inne metody. Oczywiście takie rozwiązanie nadal posiada bardzo wiele wad. W przedstawionej postaci brakuje przede wszystkim zaawansowanych mechanizmów sprawdzania poprawnego funkcjonowania aplikacji. VRRP zadziała tylko wtedy, kiedy wirtualny IP przestanie być rozgłaszany przez obecnego mastera. W przypadku awarii samej aplikacji serwer nadal będzie poprawnie obsługiwał warstwę sieciową, co spowoduje awarię usługi dla części odbiorców. Oczywiście do takiego rozwiązania można wprowadzić kolejne elementy, jak proste sprawdzanie działania aplikacji wewnątrz serwerów. W przypadku stwierdzenia awarii prosty skrypt może wyłączyć podsystem VRRP, co automatycznie spowoduje przeniesienie adresu IP na inną maszynę. Oczywiście samo rozwiązanie ma charakteryzować się prostotą. Jeżeli do poprawnej implementacji całości konieczne jest stworzenie wielu dodatkowych mechanizmów, napisanie wielu skryptów, wówczas warto przeanalizować cała sytuację i wybrać inne rozwiązanie. Warto nadmienić, iż w powyższej konfiguracji aplikacje nie będą poprawnie nasłuchiwać na adresach IP, które pojawiły się na interfejsach dopiero po tym jak aplikacja została uruchomiona. Aby aplikacja na serwerze, na który przeniesiono adres IP poprawnie obsługiwała połączenia na ten adres, konieczna jest reinicjalizacja obsługi

12 12 Mariusz Drozdziel sieci tej aplikacji. Niektóre aplikacje mają zaimplementowaną możliwość ponownego przeskanowania interfejsów bez przerywania dotychczasowej pracy - przykładowo OpenSWAN (ipsec whack listen). W skrajnych przypadkach awaria, bądź kontrolowane wyłączenie jednego z węzłów może oznaczać zerwanie połączeń nawiązanych zarówno do wyłączanego węzła, jak i węzła, na którym dodany zostanie nowy adres IP. Rozwiązania oparte wyłącznie na VRRP mają więc bardzo wiele wad i są bardzo ograniczone. Należy jednak pamiętać, że charakteryzuje je niesamowita prostota działania i co za tym idzie prostota w konfiguracji, i zarządzaniu. W praktyce VRRP lub podobne narzędzie spełniające podobną funkcję jest nieodzownym elementem większości rozwiązań zapewniających wysoką dostępność systemów informatycznych. Istnieje kilka implementacji protokołu VRRP działających pod Linuksem. Najbardziej popularny z nich to zapoczątkowany przez Jerome Etienne vrrpd. Poniższe polecenia wykonane na dwóch systemach w jednej podsieci powodują uruchomić obsługę VRRP i udostępnienie adresu IP , który w przypadku awarii serwera A będzie dostępny na serwerze B. Ilustruje to prostotę, jaką charakteryzuje się obsługa tego rozwiązania. SerwerA# vrrpd -D -i eth0 -v 50 -p SerwerB# vrrpd -D -i eth0 -v 50 -p Inną popularną aplikacją implementują między innymi VRRP jest keepalived. Poza podstawową funkcjonalnością VRRP aplikacja pozwala również na definiowanie skryptów, które zostaną wykonane po zmianach umiejscowienia adresów IP. Skrypty można wykorzystać na przykład do poinformowania aplikacji, że na interfejsach pojawił się nowy adres IP, który powinien być przez aplikacje obsługiwany. Przykładowa konfiguracja VRRP w keepalived na jednym z węzłów: } vrrp_instance VRRP_1 { interface eth0 state MASTER virtual_router_id 50 priority 20 virtual_ipaddress { /24 } notify_backup "/usr/local/bin/vrrp.sh BACKUP VRRP_1" notify_master "/usr/local/bin/vrrp.sh MASTER VRRP_2" Przy okazji aplikacji implementujących automatyczny failover adresów IP warto również wspomnieć o Common Address Redundancy Protocol alternatywnej implementacji funkcjonalności VRRP, która powstała w ramach projektu OpenBSD. Implementacja CARP pod nazwą ucarp istnieje również w wersji linuksowej i jest dostępna w podstawowym zbiorze pakietów wielu popularnych dystrybucji.

13 Budowanie tanich, wysoko wydajnych LVS Linux Virtual Server to rozwiązanie zapewniające zaawansowane metody rozkładania obciążenia pomiędzy wiele serwerów (load balancing). Jednym z podstawowych założeń LVS, jest całkowita przeźroczystość rozwiązania dla użytkowników usługi. W standardowych instalacjach faktyczna struktura klastra LVS jest całkowicie ukryta przed klientami i sprawia wrażenie pojedynczej usługi. Projekt jest intensywnie rozwijany od ponad 10 lat. Kod LVS trafił do oficjalnej gałęzi kernela pod koniec 2003, tak więc w gałęzi 2.6 znajduje się od pierwszego wydania. Zarządzenie tablicą LVS wykonywane jest przy użyciu oficjalnego narzędzia ipvsadm, które znajduje się w większości popularnych dystrybucji. Na przestrzeni lat, kiedy LVS zyskiwał na popularności, powstało bardzo wiele zewnętrznych narzędzi. Usprawniają one zarządzanie i rozszerzają funkcjonalność LVS, ułatwiając budowanie bardzo zaawansowanych instalacji. Podstawowym elementem infrastruktury klastra LVS jest director serwer zajmujący się przekierowywaniem połączeń na faktyczne maszyny z uruchomionymi aplikacjami (real servers). Klienci, nawiązując połączenie z adresem usługi, łączą się faktycznie do directora LVS, który bazując na swojej konfiguracji, przesyła pakiety do faktycznych serwerów. LVS implementuje wiele różnych algorytmów szeregujących połączenia. Korzystając z dodatkowych narzędzi można na bieżąco dostosowywać metrykę poszczególnych maszyn do faktycznych zasobów, jakie są na nich dostępne. Pozwala to na optymalne wykorzystanie zasobów na wszystkich maszynach. LVS działa na warstwie transportowej, obsługując protokoły TCP, UDP a także ESP i AH. Usługi poszczególnych wirtualnych serwerów definiuje się przez parę IP oraz port, na które wysłany został pakiet lub bazując na markowaniu iptables (fwmark). Ogólna zasada działania LVS jest bardzo prosta. Po otrzymaniu pakietu na adres, na którym zdefiniowana jest wirtualna usługa, pakiet zostaje przekazany do serwera wybranego na podstawie skonfigurowanego algorytmu szeregującego. Jednym z kluczowym elementów LVS jest metoda, jaką zostanie przekazany pakiet. Możliwe są trzy sposoby: tłumaczenie adresów (NAT), bezpośredni routing (dr direct routing) oraz tunelowanie (TUN). Ostatnie dwie metody są bardzo zbliżone zarówno od strony konfiguracji całego środowiska, jak i wydajności. Podstawowa różnica to konieczność obsługi dekapsulacji IPIP po stronie węzłów. W przypadku dedykowanych urządzeń może to niekiedy stanowić problem. Popularne systemy operacyjne (Linux/FreeBSD, Windows 2000 i nowsze) posiadają tę możliwość. LVS-NAT wykonuje przeadresowanie NAT adresów docelowych w pakiecie IP, który przekazywany jest do real serverów. Pakiet odbierany od directora przez serwer faktyczny jest przeadresowany, tak więc nie potrzebna jest żadna dodatkowa konfiguracja po stronie węzłów. Oczywiście w celu zapewnienia poprawnego funkcjonowania całej instalacji, pakiet wracający od serwera do klienta musi też przejść przez director. Aby klient poprawnie zinterpretował pakiet od serwera, musi odbyć się translacja w drugą stronę. W praktyce takie rozwiązanie osiąga się bardzo prosto, umieszczając director przekazujący pakiety w trybie LVS-NAT na domyślnej bramie w podsieci real serverów. Siłą rzeczy LVS-NAT nie będzie poprawnie obsługiwał połączeń od komputerów w tej samej podsieci, w której znajdują się serwery usługowe. Pakiety od serwerów do klientów ominą director i dotrą do klientów z innym niż oczekiwany

14 14 Mariusz Drozdziel Rys 2 Przykład load-balacingu opartego o LVS-NAT adres źródłowy. Niewątpliwą zaletą LVS-NAT jest prosta logika działania i bezproblemowe utrzymanie w przeciwieństwie do LVS-DR. Wadą tego rozwiązania w stosunku do czystego przekazywania pakietów jest przede wszystkim zwiększenie opóźnienia pakietów przechodzących przez director. Sytuacja jest zauważalna zwłaszcza przy ruchu charakteryzującym się dużą ilością małych pakietów. Dodatkowym minusem wariantu LVS-NAT jest kilkukrotnie większe zużycie mocy obliczeniowej procesora na directorze (w porównaniu do LVS-DR). LVS-DR polega na przekazywaniu pakietów bez żadnej ingerencji w ich zawartość. LVS przesyła pakiet adresując go na warstwie łącza wedle adresu IP wybranego real servera. Sam pakiet zawiera jednak w nagłówku pierwotny adres IP obsługiwany na directorze. Aby serwer poprawnie zinterpretował taki pakiet, jego konfiguracja musi być specjalnie modyfikowana. Nie tylko komplikuje to samą konfigurację, ale ogranicza również liczbę systemów operacyjnych, które będą w stanie funkcjonować jako węzły w klastrze LVS-DR (LVS-TUN). Najprostszym rozwiązaniem, jest konfiguracja tego samego adresu IP, pod którym funkcjonuje director również na real serverach. Z oczywistych powodów adres IP na faktycznym serwerze nie może być rozgłaszany w lokalnym segmencie sieci LAN. (serwer nie może odpowiadać na zapytania ARP o ten adres IP). LVS-DR narzuca jeszcze wiele innych ograniczeń i w pewnych sytuacjach komplikuje konfigurację. Konfiguracja poszczególnych elementów i wydajnośc LVS-TUN jest bardzo zbliżona do LVS-DR. Tunelowanie pozwala na umieszczenie serwerów z aplikacjami w innej podsieci aniżeli sam director.

15 Budowanie tanich, wysoko wydajnych Rys 3 Przykład load-balacingu opartego o LVR-DR Ogólną zaletą rozwiązań LVS-DR/TUN jest przede wszystkim wydajność. Nawet w bardzo obciążonych instalacjach LVS nie różni się znacząco od zwykłego forwardowania pakietów. Dodatkowo, pakiety odsyłane z serwerów do klientów nie muszą przechodzić przez director (w wielu sytuacjach nawet nie powinny). Decyzja wyboru metody przekazywania pakietów nie jest prosta i zależy w dużej mierze od konkretnej sytuacji. Sprowadza się to zazwyczaj to wyboru między łatwą i prostą konfiguracją, a wydajnością. Narzut LVS-NAT nie jest jednak krytyczny i w wielu sytuacjach będzie niezauważalny. Na stronie projektu LVS [2] można znaleźć bardzo obszerne opracowania dotyczące wydajności różnych wariantów LVS w różnych sytuacjach. Dość istotną cechą LVS jest możliwość tworzenia skojarzeń klient konkretny serwer (opcja konfiguracyjna LVS persistance). W praktyce oznacza to, że nowe połączenia przychodzące na director od tego samego klienta będą kierowane na ten sam serwer. Taka zależność ma kluczowe znaczenie dla instalacji obsługujących połączenia SSL, FTP, czy nawet HTTP (utrzymanie sesji). Sam LVS obejmuje jedynie elementy zapewniające load balancing usług. Awaria któregokolwiek z serwerów spowoduje częściową niedostępność usług, natomiast awaria directora powoduje niedostępność całkowitą. Elementy te można wprowadzić

16 16 Mariusz Drozdziel do systemu wykorzystując dodatkowe narzędzia. Najbardziej popularne rozwiązania to keepalived czy ldirectord i heartbeat. Keepalived Główną ideą projektu keepalived [3] jest rozszerzenie LVS o dwie podstawowe funkcjonalności. Sprawdzanie dostępności usług oraz zapewnienie redundancji directorów LVS poprzez wprowadzenie mechanizmu failover. Zaawansowany system sprawdzania dostępności usług potrafi na bieżąco dodawać i usuwać serwery z puli LVS. Keepalived ma zaimplementowany niezależny stos VRRP2, wykorzystywany do obsługi redundancji samego directora LVS przez przenoszenie jego funkcjonalności na inną maszynę. Monitorowanie usług na poszczególnych serwerach w obrębie klastra LVS odbywa się przez cykliczne symulowanie połączeń klienckich. Keepalived posiada wbudowaną obsługę kilku podstawowych testów pozwalających na proste monitorowanie serwera HTTP, HTTPS, SMTP lub dowolnego portu TCP. Istnieje również możliwość uruchomienia własnego skryptu, którego kod powrotu definiował będzie stan usługi. Ta funkcjonalność daje ogromną dowolność w konfigurowaniu testów i badanie praktycznie każdego elementu klastra. Wykrycie awarii serwisu powoduje automatyczne wyłączenie danego serwera z puli, na którą przekierowywane są połączenia. W praktyce spowoduje to, że obciążenie zostanie rozłożone na pozostałe maszyny wedle ustalonych wcześniej reguł zależnie od algorytmu szeregującego i ewentualnej predefiniowanej wagi (metryki). Keepalived pozwala również na definicję odrębnego serwera, na który ruch kierowany będzie dopiero podczas awarii wszystkich innych węzłów. W przypadku serwerów WWW może to być przykładowo serwer wyświetlający czytelną informację o awarii. Stos VRRP w keepalived wprowadza kolejną bardzo istotną funkcjonalność. Keepalived uruchomiony na dwóch lub więcej serwerach pozwala wprowadzić pełną redundancję samego directora. W przypadku braku rozgłaszania pakietów VRRP zapasowy keepalived przejmie adres IP i uruchomi alternatywny director. W przypadku wykorzystania LVS-DR istnieje możliwość konfiguracji samego keepalived w trybie active-active. Wykorzystując dwie oddzielne wirtualne grupy VRRP, możemy skonfigurować dwie pary directorów active-passive. Wpisując obydwa adresy pod nazwa DNS usługi uzyskamy podobny efekt jak opisany wcześniej balancing DNS-VRRP. W tym przypadku pod adresami IP kryć się będą nie konkretne usługi, ale directory LVS. W efekcie uzyskamy pełną konfigurację active-active w obrębie całego klastra. Zapewniona zostanie w ten sposób wysoka dostępność, failover oraz optymalne wykorzystanie wszystkich zasobów. LVS w połączeniu z keepalived pokrywa praktycznie wszystkie aspekty sprawnego rozdzielania obciążenia i redundancji systemów. Wszystkie omówione przypadki przyjmują założenie, że dana usługa pracuje jednocześnie na wszystkich węzłach klastra i w razie bezpośredniego połączenia jest w stanie w pełni obsługiwać klientów. Powyższe rozwiązania w żaden sposób nie wspierają samego uruchamiania usług na wielu serwerach. Stopień skomplikowania takiego procesu zależy ściśle od konkretnej usługi. W przypadkach aplikacji, które skalują się tylko w pionie zapewnienie

17 Budowanie tanich, wysoko wydajnych Rys 4 LVS-NAT + keepalived w konfiguracji active-passive redundancji może odbywać się wyłącznie w trybie active-passive. Trywialnym rozwiązaniem takiego problemu może być prosta konfiguracja oparta o VRRP i skrypty uruchamiane podczas przekazywania adresów IP. Możliwość monitorowania stanu takich usług jest bardzo ograniczona i rozwiązanie sprawdzi się tylko w niektórych, konkretnych przypadkach. Linux-HA Celem projektu Linux High Availability [4] jest implementacja zarządzenia klastrami usługowymi. Główne funkcjonalności pakietu to wzajemne monitorowanie stanu pracujących serwisów realizowane przez program Heartbeat. Od wersji 2.0 w skład projektu wszedł również bardzo zaawansowany CRM (Cluster Resource Manager), obecnie wydzielony jako oddzielny projekt funkcjonujący pod nazwą Peacemaker. CRM umożliwia zaawansowane zarządzanie zależnościami między aplikacjami wchodzącymi w skąd infrastruktury klastra. Lista obsługiwanych zasobów jest dość duża. W przypadku typowych aplikacji zarządzanie przez Heartbeat odbywa się za pomocą skryptów startowych aplikacji zgodnymi z System V.

18 18 Mariusz Drozdziel Rys 5 LVS-DR + keepalived w konfiguracji active-active Konfiguracja zasobów przez CRM pozwala na definiowanie złożonych zależności oraz kolejności, w jakiej mają być uruchamiane usługi. Dzięki temu bez skomplikowanych konfiguracji można uruchomić zaawansowane systemy klastrowe pracujące w trybie active-passive. Podczas awarii jednego z elementów systemu heartbeat będzie wiedział, które z aplikacji (również wśród pozornie działających) należy migrować na zapasową maszynę, aby przywrócić funkcjonalność usługi. Uruchamianie usług odbędzie się w predefiniowanej kolejności. W opisanym przypadku najpierw zostaną przeniesione adresy IP, następnie zamontowane zostaną współdzielone zasoby dyskowe, a dopiero potem podniesiona zostanie aplikacja. Wykonanie tych czynności innej kolejności zapewne doprowadziło by do całkowitego wyłączenia usług. Jednym z zasobów, które obsługuje heartbeat jest director LVS. Zestawienie heartbeat + ldirectord (demon pozwalający na monitorowanie zasobów LVS) jest alternatywną w stosunku do keepalived metodą zapewnienia wysokiej dostępności rozwiązań LVS. Jednym z istotnych elementów, które implementuje heartbeat jest STONITH (shoot the other node in the head) czyli forma fencingu węzłów klastra. W przypadku wykrycia awarii jednego z węzłów bardzo ważne jest, żeby pozbawić go dostępu do jakichkolwiek wspólnych zasobów. W razie awarii części infrastruktury, usługi lub pojedynczej aplikacji, węzeł nadal może wykonywać zmiany w bazach danych lub modyfikować dane na współdzielonych zasobach. Niekiedy węzły korzystają z zasobów, które nie umożliwiają obsługi więcej niż jednego klienta (zasoby dyskowe oparte

19 Budowanie tanich, wysoko wydajnych na standardowych systemach plików np. ext3). W takiej sytuacji odcięcie uszkodzonego węzła jest zadaniem kluczowym, ponieważ w przeciwnym razie dojdzie do uszkodzenia danych. Fencing polega na całkowitym odłączeniu węzła od jakichkolwiek zasobów. W przypadku awarii węzła, status dowolnego jego elementu jest nieokreślony. Programowane metody fencingu operujące na interakcji z wadliwym systemem są więc bardzo niepewne. Najpewniejsze efekty osiąga się poprzez zewnętrzne rozwiązania. W przypadku maszyn wirtualnych optymalnym rozwiązaniem jest wyłączenie systemu z poziomu supervisora. Serwery fizyczne można wyłączać korzystając z zewnętrznych interfejsów zarządzających typu ILO/DRAC (HP/DELL) lub przez odcięcie zasilania z poziomu UPS-a. Alternatywą jest fencing na poziomie samych zasobów, na przykład poprzez fizyczne odłączenie portów FC (Fibre Channel) danego serwera w switchu SAN. Synchronizacja zasobów dyskowych Jednym z głównych problemów podczas eliminowania pojedynczych punktów awarii jest duplikacja zasobów dyskowych. Niektóre aplikacje (jak na przykład bazy danych) posiadają własne mechanizmy pozwalające na replikację swoich danych na bliźniacze systemy. Dzięki temu budowa wysokiej dostępności jest ułatwiona. Wiele aplikacji korzysta bezpośrednio z danych składowanych na dyskach i w żaden sposób nie wspiera ich replikacji. Rozwiązaniem tego problemu jest wprowadzenie redundancji na poziomie blokowych urządzeń z których korzystają aplikacje. Alternatywą dla zewnętrznych i drogich macierzy dyskowych jest replikacja urządzenia blokowego przez sieć IP. DRBD (Distributed Replicated Block Device) [5] to rozwiązanie, które umożliwia mirrorowanie danych między dwoma serwerami w czasie rzeczywistym. W praktyce rozwiązanie tworzy RAID-1 między dyskami różnych maszyn połączonych siecią IP. Infrastruktura jest ukryta przed aplikacją, która korzysta ze standardowego urządzenia blokowego. Dostęp do takiego urządzenia odbywa się na dokładnie takiej samej zasadzie, jak standardowy dostęp bezpośrednio do fizycznego urządzenia. Warstwa pośrednia między aplikacją, a urządzeniem zajmuje się synchronizacją danych z zewnętrznym DRBD na innej maszynie. Należy przy tym pamiętać, że standardowe systemy plików wykorzystywane pod Linuksem (ext3, xfs, jfs, etc.) nie umożliwiają jednoczesnego dostępu do danych z różnych maszyn. Sam podsystem DRBD dba o to, aby zasób działający w trybie active-passive nie był dostępny dla dwóch maszyn jednocześnie. DRBD umożliwia również konfiguracje zasobów w trybie active-active. Wówczas oba węzły mogą modyfikować dane jednocześnie. W takiej sytuacji konieczne jest zastosowanie sieciowego systemu plików takiego jak GFS/GFS2 [6] lub OCFS/OCFS2 [7]. DRBD synchronizuje systemy plików na poziomie urządzeń blokowych. Aplikacje obsługujące sieciowe systemy plików komunikują się między sobą w celu zapewnienia integralności samych danych. Jeżeli wystąpi utrata komunikacji między systemami na warstwie sieciowej (split brain), ważne jest, aby poprawnie zadziałał fencing, który odłączy jeden z węzłów. W przypadku niezależnych zmian systemu plików na obu węzłach po utracie komunikacji konieczna będzie ręczna interwencja. W przypadku poważniejszych awarii może również dojść do uszkodzenia danych.

20 20 Mariusz Drozdziel Rys 6 Zarys architektury DRDB i przebieg zapisu danych Decyzja wyboru trybu pracy DRBD zależy od specyfiki klastrowanej usługi. Rozwiązanie active-passive wprowadza mechanizmy failover i wysoką dostępność, natomiast tryb active-active umożliwia load balancing usług. W wielu przypadkach nie jest konieczne synchronizowanie danych w trybie ciągłym. Jeżeli w danym rozwiązaniu sprawdzi się okresowa synchronizacja danych zamiast DRBD można wykorzystać dużo prostsze narzędzia typu rsync. To rozwiązanie doskonale sprawdza się do synchronizacji samych konfiguracji aplikacji. Nawet jeżeli elementy usług nie muszą współdzielić żadnych zasobów, warto wprowadzić okresową synchronizację samych ustawień. Zapewni to integralność konfiguracji i tym samym bardzo uprości zarządzanie. Podsumowanie Pod Linuksem dostępne jest wiele bardzo zaawansowanych i wydajnych rozwiązań wspierających wszelakiej maści klastrowanie usług. Najtrudniejszym elementem całego procesu budowania klastra jest zaplanowanie i opracowanie rozwiązania, które będzie adekwatne do konkretnej sytuacji. Aby móc to osiągnąć, trzeba bardzo dobrze poznać dostępne mechanizmy kastrowania i przeanalizować wszystkie aspekty danego rozwiązania pod kątem konkretnych usług.

21 Budowanie tanich, wysoko wydajnych Rys 7 Prosty klaster Apache + MySQL ze zrównoważonym obciążeniem Samo przenoszenie starych usług na klastry niekoniecznie musi się wiązać się z wprowadzeniem nowych fizycznych serwerów. Czasami okazuje się, że utylizacja obecnie posiadanych rozwiązań jest bardzo niska. W takiej sytuacji dobry pomysł i odpowiednie zaplanowanie klastra może zaoszczędzić sporych wydatków. Najefektywniejszym sposobem wprowadzenia do systemu nadmiarowości może być wzajemne kastrowanie usług w obrębie grupy serwerów. W klasycznym przykładzie Apache+MySQL pracujących na odrębnych maszynach można w prosty sposób wprowadzić redundancję. Wystarczy skonfigurować serwer MySQL jako zapasowy serwer dla Apache, a serwer Apache jako backup dla MySQL. W ten sposób awaria którejkolwiek z maszyn nie spowoduje utraty usługi. Faktyczna utylizacja maszyn (w trakcie normalnej pracy) nie ulegnie zmiany. Oczywiście dobrych sposobów implementacji takiego rozwiązania jest bardzo wiele. Na funkcjonowanie konkretnej usługi często składa się bardzo wiele aplikacji rozmieszczonych na różnych fizycznych serwerach. Projektując klaster należy przede wszystkim zlokalizować wąskie gardła (bottle necks), czyli te elementy, które zużywają najwięcej zasobów. Przy projektowaniu rozwiązania opartego o load balancing, najwięcej faktycznych zasobów należy przeznaczyć właśnie na te elementy usługi. Bardzo rzadko zdarza się, że wymagania usług wzrastają na każdym poziomie w takim samym tempie. Podobnie podczas wdrażania rozwiązań high-availablity należy zwrócić uwagę, czy w systemie nie pozostaną pojedyncze punkty awarii. Nawet jeżeli nie ma realnej możliwości wprowadzenia redundancji każdego elementu nadal warto duplikować tam, gdzie jest to możliwe. Niepełna redundancja i występujące SPOF (single point of failure) będą nadal rozwiązaniem lepszym niż brak jakiejkolwiek redundancji. Wprowadzanie rozwiązań zapewniających wysoką dostępność ma chronić nie tylko przed niespodziewanymi awariami. Często opłaca się wykorzystywać nawet najprostsze rozwiązania. Być może nie gwarantują one zabezpieczenia przed wszystkimi zdarzeniami, ale przynajmniej pozwalają na ręczne przełączanie węzłów i bezstresowe prowadzenie prac serwisowych.

22 22 Mariusz Drozdziel Literatura 1. Oficjalna specyfikacja protokołu VRRP - RFC2338: 2. Strona projektu Linux Virtual Server: 3. Strona projektu keepalived: 4. Informacje na temat projektu High Availability Linux: 5. Strona projektu DRBD: 6. Informacje na temat systemu plików GFS2: 7. System plików OCFS2:

23 P.I.W.O.3 Arkadiusz Zieliński Michał Wysocki Wojciech Sleńska Streszczenie: Reprezentujemy Studenckie Koło Naukowe MOS (Microsystems Oriented Society), działające przy Katedrze Metrologii Elektronicznej i Fotonicznej na Wydziale Elektroniki Politechniki Wrocławskiej. Projekt P.I.W.O to stworzony przez nas nietypowy system oświetlenia budynku. Projekt PIWO liczy sobie już trzy lata. Historia ta rozpoczęła się jednak jeszcze rok wcześniej. W 2006 roku, pewnego czerwcowego wieczoru kolega Filip Rus, ówczesny student specjalności Aparatura Elektroniczna na wydziale Elektroniki, wracając z zajęć, mijał osiedle studenckie na Wittigowie. Ponieważ słońce chyliło się już ku zachodowi, w części pokoi w akademikach było włączone światło. W sumie to nic nadzwyczajnego podobne obrazki mijamy bezrefleksyjnie każdego dnia. Potrzebny jest nieszablonowy umysł, by w przypadkowym układzie okien zobaczyć coś więcej. A gdyby tak móc panować nad światłem?. To był pomysł jeden z wielu, jakie zazwyczaj kotłowały się w jego głowie, ten jednak nie dał o sobie zapomnieć. Pierwsza edycja Rok później, w maju rozeszła się wśród studentów wieść, że coś ma się dziać na tekach. Po praz pierwszy pojawiała się nazwa P.I.W.O. Skrót ten, mający na celu prowokować uwagę statystycznego studenta, w rzeczywistości oznacza Potężny Indeksowany Wyświetlacz Oknowy. Potężny, ponieważ akademik T17, w który był instalowany projekt, ma całkiem spore gabaryty. Indeksowany, oznacza możliwość adresowania poszczególnych okien, w celu wyświetlania ruchomych obrazów. Wyświetlacz to oczywiste - celem projektu jest zamiana budynku w duży ekran. Oknowy, ponieważ piksel, czyli najmniejszy świecący punkt w naszym Potężnym Wyświetlaczu, to całe okno. Projekt rodził się w bólach, przede wszystkim z powodów finansowych. Kto przy zdrowych zmysłach zaufa zwykłemu studentowi i da pieniądze na tak dziwny pomysł, jak

24 24 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 1 SKN MOS ludzie odpowiedzialni za projekt P.I.W.O.3 Rys 2 Osiedle akademickie na Wittiga zamiana budynku w wyświetlacz? Filip Rus miał jednak odwagę powalczyć o swoje marzenie.

25 P.I.W.O.3 25 Pierwszy pokaz projektu, pomimo znikomej reklamy, zgromadził całkiem sporą publiczność. Studenci czekali z niecierpliwością zapowiadana godzina rozpoczęcia pokazu dawno już wybiła, a na akademiku wciąż nic się nie działo. Po godzinie, autor projektu musiał oznajmić publiczności, że z powodu problemów technicznych pokaz zostaje odwołany. Cóż za zawód dla zgromadzonej publiczności! Kolejna próba odbyła się tydzień później. Tym razem pokaz odbył się zgodnie z planem. Pewnych problemów nie udało się jednak przeskoczyć komputer sterował oświetleniem sufitowym, jakie znajduje się w pokojach. W każdym z nich były jednak wkręcone inne żarówki, co powodowało znaczne różnice w jasności pomiędzy poszczególnymi pikselami. Druga edycja Rozpoczyna się rok akademicki 2007/08. Prezesurę w kole SKN MOS obejmuje Marcin Saj, również student Aparatury Elektronicznej. Ma sporo pomysłów na rozwój koła naukowego. Rozpoczyna się zakrojona na szeroką skalę rekrutacja wśród III roku. Koło pozyskuje wielu nowych ludzi i w sumie liczy około trzydziestu członków. Jego flagowym zadaniem staje się reaktywacja projektu P.I.W.O. Toczy się gorąca dyskusja na temat jego kształtu. W okolicach lutego krystalizuje się plan i przystępujemy do realizacji. Bazując na doświadczeniach z minionego roku, budujemy własne moduły oświetleniowe, które zapewnią jednakową jasność wszystkich okien. Moduł ma postać małego plastikowego pudełka z dwiema żarówkami. W środku znajduje się jedynie element wykonawczy w postaci triaka. Wszystkie moduły z danego piętra zostają podłączone do sterownika mikroprocesorowego (jeden na piętro), te zaś wpięte w jedną sieć, podłączoną do komputera. W tym celu musimy położyć w akademiku własną sieć w sumie wykorzystujemy aż 2 km kabla telefonicznego! Pokaz projektu został zaplanowany na 13 maja 2008 roku. Tego dnia, nasze centrum dowodzenia zostało ulokowane na wzniesieniu przed akademikiem. Stąd, za pomocą laptopa, mogliśmy sterować oświetleniem całego budynku. Trudno oszacować liczbę ludzi przybyłych na pokaz, ale był to spory tłum. Szczerze zaskoczyło nas tak duże zainteresowanie, zwłaszcza ze względu na skromną promocję. Jest godzina 21:02 - boisko do koszykówki w całości zapełniło się już publicznością żądną wrażeń. Pokaz miał się rozpocząć punktualnie o godzinie dziewiątej, ale pojawiły się niespodziewane problemy techniczne. W naszej ekipie poziom zdenerwowania rośnie. W końcu jednak udaje się zapanować nad złośliwą materią z głośników rozlega się sygnał syreny, a na akademiku wyświetlają się pierwsze sekwencje animacji. Publika reaguje żywo. Z naszego stanowiska na górce widzimy morze telefonów komórkowych wszystkie wycelowane w akademik.

26 26 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys modułów oświetleniowych projektu P.I.WO.2 Trzecia edycja Na początku roku akademickiego 2008/09 odbyły się wybory nowych władz koła. W otwartym głosowaniu wybrano Arka Zielińskiego, Michała Wysockiego oraz Wojtka Sleńska. To ludzie, którzy nie widzą świata poza elektroniką. Tym razem nie było już wątpliwości wszyscy oczekiwali trzeciej edycji projektu! Studenci, ponieważ to doskonała rozrywka. Władze, bo to świetna okazja do promocji uczelni. Każda kolejna odsłona projektu przynosi nowe rozwiązania techniczne (dla widzów jest to bez znaczenia dla nas, przyszłych inżynierów, jest to kwestia kluczowa i powód do dumy). Przyjrzyjmy się zatem poszczególnym aspektom. Żarówki Jednym z większych problemów przy projekcie Potężnego Wyświetlacza był dobór odpowiednich źródeł światła. W pierwszej edycji wykorzystaliśmy żyrandole znajdujące się w każdym pokoju wyświetlacz był jednokolorowy. W drugiej edycji użyliśmy własnych modułów oświetleniowych oraz zwykłych żarówek 100W, z czego połowa była pomalowana przez nas na czerwono farbą do szkła w sprayu. Taka farba nie była przystosowana do wysokich temperatur. Eksperymenty praktyczne wykazały jednak, że choć pomalowane żarówki trochę dymią, to bez problemu wytrzymują godzinny pokaz. Ktoś mógłby spytać, dlaczego nie zastosowaliśmy fabrycznych żarówek? Okazuje się, że na rynku nie ma kolorowych żarówek

27 P.I.W.O.3 27 Rys 4 Malowanie żarówek w czasie drugiej edycji projektu. o większej mocy (jest parę wyjątków, ale ich ceny są bardzo wysokie). Z drugiej strony, pomalowanie 120 żarówek (po jednej na pokój) we własnym zakresie nie stanowi aż takiego wyzwania. Przygotowując się do trzeciej edycji, zastanawialiśmy się, czym można by zastąpić żarówki. Diody LED wydają się najlepszym rozwiązaniem, ale ich cena jest dla nas zaporowa. Braliśmy także pod uwagę świetlówki. Przy sterowaniu za pomocą zimnego zapłonu świetlówki mogłyby pracować przy częstotliwości ok 10Hz (mniejsza częstotliwość pracy powodowałaby duże smużenia np. podczas przewijania tekstu na budynku). Metoda ta wymagałby jednak gruntownych eksperymentów, a na to nie mieliśmy już czasu. W ten sposób wróciliśmy do leciwych żarówek. Postanowiliśmy przynajmniej wyeliminować problemy, jakie objawiły się podczas drugiej edycji. Pierwszym problemem było smużenie przy szybkich animacjach. Żarówka po podłączeniu napięcia nie rozbłyska natychmiast pełnią mocy zimne włókno żarówki potrzebuje trochę czasu, by się rozgrzać. Podobnie przy odłączeniu napięcia włoko chwilę stygnie. Przeprowadziliśmy eksperyment, który miał na celu pomiar czasów zapalania i wygaszania typowych żarówek o różnych mocach. Układ pomiarowy składał się z fotorezystora w układzie dzielnika napięciowego, oddalonego o 10cm od żarówki. Przebieg zmian natężenia światła rejestrowany był cyfrowym oscyloskopem. Punkt wyzwolenia pochodził z zakłócenia wywołanego zwarciem lub rozwarciem przełącznika sieciowego żarówki. Testy wykazały, że żarówki posiadają podobne czasy zapalania,

28 28 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 5 Porównanie czasu zapalenia i wygaszenia żarówek o dwóch różnych mocach jednak żarówka o mocy 100W ma dwa razy dłuższy czas gaśnięcia, w stosunku do żarówki 60W. To nas skłoniło do zastosowania dwóch żarówek 60W na kanał (jeden kolor). Co więcej: myśląc nad tym, czym zaskoczyć widzów przy trzeciej edycji, uznaliśmy, że potrzebujemy większej liczby kolorów najlepiej czterech. Jak łatwo policzyć: 120 pikseli 4 kolory 2 żarówki na kolor = 960 żarówek. To już spory wydatek. Choć projekt był w całości finansowany przez Politechnikę Wrocławską, chcieliśmy jej trochę ulżyć. Zwróciliśmy się więc z prośbą o sponsoring do firmy Philips Lighting Poland, będącej czołowym producentem oświetlenia w Polsce. Ta duża i poważna firma zainteresowała się naszym studenckim projektem, dostarczając nam 1050 sztuk żarówek o mocy 60W (by na wypadek awarii mieć pewien zapas). Mieliśmy już żarówki w dużej ilości tylko jak je teraz pomalować? Byliśmy zdeterminowani, by opracować jakąś nową technikę taką, która byłaby szybsza i dawała lepsze rezultaty. Poszukiwania doprowadziły nas do chemika, który zajmuje się m. in. produkcją farb do malowania zniczy. Zaoferował on farbę na bazie bezbarwnej bazy silikonowej, dedykowanej dla temperatur do 600 C, zmieszanej z odpowiednim barwnikiem. Wypadkowo miało to dać dopuszczalną temperaturę pracy na poziomie 160 C (do tylu stopni rozgrzewa się żarówka). Niedługo po tym otrzymaliśmy cztery puszki z farbą w kolorze czerwonym, niebieskim, zielonym i żółtym. Przystąpiliśmy

29 P.I.W.O.3 29 Rys 6 Żarówki zostały ufundowane przez firmę Philips Lighting Poland do opracowania techniki malowania. Okazało się, ze świetne rezultaty daje malowanie przez zamoczenie. Żarówka jest zamaczana w farbie i wyciągana. Następnie podłączana jest do prądu na 3 minuty wysoka temperatura powoduje szybkie schnięcie farby. Po następnych trzech minutach można ją zapakować z powrotem do kartonika. Aby przyśpieszyć proces, zbudowaliśmy proste urządzenie, składające się z deski, czterech oprawek na żarówki oraz timera na małym AVR-ku (8-bitowym mikrokontrolerze firmy Atmel), który włącza żarówki na określony czas, a następnie sygnalizuje zakończenie procesu malowania poprzez miganie diodą. Moduł oświetleniowy Z uwagi na cztery kolory, zdecydowaliśmy, że każdy moduł oświetleniowy będzie posiadał własną logikę sterującą. Każdy z modułów został więc wyposażony w mikrokontroler odpowiedzialny na sterowanie żarówkami oraz komunikację w sieci. Część układu zasilana napięciem 230V jest izolowana optycznie, co zapewnia bezpieczeństwo i niweluje ryzyko przebicia do sieci sterującej. Poprawność pracy oraz obecność w sieci może zostać zdalnie sprawdzona poprzez specjalną komendę ping, co znacznie ułatwia testowanie sieci.

30 30 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 7 Po lewej stronie żarówka z drugiej edycji projektu (malowana spray-em), obok żarówka malowana nową techniką Wbrew pozorom nie Ethernet Mimo zastosowania widocznych na zdjęciach gniazd RJ45, moduły oświetleniowe wykorzystują komunikację w przemysłowym standardzie RS485 FullDuplex. Gotowe przewody sieciowe typu patchcord (skrętka) ze względu na szeroką dostępność i niską cenę są idealnym medium transmisyjnym, a standard RS485 zapewnia niski koszt wytworzenia modułów. Zastosowanie Ethernetu podniosłoby koszt w sposób nieadekwatny do uzyskanych korzyści. Standard RS485 jest popularnym sposobem przesyłania danych, wykorzystywanym głównie przy długich liniach transmisyjnych (5 1000m). Dzięki różnicowemu przesyłaniu sygnałów łącze zapewnia dobrą odporność na zakłócenie zewnętrzne i prędkości transmisji do 1 2Mbps.

31 P.I.W.O.3 31 Rys 8 W trakcie malowania żarówek P.I.W.O.3 Struktura sieci sterującej Sieci w standardzie RS485 wymagają topologii magistrali zakończonej terminatorami. Ponieważ sieć, która powstała w budynku, ma charakter dwuwymiarowy, a maksymalna ilość urządzeń w jednej gałęzi wynosi tylko 32, konieczne było stworzenie koncentratorów. Każdy z nich posiada jeden port wejściowy oraz pięć wyjściowych. Huby nie wpływają na treść przesyłanych informacji regenerują jedynie sygnał i rozsyłają otrzymane pakiety na wszystkie porty wyjściowe. Sieć posiada jednego zarządcę komputer PC. Rys 9 Hub z podpiętym Żadne urządzenie poza nim nie ma prapatchcord-em i dwoma wa rozpocząć nadawania, chyba że odterminatorami powiada na pytanie zarządcy. Sieć jest w pełni skalowalna, a huby mogą zostać wpięte w praktycznie dowolnym miejscu, także między modułami oświetleniowymi.

32 32 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 10 Moduł oświetleniowy projektu P.I.W.O.3 Rys 11 Porównanie wpływu przypadkowych zakłóceń dla dwóch interfejsów szeregowych Programator modułów oświetleniowych

33 P.I.W.O.3 33 Rys 12 Schemat blokowy modułu Rys 13 Schemat blokowy sieci projektu P.I.W.O.3 Każdy ze 120 modułów oświetleniowych posiada mikrokontroler, w związku z czym potrzebne jest narzędzie do szybkiego i wygodnego programowania. Co prawda do pro-

34 34 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 14 Programator modułów oświetleniowych gramowania pamięci flash można wykorzystać laptopa, jednak w takim przypadku kłopot stanowi programowanie pamięci EEPROM, w której zapisany jest indywidualny adres każdego modułu. Kłopot polega na tym, że adres jest przydzielany i wgrywany dopiero w trakcie instalacji modułu w danym pokoju. Dlatego zaprojektowaliśmy i zbudowaliśmy kilka sztuk mobilnych programatorów. Posiadają one wyświetlacz LCD 4x16, klawiaturę numeryczną oraz dwa gniazda RJ25. Jedno z nich służy do podłączenia modułu oświetleniowego. Umożliwia ono zaprogramowanie modułu oraz uruchomienie programu diagnostycznego. Montaż Projekt P.I.W.O.3 to duże wyzwanie przede wszystkim pod względem logistycznym. W najbardziej gorącym okresie, odbieraliśmy dziennie po dwie, trzy paczki kurierskie z podzespołami elektronicznymi i częściami mechanicznymi. Do właściwego montażu modułów oświetleniowych przystąpiliśmy w majowy weekend. Było to kilka dni intensywnej pracy od rana do wieczora. Na prace produkcyjne składało się m. in.: wywiercenie otworów pod żarówki za pomocą otwornicy, wywiercenie otworów montażowych do przykręcenia oprawek i elektroniki,

35 P.I.W.O.3 35 Rys 15 Programator jest zasilany wprost z modułu oświetleniowego lutowanie płytek z elektroniką, skręcenie wszystkich elementów w całość, przetestowanie gotowego modułu. 8 maja nasza ekipa wyruszyła do akademika w celu położenia sieci piwnej (dużo prostszej, niż rok temu).w kolejnych dniach instalowaliśmy moduły oświetleniowe w pokojach. Sieć została w pełni uruchomiona (łącznie z eliminacją uszkodzonych pikseli) dopiero w dniu pokazu, czyli 12 maja. Mimo braku czasu, atmosfera wśród nas była spokojna. Znaliśmy się już wystarczająco dobrze, by móc na sobie polegać. Pokaz Tradycyjnie w dniu pokazu rozłożyliśmy się na wzniesieniu przed akademikiem T16. W okolicy przybywało grillów, a my z mozołem usuwaliśmy ostatnie usterki techniczne. Imprezę w naszym imieniu poprowadził Tomek Tyczyński z Akademickiego Radia LUZ. Znakomicie spisał się w tej roli. Nam bardziej do twarzy było z lutownicą, niż z mikrofonem. Transmisję na żywo, poprzez internet zapewniała Telewizja Studencka STYK. Przed rozpoczęciem właściwego pokazu, na ścianie sąsiedniego akademika została wyświetlona krótka, acz dynamiczna, filmowa zapowiedź projektu P.I.W.O.3,

36 36 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 16 W czasie montażu morale w drużynie było wysokie wyprodukowana przez Akademicki Klub Realizatorów Filmowych FOSA przy współpracy ze stowarzyszeniem Parkour Wrocław. Intro otwierające pokaz rozpoczęło się o godzinie Świetlne przedstawienie trwało ok 50 minut i składało się z 55 animacji, w większości nadesłanych na konkurs i wyselekcjonowanych przez naszego wirtuoza małych rozdzielczości, Krzyśka Birowskiego. Słów kilka na zakończenie Projekt P.I.W.O.3 udowodnił, że grupa zdeterminowanych ludzi może naprawdę wiele. Pokazaliśmy, że w polskich studentach drzemie spory potencjał i na tym polu nie mamy się czego wstydzić. Kolejnym bardzo pozytywnym aspektem jest fakt, że jeden projekt potrafił zjednoczyć wiele organizacji studenckich, które z powodzeniem współpracowały ze sobą. Projekt to także niezła gratka dla zwolenników mikrokontrolerów AVR: 120 sztuk pracujących jednocześnie w imię wspaniałej świetlnej idei. Co będzie dalej? Jeszcze jest za wcześnie, by o tym mówić. Zobaczymy, co przyniesie przyszłość.

37 P.I.W.O.3 37 Rys 17 Produkcja modułów oświetleniowych wymagała cięższego sprzętu Linki 1. Strona projektu: 2. Strona SKN MOS:

38 38 Arkadiusz Zieliński, Michał Wysocki, Wojciech Sleńska Rys 18 Tuż przed pokazem - ostatnie przygotowania

39 P.I.W.O.3 39 Rys 19 Gwiazdą specjalną na pokazie był sam Król Popu Michael Jackson!

40 Mazakiem po WWW czyli kilka słów o obiekcie «canvas» Robert BoBsoN Partyka Streszczenie: Rozwój informatyki to ciągły bieg za nowymi technologiami. Tendencja ta nie omija także globalnej pajęczyny stron WWW. Czasy, gdy serwisy internetowe składały się tylko z tekstu i hiperłączy minęły bezpowrotnie. Standardy, które wytyczają drogę rozbudowy przeglądarek, rozszerzane są o kolejne pomysły organizacji takich jak W3C, WHATWG oraz firm takich jak Nokia, Google czy Microsoft. Najnowsze wydania Firefox i Opery wprowadziły natywną obsługę strumieni video i dźwięku. W najbliższym czasie spodziewać się należy kolejnego przełomu w postrzeganiu narzędzia jakim jest WWW. Przyjrzyjmy się jednemu z elementów HTML5, które mogą przyczynić się do tego przełomu. Czym właściwie jest <canvas>? Z obiektami o działaniu podobnym do <canvas> spotkał się każdy, kto próbował swych sił w programowaniu w C/C++ czy Pascal (Delphi). Jest to nic innego jak płótno na ekranie, na której możemy narysować dowolną grafikę. Nic nadzwyczajnego, ale gdy dodamy do tego szereg wbudowanych funkcjonalności, otrzymujemy elastyczne i przydatne narzędzie, dzięki któremu możemy zmienić odbiór naszych stron WWW. <canvas> po raz pierwszy został wprowadzony przez firmę Apple dla Mac OS X Dashboard a następnie zaimplementowany w Safari. Implementacja tego obiektu została wykonana także w silniku Gecko, począwszy od wersji 1.8 oraz w przeglądarce Opera w związku z zawarciem tego obiektu w specyfikacji WHATWG Web application 1.0 znanej jako HTML5. Nie jest zaskakującym fakt, że firma Microsoft nie implementowała tego obiektu <canvas> w IE zawdzięczamy Google.

41 Mazakiem po WWW czyli kilka słów o obiekcie «canvas» 41 Podstawy Tak, jak każdą zabawę z elementami HTML i tutaj zaczynamy od wstawienia obiektu w kod strony WWW. Przykładowo: <canvas id="mycanvas" width="400" height="300"> </canvas> wstawi obiekt o wymiarach 400 na 300 pikseli. Zaleca się stosowanie zamykającego tagu </canvas> ze względu na nieprawidłowe interpretowanie <canvas.../> przez niektóre przeglądarki. Tego typu konstrukcja pozwala także na zastosowanie kodu, który zostanie wyświetlony w przeglądarkach nie wspierających tego obiektu: <canvas id="mycanvas" width="400" height="300"> Twoja przeglądarka nie wspiera obiektu Canvas. </canvas> W efekcie interpretacji przez przeglądarkę takiego kodu naszym oczom ukaże się zachęcająca do dalszej pracy pustka. Mając już obiekt <canvas> w drzewie DOM strony, przystępujemy do manipulacji na tym obiekcie. W tym celu wykorzystujemy JavaScript. <canvas> obsługuje zdarzenia HTML, dzięki czemu możliwe jest oprogramowanie interakcji z użytkownikiem. Do rysowania obrazu wykorzystywane są konteksty rysowania. Może być ich więcej niż jeden, dzięki czemu zyskujemy dodatkowe możliwości, takie jak dostęp do OpenGL ES z poziomu JavaScript (o czym za chwilę). Podstawowym kontekstem jest 2d. var canvas = document.getelementbyid( MyCanvas ); var ctx = canvas.getcontext( 2d ); Po pobraniu kontekstu możemy przystąpić do rysowania na stworzonym przez nas płótnie, wykorzystując dostarczane przez obiekt metody. canvas obsługuje jedynie prostokąt jako wbudowany kształt. fillrect(x,y,szerokość,wysokość) rysuje wypełniony prostokąt, strokerect(x,y,width,height) rysuje obrys prostokąta, a clearrect(x,y,width,height) czyści dany obszar, czyniąc go całkowicie przeźroczystym Każda inna figura musi być zbudowana ze ścieżek. Tych na szczęście jest kilka rodzajów. Rysowanie figur przy użyciu ścieżek jest trochę bardziej skomplikowane wymaga wykorzystania więcej niż jednej metody. Dodatkowo ważnym elementem staje się kontrola nad położeniem pędzla. Ścieżkę rozpoczynamy od wydania beginpath(). Kolejne metody przesuwają i rysują pędzlem. Ostatnia zamyka ścieżkę i aktywuje jej wykonanie. Jest to albo:

42 42 Robert BoBsoN Partyka fill() dla figur wypełnionych lub stroke() dla obrysów figur. Opcjonalna metoda closepath() służy do narysowania linii prostej z bieżącej pozycji pędzla do punktu początkowego ścieżki. Pierwszą metodą wywoływaną po beginpatch() w większości przypadków będzie moveto(x,y). Służy ona do przeniesienia pędzla bez pozostawiania śladu na płótnie w wybraną pozycję. W celu rysowania śladu ścieżki otrzymujemy całkiem pokaźny zestaw metod: lineto(x, y) rysuje linię prostą z aktualnej pozycji do podanej, arc(x, y, r, początkowykąt, końcowykąt, przeciwniedozegara) rysuje okrąg lub fragment okręgu od początkowego do końcowego końca, zgodnie lub przeciwnie do ruchu wskazówek zegara o promieniu r i środku w punkcie x,y. quadraticcurveto(cp1x, cp1y, x, y) oraz beziercurveto(cp1x, cp1y, cp2x, cp2y, x, y) służy do rysowania krzywych, oraz: rect(x,y, szerokość, wysokość) dodająca obrys prostokąta do aktualnej ścieżki. Pamiętać należy, że pozycją pędzla po wykonaniu którejkolwiek z tych metod, będzie pozycja ostatniego piksla zaplanowanego do narysowania. Wiemy już, jak poruszać pędzlem. Kolejny krok to dobór farb. Do dyspozycji mamy dwie własności obiektu kontekstu: fillstyle określa kolor wypełnienia, zaś: strokestyle określa kolor obrysu. Kolory te zapisane mogą być w jednym z czterech formatów: 1. słowna nazwa zgodna z nazewnictwem kolorów w CSS, 2. zapis #RRGGBB, 3. zapis z wykorzystaniem funkcji rgb(r,g,b) lub funkcji rgba(r,g,b,a) przykładowo: ctx.fillstyle = "orange"; ctx.fillstyle = "#FFA500"; ctx.fillstyle = "rgb(255,165,0)"; ctx.fillstyle = "rgba(255,165,0,1)"; Innymi słowy, jest to zapis zgodny ze specyfikacją zapisów kolorów w standardzie CSS3. Przeźroczystość (lub jak kto woli siłę nacisku) pędzla możemy określić przy pomocy globalnej własności globalalpha. Przyjmuje ona wartości zmiennoprzecinkowe z przedziału 0 do 1.

43 Mazakiem po WWW czyli kilka słów o obiekcie «canvas» 43 Sposób rysowania pędzla po płótnie określają kolejne cztery własności: linewidth określająca szerokość linii rysowanej przez pędzel, linecap określająca sposób rozpoczęcia i zakończenia rysowanej linii (możliwe wartości to: butt, round i square), linejoin określa sposób, w jaki będą łączone kolejne elementy ścieżki rysowanej przez pędzel (możliwe wartości to: round, bevel i miter), oraz miterlimit określająca, jak daleko mogą znajdować się od siebie punkty połączenia rysowanych linii (dotyczy linii szerszych niż 1px). Nie samymi kreskami i krzywymi jednak obraz żyje. Czasami przydatne jest wykorzystanie grafiki stworzonej np. w GiMP-ie. Jest to możliwe dzięki obiektowi Image() i metodzie drawimage(). Pierwszym krokiem jest załadowanie obrazka z pliku: var img = new Image(); img.src = jesien2009.png ; lub przez zakodowany tekst: img.src = data:image/gif;base64,r0lgo... trochę base64... Ow== ; Do umieszczenia załadowanego obrazka na obszarze płótna obiektu <canvas> używamy metody drawimage(). Występuje ona w trzech wersjach: drawimage(img, x, y) kopiuje obrazek w obszar o początkowej pozycji x,y na obiekcie <canvas>, drawimage(image, x, y, szerokość, wysokość) kopiuje obrazek w obszar o początkowej pozycji x,y z równoczesnym przeskalowaniem do nowych wymiarów, oraz drawimage(image, sx, sy, sszerokość, swysokość, dx, dy, dszerokość, dwysokość) kopiuje fragment obrazka od pozycji sx,sy i wymiarach zdanych w dwóch kolejnych parametrach na pozycję dx,dy w obszarze płótna obiektu canvas z równoczesnym przeskalowaniem do nowych wymiarów podanych w kolejnych dwóch parametrach. Oprócz prostego przerysowywania obrazka na płaszczyznę <canvas>, istnieje możliwość użycia go jako wzoru dla wypełnienia. Umożliwia to metoda createpattern(), która przyjmuje dwa parametry: obiekt obrazka jako pierwszy i określenie sposobu powtarzania wzorca (repeat, repeat-x, repeat-y, no-repeat). W chili obecnej wspierane jest tylko repeat. var img = new Image(); img.src = fajne_wypelnienie.png ; img.onload = function(){

44 44 Robert BoBsoN Partyka } var ptrn = ctx.createpattern(img, repeat ); ctx.fillstyle = ptrn; ctx.fillrect(0,0,150,150); Tryb kopiowania obrazu lub rysowania po nim na zasadzie dokładnego przykrywania nowym wzorcem, nie zawsze jest tym, czego potrzebujemy. Kolejny raz z pomocą przychodzą własności obiektu kontekstu. globalcompositeoperation pozwala określić, w jaki sposób łączone ze sobą będą źródło i elementy istniejące już na płótnie. Wtym miejscu otwiera się bogactwo możliwości wyboru: source-over domyślny tryb, w którym źródło przykrywa dokładnie piksle miejsca przeznaczenia; destination-over tryb, w którym nowe elementy umieszczane są poniżej istniejącego obrazu widoczne tylko w miejscach przeźroczystości aktualnego obrazu; source-in oraz destination-in tryb części wspólnej; na płaszczyźnie umieszczony zostanie obszar wspólny pochodzący z źródła lub płótna zależnie od wybranego trybu; source-out oraz destination-out tryby wycięcia, na płaszczyźnie umieszczona zostanie albo część źródła nie pokrywająca elementów w miejscu przeznaczenia, albo część elementów na płaszczyźnie nie przykryta przez element źródła (część wspólna zostanie zamieniona na przeźroczystość); source-atop oraz destination-atop tryby wycięcia z równoczesnym połączeniem części wspólnych. W pierwszym przypadku tylko fragment źródła pokrywający się z elementami w miejscu przeznaczenia będzie pozostawiony i narysowany, w drugim przypadku pozostawiona zostanie tylko część elementów z miejsca przeznaczenia, która pokrywa się z źródłem (źródło umieszczane jest pod spodem ); lighter w części wspólnej nastąpi zsumowanie kolorów źródła i elementów w miejscu przeznaczenia; darker w części wspólnej nastąpi odjęcie wartości koloru źródła od koloru przeznaczenia; xor część wspólna źródła i elementów w miejscu przeznaczenia zostanie usunięta; copy tylko źródło zostanie narysowane, wszystkie inne elementy z zadanego obszaru zostaną usunięte. Oprócz trybów rysowania, istnieje możliwość zdefiniowania ścieżki przycięcia obrazu na płaszczyźnie płótna. Oznacza to, że wszystko, co znajduje się poza obszarem wyznaczonym przez ścieżkę, zostanie usunięte. Ścieżkę taką deklarujemy w identyczny

45 Mazakiem po WWW czyli kilka słów o obiekcie «canvas» 45 sposób, jak ścieżkę elementu rysowanego na powierzchni obiektu canvas zmienia się jedynie metoda zamykająca: ctx.beginpath(); ctx.arc(0,0,60,0,math.pi*2,true); ctx.clip(); Transformacje Możliwości obiektu <canvas> nie kończą się na rysowaniu ścieżek, czy też kopiowaniu obrazków. Kolejny zestaw metod dodaje obsługę transformacji. O ile opisywane wcześniej metody odnosiły się do sterowania pędzlem, nakładania obrazków ogólnie rysowania po płótnie transformacje odnoszą się do samej powierzchni tworzonego obrazu. Nie należy mylić tego z manipulacją istniejącym obrazem. Transformacje zmieniają tylko układ siatki punktów poprzez przemieszczenie jej punktu zerowego, obrót, zmianę skalowania bez uszczerbku dla już istniejących fragmentów obrazu. Skomplikowane? Spójrzmy na przykład: Na płaszczyźnie umieśćmy kwadrat o boku 20px w pozycji (10,10). ctx.strokerect(10,10,20,20); Następnie narzućmy translację: ctx.translate(100, 100); Komenda ta przenosi punkt zerowy siatki odniesienia w nowe koordynaty. Jak widzimy już narysowany prostokąt pozostał nietknięty. Narysujmy go jeszcze raz dla pewności. ctx.strokerect(10,10,20,20); Prostokąt pojawił się... w nowym miejscu. Tak właśnie działają transformacje. Sposób widzenia płaszczyzny bez uszczerbku dla już narysowanych elementów. Sprawdźmy kolejne metody. ctx.scale(0.5, 0.5); ctx.strokerect(10,10,20,20); Odpowiada za przeskalowanie płaszczyzny. Parametry odpowiednio dla osi X i Y przyjmują wartości zmiennoprzecinkowe równe lub większe niż zero. Wartości z przedziału 0 do 1 oznaczają zgniatanie obrazu, większe od jedynki jego rozciąganie. Jak widzimy narysowany prostokąt jest połowę mniejszy, a dodatkowym efektem jest zmiana jego pozycji. To dlatego, że przeskalowaliśmy siatkę punktów odniesienia obiektu a nie sposób rysowania obiektu. Kolejna metoda pozwoli na obrócenie siatki o zadany w radianach kąt zgodnie z ruchem wskazówek zegara.

46 46 Robert BoBsoN Partyka ctx.rotate(math.pi*0.25); ctx.strokerect(10,10,20,20); Istnieje jeszcze dwie metody, które pozwalają na manipulację bezpośrednio na macierzy przekształceń. transform(m 11, m 12, m 21, m 22, dx, dy) mnożąca aktualną macierz przekształceń przez macierz: m 11 m 21 dx m 12 m 22 dy 0 oraz 0 1 settransform(m 11, m 12, m 21, m 22, dx, dy) która ustawia nowe wartości macierzy przekształceń na: m 11 m 21 dx m 12 m 22 dy Gdzie można wykorzystać transformacje? Głównie przy rysowaniu skomplikowanych elementów, takich jak np. hipotrochoida czy epicykloida. Dodawanie wyliczeń transformacji do funkcji rysującej taki element zwiększałoby jej złożoność i drastycznie zmniejszało czytelność kodu. Dzięki transformacjom siatki odniesienia obiektu <canvas> możemy tego uniknąć. Narzucanie kolejnych transformacji wiąże się z ryzykiem utraty panowania nad aktualnym stanem siatki odniesienia. Dodatkowym czynnikiem chaosu jest zmiana barw, sposobu łączenia elementów, wartości opisujących pędzel. W złożonym programie łatwo doprowadzić do sytuacji, w której przez drobną pomyłkę, część obrazu ląduje poza krawędziami obiektu <canvas>. Aby temu zapobiec, stosujemy metodę save(), która zapisuje aktualny stan obiektu <canvas> na stos. Stan przywracamy metodą restore(). Jako, że save() zapamiętuje informacje na stosie możliwe jest zapamiętanie kilku kolejnych stanów, a następnie cofanie się po nich do stanu pierwotnego. Rysowanie tekstu Obiekt <canvas> nie tylko pozwala na rysowanie obrazu. Kontekst 2d posiada także funkcje odpowiedzialne za narzucanie tekstu na obraz. Najprostszą metodą rysowania tekstu jest filltext(), która przyjmuje następujące parametry: tekst do wyświetlenia, koordynaty kolejno x i y początku rysowania tekstu, oraz opcjonalnie maksymalną szerokość (w tym przypadku silnik renderujący będzie starał się użyć fontu o większej gęstości lub mniejszej czcionce w przypadku, gdy treść nie mieści się w zadanej szerokości). measuretext() zwraca informację o szerokości zadanego tekstu w pikslach, mozpathtext() dodaje obrys tekstu do aktualnie przygotowywanej ścieżki. Pozwala to na wrysowanie w obraz tekstu, który będzie posiadał obrys. Najciekawszą z metod rysujących tekst wydaje się moztextalongpath(), która wpisuje tekst wzdłuż utworzonej ścieżki. Sama grafika nie jest skalowana lub poddawana

47 Mazakiem po WWW czyli kilka słów o obiekcie «canvas» 47 Rys 1 Praktyczny przykład (Pełen opis znajdziesz pod adresem: zniekształceniom. Proces polega na traktowaniu ścieżki jako linii bazowej pod daną literą. Pozwala to na uzyskanie ciekawych efektów, takich jak pofalowany czy spiralny tekst. Możliwe też jest ułożenie tekstu wzdłuż ścieżki utworzonej z... tekstu. Sterowanie stylem rysowanego tekstu, podobnie jak w poprzednich przypadkach, odbywa się poprzez globalne własności obiektu odpowiadającego za kontekst. font określa rozmiar i nazwę aktualnie używanej czcionki, zgodnie ze standardem zapisu wykorzystywanym w CSS, textalign definiuje sposób ułożenia tekstu względem np. ścieżki; możliwe wartości to left, right, center, start oraz end (domyślnie: start), textbaseline ustala położenie linii bazowej tekstu; aktualnie wspierane wartości to: top, hanging, middle, alphabetic, bottom (domyślnie: alphabetic). Praktyczne wykorzystane obiektu <canvas> można przedstawić implementując blue box dla obrazu video. Przypomnijmy czym jest efekt blue box jest to zastąpienie wybranego koloru tła obrazem pochodzącym z innego źródła. W efekcie uzyskujemy złudzenie przebywania osoby w innym miejscu niż jest faktycznie. Efekt ten znany jest także pod nazwami: bluescreen, greenscreen czy też chroma key. Jedyne co potrzebujemy, to obiekt <video>, z którego pobierać będziemy kolejne klatki oraz dwa obiekty <canvas>. W drugim z tych obiektów ustawiamy tło na obrazek, który ma być tłem sceny. Algorytm działania jest prosty. Po załadowaniu strony, zdarzeniem onload inicjujemy wszystkie potrzebne nam zmienne oraz inicjujemy przeliczanie widocznych klatek w funkcji settimeout(). Funkcja uruchomiona przez settimeout() każdorazowo na koniec swojego działania ustawia ponowne wywołanie samej siebie z opóźnieniem 0. W praktyce powinno ustawiać się opóźnienie, wyliczając czas na podstawie framerate filmu. Skupimy się na obliczeniach efektu chroma key. W tym celu najpierw kopiujemy zawartość obrazu z <video> do pierwszego z posiadanych obiektów <canvas>. ctx1.drawimage(myvideo, 0, 0, mywidth, myheight);

48 48 Robert BoBsoN Partyka Następnie pobieramy macierz obrazu (dane o kolorach w każdym pikslu w postaci tablicy) let frame = ctx1.getimagedata(0, 0, mywidth, myheight); let l = frame.data.length / 4; Przeliczamy w iteracji wszystkie piksle jeżeli kolor któregoś z nich zgadza się z określonym przez nas tłem ustawiamy jego alpha na zero. for (let i = 0; i < l; i++) { let r = frame.data[i * 4 + 0]; let g = frame.data[i * 4 + 1]; let b = frame.data[i * 4 + 2]; if (g > 100 && r > 100 && b < 43) frame.data[i * 4 + 3] = 0; } W ostatnim kroku umieszczamy przetworzoną macierz obrazu w drugim obiekcie <canvas>: ctx2.putimagedata(frame, 0, 0); Powyższy przykład umieszcza obraz video na statycznym tle. Przy niewielkiej modyfikacji (kopiowanie z dwóch źródeł, narzucanie na trzeci obiekt <canvas>) możliwe jest uzyskanie efektu nałożenia dwóch obrazów video. Kontekst 3D Peter Drucker powiedział kiedyś, że najlepszą metodą przewidywania przyszłości jest jej tworzenie. Nie wiadomo, czy ta sentencja przyświecała Vladimirowi Vukićevićowi, gdy rozpoczynał prace nad kontekstem 3d. Jej celem było wprowadzenie możliwości wykorzystania OpenGL ES (z sprzętową akceleracją) poprzez komendy JavaScript dostępne w ramach kontekstu graficznego obiektu <canvas>. W chwili obecnej dostępne jest rozszerzenie dla Firefox 3.5, które wprowadza dostęp do kontekstów 3d. Jego prace nie zostały bez echa. Inna grupa ludzi rozpoczęła prace nad biblioteką JS, która miała ułatwić tworzenie aplikacji w trzecim wymiarze, czego efektem jest C3D Library. Biblioteka ta wprowadza szereg udogodnień, takich jak obsługa scen, światła, system cząsteczek, kamerę czy też możliwość importu modeli z kilku formatów plików. 25 marca podczas Game Developers Conference w San Francisco fundacja Mozilla oraz grupa Khronos ogłosiły podjęcie wspólnych działań na rzecz wprowadzenia akceleracji 3D do przeglądarek internetowych. Wsparcie dla projektu zadeklarowało także Google co wraz z istnieniem przeglądarki Chrome wydaje się przesądzać o przyszłym sukcesie tego projektu. Pozostaje jedynie uzbroić się w cierpliwość i testować kolejne wersje rozszerzenia Canvas:3D.

49 Mazakiem po WWW czyli kilka słów o obiekcie «canvas» 49 Powyższy artykuł nie wyczerpuje wszystkich zagadnień związanych z obiektem <canvas>. Mam nadzieję, że udało mi się zachęcić was do bliższego przyjrzenia się temu elementowi. Czas pokaże, czy czeka nas wysyp graficznych aplikacji on-line. Źródła:

50 Postfix My MTA is better than yours! Marcin Hłybin Wstęp Zaczynając zabawę z pocztą każdy administrator powinien umieć rozróżnić trzy podstawowe pojęcia: MUA, MTA, MDA. Pierwszy z nich to Mail User Agent, który jest programem uruchamianym na desktopie i służy do pisania i odczytywania mejli 1 jak na przykład Evolution, Microsoft Outlook, czy Mozilla Thunderbird. Tego typu programy łączą się albo do serwera IMAP/POP3 w celu odebrania poczty, albo poprzez protokół SMTP do MTA. Kolejnym magicznym słowem jest tutaj MTA, bowiem oznacza Mail Transfer Agent, czyli software do wysyłania i routingu poczty, którego omówieniem się zajmiemy. Ostatnim elementem jest MDA, czyli Mail Delivery Agent odpowiedzialny za dostarczanie poczty do skrzynki pocztowej użytkownika, najczęściej w postaci zapisania mejla na dysku w odpowiednim katalogu. 1 Pisownia pochodzi od autora [przyp. red.]

51 Widok od strony SMTP i DNS Postfix My MTA is better than yours! 51 Naszym ulubionym MTA na chwilę obecną pozostanie Postfix. W dalszej części napiszę jak wygląda, kto go spłodził i dlaczego jest godny uwagi. Aby poczta mogła przemierzać czeluści Internetu, MTA musi komunikować się z innymi MTA. Standard komunikacji został ustanowiony dawno temu i do dziś odbywa się za pomocą tego samego protokołu SMTP, opatrzonego kilkoma wodotryskami dostosowującymi go do współczesnych czasów i zastosowań. Przykładowa sesja SMTP wygląda następująco: $ nc mail1.rootnode.net My MTA is better than yours! EHLO bongo.pl 250-stallman.rootnode.net 250-PIPELINING 250-SIZE VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: bongo@bongo.pl Ok RCPT TO: marcin@rootnode.net <marcin@rootnode.net>: Recipient address rejected: Your message has been greylisted for 300 seconds, please wait. RCPT TO: marcin@rootnode.net Ok DATA 354 End data with <CR><LF>.<CR><LF> Hello World Ok: queued as AF2C3655C6 W powyższym przykładzie zainicjalizowaliśmy rozszerzoną sesję SMTP. Rozszerzenie to jest nazywane ESMTP od Extended (lub Enhanced) SMTP. W protokole SMTP pierwszym poleceniem, które wydajemy jest HELO, natomiast aby odróżnić SMTP od ESTMP korzystamy z polecenia EHLO. W odpowiedzi serwer przestawia nam rozszerzenia, które obsługuje. Z ważniejszych są to PIPELINING, pozwalający na komunikację bez oczekiwania na odpowiedź po każdym poleceniu; SIZE, definiujący maksymalną wielkość przesyłki oraz STARTTLS obsługujący połączenia szyfrowane.

52 52 Marcin Hłybin W dalszej części sesji definiujemy nadawcę 2xx wszystko w porządku oraz odbiorcę poczty. Po komendzie RCPT 3xx wymagane są dodatkowe parametry TO otrzymujemy błąd 450 efekt działania greylistingu, który odracza przyjęcie 4xx tymczasowy problem poczty na 300 sekund sygnalizując tymczasowy błąd. Jest to zabezpieczenie przed 5xx krytyczny problem Tab 1 Pierwsza cyfra kodu SMTP spamerami, którzy hurtowo wysyłają mejle i nie dbają o ponowienie próby. My nie spamujemy, dlatego gdy minie 300 sekund, ponawiamy próbę wysłania RCPT i przystępujemy do przekazania treści za pomocą polecenia DATA. Zastanówmy się przez chwilę nad specyficznymi kodami: 250 i 450, które po każdym poleceniu otrzymujemy od serwera. Rodzaj kodu zależy od pierwszej cyfry: Ostatni wiersz naszej sesji informuje nas, że poczta została przyjęta i otrzymała identyfikator AF2C3655C6. Jest on bardzo istotny i pozwala w razie problemów na wyszukanie wiadomości w logach serwera pocztowego. Pojawia się naturalne pytanie: skąd serwer pocztowy wie, dokąd wysłać pocztę? W tym momencie uśmiecha się do nas usługa DNS i rekordy MX. Wpis MX (Mail exchanger) określa, który serwer pocztowy jest odpowiedzialny za obsługę poczty dla danej domeny. Jeśli domena takiego wpisu nie posiada, to zgodnie z RFC korespondencja jest pchana do maszyny określonej rekordem A. Wysyłając pocztę na adres marcin@rootnode.net, klient pocztowy (MUA) komunikuje się za pomocą protokołu SMTP z serwerem pocztowym (MTA). Postfix sprawdza najpierw w konfiguracji, czy sam nie obsługuje domeny rootnode.net. Jeśli tak, to w naszym przypadku przekazuje mejla do Dovecota (MDA), który zapisuje go na dysku twardym, w skrzynce użytkownika. Jeśli jednak Postfix nie obsługuje poczty dla tej domeny, odpytuje DNS o rekordy MX dla domeny rootnode.net: ;; ANSWER SECTION: rootnode.net. 300 IN MX 300 mail1.rootnode.net. rootnode.net. 300 IN MX 300 mail2.rootnode.net. W powyższym przykładzie widzimy, że istnieją dwa serwery obsługujące pocztę dla domeny rootnode.net i mają one identyczny priorytet 300. Jeśli komunikacja z pierwszym z nich została pomyślnie nawiązana, poczta zostanie przekazana właśnie jemu. Jeżeli nie, to Postfix komunikuje się z drugą maszyną. Jeśli jednak tamta także nie odpowiada, to mejl czeka w kolejce do momentu, aż któraś z maszyn zacznie odpowiadać lub skończy się czas przechowywania mejla w kolejce. Domyślnie jest to 5 dni. Postfix Postfix został napisany przez Wietse Venema. Pierwsza wersja ujrzała światło dzienne w 1999 roku jako półroczny projekt firmy IBM, opatrzony publiczną licencją. Od tej pory, jako doskonała alternatywa dla dużego, monolitycznego serwera poczty Sendmail, prężnie się rozwija. Postfix został zaprojektowany z myślą o bezpieczeństwie, dlatego też, zgodnie z uniksową filozofią, podzielono go na wiele małych programów,

53 Postfix My MTA is better than yours! 53 sterowanych demonem master. Każdy z nich odpowiada za jedno zadanie i jest uruchamiany z minimalnymi uprawnieniami, potrzebnymi do wykonania tego zadania. Wietse Venema pomimo swojego wieku (ur. w 1951 roku) jest nadal aktywnym developerem. Poruszając na liście dyskusyjnej ciekawy problem, możesz się spodziewać jego odpowiedzi. Może nie każdy wie, ale Wietse jest również twórcą TCP wrappera, dostępnego w każdej dystrybucji GNU/Linux w postaci demona tcpd. TCP wrapper to sieciowy system ACL pozwalający na blokowanie dostępu do usług w warstwie aplikacji. Jeśli kojarzysz pliki /etc/hosts.allow i /etc/hosts.deny to jest właśnie TCP Wrapper. Dodatkowo, Wietse w 1995 roku wraz z Danem Farmerem, stworzył rewelacyjny skaner sieciowy o nazwie S.A.T.A.N.

54 54 Marcin Hłybin Architektura Konfiguracja Postfiksa składa się z dwóch plików master.cf oraz main.cf. Pierwszy z nich zawiera definicje dla demona master, który jest odpowiedzialny za uruchamianie na żądanie wyspecjalizowanych demonów. W drugim pliku definiujemy wszystkie opcje Postfiksa, takie jak pliki map, obsługiwane domeny, restrykcje itp. Architektura Postfiksa wygląda następująco: Wydawać by się mogło, że wysłanie mejla to trywialna sprawa. Jak widać na powyższym grafie, nie do końca. Generalnie możemy wyróżnić dwa elementy procesy i kolejki. Są zaznaczone różnymi kolorami. Kolejka Postfiksa to nic innego jak katalog w /var/spool/postfix. W przypadku wysyłania mejli lokalnie za pomocą programu sendmail, praca Postfiksa rozpoczyna się od postdropa, który wrzuca Rys 1 Architektura systemu Postix przesyłkę do kolejki maildrop. Następnie demon pickup sprawdza, czy pojawiły się nowe wiadomości. Jeśli tak, pobiera i przekazuje je do demona cleanup. Alternatywnie gdy dostajemy pocztę z zewnątrz demon smtpd bezpośrednio przekazuje pocztę demonowi cleanup. Cleanup robi porządki z otrzymanym mejlem: dodaje brakujące nagłówki takie jak np. Date, From, czy To. Korzysta czasem z innego demona, trivial-rewrite, który dodaje odpowiednie domeny do adresu w przypadku niepełnych adresów . Po zakończonej pracy, cleanup przekazuje pocztę do kolejki incoming. Postfix został zaprojektowany tak, aby przy dużym obciążeniu systemu lub kończącej się pamięci nie dobić klękającego już serwera. Dlatego właśnie za pomocą specjalnej kolejki active, serwer pocztowy dawkuje sobie obsługę napływających mejli, pobierając ich odpowiednią ilość z kolejki incoming. Mejl czeka w kolejce active, aż zainteresuje się nim menedżer kolejek qmgr. Jest to serce Postfixa, które odpowiada za obsługę i trzymanie w kupie wszystkich kolejek. Pobierając mejla z kolejki active, qmgr decyduje, jak Postfix powinien go wysłać: czy przekazać do LDA (Local Delivery Agent) czy może przesłać dalej za pomocą protokołów SMTP lub LMTP, czy też przekazać jako wejście do innego programu za pomocą pipe.efekt poprawiania; w oryginale było: spajpować. DG Podsumowując, qmgr zarządza następującymi kolejkami:

55 Postfix My MTA is better than yours! 55 incoming tam wrzucane są mejle, które przychodzą do systemu pocztowego; active kolejka, w której znajduje się limitowana ilość aktualnie przetwarzanych mejli; deffered tam trafiają mejle, które nie mogły zostać dostarczone; dostarczenie jest ponawiane po podwojeniu czasu, który upłynął od poprzedniej próby, aż do końca czasu życia kolejki; corrupt tam lądują uszkodzone lub niedające się odczytać pliki; hold do tej kolejki dostają się wstrzymane mejle i leżą w niej tak długo, aż admin ich nie przywróci. Na tym etapie wiemy mniej więcej jak działa usługa poczty internetowej i jak jest realizowana przez serwer Postfix. Na stronie postfix.org dostępna jest znakomita dokumentacja zorganizowana w postaci wielu plików HTML. Każda zmienna konfiguracyjna Postfiksa to w praktyce odnośnik do strony, która szczegółowo ją opisuje. Dodatkowo, każdy demon i kolejka Postfiksa posiada osobną stronę manuala. W razie problemów warto zajrzeć najpierw tam. Konfiguracja Główny plik konfiguracyjny Postfiksa to main.cf. Wszystkie dostępne zmienne konfiguracyjne można znaleźć po wydaniu polecenia man 5 postconf. Za pomocą programu postconf można wyświetlić domyślne oraz aktualne ustawienia wszystkich zmiennych. Możemy także edytować konfigurację (parametr -e) bez konieczności otwierania pliku main.cf w edytorze tekstu. Podstawową konfigurację Postfiksa najczęściej wykona za nas system pakietowy danej dystrybucji. Nie zawsze mu to wychodzi, ale przynajmniej mamy dobry szablon pliku konfiguracyjnego. Gdy już doprowadzimy system pocztowy do działania i maillog wskazuje na to, że poczta wychodzi bezproblemowo na świat, możemy zająć się ciekawszymi rzeczami, czyli konfiguracją filtrowania poczty i restrykcjami. Kontrola dostępu Jak już wspomniałem,w sesji SMTP możemy wyróżnić polecenia HELO (lub EHLO), MAIL FROM, RCPT TO oraz DATA. W każdym etapie sesji SMTP istnieje możliwość kontroli dostępu za pomocą opcji smtpd_helo_restrictions, smtpd_sender_restrictions, smtpd_recipient_restrictions, smtpd_data_restrictions oraz smtpd_end_of_data_restrictions. Istnieje jeszcze smtpd_client_restrictions, który odwołuje się do wszystkich komend klienckich w sesji oraz smtpd_etrn_restrictions, który obsługuje restrykcje dla komendy ETRN (w dzisiejszych czasach już praktycznie nieużywanej służy ona w połączeniach dial-up owych do pobrania plików kolejki dla danej domeny). Wszystkie zmienne dotyczące restrykcji są opcjonalne, z wyjątkiem smtpd_recipient_restrictions, która jest wymagana.

56 56 Marcin Hłybin Jak widać, istnieje wiele poziomów kontroli dostępu. By dowiedzieć się, jakie parametry może przyjmować każda z nich, należy odwołać się do man 5 postconf lub stron www, wpisując na końcu URL-a jedną z powyższych restrykcji (np. Przykładowa konfiguracja może wyglądać następująco: smtpd_recipient_restrictions = check_recipient_access = hash:/etc/postfix/access permit_sasl_authenticated reject_invalid_hostname reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_pipelining reject_unauth_destination reject_multi_recipient_bounce permit_mynetworks reject_rbl_client sbl.spamhaus.org check_policy_service inet: :10022 permit Już po samych nazwach można się domyślić, za co jest odpowiedzialna każda z nich. Oczywiście wyraz reject w każdej opcji można zamienić na permit, jeśli tylko mamy ochotę inaczej sterować blokadami. Dodatkowo możemy definiować własne mapy dostępowe (jak wyżej, w opcji check_recipient_access). Jeśli mamy zbiorcze aliasy firmowe, warto wrzucić je na przykład do takiej mapy: $ cat /etc/postfix/access all@rootnode.net permit_mynetworks, reject Dzięki temu mamy gwarancję, że nikt spoza naszej sieci nie wyśle mejla na adres all@rootnode.net. Taki adres w wielu firmach stanowi doskonałe miejsce docelowe dla spamu. Należy pamiętać, aby po utworzeniu takiej mapy wykonać polecenie postmap /etc/postfix/access, w celu utworzenia bazy czytelnej dla Postfiksa. Skoro już o spamerach mowa, to Postfix umożliwia korzystanie z list RBL (Real-time Blackhole List), obsługę SPF oraz podpinanie zewnętrznych serwerów polityki dostępu. Przytoczony wyżej przykład zawiera definicję reject_rbl_client sbl.spamhaus.org, co wymusza sprawdzenie hosta, który się do nas łączy, w serwisie Spamhaus. Od strony technicznej wygląda to tak, że wykonywane jest zapytanie DNS, które jeśli niczego nie zwraca oznacza, że host nie jest spamerem. Tutaj mała uwaga: właściwie opcja reject_rbl_client powinna być umieszczona w restrykcji smtpd_client_restrictions. W praktyce nie ma to jednak żadnego znaczenia, bo restrykcje dotyczące początku sesji SMTP, aż do momentu RCPT TO są wykonywane w tym samym momencie, czyli dopiero po RCPT TO. Niektóre serwery pocztowe nie są bowiem przygotowane na odrzucenie żądania już na etapie HELO lub MAIL FROM. Co więcej: wpis w maillogu nie mógłby jednoznacznie wskazać, który

57 Postfix My MTA is better than yours! 57 z mejli został odrzucony (tzn. od kogo do kogo), gdyby odrzucenie nastąpiło to tuż po komendzie HELO. Na przytoczonym wyżej przykładzie widać, że dalsze checki mogą się odwołać do zewnętrznej usługi za pomocą check_policy_service. Mogą to być połączenia zarówno po sockecie uniksowym jak i TCP. Po drugiej stronie zazwyczaj nasłuchuje demon napisany w Perlu lub w Pythonie. Rozwiązania takie funkcjonują szybko i sprawnie, i tylko w bardzo dużych systemach może zajść potrzeba przepisania tych demonów na język niższego poziomu, np. C. W powyższym przykładzie mamy również zaimplementowany greylisting. Usługa polega na wysłaniu klientowi tuż po komendzie RCPT TO kodu 450, tak, aby spróbował ponownie później. Dzięki temu jesteśmy w stanie pozbyć się 80% spamerów, którzy wysyłają mejle przez serwery proxy, zombie na losowo wygenerowane adresy mejlowe i nie kwapią się, by powtórzyć transmisję w przypadku otrzymania kodu 450. Oczywiście należy pamiętać, że spamerzy są coraz sprytniejsi i uodpornienie się na greylisting to tylko kwestia czasu. Często spam jest wysyłany przez prawdziwe serwery pocztowe, na przykład dzięki dziurze w Wordpressie lub innej aplikacji webowej. W takich sytuacjach greylisting nie pomoże. Można stosować dodatkowe zabezpieczenia jak np. Sender Policy Framework (SPF), opierający się na usłudze DNS. Za pomocą rekordów TXT pozwala odrzucać mejle pochodzące z hostów nieupoważnionych do używania danej domeny. Serwer pocztowy sprawdza wówczas pole z nagłówka Return-path (które czasami nazywa się także Envelope-sender) i porównuje z definicją SPF w rekordzie TXT domeny. Jest to bardzo ciekawy i przydatny mechanizm, ale czasami uprzykrza życie, szczególnie z aliasami. Kończąc definiowanie restrykcji musimy dodać opcję permit, która oznacza, że jeśli poczta przeszła bezproblemowo przez wszystkie wcześniejsze warunki, to powinna zostać zaakceptowana. Administrując produkcyjnym serwerem trzeba uważać z dodawaniem nowych opcji, ponieważ może się okazać, że niewłaściwa konfiguracja spowoduje odrzucenie poprawnych mejli. Aby tego uniknąć, powstała opcja soft_bounce, która zamienia wszystkie kody 5xx na 4xx, a te jak już wiemy oznaczają tymczasowy problem i ponawianie prób przez zdalne hosty. Opcjonalnie przed daną opcją w restrykcjach można wstawić warn_if_reject, co spowoduje wygenerowanie w logu ostrzeżenia, kiedy warunek restrykcji zostanie dopasowany. Filtrowanie Postfix dostarcza nam silnych mechanizmów do odrzucania szemranych mejli, ale możemy pójść jeszcze o krok dalej. Kolejnym sposobem podnoszącym bezpieczeństwo poczty, jest mechanizm jej filtrowania. Zaczynając od najprostszych, wbudowanych w Postfiksa, mamy do dyspozycji: header_checks oraz body_checks. Obydwa posiadają rozbudowaną stronę manuala. Są zaimplementowane w demonie cleanup i przetwarzają pocztę zanim trafi do kolejki. Tabela checków zawiera serię wyrażeń regularnych oraz przyporządkowaną im akcję. Po pierwszym dopasowaniu wzorca wywoływana jest akcja i Postfix kończy przetwarzanie, przechodząc do kolejnego mejla. Do rodzajów akcji należą PERMIT, REJECT, DISCARD, WARN, HOLD, REDIRECT i kilka innych. Różnica między header_checks,

58 58 Marcin Hłybin a body_checks, jak się można domyślić, polega na tym, że pierwszy przetwarza nagłówki, a drugi treść wiadomości. Przykładowa definicja header_checks może wyglądać następująco: w pliku /etc/postfix/main.cf: header_checks = regexp:/etc/postfix/header_checks w pliku /etc/postfix/header_checks: /^content-(type disposition):.*name[[:space:]]*=.*\.(exe vbs)/ REJECT Bad attachment file name extension: $2 Powyższy przykład odrzuci mejle z załącznikami o rozszerzeniu exe lub vbs, dodatkowo informując o tym nadawcę. Gdy zamiast REJECT zastosujemy DISCARD, nadawca nie zostanie poinformowany o niedostarczeniu mejla. W przypadku WARN, w pliku loga zostanie zapisana informacja o złym załączniku. REDIRECT możemy skierować przesyłkę na dowolny adres, a polecenie HOLD zatrzymać ją w kolejce hold, aż do interwencji administratora. Możemy również zdefiniować zewnętrzny filtr mejli. Najpopularniejszym jest perlowy amavisd-new, który stanowi most pomiędzy Postfiksem a mechanizmem wykrywającym spam (na przykład SpamAssassin), skanerem antywirusowym (takim jak ClamAV), czy innymi zewnętrznymi programami, jak na przykład p0f. Zewnętrzny filtr definiujemy za pomocą opcji content_filter. Filtrowanie poczty odbywa się, gdy wiadomość znajdzie się w kolejce. Musimy wyjąć mejla z kolejki, przetworzyć i ponownie wrzucić go do Postfiksa. W pliku master.cf trzeba dodać dwa serwisy : pierwszy, odpowiedzialny za odpalenie perlowego filtra przez spawn (jest to odpowiednik inetd), oraz drugi, jako demon smtpd, odpowiedzialny za ponowne przekazanie mejla Postfiksowi, już po zakończeniu działania filtra. Uruchomienie filtra: # ============================================================= # service type private unpriv chroot wakeup maxproc command # (yes) (yes) (yes) (never) (100) # ============================================================= scan unix - - n - 10 smtp -o smtp_send_xforward_command=yes -o disable_mime_output_conversion=yes -o smtp_generic_maps= localhost:10025 inet n n n - 10 spawn user=filter argv=/path/to/filter localhost Powrót mejla: # =================================================================== # service type private unpriv chroot wakeup maxproc command # (yes) (yes) (yes) (never) (100) # =================================================================== localhost:10026 inet n - n - 10 smtpd

59 -o content_filter= Postfix My MTA is better than yours! 59 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters -o smtpd_helo_restrictions= -o smtpd_client_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= /8 -o smtpd_authorized_xforward_hosts= /8 Konfiguracja po stronie pliku main.cf ogranicza się do ustawienia parametrów content_filter oraz receive_override_options. Pilnuje ona, by do filtra trafiały oryginalne, niezmienione przez żaden mechanizm Postfiksa, nagłówki: content_filter = scan:localhost:10025 receive_override_options = no_address_mappings Istnieją jeszcze dwie inne metody filtrowania poczty. Pierwszą z nich, stosowaną przede wszystkim w listach mailingowych, jest obsługa docelowego adresu przez skrypt perlowy lub dowolny inny plik uruchamialny, poprzez pipe. Można to w prosty sposób zrobić w pliku /etc/aliases. Aby plik /etc/aliases był w ogóle przetwarzany poczta powinna być obsługiwana przez demona local, który jest domyślnym LDA. Prawie na pewno będziemy obsługiwali wiele wirtualnych domen, korzystając przy tym z demona virtual albo bodaj najlepszego pozapostfiksowego LDA Dovecot. Jeśli tak się zdarzy, a chcemy, aby konkretny mejl mógł zostać obsłużony przez plik /etc/aliases, musimy najpierw przekierować pocztę na skrzynka@localhost lub skrzynka@$mydestination. W ten sposób dajemy Postfiksowi znać, że skrzynka jest kontem na lokalnym komputerze i powinna zostać obsłużona przez demona local. Informację, który z LDA jest obecnie używany, znajdziemy w maillogu: Jul 22 00:17:42 stallman postfix/pipe[5161]: D20DD89E8E: to=<marcin@rootnode.net>, relay=dovecot, delay=10, delays=10/0.01/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service) Widzimy, że relay=dovecot, czyli dostarczenie poczty do skrzynki użytkownika zostało powierzone programowi Dovecot. Plik /etc/aliases może wyglądać następująco: /etc/aliases: users-pl: announce-pl: " /usr/bin/mlmmj-recieve -L /var/spool/mlmmj/users-pl/" " /usr/bin/mlmmj-recieve -L /var/spool/mlmmj/announce-pl/" Jak widać, skrzynki users-pl oraz announce-pl to adresy list mailingowych i są spipowane 2 z programem mlmmj-receive odpowiedzialnym za odebranie poczty i rozesłanie do wszystkich subskrybentów listy. W to miejsce można oczywiście wstawić dowolny skrypt lub program, który będzie robił z pocztą wszystko, na co tylko mamy ochotę. W Postfiksie została także zaimplementowana obsługa protokołu milter, znanego z Sendmaila. Jest to tzw. filtrowanie przedkolejkowe. Internet pełen jest gotowych 2 Określenie autora [przyp. red.]

60 60 Marcin Hłybin skryptów i programów korzystających z miltera, z których korzysta się także w Postfiksie. Więcej na ten temat znaleźć można w dokumentacji. Narzędzia Gdy mamy już uruchomionego i skonfigurowanego Postfiksa, musimy jakoś nim administrować i zarządzać. Istnieje szereg wbudowanych poleceń, które pomogą nam manipulować kolejkami. Trzy najważniejsze z nich, dostarczane przez Postfiksa to: postqueue, postsuper i postcat. Za pomocą polecenia postqueue -p możemy wyświetlić kolejkę wiadomości, które z jakiegoś powodu jeszcze nie zostały wysłane. Polecenie jest tożsame z sendmailowym mailq. Dodatkowo możemy opróżnić (ang. flush) kolejkę, czyli w trybie natychmiastowym ponowić próbę wysłania wszystkich przesyłek zalegających w kolejce. Poleceniem postsuper usuwamy wiadomości z kolejki, przenosimy do hold, itp. Jeśli chcemy wstrzymać przetwarzanie wszystkich wiadomości, wystarczy użyć polecenia postsuper -h ALL. Postcat służy natomiast do wyświetlenia konkretnego mejla z kolejki, przy założeniu, że znamy jego ID: postcat -q 03E437F67A. Ciekawym narzędziem jest konsolowe narzędzie pfqueue, które napisano z wykorzystaniem biblioteki ncurses. Dzięki niemu mamy podgląd całej kolejki mejli, z którymi jest jakiś problem. Możemy szybko przeglądnąć wiszące w kolejce mejle, zaznaczyć i usunąć. Tak naprawdę brakuje dobrych narzędzi do zarządzania Postfiksem. Każdy administrator korzysta ze swoich skryptów i aliasów. Brakuje na przykład tak fundamentalnej rzeczy, jak usuwanie wszystkich wiadomości z kolejki, zaadresowanych do danego odbiorcy. Powiedzmy, że wysyłaliśmy mejle do wszystkich użytkowników a adres jednego z nich jest już nieaktualny lub serwer pocztowy w ogóle zniknął z sieci. W takiej sytuacji, w kolejce może wisieć nawet kilkaset mejli do tego użytkownika. Oczywiście dzięki pipowaniu poleceń uniksowych i językom skryptowym jesteśmy w stanie sobie poradzić z każdym, nawet najbardziej zawiłym problemem. By usunąć z kolejki mejle do konkretnego odbiorcy, dokumentacja komendy postsuper zaleca coś takiego (teraz uwaga, trzymać się krzeseł! 3 ): mailq tail +2 grep -v ^ *( awk BEGIN { RS = "" } # $7=sender, $8=recipient1, $9=recipient2 { if ($8 == "user@example.com" && $9 == "") print $1 } tr -d *! postsuper -d - Jak widać nie wszystko w Postfiksie jest proste i przyjemne, choć to kwestia napisania odpowiednich narzędzi. 3 PLUG i redakcja nie zalecają korzystania z poniższego, niepoprawnego skryptu.

61 Duże systemy pocztowe Postfix My MTA is better than yours! 61 Nie ma niestety żadnego manuala ani poradnika, jak tworzyć duże systemy pocztowe oparte na Postfiksie. Trzeba poznać mechanizmy rządzące tym serwerem poczty i pomyśleć, w jaki sposób najlepiej go skalować. Ze względu na modularną budowę, poszczególne części Postfiksa można rozłożyć między maszynami. Najlepiej zaczynając od odseparowania serwera poczty wychodzącej od przychodzącej. Można też poświęcić jedną (lub dwie maszyny w failoverze) na front zajmujący się tylko i wyłącznie routingiem poczty do wielu maszyn. Jest to popularna metoda przy radzeniu sobie z obciążeniem serwerów www (patrz LVS). Wszystko wygląda pięknie pod warunkiem, że dysponujemy sprzętem odpowiedzialnym za przechowywanie danych (storage). Wówczas wszystkie maszyny stojące za frontem korzystają z jednego zasobu i nie ma konieczności stawiania systemu high-availability, np. DRBD z globalnym filesystemem (np. GFS), który bywa niestabilny. Podobny problem pojawia się w przypadku, gdy użytkownicy korzystający z tej samej domeny pocztowej mają konta na dwóch różnych maszynach. Nie śmiem twierdzić, że Rootnode to duży system pocztowy, ale taki problem się pojawił i trzeba było go rozwiązać. Jak? Poczta jest przechowywana w katalogach domowych użytkowników. W przypadku jednej maszyny shellowej o nazwie stallman problemu nie było MX dla domeny wskazywał na stallmana i poczta działała bezproblemowo. Problem pojawił się po dostawieniu drugiej maszyny shellowej (korn). Okazało się, że nowi użytkownicy też chcieli korzystać z domeny rootnode.net i też musieli mieć pocztę w katalogach domowych. W efekcie mamy dwa serwery, dwa różne zasoby dyskowe i jedną domenę. Jeśli pozostawimy MX-y bez zmian, poczta skierowana do użytkownika posiadającego konto na stallmanie zostanie dostarczona, a poczta w tej samej domenie skierowana do serwera korn zostanie odrzucona z komunikatem, że skrzynka nie istnieje. Otóż wpadliśmy na następujący pomysł: zróbmy na obu serwerach transporty. Na serwerze stallman będzie mapa transportów ze wszystkimi adresami znajdującymi się na kornie. Na kornie zaś będzie mapa transportów ze wszystkimi adresami, które fizycznie znajdują się na stallmanie. Przykładowy wpis w mapie transportów /etc/postfix/transport: marcin@rootnode.net smtp:[ ]:25 Powyższe oznacza, że wszystko co powinno być dostarczone na adres marcin@rootnode.net wysyłamy protokołem SMTP na port 25 do hosta Kwadratowe nawiasy oznaczają, że jest to docelowy adres IP i nie należy odpytywać DNS o rekord MX. Należy pamiętać, aby w plikach main.cf obydwu Postfiksów zdefiniować obsługę domeny rootnode.net, czy to w mydestination, czy w virtual_mailbox_domains. Ostatnim krokiem konfiguracji jest zmiana rekordów MX dla domeny i nadanie wpisom identycznych priorytetów:

62 62 Marcin Hłybin Rys 2 Mechanizm round-robin, przepływ poczty $ dig +short rootnode.net mx 300 mail1.rootnode.net. 300 mail2.rootnode.net. Od tego momentu, dzięki algorytmowi round-robin, korespondencja będzie trafiać raz na jeden serwer, raz na drugi. Zastanówmy się jeszcze przez chwilę nad przedstawionym rozwiązaniem. Rozwiązaliśmy problem obsługi jednej domeny przez dwa serwery pocztowe, bez bramy (gateway) na froncie. Zrobiliśmy przy okazji backupowy serwer MX. Dzięki temu, w przypadku awarii jednej z maszyn, druga przyjmie całą pocztę i będzie przechowywać mejle w kolejce, aż do czasu powrotu drugiej maszyny lub końca życia kolejki (domyślnie 5 dni). Bez problemu możemy też dokładać kolejne maszyny (rysunek 2). Na zakończenie Warto jeszcze wspomnieć gdzie i co czytać. Oczywiście najlepszym źródłem informacji są manuale oraz dokumentacja na stronie postfix.org. Jeśli napotkasz problem, który nie został opisany w dokumentacji, albo potrzebujesz porady podczas projektowania swojego systemu pocztowego, warto napisać na listę dyskusyjną postfix-users. Znam tylko dwie książki, które są godne uwagi: O Reilly: Postfix the definitive guide oraz The book of Postfix: state-of-the-art message transport. Postfix cały czas zmienia się i ewoluuje. Tworzony jest nowy kod, niektóre funkcje stają się obsolete 4, dlatego nie polecam starszych wydań tych książek. Prawie na pewno spotkasz tam konfigurację POP3, IMAP oraz SASL opartą o oprogramowanie Courier i Cyrus. Jest to metoda trochę przestarzała i najlepiej stosować bardzo szybki serwer Dovecot, dobrze wspierany przez Postfiksa. Konfiguracja POP3, IMAP i SASL w tym przypadku to kwestia odkomentowania kilku linii w pliku konfiguracyjnym. 4 określenie autora [przyp. red.]

63 Apache Hadoop framework do pisania aplikacji rozproszonych Piotr Praczyk Wprowadzenie Istnieje wiele rodzajów obliczeń, których wykonywanie na pojedynczej maszynie, nawet najpotężniejszej, jest zbyt czasochłonne. Wśród takich zadań wymienić można analizowanie skomplikowanych danych (na przykład dane z LHC etc...), albo przetwarzanie ogromnych ich ilości (na przykład Google Maps). Z tego powodu rozwijane są narzędzia ułatwiające wykonywanie obliczeń na wielu komputerach jednocześnie. W przypadku tradycyjnych podejść, programista musi samemu rozwiązywać problemy narastające między innymi kiedy więcej niż jeden działający fragment obliczenia chce uzyskać dostęp do zasobu, kiedy potrzebna jest komunikacja między maszynami itp. Google zaproponował własny paradygmat tworzenia aplikacji rozproszonych, Map Reduce [1] Struktura programów napisanych zgodnie z nim, ułatwia rozwiązywanie wielu skomplikowanych problemów współbieżności automatycznie, ułatwiając zadanie programisty. Przedstawione podejście sprawdza się wyjątkowo dobrze w przypadku programowania zadań wymagających przetwarzania dużych ilości danych. Apache Hadoop jest wolną implementacją Map Reduce. Jest wykorzystywany przez wiele dużych firm takich, jak Yahoo, Amazon czy Facebook. Google posiada własną implementację Map Reduce, którą wykorzystuje wewnętrznie. Hadoop składa się z oprogramowania uruchamianego na maszynach przeznaczonych do wykonywania obliczeń i przechowywania danych oraz z zestawu bibliotek

64 64 Piotr Praczyk Rys 1 Elementy zadania Map Reduce umożliwiających pisanie zadań. Językiem, w którym Hadoop jest napisany, jest głównie Java. Konsekwencją tego jest dostarczenie największej liczby interfejsów programistycznych dla tego języka. Również najbardziej naturalną metodą tworzenia programów działających pod kontrolą Hadoop, jest dostarczenie odpowiednich klas w Javie. Istnieje możliwość wykorzystania dowolnego innego języka programowania. Czasami możliwe jest również uruchomienie istniejącego programu, jako części zadania Map Reduce, bez ingerencji w jego strukturę wewnętrzną. Podstawy Map Reduce W najprostszym przypadku, przygotowanie zadania dla Map Reduce, sprowadza się do zaimplementowania dwóch funkcji, map oraz reduce. Konieczne jest również zdefiniowanie położenia danych wejściowych oraz miejsca, gdzie mają być składowane wyniki. Zadaniem funkcji map jest wykonanie pewnych obliczeń na przekazanym jej fragmencie danych wejściowych oraz wygenerowanie ciągu par składających się z klucza oraz przypisanej mu wartości. Dane wygenerowane w tym kroku, są agregowane z wykorzystaniem klucza oraz przekazywane do funkcji reduce. Każde wywołanie reduce związane jest z jednym kluczem oraz listą wszystkich odpowiadających mu wartości. Zadanie funkcji reduce polega na wygenerowaniu par stanowiących wynik obliczenia. Są one zapisywane w lokalizacji wskazanej jako wyjściowa. Rysunek 1 pokazuje strukturę dowolnego obliczenia Map Reduce. Dopóki cały opisany proces odbywa się na jednej maszynie, stosowanie infrastruktury związanej z Map Reduce wiąże się głównie ze stratami wydajności. Jeśli jednak dane wejściowe są odpowiednio duże, implementacja Map Reduce (na przykład Hadoop) zadba o to, aby obliczenia zostały automatycznie rozproszone. Rysunek 2 przedstawia schemat wykonania zadania przygotowanego dla Hadoop na wielu maszynach jednocześnie. Na pierwszy rzut oka, rozwiązanie wydaje się dość niewydajne, ponieważ przesyłanie dużych ilości danych za pośrednictwem sieci jest stosunkowo wolnym procesem. Hadoop stara się umieszczać obliczenia na tych samych maszynach, gdzie przechowywane są dane. Jeśli nie jest to możliwe, obliczenia wykonywane są w miejscach, które są bliskie ze względu na szybkość połączenia sieciowego. Klasycznym przykładem zastosowania paradygmatu Map Reduce, opisanym w [1], jest generowanie statystyk słów pojawiających się w tekście przekazanym jako wejście. Funkcja map, odpowiedzialna może być w takim przypadku za podzielenie otrzymanego napisu na wyrazy oraz wygenerowanie par zawierających wyraz jako klucz oraz liczbę 1 jako wartość. W następnym kroku, framework automatycznie pogrupuje pary ze względu na słowa będące kluczami par. Zadaniem funkcji reduce