stan Ac

[Jakub Bogusz]

On Wed, Jul 07, 2004 at 11:53:48PM +0200, Wojciech 'Sas' Cieciwa wrote:
> On Wed, 7 Jul 2004, Jakub Bogusz wrote:
> >On Wed, Jul 07, 2004 at 02:03:30PM +0200, Paweł Sikora wrote:
> >>On Tuesday 06 of July 2004 16:23, Wojciech 'Sas' Cieciwa wrote:
> >>
> >>>- rozbabrany sparc,
> >>
> >>jesli wylaczymy grsec na sparcu do czasu poprawienia zrodel,
> >>to mozna juz budowac 2.6.7-1.20.
> >>w innym wypadku, trzeba zrobic cos z tym:
> >
> >[...]
> >>init/built-in.o(.text+0x224): In function `init':
> >>: undefined reference to `grsecurity_init'
> >
> >Gdzieś grsecurity jest nie dopisane.

Dokładnie tak było, sparc ma drugą listę katalogów w swoim
$ARCH/Makefile.

> >Ale jak można cokolwiek poprawić, skoro co najmniej raz dziennie jest
> >świeży cset i zamiast tylko poprawić poprzednio występujący błąd
> >trzeba, wrr, uaktualniać ileś rzeczy, wrr, poczynając od konfiguracji
> >(przeważnie jest aktualna tylko dla 1-2 architektur) i, wrr, iluś
> >łat.  Dla przykładu teraz, wrr, jakieś wrr się nie nakłada, wrr.
> 
> BLAD !!
> Na ogol cset nie ingeruje w inne laty, a jesli juz to w takie jakie sa 
> osobnymi patchami ..

Ale zmieniają kod, na który są nakładane łaty - więc zdarza się, że się
przestają nakładać.

> >Tu są potrzebne dwie linie (branche) z jądrem 2.6.
> >To co jest jest dobre na linię rozwojową.
> >Ale brakuje linii stabilnej, gdzie byłoby dłużej trzymane _to samo_
> >jądro, bez najnowszych csetów, tylko z poprawkami błędów wyłapanych przy
> >testowaniu. I w przypadku np. wykrycia kolejnego błędu security
> >wystarczyłoby nałożyć łatę na tę wersję i puścić do Ac. Wiedząc, że tam,
> >gdzie działała poprzednia wersja (dziurawa), to nowe, załatane, też
> >zadziała - a nie ujawni się nowy błąd w parę dni wcześniej
> >uaktualnionych sterownikach czy podsystemie. Przy wymianie z 2.6.5 na
> >2.6.7 czy też snapshot post-2.6.7 do takiej pewności daleko.
> >
> >Pytanie czy 2.6.x jest już na takie zamrożenie gotowe (2.4.x dla Ra
> >zostało na dobre zamrożone po raz pierwszy przy 2.4.18...).
> >Bo jeśli nie - to... za wcześnie na używanie 2.6.x na produkcji.
> 
> 2.6.7 dziala stabilnie u mnie ....

Nie o to chodzi, czy dana wersja działa stabilnie, jeśli "co chwila"
jest nowa.

W każdej chwili może wyjść jakaś krytyczna poprawka bezpieczeństwa.
A nowe jądro będzie już znacznie się różniło od poprzedniej wersji
uznanej za stabilną, możliwe, że działającej na iluś produkcyjnych
maszynach. No i przy takich dużych różnicach nie ma żadnej pewności, że
po uaktualnieniu jąder te maszyny będą działać poprawnie...

Zamrożona wersja dystrybucji potrzebuje też zamrożonego jądra, w którym
nic się nie zmienia oprócz poprawek błędów - jak w kernel.spec na
LINUX_2_4 czy wcześniej (kiedy LINUX_2_4 było rozwijane)
LINUX_2_4_STABLE. Podobnie robię z LINUX_2_4_26 w kernel24.spec (dopóki
2.4.27 nie będzie skończone).

Nie neguję linii rozwojowej, taka _też_ jest potrzebna (a co najmniej
przydatna) - ale nie jako jedyna.
Wersje uznane za stabilne, używane na produkcji, potrzebują branchy
do nakładania krytycznych poprawek.
Czy to już jest ten moment, żeby takie branche robić - można dyskutować.
Jeśli 2.6.x z PLD ma już wejść na produkcję, to tak.
Na razie, tam gdzie jest potrzebna stabilność, trzymam się 2.4.2x.
2.6.x czasami próbuję, ale jest jeszcze zbyt nieprzewidywalne (i nie
jest to nic specyficznego dla dystrybucyjnych 2.6.x, dotyczy także
jąder waniliowych - po każdym kolejnym 2.6.x zainstalowanym na domowej
maszynce musiałem poprawiać nowe błędy).


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/