Fragmenty artykułów z książek wydawnictwa Helion.pl
Dodano: poniedziałek, 14 listopad 2011r.
Poradnik przeznaczony jest nie tylko dla zaawansowanych użytkowników i administratorów systemu Ubuntu Serwer ale także dla początkujących użytkowników chcących rozwijać swoje umiejętności, które będzie można wykorzystać w Ubuntu zainstalowanym na domowym komputerze.
Przedstawione przykłady pochodzą z Ubuntu, ale analiza będzie dotyczyła ogólnej koncepcji kryjącej się za pakietami.
Pierwsza część rozdziału nr 3 Zarządzanie pakietami z książki:
Ubuntu Serwer. Oficjalny podręcznik. Wydanie II
Na początku rozdziału zostaną przedstawione ogólne informacje na temat pakietów. Skoncentrujemy się na podstawowych funkcjach pakietów oraz systemach zarządzania pakietami dostępnych w większości dystrybucji GNU/Linux. Czytelnik dowie się, czym są pakiety oraz jakie są zadania systemów zarządzania pakietami. Wprawdzie przedstawione przykłady pochodzą z Ubuntu, ale analiza będzie dotyczyła ogólnej koncepcji kryjącej się za pakietami. Po solidnym omówieniu podstaw zostaną zaprezentowane pakiety projektu Debian — ten rodzaj pakietów jest stosowany w Ubuntu — a także pokrótce inne, odmienne rodzaje pakietów: kodu źródłowego oraz binarne. Natomiast w pozostałej części rozdziału skoncentrujemy się na zarządzaniu pakietami w Ubuntu za pomocą narzędzi powłoki. Wprawdzie wielu użytkowników biurkowej wersji Ubuntu zna procedurę uaktualnienia systemu, jednak w rozdziale będzie przedstawiona taka procedura, tyle że przeprowadzana bez użycia interfejsu graficznego. Czytelnik pozna podstawowe i bardziej zaawansowane sposoby używania systemów zarządzania pakietami, które wielu administratorów serwerów uzna za przydatne. Wreszcie ostatnie poruszone zagadnienie — tworzenie, modyfikowanie i rozprowadzanie własnych pakietów — będzie szczególnie interesowało zaawansowanych użytkowników i administratorów.
W systemie Ubuntu — oraz innych środowiskach GNU/Linux — pakiety są podstawowym sposobem tworzenia, implementacji i instalacji oprogramowania. Niemal każda ważniejsza dystrybucja systemu operacyjnego GNU/Linux rozprowadza oprogramowanie w postaci pakietów; dotyczy to zarówno plików binarnych, jak i kodu źródłowego. Wspomniane pakiety są najczęściej w formacie RPM (na przykład w dystrybucji Red Hat) lub DEB (projekt Debian) dla oprogramowania binarnego oraz odpowiadających im formatów RPM i DEB dla kodu źródłowego. Ponieważ Ubuntu jest ściśle powiązane z projektem Debian i kontynuuje stosowanie jego osiągnięć, to jest oczywiste, że Ubuntu stosuje pakiety w formacie DEB.
Upraszczając, pakiety stanowią alternatywę dla procesu pobierania, budowania i instalacji oprogramowania zupełnie od zera. W stosunku do standardowego modelu „budowy na podstawie kodu źródłowego” pakiety oferują pewne istotne zalety pod względem instalacji, usuwania, monitorowania i wzajemnych relacji między oprogramowaniem. Ponieważ stosowanie pakietów nie jest aż tak bardzo rozpowszechnione poza światem GNU/Linux — lub przynajmniej nie jest przedstawiane w takich kategoriach — to przed przejściem do omawiania sposobu implementacji pakietów w Ubuntu warto wcześniej poznać pewne ogólne informacje dotyczące pakietów.
Niemal każdy system operacyjny bazujący na GNU/Linux — Fedora, RHEL, openSUSE, Slackware, Debian i inne — zawiera prawie że w całości taki sam zestaw oprogramowania podstawowego. Z definicji każdy z wymienionych systemów operacyjnych zawiera jądro opracowane przez Linusa Torvaldsa oraz dużą ilość oprogramowania w postaci projektów GNU, czyli aplikacji przeznaczonych dla programistów i użytkowników, a niezbędnych do zbudowania i używania tego systemu. Większość wymienionych systemów operacyjnych zawiera także oprogramowanie typowo serwerowe, na przykład OpenSSH, Apache, implementację systemu X Window w postaci XFree86 lub X.org oraz bardzo często wyjątkowo obszerną kolekcję narzędzi powłoki i aplikacji graficznych. Warto w tym miejscu wyraźnie powiedzieć, że wymieniona kolekcja oprogramowania nosi nazwę dystrybucji. Ubuntu jest dystrybucją. Kiedy użytkownicy używają pojęcia „Linux” w odniesieniu do systemu operacyjnego, wówczas bardzo często mają na myśli system Linux lub dystrybucję GNU/Linux.
Podstawowym celem wszystkich dystrybucji jest zapewnienie automatycznej instalacji, konfiguracji, usuwania, obsługi i uaktualniania oprogramowania — zarówno poprzez dostarczenie przeznaczonej do tego infrastruktury, jak również utworzenie zmodyfikowanych wersji istniejącego już oprogramowania. Wspomniane modyfikacje istniejącego oprogramowania w taki specjalny sposób noszą nazwę „przygotowywania pakietów” i stanowią większą część zadań wykonywanych przez programistów Ubuntu. W ogromnym stopniu ma to wpływ na konkretną zawartość dystrybucji Ubuntu. Chociaż przygotowywanie pakietów to podstawowe zadanie przeprowadzane przez twórców dystrybucji takich jak Ubuntu, zadanie to może być wykonywane także przez użytkowników dystrybucji lub dostawców oprogramowania. Celem tych pierwszych jest zapewnienie czystej integracji oprogramowania niedostarczanego w pakietach, natomiast celem tych drugich jest ułatwienie użytkownikom procesu instalacji i obsługi danego oprogramowania.
Utworzenie pakietu — zarówno w Ubuntu, jak i innych dystrybucjach — rozpoczyna się od oprogramowania, które ma być umieszczone w pakiecie. W większości przypadków, ale nie zawsze, oznacza to nabycie odpowiedniego kodu źródłowego. We wszystkich sytuacjach kod trzeba pobrać z oryginalnego kodu źródłowego, co w świecie dystrybucji zwykle nosi nazwę „upstream”. Następnym krokiem będzie utworzenie dodatkowych metadanych, w których najczęściej znajdują się następujące dane:
Powyższe informacje będą używane przez system zarządzania pakietami lub dowolny program pozwalający użytkownikowi na wyszukiwanie, sortowanie i pracę z zainstalowanym bądź dostępnym do instalacji oprogramowaniem — to jedno z zadań systemu zarządzania pakietami. Jednak choć przedstawione powyżej metadane są ważne dla użytkowników, ponieważ pozwalają na uzyskanie dalszych informacji na temat danego oprogramowania, najważniejsza grupa metadanych dodawanych do pakietów dotyczy dokumentacji dotyczącej powiązania oprogramowania znajdującego się w pakiecie z innymi pakietami w dystrybucji. Wprawdzie składnia i semantyka różnią się w zależności od dystrybucji, ale zawarte tam informacje są podobne i odwołują się do:
Nowoczesne systemy zarządzania pakietami rejestrują jeszcze większą ilość informacji. Przykładowo w trakcie uaktualniania oprogramowania pliki konfiguracyjne w przeciwieństwie do zwykłych plików nie mogą być po prostu zastąpione nowszą wersją. Z tego powodu systemy zarządzania pakietami mają wbudowane infrastruktury odpowiedzialne za sprawdzanie i przechowywanie podstawowych informacji na temat konfiguracji. Te dane są wykorzystywane podczas uaktualniania pakietów wymagających wprowadzania zmian w plikach konfiguracyjnych. Wreszcie ostatnim zdefiniowanym celem pakietów jest dostarczenie struktury zbudowanej wokół metadanych pakietu — takich jak opisy — które mogą być tłumaczone w celu dostarczenia użytkownikowi interfejsu prowadzącego do oprogramowania zlokalizowanego w jego języku i kulturze. Szczegółowe informacje dotyczące tworzenia i uzyskiwania dostępu do tych wszystkich metadanych w pakietach Ubuntu będą przedstawione w kolejnych podrozdziałach.
Szeroka gama funkcji może być uznawana za podstawowe funkcje systemu zarządzania pakietami. Wspomniane funkcje najczęściej są implementowane przez narzędzia lub zestaw narzędzi niskiego poziomu. W przypadku projektów Ubuntu i Debian będzie to skrypt dpkg i powiązane z nim inne skrypty. W przeszłości były to podstawowe narzędzia używane przez większość użytkowników do przeprowadzania wszelkich zadań związanych z pakietami. Jednak sytuacja uległa zmianie kilka lat temu, gdy utworzono wysokiego poziomu narzędzia zarządzania pakietami. Wspomniane narzędzia zapewniają interfejs dla narzędzi niskiego poziomu. Większość użytkowników systemów operacyjnych bazujących na pakietach rzadko więc używa już narzędzi niskiego poziomu. Nadal są one stosowane przez programistów bądź administratorów, którzy chcą tworzyć własne pakiety. Ujmując ogólnie i bardzo nieprecyzyjnie, wiele z tych narzędzi niskiego poziomu odpowiada narzędziu apt używanemu w Ubuntu i Debianie.
Podstawowym celem pakietów jest automatyzacja kompilacji oprogramowania. Pakiety DEB są dostarczane w dwóch formatach: po jednym dla kodu źródłowego i programów binarnych. Pakiety kodu źródłowego są doskonałym systemem rozprowadzania i kompilacji kodu źródłowego. W systemie Ubuntu oraz innych pakiety zostały zaprojektowane do ich budowy w sposób nieinteraktywny, w przypadku oficjalnych pakietów Ubuntu mogą być budowane automatycznie dla wielu różnych architektur za pomocą oprogramowania nazywanego „autobilder”.
Pakiety oferują prostą (zwykle w postaci pojedynczego polecenia) metodę tworzenia oprogramowania, która jest spójna i stosowana we wszystkich pakietach. Problemy związane z konfiguracjami i innymi opcjami są rozwiązywane wcześniej przez twórcę pakietu. Wadą jest przeprowadzanie konfiguracji w trakcie budowy pakietu, natomiast zalety są ogromne, o czym Czytelnik przekona się w pozostałej części rozdziału. Zależności wymagane w trakcie budowy programu są deklarowane w pakiecie, więc ich spełnienie może być zrealizowane automatycznie. Przykładowo pakiety źródłowe przeznaczone dla konkretnej architektury (na przykład pakiety, które muszą być ponownie zbudowane dla każdej architektury) są umieszczane w postaci kodu źródłowego Ubuntu i w większości przypadków bez wprowadzania jakichkolwiek zmian w pakiecie źródłowym są automatycznie budowane we wszystkich architekturach obsługiwanych przez Ubuntu.
Z pojedynczego pakietu danych źródłowych można zbudować dowolną liczbę pakietów binarnych. Możliwość tworzenia wielu pakietów binarnych na podstawie pojedynczego pakietu kodu źródłowego jest szczególnie użyteczna w ogromnych projektach, które wydają ogromne lub monolityczne pakiety kodu źródłowego zawierające szeroką gamę różnorodnego oprogramowania. To także ważne w przypadku ściśle powiązanych ze sobą elementów oprogramowania i (lub) dokumentacji, których rozdzielenie może być niebezpieczne. Przykładem może być tutaj system graficzny XFree86 — obecnie zastąpiony i już zmodularyzowany przez X.org — który był dostarczany w postaci pojedynczego pakietu kodu źródłowego, ale tworzył dziesiątki innych pakietów binarnych. W tym przypadku dostarczenie pakietu pozwala użytkownikom na rozprowadzanie, instalowanie i usuwanie serwera X niezależnie od emulatora terminalu, pakietu biblioteki xlib oraz menedżera okien.
Jak można wywnioskować na podstawie powyższych informacji, kluczową zaletą systemów zarządzania pakietami jest oferowana przez nie pomoc w automatyzacji instalacji oprogramowania. Kiedy pakiet binarny jest zainstalowany, wówczas:
Prawdopodobnie najważniejsze jest tutaj sprawdzenie zależności instalowanego pakietu oraz obsługa listy pakietów zainstalowanych w systemie. W przypadku informacji dotyczących zależności użytkownik może dowiedzieć się, jakie oprogramowanie jest wymagane do uruchomienia oprogramowania znajdującego się w instalowanym pakiecie. Z tego powodu osoby tworzące oprogramowanie przeznaczone do umieszczania pakietów mogą bardzo łatwo tworzyć i implementować oprogramowanie z uwzględnieniem bibliotek współdzielonych. Sukces systemów zarządzania oprogramowaniem to jeden z powodów powszechnego wykorzystywania w środowisku GNU/Linux dynamicznie dołączanych bibliotek współdzielonych.
Kiedy użytkownik chce usunąć wybrane oprogramowanie, system zarządzania pakietami wraz ze swoim katalogiem zawierającym listę plików pakietu i działań przeprowadzonych w trakcie instalacji jest doskonale przygotowany do zapewnienia użytkownikowi pomocy w celu zagwarantowania przeprowadzenia procesu pełnego usunięcia danego oprogramowania.
Proces automatycznego uaktualniania oprogramowania jest podobny do instalacji i stanowi kolejny obszar, na którym z powodzeniem można wykorzystać system do zarządzania pakietami. Dzięki temu użytkownik takiego systemu może bezpiecznie i bardzo łatwo przeprowadzić uaktualnienie oprogramowania z jednej wersji do innej. Proces uaktualniania oprogramowania będzie niemal identyczny z procesem jego instalacji. W większości przypadków instalowane oprogramowanie jest zapisywane w miejsce istniejącego pakietu, a pliki, które nie znajdują się w nowszej wersji pakietu, są usuwane. Pliki konfiguracyjne zmodyfikowane przez proces instalacyjny i od tego czasu nie zmieniane przez użytkownika mogą być automatycznie wygenerowane przez użytkownika. Ewentualnie użytkownik może zostać poproszony o przejrzenie i zatwierdzenie zmian.
Informacje dotyczące zależności mogą odgrywać ważną rolę w procesie aktualizacji pakietu wykorzystującego biblioteki współdzielone. W przypadku zmian ABI (ang. Application Binary Interface) system zarządzania pakietami poinformuje użytkownika, że proces uaktualnienia pakietu nie będzie mógł być zakończony bez instalacji nowej biblioteki. Ponadto użytkownik będzie mógł zostać ostrzeżony o możliwości ewentualnego uszkodzenia innych pakietów w wyniku tej zmiany. Z tego powodu użytkownicy mogą kształtować uaktualnienia — lub system zrobi to za nich — aby nie dochodziło do nieoczekiwanych uszkodzeń spowodowanych przez API (ang. Application Programming Interface, interfejs programowania aplikacji) i ABI. W ten sposób użytkownicy mają gwarancję, że wszystkie pakiety wykorzystujące daną bibliotekę współdzieloną będą mogły być bezpieczne uaktualniane.
(ABI to zestaw reguł wpływających na współpracę między programami i bibliotekami, oprogramowaniem i systemem operacyjnym lub między różnymi komponentami oprogramowania i dotyczy programów skompilowanych — przyp. tłum.)
Wreszcie w dowolnej chwili użytkownik może sprawdzić podpis cyfrowy pakietu, wyświetlić wartości hash (zwykle sumy kontrolne MD5) plików znajdujących się w pakiecie i tym samym zweryfikować spójność plików w systemie pod kątem ewentualnego uszkodzenia bądź zmodyfikowania w wyniku ataku.
Wprawdzie wymienione funkcje dają ogromny potencjał podczas zarządzania oprogramowaniem w systemie, ale systemy zarządzania pakietami wyposażone jedynie w takie funkcje — czyli w zasadzie przedstawiające stan zarządzania pakietami w połowie lat dziewięćdziesiątych ubiegłego stulecia — nakładają istotne ograniczenia. Przeobrażenia API i ABI na dużą skalę wymagają pobrania wielu pakietów oraz wysokiego stopnia koordynacji ze strony użytkownika. Podczas instalacji bądź uaktualniania oprogramowania użytkownicy byli zmuszani do określenia stanu zależności programu, a następnie wyszukiwania, pobierania i jednoczesnej instalacji nowych elementów oprogramowania. W przypadku skomplikowanego oprogramowania z wieloma zależnościami ten proces bardzo często był zbyt męczący.
W wyniku tego większość uaktualnień systemu oraz zmian ABI/API była przeprowadzana za pomocą ogromnych skryptów uaktualnień między kolejnymi wydaniami dystrybucji. Użytkownik oczekiwał, że w trakcie większego uaktualnienia każdy wymagany pakiet zostanie zainstalowany przez skrypt aktualizacji, którego struktura pozwoli na zachowanie właściwej kolejności i odpowiednie obsłużenie zależności. Wprawdzie wspomniane problemy wynikały z ograniczeń samego systemu zarządzania pakietami, jednak większość z tych problemów występowała też poza systemami zarządzania pakietami. Bez systemu zarządzania pakietami biblioteki współdzielone poddawane zmianom API i ABI były akceptowane bardzo rzadko bądź wcale (z powodów bezpieczeństwa lub konieczności zagwarantowania spójności). Ewentualnie podlegały takim samym ograniczeniom, ale bez ostrzeżeń generowanych przez system zarządzania pakietami.
W ostatnich latach jesteśmy świadkami poważnej rewolucji związanej z rozwojem systemów zarządzania pakietami. Wynika to po części z faktu utworzenia w ramach projektu Debian programu o nazwie dselect i często chwalonego zestawu narzędzi APT (ang. Advanced Package Tools, początkowo o nazwie deity), które zaimplementowano w programie o nazwie apt-get. Większość z tych narzędzi do rodzaj pewnych form „interfejsu” dla poprzednio omówionych narzędzi niskiego poziomu służących do zarządzania pakietami. Podobnie jak większość innych dystrybucji bazujących na pakietach DEB, również Ubuntu używa apt-get, Aptitude, dselect oraz graficznego interfejsu Synaptic.
Możliwość śledzenia i katalogowania zależności to prawdopodobnie najważniejszy aspekt każdego systemu zarządzania pakietami. Podstawową funkcją narzędzi zaawansowanych było dostarczenie dodatkowej funkcjonalności istniejącym narzędziom zarządzania pakietami oraz możliwość jednoczesnego operowania wieloma pakietami. Każde z narzędzi zaawansowanych zawiera dodatkowe bazy danych przechowujące nie tylko opis zainstalowanych pakietów, ale również pakiety dostępne jako kandydujące do instalacji za pomocą archiwów pakietów znajdujących się lokalnie, na płytach CD lub (obecnie najczęściej) w repozytoriach sieciowych.
Systemy zarządzania pakietami mają możliwość automatycznego rozwiązywania problemów z zależnościami i kolejnością ich instalowania, pobierania pakietów (w tym również zależności), instalacji w pierwszej kolejności wszystkich zależności, a dopiero następnie instalacji i konfiguracji wybranego pakietu oprogramowania. Cały proces jest przeprowadzany za pomocą narzędzi niskiego poziomu omówionych w poprzedniej sekcji.
Te same narzędzia zaawansowane mogą być również wykorzystywane do usuwania pakietów. Przykładowo: jeżeli użytkownik chce usunąć bibliotekę współdzieloną, wówczas zostanie wyświetlony komunikat informujący o konsekwencjach takiego kroku wraz z listą pakietów, które będą musiały być odinstalowane z powodu niespełnienia zależności po usunięciu żądanej biblioteki. Uaktualnienia obejmujące zmianę zależności (na przykład zastąpione pakiety) również mogą być obsługiwane za pomocą takiego systemu.
Rzeczywiste możliwości tego rodzaju systemów ujawniają się, gdy aspekty zależności pakietu ulegają zmianom w czasie lub jeśli wiele pakietów może być zamiennikami. Pakiet wymagający możliwości wysyłania wiadomości e-mail może wymagać zależności w postaci pakietu wirtualnego „dostarczanego” przez inne pakiety. Nowsze wersje pakietu mogą powodować konflikty mimo deklaracji o „zastępowaniu” innych pakietów lub dostarczaniu funkcjonalności oryginalnego pakietu. Przykładowo: jeżeli kilka pakietów zostanie połączonych w jeden i pozostałe staną się zbędne, zaawansowany system zarządzania pakietami powinien śledzić zmiany w danych dotyczących zależności i właściwie zareagować w trakcie procesu uaktualniania. Oprócz tego zaawansowane systemy zarządzania pakietami dają użytkownikom możliwość przeprowadzania strategicznych „inteligentnych uaktualnień” każdego pakietu w systemie do najnowszej dostępnej wersji przy użyciu danych zadeklarowanych w zależnościach pakietu.
Dla niektórych użytkowników jeszcze bardziej ekscytującą możliwością jest śledzenie opracowywanych właśnie wersji systemu operacyjnego GNU/Linux i jego uaktualnianie każdego dnia do najnowszej dostępnej wersji. System zarządzania pakietami może określić bezpieczny sposób uaktualnienia i następnie je przeprowadzić. W trakcie uaktualniania zmiany wersji ABI i API również mogą być obsłużone automatycznie, ponieważ system odmówi przeprowadzenia pełnej aktualizacji biblioteki, jeśli wszystkie pakiety zainstalowane w systemie i zależne od danej biblioteki współdzielonej nie będą mogły być uaktualnione jednocześnie. System nie musi więc zawierać lub śledzić wielu wersji biblioteki współdzielonej.
cdn.
Wpisy z bloga/ TOP