ftp, rc-inetd, tcpserver

[Tomasz Kłoczko]

On Mon, 11 Oct 1999, Bartosz Waszak wrote:

> On pią, paź 08, 1999 at 12:22:06 +0200, Jan Rekorajski wrote:
> 
> >> tzn ja dodalem inetd.sh z modulu rc-inetd do speca inetd.spec  i do innych
> >> specy pliki *.inetd
> 
> > To fajnie :) Bo bałem się że robisz od nowa pliki *.inetd.
> 
> Swoją drogą jak powinno to wyglądać  z Requires   do  takich pakietów,  ja na
> razie ładuje   tylko  rc-inetd i inetdaemon, ale  nie wiem powinno wystarczyć
> samo  inetdaemon  bo  inetdeamony  już wymagają  rc-inetd.

Wystarczy tylko rc-inetd. rc-inetd wymaga już sam inetdaemon. Jeżeli
gdzieś jes nadmiarowość to nie jest ona błędem i w razie czego można ją
usuwać.

> Przegladałem sobie
> spece i  wpadłem na  genialny pomysł przydałby się jakiś szablon speca (chyba
> już nawet istnieje) i zmodyfikować  spece wg niego aby wyglądały mniej więcej
> tak samo to  by było od  strony   kosmetycznej.

Właśnie wykończyłem chyba pierwszego speca który jest już przygotowany do
rc-inetd. Podstawowa cacha jaką powinein mieć
spec opisujacy serwis to
oprócz powyższrgo także:

%post
/etc/rc.d/init.d/rc-inetd restart >&2

%postun
if [ "$1" = "0" ] ; then
       /etc/rc.d/init.d/rc-inetd restart >&2
fi

po to żeby po zainstalowaniu pakietu z sewisem wykonac resytart ineta w
trakcie którego nastąpi min wygenerowanie nowego pliku konfiguracyjnego
właściwego dla danego inet serwera. Podobnie przy usuwaniu pakietu.
Zaraz zrzucę speca do pidenta to bedzies mógł go traktoewać jako takiego
wzorcowego. Włąsnie sprawdzięłm że {de}instalacja pakietu powoduje ładnie
aktualizację tego co jest obecne via inet serwer czyli teraz kontrolowanie
tego obszaru powinno być już łatwiejsze :-)

Jest jeszcze jeden błąd w rc-inetd. Otóż skrypt ten nie jest przygotowany
na ewentualność gdy nie ma ani jednego pliku w /etc/sysconfig/rc-inetd
także już jest to sygnał że trzeba będzie wypuścić jeszcze jedna wersję
rc-inetd.

> Teraz  następna sprawa, którą
> trzeba   rozpatrzeć  - pakiety   np:   imap.spec, zawierają    kilka daemonów
> (pop2,pop3,imap)   sądze, że pakiety tego typu powinny być rozdzielony,    na
> każdego powinien przypadać jak wspomniałem we wcześniejszym poście  Provides:
> {pop3daemon,imapdemon},  i ustalić jakąs   politykę  postępowania z tego typu
> pakietami, na obecnym etapie bym wydzielił:

O ile da się rozdzielić to owszem. W przypadku imap/pop z pakietu imap
jest ten kłopot że używają one wspólnego pliku konfiguracujnego w
/etc/pam.d/. Tak czy inaczej do pakietów tego typu wartoby przywiązać
nazwę pseudopakietu żeby nie dopuszczać do sytuacji w której doszło do
zainstalwoanai kilku imap czy pop serwerów.

> o--------------o-----------------------------------------------------o\
> |  Provides:   |   Obsoletes:                                        | |
> o--------------o-----------------------------------------------------o\|
> | smtpdemon    | qmail, zmailer i ferajna                            | |
> | fingerdaemon | ffingerd, finger, cfingerd                          | |
> | imapdaemon   | imap.spec (wydzielony sam /usr/sbin/imapd)          | |
> |              | cyrus, tak samo popdaemon                           | |
> | ftpserver    | proftpd, wu-ftpd(6), ellipso, oraz ftpd             | |
> |              | wydzielone z pakietów heimdal, krb5                 | |
> | tftpdaemon   | tftp, utftp, i jeszcze zapewne jakiś dojda          | |
> | ping         | naliczyłem się 3 pakietów z pingiem, jak            | |
> |              | porządek to porządek                                | |
> | telnetdaemon | ogólnie jest jeden spec typowo z telnetd'em ale     | |
> |              | kerberosy mają swoje telnety                        | |
> |    [...]     | wogóle wszystkie pakiety których jakiś składnik się | |
> |              | powtarza powinien mieć swój Provides:               | |
> o--------------o-----------------------------------------------------o |
>  \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|

Ano właśnie coś na wzór powyższego (powyższe jest w tej chwili
chyba do łyknięcia jako w całości).
Może tylko dla ujednolicenia wartoby mieć raczej wszędzie nazwy *daemon, a
w tych kilku przyadkach, które są wynikiem zaszłości z RH dodać *server.

Albo możan raczej też trzymać się nazw *server (co nie wchodziłoby w
konflikt z tym co już jest .. To chyba byłoby w zwiazku z tym lesze).

> Trzecia  rzecz, jeśli już się  zajmujemy tymi niekonwencjonalnymi    metodami
> autentykacji (LDAP, Kerberos) trzeba by opracować jakąś  metodę modyfikowania
> plików  /etc/pam.d/*,  czy też dopisać wszystkie inne możliwości autentykacji
> moduł pam_ldap, pam_smb, jako sufficent albo coś w tym stylu.

Sprawa dotyczy także pam_ncpfs z marsa, który też powinien ulec
odseparowaniu, bo mars może być używany bez pam_ncpfs (ciekawe czy jest tu
jakiś moduł NSS do NCP (?) .. przydałby się). Na dobrą sprawę pakiety
zawierajace te moduły mołyby wykonac odpowiednia modyfikację. Coś
podobnego planowałem w przypadku modułów NSS z glibc. Obecnie w glibc są
jeszcze moduły do hesiod, nic, nisplus ale raczej nalezałóby je wydzielić
bo ich obecność by default aż kusi do tego żeby poprzez nie próbować
imporować jakieś bazy z zewnątrz z użytkownikami itd. moduł NSS do LDAP
już jest w osobnym pakiecie. pam_ldap także. W tym wypadku co do smb, kerb
czy ncp, a takze NIS, NIS+ możnaby zastosować jednolity schematr
podejścia. W którym dodatkowo pakiety pam_* powinny wymagać pakietów nss_*
i jednocześnie pakiety pam_* modyfikowałyby pliki /etc/pam.d, a nss_*
/etc/nsswitch.conf (odpadłoby używanie authconf do takich rzeczy).

Modyfikację /etc/nsswitch.conf możnaby wyskubać z authconf z RH tworząc
jakieś małe narządko do operowania na tym pliku. Z plikami z /etc/pam.d/
może być troche więcej tańcowania (szkoda, że pwdb nie działa jak było
planowane; gdyby tak było to w zasadzie cała sprawa powinna się rozbijać
o modyfikację tylko /etc/pwdb.conf bez konieczności modyfikowania plików
z /etc/pam.d/ .. może warto w ten kierunek na dłuższą metę jednak troche 
poinwestować (?) Janek co Ty na to ?).

> Poza  tym pkaiety  strasznie  niekonsekwetnie    są przydzielane    do  grup,
> ftpservery jedne do Networking/Daemons inne do Daemons.

Sprawa przydziału do grup to jest osona bajka. Jeżeli masz chęć zajać się
tu jakimś systematyzowanie to proszę bardzo. Niemniej wydaje się, że
przynajmniej w nazwach tych grup pakietów jakie są wciskane w Group
możnaby myśleć odrazu o instalatorze (nie konieczne ale dopuszczamnle i
chyba jak najbardziej zalecane wykonywanie takich ruchów gdyż Group ma
żaden wpływ na działanie pakietu niosąc w sobie tylko informacje
"porzadkujące" które przy wyborze pakietów powinny wręcz pomagać).

Wydaje się że punktem wyścia w tej materii mogłoby być przedtawienie
gdzeiś stanu obecnego na podstawie obecnej zawarości speców (moznaby
obrobić spece w celu wyłuskania par nazwa pakieytu (wynikowego) <-> Group.
Mozanby to moze gdzeiś wręcz na bierząco wrzucać na www żeby taki rejest
był na bierząco obecny (na początku powinno to być pomocne w celu
zaplanowania nowewj hierarhii lub korekty obecnej czy też przejęciu
pewnych elementów z np. RH, a potem mogłoby być trzonem stron z opisem i
rejestrem pakietów na www).

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*