Preparación para el examen 201 de LPI: Uso compartido de archivos y servicios

Administración Nivel Intermedio (LPIC-2): tema 209

A través de este tutorial, Brad Huntting y David Mertz lo siguen preparando para el examen 201 de Intermediate Level Administration (LPIC-2) del Linux Professional Institute®. En este tutorial, el quinto de una serie de ocho, aprenderá a usar un sistema Linux™ como servidor de archivos de red utilizando alguno de los diversos protocolos compatibles con Linux.

Brad Huntting, Mathematician, University of Colorado

Brad se encarga de la administración de sistemas UNIX®y de ingeniería de redes para varias compañías desde hace 14 años. En la actualidad, está cursando un Doctorado en Matemática Aplicada en la Universidad de Colorado en Boulder, y paga sus estudios trabajando en soporte de UNIX para el departamento de Ciencias de la Computación.



David Mertz, Developer, Gnosis Software

David MertzDavid 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 libro Text Processing in Python [Procesamiento de texto en Python].



28-07-2010

Antes de comenzar

Aprenda todo lo que estos tutoriales pueden enseñarle y cómo aprovecharlos al máximo.

Acerca de esta serie

El Linux Professional Institute (LPI) otorga dos niveles de certificados para administradores de sistemas Linux: nivel inicial y nivel intermedio. Para obtener el certificado de cada nivel, en necesario aprobar dos exámenes del LPI.

Cada examen abarca diversos temas, y cada tema tiene su propio valor de ponderación. Este valor indica la importancia relativa de cada tema dentro del examen. En líneas generales, prepárese para responder más preguntas sobre aquellos temas con mayor valor de ponderación. A continuación se enumeran los temas con su correspondiente valor de ponderación del examen 201 del LPI:

Tema 201
Kernel de Linux (valor 5).
Tema 202
Inicio del sistema (valor: 5).
Tema 203
Sistemas de archivos (valor: 10).
Tema 204
Hardware (valor: 8).
Tema 209
Uso compartido de archivos y servicios (valor: 8); el objeto de este tutorial.
Tema 211
Mantenimiento del sistema (valor: 4).
Tema 213
Personalización y automatización del sistema (valor: 3).
Tema 214
Solución de problemas (valor: 6).

El Linux Professional Institute no respalda ningún material ni técnica de preparación para el examen en particular. Para más información, escriba a info@lpi.org.

Acerca del presente tutorial

Bienvenido a "Uso compartido de archivos y servicios", el quinto de ocho tutoriales creados para prepararlo para el examen 201 del LPI. En este tutorial, aprenderá a utilizar un sistema Linux como servidor de archivos de red usando alguno de los diversos protocolos compatibles con Linux.

El tutorial está organizado en función de los objetivos del LPI para este tema, que se describen a continuación:

2.209.1 Configurar un servidor Samba (valor: 5)
Usted deberá poder configurar un servidor Samba para varios clientes. Este objetivo incluye configurar un script de inicio de sesión para clientes Samba y configurar un servidor WINS nmbd. También incluye cambiar el grupo de trabajo en que participa un servidor, definir un directorio compartido en smb.conf, definir una impresora compartida en smb.conf, usar nmblookup para probar la funcionalidad del servidor WINS y usar el comando smbmount para montar un recurso compartido SMB en un cliente Linux.
2.209.2 Configurar un servidor NFS (valor: 3)
Usted deberá poder crear un archivo de exportaciones y especificar sistemas de archivos para su exportación. Este objetivo incluye editar las entradas del archivo de exportaciones para restringir el acceso a ciertos hosts, subredes o netgroups. También incluye especificar opciones de montaje en el archivo de exportaciones, configurar la asignación de ID de usuario, montar un sistema NFS en un cliente y usar las opciones de montaje para especificar reintentos de fondo flexibles o forzados, el control de señales, el bloqueo y el tamaño del bloque. También debería poder configurar TCP wrappers (envolvedores de TCP) para asegurar aún más el NFS.

Los objetivos del tema 209 del actual examen del LPI abarcan NFS y Samba, pero si usted es un administrador de sistemas que diseña la configuración de un sistema, debería, además, considerar si FTP, SCP/SSH, HTTP o algún otro protocolo podría cumplir sus requisitos.

Uno de los usos más significativos de Linux, particularmente en un contexto de servidor, es el de proporcionar archivos compartidos a sistemas clientes. De hecho, este es probablemente el uso mayoritario de las redes. Este tutorial –en realidad, esta serie de tutoriales – no tratará el tema de servidores de uso compartido de archivos entre pares como BitTorrent, sino que únicamente analizará las organizaciones cliente-servidor tradicionales: un servidor central que proporciona almacenes de disco a múltiples clientes. Aun cuando los clientes suban archivos, estos siempre serán almacenados y proporcionados por el servidor, y no de manera descentralizada.

Entre los protocolos más empleados en el uso compartido de archivos cabe incluir: HTTP (la WWW), TFTP (protocolo trivial de transferencia de archivos), FTP (protocolo de transferencia de archivos), SCP (protocolo de copia segura, un uso especializado de SSH), RCP (protocolo de copia remota, generalmente obsoleto), NFS (Network File System o Sistema de Archivos en Red) y Samba (bloque de mensajes de servidor). Los protocolos HTTP y SSH se analizarán en futuros tutoriales del examen 202 del LPI, así como ciertas cuestiones de seguridad en torno al FTP. Por su parte, los protocolos TFTP y RCP son obsoletos o de aplicación específica, por lo que no se tratarán en estos tutoriales.

El presente tutorial analiza NFS y Samba con cierto detalle y describe brevemente FTP. NFS y Samba are protocolos de uso compartido de archivos de red que permiten un acceso mayoritariamente transparente a sistemas de archivos remotos. FTP podría requerir un programa cliente FTP personalizado, aunque muchas herramientas y entornos de escritorio (sean o no para Linux) ocultan los detalles de esta negociación y presentan de manera eficaz la misma interfaz de usuario que una unidad de NFS o Samba montada.

Requisitos previos

Para aprovechar este tutorial al máximo, es necesario tener un conocimiento básico de Linux y un sistema Linux en funcionamiento para practicar los comandos incluidos en este tutorial.


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:

# /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 en trusty 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 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.

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 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 forma option=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.

Recursos

  • En el Programa LPIC encontrará listas de tareas, preguntas de ejemplo y objetivos detallados de los tres niveles del certificado de administración del sistema Linux del Linux Professional Institute.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=502429
ArticleTitle=Preparación para el examen 201 de LPI: Uso compartido de archivos y servicios
publish-date=07282010