NUME¶

inetd, inetd.conf — super-server de internet

SINOPSIS¶

inetd [-d] [-E] [-i] [-l] [-q lungime] [-R rata] [fișier-configurare]

DESCRIERE¶

inetd ascultă conexiuni pe anumite socluri de internet. Atunci când se găsește o conexiune pe unul dintre aceste socluri, decide cărui serviciu îi corespunde soclul și invocă un program pentru a răspunde cererii. După ce programul este terminat, continuă să asculte pe soclu (cu excepția unor cazuri care vor fi descrise mai jos). În esență, inetd permite rularea unui demon pentru a invoca mai mulți alții, reducând astfel sarcina sistemului.

Opțiunile sunt următoarele:

-d

Activează depanarea.

-E

Împiedică inetd să curețe mediul. Fără această opțiune, o selecție de variabile de mediu potențial dăunătoare, inclusiv PATH, va fi eliminată și nu va fi moștenită de servicii.

-i

Face ca programul să nu se transforme în demon.

-l

Activează jurnalizarea conexiunii libwrap și controlul accesului. Serviciile interne nu pot fi învăluite. Atunci când este activat, /usr/sbin/tcpd nu este executat în mod silențios, chiar dacă este prezent în /etc/inetd.conf și, în schimb, libwrap este apelată direct de inetd.

-q lungime

Specifică lungimea cozii de așteptare a conexiunilor listen(2); valoarea implicită este 128.

-R rata

Specifică numărul maxim de apeluri ale unui serviciu într-un minut; valoarea implicită este 256. În cazul în care un serviciu depășește această limită, inetd va înregistra problema și va înceta să servească cererile pentru serviciul respectiv timp de zece minute. A se vedea, de asemenea, câmpurile de configurare „wait/nowai”t de mai jos.

La execuție, inetd își citește informațiile de configurare dintr-un fișier de configurare care, în mod implicit, este /etc/inetd.conf. Trebuie să existe o intrare pentru fiecare câmp al fișierului de configurare, cu intrări pentru fiecare câmp separate prin tabulator sau spațiu. Comentariile sunt marcate de un “#” la începutul unei linii. Câmpurile din fișierul de configurare sunt următoarele:

nume serviciu
tipul de soclu
protocol[,sndbuf=dimensiune][,rcvbuf=dimensiune]
wait/nowait[.max]
utilizator[.grup] sau utilizator[:grup]
programul de server
argumentele programului de server

Pentru a specifica un serviciu bazat pe Sun-RPC, intrarea ar trebui să conțină aceste câmpuri.

numele/versiunea serviciului
tipul soclului
rpc/protocol[,sndbuf=dimensiune][,rcvbuf=dimensiune]
wait/nowait[.max]
utilizator[.grup] sau utilizator[:grup]
programul de server
argumentele programului de server

În cazul serviciilor de internet, primul câmp al liniei poate avea, de asemenea, un specificator de adresă de gazdă prefixat, separat de numele serviciului prin două puncte. În acest caz, șirul de caractere care precede două puncte din primul câmp indică adresa locală pe care inetd trebuie să o folosească atunci când ascultă serviciul respectiv. Se pot specifica mai multe adrese locale pe aceeași linie, separate prin virgule. Se pot utiliza atât adrese IP numerice în notație „XXX,XXX,XXX.XXX”, cât și nume de gazdă simbolice. Numele de gazdă simbolice se caută folosind getaddrinfo(). Dacă un nume de gazdă are mai multe corespondențe de adrese, inetd creează un soclu pentru a asculta la fiecare adresă.

Caracterul simplu “*” indică INADDR_ANY, ceea ce înseamnă “toate adresele locale”. Pentru a evita repetarea unei adrese care apare frecvent, o linie cu un specificator de adresă gazdă și două puncte, dar fără alte câmpuri, face ca specificatorul de adresă gazdă să fie reținut și utilizat pentru toate liniile ulterioare fără un specificator de gazdă explicit (până la o altă astfel de linie sau până la sfârșitul fișierului). O linie

Intrarea nume serviciu este numele unui serviciu valid din fișierul /etc/services sau un număr de port. Pentru serviciile “interne” (discutate mai jos), numele serviciului trebuie să fie numele oficial al serviciului (adică prima intrare în /etc/services). Atunci când este utilizat pentru a specifica un serviciu bazat pe Sun-RPC, acest câmp este un nume de serviciu RPC valabil în fișierul /etc/rpc. Partea din dreapta lui “/” este numărul versiunii RPC. Acesta poate fi pur și simplu un singur argument numeric sau un interval de versiuni. Un interval este delimitat de versiunea mică până la versiunea mare - “rusers/1-3”. Pentru soclurile UNIX-domain, acest câmp specifică numele rutei soclului.

tipul soclului trebuie să fie unul dintre “stream” sau “dgram”, în funcție de faptul că soclul este un soclu de flux sau de datagramă.

protocol trebuie să fie un protocol valid, așa cum este indicat în /etc/protocols sau “unix”. Exemple ar putea fi “tcp” sau “udp”. Serviciile bazate pe RPC sunt specificate cu tipul de serviciu “rpc/tcp” sau “rpc/udp”. “tcp” și “udp” vor fi recunoscute ca fiind “TCP sau UDP atât pe IPv4, cât și pe IPv6”. Dacă trebuie să specificați explicit IPv4 sau IPv6, utilizați ceva precum “tcp4” sau “udp6”. Un protocol protocol de “unix” este utilizat pentru a specifica un soclu în UNIX-domeniu.

În plus față de protocol, fișierul de configurare poate specifica dimensiunile memoriilor tampon de trimitere și de primire pentru soclul de ascultare. Acest lucru este util în special pentru TCP, deoarece factorul de scalare a ferestrei, care se bazează pe dimensiunea memoriei tampon a soclului de recepție, este anunțat atunci când are loc negocierea conexiunii, astfel încât dimensiunea memoriei tampon a soclului pentru server trebuie să fie stabilită pe soclul de ascultare. Prin mărirea dimensiunilor memoriilor tampon ale soclurilor, se pot obține performanțe mai bune ale TCP în anumite situații. Dimensiunile memoriilor tampon ale soclurilor sunt specificate prin adăugarea valorilor lor la specificația protocolului, după cum urmează:

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

Se poate specifica o valoare literală sau se poate modifica folosind ‘k’ pentru a indica kiloocteți sau ‘m’ pentru a indica megaocteți.

Intrarea wait/nowait este utilizată pentru a indica lui inetd dacă trebuie să aștepte returnarea programului server sau să continue procesarea conexiunilor pe soclu. Dacă un server de datagrame se conectează la omologul său, eliberând soclul pentru ca inetd să poată primi alte mesaje pe soclu, se spune că este un server “multi-threaded” și ar trebui să utilizeze intrarea “nowait”. În cazul serverelor de datagrame care procesează toate datagramele primite pe un soclu și care, eventual, depășesc timpul de așteptare, se spune că serverul este “single-threaded” și ar trebui să utilizeze o intrare “wait”. comsat(8) (biff(1)) și talkd(8) sunt ambele exemple de acest ultim tip de server de datagrame. Sufixul opțional “max” (separat de “wait” sau “nowait” printr-un punct) specifică numărul maxim de ori de câte ori un serviciu poate fi invocat într-un minut; valoarea implicită este 256. În cazul în care un serviciu depășește această limită, inetd va înregistra problema și va înceta să servească cererile pentru serviciul respectiv timp de zece minute. A se vedea, de asemenea, opțiunea -R de mai sus.

Serverele de flux sunt de obicei marcate ca “nowait”, dar dacă un singur proces server trebuie să gestioneze mai multe conexiuni, acesta poate fi marcat ca “wait”. Soclul principal va fi apoi transmis ca fd 0 către server, care va trebui să accepte conexiunea de intrare. În cele din urmă, serverul ar trebui să se oprească și să iasă atunci când nu mai sunt active alte conexiuni. inetd va continua să asculte conexiunile pe soclul principal, astfel încât serverul nu trebuie să îl închidă atunci când iese.

Intrarea utilizator trebuie să conțină numele de utilizator al utilizatorului sub numele căruia trebuie să ruleze serverul. Acest lucru permite ca serverele să primească mai puține permisiuni decât root. Un nume de grup opțional poate fi specificat prin adăugarea unui punct la numele de utilizator urmat de numele grupului. Acest lucru permite ca serverele să funcționeze cu un ID de grup (primar) diferit de cel specificat în fișierul de parole. Dacă este specificat un grup, iar utilizatorul nu este root, grupurile suplimentare asociate cu acel utilizator vor fi totuși selectate.

Intrarea program de server trebuie să conțină numele de rută al programului care urmează să fie executat de inetd atunci când se găsește o cerere pe soclul său. În cazul în care inetd furnizează acest serviciu în mod intern, această intrare trebuie să fie “internal”.

Argumentele programului de server ar trebui să fie la fel ca argumentele obișnuite, începând cu argv[0], care este numele programului. În cazul în care serviciul este furnizat intern, cuvântul “internal” trebuie să înlocuiască această intrare.

inetd furnizează mai multe servicii “triviale” în mod intern prin utilizarea de rutine în interiorul său. Aceste servicii sunt “echo”, “discard”, “chargen” (generator de caractere), “daytime” (ora lizibilă pentru oameni) și “time” (ora lizibilă pentru mașini, sub forma numărului de secunde de la miezul nopții, 1 ianuarie 1900). Toate aceste servicii se bazează pe TCP. Pentru detalii despre aceste servicii, consultați RFC-ul corespunzător de la Network Information Center.

inetd își recitește fișierul de configurare atunci când primește un semnal de întrerupere, SIGHUP. Serviciile pot fi adăugate, șterse sau modificate atunci când fișierul de configurare este recitit.

FIȘIERE¶

/etc/inetd.conf

 

CONSULTAȚI ȘI¶

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

ISTORIC¶

Comanda inetd a apărut în 4.3BSD. Suportul pentru serviciile bazate pe Sun-RPC este modelat după cel oferit de SunOS 4.1. Suportul IPv6 a fost adăugat de proiectul KAME în 1999.

Marco d'Itri a adaptat acest cod de la OpenBSD în vara anului 2002 și a adăugat reglarea memoriilor tampon de soclu și suportul libwrap din arborele sursă NetBSD.

ERORI¶

Pe sistemele Linux, demonul nu-și poate reîncărca configurația și trebuie repornit atunci când adresa de gazdă pentru un serviciu este schimbată între “*” și o adresă specifică.

Programele server utilizate cu “dgram” “udp” “nowait” trebuie să citească de pe soclul de rețea, altfel inetd va genera procese până când se atinge maximul.

Specificatorii de adrese gazdă, deși au un sens conceptual pentru serviciile RPC, nu funcționează în totalitate corect. Acest lucru se datorează în mare parte faptului că interfața „portmapper” nu oferă o modalitate de a înregistra porturi diferite pentru același serviciu pe adrese locale diferite. Cu condiția să nu aveți niciodată mai mult de o intrare pentru un anumit serviciu RPC, totul ar trebui să funcționeze corect. Rețineți că: specificatorii de adrese gazdă implicite se aplică liniilor RPC fără un specificator explici).

TRADUCERE¶

Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu <remusgabriel.chelu@disroot.org>

Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO RESPONSABILITATE.

Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-ro@lists.sourceforge.net