/etc/services

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Wto, 6 Paź 1998, 17:01:57 CEST


On Tue, 6 Oct 1998, Pawel Krawczyk wrote:

> On Tue, Oct 06, 1998 at 12:54:28AM +0200, Tomasz Kłoczko wrote:
> > > A jak ktoś będzie chciał sobie na RH radiusa zainstalować?
> > > imo pliki typu /etc/services itp muszą mieć %verify (not size mtime md5)
> > /etc/services ma znaczenie wyłącznie informacyjne i bez niego mozna się
> > obejśc tak samo jak bez DNS. 
> 
> Hmm a co wpiszesz na pierwszym miejscu w nowej linijce w /etc/inetd.conf? :)

Przykład z "bałaganiarskiego" Solarisa :)

100230/1       tli     rpc/tcp         wait    root /usr/opt/SUNWmd/sbin/rpc.metamhd        rpc.metamhd

Ale powyższe jest możliwe tylko dla serwisów RPC czyli też nie tak do
końca ale po części można się obejśc bez services.

W linuxowych manach nie ma inetd.conf(4) ale na Solku jest:
Fragment:

DESCRIPTION
     The inetd.conf  file  contains  the  list  of  servers  that
     inetd(1M)  invokes when it receives an Internet request over
     a socket.  Each server entry is composed of a single line of
     the form:

     service-name endpoint-type protocol wait-status uid server-program server-arguments

     Fields are separated by either SPACE or TAB characters.  A
     `#' (number sign) indicates the beginning of a comment;
     characters up to the end of the line are not interpreted by
     routines that search this file.

     service-name        The name of a valid service listed in
                         the services file.  For RPC services,
                         the value of the service-name field con-
                         sists of the RPC service name or program
                         number, followed by a '/' (slash) and
                         either a version number or a range of
                         version numbers (for example, rstatd/2-
                         4).

     endpoint-type       Can be one of:
                              stream      for a stream socket,
                              dgram       for a datagram socket,
                              raw         for a raw socket,
                              seqpacket   for a sequenced packet
                                          socket
                              tli         for all tli endpoints


     protocol            Must be a recognized protocol listed in
                         the file /etc/inet/protocols.  For RPC
                         services, the field consists of the
                         string rpc followed by a '/' (slash) and
                         either a '*' (asterisk), one or more
                         nettypes, one or more netids, or a com-
                         bination of nettypes and netids.  What-
                         ever the value, it is first treated as a
                         nettype.  If it is not a valid nettype,
                         then it is treated as a netid.  For
                         example, rpc/* for an RPC service using
                         all the transports supported by the sys-
                         tem (the list can be found in the
                         /etc/netconfig file), equivalent to say-
                         ing rpc/visible rpc/ticots for an RPC
                         service using the Connection-Oriented
                         Transport Service.

     wait-status         nowait for all but "single-threaded"
                         datagram servers - servers which do not
                         release the socket until a timeout
                         occurs.  These must have the status
                         wait.  Do not configure udp services as
                         nowait.  This will cause a race condi-
                         tion where the inetd program selects on
                         the socket and the server program reads
                         from the socket.  Many server programs
                         will be forked and performance will be
                         severly compromised.

     uid                 The user ID under which the server
                         should run.  This allows servers to run
                         with access privileges other than those
                         for root.

     server-program      Either the pathname of a server program
                         to be invoked by inetd to perform the
                         requested service, or the value internal
                         if inetd itself provides the service.

     server-arguments    If a server must be invoked with command
                         line arguments, the entire command line
                         (including argument 0) must appear in
                         this field (which consists of all
                         remaining words in the entry).  If the
                         server expects inetd to pass it the
                         address of its peer (for compatibility
                         with 4.2BSD executable daemons), then
                         the first argument to the command should
                         be specified as `%A'.  No more than five
                         arguments are allowed in this field.

Czy ktoś zna jeszcze jakieś inne rzeczy które powinny być wpisane do
services ? Szczególnie poniżej portu 1024.
Chodzi o to, żeby jednak tego pliku nie zaznaczać jako %config nie dając
okazji do zminiania jefo zawartości o "dzikie serwisy".

Po za tym to co zrobił Qrczak przy okazji *cron możnaby zaadaptować prosto
do tego żeby zrobić katalog /etc/inet.d

Inna sprawa jaka mi się jeszcze nasunełą na czoło przy okazji obmyślania
konsekwencji zmian w *cron to jest wypracowanie zawartości %post{un} w
pakietach, które operują na zawartości /etc/cron.d żeby po zainstalowaniu
lub wyinstalowaniu pliku z /etc/cron.d sygnalizować ponowne przeczytanie
configuracji przez *crond. Taki opis powinien znależć sie w dokumentacji
do PLD.

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl