rc-scripts i arp

[Tomasz Kłoczko]

On 15 May 2002, Arkadiusz Miskiewicz wrote:

> Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> writes:
> 
> > On 15 May 2002, Arkadiusz Miskiewicz wrote:
> > 
> > > Michal Margula <alchemyx w uznam.net.pl> writes:
> > > 
> > > > No właśnie ;-). Swoją drogą chyba użyję w skrypcie zamiast arp, ip, bo arp
> > > > chyba jest już deprecated?
> > > rc-scripts docelową będą jechały po ip ne + /etc/sysconfig/static-arp
> > > bez wsparcia dla /etc/ethers.
> > 
> > Nie wygaduj lepie bzdur :>
> Bardziej mnie interesuje to co o tym sądzi ANK, a nie Ty. Skoro ip ne samo
> nie próbuje znaleść interfejsu to znaczy, że były za tym jakieś przesłanki.
> Po szczegóły - mailto:ank

Uwaględnij jenak to że ANK moze mniej lub barziej świadomie ignorować 
istnienie NSS. Bez względu na to czy robi to świadonmie czy nei nie jest 
to coś czemu powinniśmy przytakiwać tylko dlatego że ANK jest tu 
autorytetem, Poprostu ludzie maja tendendencje do zapędzanai się.

Winne jest tu zapene to że wsparcie na obecnych systemach transferu 
ethers posiada wsparcie w samym NSS (w libc są nawet dwie funkcje do 
obsługi tego) ale ma słabe wsparcie na pziomie aplikacji co daje niby 
sygnał że jest to coś nie za barzo pzrenyślamnego gdy hjest tu zuopełnie 
inaczje.
Otóz mamy tu niepowtarzalna szanse uporzadkowanai tych zreczy i skończenia 
także tego co jest tu nie dokńczone.

A jakie są tu btraki ?
Otóż:

* aplikacje takie jak ip czy arp/rarp nie powinny wprost wiedzieć nic  
  pliku /etc/ethers. Czytanie tej mapy powinno odbywać się ppzrez API 
  jakei udosepnia glibc. Dzięki czemu po pzrestawieniu w 
  /etc/nsswitch.conf ustawień dla ethers z

ethers: file

na np.

ethers: nis

czy

ethers: ldap

odpowidni moduł do nss powinien zadbać o zassanie całej bazy z
odpowiedniego miejsca. Przypuszczam że mogą to nawet robic poprawnie ten
czy inny moduł też wspierać operacje na tej mapie ale nie ma nawet
możliwości obecnie przetestowania tego bez zmoyfikowanego arp/rarp które
byłytby nastawione na korzystanie z tych baz poprzez NSS. Pod czymś takim
przykładowo czy ethers byłoby przekazane z lokalnego pliku czy z serwera
NIS nie miało by to znaczenia, a stałby się mozliwe _wrszcie_ zarzadzaniem
takimi informacjami z jednego punktu (np. serwera NIS czy NIS+). Dokąłdnie 
tak samo jak z tym wszystkimco odwołuje się do /etc/{passwd,group,shadow,hosts}

Dopóty dopóki czegoś takiego nie będzie trzeba to sztukować w przypadku
NIS robiać ypcat na mapie ethers, przerzucaniem tego do lokalnego
/etc/ethers i karieniem dopiero arp/rarp czy ip.

> ethers zostanie, to wiadomo ale tylko opcjonalnie przy właczeniu jakiejś tam
> opcji.

Zainwestowałbym jednak w przeróbkę arp/rarp czy ip żeby korzystało z NSS
wprost. Poprostu efekt końcowy bedzie dużo lepszy i nei bezie zsie
ograniczał tylko do kilku pzrewidywanych obecnie zastosowań.  Poprostu
dzieki temu uzyska zsie nie inny ale wyzszy poziom funkcjonalnosci
całości. Całos poprostu stanie się wreszcie poręczna. Żródłą arp to chyab 
ze 2KB testu z czego połowa to komentarze. Przeróbka powinna być prosta.

Poprostu bez otwarcia się i zrozumienai wrszcie konsekwncji istrnenia NSS
mamy dalej zamknietą droge przed Linuxewm do grup stacji roboczych do
zarzadzania nimi w sposób cywilizowany poprzez NIS/NIS+/LDAP czycokowiek
innego o czego bedziesz się w stanie zrobic prosty mosuł do NSS.
Dorobienie tego w ten sposób da nam czyste wejście na pole które jest
nadal ugorem .. którego nie _masz nadal szans_ skopać robiąć to tym co 
zaproponowałeś.

Tu moze być jeszcze jeden dołek. Otóż mogą być tu jeszcze braki w samym
glibc i to też wymagałoby uzupełnienia/testowania.

Podobnie jak z mapą ethers jest z mapą netgroup która teortycznie daje
mozliwość zaradzniem uprawnieniami w grupie jednostek tym gdzie, kto może 
sie zalogować. To znowusz także wymagałoby jeszczepewnej pracy 
implementacyjnej na pziomie. Dostoswań pod tym kontem wymagałoby takze 
PAM.

O co w tym wszystkim poprostu chodzi ? Ano o rzecz prostą jak świńsko
ogon: żebyśmy nie wymyślali młotka w celu wbicia gwoździa. Młotek może być
obecnie niekopletny czy niesparwny ale po włożeniu do wody żeby trzonek
napęczniał powinien tymczasowo spełniać swoje funkcje dalej i czymś takim
może być obecne przystosowanie do korzystanai z ethers jakei jest obecnie
w rc-scripts. Na dłuzszą mete będzie to wymagało wystrugania nowego
trznonka (przeróbek konkretnych programów czy dorobieniem czegoś
brakujacego w glinc) niemniej sama metalowa końcówka młotka (NSS) jest
nadal użyteczna i nadal mało zużyta. Po naprawie całożć będzie słuzyła 
jeszcze latami.

I jeszcze jedno. Jest tu niewątpliwie pewiemn nieporządek ale zamiast
wprowadzać inny bałagan lepiej będzie zostawić to do mometu w którym
kttoś to zrobi porzadnie zgodnie z pewnym kierunkeim który został 
wycziony już _dawno temu_.
Podobie sytuacja ma się z naszym applnk. Mamy tu nieporządek ale nikt na
razie nie próbuje z racji tego nieporządku zastpować dobrego mechanizmu
czymś innym jak choćby menu z Debiana.
Chodzi o to żeby nieporzadek prowokował jeżeli już do tego żeby
coś posprzatać a nie żeby mówić że coś kompletnie należy wywalić i zrobic
to od początku.

Wracjaąc do początku listu to mam prostu obawy że powoływanie się na ANKa
jako autorytet może być tu poprstu w świetle powyższego błędem który
prowadzić będzie nie tam gdzie jest *właciwe* rozwiązanie bo on sam popstu
może sobie nie zdawać dobrze sparwy z konsekwencji istnienia NSS.

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*