Jesień Linuksowa 2006

Transkrypt

1 Jesień Linuksowa 2006 Polska Grupa Użytkowników Linuxa

2 Tytuł oryginału: Jesień Linuksowa 2006 ISBN-10: X ISBN-13: Autorzy: Koordynacja: Wydawca: Projekt graficzny okładki: Skład i łamanie: Adam Buraczewki, Dariusz Grzesista (DarGrze) Maciej Laskowski (Tsalarioth), Marek Magryś (tezar) Paweł Moll (Hornet), Grzegorz Ponikierski (Grey) Marcin Kuczera Dariusz Grzesista Polska Grupa Użytkowników Linuxa, ul. Bartycka 18, Warszawa Marzenna Dobrowolska (marzka) Jarosław Jan Pyszny (arghil@pyszny.net) Składu dokonano z wykorzystaniem: Wersja elektroniczna książki: OS Linux, LaTeX, OpenOffice.org, VIM, KDE/Kile Druk: QPrint ( ul. Emilli Plater Warszawa, (22) Rozpowszechnianie całości lub fragmentów niniejszej publikacji jest wskazane. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym nie powoduje naruszenia praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są znakami z alfabetu łacińskiego, z elementami diakrytycznymi polskimi. Autorzy oraz Wydawca dołożyli wszelkich starań, żeby zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności za ich wykorzystanie.

3 Wstępniak Nastała Jesień. Tym razem spotykamy się w Lewinie Kłodzkim żeby posłuchać ciekawych prelekcji na tematy związane z Wolnym Oprogramowaniem, poznać nowych znajomych, wymienić się spostrzeżeniami i pomysłami. Lato się skończyło, powróciliśmy do naszych domów z wakacji, nastają długie zimowe wieczory. Czy to nie idealna pora do pracy nad rozwojem Wolnego Oprogramowania oraz nad sobą samym? Nieciekawa pogoda sprzyja zagłębianiu się w literaturę, pogaduszkom na Jabberze z innymi zwolennikami Wolnego Oprogramowania oraz wnoszeniu własnego wkładu w jego rozwój. Dziękujemy naszym sponsorom, którzy dali różne upominki dla uczestników: Leon Teleinformatyka Sp. z o.o. ( LinuxStuff ( Power Media Sp. z o.o. ( Producentowi polskiej wersji pakietu OpenOffice.org, przedsiębiorstwu UX Systems ( Producentowi i dystrybutorowi SUSE Linux Novell Polska ( Producentowi i dystrybutorowi Mandriva Linux ( Wydawcy miesięcznika Linux Magazine ( Wydawcy Software Developer's Journal ( Wydawnictwu Helion ( Wydawnictwu RM ( Podziękowania dla tych, którzy pomagali w trudzie powstawania książki oraz wszystkim tym, którzy przyczynili się do tego by konferencja mogła się odbyć.

4 Organizatorzy Jesień 2006 współorganizują: PLUG (głownie rękoma oddziałów śląskiego i wrocławskiego) oraz sklep linuksowy Linuxstuff. Agnieszka Bohosiewicz (Agusia) (prezes@linux.org.pl) Czujne Oko Dariusz Grzesista (DarGrze) (darek@linux.rybnik.pl) koordynator całości Bartek Jakubski (migo@pld-linux.org) soundmanager, inkwizytor Filip Kłębczyk (delta@rybnik.net.pl) - naczelny kamerman, inkwizytor Krzysztof Leszczyński (chris@camk.edu.pl) twórca i nadzorca systemu rejestracji uczestników Jesieni Paweł Moll (hornet@sltzn.katowice.pl) sternik AV Grzegorz Ponikierski (GREY) (greymail@poczta.fm) inkwizytor, nosiwoda Jaroslaw Jan Pyszny (Arghil) (arghil@pyszny.net) główny TeXnokrata d/s broszury jesiennej Paweł Rodowicz (pawel@tawerna.org) inkwizytor, spec. d/s karaoke Rafał Roszak (rmrmgrmrmg.com) inkwizytor Artur Siążnik (artursilesia.linux.org.pl) stronowładny, inkwizytor, wgrywający pliki na serwer Iza Sobota-Miszczak (izasilesia.linux.org.pl) główny skarbnik Mamy nadzieję, że tegoroczna Jesień okaże się udana. Życzymy Wam świetnej zabawy, miłego pobytu. Przepraszamy za wszelkie uchybienia. Prosimy też o uwagi na temat organizacji i pomysły na przyszłoroczną (mała rocznica 5 edycja ) Jesień Zawsze i wszędzie można się z nami kontaktować poprzez adres: jesien@linux.org.pl.

5 Agenda Temat Piątek 15:30 Big Bang - rozpoczęcie / Zakwatrerowanie Autor Czas trwania [min.] 16:30 Unicode Grzegorz Ponikierski GREY 60 17:30 FUSE - ciekawe zastosowania programowych systemów plików 19:00 Kolacja 20:00 Walne zebranie członków PLUG o. Śląsk / Karaoke 09:00 Śniadanie Sobota Marek Janukowicz [Power Media sp. z o.o] 10:00 Google hacking Maciej Laskowski/Tsalarioth 60 11:15 Wi-Fi hacking Marek Magryś/Tezar 90 13:00 Obiad 14:15 Wykorzystanie protokołów routingu dynamicznego w sieciach komputerowych z dostępem do Internetu Marcin Kuczera [Leon sp. z o.o] 15:30 Bezpieka w strukturach poczty Dariusz Grzesista 60 16:45 [Warsztat] Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 18:30 Kolacja 19:30 Karaoke 09:00 Śniadanie Niedziela Adam Buraczewski 60 10:15 Podstawy inżynierii jądrowej Paweł Moll/Hornet :00 Sztuka pozycjonowania Maciej Laskowski/Tsalarioth 60 13:00 Obiad / Zakończenie imprezy

6 Spis treści I. UNICODE 7 II. Google hacking 11 III. Wi-Fi Hacking 16 IV. Zastosowanie protokołów routingu dynamicznego w sieciach komputerowych z dostępem do Internetu. 18 V. Bezpieka w strukturach poczty 21 VI. Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 26 VII. Podstawy inżynierii jądrowej 36 VIII. Sztuka Pozycjonowania 49

7 Grzegorz GREY Ponikierski UNICODE Язык, アルファベット, página de código Powyższy tekst został napisany po rosyjsku, japońsku i hiszpańsku. Słowa które zostały za ich pomocą zapisane to alfabet, język i strona kodowa. Ludzie używają obecnie ok języków (choć niektórzy badacze twierdzą, że jest ich 6-6.5k), ok. 100 różnych alfabetów i kilkadziesiąt stron kodowych. Jeśli spojrzeć na popularność języków, których przed chwilą użyliśmy to rosyjski jest na 8-mym miejscu (160mln użytkowników), japoński 9-tym (130mln), hiszpański 3-cim (450mln). Język polski jest dopiero na 20-tym miejscu (50mln). Do zapisu języka rosyjskiego używa się cyrylicy (grażdanki), dla japońskiego używa się naraz dwóch alfabetów kanji i kany (ten drugi dzieli się na hiraganę i katakanę), a dla języka hiszpańskiego używa się alfabetu łacińskiego z dodatkowymi znakami i tak samo jest z polskim (tak wiec można powiedzieć, że hiszpański i polski używa dwóch różnych alfabetów). Użyliśmy już 4 języków i 5 alfabetów (przypominam, że Japończycy używają dwóch alfabetów, a przez wpływ państw zachodnich i ameryki musieli też poznać alfabet łaciński więc praktycznie każdego dnia korzystają z 3 alfabetów). Tak więc pomyślmy za pomocą jakich stron kodowych moglibyśmy zapisać ten tekst? Gdyby to był rosyjski to moglibyśmy użyć ISO , KOI8-R, KOI8-U, CP-1251, CP-866. Dla japońskiego mamy Shift-JIS, ISO-2022-JP, EUC-JP. Hiszpański? ISO , ISO , CP Polski chyba ma najmniejszy wybór bo obecnie mamy tylko ISO i CP Tak oto wymieniliśmy 13 stron kodowych. 4 języki, 5 alfabetów, 13 stron kodowych. Przeciesz to dopiero początek, tego jest więcej! Strony kodowe nie są ze sobą kompatybilne, przy próbie konwersji jednej strony kodowej na druga tracimy informacje o części znaków (lub nawet wszystkich). Czy każdy z nas ma być ekspertem od stron kodowych jeśli będzie chciał coś napisać do kolegi z Finlandii czy Turcji? (Znasz tak w ogóle języki, alfabety i strony ZS6 im. króla Jana III Sobieskiego w Jastrzębiu Zdroju kodowe, których tam używają?). Boli Cię już głowa od tego? Pomyśl ile utrapienia maja deweloperzy, którzy muszą te wszystkie strony kodowe wpierać. Do tego wiele ludzi używa znaków matematycznych, muzycznych, do rysowania ramek, znaków alfabety greckiego. Tych znaków nie ma np. w stronach kodowych ISO-8859-*. Zaraz! Tak więc jak w tym tekście mogliśmy użyć tych wszystkich znaków mimo różnić w stronach kodowych? Jak więc zaradzić temu całemu galimatiasowi? Nie zmusimy wszystkich ludzi by znali angielski i by używali tylko alfabetu łacińskiego. Za to możemy sprawić by wszyscy używali jednej tablicy znaków. Tak więc odpowiedzią na nasze pytanie jest UNI- CODE! UWAGA! Unicode jako słowo ma dwa znaczenia. Pierwsze to idea, która opisuje w pkt. 2. Idee tą będę w dalszej części konspektu określał mianem Unikodu (to polska wersja). Drugie znaczenie to standard wydawany przez Unicode Consortium pod nazwa Unicode. Proszę o tym pamiętać by nie było pomyłek. Czym jest Unikod? Co daje Unikod? Dlaczego warto całkowicie na niego przemigrować? Unikod przypisuje unikalny numer każdemu znakowi, niezależny od używanej platformy, programu czy języka. W zamierzeniu ma obejmować wszystkie znaki używane w alfabetach świata. W angielskiej dokumentacji możemy wyczytać że zawiera alfabety: Latin, Greek, Cyrillic, Hebrew, Arabic, Armenian, and Georgian scripts, but also Chinese, Japanese and Korean Han ideographs as well as scripts such as Hiragana, Katakana, Hangul, Devanagari, Bengali, Gurmukhi, Gujarati, Oriya, Tamil, Telugu, Kannada, Malayalam, Thai, Lao, Khmer, Bopomofo, Tibetan, Runic, Ethiopic, Canadian Syllabics, Cherokee, Mongolian, Ogham, Myanmar, Sinhala, Thaana [... ] Do tego zawiera też znaki używane przez matematyków i fizyków, nuty, znaki obrazkowe, znaki do rysowania ramek oraz wiele innych. Widać od razu, że przy próbie konwersji Uniko-

8 8 Grzegorz GREY Ponikierski dowa strona kodowa jakaś inna strona kodowa nie tracimy informacji o znakach. Śmiało można więc stwierdzić, że za pomocą Unikodu możemy zastąpić wszystkie poprzednie strony kodowe jedna wspólną. To nie tylko ułatwi komunikacje między różnojęzycznymi użytkownikami ale nawet między użytkownikami mówiącymi w tym samym języku (przypomnij sobie co mówiliśmy o stronach kodowych np. w przypadku japońskiego). Nie zapominajmy też o użytkownikach wielojęzycznych. Zachwyceni też będą ludzie używający znaków specjalnych: naukowcy, inżynierowie, lingwiści etc. Kto odpowiada za Unikod? Strona techniczna i implementacja. Za Unikod odpowiedzialne są Unicode Consortium i ISO. Konsorcjum unikodowe, znane jako Unicode Consortium, jest niedochodową organizacją założoną by rozwijać i promować używanie Unikodu, określającą sposób reprezentacji tekstu w nowoczesnych programach i standardach. Członkowie konsorcjum reprezentują szerokie spektrum firm i organizacji mających do czynienia z informacyjnymi i informatycznymi systemami przetwarzania w przemyśle. Konsorcjum jest utrzymywane wyłącznie z opłat członkowskich. Członkostwo w Konsorcjum jest otwarte dla organizacji i osób prywatnych z całego świata, którzy wspierają Unikod i pragną pomagać w jego rozwijaniu i wdrażaniu. ISO w standarcie ISO definiuje tzw. UCS (Universal Character Set). Jest to tablica znaków w której każdy znak ma swój własny numer oraz opis. UCS może pomieścić Do 2000 zapełniono pierwsze znaków (czyli BMP - Basic Multilingual Plane), a do dzisiaj znaków. Numery kodów zgadzają się z ASCII i ISO Cały UCS jest podzielony na bloki takie jak Basic Latin, Latin-1 Supplement, Hiragana, Katakana etc. dzięki czemu znaki są uporządkowane w logicznie sposób i w łatwy do przeglądania. Oto parę przykładów z UCS: Kod Unikod Opis Znak U+0041 LATIN CAPITAL LETTER A U+03B1 GREEK SMALL LETTER ALPHA α U+3042 HIRAGANA LETTER A あ U+16A8 RUNIC LETTER ANSUZ A W każdej kolejnej wersji UCS dokładane są nowe znaki, a stare pozostaja na swoim miejscu. Dzięki czemu UCS jest zawsze zgodny wstecz. Unicode Consortium ze swojej strony wydaje standart Unicode. Unicode i UCS są zawsze ze sobą zgodne i są synchronizowane: Unicode 1.1 ISO/IEC :1993 Unicode 3.0 ISO/IEC :2000 Unicode 3.2 ISO/IEC :2001 Unicode 4.0 ISO/IEC :2003 Unicode w stosunku do ISO jest o wiele bardziej szczegółowy, zawiera więcej propozycji gotowych algorytmów i rozwiązań. Jednak sama tablica znaków nie wystarcza. Stworzono i zaproponowano następujące strony kodowe: UCS-2, UTF-7, UTF-8, UTF-16, UCS-4, UTF-32 (oraz parę różnych pododmian tych stron). My zajmiemy się UTF-8 jaka tą, która sprawia najmniej problemów z implementacją oraz jest najpowszechniej używana. UTF-8 powstał już w 1992 i został stworzony przez Ken a Thompson a (tego samego, który razem z Denis em Richie w 1969 napisali UNICS a) i Rob a Pike a. Był to projekt w ramach systemu operacyjnego Plan 9 - następcy UNIX a. Obecnie UTF-8 opisują następujące dokumenty: RFC 3629 / STD 63 (2003) The Unicode Standard, Version 4.0, (2003) ISO/IEC :2000 Annex D (2000) Jego zalety to: Każdy tekst w ASCII jest tekstem w UTF-8. Żaden znak spoza ASCII nie zawiera bajtu z ASCII. Zachowuje porządek sortowania UCS-4. Typowy tekst ISO-Latin-X rozrasta się w bardzo niewielkim stopniu po przekonwertowaniu do UTF-8. Nie zawiera bajtów 0xFF i 0xFE, więc łatwo można go odróżnić od tekstu UTF-16. O każdym bajcie wiadomo czy jest początkiem znaku, czy też leży w jego środku (co nie jest prawdą np. w kodowaniu EUC). Nie ma problemów z little endian vs. big endian. Wady to: Znaki CJK zajmują po 3 bajty zamiast 2. UTF-8 nie używa przesunięć zasięgów, co stanowi dodatkowe utrudnienie dla implementacji UTF-8 (szczegóły poniżej) Mapowanie znaków Unikodu na ciągi bajtów: Kod UCS 0x00-0x7F 0x80-0x7FF 0x800-0xFFFF 0x x1FFFFF UTF-8 0xxxxxxx 110xxxxx 10xxxxxx 1110xxxx 10xxxxxx 10xxxxxx 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

9 UNICODE 9 0x x3FFFFFF xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0x x7FFFFFFF x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx Przykłady: Literka A ma kod U+0041 == , mieści się w zakresie od 0x00 do 0x7F więc znak zajmie 1B: Wzór dla UTF-8 0xxxxxx Kod UCS UTF Niestety oznacza to, że ten sam znak można zapisać na kilka sposobów. Przykładowo znak ASCII / (ukośnik) można zapisać lub lub itd. Stanowi to zagrożenie bezpieczeństwa m.in. dla serwerów, które sprawdzają obecność znaku / w ścieżkach. Standard UTF-8 przewiduje, że każdy program MU- SI odrzucać wszystkie znaki zapisane sekwencjami dłuższymi niż minimalna. Problemu tego można by było uniknąć, przy okazji skracając nieznacznie długość danych, jeśli wykorzystano by zasadę przesunięć typu: sekwencje 1-bajtowe kodują 0x80 różnych znaków od 0x00 do 0x7F sekwencje 2-bajtowe kodują 0x800 różnych znaków od 0x80 do 0x87F sekwencje 3-bajtowe kodują 0x10000 różnych znaków od 0x880 do 0x1087F itd UTF-8 jest zaimplementowany w wszystkich głównych językach programowania: C/C++, Java, Perl, Python etc. Niestety nie potrafie wskazać jednego wspólnego sposobu programowania z użyciem UTF-8 dlatego każdy zainteresowany programista powinien zajrzeć do dostępnej dokumentacji swojego języka programowania by poczytać o kodach multibajtowym lub też o specjalnych modułach i bibliotekach obsługi UTF-8. The Unicode HOWTO Bruno Haible a w rozdziale 6-tym pokrótce opisuje jak w głównych językach programowania zacząć używać UTF-8. Gdzie już jest wykorzystywany Unikod? Wszystkie główne języki programowania obsługują Unikod Platformy POSIX owe i Windowsowe od dawna w obsługują Unikod w swoich API oraz w lokalizacjach (locale, pliki.mo, pliki konfiguracyjne KDE i GNOME). Standardy W3C, OASIS, ISO, IEEE, IETF wspierają i używają Unikodu najczęściej tam gdzie używany jest pod wszelaką postacią XML np. ODF, XMPP, XHTML etc. Nie ma problemów z dostępnością czcionek zawierających Unikodowe znaki (formaty TrueType i OpenType od lata wspierają Unikod) - chociażby takie podstawowe czcionki jak Fixed czy Arial zawierają odpowiednio uporządkowane znaki. Silniki wyświetlania tekstu obsługujące Unikod to np. - Pango (GTK+), Scribe (Qt), WorldScript (Apple), Apple Type Services for Unicode Imaging (Apple), Uniscribe (Windows). Systemy wprowadzania znaków dla środowisk graficznych i konsol tekstowych umożliwiają wprowadzania znaków Unikodowych tak samo jak umożliwiały nam to wcześniej. Jeśli ktoś chce może nawet ręcznie wprowadzać numery kodów. Nie brakuje edytorów tekstów obsługujących Unicode - nano, vim, kwrite, gedit, yudit, mined, emacs, joe, cooledit... Nie zapomnijmy o emulatorach konsol tekstowych - konsole, gnome-terminal, xterm, mlterm, uterm, kterm... Unikod na dobre zadomowił się w klientach pocztowych i grup dyskusyjnych - KMail, KNode, Thunderbird, mutt, slrn, sylpheed... To samo u przeglądarek WWW - Netscape, Mozilla, Firefox, Konqueror, Opera, Safari, MSIE, links... Bazy danych również nie odstają - PostgreSQL, MySQL, Adabas, FrontBase, Ingres, Microsoft SQL Server, Oracle, Sybase... Miedzynarodowe znaki w adresach URL to właśnie Unikod tak więc serwery WWW muszą go wspierać. Inne narzędzia z racji tego, że korzystają z innych bibliotek, które same w sobie korzystają z Unikodu powinny działać poprawnie z Unikodem. Mamy tu na myśli - glibc, Qt, GTK+, ncurses... Co jest jeszcze niegotowe i co sprawia problemy? Małe projekty początkujących programistów nie wspierają Unikodu z prostego powodu - jeszcze się tego nie nauczyli. Czasem nawet doświadczeni programiści nie przekonali się do Unikodu przez co ich projekty nie wspierają Unikodu. Można spotkać w sieci źle skonfigurowane serwery WWW i baz danych przez narzędzia z nich ko-

10 10 Grzegorz GREY Ponikierski rzystające źle wyświetlają znaki lub gubią o nich właściwa informacje. Brak wodotryskowych narzędzi do migracji na Unikod. Jak przemigrować na Unikod? Oto następujące kroki jakie musimy wykonać by by przemigrować nasz system na Unikod (oczywiście my będziemy korzystać z UTF-8): Ustawienie locale \$ export LANG=pl_PL.UTF-8 Zmiana ta będzie dotyczyć narzędzi uruchomionych w obecnej powłoce. Jeśli chcemy by zmiana miała charakter globalny wystarczy wy edytować skrypty startowe, pliki konfiguracyjne lokalizacji systemu czy konfiguracje powłoki systemowej. Jak widać jest wiele sposobów. Można skorzystać też z dystrybucyjnych narzędzi np. w Debianie będzie to dpkg-reconfigure locale. Opcje montowania systemów plików Najpierw w jądrze musimy mieć zapewnioną obsługę UTF-8 (wewnętrznie lub jako moduł): File systems->native Language Support-> NLS UTF-8 Możemy już w jądrze ustawić domyślne kodowanie znaków w systemach plików: File systems->native Language Support-> Default NLS Option (utf8) Dla osób lubiących testować można też pokombinować z opcjami FAT: File systems->dos/fat/nt Filesystems-> Default codepage for FAT File systems->dos/fat/nt Filesystems-> Default iocharset for FAT Jeśli nie ustawialiśmy wartości domyślnych w jądrze to w pliku fstab dopisujemy opcje utf8 dla każdego systemu plików, który nas interesuje: proc /proc proc defaults 0 0 /dev/hda1 / ext3 defaults,errors=remount-ro,utf8 0 1 /dev/hdc /media/dvd iso9660 ro,users,noauto,unhid,utf8 0 0 /dev/fd0 /media/floppy auto rw,users,noauto,unhide,utf8 0 0 /dev/sda1 /media/player vfat rw,users,noauto,utf8 0 0 Uniksowe systemy plików nie zachowują informacji o stronie kodowej dlatego jeśli używaliśmy jakiś specjalnych znaków w nazwach plików i katalogów (np. polskich ogonków) to będzie konieczna konwersja nazwa z starego kodowania na UTF-8. Można do tego celu skorzystać z narzędzia convmv ( Konwersja plików tekstowych Do konwersji stron kodowych plików tekstowych można wykorzystać takie narzędzia jak iconv, recode, uniconv czy piconv: $ iconv -f stare_kodowanie -t UTF-8 plik > plik.tmp && cat plik.tmp > plik && rm plik.tmp Oczywiście można napisać skrypt, który w pętli będzie konwertował całe katalogi lub nawet całe systemy plików. Instalacja czcionek z Unikodowymi znakami Najpewniej już masz zainstalowane odpowiednie czcionki w systemie. To tylko przypomnie dla osób, które nie mają ogóle polskich czcionek. 1. Przydatne zasoby Unicode Consortium Przykładowa lista narzędzi wspierających Unikod Unicode w Wikipedii (sama Wikipedia korzysta w całości z Unikodu) UTF-8 and Unicode FAQ for Unix/Linux unicode.html#apps Unicode HOWTO -HOWTO.html A Quick Primer On Unicode and Software Internationalization Under Linux and UNIX Introduction to Unicode Using Unicode in Linux mikosmul /computing/articles/linux-unicode.html Linux Unicode programming linux/library/l-linuni.html unifont.org - o Unikodowych czcionkach i nie tylko decodeunicode.org - tablice UCS z ciekawa dawką informacji o nich

11 Maciej Laskowski Google hacking 1. Wprowadzenie Google jest obecnie uważane przez gros Internautów [1] za najlepszą, najszybszą i najbardziej pewną wyszukiwarkę internetową. Specjalne oprogramowanie, znane jako Googleboty, stale przeczesuje Sieć zbierając informacje. Zasadniczo, Google zostało zaprojektowane tak, aby nawet najbardziej początkujący użytkownik Internetu mógł prosto, łatwo i szybko znaleźć to, czego szuka. Posiada bowiem wiele bardzo przydatnych dla zwykłych userów funkcji takich jak przeszukiwanie stron internetowych, grafik, grup dyskusyjnych czy katalogu, włączając w to również automatyczną konwersję dokumentów, ich tłumaczenie, etc. Jednak Google posiada także swoją ciemną stronę, która może zostać odpowiednio wykorzystana przez osoby o niezbyt dobrych zamiarach. Jak i dlaczego jest to możliwe? Aby odpowiedzieć na te pytania, na początek trzeba poznać metodę działania Googlebotów. 2. Jak działają Googleboty? Googlebot jest zdefiniowany jako robot firmy Google przeczesujący sieć, który analizuje znalezione dane celem zbudowania przeszukiwalnego indeksu dla wyszukiwarki Google [2]. Twórcy Google musieli opracować sposób umożliwiający szybkie, ale i poprawne indeksowanie stron. Do tej pory większość wyszukiwarek opierała się o dane, które zostały ręcznie wprowadzone do bazy. Minusy tego rozwiązania są oczywiste zawężało ono dosyć znacząco zakres wyszukiwania, gdyż większość webmasterów dodawała wpisy dotyczące swoich stron tylko do największych i najpopularniejszych serwisów wyszukujących. Aby uniknąć tego problemu wystarczyło podążyć za pomysłem filtrowania informacji przez samych internautów. Metoda ta opiera się na prostym rozumowaniu jeśli ktoś na swojej stronie zamieszcza link prowadzący na inną witrynę oznacza Instytut Informatyki, Politechnika Lubelska, ul. Nadbystrzycka 36b, Lublin to zazwyczaj, że uważa jej treść za interesującą i godną polecenia swoim odwiedzającym potencjalnie warto więc zindeksować taką stronę. Ten właśnie pomysł stał się fundamentem Google Googleboty przeczesują sieć w dwojaki sposób za pomocą tzw. fresh crawl, który odbywa się codziennie i służy do indeksowania nowych stron oraz main crawl (odbywającego się raz na miesiąc, zazwyczaj w okolicach 28. każdego miesiąca). Roboty podążają za każdym napotkanym linkiem (z wyjątkiem tych, do których ograniczono im dostęp za pomocą pliku robots.txt, meta tagu <meta name="googlebot" content="nofollow"> w sekcji <head> strony, bądź też poprzez użycie w przypadku pojedynczego linku tagu <a> z opcją rel, np.: <a href=" rel="nofollow">od tego linku wara!</a>). Jeśli więc dostęp do linku nie zostanie zablokowany w któryś z wyżej wymienionych sposobów, to zostanie od zindeksowany. Oznacza to, iż będzie on dostępny po zadaniu odpowiedniego zapytania do google.com. W zasadzie wszystko jest tak, jak być powinno ale łatwo można wyobrazić sobie sytuację, gdy w ten sposób można odnaleźć pliki konfiguracyjne, hasła czy prywatne dane. Jak się okazuje, nie jest to wcale takie trudne wystarczy tylko odrobina nieuwagi webmastera lub administratora serwera oraz odpowiednie zapytanie do wyszukiwarki. 3. Podstawowe techniki wyszukiwania w Google Aby przeprowadzić podstawowe wyszukiwanie za pomocą Google wystarczy wprowadzić poszukiwaną frazę w pole tekstowe na stronie głównej Google. Należy sobie zdawać jednak sprawę, że wpisując frazę jan kowalski, uzyskamy wyniki dotyczące stron nie tylko o panu Janie Kowalskim, ale także stron zawierających zarówno słowo jan, jak i kowalski (np. stron o Janie Nowaku i Stefanie Kowalskim). Google pomija jednak słowa, które uznaje za zbyt pospolicie występujące (np. the, a bądź an w języku angielskim). Za pomocą znaku + (np. +a

12 12 Maciej Laskowski +cat +in +the +hat) możemy obejść to ograniczenie. Dodatkowo, użycie tego znaku powoduje, iż wyszukiwane słowa muszą znajdować się w odległości maksymalnie 10 innych wyrazów od siebie. Analogicznie, używając znaku minusa, możemy wyeliminować z wyników wyszukiwania określone słowo. Aby wyszukać strony zawierające konkretną frazę, należy ująć ją pomiędzy apostrofy (np. jan kowalski ). Dodatkowo, Google umożliwia używanie znaków zastępczych kropka (.) zastępuje jeden znak, zaś gwiazdka (*) jedno słowo, a nie dowolny ciąg znaków.[3] Google akceptuje także zapytania oparte o logikę Boole a. Operator AND jest automatycznie wstawiany pomiędzy wszystkie elementy zapytania. Użycie operatora OR spowoduje uzyskanie wyników zawierających albo jedno albo drugie słowo. Operator NOT może zostać wykorzystany podobnie jak znak minusa ( ). 4. Zaawansowane techniki wyszukiwania Czas zapoznać się z nieco bardziej zaawansowanymi opcjami wyszukiwania. Google udostępnia swoim użytkownikom kilkanaście predefiniowanych operatorów. Najpopularniejszymi z nich są: site:, filetype:, link:, cache:, intitle: oraz url:. Należy jednak pamiętać o zachowaniu odpowiedniej składni podczas zadawania zapytań operator:wyszukiwana fraza. [3] Operator site: zawęża obszar przeszukiwania tylko do określonej domeny. Operator filetype: określa typ poszukiwanego pliku, np. pdf, należy przy tym zwrócić uwagę, aby nie poprzedzać rozszerzenia pliku kropką. Ciekawym operatorem jest link:, który zwraca nam strony zawierające linki do wyszukiwanej frazy (zazwyczaj jest to określona strona, bądź domena). Cache: wyświetla poszukiwaną stronę korzystając z wersji z cache Google. Istnieją jeszcze dwa interesujące operatory intitle: oraz inurl:. Pierwszy z nich zwraca strony zawierające poszukiwaną frazę w tytule, zaś drugi strony zawierające poszukiwaną frazę w adresie URL. Google dostarcza swoim użytkownikom także wiele innych operatorów, np. date:, safesearch: albo related:, lecz z punktu widzenia Google hackingu są one praktycznie bezużyteczne. 5. Wyszukiwanie prywatnych lub własnościowych danych za pomocą Google. Rysunek 1. Za pomocą opisanych wyżej operatorów oraz podstawowych technik wyszukiwania każdy internauta jest w stanie skonstruować odpowiednie zapytanie dające mu, na przykład, dostęp do prywatnych/poufnych danych bądź też umożliwiając wyszukanie słabych stron systemu. Ta technika jest szerzej znana jako Google hacking. Google hacking jest najczęściej wykorzystywane do uzyskania nieautoryzowanego dostępu do prywatnych bądź własnościowych danych. Na przykład, internauta w Lublinie chciałby wyszukać strony zawierające utwory Kayah. Szczególnie interesują go strony w domenie lublin.pl (potencjalnie znajdują się one na serwerach w miejskiej sieci, tak więc transfer danych powinien być dość szybki). Zapytanie o treści kayah mp3 inurl:lublin.pl zwraca trzy wyniki. Jeden z nich okazuje się być zwykłą tekstową stroną, ale dwa pozostałe wyniki są w pełni zindeksowanymi katalogami, zawierającymi kilka albumów Kayah w formacie mp3, w żaden sposób niezabezpieczonych. [rys.1] Nasz internauta może bez problemu ściągnąć je na swój komputer. Google hacking jest jednak wykorzystywane do znacznie poważniejszych rzeczy niż wyszukiwanie plików mp3 umieszczanych na stronach internetowych. Dla przykłady, wiele witryn zawiera skrypty do łatwego zarządzania treścią nie koniecznie pełen CMS, ale np. skrypty do zarządzania galerią czy też mechanizmem dodawanie newsów. Oczywiście zazwyczaj wymagają one identyfikacji za pomocą loginu i hasła. Zazwyczaj lista loginów i haseł użytkowników przechowywana jest w pliku konfiguracyjnym, na przykład config.php. Jeśli skrypt został napisany w sposób niechlujny, taki plik może zostać łatwo zindeksowany przez Googleboty. Ryzyko włamania do sys-

13 Google hacking 13 temu maleje w przypadku haseł przechowywanych w postaci zaszyfrowanej. Nie zmienia to jednak faktu, że umożliwienie dostępu do takich danych osobie nieupoważnionej jest nie do zaakceptowania. Załóżmy, że atakujący chciałby zdobyć dane z plików konfiguracyjnych konkretnego skryptu. Wie, że kluczowe dane przechowywane są otwartym tekstem w pliku config.php. Jeśli zapyta po prostu o inurl:config.php, uzyska ponad wyników, włączając w to dokumenty how-to, zawierające w swoim adresie frazę config.php, na przykład config-php-file.html (należy pamiętać, że kropka zastępuje dokładnie jeden znak). Odfiltrowanie wartościowych informacji zajęłoby stanowczo za dużo czasu. Warto więc zmodyfikować zapytanie zakładając, że plik znajdujący się w pełni zindeksowanym katalogu będzie nieco łatwiej dostępny, atakujący mógłby spróbować zapytania o następującej treści: intitle:"index of" "config.php". Zwracanych jest ok wyników. Część z nich jest oczywiście nieaktualna, ale pozostałe mogą okazać się całkiem obiecujące, co najlepiej ilustruje przykład: tsalarioth@luna ~$ cat config.php [...] $dbhost = localhost ; // database server $dbuser = michael ; // db username $dbpass = nimda ; // db password $dbname = datenator ; // db name [...] Zgodnie z informacjami zamieszczonymi w [4], niektóre fora posiadają luki, które nie tylko pozwalają atakującemu na przeczytanie config.php, ale także, na przykład, phpbb i kilka niższych wersji posiadały lukę umożliwiającą atakującemu na uruchomienie poleceń linuksowych na serwerze. Wszystko czego potrzebował atakujący to login i hasło, które były możliwe do uzyskania w sposób opisany powyżej. Niektórzy użytkownicy blokują dostęp do części swoich stron za pomocą plików.htpasswd. Ponieważ pliki te znajdują się po stronie serwera i zwykli internauci nie mają do nich dostępu, rozwiązanie to wydaje się być skuteczne. Jednak jak się okazuje, w niektórych przypadkach (zazwyczaj w przypadku wyjątkowo niestandardowych nazw) pliki te mogą zostać zindeksowane przez wyszukiwarki internetowe. Sytuacja ta chyba zdarza się na tyle często, że Google wprowadziło specjalny typ pliku htpasswd dla operatora filetype:. Dzięki temu jest możliwe skonstruowanie zapytania filetype:htpasswd htpasswd, które zwraca ponad 1500 rezultatów, oczywiście z loginami i zaszyfrowanymi hasłami, np.: dave:1eaziu9ytb.16 udel:f2jnn2gxs1cxi saic:grlfe/bakydyq coventor:.4f5pcuhek.n. arl:/wp29t4jxojee pitt:h.da7bcn8hcvs Innym sposobem na zdobycie dostępu do danych z pliku.htpasswd jest zapytanie w postaci intitle:"index of" ".htpasswd" "htgroup" -intitle: "dist" -apache -htpasswd.c. Zwraca ono jednak znacząco mniej wyników (ok. 60), dosyć często zakończonych błędem 403 (dostęp zabroniony). Jak łatwo więc zauważyć, metoda ta jest znacznie mniej skuteczna od poprzedniej. Często wykorzystywanym sposobem na uzyskanie dostępu do danych prywatnych jest wyszukiwanie plików password.log. Być może wynika to z faktu, że hasła w takich plikach zapisane są czystym tekstem. Zapytanie filetype:log inurl: password.log zwraca ponad 600 wyników. Typowy plik password.log zawiera trzy informacje login, hasło oraz URL strony do zalogowania się, na przykład: name: = "test"; password: = "test"; URL: = "passdemo1.html"; Atakujący może w bardzo łatwy sposób uzyskać nieautoryzowany dostęp do strony internetowej. Google może też znacząco ułatwić kradzież tożsamości internauty. Aby to zrobić, należy odwołać się do socjotechniki. Wiele osób pisząc CV podaje tam wiele bardzo prywatnych danych (począwszy od pełnych danych teleadresowych, poprzez numery PESEL (w Polsce) czy numer ubezpieczenia społecznego (Social Security Number) w USA, numer karty kredytowej czy konta bankowego). Większość z tych danych spokojnie wystarczy do zrobienia zakupów w sklepie internetowym czy do dokonania operacji w banku internetowym w niektórych krajach. Do uzyskania tak prywatnych informacji wystarczy zapytanie w postaci: phone * * * address * intitle: curriculum vitae (prawie wyników), bądź też w formie nieco bardziej sprecyzowanej - social security number phone * * * address * * intitle: curriculum vitae, które zwraca tylko około 150 wyników. Jak więc widać, uzyskanie wartościowych danych osobowych może zająć atakującemu kilka minut.

14 14 Maciej Laskowski Google można użyć także do szybkiej budowy spamlisty. Niektóre osoby eksportują swoje książki adresowe do formatu.csv i umieszczają w formie pliku dostępnego z Internetu. Wystarczy więc, aby atakujący wyszukał address filetype:csv csv ponad 600 wyników równa się tysiącom adresów , a często także innym informacjom teleadresowym. Dzisiejszy świat biznesu również opiera się na informacji, do ochrony której powinno się przywiązywać szczególną rolę. Jak się jednak okazuje, dla niektórych oznacza to po prostu napisanie w nagłówku dokumentu ściśle tajne. Zapytanie o treści not for distribution confidential zwraca ponad dokumentów. Teraz potencjalny atakujący, zawężając odpowiednio wyniki wyszukiwań jest w stanie uzyskać interesujące informacje. Rysunek 2. Google hackerzy udowodnili także, że bez większego kłopotu można uzyskać dostęp do kluczy aktywacyjnych do różnego typu oprogramowania komercyjnego. W niektórych przypadkach udostępnienie cd-keys na stronie internetowej było działaniem zamierzonym, lecz nie należy zapominać, że takie dane ciągle powinny być rozpatrywane w kategoriach prywatnej własności. Poszukiwanie nieokreślonego klucza za pomocą allinurl:cdkey.txt zwraca ponad 300 wyników. Oczywiście podając nazwę programu znacznie zawęzimy listę rezultatów. Ciekawostką jest, że nawet jeśli zindeksowane strony zostały już usunięte z sieci, to w większości przypadków wszystkie potrzebne informacje zostaną wyświetlone w oknie wyników wyszukiwania, co zostało zilustrowane na rysunku Znajdowanie słabych stron systemu komputerowego za pomocą Google. Google hacking oznacza także możliwość znajdowania słabych stron serwerów www. Najpopularniejszą metodą jest ustalenie dokładnej wersji oprogramowania obsługującego serwer www jest to informacja, która jest wręcz wymagana do przeprowadzenia skutecznego ataku. Oczywiście łącząc się bezpośrednio z potencjalnym celem agresor może pozyskać te dane z nagłówków HTTP. Ale połączenie takie może zostać zalogowane, a w związku z tym administratorzy serwisu mogą mieć dodatkową możliwość namierzenia źródła ataku (choć wydaje się to mało prawdopodobne). Możliwe jest jednak uzyskanie takich informacji z cache Google bez konieczności łączenia się z potencjalnym celem.[3] Wystarczy, aby atakujący przeprowadził wyszukiwanie w postaci intitle:index.of server.at. Oczywiście niektórzy administratorzy mogą zafałszować tą informację, bądź też (posługując się polityką security by obscurity) ukryć ją. Jednak w większości przypadków agresor uzyska dostęp do prawdziwej wersji serwera. Dodatkowo, może bez problemu zawęzić wyniki wyszukiwania do konkretnej domeny dzięki zapytaniu intitle:index.of server.at site:domena docelowa. Systemy CMS w różnej postaci są dosyć popularne pośród zwyczajnych użytkowników Internetu. Jednak część z nich używa tego typu rozwiązań bez prawidłowego ich zabezpieczenia na przykład zostawiając dostęp do bazy MySQL na prawach roota bez hasła. Zapytanie intitle:phpmyadmin Welcome to phpmyadmin *** running on * as root@* zwraca prawie 7000 wyników, gros których jest ciągle aktywna, Rysunki 3 i 4 pokazują nieautoryzowany dostęp do struktury bazy danych. Rysunek 3. Ekran powitalny niezabezpieczonego phpmy- Admin Jeśli zostanie wykryta nowa luka w oprogramowaniu serwera www, atakujący stosując opisane wyżej metody może w szybki sposób odnaleźć potencjalną ofiarę, zanim zdąży się ona zabezpieczyć. Dodatkowo, agresor może użyć wyszukiwania charakterystycznych ciągów znaków bądź nazw plików do

15 Google hacking 15 Rysunek 4. Ekran powitalny niezabezpieczonego phpmy- Admin Niektóre zapytania do Google mogą pomóc atakującemu znaleźć słabe luki w systemie ofiary, nie tylko za pomocą wykrycia wersji używanego oprogramowania, ale także dzięki znajdowaniu bugów lub backdoorów w kodzie źródłowym strony. Jedna z najbardziej popularnych metod nazywana jest CSS (Cross Site Scripting). Wraz ze wzrastającą popularnością tematu rośnie również świadomość webmasterów, a liczba sposobów ataku maleje. określenia wersji i rodzaju używanego oprogramowania. 7. Podstawowe sposoby ochrony. Po pierwsze, nikt nie powinien umieszczać ważnych danych w sieci, nawet tymczasowo, nie zabezpieczając ich uprzednio za pomocą pliku.htaccess. Po drugie, dostęp Googlebotów do kluczowych plików i danych, które muszą znaleźć się w Internecie powinien być ograniczony albo za pomocą robots.txt, tagu meta <meta name="googlebot" content="nofollow"> w sekcji <head> strony, bądź też, w przypadku pojedynczego linku za pomocą znacznika <a> z opcją rel= nofollow. Plik robots.txt jest uznawany za standard i, co jest godne uwagi, respektują go także inne duże wyszukiwarki internetowe. Webmasterzy powinni też przeskanować swoje witryny pod względem opisanych powyżej luk. Inną, wartą rozważenia metodą obrony jest oczyszczenie kodu źródłowego strony ze wszelkich niepotrzebnych linków i dodanie do każdego katalogu przynajmniej czystego pliku index.html. Ostateczną, niepolecaną metodą obrony jest usunięcie swojej witryny z indeksu Google. Literatura [1] Michał Piotrowski, Niebezpieczne Google wyszukiwanie poufnych informacji, hakin9 3/2005 [2] [3] Johnny Long, Google hacking mini-guide, p=170880&rl=1 [4] prodreviews&func=showcontent&id=27 8. Podsumowanie Google hacking jest uważany za średnie zagrożenie dla doświadczonego webmastera i administratora serwisu internetowego. Ale jak pokazują zaprezentowane powyżej przykłady, w Internecie spotkać można jeszcze ciągle zbyt wiele osób, które nie są świadome potencjalnego zagrożenia. Wartość informacji uzyskanych za pomocą Google hackingu jest różna, ale jak zostało dowiedzione, w kilka minut atakujący jest w stanie uzyskać dostęp do prywatnych bądź też poufnych danych.

16 Marek tezar Magryś Wi-Fi Hacking Sieci bezprzewodowe są dzisiaj jednym z najbardziej popularnych sposobów budowy domowych i firmowych sieci LAN. Coraz częściej spotykane są również jako elementy infrastruktury sieci miejskich. Warto więc zadać sobie pytanie czy dane, które są przesyłane za ich pośrednictwem są naprawdę bezpieczne? Odpowiedź na to pytanie jest dość prosta zwykle nie. Postaram się to udowodnić w czasie trwania wykładu. Już od początków istnienia sieci bezprzewodowych (czyli od roku 1997) inżynierowie zdawali sobie sprawę z tego, że przesyłanie danych w powietrzu może dość boleśnie odbić się na bezpieczeństwie. Każdy mógł podsłuchać dane, które krążyły w ogólnodostępnym eterze. Postanowiono opracować jakiś standard zabezpieczeń, który miałby na celu zapewnienie przyzwoitego poziomu zaufania do tych, jakże zresztą wygodnych, sieci bez kabelków. Tak w 1999 roku narodził się WEP (Wired Equivalent Privacy). Nazwa sugeruje, że używanie WEP zapewnia takie samo bezpieczeństwo jak sieci klasyczne (wired). Niestety dość szybko okazało się, że tak wcale nie jest. Już w czasie projektowania WEP popełniono szereg błędów. Jak widać na załączonym obrazku klucz WEP składa się z wektora inicjalizacyjnego o długości 24 bitów oraz 40 lub 104 bitowego klucza. Wektor inicjalizacyjny jest dodatkowo przesyłany w postaci jawnej, co z teoretycznego szyfrowania 64 lub 128 bitowego daje nam de facto 40 lub 104 bitów. Oprócz WEP został oparty na algorytmie RC4, który już w 1995r został uznany za potencjalnie słaby. W 2000 roku pojawiła się pierwsza publikacja opisująca podatność WEP na atak. W 2001 roku pojawiła się cała seria publikacji na ten temat, co zaowocowało stworzeniem w sierpniu tego roku najpopularniejszego narzędzia do łamania zabezpieczeń WEP AirSnorta. AirSnort implementuje atak FMS i umożliwia złamanie klucza po złowieniu kilku milionów (!) pakietów. Nawet w dużej sieci zajmuje to dość dużo czasu. Dlatego sposoby walki z WEP ewoluowały, pojawiły się metody opracowane przez h1kariego oraz KoreKa. Drastycznie zmniejszyły one liczbę koniecznych pakietów (do kilkuset tysięcy), co doprowadziło do powstania narzędzia AirCrack w 2004 roku. Do dzisiaj ta aplikacja (a w zasadzie rodzina aplikacji) jest najskuteczniejszym sposobem na złamanie klucza WEP. Dostarczane są z nią cztery programy: aircrack, airodump, aireplay oraz skrypt airmon.sh, a manual dostarcza obfitych informacji na temat ich użycia. Jak widać WEP nie zapewniał nawet częściowo poziomu bezpieczeństwa sieci klasycznych. Dlatego w 2001 powołano komitet IEEE i mający na celu zaprojektowanie nowego systemu mającego zapewnić bezpieczeństwo w sieciach z rodziny Zaowocowało to stworzeniem WPA oraz WPA2 (Wi-Fi Protected Access). WPA (występujący w kilku odmianach, najczęściej spotykany jako WPA-PSK) używa 128 bitowego szyfrowania RC4, ale ze znacznymi usprawnieniami w stosunku do WEP. W WPA IV jest aż 48 bitowy, co zapobiega możliwości powtórzenia się tego wektora. Oprócz tego zastosowano mechanizm TKIP (Temporal Key Integrity Protocol), który dynamicznie zmienia klucze w czasie transmisji. Dodano także algorytm MIC (Message Integrity Code) oparty na algorytmie Michael, który zawiera m.in. licznik pakietów, co eliminuje możliwość ponownego wstrzykiwania pakietów (w WPA do kontroli integralności używano CRC). Klasyczny WPA-PSK jest bezpieczny, o ile PSK, którym się posługuje jest wystarczająco długi (zwykle powyżej 20 znaków), a to dlatego, że jedynym znanym dotychczas atakiem na ten mechanizm jest metoda siłowa (losowa, bądź oparta na słowniku). Tak więc użycie stosunkowo długiego, niesłownikowego hasła daje nam praktycznie pewność, że nasze dane nie zostaną przechwycone. Jak wspomniałem wcześniej, IEEE opracowało również mechanizm WPA2, który zapewnia niemal stuprocentowe (na dzień dzisiejszy) bezpieczeństwo. Jego działanie jest zbliżone do WPA, jednak zamiast

17 Wi-Fi Hacking 17 RC4 użyto AES, a zamiast Micheala CCIP, który praktycznie całkowicie eliminuje możliwość ataku. W tej chwili każde nowe urządzenie, które chce być zgodnie z Wi-Fi musi obsługiwać WPA2. To tyle suchej historii. Oprócz wymienionych do tej pory metod istnieją także inne sposoby na zapewnienie naszym sieciom poufności, oraz chroniące je przed włamaniami. Takim sposobem jest np. bardzo prosty i stosunkowo popularny system portalowy NoCatAuth (oparty o autoryzację przez WWW). Wydaje się Wam, że jakaś podatność na atak została pominięta? Racja. Otóż, jak powszechnie wiadomo, sieci bezprzewodowe charakteryzują się przede wszystkim tym, że są... bezprzewodowe. No właśnie. Więc jaką mamy pewność, że to co podaje się za naszego Access Pointa naprawdę nim jest? Wi-Fi jak żaden inny sposób przesyłu danych pozwala na całkowitą dowolność w działaniu hackerów korzystających z metody Man-In-The-Middle. Fałszywe Access Pointy pozwalają im przechwytywać nasz ruch w postaci jawnej. Mogą podszyć się pod dowolną stronę WWW, dowolny serwer SSH, gdyż w całości kontrolują nasz ruch. Dokładnie metody ataków MITM zostaną opisane w czasie mojej prezentacji. Podsumowując, sieci bezprzewodowe wcale nie są tak bezpieczne jak się to może wydawać. Włamanie się do większości z nich trwa maksymalnie kilka godzin, co dla spragnionego poufnych pakietów lub anonimowego dostępu do Sieci hackera wcale nie jest dużo... Kilka projektów zaprezentowanych w ostatnich latach (WPA2, idea Stealth Network ) zapowiada, że już niedługo uda się w pełni zabezpieczyć nasze sieci radiowe przed niepowołanymi osobami. Miejmy jednak nadzieję, że nie stanie się to zbyt szybko ;)

18 Marcin Kuczera Zastosowanie protokołów routingu dynamicznego w sieciach komputerowych z dostępem do Internetu. W dzisiejszych czasach, tak popularne niegdyś sieci osiedlowe jeżeli nie urosły do odpowiednich rozmiarów, to albo padają albo też integrują się z innymi sieciami tworząc spore struktury sieciowe. Przy odpowiednich rozmiarach, w takiej sieci jest najczęściej od kilku do kilkunastu routerów. Także ze względu na jakość i konkurencję jedno łącze do Internetu to za mało, tak więc pojawiają się dodatkowe styki z różnymi dostawcami sygnału. Rysunek 1. czyli do zastosowań wewnątrz Systemu Autonomicznego (AS) sieci zarządzanej przez jedną organizację lub firmę. Protokół ten ma na celu rozgłoszenie pomiędzy routerami należącymi do danego ASa wszystkich informacji o dostępnych sieciach. Przykład na rysunku 1. Rysunek 2. SIEĆ A Router A SIEĆ A Link 2 m=20 Router A Router B SIEĆ B Link 1 m=10 Router B SIEĆ B Gdy nasza sieć jest podzielona na wiele segmentów, a one podłączone do różnych routerów kwestia komunikacji pomiędzy poszczególnymi segmentami sieci zaczyna się komplikować. Tablice routingu zaczynają być coraz większe, a ilość wpisów o których musimy pamiętać na każdym routerze robi się spora. Do tego jeżeli zapragniemy posiadać łącza zapasowe pomiędzy poszczególnymi routerami, zwykła metoda routingu statycznego przestaje wystarczać. Oczywiście można to wszystko załatwić za pomocą tony skryptów monitorujących poszczególne łącza i przełączających ruch w razie awarii jednego z nich. Tyle, że praktycznie od zawsze istnieją stworzone w tym celu odpowiednie protokoły oraz narzędzia które warto wykorzystać. Jedynym z protokołów tzw. routingu dynamicznego jest OSPF (Open Shortest Path First). Należy on do grupy protokołów IGP (Interior Gateway Protocol) Aby możliwa była komunikacja pomiędzy komputerami znajdującymi się w sieci A oraz B, routera musi zawierać w swojej tablicy routingu wpis mówiący o tym w jaki sposób dostać się do sieci B. Można się tam dostać oczywiście poprzez routerb. Tyle że zamiast wpisywać tę informację z palca, routerb może poinformować automatycznie routera o sieci B. Tak samo w 2gą stronę. W ten sposób automatem załatwiamy komunikację międzysieciową. Także w przypadku istnienia łączy zapasowych będą one wykorzystane w przypadku awarii łącza podstawowego. Przykład na rysunku 2. Jeżeli chcemy aby routery mogły wykorzystać łącze link2 w przypadku awarii łącza link1, na obu łączach musi być odpalony protokół routingu

19 Zastosowanie protokołów routingu dynamicznego 19 dynamicznego, w naszym przypadku OSPF. Jednak w tym momencie pojawia się pojęcie metryki. Jest to parametr określający wagę/priorytet dla danego łącza. Im większa metryka, tym mniejszy priorytet. Tak więc jeżeli link1 będzie posiadał metrykę 10 a link2 metrykę 20, wtedy link1 będzie wykorzystywany jako łącze podstawowe, a link2 jako łącze zapasowe. SIEĆ A m=6 m=5 Rysunek 3. Link 1 Router A Link 2 m=6 m=5 Router B SIEĆ B Metryka w OSPFie jest wyjątkowo istotna. Składają się na nią takie parametry jak np.: przepustowość lub cena. Jest ona także wartością jednostronną, tak więc metrykę ustawia się po obu stronach łącza. Tę przypadłość możemy wykorzystać w przypadku posiadania podwójnego łącza radiowego. Przykład na rysunku 3. Najbardziej popularne łącza radiowe na 5.7GHz są tzw. łączami half-duplexowymi. Tak więc albo nadajemy, albo odbieramy. Powoduje to podział dostępnej przepustowości na kierunek up i down. Pełną przepustowość możemy osiągnąć jedynie transmitując dane w jedynym kierunku. W ten sposób zmniejszamy również straty związane z kolizjami. W przypadku podanym na rysunku, mamy do dyspozycji 2 takie łącza half-duplexowe. Ponieważ metryki na łączach ustawione są asymetrycznie, pakiety z sieci A do sieci B polecą radiolinią1 a z sieci B do sieci A radiolinią2. W ten sposób nasze zasoby są wykorzystane w najbardziej optymalny sposób. Dodatkowo w przypadku awarii jednej z radiolinii, ruch w obie strony będzie przebiegał poprzez pozostały działający link. Powyższe przykładem to jedynie zarys części tego, co można zrobić z wykorzystaniem protokołu OSPF. Drugi z protokołów, BGP (Border Gateway Protocol) należy do grupy EGP (Exterior Gateway Protocol). Służy on do wymiany informacji pomiędzy Systemami Autonomicznymi (AS), czyli zasadniczo pomiędzy sieciami zarządzanymi przez inne firmy. Przykładem systemu autonomicznego może być sieć Netii, TPSA lub np. Pionier czy Telia. Weźmy na ten przykład sieć firmy którą reprezentuje z numerem systemu autonomicznego AS Jest ona podłączona do sieci Politechniki Śląskiej (Silweb) AS15744 oraz TPSA AS5617. Dodatkowo ma ona połączenie z operatorami podłączonymi do węzłów wymiany ruchu WIX/PL-IX. Numery AS mają kluczowe znaczenie dla routingu opartego o protokół BGP, ponieważ tworzą tzw. ścieżkę systemów autonomicznych jakie należy przebyć aby dotrzeć do docelowego systemu autonomicznego. Dajmy na to jak widzą nas z Telii: AS13293 sieć tranzytowa Pionier AS15744 Silweb AS13000 LEON Sumarycznie 3 przeskoki, 3 sieci przez które musi przejść pakiet aby dotrzeć do sieci docelowej. Warto w tym momencie zauważyć, iż ilość routerów wskazanych przez np. traceroute ma się nijak do długości tejże ścieżki. Dla BGP znaczenie ma ilość systemów autonomicznych, a nie ilość routerów. ICM AS8664 SILWEB AS15744 Rysunek 4. LEON AS13000 Internet ATMAN AS24748 TPNET AS5617 Wracając do naszego przykładu (rysunek 4) - AS13000 informuje swoich sąsiadów (AS5617, AS15744) jak i kilku innych o adresach IP znajdujących się wewnątrz AS Następnie AS5617 i AS15744 informują o tym co się dowiedzieli od

20 20 Marcin Kuczera AS13000 innych swoich sąsiadów i w ten sposób informacja rozprzestrzenia się po całym świecie. Tak więc każdy router BGP na świecie powinien znać przynajmniej jedną ścieżkę do adresów IP rozgłaszanych przez AS Co nam to daje? Otóż w przypadku awarii łącza pomiędzy AS13000 i AS5617, cały ruch będzie kierowany poprzez AS15744 przez co zapewniona jest ciągłość działania sieci. Oczywiście protokół BGP posiada znacznie więcej możliwości, dodatkowe sterowanie ruchem, filtrowanie dostępu do pewnych ASów dla innych ASów (tzw. peering/tranzyt) jest to jeden z najważniejszych elementów składowych dzisiejszego Internetu. A w jaki sposób możemy uruchomić protokoły routingu dynamicznego w naszej sieci? Dla Linuksa proponuje zapoznać się z pakietem quagga ( który zawiera zarówno OSPF jak i BGP. Nie jest on idealnym oprogramowaniem, nie mniej jednak daje się całkiem sensownie wykorzystać z bardzo pozytywnymi rezultatami. Wdrożenie OSPFa powinno być dość proste przy podpieraniu się dokumentacją i grupami dyskusyjnymi, jednak w przypadku BGP polecam rozpocząć od grup dyskusyjnych. Można również pytać mnie: marcin@leon.pl Życzę wielu godzin dodatkowego świętego spokoju po wprowadzeniu rozwiązań automatycznego regulowania ruchem w sieci w przypadku niestety występujących awarii.

21 Dariusz Grzesista Bezpieka w strukturach poczty Streszczenie Artykuł ten przybliża techniki filtrowania używane w antyspamowym czytniku poczty, stworzonym na WWW w ramach ćwiczeń w języku Arc. Ulepszony algorytm opisano w artykule pt. Better Bayesian Filtering ( Od tłumacza: Przykłady filtrowania spamu oraz inne ciekawe dodatki dostępne są na stronie oryginału: Uzupełnieniem tekstu jest prezentacja, która wraz z przykładami konfiguracji Bogofiltra programu OpenSource autorstwa Erica S. Raymonda, zainspirowanego niniejszym tekstem miała premierę na Jesieni Linuksowej 2006 i na stałe znajduje się pod adresem: ftp://ftp.dgnet.pl/pub/linux/. Sposób na spam Paul Graham, sierpień 2002 tłumaczenie: Dariusz Grzesista, sierpień 2006 Powstrzymanie spamu jest jak najbardziej możliwe! Jedynym skutecznym sposobem na wykonanie tego zadania są filtry treści. Spam potrafi przechytrzyć każdą ustawioną przed nim barierę, jedyną jego piętą achillesową pozostaje treść. Spammerowi zawsze najbardziej zależy na dostarczeniu wiadomości, czymkolwiek by ona nie była. Jeśli stworzymy program, który będzie rozpoznawał treść, spammer nigdy nie obejdzie takiego zabezpieczenia. Dla odbiorcy spam jest stosunkowo łatwy do rozpoznania. Gdybyśmy zatrudnili Krystynę z Gazowni do czytania poczty i odrzucania spamu, poradziłaby sobie łatwo, choć miałaby naprawdę sporo pracy. Skoro tak, to czy nie dałoby się zautomatyzować tego procesu? Okazuje się, że problem można rozwiązać przy pomocy naprawdę prostych algorytmów. Co więcej - codzienny spam da się naprawdę nieźle filtrować, używając do tego celu tylko i wyłącznie metody Bayesa, która przyporządkowuje wagi prawdopodobieństwa każdemu ze słów. Metoda Bayesa pozwala na filtrowanie, za pomocą którego przepuścimy mniej niż 5 przesyłek spamowych na 1000, przy 0 false-positive ach! False-positive to przesyłki, które błędnie zostały sklasyfikowane jako spam. Analiza statystyczna nie była pierwszym sposobem walki ze spamem. Wielu hackerów najpierw próbowało stworzyć oprogramowanie do rozpoznawania indywidualnych cech spamu. Prawda, że gdy spojrzysz na spam, wkurzasz się, kiedy ktoś bezczelnie śle maila rozpoczynającego się od Dear Friend, albo z tytułem pisanym wielkimi literami, z ośmioma wykrzyknikami na końcu? Nie wiem jak Ty, ale ja takie przypadki odsiewam jednym wyrażeniem regularnym. Dobra. Siadamy, piszemy, uruchamiamy. Kilka prostych reguł wycina sporą część napływającego spamu. Dla przykładu: samo wyszukanie słowa click wyłapie 79, 7% i w całej grupie spamu, pozostawiając jedynie 1, 2% false-positive ów. Zanim przekonałem się do metody statystycznej, straciłem jakieś sześć miesięcy na napisanie oprogramowania, które klasyfikowało spam według jego cech indywidualnych. Za każdym razem dochodziłem do tego, że pozostawała ostatnia, niewielka część spamu, bardzo trudna do odfiltrowania, dla której dalsze uściślanie warunków, zamiast lepszego odsiewania, dawało tylko zwiększenie ilości false-positive ów. Dla większości użytkowników utrata dobrego a jest o wiele gorsza niż wpuszczenie spamu, dlatego filtr produkujący false-positive y jest jak leczenie trądzika, powodujące zejście pacjenta na tamten świat. Im więcej spamu otrzyma użytkownik, tym mniejsza szansa, że dostrzeże on jednego false-positive a w katalogu spamu. Co gorsza, false-positive y są tym niebezpieczniejsze, im lepszy jest filtr! Dlaczego? Dlatego, że jeśli filtr jest naprawdę dobry, użytkownik ma tendencję do całkowitego zignorowania wszystkiego, co złapie się w jego sidła.

22 22 Dariusz Grzesista Nie pytajcie mnie, czemu tak długo olewałem metodę statystyczną. Być może dlatego, że wpadłem w jakiś irracjonalną manię identyfikowania spamu, jakbym grał ze spammerami w jakiś obłędny konkurs! (Zwykli użytkownicy często sobie nie uświadamiają, jak ambitni potrafią być spammerzy.) Kiedy wreszcie przegryzłem sie przez tajniki metody statystycznej, nie mogłem pojąć, dlaczego wcześniej straciłem tyle pary na coś znacznie gorszego. Odkryłem na przykład, że wyrażenia w stylu: virtumondo czy teens są bardzo dobrymi wskaźnikami spamu. Są nimi również per, FL i ff0000. Tak tak, ff0000 (czyli kolor czerwony w HTML) okazuje się świetnym wyróżnikiem większości przesyłek pornograficzynch! Ok, wróćmy do tematu. Przedstawię teraz z grubsza, jak robię filtrowanie statystyczne. Biorę dwa pliki: jeden z czystym spamem i drugi całkowicie go pozbawiony. Każdy z nich zawiera po 4000 wiadomości. Skanuję treść tych wiadomości łącznie z nagłówkami, HTML-em i Javascriptem. Biorę pod uwagę znaki alfanumeryczne, dashe, apostrofy i znaki dolara (ale tylko te oznaczające walutę), a także wszystkie symbole rozdzielające. Ignoruję natomiast wszystkie cyfry nie będące ceną (czyli bez znaków waluty) i komentarze HTML, bo ich znaczenie jest znikome. Zliczam ilość wystąpień każego wyrazu w każdym ze zbiorów, bez rozróżniania wielkości liter. Otrzymuję dwie duże tablice haszujące, po jednej dla każdego zbioru przesyłek. Tablice te przypisują poszczególnym wyrazom liczbę ich wystąpień. Następnie tworzę trzecią tablicę, w której każdy wyraz ma specjalny współczynnik określąjący prawdopodobieństwo, że zawierający go jest spamem. Współczynnik ten obliczam następująco 1 : (let ((g (* 2 (or (gethash word good) 0))) (b (or (gethash word bad) 0))) (unless (< (+ g b) 5) (max.01 (min.99 (float (/ (min 1 (/ b nbad)) (+ (min 1 (/ g ngood)) (min 1 (/ b nbad))))))))) gdzie word jest wyrazem, dla którego obliczamy prawdopodobieństwo, good i bad są tablicami haszującymi utworzonymi w pierwszym kroku, a ngood oraz nbad są odpowiednio liczbami spamu i nie-spamu, w których stwierdzono występowanie wyrazu word. 1 Przykłady w tym artykule przetłumaczone zostały na język Common Lisp w celu polepszenia czytelności. Aplikacja tu przytoczona pochodzi ze zbioru, który napisałem podczas testów nowego, jeszcze nie opublikowanego dialektu tego języka: Arc ( Zatrzymajmy się na moment i zwróćmy uwagę na kilka szczegółów. Chcąc polepszyć trafność rachunku prawdopodobieństwa, wykluczaąc przy okazji false-positive y, stwierdziłem (metodą prób i błędów), że wystarczy w tablicy wyrazów dobrych pomnożyć wszystkie liczby przez dwa. Pomaga to odróżnić słowa, które przypadkowo znajdą się w dobrych ach od tych, które nigdy w nich nie wystąpiły. Biorę pod uwagę tylko te, które występują w sumie więcej niż pięć razy (w istocie, po podwojeniu wystarczy ich trzykrotna obecność w nie-spamie). Teraz pytanie: jakie prawdopodobieństwo przypisać słowom, które występują w jednym zbiorze, ale nie ma ich w drugim? Tutaj (znów metodą prób i błędów) wyznaczyłem współczynnik 0,01 oraz 0,99. Możnaby spróbować dobrać lepsze wartości, ale ponieważ w praktyce zbiór maili zawsze przyrasta, tuning będzie przebiegał samoistnie. Uważny obserwator zauważy pewnie, że jeśli każdy zbiór potraktujemy jako jeden długi strumień tekstu, to jako dzielnika do obliczania prawdopodobieństwa spamu trzeba będzie użyć ilości i, a nie ich łącznej długości. Zabezpieczymy się w ten sposób przed występowaniem false-positive ów. Kiedy przychodzi nowa przesyłka, jest ona skanowana pod kątem występujących słów. Filtr wyznacza piętnaście najbardziej interesujących, gdzie zainteresowanie określa, na ile ich prawdopodobieństwo różni się od neutralnego poziomu 0,5. W praktyce to one są użyte do oceny, czy przesyłka jest spamem, czy nie. Jeśli przyjmiemy, że zmienna probs to lista piętnastu indywidualnych prawdopodobieństw, łączne prawdopodobieństwo ocenimy tak: (let ((prod (apply # * probs))) (/ prod (+ prod (apply # * (mapcar # (lambda (x) (- 1 x)) probs))))) Pytanie praktyczne: jaki stopień prawdopodobieństwa przypisać słowu, które nigdy wcześniej nie wystąpiło? Jakie prawdopodobieństwo przypisać słowu, którego nie mamy w żadnej tablicy haszującej? Z pomocą znów przychodzi metoda prób i błędów. Okazuje się, że najlepszą wartością będzie 0,4. Dlaczego? Ano, jeśli nigdy wcześniej słowa nie widzieliśmy, to będzie ono z dość dużym prawdopodobieństwem być niewinne, bo hasła spamowe mają tendencję do bycia znanymi wszem i wobec. Reasumując: przesyłkę potraktuję jako ewidentny spam, jeśli podany wyżej algorytm zwróci współ-

23 Bezpieka w strukturach poczty 23 czynnik prawdopodobieństwa wyższy niż 0,9. Próg ten ma w sumie niewielkie znaczenie, gdyż niewiele wyników plasuje się pośrodku pasma. Największą bodaj zaletą podejścia statystycznego jest to, że nie musimy czytać ogromnych ilości spamu. W ciągu ostatnich sześciu miesięcy przejrzałem tony takich przesyłek i mogę powiedzieć, że jest to czynność bardzo deprawująca. Norbert Wiener powiedział, że kto rywalizuje z niewolnikami, sam staje się niewolnikiem. Podobnie ja, rywalizując ze spammerami, musiałem zniżyć się do ich poziomu. Aby rozpoznać indywidualne cechy spamu, trzeba dostać się do umysłu spammera. Szczerze? Wolę być w nim tak krótko, jak tylko to możliwe! Prawdziwą zaletą podejścia bayesowskiego jest oczywiście to, że wiemy co mierzymy. Filtry cech, takie jak np. SpamAssasin (obecnie SpamAssasin ma wbudowane filtry Bayesa, jednak w chwili pisania tego artykułu jeszcze nie miał przyp. tłum.), przypisują om tzw. wynik (ang. score) spamowy, w przeciwieństwie do algorytmu Bayesa, który oblicza rzeczywiste prawdopodobieństwo. Problem wyniku spamowego polega na tym, że nikt nie wie, co on tak naprawdę oznacza. Nie wie użytkownik, ba nie wie nawet deweloper! Ile punktów powinna dostawać przesyłka, jeśli zawiera słowo sex? Prawdopodobieństwo oczywiście może być obliczone źle, ale przynajmniej wiemy, co ono oznacza i jakie metody zostały użyte do jego określenia. Opierając się na moim zbiorze, sex wykazuje, że przesyłka jest spamem z prawdopodobieństwem rzędu 0,97, podczas gdy przesyłka ze słowem sexy wskazuje na prawdopodobieństwo równe 0,99. Tak samo jednoznaczna zasada Bayesa mówi, że zawierający oba słowa, nawet jeśli nie figuruje w żadnych zbiorach, ma szanse bycia spamem na poziomie 99,97%. Spróbujcie to osiągnąć metodą scoringu. Podejście Bayesa bada wszystkie wystąpienia słów, zarówno dobre jak i złe. Słowa, które występują w spamie niezmiernie rzadko (takie jak np. jednak, wieczorem, czy pozornie) zmniejszają prawdopodobieństwo w równie niewielki sposób, w jaki zwiększają je wyrazy unsubscribe czy wybierać. Należy dążyć do tego, aby prawdopodobieństwa były liczone indywidualnie dla każdego użytkownika. Dostaję dużo i zawierających słowo Lisp, i jak do tej pory żaden z nich nie był spamem. Słowo to jest więc pewnego rodzaju hasłem, którego można użyć, aby poczta na pewno do mnie dotarła. W moim poprzednim filtrze spammer mógł użyć listy takich słów i jego automatycznie przedostałby się. Na liście wyrażeń umieściłem na przykład słowo Lisp i kod pocztowy, aby powierdzenia z zakupów on-line, które normalnie wyglądają jak spam, przedostawały się przez filtr. Hehe, popadłem nawet w chwilowy samozachwyt, ale zaraz przyszło mi do głowy, że filtr Bayesa zrobiłby dla mnie to samo, przy okazji wyłapując słowa, których na tej liście nie ująłem. Pisałem już, że nasze filtry mogą przepuszczać niespełna 0,5% spamu i zero false-positive. Sytuacja taka zdarzyła się podczas filtrowania zbioru mojej poczty. Może jednak mieć miejsce tylko wtedy, kiedy filtr użytkownika uczy się na wiadomościach, które sam otrzymuje. Idealnie, jeśli użytkownik w swoim kliencie pocztowym będzie dysponował dwoma przyciskami Delete: zwykłym oraz Delete-as-spam. Wszystko, co skasuje bo było spamem, powinno trafić do zbioru spamu, pozostałe przesyłki do zbioru nie-spamu. Uczenie filtra powinno się rozpocząć od zasilenia zbiorów użytkowników jakimiś danymi inicjalnymi. Ostatecznie jednak każdy powinien regularnie wzbogacać swoją bazę danymi uzyskiwanymi z poczty, którą otrzymuje. Takie rozwiązanie: (a) czyni filtr bardziej efektywnym, (b) pozwala użytkownikowi decydować o precyzji własnego filtra, oraz (c) - i to prawdopodobnie największa zaleta - utrudnia spammerom tworzenie przesyłek przebijających się przez filtr. Największa siła filtra tkwi w indywidualnych bazach danych użytkowników, aczkolwiek korzystanie z baz, które nie są zasilane indywidualnymi danymi, najczęściej nie daje takiej skuteczności, jakiej byśmy oczekiwali. Jedyną dobrą metodą są rozłączne bazy użytkowników, bo tylko one zapewniają dostateczne rozróżnienie i dostosowanie filtra do potrzeb użytkownika, nie przeszkadzając przy okazji innym. Filtrowanie zawartości często bywa łączone z whitelistingiem technologią wykorzystującą listy adresów, z których poczta powinna docierać bez kontroli zawartości. Jedynym sposobem utrzymania takiej listy jest dodawanie do niej każdego adresu, do którego użytkownik choć raz coś napisał. Jeśli klient pocztowy użytkownika posiada przycisk delete-as-spam, powinno się do whitelisty dołączać również te adresy, z których poczta została usunięta w zwykły sposób. Osobiście jestem zwolennikiem whitelistingu, ale bardziej jako sposobu na oszczędzanie mocy obliczeniowej, niż na poprawę samego filtrowania. Kiedyś uważałem, że whitelisting ułatwia filtrowanie, bo przecież wystarczy filtrować wiadomości od ludzi, od których nigdy nic nie otrzymaliśmy. Obcy nadawca ograniczony jest wówczas tym, co my po-

24 24 Dariusz Grzesista zwolimy mu napisać. Ktoś, kogo już znamy, może swobodnie pisać do nas o seksie, natomiast nie wolno tego robić osobie, która wcześniej do nas nic nie napisała. Problem w tym, że ludzie miewają więcej adresów nowy adres w polu From wcale nie oznacza, że nadawca jest osobą obcą. Dla starego wyjadacza wysłanie poczty z nowego adresu nie jest niczym nadzwyczajnym, nie można więc ryzykować false-positive ów, zbyt rygorystycznie podchodząc do reguł filtra. Mój filtr jest pewnym rodzajem zarówno whitelistingu jak i blacklistingu, ponieważ bazuje na całych wiadomościach, łącznie z nagłówkami. Dzięki temu zna adresy zaufanych nadawców i drogi, którymi przesyłki do mnie trafiają. To samo wie oczywiście o spamie, wliczając w to nazwy serwerów, wersje klientów oraz protokoły. Utrzymanie skuteczności filtrowania spamu może dawać złudzenie definitywnego rozwiązania problemu. Ilość odsianego spamu ma jednak niewielkie znaczenie, ponieważ ten ostatni ciągle ewoluuje. Najlepsze nawet metody antyspamowe są jak pestycydy, które tylko uczestniczą w rozwoju nowych, odpornych na ich działanie szkodników. Większą nadzieję daje natomiast filtr Bayesa, ponieważ potrafi on ewoluować razem ze spamem. Na przykład, gdy spammer zaczyna używać k0gut zamiast kogut by ominąć proste bariery słownikowe, filtr Bayesa automatycznie uczy się takiej zmiany. W praktyce k0gout staje się o wiele pewniejszym dowodem na spam niż kogut, a filtr Bayesa dokładnie wie, o ile więcej. Każdy, kto proponuje jakiś nowy sposób na spam, musi sobie odpowiedzieć na pytanie: gdyby spammerzy wiedzieli dokładnie do czego używasz i do czego zmierzasz, po jakim czasie dostaliby się do ciebie? Na przykład, gdyby poważną przeszkodą stały się sumy kontrolne, na ile szybko spammerzy przesiedliby się na nowe biblioteki obliczające takie sumy dla i? By przechytrzyć filtr Bayesa, nie wystarcza utworzenie unikalnej przesyłki i rezygnacja ze znanych haseł spamowych. Spammer musiałby jeszcze spowodować, aby jego maile były nie do odróżnienia od zwykłej poczty. To właśnie stanowi o największej sile filtra Bayesa. Spam to najczęściej reklama jakiegoś towaru, dlatego aby przechytrzyć filtr, spammer musiałby zmienić (i utrzymywać zmienioną) infrastrukturę własnej sieci. W przeciwnym razie jego nagłówki poczty zawsze będą podejrzane, bez względu na to, co wpisze w ciele wiadomości. Nie wiem zbyt wiele o infrastrukturze z jakiej korzystają spammerzy, aby jednoznacznie stwierdzić, na ile trudna byłaby dla nich zmiana, która spowodowałaby uznanie poczty za niewinną. Przypuszczam, że niejednokrotnie łatwiej byłoby wysłać nie-spam. Gdyby mocno zaingerowali w treść nagłówka i przedostali się, spam przyszłości wygląłby na przykład tak: Cześć. Pomyślałem, że powinieneś spojrzeć na to: Wiadomość ta prawdopodobnie dotrze, ponieważ jest w niej bardzo mało informacji handlowej. Trudno będzie zmusić filtr do prawidłowej oceny tej przesyłki, bo jeśli cała treść pozostanie neutralna, prawdopodobieństwo spamu zależeć będzie już tylko od podanego URL-a. Spammerami są zarówno pseudo-biznesmeni, rozsyłający różne zachęty do wyboru ich produktów, jak i pospolici szkodnicy, przejmujący błędnie skonfigurowane serwery pocztowe w celu siania spamu promującego np. strony porno. Jeśli użyjemy filtrowania Bayesa by pozbyć się wszystkich tych przypadków, resztę będziemy mogli całkiem spokojnie potraktować jako prawie legalny margines biznesu. Spammerzy z tego marginesu czują się zobowiązani przez przeróżne aparaty sprawiedliwości do przekonywania nas, dlaczego ich spam nie jest spamem, w jaki sposób odwołać jego subskrybcję, itp. Margines ten zaś można usunąć nawet bez pomocy filtrów statystycznych. Sądziłem kiedyś, że myślenie, iż restrykcyjne prawo może powstrzymać spam, jest naiwne. Z czasem spostrzegłem jednak, że o ile surowe prawo nie jest w stanie całkowicie go zatrzymać, to jednak pośrednio pomaga filtrom, zmniejszając efektywną ilość spamu docierającą do odbiorcy. Trzeba pamiętać, że ograniczanie możliwości reklam produkowanych przez spammerów nieuchronnie prowadzi do bankructwa tych ostatnich. Spammerzy to biznesmeni wysyłają spam tak naprawdę tylko dlatego, że on działa! Nawet wówczas, gdy poziom odpowiedzi jest skrajnie niski (w najlepszym wypadku 15 na milion, dla porównania przy wysyłkach katalogowych jest to ok na milion), nie zrażają się, bo ich koszt wysyłki też jest niski. Bardzo wysoki jest za to koszt po stronie odbiorców: rzędu pięciu osobotygodni na każdy milion

25 Bezpieka w strukturach poczty 25 odbiorców, przy założeniu, że tracą tylko sekundę na usunięcie 1 spamu! A spammerzy za to nie płacą. Rozsyłanie śmieci ileś jednak spammerów kosztuje 2. Powinniśmy więc starać się obniżać ich skuteczność stosując filtry, tak aby to destrukcyjne działanie było dla nich coraz mniej opłacalne. Głównym celem używania coraz to bardziej wysublimowanych technik reklam jest stałe podnoszenie wskaźników reakcji. Zamiast dostawać się do umysłu klienta, spammer będzie na ogół wzbudzał wstręt. Spójrzmy jednak do wnętrza osoby, która odpowiada na spam. Najczęściej jest albo zadziwiająco łatwowierna, albo mocno skrzywiona seksualnie. W obydwu przypadkach zwroty, dla normalnego człowieka odrażające i idiotyczne, traktuje jako podnietę. Spammerzy nie wypisywaliby żadnych obscenicznych określeń, gdyby nie brzmiały zachęcająco. Stwierdzenie: Myślę, że powinieneś to sprawdzić samo w sobie pcha do podejrzanych zachowań. Reasumując: jeśli spam nie mógłby zawierać powyższych słów, stałby się raczej miernym chwytem marketingowym i środowiska biznesu szybko przestałyby się nim interesować. Tymi słowy pragnę zakończyć moje rozważania. Zacząłem tworzyć oprogramowanie antyspamowe, bo nie mam ochoty już więcej oglądać śmietniska, jakie produkuje nadchodzący spam. Jeśli staniemy się wystarczająco dobrzy w jego odsiewaniu, nie będzie oddziaływał na ludzi i umrze śmiercią naturalną. Spośród wszystkich sposobów na zwalczanie spamu, rozpoczynając od programowych a kończąc na prawnych, jestem głęboko przekonany, że filtry Bayesa pozostaną rozwiązaniem najbardziej efektywnym. Mam również nadzieję, że podejmiemy wysiłek tworzenia innych rodzajów antyspamu zawsze lepszych, ponieważ każdy nowy sposób na ograniczanie rozmiarów tego śmietnika będzie nową cegiełką w murze potrzeb. Im więcej pojawi się różnorodnego oprogramowania filtrującego, tym korzystniej dla nas wszystkich. Im więcej filtrów, tym trudniej spammerom spreparować taką treść, która będzie w stanie się przez nie przedostać. 2 Obecnie najniższa znana stawka za rozesłanie miliona spamu kształtuje się na poziomie 200 dolarów. To bardzo mało zaledwie 1/50 centa za przesyłkę. Odfiltrowanie 95% spamu podnosi jednak ten koszt nawet dwudziestokrotnie! Trzeba z tym walczyć, bo nie stać nas na takie wydatki.

26 Adam Buraczewski Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole Streszczenie PostgreSQL jest systemem zarządzania bazami danych Open Source, który dzięki swoim bogatym możliwościom, uznanej stabilności i wydajności w pracy wieloużytkownikowej zyskał uznanie nie tylko w kręgach naukowych i inżynierskich, ale także w biznesie. Wokół niego powstaje coraz więcej różnych projektów mających na celu uzupełnienie go o funkcje znane z dużych, komercyjnych systemów, takie jak transakcje rozproszone, replikacja baz danych, czy klastry. Niniejszy artykuł dokonuje przeglądu i porównania najważniejszych rozwiązań tego typu. 1. Wprowadzenie Najbardziej zaawansowany system zarządzania bazami danych Open Source tak jego autorzy dumnie określają PostgreSQL, świętując zarazem 10-lecie jego rozwoju od chwili przejęcia kodu z Uniwersytetu Kalifornijskiego w Berkeley. Trudno im odmówić racji: historia tego systemu rozpoczęła się na początku lat 70. od projektu Ingres (ang. Interactive Graphics Retrieval System), stworzonego i rozwijanego przez zespół prof. Michalea Stonebreakera, pioniera relacyjnych baz danych. Postgres, którego nazwa określa następstwo po systemie Ingres, był początkowo systemem jedynie eksperymentalnym, rozwijanym w ramach grantów naukowych, ale wraz z upływem czasu stawał się coraz poważniejszym produktem, mającym zastosowanie w wielu projektach. Obydwa wymienione programy na stałe zostały wpisane do historii informatyki, a ich kod stał się podstawą wielu wykorzystywanych współcześnie, także komercyjnych systemów. W roku 1995 Postgres opuścił mury uniwersytetu, a dwaj doktoranci prof. Stonebreakera rozpoczęli proces oczyszczania i przyspieszania jego kodu, dostosowania do języka zapytań SQL (dotąd stosowano specjalnie zaprojektowany dla Postgresa język PostQuel), oraz zaadaptowania do systemu GNU/Linux. Projekt wkrótce zyskał na popularności, jego nazwę zmieniono początkowo na Postgres95, następnie na PostgreSQL, a odpowiedzialność za jego dalszy rozwój przejęła grupa wolontariuszy Postgre- SQL Global Development Group. Pierwszy PostgreSQL oznaczony został od razu numerem 6, żeby zaakcentować związek ze swoimi poprzednimi wcieleniami (cztery pierwsze wersje powstały w Berkeley, a piąta to Postgres95). Od tamtej chwili PostgreSQL, który już na starcie dysponował wieloma ciekawymi możliwościami, np. elementami aktywnymi (triggerami, regułami), łatwo definiowanymi procedurami, czy rozszerzalnym systemem typów danych, został znacznie rozbudowany. Jego autorzy postawili na zwiększenie wydajności i bezpieczeństwa systemu, oraz na zgodność ze standardem języka SQL. Usprawniono obsługę transakcji, opierającą się na schemacie MVCC (ang. Multi-Version Concurrency Control), dzięki któremu odczyt a nawet modyfikacja danych w tabelach bardzo rzadko wymaga zakładania blokad, co z kolei pozwala na wydajną pracę wielu użytkowników na raz, czy np. wykonywanie kopii bezpieczeństwa bez zatrzymywania bazy. Dodano mechanizm WAL (ang. Write-Ahead Log), gwarantujący spójność danych w przypadku awarii zasilania komputera, dodatkowe języki programowania, w których można pisać procedury (np. język zgodny z PL/SQL), nowe typy indeksów, zniesiono bariery związane z wielkością pól danych w tabelach itp. Sukces, który PostgreSQL zaczął odnosić dzięki swojej bogatej funkcjonalności, uznanej stabilności i wydajności w aplikacjach wieloużytkownikowych, spowodował rosnące zainteresowanie w kręgach biznesowych. Wiele firm, nie tylko zajmujących się oprogramowaniem Open Source, zaczęło dostrzegać w tym systemie wielki potencjał. Dzięki ich zaangażowaniu, PostgreSQL wkrótce dorobił się takich możliwości jak obsługa schematów, przestrzeni tabel, savepointów, PITR (ang. Point-in-Time Recovery), indeksowania pełnotekstowego, języka Java w zastosowaniu do tworzenia procedur składowanych i triggerów, a nawet natywnej wersji działającej w środowisku Microsoft Windows. Bardzo dużo wysiłku poświęcono na zwiększenie wydajności PostgreSQLa. Powstały komercyjne projekty takie jak EnterpriseDB, Bizgres, czy Mammoth Post-

27 Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 27 gresql, których celem jest rozbudowa funkcjonalności podstawowego systemu o elementy potrzebne w dużych zastosowaniach i ułatwiające migrację z drogich, komercyjnych systemów bazodanowych. Co ciekawe, przy tym wszystkim PostgreSQL nadal pozostaje doskonałym środowiskiem o walorach naukowych i edukacyjnych, a firmy realizujące projekty komercyjne intensywnie biorą udział w rozwoju podstawowej, otwartej wersji i przekazują do niej swoje rozwiązania. Wykorzystanie systemu PostgreSQL w coraz poważniejszych zastosowaniach, w tym biznesowych, stawia przed nim dodatkową poprzeczkę, która jest związana z wymogiem, aby był to system nie tylko stabilny i wydajny, ale także żeby realizował postulat high availability. Firmy i instytucje rozważające wykorzystanie PostgreSQLa jako zamiennika systemów komercyjnych, coraz częściej oczekują od niego możliwości ciągłej pracy, działania w systemach rozproszonych, w obrębie klastrów komputerów, automatycznej replikacji danych i przełączania pomiędzy serwerami w przypadku ich awarii. Celem niniejszego artykułu jest przybliżenie takich rozwiązań, ich obecnych możliwości i ograniczeń. 2. Praca rozproszona 2.1. Moduł dblink i podobne rozwiązania Wraz z uporządkowaniem w wersji 7.3 systemu PostgreSQL mechanizmu funkcji mogących jako wynik zwrócić całą tabelę (tzw. Table Functions lub Set Returning Functions), pojawiła się możliwość wygodnego wykorzystania w zapytaniach SQL danych nie przechowywanych bezpośrednio w bazie, lecz pobieranych z zewnętrznego źródła w chwili wywołania takiej funkcji. Możliwość tę wykorzystano w module dblink, który jest standardowo rozprowadzany ze źródłami systemu PostgreSQL w katalogu contrib. Zadaniem funkcji tego modułu jest połączenie się do innej bazy PostgreSQL, która może być umieszczona zarówno na tym samym, jak i zdalnym serwerze, wykonanie zapytań i zwrócenie wyniku w postaci tabeli, która może być np. złączona z tabelą z bazy lokalnej. Możliwe jest też wykonywanie na zdalnym serwerze poleceń modyfikujących bazę. Przykład prostego wykorzystania modułu dblink znajduje się poniżej składa się z polecenia połączenia do zdalnej bazy danych, wykonania zapytania typu SELECT, uaktualnienia bazy za pomocą UPDATE i zamknięcia połączenia: SELECT dblink_connect ( host= dbname=baza ); SELECT * FROM dblink( SELECT c1, c2 FROM tabela ) AS (c1 integer, c2 integer); SELECT dblink_exec( UPDATE tabela SET c2 = 5 WHERE c1 = 3 ); SELECT dblink_close(); Należy zwrócić uwagę, że przy wykonywaniu zapytań należy określić liczbę i typy kolumn wyniku za pomocą klauzuli AS jest to ograniczenie mechanizmu Set Returning Functions w systemie PostgreSQL. Dlatego, do często wykonywanych zapytań, najprościej jest stworzyć widoki, np. tak: CREATE VIEW zdalna_tabela AS SELECT * FROM dblink( SELECT c1, c2 FROM tabela ) AS (c1 integer, c2 integer); SELECT * FROM zdalna_tabela; Oczywiście możliwości modułu dblink nie kończą się w tym miejscu, a liczba jego zastosowań jest praktycznie nieograniczona. Jego funkcje można wykorzystać wewnątrz procedur pisanych w dowolnym z wielu dostępnych w PostgreSQL języków proceduralnych, w tym w PL/pgSQL. W szczególności, funkcje modułu dblink mogą być wywoływane wewnątrz triggerów, co pozwala na modyfikację bazy zdalnej wskutek zdarzeń występujących w bazie lokalnej. Moduł dblink łączy się z bazą zdalną za pomocą standardowego protokołu wymiany danych używanego w systemie PostgreSQL do komunikacji klient-serwer. Z jednej strony jest to zaleta: połączenie może nastąpić do dowolnej wersji systemu PostgreSQL, mogą więc w ten sposób współpracować bazy oparte na wersjach od 7.3 do 8.1, a w szczególnych przypadkach nawet starsze. Do wad tego rozwiązania należy natomiast zaliczyć: dwukrotną konwersję danych, które są przesyłane pomiędzy serwerami w postaci tekstowej, narzut czasowy na proces autoryzacji użytkownika w serwerze, do którego dblink się łączy (można to zminimalizować stosując np. pgpool, opisany w dalszej części artykułu), oraz problemy w obsłudze transakcji. Obsługa transakcji w przypadku modułu dblink jest problematyczna. Transakcje na serwerze zdalnym można rozpocząć i zakończyć tylko jawnie, wysyła-

28 28 Adam Buraczewski jąc do niego odpowiednie polecenia: BEGIN i COM- MIT lub ROLLBACK. Nie jest to w żaden sposób zsynchronizowane z transakcjami na serwerze lokalnym, musi więc o to zadbać programista. O ile jeszcze błędy poleceń wykonywanych zdalnie są zwracane przez funkcje modułu dblink, to wycofanie transakcji lokalnej wcale nie unieważnia transakcji rozpoczętej na zdalnym serwerze. Najgorszy przypadek przedstawiono poniżej gdy decyzja o wycofaniu lokalnej transakcji pozostawia zmiany na serwerze zdalnym: BEGIN; -- Rozpoczęcie lokalnej transakcji. -- Rozpoczęcie zdalnej transakcji. SELECT dblink_exec( BEGIN ); -- Modyfikacja zdalnej bazy. SELECT dblink_exec( INSERT... ); -- Zatwierdzenie zmian. SELECT dblink_exec( COMMIT ); ROLLBACK; -- Wycofanie lokalnej transakcji. Rozwiązaniem tego problemu jest zastosowanie transakcji rozproszonych, realizowanych w systemie PostgreSQL pod postacią mechanizmu Two-Phase Commit, opisanego w następnej sekcji. Powyższe zachowanie jest jednak czasami wykorzystywane celowo, do równoczesnej realizacji dwóch niezależnych transakcji na tej samej bazie danych w ramach jednego połączenia z serwerem. W ten sposób można np. stworzyć procedurę, której wynik działania pozostaje w bazie danych nawet mimo wycofania transakcji, w której ją wywołano. Istnieją także specjalizowane pakiety, pozwalające na wykonywanie zdalnych zapytań na serwerach innych producentów, np. oralink czy dblink-tds. Działają na tej samej zasadzie co moduł dblink, wykorzystują tylko odpowiednie biblioteki służące do łączenia się do innych baz. Zupełnie inne podejście do problemu prezentuje za to pakiet DBI-link, który do połączeń z innymi bazami danych wykorzystuje język Perl i sterowniki DBI z tego języka programowania, dzięki czemu może łączyć się z praktycznie dowolnym serwerem bazodanowym. Pakiet ten analizuje strukturę wskazanej, zdalnej bazy danych, a następnie tworzy lokalnie komplet widoków, odzwierciedlających strukturę tej bazy można z nich korzystać tak samo jak z tabel tamtej bazy Two-Phase Commit Problem równoczesnego zatwierdzania rozpoczętych transakcji dotyczy każdego systemu rozproszonego, niezależnie czy aplikacja sama zarządza połączeniami, korzysta z jakiegoś middleware, czy też połączenie ze zdalną bazą realizowane jest za pomocą mechanizmów typu dblink. Równoczesne korzystanie z kilku baz danych, wiążące się z ich modyfikacją, w większości przypadków wymaga równoczesnego zatwierdzenia zmian we wszystkich bazach, lub wycofania zmian ze wszystkich baz. O ile to drugie jest proste wystarczy wykonać polecenie ROLLBACK lub zakończyć połączenie z serwerem (w PostgreSQL wycofywane są także transakcje, które były rozpoczęte w chwili np. awarii komputera, systemu operacyjnego lub sieci, która spowodowała natychmiastowe zakończenie działania PostgreSQLa lub zerwanie połączenia sieciowego), o tyle zatwierdzanie transakcji pociąga za sobą więcej ryzyka. Gdyby w systemie rozproszonym transakcje były zatwierdzane za pomocą zwykłego polecenia COMMIT, mogłaby się zdarzyć sytuacja, w której, po zatwierdzeniu zmian na kilku serwerach, zatwierdzenie na następnym nie powiodłoby się (bo np. połączenie sieciowe lub zasilanie serwera zostało uszkodzone). Powstałaby więc niespójność pomiędzy zawartością serwerów. Mechanizm Two-Phase Commit (oznaczany skrótem 2PC) został dodany w wersji 8.1 systemu PostgreSQL właśnie w celu realizacji wiarygodnych, rozproszonych transakcji. Rozszerza on stosowane dotąd polecenia języka SQL obsługujące transakcje o: PREPARE TRANSACTION oraz COMMIT PREPA- RED i ROLLBACK PREPARED. Polecenia te działają następująco: transakcje rozpoczynane są standardowym poleceniem BEGIN, wykonanie polecenia PREPARE TRANSACTION z podaniem identyfikatora tekstowego powoduje wykonanie większości operacji związanych z zatwierdzeniem transakcji, w tym kontroli spójności danych zmodyfikowanych w ramach tej transakcji, ale sama transakcja nie jest jeszcze zakończona a zmiany dokonane w jej obrębie nie są jeszcze widoczne, nawet w obrębie sesji bazodanowej, w której ta transakcja była przed chwilą realizowana, wykonanie polecenia COMMIT PREPARED z podaniem tego samego identyfikatora co w przypadku PREPARE TRANSACTION powoduje dokończenie zatwierdzania transakcji, której wyniki są widoczne w bazie danych tak samo jak w przy-

29 Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 29 padku zwykłego polecenia COMMIT; podobnie polecenie ROLLBACK PREPARED wycofuje transakcję o podanym identyfikatorze; polecenia COM- MIT/ROLLBACK PREPARED nie muszą być wykonane w ramach tej samej sesji bazodanowej co zatwierdzana transakcja. Warto zauważyć, że PostgreSQL gwarantuje możliwość późniejszego zatwierdzenia transakcji przygotowanej przez PREPARE TRANSACTION, nawet w przypadku awarii sieci, zasilania czy komputera. Żeby to osiągnąć, wszystkie dane potrzebne do zatwierdzenia transakcji zapisywane są na dysku serwera, w katalogu pg_twophase, a należą do nich nie tylko informacje o dokonanych zmianach w bazie, ale nawet blokady, które muszą być zachowane. Oczywiście, użytkownicy którzy rozpoczęli transakcje po wykonaniu PREPARE TRANSACTION mogą mieć z powodu tych blokad problemy z pracą, ale nie są one inne niż w przypadku stosowania w systemie zwykłych, ale rozciągniętych w czasie transakcji. Administrator systemu PostgreSQL może w każdej chwili obejrzeć informacje o przygotowanych transakcjach rozproszonych, może je także według swojego uznania wycofywać lub zatwierdzać. Informacje te zebrane są w tabeli systemowej pg_prepared_xacts. Wykorzystanie mechanizmu 2PC z np. omówionym w poprzedniej sekcji modułem dblink do bezpiecznego realizowania transakcji na kilku serwerach można wyobrazić sobie następująco: -- Rozpoczęcie lokalnej transakcji. BEGIN; -- Rozpoczęcie zdalnej transakcji. SELECT dblink_exec( BEGIN ); -- Modyfikacja zdalnej bazy. SELECT dblink_exec( UPDATE... ); -- Modyfikacja lokalnej bazy. UPDATE...; -- Przygotowanie zdalnej transakcji. SELECT dblink_exec( PREPARE TRANSACTION t123 ); -- Zatwierdzenie lokalnej transakcji. COMMIT; -- Zatwierdzenie zdalnej transakcji -- - na pewno się powiedzie. SELECT dblink_exec( COMMIT PREPARED t123 ); 2.3. JTA Wykorzystanie mechanizmu Two-Phase Commit w aplikacji pozwala na realizację transakcji rozproszonych, ale jest to mechanizm raczej niskopoziomowy wymaga od programisty oprogramowania odpowiednich sekwencji poleceń PREPARE TRANS- ACTION i COMMIT/ROLLBACK PREPARED. Staje się to bardziej skomplikowane, gdy aplikacja korzysta z kilku różnych baz danych, albo także z innych obiektów o zachowaniu transakcyjnym (np. obiektów obsługiwanych za pomocą Hibernate lub innego silnika ORM, EJB itp.), które wykorzystują różne protokoły zatwierdzania transakcji. Dlatego, w przypadku języka Java, powstał standard zarządzania transakcjami: Java Transaction API (JTA), który określa mechanizmy potrzebne do realizacji transakcji obejmujących równoczesną modyfikację wielu baz danych i obiektów. Standard ten jest częścią J2EE API i jest dostępny jako dokument JSR 907. Aplikacja wykorzystująca JTA musi działać na platformie, na której dostępna jest usługa JTS Java Transaction Service. Należą do nich różne komercyjne platformy zgodne ze standardem J2EE, ale także rozwiązania Open Source, takie jak JBoss. Istnieją także niezależne implementacje JTS, np. JOTM, które można wykorzystać razem z np. serwerem Tomcat czy we własnych programach. Wykorzystanie JTA we własnych programach jest dosyć proste, może jednak wymagać wcześniejszego skonfigurowania JTS. Na przykład, w przypadku JOTM i Tomcata, należy w tym celu przygotować odpowiedni plik konfiguracyjny carol.properties, opisujący sposób komunikacji z serwerem JTS, oraz zmodyfikować plik server.xml lub context.xml, dodając zasób o nazwie np. UserTransaction. Uzyskanie odpowiedniego obiektu transakcji odbywa się poprzez mechanizm JNDI: UserTransaction ut; ut = (UserTransaction) context.lookup("java:comp/usertransaction"); ut.begin(); // Tu następuje dostęp do wielu // różnych źródeł danych ut.commit(); W chwili wywołania funkcji commit(), JTS sprawdza czy źródła danych wspierają mechanizm Two-Phase Commit i jeżeli tak, wykorzystuje go do jednoczesnego zatwierdzenia transakcji. W przypadku źródeł nie obsługujących tego protokołu, wy-

30 30 Adam Buraczewski korzystywane jest oddzielne zatwierdzanie transakcji w każdym z takich źródeł, co oczywiście może prowadzić do problemów gdy zatwierdzanie jednego z nich się nie powiedzie. Na szczęście Postgre- SQL dysponuje już mechanizmem 2PC, wymaga to jednak stosowania sterownika JDBC w wersji 8.1 lub nowszej. W przypadku baz danych nie obsługujących 2PC (w tym starszych wersji PostgreSQLa) można go symulować za pomocą pakietu XAPool, który dodaje namiastkę transakcji rozproszonych do dowolnego sterownika JDBC Sequoia (dawniej Clustered-JDBC) Projekt Sequoia plasuje się właściwie pomiędzy rozproszonymi bazami danych, klastrami, replikacją oraz mechanizmami zapewniającymi rozkładanie obciążenia systemu i obsługę awarii. Jest to system typu middleware napisany w języku Java (wykorzystuje sterowniki JDBC, chociaż dostęp z poziomu języka C++ też jest możliwy). Jego zadaniem jest organizacja całego klastra rozproszonych baz danych i udostępnianie go za pomocą pojedynczego połączenia JDBC, z którego aplikacja korzysta tak, jakby cały klaster był pojedynczą bazą danych. Dzięki temu nie trzeba w ogóle modyfikować aplikacji, która dotąd działała z pojedynczą bazą danych, stosować mechanizmów typu JTA i rozproszonych transakcji wewnątrz aplikacji, aby zwiększyć jej możliwości (zwłaszcza wydajność) i stworzyć system rozproszony. System Sequoia można traktować właściwie jak samodzielny serwer bazodanowy, który jednak nie przechowuje danych bezpośrednio, lecz korzysta z zewnętrznych serwerów PostgreSQL (lub innych) do składowania danych. Możliwe są następujące konfiguracje: każdy z serwerów bazodanowych przechowuje pełną kopię bazy danych, wówczas Sequoia zapewnia ich synchronizację, rozkłada obciążenie (dostępnych jest kilka algorytmów load balancing), oraz obsługuje awarie poprzez włączanie do działania serwerów zapasowych (które normalnie nie są używane) czyli realizuje podobne funkcje jak np. program pgpool, poszczególne serwery bazodanowe przechowują tylko część tabel (partycjonowanie bazy danych), wówczas Sequoia zapewnia przekierowanie zapytań SQL do odpowiedniego serwera, różne kombinacje powyższych rozwiązań, czyli np. duże, rzadko wykorzystywane tabele są umieszczone tylko na wybranych serwerach, podczas gdy tabele często wykorzystywane są zreplikowane na każdym z serwerów i dostęp do nich jest rozkładany tak, żeby zrównoważyć obciążenie wszystkich serwerów. System Sequoia jest dosyć prosty w instalacji i konfiguracji dostępne są nawet graficzne wizardy ułatwiające uruchomienie systemu. Wraz z tym systemem dostępne są także bogate w możliwości narzędzia administracyjne, służące do konfiguracji i monitoringu systemu, oraz np. wykonywania kopii bezpieczeństwa całego klastra. Wadą systemu Sequoia jest natomiast to, że został stworzony do współpracy z bazami danych nie obsługującymi mechanizmu Two-Phase Commit i ma w związku z tym własny system zapewniania spójności baz danych, podobnie jak np. Slony-I. Nie można go więc stosować w aplikacjach korzystających z transakcji JTA, co najwyżej można w tym przypadku zastosować wspomniany wcześniej moduł XAPool. 3. Connection pooling 3.1. pgpool Program pgpool, stworzony przez japońską firmę SRA, jest sztandarowym programem realizującym tzw. connection pooling dla serwerów PostgreSQL. Jego zadaniem jest rozkładanie obciążenia pomiędzy wiele serwerów, które obsługują np. duży serwis WWW. Jego dodatkowym atutem jest utrzymywanie puli otwartych połączeń do serwera Postgre- SQL, dzięki czemu nowo łączące się do bazy danych aplikacje nie muszą ponownie przechodzić całego procesu autoryzacji, co ma szczególnie znaczenie gdy sesje bazodanowe są krótkie (a właśnie taka sytuacja występuje w serwisach WWW). W pierwszym wydaniu program pgpool obsługiwał na raz dwa serwery PostgreSQL. Zapytania odczytujące bazę danych były kierowane do jednego z tych dwóch serwerów, natomiast modyfikujące do obydwóch, dzięki czemu bazy danych miały zawsze tę samą zawartość. Optymalne wykorzystanie programu pgpool wymagało jednak odpowiedniej wiedzy programisty, który powinien odpowiednio przygotować zapytania (np. wstawiając do nich odpowiednie komentarze instruujące program, czy mogą być wykonane tylko na jednym z dwóch serwerów). W przypadku awarii jednego z serwerów, program pgpool automatycznie przekierowywał wszystkie połączenia do drugiego serwera.

31 Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 31 Bardzo dużą zaletą programu pgpool jest wykorzystanie natywnego protokołu klient-serwer stosowanego przez PostgreSQL, dzięki czemu jego zastosowanie nie wymaga specjalnych zmian w aplikacjach, jedynie podanie odpowiedniego adresu i numeru portu, na którym działa pgpool. Jest to też rozwiązanie niezależne od zastosowanego języka programowania czy sterownika. We wrześniu 2006 r. ukazał program pgpool II, będący nowym wcieleniem programu pgpool. W tej wersji dodano szereg nowych możliwości, do których należy zaliczyć: brak ograniczenia na liczbę serwerów składających się na klaster, tryb pracy parallel, w którym zapytania dotyczące dużych tabel rozdzielane są na podzapytania, następnie wykonywane równocześnie na wszystkich serwerach, a wynik łączony i w tej postaci zwracany do klienta, wygodny, graficzny panel administracyjny o nazwie pgpooladmin, napisany w PHP. Najciekawszy w pgpool II wydaje się tryb parallel, w którym można partycjonować duże tabele i rozdzielać je pomiędzy serwery. Operacja ta wymaga zdefiniowania specjalnej systemowej tabeli pgpool_catalog.dist_def, w której będą zapisane informacje o tym które dane z której tabeli umieszczone są na którym komputerze klastra. Możliwe jest właściwie dowolne rozdzielanie danych, należy jednak pamiętać o tym, że dla PostgreSQLa są to osobne bazy, zatem ich niewłaściwy podział może spowodować problemy z blokadami, sprawdzaniem poprawności kluczy obcych, a nawet widzialnością danych w obrębie pojedynczej transakcji. Opisane powyżej możliwości programu pgpool wydają się być zbliżone do możliwości systemu Sequoia, obydwa produkty powstały bowiem z myślą o zwiększeniu wydajności systemów za pomocą rozproszenia bazy danych, jednak charakteryzują się zupełnie innym podejściem. Sequoia jest produktem przeznaczonym właściwie wyłącznie dla aplikacji napisanych w języku Java, podczas gdy pgpool działa z dowolnymi aplikacjami, za to przeznaczonymi wyłącznie dla PostgreSQLa. Sequoia pozwala widzieć cały klaster jako jedną bazę danych, ukrywając przed aplikacją złożoną strukturę i dystrybucję danych, pgpool natomiast tylko przekierowuje połączenia do jednego z wielu serwerów, tworzy pulę oczekujących połączeń zmniejszając narzut na rozpoczęcie nowej sesji bazodanowej, oraz umożliwia prostą replikację i dystrybucję danych w klastrze. Dodatkową cechą programu pgpool jest to, że zakłada, że w chwili uruchomienia wszystkie bazy danych mają zsynchronizowaną, odpowiednią zawartość, ale pozwala za to na dowolne manipulowanie strukturą tych baz przez programistę czy administratora, podczas gdy Sequoia sama zarządza strukturą baz, synchronizuje je i pozwala na ich modyfikację jedynie za pomocą odpowiedniego panelu administracyjnego. Program pgpool szczególnie nadaje się do przekierowywania połączeń do jednego z wielu serwerów, których zawartość synchronizowana jest przez jakiś system replikacji, np. Slony-I, ma nawet do tego przewidziany specjalny tryb pracy PostgreSQL Relay Kolejny program, PostgreSQL Relay, na pierwszy rzut oka wydaje się być zbliżony do programu pgpool działającego w trybie raw, jednak o ile pgpool służy do rozkładania obciążenia i utrzymywania puli oczekujących połączeń do baz danych, to Postgre- SQL Relay służy do integracji wielu rozproszonych serwerów i baz danych w jednym serwerze, dostępnym pod jednym adresem i numerem portu. Mapowanie baz danych i serwerów opisane jest w prostym pliku konfiguracyjnym. Celem powstania tego programu jest przede wszystkim ułatwienie organizacji rozproszonych serwerów. Dzięki niemu można np. utrzymywać stałe nazwy baz danych i adresy serwerów w programach przy przenoszeniu baz danych do innych lokalizacji. Jego zaletą w stosunku do innych takich programów jest możliwość bardziej szczegółowego określania praw dostępu do baz danych, z użyciem mechanizmu tcpwrappers SQL Relay SQL Relay jest rozbudowanym pakietem realizującym usługi typu connection pooling, obsługującym wiele różnych serwerów bazodanowych, dialektów SQL i języków programowania. Działa w sposób zbliżony do programu pgpool, ale wykorzystuje własny protokół komunikacji klient-serwer, własne API dla języków programowania, oraz własne biblioteki dostępu do baz danych. Ma też wiele ograniczeń, m.in. nie potrafi samodzielnie synchronizować zawartości serwerów (trzeba w tym celu wykorzystać inny mechanizm replikacji lub korzystać z baz danych w trybie tylko do odczytu ), ani reagować na awarie serwerów. Podstawowym zastosowaniem pakietu SQL Relay pozostaje jednak przyspieszenie realizacji krótkich sesji bazodanowych, typowych

32 32 Adam Buraczewski dla aplikacji WWW, w czym sprawdza się znakomicie. Na pakiet SQL Relay składa się szereg programów: sqlr-connection, łączący się do bazy danych, sqlr-listener, udostępniający pulę połączeń aplikacjom, sqlr-scaler, uruchamiający dodatkowe instancje połączeń w razie potrzeby, oraz skrypty uruchamiające i zatrzymujące działanie pakietu. Do łączenia się z pakietem przewidziano szereg API dla wielu języków programowania; większość z nich występuje w dwóch odmianach: zgodnej ze standardami stosowanymi w tych językach (np. JDBC, DBI, Pear::DB), oraz własnej, specyficznej dla SQL Relay. Możliwe jest też zastosowanie specjalnej biblioteki, ładowanej przez ustawienie zmiennej środowiskowej LD_PRELOAD, która zastępuje standardową bibliotekę libpq.so, stosowaną przez większość aplikacji łączących się z Postgre- SQL, i pozwala na łączenie się z bazą danych pośrednio, poprzez SQL Relay, bez nawet rekompilacji programu. Ciekawą funkcją pakietu SQL Relay, nie spotykaną w innych omawianych programach, jest możliwość cacheowania wyników zapytań. Odbywa się to automatycznie, o ile aplikacja sobie tego zażyczy. Wyniki zapytań zapisywane są w cache, znajdującym się w odpowiednim katalogu na dysku, i są zwracane przy ponownym wykonaniu tego samego zapytania, o ile nastąpiło to w odpowiednio krótkim czasie. Specjalny program sqlr-cachemanager zajmuje się usuwaniem przeterminowanych wyników zapytań z cache. W pakiecie SQL Relay dołączany jest także wygodny, graficzny (GTK+) panel administracyjny, za pomocą którego można konfigurować klaster, oraz tekstowy program podobny do np. psql, za pomocą którego można wykonywać polecenia SQL. W odróżnieniu od programu pgpool, SQL Relay pozwala na określanie praw dostępu sprawdzanych jeszcze po stronie samego pakietu, zanim nastąpi połączenie z bazą danych. 4. Replikacja baz danych 4.1. Slony-I Pakiet Slony-I jest obecnie najbardziej dojrzałym rozwiązaniem Open Source, pozwalającym na replikację baz danych PostgreSQL. Został opracowany w 2004 r. przez Jana Wiecka z firmy Afilias z myślą o obsłudze rejestrów domen.org i.info, a następnie udostępniony na licencji BSD i rozwijany dalej przez grupę wolontariuszy. Obsługuje jednokierunkową replikację, z jednym serwerem głównym, oraz dowolnie wieloma podrzędnymi, zorganizowanymi w strukturę drzewiastą. Jego podstawową cechą jest to, że nie wymaga zmian w kodzie samego PostgreSQLa i wykorzystuje jedynie jego standardowe mechanizmy: triggery, komunikaty LISTEN/NOTIFY, procedury w językach PL/pgSQL oraz C. Współpracuje z wersjami PostgreSQLa od 7.3 do 8.1. Nazwa pakietu Slony-I nawiązuje oczywiście do polskich korzeni głównego autora. Slony-I działa w obrębie pojedynczych baz danych. Podstawową jednostką replikacji jest zbiór tabel (ang. set), które są ze sobą powiązane np. za pomocą kluczy obcych i powinny być replikowane razem. W bazie danych może być wiele takich zbiorów. Modyfikacje zbioru tabel dokonane za pomocą standardowych poleceń INSERT/UPDATE/DELETE, powodują umieszczenie informacji o zmianach w specjalnych tabelach logów. Stamtąd są one pobierane przez specjalne programy o nazwie slon, dystrybuowane w drzewie serwerów, a następnie nanoszone. Jest to więc replikacja asynchroniczna typu master to multiple slaves. Informacja o poprawnym przekazaniu zmian trafia z powrotem do serwera głównego, który kasuje zbędne już dane z tabel logów. Pakiet modyfikacji zawiera zawsze pełne informacje o zmianach z całej transakcji, modyfikacje zapewniają więc zawsze spójność bazy danych. Konfiguracja systemu replikacji opartego o Slony-I odbywa się za pomocą specjalnego programu slonik, którym steruje się za pomocą specjalnego języka poleceń. Program ten interpretuje te polecenia, a następnie wywołuje procedury w PL/pgSQL, które zapewniają przekazanie tych poleceń do serwerów podrzędnych, tak więc w końcu wszystkie serwery wykonują te same polecenia. Jedyne, czego Slony-I nie potrafi, to utworzenie struktury tabel, dlatego uruchomienie replikacji rozpoczyna się od zapisania pustej struktury za pomocą polecenia pg_dump z opcją -s, a następnie odtworzeniu jej na nowym serwerze podrzędnym. Kolejnym etapem jest konfiguracja węzłów: nadrzędnego i podrzędnych, oraz określenie sposobu ich połączenia i ścieżek przekazywania danych. Odpowiedni skrypt dla programu slonik może wyglądać następująco: cluster name = moj_klaster; node 1 admin conninfo = dbname=nadrzedny host= ; node 2 admin conninfo = dbname=podrzedny host= ; init cluster (id = 1); store node (id = 2);

33 Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 33 store path (server = 1, client = 2, conninfo = dbname=nadrzedny host= ); store path (server = 2, client = 1, conninfo = dbname=podrzedny host= ); store listen (origin = 1, provider = 1, receiver = 2); store listen (origin = 2, provider = 2, receiver = 1); Po wykonaniu powyższego skryptu można uruchomić komplet programów slon, po jednym dla każdego serwera biorącego udział w replikacji. Kolejnym etapem jest zdefiniowanie zestawów, dodanie do nich tabel i sekwencji, po czym replikacja rozpoczyna się automatycznie. Odpowiedni skrypt dla programu slonik może wyglądać następująco: cluster name = moj_klaster; node 1 admin conninfo = dbname=nadrzedny host= ; node 2 admin conninfo = dbname=podrzedny host= ; create set (id = 1, origin = 1); set add sequence (set id = 1, origin = 1, id = 1, fully qualified name = public.sekwencja ); set add table (set id = 1, origin = 1, id = 1, fully qualified name = public.tabela1 ); set add table (set id = 1, origin = 1, id = 2, fully qualified name = public.tabela2 ); set add table (set id = 1, origin = 1, id = 3, fully qualified name = public.tabela3 ); subscribe set (id = 1, provider = 1, receiver = 2, forward = no); W zestawie tabel replikowanym za pomocą Slony-I, tabele węzła podrzędnego są blokowane przed zapisem za pomocą specjalnych triggerów. Zwykłe triggery także są blokowane, tak więc wykonywane są jedynie na serwerze głównym. Zmiany w strukturze bazy mogą się odbywać jedynie poprzez polecenie execute script w skrypcie programu slonik, po którym zwykle należy dodać/usunąć tabele i sekwencje z replikowanego zbioru. System Slony-I pozwala na oprogramowanie wielu różnych sytuacji specjalnych i awaryjnych. Poszczególne serwery mogą mieć zmieniane położenie w hierarchii, a w przypadku awarii głównego serwera jego rolę może przyjąć dowolny serwer podrzędny, przy czym serwery automatycznie synchronizują się do najnowszej znalezionej wersji bazy danych. W przypadku braku połączenia sieciowego, logi ze zmianami mogą być przenoszone nawet na dowolnych nośnikach, w postaci plików. W ramach systemu Slony-I nie są dostępne jednak żadne zaawansowane narzędzia do monitoringu, co najwyżej podstawowe skrypty obsługujące najbardziej typowe sytuacje oraz program w języku Perl uruchamiający automatycznie prostą replikację dla wybranej bazy danych. Slony-I nadaje się szczególnie do systemów, w których liczy się niezawodność (np. szybkie przejście na inny serwer w przypadku awarii serwera głównego) lub też rozłożenie obciążenia na wiele serwerów. System ten dobrze sprawuje się w złożonych strukturach sieci i przy dużych bazach danych. Doskonale nadaje się do wykorzystanie z wcześniej omówionym programem pgpool. Autorzy systemu Slony-I planują stworzenie systemu Slony-II, który będzie realizował replikację synchroniczną typu multi-master to multiple slaves. Jako punkt wyjściowy przyjęto rozwiązania zastosowane w systemie PostgreSQL-R, opisanym poniżej. Obecnie trwają prace nad jego rozwojem PostgreSQL-R System PostgreSQL-R jest projektem starszym niż Slony-I (rozpoczętym około roku 2000), jednak przez lata niedocenianym i nierozwijanym i na razie jego rozwój nie osiągnął stadium, w którym byłby to system polecany do użycia w systemach produkcyjnych. Jest to system replikacji synchronicznej typu mult-master, w której aplikacja może łączyć się z dowolnym serwerem klastra i modyfikować jego zawartość, a następnie zmiany są replikowane do pozostałych, równoważnych węzłów. W tej sytuacji zatwierdzenie transakcji wymaga potwierdzenia zmian w pozostałych serwerach, wymaga więc wiarygodnego przekazywania danych, podobnie jak to ma miejsce w mechanizmie 2PC. Ze względu na te wymogi, system PostgreSQL-R nie może być zrealizowany jako zewnętrzny zestaw triggerów i procedur, lecz musi głęboko ingerować w kod samego serwera bazodanowego. Projekt PostgreSQL-R został początkowo stworzony przez zespół prof. Bettiny Kemme na Politechnice w Zurichu, bazował jednak na starej wersji PostgreSQL W późniejszym czasie był rozwijany przez Darrena Johnsona pod nazwą PGReplication, by w końcu przejść pod skrzydła Markusa Schiltknechta, który dostosował go dostosował do nowszej

34 34 Adam Buraczewski wersji PostgreSQL i przedstawił na konferencji PostgreSQL Anniversary Summit w lipcu 2006 r. W systemie PostgreSQL-R jedynie polecenia odczytujące bazę danych realizowane są lokalnie, w ramach jednego serwera. W pozostałych przypadkach, zmiany dokonane przez aplikację są gromadzone w tzw. writeset, a w momencie zatwierdzania transakcji przekazywane do pozostałych równorzędnych serwerów. Jeżeli wszystkie serwery potwierdzą możliwość zatwierdzenia, jest ono realizowane. Do komunikacji (wysyłania danych i odbierania potwierdzeń) wykorzystany jest mechanizm komunikatów Spread, zapewniający tę samą kolejność nanoszenia zmian z zatwierdzanych transakcji na wszystkich serwerach. Ze względu na konieczność natychmiastowego synchronizowania informacji pomiędzy serwerami, muszą być one połączone odpowiednio szybką siecią lokalną. Co prawda na razie nie ma gotowych wydań systemu PostgreSQL-R, ale na stronie domowej projektu znajduje się obraz płyty typu Live CD z Linuksem i aktualną wersją systemu PostgreSQL-R, którą można po prostu użyć do szybkiego stworzenia systemu klastrów w sieci komputerów PGCluster PGCluster jest kolejnym projektem oferującym replikację synchroniczną typu multi-master. Podobnie jak PostgreSQL-R, kod PGCluster ingeruje w źródła systemu PostgreSQL, oraz dodaje do niego dwa dodatkowe programy: serwer replikacji oraz load balancer, rozkładający obciążenie pomiędzy wiele serwerów. Potrafi replikować jedynie cały serwer bazodanowy, ze wszystkimi znajdującymi się na nim bazdami danych. Do wstępnej synchronizacji plików danych wykorzystuje program rsync, a na dodatek wymaga aby oprogramowanie na każdym z serwerów było instalowane pod w tym samym katalogu. Podstawowym problemem z systemem PGCluster, podobnie jak w przypadku PostgreSQL-R, jest brak integracji z najnowszymi wersjami PostgreSQLa. Wersja stabilna systemu PGCluster odpowiada możliwościami PostgreSQL 7.3, jest więc dosyć stara. Brakuje też szerszej dokumentacji. Zaletą jest łatwe uruchomienie klastra oraz fakt, że cały klaster widziany jest pod jednym adresem i numerem portu, nie wymaga więc modyfikacji aplikacji. Do autoryzacji użytkowników wykorzystywane są standardowe mechanizmy PostgreSQL SkyTools SkyTools to kolejny przykład produktu stworzonego przez firmę komercyjną (w tym przypadku Skype) dla własnych potrzeb, która to firma udostępniła go społeczności Open Source. Jest to właściwie nie tyle samodzielny system replikacji, co raczej system kolejek komunikatów realizowanych z użyciem Postgre- SQL. Bazuje on na rozwiązaniach z systemu Slony-I (dokładniej: na systemie monitorowania zmian i dystrybucji logów zmian w tabelach), ale nie jest napisany w PL/pgSQL, lecz w Pythonie. Pakiet SkyTools zawiera moduł londiste, który jest prostym, przykładowym systemem replikacji tabel. Pakiet SkyTools nie może być jeszcze uznany za gotowy system replikacji, ale ponieważ jest wykorzystywany produkcyjnie w dużych zastosowaniach, można go traktować jako wiarygodną podstawę, na której można zbudować własne aplikacje. 5. Podsumowanie Zainteresowanie systemem PostgreSQL w poważnych zastosowaniach, czy to naukowych, czy to w różnych organizacjach i w biznesie, doprowadziło do stworzenia dla niego wielu rozwiązań i narzędzi zapewniających tzw. wysoką dostępność, czyli zwiększenie wydajności lub niezawodności systemu poprzez pracę w klastrze, wiarygodną realizację rozproszonych transakcji, replikację danych i connection pooling. Niektóre z tych rozwiązań, dostępnych na licencji typu Open Source, są bardzo wysokiej jakości (np. 2PC, pgpool, Slony-I, sterownik JDBC), podczas gdy inne, chociaż ciekawe, są jeszcze we wcześniejszym stadium rozwoju (np. PostgreSQL-R). Najbardziej kuleje replikacja typu multi-master, która jest potrzebna do tworzenia klastrów równorzędnych serwerów, prawdopodobnie dlatego że jest najbardziej wymagająca dla twórców tych rozwiązań. Ze względu na rosnące zapotrzebowanie, użytkownicy PostgreSQL powinni jednak wkrótce doczekać się doskonałych produktów z tej kategorii. 6. Źródła Najważniejsze linki związane z systemem Postgre- SQL i tematyką omawianą w artykule: strona domowa systemu PostgreSQL,

35 Słonie w stadzie, czyli jak PostgreSQL pracuje w zespole 35 serwis pgfoundry, czyli katalog i repozytorium większości oprogramowania związanego z PostgreSQL, np. pgpool, PGcluster, PostgreSQL Relay, SkyTools itp., slony.info strona domowa projektu Slony I, strona domowa projektu Postgres-R, spread.org strona domowa projektu Spread, jotm.objectweb.org strona domowa JOTM, xapool.experlog.com strona domowa projektu XAPool, strona domowa JBoss. sequoia.continuent.org strona domowa projektu Sequoia, sqlrelay.sourceforge.net strona domowa projektu SQL Relay.

36 Paweł Moll Podstawy inżynierii jądrowej 1. Aaaale o co chodzi? Jako czytelnik tego tekstu mam prawo wiedzieć o co chodzi! ;-) Chodzi o to, żeby dowiedzieć się jak napisać moduł jądra Linuksa obsługujący proste urządzenie podłączone do komputera. Niezależnie od faktu czy to dobrze czy źle, większość z nas ma komputery PC z procesorami bardziej lub mniej pokrewnymi z poczciwym Na tej platformie się więc skoncentrujemy, choć oczywiście idee, które spróbuję przekazać w niniejszym tekście, są niezależne sprzętowo. 2. Port równoległy Żeby było łatwo na pierwszy raz proponuję wykorzystać port równoległy, który na szczęście ciągle można znaleźć chyba w każdym PeCecie (choć pewnie wkrótce USB wybije i to pożyteczne zwierzątko). Znany również jako Centronics charakteryzuje się 25-sto pinowym gniazdem, do którego tradycyjnie podłączało się grubym kablem drukarkę. Nam domorosłym eksperymentatorom posłuży on w nieco inny sposób. Skorzystamy z faktu, że wśród wspomnianych 25 pinów znaleźć można co najmniej 14, których stanem logicznym (a więc i napięciem 0V lub 5V w stosunku do masy komputera, którą też znajdziemy na innych pinach) możemy w dowolny sposób sterować. W jaki sposób? Otóż każdy z tych pinów podłączony jest do jednego z bitów rejestru wyjściowego mikropamięci, której stan jest ustawiany programowo przez zmianę wartości odpowiedniej komórki przestrzeni wejścia-wyjścia. Cóż to za stwór? Jest to osobna magistrala do komunikacji z urządzeniami zewnętrznymi, adresowana niezależnie od magistrali pamięci. Spokojnie. Istotne jest spostrzeżenie, że port (określenie to oznacza również komórkę przestrzeni wejścia-wyjścia cóż za zamęt w nazewnictwie!) o numerze np. 0x378 nie ma nic wspólnego z komórką pamięci o tym samym adresie. Drugą i może najważniejszą informacją jest to, że do dostępu do portu wykorzystuje się specjalne rozkazy procesora, co przekłada się na specjalne funkcje biblioteczne. Dla przykładu, w czasach DOS-a i Pascala programista pisał port[378h] = 55h; i już - bity danych pierwszego portu równoległego (bo właśnie uparcie przytaczana przez mnie wartość 378 szesnastkowo jest jego adresem) były na przemian załączone i wyłączone. W świecie Linuksa i krewnych nie jest to już (na szczęście!) takie proste, ale o tym za chwilę. Na razie przyjrzyjmy się związkom między bitami portu programowego a pinami portu sprzętowego. Najpierw sprzęt. W najprostszym Centronics-ie wśród 25 pinów złącza znajdziemy: piny 2 do 9 8 bitów wyjścia danych (kierunek komputer drukarka), piny 10 do 13 i 15 5 bitów wejścia statusu (drukarka komputer), piny 1, 14, 16 i 17 4 bity wyjść sterujących (komputer drukarka), piny 18 do 25 masa elektryczna. Opisane linie przekładają się na trzy rejestry, reprezentowane przez trzy kolejne porty w przestrzeni wyjścia-wyjścia. Pierwszym z nich jest rejestr danych, znajdujący się pod tzw. adresem bazowym (czyli... tak, znane już 0x378 dla pierwszego portu równoległego, 0x278 dla drugiego). Reprezentuje on bezpośrednio wyjście danych. Pod adresem większym o 1 (czyli odpowiednio 0x379 lub 0x278) ma swoje miejsce rejestr statusu, reprezentujący na bitach 3-7 piny wejściowe. Adresu ostatniego z rejestrów kontrolnego łatwo się już domyślić. Jest to oczywiście adres bazowy plus dwa 0x37a lub 0x27a. Cztery pierwsze bity są połączone z wyjściami sterującymi. Dokładne zależności między bitami rejestrów pokazuje rysunek 1. Rysunek 1. Piny portu równoległego i ich powiązanie z rejestrami Trójkąty na rysunku oznaczają wzmacniacze logiczne elementy przekładające słabowite zera i jedynki (lub zmęczony długą drogą sygnał wejściowy) na całkiem konkretny strumień elektronów. Widać, że niektóre z linii statusu i kontroli są zanegowane (trójkąty z kółeczkami), czyli ich poziom elektryczny jest dokładnie odwrotny do stanu wynikającego z wartości odpowiedniego bitu rejestru. I odwrotnie gdy urządzenie jeden ze swoich statusów określi jako wysoki, zawartość rejestru podpowie nam, że jest zerem. Takie sytuacje trzeba uwzględniać przy obsłudze podłączanych urządzeń.

37 Podstawy inżynierii jądrowej 37! Uwaga! Port równoległy jest jednym z najbardziej wrażliwych na smażenie interfejsów w typowym PeCecie przed podłączeniem do niego czegokolwiek sprawdź trzy razy czy nie masz nigdzie zwarcia albo 220V... Zostałeś ostrzeżony miłego dnia ;-) 3. Urządzenie Wiemy już czego można się spodziewać po porcie równoległym. Teraz trzeba przygotować coś, czym będziemy sterować. Zróbmy to w dwóch krokach, zbierając jakże cenne doświadczenie. Rysunek 3. Diody wlutowane w złącze diod Najpierw wariant najprostszy. Spójrzmy na schemat na rysunku 2. Rysunek 2. Schemat najprostszego urządzenia Jak widać do każdego z pinów wyjściowych podłączona jest dioda świecąca połączona z opornikiem. Wspomniane wcześniej wzmacniacze zapewnią wystarczająca ilość prądu by je zaświecić. A przynajmniej powinny ;-) Acha i nie trzeba od razu robić specjalnej płytki drukowanej z diodami na pierwszy ogień można zlutować diodę z opornikiem i wetknąć ją do odpowiednich dziurek portu. Ostrożnie! Ja wlutowałem diody w męskie 25-cio pinowe złącze (rys. 3) i podłączam je przez przedłużacz. Jak sprawdzić czy wszystkie powyższe wywody nie są bzdurą wyssaną z palca? I jakość montażu? (jeśli coś nie działa to sprawdź 10 razy czy wszystko prawidłowo połączyłeś i nie zepsułeś jeszcze portu dopiero potem obrzucaj mnie błotem i obelgami ;-) Na dobry początek proponuję prosty programik napisany w C dla środowiska Gnome specjalnie na potrzeby tego artykułu parporter 1. Pomijając szczegóły implementacyjne (w końcu 1 Do pobrania tak jak inne przykłady pod adresem inzynierii jadrowej tekst ten traktować ma o pisaniu modułów jądrowych, a nie aplikacji użytkownika; poza tym oczywiście dostępne są źródła ;-), wykorzystuje on funkcje inb, outb i ioperm zdeklarowane w nagłówku systemowym sys/io.h. Musi być uruchamiany z uprawnieniami użytkownika root, aby mieć uprawnienia skorzystania z tych funkcji. Dodatkowo musi być skompilowany z optymalizacją (opcja kompilatora -O lub -O2 i więcej). W zależności od posiadanego komputera wymagana jest inicjalizacja peryferiów związanych z łączem równoległym. Przy pisaniu sterownika trzeba o tym pamiętać. W moim przypadku (laptop, w którym port równoległy był urządzeniem PNP, które trzeba było zarejestrować) wykopiowałem potrzebne podprogramy z kodu oryginalnego modułu parport pc standardowego sterownik Centronics-a w Linuksie. Na razie wystarczy załadować ten moduł (jeśli po uruchomieniu parporter-a nie potrafimy sterować diodami naszego urządzenia) załatwi wszystko co trzeba... Spójrzmy na okno naszego programu testowego (rys. 4). Po uruchomieniu trzeba wybrać port do którego podłączona jest nasza linijka diodowa. Klikając w przyciski 0-9 i A-D załączamy i wyłączamy odpowiednie światełka. Poniżej przycisków widoczny jest stan portów. Zaobserwować można opisaną inwersję wyjść kontrolnych gdy pierwszy bit rejestru kontrolnego ma wartość 0 dioda podpięta do pinu nr 1 świeci, dla wartości 1 jest zgaszona. Odwrotnie jest w przypadku nie zanegowanego bitu trzeciego (pin 14). Rysunek 4. Zrzut ekranu parporter-a

38 38 Paweł Moll 3.2. Wyświetlacz Docelowym urządzeniem do którego za chwilę napiszemy sterownik jest układ czterocyfrowego wyświetlacza LED, takiego jak stosowane w tanich zegarach elektronicznych. Jego schemat przedstawiony jest na rysunku 5, a gotowy układ zmontowany na płytce uniwersalnej widać na rysunku 6. Rysunek 6. Prototyp wyświetlacza Rysunek 5. Schemat układu wyświetlacza Budowa układu jest nieco bardziej skomplikowana niż w poprzednim przypadku, ale idea jest zbliżona. Do zrozumienia zasady działania przydatny jest schemat wewnętrzny wyświetlacza który zastosowałem 2 rysunek 7. Bity portu danych sterują kolejnymi segmentami wszystkich cyfr wyświetlacza jednocześnie (poprzez załączanie i wyłączanie tranzystorów T5 do T12). Trochę inaczej wykorzystane są bity wyjściowe portu kontrolnego, którego bity sterują tranzystorami T1 do T4, załączającymi lub wyłączającymi całe cyfry. Dwa układy scalone to bufory 2 W moim przypadku był to LTC2623G firmy Lite-On Electronics ( wybór był potraktowany faktem, że wyświetlacz taki... leżał na moim biurku ;-) cyfrowe, odseparowujące port równoległy od stosunkowo sporych prądów płynących przez tranzystory i wyświetlacz i zwiększających szanse naszego Centronics-a na przeżycie. Wartości oporników R13 do R20 zależą od wyświetlacza i powinny być dobrane tak, aby wyświetlacz świecił i to dłużej niż krótką chwilę po załączeniu (czytaj: nie spalił się ;-). Zasilanie wziąłem z portu USB (który doskonale się przecież nadaje do podłączania lampek i podgrzewaczy do kubków ;-), przecinając kabel USB A-B i wykorzystując przewody czerwony (+5V ) i czarny (masa) kolory podobno standardowe dla wszystkich takich kabli. Do pierwszych testów można wykorzystać znanego już parporter-a, który pozwoli pozapalać poszczególne cyfry i wybrać segmenty do wyświetlenia (na wszystkich załączonych cyfrach wyświetlać się będzie ta sama kombinacja segmentów). Jeśli tu wszystko wydaje się będzie działać, proponuję użyć drugiego z programów przykładowych displayer-a (rys. 8). Po jego załączeniu na wyświetlaczu w magiczny sposób pojawią się 4 różne znaki, które w dodatku można zmienić wpisując swój wybór w odpowiednie pole... Magia? Oczywiście że nie. Prosta sztuczka, stosowana w 99% zegarków, zwana multipleksowaniem w każdej chwili widoczna jest tylko jedna cyfra na wyświetlaczu. Chwila jest jednakże na tyle krótka, że nasze niedoskonałe oko daje się oszukać i widzi cały napis. Aby się przekonać że tak jest wystarczy poruszyć suwakiem, który reguluje prędkość odświeżania w skrajnie prawym położeniu cyfra jest zmieniana co sekundę, w skrajnie lewym tak szybko jak się tylko da, będą to czasy rzędu mikrosekund. Można również zauważyć pewien niepożądany efekt np. przy przełączaniu okien klawiszami Alt-Tab wyświetlacz mruga. Wiążę się to z faktem, że program przemiata wyświetlacz w osobnym wątku, który może być wywłaszczony przy operacjach użytkownika. I wtedy odświeżanie wyświetlacza na chwilę zamiera... Spróbujemy się pozbyć tego efektu korzystając ze sterownika urządzenia w jądrze!

39 Podstawy inżynierii jądrowej I w końcu sterownik Tak więc wreszcie stało się. Zaczynamy pisać remedium na całe zło, prawdziwy moduł jądra Linuksa sterownik naszego wyświetlacza... Oczywiście wszyscy wiedzą czym jest moduł, ale dla utrwalenia materiału przypomnę, że jest to kawałek kodu jądra systemu operacyjnego, odpowiedzialny za określoną funkcjonalność (np. obsługę urządzenia zewnętrznego), który może być załadowany w trakcie pracy systemu i od tej pory jest dostępny dla innych komponentów jądra jak i dla procesów użytkownika (o ile udostępnia niezbędne do tego zasoby). W naszym przypadku będzie sterował opisanym układem wyświetlacza, udostępniając użytkownikowi urządzenie (w znaczeniu wpisów w katalogu /dev), służące do zmiany wyświetlanej treści i konfiguracji parametrów pracy. W przypadku jądra Linuksa serii 2.6 gotowe moduły mają rozszerzenie.ko, które można uzyskać korzystając z systemu budowania jądra umożliwia on kompilację plików źródłowych modułu, znajdujących się poza drzewem plików 3. Uzyskuje się to wywołując polecenie: make -C <ścieżka_źródeł_jądra> M=<ścieżka_źródeł_modułu> modules Źródła do kompilacji wskazuje się przygotowując plik Makefile lub (zgodnie z najnowszą nomenklaturą) Kbuild. W naszym przypadku będziemy mieć dwa pliki źródłowe display.c, zawierający główny kod sterownika oraz hardware.c z dodatkową inicjalizacją sprzętu. Wynikiem starań powinien się zaś stać moduł o nazwie led display.ko. W takim układzie komendy dla systemu budowania modułów wyglądać będą następująco: Rysunek 7. Struktura wewnętrzna 4-cyfrowego, 7-segmentowego wyświetlacza LED LTC2623G obj-m := led_display.o led_display-y := display.o hardware.o Aby oszczędzić sobie wpisywania długich parametrów dla make-a można wykorzystać fakt, że w już trakcie kompilacji modułu ustawiona jest zmienna środowiskowa KERNELRELEASE i ukuć następujący plik Makefile: ifneq ($(KERNELRELEASE),) obj-m := led_display.o led_display-y := display.o hardware.o else KERNELDIR?= <ścieżka_do_źródeł_jądra> PWD := $(shell pwd) modules %: $(MAKE) -C $(KERNELDIR) M=$(PWD) $@ endif Rysunek 8. Zrzut ekranu displayer-a Pozwoli on na zbudowanie jądra po prostym wpisaniu make, zaś make clean posprząta w katalogu z modułem. Wyjaśnienia wymaga jeszcze jeden fakt. Aby skorzystać w opisanej wyżej metody budowania modułu trzeba mieć 3 Szczegółowo jest to opisane w dokumentacji dołączonej do źródeł jądra serii 2.6, w pliku Documentation/kbuild/modules.txt

40 40 Paweł Moll własnoręcznie zbudowane ze źródeł jądro (i wtedy wartością KERNELDIR jest ścieżka do tych źródeł) lub odpowiednio przygotowany przez twórcę dystrybucji wyciąg, najczęściej określany jako kernel-headers (szukajmy pakietu o takiej lub zbliżonej nazwie). Wynika to z faktu, że moduł w trakcie kompilacji zostaje opisany numerem seryjnym jądra, generowanym w trakcie budowania jego głównej części. A te będą się różnić nawet dla dwóch różnych kompilacji tej samej wersji jądra. Symptomem takiej sytuacji jest wyświetlany podczas (nieudanego) ładowania modułu komunikat zbliżony do następującego: insmod: error inserting led_display.ko : -1 Invalid module format 4.1. Inwokacja Najprostszą w realizacji funkcjonalnością modułu jest załadowanie (i ewentualnie usunięcie). Rozpatrzmy następujący kod źródłowy: #include <linux/module.h> #include <linux/init.h> static int unsigned long port = 0x378; module_param(port, ulong, S_IRUGO); static int init led_display_init(void) printk(kern_info "LED display driver initialization.\n"); printk(kern_info "LED display port: %#lx.\n", port); return 0; } static void exit led_display_cleanup(void) printk(kern_info "LED display driver cleanup.\n"); } module_init(led_display_init); module_exit(led_display_cleanup); MODULE_DESCRIPTION("LED display driver"); MODULE_LICENSE("GPL"); Mając odpowiedni Makefile skompilujmy nasz moduł zgodnie z opisem i załadujmy. Cóż się stanie? $ sudo insmod led_display.ko $ tail /var/log/messages <...> Aug 30 22:55:22 lx kernel: LED display driver initialization. Aug 30 22:55:22 lx kernel: LED display port: 0x378. Gratulacje! Twój Pierwszy Moduł gotowy! Robi na razie niewiele, ale za to dokładnie to o co zostanie poproszony, czyli przy załadowaniu wywołuje funkcję led_display_init. Robi to na nasze wyraźne polecenie, wyrażone makrem module_init. Jak widać z przytoczonego kawałka loga użyta w kodzie funkcja printk służy do wypisywania komunikatów, potencjalnie przydatnych dla programisty a później użytkownika. I tu ostrzeżenie. W kodzie modułu jądra nie wolno wykorzystywać funkcji standardowej biblioteki C, która w jądrze po prostu nie występuje. Czyli żadnych printf, malloc itp. Większość z nich zresztą ma swoje odpowiedniki i właśnie printk zachowuje się prawie identycznie do znanego wszystkim printf, z drobnymi różnicami w możliwościach formatowania ciągu znaków. Zauważyć można jeszcze użycie stałej KERN_INFO przed treścią komunikatu definiuje ona rodzaj wypisywanej informacji. W zależności od konfiguracji daemona syslog różne poziomy komunikatów pojawiają się w różnych plikach z logami najczęściej są to /var/log/messages i/lub /var/log/syslog 4. Na nasze potrzeby będziemy wykorzystywać jedynie komunikaty KERN_INFO dla komunikatów informacyjnych i KERN_ALERT dla powiadamiania o sytuacjach błędnych. Tajemnicze może być jeszcze wyrażenie init umieszczone przed nazwą funkcji. Jest to dodatkowa informacja dla jądra, że funkcja ta będzie wywołana tylko raz, przy ładowaniu jądra. Później można ją spokojnie usunąć ot, zawsze to oszczędność pamięci. Podobnie do ładowania jądra wygląda jego usuwanie. Makro module_cleanup wskazuje funkcję, która będzie zawołana w takiej sytuacji, co widać na przykładzie: $ sudo rmmod led_display $ tail /var/log/messages <...> Aug 30 22:55:37 lx kernel: LED display driver cleanup. Ostatnią funkcjonalnością wykorzystywaną na tym etapie rozwoju naszego modułu będzie przekazywanie parametrów w czasie ładowania. Popatrzmy na definicję zmiennej port i następujące po niej makro: static int unsigned long port = 0x378; module_param(port, ulong, S_IRUGO); Jak widać inicjowana jest ona dziwnie znajomą wartością 0x378, co potwierdza informacja w przytoczonym logu, wypisana instrukcją: printk(kern_info "LED display port: %#lx.\n", port); I teraz jeśli załadujemy moduł z dodatkowym parametrem, otrzymamy co następuje: $ sudo insmod led_display.ko port=0x111 $ tail /var/log/messages <...> Aug 31 14:07:40 lx kernel: LED display driver initialization. Aug 31 14:07:40 lx kernel: LED display port: 0x Można też stosować aplikację xconsole, która komunikaty jądra wypisuje po prostu w okienku.

41 Podstawy inżynierii jądrowej 41 Wartość zmiennej port jest inna! Czarodziejem jest oczywiście makro module_param, które powoduje zmianę wartości zmiennej podanej jako jego pierwszy parametr, jeśli w linii polecenia ładowania modułu znajdzie się wartość o tej samej nazwie. Drugi parametr opisuje typ wprowadzanych danych. Poza użytym ulong istnieją jeszcze np. int, uint, bool dokładną ich listę i opis znaleźć można w dokumentacji jądra. Ostatni parametr to tryb dostępu do wartości parametru przez pseudo-system plików sys. Dla naszych potrzeb niech to będzie wartość wyłącznie do odczytu, co zapewnia stała S_IRUGO. Na koniec wspomnieć można jeszcze o makrach MODULE_DESCRIPTION i MODULE_LICENSE, które zwyczajowo definiuje się na końcu kodu. Definiują one odpowiednio opisową nazwę modułu i licencję, na której został opublikowany. Jeśli ciąg znaków opisujący licencję będzie inny niż kilka akceptowanych (z którego oczywiście najwłaściwszym jest GPL ;-) jądro zostanie skażone (ang. tainted). Efektem będzie kilka komunikatów informujących o tym oraz ostracyzym społeczności, w przypadku zgłaszania problemów ze skażonym jądrem (fakt ten widać to na tzw. oops-ach, wypisywanych w przypadku niedozwolonej operacji) oraz ewentualne problemy z dostępem do symboli (najczęściej funkcji udostępnianych przez inne komponenty jądra) zadeklarowanych jako dostępnych wyłącznie dla modułów na koszernych licencjach Dostęp do portów Czas najwyższy porozumieć się z naszym wyświetlaczem, który już od dłuższego czasu nudzi się, podłączony do komputera... Wiemy już, że sterujemy jego diodami ustawiając odpowiednie wartości w rejestrach portu równoległego. Robi się to funkcjami rodziny in* oraz out*. Warto je wcześniej zarezerwować, do czego służy funkcja request_region to zapewni nam wyłączność. Trzeba jednakże pamiętać, że w większości dystrybucji domyślnie jest ładowany standardowy moduł obsługi portu równoległego, który prawdopodobnie zrobił dokładnie to samo i skutecznie uniemożliwi załadowanie naszego kodu. Objawi się to takim komunikatem: nsmod: error inserting led_display.ko : -1 No such device Dlatego teraz jest najlepszy moment na usunięcie modułu parport pc i innych z niego korzystających. Najpierw poleceniem $ lsmod grep parport_pc sprawdźmy czy intruz jest w ogóle załadowany i, jeśli tak, jakie inne moduły z niego korzystają, a następnie usuńmy je w kolejności odwrotnej do wyświetlonej korzystając z polecenia rmmod. U mnie linia polecenia usuwająca wszystko co trzeba wygląda następująco: $ sudo rmmod ppdev lp parport_pc parport Oczywiście do wszystkich operacji na modułach niezbędne jest posiadanie uprawnień administratora. Osobiście korzystam w takich sytuacjach z sudo, ale to już zupełnie inna opowieść... ;-) Droga wolna, więc działajmy. Funkcja inicjująca będzie teraz wyglądała następująco: static int init led_display_init(void) printk(kern_info "LED display driver initialization.\n"); printk(kern_info "LED display port: %#lx.\n", port); if (led_hardware_init() == 0) if (request_region(port, 3, "LED display")!= NULL) outb(0x02, port + 2); // Select some digits outb(0x5b, port); // Select some segments return 0; } else printk(kern_alert "Can t request ports!\n"); return -ENODEV; } } else printk(kern_alert "Can t init hardware!\n"); return -ENODEV; } } Kompilujemy, uruchamiamy, i? No cóż, ja widzę na dwóch skrajnych cyfrach wyświetlacza dwie dwójki mam nadzieję że nie jestem osamotniony. Co jest przyczyną tego stanu rzeczy? Po kolei. Na początek wywoływana jest funkcja led_hardware_init, zdefiniowana w pliku hardware.c jak już wspominałem w moim przypadku konieczne było zarejestrowanie urządzenia Plug-and-Pray (przepraszam Play) odpowiadającego za port równoległy. Generalnie ma ona doprowadzić do stanu, w którym możliwe jest sterowanie rejestrami portu. Jeśli zadział Ci parporter bez załadowanego modułu parport pc nie musisz robić nic, zostaw wspomnianą funkcję pustą. Niepowodzenie wypisuje odpowiedni komunikat (na poziomie KERN_ALERT) i kończy działanie funkcji, zwracając kod błędu. Przy okazji warto wspomnieć, że z punktu widzenia systemu operacyjnego załadowanie modułu powiedzie się jedynie wówczas, gdy funkcja inicjująca zwraca wartość 0. Każda inna oznacza błąd, przy czym warto się trzymać zdefiniowanych stałych w naszym przypadku będzie to błąd ENODEV (zwyczajowo z ujemnym znakiem). Podobnie zachowamy się, jeśli nie powiedzie się (czyli zwróci wartość NULL) wspomniana już funkcja request_region. Przyjmuje ona trzy parametry, z których pierwszy to adres pierwszego interesującego nas

42 42 Paweł Moll portu, drugi ilość kolejnych portów do rezerwacji, a ostatni to nazwa czy też opis celu, do którego porty owe będą wykorzystywane. Po pomyślnym załadowaniu takiego modułu, odczytując plik /proc/ioports zobaczymy coś takiego: $ cat /proc/ioports <...> 02f8-02ff : serial a : LED display 03c0-03df : vesafb <...> Znajdujące się dalej wywołania funkcji outb (pierwszy parametr to wartość do ustawienia, drugi to adres portu) ustawiają przykładowe wartości, które mają wymusić opisany wygląd wyświetlacza. Można je wcześniej przetestować używając nieocenionego parporter-a. A co z usuwaniem modułu? Należy być wtedy uprzejmym i posprzątać po sobie, wykonując czynności komplementarne do inicjujących (oczywiście w odwrotnej kolejności): static void exit led_display_cleanup(void) printk(kern_info "LED display driver cleanup.\n"); release_region(port, 3); led_hardware_cleanup(); } 4.3. Wykonanie cykliczne Przejdźmy teraz do realizacji sztuczki z multipleksowanym wyświetlaniem napisów na wyświetlaczu. Natychmiast powstaje pytanie jak zapewnić cykliczne wykonanie funkcji. Od razu porzucić można wszelkie pomysły w rodzaju pętli w funkcji inicjacyjnej, usypianej na jakiś czas inicjacja ma się rozpocząć, zrobić swoje i zakończyć, a urządzenie od tego momentu ma funkcjonować. Można próbować tworzyć wątek jądra zawierający taką pętlę (podobne rozwiązanie jest użyte w znanym już programie displayer), ale to znowuż jest wyciąganie armaty na wróbla. Na całe szczęście problem okresowego wysyłania lub odbierania danych jest na tyle powszechny w świecie sterowników urządzeń, że istnieje na tą okoliczność specjalny mechanizm zwany z angielska timer-ami. Trudno znaleźć dobry polski odpowiednik tej nazwy, gdyż ani stoper ani czasomierz nie oddają dobrze zasady jego działania, które wyjaśnimy na przykładzie naszego sterownika. Na początku trzeba zdefiniować kilka zmiennych globalnych dla modułu: static struct timer_list display_timer; static unsigned char *display_buffer = "1234"; static int display_digit = 0; static int display_period = 500; // ms Pierwsza z nich to struktura zdefiniowana w nagłówku linux/timer.h i wykorzystywana jako identyfikator timer-a. Następny jest bufor wyświetlacza zawiera ciąg znaków, które mają być wyświetlone. display_digit przechowuje numer cyfry wyświetlacza, którą należy załączyć w następnym okresie, zaś display_period określa czas trwania jednego okresu w milisekundach. W funkcji inicjującej moduł w miejsce wywołań funkcji out, które wyświetlały coś wstawić trzeba kod ustawiający nasz timer: if (request_region(port, 3, "LED display")!= NULL) // outb(0x02, port + 2); // Select some digits // outb(0x5c, port); // Select some segments } init_timer(&display_timer); display_timer.function = display_now; display_schedule(); return 0; init_timer to funkcja jądra, inicjująca strukturę opisu timer-a. Dwie pozostałe funkcje display_now i display_schedule są zdefiniowane przez nas. Pierwsza z nich, przypisywana do pola function struktury, będzie wykonywana po upłynięciu zdefiniowanego okresu czasu. Druga nakręca zegarek : static void display_schedule(void) display_timer.expires = jiffies + display_period * HZ / 1000; add_timer(&display_timer); } Funkcja add_time rozpoczyna odliczanie, zaś pole expires struktury określa czas następnego zawołania funkcji wybranej przez użytkownika. Jest to czas bezwzględny, dlatego też trzeba wiedzieć, która jest godzina aktualnie. Informację taką dostarcza nagłówek linux/jiffies.h, deklarując zmienną jiffies. Jest to ilość wygenerowanych przerwań zegarowych licząc od startu systemu. Biorąc pod uwagę, że następuje to HZ razy na sekundę, przeliczenie z milisekund na dżiffi jest proste: jiffie = czas[ms] HZ 1000 Pozostaje jeszcze tylko omówić funkcję display_now: static void display_now(unsigned long arg) // Select digit // Control port: "x x x x ~1 2 ~3 ~4" outb( (1 << (3 - display_digit)) ^ 0x0b, port + 2); // Display symbol, selecting proper segments // Data port: "DP G F E D C B A" outb(led_symbols[display_buffer[display_digit]], port); display_digit = (display_digit + 1) % 4;

43 Podstawy inżynierii jądrowej 43 } display_schedule(); Nie jest ona zbyt skomplikowana. Na dobry początek wybieramy cyfrę, która będzie wyświetlona w danym okresie, ustawiając odpowiednią wartość na porcie kontrolnym Centronics-a (uwzględniając sposób podłączenia wyświetlacza i negację niektórych bitów portu równoległego). Później należy wyświetlić kształt odpowiedniego znaku z bufora. Przeliczenie znaku w kodzie ASCII na odpowiednią kombinację segmentów wyświetlacza siedmio-segmentowego zrobione jest w o tyleż prymitywny co skuteczny sposób tablica led_symbols (znajdująca się w prywatnym nagłówku symbols.h) zawiera 256 liczb, będących odwzorowaniem znaku o danym kodzie (a przynajmniej najlepszą jak to się da zrobić na siedmiu segmentach podobizną ;-). W tym momencie praca została wykonana, pozostaje jeszcze zainicjować następny okres, obliczając numer następnej cyfry do wyświetlenia oraz wołając znaną już funkcję display_schedule. A w przypadku, gdy trzeba wstrzymać odliczanie czasu, np. w przypadku usuwania modułu funkcja del_timer(&display_timer) załatwi sprawę. Tak napisany moduł po skompilowaniu powinien wyświetlać poszczególne cyfry ciągu znajdującego się w buforze, zmieniając wyświetlaną cyfrę co pół sekundy. Działa? To teraz zmodyfikujmy kod, przypisując zmiennej display_period wartość 1. Po załadowaniu takiej wersji cały zobaczymy na wyświetlaczu pełne Tak więc doszliśmy do punktu, w którym znajduje się diplayer, tyle że teraz można zauważyć że przełączanie okienek i inne czasochłonne operacje w przestrzeni użytkownika nie wpływają na jakość wyświetlania nie można zaobserwować żadnego mrugania itp. Cel osiągnięty! 4.4. Urządzenie /dev/led display Powiedzmy osiągnięty częściowo, gdyż jak na razie nie ma żadnego sposobu, by zwykły użytkownik zmienił treść wyświetlanego komunikatu. A przecież sterownik dowolnego urządzenia powstaje najczęściej po to, aby człowiek miał wpływ na jego działanie. W systemach rodziny UN*X typowym sposobem komunikacji między przestrzeniami użytkownika a jądra są urządzenia systemowe (devices). Zgodnie z ideą everything is a file są one reprezentowane przez pliki znajdujące się w katalogu /dev. Przykładowo powszechnie znany plik /dev/hda z powodzeniem wykorzystać można (mając odpowiednie uprawnienia) do zamazania zawartości dysku twardego. Rozróżnić można dwie niezależne rodziny urządzeń. Pierwsza to urządzenia blokowe (block devices, np. wspomniany dysk twardy), charakteryzujące się swobodnym dostępem do danych (możnba przeczytać sektor pierwszy, potem trzeci, potem drugi itd.), za to mające pewne ograniczenia dotyczące odczytu i zapisu (może nie być możliwy dostęp do pojedynczego bajtu danych, a tylko np. zapis lub odczyt całego sektora). Drugi rodzaj to urządzenia znakowe, w których dane przesyłane są bajt po bajcie, za to czasem nie jest możliwe przewijanie nośnika, czyli dostęp swobodny (raz wysłany łączem szeregowym czy równoległym znak przepada w przestrzeni i nie można już z nim nic zrobić......). Zerknijmy na kilka przykładowych plików w katalogu /dev: $ ls -l /dev <...> brw-rw root disk 3, 0 <...> /dev/hda brw-rw root disk 3, 1 <...> /dev/hda1 <...> crw-rw root lp 99, 0 <...> /dev/parport0 <...> Jak widać wspomniane urządzenie dysku twardego jest opisane literą b na początku linii, zaś drukarka (parport0) literą c. Łatwo się domyślić że jest to związane z ich charakterem. Biorąc pod uwagę, że wyświetlacz jest podłączony do tego samego złącza co drukarka, przyjmijmy, że sterownik wyświetlacza będzie obsługiwany przez urządzenie znakowe. Dodatkowo ten typ urządzeń jest po prostu prostszy w oprogramowaniu. Na przytoczonym wyżej fragmencie katalogu /dev uwage przykuć mogą cyfry 3, 0 czy 99, 0. Są to tzw. liczby główne i dodatkowe (jest to moje swobodne tłumaczenie wyrażenia major and minor numbers ;-) Łaczą one plik urządzenia z jego sterownikiem. Na podstawie liczby głównej jądro określa sterownik, do którego trafić mają odwołania z przestrzeni użytkownika. Istotny jest fakt, że numeracja dla urządzeń blokowych i znakowych jest całkowicie rozłączna istnieje zarówno urządzenie blokowe o numerze 3 (/dev/hda*) jak i znakowe (/dev/ttyp*). Tak więc operacje na plikach blokowych oznaczonych liczbą główną 3 (nazwa tak naprawdę nie ma znaczenia z punktu widzenia jądra) trafią do sterownika dysku twardego ATA. Liczba dodatkowa jest już rozróżniania przez sam sterownik i przykładowo w przypadku dysku definiuje kolejne partycje. Wszystko to oznacza, że każdy ze sterowników powinien mieć swój własny i niepowtarzalny numer główny. Nie jest to oczywiście możliwe całkowite spełnienie to warunku trudno zapewnić, że dwóch programistów znajdujących się w dwóch przeciwnych końcach świata nie wybierze tego samego numeru dla sterownika glebogryzarki i silnika rakietowego... Dlatego też istnieje (obecnie już raczej nierozszerzana) lista tzw. dobrze znanych numerów (well known numbers), obejmująca najczęściej spotykane urządzenia (dyski twarde, terminale itp.). Autor sterownika dla bardziej egzotycznych gadżetów musi korzystać z dynamicznej alokacji numerów głównych (przy każdym załadowaniu modułu zostanie mu przypisana liczba główna, ważna aż do jego usunięcia)), co też zrobimy w funkcji inicjującej naszego modułu. Jej ostateczna postać, uzględniająca potrzebę sprzątania po sobie w przypadku niepowodzenia poszczególnych etapów działania (jest to według mnie jedynie dopuszczalne zastosowanie goto w języku C) wygląda następująco: static int init led_display_init(void) printk(kern_info "LED display driver initialization.\n");

44 44 Paweł Moll printk(kern_info "LED display port: %#lx.\n", port); alloc_chrdev_region(&device, minor, 1, "led_display") if (led_hardware_init()!= 0) printk(kern_alert "Can t init hardware!\n"); goto error_hardware; } if (request_region(port, 3, "LED display") == NULL) printk(kern_alert "Can t request ports!\n"); goto error_port; } if (alloc_chrdev_region(&device, minor, 1, "led_display")!= 0) printk(kern_alert "Can t allocate device!\n"); goto error_device; } major = MAJOR(device); cdev_init(&cdev, &fops); cdev.owner = THIS_MODULE; if (cdev_add(&cdev, MKDEV(major, minor), 1)!= 0) printk(kern_alert "Can t register char device!\n"); goto error_cdev; } Rezerwuje ona jedno (trzeci parametr) urządzenie pod głównym numerem, który można chwilę później wyczytać ze struktury device za pomocą makra MAJOR(device) (istnieje oczywiście również analogiczne makro MINOR, którego działania łatwo się domyślić). Numerem dodatkowym urządzenia będzie zero (taką wartością jest inicjowana zmienna minor), a jego nazwa to led_display. Po załadowaniu takiego modułu można poznać przyznany numer główny, zaglądając do pliku /proc/devices: $ cat /proc/devices Character devices: <...> 253 led_display <...> Znając numer główny można stworzyć plik urządzenia o uzyskanym numerze i rozpocząć komunikację. Jednakże biorąc pod uwagę, że numer ten może się zmieniać, dobrze jest przygotować skrypt, który niezbędne czynności wykona automatycznie: #!/bin/sh module="led_display" device="led_display" mode="664" group="admin" sudo="sudo" $sudo} insmod./$module.ko $* exit 1 init_timer(&timer); timer.function = display_now; timer.data = 0; schedule_display(); return 0; error_cdev: unregister_chrdev_region(device, 1); error_device: release_region(port, 3); error_port: led_hardware_cleanup(); error_hardware: return -ENODEV; } Przy czym wcześniej zdeklarowanych jest kilka zmiennych globalnych dla modułu: static dev_t device; static int major; static int minor = 0; static struct cdev cdev; static int opened = 0; Do otrzymania numeru głównego służy funkcja major=$(awk "\$2==\"$module\" print \$1}" /proc/devices) $sudo} rm -f /dev/$device} $sudo} mknod /dev/$device} c $major 0 $sudo} chgrp $group /dev/$device} $sudo} chmod $mode /dev/$device} W kodzie modułu pozostaje już tylko zarejestrować obsługę urządzenia o znanych numerach: cdev_init(&cdev, &fops); cdev.owner = THIS_MODULE; cdev_add(&cdev, MKDEV(major, minor), 1); Funkcja cdev_init przygotowuje strukturę opisującą urządzenie znakowe cdev (do struktury fops za chwilę przejdziemy), następnie jej polu owner przypisywana jest stała określająca aktualny moduł. Wreszcie cdev_add wieńczy dzieło, rejestrując strukturę w jądrze, dla urządzenia o zadanych numerach (makro MKDEV jest komplementarne do pary MAJOR i MINOR). Trzeci parametr określa ilość urządzeń podpiętych do jednego numeru dodatkowego. W typowym przypadku jak na przykład u nas przyjmuje wartość 1. Pozostaje pytanie jak obsługiwać żądania płynące z przestrzeni użytkownika. Odpowiedzią jest struktura fops,

45 Podstawy inżynierii jądrowej 45 która opisuje funkcje obsługujące operacje na pliku urządzenia: static struct file_operations fops =.owner = THIS_MODULE,.open = led_open,.release = led_release,.read = led_read,.write = led_write,.ioctl = led_ioctl, }; Możliwych sytuacji (a więc i pól w strukturze) jest dużo więcej, ale w naszym przypadku ograniczymy się do podstawowych. Na początek zajmiemy się parą funkcji wywoływanych przy otwieraniu i zamykaniu pliku urządzenia: int led_open(struct inode *inode, struct file *file) printk(kern_debug "LED display: open()\n"); if (opened) return -EMFILE } opened = 1; return 0; int led_release(struct inode *inode, struct file *file) printk(kern_debug "LED display: release()\n"); opened = 0; return 0; } Są one wyjątkowo proste druga zawsze się kończy powodzeniem (zwracając wartość 0), zeruje również wartość zmiennej opened, od której stanu zależy, czy otwarcie pliku urządzenia się powiedzie. Jak widać stanie się tak tylko wtedy, gdy wspomniana zmienna jest wyzerowana zostanie jej zresztą zaraz potem przypisana wartość 1. Jest to bardzo prymitywne 5 zabezpieczenie przed otwarciem przez kilku klientów jednocześnie. Warto jeszcze zwrócić uwagę na dwie sprawy. Po pierwsze, warto zwracać standardowe kody błędów użyty przez nas kod EMFILE opisywany jest w nagłówku asm/errno.h jako Too many open files, co dość dobrze oddaje naturę problemu. Po drugie do wypisywania komunikatów sterownika w miejscach, które mogą być często wykonywane, dobrze jest korzystać z poziomu KERN_DEBUG, który w wielu dystrybucjach jest domyślnie wysyłany do /dev/null, co zapobiega niepotrzebnemu zapełnianiu logów, ale też potrafi wprowadzić początkującego twórcę sterowników w błąd i konfuzję. 5 Prymitywne i w dodatku czasami nieskuteczne w przypadku tzw. wyścigu przy jednoczesnym otwieraniu pliku urządzenia przez kilka aplikacji może nie zadziałać. Nie będziemy się tu jednak tym przejmować. Zajmijmy się teraz operacją odczytu przyjmijmy, że powinna zwracać zawartość bufora wyświetlacza, a więc oddawać jego aktualny wygląd. Funkcjonalność ta jest raczej średnio przydatna, za to w innych urządzeniach może być kluczowa, warto więc poznać zasadę: ssize_t led_read(struct file *file, char user *target, size_t count, loff_t *pos) ssize_t res = 0; printk(kern_debug "LED display: read()\n"); } if (count > 4) count = 4; if (copy_to_user(target, buffer, count) == 0) res = count; else res = -EFAULT; return res; I od razu przykład zastosowania: $ cat /dev/led_display <Ctrl+C> $ Od razu zauważyć można, że odczyt kręci się w kółko. Spowodowane jest to faktem, że o ile nie wystąpi błąd w kopiowaniu danych między przestrzeniami jądra a użytkownika (za chwilę), zawsze zwracamy wartość 4 (lub mniej, jeśli parametr count, czyli ilość bajtów, które użytkownik spodziewa się odczytać jest mniejsza niż 4). Jeśli chcielibyśmy zasygnalizować koniec pliku, a więc sytuację, gdy nie ma (i nie będzie) więcej danych do odczytu, należałoby zwrócić w tej funkcji wartość 0. Ale najważniejszym fragmentem tej funkcji jest przekazywanie danych z bufora wyświetlacza do przestrzeni użytkownika za pomocą wywołania copy_to_user(target, buffer, count) Jak widać pierwszym parametrem jest zmienna target (przekazywana przez jądro jako argument funkcji), który zawiera wskaźnik, do którego nie wolno odwoływać się bezpośrednio. Jedynym dopuszczalnym sposobem jest użycie przytoczonej funkcji jądra, która przenosi żądaną ilość bajtów (trzeci parametr) danych z pamięci przestrzeni jądra do góry w bezpieczny sposób. Zwraca ona wartość 0 w przypadku powodzenia lub inną w sytuacji błędnej. Przyjęło się, że cała funkcja operacji zwraca wtedy kod błędu EFAULT. Dużo przydatniejszą operacją będzie zapis, którym przekazywane będą znaki przeznaczone do wyświetlenia. Dla uniknięcia konieczności alokowania dodatkowych buforów (co jest oczywiście możliwe, ale alokacja pamięci w jądrze to temat na osobny tekst pokaźnych rozmiarów) założymy, że wyświetlane będą zawsze ostatnie 4 znaki

46 46 Paweł Moll przekazywanych ciągów, lub w przypadku krótszych zapisów (ponownie argument count) wyrównane do prawej strony, z przesunięciem poprzedniej zawartości w lewo. Mówiąc obrazowo mają się wyświetlać zawsze ostatnie cztery znaki drukowane kolejno na długiej taśmie papierowej ;-) ssize_t led_write(struct file *file, const char user *source, size_t count, loff_t *pos) ssize_t res = 0; } printk(kern_debug "LED display: write()\n"); if (count < 4) memmove(buffer, buffer + count, 4 - count); if (copy_from_user( buffer + (4 - count),source, count) == 0) res = count; else res = -EFAULT; } else if (copy_from_user( buffer, source + count - 4,4) == 0) res = count; else res = -EFAULT; } return res; Szybki test powyższej funkcjonalności pozwoli przeprowadzic każda (no, prawie) powłoka. Wykonanie polecenia 6 : $ echo -n "Abcd" > /dev/led_display wyświetli coś na kształt wspomnianych liter ;-) Jak? Po prostu echo otworzy nasze urządzenie, zapisze do niego żądany ciąg znaków i zaraz potem je zamknie. A efekt pozostanie... Dla pełnej demonstracji działania naszego urządzenia powstał program controller (rysunek 9), nieco zbliżony do displayer-a, jednakże korzystający z urządzenia /dev/led display, zamiast z bezpośredniego dostępu do portów. Na starcie controller otwiera to urządzenie standardową funkcją systemową open (a więc wystarczy mieć prawa do urządzenia, niekoniecznie mając uprawnienia użytkownika root, jak to było w dwóch pierwszych programach): int device = open("/dev/led_display", O_RDWR); Kliknięcie przycisku Display spowoduje zapis (funkcją write) ciągu znaków wprowadzonych w pole tekstowe zgodnie z tym, co zostało napisane wyżej, wyświetlacz pokaże 4 ostatnie znaki ciągu. write(device, text, strlen(text)); Wartość suwaka inicjowana jest czasem okresu odświeżania, pobranego z urządzenia odpowiednią komendą IOCTL (za chwilę więcej o nich): int period = ioctl(device, LED_DISPLAY GET_PERIOD); zaś jego przesunięcie spowoduje ustawienie nowej wartości okresu: Widać, że sytuacja jest bardzo zbliżona do odczytu. Występuje funkcja do przesyłu danych między obiema przestrzeniami, jedynie kierunek się zmienia celem (pierwszy parametr) jest bufor w przestrzeni jądra, zaś źródłem (parametr drugi) obszar użytkownika. Trzeci parametr oraz wartość zwracana mają identyczne znaczenie. Zaznaczyć trzeba w tym miejscu, że tak napisana funkcja jest nieodporna na szereg zdarzeń, które mogą nastąpić np. w przypadku jednoczesnego zapisu przez więcej niż jeden wątek użytkownika. Dla prostoty przykładów pomińmy jednak te czynniki, mając w pamięci, że istnieją i wcześniej czy później przy rozwoju sterowników trzeba będzie się z nimi zmierzyć. ioctl(device, LED_DISPLAY SET_PERIOD, period); Nic prostszego, czyż nie? Słowa komentarza wymagają jeszcze polecenia IOCTL. Jest to POSIX-owy sposób przekazywania komend sterujących. Wykonanie tej funkcji w przestrzeni użytkownika spowoduje wywołanie w jądrze właściwej funkcji obsługi, o ile oczywiście została zarejestrowana. W przypadku naszego modułu funkcja wygląda następująco: int led_ioctl(struct inode *inode, struct file *file, unsigned int command, unsigned long argument) int res = 0; printk(kern_debug "LED display: ioctl(command=%#x, argument=%lu)\n", command, argument); Rysunek 9. Zrzut ekranu controller-a switch (command) 6 Opcja -n powstrzyma polecenie echo of wysłania znaku końca linii, który by zajął ostatnią cyfrę wyświetlacza.