uaktualnienia (było Re: openssh)

[Jakub Bogusz]

On Sat, Jun 29, 2002 at 05:09:18PM +0200, undefine w aramin.one.pl wrote:
> On Sat, Jun 29, 2002 at 04:13:51PM +0200, Jakub Bogusz wrote:
> > Jednak chyba wolałbym wycieczkę w celu uruchomienia sshd
> > z prawdopodobieństwem 0.01 niż w celu stawiania systemu od zera
> > z prawdopodobieństwem 0.001 (jak na kilka dni, ta druga liczba może być
> z prawd 0.01?

Liczba z sufitu, ale myślę, że ten rząd wielkości - prawdopodobieństwo
utraty sesji z powodu problemów z siecią, zasilaniem czy innych zjawisk
przed poprawieniem konfiguracji.
Dotyczy samej wycieczki, a nie problemów ze startem demona - to nie jest
tożsame jeśli w momencie upgrade sesja nie zostaje zerwana (to byłaby
poważniejsza wpadka).

Abstrahując od tego problemu (bo tu się ujawniał często w typowej
konfiguracji; poza tym już wystarczająco długo był omawiany - mam
nadzieję, że poniższe będzie bardziej konstruktywne.
Bardzo wskazane jest sprawdzanie działania kluczowych usług po
upgrade.

Powinnością developera(ów) przy przygotowywaniu nowej/poprawionej/załatanej
wersji pakietu jest sprawdzenie czy nie ma problemów po uaktualnieniu ze
starej wersji. Ale nie wszystko można sprawdzić czy przewidzieć
(zwłaszcza jeśli jest mało czasu; sprawdzenie przez jedną osobę na pewno
nie wystarcza - potrzeba więcej, i to zróżnicowanych, środowisk testowych).

Kłania się problem procedur testowych - kiedyś były pomysły z MOP-em
itp. Ale jak postępować w przypadku poprawek klasy security - macie
jakieś pomysły na przyszłość?

Różne rzeczy mogą się zdarzyć - np. zmieniają się nazwy lub niektóre
opcje są wyrzucane; niektóre demony tylko to sygnalizują ostrzeżeniami,
ale inne traktują jako "fatal error". O ile takie opcje występowały
w standardowej (dystrybucyjnej) konfiguracji poprzedniej wersji demona,
to się je wychwyci i doda aplikowanie odpowiedniej poprawki w %post lub
triggerze. Ale jeśli dotyczy to opcji nie występujących standardowo
- takie też powinny być poprawiane, ale rzadko się to robi, dopóki ktoś
nie wychwyci.[1]
Albo apache wyłączający się w czasie upgrade, jeśli zmieni się SONAME
libphp_common. Problem znany, ale rozwiązania jeszcze nie ma.
Albo jakieś błędy w środowisku (np. nazwa hosta niezgodna z RFC dot. DNS
- squid tego nie lubi, ale wielu innym rzeczom nie przeszkadza),
akceptowane przez starą wersję, ale już nie przez nową.
[stop - można długo wymyślać inne powody, ale starczy]

W każdym razie administrator powinien sprawdzać działanie uaktualnionych
demonów. Nie chodzi tu o jakieś dokładne testy regresji, ale prostą
kontrolę - np. czy apache wyświetla główną stronę, czy serwer baz danych
oczekuje połączeń, wreszcie czy można zalogować się po ssh.
Pierwszą rzeczą jaką robię po upgrade sshd (zwłaszcza zdalnym; jeśli
zdalnym, to przed rozłączeniem) jest próba zalogowania.

Nie znaczy to, że administrator nie ma prawa mieć pretensji o nie
działanie usługi zaraz po upgrade, jeśli wynika to z niedoróbki
w pakiecie.


[1] Znowu apel, także do siebie: sprawdzać, czy nie pozmieniały się
jakiekolwiek (nie tylko użyte w dystrybucyjnej konfiguracji) opcje
i robić poprawki w %post/triggerach (jeśli to tylko możliwe - jak nie da
się automatycznie poprawić, to chociaż wypisać komunikat).

-- 
Jakub Bogusz    http://prioris.mini.pw.edu.pl/~qboosh/