1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216
|
.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" This manpage is Copyright (C) 1996 Austin Donnelly <and1000@cam.ac.uk>,
.\" with additional material (c) 1995 Martin Schulze <joey@infodrom.north.de>
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date. The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein. The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.\" This manpage was made by merging two independently written manpages,
.\" one written by Martin Schulze (18 Oct 95), the other written by
.\" Austin Donnelly, (9 Jan 96).
.\"
.\" Thu Jan 11 12:14:41 1996 Austin Donnelly <and1000@cam.ac.uk>
.\" * Merged two services(5) manpages
.\"
.\" Traslated Mon Jan 26 19:20:00 1997 by Juan Piernas (piernas@dif.um.es)
.\"
.TH SERVICES 5 "11 enero 1996" "Linux" "Manual del Programador de Linux"
.SH NOMBRE
services \- Lista de servicios de red de Internet
.SH DESCRIPCIÓN
.B services
es un fichero ASCII que proporciona una correspondencia entre nombres textuales
cómodos para los servicios de internet y sus correspondientes números de
puerto y tipos de protocolo subyacentes. Todo programa de red debería mirar
este fichero para obtener el número de puerto (y protocolo) para su
servicio.
Las funciones
.BR getservent (3),
.BR getservbyname (3),
.BR getservbyport (3),
.BR setservent (3),
y
.BR endservent (3)
de la biblioteca de C, permiten consultar este fichero desde un programa.
Los números de puerto son asignados por la IANA (Internet Assigned Numbers
Authority: Autoridad para la Asignación de Números de Internet), y su
política actual es la de asignar tanto los protocolos TCP y UDP cuando se
asigna un número de puerto. Por tanto, la mayoría de las entradas tendrán
dos entradas, incluso para los servicios que son exclusivos de TCP.
Los números de puerto por debajo de 1024 (los así llamados "puertos de baja
numeración") sólo pueden ser enlazados por el superusuario (ver
.BR bind (2),
.BR tcp (7),
y
.BR udp (7).)
Esto es así para que los clientes que se conecten a los puertos de baja
numeración puedan confiar en que el servicio ejecutándose en el puerto es la
implementación estándar y no un servicio tramposo ejecutado por un usuario
de la máquina. Los números de puerto bien conocidos especificados por la
IANA se localizan normalmente es este espacio exclusivo del superusuario.
La presencia de una entrada para un servicio en el fichero
.B services
no significa, necesariamente, que el servicio se está ejecutando actualmente
en la máquina. Vea
.BR inetd.conf "(5)"
para la configuración de los servicios ofrecidos de Internet. Dese cuenta
que no todos los servicios de red son iniciados por
.BR inetd "(8), "
por lo que no aparecerán en
.BR inetd.conf "(5). "
En particular, los servidores de noticias (NNTP) y de correo (SMTP)
frecuentemente se inician desde los guiones de arranque del sistema.
La localización del fichero
.B services
viene especificada por
.B _PATH_SERVICES
en
.IR /usr/include/netdb.h "."
Normalmente, el valor asignado es
.IR /etc/services "."
Cada línea describe un servicio, y tiene el formato:
.IP
\f2service-name\ \ \ port\f3/\f2protocol\ \ \ \f1[\f2aliases ...\f1]
.TP
donde:
.TP 10
.I service-name
es el nombre amigable por el que el servicio es conocido y buscado.
Distingue entre mayúsculas y minúsculas. Normalmente, el programa cliente se
especifica tras
.IR service-name "."
.TP
.I port
es el número de puerto (en decimal) usado por este servicio.
.TP
.I protocol
es el tipo de protocolo usado. Este campo debe coincidir con una entrada del
fichero
.BR protocols "(5)".
Los valores típicos incluyen
.B tcp
y
.BR udp "."
.TP
.I aliases
es una lista separada, opcionalmente, por espacios o tabuladores de otros
nombres para este servicio (pero consulte más abajo la sección ERRORES).
Nuevamente, se distingue entre mayúsculas y minúsculas.
.PP
Se pueden usar o bien espacios o bien tabuladores para separar los campos.
Los comentarios comienzan con un '#' y terminan con un final de línea. Las
líneas en blanco se saltan.
.I service-name
deben comenzar en la primera columna del fichero, ya que no se eliminan los
espacios iniciales.
.I service-names
puede ser cualquier secuencia de caracteres imprimibles, excepto espacios y
tabuladores. Sin embargo, se debe hacer una selección conservativa de caractares
para minimizar problemas de interoperatibidad. Es decir, los caracteres a-z,
0-9 y el guión (\-) deben ser una elección sensata.
Las líneas que no coincidan con este formato no deberían estar presentes en
el fichero. (Actualmente,
.BR getservent (3),
.BR getservbyname (3)
y
.BR getservbyport (3).
las saltan silenciosamente. Sin embargo, no debería fiarse de este
comportamiento.)
Como característica de compatibilidad hacia atrás, la barra inclinada (/)
entre el número de
.I puerto (port)
y el nombre del
.I protocolo (protocol)
puede ser, de hecho, o bien una barra inclinada o bien una coma (,). El uso
de la coma en instalaciones modernas se desprecia.
Este fichero se podría distribuir a través de una red usando un servicio de
nombres de red como Yellow Pages/NIS o BIND/Hesiod.
Un ejemplo. El fichero
.B services
podría tener el siguiente aspecto:
.RS
.nf
.sp
.ta 3i
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp 21/tcp
# 22 - unassigned
telnet 23/tcp
.sp
.fi
.RE
.SH ERRORES
Hay un máximo de 35 alias, debido a la forma en que está escrito el código
de
.BR getservent "(3)".
Las líneas con una longitud superior a
.B BUFSIZ
(actualmente, 1024) caracteres serán ignoradas por
.BR getservent (3),
.BR getservbyname (3),
y
.BR getservbyport (3).
Sin embargo, esto también provocará que la siguiente línea sea analizada
incorrectamente.
.SH FICHEROS
.TP
.I /etc/services
La lista de servicios de red de Internet.
.TP
.I /usr/include/netdb.h
Definición de
.B _PATH_SERVICES
.SH "VÉASE TAMBIÉN"
.BR getservent (3),
.BR getservbyname (3),
.BR getservbyport (3),
.BR setservent (3),
.BR endservent (3),
.BR protocols (5),
.BR listen (2),
.BR inetd.conf (5),
.BR inetd (8)
RFC de Números Asignados, más recientemente RFC 1700, (AKA STD0002)
Guide to Yellow Pages Service
Guide to BIND/Hesiod Service
|