|
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
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:
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:
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 |
|
|