odwrócenie bconda pax w glibc
Marek Guevara Braun
marek.guevara w atm.com.pl
Śro, 27 Wrz 2006, 10:19:42 CEST
Piotr Zięcik wrote:
> Owszem. Ale po takim upgradzie maszyny nie zrestartujesz (ba, w ogóle nie
> wykonasz żadnego polecenia). A ja mam maszyny 60 km od siebie ...
Jeśli mamy własny kompilat glibca, zbudowany z opcją --with pax, a
domyślnie ta opcja byłaby wyłączona, to i tak nie można "w ciemno"
upgradować takiej maszyny, bo np. za chwilę pojawi się "w poldku" nowy
release danej biblioteki i po upgrade system nie działa.
Rozwiązania tu widzę raczej administracyjne
(1) dodanie glibca, zlib i ew. paxctl do listy hold w poldku
(2) dodanie do poldka tylko własnych punktów dystrybucji/builderów,
które produkują "dobre" pakiety
(3) dodanie jakiegoś watchdoga/zdalnego resetu do serwerów, albo lepiej
karty zdalnego dostępu do poziomu BIOS maszyny (można edytować
gruba przy starcie)
(4) zainwestowanie w większy dysk, vmware serwer i testowanie upgradów
przed zdalną implementacją.
Nawet gdy --with pax było by dalej (tak jak jest obecnie) domyślnie
wyłączone, nic nie stoi na przeszkodzie, że ktoś edytując speca
wywali/zepsuje odpowiednią łatkę, albo odpowiednio skompilowana, nowa
wersja będzie po prostu błędna.
Pozdrawiam,
Marek
PS. Pewnym ułatwieniem, byłoby dodanie jakiegoś provides do glibca i
zliba --with pax, ale nie za bardzo widzę co musiało by mieć odpowiednie
requires - bo kernel-pax to trochę bez sensu, a paxctl, to pewnie by się
automatycznie odinstalowało :-)
Więcej informacji o liście dyskusyjnej pld-devel-pl