Ubuntu Manpage: inetd, inetd.conf — superserwer internetowy

NAZWA

     inetd, inetd.conf — superserwer internetowy

SKŁADNIA

     inetd [-d] [-E] [-i] [-l] [-q długość] [-R częstość] [plik-konfiguracyjny]

OPIS

Inetd nasłuchuje połączeń na określonych gniazdach internetowych. Gdy na jednym z gniazd zaistnieje
połączenie, decyduje on, jakiej usłudze to gniazdo odpowiada i wywołuje program, który obsłuży żądanie. Po
zakończeniu programu, inetd kontynuuje nasłuchiwania gniazda (poza niektórymi wypadkami, opisanymi
poniżej). Ogólnie, inetd umożliwia używanie jednego demona do wywoływania wielu innych, zmniejszając
wymagane obciążenie systemu.

Dostępne są następujące opcje:

-d Włącza debugowanie.

-E Zapobiega ignorowaniu przez inetd środowiska. Bez tej opcji część potencjalnie niebezpiecznych
zmiennych środowiskowych, w tym PATH zostanie usuniętych i nie będzie dziedziczone przez usługi.

-i Program nie przechodzi w tryb demona.

-l Włącza logowanie połączeń i kontrolę dostępu przez libwrap. Usługi wewnętrzne nie mogą być
opakowywane. Gdy opcja jest aktywna, po cichu nie dokonuje się wykonania /usr/sbin/tcpd nawet gdy
jest ono obecne w pliku /etc/inetd.conf, a w zamian inetd bezpośrednio wywołuje libwrap.

-q długość
Określa długość kolejki połączeń listen(2) (domyślnie 128).

-R częstość
Określa maksymalną częstość, z jaką usługa może być wywołana w ciągu minuty (domyślnie 256). Jeśli
usługa przekroczy ten limit, inetd zapisze problem do dziennika i zaprzestanie obsługi żądań dla
danej usługi przez dziesięć minut. Więcej informacji można przeczytać też w poniższym opisie pól
wait/nowait.

Podczas uruchamiania, inetd odczytuje swoją konfigurację z pliku konfiguracyjnego, którym domyślnie jest
/etc/inetd.conf. Musi tam być wpis dla każdego pola pliku konfiguracyjnego, z poszczególnymi wpisami dla
danego pola; wpisy są oddzielane znakiem tabulacji lub spacji. Komentarze są zaznaczane przez “#” na
początku wiersza. Pola pliku konfiguracyjnego są następujące:

nazwa usługi (service name)
rodzaj gniazda (socket type)
protokół[,sndbuf=rozmiar][,rcvbuf=rozmiar]
(protocol[,sndbuf=size][,rcvbuf=size])
określenie, czy usługa ma "zwlekać" (wait/nowait[.max])
użytkownik[.grupa] lub użytkownik[:grupa]
(user[.group] lub user[:group])
program serwera (server program)
argumenty programu serwera (server program arguments)

Aby podać usługę opartą o Sun-RPC , wpis powinien zawierać te pola:

nazwa usługi/wersja (service name/version)
rodzaj gniazda (socket type)
rpc/protokół[,sndbuf=rozmiar][,rcvbuf=rozmiar]
(rpc/protocol[,sndbuf=size][,rcvbuf=size])
zwłoka (wait/nowait[.max])
użytkownik[.grupa] lub użytkownik[:grupa]
(user[.group] or user[:group])
program serwera (server program)
argumenty programu serwera (server program arguments)

W przypadku usług internetowych, pierwsze pole w wierszu może posiadać również wyrażenie określające adres
hosta, będące przedrostkiem oddzielonym dwukropkiem. Łańcuch będący w pierwszym polu przed dwukropkiem
określa wówczas którego adresu lokalnego ma użyć inetd przy nasłuchiwaniu dla tej usługi. W jednym wierszu
można podać wiele adresów lokalnych, oddzielonych dwukropkiem. Można wpisać adresy w postaci numeru IP
(cztery liczby oddzielone kropkami) lub nazw symbolicznych domen. Nazwy domenowe są sprawdzane za pomocą
getaddrinfo(). Jeśli dana nazwa ma przypisanych kilka adresów, inetd tworzy gniazda do nasłuchu na każdym
adresie.

Pojedynczy znak “*” oznacza INADDR_ANY, czyli “wszystkie adresy lokalne”. Aby zapobiec powtarzaniu adresów
występujących wielokrotnie, wiersz z wyrażeniami określającymi adresy hosta i dwukropkiem, bez kolejnych
pól, powoduje że adresy są zapamiętywane i używane do wszystkich kolejnych wierszy bez bezpośrednio
podanego wyrażenia określającego adres (do momentu napotkania kolejnego tak skonstruowanego wiersza lub
dotarcia do końca pliku). Wiersz
*:
jest bezpośrednio udostępniony na początku pliku, z tego powodu tradycyjne pliki konfiguracyjne (bez
wyrażeń określających adres hosta) będą interpretowane w tradycyjny sposób, czyli wszystkie usługi będą
nasłuchiwać na wszystkich adresach lokalnych. Jeśli protokół to “unix”, to ta wartość jest ignorowana.

Wpis nazwa-usługi jest nazwą prawidłowej usługi, zdefiniowanej w pliku /etc/services lub portem. Dla usług
“wewnętrznych” (internal) (opisanych niżej), nazwa usługi musi być oficjalną nazwą usługi (to znaczy
pierwszym wpisem w /etc/services). Podczas podawania usługi opartej o Sun-RPC, pole to jest prawidłową
nazwą usługi RPC, zdefiniowaną w pliku /etc/rpc. Część na prawo od “/” jest numerem wersji RPC. Może to
być zwyczajny argument numeryczny, lub zakres wersji. Zakres jest obramowany od niższej wersji do wyższej -
“rusers/1-3”. W przypadku gniazd UNIX-domain pole to określa ścieżkę gniazda.

Wpis rodzaj gniazda powinien być jednym z “stream” lub “dgram”, zależnie od tego, czy gniazdo jest
strumieniowe (stream) czy datagramowe (datagram).

Protokół musi być prawidłowym protokołem, podanym w pliku /etc/protocols lub w “unix”. Przykładami mogą
być “tcp” lub “udp”. Usługi oparte na RPC są podawane z typem usługi “rpc/tcp” lub “rpc/udp”. “tcp” i
“udp” będą rozpoznawane jako “TCP lub UDP zarówno w IPv4 jak i w IPv6”. Aby bezpośrednio wskazać IPv4 lub
IPv6 należy zastosować zapis taki jak w przykładach: “tcp4”, “udp6”. Protokół równy “unix” służy do
wskazania gniazda w UNIX-domain.

Oprócz protokołu, plik konfiguracyjny może określać rozmiary buforów nasłuchujących gniazd do wysyłania i
otrzymywania danych. Jest to szczególnie przydatne przy TCP, jako współczynnik skalujący okna, co bazuje na
fakcie, że rozmiar bufora gniazda danych otrzymywanych jest ogłaszany przy nawiązaniu połączenia, a zatem
rozmiar bufora gniazda serwera musi być ustawiony na gnieździe nasłuchującym. Zwiększając rozmiary buforów
gniazda, w pewnych sytuacjach można uzyskać lepszą wydajność TCP. Rozmiar buforów gniazda są podawane
przez dołączanie ich wartości do określenia protokołów, jak poniżej:

tcp,rcvbuf=16384
tcp,sndbuf=64k
tcp,rcvbuf=64k,sndbuf=1m

Można podać wartość dosłowną lub zmodyfikować ją podając ‘k’ do wskazania kilobajtów lub ‘m’ - jeśli chodzi
o megabajty.

Wpis wait/nowait (zwłoka) jest używany do przekazania inetd czy powinien on czekać na powrót programu
serwera, czy kontynuować obsługę połączeń na gnieździe. Jeśli serwer datagramowy łączy się ze swoim
rozmówcą, zwalniając gniazdo w ten sposób, że inetd może odbierać dalsze wiadomości z tego gniazda, to mówi
się o nim jako o serwerze “wielowątkowym” (multi-threaded) i powinno się używać wpisu “nowait” Serwery
datagramowe, które przetwarzają wszystkie nadchodzące do gniazda datagram, które ostatecznie przedawniają
się, nazywa się “jednowątkowymi” (single threaded) i powinno używać się dla nich wpisu “wait”. comsat(8)
(biff(1)) i talkd(8) są przykładami tego drugiego rodzaju serwerów datagramowych. Opcjonalny przyrostek
“max” (oddzielony od “wait” lub “nowait” kropką) określa maksymalną liczbę instancji serwera, jakie mogą
zostać postawione przez inetd w czasie 60 sekund, domyślnie wynosi 256. Jeśli usługa przekroczy ten limit,
inetd zapisze ten problem do dziennika i zaprzestanie obsługi żądań dla danej usługi przez dziesięć minut.
Proszę sprawdzić też opis opcji -R (powyżej).

Serwery strumieniowe są zwykle oznaczane jako “nowait”, lecz jeśli pojedynczy serwer strumieniowy ma
obsługiwać wiele połączeń, można go oznaczyć “wait”. Główne gniazdo zostanie wówczas przekazane jako fd 0
do serwera, który następnie będzie musiał akceptować połączenia przychodzące. Serwer powinien ostatecznie
przedawnić się i wyjść gdy nie będzie już aktywnych połączeń. inetd będzie kontynuował nasłuch na głównym
gnieździe czekając na połączenia, więc serwer nie powinien zamykać go przy wychodzeniu.

Wpis użytkownik powinien zawierać nazwę użytkownika, pod którym powinien uruchamiać się serwer. Umożliwia
to serwerom posiadanie mniejszych praw niż prawa roota. Opcjonalnie, po dodaniu kropki do nazwy
użytkownika, można podać w tym polu nazwę grupy. Umożliwia to serwerom pracę z innym (podstawowym)
identyfikatorem grupy niż ten, podany w pliku z hasłami. Jeśli grupa jest podana, a użytkownik nie jest
rootem, to uzupełniające grupy związane z użytkownikiem wciąż będą ustawione.

Wpis program serwera powinien zawierać ścieżkę programu, który ma być wywoływany przez inetd po otrzymaniu
żądania na gnieździe. Jeśli inetd udostępnia tę usługę wewnętrznie, to wpis ten powinien być wpisem
“internal”.

Wpis argumenty programu serwera powinien wyglądać tak jak zwykłe argumenty, poczynając od argv[0], który
jest nazwą programu. Jeśli usługa jest udostępniana wewnętrznie, to wpis powinien przyjąć nazwę “internal.”

Program inetd udostępnia wiele “trywialnych” usług wewnętrznie, używając do tego swoich własnych procedur.
Tymi usługami są “echo”, “discard”, “chargen” (generator znaków), “daytime” (odczytywalny przez człowieka
czas) oraz “time” (czas odczytywalny przez maszynę, liczba sekund od północy 1 stycznia 1900). Wszystkie
te usługi są oparte o tcp. Dla dalszych szczegółów o tych usługach, skonsultuj się z odpowiednim RFC z
Centrum Informacji Sieci (Network Information Center).

Inetd odczytuje swój plik konfiguracyjny od nowa gdy otrzyma sygnał zawieszenia (hangup), czyli SIGHUP.
Usługi mogą być tak dodawane, kasowane lub modyfikowane.

libwrap
Obsługa opakowań TCP jest włączona w program inetd w celu zapewnienia wbudowanej funkcji kontroli dostępu
podobnej do tcpd. Zewnętrzny program tcpd nie jest wymagany. Nie ma potrzeby zmian wpisu programu serwera w
/etc/inetd.conf do włączenia tej funkcji. inetd używa /etc/hosts.allow i /etc/hosts.deny do konfiguracji
usług kontroli dostępu, zgodnie z opisem w podręczniku hosts_access(5).

Zachowanie TCP/UDP w IPv6
Domyślnie uruchamiane są dwa serwery: jeden do obsługi ruchu IPv4, a drugi do IPv6. Przy innych
wymaganiach, może być konieczne podanie jednego lub dwóch odrębnych wierszy w pliku inetd.conf, dla “tcp4”
i “tcp6”.

W zależności od różnych kombinacji ustawień demona IPv4/IPv6 inetd będzie wykazywał następujące zachowanie:
• Jeśli ma się jedynie jeden serwer - “tcp4”, ruch IPv4 będzie przekierowany na serwer. Ruch IPv6 nie
będzie akceptowany.
• Jeśli ma się dwa serwery, tzn. “tcp4” oraz “tcp6”, to ruch IPv4 będzie przekierowany na serwer “tcp4”,
a ruch IPv6 będzie przekierowany na serwer “tcp6”, co jest identyczne z domyślnym rozwiązaniem
stosowanym gdy poda się wyłącznie “tcp”.
• Jeśli ma się jedynie jeden serwer - “tcp6”, jedynie ruch IPv6 będzie przekierowany na serwer.

Specjalny parametr “tcp46” można wykorzystać przy przestarzałych serwerach, które wymagają połączenia
IPv4 przepisanego na gniazdo IPv6. Nie zaleca się używania tego parametru.

PLIKI

     /etc/inetd.conf

ZOBACZ TAKŻE

     fingerd(8), ftpd(8), identd(8), talkd(8)

HISTORIA

     Polecenie inetd pojawiło się w 4.3BSD.  Obsługa usług opartych na Sun-RPC została utworzona wg
     udostępnionej przez Sun-OS 4.1. Obsługę IPv6 dodano w projekcie KAME w 1999.

     Marco d'Itri przeniósł ten kod z OpenBSD latem 2002 roku oraz dodał możliwość modyfikacji buforów gniazd
     oraz obsługę libwrap z drzewa źródeł NetBSD.

USTERKI

     Na systemach linuksowych demon nie może przeładować swojej konfiguracji. Trzeba go zrestartować jeśli
     zmienił się adres hosta dla usługi pomiędzy “*” i wyrażeniem określającym adres.

     Programy serwera używane z “dgram” “udp” “nowait” muszą czytać z gniazd sieciowych lub inetd będzie mnożył
     procesy aż do osiągnięcia limitu.

     Wyrażenia określające adres hosta, choć ich koncepcja ma sens przy usługach RPC, nie działają do końca
     poprawnie. Dzieje się tak w dużej części z powodu faktu, iż interfejs portmappera nie udostępnia metody
     rejestracji różnych portów dla tej samej usługi na różnym adresie lokalnym. Jeśli nie będzie się używało
     więcej niż jednego wpisu dla danej usługi RPC, to wszystko powinno działać poprawnie (proszę zauważyć, że
     do wierszy RPC bez bezpośredniego określenia adresu ma zastosowanie domyślne wyrażenie określające adres
     hosta).

TŁUMACZENIE

     Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Przemek Borys <pborys@dione.ids.pl> i
     Michał Kułach <michal.kulach@gmail.com>

     Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać
     zapoznając się z GNU General Public License w wersji 3: https://www.gnu.org/licenses/gpl-3.0.html lub
     nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

     Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej
     manpages-pl-list@lists.sourceforge.net .