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