xinetd es un reemplazo seguro de inetd y un reemplazo más eficiente de inetd y tcp_wrappers. Tiene una serie de características que lo convierten en una buena opción para proteger un servidor. Estos incluyen control de acceso (basado en la dirección de origen, la dirección de destino y la hora), un registro extenso y la capacidad de vincular servicios a interfaces específicas. Este tutorial intentará brindarle al administrador las herramientas necesarias para instalar, configurar y mantener xinetd.
Lea también:
Al ser un "reemplazo seguro de inetd", xinetd intenta hacer todo lo que hace inetd, sólo que de forma segura. Esto significa que, al igual que inetd, es un superservidor. Tanto xinetd como inetd leen en sus archivos de configuración que son básicamente una lista de servicios IP para escuchar. Los superservidores "escuchan" los puertos definidos por los que figuran en los archivos de configuración para detectar intentos de conexión en esos puertos. Cuando recibe una conexión en un puerto para el que cree que tiene un servicio, intenta iniciar el servidor requerido. Hay excepciones a este esquema, principalmente para servidores de un solo subproceso, donde los superservidores simplemente inician el servidor, que luego se ocupa de las solicitudes de servicio hasta que el servidor muere.
Donde inetd y xinetd comienzan a diferir es en el soporte de xinetd para servicios RPC; no es genial. El autor de xinetd sugiere que un administrador que ejecute un servicio rpc lo haga desde inetd. xinetd e inetd pueden convivir bastante pacíficamente. Otra cosa que difiere son los archivos de configuración; los dos son mutuamente incompatibles. El archivo conf de xinetd contiene más información que inetd para poder manejar los parámetros de seguridad adicionales.
Instalación
Primero necesita descargar la fuente más reciente de xinetd.org a algún directorio conveniente (es decir, /usr/local/src). Una vez descargado, expanda el archivo y cambie a su directorio. (Si ejecuta Mac OS X(S), hay una sección más adelante en este tutorial que tiene información adicional para ayudarlo en este proceso).
Es posible compilar xinetd con soporte libwrap agregando el indicador --with-libwrap a ./configure. Esto permite que xinetd use los hosts.{allow | negar} mecanismo. Para hacerlo, necesitará tener tcp_wrappers instalado y las bibliotecas necesarias en su lugar. La decisión de hacerlo depende del administrador individual. Esta opción existe principalmente para ayudar a aquellos que se sienten más cómodos con el mecanismo contenedor a configurar xinetd más fácilmente. Le sugerimos que no compile el software con soporte libwrap a menos que sea necesario; lo mejor y más flexible es prescindir de él.
Hay más opciones disponibles (como rutas de instalación, compatibilidad con ipv6, etc.) y debe leer los documentos de instalación para determinar cuál de estas configuraciones es la correcta para usted.
Una vez que haya ejecutado ./configure con las opciones que necesita, ejecute "make" seguido de "make install" como root. Suponiendo que xinetd lo fabrique e instale sin errores, lo siguiente que debe hacer es configurarlo. Si no es así, es posible que desees suscribirte a la lista de correo de xinetd enviando un mensaje a majordomo@synack.net con el cuerpo "subscribe xinetd".
Conceptos básicos de archivo de configuración
xinetd viene con un script perl (instalado en el mismo directorio que el binario xinetd) que convierte convenientemente un inetd.conf en un xinetd.conf. Se puede invocar como "/usr/sbin/xconv.pl /tmp/xinetd.conf", donde "/usr/sbin" es su ruta al ejecutable de xinetd.
xconv.pl intentará crear un xinetd.conf a partir de su inetd.conf original lo mejor que pueda, pero la mayoría de los administradores querrán (léase: necesitarán) modificar el xinetd.conf que genera. Por ejemplo, muchos BSD (incluido Mac OS X [Server]) requieren que cada servicio tenga una configuración "grupos = sí".
La sección de valores predeterminados
xconv.pl de forma predeterminada crea una sección de valores predeterminados que se parece a esto:
valores predeterminados
{
#El número máximo de solicitudes que un servicio en particular puede manejar
# de una vez.
instancias = 25
# El tipo de registro. Esto se registra en un archivo que se especifica.
# Otra opción es: SYSLOG syslog_facility [syslog_level]
log_type = ARCHIVO /var/log/serviciolog
# Qué registrar cuando la conexión se realiza correctamente.
# PID registra el pid del servidor que procesa la solicitud.
# HOST registra la dirección IP del host remoto.
# USERID registra el usuario remoto (usando RFC 1413)
# EXIT registra el estado de salida del servidor.
# DURATION registra la duración de la sesión.
log_on_success = HOST PID
# Qué registrar cuando falla la conexión. Mismas opciones que arriba
log_on_failure = REGISTRO DE HOST
# El número máximo de conexiones que una dirección IP específica puede
Tener que a un servicio específico.
per_source = 5
}
Aquí podemos empezar a ver algunas de las características básicas de un archivo conf. Las secciones tienen la forma general:
tipoosecciónonombre
{
...
...
...
}
Las líneas que comienzan con "#" son comentarios. Se ignoran las líneas de espacios en blanco. Sólo puede haber una sección de valores predeterminados en un archivo xinetd.conf. En la sección de valores predeterminados, asignar_op es solo un "=".
La sección de valores predeterminados, como su nombre lo indica, especifica la configuración predeterminada para los servicios especificados en otras partes del archivo. La sección de valores predeterminados puede contener varios atributos: log_type, log_on_success, log_on_failure, only_from, no_access, passenv, instancias, deshabilitado y habilitado. De estos, sólo log_type y las instancias no muestran un "efecto acumulativo". El efecto acumulativo es la capacidad de especificar un atributo varias veces dentro de la sección.
El primer atributo que vemos aquí son instancias (instancias = 25). Especifica el número máximo de solicitudes que cualquier servicio puede manejar a la vez. Esta configuración dice que para cualquier servicio que no especifique su propio atributo de instancias, ese servicio estará limitado a 25 conexiones. El siguiente atributo es log_type (FILE /var/log/servicelog), que especifica el tipo de registro (ya sea FILE o SYSLOG) y dónde iniciar sesión específicamente. Para el tipo de registro FILE, esto significa la ruta completa al archivo de registro, y para el registro SYSLOG, escriba la instalación syslog y, opcionalmente, el nivel de syslog.
Los dos atributos siguientes, log_on_success y log_on_failure, tratan de lo que se debe registrar cuando se inicia y se cierra un servidor. El atributo log_on_success acepta cinco valores diferentes: PID (registro del pid que xinetd usa para generar el servidor), HOST (registra la dirección IP del host remoto), USERID (registra el ID de usuario del usuario remoto tal como lo devuelve el servicio identd remoto), EXIT (registra el estado de salida del servidor cuando sale) y DURACIÓN (registra la duración de la sesión del servidor). Aquí, solo se registran de forma predeterminada la dirección del host y el pid del servidor (log_on_success = HOST PID). El atributo log_on_failure entra en juego cuando el servidor no se pudo iniciar debido a la falta de recursos o cuando se denegó el acceso a través de las reglas del archivo conf. Tiene cuatro valores válidos: HOST (nuevamente, la dirección IP del host remoto), USERID (igual que log_on_success), ATTEMPT (reconocimiento simple de que se realizó un intento fallido) y RECORD (obtiene tanta información como sea posible sobre el extremo remoto). ). En este xinetd.conf predeterminado, se registra la dirección de la máquina remota así como cualquier otra información que pueda obtener (log_on_failure = HOST RECORD).
El último atributo que se muestra en la configuración predeterminada es el atributo per_source. Esto especifica el número máximo de conexiones para cualquier dirección remota a un servicio. Puede ser un número entero o el valor especial "ILIMITADO", que es, por ejemplo, un número ilimitado de conexiones. Aquí el valor predeterminado es un máximo de 5 conexiones por servidor por dirección IP (per_source = 5).
Como puede ver, hay una serie de atributos que no se tienen en cuenta en la configuración predeterminada. Discutiré brevemente los atributos que faltan aquí, ya que la mayoría también se aplica a las secciones de servicios individuales que veremos más adelante. Para permitir y denegar explícitamente direcciones y redes, xinetd proporciona dos atributos llamados only_from y no_access. Hay varias formas de especificar una dirección IP o un rango de direcciones, incluidos quads decimales con puntos, notación CIDR y quads factorizados.
Los atributos deshabilitados y habilitados están destinados a ser listas de nombres de servicios (consulte la siguiente sección) que están habilitados y deshabilitados. Si se especifica habilitado, se consideran todos los servicios que no figuran como valores. Lo mismo ocurre con el atributo deshabilitado, considerándose habilitados los servicios no listados. Si un servicio aparece como valor tanto para habilitado como para deshabilitado, el atributo deshabilitado prevalece. Estos dos atributos sólo están disponibles en la sección de valores predeterminados.
El atributo restante disponible en la sección de valores predeterminados es passenv. Los valores para passenv son elementos en una lista de variables de entorno del entorno de xinetd para enviar al servidor cuando se crea una instancia.
Una vez completada esta breve introducción a la sección de valores predeterminados, pasaremos a las secciones de servicio. Pero no temas, volveremos a la sección de valores predeterminados y sus atributos más adelante con las configuraciones de muestra.
Secciones de servicios
La sección de servicios define los servicios individuales que xinetd iniciará y cómo deben iniciarse. Su forma general es
servicio{ ... ... ... }
Al igual que la sección predeterminada, las secciones de servicios tienen una serie de atributos que se pueden especificar: tipo, banderas, tipo_socket, protocolo, espera, usuario, grupo, instancias, nice, servidor, server_args, only_from, no_access, access_times, log_type, log_on_success, log_on_failure, rpc_version, rpc_number, env, passenv, puerto, redirección, enlace, interfaz, banner, banner_success, banner_fail, per_source, cps, max_load y grupos. Puede parecer mucho, pero tenga en cuenta que necesitará alrededor de 7 para configurar un servicio básico.
xconv.pl crea secciones de servicios que se ven así:
servicio ftp
{
flags = REUSE NAMEINARGS
socket_type = flujo
protocolo = tcp
esperar = no
usuario = root
servidor = /usr/libexec/ftpd
server_args = ftpd -l
}
servicio telnet
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
servidor = /usr/libexec/telnetd
server_args = telnetd
}
xconv.pl solo traducirá aquellos servicios en inetd.conf que no estén comentados, y aquellos que traduce están configurados en su modo más básico y compatible.
Lo primero que probablemente notará aquí es que las secciones de servicios están divididas en configuraciones de servicios individuales. El nombre del servicio es un nombre único para un servicio que desea configurar en la siguiente sección. Este nombre de servicio es lo que se utiliza para buscar la información del servicio en /etc/services (o equivalente).
El atributo flags generalmente se puede dejar como está. El valor REUTILIZAR es generalmente bueno y debe dejarse a menos que tenga una razón específica para eliminarlo. NAMEINARGS especifica que el primer valor del atributo server_args se utilizará como primer argumento al iniciar el servicio especificado. Esto es más útil cuando se utiliza tcpd; especificaría tcpd en el atributo del servidor y le daría el servicio ("ftpd -l") en el atributo server_args. El atributo de banderas es opcional. Las configuraciones predeterminadas deberían funcionar bien en la mayoría de los casos.
Los atributos socket_type, protocolo, espera y usuario son todos sinónimos de sus contrapartes inetd. En todos los casos que he visto, estos se pueden dejar en paz. De estos, el protocolo es opcional.
Ya hemos hablado un poco sobre server y server_args. El atributo del servidor es simplemente la ruta completa al ejecutable del servidor, y en gran medida es un campo obligatorio. Server_args es una lista de argumentos que se pasarán al ejecutable anterior. Aunque la aplicación xconv.pl lista el nombre ejecutable del servidor en este atributo, no es necesario ni particularmente deseable (como lo indican las páginas de manual de xinetd). Sin embargo, no parece haber ningún problema específico al dejar el atributo tal como lo establece xconv.pl. Si desea eliminar el nombre de los atributos, recuerde eliminar también la bandera NAMEINARGS del atributo flags. El atributo server_args debe incluirse en una definición de servicio, incluso si se deja en blanco.
Una versión mínimamente configurada del servicio ftp de ejemplo tendría el siguiente aspecto:
servicio ftp
{
socket_type = flujo
esperar = no
usuario = root
servidor = /usr/libexec/ftpd
server_args = -l
}
Si utiliza servicios rpc, los atributos protocolo, rpc_version y rpc_number (si no figuran en /etc/rpc o su equivalente) también son obligatorios.
En su mayor parte, estos son los atributos necesarios para configurar correctamente un servicio en xinetd. Sin embargo, hay dos excepciones: si estás ejecutando un BSD o si el servicio que estás configurando no aparece en /etc/services (o equivalente). La mayoría de BSD parecen requerir la adición del atributo grupos (grupos = sí) a la configuración del servicio. Si está configurando un servicio que no está en /etc/services., debe agregar el atributo de puerto a la configuración del servicio (es decir, puerto = 22, para sshd). Hay algunas variaciones adicionales cuando se trata de los servicios internos de xinetd, pero las discutiremos más adelante.
Por supuesto, este no es el final de la historia; No sólo queremos tener servicios que funcionen, sino que queremos controlar el acceso a estos servicios. Para este fin, xinetd nos proporciona una serie de atributos de servicio pertinentes: instancias, nice, only_from, no_access, access_times, per_source, cps y max_load.
Instancias acepta un número entero como valor y, como se indicó en la sección de valores predeterminados anterior, especifica el número máximo de conexiones simultáneas al servicio en particular. Al igual que con cualquiera de estos valores, establecer este atributo en la definición del servicio debería anular lo que esté en la sección de valores predeterminados. Nice está relacionado con el comando nice de Unix. Toma un número entero que especifica la prioridad del proceso de servicios. El atributo max_load acepta un valor de punto flotante y especifica la carga a la que el servidor dejará de aceptar conexiones, basándose en un promedio de carga de CPU de un minuto. Debido a su dependencia del sistema operativo, esto sólo funciona en Linux y Solaris en este momento. Luego está el atributo cps, que también toma un número entero y se utiliza para limitar la velocidad (en conexiones por segundo) de un servicio. El último de estos limitadores cuantitativos es el atributo per_source. Toma un número entero y establece el límite en la cantidad máxima de conexiones que un solo host puede tener con el servicio especificado.
Los atributos only_from y no_access también están muy relacionados entre sí, en la medida en que toman los mismos valores y tienen una función complementaria. Aceptan una lista de direcciones IP, nombres de redes (a través de /etc/networks o equivalente), nombres de host/dominio (mediante búsqueda inversa) o redes (en notación CIDR). Si se especifican only_from y no_access para un servicio, se utiliza la mejor coincidencia (es decir, un host coincide mejor que una red, es mejor que una red con una subred más grande). El atributo no_access tiene prioridad sobre only_from en caso de una duplicación completa. Si incluye cualquiera de los atributos, pero los deja en blanco, no permitirán todas las direcciones. El último atributo de control de acceso es access_times. Esto acepta intervalos de tiempo en notación de 24 horas HH:MM-HH:MM. El acceso se concede durante estos intervalos.
Los atributos restantes tienen que ver con el registro (y ya se han analizado en la sección de valores predeterminados) y algunos matices de la configuración del servicio. Algunos se tratan en una sección posterior, pero para obtener más información sobre estos atributos, recomendaría leer las páginas de manual.
Una Configuración Sencilla y con poco control de acceso
# Esta es una versión modificada y limpia de xinetd.conf
# originalmente creado por xconv.pl.
# The valores predeterminados section sets some information for all services
defaults
{
#El número máximo de solicitudes que un servicio en particular puede manejar
# de una vez.
instancias = 25
# El tipo de registro. Esto se registra en un archivo que se especifica.
# Otra opción es: SYSLOG syslog_facility [syslog_level]
log_type = ARCHIVO /var/log/serviciolog
# Qué registrar cuando la conexión se realiza correctamente.
# PID registra el pid del servidor que procesa la solicitud.
# HOST registra la dirección IP del host remoto.
# USERID registra el usuario remoto (usando RFC 1413)
# EXIT registra el estado de salida del servidor.
# DURATION registra la duración de la sesión.
log_on_success = HOST PID
# Qué registrar cuando falla la conexión. Mismas opciones que arriba
log_on_failure = REGISTRO DE HOST
# El número máximo de conexiones que una dirección IP específica puede
Tener que a un servicio específico.
per_source = 25
}
servicio ftp
{
socket_type = flujo
esperar = no
usuario = root
servidor = /usr/libexec/ftpd
server_args = -l
}
servicio nntp
{
socket_type = stream
wait = no
usuario = usenet
servidor = /usr/libexec/nntpd
server_args =
}
servicio telnet
{
socket_type = stream
wait = no
user = root
servidor = /usr/libexec/telnetd
server_args =
}
Una configuración más complicada con control de acceso
# Esta es una versión modificada y limpia de xinetd.conf
# originalmente creado por xconv.pl.
# The valores predeterminados section sets some information for all services
defaults
{
#El número máximo de solicitudes que un servicio en particular puede manejar
# de una vez.
instancias = 25
# El tipo de registro. Esto se registra en un archivo que se especifica.
# Otra opción es: SYSLOG syslog_facility [syslog_level]
log_type = ARCHIVO /var/log/serviciolog
# Qué registrar cuando la conexión se realiza correctamente.
# PID registra el pid del servidor que procesa la solicitud.
# HOST registra la dirección IP del host remoto.
# USERID registra el usuario remoto (usando RFC 1413)
# EXIT registra el estado de salida del servidor.
# DURATION registra la duración de la sesión.
log_on_success = HOST PID
# Qué registrar cuando falla la conexión. Mismas opciones que arriba
log_on_failure = REGISTRO DE HOST
# El número máximo de conexiones que una dirección IP específica puede
Tener que a un servicio específico.
per_source = 25
# Deshabilitado nntp
desactivado = nntp
#Hagas lo que hagas, no dejes entrar a los malvados bastardos
no_access = .evilbastards.com
}
servicio ftp
{
socket_type = flujo
esperar = no
usuario = root
servidor = /usr/libexec/ftpd
server_args = -l
#Permitir el acceso desde la red local (es decir, 192.168.0.0/24)
only_from = 192.168.0.0/24
#Y desde dos ubicaciones remotas
only_from = 10.1.1.2 roadwarrior.sampleconfig.com
#Pero no de la subred del malvado director de recursos humanos.
no_access = 192.168.0.128/27
log_on_success = PID HOST EXIT DURATION
log_on_failure = INTENTO REGISTRO ANFITRIÓN
}
servicio nntp
{
socket_type = stream
wait = no
usuario = usenet
servidor = /usr/libexec/nntpd
server_args =
#Allow access from the local network (ie, 192.168.0.0/24)
only_from = 192.168.0.0/24
#Y solo durante horas laborales
access_times = 08:00-17:00
#Y solo 5 personas a la vez
instancias = 5
#Y solo 5 conexiones por segundo
cps = 5
#Y no bajo carga
max_load = 2.9
#Y ser de baja prioridad
agradable = 15
}
servicio ssh
{
socket_type = stream
wait = no
user = root
servidor = /usr/libexec/sshd
#No está listado en mi /etc/services
puerto = 22
server_args = -i
#Allow access from the local network (ie, 192.168.0.0/24)
only_from = 192.168.0.0/24
#And from two remote locations
only_from = 10.1.1.2 roadwarrior.sampleconfig.com
log_on_failure = ATTEMPT HOST RECORD
}
Uso diario de xinetd (o actualización de xinetd.conf)
En la vida de todo servicio llega un día en el que éste debe ser reconfigurado por algún motivo. A veces es porque has instalado otro servicio, o deseas habilitar uno que ha sido previamente deshabilitado, o puede que tengas un bastardo malvado tratando de destrozar tu servidor imap. Cualquiera sea la razón, generalmente es desventajoso tener que cerrar todos los procesos que xinetd ha iniciado para generar una nueva configuración, especialmente en un servidor ocupado. Afortunadamente, los codificadores de xinetd nos dieron una solución a este problema. Para que aparezca una nueva configuración, realice sus modificaciones en xinetd.conf (después de hacer una copia de seguridad del mismo, por supuesto). Luego busque el PID para xinetd (ps -aux | grep xinetd). Con el PID xinetd en la mano, use el comando kill para enviarle una señal SIGUSR1 o SIGUSR2 (kill -USR1
Sorprendentemente, las personas que codificaron xinetd han agregado la capacidad de redirigir puertos. Es decir, puede aceptar una conexión en un puerto y redirigir esa conexión a otro puerto, incluso en otro host. Esto es especialmente útil en una situación donde la máquina que ejecuta xinetd es un firewall o enrutador. Por lo general, esto significa que la máquina tiene varias NIC, cada una con su propia dirección IP y subred. Al utilizar la redirección de puertos, una máquina podría aceptar una sesión de telnet en el puerto 23 de la máquina enrutador/firewall y redirigirla al puerto 23 de uno de los hosts internos. La definición de servicio para hacer esto sería similar a la siguiente:
servicio telnet
{
flags = REUSE
socket_type = flujo
protocolo = tcp
esperar = no
usuario = root
grupos = sí
bind = 10.1.1.1
redirección = 192.168.0.3 23
}
Hay una serie de cosas a tener en cuenta aquí. Hay dos atributos nuevos: vincular y redirigir. El atributo de redirección acepta una dirección IP (como está aquí) o un nombre de host, seguido de un número de puerto. No es necesario que el número de puerto especificado sea el mismo que el del servicio (en otras palabras, podría aceptar fácilmente conexiones a través de telnet y redirigirlas al puerto 80, que es http, en algún host). También se puede redirigir a un puerto en la misma máquina desde donde se redirige. El otro atributo nuevo es vincular. Esto le dice a xinetd que este servicio/regla está vinculado a la interfaz con la ip especificada. En el escenario anterior, es probable que haya dos o más NIC en la máquina, una de las cuales tiene una IP configurada de 10.1.1.1 y la otra con una dirección en la misma red (o tiene algún acceso) que la anfitrión 192.168.0.3. El atributo de vinculación no es de ninguna manera obligatorio; solo se muestra aquí porque se trata de una configuración y uso común para el atributo de redirección.
Información adicional para Mac OS X (Servidor)
Lo que sigue son instrucciones específicas para usuarios de Mac OS X (Servidor y Cliente). Como el sistema operativo es nuevo y actualmente está en un estado de cambio, considere estas instrucciones como una guía útil que puede tener errores sutiles por ahora. A medida que el sistema operativo avance hacia su lanzamiento y nos familiaricemos más con él, actualizaremos esta sección en consecuencia. Si tiene sugerencias o encuentra errores, no dude en compartirlas.
Existen diferencias en la instalación de xinetd en Mac OS X Server 1.xy Mac OS X. Cuando estas diferencias sean evidentes, así se indicará. Otras instalaciones de Unix serán similares a MOSX(S), excepto los métodos de inicio, y su kilometraje variará.
Todo lo que sigue hay que hacerlo como root para funcionar como se indica.
Es posible que sea necesario cambiar algunos nombres de archivos y rutas para proteger a los inocentes.
La compilación e instalación
Descargue la fuente en un directorio conveniente (es decir, /usr/local/src/).
Descomprima el archivo y copie los archivos de configuración necesarios de /usr/libexec:
tar xzvf xinetd-N.N.N.N.tar.gz cd xinetd-N.N.N.N/ cp /usr/libexec/config.* ./
Luego descargue el parche necesario de Macsecurity y colóquelo en el directorio xinetd-N.N.N.N .
A continuación, haga lo siguiente:
cd /ruta/a/xinetd-N.N.N.N tar zxvf xinetd-N.N.N.N-osx.patch.tar.gz parche -p 1 -l <xinetd-N.N.N.N-osx.patch
Lo siguiente que debe hacer es ejecutar ./configure con las opciones que desee (soporte libwrap, diferentes rutas de comando). Si compila con soporte libwrap, consulte la sección del tutorial llamada "Compilación con soporte libwrap". Típico para MOSX(S):
./configure --sbindir=/usr/sbin --mandir=/usr/share/man
Esperemos que esto continúe sin errores. Suponiendo que esto sea así, deberá realizar dos modificaciones menores en dos Makefiles. Querrás hacer estas modificaciones con vi, ya que pico tiende a cortar líneas largas de una manera que rompe los Makefiles.
En /path/to/xinetd-N.N.N.N/Makefile busque una línea que comience con "CFLAGS =" e inserte "-traditional-cpp" en la lista de argumentos. Luego, busque una sección que comience con makelibs: agregue una línea después de la que contenga ; hecho. Escribe $(RANLIB) libs/lib/*.a
Esta sección ahora debería verse de la siguiente manera:
makelibs: for lib in $(MANDATORY_LIBS) ; do \ ( cd libs/src/$$lib ; realizar instalación "INSTALL=$(INSTALL_CMD)" "DEFS=$(LIB_DEFS)" RANLIB=true "CC=$(CC)" DEBUG=-O ) \ ; hecho $(RANLIB) libs/lib/*.a
En /path/to/xinetd-N.N.N.N/xinetd/Makefile nuevamente busque la línea "CFLAGS =" y agregue "-traditional-cpp" a la lista de argumentos.
Continúe con lo siguiente en /path/to/xinetd-N.N.N.N/:
hacer instalar
xinetd ya está instalado. Ya sólo queda configurarlo, y de eso ya se ha hablado extensamente en este documento. Una vez que crea que tiene un buen archivo xinetd.conf creado y en su lugar, se sugiere que ejecute xinetd desde la línea de comando con el indicador de depuración '-d'. Esto te ayudará enormemente a solucionar cualquier problema que pueda surgir. Además, recuerde agregar el atributo "grupos = sí" a cada definición de servicio.
Iniciando el demonio al inicio
La mayoría de los administradores querrán iniciar xinetd desde el inicio. Una vez más, existe una diferencia entre Mac OS X Server y Mac OS X.
En Mac OS X Server, hay varias formas de hacerlo. Una forma es editar el archivo /etc/1700_IPServices y agregar una línea para xinetd (consulte las líneas de inetd para obtener una pista sobre cómo proceder). Es posible ejecutar inetd y xinetd al mismo tiempo, aunque es posible que ambos no ejecuten los mismos servicios (FIFO).
En Mac OS X, la forma de hacerlo es crear un StartupItem para xinetd. Para ello siga estas indicaciones:
cd /System/Library/StartupItems cp -R IPServices SecureIPServices cd SecureIPServices mv IPServices SecureIPServices
Edite el archivo SecureIPServices. Elimine todo después de 'ConsoleMessage "Iniciando servicios TCP/IP"'. Modifique el texto restante para que aparezca como sigue, teniendo cuidado de que las rutas indicadas sean las rutas reales a los archivos especificados.
## # Ejecutar el super-servidor de Internet. ## . /etc/rc.common ConsoleMessage "Iniciando servicios TCP/IP seguros" /usr/local/sbin/xinetd
Edite StartupParameters.plist para que tenga un aspecto similar al siguiente:
{
Descripción = "Servicios seguros de Internet";
Proporciona = ("SecureSuperServer"
);
Requiere = ("Resolver");
Usos = ("NetworkTime");
OrderPreference = "Ninguno";
Mensajes =
{
start = "Iniciando servicios de Internet seguros";
stop = "Deteniendo servicios de Internet seguros";
};
}
Eso es todo. Xinetd ahora se iniciará en el momento del arranque.
Compilando con soporte de libwrap
Si está compilando con soporte libwrap (./configure --with-libwrap), deberá asegurarse de que las bibliotecas necesarias estén instaladas en los lugares adecuados. Busque tcpd.h en /usr/include o /usr/local/include, y libwrap.a en /usr/lib o /usr/local/lib; si no están ahí, tendrás que llevarlos allí. La forma de hacer esto difiere entre las dos versiones de Mac OS X.
Para Mac OS X Server, siga estas instrucciones (extraidas del artículo de Joshua Marker sobre la instalación de SSH1 en el servidor Mac OS X en Stepwise):
cd /Sistema/Desarrollador/Fuente/Comandos/tcp_wrappers/ make RC_ARCHS=ppc install mkdir -p /usr/local/lib mkdir -p /usr/local/include cp /tmp/tcp_wrappers/Release/usr/local/lib/libwrap.a \ /usr/local/lib/libwrap.a ranlib /usr/local/lib/libwrap.a cp /System/Developer/Source/Commands/tcp_wrappers/tcp_wrappers/tcpd.h \ /usr/local/include/
Para Mac OS X, estas son las instrucciones (extraídas del artículo de Joshua Marker sobre la instalación de SSH1 en Mac OS X en Stepwise ):
wget ftp://ftp.stepwise.com/pub/macosx/unix/tcp_wrappers-7.6-4.tar.gz gnutar -xzf tcp_wrappers-7.6-4.tar.gz cd tcp_wrappers-4 make RC_ARCHS=ppc install mkdir -p /usr/local/lib mkdir -p /usr/local/include cp /tmp/tcp_wrappers/Release/usr/local/lib/libwrap.a \ /usr/local/lib/libwrap.a ranlib /usr/local/lib/libwrap.a 'cp tcp_wrappers/tcpd.h \' /usr/local/include/
Tenga en cuenta que si los scripts de configuración de xinetd no encuentran los archivos y ha compilado con soporte libwrap, xinetd no funcionará correctamente. Recuerde probar la funcionalidad antes de confiar en el nuevo demonio.
Si bien hemos analizado muchas de las opciones, configuraciones y características disponibles de xinetd, no todas las opciones están representadas o explicadas en su totalidad. Para obtener más información, consulte "man xinetd.conf" y "man xinetd". Si necesita más ayuda, busque a los autores de xinetd y únase a la lista de correo de xinetd.
