Bociek PLD - Pisarz
I. Informacje podstawowe
II. Instalacja
III. Podręcznik użytkownika
IV. Podręcznik administratora
Zarządzanie pakietami
Zaawansowane operacje
V. Tworzenie PLD - Praktyczny poradnik
VI. O podręczniku
O tej książce
Spis treści
Inne wersje tego dokumentu
HTML (jeden plik)
Odnośniki
Tworzymy dokumentację PLD
Strona PLD
Listy dyskusyjne PLD

Zaawansowane operacje

<- ->
 

Lista ostatnio instalowanych pakietów

Jeśli chcemy utworzyć listę zainstalowanych pakietów w kolejności wg. daty instalacji to posłużymy się poleceniem

# rpm -qa --last

Odinstalowanie "opornych" pakietów

Bywa, że pakiet w wyniku błędów w skryptach nie pozwala się odinstalować, możemy go jednak łatwo usunąć wydając polecenie deinstalacji z parametrem --noscripts np.:

# rpm -e lockdev-1.0.2-1 --noscripts

Repackage - bezpieczna aktualizacja

Jeśli obawiamy się aktualizacji jakichś pakietów, możemy posłużyć się operacją repackage - ponownego umieszczenia plików w pakiecie rpm. Jeśli program po aktualizacji odmawia posłuszeństwa, wystarczy ponownie zainstalować pakiet w starszej wersji. Aby włączyć repakietację wystarczy, że ustawimy niezerową wartość dla makra %_repackage_all_erasures w pliku /etc/rpm/macros:

%_repackage_all_erasures    1

Od tej pory każda aktualizacja rozpocznie się od ponownego złożenia pakietu. Dla pojedynczych pakietów nie ma sensu modyfikować pliku z makrami, lepiej przekazać parametr do rpm-a:

poldek> upgrade geninitrd-10000.18-6.noarch --pmop=--repackage

W przypadku bezpośredniego użycia rpm-a:

# rpm -U --repackage geninitrd-10000.18-6.noarch

Tak zbudowane pakiety trafiają do katalogu /var/spool/repackage Repakietacja jest czasochłonna, ponadto dodatkowo zajmowane jest miejsce na dysku, dlatego najlepiej używać tej funkcji tylko dla wybranych programów.

Aby cofnąć wersję pakietu wykonujemy następującą operację:

rpm -U --oldpackage /var/spool/repackage/1189984560/geninitrd-10000.18-6.noarch

Kontrola integralności systemu

Zdarza się, że potrzebujemy sprawdzić czy nie nastąpiły w systemie uszkodzenia jakichś plików lub ich modyfikacje. Takie zdarzenia mogą się pojawić w wypadku uszkodzenia systemu plików, błędu człowieka lub ataku crackera. W obu przypadkach możemy posłużyć się weryfikacją pakietów RPM. Kontrola przyniesie oczekiwany skutek tylko wtedy, gdy jesteśmy pewni, że sama baza RPM nie została skompromitowana lub uszkodzona.

Aby uzyskać listę zmodyfikowanych plików użyjemy programu rpm:

# rpm --verify --all
......G.   /etc/cups
S.5....T   /usr/lib/libsasl2.so.2.0.22
S....... c /etc/xml/catalog
.M...UG. c /etc/samba/smb.conf

szczegółowy opis oznaczeń znajdziemy w manualu programu rpm. Musimy pamiętać, że wiele plików konfiguracyjnych (oznaczanych literką "c") jest modyfikowanych po instalacji programu, dlatego ich obecność na liście jest naturalna.

Załóżmy, że poznaliśmy listę zmodyfikowanych plików i chcemy na jej podstawie stworzyć listę pakietów do reinstalacji. Zaczynamy od odfiltrowania wszystkiego prócz nazw plików:

# rpm --verify --all | sed 's/.*\ //' > pliki.txt

Taką listę możemy teraz sobie obejrzeć i ewentualnie zmodyfikować, kiedy lista już nam odpowiada sprawdzamy z jakich pakietów pochodzą pliki:

# cat pliki.txt | xargs rpm -qf --qf '%{NAME}\n' | sort -u  > pakiety.txt

Powyższy ciąg poleceń stworzy listę składającą się wyłącznie z nazw pakietów, by uniknąć problemów w przypadku różnic w wersjach pakietów: tych zainstalowanych z dostępnymi do instalacji. Mając listę unikalnych nazw pakietów, możemy wywołać polecenie ich reinstalacji:

# poldek --reinstall --pset pakiety.txt

Naprawa bazy RPM

System pakietów RPM opiera się na bazie w postaci plików przechowywanych w katalogu /var/lib/rpm. Nagłe przerwanie pracy programu, który na niej operował może zaowocować błędami w jej strukturze. Na początek należy się upewnić, że żaden z procesów nie operuje na bazie:

# lsof | grep /var/lib/rpm

jeśli nie wyświetlą nam się żadne informacje to możemy usunąć pliki blokad, łatwo je rozpoznamy, gdyż zaczynają się od __db

# rm -f /var/lib/rpm/__db*

Teraz możemy spróbować czy sytuacja się poprawiła, jeśli nie to musimy spróbować przebudować bazę. Zaczynamy od wykonania kopii bezpieczeństwa:

# tar -czf rpm.tar.gz /var/lib/rpm/

następnie wydajemy polecenia przebudowania:

# rpm --rebuilddb

W większości wypadków ta operacja pomoże nam odzyskać bazę, może się jednak zdarzyć, że odtworzy nam się tylko jej część. Do oszacowania strat konieczne będzie utworzenie listy pakietów w bazie:

# rpm -qa

Kiedy ustalimy listę brakujących pozycji, najłatwiejszym sposobem dodania brakujących wpisów będzie instalacja pakietów z opcją --justdb, powodującą jedynie modyfikowanie bazy RPM.

Reinstalacja wszystkich pakietów - zmiana architektury

Zdarza się, że potrzebujemy zainstalować na nowo wszystkie pakiety, np. w wypadku zainstalowania pakietów w niewłaściwej architekturze. Nie jest to pracochłonna operacja, wystarczy, że z powłoki Poldka wydamy polecenie:

poldek> install -F * --reinstall --nodeps --nofollow

 
<- ->