/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