Memoria Pfc Superior

(1)

Ingenier´ıa Inform´

atica

Escuela Técnica Superior de Ingenier´ıa Informática Curso académico 2007-2008

Proyecto Fin de Carrera

INSTALACI ´

ON, CONFIGURACI ´

ON Y ADMINISTRACI ´

ON

DE AULAS INFORM ´

ATICAS MEDIANTE SOFTWARE

LIBRE

Autor: Antonio Guti´errez Mayoral Tutor: Jose Centeno Gonz´alez

(2)

(3)

(4)

(5)

Gracias

La finalización de un proyecto fin de carrera normalmente lleva asociado el fin de una etapa y el comienzo de otra. En particular, este proyecto resume prácticamente los últimos dos años trabajando en el GSyC en la administración de sus laboratorios docentes. Un par de años en los que he trabajado en un entorno de trabajo que creo que puede considerarse privilegiado y que cualquier persona podr´ıa envidiar.

A través de este pequeño texto quiero agradecer al Grupo de Sistemas y Comunicaciones el facilitarme un entorno de trabajo envidiable, y del que me acordaré siempre, sobre todo si algún d´ıa ya no estoy aqu´ı. A Jose Centeno y Pedro de las Heras por confiar en m´ı y creer en m´ı como aquél que podr´ıa realizar el trabajo que intento hacer todos los d´ıas con la máxima ilusión posible. Gracias también a Sergio Arévalo y Jesús González Barahona como directores del Departamento y estar ah´ı siempre que lo he necesitado, ayudándome siempre que han podido. Gracias también a todo el Grupo por el capital humano aportado y por hacerme sentir en uno de los mejores entornos de trabajo que he estado.

Gracias a mis compañeros de Universidad sin los cuales el d´ıa a d´ıa ser´ıa mucho más amargo y aburrido. Gracias a Lorena, Juan Carlos, Carlos, Tamara, Fran, Javi, Marina, Belén y todos los demás.

Gracias a mi familia, a mis padres y mi hermano, ya que sin su apoyo y confianza nada de esto hubiera sido posible.

A todos, gracias.

(6)

(7)

Resumen

Hoy en d´ıa la administración de sistemas se ha convertido en un aspecto fundamental en cualquier entorno informático. En la empresa esta responsabilidad es clara, donde la alta disponibilidad de los sistemas es básica para su operabilidad. De la misma manera, en cualquier entorno docente es fundamental la puesta en marcha de todas aquellas tecnolog´ıas necesarias para permitir a los alumnos realizar sus prácticas y a los profesores impartir sus asignaturas. A veces esta tarea no es tan fácil como parece a simple vista: requiere de conocimientos avanzados de redes, sistemas operativos y administración de sistemas.

Por otro lado, el avance del Software Libre como modelo de desarrollo de software además de como alternativa para la docencia hace muy atractivo su uso de cara a las diferentes materias que pueden ser impartidos en una carrera de Ingenier´ıa Informática, ya que su flexibilidad y los conceptos sobre los que se sustenta el Software Libre hacen que se pueda adaptar muy fácilmente a ellas. En particular, la puesta en marcha de una serie de tecnolog´ıas relacionadas con la administración del sistema Linux resultan básicas para que se pueda usar este Sistema Operativo en un entorno docente.

En este proyecto se ha llevado a cabo un análisis de las diferentes tecnolog´ıas que son necesarias para el funcionamiento de un entorno de estas caracter´ısticas. Por un lado, es necesario establecer un plan o mecanismo que facilite la labor de los administradores de cara a la instalación de un número elevado de estaciones de usuario. Para ello, se implementará un mecanismo de instalaciones automáticas completamente desatendidas que facilite esta labor.

Por otro lado, también se hace necesaria la implantación de un servicio que facilite que los usuarios puedan iniciar una sesión en el entorno a partir de unas credenciales determinadas (normalmente un par formado por el nombre de usuario y contraseña), as´ı como proporcionar un servicio de disco en red que facilite a los usuarios el poder almacenar sus ficheros personales a lo largo de toda la red local.

Estos dos objetivos principales son b´asicos para el funcionamiento del entorno, pero no son los ´

unicos. La adición de servicios adicionales al Laboratorio, como un servicio de correo electrónico (entrega y recogida) as´ı como un sitio web bien documentado y funcional de cara a los alumnos van a hacer que éste sea más agradable al uso diario. Servicios adicionales de cara a la gestión, como construir y documentar pol´ıticas de seguridad eficientes e instaurar un sistema de monitorización del estado de la red (que garantizarán la rápida detección de incidencias y por tanto su resolución), culmina el proyecto.

La realización de este proyecto supone la implantación de un entorno totalmente funcional apto para la docencia de todas las prácticas de las asignaturas pertenecientes al Departamento de Sistemas Telemáticos y Computación, al mismo tiempo que consolidan amplios conocimientos en Sistemas Operativos de la familia GNU/Linux, as´ı como en un amplio abanico de aplicaciones de servidor, ampliamente usadas en entornos empresariales. La construcción adicional de aplicaciones web de gestión de todos los servicios que hemos implementado en este proyecto, as´ı como técnicas avanzadas como la virtualización de servidores dejan la puerta abierta a trabajos futuros en la misma l´ınea de investigación que el presente proyecto.

(8)

(9)

´Indice general

1. Introducci´on 3

1.1. Motivaci´on del proyecto . . . 4

1.2. Estructura de este documento . . . 4

1.3. Estado del arte . . . 4

1.3.1. Distribuciones de Linux . . . 5

1.3.2. Sistemas de instalaci´on desatendidos . . . 10

1.3.3. Sistemas de autenticaci´on de usuarios . . . 13

1.3.4. Sistemas de ficheros en red . . . 17

1.3.5. Servidores de correo electr´onico . . . 19

1.3.6. Sistemas de monitorizaci´on . . . 22

2. Objetivos 27 2.1. Sistema de instalaciones masivas y desatentidas . . . 28

2.2. Sistema de cuentas de usuario y disco en red . . . 28

2.3. Servicios adicionales . . . 29

2.4. Monitorizaci´on del sistema . . . 30

2.5. Pol´ıticas de seguridad . . . 31

2.6. Documentaci´on . . . 32

3. Especificaci´on y Dise˜no 33 3.1. Metodolog´ıa empleada . . . 34

3.2. An´alisis de requisitos . . . 34

3.2.1. Proceso de instalaci´on desatendido . . . 34

3.2.2. Cuentas de usuario en red y disco en red . . . 35

3.2.3. Servicios de valor a˜nadido . . . 35

3.3. Dedicaci´on de las m´aquinas f´ısicas . . . 36

3.3.1. Peloto . . . 37 3.3.2. Zipi . . . 37 3.3.3. Zape . . . 37 3.3.4. Lechuzo . . . 37 3.3.5. Sapientin . . . 37 3.3.6. Pantuflo . . . 38 3.3.7. Espatula . . . 38

3.4. Servidores disponibles en el Campus de Fuenlabrada . . . 38

3.4.1. Bilo . . . 39

3.4.2. Nano . . . 39 ix

(10)

´_{INDICE GENERAL} ´_{INDICE GENERAL}

4. Implantaci´on 41

4.1. Herramienta de Instalaci´on Autom´atica . . . 42

4.1.1. Servidor DHCP para configuraci´on autom´atica de Red . . . 43

4.1.2. Arranque por PXE . . . 44

4.1.3. Arranque por red de Linux . . . 46

4.1.4. Ficheros de preconfiguraci´on . . . 46

4.2. Protocolos situados en la capa de aplicaci´on . . . 52

4.2.1. Servidor LDAP de cuentas de usuario . . . 52

4.2.2. Servidor NFS de ficheros en red . . . 69

4.2.3. Servidor Web de los Laboratorios . . . 74

4.2.4. Servidor de correo electr´onico . . . 81

4.3. Otros servicios disponibles . . . 86

4.3.1. Listas de correo . . . 86

4.3.2. Mirror de Debian y Ubuntu . . . 89

4.4. Monitorizaci´on del Sistema . . . 90

4.4.1. Monitorizaci´on de servidores . . . 91

4.4.2. Monitorizaci´on de estaciones . . . 94

4.5. Seguridad . . . 95

4.5.1. Limitar los accesos remotos . . . 95

4.5.2. Auditor´ıa de usuarios . . . 97

4.5.3. Detecci´on de intrusos . . . 99

4.5.4. Ataques de fuerza bruta v´ıa SSH . . . 100

4.5.5. Seguridad en las contrase˜nas de los usuarios . . . 102

5. Conclusiones 105 5.1. Logros alcanzados . . . 106

5.2. Conocimientos adquiridos . . . 107

5.3. Trabajo futuro . . . 108

A. Scripts de Instalación Automática I A.1. Fichero de preconfiguración genérico . . . ii

A.2. Configuraci´on Isolinux . . . v

A.3. Fichero de configuraci´on del servidor dhcp . . . vi

B. Scripts adicionales IX B.1. Scripts de copias de seguridad . . . x

B.1.1. De lechuzo a sapientin . . . x

B.1.2. De bilo a nano . . . x

B.1.3. De sapientin al disco USB . . . xi

B.1.4. De nano al disco USB . . . xi

B.2. Script de copia de seguridad del directorio LDAP . . . xii

B.3. Auditor´ıa de usuarios . . . xii

B.3.1. Creaci´on de la base de datos . . . xii

B.3.2. Inserci´on de los datos de auditor´ıa . . . xii

B.4. Scripts ssh-a-todos y scp-a-todos . . . xiii

B.4.1. Scripts ssh-a-todos . . . xiii

B.4.2. Scripts scp-a-todos . . . xiv

(11)

C. Ficheros de configuraci´on XXI

C.1. M´aquinas zipi y zape . . . xxii

C.1.1. Servidor LDAP. Fichero slapd.conf . . . xxii

C.1.2. Servidor DNS. Fichero named.conf y db.pantuflo.es para zipi . . . xxiv

C.1.3. Servidor DNS. Fichero named.conf para zape . . . xxxi

C.2. M´aquina pantuflo . . . xxxii

C.2.1. Fichero de configuraci´on de Apache . . . xxxii

C.2.2. Fichero de configuraci´on de Postfix . . . xxxv

C.2.3. Fichero de configuración de Dovecot . . . xxxviii C.3. Máquina lechuzo . . . li C.4. Máquina peloto . . . lii C.5. Máquina sapientin . . . lv C.6. Máquina minervo . . . lv C.7. Máquina espatula . . . lv C.8. Máquina bilo . . . lv C.8.1. Servicio NFS en bilo . . . lvi C.9. Máquina nano . . . lvi

(12)

(13)

´Indice de figuras

1.1. Interfaz web de Zabbix. Fuente: Wikipedia . . . 23

1.2. Representación del uso de memoria en una máquina a través de Munin. Fuente: Wikipedia . . . 25

4.1. El proceso de instalaci´on en Debian/Ubuntu y la preconfiguraci´on de paquetes. . . 50

4.2. La raiz del ´arbol LDAP contiene dos unidades organizativas principales: alumnos y profesores. . . 55

4.3. La unidad organizativa de alumnos se subdivide a su vez en otras dos: alumnos de M´ostoles y alumnos de Fuenlabrada. . . 55

4.4. La unidad organizativa de profesores contiene dos unidades organizativas que almacenan los objetos posixAccount y posixGroup. . . 56

4.5. La aplicaci´on wireshark muestra como se mandan los datos de autenticaci´on en claro entre cliente y servidor, con nuestro esquema actual. . . 60

4.6. Una vez establecida la conexión segura entre cliente y servidor LDAP resulta más dif´ıcil capturar datos de autenticación de usuarios. . . 62

4.7. Reparto de carga entre varios servidores LDAP. . . 63

4.8. La aplicaci´on PHPLdapAdmin sobre nuestro esquema de servidores. . . 68

4.9. P´agina principal del Laboratorio de M´ostoles . . . 78

4.10. Autenticaci´on en la p´agina del Laboratorio mediante el directorio LDAP. . . 80

4.11. Webmail de pantuflo . . . 86

4.12. Webmail de bilo . . . 87

4.13. Gesti´on de listas de correo en pantuflo con Mailman. . . 87

4.14. La p´agina de resumen de estado de Nagios para el Laboratorio de M´ostoles. . . 93

4.15. La p´agina de problemas de Nagios muestra los problemas en algunas m´aquinas. . . 93

4.16. El parte de guerra de M´ostoles muestra el estado de las estaciones. . . 94

(14)

(15)

Indice de Listados

4.1. Generación de un CD personalizado de Ubuntu para instalación automática . . . . 43

4.2. Instalaci´on del paquete dhcp a trav´es de apt-get . . . 43

4.3. Fichero de configuraci´on dpchd.conf. Configuraci´on de subred. . . 44

4.4. Fichero de configuraci´on dpchd.conf. Configuraci´on de host. . . 44

4.5. Instalaci´on del servicio tfptd-hpa a trav´es de apt-get . . . 45

4.6. Fichero de configuraci´on /etc/default/tfptd-hpa. . . 45

4.7. Reinicio del demonio tftp . . . 45

4.8. Descarga del kernel de arranque por red de Ubuntu Hardy . . . 46

4.9. Fichero de configuraci´on de Isolinux . . . 46

4.10. Fichero de configuraci´on de Isolinux . . . 47

4.11. El fichero de preconfiguraci´on preseed.cfg. . . 47

4.19. Instalaci´on del paquete slapd a trav´es de apt-get . . . 51

4.20. El fichero de plantilla de debconf para el paquete slapd. . . 51

4.21. Preconfigurando el paquete slapd. . . 51

4.22. Instalaci´on del paquete slapd a trav´es de apt-get . . . 52

4.23. Instalaci´on de las bibliotecas necesarias para la autenticaci´on PAM v´ıa LDAP . . . 56

4.24. Contenido del fichero nsswitch.conf para autenticaci´on v´ıa LDAP . . . 57

4.25. Contenido del fichero pam ldap.conf para autenticaci´on v´ıa LDAP . . . 57

4.26. Contenido del fichero libnss-ldap.conf para autenticaci´on v´ıa LDAP . . . 57

4.27. Instalaci´on del conjunto de herramientas migrationtools a trav´es de apt-get . . 58

4.28. Modificando registros en el ´arbol LDAP usando ldapadd . . . 58

4.29. Instalaci´on del paquete openssl a trav´es de apt-get . . . 60

4.30. Creaci´on de un certificado para nuestro servidor LDAP . . . 60

4.31. L´ıneas necesarias para proporcionar soporte SSL al servidor LDAP . . . 61

4.33. Reinicio del demonio slapd . . . 61

4.36. Instalaci´on del demonio slurpd con apt-get . . . 65

4.37. A˜nadiendo replicaci´on a nuestro servidor LDAP . . . 65 xv

(16)

INDICE DE LISTADOS INDICE DE LISTADOS

4.38. A˜nadiendo replicaci´on a nuestro servidor LDAP . . . 66

4.39. Copia de Seguridad de los datos del servidor LDAP . . . 67

4.40. L´ınea de cron para automatizar las copias de seguridad de LDAP . . . 67

4.41. Modificando la contrase˜na de un usuario usando ldappasswd . . . 69

4.42. Instalaci´on del servidor NFS a trav´es de apt-get . . . 70

4.43. Instalaci´on del gestor de raid mdadm usando apt-get . . . 71

4.44. Automatizaci´on en la creaci´on del raid . . . 72

4.45. Automatizaci´on en la creaci´on del RAID . . . 72

4.46. Instalaci´on de Apache y del m´odulo PHP5 para el servidor . . . 75

4.47. Instalaci´on del servidor Apache2 y del m´odulo WebDav/Subversion para el servidor . . . 75

4.48. Creaci´on de un host virtual en Apache para el host pantuflo.escet.urjc.es . . . . 76

4.49. Descarga e Instalaci´on de la herramienta MediaWiki . . . 77

4.50. Configuraci´on de MediaWiki para autenticar usuarios usando LDAP . . . 79

4.51. Configuraci´on de Apache para dar soporte a p´aginas personales de usuarios . . . . 81

4.52. Instalaci´on de la herramienta postfix usando apt-get . . . 82

4.53. Instalaci´on de los demonios necesarios para dar soporte POP3 e IMAP a pantuflo 83 4.54. Reiniciando el demonio dovecot tras su reconfiguraci´on . . . 84

4.55. Instalaci´on de mailman usando apt-get . . . 88

4.56. Creaci´on de una nueva lista de mailman usando el comando newlist . . . 88

4.57. Instalaci´on de la herramienta debmirror usando apt-get . . . 89

4.58. Descargando la r´eplica de Ubuntu usando el comando debmirror . . . 90

4.59. Descargando la r´eplica de Debian usando el comando debmirror . . . 90

4.60. Contenido del fichero /etc/apt/sources.list usando la r´eplica del Laboratorio . . 90

4.61. Instalaci´on de la herramienta Nagios con apt-get . . . 91

4.62. Instalaci´on de la herramienta Munin (servidor) con apt-get . . . 93

4.63. Instalaci´on de la herramienta Munin (cliente) con apt-get . . . 94

4.64. Instalaci´on de la herramienta Munin (cliente) con apt-get . . . 94

4.65. Creaci´on de una tabla en MySQL para almacenar la informaci´on relativa a auditor´ıa de usuarios . . . 98

4.66. Script b´asico para registrar informaci´on de auditor´ıa de usuarios . . . 98

4.67. L´ınea de cron para la automatizaci´on de la auditor´ıa de usuarios en el sistema . . . 99

4.68. Monitor de alerta de conexiones nocturnas en el laboratorio . . . 99

4.69. Intentos de ataque de SSH mediante fuerza bruta o diccionario . . . 100

4.70. Instalaci´on de la herramienta Denyhosts . . . 101

A.1. El fichero de preconfiguraci´on necesario para la instalaci´on desatendida. . . ii

A.2. Fichero de configuraci´on de Isolinux para el arranque por red. . . v

A.3. Fichero de configuraci´on de Isolinux para el arranque por red. . . vi

B.1. Script backup-sapientin.sh . . . x

B.2. Script backup-nano . . . x

B.3. Script backup-usb.sh . . . xi

B.4. Script backup-usb.sh . . . xi

B.5. Script backup-ldap.sh . . . xii

B.6. Creaci´on de la base de datos de Auditor´ıa . . . xii

B.7. Script who-mostoles.sh . . . xii

B.8. Script sshatodos-alphas.sh . . . xiii

B.9. Script sshatodos-betas.sh . . . xiii

B.10.Script sshatodos-gammas.sh . . . xiii

(17)

B.12.Script sshatodos.sh . . . xiv

B.13.Script scpatodos-alphas.sh . . . xiv

B.14.Script scpatodos-betas.sh . . . xiv

B.15.Script scpatodos-gammas.sh . . . xiv

B.16.Script scpatodos-deltas.sh . . . xiv

B.17.Script scpatodos.sh . . . xv

B.18.Script john-laboratorio-mostoles . . . xv

B.19.Script john-laboratorio-fuenla . . . xviii

C.1. Fichero de configuraci´on /etc/ldap/slapd.conf . . . xxii

C.2. Fichero de configuraci´on /etc/bind9/named.conf . . . xxiv

C.3. Fichero de configuraci´on /etc/bind9/db.pantuflo.es . . . xxvi

C.4. Fichero de configuraci´on /etc/bind9/named.conf . . . xxxi

C.5. Fichero de configuraci´on /etc/apache2/sites-enabled/pantuflo.es . . . xxxii

C.6. Fichero de configuraci´on /etc/apache2/sites-enabled/pantuflo.escet.urjc.es . xxxii C.7. Fichero de configuraci´on /etc/apache2/sites-enabled/webmail.pantuflo.es . . xxxiv

C.8. Fichero de configuraci´on /etc/apache2/sites-enabled/mysql.pantuflo.es . . . xxxiv

C.9. Fichero de configuraci´on /etc/postfix/main.cf . . . xxxv

C.10.Fichero de configuraci´on /etc/postfix/master.cf . . . xxxvi

C.11.Fichero de configuración /etc/dovecot/dovecot.conf . . . xxxviii C.12.Fichero de configuración /etc/exports . . . li C.13.Fichero de configuración /etc/postfix/master.cf . . . lii C.14.Fichero de configuración /etc/exports . . . lvi

(18)

(19)

Licencia de este documento

El presente documento se distribuye bajo la licencia Creative Commons -Reconocimiento no comercial - compartir bajo la misma licencia 2.5, cuyos t´erminos pueden encontrarse en el Web1

. La presente licencia, le otorga permiso para: Copiar, distribuir y publicar libremente la obra

Hacer obras derivadas

Bajo las condiciones siguientes:

Reconocimiento: Debe reconocer los cr´editos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).

No comercial. No puede utilizar esta obra para fines comerciales.

Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

1

http://creativecommons.org/licenses/by-nc-sa/2.5/es/

(20)

(21)

Cap´ıtulo

1

Introducci´

on

El primer cap´ıtulo de este documento resume la motivación inicial de la realización de este proyecto (el porqué se lleva a cabo), as´ı como la estructura principal del presente documento. Posteriormente, se procede a enumerar cada una de las tecnolog´ıas que se utilizan en el proyecto, incluyendo todas las alternativas que exist´ıan para cada una de ellas (en el apartado Estado del arte). Este cap´ıtulo es meramente introductorio al proyecto desarrollado, dejando los detalles de los objetivos a desarrollar y la implementación de los mismos para cap´ıtulos posteriores.

(22)

1.1. MOTIVACI ´ON DEL PROYECTO

1.1. Motivaci´

on del proyecto

El presente documento resume casi toda la actividad realizada en un plazo de un a˜no aproximadamente como administrador de sistemas de los Laboratorios de Linux de la ETSII1

y la ETSIT2

, en los Campus de Móstoles y Fuenlabrada, de la Universidad Rey Juan Carlos. Durante el desarrollo de este trabajo, se han completado una serie de hitos que si bien pertenecen al trabajo diario y normal de cualquier administrador de sistemas, puede adaptarse bastante bien a la realización de un Proyecto Fin de Carrera de una Ingenier´ıa Informática, debido a que el desarrollo diario del trabajo ha sido dividido en fases, al igual que un proyecto: elaborar una lista y analizar las diferentes alternativas para cada uno de los objetivos, construir una lista de objetivos a desarrollar en un plazo determinado de tiempo, establecer un diseño conveniente y escalable, y por último, implementar o implantar poco a poco cada uno de los objetivos propuestos.

Por supuesto, un año da para mucho, para bastante más que para los hitos que se documentan en la presente memoria. Sin embargo, debido a limitaciones de espacio, nos vemos obligados a documentar lo estrictamente necesario y lo más fundamental.

1.2. Estructura de este documento

En esta sección se indica la división en cap´ıtulos del presente documento, en los cuales se realizará un análisis de cada una de las fases por las cuales ha avanzado el proyecto. Este documento se encuentra dividido en cinco cap´ıtulos, a saber:

El cap´ıtulo de Introducción, en el cual se presentan cuál es la motivación del proyecto y el estado del arte de cada una de las tecnolog´ıas que se han usado en el proyecto.

El cap´ıtulo de Objetivos, en el cual se presentar´an los objetivos principales que se han de desarrollar en el proyecto.

El cap´ıtulo de Dise˜no,

El cap´ıtulo de Implantaci´on, en el cual se implementan cada uno de los requisitos de los que consta el proyecto.

El cap´ıtulo de Conclusiones, en el que se realiza un an´alisis de todos los hitos alcanzados, los conocimientos adquiridos y todo el trabajo futuro que podr´ıa realizarse para mejorar o terminar de perfilar el trabajo realizado.

Por último, en los Apéndices del presente documento, se incluye el código fuente (entiéndase por código fuente en este proyecto todos aquellos ficheros de configuración y scripts de shell que se han desarrollado) desarrollado en el proyecto.

Junto con el presente documento se adjunta un soporte electr´onico en CD en el que puede encontrarse la presente memoria as´ı como todo el c´odigo fuente desarrollado en el proyecto.

1.3. Estado del arte

En este apartado vamos a analizar todas aquellas tecnolog´ıas que vamos a tocar en este proyecto. En este proyecto de hecho, van a ser muchas las tecnolog´ıas, aplicaciones, servidores y servicios que se van a facilitar a los usuarios de nuestro sistema. Como ser´ıa pr´acticamente

1

Escuela Superior de Ingenier´ıa Inform´atica

2

(23)

CAP´ITULO 1. INTRODUCCI ´ON

imposible realizar un análisis del estado del arte de cada una de ellas, nos vamos a centrar solamente en realizar un breve análisis de los sistemas de instalaciones desatendidos, por un lado, ya que uno de nuestros objetivos primordiales (el que nos llevará más tiempo) será la implementación de un sistema de instalaciones completamente desatendido que nos haga olvidarnos del tedioso proceso de tener que instalar aproximadamente 200 estaciones de usuario. Evidentemente para ello, partimos de la base que estas instalaciones se realizan de sistemas Linux, y no hemos ca´ıdo en la cuenta que hoy en d´ıa existen multitud de distribuciones que ofrecen este grandioso sistema operativo listo para su instalación. Aunque son pocas las distribuciones que tienen más fama hoy en d´ıa, será necesario enumerar las bondades y defectos de las más conocidas (principalmente, Debian GNU/Linux, Ubuntu, Red Hat Linux y SuSE). Por último, y dado que nuestro sistema albergará un gran número de cuentas de usuario, será tarea obligada decidir acerca de qué sistema de cuentas de usuario en red es más adecuado para nuestras necesidades, y por supuesto, dotar a este sistema de cuentas de un mecanismo de almacenamiento de ficheros adecuado (obviamente, si tenemos un sistema de cuentas en red, el medio de almacenamiento de información deberá estar en red también).

Por último, y para no extendernos demasiado, realizaremos un breve análisis de las aplicaciones que dotan de funcionalidad de correo electrónico a nuestro sistema (tanto de recogida como de entrega). De esta manera dotaremos a nuestro entorno con la funcionalidad de que los usuarios sean capaces de recibir correo electrónico en sus cuentas, y éstos también sean capaces de poder descargar este correo en sus ordenadores personales. Una vez que todos estos sistemas se encuentran perfectamente configurados y funcionando, nuestra labor se centrará en la monitorización de todos estos servicios. Para ello, instalaremos una herramienta de monitorización que de cuenta cuando se produce cualquier tipo de problema o ca´ıda de un servicio concreto, alertando a las personas oportunas. Estos herramientas serán discutidas en el apartado Herramientas de monitorización.

1.3.1. Distribuciones de Linux

En primer lugar, vamos a realizar un breve repaso por las distribuciones de Linux más usadas hoy en d´ıa. Cuando hablamos de Linux, en el sentido más general de la palabra, nos referimos al kernel o núcleo del Sistema Operativo. El kernel de Linux es el mismo para todas las distribuciones (normalmente, m´ınimamente modificado por la distribución) y puede ser descargado de forma independiente desde Internet3

e instalado en cualquier distribución sin muchas dificultades. Cuando hablamos de distribución de Linux nos referimos al conjunto formado por el kernel, las aplicaciones (que incluya de forma opcional el equipo desarrollador de la distribución en concreto) junto con un proceso de instalación. En este sentido, hoy en d´ıa hay miles de distribuciones de Linux4

que son usadas por millones de usuarios alrededor del mundo. Sin embargo, hay algunas que merecen especial atención, y que están clasificadas como las más usadas o más populares hoy en d´ıa. En esta clasificación, se encuentran Red Hat Linux, SuSE o Debian GNU/Linux. Según podemos comprobar en el cuadro 1.1, la distribución más usada hoy en d´ıa es Debian (18.84 %), seguida por Ubuntu (16.43 %), SuSE (9.32 %), Slackware (8.35 %) y gentoo (8.07 %), entre otras. Se omite en este resultado el indicado por otras distribuciones mostrado en la tabla.

Es necesario indicar que las estad´ısticas de uso por distribuciones mostradas en la tabla 1.1 se realizan a partir de los usuarios registrados en el sitio del cual se ha obtenido la estad´ıstica. La tabla 1.2 muestra su estad´ıstica particular sobre las diez distribuciones m´as usadas (en el

3

http://www.kernel.org

4

http://distrowatch.com/index.php?language=ES

(24)

1.3. ESTADO DEL ARTE Distribuci´on Uso CentOS 0.98 % Kubuntu 1.50 % Mandriva 2.01 % Mandrake 4.27 % Red Hat 6.70 % Fedora Core 6.93 % Gentoo 8.07 % Slackware 8.35 % SuSE 9.32 % Ubuntu 16.43 % Debian GNU/Linux 18.84 % Others 18.80 %

Cuadro 1.1: Distribuciones más usadas en la actualidad. Fuente: LinuxCounter Distribución Número de visitas último mes

Ubuntu 1944 openSUSE 1557 Mint 1351 PCLinuxOS 1053 Fedora 1036 Debian 923 Sabayon 853 Mandriva 776 CentOS 629 Gentoo 611

Cuadro 1.2: Distribuciones m´as usadas en la actualidad. Fuente: DistroWatch ´

ultimo mes), colocando tambi´en a Ubuntu y Debian entre los primeros puestos. En este caso se han obtenido los datos del portal DistroWatch5

. Como vemos, las distribuciones mayoritarias son Debian GNU/Linux y Ubuntu, seguidas muy de cerca por SuSE, Gentoo y Fedora, entre otras. La decadencia de Red Hat en los últimos años queda presente en la estad´ıstica. La distribución que hace años ocupaba los primeros puestos de uso entre los usuarios ha visto comido su terreno a favor de Ubuntu y SuSE. Quizá los cambios en la organización interna de Red Hat (que veremos a continuación) y la aparición de Ubuntu tuvo como precio la pérdida de un gran número de usuarios.

En definitiva, existen multitud de distribuciones hoy en d´ıa, de las cuales sólo unas cuantas alcanzan los primeros puestos en número de usuarios y en popularidad. En concreto, en los Laboratorios de Linux de la Universidad se ha usado Debian GNU/Linux desde que comenzó su andadura, hasta hace poco tiempo, que se tomó la decisión de pasar a Ubuntu.

A continuación vamos a realizar un breve repaso por las distribuciones más usadas o más populares. En concreto, Debian GNU/Linux, como distribución que usaremos en aquellas máquinas que presten su función de servidor. A continuación, Ubuntu, distribución que usaremos en las estaciones de trabajo de los laboratorios. Por último, detallaremos las razones que nos llevan a descartar otras distribuciones como solución adoptada tanto en los servidores de los laboratorios como en las estaciones, haciendo hincapié principalmente en las desventajas, ya que

5

(25)

son propuestas que en un principio se decide descartar. Debian GNU/Linux

El proyecto Debian surge aproximadamente en el año 1993, de la mano de Ian Murdock como l´ıder del proyecto, y con un objetivo principal: crear una distribución de Linux que separara claramente el software libre del no libre. Además, el modelo de desarrollo de la distribución es completamente ajeno a objetivos empresariales o comerciales, dejando de la mano de los usuarios de la misma la liberación de las versiones de la distribución.

En principio, la adaptación de Debian más conocida y más desarrollada hasta la fecha es la que se basa en el núcleo Linux, comúnmente llamada Debian GNU/Linux, aunque existen otras ramas de desarrollo basadas en otros núcleos, como Hurd, NetBSD o FreeBSD. El proyecto Debian se rige por unas directrices muy estrictas en cuanto a la organización del mismo: un contrato social establece cual es la base del proyecto y como sus usuarios deben tratar la mayor´ıa de los asuntos, unas directrices de software establecen qué software es adecuado o no para la distribución, as´ı como la Constitución de Debian establece cual es la jerarqu´ıa interna de la organización y como se llevan a cabo y se toman las decisiones principales. Estas normas establecen cuales son los poderes principales del l´ıder del proyecto (el que esté vigente en ese momento) y las responsabilidades de los desarrolladores en general.

Existe una figura visible dentro de la organización, el l´ıder de la misma. Esta figura es elegida por los propios integrantes de la comunidad Debian (principalmente, desarrolladores) y aunque tiene unas atribuciones principales más allá de las de cualquier desarrollador, está lejos de ser una decisión absoluta que tengan que acatar el resto de desarrolladores. El l´ıder de la comunidad se elige una vez al año, siendo el primero Ian Murdock (año 1993-1996) y el último (l´ıder actual) Steve McIntyre (abril 2008-hoy).

Respecto a los detalles técnicos, cabe reseñar que Debian ha conseguido su fama en los últimos años, cuando el número de arquitecturas soportadas se ha elevado considerablemente en los ´

ultimos años, as´ı como el número de paquetes incluido por defecto dentro de la distribución. Actualmente, son soportadas 11 arquitecturas diferentes de hardware en Debian GNU/Linux, y el número de paquetes se eleva por encima de 18.000. Actualmente, la distribución se encuentra en la versión 4.0 de manera estable (última versión estable liberada), cuyo nombre en clave se denomina Etch. Como curiosidad, los nombres de liberación de las versiones de Debian hacen alusión a personajes de la trilog´ıa de Disney/Pixar Toy Story, asignándose un nuevo nombre cuando se crea una nueva versión de pruebas.

La organización de desarrollo de Debian se divide en tres ramas de desarrollo principales: la rama estable, la cual es fruto de la congelación de una rama en pruebas (llega un momento que la estabilidad alcanzada en la rama en pruebas supone que no se añadan ni nuevos paquetes ni nueva funcionalidad a la correspondiente rama, creando una nueva versión de la distribución); la rama de pruebas o testing, la cual se compone de todos los paquetes que han ido reduciendo su número de fallos provenientes de la rama inestable. Por último, la rama inestable, comprende el desarrrollo activo y principal de la distribución. En ella se encuentran los paquetes recién añadidos a la distribución donde se comprueba su estabilidad, el número de fallos y la integración con el resto de paquetes de la distribución. En particular y respecto a las diferentes ramas de desarrollo de la distribución, siempre se recomienda el uso de la rama estable para uso en producción (debido a la estabilidad y al nivel de depuración que ha alcanzado esta versión) y al uso de la rama inestable si se quiere estar más al d´ıa en cuanto a versiones de un paquete en concreto, incluido dentro de la distribución. Sin embargo, usar la rama inestable puede convertirse en un juego peligroso, ya que de un d´ıa para otro nuestro ordenador puede dejar de funcionar o puede producirse un problema grave que puede acabar en una reinstalación si no se tienen los conocimientos necesarios para solucionar el problema y volver a la situación original. Los usuarios avanzados de Debian

(26)

1.3. ESTADO DEL ARTE

conocen esta situaci´on y normalmente, siempre que su distribuci´on se encuentra situada en la rama inestable, suelen tener mucho cuidado con las actualizaciones o instalaciones de paquetes nuevos.

Existe dos ventajas principales de la distribución Debian GNU/Linux sobre la mayor´ıa de distribuciones más usadas hoy en d´ıa. La principal, es la estabilidad de la rama estable de la distribución. La independencia de Debian frente a intereses comerciales hacen que los tiempos de liberación de la distribución sean lo suficientemente grandes como para que de tiempo a que la distribución sea revisada todo lo necesario como para que tenga un nivel de calidad más que aceptable. Estos tiempos, de un año normalmente (como m´ınimo) son excesivos para usuarios que desean tener su software al d´ıa: última versión de escritorio, última versión del servidor web Apache, etcétera. Sin embargo, estos usuarios deben saber que la rama de desarrollo de Debian que están usando no es la más adecuada para ellos, ya que los tiempos de liberación tan grandes facilitan que la distribución sea una de las más estables y seguras frente a otras más conocidas, en detrimento de usar las versiones más actuales y novedosas en lo que a software se refiere. Es por ello que la rama estable de Debian GNU/Linux ha sido relegada al plano del servidor principalmente, dejando otras ramas para el escritorio y el uso menos profesional del equipo en cuestión. La otra ventaja que nos ocupa es la herramienta de instalación de software, la herramienta apt6

. Esta herramienta, muy conocida entre los usuarios de la distribución y todas aquellas que se apoyan en ésta (Knoppix, Ubuntu y demás) facilita enormemente la instalación, configuración y eliminación de software en Debian (y en todas aquellas distribuciones Linux que lo hayan acogido como herramienta de instalación de software). En principio, esta herramienta funciona en l´ınea de comandos, aunque ha medida que ha pasado el tiempo se han diseñado interfaces únicos o front-ends que facilitan el uso de la herramienta para usuarios noveles7

. La herramienta apt es capaz de funcionar con repositorios de software a lo largo de Internet, facilitando as´ı la labor de localización de software adicional. De forma oficial, existen repositorios oficiales para Debian que contienen los paquetes incluidos en la distribución en cada una de las ramas. Para que este sistema sea escalable, estos repositorios se encuentran replicados a lo largo del mundo en mirrors o espejos locales distribuidos en cada región del planeta. Es común que cada Universidad cuente con el suyo propio (como es el caso de la nuestra). Además, es posible que los usuarios construyan o creen sus propios repositorios con aquellos paquetes que hayan construido particularmente con las aplicaciones que ellos hayan considerado oportuno. El resto de usuarios del planeta puede instalar esas aplicaciones sin más que indicar a la herramienta apt cual es la localización del recurso del correspondiente repositorio (normalmente, a través de una URL común). El uso de apt es casi una herramienta fundamental en el uso diario del sistema, facilitando la tarea de instalación de software enormemente, tanto al administrador como al usuario de a pié. Tanto, que hoy en d´ıa, la instalación de software en sistemas Linux a través de los fuentes (usando el código fuente, compilándolo de forma manual) a quedado relegada a un plano muy lejano y casi ya no es usada por los usuarios, tanto por la incomodidad de este método como por el número de errores que normalmente se suelen producir.

Es por ello que realizamos la elección de Debian GNU/Linux como sistema base para nuestros servidores: la estabilidad de la distribución en su rama estable para sistemas en producción hace que nos decantemos por esta opción, dejando para el escritorio distribuciones que se apoyen en Debian (principalmente, por la estabilidad y las herramientas de instalación de software) pero que incluyan software más actual de cara al usuario.

Con el paso del tiempo han sido muchas las distribuciones que han surgido tomando Debian GNU/Linux como distribución base. La estabilidad y la organización de la distribución hace que muchas distribuciones adopten o partan de ella para crear nuevas distribuciones. Las más

6

APT son las siglas de Advanced Packaging Tool o Herramienta de empaquetamiento avanzado.

7

(27)

conocidas, Knoppix o Ubuntu, que comentaremos a continuaci´on.

Ubuntu Ubuntu8

es una de las distribuciones cuyo cociente entre tiempo y popularidad ha sido más pronunciado. Basada en Debian GNU/Linux como distribución base, ha ido desplazando a los usuarios más confesos y acérrimos a la distribución base hasta Ubuntu como sistema principal de escritorio basado en Linux. Los pilares ideológicos principales en los que se basa Ubuntu son la facilidad y usabilidad a la hora de usar el sistema operativo, as´ı como la regularidad en la liberación de nuevas versiones (normalmente, cada seis meses, en Abril y en Octubre). Está desarrollada por Canonical, apoyada por el empresario sudafricano Mark Shuttleworth.

El proyecto surgió en el año 2004 aproximadamente, con una financiación de unos diez millones de dólares. En la distribución participan muchos desarrolladores de Debian y de Gnome, estos primeros decepcionados con el modo de funcionamiento interno de la distribución Debian, por aquel entonces una de las más usadas, tanto en el escritorio como en el servidor. Estos desarrolladores buscaron apoyo en el empresario Mark Shuttleworth, que apreció la idea del proyecto y lo apoyó económicamente. Tras varios meses de trabajo y un breve per´ıodo de pruebas, la primera versión de Ubuntu (Warty Warthog) fue lanzada el 20 de octubre de 2004.

Como detalles técnicos relevantes, podemos destacar que Ubuntu conserva la mayor´ıa de las ventajas de Debian GNU/Linux, manteniendo como principal la herramienta de instalación de software apt. Además, los periodos de liberación de Ubuntu son bastante más cortos, lo que hace que las versiones que se incluyen en la distribución sean bastante actuales. Normalmente, Ubuntu suele incluir la última versión de los escritorios Gnome y KDE (sino la última, una de las más actuales) as´ı como las últimas versiones de los paquetes de software más importantes. Ubuntu no soporta tanto arquitecturas como Debian: se incluyen de manera oficial soporte para dos arquitecturas: Intel x86 y AMD64, sin embargo ha sido portada a más plataformas de forma extraoficial, la descontinuada PowerPC, Sparc, o incluso la plataforma de videojuegos PlayStation 3 creada por Sony.

Ubuntu es una de las distribuciones que incluye un CD Live!, que facilita que el usuario pueda probar la distribuci´on sin necesidad de realizar una instalaci´on en el disco. Esta funcionalidad es bastante interesante para poder introducir nuevos usuarios en Linux sin necesidad de realizar nuevas instalaciones en sus sistemas.

Una de las principales ventajas que hacen que nos decantemos por Ubuntu como sistema usado en las estaciones del Laboratorio es que, aparte de ser una distribución basada en Debian (incluyendo todas sus ventajas, como apt), se incluyen las versiones más actuales de software en cada liberación, de forma que de cara a los usuarios disponemos de un sistema totalmente actual, no como pasaba anteriormente cuando las estaciones del Laboratorio se basaban en Debian GNU/Linux: los periodos de liberación tan largos hac´ıan que una vez liberada la versión estable, las versiones de escritorio, aplicaciones y demás estuvieran totalmente desactualizadas.

Ubuntu al igual que Debian, ha servido como base para otras distribuciones: xUbuntu, kUbuntu o Edubuntu son distribuciones muy usadas en la actualidad y que están basadas en Ubuntu como distribución base (al igual que Ubuntu se apoya en Debian). Estas distribuciones normalmente contienen pocas variaciones con respecto a la original, centrándose normalmente en las aplicaciones incluidas o en el escritorio por defecto que se usa en cada una de ellas.

8

http://www.ubuntulinux.org

(28)

SuSE

La distribuci´on SuSE9

es una de las distribuciones Linux más conocidas y más usadas en la actualidad. Está basada en la distribución Slackware y entre las principales ventajas o virtudes de esta distribución está la facilidad de instalación de la misma (contaba con un instalador gráfico hace bastante tiempo, cuando ninguna de las distribuciones Linux lo sol´ıan incluir) y un administrador gráfico del equipo llamado Yast, el cual facilita la labor de instalación de nuevo software y la configuración del equipo. En la actualidad, SuSE es propiedad de Novell, desde que la absorbió en 2004. En el año 2005, en la LinuxWorld, Novell, siguiendo los pasos de RedHat Inc., anunció la liberación de la distribución SuSE Linux para que la comunidad fuera la encargada del desarrollo de esta distribución, que ahora se denomina openSUSE.

Como detalles técnicos, SuSE usa el escritorio KDE por omisión, aunque incluye también el escritorio Gnome. Como sistema de paquetes nativo, SuSE usa el sistema de paquetes RPM (Red Hat Package Manager), que es el sistema de paquetes que se incluye en la distribución Red Hat/Fedora. Sin embargo, los cambios que ha sufrido esta distribución a lo largo del tiempo as´ı como el sistema de gestión de paquetes que usa (RPM) hace que descartemos esta distribución para ser usada en nuestro entorno.

Red Hat/Fedora Core

Por último, realizaremos un breve análisis de otra de las distribuciones más conocidas en la actualidad. La distribución Red Hat10

, posteriormente Fedora, ha sido una de las distribuciones que más reconocimiento ha tenido en los últimos tiempos. En principio, existen dos versiones principales de esta distribución: Red Hat Enterprise Linux, dirigida principalmente al mercado profesional, y Fedora Core, que surgió en el año 2003 cuando Red Hat Linux fue descontinuado. Digamos que esta división es similar a la sufrida por SuSE, que mantiene una versión comercial de su distribución (Novell SuSE Enterprise) y su versión gratuita, openSuSE. De forma similar, Red Hat ofrece su versión comercial (Red Hat Enterprise Linux) y su versión gratuita o libre (Fedora).

Red Hat Software Inc. fue fundada en el año 1994, y es conocida por aportar numerosas contribuciones y luchar en pro del software libre. En esos años la distribución contaba con gran número de usuarios y gran popularidad. Sin embargo, el paso de los años y la aparición de nuevas distribuciones con mayor estabilidad, mayor número de usuarios y de desarrolladores la ha relegado a un segundo plano, aunque sigue contando con un gran número de usuarios en la actualidad.

En cuanto al plano técnico no hay muchos detalles que comentar. Red Hat Linux al igual que SuSE usa el sistema de paquetes RPM, un sistema de paquetes un tanto antiguo en comparación con el sistema de paquetes apt. El sistema de paquetes es algo tan fundamental dentro de una distribución que es motivo de descartar esta distribución para su uso en el laboratorio al igual que SuSE.

1.3.2. Sistemas de instalaci´on desatendidos

Dado que uno de nuestros objetivos principales es diseñar un proceso de instalación desatendida y completamente automatizado, vamos a analizar los sistemas de instalación desatendidos más usados hoy en d´ıa por administradores de un número muy elevado de máquinas. En concreto y para el caso que nos ocupa, partimos de la base que necesitamos un método que nos permita instalar en 300 estaciones de usuario aproximadamente (160 en el Campus de Móstoles

9

http://es.opensuse.org/Bienvenidos a openSUSE.org

10

(29)

y 140 en el de Fuenlabrada) de la forma más rápida y cómoda posible, de cara al administrador de las estaciones y de las instalaciones masivas.

Clonaci´on de disco duro

La clonación de una partición del disco o del disco duro completo es hoy en d´ıa uno de los sistemas más usados a la hora de realizar instalaciones masivas, bien se trate de entornos docentes o de entornos empresariales, en los que se debe instalar una máquina réplica de una máquina inicial. Este sistema copia bit a bit todos los datos de una partición en un fichero para el posterior volcado a la inversa en otra partición o disco duro. Dependiendo de la aplicación con la que estemos realizando la clonación, este proceso será más o menos rápido, y nos permitirá una mayor flexibilidad a la hora de realizar la clonación.

Hoy en d´ıa, las aplicaciones m´as modernas que permiten realizar clonaciones de disco duro, permiten:

Lectura de sistemas de ficheros ext2/ext3 (aspecto fundamental en nuestro caso)

Compresión de los datos para que ocupen menos espacio. Los sistemas de clonación más antiguos requer´ıan un espacio en disco igual o mayor al del disco duro que se iba a clonar. Almacenamiento en red de los datos. La imagen del disco duro clonado pod´ıa almacenarse en un servidor FTP, o en un directorio compartido de Windows. Posteriormente, cuando se realizaba el proceso inverso, los datos pod´ıan ser descargados de estos servicios en red. Clonación de todo el disco duro o de una partición en concreto. Los sistemas más modernos permiten elegir entre clonar el disco duro al completo, o solamente una partición del disco. Rapidez de la clonación del disco duro o partición. Los sistemas más antiguos empleaban una gran cantidad de tiempo para realizar una clonación de un disco, con el consiguiente perjuicio para el administrador.

Hoy en d´ıa, existe un gran abanico de aplicaciones con diferentes licencias pensadas para realizar clonaciones de discos duros o particiones para realizar copias de seguridad de datos, realizar instalaciones masivas, etc´etera. Las aplicaciones comerciales m´as conocidas hoy en d´ıa pueden ser Acronis True Image11

o Norton Ghost12

. Ambas aplicaciones están disponibles a través de los servicios informáticos de Campus, con una licencia totalmente funcional para nuestras necesidades. Sin embargo, el balance total entre las ventajas y desventajas entre este método y el posteriormente elegido como método principal de instalación, hace que nos decantemos finalmente por el método basado en ficheros de preconfiguración. Existen otras aplicaciones con licencias libres que permiten realizar una clonación de disco duro. En el caso más básico, el comando dd permite leer una partición y guardarla en un fichero. Sin embargo, este método tan rudimentario adolece de ser muy lento, a parte de necesitar como m´ınimo el tamaño en disco de la partición para almacenar el fichero correspondiente.

Entre los dos aplicaciones comerciales presentadas anteriormente, cabe destacar como ventajas principales la rapidez y el poco espacio que ocupa la imagen de un disco duro de cualquiera de los equipos que deseemos clonar. Además, la aplicación Acronis True Image nos permite guardar las imágenes de los discos duros que deseemos en un servidor FTP, con las ventajas que ello supone: cuando deseemos instalar un equipo a partir de una imagen, solamente debemos arrancarlo con el CD de la aplicación, y seleccionar el servidor FTP donde se encuentran alojadas las imágenes del

11

http://www.acronis.com/homecomputing/products/trueimage/

12

http://www.symantec.com/es/mx/norton/ghost

(30)

equipo en cuestión. Este mecanismo puede resultar muy cómodo cuando el número de equipos que se desea instalar es muy bajo: pongamos, quince o veinte equipos, siendo generosos en la paciencia de la persona que vaya a ocuparse de las instalaciones. A mayor número de equipos, el proceso de instalación, puede resultar tedioso. En nuestro caso, disponiendo de 160 estaciones en el Campus de Móstoles y 140 en el Campus de Fuenlabrada, resulta prácticamente no asumible. Además de esta desventaja principal, hemos de añadir que las diferencias entre las estaciones principales del laboratorio supone que se deba almacenar una imagen por cada modelo de estación, ya que la clonación asume que ésta se realiza entre equipos idénticos. En nuestro caso, disponemos en Móstoles de 3 tipos principales de hardware en las estaciones de usuario y de tres tipos en el Campus de Fuenlabrada. Es por ello que decidimos plantearnos otros mecanismos de instalación desatendida para realizar nuestro proceso de instalación automática.

Sin embargo, el método de la clonación de disco nos vendrá muy bien cuando tengamos que arreglar un disco que ha sido reemplazado (por ejemplo, por un problema de hardware) o cuando tengamos que instalar pocas máquinas (una o dos) y el resto ya estén instaladas completamente. La razón de esta elección es que el método de la clonación es muy rápido, y no supone la puesta en marcha de infraestructura adicional (como es el caso de los ficheros de preconfiguración, que estudiaremos posteriormente).

En resumen, podr´ıamos decir que las ventajas y desventajas que aporta este método son: Como ventajas, el método de la clonación es rápido, sencillo y no requiere maquinaria adicional para ponerlo en marcha.

Como desventajas, podemos afirmar que este método puede ser complejo en caso de que el número de estaciones sea elevado, exige hardware idéntico (al menos para una sola clonación) y que realiza una instalación no limpia del sistema.

Ficheros de preconfiguraci´on

Por último, vamos a realizar un análisis del uso de ficheros de preconfiguración para realizar instalaciones masivas y completamente desatendidas. El método de los ficheros de preconfiguración (el término anglosajón es preseeds o ficheros semilla). Este método, que se encuentra disponible en Debian (y sus derivados) a partir de la versión de Sarge, consiste en incluir en un fichero de texto todas las indicaciones necesarias para la instalación de o bien un sistema Debian completo (fichero de preconfiguración para el proceso de instalación) o bien un paquete en concreto. A través de este método, conseguimos que todas las indicaciones o preguntas que el proceso de instalación realiza al usuario, sean introducidas automáticamente sin necesidad de la interacción del usuario en ningún momento en el proceso de instalación (siempre que todas las respuestas sean introducidas en el fichero correspondiente). El fichero de semilla o fichero preconfiguración es un fichero de texto legible por humanos, en el que se incluyen la preconfiguración de cada pregunta en un formato concreto. Este formato, si bien no es a priori puede resultar un tanto complejo, es bastante automático en cuanto a la forma de construir indicaciones para un proceso de instalación. Cada indicación se incluye en una l´ınea del fichero de texto, y contiene una especificación en la forma clave/valor para cada paquete a instalar, incluido el proceso de instalación (el proceso debian installer ).

Una de las ventajas principales de este método radica en que se puede automatizar todo el proceso de instalación al completo, sin más que responder o incluir todas las indicaciones en el fichero de preconfiguración correspondiente. Además, estaremos realizando una instalación limpia de un sistema (a diferencia del procedimiento de la clonación de una partición o del disco duro). Esta instalación sin duda es más conveniente para el sistema que replicar una instalación ya hecha. Por otra parte, los ficheros de preconfiguración son muy flexibles en el sentido que pueden

(31)

estar almacenados en un CD ya prefabricado (un CD de Debian en el que se ha modificado el arranque) o bien se pueden incluir en una memoria USB o incluso en la red, localizadas por una URL. Este método es especialmente potente y flexible, ya que facilita que el sistema pueda ser instalado completamente por la red, sin necesitar tan siquiera un CD de Debian para realizar la instalación. Solamente necesitaremos la imagen correspondiente del arranque por red de la versión correspondiente que queramos instalar (disponible en cualquiera de los mirrors de Debian) y unas pequeñas modificaciones en el arranque para que éste use un fichero de preconfiguración. Una vez hecho esto, tendremos un proceso de instalación que no necesita soporte de instalación (un CD, como tradicionalmente se ha instalado el Sistema Operativo) ni ninguna interacción con el usuario: tan sólo será necesario reiniciar el equipo y seleccionar arranque por red en la placa base para que el proceso comience, se instale correctamente y cuando haya finalizado el proceso, el equipo se reinicie y muestre el nuevo sistema al usuario. Como vemos, la idea es bastante atractiva: tan sólo requiere reiniciar el equipo para realizar una instalación.

En el cap´ıtulo Implantación veremos los detalles técnicos de este proceso, que si bien no requiere tan sólo de fichero de preconfiguración en cuestión (es necesario otras tecnolog´ıas paralelas, como arranque por red de Linux, puesta en marcha de un servidor que despache direcciones IP, etcétera) no es complicado en exceso. Podemos resumir que el proceso de instalación tiene las siguientes ventajas y desventajas principales:

Como ventaja, principalmente es la escasa interacción con el usuario que necesita (por no decir nula). La única acción que se requiere por parte del usuario es reiniciar el equipo para que comience la instalación (y esta acción no pertenece propiamente al proceso de instalación). La instalación del sistema es totalmente limpia (se formatea el disco duro, se crea la tabla de particiones, se instala el sistema completo partiendo de cero, se configuran todos los paquetes una vez éste se ha instalado, etcétera), lo cual es una ventaja con respecto al método de la clonación. Por último el poder realizar instalaciones por red es una ventaja bastante importante, en los tiempos en los que nos encontramos, en el que el uso de soportes de almacenamiento f´ısicos cada vez está menos extendido.

Como desventaja, podemos indicar que si bien este proceso es muy usado hoy en d´ıa por parte de administradores de sistemas, la documentación del método de preconfiguración es bastante escasa, por no decir nula. Si bien ya empiezan a existir proyectos de Debian dedicados únicamente a esta labor13

, hace un año aproximadamente resultaba bastante complicado encontrar recetas de instalaciones desatendidas usando ficheros de preconfiguración. También cabe reseñar que el método de ficheros de preconfiguración suele requerir la puesta en marcha y configuración de tecnolog´ıas paralelas que no tienen que ver mucho con el proceso de instalación, como veremos en el cap´ıtulo Implantación.

1.3.3. Sistemas de autenticaci´on de usuarios

Otro de los puntos que es necesario debatir es el diseño e implantación de un sistema de autenticación de usuarios, necesario para que los alumnos puedan iniciar su sesión en las estaciones del Laboratorio. En este sentido, será necesario analizar las tecnolog´ıas actuales que brindan un sistema de usuarios en red que proporcione la infraestructura necesaria para que una persona, en posesión de su nombre de usuario y contraseña pueda iniciar una sesión, independientemente del ordenador en el que se encuentre en ese momento (de ah´ı que sea un sistema de usuarios en red). En este sentido, vamos a estudiar tres sistemas de autenticación principales. El primero de ellos, es el más rudimentario, basándose en el sistema tradicional de ficheros /etc/passwd y /etc/shadow con replicación ante cambios.

13

http://sites.google.com/a/ibeentoubuntu.com/debian-preeseds/

(32)

En segundo lugar, estudiaremos los sistemas más avanzados para implementar un sistema de usuarios en red, y más usados hoy en d´ıa, sobre todo la segunda alternativa que planteamos, LDAP, un protocolo basado en directorio bastante ligero y que es una de las alternativas más usadas hoy en d´ıa ante este tipo de problemas.

Mapa de usuarios local con replicaci´on

La primera solución que nos planteamos es la implantación de un mecanismo de autenticación basado en un mapa de usuarios locales que se replique a lo largo de todas las máquinas que componen el laboratorio. El funcionamiento de este mecanismo por tanto, ser´ıa el funcionamiento clásico basado en los ficheros /etc/shadow y /etc/passwd superponiendo por encima un mecanismo que permita replicar estos ficheros en todas las estaciones que componen nuestro entorno.

Este mecanismo de replicación se puede llevar a cabo de muy diferentes maneras. Por ejemplo, implementando un monitor que sondee los cambios en ambos ficheros en una máquina concreta (en la que se producen los cambios, por ejemplo) y vaya propagando estos cambios entre aquellas máquinas interesadas. Esta replicación se puede llevar a cabo mediante una transmisión simple de ficheros usando SSH (usando el comando SCP, por ejemplo).

Otra decisión a tomar ser´ıa si los cambios lo solicitan los clientes, o es una única máquina la que propaga los cambios cuando estos se produzcan. En cualquier caso, estas decisiones pertenecen al mecanismo de propagación de cambios que este mecanismo incorporar´ıa. Lo fundamental de este mecanismo es comprender que los mecanismos para añadir y borrar usuarios, as´ı como cambiar una contraseña, por ejemplo, son los mismos que en un sistema Linux/Unix tradicional (al basarse en los ficheros tradicionales de usuarios de cualquier sistema Unix).

Sin embargo, este sistema adolece de muchos problemas para ser llevado a la práctica. Como desventaja principal, la escalabilidad del sistema, que se puede convertir en insostenible. Si el número de máquinas es relativamente alto, la propagación de cambios puede convertirse en un verdadero problema, cuando añadamos muchas cuentas en muy poco tiempo, o simplemente realicemos un cambio en los datos de los usuarios, a parte de convertirse en un cuello de botella. Además, si elegimos un diseño en el que solo se pudieran modificar datos en una sola máquina, nos deber´ıamos preguntar qué pasar´ıa si un usuario decide cambiar su contraseña (una acción bastante frecuente). ¿Deber´ıa iniciar una sesión en esa máquina y entonces cambiar la contraseña? ¿Deber´ıa poder cambiar la contraseña en la máquina en la que se encuentra, y que esta informara a la máquina maestra de que se ha producido un cambio? Como vemos, la acción más simple que puede darse en un esquema de cuentas en red, como cambiar una contraseña, puede convertirse en algo bastante complicado usando este esquema. Sin embargo, añadir y borrar cuentas, as´ı como cambiar una contraseña en la máquina maestra es extremadamente simple, usando directamente comandos del sistema para realizarlo (eso s´ı, siempre que sea el administrador el que realice estos cambios). Debido a que el número de pros es mayor a las ventajas que puede ofrecernos esta tecnolog´ıa, en principio decidimos estudiar otras alternativas para nuestro diseño de cuentas en red. Sin embargo y como reseña, cabe destacar las ventajas y desventajas de la citada tecnolog´ıa: Como ventaja, podemos decir que un sistema de usuarios locales con replicación o propagación de cambios es bastante simple para añadir y borrar usuarios, as´ı como para cambiar contraseñas, ya que siempre se usan los comandos estándar del sistema para esta labor (siempre y cuando los realice un administrador o un usuario con privilegios).

Como desventaja podr´ıamos destacar que se producen un gran problema de escalabilidad en este diseño, además de tener que diseñar un sistema completo de propagación de cambios que sea lo suficientemente bueno como para asumir el volumen de datos de cuentas que nos

(33)

proponemos. Adem´as, este dise˜no tiene serios problemas de concurrencia, que pueden darse cuando dos administradores realicen modificaciones en la cuenta de un usuario.

NIS

Las p´aginas amarillas NIS14

, también llamadas Sun Yellow Pages es una tecnolog´ıa de cuentas de usuario en red (aunque también puede ser usado para otros menesteres), desarrollada principalmente por Sun Microsystems en los años de los 90.

Esta tecnolog´ıa es la que inicialmente se usaba en los Laboratorios de Linux de la Universidad antes de evaluar soluciones m´as avanzadas de cara al aumento tanto de estaciones instaladas en los Laboratorios como de usuarios en posesi´on de una cuenta.

La tecnolog´ıa NIS se basa en llamadas RPC entre cliente y servidor para el intercambio de información sobre usuarios en sistemas distribuidos, tales como el que nos ocupa. El software que implementa tal funcionalidad se compone de un servidor, una biblioteca para el lado del cliente y varias herramientas de administración. En concreto NIS funciona de tal forma que la información contenida en los ficheros /etc/passwd, /etc/shadow y /etc/group se puede distribuir a lo largo de una LAN de tal forma que el efecto es como si los citados ficheros fueran locales a la máquina en la que nos encontramos. En cierto modo, el funcionamiento es muy similar a tener un fichero /etc/passwd, /etc/shadow locales, ya que las herramientas para añadir y borrar usuarios as´ı como cambiar una contraseña son las estándares de Unix, con la única excepción que ha de realizarse en el servidor que proporciona la información NIS. En el resto de hosts es necesario realizar llamadas RPC para realizar consultas sobre los datos de los usuarios.

En particular este esquema es bastante simple, y muy funcional: estuvo funcionando perfectamente durante aproximadamente 5 años en los Laboratorios sin muchos problemas. En cuanto a requerimientos técnicos, solamente se necesita un servidor que almacene la información de los usuarios, y conocimientos básicos de administración de usuarios en sistemas Unix. Con esto, es suficiente para poder construir un sistema de cuentas en red basado en NIS.

Sin embargo, hay dos problemas fundamentales para este esquema, que desarrollamos a continuaci´on:

La escalabilidad únicamente hay un servidor NIS de cuentas de usuario con todo lo que ello conlleva: protección ante fallos, cuellos de botella, etcétera. Sin embargo, cabe destacar que en los años que esta solución estuvo implantada en los Laboratorios, no se produjeron en ningún momento cuellos de botella significativos, ante un laboratorio de aproximadamente 90 estaciones de trabajo, lo que deducimos que se debe a lo ligero del protocolo, entre otras cosas. Por tanto, lo más preocupante es la protección ante fallos y ca´ıdas repentinas del servidor que puedan producirse en cualquier momento.

La seguridad de los datos en la red. Usando esta solución, los datos de los usuarios viajan en claro por la red, con todo lo que ello conlleva. La información relativa al nombre de usuario, directorio personal de los mismos viaja totalmente en claro, y las contraseñas de las cuentas viajan cifradas con un mecanismo de cifrado simétrico, con lo que el romper este cifrado es bastante sencillo. Hoy en d´ıa no podemos asumir que esto ocurra. Cualquier usuario malicioso que pueda ponerse entre medias de un cliente y del servidor NIS podrá captar datos de cualquier usuario del sistema. Se hace necesario por tanto añadir un mecanismo que cifre los datos de los usuarios cuando estos viajan entre cliente y servidor, mecanismo que a d´ıa de hoy no posee la tecnolog´ıa NIS de Sun.

14

NIS son las iniciales de Network Information Service

(34)

Por tanto, debido a estas principales desventajas y a ser un producto tecnol´ogicamente desfasado, nos vemos obligados a estudiar otras tecnolog´ıas para llevar a cabo el sistema de usuarios en red.

LDAP

Por último, nos planteamos el estudio de una solución basada en directorio, usando para ello el estándar LDAP15

. LDAP es una tecnolog´ıa de reciente aparición que gestiona un directorio en una base de datos que puede servir en principio para dar servicio a muy dispares aplicaciones, aunque sin duda, una de las más usadas hoy en d´ıa es la autenticación de usuarios ya sea en sistemas operativos tipo Unix (como el que nos ocupa) o máquinas Windows (a través de la creación de cuentas Samba).

En nuestro caso, solamente usaremos el directorio LDAP para la autenticación de usuarios en máquinas Unix. Aunque una vez puesto en marcha el servicio, se puede utilizar para muy diversos fines (aparte del descrito) como por ejemplo, la información de hosts en la red, o como servicio de libreta de direcciones. Como tal, LDAP es un estándar detallado como tal en la RFC16

correspondiente17

.

Habitualmente, un servidor LDAP almacena información de un usuario de la red, tal como su nombre de usuario y su contraseña, aunque puede incluir información adicional como nombre de la persona, ubicación f´ısica, foto personal, etcétera. En definitiva, podemos afirmar que LDAP es un protocolo de acceso unificado a un conjunto de información sobre una red.

En nuestro caso vamos a utilizar este servicio para almacenar la información de las cuentas de usuario del sistema, particularmente y como información fundamental, su nombre de usuario y contraseña. Aunque por supuesto, también será necesario almacenar otro tipo de información, como el nombre y apellidos del usuario en cuestión, correo electrónico, etcétera. La tecnolog´ıa LDAP como tal y dado a que únicamente describe un protocolo, es implementada por numerosas aplicaciones con muy diferentes licencias. Los gigantes informáticos han querido hacer suya esta tecnolog´ıa y han liberado aplicaciones que implementa de forma muy diferente (y con unos nombres muy diferentes) un servicio de directorio basado en LDAP. En concreto, Microsoft distribuye la aplicación Active Directory, bajo la cual se almacena información de usuarios, recursos de la red, pol´ıticas de seguridad, configuración, y asignación de permisos, entre otras cosas, en entornos de redes Windows. Ni que decir tiene que se trata de una solución comercial y por tanto, de pago, por lo que para nosotros queda descartada automáticamente, debido a la naturaleza del entorno en el que nos encontramos.

Otro producto muy similar es el liberado por Novell, Novell Directory Services. Esta aplicación es la implementación de Novell utilizada para manejar el acceso a recursos en diferentes servidores y computadoras de una red en la que se representan como objetos los servicios más usuales en una red, como una impresora, una estación, un servidor, un servicio, una persona, etcétera. Una vez definidos los objetos en la base de datos, se asignan los permisos para el control de acceso. Dado que esta solución también es una solución comercial, no nos planteamos abordarla en nuestros objetivos.

Por último, la aplicación OpenLDAP es una implementación del protocolo LDAP basada en el concepto de software libre desarrollada por el proyecto OpenLDAP, que comienza aproximadamente en el año 1998. Esta implementación del estándar LDAP, esta incluida en la mayor´ıa de distribuciones Linux más usadas hoy en d´ıa (por supuesto se encuentra en las basadas en Debian GNU/Linux, como Ubuntu). La implementación incluye un servidor (llamado slapd ),

15

LDAP son las siglas de Lightweight Directory Access Protocol o Protocolo ligero de acceso a directorio

16

RFC son las siglas de Request for comments y es un documento t´ecnico que describe el comportamiento de un protocolo de red.

17