RPM, Informatyka, Linux, Linux - Podręcznik


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



Wyszukiwarka