Servidor NFS de ficheros en red

En este punto, podemos decir que uno de los hitos fundamentales que quer´ıamos conseguir en nuestro sistema, ya lo hemos logrado: dar el salto a una tecnolog´ıa punta como es hoy en d´ıa LDAP, aumentar la seguridad de la autenticaci´on de los usuarios en el sistema, como ha quedado demostrado, adem´as de dotar al entorno de una fiabilidad y rendimiento ´optimos. A continuaci´on, se nos presenta como reto dotar al sistema de un servicio de ficheros en red capaz de soportar toda la carga del entorno, adem´as de disponga de espacio suficiente para poder almacenar de forma amplia un n´umero aproximado de tres mil cuentas de usuario, con sus correspondientes carpetas personales.

La opci´on ´unica clara que se presenta es el uso del sistema de ficheros NFS21

, un sistema de ficheros en entornos Unix que permite acceder a ficheros y diretorios remotos como si fueran ficheros locales. En Unix/Linux esto es posible gracias a una mezcla de funcionalidad en el mismo kernel de Linux en la m´aquina cliente y un demonio en el servidor, mezclado todo con llamadas RPC22

entre el cliente y el servidor (NIS tambi´en funciona con RPC).

El servidor de NFS, exporta un conjunto de directorios (uno o m´as) de forma remota a todos aquellos clientes que deseen montar ese directorio. Por otro lado, los clientes montan ese directorio v´ıa NFS en su sistema de ficheros local. La sintaxis para montar un directorio v´ıa NFS no es muy diferente a la que que se usa para montar directorios locales, m´as que a˜nadiendo la m´aquina que alberga el servidor NFS y el directorio que se desea montar. Como vimos en el cap´ıtulo de dise˜no, la m´aquina que albergar´a el servidor NFS para el Campus de M´ostoles, ser´a la m´aquina lechuzo (con direcci´on IP 212.128.4.8), y exportar´a el directorio /disks/raid/homes.mostoles de cara a los clientes, las estaciones del Laboratorio. As´ı, para poder montar remotamente los directorios personales de los alumnos en una estaci´on cliente, tendr´ıamos que introducir:

$ mount -t nfs lechuzo . escet . urjc . es :/ disks / raid / homes . m o s t o l e s / home

De forma que en el directorio /home de los clientes, quedar´ıa montado el directorio remoto /disks/raid/homes.mostoles/ del servidor. El uso de este directorio, ser´ıa totalmente transparente para los usuarios de las estaciones, que lo usar´ıan como si de un directorio local se tratara. Evidentemente, la tarea de montar el servidor de homes est´a automatizada en el arranque de las estaciones del laboratorio. Esto se consigue a˜nadiendo una l´ınea al fichero /etc/fstab que contiene los montajes remotos que se desea iniciar en el inicio del sistema:

lechuzo . escet . urjc . es :/ disks / raid / homes . m o s t o l e s / / h ome nfs rw , rsize =8192 , wsize =8192 , udp

Esta l´ınea contiene algo m´as de informaci´on que la anterior. Las opciones m´as interesantes son las opciones rw, y la opci´on udp, que monta el directorio del servidor usando el protocolo de

21

NFS son las siglas de Network File System o Sistema de Ficheros en Red.

22

RPC son las siglas de Remote Procedure Call o Llamada a Procedimiento Remoto.

4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACI ´ON

transporte udp. Resulta razonable en una red local como la que nos ocupa usar este protocolo, ya que suponemos que se producen pocas p´erdidas y los tiempos de respuesta son en su mayor´ıa bajos.

Por otro lado, en el servidor, deber´ıamos tener disponible el demonio de NFS, provisto por el paquete nfs-kernel-server:

Listado 4.42: Instalaci´on del servidor NFS a trav´es de apt-get

$ apt - get install nfs - kernel - server

Configuraci´on del servidor

La configuraci´on del servidor de NFS ´unicamente contempla el seleccionar el directorio que se desea exportar de cara a los clientes. Esta configuraci´on se lleva a cabo en el fichero /etc/exports. Para cada directorio exportado, se debe seleccionar el rango de direcciones IP a los que se les permite usar o montar ese recurso. En este momento, NFS no dispone de ning´un mecanismo de autenticaci´on que no sea permitir o denegar el montaje del recurso ateniendo a la direcci´on IP del cliente. Vemos un fragmento del fichero de configuraci´on a continuaci´on:

/ disks / raid / homes . m o s t o l e s \

2 1 2 . 1 2 8 . 4 . 0 / 2 4 ( rw , sync , no_root_squash , n o _ s u b t r e e _ c h e c k ) \ 1 9 3 . 1 4 7 . 5 6 . 0 / 2 4 ( rw , sync , no_root_squash , n o _ s u b t r e e _ c h e c k )

En efecto, esto supone muchos problemas de seguridad de cara a los clientes a los que permitimos montar el recurso, y en los que confiamos. En principio, cualquier persona que usara una direcci´on IP del laboratorio (con su ordenador port´atil, por ejemplo) ser´ıa capaz de montar el recurso NFS sin mayor dificultad. Las operaciones que pueda realizar en ese momento con ese directorio dependen ´unicamente de las opciones que se hayan marcado en el directorio exportado en el servidor:

Si el recurso se ha exportado con la opcion no root squash, las operaciones a nombre del usuario root en la m´aquina local se traducir´an como operaciones con el usuario root en la m´aquina servidor.

Por el contrario, si se ha exportado el directorio con la opci´on root squash, las operaciones a nombre del usuario root en la m´aquina local se traducir´an como operaciones a nombre del usuario nobody en la m´aquina remota, y por tanto, este usuario solamente tendr´a privilegios sobre aquellos ficheros que tenga a su nombre.

A´un as´ı, estando el recurso exportado con la opci´on root squash, un usuario root local no tendr´ıa privilegios sobre nada que no est´e a su nombre, pero nada impide que intercambiando su id de usuario acceda a todos los ficheros para los que no tenga privilegios. Vemos por tanto, que las opciones son bastante poco esperanzadoras, en cuanto a seguridad se refiere. Adem´as de no poder autenticar a los clientes, excepto confiar en ellos a trav´es de su direcci´on IP, es posible acceder en modo lectura y escritura con privilegios desde cualquier cliente y modificar los ficheros de cualquier usuario al antojo del atacante, sin m´as que escribir unos cuantos comandos de shell. Como se puede deducir, NFS hoy en d´ıa adolece de graves problemas de seguridad que de momento, y debido a la estructura del kernel de Linux, no est´a a la vista ser corregidos, pero hoy en d´ıa representa la ´unica opci´on medianamente usable en cuanto a rendimiento y fiabilidad. RAID de disco

En un sistema en el que se tienen aproximadamente tres mil cuentas de usuario, resulta imprescindible disponer de una tecnolog´ıa que permita aunar gran cantidad de espacio en disco

CAP´ITULO 4. IMPLANTACI ´ON

como si se tratara de un solo dispositivo. Como vimos en el cap´ıtulo de dise˜no, vamos a hacer uso de la m´aquinas lechuzo y sapientin en el Campus de M´ostoles para albergar por un lado los directorios personales de los usuarios (directorios HOMES) y por otro lado, una copia de seguridad exacta de estos directorios, para que en caso de fallo de alg´un disco de la primera, se pueda sustituir ´esta r´apidamente (sin m´as que cambiar su direcci´on IP) y no dejar sin servicio a los laboratorios.

Discos disponibles

En principio, la configuraci´on de hardware de las m´aquinas lechuzo y sapientin no tienen porqu´e ser similares, siendo recomendable ´unicamente que la segunda tenga al menos el mismo tama˜no de espacio en disco que la primera. Incluso, la configuraci´on del RAID puede variar, no teniendo porqu´e estar configuradas en el mismo nivel.

En la m´aquina lechuzo, disponemos de cinco discos duros disponibles, de diferentes tama˜nos, tal y como muestra la tabla 4.1. El espacio total sumado entre todos los discos alcanza los 830 GB, aproximadamente.

Disco duro Tama˜no Partici´on principal

/dev/hdb 400 GB /dev/hdb1

/dev/hde 163 GB /dev/hde1

/dev/hdi 163 GB /dev/hdi1

/dev/hdm 163 GB /dev/hdm1

Cuadro 4.1: Discos duros de la m´aquina lechuzo

An´alogamente, en la m´aquina sapientin, destinada a albergar las copias de seguridad de los directorios personales de los usuarios, disponemos de seis discos duros (sin contar el dedicado a la partici´on del sistema) de 120 GB de tama˜no cada uno. El tama˜no total es aproximadamente de 500 GB, para copias de seguridad.

Configuraci´on del raid en Linux

Dispuestos los discos duros que van a ser dedicados en cada m´aquina a albergar los directorios personales de los usuarios (m´aquina principal y copias de seguridad) debemos configurar un raid por software bajo Linux, para poder acceder a todos los discos como si de ´unico dispositivo se tratara. Las herramientas adecuadas que disponen de esta funcionalidad bajo Linux vienen provistas por el paquete mdadm, cuya instalaci´on se puede completar usando el gestor de paquetes de Debian (recordamos que en el cap´ıtulo de Dise˜no establecimos que la distribuci´on a usar en los servidores, iba a ser Debian GNU/Linux):

Listado 4.43: Instalaci´on del gestor de raid mdadm usando apt-get

$ apt - get install mdadm

La herramienta mdadm es una utilidad para Linux que permite administrar (a˜nadir, borrar y modificar) raids de disco que funcionen por software (en ausencia de una controladora hardware dedicada). El nombre de la aplicaci´on mdadm viene de multiple disks. La herramienta mdadm se distribuye bajo la licencia GNU/GPL.

Lo primero que debemos hacer para configurar el RAID de disco, es formatear los discos usando el sistema de ficheros ext3. Si previamente, los discos no ten´ıan ninguna partici´on creada, debemos crearla haciendo uso de las herramientas fdisk o cfdisk. Una vez que hemos creado las particiones correspondientes, podemos formatearlas usando el sistema de ficheros ext3 invocando el programa mkfs.ext3:

4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACI ´ON

Listado 4.44: Automatizaci´on en la creaci´on del raid

$ for i in ‘ echo b e i m ‘; do mfks . ext3 / dev / hd$i1 ; done

De esta forma, formateamos las cuatro particiones en lechuzo de forma totalmente autom´atica. Lo mismo podemos hacer en la m´aquina sapientin:

Listado 4.45: Automatizaci´on en la creaci´on del RAID

$ for i in ‘ echo e g i k m ‘; do mkfs . ext3 / dev / hd$i1 ; done

Concluida esta operaci´on, podemos crear el RAID de disco deseado. Niveles de RAID usados

Un dispositivo RAID puede ser configurado en diferentes niveles, dependiendo de la configuraci´on m´as ´optima para el entorno. Para ilustrar diferentes configuraciones de RAID, vamos a usar el nivel cero (tambi´en llamada configuraci´on en tiras) en la m´aquina lechuzo y la configuraci´on de nivel cinco (disco en redundancia o disco spare) en la m´aquina sapientin. Desde el punto de vista del espacio en disco, la configuraci´on m´as ´optima es la configuraci´on en tiras, que aprovecha al m´aximo el uso de cada disco: el tama˜no total del RAID es la resultante de multiplicar el espacio disponible en cada uno de los discos por el n´umero de discos. Sin embargo, si se produce un error en uno de los discos, el RAID quedar´a totalmente inutilizable, y ser´a preciso hacer uso de la copia de seguridad.

La configuraci´on en nivel cinco, o con redundancia, hace uso de un disco para almacenar redundancias entre la informaci´on, de forma que si se produce un error en alguno de los discos, nos podremos recuperar de la informaci´on en caliente, sin m´as que cambiar el disco defectuoso. Como en principio, disponemos de dos m´aquinas, vamos a hacer uso de ambas configuraciones para poder disponer de cada las dos ventajas por el mismo precio.

Para la creaci´on del RAID hacemos uso de la herramienta mdadm de la siguiente forma:

$ mdadm -- create / dev / md0 -- level - raid 0 -- raid - devices 4 / dev / hd [ beim ]1

En la m´aquina lechuzo. El dispositivo final /dev/md0 en esta m´aquina albergar´a el raid de disco que podr´a ser considerado como si de un solo disco se tratara. En el comando expuesto, se indica que se desea aplicar un nivel de raid cero, con cuatro discos, indicando por supuesto que discos se desea a˜nadir al raid. De la misma forma, en la m´aquina sapientin,

$ mdadm -- create / dev / md0 -- level - raid 5 -- raid - devices 5 / dev / hd [ egikm ]1 -- spare - devices / dev / hdo1

En este caso, se desea aplicar una configuraci´on de RAID con redundancia, y por tanto es necesario indicar mediante el par´ametro –spare-devices que disco se desea usar para almacenar esta redundancia. Despu´es de aplicar estas operaciones, debemos tener en ambas m´aquinas y bajo el directorio /dev/md0 los respectivos dispositivos raid. Usando la propia herramienta de diagn´ostico del paquete podemos comprobar el estado de cada uno de los raids:

lechuzo :~# mdadm -D / dev / md0 / dev / md0 :

Version : 0 0 . 9 0 . 0 3

C r e a t i o n Time : Sun Jun 24 2 1 : 2 4 : 0 0 2007 Raid Level : raid0

Array Size : 8 7 0 9 4 7 3 9 2 (830.60 GiB 891.85 GB ) Raid Devices : 4

Total Devices : 4 P r e f e r r e d Minor : 0

CAP´ITULO 4. IMPLANTACI ´ON

Update Time : Sun Jun 24 2 1 : 2 4 : 0 0 2007 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Chunk Size : 64 K

UUID : 4838047 a :31901 cef :88217 ab2 :99168 cf3 Events : 0.1

Number Major Minor R a i d D e v i c e State

0 3 65 0 active sync / dev / hdb1

1 33 1 1 active sync / dev / hde1

2 56 1 2 active sync / dev / hdi1

3 88 1 3 active sync / dev / hdm1

Que nos indica que el estado es correcto (clean), que existen cuatro dispositivos activos y funcionando, el tama˜no total del dispositivo raid, adem´as de las fechas de creaci´on, actualizaci´on y de los dispositivos f´ısicos de los que se compone el raid. De la misma forma en la m´aquina sapientin, podemos observar la misma informaci´on:

s a p i e n t i n :~# mdadm -D / dev / md0 / dev / md0 :

Version : 0 0 . 9 0 . 0 3

C r e a t i o n Time : Mon May 22 1 0 : 1 4 : 2 3 2006 Raid Level : raid5

Array Size : 4 6 8 8 7 2 7 0 4 (447.15 GiB 480.13 GB ) Device Size : 1 1 7 2 1 8 1 7 6 (111.79 GiB 120.03 GB ) Raid Devices : 5

Total Devices : 6 P r e f e r r e d Minor : 0

P e r s i s t e n c e : S u p e r b l o c k is p e r s i s t e n t Update Time : Mon Feb 25 0 7 : 5 2 : 3 5 2008

State : clean Active Devices : 5 Working Devices : 6 Failed Devices : 0 Spare Devices : 1 Layout : left - s y m m e t r i c Chunk Size : 64 K

UUID : c 8 a 8 6 6 1 f :758 a1942 :83 ba8395 : d d 3 0 6 4 c a Events : 0 . 7 1 2 9 7 0 8

Number Major Minor R a i d D e v i c e State

0 33 1 0 active sync / dev / hde1

1 34 1 1 active sync / dev / hdg1

2 56 1 2 active sync / dev / hdi1

3 57 1 3 active sync / dev / hdk1

4 88 1 4 active sync / dev / hdm1

5 89 0 - spare / dev / hdo

Ahora podemos tratar todos estos discos como si de un ´unico se tratara, por lo que (aunque no es obligatorio) se recomienda formatear esta nueva partici´on en el formato de ficheros elegido, en nuestro caso, el sistema de ficheros ext3:

$ mkfs . ext3 / dev / md0

Ejecutado en ambas m´aquinas, formatear´a los dispositivos para que puedan ser montados a partir de ese momento en el sistema. ´Unicamente nos queda montar los directorios bajo el punto

4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACI ´ON

de montaje elegido: /disks/raid/homes.mostoles/:

$ mount / dev / md0 / disks / raid / homes . m o s t o l e s /

Y por ´ultimo, reiniciar el demonio NFS en ambas m´aquinas para que los recursos est´en disponibles a todas las estaciones del Laboratorio:

$ / etc / init . d / nfs - kernel - server restart

Configuraci´on del RAID en los servidores del Campus de Fuenlabrada

La configuraci´on del RAID para los servidores del Campus de Fuenlabrada (bilo y nano) es muy similar a la creaci´on del RAID para los servidores de disco del Campus de M´ostoles. En concreto, usaremos nivel de raid cero (configuraci´on en tiras) en ambas m´aquinas. Como vimos en el cap´ıtulo de dise˜no, la m´aquina bilo albergar´a el RAID que contendr´a los ficheros personales de los usuarios de ese campus (como servidor principal) y la m´aqina nano albergar´a las copias de seguridad de dichos ficheros.