Linux Avanzado - Amazon Web Services

Linux Avanzado
Tema 12: TCP/IP, NFS, Samba, FTP, DHCP, DNS, Proxy.
Configuración de un servidor NFS
Uso de NFS en un cliente
Si el servidor está correctamente configurado y el cliente tiene los permisos adecuados, el montaje
de un sistema de archivos remoto con NFS solamente requiere el comando mount:
mount -t nfs my.nfs.server.com:/path/on/server /path/on/client
o una entrada adecuada en /etc/fstab:
my.nfs.server.com:/path/on/server /path/on/client nfs rw,soft 0 0
La opción soft le indicará al kernel que envíe un error de E/S (EIO) a los procesos de usuario en
caso de dificultades en la red. La opción predeterminada hard provocará que los procesos se
cuelguen mientras el servidor NFS permanece inaccesible.
Además, los programas auxiliares rpc.lockd, rpc.statd y rpc.quotad se pueden ejecutar en cliente
y/o servidor.
Configuración de un servidor NFS (parte uno)
Un servidor NFS requiere tres programas distintos, así como tres programas opcionales.
Cuando un cliente NFS monta un sistema de archivos NFS, se contacta con los siguientes
daemons de servidor, la mayoría de los cuales se deben ejecutar de forma independiente (en
contraposición a su inicio a través de inetd):
• portmap: a veces llamado portmapper o rpc.bind.
• rpc.mountd: a veces mounted.
• rpc.nfsd: a veces nfsd.
Además, existen tres programas auxiliares opcionales: rpc.lockd, rpc.statd y rpc.quotad que,
respectivamente, proporcionan un bloqueo global, aceleran la familia de llamadas al
sistema lstat (usada por ls -l, etc.) y dan soporte a las cuotas.
Configuración de un servidor NFS (parte dos)
Todos los servidores relacionados con NFS usan TCPwrappers (tcpd) para el control de acceso y,
por lo tanto, pueden requerir entradas en /etc/host.allow.
Por lo general, ni nfsd ni portmap requieren otra configuración además de /etc/hosts.allow.
El archivo de configuración de mountd es (indirectamente) /etc/exports. Indica qué sistemas de
archivos pueden ser montados por qué clientes. Con la implementación Linux de NFS, /etc/exports
no es directamente analizado por mountd. En cambio, el comando exportfs -a analiza /etc/exports y
escribe el resultado en /var/lib/nfs/xtab, donde mountd lo puede leer. Existen otros indicadores
para exportfs que permiten desincronizar estos dos archivos. Es decir, es posible agregar o quitar
temporariamente directorios exportados sin modificar los registros semipermanentes en
/etc/exports.
Los administradores de otros servidores similares a Unix deben tener en cuenta que la sintaxis del
archivo /etc/exports de Linux difiere considerablemente de la de SunOS o BSD.
Configuración de /etc/hosts.allow y /etc/hosts.deny
El archivo de configuración /etc/hosts.allow describe los hosts que tienen permiso para conectarse
a un sistema Linux. Esta configuración no es específica de NFS, sino que es necesario que un
sistema tenga permiso para poder conectarse y usar un servidor NFS. Por su parte, /etc/hosts.deny
es una lista de hosts que tienen prohibido conectarse.
De una manera un poco irracional, primero se buscan los hosts permitidos y luego los denegados,
y se le concede acceso a todo aquello que no esté asociado. Esto no significa que los mecanismos
de inicio de sesión de los servidores no funcionen; sin embargo, un administrador cauteloso podría
denegar todo aquello que no esté expresamente permitido (un poco de paranoia viene bien)
usando:
1
# /etc/hosts.deny ALL:ALL EXCEPT localhost:DENY
Si se configura /etc/hosts.deny de manera de denegar todo (excepto conexiones desde
LOCALHOST), solo tendrán permiso aquellas conexiones expresamente permitidas. Por ejemplo:
#/etc/hosts.allow# Allow localhost and intra-net
domain to use all servers ALL : 127.0.0.1, 192.168. # Let everyone ssh here
except 216.73.92.* and .microsoft.com sshd: ALL EXCEPT 216.73.92. .microsoft.com
: ALLOW # Let users in the *.example.net domain ftp in ftpd: .example.net
Configuración de /etc/exports
El siguiente es un archivo /etc/export de muestra:
# sample /etc/exports file / master(rw) trusty(rw,no_root_squash) /projects proj*.local.domain(rw)
/usr *.local.domain(ro) @trusted(rw) /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)
/pub (ro,insecure,all_squash)
Por lo general, a root (uid 0) en el cliente se lo considera nobody (uid 65534) en el servidor; esto se
denomina aplastamiento de raíz ya que protege los archivos de propiedad de raíz (no de grupo ni
editables) para evitar su modificación por parte de los clientes NFS. La
etiqueta no_root_squash deshabilita este comportamiento y permite el acceso completo del usuario
raíz entrusty a la partición /. Esto puede resultar para la instalación y configuración de software.
La partición /usr será de solo lectura para todos los hosts excepto para aquellos que estén en el
netgroup "confiable".
Cuando /home/joe está montado por pc001, se considera que todos los usuarios remotos
(independientemente de uid/gid) tienen uid=150 y gid=100. Esto es útil si el cliente NFS remoto es
una estación de trabajo de usuario único o incompatible con diferentes usuarios (p. ej., DOS).
Por lo general, Linux (y otros sistemas operativos similares a Unix) reserva el uso de los puertos
TCP y UDP 1-1023 (denominados puertos seguros) a los procesos que se ejecutan como raíz.
Para garantizar el inicio del usuario raíz como montaje NFS remoto, el servidor NFS generalmente
requiere que los clientes remotos usen puertos seguros al montar sistemas de archivos NFS. Sin
embargo, esta convención no es respetada por ciertos sistemas operativos (en particular,
Windows). En esos casos, la opción Insecure (inseguro) permite al cliente NFS usar cualquier
puerto TCP/UDP. Esto suele ser necesario en el caso de clientes Windows.
Utilidades de NFS
nfsstat muestra una serie temporal de estadísticas relacionadas con NFS (cliente y/o servidor)
sobre la máquina local de un modo similar a iostat y vmstat.
El comando showmount consulta mountd y muestra cuáles son los clientes que montan sistemas
de archivos. Como NFS es un protocolo sin estado y el daemon mountd no se consulta con
frecuencia, el resultado de showmount puede ser incorrecto. Desgraciadamente, no existe una
manera de forzar la corrección de showmount. Sin embargo, en caso de incorrección, el error
de showmount casi siempre consiste en mostrar montajes obsoletos**** y no en omitir montajes
activos, lo cual es relativamente inofensivo.
En este contexto, "sin estado" significa que los daemons nfsd que proporcionan los datos de
archivo no mantienen en la memoria qué archivos están abiertos ni qué clientes tienen montadas
qué particiones. Cada una de las solicitudes (readblock, writeblock, etc.) contiene toda la
información necesaria para su compleción (id. de partición proporcionado por mountd, número de
inodo, número de bloque, datos de lectura, escritura, etc.). El protocolo HTTP es similar en este
sentido. Una ventaja de la falta de estado es que si se reinicia el servidor, los clientes solamente
notarán un breve período de acceso interrumpido.
Configuración de un servidor Samba
Configuración de un servidor Samba
El servidor Samba smbd proporciona servicios de archivos y de impresión (principalmente para
clientes Windows). Si bien es posible iniciarlo desde inetd, generalmente se lo ejecuta como un
2
daemon independiente smbd -D. nmbd es el servidor de nombres de NetBios (o servidor WINS).
También se lo puede ejecutar desde inetd, pero, generalmente, se lo ejecuta como un daemon
independiente nmbd -D. Samba puede actuar como servidor en un grupo de trabajo Windows y
como controlador de dominio principal.
El archivo de configuración tanto de smbd como de nmbd es /etc/samba/smb.conf. En la página
man smb.conf se describen abundantes parámetros de configuración. El archivo lmhosts se usa
para asignar nombres de NetBios a direcciones IP. Su formato es similar (pero no idéntico) al
archivo /etc/hosts.
Existen excelentes instructivos sobre la configuración de Samba, así como varios libros sobre el
tema. Esta sección toca las ideas básicas y contiene indicadores de documentación más completa.
Configuración de un recurso compartido de archivos de directorio principal
El siguiente fragmento de código smb.conf permite a los usuarios acceder a sus directorios
principales (locales) desde clientes Samba remotos:
[homes]comment = Home Directories browseable =
no
Por lo general, el fragmento está incluido en el archivo smb.conf predeterminado.
Configuración de un recurso compartido de impresión con CUPS
De los numerosos sistemas de impresión Unix, CUPS es el menos anticuado y, probablemente, el
más popular en la actualidad. Dependiendo de la distribución, CUPS puede estar habilitado en el
smb.conf predeterminado. El siguiente es un ejemplo simple de un recurso compartido de
impresión CUPS:
[global]load printers = yes printing = cups printcap
name = cups [printers] comment = All Printers path = /var/spool/samba browseable
= no public = yes guest ok = yes writable = no printable = yes printer admin =
root [print$] comment = Printer Drivers path = /etc/samba/drivers browseable =
yes guest ok = no read only = yes write list = root
CUPS puede proporcionar archivos ppd (descripción de impresora Postscript) y controladores de
Windows para clientes que, si se configuran correctamente, permiten a los usuarios remotos
aprovechar toda la gama de características de una impresora (color vs. blanco y negro, resolución,
selección de bandeja de papel, impresión doble cara vs. una cara, etc.). Los sistemas de impresión
Unix tradicionales son, en comparación, muy complicados. Si desea obtener más información,
consulte la página man cupsaddsmb.
Autenticación
Samba (a diferencia de NFS) requiere que cada uno de los usuarios se autentique en el servidor.
Como con cualquier servicio de autenticación de red, hay que asegurarse de que las contraseñas
no pasen por la red sin cifrar. Para obtener más detalles, consulte la sección relativa al cifrado de
contraseñas en la página man smb.conf.
Existen varios mecanismos que puede usar Samba para autenticar usuarios remotos (clientes). Por
naturaleza, la mayoría de ellos son incompatibles con el hash de contraseña Unix estándar. La
excepción notable se da cuando las contraseñas se pasan en línea sin cifrar, lo cual es siempre
una mala idea.
Si se cifran contraseñas en línea, smbpasswd generalmente se usará para establecer una
contraseña Samba inicial para los usuarios. La opción "Unix password sync" permite
que smbpasswd cambie las contraseñas Unix cada vez que los usuarios cambien su contraseña
Samba.
3
Por otro lado, el módulo pam_smb configurado puede autenticar usuarios Linux usando la base de
datos Samba directamente. Y si estas opciones no fueran suficientes, se puede usar LDAP para
autenticar usuarios Samba o Linux.
Depuración de Samba
Al configurar un servidor Samba, el comando testparm (osmbtestparm) puede resultar muy útil.
Analizará el archivo smb.conf e informará problemas.
El comando nmblookup hace en Samba lo que nslookup hace en DNS; consulta el directorio
NetBios. Si desea obtener más detalles, consulte la página man nmblookup.
Configuración del cliente Samba
El comando smbclient proporciona un acceso similar a FTP a un recurso compartido de archivos
Samba. Un acceso transparente a los recursos compartidos de archivos SMB es más complicado;
para obtener más información, consulte la página man smbmount o el paquete sharit'.
Configuración de los servidores de protocolo de transferencia de archivos
Acerca de FTP
FTP es un protocolo de red tradicional de uso generalizado. Por lo general, FTP se ejecuta en dos
puertos separados, 20 y 21. El puerto 21 actúa como una secuencia de control (para transmitir
comandos e información de inicio de sesión), mientras que el puerto 20 actúa como una secuencia
de datos por donde se transmite el contenido de los archivos.
A FTP no se lo suele considerar un protocolo muy seguro debido a que, en su modo de
funcionamiento predeterminado, la información de control—contraseñas de inicio de sesión—se
transmiten sin cifrar. En realidad, las secuencias de datos también están cifradas, pero FTP
comparte esa característica con NFS y Samba (con canales de datos seguros, SSH/SCP es una
mejor opción). Sin embargo, es posible disponer en capas el puerto de control de FTP a través de
SSH de manera de proteger la información de control.
Los clientes FTP tradicionales proporcionan su propio entorno shell para transmitir comandos de
control y configurar conexiones. A veces se usan front-ends GUI para dotar a las transferencias
FTP de interfaces fáciles de usar. Sin embargo, en la actualidad, muchas herramientas no
dedicadas incorporan FTP (generalmente todos los programas, desde los administradores de
archivos hasta los editores de texto, están felices cuando trabajan con archivos proporcionados por
un servidor FTP).
FTP anónimo
Con el uso más extendido de FTP, la seguridad no suele ser un problema. Probablemente los
servidores FTP se usen con "FTP anónimo", es decir, datos que están disponibles para todo el
mundo y que, por lo tanto, no requieren tanta seguridad. Convencionalmente, se configura un
nombre de usuario de anónimo para permitir acceso, y se solicita una contraseña de identificación
(por lo general, una dirección de correo electrónico) que no se verifica. A veces se requiere un
nombre de usuario y una contraseña, pero esta combinación se proporciona sin ninguna
autenticación de usuario profunda (por ejemplo, con gente que se ofrece como voluntaria para un
proyecto determinado).
La mayoría de los exploradores Web y muchos administradores y herramientas de archivos son
compatibles con los servidores FTP de manera transparente. Estas herramientas suelen usar una
URL FTP para solicitar un archivo (o para cargar un archivo en un servidor). Por ejemplo, la
herramienta de línea de comandos wget recupera archivos de servidores FTP usando el siguiente
código:
$ wget ftp://example.net/pub/somefile $ wget
ftp://user:passwd@example.net/pub/somefile
Por lo general, los administradores de archivos montan un servidor FTP de manera que sea
esencialmente idéntico a un sistema de archivos local o a una unidad de NFS o Samba (sin
4
embargo, aquí no se usa el sistema mount y /etc/fstab; a estas seudoparticiones se las suele
nombrar con su URL).
Elección de servidores FTP
Debido a la antigüedad y la omnipresencia de FTP, existe un sorprendente número de
implementaciones disponibles e instaladas para varias distribuciones Linux. La configuración del
servidor FTP que se decida usar hace necesario consultar la documentación que acompaña al
servidor específico.
Entre los servidores FTP Linux más populares cabe incluir los siguientes:
• wu-ftpd.
• vsftpd.
• ProFTPd.
• BSD ftpd.
• TUX FTP.
Además, existen muchos servidores de uso menos generalizado. En casi todos los casos, la
configuración del servidor se aloja en un archivo como /etc/FOOftpd.conf (con un valor adecuado
de "FOO"). Personalmente, me gusta vsftpd, que es rápido y evita problemas de seguridad
conocidos ("vs" significa "muy seguro ").
Archivo de configuración FTPd de muestra
Debido a la abundancia de servidores, las sintaxis de configuración difieren. Sin embargo, algunos
conceptos extraídos de /etc/vsftpd.conf ilustran los tipos de opciones que proporcionan los otros
servidores. Con vsftpd, cada opción toma la formaoption=value; las marcas hash habituales
corresponden a las líneas de comentarios. La mayoría de los otros archivos de configuración FTPd
son similares.
• anonymous_enable: controla si se permiten los inicios de sesión anónimos.
• anon_world_readable_only: si está activado, los usuarios anónimos solo podrán descargar
archivos de legibilidad mundial.
• chroot_local_user: si está activado, se colocará a los usuarios locales en una
cárcel chroot() en su directorio principal después del inicio de sesión.
• pasv_enable: el servidor usa el estilo "FTP pasivo" en que los clientes inician los puertos
(ayuda con los firewalls en los clientes).
• ssl_enable: si está activado, vsftpd será compatible con las conexiones seguras SSL.
• tcp_wrappers: si está activado, las conexiones entrantes se alimentarán a través del
control de acceso (como /etc/hosts.allow y /etc/hosts.deny).
Iniciación de un servidor FTP
En el caso más simple, el servidor FTP se puede iniciar de la misma manera que cualquier
daemon:
% sudo vsftpd
En este punto, el servidor detectará las conexiones entrantes de acuerdo con las reglas
configuradas en el archivo de configuración correspondiente. También es posible iniciar un servidor
FTP desde un "superservidor de red" como inetd o xinetd. En los tutoriales para el examen 202 del
LPI se analizarán estos superservidores.
Si el daemon se inicia de manera individual, incluso con scripts de inicio adecuados – tanto como
para un nivel de ejecución específico como para /etc/rcS.d/–, usted tendrá un control más preciso
del comportamiento del servidor FTP.
Sistema de nombres de dominio (DNS)
Acerca de DNS
5
El sistema de nombres de dominio permite a los usuarios de aplicaciones TCP/IP referirse a los
servidores por nombre simbólico en vez de por dirección IP numérica. El software Berkeley Internet
Name Domain (BIND) provee un daemon de servidor llamado named que responde pedidos de
información sobre la dirección IP asignada a un nombre simbólico (un una búsqueda inversa u otra
información). Del lado del cliente del sistema DNS, un resolutor es un conjunto de bibliotecas que
pueden utilizar las aplicaciones para comunicarse con los servidores DNS. El paquete BIND viene
con varias utilidades para el cliente que ayudan a configurar, consultar y depurar un servidor BIND
9: dig, nslookup, host, y rndc(anteriormente ndc). En esencia, estas utilidades llaman a las mismas
bibliotecas que otras aplicaciones de clientes, pero dan información directa sobre las respuestas
proporcionadas por los servidores DNS.
Acerca de BIND
Al momento de esta redacción, la versión actual de BIND es 9.3.1. La primera versión estable de la
serie BIND 9 salió en octubre de 2000. Puede encontrar BIND 8, que aún se mantiene por los
parches de seguridad (actualmente de la versión 8.4.6), en algunas instalaciones más antiguas,
pero como norma, actualice a BIND 9 donde sea posible. Los sistemas muy antiguos podrían tener
instalado BIND 4, pero debe actualizarlos lo antes posible ya que BIND 4 ya no se soporta en las
versiones actuales.
Todas las versiones de BIND se pueden obtener del Consorcio de Sistemas de Internet (ISC;
ver Recursos para obtener un enlace). La documentación y otros recursos sobre BIND también
están en ese sitio.
Debido a que los objetivos LPI requieren específicamente conocimientos de la configuración de
BIND 8, y aquí cubrimos BIND 9, la recomendamos que revise la información de BIND 8 en el sitio
USC antes de dar el examen LPI 202.
Otros recursos
Al igual que con la mayoría de las herramientas de Linux, siempre es útil examinar las páginas del
manual para ver toda utilidad tratada. Las versiones y los conmutadores pueden cambiar entre la
utilidad o la versión del kernel o con las distintas distribuciones de Linux. Para obtener información
más detallada, el Proyecto de documentación Linux (ver Recursos para obtener un enlace) tiene
una cantidad de instructivos útiles. Se han publicado una variedad de buenos libros sobre redes
Linux, en particular TCP/IP Network Administration de O'Reilly es bastante útil (fíjese qué edición
es la más actual cuando lea esto; verRecursos para obtener un enlace).
Para obtener específicamente información sobre DNS y BIND, DNS and BIND, Fourth Edition de
O’Reilly es un buen recurso (ver Recursos para obtener un enlace); en 622 páginas cubre más
detalles de los que puede abarcar este tutorial. También hay otros libros sobre BIND de diversos
editores.
Cómo comprender las consultas del sistema de nombres de dominio
La topología de DNS
DNS es un sistema jerárquico de zonas de dominio. Cada zona brinda un conjunto limitado de
respuestas sobre mapeos de nombres de dominio, aquellos dentro de su propio subdominio. Cierto
servidor consulta un servidor más general cuando no conoce un mapeo y, de ser necesario, sigue
las sugerencias de redireccionamiento hasta que encuentra la respuesta correcta (o determina que
no se puede encontrar una respuesta, lo que produce un error). Cuando un servidor
local named encuentra la respuesta a una consulta DNS, almacena en caché esa respuesta
durante una cantidad de tiempo configurable (generalmente en el orden de horas en vez de
segundos o días). Al almacenar en caché las consultas DNS, la demanda general de red se reduce
considerablemente, sobre todo en los servidores de dominio de nivel superior (TLD). El artículo
sobre DNS que figura en Wikipedia (ver la sección Recursos para obtener un enlace) es un punto
de partida excelente para comprender la arquitectura general. Este tutorial toma prestado un
diagrama de dominio público de ese sitio (ver la Figura 1 a continuación).
Un diagrama de una consulta DNS hipotética facilita comprender el proceso de búsqueda general.
Suponga que su máquina desea contactar el nombre simbólico de dominio www.wikipedia.org.
Para encontrar la dirección IP correspondiente, su máquina consultaría primero el servidor de
6
nombres que ha configurado para la máquina de un cliente. Este servidor de nombres local puede
ejecutarse en la misma máquina que la aplicación del cliente; puede ejecutarse en un servidor DNS
en su LAN local; o puede proporcionarlo su proveedor de servicios de Internet. En casi todos los
casos, es una instancia del named del BIND. Este servidor de nombres local primero verifica su
caché, pero suponiendo que no haya información almacenada en caché disponible, realizará los
pasos que se muestran en el siguiente diagrama:
Figura 1. Ejemplo de recursividad de DNS
Comprenda que en este diagrama, el “DNS Recurser” es el servidor DNS real (named), no la
aplicación del cliente que le habla.
DNS utiliza TCP y UDP en el puerto 53 para atender solicitudes. Casi todas las consultas DNS
consisten en una solicitud UDP individual del cliente seguida de una respuesta UDP individual del
servidor.
Cómo sabe una aplicación dónde encontrar un servidor DNS
Configurar el acceso de la aplicación de cliente a su servidor (o servidores) DNS es bastante
sencillo. Toda la configuración está dentro del archivo /etc/resolve.conf, cuya tarea principal es
especificar direcciones IP para uno o más servidores DNS "locales". Puede configurar
/etc/resolve.conf manualmente con servidores DNS conocidos; sin embargo, si usa DHCP para
configurar un cliente, el proceso de enlace agregará automáticamente esta información a
/etc/resolve.conf (aún puede leerla o incluso modificarla después de que DHCP la configure, pero
se restablecerá al reiniciar la máquina). El código de biblioteca modificado por /etc/resolv.conf se
llama "solucionador DNS".
Si se configura más de un servidor DNS en un archivo /etc/resolv.conf, se consultarán servidores
DNS secundarios y terciarios si el servidor primario no da respuesta dentro del tiempo de espera
especificado. Se puede configurar un máximo de tres servidores DNS.
La entrada básica dentro de un archivo /etc/resolv.conf contiene las entradas nameserver <IPaddr>. Algunas otras entradas le permiten modificar las respuestas recibidas. Por ejemplo, las
directivas domain y search le permiten expandir los nombres sin puntos en ellos (como por ejemplo
máquinas de la LAN local). La directiva options le permite modificar tiempos de espera por servidor
DNS, activar el depurador, decidir cuándo anexar nombres de dominio completos, y modificar otros
aspectos del comportamiento del solucionador DNS. Por ejemplo, una de mis máquinas está
configurada con:
Listado 1. Modificación de opciones para configurar servidores DNS
# cat
/etc/resolv.conf search gnosis.lan nameserver 0.0.0.0 nameserver 192.168.2.1
nameserver 151.203.0.84 options timeout:3
La primera directiva la permite a esta máquina saber que las máquinas de la LAN local usan el
dominio privado gnosis.lan, así que el nombre simple bacchus se puede resolver
como bacchus.gnosis.lan. Se puede listar más de un dominio separado por espacio en la
directiva search.
A continuación, indico varios servidores DNS para probar. El primero es la máquina local misma,
que se puede llamar 0.0.0.0 o por su dirección IP oficial, pero no con una dirección de bucle
invertido. La siguiente directiva nameserver lista el router de la oficina hogareña que conecta mi
7
LAN con Internet (y provee servicios DHCP y DNS). El servidor de nombres terciario lo proporciona
mi proveedor de servicios de Internet. También configuro una opción para utilizar un tiempo de
espera de tres segundos en cada servidor de nombres en lugar de los cinco segundos
predeterminados.
Utilidades de cliente DNS
BIND 9 viene con cuatro utilidades de cliente principales. Tres de ellas: dig, nslookup y host -realizan funciones similares, más o menos en orden de detalle descendente. Las tres utilidades
son simplemente utilidades de línea de comandos para ejercitar el solucionador DNS. Básicamente
hacen lo que muchas aplicaciones de cliente hacen internamente; estas utilidades tan sólo proveen
datos de salida sobre los resultados de las búsquedas en STDOUT. La más poderosa de las tres
utilidades,dig, también tuene la mayor cantidad de opciones para limitar o configurar su salida.
Estas utilidades se usan con mayor frecuencia para buscar una dirección IP de un nombre de
dominio simbólico, pero puede realizar búsquedas inversas u otros tipos de registro que no sean
registros “A” predeterminados. Por ejemplo, el comandohost -t MX gnosis.cx le muestra servidores
de correo asociados a gnosis.cx. Algunos ejemplos podrían ser de ayuda:
Listado 2. Consulta de host en google.com
$ host google.com google.com has
address 72.14.207.99 google.com has address 64.233.187.99
Listado 3. Consulta de host MX en gnosis.cx
$ host -t MX gnosis.cx gnosis.cx
mail is handled by 10 mail.gnosis.cx.
Para la utilidad:nslookup
Listado 4. nslookup usando servidor predeterminado (máquina local)
$ nslookup
gnosis.cx Server: 0.0.0.0 Address: 0.0.0.0#53 Non-authoritative answer: Name:
gnosis.cx Address: 64.41.64.172
O una búsqueda inversa usando la utilidad dig y especificando un servidor de nombres no
predeterminado:
Listado 5. Indagar búsqueda inversa especificando un servidor de nombres no
predeterminado
$ dig @192.168.2.2 -x 64.233.187.99 ;
<<>> DiG 9.2.4 <<>>
@192.168.2.2 -x 64.233.187.99 ;; global options: printcmd ;; Got answer: ;;
->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id:
3950 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;;
QUESTION SECTION: ;99.187.233.64.in-addr.arpa. IN PTR ;; AUTHORITY SECTION:
187.233.64.in-addr.arpa. 2613 IN SOA ns1.google.com. dns-admin.google.com.
2004041601 21600 3600 1038800 86400 ;; Query time: 1 msec ;; SERVER:
192.168.2.2#53(192.168.2.2) ;; WHEN: Thu Nov 10 02:00:27 2005 ;; MSG SIZE rcvd:
104
La utilidad BIND 9 restante para recordar es rndc. La utilidad rndc controla el funcionamiento de un
servidor de nombres. Sustituye la utilidad ndc que se brindaba en versiones BIND anteriores. Si se
invoca rndc sin opciones de línea de comando o argumentos, imprime un breve resumen de
comandos soportados. Ver la manpage para rndc para obtener información completa sobre su uso.
8
Configuración BIND básica y ejecución de un name server
Configuraciones BIND
Cuando ejecuta el daemon con nombre para brindar un servidor DNS, puede elegir entre tres
modos de operación: maestro,esclavo y almacenamiento en caché únicamente. El mismo daemon
con nombre busca en sus archivos de configuración, principalmente /etc/bind/named.conf, para
determinar su modo de operación.
En modo maestro, el servidor con nombre actúa como la fuente autoritativa de toda la información
sobre su zona. La información de dominio proporcionada por el servidor se carga de un archivo de
disco local que se modifica o actualiza en forma manual. Cada zona de DNS debería tener
exactamente un servidor maestro.
En modo esclavo, el servidor con nombre trasfiere su información de zona desde el servidor
maestro para su zona. Técnicamente, un servidor multi zona puede ser maestro de una zona y
esclavo de otra, pero con mayor frecuencia una instalación Lan tiene una única jerarquía de
servidores entre los servidores maestro y esclavo o de almacenamiento en caché únicamente. Un
servidor esclavo transfiere información de zona completa desde su servidor maestro, para que las
respuestas proporcionadas por un servidor esclavo se sigan considerando autoritativas.
En el modo almacenamiento en caché únicamente, el servidor con nombre no guarda archivos de
zona. Cada consulta depende de otro servidor con nombre para obtener una respuesta inicial, pero
para minimizar el uso de ancho de banda, el servidor de almacenamiento en caché únicamente
almacena en caché consultas anteriores. Sin embargo, toda consulta nueva se debe responder
mediante una consulta enviada por la red. Los servidores de almacenamiento en caché
únicamente son más comunes en máquinas locales donde las aplicaciones de cliente a menudo
pueden realizar una búsqueda sin tráfico de red.
En la configuración de /etc/resolv.conf que ofrecí como ejemplo antes en Listado 1, 0.0.0.0 es un
servidor de almacenamiento en caché únicamente, 192.168.2.1 es un servidor esclavo, y
151.203.0.84 es un servidor maestro. No puede saber con seguridad solo basándose en el orden o
en las direcciones IP utilizadas, pero el uso de la dirección pseudo IP 0.0.0.0 de la máquina local
sugiere que está ejecutando un servidor de almacenamiento en caché únicamente.
Cómo configurar named.conf
Hay algunas funciones estándar que tienen casi todos los archivos /etc/bind/named.conf. Una
directiva
inicial optionsconfigura
alguna
información
básica.
Después,
varias
directivas zone brindan información sobre cómo manejar diversas solicitudes de zonza. Los
dominios indicados en las directivas zone como direcciones IP representan porciones iniciales de
rangos de dirección IP, pero si indican “hacia atrás”. Los nombres simbólicos también pueden
definir zonas, permitiendo otros subdominios especificados.
Los archivos named.conf (y otros archivos de configuración BIND) siguen convenciones de formato
tipo C, en gran parte. Los comentarios de bloque estilo C (/* comment */) y los comentarios de línea
estilo C++ (// comment) se permiten, al igual que los comentarios de línea estilo shell (# comment).
Las directivas son seguidas por instrucciones divididas por punto y coma entre llaves.
Para empezar, aquí hay algunas opciones comunes. Mi /etc/bind/named.conf local comienza con:
Listado 6. Mi named.conf local comienza así
ncluir
"/etc/bind/named.conf.options";
Pero también puede utilizar la directiva options directamente:
Listado 7. Configuración de opciones named.conf
options { directory
"/var/bind"; forwarders { 192.168.2.1; 192.168.3.1}; // forward only; }
9
Esta configuración permite a los archivos especificados sin ruta completa ser ubicados en un
directorio relativo; también le dice al servidor con nombre local que busque primero en 192.168.2.1
y 192.168.3.1 resultados no almacenados en caché. La directiva forward only (comentada aquí)
indica buscar sólo en esos servidores de nombres en la LAN local en lugar de consultar a los
servidores raíz en Internet.
Una directiva especial zone está presente en casi todos los archivos named.conf:
Listado 8. Zona hint para servidores raíz
zone "." { type hint; file
"/etc/bind/db.root"; };
El contenido de db.root (a veces llamado named.ca por la "autoridad certificadora") es especial.
Señala servidores raíz canónicos, los registradores de dominio mismos. Sus valores rara vez
cambian, pero puede obtener la versión oficial más reciente en ftp.rs.internic.net. Este no es un
archivo que modifica un administrador común.
Más allá de la pista zona raíz, un archivo named.conf debe contener algunas zonas maestro y/o
esclavo. Por ejemplo, para el bucle invertido local:
Listado 9. Configuración de zona de bucle invertido
zone "127.in-addr.arpa" {
type master; file "/etc/bind/db.127"; };
Curiosamente, un servidor con nombre podría actuar como maestro para un dominio (y brindar
búsqueda inversa):
Listado 10. Configuración de zona externa
zone "example.com" { type master;
file "example.com.hosts"; // file relative to /var/bind }; // Reverse lookup for
64.41.* IP addresses (backward IP address) zone "41.64.in-addr.arpa" { type
master; file "41.64.rev"; };
Para una configuración de esclavo, podría utilizar en cambio:
Listado 11. Configuración de zona externa (esclavo)
zone "example.com" { type
slave; file "example.com.hosts"; // file relative to /var/bind masters {
192.168.2.1; }; }; // Reverse lookup for 64.41.* IP addresses (backward IP
address) zone "41.64.in-addr.arpa" { type slave; file "41.64.rev"; masters {
192.168.2.1; }; };
Otros archivos de configuración
El archivo named.conf hace referencia a una cantidad de otros archivos de configuración con la
directiva file. Estos nombres dependen de su configuración específica, pero en general contienen
diversos registros de recursos que se definen en RFC 1033 (Guía de operaciones para
administradores de dominios; ver Recursos para obtener un enlace). Los registros de recursos
estándar son:
SOA
Inicio de autoridad. Parámetros que afectan a toda una zona.
NS
Servidor de nombres. El nombre del servidor de un dominio.
A
Dirección. Nombre de host a dirección IP.
10
PTR
Indicador. Dirección IP a nombre de host.
MX
Intercambio de correo. Dónde entregar correo para un dominio.
CNAME
Nombre canónico. Alias del nombre de host.
TXT
Texto. Almacena valores arbitrarios.
El formato de un registro es: <name><time-to-live>IN <type> <data>.
El nombre y el tiempo de vida son opcionales y predeterminados conforme a los últimos valore
sutilizados. La cadena literal INsignifica que siempre se utiliza Internet en la práctica. Los archivos
de registro de recursos también pueden contener directivas, que comienzan con un signo de dólar.
El más común quizás sea $TTL, que fija un tiempo de vida predeterminado. Por ejemplo, un
archivo de registro algo trivial para el localhost 127.* se ve así:
Listado 12. Archivo de registro trivial
# cat /etc/bind/db.127 ; BIND reverse
data file for local loopback interface ; $TTL 604800 @ IN SOA localhost.
root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire
604800 ) ; Negative Cache TTL ; @ IN NS localhost. 1.0.0 IN PTR
localhost.
Otras directivas son: $ORIGIN, que fija el nombre de dominio utilizado para completar todo nombre
de dominio relativo;$INCLUDE, que lee un archivo externo; y $GENERATE, que crea una serie de
registros de recursos que cubren una gama de direcciones IP.
Crear y mantener zonas DNS
Archivos de zona inversa
Los archivos de zona inversa (a menudo indicados con una extensión .rev) contienen mapeos de
direcciones IP de zonas específicas a nombres simbólicos. Por ejemplo, podría tener un archivo
/var/bind/41.64.rev que contiene:
Listado 13. Reverse zone file for 64.41.*
$TTL 86400 ; IP address to hostname @ IN SOA
example.com. mail.example.com. ( 2001061401 ; Serial 21600 ;
Refresh 1800 ;
Retry 604800 ; Expire 900 ) ; Negative cach TTL IN NS
ns1.example.com. IN NS
ns2.example.com. ; Define names for 64.41.2.1, 64.41.2.2, etc. 1.2
IN PTR
foo.example.com. 2.2 IN PTR bar.example.com. 3.2 IN PTR
baz.example.com.
Archivos de zona hacia adelante
Los archivos de zona hacia adelante (a menudo llamados domain.hosts) contienen los registros
cruciales "A" para nombres simbólicos de mapeo a direcciones IP. Por ejemplo, podría tener una
archivo /var/bind/example.com.hosts que contiene lo siguiente:
Listado 14. Reenviar archivo de zona para example.com
$TTL 86400 ; Hostname to
IP address @ IN SOA example.com. mail.example.com. ( 2001061401 ; Serial 21600 ;
Refresh 1800 ; Retry 604800 ; Expire 900 ) ; Negative cach TTL IN NS
ns1.example.com. IN NS ns2.example.com. localhost IN A 127.0.0.1 foo IN A
11
64.41.2.1 www IN CNAME foo.example.com bar IN A 64.41.2.2 bar IN A
64.41.2.3
Cómo asegurar un servidor DNS
Cómo asegurar un servidor DNS
Al igual que con muchos servicios, es buena idea ejecutar BIND en una jaula chroot. , Esto limita el
accedo de BIND a otros archivos o recursos del sistema si existiera una vulnerabilidad o un error
en BIND. Encuentre un tutorial más detallado sobre ejecutar BIND con chroot en el instructivo
"Chroot-BIND HOWTO" (ver Recursos para obtener un enlace).
La utilidad general de este procedimiento es que no es bueno ejecutar BIND co usuario raíz, o
incluso como un usuario común especial como “nadie". A menudo se crea el usuario "named" para
ejecutar BIND. Los archivos utilizados por este usuario especial se colocan en un directorio local
como /chroot/named/ y subdirectorios relativos apropiados.
BIND 9 brinda soporte mucho más limpio para chroot de lo que lo hacía BIND 8; una compilación
limpia debería ser suficiente sin conmutadores especiales o ajustes Makefile.
DNSSEC
Además de asegurar la máquina local que ejecuta BIND, también es deseable brindar garantías de
seguridad para el protocolo DNS mismo. Las Extensiones de Seguridad DNS (DNSSEC) son un
conjunto de extensiones que brindan autenticidad e integridad
DNS está basado en UPD en vez de TCP, y por ende no tiene un mecanismo para verificar una
fuente paquete. Esta limitación hace posibles ataques de suplantación e intercepción. En otras
palabras, los solicitantes de DNS pueden recibir información maliciosa, por ejemplo para redirigir
comunicación al host de un intruso. Al agregar Firmas Transaccionales (TSIG) a solicitudes DNS,
DNSSEC puede evitar la suplantación de respuestas DNS. Cada servidor BIND 9 que desea
comunicarse en forma segura debe activar DNSSEC, pero el protocolo mejorado es compatible en
forma inversa. Lo primero que deben hacer los servidores DNS (los que desean comunicarse de
manera segura) es generar key pairs. Esto funciona de manera muy similar a las claves SSH para
host y servidor. Por ejemplo:
Listado 15. Generación de claves DNSSEC
dnssec-keygen -r /dev/urandom -a
HMAC-MD5 -b 128 -n HOST \ primary-secondary.my.dom # ls
Kprimary-secondary.my.dom.* Kprimary-secondary.my.dom.+157+46713.key
Kprimary-secondary.my.dom.+157+46713.private
Como sugieren los nombres de archivo, esto general claves públicas y privadas para el host
configurado, y la clave pública se distribuye a otros servidores. Obtenga una buena introducción a
DNSSEC en "The Basics of DNSSEC" en la Red O'Reilly (verRecursos para obtener un enlace).
Recursos
•
El artículo sobre DNS que se encuentra en Wikipedia es un buen punto de partida para
comprender la arquitectura general.
•
DNS and BIND, Fourth Edition por Paul Albitz y Cricket Liu (O'Reilly, 2001) cubre
minuciosamente los temas relacionados con DNS y BIND.
•
TCP/IP Network Administration, Third Edition por Craig Hunt (O'Reilly, abril de 2002) es un
recurso excelente sobre redes Linux.
•
El instructivo Chroot-BIND HOWTO muestra cómo configurar BIND para ejecutarse en una
jaula chroot.
12
•
El instructivo Basics of DNSSEC ofrece una buena introducción a DNSSEC.
•
Vea 700 Grupos de usuarios de Linux (LUG) en todo el mundo; muchos LUGs tienen
grupos de estudio locales y a distancia para los exámenes LPI.
•
El Proyecto de Documentación Linux Tiene una variedad de documentos útiles,
especialmente sus instructivos.
•
Encuentre más tutoriales para desarrolladores Linux en la zona developerWorks Linux.
Servicios web
Acerca de Apache y Squid
Servidor Web Apache
Apache es el servidor Web dominante en Internet en su conjunto; su predominio es aún mayor
entre los servidores Linux. Existen algunos otros servidores Web de propósitos especiales (algunos
ofrecen un mejor rendimiento para tareas específicas), pero el servidor Apache es siempre la
opción predeterminada.
Apache viene preinstalado en la mayoría de las distribuciones Linux y, a menudo, ya está
funcionando después de ser lanzado durante la inicialización, aun cuando usted no haya
configurado específicamente un servidor Web. Si Apache no está instalado, utilice el sistema de
instalación normal de su distribución para instalarlo, o descargue el último servidor HTTP del
Apache HTTP Server Project (Proyecto de Servidor HTTP Apache). Los módulos aportan muchas
otras capacidades, muchas de las cuales se distribuyen con Apache en sí y otras pueden
obtenerse de terceros.
Aunque el último Apache se encuentra en el nivel 2.x desde 2001, el Apache 1.3.x sigue siendo de
uso generalizado y la serie 1.3.x sigue manteniéndose para la corrección de errores y las
actualizaciones de seguridad. Existen algunas diferencias de configuración menores entre 1.3 y
2.x; hay algunos módulos disponibles para 1.3 que no están disponibles para 2.x. Las últimas
versiones a la fecha de este tutorial son 1.3.34 (estable), 2.0.55 (estable) y 2.1.9 (beta).
Como norma, un nuevo servidor debería utilizar la última versión disponible de la serie 2.x. A
menos que usted tenga una necesidad especifica para utilizar un módulo no habitual más antiguo,
2.x proporciona buena estabilidad, más capacidades y un mejor rendimiento general (para algunas
tareas, como soporte PHP, el 1.3 sigue teniendo un mejor rendimiento). Con miras al futuro, las
nuevas funcionalidades tendrán sin duda un mejor soporte en 2.x que en 1.3.x.
Servidor proxy Squid
Squid es un servidor proxy-caché para clientes Web que soporta los protocolos HTTP, FTP, TLS,
SSL y HTTPS. Ejecutando un caché en una red local, o al menos más cerca de su red que los
recursos consultados, se puede mejorar la velocidad y reducir el ancho de banda de la red.
Cuando las máquinas atendidas por el mismo servidor Squid solicitan el mismo recurso varias
veces, el recurso es prestado desde una copia local del servidor en lugar de que el pedido salga
por múltiples routers de red que pueden potencialmente desacelerar o sobrecargar a los servidores
de destino.
Usted puede configurar a Squid como proxy explícito que debe configurarse en cada cliente Web
(navegador) o configurarlo para que intercepte todos los pedidos Web que salen de una LAN y
almacenar en caché todo ese tráfico. Puede configurar a Squid con diversas opciones respecto de
la duración y las condiciones en que habrán de mantenerse las páginas almacenadas en caché.
Otros recursos
Tal como ocurre con la mayoría de las herramientas Linux, siempre es útil examinar las páginas
man para conocer las utilidades que se analizan. Las versiones y switches podrían cambiar entre
las distintas versiones de utilidad o kernel o con diferentes distribuciones de Linux. Si desea
13
información más detallada, el Proyecto de Documentación de Linux contiene una serie de
documentos útiles, en especial los instructivos. Se han publicado una serie de libros sobre redes
Linux; en mi opinión,TCP/IP Network Administration (Administración de redes TCP/IP) de O’Reilly,,
escrito por Craig Hunt, es especialmente útil. (Vea Recursos más adelante en este tutorial si desea
los vínculos.)
También se han escrito buenos libros sobre cómo trabajar con Apache. Algunos se refieren a la
administración general mientras que otros cubren módulos determinados o configuraciones
especiales de Apache. Consulte en la librería de su preferencia la gama de títulos disponibles.
Implementación de un servidor Web
Una multitud daemons
El inicio de Apache es similar al inicio de cualquier otro daemon. Por lo general, usted prefiere
colocar su inicio en los scripts de inicialización del sistema pero, en principio, puede iniciar el
Apache en cualquier momento. En la mayoría de los sistemas, al Apache se lo llama httpd, aunque
también puede llamárselo apache2. Es probable que el servidor esté instalado en /usr/sbin/, pero
otras ubicaciones son posibles dependiendo de la distribución y de cómo haya instalado usted el
servidor.
En la mayoría de las ocasiones, usted iniciará el Apache sin opciones pero vale la pena tener en
cuenta las opciones -d serverroot y -f config. La primera opción le permite especificar una ubicación
en los discos locales desde la cual se brindará contenido; la segunda le permitirá especificar un
archivo de configuración no predeterminado. Un archivo de configuración puede anular la opción f utilizando la directiva ServerRoot (la mayoría lo hace). De forma predeterminada, los archivos de
configuración son apache2.conf o httpd.conf, dependiendo de las opciones de compilación. Estos
archivos podrían estar en /etc/apache2/, /etc/apache/, /etc/httpd/conf/, /etc/httpd/apache/conf, o en
algunas otras ubicaciones dependiendo de la versión, la distribución de Linux y la forma en que
usted instaló o compiló Apache. La verificación de man apache2 o man httpd debería darle detalles
específicos del sistema.
El daemon de Apache es poco común si se lo compara con otros servidores en el sentido de que,
por lo general, crea varias copias ejecutables de sí mismo. La copia principal sencillamente
engendra las otras, mientras que estas copias secundarias atienden los pedidos entrantes reales.
El objetivo de tener múltiples copias ejecutables es actuar como "pool" (grupo) para los pedidos
que pueden llegar en paquetes; las copias adicionales del daemon se inician cuando resulta
necesario, de acuerdo con varios parámetros de configuración. Por lo general, la copia principal se
ejecuta como raíz pero las otras copias se ejecutan como usuario más restringido por razones de
seguridad. Por ejemplo:
Listado 1. Las numerosas caras de copias ejecutables múltiples de Apache
# ps axu
| grep apache2 root 6620 Ss Nov12 0:00 /usr/sbin/apache2 -k start -DSSL www-data
6621 S Nov12 0:00 /usr/sbin/apache2 -k start -DSSL www-data 6622 Sl Nov12 0:00
/usr/sbin/apache2 -k start -DSSL www-data 6624 Sl Nov12 0:00 /usr/sbin/apache2
-k start -DSSL dqm 313 S+ 03:44 0:00 man apache2 root 637 S+ 03:59 0:00 grep
apache2
En muchos sistemas, el usuario restringido no será nadie. En el Listado 1, es www-data.
Inclusión de los archivos de configuración
Como se mencionó antes, la conducta de Apache se ve afectada por directivas de su archivo de
configuración. Para los sistemas Apache2, es muy probable que el principal archivo de
configuración resida en /etc/apache2/apache2.conf pero, a menudo, este archivo contiene múltiples
instrucciones Include (incluir) para agregar información de configuración de otros archivos,
posiblemente mediante patrones de comodines. En términos generales, es probable que una
configuración de Apache contenga cientos de directivas y opciones (la mayoría de las cuales no se
documentaron específicamente en este tutorial).
14
También es muy probable que se incluyan algunos archivos. Usted podría ver httpd.conf para las
configuraciones del "usuario", para utilizar los archivos de configuración anteriores a Apache 1.3
que utilizan ese nombre. En general, los hosts virtuales se especifican en archivos de configuración
independientes, compatibilizados en un comodín, como se muestra a continuación:
Listado 2. Especificación de hosts virtuales
# Include the virtual host
configurations (incluye las configuraciones de host virtuales): Incluye
/etc/apache2/sites-enabled/[^.#]*
Con Apache 2.x, los módulos también se especifican por lo general en archivos de configuración
independientes (a menudo en el mismo archivo en 1.3.x). Por ejemplo, un sistema propio incluye:
Listado 3. Desde /etc/apache2/apache2.conf
# Include module configuration (incluye
la configuración del módulo): Incluye /etc/apache2/mods-enabled/*.load Incluye
/etc/apache2/mods-enabled/*.conf
En realidad, para utilizar un módulo en un servidor Apache ejecutable hacen falta dos pasos en el
archivo de configuración, cargarlo y habilitarlo:
Listado 4. Carga de un módulo Apache opcional
# cat
/etc/apache2/mods-enabled/userdir.load LoadModule userdir_module
/usr/lib/apache2/modules/mod_userdir.so # cat
/etc/apache2/mods-enabled/userdir.conf <IfModule mod_userdir.c>
UserDir public_html UserDir disabled root <Directory
/home/*/public_html> AllowOverride FileInfo AuthConfig Limit Options
MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory> </IfModule>
Los comodines de las líneas Include (Incluir) insertarán todos los archivos .load y .conf en el
directorio /etc/apache2/mods-enabled/.
Observe el patrón general: las directivas básicas son comandos de una línea con algunas
opciones; las directivas más complejas anidan comandos que utilizan una etiqueta abrir/cerrar tipo
XML. Para cada directiva, usted sólo deberá saber si es una línea o estilo abrir/cerrar – no puede
elegir el estilo que desea a voluntad.
Archivos de registro
Una clase importante de directivas de configuración se refieren al registro de las operaciones de
Apache. Usted podrá mantener diferentes tipos de información y niveles de detalle para las
operaciones de Apache. Llevar un registro de errores siempre es una buena idea; podrá
especificarlo con la siguiente directiva única:
Listado 5. Especificación de un registro de errores
# Global error log.
ErrorLog /var/log/apache2/error.log
Podrá personalizar otros registros de acceso al servidor, de referenciador y de cualquier otra
información apropiada para su configuración individual. La operación de registro se configura con
dos directivas. Primero, una directiva LogFormat utiliza un conjunto de variables especiales para
especificar lo que va en el archivo de registro; segundo, una directiva CustomLog le dice a Apache
que registre realmente los eventos en el formato especificado. Usted podrá especificar un número
15
ilimitado de formatos independientemente de que se utilicen o no. Esto le permite activar y
desactivar detalles del registro de acuerdo con las necesidades que pudieran surgir.
Las variables de un LogFormat son similares a las variables shell, pero con un % inicial. Algunas
variables tienen letras únicas, mientas que otras tienen nombres largos rodeados de corchetes, tal
como se muestra en el Listado 6.
Listado 6. Variables de LogFormat
LogFormat "%h %l %u %t \"%r\" %>s %b
\"%{Referer}i\" \"%{User-Agent}i\"" combined CustomLog
/var/log/apache2/referer_log combined
Consulte un libro o la documentación completa de Apache si desea una lista de todas las variables.
Entre las más comunes se encuentran: %h para la dirección IP del cliente solicitante, %t para la
fecha y hora del pedido, %>s para el código de estado de HTTP, y la variable mal
escrita %{Referer} para el sitio referenciador que llegó a la página atendida .
El nombre utilizado en las directivas LogFormat y CustomLog es arbitrario. En el Listado 6, se
utilizó el nombre combined pero también podría ser myfoobarlog. Sin embargo, hay algunos
nombres que habitualmente se utilizan y que vienen con archivos de configuración de muestra,
como combined, common, referer y agent. Por lo general, estos formatos específicos reciben el
soporte directo de las herramientas analizadoras de registros.
Mantenimiento de un servidor Web
Hosts virtuales, multi-homing y opciones por directorio
Los directorios individuales servidos por un servidor Apache pueden tener sus propias opciones de
configuración. Sin embargo, la configuración principal puede limitar las opciones que pueden
configurarse localmente. Si desea una configuración por directorio, utilice la
directiva AccessFileName y especifique el nombre de archivo de configuración local de .htaccess.
Las limitaciones de configuración local se especifican dentro de una directiva <Directory>.Por
ejemplo:
Listado 7. Ejemplo de directiva de directorio
#Let's have some Icons, shall we? Alias
/icons/ "/usr/share/apache2/icons/" <Directory
"/usr/share/apache2/icons"> Options Indexes
AllowOverride None
Order allow,deny Allow from all </Directory>
MultiViews
A menudo, trabajando en conjunto con las opciones por directorio, Apache puede atender a
los hosts virtuales. Múltiples nombres de dominio pueden ser atendidos desde el mismo proceso
Apache, cada uno de los cuales accede a un directorio apropiado. Usted puede definir los hosts
virtuales con la directiva <VirtualHost>; coloque los archivos de configuración en un directorio
incluido, como /etc/apache2/sites-enabled/ o en un archivo de configuración principal. Por ejemplo,
usted podría especificar:
Listado 8. Configuración de hosts virtuales
<VirtualHost
"foo.example.com"> ServerAdmin webmaster@foo.example.com DocumentRoot
/var/www/foo ServerName foo.example.com <Directory /var/www/foo>
Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny
allow from all </Directory> ScriptAlias /cgi-bin/
/usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride
None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow
from all </Directory> CustomLog /var/log/apache2/foo_access.log
16
combined </VirtualHost> <VirtualHost
"bar.example.org"> DocumentRoot /var/www/bar ServerName bar.example.org
</VirtualHost> <VirtualHost *> DocumentRoot /var/www
</VirtualHost>
La opción final * toma cualquier pedido HTTP que no esté dirigido a uno de los nombres
especificados explícitamente (como los dirigidos por dirección IP o dirigidos como un dominio
simbólico no especificado que también resuelve a la máquina servidor). Para que los dominios
virtuales funcionen, DNS debe definir cada alias con un registro CNAME.
Los servidores multi-homed suenan de manera similar al hosting virtual pero el concepto es
diferente. Utilizando multi-homing, usted podrá especificar las direcciones IP a las que está
conectada una máquina para permitir los pedidos Web. Por ejemplo, usted podría brindar acceso
HTTP sólo a la LAN local y no al mundo exterior. Si usted especifica una dirección para escuchar,
también puede indicar un puerto no predeterminado. El valor predeterminado
para BindAddress es *, que significa aceptar los pedidos de cada dirección IP bajo la cual se puede
acceder al servidor. El siguiente podría ser un ejemplo mixto:
Listado 9. Configuración de multi-homing
BindAddress 192.168.2.2 Listen
192.168.2.2:8000 Listen 64.41.64.172:8080
En este caso, aceptaremos todos los pedidos del cliente provenientes de la LAN local (que utilizan
la dirección 192.168.2.2) en el puerto predeterminado 80 y en el puerto especial 8000. Esta
instalación de Apache también monitoreará los pedidos HTTP del cliente que provienen de la
dirección WAN, pero sólo en el puerto 8080.
Limitación del acceso Web
Usted puede habilitar el acceso al servidor por directorio con los comandos Order, Allowfrom,
y Deny from que están dentro de una directiva <Directory>. Es posible especificar las direcciones
denegadas o permitidas mediante nombres de host parciales o direcciones IP. Order le permite
establecer una prioridad entre la lista de aceptación y la lista de denegación.
En muchos casos, usted necesitará un control más ajustado que el que puede obtener con el
simple hecho de permitir que determinados hosts accedan a su servidor Web. Para habilitar los
requisitos de inicio de sesión del usuario, utilice la familia de comandos Auth*, que se encuentra
también dentro de la directiva <Directory>. Por ejemplo, para configurar la Autenticación Básica,
usted podría utilizar una directiva como la que aparece en el Listado 10.
Listado 10. Configuración de la Autenticación Básica
<Directory
"/var/www/baz"> AuthName "Baz" AuthType Basic AuthUserFile
/etc/apache2/http.passwords AuthGroupFile /etc/apache2/http.groups Require john
jill sally bob </Directory>
También puede especificar la Autenticación Básica dentro de un archivo .htaccess por directorio.
La Autenticación “Digest” es más segura que la Básica, pero se encuentra mucho menos
implementada en los servidores. Sin embargo, la debilidad de la Autenticación Básica (que
transmite contraseñas en texto claro) de todos modos se resuelve mejor con una capa SSL.
El soporte al cifrado SSL del tráfico Web es suministrado por el módulo mod_ssl. Cuando se utiliza
SSL, los datos transmitidos entre el servidor y el cliente se cifran con una contraseña que se
negocia de forma dinámica y que es resistente a la interceptación. Todos los navegadores
importantes soportan SSL. Si desea más información sobre cómo configurar Apache 2.x
con mod_ssl, vea la descripción en el sitio Web de Apache (diríjase a Recursos para ver el
vínculo).
17
Implementación de un servidor proxy
Instalación y ejecución de Squid
En la mayoría de las distribuciones, usted puede instalar Squid utilizando los procedimientos de
instalación normal. Obtenga la versión fuente de Squid en el sitio Web de Squid Web Proxy Cache
(diríjase a Recursos para ver el vínculo). Construyendo a partir de la fuente, utilice la secuencia
básica ./configure; make; make install.
Una vez instalado, podrá ejecutarlo de manera sencilla como raíz, /usr/sbin/squid (o desde la
ubicación que utilice su distribución, quizá /usr/local/sbin/). Por supuesto que para que resulte
mucho más útil, usted probablemente querrá configurar el archivo de configuración de Squid en
/etc/squid/squid.conf, /usr/local/squid/etc/squid.conf, o en el lugar en el que su sistema ubique con
precisión a squid.conf. Tal como ocurre con casi todos los daemons, podrá utilizar un archivo de
configuración diferente, en este caso con la opción -f.
Puertos, direcciones IP, http_access y ACL (Listas de control de acceso)
Las opciones de configuración más importantes para Squid son las opciones http_port que usted
elige. Usted puede monitorear todos los puertos que desee, adjuntando opcionalmente cada uno a
una dirección de IP o nombre de host determinados. El puerto predeterminado para Squid es 3128,
que permite que cualquier dirección de IP se conecte al servidor Squid. Para almacenar en caché
sólo para una LAN, especifique la dirección de IP local, de la siguiente manera:
Listado 11. Almacenamiento en caché de Squid sólo para una LAN
# default
(disabled) # http_port 3128 # LAN only http_port 192.168.2.2:3128
Usted también puede habilitar el almacenamiento en caché a través de otros servidores Squid
utilizando icp_port yhtcp_port. Los protocolos IPC y HTCP se utilizan para que los caché se
comuniquen entre sí en lugar de hacerlo mediante los servidores y clientes Web. Para almacenar
en caché los multicasts, utilice mcast_groups.
Para permitir que los clientes se conecten a su servidor Squid, tendrá que darles permiso para
poder hacerlo. A diferencia de un servidor Web, el servidor Squid no es absolutamente generoso
con sus recursos. En el caso simple, sólo podemos utilizar un par de patrones de subred/máscara
de red o CIDR (Classless Internet Domain Routing) para controlar los permisos:
Listado 12. Permisos de acceso simples de Squid
http_access deny
10.0.1.0/255.255.255.0 http_access allow 10.0.0.0/8 icp_access allow
10.0.0.0/8
Usted puede utilizar la directiva acl para nombrar la listas de control de acceso (ACL). Puede
nombrar las ACL tipo src que sencillamente especifican rangos de dirección como se ve en el
Listado 12, pero también puede crear otros tipos de ACL. Por ejemplo:
Listado 13. Permisos de acceso ajustados
acl mynetwork src 192.168/16 acl asp
urlpath_regex \.asp$ acl bad_ports port 70 873 acl javascript rep_mime_type -i
^application/x-javascript$ # what HTTP access to allow classes http_access deny
asp # don't cache active server pages http_access deny bad_ports # don't cache
gopher or rsync http_access deny javascript # don't cache javascript content
http_access allow mynetwork # allow LAN everything not denied
El Listado 13 muestra sólo un pequeño subconjunto de los tipos de ACL disponibles. Vea una
muestra de squid.conf si desea ejemplos de muchos otros. O consulte la documentación sobre
control de acceso (Capítulo 6) de la Guía del Usuario de Squid (diríjase a Recursos para ver el
vínculo).
18
En el Listado 13, decidimos no no almacenar en caché las direcciones URL que terminan en .asp
(el contenido es probablemente dinámico), no almacenar en caché los puertos 70 y 873 y no
almacenar en caché los objetos JavaScript devueltos. Fuera de lo que se deniega, las máquinas de
la LAN (el rango /16 dado) tendrán todos sus pedidos almacenados en caché. Observe que cada
ACL definida tiene un nombre único pero arbitrario (utilice nombres que tengan sentido; Squid no
reserva los nombres).
Modalidades de almacenamiento en caché
La manera más simple de ejecutar Squid es en el modo proxy. Si sigue este procedimiento, los
clientes deberán configurarse explícitamente para utilizar el caché. Los clientes del navegador Web
tienen pantallas de configuración que les permiten especificar un puerto y dirección proxy en lugar
de una conexión http directa. Este sistema simplifica al máximo la configuración de Squid pero
obliga a los clientes a realizar algún trabajo de configuración si desean beneficiarse con el caché
de Squid.
También podrá configurar a Squid para que sea ejecutado como un caché transparente. Para ello,
deberá configurar el ruteo basado en políticas (fuera de Squid en sí, utilizando ipchains o ipfilter) o
usar su servidor Squid como una puerta de enlace. Suponiendo que usted está en condiciones de
dirigir los pedidos externos a través del servidor Squid, el servidor deberá configurarse de la
siguiente manera. Es probable que necesite recompilar Squid con la opción --enable-ipftransparent; sin embargo, en la mayoría de las instalaciones Linux, no debería ser necesario. Para
configurar el servidor para el almacenamiento en caché transparente (una vez que tiene los
paquetes redireccionados), agregue algo similar al Listado 14 a su squid.conf:
Listado 14. Configuración de Squid para el almacenamiento en caché transparente
httpd_accel_host virtual httpd_accel_port 80
httpd_accel_with_proxy on httpd_accel_uses_host_header on
Configuración DHCP
Aspectos generales del protocolo
Como muchos protocolos de red, el Protocolo de configuraciónn dinámica de host (DHCP) es una
interfaz cliente/servidor. El cliente DHCP es un programa mucho más fácil, tanto en su estructura
interna como en su configuración, que el servidor DHCP. Esencialmente, la función de un cliente
DHCP es difundir un mensaje DHCPDISCOVER en su subred física local y luego esperar una
respuesta.
El mensaje DHCPDISCOVER PUEDE incluir opciones con sugerencias de valores para la
dirección de red y la duración de la concesión. Los servidores que reciben un mensaje
DHCPDISCOVER deberían responder a la dirección MAC solicitante con un mensaje
DHCPOFFER. El cliente, a su vez, responde con un mensaje DHCPREQUEST a uno de los
servidores oferentes, por lo general el primer (y único) servidor que responde.
Los parámetros de configuración de un cliente son recibidos en un mensaje DHCPACK. En ese
punto, el cliente ya ha recibido una dirección IP asignada, y sus comunicaciones pasarán, por
decirlo de alguna manera, del nivel de enlace de datos (Ethernet) al nivel de red (IP).
Proceso cliente
Por lo general, un cliente DHCP se debe configurar únicamente con la información que se desea
obtener. Por ejemplo, las distribuciones basadas en Debian suelen usar el cliente DHCP, dhclient,
que se configura con el archivo /etc/dhcp3/dhclient.conf. El archivo de muestra incluido en el
paquete del cliente dhcp3 tiene todas las opciones de configuración deshabilitadas con
comentarios, excepto una. La única opción habilitada podría tener el siguiente aspecto:
Listado 1. Opción de dhclient.conf
request subnet-mask, broadcast-address,
19
time-offset, routers, domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope;
En este ejemplo, con la configuración predeterminada, el cliente básicamente dice: "pido todo lo
que se pueda". En los mensajes de negociación, el mensaje DHCPACK del servidor contiene
información de todos estos valores solicitados que el cliente usará una vez recibidos. La dirección
IP del cliente está implícita en la lista ya que esa configuración siempre es objeto de negociación.
Además de especificar las opciones de tiempo de espera y de tiempo de concesión (y algunas
otras), el cliente puede (en la mayoría de los casos no está obligado a hacerlo) imponer ciertas
restricciones a las direcciones IP que desea usar. Para excluir una dirección en particular, es
posible usar reject 192.33.137.209;. Para especificar de manera expresa la dirección que desea
utilizar el cliente, usefixed-address 192.5.5.213;.
Es posible que el cliente rechace una oferta de concesión con el mensaje DHCPDECLINE; sin
embargo, los servidores intentarán cumplir las solicitudes cuando fuera posible. Un servidor DHCP
también puede realizar la asignación fija de una dirección IP específica a una dirección MAC; es
más frecuente que la configuración de una dirección IP por máquina se lleve a cabo con la
configuración del servidor que con la configuración del cliente.
Para tener un registro de las concesiones adquiridas, dhclient mantiene una lista con las
concesiones que se le asignaron en el archivo /var/lib/dhcp3/dhclient.leases (la ruta de acceso
puede variar según la distro); así, una concesión DHCP vigente no se perderá si un sistema se
desconecta de la red física o se reinicia.
Proceso servidor
El servidor DHCP necesita conocer un poco más sus opciones ya que proporciona diversa
información a los clientes en las concesiones CDP; además, debe asegurarse de que las
direcciones IP se asignen de manera única exclusiva a cada cliente. Por lo general, el servidor
DHCP se ejecuta como daemon, dhcpd, y obtiene la información de su configuración de
/etc/dhcpd.conf (la ruta de acceso puede variar según la distro). Es posible que un solo daemon
dhcpd gestione múltiples subredes, generalmente cuando existen múltiples redes físicas que se
conectan a un servidor; sin embargo, es más frecuente que un servidor gestione una subred. El
listado 2 es un ejemplo bastante completo de la configuración de un servidor.
Listado 2. Opciones de configuración de dhcpd.conf
# default/max lease in
seconds: day/week default-lease-time 86400; max-lease-time 604800; option
subnet-mask 255.255.255.0; option broadcast-address 192.168.2.255; option
routers 192.168.2.1; # DNS locally, fallback to outside local domain option
domain-name-servers 192.168.2.1, 151.203.0.84; option domain-name "example.com";
# Set the subnet in which IP address are pooled subnet 192.168.2.0 netmask
255.255.255.0 { range 192.168.2.100 192.168.2.199; } # Assign a fixed IP to a
couple machines by MAC address group { use-host-decl-names true; host
first.example.com { hardware ethernet 00:00:c1:a2:de:10; fixed-address
192.168.2.200; } host second.example.com { hardware ethernet 00:dd:cc:a1:78:34;
fixed-address 192.168.2.201; }
Cuando un cliente envía un mensaje de difusión a un servidor que se ejecuta con esta
configuración, este recibirá una concesión en 192.168.2.200 ó 192.168.2.201, si tiene la dirección
MAC especificada, o recibirá una concesión en una dirección disponible dentro del grupo
192.168.2.100-192.168.2.199.
El cliente también puede usar el mensaje DHCPINFORM para indicarle al servidor que ya tiene una
dirección IP asignada (por configuración manual), pero que desea obtener otro tipo de información
20
de configuración. Tenga presente que informar a un servidor que un cliente está usando una
dirección IP específica no es lo mismo que solicitar una dirección IP específica. En el último caso,
el servidor puede conceder o no la solicitud dependiendo de las concesiones existentes. En el
primer caso, el servidor no tiene voz en la decisión, y no se puede otorgar una concesión per se
(sin embargo, los servidores intentarán evitar la asignación de direcciones IP que estén en uso a
nuevos clientes solicitantes).
Cuando expira la concesión, los clientes y los servidores deben negociar nuevas concesiones para
que los parámetros de configuración sigan siendo válidos. Se pueden usar concesiones más cortas
cuando haya grandes posibilidades de que cambie la información de configuración de un servidor
(por ejemplo, DNS dinámico a través de una WAN externa). Un cliente puede extinguir una
concesión enviando el mensaje DHCPRELEASE, pero esto no es suficiente para lograr un correcto
funcionamiento (después de todo, los clientes a veces se bloquean, se reinician o se desconectan
sin tener la oportunidad de enviar el mensaje).
En ausencia de un mensaje de liberación, la concesión es mantenida por el servidor según los
términos de duración en que se otorgó la concesión, por lo que una máquina reiniciada
generalmente seguirá usando la concesión anterior (que se almacenará en dhclient.leases tanto en
el servidor como en el cliente).
Configuración NIS
Cuándo usar NIS
La mayoría de las utilidades asociadas con NIS siguen llevando el prefijo yp debido al nombre
anterior del protocolo, "Sun Yellow Pages". Por cuestiones legales relativas a la marca, el servicio
pasó a llamarse NIS. NIS permite que una red de máquinas comparta información como usuarios y
grupos (el contenido de /etc/passwd y /etc/group, respectivamente), dando a los usuarios derechos
en cualquier máquina dentro de un dominio NIS.
NIS funciona de manera similar a DNS al definir dominios donde se distribuye información y
permitir que los servidores maestros y esclavos distribuyan información jerárquicamente dentro de
un dominio. De hecho, NIS se podría usar en lugar de DNS distribuyendo la información de
nombres de dominio encontrada en /etc/hosts, aunque esto rara vez suceda en la práctica. NIS
tiene cierta flexibilidad: en principio, cualquier tipo de información puede colocarse en una base de
datos NIS (que está en formato DBM, pese a que la herramienta makedbm del paquete de servidor
NIS convierte los archivos planos en este formato, generalmente "tras bambalinas ").
También existe un servicio llamado NIS+ con el que se buscó reemplazar a NIS y que incluye el
cifrado y la autenticación de datos; sin embargo, NIS+ no es compatible con versiones anteriores
de NIS y su uso no es muy extendido.
Antes de comenzar
Para ejecutar cualquiera de las utilidades NIS, es necesario ejecutar el daemon /sbin/portmap, que
convierte los números del programa RPC en números de puerto del protocolo TCP/IP (o UDP/IP),
debido a que los clientes NIS hacen llamadas RPC. Si bien la mayoría de las distribuciones de
Linux inician /sbin/portmap en sus scripts de inicio, se recomienda verificar si este daemon se está
ejecutando con % ps -ax | grep portmap.
Si no está en ejecución, instale /sbin/portmap e inclúyalo en los scripts de inicio de su sistema.
Utilidades del cliente NIS (daemon ypbind)
Un cliente NIS incluye las herramientas ypbind, ypwhich, ypcat, yppoll y ypmatch. El daemon
ypbind se debe ejecutar como raíz y, por lo general, es iniciado como parte de los scripts de inicio
del sistema (si bien esto no es obligatorio).
Las otras herramientas están basadas en los servicios de ypbind, pero se ejecutan a nivel de
usuario. La versión anterior de ypbind difundía una solicitud de enlace en la red local; sin embargo,
esto permite que un servidor NIS malicioso responda la solicitud y proporcione a los clientes
información de usuario y de grupo errónea. Es preferible configurar servidores específicos para que
ypbind se conecte antes que usar el archivo /etc/yp.conf. Si se configuran múltiples servidores (o si
se usa la difusión a pesar del peligro), ypbind puede cambiar los servidores enlazados cada 15
21
minutos según cuál de ellos puede responder más rápidamente. Estos servidores deberían estar
organizados en una configuración maestro/esclavo, pero el cliente no tiene que conocer este dato
ni preocuparse por él. Por ejemplo, la configuración ypbind puede tener el siguiente aspecto:
Listado 3. /etc/yp.conf
ypserver 192.168.2.1 ypserver 192.168.2.2 ypserver
192.168.1.100 ypserver 192.168.2.200
Antes que se ejecute /usr/sbin/ypbind, es necesario establecer el nombre de dominio NIS de la red,
que puede ser cualquier nombre que se elija para el servidor NIS y que, por lo general, debería ser
diferente del nombre de dominio DNS. Establezca el nombre de dominio NIS usando (incluya el
nombre real): % ypdomainname my.nis.domain.
Utilidades del cliente NIS (otra configuración)
Si desea usar NIS como parte de la búsqueda del nombre de dominio, debe modificar
/etc/host.conf de manera que incluya NIS en el orden de búsqueda; por ejemplo, buscar un nombre
en primer lugar en /etc/hosts, luego en NIS y, por último, en DNS:
Listado 4. Modificación del orden de búsqueda
% cat /etc/host.conf order
hosts,nis,bind
Para habilitar usuarios distribuidos NIS, modifique el archivo /etc/passwd del cliente de manera que
incluya +::::::.
La información de base de datos NIS actúa como una plantilla para los intentos de inicio de sesión
con este patrón "sin rellenar". Es posible ajustar la información de usuario si así lo desea; por
ejemplo:
Listado 5. /etc/passwd detallado
+user1:::::::+user2:::::::+user3:::::::+@sysadmins:::::::-ftp+:*::::::/etc/NoShell
De esta manera, solo se permite el acceso a user1, user2 y user3, así como a todos los miembros
del netgroup sysadmin, pero se proporcionan los datos de cuenta de todos los otros usuarios de la
base de datos NIS.
Las fuentes NIS se configuran en /etc/nsswitch.conf. El nombre podría indicar que se hace
referencia estricta a una búsqueda de servidor de nombres cuando, en realidad, se describen
diversos tipos de información. Básicamente, esta configuración describe el orden en que se busca
en las fuentes de información. El nombre nis significa información obtenida en un servidor NIS; el
nombre files implica usar un archivo de configuración local apropiado. El nombre dns se usa para
la opción hosts.
Además, es posible especificar qué hacer si una fuente inicial no contiene la información
deseada: return implica abandonar (y a menos que NIS no responda en absoluto, continue implica
buscar el dato en la siguiente fuente). Por ejemplo:
Listado 6. /etc/nsswitch.conf
passwd: compat group: compat shadow: compat
22
hosts: dns [!UNAVAIL=return] files networks: nis [NOTFOUND=return] files ethers:
nis [NOTFOUND=continue] files protocols: nis [NOTFOUND=return] files rpc: nis
[NOTFOUND=return] files services: nis [NOTFOUND=return] files
Utilidades de usuario del cliente NIS
Las utilidades ypwhich, ypcat, yppoll y ypmatch se usan a nivel de usuario para consultar
información sobre NIS:
• ypwhich imprime el nombre de un servidor NIS.
• ypcat imprime los valores de todas las claves de una base de datos NIS.
• yppoll imprime la versión y el servidor maestro de un mapa NIS.
• ypmatch imprime los valores de una o más claves de un mapa NIS.
Consulte las páginas man correspondientes a la utilidad en cuestión para obtener más información
acerca de su uso.
Utilidades del servidor NIS (ypinit, ypserv)
El servidor NIS usa el daemon ypserv para proporcionar bases de datos NIS a los clientes y se
configura en el archivo /etc/ypserv.conf. Como se mencionó anteriormente, es posible ejecutar los
servidores NIS maestro y esclavo dentro de un dominio. El conjunto de bases de datos NIS se
inicializa en un servidor maestro usando (solo la primera vez que se ejecuta; luego use make -C
/var/yp): % /usr/lib/yp/ypinit -m.
Un servidor esclavo no es sino un cliente NIS que obtiene sus bases de datos del servidor maestro
(y ejecuta ypserv). Para copiar la información del servidor maestro en el servidor esclavo que se
ejecuta localmente, use % /usr/lib/yp/ypinit -s my.nist.domain.
En el servidor maestro, las bases de datos NIS se generan a partir de información incluida en
(algunos de) los siguientes archivos de configuración:
• /etc/passwd,
• /etc/group,
• /etc/hosts,
• /etc/networks,
• /etc/services,
• /etc/protocols,
• /etc/netgroup,
• /etc/rpc.
Las bases de datos que se exportan son configuradas en /var/yp/Makefile, que también propaga
los cambios al momento de su regeneración.
Los servidores esclavos recibirán una notificación de cualquier cambio que se produzca en los
mapas NIS al momento de su regeneración (a través del programa yppush) y automáticamente
recuperarán los cambios necesarios para poder sincronizar sus bases de datos. Los clientes NIS
no necesitan hacer esto ya que se comunican continuamente con el servidor NIS para leer la
información almacenada en sus bases de datos DBM.
Configuración LDAP
Cuándo usar LDAP
En principio, el Protocolo ligero de acceso a directorios es similar en cuanto a su objetivo a NIS.
Ambos distribuyen cierta información estructurada desde el cliente hasta el servidor; sin embargo,
LDAP va más allá estructurando de forma jerárquica qué información se distribuye entre qué
clientes, redirigiendo solicitudes a otros servidores LDAP si fuera necesario e incorporando
mecanismos de seguridad. Además, LDAP proporciona mecanismos y herramientas para que los
clientes actualicen la información almacenada en los servidores LDAP y, a su vez, la distribuyan
entre otros clientes que la soliciten (conforme a los permisos correspondientes).
23
Instalación
Antes de ejecutar OpenLDAP, la implementación de software libre generalmente usada en Linux (si
bien existen implementaciones comerciales), es necesario instalar varias bibliotecas necesarias (o
verificar su existencia):
• Es posible obtener los servicios de Seguridad del nivel de transporte (TLS) desde el
proyecto OpenSSL Project (o a través de los mecanismos de instalación de su distribución
de Linux).
• Los servicios de autenticación Kerberos son opcionales, pero muy recomendables. Es
posible usar MIT Kerberos oHeimdal Kerberos.
• El nivel de seguridad y autenticación simple se puede instalar como parte de la distro
básica, pero también se puede obtener desde Cyrus SASL.
• Se recomienda usar Sleepycat Software Berkeley DB, aunque probablemente existan otras
implementaciones DBM compatibles.
• Es deseable, por no decir obligatorio, usar Posix threads y TCP wrappers.
Una vez satisfechos estos requisitos previos, descargue la biblioteca OpenLDAP y realice el baile
más o menos habitual:
Listado 7. Danza de instalación de OpenLDAP habitual
% ./configure % make
depend % make % make test # make sure things went OK % su root -c 'make
install'
Después de la instalación básica, es necesario configurar la configuración slapd, que suele estar
en /usr/local/etc/openldap/slapd.conf. La configuración debe incluir los componentes del dominio:
Listado 8. Componentes de dominio a incluir en slapd.conf
database bdb suffix
"dc=eng,dc=uni,dc=edu,dc=eu" rootdn "cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu"
rootpw <secret> directory /usr/local/var/openldap-data
Para encontrar un valor para <secret>, use la utilidad slappasswd con la siguiente cadena
codificada en base64 cifrada para su "<secret>":
Listado 9. Descubrimiento del "secreto"
% slappasswd New password: *******
Re-enter new password: ******** {SSHA}YzPqL5Jio2+17NFIy/pAz8pqS5Ko13fH
Para obtener más información acerca de los permisos, la replicación y otras opciones de
slapd.conf, observe con atención las páginas man detalladas.
La iniciación del daemon slapd es similar a la iniciación de cualquier otro daemon; para comprobar
su funcionamiento, useldapsearch:
Listado 10. Prueba de funcionamiento de slapd
su root -c
/usr/local/libexec/slapd ldapsearch -x -b '' -s base '(objectclass=*)'
24
namingContexts
Si todo salió bien, debería aparecer un código similar al del listado 11:
Listado 11. Respuesta de slapd en funcionamiento
dn:namingContexts:
dc=eng,dc=uni,dc=edu,dc=eu
Agregado de datos con un archivo LDIF
El formato de datos usado en LDAP es un formato binario; sin embargo, para exportar e importar
datos en una base de datos LDAP, se usa una serialización ASCII llamada Formato de intercambio
de datos LDAP (LDIF). En LDIF, los datos binarios se representan como codificación base64.
OpenLDAP incluye herramientas para exportar datos desde los servidores LDAP a LDIF
(ldapsearch), para importar datos desde LDIF a los servidores LDAP (ldapadd) y para aplicar un
conjunto de cambios descriptos en LDIF a los servidores LDAP (ldapmodify y ldapdelete).
Además, LDIF es uno de los formatos que se usan para importar y exportar datos de la libreta de
direcciones de Mozilla Application Suite y otras herramientas de usuario de nivel de aplicación.
Incluso Microsoft Windows 2000 Server y Windows Server 2003 incluyen una herramienta
LDIF, LDIFDE, para transferir datos desde y hasta Active Directory (Directorio activo).
Para agregar información manualmente a un servidor LDAP, primero es necesario crear un archivo
LDIF:
Listado 12. Creación del archivo LDIF de muestra, example.ldif
dn:
dc=example,dc=com objectclass: dcObject objectclass: organization o: Example
Company dc: example dn: cn=Manager,dc=example,dc=com objectclass:
organizationalRole cn: Manager
Luego agréguelo usando% ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif.
Por supuesto que el dominio example.com se debe reemplazar por un dominio adecuado para su
sitio. Normalmente, las jerarquías y los nombres de dominio LDAP coinciden con aquellos usados
por los nombres DNS familiares. Se le pedirá que ingrese el valor rootpw especificado en
slapd.conf.
Consulta de bases de datos LDAP
Existe una herramienta, slurpd (Standalone LDAP Update Replication Daemon), que se utiliza
para replicar una base de datos de información completa; sin embargo, para el caso de valores de
datos individuales, se usa una herramienta como ldapsearch o bien (más probablemente) se
incorpora la compatibilidad con LDAP en alguna aplicación que se ejecute. La
herramientaslapcatsirve para volcar una base de datos LDAP en LDIF. Por ejemplo, muchos Mail
User Agents (MUA) pueden usar LDAP para buscar información de dirección y de contacto.
Dentro de algunas aplicaciones, incluso aquellas que se pueden programar usando lenguajes de
scripting o de aplicación, es posible acceder a los recursos LDAP con URL LDAP, que toman la
siguiente forma: ldap://host:port/dn?attributes?scope?filter?extensions.
La mayoría de estos campos son opcionales. El nombre de host predeterminado es localhost; el
puerto predeterminado es 389. El nombre distintivo raíz predeterminado es la cadena vacía. Si
necesita información de autenticación, especifíquela en la porción extensions de la URL.
25
Además de las URL LDAP, muchos servidores y clientes LDAP son compatibles con las URL
LDAPS, no estándar pero ampliamente usadas. Las URL LDAPS usan conexiones SSL en lugar de
conexiones
de
texto
simple
y
usan
un
puerto
predeterminado
636: ldaps://host:port/dn?attributes?scope?filter?extensions.
Recursos
Aprender
• Lea las especificaciones formales de DHCP (RFC 2131) para conocer este protocolo.
•
Lea "The Linux NIS(YP)/NYS/NIS+ HOWTO" para conocer NIS.
•
La especificación formal de LDAP es RFC 2251.
•
TCP/IP Network Administration, tercera edición , de Craig Hunt, (O'Reilly, abril de 2002) es
un excelente recurso sobre las redes Linux.
•
Esta lista de más de 700 grupos de usuarios Linux de todo el mundo lo ayudará a
encontrar grupos de estudio locales y remotos para los exámenes de LPI.
•
Si desea obtener información más detallada, el proyecto Linux Documentation Project tiene
una gran variedad de documentos útiles, entre los que se destacan sus instructivos.
•
En la zona Linux de developerWorks encontrará más recursos para desarrolladores Linux.
•
Manténgase al día con los eventos técnicos y las transmisiones por Internet de
developerWorks.
Autor:
David Mertz es Turing completo, pero probablemente no apruebe la Prueba de Turing. Para
conocer más acerca de su vida, consulte su página Web personal. David escribe las columnas
developerWorks Charming Python y XML Matters desde el año 2000. Consulte su libroText
Processing in Python [Procesamiento de texto en Python].
Compilación y edición:
Ing. Sergio Aguilera. Facultad de Tecnología Informática. Universidad de Belgrano.
sergio.aguilera@ub.edu.ar
Todos los Derechos Reservados a IBM Corp. – Marzo 2012.
26
27