ftp, rc-inetd, tcpserver

[Tomasz Kłoczko]

On Sun, 17 Oct 1999, Grzegorz Stanislawski wrote:
[..]
> Jeszcze jedna kwestia: "W kazdej rzeczy miary patrzaj."
> 
> Do kazdego bardziej zaawansowanego systemu autoryzacji (obojetnie czy to
> kerberos, ldap czy radius) admin musi dojzec/dorosnac i podjac suwerenna
> decyzje czy jest mu to potrzebne.
> Latwy i przyjemny skrypt spowoduje tylko to ze jakies lamy majace linuxy
> po domach i majace dwa konta dla siebie i brata, beda meczyc wszystkich
> na #plug na przyklad "co to jest ten ldap bo sie nie moge na moja maszynke
> zalogowac. Ech do kitu jest ten pld".

A i owszem masz rację .. "W kazdej rzeczy miary patrzaj.".

Zmuszanie każdego do tego, żeby sam ręcznie przenosił bazę użytkowników do
LDAP (choć i za pomocą MigrationTools) czy też sam po dodaniu w systemie
wsparcie do LDAP w postaci modułu NSS do LDAP żeby zmodyfikował
nsswitch.conf czy też w następnym etapie po dodaniu pam_ldap żeby sam
ręcznie zmodyfikował wszystkie pliki w /etc/pam.d to jest poprostu
przesada .. i to nawet na potrzeby tych co dobrze wiedzą co robią. To tak
jakby pozbawiać się możliwości korzystania z pwconv do odseparowania haseł
w shadow. Z PAM jest o tyle źle, że w zasadzie taka modyfikacja nie byłaby
wogóle potrzebna o ile poprawnie funkcjonowałby i byłby nadal rozwijany
pam_pwdb, gdyz to ten moduł miał załatwiać zunifikowany interfejs do
rożnych typów baz potrzebnych przy autentykacji. Gdyby nie to, to operacje
konieczne do wykonania przejścia np. na LDAP byłyby znacznie prostrze.

We wszelkiej automatyzacji chodzi nie tyle o wspomaganie osadzania np.
pakietu w środowisku co bardziej o odseparowanie w pewiem dobrze
wytestowany podprogram (moze być i w sh) który wykona _tylko_ to co
konieczne i w stu procentach powtarzalne przy okazji jakieś operacji np.
przejścia na trzymanie niektórych baz w LDAP.

Reszta zgodzę się, że może być i najprawdopodobniej będzie przesadą. Takim
wykroczeniem do pewnego stopnia mogłoby się wydawać przeciw tej zasadzie
jest to co sie dzieje w rc-inetd, niemniej tutaj poprostu mam nadzieję, że
tworząc coś takiego tworzy się nie inna co lepszą jakość .. wogóle. Co
samo w sobie usprawiedliwia taki krok (IMHO). Radziłbym zwróciś uwagę na
to, ze napisałem "moze być i najprawdopodobniej będzie", bo IMHO tak czy
inaczej od tego kierunku tak wogóle nie należy się programowoe odcinać i
to tylko dlatego, że z kupy śmieca od czasu do czasu daje się wyskrobać
coś przydatnego/porzytecznego i to tylko dlatego, że ktoś coś np. wyrzucił
(tak jak to ma miejsce z modularnymi skryptami do Xsession jakie znalazłem
w dyskusjach na debian-devel, a w których kryje sie IMHO potencjał jakiego
możemy potrzebować próbując robić naprawde dobre narzędzia nie chcąć
zamykać się w kregu konkretnych window managerów czy środowisk typu
desktop).

Jeszcze co do rc-inetd bo akurat kilka dni temu rozmawiałem ze znajomym
który używa OpenBSD opowiadajac mu o tym czymś. Otóż jego kontrargument
był taki (niepodobało mu się to), że niezależnie od tego co ma się
zainstalowane w O*BSD jest to, że admin musi to świadomie w pewnym
momencie włączyć. IMHO w tym wypadku etap wcześniejszego instalowania jest
zbędny i można się ograniczyć do świadomego zainstalowania pakietu, który
sam z siebie wykona wszystkie żmudne i powtarzalne operacje. W sytuacji
kiedy tenże sam pakiet tak samo wykona wszystko co trzeba przy usuwaniu
reakcja na błąd w konkretnym pakiecie jest o wiele prostrza i łatwiejsza
do kontroli gdyż wystarczy poprostu usunąć wadliwy pakiet bez zbędnego
palcowania po czasami kilku plikach i wykonywaniu dodatkowych operacji.
Ten mój znajomy kładł silny nacisk na ową śwaidomość ruchów. Ja natomiast
ripostowałem tym, że równeidobzre domorosły użytkownik O*BSD działając
metodą Macajewa moze czytać losowe fragmenty dokumentacji wybierając z
nich tylko to jak należy posczególen rzeczy włączać nie zaprzatajac sobei
nadal głowy tym co tak wogóle włącza czyli, że to zabezpieczenie jakie ma
tkwić w idei używanai O*BSD jest li tylko pozorne i potencjalnie
jaknajbardziej (za)często niezauważalne dla dowolnie wybranego wybanego
nowicjusza.

Dodam tylko tyle, że w miarę szerszego eksploatowania "pola automatyzacji"
owszem granica między tym co sensowne, a niebezpieczne zaczyna sie mocno
zwężać do szerokości przy której łatwo ją przez przypadek przekroczyć nie
zauważając jej. Niemniej próby eksploatacji tego obaszaru uważam, że są
naprawdę dość ważne .. tylko dlatego, że mało kto dotąt próbował to robić
widząc w tym raczej zagrożenia niż korzyści.
Faktem jest też to że chcąć sie poruszać po tym obszarze trzeba więcej
uwagi poświecać na to jak się mysli o danym zagadnieniu i jakie skutki
wywiera to na otoczenie .. niemniej myślę, że w grupie będzie łatwiej
zachować odpowiedni poziom dyscypliny myślenia, która pozwoli na w miarą
rzadkie branie śmiecia za kamień szlachetny.

Co powiesz na takie podejście Grasiek ?

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*