Ksh static - ale jak ? ;)

[Tomasz Kłoczko]

On Tue, 1 Jun 1999, Marek Obuchowicz wrote:
[..]
> hmmm
> 1. ustatlilismy ze skrypty robimy jak mozna dla POSIX-sh ale domyslnym
> shellem interaktywnym ma byc bash!

Przepraszam .. kto ustalał? Dlaczego mamy takie rzeczy ustalać ?
(chodzi mi o domyślny shell)
OK .. mamy mówić root-owi jakie aplikacje może uruchamiać, a które nie
(patche Wojtka *-nonroot.patch), mamy mu mówić jakiego musi mieć shella,
to samo i użytkownikom (jeśli chodzi o shella). Co jeszcze mamy mówić ?
Przeprasza ale ani nie jest to konieczne ani my bynajmniej nie mamy
aspirować do roli przedszkolanki.

Jeżeli chcesz to rzeczywiście wcielić w życie to powinniśmy mieć tylko ksh
(robiący za sh) i basha. Nie do nas należy podejmowanie takich wyborów. To
jest niestety obszar podlegający juryzdykcji końcowego użytkownika
systemu, a ten zrobi co będzie chciał i masz na to zerowy wpływ.

> 2. 2 pytania do znawcow systemu:
>  a) czyz programy kompilowane statycznie nie uruchamiaja sie szybciej?

Czasami tak czasami nie. Regóły generalnie nie ma.

>  b) czy odpalajac 2 razy program linkowany statycznie mamy szanse
>     na zaoszczedzenie pamieci jak w przypadku dynamicznym?

Jeżeli program linkowany dynamicznie jest zlinkowany z libem, który jest
juz w pamięci to zajmie on mniej pamięci niż jego odopowiednik statyczny.
W tym wypadku bash jest linkowany z libncurses i libc. Po co więc linkować
to statycznie skoro _nie może i nie jest_ to bynajmniej podyktowane
względami bezpieczeństwa pracy _interakcyjnej_, a tylko chodzi o to, że
shell statyczny przydać się mogł _dla root-a_ w sytuacjach ekstremalnych
??

> Tomek, ja tylko w jednej sprawie popre Wojtka - koniecznie statyczny
> sh dla root-a!

No włąśnie po co ?
Przecież pisałem już, że jest to potrzebne tylko od wielkiego wypadku i
_wtedy_ to dopiero można użyć specjalnego shella, ale wcale bynaj,mniej
nie musi to oznaczać, że root musi pracować zawsze na takim shellu.

> Mi tez sie zdarzylo wywalenie glibc w kosmos - i to
> wcale nie na 'mocno developerskiej maszynie' tylko na moim kompie w domu
> kiedy podczas upgrade-u na nowsze rpmy sypnal sie prad...

No to maszynka się zrestartowała. Powinieneś wywołać a lilo
init=/bin/ash.static i po starcie skorygować bład. Gdzie tu widzisz
potrzrbę posiadania permanentnie statycznego shella dla root-a ? Wybacz
ale tego nie widzę.

> o ile na pewno jakos przezylbym bez statycznego shella to jednak
> uporzadkowanie zajebloby mi kilka razy wiecej czasu! (musialbym w koncu
> cos odpalic jako init=... przy kernelu a poza glibc sypnelo sie troche
> dysku - wylaczyli zasilanie w czasie zapisu z wlaczonym cache-owaniem
> przez hdparma...).

Dla osoby która wie co chce zrobić powyższe zajmie mniej więcej tyle samo
czasu co i z shellem (na stałe) statycznym.

Przypadek z przed około czterech, pięciu lat. System dało mi się szybko
uratować tylko dlatego, że jako shella na dodatkowym roocie miałem tcsh.
Bash był dokumentnie skopany i ash.static także (porostu dysk zaczął się
sypać i skopana była dość duża powieżchnia root fs). Wtedy jeszcze nie
było możliwość podania w parametrach kernela init .. dzisiaj jest.

> To tak jak ucza w szkole - jak przechodzisz przez ulice to sie dobrze
> rozejrzyj. I nie ma znaczenia to ze wiekszosc ludzi cale zycie przechodzi
> bez rozgladania sie i nie zostaje potracony. Ja kiedys zaliczylem spotkanie
> z maska samochodu i teraz juz doskonale rozumiem czemu tak ucza skoro
> i tak wiekszosc pusci to mimo uszu.

Rozumiem ale bąćmy rosądni i nie rozciągajmy tego na obszar w którym
zaczyna się działanie podszyte paranoją.

Pisałem wielokrotnie, że można przystać na jakieś rozwiązanie o ile są
podstawy do tego żeby zachować się tak, a nie inaczej. W tym wypadku
pokazne juz wielokrotnie było chyba, że konieczności posiadania shella
statycznego takiego jak bash czy sh nie ma więc albo ktoś takie
uzasadnienie poda albo poprostu kończymy dyskusję. A skroro takowego
uzasadnienia nie będzie to do momentu aż się coś zmieni w tej materii nie
ma sensu dalej rozmawiać o linkowaniu statycznym powyższych shelli, a
co najwyżej powinniśmy mieć jednego statycznego ale możliwie
najmniejszego (np. ash).

I jeszcze raz podsumuję dlaczego tak ma być .. to znaczy dlaczego jeden i
w dodatku jak najmniejszy shell statyczny. Powód pierwszy jest taki, że
shell statyczny jest potrzebny do init rd, a tam miejsca za dużo nie ma.
Powód drugi jest taki, że shell statyczny jest potrzebny tylko w
sytuacjach awaryjnych i zawsze można doprowadzić do tego, że da się go
jakoś uruchomić, a jeżeli i ten shell jest walnięty to równie dobrze może
być i walnięty np. bash, którego tak na marginesie prawdopodobienstwo
uszkodzenie będzie jednak większe gdyż jest poprostu także i większy.
Powód trzeci jest taki, że skoro mamy jednego shella statycznego i nie
jest nim bash czy ksh bo są za duże, to i drugiego statycznego już nie
potrzebujemy.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*