RPM
Instalujemy pakiety
W bieżącym ćwiczeniu chcemy sprawdzić, czy w systemie zainstalowana jest powłoka Korne'a (pdksh oraz pakiet dokumentacji HOWTO w języku polskim (howto-polish).
Listę aktualnie zainstalowanych w systemie pakietów możemy uzyskać w sposób następujący:
# rpm -qa | less
setup-1.9.2-1
filesystem-1.3.2-3
.....
......
zip-2.1-4
zlib-devel-1.1.3-2
(END) [q]
[root@crash /root]#
Lista jest dość długa, dlatego do jej przeglądania użyliśmy programu less. Każdy wiersz listy dotyczy innego pakietu i składa się z nazwy pakietu i jego wersji. Aby uzyskać informację o którymś z nich, wystarczy wydać polecenie:
#rpm -qi nazwa_pakietu
Nie znaleźliśmy na liście naszych pakietów, ale znamy ich dokładne nazwy więc możemy zapytać wprost:
# rpm -q pdksh howto-polish
package pdksh is not instaled
package howto-polish is not instaled
[root@crash /root]# _
Upewniliśmy się, że oba pakiety nie są zainstalowane. Włóżmy zatem dystrybucyjny CD-ROM do czytnika i przystąpmy do instalacji:
# cdm
ISO9660 Extensions: Microsoft Joliet Level 3
[root@crash/root]# ls /mnt/cdrom/RedHat/RPMS/*{ksh,polish}*
/mnt/cdrom/RedHat/RPMS/howto-polish-5.2-2.noarch.rpm
/mnt/cdrom/RedHat/RPMS/pdksh-5.2.12-5.i386.rpm
[root@crash /RPMS]# cd /mnt/cdrom/RedHat/RPMS/
[root@crash /RPMS]# rpm -i --test howto-polish-5.2-2.noarch.rpm
[root@crash /RPMS]# rpm -i --test pdksh-5.2.12-5.i386.rpm
[root@crash /RPMS]# rpm -iv howto-polish-5.2-2.noarch.rpm
Installing howto-polish-5.2-2.noarch.rpm
[root@crash /RPMS]# rpm -iv pdksh-5.2.12-5.i386.rpm
Installing pdksh-5.2.12-5.i386.rpm
[root@crash /RPMS]# cd ~
[root@crash /root]# _
Wyjaśnijmy teraz przebieg naszych działań. Po pierwsze do zamontowania CD-ROM-u użyliśmy aliasy cdm zdefiniowanego tutaj
W argumencie polecenia ls skorzystaliśmy z właściwej tylko bash-owi możliwości użycia nawiasów klamrowych i mechanizmów rozwijania nawiasów. Zapis "*{ksh,polish}*" oznacza tu wszystkie pliki, w których nazwie występuje łańcuch "ksh" bądź "polish".
Pozycja --test opcji -i polecenia rpm jest wygodna do uruchomienia przed instalacją w celu sprawdzenia an przykład, że nie ma konfliktów czy innych problemów.
Do samej instalacji służy opcja -i, dodatkowe -v ma na celu jedynie wyświetlenie komunikatu
Installing ...
Efektowną wizualizację (linijkę ze znaków "#") instalacji uzyskujemy dodając jeszcze -h. Wtedy polecenie instalacji przyjmie postać:
# rpm -ivh nazwa_pakietu
a komunikat będzie zawierał elegancką linijkę postępu złożoną ze znaków #:
# nazwa_pakietu ############################
Taka postać komunikatu jest szczególnie atrakcyjna, gdy za pomocą jednego polecenia instalujemy wiele pakietów RPM, tzn. korzystamy ze znaków grupowych w nazwie pakietu.
Powinniśmy pamiętać, że przy instalacji (użyciu opcji -i) pojedynczego pakietu musimy podać pełną nazwę pliku z pakietem (łącznie ze wszystkimi przyrostkami), gdyż inaczej otrzymamy komunikat o błędzie:
error: cannot open file nazwa_pliku_którą_podaliśmy
Instalacja dobiegła końca. Sprawdźmy na przykładzie pdksh, czy to jest to, o co nam chodziło:
# rpm -qi pdksh
Name : pdksh Distribution: Manhattan
Version : 5.2.12 Vendor: Red Hat
Relase : 5 Build Date: Sun Aug 16 20:30:30 1998
Install Date : Tue May 28 13:34:23 2000
Build Host: porky.redhat.com
Group : Shells Source RPM: pdksh-5.2.12-5.src.rpm
Size : 400968 License: Public Domain
Packager : Red Hat Software
Summary : Public Domain Korn Shell
Description :
pdksh, a reimplementation of ksh, is a command interpretator that is intended for both interactive
and shell script use. Its command language is a superset of the sh(l) shell language.
[root@crash /root]# _
Jest to typowa metka (krótka informacja) pakietu RPM. Bardzo szybko możemy się również przekonać gdzie i jakie pliki zostały zainstalowane:
# rpm -ql pdksh
/bin/ksh
/usr/bin/ksh
/usr/bin/pdksh
/usr/doc/pdksh-5.2.12
/usr/doc/pdksh-5.2.12/BUG-REPORTS
/usr/doc/pdksh-5.2.12/NEWS
/usr/doc/pdksh-5.2.12/NOTES
/usr/doc/pdksh-5.2.12/PROJECTS
/usr/doc/pdksh-5.2.12/README
/usr/man/man1/ksh.1
/usr/man/man1/pdksh.1
[root@crash /root]# _
Teraz spróbujmy jeszcze raz zainstalować już zainstalowany pakiet pdksh:
# rpm -ivh pdksh-5.2.12-5.i386.rpm
package pdksh-5.2.12-5 is already installed
error: pdksh-5.2.12-5.i386.rpm cannot be installed
[root@crash /RPMS]# _
Istnieje zabezpieczenie przed przypadkową ponowną instalacją już zainstalowanego pakietu, które chroni nas przez zniszczeniem (nadpisaniem) plików konfiguracyjnych pakietu. Zdarzają się jednak sytuacje w których należy pakiet ponownie zainstalować. Posłużymy się wówczas podopcją --replacepkgs, która umożliwi nam taką ponowną instalację:
# rpm -ivh --replacepkgs pdksh-5.2.12-5.i386.rpm
pdksh ############################
[root@crash /RPMS]# _
Weryfikujemy zainstalowany pakiet
Jeżeli podejrzewamy, że któryś ze składników pakietu uległ uszkodzeniu, możemy skorzystać z opcji weryfikacji. Zasymulujemy taką sytuację dla pdksh:
# rpm -ql pdksh
/bin/ksh
/usr/bin/ksh
/usr/bin/pdksh
/usr/doc/pdksh-5.2.12
/usr/doc/pdksh-5.2.12/BUG-REPORTS
/usr/doc/pdksh-5.2.12/NEWS
/usr/doc/pdksh-5.2.12/NOTES
/usr/doc/pdksh-5.2.12/PROJECTS
/usr/doc/pdksh-5.2.12/README
/usr/man/man1/ksh.1
/usr/man/man1/pdksh.1
[root@crash /root]# rpm -V pdksh
[root@crash /root]# rm /usr/man/man1/pdksh.1
rm: remove '/usr/man/man1/pdksh.1' ? y
[root@crash /root]# rpm -V pdksh
missing /usr/man/man1/pdksh.1
[root@crash /root]# _
Jak widać usunięty plik manuala pdksh.1 został zweryfikowany jako brakujący (missing). Weryfikacja obejmuje nie tylko istnienie samych plików i ścieżek dostępu, ale sięga znacznie głębiej. Możemy teraz naprawić pakiet pdksh instalując cały na nowo bądź instalując tylko brakujący czy też wykryty jako wadliwy w czasie weryfikacji element (korzystając z podopcji --allfiles):
# rpm -ivh --allfiles --replacepkgs pdksh-5.2.12-5.i386.rpm
pdksh #############################################
[root@crash /root]# rpm -V pdksh
[root@crash /root]# _
Do poprawnej pracy pakiet wymaga określonego środowiska w szczególności konkretnych programów i bibliotek nie wchodzących w jego skład. Informację o tych wymaganiach możemy uzyskać za pomocą opcji -R. Zróbmy to dla pakietu pdkh:
# rpm -qR pdksh
/bin/sh
ld-linux.so.2
libc.so.6
[root@crash /root]# _
Przynależność plików
W praktyce często spotkać się możemy z koniecznością ustalenia, do jakiego pakietu RPM należy dany plik. Ustalmy dla przykładu pochodzenie pliku /etc/passwd:
# rpm -qf /etc/passwd
setup-1.9.2-1
[root@crash /root]# _
Przeglądamy pakiety niezainstalowane
Poprzednio do przeglądania pakietów w katalogu /RedHat/RPMS na CD-ROMie posłużyliśmy się poleceniem ls. Jednakże równie elegancko można do tego celu wykorzystać rpm. Najpierw zażyczymy sobie listę wszystkich pakietów znajdujących się w katalogu RPMS:
# rpm -qp *rpm | less
AfterStep-1.5-0.7
...
...
zsh-3.0.5-6
(END) [q]
[root@crash /RPMS]# _
Lista jest dość długa dlatego do jej przeglądania skorzystamy z programu less. Do wyszukania konkretnych pakietów posłużymy się znanym już wzorcem:
# rpm -qp *{ksh,polish}*
pdksh-5.2.12-5
howto-polish-5.2-2
[root@crash /RPMS]# rpm -qp apache*
apache-1.3.3-1
apache-devel-1.3.3-1
[root@crash /RPMS]# rpm -qpi apache-1*
Name : apache Distribution: Manhattan
Version : 1.3.3 Vendor: Red Hat Software
Relase : 1 Build Date: Tue Oct 13 09:08:03 1998
Install Date : (not installed)
Build Host: porky.redhat.com
Group : Networkings/Demons Source RPM: apache-1.3.3-1.src.rpm
Size : 1980776 License: Freely distributable and usable
Packager : Red Hat Software
Summary : Leading World Wide Web Server
Description :
Apache is full featured web server that is freely available, and also happens
to be the most widely used.
[root@crash /RPMS]# cd ~
[root@crash /root]# _
Analogicznie możemy (poleceniem: rpm -qpl apache-1* uzyskać listę plików pakietu oraz informację dotyczącą wymagań środowiska (poleceniem: rpm -qpR apache-1*).
Aktualizujemy pakiety
Już raz zainstalowany pakiet może być aktualizowany (ang. upgrade) do nowszej wersji. Posługujemy się tu opcją -U. Możemy używać wszystkich podopcji znanych z instalacji pakietu. Podstawowa składnia polecenia będzie następująca:
rpm -Uvh pełna_nazwa_pakietu
gdzie opcje -vh, jak już wiemy służą jedynie celom wizualizacji.
W przypadku dystrybucji Red HAt nowe wersje pakietów rozpowszechniane są jako aktualizacje do danego numeru dystrybucji. Będą one dostępne w serwisie internetowym dystrybutora www.redhat.com i na jego mirrorach oraz często na CD-ROMach w czasopismach komputerowych.
Deinstalujemy pakiet
Usuniemy teraz pakiet pdksh:
# rpm -e --test pdksh
[root@crash /root]# rpm -e pdksh
[root@crash /root]# rpm -q pdksh
package pdksh is not installed
[root@crash /root]# _
Opcja -e służy do usuwania pakietów. Można użyć podopcji --test w celu sprawdzenia bezproblemowej możliwości usunięcia pakietu. Dany pakiet może być bowiem potrzebny do poprawnego funkcjonowania zainstalowanego oprogramowania z innych pakietów. W naszym przypadku nie otrzymaliśmy żadnego komunikatu o błędzie.
Wszystkie informacje o pakietach RPM przechowuje w katalogu /var/lib/rpm.
Obsługa pakietów za pomocą MC
Midnigh Commander posiada wbudowane funkcje obsługi pakietów RPM. Za pomocą MC możemy przeglądać, instalować oraz aktualizować pakiety:
# cd /mnt/cdrom/RedHat/RPMS
[root@crash RPMS]# mc
Po uruchomieniu MC znajdziemy się w katalogu /mnt/cdrom/RedHat/RPMS z pakietami RPM. Teraz możemy podświetlić wybrany katalog i po naciśnięciu [Enter] uzyskamy w oknie MC pseudozawartość katalogu odpowiadającego wybranemu pakietowi:
/..
/INFO
HEADER
*INSTALL
*UPGRADE
Plik HEADER zawiera informację (metkę) na temat pakietu. Możemy ją obejrzeć podświetlając HEADER i naciskając [F3]. Pliki wykonywalne INSTALL i UPGRADE służą, jak łatwo się domyślić, do dokonania instalacji bądź aktualizacji pakietu. Przykładowo, w celu dokonania instalacji podświetlamy INSTALL i naciskamy [ENTER].
Podkatalog /INFO zawiera pliki z danymi na temat pakietu. W wielu wypadkach jest to rozpisana na tematy informacja pochodząca z metki, ale nie tylko. Poszczególne pliki z /INFO przeglądamy za pomocą przeglądarki MC uruchamianej naciśnięciem klawisza [F3].
Opuszczamy pakiet przez podświetlenie /.. i naciśnięcie [Enter].
Instalujemy z kompilacją
Instalacja tego rodzaju może być równie bezproblemowa jak w przypadku pakietu RPM, ale może sprawić nam jakieś kłopoty. Zależy to w dużym stopniu od staranności przygotowania pakietu instalacyjnego przez jego autora. Postępowanie jest tu podobne jak przy kompilacji jądra. Jak w przypadku jądra, tak w przypadku określonych aplikacji spotkać się możemy z również z łatami (patch), które instalujemy analogicznie jak w przypadku tekstu źródłowego jądra.
Tekst źródłowy programy w języku C otrzymujemy zwykle w postaci archiwum zwykłego (.tar) lub skompresowanego (.tar.gz). Należy je rozpakować w określonym katalogu. Archiwum nie zawiera z reguły pojedynczego pliku lecz katalog z drzewem podkatalogów, tak jak w przypadku jądra. Po rozpakowaniu szukamy w nim plików tekstowych INSTALL, README (czy podobnych) i przeglądamy je. Pliki te powinny zawierać szczegółowy opis instalacji i należy postępować zgodnie z zawartą w nich instrukcją. Interesuje nas jeszcze plik o nazwie makefile (lub Makefile, czy też GNUmakefile). Jest to skrypt dla polecenia make automatyzujący proces kompilacji i instalacji. Występują w nim między innymi wywołania kompilatora. W przypadku istnienia pliku makefile instalacja aplikacji z reguły sprowadza się do wydania kolejno dwóch poleceń:
# make
# make install
Polecenie make wydane bez żadnych parametrów poszukuje w bieżącym katalogu pliku o nazwie GNUmakefile, Makefile bądź makefile. Gdy go znajdzie - wykonuje.
Gdy otrzymamy komunikat o błędach, zaczynają się trudności. Przyczyną może być błąd w skrypcie makefile lub częściej niekompletność bądź nieadekwatność naszego środowiska programistycznego. Kompilator gcc i samo make z reguły będzie zainstalowane, ale braki (nieadekwatność wersji) mogą wystąpić wśród plików nagłówkowych (.h) bądź bibliotek.
Biblioteki znajdziemy w katalogu /lib. Natomiast pliki nagłówkowe znajdują się w katalogu /usr/include/asm i /usr/include/linux. Z reguły będą to odpowiednie łączniki symboliczne.
ldd
Programy w Linuksie korzystają na ogół z ładowanych dynamicznie dzielonych bibliotek (ang. shared librares).
W Linuksie istnieją dwa formaty plików binarnych: obecnie obowiązuje ELF i starszy a.out. Są one wzajemnie niekompatybilne i wymagają innych bibliotek dzielonych. Aby móc zatem wykorzystywać programy zarówno w formacie ELF, jak i a.out, musimy posiadać dwa komplety bibliotek. W sytuacjach wątpliwych pomocny okazać się może skrypt ldd. Wypisuje on niezbędne dla wskazanego programu biblioteki. Operuje na programach w obu formatach binarnych.
Zobaczymy teraz, jakich bibliotek wymagają make i bash:
# which make
/usr/bin/make
[root@crash /root]# ldd /usr/bin/make
lib.so.6 => /lib/libc.so.6 (0x40004000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
[root@crash /root]# which bash
/bin/bash
[root@crash /root]# ldd /bin/bash
libtermcap.so.2 => /lib/libtermcap.so.2 (0x40004000)
lib.so.6 => /lib/libc.so.6 (0x40008000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
[root@crash /root]# which ldd
/usr/bin/ldd
[root@crash /root]# ldd /usr/bin/ldd
not a dynamic executable
[root@crash /root]# _
1