Ksh static - ale jak ? ;)

[Tomasz Kłoczko]

On Sun, 6 Jun 1999, Marek Obuchowicz wrote:
[..]
> > 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 chodzi o *-noroot.patch to w tej chwili pokazuje on tylko informację
> że podanej czynności nie powinno się robić, po czym można kontynuować.
> A co do domyślnego shella to przepraszam, ale chyba trochę przesdziłeś
> w swojej wypowiedzi. Robiąc dystrybucję TRZEBA założyć kilka rzeczy.
> Chyba, że chcesz aby instalacja polegała na kilkugodzinnnym podawaniu
> podstawowych parametrów. Na wszystkich dystrybucjach linuxa jakie
> widziałem przy dodawaniu użytkownika jako domyślny shell jest podawany
> /bin/bash...... ty uważasz że jak to należy zrobić??
> nie podawać domyślnego shella? oki, nie ma problemu, ale DLACZEGO?
> skoro większośc administratorów zakładając konta i tak wpisze swój
> ulubiony shell który statystycznie najczęściej jest bashem....
> pamiętaj że jak chcesz dodać kogoś z shellem tcsh to i tak musisz w adduserze
> dokładnie tyle samo znaków wpisać jeżeli domyślnym shellem byłby bash i ""
> A ustawienie domyślnego /bin/bash po prostu da zaoszczędzić czasu
> niektórym.

Wstawienie domyślnie shella np. /bin/bash, a ustawienia domyślne to dla
mnie dwie różne rzeczy. Jest sobie np. plik /etc/defaults/adduser, a w nim
i domyślny shell dla nowych użytkowników, który z tym co przychodzi z
dystrybucją nie musi mieć wcale wiele wspólnego. W tym sensie dalsze
nadawanie formy innym pakietom na podstawie zawartości na przykład trgo
pliku traci sens lub jak wolisz sensu nie ma. W tym sensie nie są to
ustawienia domyślne co początkowe.

> > 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.

> Oki, ale już wyżej piszę że każdy musi założyuć jakieś ustawienie 
> domyślne... nawet jeżeli my tego nie zrobimy to root dodając użytkownika
> i tak na 99% wpisze mu swojego ulubionego shella (jeżeli nie będzie
> jakiegoś domyślnego), skoro i tak zawsze można go sobie samemu zmienić!

Chodzi o to żeby bynajmniej na postawie takiego parametru jak pczątkowy
shell dla nowo tworzonych użytkowników nie brać za paramert mogący służyć
do uformowania tegoczy innego pakietu.

[..]
> > 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).

> Oki, tylko że mi się wydaje że nie do końca się z Wojtkiem dogadałeś...
> albo to ja źle rozumiem :)
> w każdym razie Wojtkowi chodzi o to, żeby root miał domyślnie shella
> statycznego nie zważając czy jest to /bin/bash czy /bin/bash.static
> czy /bin/jakieś.inne.cholerstwo-i-w-ogole-2.46654.21theta
> a Ty zrozumiałeś że Wojtkowi chodziło o to żeby /bin/bash był
> statyczny....

W tym sensie nie jest to tak jak wyżej ustawienie domyślne na postawie
którego masz prawo podejmowania jakichkolwiek dalszych kroków co
ustawienie początkowe. I tutaj wszelka inwencja powinna się kończyć gdyż
wszystko co ponadto będzie posztrzegane jako niczym nie uzasadnione
narzucanie komuś woli.

> Ja ciągle popieram to, aby /bin/bash był dynamiczny a root miał
> swojego shella /bin/bash.static.

Owszem poieraj to. Używaj tego jeśli chcesz ale nadal nie ma to nic z
czymkolwiek co pozwalać by ci mogło na wymuszanie takie stanu rzeczy.

> Dlaczego bash a nie ash?
> nie wiem jak duża jest różnica między binarną wersją statycznego
> ash i basha ale IMO w sytuacji kiedy system się posypał na nogi
> a szef się pyta dlaczego nie działa trzymając w jednej ręce
> skargi od klientów a w drugiej nie podpisane (jeszcze) zwolnienie
> to shell który jest po prostu niewygodny może być bardzo frustrujące...

Przepraszam w tym wypadku i w każdym innym niestety nie możemy przyjąć do
wiadomości czegoś czego się nie da uzasadnić. Panuje swego rodzaju atawizm
mówiący, że niby statyczny shell ma przed czymś chronić. Otóż nie chroni,
a przynajmniej nikt jak na razie takiego uzasadnienia nie podał. Są pewne
sytuacje które wymagałyby shella statycznego i o tym już było tu
wieleokrotnie ale nie ma to związku z kononiecznością posiadania
statycznego interactiv shella na jakimkolwiek koncie. Rozumiem, że ktoś
dla własnego psyhiczneg komfortu może czegoś takiego potrzebować. Niemniej
takie wewnętrzne potrzeby tak jak napisałem powyżej są z regóły wyynikiem
isteninia owego atawizmu wynikającego z tego, że kiedyś nie można było
zrobić takiego triku jak obecnie polegającego na mozliwości podania
programu robiacego za init. Dzisiaj takiej konieczności nie ma więc można
sobie spokojnie powiedzieć, że można skończyć z czyms co dzisiaj ma już
charakter zabobonu. Jeżeli ktoś ma zamiar kultywaować tą tradycję to nie
ma sprawy niech to robi niemniej w zasobach wchodzących w skąłd
dystrybucji konieczności kultywowanai czegoś takiego nie wiedzę.

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*