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:[email protected]/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 . 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: ;; ->>HEADERs %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 .Por ejemplo: Listado 7. Ejemplo de directiva de directorio #Let's have some Icons, shall we? Alias /icons/ "/usr/share/apache2/icons/" Options Indexes AllowOverride None Order allow,deny Allow from all

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 ; 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 ServerAdmin [email protected] DocumentRoot /var/www/foo ServerName foo.example.com Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all CustomLog /var/log/apache2/foo_access.log

16

combined DocumentRoot /var/www/bar ServerName bar.example.org DocumentRoot /var/www 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 . 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 . 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 AuthName "Baz" AuthType Basic AuthUserFile /etc/apache2/http.passwords AuthGroupFile /etc/apache2/http.groups Require john jill sally bob 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 directory /usr/local/var/openldap-data

Para encontrar un valor para , use la utilidad slappasswd con la siguiente cadena codificada en base64 cifrada para su "": 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. [email protected] Todos los Derechos Reservados a IBM Corp. – Marzo 2012.

26

27