PLD Th: fixing a vserver

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:

  1. Instalujemy pakiet db4.6-utils, kopiujemy z niego program db_dump;
  2. Odinstalowujemy db4.6-utils, zachowując sam db4.6;
  3. Instalujemy pakiet db4.5-utils;
  4. Cofamy wersję rpm i instalujemy pakiet poldek zbudowany dla tej wersji rpm;
  5. 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
  6. 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.

linux software