Niniejszy post jest oparty o historię z pola bitwy. Bardzo techniczny i nieszczególnie ciekawy, jeśli ktoś nie używa wymienionych technologii. Być może komuś się przyda.
Awaria
Poszukiwanie przyczyn pozwoliło nam ustalić następujące fakty:
- W jednej z maszyn wirtualnych ktoś zainstalował pakiety
rpm i poldek, a następnie użył ich do instalacji oprogramowania;
- Maszyna miała cały czas zamontowaną zewnętrzną bazę
rpm (prawdopodobnie utils-vserver zdechło i pozostawiło po sobie bałagan, ale o tym później);
- Wewnętrzny
rpm miał inną wersję i w jakiś sposób uszkodził bazę zainstalowanych pakietów;
- Następujący po nim
rpm --rebuilddb bezpowrotnie wyczyścił bazę pakietów maszyny;
- W międzyczasie miał miejsce upgrade pakietów
rpm i poldek w zewnętrznym systemie;
Postanowiliśmy zatem przeinstalować maszynę od nowa, rekonstruując na podstawie działających usług listę niezbędnych pakietów.
Nosem w dół
Dość szybko okazało się, że nie będzie tak łatwo:
ncontext: vc_net_create(): Invalid argument
Tak właśnie kończyło się każde wywołanie narzędzi vrpm i vpoldek. Winnym okazało się wywołanie chbind, a poprawka wygląda tak:
--- /usr/lib/util-vserver/functions~ 2007-09-05 16:09:16.967334575 +0200
+++ /usr/lib/util-vserver/functions 2007-09-05 16:10:29.456275993 +0200
@@ -1171,5 +1171,5 @@
export RPM_FAKE_CHROOT RPM_FAKE_CTX RPM_FAKE_CAP RPM_FAKE_FLAGS
LD_PRELOAD=$_RPM_FAKE_SO${LD_PRELOAD:+:$LD_PRELOAD} \
- exec $_CHBIND "${CHBIND_OPTS[@]}” “$@”
+ exec $_CHBIND –nid $RPM_FAKE_CTX “${CHBIND_OPTS[@]}” “$@”
}
Dość szybko okazało się, że radość jest przedwczesna. O ile vrpm i vpoldek zaczęły działać, to żadne z nich nie potrafiło nic zmienić. Odpytywanie bazy nie przysparzało żadnych trudności, próba instalacji lub usunięcia pakietu kończyły się kolejnym radosnym komunikatem:
error: cannot open Basenames index using db3 - No such file or directory (2)
Winny
Okazało się, że winny jest rpm-4.4.9 w połączeniu z db4.6. Nie miałem okazji sprawdzić, co dokładnie powoduje nieprawidłowe działanie, dość było upewnić się, że działa wersja rpm-4.4.9-1, zbudowana z pakietem db4.5-devel.
Problemem jest fakt, że db4.6 automatycznie konwertuje każdą otwartą bazę do swojego formatu, co oznacza, że po wykonaniu downgrade pakietu rpm zostaniemy z bezużytecznym narzędziem.
Rozwiązanie
Jeff, autor rpm pomógł mi cofnąć upgrade:
- Instalujemy pakiet
db4.6-utils, kopiujemy z niego program db_dump;
- Odinstalowujemy
db4.6-utils, zachowując sam db4.6;
- Instalujemy pakiet
db4.5-utils;
- Cofamy wersję
rpm i instalujemy pakiet poldek zbudowany dla tej wersji rpm;
- Wykonujemy:
cd /var/lib/rpm
rm __db*
mv Packages{,.old}
db_dump_4.6 Packages.old > Packages.dump
db_load Packages < Packages.dump
rpm --rebuilddb
- Powyższą czynność powtarzamy dla wszystkich katalogów
/vservers/.pkg/*/rpm/state, które zdążyły się zaktualizować do nowej wersji, odpowiednio modyfikując pierwszą linię i do ostatniej dopisując --dbpath <sciezka_do_katalogu_state>
Kolejny problem
Ostatnim krokiem było przekonanie narzędzia vpoldek, że instalowane pakiety są dla właściwej architektury. Tutaj rozwiązaniem było dopisanie do każdego pliku /vservers/.pkg/*/rpm/etc/macros linijki:
%_host_os %_os
Voila, wszystko działa, maszyna została przebudowana. Następnym razem postaram się pozbyć irytujących komunikatów LD_PRELOAD.
Ostatnie komentarze