Ingeniería Informática

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Ingeniería Informática"

Transcripción

1 Ingeniería Informática Escuela Técnica Superior de Ingeniería Informática Curso académico Proyecto Fin de Carrera INSTALACIÓN, CONFIGURACIÓN Y ADMINISTRACIÓN DE AULAS INFORMÁTICAS MEDIANTE SOFTWARE LIBRE Autor: Tutor: Antonio Gutiérrez Mayoral Jose Centeno González Septiembre 2008

2 ii

3 A mis padres y mi hermano

4 iv

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. v

6 vi

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ásicos para el funcionamiento del entorno, pero no son los únicos. 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. vii

8 viii

9 Índice general 1. Introducción Motivación del proyecto Estructura de este documento Estado del arte Distribuciones de Linux Sistemas de instalación desatendidos Sistemas de autenticación de usuarios Sistemas de ficheros en red Servidores de correo electrónico Sistemas de monitorización Objetivos Sistema de instalaciones masivas y desatentidas Sistema de cuentas de usuario y disco en red Servicios adicionales Monitorización del sistema Políticas de seguridad Documentación Especificación y Diseño Metodología empleada Análisis de requisitos Proceso de instalación desatendido Cuentas de usuario en red y disco en red Servicios de valor añadido Dedicación de las máquinas físicas Peloto Zipi Zape Lechuzo Sapientin Pantuflo Espatula Servidores disponibles en el Campus de Fuenlabrada Bilo Nano ix

10 ÍNDICE GENERAL ÍNDICE GENERAL 4. Implantación Herramienta de Instalación Automática Servidor DHCP para configuración automática de Red Arranque por PXE Arranque por red de Linux Ficheros de preconfiguración Protocolos situados en la capa de aplicación Servidor LDAP de cuentas de usuario Servidor NFS de ficheros en red Servidor Web de los Laboratorios Servidor de correo electrónico Otros servicios disponibles Listas de correo Mirror de Debian y Ubuntu Monitorización del Sistema Monitorización de servidores Monitorización de estaciones Seguridad Limitar los accesos remotos Auditoría de usuarios Detección de intrusos Ataques de fuerza bruta vía SSH Seguridad en las contraseñas de los usuarios Conclusiones Logros alcanzados Conocimientos adquiridos Trabajo futuro A. Scripts de Instalación Automática I A.1. Fichero de preconfiguración genérico ii A.2. Configuración Isolinux v A.3. Fichero de configuración 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ón de la base de datos xii B.3.2. Inserción 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 B.5. Script de debilidad de contraseñas xv x

11 C. Ficheros de configuración XXI C.1. Máquinas 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áquina pantuflo xxxii C.2.1. Fichero de configuración de Apache xxxii C.2.2. Fichero de configuración 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 xi

12 ÍNDICE GENERAL ÍNDICE GENERAL xii

13 Índice de figuras 1.1. Interfaz web de Zabbix. Fuente: Wikipedia Representación del uso de memoria en una máquina a través de Munin. Fuente: Wikipedia El proceso de instalación en Debian/Ubuntu y la preconfiguración de paquetes La raiz del árbol LDAP contiene dos unidades organizativas principales: alumnos y profesores La unidad organizativa de alumnos se subdivide a su vez en otras dos: alumnos de Móstoles y alumnos de Fuenlabrada La unidad organizativa de profesores contiene dos unidades organizativas que almacenan los objetos posixaccount y posixgroup La aplicación wireshark muestra como se mandan los datos de autenticación en claro entre cliente y servidor, con nuestro esquema actual Una vez establecida la conexión segura entre cliente y servidor LDAP resulta más difícil capturar datos de autenticación de usuarios Reparto de carga entre varios servidores LDAP La aplicación PHPLdapAdmin sobre nuestro esquema de servidores Página principal del Laboratorio de Móstoles Autenticación en la página del Laboratorio mediante el directorio LDAP Webmail de pantuflo Webmail de bilo Gestión de listas de correo en pantuflo con Mailman La página de resumen de estado de Nagios para el Laboratorio de Móstoles La página de problemas de Nagios muestra los problemas en algunas máquinas El parte de guerra de Móstoles muestra el estado de las estaciones xiii

14 ÍNDICE DE FIGURAS ÍNDICE DE FIGURAS xiv

15 Indice de Listados 4.1. Generación de un CD personalizado de Ubuntu para instalación automática Instalación del paquete dhcp a través de apt-get Fichero de configuración dpchd.conf. Configuración de subred Fichero de configuración dpchd.conf. Configuración de host Instalación del servicio tfptd-hpa a través de apt-get Fichero de configuración /etc/default/tfptd-hpa Reinicio del demonio tftp Descarga del kernel de arranque por red de Ubuntu Hardy Fichero de configuración de Isolinux Fichero de configuración de Isolinux El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg El fichero de preconfiguración preseed.cfg Instalación del paquete slapd a través de apt-get El fichero de plantilla de debconf para el paquete slapd Preconfigurando el paquete slapd Instalación del paquete slapd a través de apt-get Instalación de las bibliotecas necesarias para la autenticación PAM vía LDAP Contenido del fichero nsswitch.conf para autenticación vía LDAP Contenido del fichero pam ldap.conf para autenticación vía LDAP Contenido del fichero libnss-ldap.conf para autenticación vía LDAP Instalación del conjunto de herramientas migrationtools a través de apt-get Modificando registros en el árbol LDAP usando ldapadd Instalación del paquete openssl a través de apt-get Creación de un certificado para nuestro servidor LDAP Líneas necesarias para proporcionar soporte SSL al servidor LDAP Líneas necesarias para proporcionar soporte SSL al servidor LDAP Reinicio del demonio slapd Líneas necesarias para proporcionar soporte SSL al servidor LDAP Líneas necesarias para proporcionar soporte SSL al servidor LDAP Instalación del demonio slurpd con apt-get Añadiendo replicación a nuestro servidor LDAP xv

16 INDICE DE LISTADOS INDICE DE LISTADOS Añadiendo replicación a nuestro servidor LDAP Copia de Seguridad de los datos del servidor LDAP Línea de cron para automatizar las copias de seguridad de LDAP Modificando la contraseña de un usuario usando ldappasswd Instalación del servidor NFS a través de apt-get Instalación del gestor de raid mdadm usando apt-get Automatización en la creación del raid Automatización en la creación del RAID Instalación de Apache y del módulo PHP5 para el servidor Instalación del servidor Apache2 y del módulo WebDav/Subversion para el servidor Creación de un host virtual en Apache para el host pantuflo.escet.urjc.es Descarga e Instalación de la herramienta MediaWiki Configuración de MediaWiki para autenticar usuarios usando LDAP Configuración de Apache para dar soporte a páginas personales de usuarios Instalación de la herramienta postfix usando apt-get Instalación de los demonios necesarios para dar soporte POP3 e IMAP a pantuflo Reiniciando el demonio dovecot tras su reconfiguración Instalación de mailman usando apt-get Creación de una nueva lista de mailman usando el comando newlist Instalación de la herramienta debmirror usando apt-get Descargando la réplica de Ubuntu usando el comando debmirror Descargando la réplica de Debian usando el comando debmirror Contenido del fichero /etc/apt/sources.list usando la réplica del Laboratorio Instalación de la herramienta Nagios con apt-get Instalación de la herramienta Munin (servidor) con apt-get Instalación de la herramienta Munin (cliente) con apt-get Instalación de la herramienta Munin (cliente) con apt-get Creación de una tabla en MySQL para almacenar la información relativa a auditoría de usuarios Script básico para registrar información de auditoría de usuarios Línea de cron para la automatización de la auditoría de usuarios en el sistema Monitor de alerta de conexiones nocturnas en el laboratorio Intentos de ataque de SSH mediante fuerza bruta o diccionario Instalación de la herramienta Denyhosts A.1. El fichero de preconfiguración necesario para la instalación desatendida ii A.2. Fichero de configuración de Isolinux para el arranque por red v A.3. Fichero de configuración 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ón 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 B.11.Script sshatodos-deltas.sh xiv xvi

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ón /etc/ldap/slapd.conf xxii C.2. Fichero de configuración /etc/bind9/named.conf xxiv C.3. Fichero de configuración /etc/bind9/db.pantuflo.es xxvi C.4. Fichero de configuración /etc/bind9/named.conf xxxi C.5. Fichero de configuración /etc/apache2/sites-enabled/pantuflo.es xxxii C.6. Fichero de configuración /etc/apache2/sites-enabled/pantuflo.escet.urjc.es. xxxii C.7. Fichero de configuración /etc/apache2/sites-enabled/webmail.pantuflo.es.. xxxiv C.8. Fichero de configuración /etc/apache2/sites-enabled/mysql.pantuflo.es... xxxiv C.9. Fichero de configuración /etc/postfix/main.cf xxxv C.10.Fichero de configuración /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 xvii

18 INDICE DE LISTADOS INDICE DE LISTADOS xviii

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érminos pueden encontrarse en el Web 1. 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éditos 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 1

20 INDICE DE LISTADOS Proyecto Fin de Carrera 2 Universidad Rey Juan Carlos

21 Capítulo 1 Introducción 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. 3

22 1.1. MOTIVACIÓN DEL PROYECTO 1.1. Motivación del proyecto El presente documento resume casi toda la actividad realizada en un plazo de un año aproximadamente como administrador de sistemas de los Laboratorios de Linux de la ETSII 1 y la ETSIT 2, 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 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án los objetivos principales que se han de desarrollar en el proyecto. El capítulo de Diseño, El capítulo de Implantación, 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álisis 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ónico en CD en el que puede encontrarse la presente memoria así como todo el código fuente desarrollado en el proyecto 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ácticamente 1 Escuela Superior de Ingeniería Informática 2 Escuela Técnica Superior de Ingeniería de Telecomunicaciones Proyecto Fin de Carrera 4 Universidad Rey Juan Carlos

23 CAPÍTULO 1. INTRODUCCIÓN 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 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 Internet 3 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 Linux 4 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ás usadas (en el A. Gutiérrez Mayoral 5 ETSI Informática

24 1.3. ESTADO DEL ARTE Distribución 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 % Debian GNU/Linux % Others % 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ás usadas en la actualidad. Fuente: DistroWatch último mes), colocando también a Ubuntu y Debian entre los primeros puestos. En este caso se han obtenido los datos del portal DistroWatch 5. 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 Proyecto Fin de Carrera 6 Universidad Rey Juan Carlos

25 CAPÍTULO 1. INTRODUCCIÓN 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 ) 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 últimos 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 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 A. Gutiérrez Mayoral 7 ETSI Informática

26 1.3. ESTADO DEL ARTE conocen esta situación y normalmente, siempre que su distribución 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 apt 6. 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 noveles 7. 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 Los más conocidos son Synaptics (para el escritorio Gnome) o Adept (para KDE) Proyecto Fin de Carrera 8 Universidad Rey Juan Carlos

27 CAPÍTULO 1. INTRODUCCIÓN conocidas, Knoppix o Ubuntu, que comentaremos a continuación. Ubuntu Ubuntu 8 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 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ón sin necesidad de realizar una instalación 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 A. Gutiérrez Mayoral 9 ETSI Informática

28 1.3. ESTADO DEL ARTE SuSE La distribución SuSE 9 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 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 Hat 10, 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 Sistemas de instalación 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 a opensuse.org 10 Proyecto Fin de Carrera 10 Universidad Rey Juan Carlos

29 CAPÍTULO 1. INTRODUCCIÓN 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ón 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ás 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étera. Las aplicaciones comerciales más conocidas hoy en día pueden ser Acronis True Image 11 o Norton Ghost 12. 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 A. Gutiérrez Mayoral 11 ETSI Informática

30 1.3. ESTADO DEL ARTE 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ón 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 Proyecto Fin de Carrera 12 Universidad Rey Juan Carlos

31 CAPÍTULO 1. INTRODUCCIÓN 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 labor 13, 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 Sistemas de autenticación 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 A. Gutiérrez Mayoral 13 ETSI Informática

32 1.3. ESTADO DEL ARTE 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ón 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 Proyecto Fin de Carrera 14 Universidad Rey Juan Carlos

33 CAPÍTULO 1. INTRODUCCIÓN proponemos. Además, este diseño tiene serios problemas de concurrencia, que pueden darse cuando dos administradores realicen modificaciones en la cuenta de un usuario. NIS Las páginas amarillas NIS 14, 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ás avanzadas de cara al aumento tanto de estaciones instaladas en los Laboratorios como de usuarios en posesión 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ón: 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 A. Gutiérrez Mayoral 15 ETSI Informática

34 1.3. ESTADO DEL ARTE Por tanto, debido a estas principales desventajas y a ser un producto tecnológicamente 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 LDAP 15. 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 RFC 16 correspondiente 17. 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 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écnico que describe el comportamiento de un protocolo de red. 17 es la RFC de LDAP en su versión 3. Proyecto Fin de Carrera 16 Universidad Rey Juan Carlos

35 CAPÍTULO 1. INTRODUCCIÓN un demonio de replicación de datos (llamado slurpd) y una serie de bibliotecas que implementan el estándar LDAP. Además, esta implementación soporta múltiples esquemas de datos, entre los que se encuentran los necesarios para representar una cuenta en un sistema Unix y un grupo, por lo que nos sirve para representar la información de cuentas de los usuarios del sistema. Además de todo lo descrito hasta ahora, OpenLDAP dispone de multitud de aspectos avanzados que lo convierten en una solución bastante factible a la hora de decantarse por un sistema de cuentas en red, particularmente, La posibilidad de añadir replicación de datos entre servidores OpenLDAP: Como veremos posteriormente en el capítulo Implantación, es posible diseñar un esquema de servidores maestros-esclavos de tal forma que exista tolerancia ante fallos de red o de suministro eléctrico, además del consiguiente reparto de carga. Reparto de carga entre diferentes servidores LDAP: Del lado del cliente, es posible repartir las peticiones de información sobre diferentes servidores LDAP. Esto es especialmente interesante en un entorno en el que nos encontramos, en el que existe un gran número de usuarios y de estaciones que van a realizar peticiones sobre el servidor LDAP. Veremos más adelante como podemos llevar este diseño a cabo y cuales son las ventajas que nos proporciona. Cifrado de datos entre cliente y servidor: OpenLDAP nos brinda la posibilidad de asegurar las conexiones entre el servidor y los diferentes clientes que vayan a realizar peticiones de autenticación o solicitud de información sobre el mismo. Para ello, se utilizarán las bibliotecas SSL de cifrado de información entre ambos extremos, que asegurarán confidencialidad y privacidad de los datos de los usuarios que viajen en la red. Este aspecto es fundamental y es un requisito crítico en el entorno en el que nos encontramos. Debido a estas razones, LDAP se convierte hoy en día en un estándar de facto a la hora de implementar un sistema de autenticación de usuarios en red y será la opción elegida para la construcción de nuestro servicio de autenticación de usuarios en red Sistemas de ficheros en red Dado que estamos trabajando con un entorno de red basado en estaciones de trabajo en las que los usuarios pueden iniciar su sesión y trabajar con un conjunto de ficheros (a los que llamaremos directorio personal de usuario o ficheros de usuario) es necesario implantar un sistema de ficheros en red que sea capaz de dotar al entorno de un servicio de ficheros en red que permita a los usuarios poder usar sus ficheros independientemente de la estación en la que se encuentren trabajando. En este sentido, no existen muchas alternativas para poder implementar esta funcionalidad dentro de un sistema operativo Linux o Unix. Una de las más conocidas y la más usada por excelencia, es el sistema de ficheros en red NFS 18. En los últimos años se ha extendido una alternativa a esta opción, el sistema de ficheros usado en comparticiones con sistemas operativos Windows. Esta solución suele ser adoptada en entornos híbridos en los que se trabaja tanto con sistemas Unix/Linux como con sistemas Windows. En principio no es nuestro caso y por tanto optaremos por no implantar tal sistema, aunque su análisis resulta interesante por si en algún momento es necesario plantear la posibilidad de instalar sistemas Windows en el Laboratorio ante el requerimiento de software docente de alguna asignatura. Cabe reseñar que aunque son sistemas de ficheros en principio muy diferentes, las dos opciones pueden funcionar perfectamente en conjunción: si un host arranca un sistema operativo Windows, 18 NFS son las siglas de Network File System o Sistema de Ficheros en Red. A. Gutiérrez Mayoral 17 ETSI Informática

36 1.3. ESTADO DEL ARTE usará el sistema de ficheros en red que facilite el servidor Samba, y si arranca el sistema operativo Linux o cualquier otro basado en Unix, usará el análogo basado en NFS. Por tanto, los directorios serán lo mismo, simplemente la manera de servirlos será diferente: en un caso se usará el sistema de ficheros para comparticiones Windows (Samba) y en otro, para sistemas Linux (NFS). NFS El sistema de ficheros NFS (Sistema de ficheros en red) es un protocolo a nivel de aplicación según el modelo OSI). Este sistema de ficheros en red es muy usado en entornos de red en el que se trabaja con un modelo distribuido de estaciones de trabajo que necesitan acceder a un mismo directorio que se encuentra alojado en un servidor (como el caso que nos ocupa). Esto posibilita que las estaciones de trabajo puedan acceder a este directorio como si de un directorio local se tratara. Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que fuera independiente del Sistema Operativo, y el protocolo de transporte. Esto fue posible ya que fue implementando bajo los protocolos XDR y ONC-RPC. El conjunto de aplicaciones que hace posible el uso del protocolo NFS suele estar incluido por defecto en la mayoría de las distribuciones Linux actuales. El sistema NFS suele estar compuesto de un servidor, y uno o más clientes. Los clientes acceden de forma remota a los directorios ofrecidos o exportados por el servidor, donde se encuentran almacenados los datos. De esta forma, los usuarios de nuestro sistema no necesitarán disponer de un directorio HOME (el directorio personal de usuario en un sistema Linux) en cada una de las estaciones Linux en las que inicien su sesión, sino que todos los directorios HOME se encontrarán en el servidor de ficheros NFS y los usuarios importarán o montarán (término muy usado en sistemas Linux que hace suele hacer alusión a empezar a usar un sistema de ficheros) este directorio en la estación de trabajo en la que se encuentren. No es objetivo de esta sección enumerar los aspectos técnicos del protocolo, ya que estos se encuentran descritos en la RFCs correspondientes 19. Las pruebas que se han llevado a cabo en el entorno demuestran que este protocolo resuelve bastante bien la tarea de servir un directorio HOME a todas las estaciones del Laboratorio (unas 160 aproximadamente) sin que se produzcan retardos excesivos en las comunicaciones o cuellos de botella. De hecho, solamente es una sola máquina es la que lleva a cabo esta tarea, sin que sea necesario la división del servicio para su escalabilidad. Dado que el sistema NFS es un sistema nativo y propio de sistemas operativos Unix/Linux, y debido a que no disponemos de equipos Windows en el conjunto de estaciones de trabajo que conforman nuestra red de área local (y por tanto no es necesario servir a través de un sistema de ficheros de Windows los directorios personales de los usuarios) será la solución que adoptemos en el entorno que nos ocupa. Samba Samba es una implementación de software libre del protocolo de archivos compartidos de Windows para sistemas operativos tipo Unix/Linux. Antiguamente recibía el nombre SMB, pero fue renombrado recientemente a CIFS. Gracias a esta implementación es posible que ordenadores con Linux, MacOS o cualquier Unix en general sean capaces de servir o ser clientes de ficheros en redes Windows. Samba también permite validar usuarios haciendo las labores de Controlador Principal de Dominio (PDC), como miembro de dominio o incluso como un dominio de Directorio Activo (Active Directory) para redes basadas en Windows, aparte de ser capaz de servir colas de impresión, directorios compartidos y autenticar con su propio archivo de usuarios. 19 es la RFC del protocolo NFS en su última versión. Proyecto Fin de Carrera 18 Universidad Rey Juan Carlos

37 CAPÍTULO 1. INTRODUCCIÓN Entre los sistemas tipo Unix en los que se puede ejecutar Samba, están las distribuciones GNU/Linux, Solaris y las diferentes variantes BSD entre las que podemos encontrar el Mac OS X Server de Apple. Dado que en nuestra red no se van a alojar hosts con sistemas operativos Windows, descartamos esta opción, aunque es interesante analizarla por si en un futuro no muy lejano es necesario instalar Windows para la docencia de alguna asignatura del Departamento Servidores de correo electrónico Dotar al entorno de un sistema de gestión del correo electrónico nos brinda una cantidad enorme de nuevas funcionalidades. Sin entrar aún en cuales pueden ser estas nuevas funcionalidades, es necesario indicar que bajo el punto de vista de organización independiente dentro de la Universidad, no se disponen a priori datos de los alumnos, entre ellos, los datos necesarios para poder contactar con ellos en caso de que sea necesario. A menos que usemos el correo electrónico que se usa por defecto sobre cualquier máquina Unix. Es por esta razón que debemos instaurar un mecanismo que nos permita entrar en contacto con los alumnos, para poder indicarles en un momento determinado cualquier incidencia con su cuenta de usuario. Además, este mecanismo también puede ser usado para otros menesteres, entre ellos, enviar al alumno las notas de sus exámenes parciales, noticias acerca del funcionamiento interno del Laboratorio, etcétera. Para ello, se decide la implantación de un sistema de transporte de correo (MTA) que asuma las funciones de recogida de correo electrónico bajo los dominios de cada uno de los campus en los que disponemos de un Laboratorio de Linux (Móstoles y Fuenlabrada) y que facilite de un buzón de correo electrónico a los usuarios. Además, como posteriormente veremos en el capítulo de Implantación, instalaremos un servidor de recogida de correo (para que los usuarios sean capaces de recoger su correo electrónico usando un gestor como Outlook, Evolution, Eudora, etcétera) y un webmail, que facilitará que todos aquellos usuarios que no quieran o no puedan recoger su correo electrónico usando un gestor, lo puedan consultar en el web. En el capítulo Implantación se detallará más ampliamente este mecanismo. A continuación vamos a enumerar las alternativas más frecuentes y más conocidas en lo que a servidores o agentes de correo se refiere. Por un lado, es necesaria la instalación de un agente de correo o Mail Transport Agente, que se encargue de la recogida de todo el correo que llega a cada uno de los servidores: de este lado, analizaremos los servidores más comúnmente usados en este sentido: Postfix y Sendmail. Una vez completada esta tarea, será necesaria la instalación del citado servidor de recogida de correo. Estos servidores, suelen operar bajo los protocolos POP y/o IMAP (siempre bajo conexiones seguras, usando SSL o TLS). En este sentido, hemos citado dos de los servidores más conocidos y usados en la actualidad: Courier y Dovecot (aunque por supuesto, existen muchos más). Cabe reseñar que las pretensiones de estos servidores no van más allá que la simple entrega y recogida de correo, sin necesidad de alcanzar unas cotas de rendimiento mínimas o condiciones especiales. Es por ello que a la hora de decantarnos por una opción u otra, nos centraremos básicamente en la facilidad de instalación de cada herramienta. Sendmail Sendmail a día de hoy es uno de los proyectos más conocidos dentro del Software Libre. Sendmail es un Agente de Transporte de correo, o MTA (Mail Transport Agent). Esta aplicación se encarga de encaminar los mensajes de correo electrónico en Internet para que lleguen a su destino. Se afirma que Sendmail es uno de los principales encaminadores de todo el tráfico de correo electrónico en la Internet mundial, de ahí la importancia de este agente de correo electrónico. Comenzaba su andadura cuando la Internet moderna comenzaba sus pasos, de ahí que una de las principales dolencias de Sendmail sea uno de los aspectos que en principio no era un A. Gutiérrez Mayoral 19 ETSI Informática

38 1.3. ESTADO DEL ARTE problema cuando Internet comenzaba sus pasos: la seguridad. Según los principales detractores de esta herramienta adolece de numerosas fallas de seguridad (muchas descubiertas y documentadas, y quien sabe las que tiene por descubrir), aunque normalmente están son arregladas a las pocas horas de ser notificadas. Otro de los principales problemas de los que adolece Sendmail es de su configuración. Mientras la mayoría de los servidores de recogida de correo tienen ficheros de configuración legibles por humanos (human-readables) los propios desarrolladores de Sendmail afirman que los ficheros de configuración de la herramienta no cumplen esta condición, y recomiendan al administrador de sistemas encargado de configurar esta tediosa herramienta el aprender un lenguaje basado en macros para la configuración de la misma (M4 20 ). Además de soportar evidentemente el protocolo SMTP de correo electrónico, Sendmail da soporte a una gran variedad de protocolos de correo electrónico, como ESMTP, DECnet s mail11, HylaFax, QuickPage o UUCP. Como vemos, Sendmail es una aplicación con una funcionalidad bastante extensa para nuestros propósitos, que dificulta su configuración enormemente, por lo que en un principio será descartada en favor de una aplicación que aunque con menor funcionalidad, sea más sencilla y rápida de configurar. Postfix Al igual que Sendmail, Postfix 21 es un agente de transporte de correo (MTA) que encamina los mensajes de correo electrónico desde el origen hasta el destinatario. Actualmente, Postfix se encuentra en su versión estable 2.5, liberada aproximadamente en Enero de Postfix surgió como principal alternativa a Sendmail: se buscaba un gestor de correo electrónico seguro, fácil de administrar y cuya instalación no supusiera un quebradero de cabeza para muchos administradores de sistemas a lo largo de toda Internet. Con este objetivo, Thomas J. Watson desarrolló las primeras versiones de Postfix, antiguamente conocido como VMailer y IBM Secure Mailer. Postfix es el sistema gestor de correo predefinido en muchas distribuciones de Linux (por ejemplo Ubuntu), y en las últimas versiones del sistema operativo de Apple (Mac OS Tiger y Leopard). Respecto a los detalles técnicos, el código fuente de Postfix suele ser citado como ejemplo de buena práctica de programación. Aparte de este detalle, Postfix posee muchas funcionalidades que hoy en día son casi primordiales a la hora de configurar cualquier servidor de correo: soporte para comunicaciones seguras (usando la capa de seguridad TLS), capacidad de filtrar el correo mediante listas grises, uso de diferentes bases de datos para obtener fuentes de usuarios, dominios etcétera (entre ellas, MySQL, PostgreSQL, LDAP, bases de datos Berkeley, etcétera), soporte de formato mbox y Maildir para almacenar los mensajes de correo, etcétera. Como se puede observar, la funcionalidad de este gestor de correo es bastante extensa, lo que puede incitar a pensar que su configuración puede ser incluso más complicada que la de su principal rival, Sendmail. Nada más lejos de la realidad. La instalación y configuración de Postfix se realiza en apenas tres pasos, sin más que indicar si se desea instalar un gestor de correo que reciba correo de Internet, el dominio para el que se desea recoger correo y poco más. Por supuesto, si la configuración es más extensa, se deberán personalizar los ficheros de configuración al gusto, para conseguir la configuración deseada según las necesidades de cada administrador. No obstante, los ficheros de configuración de Postfix son bastante sencillos de asimilar (principalmente la configuración se realiza editando un único fichero, el fichero /etc/postfix/main.cf) y la configuración avanzada no resulta muy complicada, existiendo gran documentación en Internet y configuraciones estándar ya escritas para la mayoría de los supuestos casos que nos podemos encontrar. 20 M4 es un procesador de macros de propósito general, desarrollado por Brian Kernighan y Dennis Ritchie. 21 Proyecto Fin de Carrera 20 Universidad Rey Juan Carlos

39 CAPÍTULO 1. INTRODUCCIÓN Debido a la rapidez de la instalación de esta herramienta y su posterior configuración (para nuestros requerimientos, la configuración estándar es más que necesaria) será el gestor de correo que elijamos como agente de transporte de correo para el Laboratorio, frente a su principal competidor (Sendmail). En el capítulo Implantación estudiaremos más en detalle la configuración que se lleva a cabo para que el gestor funcione correctamente. Courier Una vez elegido un agente de transporte de correo (MTA) debemos pensar en que los usuarios deben poder leer su correo de una forma eficiente. En este sentido, será necesario instalar y configurar un servicio de recogida de correo. Estos servicios facilitan a los usuarios la descarga del correo electrónico usando un gestor de correo electrónico para el escritorio, como por ejemplo Outlook (para Windows), Eudora, Mozilla Thunderbird, Evolution, etcétera. A través de estos gestores los usuarios podrán descargar el correo del Laboratorio sin necesidad de tener que conectarse al servidor para leerlo en el terminal, algo engorroso en algunos casos. Para ello, nos planteamos la instalación de alguna herramienta que facilite este servicio. Hoy en día, los más usados en la distribuciones Linux que vamos a usar como principales (Debian y Ubuntu) son Courier y Dovecot, que repasaremos a continuación. Courier Mail Server, o comúnmente llamado Courier, también es un agente de transporte de correo MTA que facilita la operación de los protocolos POP e IMAP para la recogida de correo. Estos protocolos son los que facilitan que los gestores de correo e información personales puedan conectarse al servidor y descargar el correo electrónico a cada uno de los ordenadores de los usuarios. Además, Courier puede funcionar como gestor de correo electrónico (como Postfix y Sendmail) aunque en nuestro caso, solamente plantearemos su uso como servicio POP e IMAP. La herramienta Courier se encuentra presente en Debian como paquete (en concreto, es necesario instalar los paquetes courier-pop-ssl, courier-imap-ssl para añadir soporte POP e IMAP usando una conexión segura). La instalación de Courier se divide en aquellos elementos que se desea instalar, según el protocolo ofrecido al usuario (POP, IMAP, POP bajo SSL, etcétera) existiendo un paquete para cada funcionalidad. La configuración de Courier es algo compleja para nuestras necesidades, por lo que en principio, nos decantaremos por una opción más sencilla de instalar y configurar, como es Dovecot, un servidor POP e IMAP muy sencillo de configurar. Dovecot La labor fundamental de Dovecot 22 es la de facilitar el acceso a los buzones de correo mediante los protocolos POP3 e IMAP (pudiendo usar también una conexión segura, es decir, POP3s e IMAPs). Esta aplicación ha sido escrita principalmente por Timo Sirainen y fue liberada por primera vez en 2002, por lo que después de seis años podemos afirmar que la herramienta se encuentra lo suficientemente madura como para ser usada en producción (la última versión es la que fue liberada en Julio de 2008). La instalación y posterior configuración de Postfix es extremadamente sencilla, basándose únicamente en un fichero de configuración (el fichero /etc/dovecot/dovecot.conf). En este fichero se indica los protocolos que se desea ofrecer (pop3, pop3, imap o imaps) y algunas otras indicaciones relativas a los certificados (en caso de que ofrezcamos conexiones seguras), los directorios de ejecución, el formato de los mensajes de correo almacenados, etcétera. En realidad es muy probable que con tan solo indicar los protocolos ofrecidos la herramienta funcione a la primera, de ahí la sencillez de su configuración. Para nuestro caso es más que suficiente (en un momento somos capaces de ofrecer un servicio POP/IMAP bajo conexiones seguras a los usuarios 22 A. Gutiérrez Mayoral 21 ETSI Informática

40 1.3. ESTADO DEL ARTE para que descarguen sus correos) por lo que nos decantamos por esta herramienta en favor de cualquier otra Sistemas de monitorización Los sistemas de monitorización nos permiten conocer en todo momento el estado de la red, formado por un conjunto de máquinas que ofrecen una serie de servicios a disposición de los usuarios. En este sentido, las herramientas de monitorización realizan un sondeo continuo de todas las máquinas que conforman una red, comprobando que todos los servicios que dispone esa máquina están funcionando adecuadamente. En caso de que alguno de ellos no esté funcionando como debiera, el sistema enviará una alerta, normalmente en forma de correo electrónico al administrador de la aplicación. Este correo electrónico pondrá en aviso al responsable de la máquina o máquinas en cuestión afectadas por el problema, que tomará las medidas oportunas. En nuestro caso, estas herramientas nos van a permitir conocer en todo momento el estado de las estaciones del Laboratorio y de los servidores, mostrando en todo momento aquellas máquinas que se encuentren en problemas. Normalmente, la mayoría de los sistemas de monitorización ofrecen un interfaz web amigable para el usuario donde se muestran los resultados de la monitorización de la red. Es el caso de las tres herramientas estudiadas en esta sección: Zabbix, Munin y Nagios. Zabbix Zabbix 23 es una solución de monitorización de código abierto de las más avanzadas hoy en día. Permite la monitorización y registro del estado de varios servicios de red, servidores, estaciones, etcétera. Almacena los datos que registra en un sistema gestor de base de datos del tipo MySQL, PostgreSQL, SQLite o Oracle. Además dispone de un frontend o interfaz único escrito en PHP, donde se muestran todos los datos recopilados por cada una de las herramientas que sondea el estado de la red. Aparte de monitorizar el estado de máquinas y servicios (por ejemplo, una pasarela SMTP o un servidor HTTP) Zabbix permite la monitorización avanzada de una máquina instalando un componente llamado agente zabbix (Zabbix Agent) en el host en cuestión. Este agente permite la obtención de datos del host como por ejemplo el uso de memoria, procesos, espacio libre en disco, etcétera. Los agentes envían la información al servidor para almacenar los datos y mostrarlos de una forma amigable para el usuario a través de un interfaz web. En la imagen 1.1 podemos observar una de las capturas de pantalla del interfaz web de gestión de Zabbix, en el que se muestra el estado particular de un host: uso de memoria, carga de procesador, espacio en disco, carga de red, etcétera. Como se puede ver en la imagen, las estadísticas resultado de la monitorización realizada por Zabbix resultan ser bastante detalladas, quizá más de lo que en un principio necesitamos. Además, la instalación y posterior configuración de esta herramienta puede ser demasiado compleja, lo suficiente para que no compense realmente con respecto a nuestras necesidades. Digamos que los reportes ofrecidos resultan ser bastante más detallados de lo que en un principio necesitamos: saber qué máquinas están disponibles en cada momento y si se ha producido cualquier tipo de problema. Es por ello que en principio dejamos aparcada esta herramienta en busca de otra un poco más simple para nuestros propósitos. No obstante, vamos a destacar las principales ventajas y desventajas de esta herramienta de monitorización. Como ventajas, podemos decir que los reportes obtenidos por esta herramienta son muy detallados, obteniendo gráficas en diferentes formatos de toda la información acerca del estado de la red y de los hosts que creamos oportuno. Esta información nos puede ayudar 23 Proyecto Fin de Carrera 22 Universidad Rey Juan Carlos

41 CAPÍTULO 1. INTRODUCCIÓN Figura 1.1: Interfaz web de Zabbix. Fuente: Wikipedia a construir informes de disponibilidad muy bien detallados y de una calidad más que aceptable. Además de esto, Zabbix, soporta un gran número de plataformas (incluidos Solaris, Linux, Mac OS, FreeBSD, HP-UX, etcétera). En la actualidad el núcleo de Zabbix no soporta Windows, pero sí puede monitorizar plataformas Windows, algo muy interesante para todas aquellas personas que usen software de servidor basado en este sistema operativo. Como desventajas podemos decir que la curva de aprendizaje de esta herramienta es bastante elevada, y se ha de meditar si conviene usarla para lo que realmente se necesita. En nuestro caso, la respuesta era no, ya que es una herramienta bastante avanzada para nuestros objetivos. La configuración de la herramienta es bastante compleja y podemos afirmar que su manual de instrucciones tiene muchas páginas, lo que puede echar para atrás a alguien que en principio quiera usar esta herramienta para monitorizar una red de no muy grandes dimensiones. Nagios Nagios 24 es una aplicación bastante parecida a Zabbix, en muchos sentidos: permite monitorizar el estado de un conjunto de máquinas en una red, comprobando disponibilidad tanto de las máquinas como de los servicios asociados a ella. Cuando se produce un problema, Nagios envía una alerta a un contacto o grupo de contactos informando del problema producido y su nivel de peligro. La diferencia más importante de Nagios respecto a Zabbix es que Nagios en principio no puede monitorizar el estado interno de una máquina (carga de memoria, procesador, espacio en disco, etcétera), aunque en principio estos datos no son de nuestro interés, ya que para 24 A. Gutiérrez Mayoral 23 ETSI Informática

42 1.3. ESTADO DEL ARTE nosotros es más importante conocer el estado de la red en tanto a máquinas y servicios. Además de la monitorización constante que realiza Nagios, éste ofrece un portal Web donde monitorizar todos los resultados. Si en un momento dado queremos ver de una pasada rápida el estado de un host o de un grupo de hosts podemos realizarlo usando para ello su interfaz web. Respecto a la configuración de Nagios, podemos afirmar que no es demasiado complicada. Existen diversos ficheros de configuración donde se indican por un lado, las máquinas de las que consta nuestra red, por otro lado y por otro los servicios que se desean comprobar sobre estas máquinas. Digamos que la configuración es más tediosa que complicada, debido a la verbosidad de los ficheros de configuración. Aún así, puede resolverse eficientemente si disponemos de un fichero de texto donde se indique la dirección IP de cada máquina y su nombre correspondiente. Usando un script de shell muy sencillo podemos generar el fichero de configuración de nagios de forma trivial. Una vez que se han declarado todas las máquinas en el fichero de configuración, se indican los servicios que se desean comprobar para cada máquina. Como es muy frecuente agrupar las máquinas en grupos (en nuestro caso, las agruparemos por laboratorios y por grupos de servidores) Nagios nos permite declarar grupos de hosts. De esta forma, será más sencillo indicar que se desea comprobar un cierto servicio sobre un determinado grupo de hosts. Una vez que se han declarado máquinas, grupos de máquinas y servicios, solamente deberemos indicarle a Nagios los contactos a los que se desea enviar información en caso de problemas. De la misma forma que antes, Nagios permite declarar contactos y grupo de contactos. Es usual que los responsables de un conjunto de máquinas sean más de una persona, de ahí esta funcionalidad muy acertada en la herramienta. Una vez se han configurado estos parámetros, se lanza Nagios y se pueden consultar a través de su página web el estado de la red, y si se ha configurado para ello, nos llegará mediante correo electrónico los avisos de las alertas correspondientes. Nagios está disponible como paquete Debian/Ubuntu en las versiones estables actuales de ambas distribuciones, por lo que su instalación es trivial. No obstante, también puede ser instalado mediante fuentes, si queremos tener disponible la última versión estable de la herramienta. Debido a la sencillez de la configuración (generada automáticamente con scripts) nos decantaremos por Nagios como herramienta de monitorización de nuestro entorno. Finalmente y para recapitular, podemos decir que, Nagios presenta las siguientes ventajas y desventajas: Como ventajas, su configuración es muy simple y se puede realizar en apenas minutos, partiendo de un fichero con las IPs de todos los equipos de la red y su nombre de host, lo cual siempre se suele tener a mano. Una vez realizada esta configuración, la herramienta empieza a obtener todos los reportes sin más. Como desventajas, podemos decir que los reportes por Nagios son demasiado simples. Dependiendo del nivel de reporte que queramos obtener, esto puede ser una desventaja, pero también puede convertirse en una ventaja. En el entorno en el que nos encontramos, estos reportes son más que suficientes. Otra de sus desventajas es que solamente existe una versión para sistemas operativos de la familia Unix (y por tanto, Linux). No existe actualmente una versión para Windows, aunque en principio esto no nos afecta ya que en nuestro entorno no disponemos hasta la fecha de estaciones Windows. Esto ocurría también con su principal competidor, Zabbix, con la diferencia de que Zabbix puede obtener las estadísticas completas de monitorización de una máquina Windows, debido a que dispone de una versión de su agente para este sistema operativo. Proyecto Fin de Carrera 24 Universidad Rey Juan Carlos

43 CAPÍTULO 1. INTRODUCCIÓN Munin Por último, analizamos la herramienta Munin 25. La aplicación Munin es una herramienta de monitorización de red y del sistema en general (más bien, del sistema). La aplicación se distribuye en dos componentes: El servidor Munin, que recoge y procesa los datos que son enviados por los clientes, los nodos de Munin. Estos nodos se encuentran instalados en todas aquellas máquinas que se desea monitorizar o de las que se desea obtener estadísticas. Además, dispone de un gran número de plugins o añadidos para recoger y procesar todo tipo de datos interesantes para el administrador: carga de procesador (procesos), carga de memoria, espacio en disco, carga de la red, número de operaciones de entrada/salida, etcétera. Además, dependiendo de si el servidor dispone de una serie de servicios o no, Munin será capaz de obtener datos de estos servicios. Por ejemplo, para un servidor MySQL, Munin es capaz de obtener el número de consultas por unidad de tiempo realizadas, e incluso, discriminar por tipo de consulta realizada en la base de datos. Sin embargo si nuestro servidor tiene capacidades de servidor web, Munin es capaz de representar el número de páginas servidas por unidad de tiempo. En general, Munin dispone de un amplio abanico de plugins que hace que sea capaz de representar casi todas las estadísticas que puede haber en un servidor hoy en día. Figura 1.2: Representación del uso de memoria en una máquina a través de Munin. Fuente: Wikipedia La aplicación está pensada para visualizar únicamente los datos que son recogidos a través de los diferentes nodos. Una vez que estos datos son recogidos, se muestran a través de un interfaz 25 A. Gutiérrez Mayoral 25 ETSI Informática

44 1.3. ESTADO DEL ARTE web las diferentes gráficas que se corresponden con cada uno de los servicios. En la imagen 1.2 podemos ver cómo se representa el uso de memoria en una máquina a través de Munin. Munin utiliza la herramienta RRDTool 26 para la representación de sus páginas. La configuración de Munin es extremadamente simple, ya que únicamente hay que instalar la aplicación cliente en cada uno de los nodos que se desea monitorizar y el servidor en aquella máquina que se desea usar para representar la información. En los clientes, se especifica en un fichero de configuración qué máquina es el servidor (para permitirle recoger los datos que el cliente recopila) especificando la dirección IP del mismo. En el servidor, se indica a qué clientes se debe acudir para recopilar toda la información que se desea monitorizar. Y nada más. Una vez hecho esto, el servidor Munin se conectará a los clientes periódicamente para representar la información que le facilitan los clientes. Como el uso de esta aplicación no implica no usar el resto, hemos decidido instalarla en una máquina para obtener gráficas relativas al uso de los diferentes servicios en cada uno de los servidores. Ya que la configuración es extremadamente simple, no nos llevará mucho tiempo debido a que el número de servidores en nuestra red no es muy elevado. Finalmente, indicamos las ventajas y desventajas de esta herramienta: Como ventaja, podemos afirmar que la configuración de Munin es extremadamente sencilla, realizándose en apenas minutos para el entorno en el que nos encontramos. Además, las estadísticas obtenidas por Munin son muy detalladas y nos brindan una información muy concisa. Como desventaja, podemos decir que el sistema de notificación es algo pobre y algo extraño de configurar. Aunque, como Munin en sí mismo no está pensado como sistema de notificación, simplemente podemos usarlo para visualizar las gráficas de los diferentes servidores y estaciones y usar Nagios como sistema de notificación. 26 Proyecto Fin de Carrera 26 Universidad Rey Juan Carlos

45 Capítulo 2 Objetivos Una vez realizada una introducción tanto a la motivación del proyecto como a los objetivos principales, vamos a detallar de forma concisa en qué consistirá cada uno de ellos. Para ello, detallaremos cada uno de los objetivos y como lo afrontaremos. Nos proponemos dos objetivos principales, basados en el desarrollo de un sistema de instalación automático y desatendido y la implantación de un sistema de cuentas de usuario en red. Una vez que ambos objetivos han sido llevados a cabo, se ampliará la funcionalidad del entorno dotándolo de servicios de valor añadido y ampliando la seguridad del mismo todo lo que podamos. Con esto conseguiremos un entorno bastante fiable y reduciremos la probabilidad de que alguien pueda entrar en el sistema con una cuenta de usuario que no le pertenece, con todo lo que ello conlleva. 27

46 2.1. SISTEMA DE INSTALACIONES MASIVAS Y DESATENTIDAS Una vez presentado el marco general de desarrollo de este proyecto y las tecnologías utilizadas, en este capítulo abordaremos los objetivos que se han perseguido durante la elaboración del proyecto. Los principales objetivos del proyecto son: Desarrollar un sistema de instalaciones masivas y completamente desatendidas Implantar un sistema de cuentas de usuario y disco en red Dotar al entorno de una serie de servicios de valor añadido (página web, correo electrónico, etcétera) Instaurar un servicio de monitorización de la red y de los servicios Aumentar al máximo la seguridad del entorno Sistema de instalaciones masivas y desatentidas El primer objetivo que abordamos es la implementación de un mecanismo que permita automatizar la instalación de estaciones de usuario basadas en Ubuntu Linux, de una forma lo más automática y desatendida posible. Este mecanismo permitirá la instalación masiva de laboratorios de una forma cómoda para el administrador de las mismas, y en un corto espacio de tiempo. Hay que tener en cuenta que cada Laboratorio se compone de al menos cuarenta equipos, por lo que el que exista un método de instalación que no sea el tradicional (basado en un medio extraíble que se instala en un equipo, siguiendo una serie de pasos) resulta prácticamente indispensable. El mecanismo de instalación que perseguimos construir debe instalar todo el sistema, con todos los requisitos necesarios, sin que sea necesaria la intervención del usuario administrador que lo realiza (únicamente, la iniciación del proceso). Nuestro objetivo será siempre que la interacción entre el administrador y el proceso de instalación sea mínimo, como veremos posteriormente. A veces, esto no será posible, como veremos en el capítulo Implantación, donde se estudiará detenidamente la construcción de esta herramienta. Sin embargo, y en comparación con los métodos estudiados y descartados, la interacción del administrador con el proceso de instalación casi siempre será mínima. En el método estudiado e implementado se ha dotado al sistema de un sistema de instalación desatendido que solamente requiere que el administrador inicie el proceso. El sistema se instalará sin requerir ninguna acción por parte del usuario y cuando éste haya sido completado, la estación se reiniciará automáticamente, iniciando el nuevo sistema recién instalado. Para la construcción de este sistema de instalación automática nos basaremos en diversas tecnologías, siendo la primordial los ficheros de preconfiguración de Debian GNU/Linux. Este mecanismo será estudiado con detalle en el capítulo de Implantación del presente documento Sistema de cuentas de usuario y disco en red Debido a la naturaleza del sistema, es necesario proveer al mismo de un sistema de cuentas de usuario en red, que facilite que los usuarios puedan iniciar una sesión en el sistema usando para ello una credencial basada en nombre de usuario y una palabra de paso o contraseña. El sistema debe facilitar que un usuario pueda iniciar siempre una sesión en cualquier estación del Laboratorio, independientemente de cual sea ésta. De la misma forma, debe facilitar la creación de nuevos usuarios, o el cambio de la palabra de paso de un usuario en concreto. Sería razonable el marcar como objetivo que un cambio de una contraseña de un usuario, permita que el usuario Proyecto Fin de Carrera 28 Universidad Rey Juan Carlos

47 CAPÍTULO 2. OBJETIVOS inmediatamente vea reflejado que el cambio afecta a todas las estaciones del Laboratorio: no sería razonable que si el usuario ha efectuado un cambio en su contraseña, la nueva palabra de paso no se viera reflejada inmediatamente al iniciar una sesión en cualquier otra estación del Laboratorio. Como objetivo primordial para esta fase también nos marcaremos el añadir privacidad a los datos que viajan por la red relativos a las credenciales del usuario que intenta iniciar una sesión en una estación del Laboratorio, o que efectúa un cambio en la palabra de paso o contraseña de su cuenta. Esto es muy importante ya que al encontrarnos en un entorno basado en red de medio compartido, nos podríamos encontrar con usuarios maliciosos que pueden monitorizar los datos que viajan por la red en un momento dado, capturando nombres de usuario y contraseñas pertenecientes a un usuario en concreto. Si no añadimos un mecanismo que permita ocultar estos datos de forma conveniente, nos podemos encontrar con alguna que otra sorpresa desagradable. Veremos posteriormente en el capítulo Implantación como este aspecto se soluciona convenientemente aportando una solución basada en bibliotecas de cifrado sobre el protocolo que se ocupa de las cuentas de usuario. En principio no aportamos más detalles técnicos sobre este objetivo, ya que se estudiarán en detalle en el capítulo oportuno. Además, junto con el sistema de cuentas de usuario en red, sería conveniente proporcionar un servicio de disco en red. No sería lógico que cada vez que un usuario iniciara una sesión en un equipo, tuviera unos ficheros diferentes a una sesión iniciada previamente en otro equipo (es decir, cada máquina con sus ficheros independientes). Como es lógico, el inicio de una sesión en una estación debe llevar asociado un espacio en disco personal, independiente de la estación en la que se inicia la sesión y que esté siempre disponible. Estudiaremos posteriormente como implementar este servicio Servicios adicionales Construir un sistema de instalación completamente automático y desatendido y dotar al entorno con un sistema de cuentas de usuario en red y lo suficientemente seguro y confiable serán nuestros objetivos principales. Una vez completados estos hitos, nos marcamos ampliar la funcionalidad del entorno con otros aspectos secundarios. En general, estos objetivos serán en su mayoría servicios de valor añadido, que harán del sistema un entorno más funcional y más agradable de cara al usuario final: los alumnos. En esta sección, nos planteamos la persecución de los siguientes hitos: Dotar al entorno de una página web: dotar a los Laboratorios de un sitio web facilita el aprendizaje por parte de los usuarios al funcionamiento del mismo, así como facilita una plataforma para la documentación de preguntas frecuentes de usuarios, anunciar noticias relacionadas con el Laboratorio y colgar los horarios de las salas para referencia de profesores y alumnos. Sistema de correo de entrada y recogida: dado que el sistema de cuentas de usuario no está relacionado con las cuentas de dominio único que se facilitan a los usuarios y profesores de la Universidad por ser miembros de ella, implementaremos un sistema de correo unido a las cuentas que entregarán correo en la dirección compuesta por el nombre de usuario propietario de la cuenta seguido del dominio del servidor que recoja el correo en ese momento. Una vez que los usuarios disponen de esta cuenta de correo, podrán leer los mensajes que en ella se almacenen o bien redirigirlos a una cuenta de correo que lean asiduamente. Esta característica es fundamental, puesto que no disponemos de otro mecanismo de comunicación con los usuarios del sistema que no sea el correo electrónico. Sistema de resolución de nombres local: de cara a añadir funcionalidad y tolerancia de fallos, es interesante el añadir un sistema de resolución de nombres local interno a los A. Gutiérrez Mayoral 29 ETSI Informática

48 2.4. MONITORIZACIÓN DEL SISTEMA Laboratorios. Esto permitirá la resolución de nombres de dominio más rápidamente que si se usara un servidor de resolución de nombres ajeno al mismo, además de aumentar la tolerancia a fallos de cara a caídas de red. En cualquier caso, siempre podríamos usar los servidores DNS que facilita la Universidad de cara a los usuarios de la red de la Organización. Listas de correo: la utilización de listas de correo tiene dos objetivos principales. Por un lado, la comunicación entre los administradores del Laboratorio y los usuarios, por medio de una única lista de correo. A través de esta lista de correo se mandan avisos, noticias, recomendaciones de uso sobre el Laboratorio y en general cualquier nota que sea de interés para los usuarios del sistema. Los avisos que se mandan a esta lista son recibidos automáticamente por los usuarios del mismo solamente por el mero hecho de disponer de una cuenta en los Laboratorios. Por otro lado, la creación de un sistema de listas de correo nos va a permitir el gestionar determinados avisos y alertas que lleguen a determinados grupos de personas encargadas de la gestión de los Laboratorios (profesores, administradores, etcétera). Por ejemplo, alertas sobre caídas en los servicios (fallos eléctricos, de red, etcétera) o incidencias que se producen en el entorno (enviadas por los propios usuarios). La creación de listas permite que los mensajes sean enviados a varias personas con facilidad además de ser almacenados para su posterior consulta. Réplicas locales de Debian y Ubuntu: Dado que la instalación de software (paquetes, como se denomina usualmente en las distribuciones Debian GNU/Linux y Ubuntu) es muy frecuente, y normalmente se repite en tantas estaciones haya en el Laboratorio, el disponer de una réplica local o espejo de un servidor de software de Debian GNU/Linux o de Ubuntu resulta realmente interesante. Si esto no fuera así, cada paquete de software que se deseara instalar en una estación o servidor debería ser descargado desde la réplica correspondiente. Esta réplica, aún no estando muy lejos (podemos disponer de una réplica de Debian GNU/Linux o de Ubuntu en los servidores de RedIris) ya supone el dar un salto fuera de la red institucional de la propia Universidad, con todo lo que ello conlleva. Por esta razón, la instalación de una réplica local siempre será un punto muy a favor para disminuir el tráfico externo y aumentar la velocidad a la hora de instalar software en los Laboratorios. Copias de seguridad de directorios de usuario: con el fin de que un problema de hardware no afecte a los datos personales de los usuarios del sistema, llevaremos a cabo un plan de copias de seguridad que garantice que al menos si se produce un fallo de hardware en alguno de los discos del sistema tengamos una copia de respaldo de la que disponer para restaurar los ficheros personales de los usuarios. Posteriormente en el capítulo Implantación estudiaremos como se han llevado a cabo cada uno de estos requisitos que acabamos de definir Monitorización del sistema En este tipo de entornos, parece que el trabajo queda finalizado cuando todos los hitos que nos planteábamos se han completado y todos los sistemas se encuentran funcionando en fase de producción. Nada más lejos: una vez que el sistema está en marcha, la monitorización del sistema se convierte en el aspecto fundamental para el correcto funcionamiento del mismo. En nuestro caso, y dado el elevado número de estaciones existentes y servidores que hacen que el entorno funcione correctamente, la evaluación de un sistema de monitorización de servicios será algo fundamental y completamente necesario si no queremos encontrarnos una mañana con que un servicio ha dejado de funcionar y no nos hayamos enterado hasta pasadas unas horas. Proyecto Fin de Carrera 30 Universidad Rey Juan Carlos

49 CAPÍTULO 2. OBJETIVOS Para solucionar este aspecto, se pondrá en marcha un sistema de monitorización de todos los servicios existentes en el Laboratorio: por un lado, se vigilará que no haya caída masiva de estaciones (las cuales son producidas normalmente por interrupciones del fluido eléctrico). En este sentido, es importante saber en todo momento cuando se ha producido una caída masiva de estaciones: es significado de que algo no va bien. Sin embargo, no será necesario conocer cuando un ordenador ha dejado de estar disponible (se encuentra apagado), ya que puede ser por muy diversos motivos y en principio, que una estación deje de funcionar (una o un número muy pequeño) no debe ser motivo de distracción. Por otro lado, será muy importante vigilar que todas aquellas máquinas que proporcionen servicios básicos para el funcionamiento del Laboratorio (esto es, servidores) se encuentren disponibles siempre, en todo momento. Al contrario que en las estaciones, la caída de una sola de estas máquinas debe requerir nuestra atención inmediatamente y debe ser resuelta lo más rápido posible. Normalmente, estos avisos son enviados por correo electrónico, o son notificados mediante avisos sonoros. En cualquier caso, la notificación inmediata de problemas en el entorno debe ser fundamental. Estos mensajes son interesantes para los administradores del Laboratorio, si bien para los alumnos siempre resulta útil conocer cuantas estaciones están disponibles en un momento dado, para poder iniciar una sesión en una de ellas. Si bien esta información no es fundamental, es bastante interesante de cara a encontrar una estación disponible en un momento dado para poder iniciar una sesión remota. En este sentido, llamaremos partes de guerra a los informes de estaciones disponibles existentes en el Laboratorio, y podrán ser consultados desde la página web del Laboratorio. En resumen, será condición indispensable para este proyecto la implantación de un sistema que permita monitorizar en todo momento el estado de todos los servicios del Laboratorio: estaciones (si están funcionando, cuantas en cada momento, etcétera) y servidores (que estén todos levantados y que sus correspondientes servicios se encuentren funcionando correctamente) Políticas de seguridad Una vez puesto en marcha todos los servicios anteriores, se marca como hito mantener siempre un entorno lo más seguro posible. Cabe destacar que nos encontramos en un entorno con las siguientes características: Aproximadamente 3000 cuentas de usuario 160 estaciones de trabajo en el Campus de Móstoles y 100 en el Campus de Fuenlabrada Todas las estaciones de trabajo y servidores disponen de IPs públicas. Un entorno de estas características, en el que todas las estaciones disponen de un servicio SSH en el que realizar peticiones, y con tantas cuentas de usuario y además con IPs públicas (accesibles desde cualquier punto de Internet) puede ocasionarnos verdaderos quebraderos de cabeza si no tomamos una serie de medidas que garanticen que si alguien accede al sistema de forma fraudulenta (normalmente, usando una cuenta de usuario que no le pertenece), éste sea interceptado inmediatamente. Es comúnmente sabido que no hay mayor defensa que un buen ataque. Pues bien, en este sentido, para minimizar la posibilidad que alguien pueda entrar en el sistema de forma fraudulenta, plantearemos un ataque en los siguientes aspectos: Limitar el acceso a los servidores a redes internas de la Universidad. A. Gutiérrez Mayoral 31 ETSI Informática

50 2.6. DOCUMENTACIÓN Monitorizar y denegar conexiones a aquellas IPs que son detectadas como posibles orígenes o causantes de intentos de fuerza bruta a través de SSH. Desarrollar un sistema de auditoría que nos permita almacenar un histórico de aquellos usuarios que han iniciado una sesión en alguna estación del laboratorio. Utilizar herramientas que nos ayuden en la detección de intrusos (o desarrollarlas nosotros mismos). Vigilar constantemente la fortaleza de las contraseñas de los usuarios del sistema. Siguiendo estrictamente y regularmente esta serie de medidas, seguramente no eliminemos la probabilidad de que alguien ajeno al sistema pueda penetrar en él utilizando o bien una cuenta de usuario o bien un agujero de seguridad en alguna aplicación; pero con toda seguridad, esta probabilidad será bastante más baja a no realizar estos chequeos Documentación Por último, un aspecto deseable de nuestro proyecto sería generar la máxima documentación posible de todos aquellos hitos realizados. Implementaciones, ficheros de configuración, decisiones tomadas, etcétera. Todo aquello que podamos dejar por escrito siempre será bienvenido para poder ser consultado en un futuro bien por nosotros mismos o por la persona que se tenga que encargar de la administración de los Laboratorios en un momento dado. Dado que vamos a disponer de una página web para los Laboratorios, no será mala idea utilizar esa misma página web para poder almacenar toda la documentación que se ha ido generando a medida que los hitos se han ido completando. Una buena idea para almacenar esta información podría ser la utilización de un sitio web tipo wiki 1 que se pudiera editar usando el propio navegador, incluso por otros usuarios. Así, diversos usuarios encargados de la gestión del Laboratorio podrían visualizar y editar los contenidos en caso que lo creyeran oportuno. 1 Un wiki, o una wiki, es un sitio web cuyas páginas web pueden ser editadas por múltiples voluntarios a través del navegador web. Proyecto Fin de Carrera 32 Universidad Rey Juan Carlos

51 Capítulo 3 Especificación y Diseño Una vez puestas sobre la mesa todas las tecnologías, habiendo enumerado las posibles alternativas a cada una de ellas y establecido los objetivos que nos proponemos como base en el presente proyecto, en este capítulo vamos a enumerar todos los requisitos de una manera más formal. Debido a que este proyecto no se centra en el desarrollo de ningún producto software en particular, no se seguirá ninguna metodología de desarrollo en concreto, basándonos únicamente en la implementación y puesta en marcha de todos los servicios requeridos. En este capítulo enumeraremos los requisitos de cada una de las tres partes diferenciadas desarrolladas anteriormente. 33

52 3.1. METODOLOGÍA EMPLEADA 3.1. Metodología empleada El desarrollo de cualquier producto software se realiza siguiendo una determinada metodología o modelo de desarrollo, de manera que se realizan una serie de tareas entre la idea inicial y el resultado obtenido. El modelo de desarrollo escogido establece el orden en el que se han de afrontar las tareas en el desarrollo del proyecto, y nos provee de requisitos de entrada y salida para cada una de las actividades. Sin embargo, en este proyecto, al no desarrollarse ningún producto software en concreto (está centrado básicamente en la administración de sistemas) en este capítulo nos vamos a centrar en enumerar todos los requisitos funcionales y no funcionales de los que constaba nuestro desarrollo Análisis de requisitos El análisis de los servicios necesarios que deben estar funcionando en cada uno de los servidores (necesarios para el correcto funcionamiento del Laboratorio) se llevará a cabo mediante una lista de requisitos funcionales. Debido a que el proyecto se subdivide básicamente en tres partes claramente diferenciadas (construcción del proceso de instalación desatendido, implementación de un sistema de cuentas de usuario en red y creación de servicios de valor añadido para los usuarios) vamos a ver la lista de requisitos funcionales para cada una de estas tres partes por separado. Los requisitos se obtienen normalmente de los casos de uso, que a su vez describen la interacción del usuario y el sistema. En nuestro caso, vamos a establecer que el usuario es el usuario administrador (que puede considerarse como un nivel más elevado de usuario) y que el sistema es en cada caso cada una de las partes que nos proponemos desarrollar. Debido a que la interacción en cada caso es mínima, no vamos a describir los casos de uso (ni los diagramas ni la descripción del flujo de eventos en cada caso) ciñéndonos únicamente a la captura de requisitos Proceso de instalación desatendido A continuación vamos a enumerar la lista de requisitos que debe cumplir el proceso de instalación desatendido. En cuanto a los requisitos funcionales, cabría destacar: 1. RF1: El proceso debe facilitar la instalación de un sistema completo Ubuntu Linux, preferiblemente, en la versión Hardy (numerada como 8.04). 2. RF2: La interacción con el usuario en este proceso debe ser nula. El proceso de instalación debe ser completamente desatendido. En cuanto a los requisitos no funcionales (basados principalmente en las propiedades del sistema) podemos observar las siguientes: 1. RNF1: El sistema de instalación automática debe funcionar en plataformas Linux (tanto el sistema instalado, el cliente, como el sistema que provee la instalación, el servidor). 2. RNF2: Será necesario que el cliente posea la capacidad de realizar arranque por red en la placa base (comúnmente llamado PXE). 3. RNF3: El sistema debe cumplir unas condiciones mínimas de velocidad. Dado que el número de estaciones a instalar será elevado, es conveniente que se provea de algún espejo local de instalación, para que las latencias sean lo más pequeñas posibles y por tanto, el proceso de instalación no lleve mucho tiempo. Proyecto Fin de Carrera 34 Universidad Rey Juan Carlos

53 CAPÍTULO 3. ESPECIFICACIÓN Y DISEÑO Cuentas de usuario en red y disco en red Respecto al sistema de cuentas de usuario en red, podemos destacar los siguientes requisitos funcionales: 1. RF1: El sistema de cuentas de usuario en red debe facilitar la autenticación de usuarios del sistema, en todas aquellas máquinas que conformen nuestro sistema, a través de un nombre de usuario y una contraseña, o palabra de paso. 2. RF2: El sistema debe autenticar a los usuarios independientemente de la máquina en la que se encuentren y de forma independiente, es decir, un usuario puede iniciar su sesión al mismo tiempo en tantas máquinas como desee. 3. RF3: El sistema debe permitir la creación de nuevas cuentas de usuario (por parte de un administrador o una cuenta privilegiada). 4. RF4: El sistema debe permitir que un usuario pueda cambiar su palabra de paso (no será posible cambiar su nombre de usuario). 5. RF5: El sistema debe proveer un directorio personal para el usuario donde poder almacenar sus ficheros personales, una vez que haya iniciado su sesión. Este espacio permitirá que los alumnos puedan almacenar sus prácticas en el servidor, y que puedan ver estos ficheros y directorios independientemente de la máquina en la que hayan iniciado su sesión. En cuanto a los requisitos no funcionales de este elemento del sistema, podemos destacar los siguientes: 1. RNF1: En cuanto al Sistema Operativo usado para implementar el sistema de autenticación, éste debe ser un Sistema Operativo Debian GNU/Linux, a ser posible, en la última versión estable. 2. RNF2: En cuanto al sistema de cuentas de usuario en red, éste debe estar basado en un directorio LDAP, que estará implementado por el software OpenLDAP, en su última versión estable también a ser posible. 3. RNF3: En cuanto a requisitos de seguridad, debemos procurar en la medida de lo posible que siempre que los datos de usuario viajen por la red, éstos deben encontrarse cifrados utilizando técnicas avanzadas de criptografía, que haga muy difícil que un usuario no autorizado pueda capturar estos datos y obtener una cuenta de usuario de forma ilegítima. 4. RNF4: En cuanto a aspectos avanzados de tolerancia a fallos, replicación, división de carga y demás, se debe procurar en la medida de lo posible que el sistema sea tolerante a fallos (deben duplicarse aquellos recursos que sean necesarios), el sistema sea escalable (se debe realizar un reparto de carga adecuado) y se pueda realizar una recuperación rápida ante cualquier tipo de desastre (se deben realizar copias de seguridad diarias de los datos de autenticación de los usuarios) Servicios de valor añadido Por último vamos a poner en marcha una serie de servicios de valor añadido que van a ayudar a que el entorno sea más agradable y funcional de cara a los usuarios. Dado que estos servicios son opcionales, de cara a que el uso del entorno por parte de los usuarios sea más agradable y sencillo, plantearemos en su mayoría requisitos funcionales, que serán normalmente requisitos recomendados y que no estén del todo definidos, dejando al administrador la elección de la plataforma, sistema en concreto, etcétera. A. Gutiérrez Mayoral 35 ETSI Informática

54 3.3. DEDICACIÓN DE LAS MÁQUINAS FÍSICAS 1. RF1: Se debe poner en marcha un sistema de correo que permita que los usuarios propietarios de una cuenta en el sistema puedan recibir correo (posean un buzón de correo en el servidor donde recibir mensajes). Este sistema permitirá que podamos comunicarnos con los usuarios del sistema para indicarles cualquier asunto relacionado con su cuenta. 2. RF2: El entorno debe contar con una página web, donde se indique el nombre de los Laboratorios, y a ser posible se documente la mayor información posible acerca del funcionamiento interno de los mismos (horarios, normas internas de funcionamiento, recomendaciones, preguntas de uso frecuente sobre el uso del sistema, donde acudir si existe algún problema, etcétera). También debe facilitar que los alumnos puedan colgar sus propias páginas web, mediante la inclusión de algún directorio en su espacio de disco personal. Esto permitirá que puedan generar documentación sobre las asignaturas y puedan compartirla en Internet. 3. RF3: Es recomendable que se implemente algún mecanismo de listas de correo que permita la gestión de anuncios a los usuarios del sistema, así como la comunicación interna de los responsables del Laboratorio. Además, las listas de correo pueden ser usadas para enviar notificaciones relativas al funcionamiento interno del sistema (alertas sobre caídas en servicio, por ejemplo). 4. RF4: Debe implantarse un sistema de monitorización y notificación de todos aquellos servicios que sean vitales para el correcto funcionamiento del Laboratorio. Este servicio debe alertar inmediatamente de cualquier caída en cualquiera de los servicios que impida que el Laboratorio pueda funcionar adecuadamente. Es recomendable que este servicio posea una interfaz web de cara al administrador y a los usuarios, que permita visualizar el estado de las estaciones y de los servidores. Como requisitos no funcionales, únicamente vamos a reseñar lo siguiente: 1. RNF1: se debe intentar en la medida de lo posible garantizar la seguridad en el entorno. Esto incluye la instalación de todas aquellas herramientas de detección de intrusos, seguridad y toma de decisiones relativas a la instauración de políticas de seguridad que impidan al máximo que un usuario pueda obtener una cuenta de usuario de forma ilegítima o penetrar en alguno de los servidores críticos para el funcionamiento del Laboratorio Dedicación de las máquinas físicas Una vez establecidos los requisitos de manera semiformal, vamos a establecer la división de cada uno de los subsistemas principales entre las máquinas que tenemos disponibles. En principio en el Campus de Móstoles contamos con aproximadamente siete máquinas que pueden actuar como servidores en los cuales se instalarán los servicios más importantes que darán servicio al Laboratorio. En el Campus de Fuenlabrada contamos solamente con dos servidores. La razón de esta diferencia en cuanto a número de servidores se debe a que inicialmente los Laboratorios de Linux comenzaron su andada en el Campus de Móstoles, mientras que el Campus de Fuenlabrada (que presta servicio principalmente a asignaturas que se imparten en la titulación de Ingeniería de Telecomunicaciones) ha comenzado hace poco, y continua ampliándose actualmente. En el Campus de Móstoles contamos con las máquinas peloto, zipi, zape, lechuzo, sapientin, pantuflo y espatula. Como se puede observar, los nombres de los servidores de este campus pertenecen a personajes del cómic Zipi y Zape, de Escobar. Como vimos en el capítulo Introducción, el Sistema Operativo elegido para los servidores será el Sistema Operativo Debian GNU/Linux, en su versión 4.0 (la última versión estable, código Etch). Proyecto Fin de Carrera 36 Universidad Rey Juan Carlos

55 CAPÍTULO 3. ESPECIFICACIÓN Y DISEÑO Peloto La máquina peloto poseerá la dirección IP , y albergará el servidor LDAP de cuentas de usuario de forma primaria (esto es, el servidor LDAP alojado en esta máquina será el encargado de realizar escrituras en el directorio LDAP (en caso de que se produjeran). Además, albergará un mirror o espejo de los repositorios de Debian y de Ubuntu, para que las instalaciones de software en el Laboratorio sean más rápidas Zipi La máquina zipi poseerá la dirección IP y albergará el servidor LDAP en forma secundaria. Es uno de los servidores secundarios del directorio LDAP en el Laboratorio, además de otros servicios. En concreto la máquina zipi albergará el servidor DNS del laboratorio de forma primaria, aunque en este documento no ha quedado detallado este servicio Zape La máquina zape posee la dirección IP y es el segundo de los servidores secundarios de LDAP en el Campus de Móstoles. Junto con los otros dos servidores LDAP existentes en el Campus de Móstoles conforman el conjunto de los servidores de autenticación para este Campus. Como veremos posteriormente en el capítulo Implantación, la división del servicio de autenticación en diferentes máquinas nos va a garantizar la fiabilidad, escalabilidad y tolerancia a fallos del servicio. En concreto esta máquina, también alberga otro servicio no detallado en este documento, que es el de resolución de nombres DNS (la máquina zape alberga de forma secundaria el servicio DNS para el Laboratorio) Lechuzo La máquina lechuzo posee la dirección IP y es una máquina crítica para el correcto funcionamiento del Laboratorio, ya que alberga el servicio de almacenamiento de ficheros en red para los usuarios. A través de este servicio los usuarios al iniciar la sesión disponen de un espacio personal en el que almacenar sus ficheros personales (prácticas, documentos, etcétera). Por supuesto, se trata de un servicio distribuido y en el que independientemente de la estación en la que inicien la sesión, dispondrán de los mismos ficheros. Como vimos en el capítulo Introducción, la solución adoptada para implementar este servicio se basa en el sistema de ficheros NFS de Linux. Aunque este servicio se encuentra duplicado (en la máquina sapientin) el cese en el funcionamiento de esta máquina provocaría que los usuarios, aún pudiendo iniciar su sesión en cualquier estación del Laboratorio, no pudieran acceder a sus ficheros personales (la autenticación y el disco en red son servicios en principio independientes el uno del otro). Es por ello que el funcionamiento de esta máquina es crítico para el funcionamiento del Laboratorio, y debe ser monitorizada constantemente para ser alertados en el preciso instante en el que se produzca cualquier problema Sapientin La máquina sapientin posee la dirección IP y en cuanto a servicios, podemos decir que es una réplica exacta a la máquina lechuzo. Esta máquina dispone de un servicio de disco en red (usando para ello el sistema de ficheros NFS de Linux) y posee una copia exacta de A. Gutiérrez Mayoral 37 ETSI Informática

56 3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA los ficheros personales de los usuarios que se encuentran alojados en la máquina lechuzo. Para ello, todas las noches se sincronizan ambos directorios desde lechuzo hasta sapientin. Si se produce cualquier tipo de problema en la máquina lechuzo que no sea recuperable en un periodo corto de tiempo (imaginemos que se rompe un disco en la máquina lechuzo pero el Laboratorio debe seguir prestando servicio), esta máquina comenzará a prestar servicio de disco en red como lo estaba haciendo lechuzo. En principio, las probabilidades de que esta máquina llegue a usarse son realmente bajas. Para que se deje de usar la máquina lechuzo han de estropearse al menos dos discos en lechuzo, debido a que el espacio en disco se implementará usando una solución basada en RAID, como veremos posteriormente en el capítulo de Implantación. En cualquier caso, siempre es necesario disponer de una máquina de recambio para que el servicio pueda seguir funcionando en cualquier caso ante cualquier tipo de desastre Pantuflo La máquina pantuflo posee la dirección IP y tradicionalmente ha sido la máquina visible de los Laboratorios de Linux de la Escuela. Antiguamente (en los primeros años de existencia de la Escuela, allá por el año 1999) era el único servidor que existía: prestaba servicio de autenticación, disco en red, página web, correo, servía para que los usuarios (alumnos y profesores) se conectaran e hicieran las prácticas, etcétera. Afortunadamente, los tiempos han cambiado y con la adquisición de nuevos servidores dedicados en exclusiva a servicios críticos para el Laboratorio (autenticación, disco en red, etcétera) la máquina pantuflo ha sido relegada a ser únicamente la máquina visible o buque insignia de los Laboratorios de Linux. Esta máquina, solamente prestará servicio de página web para los Laboratorios, web personales de los alumnos, y albergará el sistema de correo para los usuarios. La razón de albergar el sistema de correo y página web en esta máquina, es que los alumnos ya asocian la máquina pantuflo con los Laboratorios de Linux, de forma que para ellos es muy fácil recordar (o averiguar) que la página web se encuentra en la dirección o que las cuentas de correo del servidor terminan Además, vamos a aprovechar esta máquina para albergar las listas de correo del servidor, lo que nos va a permitir crear un canal directo de comunicación entre todos los usuarios de los Laboratorios (para enviar notificaciones, noticias y notas de régimen interno sobre el funcionamiento de los Laboratorios) Espatula Por último, la máquina espatula, con dirección IP servirá para albergar los diferentes ficheros de preconfiguración de las instalaciones desatendidas que desarrollaremos posteriormente en el capítulo Implantación. Además, en esta máquina instalaremos el servicio de monitorización que nos servirá para comprobar el estado de la red en todo momento, y que enviará alertas en forma de correo electrónico cuando se produzca algún problema en cualquiera de los servidores o de los servicios críticos para el funcionamiento del Laboratorio. En principio en esta máquina no alojaremos ningún servicio más Servidores disponibles en el Campus de Fuenlabrada A diferencia del Campus de Móstoles, en el Campus de Fuenlabrada únicamente se dispone de dos servidores principales, que asumen las labores de autenticación de usuarios y de disco en red. Bien es cierto que el número de estaciones en este campus es bastante menor que el de Móstoles (160 estaciones en el Campus de Móstoles frente a unas 100 aproximadamente en el Campus de Fuenlabrada), aunque debido a que este número está aumentando considerablemente, se prevee Proyecto Fin de Carrera 38 Universidad Rey Juan Carlos

57 CAPÍTULO 3. ESPECIFICACIÓN Y DISEÑO que el número de servidores en el Campus de Fuenlabrada también aumente. De momento, los dos servidores de los que se dispone son bilo y nano. Estos nombres están inspirados en la tira de cómic del mismo nombre, Bilo y Nano, personajes creados por Javier Malonda. Debido a que el número de servidores en este campus es menor, será inevitable reunir servicios en una misma máquina Bilo La máquina bilo, posee la dirección IP Es la máquina análoga a pantuflo para el Campus de Fuenlabrada, es decir, albergará el servicio de página web para ese laboratorio, así como las páginas personales de los usuarios, el servicio de correo y la lista de correo de usuarios para este Campus. Además, albergará el servicio de disco en red para los laboratorios de este Campus (debido a que solamente poseemos dos servidores, es inevitable que una sea la que sirva el disco en red y la otra la tengamos de repuesto ante posibles catástrofes) Nano La máquina nano posee la dirección IP y tiene asociados dos servicios críticos. Por un lado, es un servidor secundario para el servicio de directorio LDAP (el servicio de cuentas de usuario en red) y por otro lado, sirve de máquina de repuesto ante cualquier caída en el servicio de disco en red que provee la máquina bilo (al igual que la máquina sapientin en el Campus de Móstoles). Como se puede apreciar, disponemos de un único servicio de directorio LDAP que da servicio a ambos campus, el de Móstoles y el de Fuenlabrada. Por motivos de operación, el servidor primario para este servicio se encuentra alojado en el Campus de Móstoles (debido a que nuestra localización física en la Universidad se encuentra en el Campus de Móstoles, resulta más cómodo tenerlo en este campus). Por el contrario, el servicio de disco en red se ofrece de forma independiente entre ambos campus, cada uno dispone de su disco particular y de sus ficheros. Evaluados en este capítulo los requisitos funcionales y no funcionales de cada una de las tres partes en las que se divide este proyecto, y diseñados y divididos por servidores todos los servicios que nos proponemos construir e implementar, en el siguiente capítulo detallaremos todos los detalles técnicos que son necesarios para la puesta en marcha de todos los servicios. A. Gutiérrez Mayoral 39 ETSI Informática

58 3.4. SERVIDORES DISPONIBLES EN EL CAMPUS DE FUENLABRADA Proyecto Fin de Carrera 40 Universidad Rey Juan Carlos

59 Capítulo 4 Implantación Una vez llegados a este punto, nos ponemos manos a la obra para llevar a cabo uno por uno cada uno de los objetivos que nos propusimos en los capítulos Objetivos y y Diseño. En primer lugar, arrancaremos formalizando e implementando un proceso completo de instalación desatendida. Este proceso, nos facilitará la tarea de realizar instalaciones masivas en poco tiempo y con muy poco esfuerzo. Una vez completada esta tarea, pasaremos a implementar cada uno de los servicios de los que se compone el entorno. En primer lugar, y como servicios indispensables, un mecanismo de autenticación que permita a los usuarios poder usar tanto los terminales como los servidores oportunos. De forma paralela, un servicio de disco en red que permita tener disponible almacenar sus ficheros en el entorno distribuido. A continuación, iremos completando la implementación con más servicios, que sin ser del todo indispensables, son necesarios para que el entorno funcione adecuadamente. Estos servicios (Web, correo electrónico, resolución de nombres, listas de correo, etcétera) quedarán totalmente implantados y funcionando correctamente a la finalización del presente capítulo. 41

60 4.1. HERRAMIENTA DE INSTALACIÓN AUTOMÁTICA 4.1. Herramienta de Instalación Automática Cuando se dispone de un número muy elevado de estaciones o terminales se hace necesario el disponer de un método de instalación desatendida para que tanto la instalación del Sistema Operativo como de todo el software se haga de la forma más automática posible. Para llevar a cabo esta tarea, se va a utilizar el método de los ficheros de preconfiguración de Debian, como se estudió en el capítulo Introducción. Esta técnica no es nueva, y viene introducida desde la versión 3.0 de Debian GNU/Linux. Como vimos en la sección Estado del arte, esta técnica se basa en la inclusión de las respuestas a todas las preguntas del proceso de instalación de Debian GNU/Linux o de Ubuntu, en nuestro caso. Si dejamos alguna cuestión sin especificar, el instalador nos preguntará de forma interactiva sobre ella. Como es obvio, cuantas más preguntas queden respondidas en este fichero, más automatizado y por tanto desatendido será el proceso. Las preguntas respondidas en este fichero, pueden o deben ser las siguientes, por ejemplo: Configuración de la red (dirección IP, puerta de enlace predeterminada, servidores de nombres DNS. Configuración de la versión de Ubuntu a ser instalada (por ejemplo, la actual 8.04, Ubuntu Hardy). Sitio réplica que debe usarse para instalar la distribución a través de la red (nuestro mirror local). Disco duro donde será instalado el Sistema Operativo. Particionado específico (novato, experto, usual). Configuración de la zona horaria. Configuración de la herramienta de gestión de software (apt-get). Contraseña del superusuario (root) y creación de un usuario sin privilegios. Por último, ejecución de un script de postinstalación para personalizar la estación a nuestro gusto. Como es frecuente en las instalaciones de las últimas versiones de Ubuntu, la mayoría de las preguntas de la lista anterior son las correspondientes a las del proceso de instalación, y que dejándolas todas resueltas, el proceso de instalación se realizará completamente en silencio, sin realizar ninguna cuestión al usuario y de forma totalmente desatendida. Este fichero de preconfiguración debe ser incluido en el CDROM de Ubuntu con el que se pretenda instalar el sistema 1. Bastará con colocar el fichero de texto en el raíz del sistema de ficheros del CDROM y modificar algunas líneas del fichero isolinux para poder en marcha nuestra solución. Para ello, podemos descargar la versión actual de Ubuntu, montar la imagen ISO como un sistema de ficheros de loopback, copiar y modificar los ficheros correspondientes y volver a generar la ISO. Una vez hecho esto, podemos grabar nuestro CD personalizado de Ubuntu y proceder a realizar el proceso de instalación de Ubuntu. 1 Recomendamos la consulta del apéndice o los ficheros incluidos en el CDROM adjunto para leer un fichero de preconfiguración de ejemplo básico. Proyecto Fin de Carrera 42 Universidad Rey Juan Carlos

61 CAPÍTULO 4. IMPLANTACIÓN Listado 4.1: Generación de un CD personalizado de Ubuntu para instalación automática 1 # Descargamos una imagen mínima de Debian o Ubuntu 2 $ wget 3 # Montamos el CD de Ubuntu 4 $ mkdir /mnt/nueva_imagen 5 # copiamos el preseed 6 $ mount -o loop -t iso9660 $imagen_base / mnt/ nueva_imagen 7 # Creamos un directorio para la nueva imagen 8 $ mkdir / copia_imagen 9 # Copiamos todo el contenido 10 $ cp -arv /mnt/$nueva_iso /copia_imagen 11 # Se modifica el fichero Isolinux, situado en 12 # /copia imagen/nueva iso/isolinux/isolinux.cfg 13 # Copiamos el fichero de preconfiguracion creado previamente 14 $ cp preseed.cfg /copia_imagen/$nueva_iso/. 15 # Se regenera la ISO y se graba mediante Cdrecord, por ejemplo 16 $ mkisofs -v -J -R -T -V nueva_imagen -b isolinux/isolinux.bin -c boot.cat 17 -no-emul-boot -boot-load-size 4 -boot-info-table 18 -o nueva_imagen. iso / copia_imagen/ nueva_imagen Pero, tenemos que insertar nuestro CDROM 160 veces, y expulsarlo otras 160? No existe algún proceso más corto? Efectivamente, lo hay. Si nuestro hardware es relativamente moderno, y nos permite realizar arranque por red, podemos realizar una instalación completa a través de la red, sin tan siquiera tener que insertar nuestro CD en el equipo correspondiente. De esta forma, incluso podemos indicar que nuestro fichero de preconfiguración, se encuentra en una URL concreta. Esto nos abre la puerta a un mundo de posibilidades: podemos tener un repositorio de preconfiguraciones en un servidor concreto, siempre disponible para poder servir instalaciones de equipos. Para llevar a cabo este proceso, es necesario la puesta a punto de unas cuantas herramientas. Suponemos por supuesto que nuestra placa base permite el arranque del sistema a través de red (usualmente llamado PXE 2. Hablaremos de ello en adelante. De forma implícita, necesitamos un despachador de direcciones IP automáticas, esto es, un servidor DHCP Servidor DHCP para configuración automática de Red Como hemos visto anteriormente, si queremos que nuestras instalaciones automáticas se realicen a través de la red, sin tan siquiera introducir un CDROM de instalación, necesitamos la puesta a punto de un servidor DHCP. Este servidor configurará automáticamente la red de la estación que lo solicite, habilitándola para poder descargar tanto el Sistema Operativo como todas aquellas herramientas o ficheros de configuración que consideremos oportunos. Nuestro servidor DHCP se puede encontrar en cualquier servidor que tengamos en nuestra Intranet. No es necesario que se encuentre en el mismo servidor donde se encuentre el sitio réplica de la distribución de Linux a instalar ni tampoco en el servidor donde se encuentre el fichero PXE que se descargará para comenzar la instalación del Sistema Operativo. Un servidor DHCP: dhcpd Si estamos usando Ubuntu o en su defecto Debian, una llamada al instalador de software apt-get será suficiente para instalar rápidamente un servidor DHCP. $ apt-get install dhcp Listado 4.2: Instalación del paquete dhcp a través de apt-get 2 PXE son las siglas de Preboot Execution Environment, o Entorno de preejecución. 3 DHCP son las siglas de Dynamic Host Configuration Protocol, o Protocolo de Configuración dinámica de huésped. A. Gutiérrez Mayoral 43 ETSI Informática

62 4.1. HERRAMIENTA DE INSTALACIÓN AUTOMÁTICA Es probable que la herramienta de configuración e instalación de paquetes dpkg solicite configuración para el citado paquete (por ejemplo el rango de direcciones IP que se va a despachar automáticamente). En nuestro caso, procedemos a configurar manualmente editando el fichero de configuración que encontramos en /etc/dhcpd.conf. Es necesario especificar algunos parámetros correspondientes a la configuración de la subred que estemos usando en ese momento. Listado 4.3: Fichero de configuración dpchd.conf. Configuración de subred. 1 subnet netmask { 2 range ; 3 option broadcast- address ; 4 option routers ; 5 } Además, vamos a incluir una entrada para que el host beta01.pantuflo.es arranque automáticamente a través de la red: 1 host beta01 { Listado 4.4: Fichero de configuración dpchd.conf. Configuración de host. 2 hardware ethernet 00:0f:1f:e4:a9:20; 3 filename "pxelinux.0"; 4 next-server ; 5 fixed-address ; 6 } Vemos como a través de la dirección MAC 4, asignamos automáticamente la dirección IP del equipo especificando además que busque el fichero de arranque PXE en el servidor El fichero, se llama además pxelinux.0. Se recomienda que si el número de estaciones a instalar es muy elevado, se programe un pequeño script de shell (por ejemplo, en bash o sh) para automatizar la tarea de crear el fichero de configuración de DHCP. Bastaría solamente añadir la salida de este pequeño script al fichero de configuración de DHCP y reiniciar su demonio correspondiente Arranque por PXE El protocolo PXE (Entorno de preejecución) es un protocolo que permite el arranque de estaciones usando un interfaz de red, independientemente de los dispositivos de almacenamiento locales que se encuentren en el mismo. PXE fue introducido por Intel y está descrito en su especificación correspondiente 5 publicado por la propia Intel y Systemsoft, el 20 de Septiembre de Este protocolo hace uso de otros tantos protocolos de red (como IP) transporte (como UDP) y aplicación (como hemos visto, hace necesario el uso de DHCP para el arranque). A continuación veremos como es necesario que se use otro protocolo de la capa de aplicación, TFTP para poder descargar la imagen linux correspondiente que será arrancada para la instalación del Sistema Operativo. Como dijimos anteriormente, es necesario que nuestro hardware (tarjeta de red y placa base) incluya el uso de esta tecnología para poder hacer uso de ella. Normalmente a través de la herramienta de configuración de nuestra placa base podremos ver si se dispone de ella. 4 Es recomendable que si usa DHCP en su red, se asegure que solamente responde a aquellas estaciones que lo necesitan. El uso indiscriminado de DHCP puede producirle problemas a otros usuarios de su misma subred. 5 Actualmente en la versión 2.1 Proyecto Fin de Carrera 44 Universidad Rey Juan Carlos

63 CAPÍTULO 4. IMPLANTACIÓN Normalmente, para poder arrancar usando este protocolo, es necesario que durante el arranque de la estación correspondiente, se pulse una combinación de teclas (normalmente F12 o alguna otra tecla función) que llame a la ejecución del protocolo. Una vez arrancado, la tarjeta solicitará una petición DHCP a la subred para que ésta se autoconfigure. Configuración del servicio TFTP Por último, y para poder comenzar con la instalación del Sistema Operativo en cuestión, necesitamos una imagen del mismo y que de alguna forma, se pueda descargar de la red desde un servidor hacia la estación que se esté instalando en ese momento. Para ello, se hace uso de otro protocolo de la capa de aplicación, TFTP 6. TFTP es un protocolo de transferencia de ficheros muy similar a su familiar más cercano FTP 7. Este protocolo es muy usado cuando se quiere transferir archivos de pequeño tamaño entre estaciones de una misma subred. Nótese que el que este protocolo use el protocolo de transporte UDP no es una simple elección trivial: se asume que no se va a usar TFTP para transferir ficheros muy pesados o para realizar una trasnferencia entre subredes muy alejadas. Algunos detalles de TFTP son los siguientes: Utiliza UDP (puerto 69) como protocolo de transporte (a diferencia de FTP que utiliza el puerto 21 TCP). No puede listar el contenido de los directorios. No existen mecanismos de autentificación o cifrado. Se utiliza para leer o escribir archivos de un servidor remoto. Soporta tres modos diferentes de transferencia, netascii, octet y mail, de los que los dos primeros corresponden a los modos ascii e imagen (binario) del protocolo FTP. Podemos instalar un servidor TFTP en Debian GNU/Linux o Ubuntu a través del siguiente comando: $ apt-get install tftpd-hpa Listado 4.5: Instalación del servicio tfptd-hpa a través de apt-get Al igual que antes, el paquete solicitará configuración. Lo vamos a configurar como demonio, ejecutándose de forma independiente de inetd. Para ello, el fichero de configuración situado en /etc/default/tftpd-hpa contendrá las siguientes líneas: Listado 4.6: Fichero de configuración /etc/default/tfptd-hpa. 1 RUN_DAEMON =" yes" 2 OPTIONS="-l -s /var/lib/tftpboot" Vemos como en el fichero de configuración se indica que se servirán los ficheros situados por debajo del directorio /var/lib/tftboot. Esto nos servirá para incluir en este directorio la imagen de la distribución de Linux que vamos a instalar posteriormente. Para aplicar los nuevos cambios, basta con reiniciar el demonio correspondiente, tal y como muestra el listado de órdenes 4.7. /etc/init.d/tftpd-hpa restart Listado 4.7: Reinicio del demonio tftp 6 TFTP son las siglas de Trivial File Transfer Protocol (Protocolo de transferencia de archivos trivial). 7 FTP son las silgas de File Transfer Protocol (Protocolo de transferencia de ficheros). A. Gutiérrez Mayoral 45 ETSI Informática

64 4.1. HERRAMIENTA DE INSTALACIÓN AUTOMÁTICA Arranque por red de Linux Una vez que todas las herramientas anteriores se encuentran perfectamente configuradas y se encuentran funcionando, necesitamos una imagen concreta de la distribución de Linux que queremos instalar. En nuestro caso, necesitaremos una versión de Ubuntu de arranque por red. Esta imagen contendrá una imagen mínima del kernel de Linux que permitirá iniciar los dispositivos necesarios y comenzará el proceso de instalación. Podemos descargar una imagen mínima de arranque por red desde la página de Ubuntu Linux 8. En concreto, usaremos la versión de arranque por red de Ubuntu Hardy (8.04) que es la versión que instalaremos en el Laboratorio. Una vez que hemos descargado el fichero correspondiente, procedemos a descomprimirlo en el directorio raíz que sirve nuestro servidor TFTP, tal y como queda indicado en el listado 4.8. Listado 4.8: Descarga del kernel de arranque por red de Ubuntu Hardy $ wget main/installer-i386/current/images/netboot/netboot.tar.gz $ tar -xvzf pxeboot.tar.gz -C /var/lib/tftpboot/ Si todo va bien (nuestro servidor DHCP está funcionando correctamente y el servidor TFTP está sirviendo ficheros) al solicitar arranque por red en la pantalla de arranque de nuestra estación, debería auto configurarse la tarjeta según su IP correspondiente, y justo a continuación, ver la pantalla principal de Ubuntu Ficheros de preconfiguración A continuación, vamos a ver de qué manera podemos automatizar todo el proceso de instalación. A partir de un fichero de preconfiguración, que contiene todas las respuestas al proceso de instalación, podemos evitar que el programa de instalación de Ubuntu nos realice ninguna pregunta sobre la configuración del Sistema Operativo. Isolinux Isolinux 9 es un cargador de de arranque para Linux (arquitectura i386). Necesitamos editar el fichero de configuración de Isolinux para poder indicar que queremos cargar un fichero de preconfiguración. Esto lo podemos hacer de la siguiente forma: Listado 4.9: Fichero de configuración de Isolinux 1 LABEL instalacionautomatica kernel ubuntu-installer/i386/linux 3 append vga=normal initrd=ubuntu-installer/i386/initrd.gz netcfg/ choose_interface = eth1 locale = es_es 5 console-setup/ask_detect=false console-setup/layoutcode=es languagechooser/ language- name = Spanish countrychooser/ shortlist =ES 7 console- keymaps- at/ keymap =es netcfg/ get_hostname = unassigned- hostname preseed/url=http://minervo.escet.urjc.es/preseed -- Nótese el uso de la directiva preseed/url indicando que el fichero de preconfiguración es un recurso HTTP situado en la dirección indicada por la URL. Si quisiéramos haber incluido el fichero de preconfiguración directamente en la imagen mínima del kernel que se arranca con el proceso de instalación, deberíamos hacer uso de la directiva preseed/file, indicando la ruta absoluta hacia el fichero de semilla. El fichero de configuración de isolinux puede contener numerosas opciones de arranque (cada una forma una etiqueta LABEL). Podemos tener por tanto numerosas opciones de arranque, 8 https://help.ubuntu.com/community/installation/netboot 9 Proyecto Fin de Carrera 46 Universidad Rey Juan Carlos

65 CAPÍTULO 4. IMPLANTACIÓN cada una dependiendo por ejemplo de un hardware específico, o de unas opciones de instalaciones concretas. Si queremos que en cada momento se arranque siempre una instalación en concreto (una etiqueta LABEL) lo podemos hacer incluyendo las siguientes líneas: 8 DEFAULT instalacionautomatica 9 PROMPT 0 10 TIMEOUT 0 Listado 4.10: Fichero de configuración de Isolinux Donde indicamos que se debe arrancar por defecto la etiqueta instalacionautomatica, con un timeout de 0 segundos, y sin indicador de arranque. Fichero de preconfiguración Por último, únicamente nos queda empezar a definir el fichero de preconfiguración que utilizará el sistema de instalación automática para realizar el proceso de instalación en un modo no interactivo. Este fichero es un fichero de texto, visible y modificable por cualquier editor de textos. Podemos usar nuestro editor de textos favorito para poder editar nuestro fichero de preconfiguración personalizado. El fichero de preconfiguración contiene todas las respuestas a cada una de las secciones del proceso de instalación. Así, en vez de solicitar al usuario la entrada por teclado, la leerá de este fichero. Las opciones más importantes son las relacionadas con la red, el particionado del disco duro, la configuración de la herramienta de gestión de software, y la creación de usuarios. Mencionaremos las opciones más importantes, dejando la posibilidad de leer el fichero de preconfiguración completo en el apéndice de este documento. En primer lugar, debemos indicar las opciones necesarias para preconfigurar la red. En nuestro caso, nos es particularmente interesante que la preconfiguración se realice a través del protocolo DHCP. Esto nos facilitará que cada estación asuma la dirección de red que le pertenece. Una vez finalizado el proceso, podemos cambiar esta configuración de dinámica a estática, si así nos sentimos más seguros ante la caída del servidor DHCP y por ende el cese del funcionamiento de todas las estaciones. Esto lo podemos conseguir con las siguientes líneas: Listado 4.11: El fichero de preconfiguración preseed.cfg. 10 d- i netcfg/ choose_ interface select eth1 11 d- i netcfg/ disable_ dhcp boolean false 12 d- i netcfg/ confirm_ static boolean true Una vez hemos configurado la red, procedemos a indicar el sitio réplica de donde se descargará la imagen del sistema base a ser instalada. Es preciso indicar también que sistema deseamos instalar (versión concreta). Lo podemos indicar con el codename o nombre en clave de cada una de las versiones. En nuestro caso, vamos a instalar la vesión Hardy (numerada 8.04) de la distribución Ubuntu: Listado 4.12: El fichero de preconfiguración preseed.cfg. 12 d- i mirror/ country string enter information manually 13 d-i mirror/http/hostname string peloto.escet.urjc.es 14 d-i mirror/http/directory string /ubuntu/ 15 d- i mirror/ suite string hardy 16 d-i mirror/security-host peloto.escet.urjc.es A. Gutiérrez Mayoral 47 ETSI Informática

66 4.1. HERRAMIENTA DE INSTALACIÓN AUTOMÁTICA Tenga en cuenta que es interesante tener un mirror o espejo local en la Intranet para acelerar notablemente el proceso de instalación. Si por motivos de espacio no le es posible instalar un mirror completo de toda la distribución, puede usar la herramienta apt-proxy para evitar descargar un mismo paquete repetidas veces (una por estación). Notará una mejoría notable en el proceso de instalación. Una parte importante del proceso de instalación reside en la configuración del particionado del disco donde se ha de instalar el Sistema Operativo. Esto requiere de numerosas líneas de preconfiguración que indican entre otras cosas, que disco ha de usarse en la instalación (usando la nomeclatura clásica de sistemas Unix), que esquema de particionado se va a usar (para novatos, experto o con receta) y el esquema concreto que va a usarse. En nuestro caso, vamos a usar una receta 10 de partman (el programa que se encarga del particionado del disco para la instalación). Para ello, indicamos las siguientes líneas: Listado 4.13: El fichero de preconfiguración preseed.cfg. 16 d-i mirror/security-host peloto.escet.urjc.es 17 d-i partman-auto partman-auto/select_disk string /dev/sda 18 d-i partman-auto/disk string /dev/sda 19 d- i partman- auto/ method string regular 20 d- i partman- auto/ expert_ recipe string 21 boot-root :: ext3 22 $primary{ } $bootable{ } 23 method{ format } format{ } 24 use_filesystem{ } filesystem{ ext3 } 25 mountpoint{ / } % linux-swap 27 method{ swap } format{ } ext3 29 method{ format } format{ } 30 use_filesystem{ } filesystem{ ext3 } 31 mountpoint{ /data }. 32 d- i partman/ choose_ partition select Finish 33 partitioning and write changes to disk 34 d- i partman/ confirm boolean true En la etiqueta se indica una receta de partman. Como vemos, en ella se indica que se crearán tres particiones, todas ellas deberán ser formateadas, y el sistema de ficheros de todas ellas será (el sistema de ficheros más usado en particiones Linux). Se indican además los puntos de montaje de cada una de ellas, además como el tamaño (indicando el cilindro de comienzo y el de final). Se recomienda la lectura de las reglas de sintaxis para la formación de recetas para el particionador partman. Es necesario configurar el lenguaje predefinido del Sistema. Además, tenemos que configurar apt-get, la herramienta de gestión de paquetes de Ubuntu. También nos interesará que se use nuestro mirror local (situado en el servidor peloto.escet.urjc.es) y que además, se usen todas las secciones de las distribuciones 11. Esto lo conseguimos con las siguientes líneas: Listado 4.14: El fichero de preconfiguración preseed.cfg. 34 d- i languagechooser/ language- name- fb select Spanish 35 d-i debian-installer/locale select es_es.utf-8 10 Receta viene del término anglosajón recipe, muy usado en la comunidad Open source. 11 Usualmente, en las distribuciones Debian y Ubuntu el software incluido ha estado dividido en secciones. En Ubuntu existen principalmente cuatro: main, universe, multiverse, restricted y backports. Proyecto Fin de Carrera 48 Universidad Rey Juan Carlos

67 CAPÍTULO 4. IMPLANTACIÓN 36 d-i apt-setup/uri_type select http 37 d- i apt- setup/ country select enter information manually 38 d-i apt-setup/hostname string peloto.escet.urjc.es 39 d-i apt-setup/directory string /ubuntu/ 40 d-i apt-setup/another boolean false 41 d-i apt-setup/security-updates boolean false 42 d-i apt-setup/security_host string peloto.escet.urjc.es 43 d-i apt-setup/main boolean true 44 d-i apt-setup/universe boolean true 45 d- i apt- setup/ multiverse boolean true 46 d- i apt- setup/ restricted boolean true 47 d-i apt-setup/backports boolean true También nos interesa configurar la zona horaria del Sistema y su localización. Lo conseguimos con las líneas siguientes: Listado 4.15: El fichero de preconfiguración preseed.cfg. 47 d- i tzconfig/ gmt boolean false 48 d- i tzconfig/ choose_ country_ zone/ Europe select Madrid 49 d-i tzconfig/choose_country_zone_single boolean true Las cuales dependerán evidentemente de la localización de la estación que se instale en ese momento. A continuación, vamos a configurar el usuario genérico del sistema, que dispondrá de privilegios especiales por medio de la herramienta sudo para convertirse en superusuario: Listado 4.16: El fichero de preconfiguración preseed.cfg. 49 d- i passwd/ user- fullname string agutierr 50 d- i passwd/ username string agutierr 51 d-i passwd/user-password-crypted 52 d-i passwd $1$ascCqW. t$bfuofhdqlpbmpr9dorp. a0 La contraseña, como se puede observar, se introduce en claro (cifrada con un pequeño hash. Recomendamos la inclusión de una contraseña genérica y que una vez terminado el proceso, se sustituyan lo más rápido posible los ficheros /etc/passwd y /etc/shadow. En las líneas finales, indicaremos que, como última tarea, deseamos ejecutar un script descargado de Internet. A través de este script, realizaremos todas aquellas tareas que no no es posible configurar a través de esta herramienta de preconfiguración. En este script podremos instalar paquetes, retocar ficheros de configuración, tener en cuenta algunas particularidades específicas de hardware, etcétera. Esta aplicación es muy interesante, ya que nos permite dejar el sistema al gusto del administrador. Lo conseguimos con las líneas: Listado 4.17: El fichero de preconfiguración preseed.cfg. 52 d-i preseed/late_command string wget 53 instalacion/ ajusta- linux- mostoles; 54 chmod +x ajusta-linux-mostoles; sh ajusta-linux-mostoles Por último, indicamos donde se instalará el gestor de arranque. El gestor de arranque es necesario para poder iniciar el sistema una vez instalado. El gestor de arranque que se usa hoy en día es Grub, en detrimento de Lilo (LinuxLoader) que se usaba hasta hace muy poco en la mayoría de las distribuciones. Lo conseguimos con las siguientes líneas: A. Gutiérrez Mayoral 49 ETSI Informática

68 4.1. HERRAMIENTA DE INSTALACIÓN AUTOMÁTICA Listado 4.18: El fichero de preconfiguración preseed.cfg. 54 d-i finish-install/reboot_in_progress note 55 d- i grub- installer/ only_ debian boolean true 56 d-i grub-installer/with_other_os boolean true Preconfiguración genérica de paquetes El fichero de configuración mostrado anteriormente es válido para todas aquellas instalaciones basadas en la versión Hardy (8.04) de Ubuntu. Sin embargo, si se quiere usar este método en futuras versiones, es muy probable que la notación de la preconfiguración haya cambiado. El objetivo de este apartado es la de entender como funciona internamente la preconfiguración de un paquete, y poder usar este método para preconfigurar cualquier paquete en la instalación, sin necesidad de guiarnos por un método genérico (el fichero mostrado anteriormente). Es muy probable que si usamos este método en versiones posteriores a la usada en el presente documento, se introduzcan en la instalación nuevos paquetes (con su correspondiente configuración) que hagan que si éste no se encuentra preconfigurado (entiéndase por preconfigurado el que se indique en el fichero de preconfiguración todas las preguntas a su configuración) se muestre el diálogo del proceso de instalación instando a la persona que realiza el proceso de instalación a responder a las preguntas que sean necesarias. Comentábamos en el capítulo Introducción que sin duda una de las ventajas principales del método de instalación desatentida basada en ficheros de preconfiguración es que el proceso se realiza automáticamente, sin necesidad de realizar ninguna acción entre el administrador que instala el sistema y el proceso de instalación. Si bien responder a una pregunta o dos en el proceso de instalación no representa mayor molestia, si el número de instalaciones es elevado, el proceso puede llegar a convertirse en tedioso. Figura 4.1: El proceso de instalación en Debian/Ubuntu y la preconfiguración de paquetes. Si nos vemos en el papel de realizar una instalación desatendida basada en ficheros de preconfiguración y tenemos la mala suerte de que el fichero incluido en el apéndice de este documento no resulta completo frente a la preconfiguración de todos los paquetes que se instalan en el proceso de instalación del sistema, no tenemos que asustarnos, puesto que el método es muy simple. En primer lugar, debemos fijarnos en qué paquete está solicitando configuración Proyecto Fin de Carrera 50 Universidad Rey Juan Carlos

69 CAPÍTULO 4. IMPLANTACIÓN adicional. Para ello, podemos observar el título de la ventana de debconf, donde indica el paquete en cuestión. Por ejemplo, en la imagen 4.1 se muestra como el paquete slapd está solicitando configuración adicional. Una vez que hemos identificado el paquete molesto, debemos obtener sus fuentes para inspeccionar la plantilla de configuración. Para realizar este paso, podemos optar por diversas soluciones. Si se tiene configurada una línea de fuentes en el fichero /etc/apt/sources.list, simplemente una llamada a apt-src puede ser más que suficiente. En el listado 4.19 se muestra la llamada a este comando. Nótese que la llamada a apt-src no requiere privilegios especiales, y que la instalación resolverá todos aquellos paquetes necesarios, de los que depende el que se quiere instalar. Nuestro objetivo solamente será el paquete indicado en la llamada a apt-src, pudiendo obviar el resto. $ apt-src install slapd Listado 4.19: Instalación del paquete slapd a través de apt-get Una vez que las fuentes han sido descargadas, es necesario descomprimir el código fuente del paquete en busca del fichero templates. Este fichero en la mayoría de las ocasiones suele encontrarse en el directorio debian/ de las fuentes del paquete. En el caso del paquete slapd, el fichero mencionado se encontraría en el directorio openldap /debian/slapd.templates 12. Una vez que hemos localizado el fichero, podemos abrirlo con nuestro editor de texto favorito. Un párrafo del fichero puede ser el siguiente: Listado 4.20: El fichero de plantilla de debconf para el paquete slapd. 56 Template: slapd/ no_ configuration 57 Type: boolean 58 Default: false 59 _ Description: Omit OpenLDAP server configuration? 60 If you enable this option, no initial configuration or database will be 61 created for you. La lectura de este fichero es muy sencilla: en él se incluyen todas las preguntas que deben ser respondidas cuando se instala el paquete por primera vez, a través de la herramienta debconf. En el caso del fragmento del fichero anterior, se indica que se realiza una pregunta que solamente puede tener dos respuestas (de ahí el tipo booleano), que de forma predeterminada se responderá que No y que tiene la descripción indicada en las líneas siguientes. Si estuviéramos interesados en preconfigurar este paquete, deberíamos incluir una línea por cada pregunta que fuera incluida en la configuración del mismo. Para el caso de la pregunta anterior, sería suficiente que incluyéramos la siguiente línea: Listado 4.21: Preconfigurando el paquete slapd. 61 slapd slapd/ no_ configuration boolean false Con esto conseguiríamos que la pregunta anterior no se llevara a cabo, ya que se encuentra preconfigurada. Si realizamos este mecanismo para todas aquellas preguntas que interfieren en el proceso de instalación no dejando que sea un proceso desatendido al cien por cien, habremos conseguido que no sea necesario realizar ninguna acción para instalar el paquete en cuestión. Como vemos, la preconfiguración de paquetes es un método muy potente y flexible, que nos brinda la posibilidad de realizar procesos de instalación completamente desatendidos sin más 12 Fuentes del paquete slapd en la distribución Ubuntu Hardy. A. Gutiérrez Mayoral 51 ETSI Informática

70 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACIÓN que inspeccionar los ficheros de plantilla que requieren los paquetes que estemos interesados en instalar Protocolos situados en la capa de aplicación En esta sección se detallará cómo se ha llevado a cabo la implementación todos los protocolos que son necesarios para el correcto funcionamiento del entorno. Sin duda, los dos más importantes son el servicio de cuentas de usuario, y el servicio de disco en red. A través de estos dos protocolos los usuarios podrán iniciar su sesión en cada una de las estaciones y poder acceder a sus ficheros, independientemente de la estación en la que se encuentren Servidor LDAP de cuentas de usuario Un punto muy importante en cualquier sistema que se precie, es la gestión de los usuarios en red. Teniendo en cuenta que se trata de un sistema que va a soportar un número muy elevado de usuarios en línea, son muchos los factores a tener en cuenta. La implementación del servicio de cuentas de usuario se llevará a cabo mediante la gestión de un directorio de tipo LDAP, tal y como estudiamos en el capítulo Introducción, donde realizamos una comparativa de las diferentes tecnologías para llevar a cabo una implementación de cuentas de usuario en red. Instalación del servicio LDAP Una vez comentadas las motivaciones principales que nos convencieron a proceder al cambio de los protocolos NIS a LDAP, vamos a proceder a meternos en harina detallando cuales son los pasos necesarios para poder implementar un entorno de autenticación segura basado en el protocolo LDAP. En primer lugar, necesitamos por supuesto uno o más servidores LDAP. Cabe reseñar en cuanto a la nomenclatura usada, que el término LDAP hace referencia al protocolo, descrito por la RFC 13 correspondiente 14 ; mientras que existen aplicaciones con diferentes licencias que implementan el citado protocolo. Una de las más usadas hoy en día en la mayoría de servidores Unix y Linux (además de otros Sistemas Operativos de la familia Unix) es OpenLDAP, un software que proporciona un servidor basado en el protocolo LDAP. En nuestro caso, será el que usemos. Como comentamos en el capítulo de diseño, en los servidores del entorno se usará la distribución Debian GNU/Linux, en versión estable (actualmente, la 4.0 con código Etch). La instalación de la aplicación OpenLDAP en una distribución Debian es realmente sencilla, y se basa en una llamada muy simple a su herramienta de instalación de Software, como queda reflejado en el listado $ apt-get install slapd Listado 4.22: Instalación del paquete slapd a través de apt-get En Debian, y en la mayoría de distribuciones Linux, la aplicación OpenLDAP se provee a través del paquete slapd. La instalación del paquete resolverá aquellas dependencias que se consideren oportunas para que el servidor pueda funcionar adecuadamente. En el proceso de instalación del paquete, es necesario responder a algunas preguntas relativas a la configuración del paquete en el entorno en el que va a ser instalado. Algunas de ellas son cuál 13 RFC son las siglas de Request for comments, documentos que describen detalladamente el comportamiento de un protocolo. 14 Proyecto Fin de Carrera 52 Universidad Rey Juan Carlos

71 CAPÍTULO 4. IMPLANTACIÓN será la raíz del directorio LDAP, la contraseña del administrador, la elección del sistema gestor de base de datos que almacenará los datos del directorio y poco más. En nuestro caso, hemos decidido que: La raíz del árbol LDAP se identifique mediante la cadena siguiente: dc=zipi,dc=escet,dc=urjc,dc=es. Este nombre se debe a la notación de los nombres de las máquinas usado en la Universidad. El tipo de base de datos que almacenarán los datos del directorio será DBD. La contraseña de administrador de LDAP es un dato que queda privado de cara al administrador del sistema. Una vez que hemos decidido estos parámetros, el servidor queda instalado, y se inicia en el puerto estándar de LDAP: el puerto 389. Este puerto recibirá las peticiones de los clientes sobre consultas al directorio LDAP: en texto claro. Cualquier usuario que tenga acceso a la red podrá escuchar estas peticiones y averiguar datos sensibles (muy sensibles, como la contraseña de su cuenta, por ejemplo) de los usuarios. Es por tanto, que nuestra primera tarea avanzada será securizar el servidor de cara a crear conexiones seguras entre los clientes y el servidor LDAP. El protocolo LDAP: conceptos básicos Hasta el momento hemos detallado como se lleva a cabo la instalación básica de un servidor LDAP. Sin embargo, no sabemos hasta el momento como funciona realmente este protocolo. Vamos a realizar una descripción técnica muy breve de cómo se organizan los datos en un servidor LDAP y cómo funciona éste realmente (a grandes rasgos). Sin duda, estas explicaciones son fundamentales de cara a mejorar la funcionalidad del servidor, poder agrupar los datos en organizaciones o subárboles, y dotar al servidor de aspectos avanzados como son la replicación y el reparto de carga. Como hemos dicho, LDAP proporciona servicios de directorio: una base de datos centralizada de información esencial sobre personas, usuarios, grupos de usuarios, etcétera. Puesto que cada organización se estructura de una forma y su definición de información esencial puede ser muy distinta, un servicio de directorio debe ser muy flexible y personalizable. El eje fundamental de un servicio de directorio es proporcionar un mapa de distribución de una compañía, en este caso, de una organización de los usuarios de una Universidad. Una de las características más visibles de una estructura de base de datos LDAP es la convención en los nombres que se usa: es fundamental llevar a cabo una convención de nombres que identifique la estructura organizativa de la empresa u organización que se quiere representar antes de configurar el servidor. Este sistema, puede resultar muy parecido y similar al Sistema de Resolución de nombres DNS, en el que cada compañía debe encajar en un único nombre de dominio de primer nivel, pudiendo crear por debajo multitud de nombres dependiendo de la estructura de servicios de la empresa. En este sentido la organización de los nombres en una base de datos LDAP es muy similar. En una base de datos LDAP, la organización se estructura en forma de árbol, en el que existe una raíz o elemento superior que se crea en el momento de la instalación (este parámetro se corresponde cuando la configuración del servidor nos preguntaba acerca de la raíz del árbol). Por debajo, se encuentran los elementos de información llamados nodos, los cuales deben pertenecer a un tipo concreto. Este tipo, es llamado el elemento estructural del nodo, que en principio, no tiene porqué ser uno solamente, sino que pueden ser varios. Existen varios tipos predefinidos que pueden ser usados para representar elementos de información comúnmente usados hoy en día: para almacenar la información de una persona, podemos usar el tipo person, para almacenar la A. Gutiérrez Mayoral 53 ETSI Informática

72 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACIÓN información de una cuenta de usuario en un sistema Unix, podemos usar el tipo posixaccount, mientras que para poder representar la información de un grupo en un sistema Unix, se facilita el tipo posixgroup. Una vez que el tipo de un nodo queda establecido, podemos asignar valores a los atributos que nos facilita ese tipo estructural. Parece razonable que si un elemento posee el tipo posixaccount, se pueda saber el nombre de usuario, su UID, el grupo al que pertenece, su gecos, y seguramente algunos campos más. Sin embargo, si un objeto posee la estructura posixgroup, seguramente nos baste con saber el nombre del grupo y su identificador numérico. Podemos decir que cada objeto que exista en el directorio LDAP va a constar de una serie de tipos estructurales a los que pertenece, además de un nombre o identificador que va a posicionar al elemento en un punto concreto del directorio. Este nombre se denomina nombre distinguido o distinguished name. Dependiendo del punto en el que se encuentre el objeto dentro del árbol, este tendrá un dn diferente a otro. Normalmente, el dn se construye concatenando la sucesión de nodos por los que es necesario pasar para poder llegar al objeto, de forma muy similar al servicio de nombres DNS. Existen tipos predefinidos que se facilitan para poder agrupar elementos, y poder así crear organizaciones dentro del árbol. Normalmente, estos tipos reciben el nombre de unidad organizativa o organizational unit. A través de estos elementos estructurales, podremos agrupar elementos finales (como cuentas de usuario, por ejemplo) en diferentes subárboles, como veremos a continuación. La jerarquía de nuestro directorio LDAP Una vez llegados a este punto, es necesario decidir cómo estará estructurado el directorio LDAP donde se encontrarán las cuentas de los usuarios de nuestro sistema. Para empezar, debemos decidir cuales son las diferencias entre los tipos de usuario que vamos a almacenar en nuestro directorio, que se detallan a continuación: En primer lugar, necesitamos almacenar cuentas de usuario de dos tipos, fundamentalmente: estudiantes que cursan asignaturas (normalmente, pertenecientes a titulaciones de grado y postgrado) y profesores que imparten estas asignaturas. Los estudiantes pueden pertenecer al Campus de Móstoles (Escuelas de Ciencias Tecnológicas e Informática) o al Campus de Fuenlabrada (Escuelas de Telecomunicación y Facultad de Comunicación Audiovisual). Sin embargo, los profesores que imparten las asignaturas, suelen pertenecer al Campus de Móstoles (al menos, su localización geográfica se encuentra en Móstoles) y pueden impartir asignaturas en un campus, o en ambos. Además, es preciso saber de cada alumno, el año en el que obtuvo la cuenta, sin importar en principio la asignatura para la que la usa (ya que en cada carrera, suele usarse en diferentes asignaturas). Con estas premisas, se ve claramente que los profesores, deben poder usar su cuenta en ambos campus (no se hace distinción entre los profesores de Fuenlabrada y los profesores de Móstoles) y que las cuentas de los alumnos de cada campus deben estar organizadas o separadas por el campus al que pertenecen. Además, es muy probable que un profesor pueda acceder a recursos o a máquinas a las que no pueden acceder los alumnos estudiantes. Es por ello que una vez más, deberemos separar muy bien esta organización en el esquema del árbol LDAP. Podemos ver una primera versión de esta jerarquía en la imagen 4.2. En ella vemos como la raíz del árbol LDAP Proyecto Fin de Carrera 54 Universidad Rey Juan Carlos

73 CAPÍTULO 4. IMPLANTACIÓN contiene dos nodos principales, en los que se crean dos unidades organizativas: los alumnos por un lado, y los profesores por otro. dc=admin,dc=zipi,dc=es cet,dc=urjc,dc=es ou=alumnos,dc=zipi, dc=escet,dc=urjc,dc= es ou=profesores,dc=zipi, dc=escet,dc=urjc,dc=e s Figura 4.2: La raiz del árbol LDAP contiene dos unidades organizativas principales: alumnos y profesores. Si nos centramos en la unidad organizativa de alumnos, debemos tener en cuenta que éstos pueden pertenecer a dos campus: al campus de Móstoles, o al campus de Fuenlabrada. Es por ello, que decidimos de la misma forma representar esta división en el árbol LDAP en forma de dos unidades organizativas, como se puede ver en la imagen 4.3. Figura 4.3: La unidad organizativa de alumnos se subdivide a su vez en otras dos: alumnos de Móstoles y alumnos de Fuenlabrada. Por el contrario, en el grupo de profesores, no es necesario realizar ninguna distinción adicional: podemos decir que todos los profesores se deben encontrar en el mismo nivel del árbol LDAP. Es por ello, que directamente agrupamos sus usuarios y grupos (objetos de las clases PosixAccount y PosixGroup) en el nivel de la unidad organizativa profesores que veíamos en la imagen 4.2. A. Gutiérrez Mayoral 55 ETSI Informática

74 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACIÓN Esta representación se puede observar en la imagen 4.4. ou=profesores, dc=zipi,dc=escet, dc=urjc,dc=es ou=usuarios (...) ou=grupos (...) Figura 4.4: La unidad organizativa de profesores contiene dos unidades organizativas que almacenan los objetos posixaccount y posixgroup. Configuración de los clientes Una vez que se ha configurado los servidores, es necesario pasar a configurar los clientes para que éstos puedan autenticar a sus usarios mediante un directorio LDAP. Usando Ubuntu, solamente es necesario instalar un par de paquetes para disponer de las herramientas adecuadas. Estos paquetes son libnss-ldap y libpam-ldap, los cuales proveen de las bibliotecas oportunas para poder autenticar a usuarios a través de un directorio LDAP. La instalación de estos paquetes en Ubuntu es inmediata y bastante simple, realizando una llamada al instalador de paquetes apt, como queda reflejado en el listado Listado 4.23: Instalación de las bibliotecas necesarias para la autenticación PAM vía LDAP $ apt-get install --assume-yes libnss-ldap libpam-ldap Es posible que los paquetes instalados anteriormente requieran configuración adicional, como por ejemplo, la raíz del árbol LDAP a partir del cual se buscarán los usuarios a autenticar. En nuestro caso, vamos a responder a todas las preguntas por omisión y a configurar estos datos de forma manual. En principio, para poder autenticar a los usuarios de un sistema Ubuntu mediante LDAP, es necesario configurar al menos los siguientes ficheros: El fichero /etc/nsswitch.conf en el que se indicará que los datos de los usuarios y los grupos proceden de una base de datos LDAP. El fichero /etc/ldap/ldap.conf en el que se deben introducir los datos de conexión a los servidores LDAP (URIs de los servidores) y algún otro parámetro, como por ejemplo si es necesario establecer una conexión segura al servidor. Los ficheros /etc/pam ldap.conf y /etc/libnss-ldap.conf, en los que es necesario configurar entre otras cosas, los datos de conexión a los servidores LDAP, la raíz del árbol LDAP a partir de la cual se deben buscar a los usuarios, y muchos otros parámetros que para nosotros serán transparentes. Proyecto Fin de Carrera 56 Universidad Rey Juan Carlos

75 CAPÍTULO 4. IMPLANTACIÓN Los ficheros de los módulos de autenticación PAM, situados bajo el directorio /etc/pam.d/. En este directorio se situan los ficheros de configuración de los módulos de autenticación de usuario, en los que será necesario indicar que la autenticación se llevará a cabo mediante LDAP. Vamos a ver de forma más detallada los ficheros de configuración más importantes. Fichero /etc/nsswitch.conf En este fichero se indica de donde provienen las bases de datos de los servicios más importantes del sistema, como los usuarios y los grupos. En nuestro caso, será necesario anteponer la palabra LDAP para indicar que los datos de los usuarios y los grupos provienen de una base de datos LDAP, tal y como muestra el fichero passwd: group: shadow: Listado 4.24: Contenido del fichero nsswitch.conf para autenticación vía LDAP files ldap files ldap files ldap Fichero /etc/pam ldap.conf Este fichero contiene la configuración de PAM que accede a servicios de directorio LDAP. En este fichero, los datos de configuración más importantes son las cadenas de conexión al servidor LDAP y la raiz del árbol a partir de la cual se empiezan a buscar usuarios. Podemos ver esta configuración en el siguiente fragmento del fichero de configuración mostrado en el listado del fichero Listado 4.25: Contenido del fichero pam ldap.conf para autenticación vía LDAP uri ldaps://peloto.escet.urjc.es base dc=zipi,dc=escet,dc=urjc,dc=es ldap_version 3 bind_policy soft fichero /etc/libnss-ldap.conf Este fichero es bastante parecido al anterior, y contiene la información para poder acceder a un servidor LDAP en el caso en el que se usen bases de datos LDAP en la base de datos de los servicios del sistema (Fichero nsswitch.conf). Las líneas más significativas de este fichero son bastante parecidas al anterior, y se muestran en el listado del fichero Listado 4.26: Contenido del fichero libnss-ldap.conf para autenticación vía LDAP uri ldaps://peloto.escet.urjc.es base dc=zipi,dc=escet,dc=urjc,dc=es ldap_version 3 bind_policy soft Módulos de PAM bajo /etc/pam.d/ Por último, es necesario configurar todos los ficheros de autenticación de PAM para que usen la autenticación bajo un directorio LDAP. Este directorio, contiene los ficheros necesarios para la autenticación, además de un fichero por cada servicio que requiere autenticación en el sistema (ssh, screensaver, gdm, etcétera). Debemos ser cuidadosos en el sentido de que si tenemos un servicio que requiere autenticación pero no añadimos su fichero correspondiente en este directorio, ese servicio no podrá autenticar vía LDAP con nuestro servicio de autenticación. Por ejemplo, si no se crea el servicio de autenticación screensaver, cuando un usuario lance el salvapantallas en una sesión X y deje la pantalla bloqueada (es necesario introducir el nombre de usuario y la contraseña A. Gutiérrez Mayoral 57 ETSI Informática

76 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACIÓN para volver a retomar su sesión) no podrá desbloquearla, puesto que el servicio salvapantallas no podrá autenticar contra el servicio de autenticación LDAP. Migración de cuentas NIS a LDAP Un aspecto importante de la decisión de implantación de un servidor LDAP para la administración de cuentas de usuario es la seguridad de poder migrar la base de datos actual de usuarios (ahora mismo en NIS) a la base de datos LDAP. En el momento en el que se realiza la migración, el número de usuarios en el sistema es aproximadamente de dos mil usuarios (solamente en el Campus de Móstoles, que es el primero en el que se propone la migración). Sin duda, no nos podemos plantear la migración a la tecnología LDAP si no tenemos una herramienta que automatice todo el proceso de migración de cuentas (es impensable migrar dos mil cuentas de usuario a mano). Por eso, lo primero que debemos hacer es localizar una herramienta que pueda traducir el fichero actual de usuarios (recordamos que la una base de datos NIS es equivalente a los ficheros de usuarios /etc/passwd y /etc/shadow tradicionales) a una base de datos o fichero de importación de datos de LDAP, un fichero LDIF 15 que contendrá todos los usuarios actuales y que únicamente tendremos que volcar en la base de datos LDAP. Para esta tarea, se provee de unas herramientas muy útiles que nos ayudarán en la tarea de la migración de un formato a otro. Una vez más, este paquete se encuentra en la mayoría de las distribuciones usadas hoy en día, y como no, en Debian GNU/Linux: Listado 4.27: Instalación del conjunto de herramientas migrationtools a través de apt-get $ apt- get install migrationtools El uso de estas herramientas es realmente simple y muy potente. Las aplicaciones quedan instaladas bajo el directorio /usr/share/migrationtools/. En este directorio podemos localizar el script migrate passwd.pl, el cual se encarga de transformar los ficheros /etc/passwd y /etc/shadow de la máquina donde ejecuta el script en el formato adecuado de una base de datos LDAP: la salida, mostrada por pantalla, es un fichero LDIF que contiene los usuarios de estos ficheros transformados al formato correspondiente. Con un poco de mano, podemos transformar este pequeño script escrito en Perl para que tome como argumentos ficheros pasados al invocar al programa, aumentando así la versatibilidad del mismo. Además, como vimos en el apartado anterior (Jerarquía de nuestro servidor LDAP), podemos separar las cuentas entre los profesores y los alumnos, haciendo que para cada uno de ellos, se muestre un nombre distinguido diferente. Estas operaciones auxiliares, se pueden realizar haciendo uso de comandos estándar de Unix, como sed, awk, grep y cut. Una vez que tenemos los datos de los usuarios almacenados en un fichero de intercambio de información LDAP (simplemente, redirigiendo la salida de la herramienta de migración a un fichero) procedemos a la carga de este fichero en el servidor LDAP. Esta operación, se realiza a través de la herramienta ldapadd 16, de la siguiente forma: Listado 4.28: Modificando registros en el árbol LDAP usando ldapadd $ ldapadd -x -H ldap://peloto.escet.urjc.es -D cn=admin,dc=zipi,dc=escet,dc=urjc,dc=es -W -f cuentas.ld En el comando, que sirve para añadir información a un servidor LDAP, se especifican los siguientes parámetros: 1. El modificador -x asume que la autenticación es simple, en vez de usar el protocolo SASL. 15 LDIF son las siglas de LDAP Interchange format o formato de intercambio de datos LDAP 16 Para poder usar el comando ldapadd es necesario tener instalado el paquete ldap-utils. Proyecto Fin de Carrera 58 Universidad Rey Juan Carlos

77 CAPÍTULO 4. IMPLANTACIÓN 2. La localización del servidor LDAP, especificado mediante una URI (identificador de recurso universal). 3. Se pasa como parámetro (-D) el nombre distinguido del usuario administrador, que es en ese momento el que permite realizar escrituras en el árbol LDAP. En general el modificador -D sirve para atarse al servidor con un nombre de usuario concreto. 4. El modificador -W para que el comando pregunte de forma interactiva al usuario por su contraseña o palabra de paso. 5. Y por último, se pasa con el modificador -f, el nombre de fichero con los datos en formato LDIF que se pretenden añadir al servidor. La llamada al comando provocará que se muestre por la salida estándar un pequeño mensaje por cada nodo o entrada que se va añadiendo al árbol LDAP. En caso de error, éste también se mostrará, y dependerá de cómo se haya invocado al comando la interrupción inmediata o asumir la continua carga del fichero en el servidor para continuar o no la ejecución. Una vez concluido este paso, podemos decir que tenemos completamente migrada nuestra base de datos de usuarios anterior (en formato NIS) a un servidor de directorio LDAP, por lo que los clientes, ya serán capaces de autenticar con los usuarios actuales del sistema, a través de un servidor de autenticación LDAP. A partir de este momento, vamos a centrar nuestra tarea en dotar al servidor de aspectos avanzados muy interesantes (y muchos de ellos indispensables) como implementar una conexión segura entre el servidor y los clientes (recordamos que ahora mismo el intercambio de información se realiza en texto claro), además de implementar la funcionalidad de reparto de carga y replicación para aumentar la fiabilidad y seguridad del servicio. Aspectos avanzados: Aumentando la seguridad Ahora mismo, tenemos un entorno de autenticación de usuarios bajo un directorio LDAP totalmente funcional. Los usuarios podrían autenticarse sin problemas en las estaciones clientes, con la misma contraseña que tuvieran antes (ya que hemos migrado la base de datos de usuarios y para el usuario final, la autenticación es completamente transparente). Sin embargo, sino realizamos ningún ajuste adicional, podríamos tener problemas con usuarios maliciosos que tuvieran acceso a herramientas de escaneo de tráfico en una interfaz de red determinada. Sin duda, esto en un entorno real empresarial, sería difícil que ocurriera. Sin embargo, en un entorno universitario, en el que muchas de las prácticas que se realizan tienen que ver con el análisis del tráfico de red de determinados protocolos, esto es completamente normal. En la figura 4.5 se muestran los paquetes capturados en el momento en el que un usuario inicia una sesión en una máquina. Vemos como bajo el protocolo LDAP, en el campo de datos del paquete TCP se muestran claramente el nombre de usuario y la contraseña del usuario en cuestión, lo que demuestra que el esquema que nos hemos planteado hasta el momento adolece de problemas de seguridad bastante evidentes. Por eso, no podemos poner en funcionamiento nuestro sistema todavía sin antes establecer una conexión segura entre los clientes y el servidor de autenticación. Para poder completar esta tarea, nos vemos obligados a la realización de los siguientes pasos: Del lado del servidor, será necesario la creación de un certificado para poder establecer la comunicación usando los protocolos de seguridad SSL/TLS. Podemos crear el certificado de dos formas: la más sencilla (en principio será la que se usará en nuestro entorno, por simplicidad) contempla la creación de un certificado auto firmado. La forma más compleja contempla el caso de que nuestro certificado sea firmado por una entidad certificadora (una CA). Podemos usar este método también, siguiendo los siguientes pasos: A. Gutiérrez Mayoral 59 ETSI Informática

78 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACIÓN Figura 4.5: La aplicación wireshark muestra como se mandan los datos de autenticación en claro entre cliente y servidor, con nuestro esquema actual. 1. Creamos la entidad certificadora 2. Creamos el certificado 3. Firmamos el certificado mediante la entidad certificadora. Sin embargo, por simplicidad (en principio, no dependemos de ninguna entidad certificadora) usaremos un certificado auto firmado. De cara a los clientes, deberemos modificar los parámetros de conexión para que ésta se realice a través de otro puerto (el protocolo LDAP sobre SSL usa el puerto 636). En principio estas modificaciones en los clientes serían más que suficientes. Creación de un certificado auto firmado Para llevar a cabo la creación de un certificado auto firmado hemos de seguir los siguientes pasos. En primer lugar, hemos de tener instaladas en nuestro sistema las herramientas relacionadas con la creación de certificados SSL, provistas en su mayoría por el paquete openssl. Lo instalamos de la forma habitual: $ apt-get install openssl Listado 4.29: Instalación del paquete openssl a través de apt-get Una vez instalado el paquete, bajo el directorio /usr/lib/ssl/misc/ tenemos los scripts necesarios para nuestra tarea. El comando que deberemos lanzar para crear el certificado, es el siguiente: Listado 4.30: Creación de un certificado para nuestro servidor LDAP $ openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout server.pem -days 365 Entre los modificadores más importantes de este comando, se encuentran donde se guardará el certificado de salida (fichero server.pem), la duración antes de que el certificado expire (365 días), Proyecto Fin de Carrera 60 Universidad Rey Juan Carlos

79 CAPÍTULO 4. IMPLANTACIÓN y el tamaño de la clave (1024 bits). Una vez que invocamos el comando, éste nos preguntará acerca de la información que contendrá el certificado. Es muy importante que cuando nos pregunte acerca del nombre común o Common Name del certificado, escribamos exactamente el elemento raiz del árbol LDAP: en nuestro caso, recordamos que era dc=zipi,dc=escet,dc=urjc,dc=es. Si no escribimos literalmente esto, la conexión desde los clientes fallará. El resto de preguntas tienen que ver con la organización donde se usará, el correo de la persona responsable, etcétera. Configuración de OpenLDAP para el uso del certificado Una vez que hemos creado el certificado (éste se encuentra en el fichero server.pem) debemos modificar la configuración del servidor OpenLDAP para el uso del certificado, y que éste atienda peticiones a través de un canal de comunicación seguro (basado en SSL/TLS). Para ello, editamos el fichero /etc/ldap/slapd.conf, que es el fichero de configuración del servidor LDAP, y añadimos al final del fichero las siguientes líneas: Listado 4.31: Líneas necesarias para proporcionar soporte SSL al servidor LDAP 1 TLSCipherSuite HIGH: MEDIUM:- SSLv2 2 TLSCACertificateFile /etc/ldap/ssl/server.pem 3 TLSCertificateFile /etc/ldap/ssl/server.pem 4 TLSCertificateKeyFile /etc/ldap/ssl/server.pem Hemos copiado el certificado del servidor a la localización /etc/ldap/ssl/. Por último, es necesario modificar las opciones de arranque del demonio LDAP para que cambie el puerto en el que atenderá peticiones a partir de ahora. Este paso es muy simple, y se consigue editando el fichero /etc/default/slapd y añadiendo la línea Listado 4.32: Líneas necesarias para proporcionar soporte SSL al servidor LDAP 1 SLAPD_SERVICES =" ldaps://" Donde la cadena ldaps:// indica que el protocolo de comunicación usado se basará a partir de ahora en SSL/TLS. Si quisiéramos tener ambos métodos de conexión disponibles (tanto seguro como no seguro) hubiera bastado con dejar ambas cadenas disponibles (ldaps:// y ldap://). En principio, como nos interesa que los clientes únicamente puedan conectar al servidor usando un canal seguro, dejaremos la opción indicada como predeterminada. Una vez efectuados todos estos cambios, bastaría reiniciar el servidor LDAP para que fueran aplicados: /etc/init.d/slapd restart Listado 4.33: Reinicio del demonio slapd Podemos comprobar con ayuda de la herramienta nmap que el servidor LDAP se ha iniciado correctamente en el puerto SSL: 636/ tcp open ldapssl Configuración de los clientes Los cambios que se deben efectuar en los clientes para que efectúen una conexión al servidor LDAP son realmente simples, y se basarán en la sustitución de la cadena de conexión que especifica la localización del servidor LDAP. Así, debemos editar los siguientes ficheros: En el fichero /etc/ldap/ldap.conf, sustituimos la cadena ldap:// por ldaps:// En los ficheros /etc/libpam ldap.conf y /etc/libnss-ldap.conf se realiza la misma modificación. A. Gutiérrez Mayoral 61 ETSI Informática

80 4.2. PROTOCOLOS SITUADOS EN LA CAPA DE APLICACIÓN Además, en el fichero /etc/ldap/ldap.conf se añade la linea tls reqcert never para que no se compruebe el certificado del lado de los clientes. Si no añadimos esto, la conexión probablemente fallaría del lado del servidor, puesto que el cliente no le va a ofrecer ningún certificado. Figura 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. Una vez realizadas todas las modificaciones, procedemos a realizar la misma prueba que realizamos antes. Apoyándonos en la herramienta wireshark, procedemos a autenticarnos en el sistema. Vemos como ahora el protocolo que se identifica es SSL/TLS, y que resulta prácticamente imposible identificar cualquier campo del mensaje puesto que ahora se encuentran cifrados. Se puede observar en la imagen 4.6 como ahora resulta imposible identificar datos de usuarios analizando el tráfico que pasa por el interfaz de red. Aspectos avanzados: Reparto de carga Vimos como en el capítulo de diseño íbamos a dedicar tres máquinas en el Campus de Móstoles para que dispusieran de servidor de directorio LDAP. Evidentemente, en esta configuración, una de las máquinas servirá la base de datos LDAP de forma primaria (lectura y escritura de datos) y el resto de las máquinas lo servirán de forma secundaria (solamente lectura). Esta configuración nos permitirá separar la carga de todos los laboratorios por máquinas (160 máquinas en un campus y 140 en otro es mucha carga para un único servidor LDAP por campus), además de poder realizar replicación del servidor primario a los secundarios y disponer de la misma base de datos LDAP en diferentes localizaciones (de cara a que pudiera ocurrir una tragedia y necesitáramos acceder a los datos de las cuentas). La máquina principal en este esquema, tal y como vimos en el capitulo de Diseño, será la máquina peloto (con dirección IP ) la cual se va a encargar de servir el directorio LDAP de forma primaria. Esto significa que siempre que se necesite realizar una escritura en el directorio (creación de una cuenta o cambio de una contraseña) se deberá realizar en el servidor LDAP de peloto. Por el contrario, las lecturas de datos (autenticación de un usuario frente al directorio) se podrán realizar en cualquiera de los servidores secundarios. Proyecto Fin de Carrera 62 Universidad Rey Juan Carlos

81 CAPÍTULO 4. IMPLANTACIÓN Las operaciones más frecuentes en un directorio LDAP suelen ser de lectura, frente a las operaciones de escritura. Las creaciones de cuenta se suelen llevar a cabo una única vez en todo el año (comienzo de curso) y los cambios de contraseña, aún siendo más usuales que las operaciones de creación de cuenta, representan un porcentaje totalmente despreciable frente al número de lecturas para autenticación que se realizan. peloto.escet.urjc.es Servidor LDAP Primario zipi.escet.urjc.es Servidor LDAP Secundario (1) zape.escet.urjc.es Servidor LDAP Secunario (2) nano.cct.urjc.es Servidor LDAP Secunario (ETSIT Fuenlabrada) Figura 4.7: Reparto de carga entre varios servidores LDAP. El resto de máquinas que se disponen para servir el directorio LDAP de forma secundaria son zipi (con dirección IP ) y zape (con dirección IP ), situadas estas dos máquinas en el campus de Móstoles. En el campus de Fuenlabrada, disponemos de una sola máquina para la autenticación, la máquina nano (con dirección IP ). El número de estaciones en cada campus (160 en Móstoles frente a 140 en Fuenlabrada) nos hace en principio disponer de más servidores de autenticación en Móstoles que en Fuenlabrada, aunque se prevee que se instalen más en el futuro en el campus de Fuenlabrada dado que el número de estaciones en ese campus está aumentando considerablemente. La figura 4.7 muestra una imagen representativa de la división en máquinas de los servidores que dispondrán de servicio de autenticación LDAP. Cabe recordar en este punto, que las cuentas de usuario son las mismas para ambos campus (Móstoles y Fuenlabrada), por lo que si en principio el servidor de LDAP de Fuenlabrada deja de estar disponible por cualquier razón, las estaciones de este campus intentarán autenticar contra cualquiera de los servidores de autenticación instalados en el campus de Móstoles, sin ningún tipo de problema. Configuración de los clientes para el reparto de carga La configuración de los clientes para que puedan conectarse a diferentes servidores LDAP en caso de que encuentren un fallo en alguno es realmente simple, y basta con añadir en los ficheros /etc/ldap/ldap.conf, /etc/libpam ldap.conf, y /etc/libnss-ldap.conf tantas cadenas de conexión como servidores tengamos disponibles. En nuestro caso, vamos a tener disponibles cuatro servidores que ofrezcan servicio de autenticación vía LDAP, que se identifican por su nombre de host. Por tanto, las cadenas de conexión serían las siguientes: A. Gutiérrez Mayoral 63 ETSI Informática

Índice. agradecimientos...19

Índice. agradecimientos...19 Índice agradecimientos...19 CAPÍTULO 1. CARACTERIZACIÓN DE SISTEMAS OPERATIVOS...21 1.1 El sistema informático...22 1.1.1 Clasificación de los sistemas informáticos...24 1.2 El sistema operativo... 26

Más detalles

IES Abyla. Departamento de Informática. Sistemas Operativos

IES Abyla. Departamento de Informática. Sistemas Operativos Sistemas Operativos Definición y funciones básicas El Sistema Operativo es el software que permite y simplifica el uso del ordenador (hardware). Sus funciones principales son: Arrancar el ordenador y controlar

Más detalles

MÁSTER ONLINE EN ADMINISTRACIÓN LINUX

MÁSTER ONLINE EN ADMINISTRACIÓN LINUX MÁSTER ONLINE EN ADMINISTRACIÓN LINUX Módulo 1 Hardware & Arquitectura de sistemas - 20 horas Este módulo permite conocer y configurar los elementos básicos del hardware del sistema, como también otros

Más detalles

Software libre. El software libre provee la libertad de: Documentación (guías, wikis, faqs, etc.). Programa ejecutable. Código fuente del programa.

Software libre. El software libre provee la libertad de: Documentación (guías, wikis, faqs, etc.). Programa ejecutable. Código fuente del programa. GNU / Linux Software libre Es una forma ética de entender el software (en su desarrollo, comercialización, distribución y uso). Con el software libre se distribuye: Documentación (guías, wikis, faqs, etc.).

Más detalles

Acronis Backup & Recovery 10 Server para Linux. Update 5. Guía de instalación

Acronis Backup & Recovery 10 Server para Linux. Update 5. Guía de instalación Acronis Backup & Recovery 10 Server para Linux Update 5 Guía de instalación Contenido 1 Antes de la instalación...3 1.1 Componentes de Acronis Backup & Recovery 10... 3 1.1.1 Agente para Linux... 3 1.1.2

Más detalles

Acronis Backup & Recovery 10 Server for Linux. Guía de instalación

Acronis Backup & Recovery 10 Server for Linux. Guía de instalación Acronis Backup & Recovery 10 Server for Linux Guía de instalación Contenido 1 Antes de la instalación...3 1.1 Componentes de Acronis Backup & Recovery 10... 3 1.1.1 Agente para Linux... 3 1.1.2 Generador

Más detalles

CONFIGURACIÓN DEL ADAPTADOR DE RED EN LINUX

CONFIGURACIÓN DEL ADAPTADOR DE RED EN LINUX CONFIGURACIÓN DEL ADAPTADOR DE RED EN LINUX 16/09/2005 Índice de Contenidos 1 INTRODUCCIÓN... 1-1 2 DISTRIBUCIONES LINUX... 2-1 3 CONFIGURACIÓN DE RED EN LINUX... 3-1 3.1 FEDORA CORE 3... 3-1 3.1.1 Configuración

Más detalles

PROGRAMA FORMATIVO. Ingeniero de Sistemas Red Hat LINUX

PROGRAMA FORMATIVO. Ingeniero de Sistemas Red Hat LINUX PROGRAMA FORMATIVO Ingeniero de Sistemas Red Hat LINUX Septiembre 2014 DATOS GENERALES DE LA ESPECIALIDAD 1. Familia Profesional: INFORMÁTICA Y COMUNICACIONES Área Profesional: Sistemas y telemática 2.

Más detalles

Módulos: Módulo 1. Hardware & Arquitectura de sistemas - 20 Horas

Módulos: Módulo 1. Hardware & Arquitectura de sistemas - 20 Horas Módulos: Módulo 1 Hardware & Arquitectura de sistemas - 20 Horas Este módulo permite conocer y configurar los elementos básicos del hardware del sistema, como también otros componentes adicionales como

Más detalles

La inscripción sólo se realiza rellenando en Internet la ficha de inscripción:

La inscripción sólo se realiza rellenando en Internet la ficha de inscripción: Nombre: Certified IT Professional: Administración de Sistemas Operativos Nº horas: 280 Nº alum.: 16 Inicio: 19/01/2015 Fin: 21/05/2015 Horario: 9-13h Lugar: ZARAGOZA La inscripción sólo se realiza rellenando

Más detalles

Unidad 0. Preparación del material. Implantación y administración remota y centralizada de Sistemas Operativos. Manuel Morán Vaquero

Unidad 0. Preparación del material. Implantación y administración remota y centralizada de Sistemas Operativos. Manuel Morán Vaquero Unidad 0 Preparación del material Implantación y administración remota y centralizada de Sistemas Operativos Manuel Morán Vaquero mmv@edu.xunta.es http://www.immv.es Contenidos 1 Introducción 2 Máquina

Más detalles

6 INSTALA, ADMINISTRA, SECURIZA Y VIRTUALIZA ENTORNOS LINUX RA-MA

6 INSTALA, ADMINISTRA, SECURIZA Y VIRTUALIZA ENTORNOS LINUX RA-MA ÍNDICE PRÓLOGO...13 CAPÍTULO 1. LINUX: UNA VISIÓN GENERAL...15 1.1 QUÉ APORTA ESTE LIBRO SOBRE LINUX...16 1.2 CÓMO COMIENZA LINUX...17 1.3 SISTEMA OPERATIVO LINUX...17 1.4 GNU LINUX, LINUX GNU O LINUX...18

Más detalles

Índice. agradecimientos...15

Índice. agradecimientos...15 Índice agradecimientos...15 CAPÍTULO 1. LOS SISTEMAS OPERATIVOS EN RED...17 1.1 La Arquitectura cliente/servidor...18 1.2 Características de los sistemas operativos de red... 20 1.2.1 La gestión de los

Más detalles

Clase 02 Distribuciones GNU/Linux

Clase 02 Distribuciones GNU/Linux Clase 02 Distribuciones GNU/Linux Introducción al Sistema Operativo GNU/Linux DCIC - UNS Copyright Copyright 2011 A. G. Stankevicius Se asegura la libertad para copiar, distribuir y modificar este documento

Más detalles

INTRODUCCIÓN enumeraré los requisitos

INTRODUCCIÓN enumeraré los requisitos INTRODUCCIÓN Estimado lector le damos la bienvenida a esta nueva edición en la saga Pentesting del foro Underc0de, yo soy MagoAstral y me complace ser el tutor que desarrollará esta edición. Al igual que

Más detalles

Creación de una Distro Linux

Creación de una Distro Linux 1 PRACTICA NO.21: CREACIÓN DE DISTRO LINUX Creación de una Distro Linux Una distribución Linux (coloquialmente llamada distro) es una distribución de software basada en el núcleo Linux que incluye determinados

Más detalles

Módulos: Módulo 1. El núcleo de Linux - 5 Horas

Módulos: Módulo 1. El núcleo de Linux - 5 Horas Módulos: Módulo 1 El núcleo de Linux - 5 Horas En este módulo se centrará en el estudio en profundidad del núcleo de Linux. Los estudiantes tendrán que ser capaces de conocer en profundidad los distintos

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

Thinclients Terminales ligeros con CentOS 5 y Thinstation

Thinclients Terminales ligeros con CentOS 5 y Thinstation Thinclients Terminales ligeros con CentOS 5 y Thinstation Manuel Morán Vaquero mmv@edu.xunta.es Febrero 2010 Índice 1 Introducción Licencia y disclaimer Ventajas y desventajas de los terminales ligeros

Más detalles

Nivel Básico/Intermedio/Avanzado. Instalar y Configurar Servidores GNU/Linux. Administrar Servidores GNU/Linux. Proteger ante ataques a Servidores.

Nivel Básico/Intermedio/Avanzado. Instalar y Configurar Servidores GNU/Linux. Administrar Servidores GNU/Linux. Proteger ante ataques a Servidores. GNU/Linux CentOS Nivel Básico/Intermedio/Avanzado Instalar y Configurar Servidores GNU/Linux. Administrar Servidores GNU/Linux. Proteger ante ataques a Servidores. Optimizar Servidores GNU/Linux y virtualizar

Más detalles

Software de Comunicaciones. Práctica 4 - DHCP & Dynamic DNS

Software de Comunicaciones. Práctica 4 - DHCP & Dynamic DNS Software de Comunicaciones Práctica 4 - DHCP & Dynamic DNS Juan Díez-Yanguas Barber Software de Comunicaciones Ingeniería Informática - 5º Curso Jdyb - Marzo 2013 Juan Díez- Yanguas Barber Práctica 4 Índice

Más detalles

INTRODUCCIÓN...15 TEORÍA...17

INTRODUCCIÓN...15 TEORÍA...17 ÍNDICE INTRODUCCIÓN...15 TEORÍA...17 CAPÍTULO 1. ASPECTOS BÁSICOS...19 1.1 TAREAS DEL ADMINISTRADOR...19 1.2 HARDWARE DEL SERVIDOR...21 1.2.1 CPD...21 1.2.2 Sistema de rack...23 1.2.3 Servidores...24 1.2.4

Más detalles

Luis Caballero Cruz. Ingeniería Técnica Informática de Sistemas. Universidad de Sevilla

Luis Caballero Cruz. Ingeniería Técnica Informática de Sistemas. Universidad de Sevilla Luis Caballero Cruz Ingeniería Técnica Informática de Sistemas Universidad de Sevilla 5.1- RED LOCAL PARA PANDORA FMS: En este capítulo estudiaremos el aspecto de la instalación y requisitos de nuestra

Más detalles

Software de Comunicaciones. Práctica 7 - Secure Shell. SSH

Software de Comunicaciones. Práctica 7 - Secure Shell. SSH Software de Comunicaciones Práctica 7 - Secure Shell. SSH Juan Díez-Yanguas Barber Software de Comunicaciones Ingeniería Informática - 5º Curso Jdyb - Mayo 2013 Juan Díez- Yanguas Barber Práctica 7 Índice

Más detalles

Instalación de Debian Etch. Pablo Sanz Mercado.

Instalación de Debian Etch. Pablo Sanz Mercado. Instalación de Debian Etch. Pablo Sanz Mercado. 1 Debian es una de las distribuciones Linux más conocidas, siendo la distribución probablemente más querida y más odiada. Por qué odiada y querida? Hay que

Más detalles

Laboratorio 1 Preparación del entorno de trabajo

Laboratorio 1 Preparación del entorno de trabajo DEPARTAMENTO DE TECNOLOGÍA ELECTRÓNICA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Laboratorio 1 Preparación del entorno de trabajo Planificación y Gestión de Proyectos Informáticos 1. Introducción

Más detalles

Índice de contenido. Página 1 de 14

Índice de contenido. Página 1 de 14 Índice de contenido CURSO DE PREPARACIÓN PARA EL EXAMEN DE LPI 101...3 CURSO DE PREPARACIÓN PARA EL EXAMEN DE LPI 102...5 CERTIFICACIÓN LINUX NIVEL JUNIOR LPCI (1)...7 CURSO DE PREPARACIÓN PARA EL EXAMEN

Más detalles

ANÁLISIS DE HERRAMIENTAS PARA CLONAR DISCOS DUROS

ANÁLISIS DE HERRAMIENTAS PARA CLONAR DISCOS DUROS ANÁLISIS DE HERRAMIENTAS PARA CLONAR DISCOS DUROS Descripción y características: Clonezilla es un particionador o clonador de discos, similar a Norton Ghost que guarda y restaura bloques sólo se usa en

Más detalles

2.2. Principales características de los sistemas operativos. UNIDAD 2

2.2. Principales características de los sistemas operativos. UNIDAD 2 2.2. Principales características de los sistemas operativos. UNIDAD 2 Mac OS X es un sistema operativo desarrollado y comercializado por Apple Inc. Ha sido incluido en su gama de computadoras Macintosh

Más detalles

Capítulo 4.- Recomendaciones para un Servidor web y de bases de datos seguro.

Capítulo 4.- Recomendaciones para un Servidor web y de bases de datos seguro. Capítulo 4.- Recomendaciones para un Servidor web y de bases de datos seguro. Este capítulo explica las características que un servidor web y de bases de datos seguro debe tener. Esto es esencial para

Más detalles

Requisitos de Hardware: Procedimientos: Instalación en modo texto CentOS 5

Requisitos de Hardware: Procedimientos: Instalación en modo texto CentOS 5 Instalación en modo texto CentOS 5 Requisitos de Hardware: Si bien los sistemas GNU/Linux pueden instalarse en equipo con capacidades muy reducidas (o limitadas), para tener un entorno con un buen desempeño

Más detalles

Administración de sistemas UNIX/Linux Práctica Colección de scripts para la configuración de una infraestructura de máquinas UNIX

Administración de sistemas UNIX/Linux Práctica Colección de scripts para la configuración de una infraestructura de máquinas UNIX Administración de sistemas UNIX/Linux Práctica Colección de scripts para la configuración de una infraestructura de máquinas UNIX Curso 2013/2014 Introducción Esta práctica consiste en la elaboración de

Más detalles

DIPLOMADO LINUX ENTERPRISE SERVER: SERVIDORES Y SEGURIDAD

DIPLOMADO LINUX ENTERPRISE SERVER: SERVIDORES Y SEGURIDAD DIPLOMADO LINUX ENTERPRISE SERVER: SERVIDORES Y SEGURIDAD TABLA DE CONTENIDO INTRODUCCION... 3 ESTRUCTURA DEL DIPLOMADO... 4 TEMA 1: INSTALACION, ADMINISTRACION, SOPORTE... 4 Instalación de Linux... 4

Más detalles

Unidad 6. Terminales Ligeros. Implantación y administración remota y centralizada de Sistemas Operativos. Manuel Morán Vaquero

Unidad 6. Terminales Ligeros. Implantación y administración remota y centralizada de Sistemas Operativos. Manuel Morán Vaquero Unidad 6 Terminales Ligeros Implantación y administración remota y centralizada de Sistemas Operativos Manuel Morán Vaquero mmv@edu.xunta.es http://www.immv.es Contenidos 1 Introducción Ventajas y desventajas

Más detalles

PROGRAMAS DE ESTUDIO FORMATO 7 ADMINISTRACIÓN AVANZADA DE LINUX. Área de Formación Profesional

PROGRAMAS DE ESTUDIO FORMATO 7 ADMINISTRACIÓN AVANZADA DE LINUX. Área de Formación Profesional PROGRAMAS DE ESTUDIO FORMATO 7 NOMBRE DE LA ASIGNATURA ADMINISTRACIÓN AVANZADA DE LINUX CICLO, AREA O MODULO Área de Formación Profesional CLAVE DE LA ASIGNATURA IT223 OBJETIVOS GENERALES DE LA ASIGNATURA

Más detalles

Índice. OpenGnSys 1.0.5-RC1 Mejoras versión 1.0.5 Estadísticas del proyecto Mapa de implantación Curso on-line Futuro

Índice. OpenGnSys 1.0.5-RC1 Mejoras versión 1.0.5 Estadísticas del proyecto Mapa de implantación Curso on-line Futuro Índice OpenGnSys 1.0.5-RC1 Mejoras versión 1.0.5 Estadísticas del proyecto Mapa de implantación Curso on-line Futuro OpenGnSys 1.0.5-RC1 Descargar versión completa OpenGnSys 1.0.5-RC1 http://www.opengnsys.es/downloads/opengnsys-1.0.5-rc1-r4258-install-oglive-1.0.4.tar.gz

Más detalles

Programa Instruccional de Asignatura

Programa Instruccional de Asignatura DuocUC Vicerrectoría Académica Programa Instruccional de Asignatura ASR4501 ADMINISTRACION DE SERVICIOS DE RED 10 créditos 90 horas Requisitos: SOR4501 Fecha Actualización: 24-AUG-12 ESCUELA DE INFORMÁTICA

Más detalles

Maquinas virtuales Conceptos Básicos

Maquinas virtuales Conceptos Básicos Jimenez Zamudio Eduardo Aplicaciones de redes de computadoras 13 de septiembre de 2014 Maquinas virtuales Conceptos Básicos Concepto Básicamente, es un equipo dentro de un equipo, implementado en el software.

Más detalles

CURSO TALLER DE ADMINISTRACION DE SERVIDORES LINUX NUMERO DE HORAS: 40 A 50 HORAS DURACION: 2 HORAS DIARIAS 1 SOLO HORARIO(1 MES)

CURSO TALLER DE ADMINISTRACION DE SERVIDORES LINUX NUMERO DE HORAS: 40 A 50 HORAS DURACION: 2 HORAS DIARIAS 1 SOLO HORARIO(1 MES) CURSO TALLER DE ADMINISTRACION DE SERVIDORES LINUX NUMERO DE HORAS: 40 A 50 HORAS DURACION: 2 HORAS DIARIAS 1 SOLO HORARIO(1 MES) TEMARIO DEL CURSO PARA LINUX ASPECTOS GENERALES Qué es el Software libre

Más detalles

Hay muchas aplicaciones para la creación de imágenes de respaldo en Windows como pueden ser:

Hay muchas aplicaciones para la creación de imágenes de respaldo en Windows como pueden ser: Realiza un informe sobre los diferentes programas que existen en el mercado informático que permite crear imagenes de respaldo de tu equipo y realiza una demostración práctica de uno de ellos Una imagen

Más detalles

Introducción a Gentoo Linux

Introducción a Gentoo Linux Introducción a Gentoo Linux Grupo de Usuarios de Linux Universidad Carlos III de Madrid 2007-04-10 Jaime Martín Jiménez jaime.martin@uc3m.es Índice de la charla Historia Gentoo Linux: una metadistribución

Más detalles

Curso de Linux (Version Ubuntu 9) (140 horas)

Curso de Linux (Version Ubuntu 9) (140 horas) Curso de Linux (Version Ubuntu 9) (140 horas) 1 Curso de Linux (Version Ubuntu 9) En La Salle, conscientes de la necesidad de progreso y evolución de la sociedad actual, hemos desarrollado unos programas

Más detalles

Tipos de Centros. TIC de Gestión. TIC de Práctica Docente. Dotación y Apoyo

Tipos de Centros. TIC de Gestión. TIC de Práctica Docente. Dotación y Apoyo Índice de contenido Tipos de Centros...3 TIC de Gestión...3 TIC de Práctica Docente...3 Dotación y Apoyo...3 Datos (aproximados)...4 Cómo se mantiene todo esto?...4 CGA - Quienes son?...5 CGA - Para qué?...5

Más detalles

Seguidamente se muestra una pantalla para seleccionar nuestra localización, y comprobamos que la hora y demás es correcto. Podemos hacerlo fácilmente

Seguidamente se muestra una pantalla para seleccionar nuestra localización, y comprobamos que la hora y demás es correcto. Podemos hacerlo fácilmente A continuación se presentarán los diferentes pasos a seguir para la instalación de la distribución de linux Ubuntu 6.06 en su versión Desktop, usando para esto el nuevo instalador gráfico incluido en la

Más detalles

1. Introducción a LMD (LTSP Management for non-developers)

1. Introducción a LMD (LTSP Management for non-developers) 1. Introducción a LMD (LTSP Management for non-developers) 1.1. Qué es LMD (o LliureX LMD 2.0)? LliureX LMD es la adaptación del proyecto LTSP (Linux Terminal Server Project) para el soporte de clientes

Más detalles

Como instalar Ubuntu 9.04

Como instalar Ubuntu 9.04 Como instalar Ubuntu 9.04 Hola a todos, pues como lo prometido es deuda antes del día lunes les traemos este tutorial para que las personas que deseen conocer la nueva versión de este magnífico sistema

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 1: Tareas Iniciales. Instalación Servidor

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 1: Tareas Iniciales. Instalación Servidor Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows Módulo 1: Tareas Iniciales. Instalación Servidor Aulas en red. Aplicaciones y servicios. Windows Windows Server 2008 En este apartado de

Más detalles

Cómo instalar un sistema operativo en VirtualBox http://www.noticiasubuntu.com/

Cómo instalar un sistema operativo en VirtualBox http://www.noticiasubuntu.com/ 1 de 16 Cómo instalar un sistema operativo en VirtualBox http://www.noticiasubuntu.com/ Este tutorial va dedicado a todos aquellos que estáis dando vuestros primeros pasos en VirtualBox. Vamos a aprender

Más detalles

TALLER DE TECNOLOGÍAS PARA LA EDUCACIÓN: PerúEduca Guía de Instalación y Configuración para Servidores

TALLER DE TECNOLOGÍAS PARA LA EDUCACIÓN: PerúEduca Guía de Instalación y Configuración para Servidores TALLER DE TECNOLOGÍAS PARA LA EDUCACIÓN: PerúEduca Guía de Instalación y Configuración para Servidores 1 GUÍA DE INSTALACIÓN Y CONFIGURACIÓN PARA SERVIDORES 1. INTRODUCCIÓN El sistema para servidores

Más detalles

CURSO SUPERIOR ADMINISTRACIÓN DE SISTEMAS LINUX NIVEL JUNIOR (LPIC 1) LPI 101 y LPI 102

CURSO SUPERIOR ADMINISTRACIÓN DE SISTEMAS LINUX NIVEL JUNIOR (LPIC 1) LPI 101 y LPI 102 S CURSO SUPERIOR ADMINISTRACIÓN DE SISTEMAS LINUX NIVEL JUNIOR (LPIC 1) LPI 101 y LPI 102 Linux es uno de los paradigmas más prominentes del software libre y del desarrollo del código abierto, cuyo código

Más detalles

ebox: Servidor de dominio Windows libre y gratuito

ebox: Servidor de dominio Windows libre y gratuito ebox: Servidor de dominio Windows libre y gratuito Guía de instalación y configuración Manuel Morán Vaquero mmv@edu.xunta.es Febrero 2010 Esta guía está basada en la versión 1.2 de ebox Índice 1 Introducción

Más detalles

INSTRUCTIVO DE INSTALACION EN WINDOWS Y LINUX DE ALFRESCO COMMUNITY 4.2

INSTRUCTIVO DE INSTALACION EN WINDOWS Y LINUX DE ALFRESCO COMMUNITY 4.2 INSTRUCTIVO DE INSTALACION EN WINDOWS Y LINUX DE ALFRESCO COMMUNITY 4.2 Grupo de Innovación y Apropiación de Tecnologías de la Información Archivística Compilador: Pedro Antonio Gómez Guarín Contenido

Más detalles

INSTALACION VIRTUALIZADA DE UBUNTU SERVER CON SERVICIOS LAMP Y OPENSSH SOBRE VIRTUAL BOX. Nicolás Botero Botero Juan Manuel Velásquez Isaza

INSTALACION VIRTUALIZADA DE UBUNTU SERVER CON SERVICIOS LAMP Y OPENSSH SOBRE VIRTUAL BOX. Nicolás Botero Botero Juan Manuel Velásquez Isaza INSTALACION VIRTUALIZADA DE UBUNTU SERVER CON SERVICIOS LAMP Y OPENSSH SOBRE VIRTUAL BOX Nicolás Botero Botero Juan Manuel Velásquez Isaza Universidad Tecnológica de Pereira Facultad de Ingenierías Ingeniería

Más detalles

ANEXO A: Guía de instalación de Debian GNU/Linux 4.0.

ANEXO A: Guía de instalación de Debian GNU/Linux 4.0. Técnico en Repatación de PC y Redes (intensivo) ANEXO A: Guía de instalación de Debian GNU/Linux 4.0. Introducción. La presente guía indica el paso a paso para instalar la version 4.0 de Debian GNU/Linux

Más detalles

SRI UT01 Instalación de WMware Software de máquinas Virtuales Jorge García Delgado. Jorge García Delgado

SRI UT01 Instalación de WMware Software de máquinas Virtuales Jorge García Delgado. Jorge García Delgado SRI UT01 Instalación de WMware Software de máquinas Virtuales SRI UT01 Instalación de WMware Software de máquinas Virtuales INSTALACIÓN DE WMWARE 1. Iniciamos la instalación. 2. Nos sale un asistente,

Más detalles

José Ramón Ruiz Rodríguez

José Ramón Ruiz Rodríguez Puesta en marcha de un servidor LDAP para PYMES José Ramón Ruiz Rodríguez No se permite la reproducción total o parcial de este libro, ni su incorporación a un sistema informático, ni su transmisión en

Más detalles

Redes de área local en centros educativos. Windows

Redes de área local en centros educativos. Windows Ministerio de Educación Redes de área local en centros educativos. Windows Módulo 6: W7-Gestión de imágenes Instituto de Tecnologías Educativas 2011 En este apartado nos centraremos en la gestión de la

Más detalles

Ventajas de Linux para. las empresas

Ventajas de Linux para. las empresas Whitepaper Ventajas de Linux para las empresas Nicostrato Vela, 20 Parque Tecnológico de León 24009 - León (España) Tel.: +34 987 27 90 42 www.xeridia.com INTRODUCCIÓN En los últimos años, Linux se ha

Más detalles

Toledo 25-05-2006 José Luis Martínez Director Operaciones Hispafuentes

Toledo 25-05-2006 José Luis Martínez Director Operaciones Hispafuentes Toledo 25-05-2006 José Luis Martínez Director Operaciones Hispafuentes INDICE OBJETIVO ESCULAPIO. DATOS DE HARDWARE/SOFTWARE. SITUACIÓN ACTUAL DEL PROYECTO. INFRAESTRUCTURA. SOFTWARE DE GESTIÓN. CONCLUSIONES

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 3: Gestión de equipos. Servicio WDS

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 3: Gestión de equipos. Servicio WDS Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows Módulo 3: Gestión de equipos. Servicio WDS Aulas en red. Aplicaciones y servicios. Windows Equipos Clientes del Dominio En este apartado

Más detalles

Curso de Administración de Servidores GNU/Linux

Curso de Administración de Servidores GNU/Linux Curso de Administración de Servidores GNU/Linux Centro de Formación Permanente Universidad de Sevilla Jorge Juan . Abril, 2014 Usted es libre de copiar, distribuir y comunicar públicamente

Más detalles

Administración de sistemas UNIX/Linux Ejercicio práctico optativo (IX)

Administración de sistemas UNIX/Linux Ejercicio práctico optativo (IX) Administración de sistemas UNIX/Linux Ejercicio práctico optativo (IX) 2012/2013 Introducción En este ejercicio vamos a configurar una de las máquinas para que albergue el sistema raíz de la otra y provea

Más detalles

COMPUTACION DE LA UNIVERSIDAD FRANCISCO GAVIDIA DE LA CIUDAD DE SANTA ANA.

COMPUTACION DE LA UNIVERSIDAD FRANCISCO GAVIDIA DE LA CIUDAD DE SANTA ANA. CAPITULO IV: PROPUESTA DEL DISEÑO DE LA IMPLEMENTACION Y CONFIGURACION DE UN SERVIDOR LINUX CON SERVICIOS FTP Y WEB QUE APORTE CONOCIMIENTOS SIGNIFICATIVOS A LOS ESTUDIANTES DE INGENIERIA EN CIENCIAS DE

Más detalles

Unidad 1. Despliegue de clientes Windows. Clonados. Sysprep. Redobackup. Implantación y administración remota y centralizada de Sistemas Operativos

Unidad 1. Despliegue de clientes Windows. Clonados. Sysprep. Redobackup. Implantación y administración remota y centralizada de Sistemas Operativos Unidad 1 Despliegue de clientes Windows. Clonados. Sysprep. Redobackup Implantación y administración remota y centralizada de Sistemas Operativos Manuel Morán Vaquero mmv@edu.xunta.es http://www.immv.es

Más detalles

Administración GNU/Linux Infraestructura. Entrenamiento para la Administración de Servicios de Infraestructura de Redes con GNU/Linux

Administración GNU/Linux Infraestructura. Entrenamiento para la Administración de Servicios de Infraestructura de Redes con GNU/Linux Entrenamiento para la Administración de Servicios de Infraestructura de Redes con GNU/Linux San Cristóbal, 8 de abril de 2014 Identificación del Documento 1 Lugar y fecha San Cristóbal, 8 de abril de 2014

Más detalles

Detalle de equipamiento. Laboratorio de Ingeniería Informática

Detalle de equipamiento. Laboratorio de Ingeniería Informática Laboratorio de Ingeniería Informática Dpto. Informática y Automática 1 Detalle de equipamiento Servidor LINUX. Dell PowerEdge 1950 (nogal) 30 PC s Fujitsu-siemens Esprimo P9505 Elementos de red Armario

Más detalles

servidor escuela Introducción Hardware servidor escuela Adicionalmente, se han realizado configuraciones para poder agregar otros recursos:

servidor escuela Introducción Hardware servidor escuela Adicionalmente, se han realizado configuraciones para poder agregar otros recursos: Adicionalmente, se han realizado configuraciones para poder agregar otros recursos: Introducción servidor escuela El sistema para servidores está basado en Fedora 14, un sistema estable y con un entorno

Más detalles

Curso de Linux (Versión ubuntu 9) (140 horas)

Curso de Linux (Versión ubuntu 9) (140 horas) Curso de Linux (Versión ubuntu 9) (140 horas) Curso de Linux (Versión ubuntu 9) En Vértice Training, conscientes de la continua necesidad de formación tanto del tejido empresarial actual como de la sociedad

Más detalles

Proceso de Clonado por Multicast

Proceso de Clonado por Multicast Proceso de Clonado por Multicast Con el fin de lograr un clonado de imagen de disco lo más homogéneo y rápido se puede recurrir a diversas herramientas, mucha de ellas licenciadas que requieren un costo

Más detalles

Especialista en Ingeniería de Sistemas LINUX LPIC

Especialista en Ingeniería de Sistemas LINUX LPIC Especialista en Ingeniería de Sistemas LINUX LPIC Carga Lectiva: 700 horas Formación técnica y certificación: 200 horas El alumno realiza la formación técnica utilizando las últimas tecnologías de formación

Más detalles

Luis Caballero Cruz. Ingeniería Técnica Informática de Sistemas. Universidad de Sevilla

Luis Caballero Cruz. Ingeniería Técnica Informática de Sistemas. Universidad de Sevilla Luis Caballero Cruz Ingeniería Técnica Informática de Sistemas Universidad de Sevilla 5.1- INSTALACION DE PANDORA FMS: En este capítulo analizaremos profundamente nuestra solución seleccionada en el cuarto

Más detalles

Si están trabajando en un computador real, lo primero que deben colocar los discos de manera SCSI, como mínimo deben de ser dos.

Si están trabajando en un computador real, lo primero que deben colocar los discos de manera SCSI, como mínimo deben de ser dos. Rocío Alt. Abreu Ortiz 2009-3393 RAID 0 en Debian RAID (del inglés Redundant Array of Independent Disks, «conjunto redundante de discos independientes») hace referencia a un sistema de almacenamiento que

Más detalles

Instalación de la aplicación.

Instalación de la aplicación. Manual de Instalación del Auto apagado de la UPV. Versión 1.0.1. Marzo del 2010 Redactado por Guillermo García. Dudas o erratas a guillermogn@upv.es. Instalación de la aplicación. Introducción La aplicación

Más detalles

LPIC-2. Guía de Estudio-Exámenes 201 y 202

LPIC-2. Guía de Estudio-Exámenes 201 y 202 LPIC-2. Guía de Estudio-Exámenes 201 y 202 Agradecimientos Sobre el autor Índice Introducción Introducción Qué es Linux? Por qué obtener una certificación LPI? Cómo obtener un certificado del LPI Quién

Más detalles

Novell ZENworks Configuration Management para entornos de Microsoft * Windows *

Novell ZENworks Configuration Management para entornos de Microsoft * Windows * Guía GESTIÓN DE SISTEMAS Novell ZENworks Configuration Management para entornos de Microsoft * Windows * Novell ZENworks Configuration Management para entornos de Microsoft Windows Índice: 2..... Bienvenido

Más detalles

índice CONVENCIONES USADAs...17

índice CONVENCIONES USADAs...17 índice CONVENCIONES USADAs...17 capítulo 1. INSTALAción del servidor...19 1.1 Novedades en Windows Server 2012...19 1.2 La familia de Windows Server 2012...20 1.3 Roles de Windows Server 2012...21 1.4

Más detalles

Deployment Windows con Diskless Remote Boot Linux (DRBL) y Clonezilla usando Multicast y Samba Server.

Deployment Windows con Diskless Remote Boot Linux (DRBL) y Clonezilla usando Multicast y Samba Server. Deployment Windows con Diskless Remote Boot Linux (DRBL) y Clonezilla usando Multicast y Samba Server. Trabajo Realizado por: MAP L.I. Jesús Octavio Rodríguez de Santiago Professional Communities en ITPro.es

Más detalles

Administración de Sistemas Operativos Fecha: 20-09-13

Administración de Sistemas Operativos Fecha: 20-09-13 Página 1 de 19 RESUMEN DE LA PROGRAMACIÓN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED CURSO AC. 2012 / 2013 ÁREA / MATERIA / MÓDULO PROFESIONAL Administración de Sistemas Operativos (126 horas 6 h.

Más detalles

Podemos descargar la distribucion de gnu/linux de los repositorios de Ubuntu http://releases.ubuntu.com/.

Podemos descargar la distribucion de gnu/linux de los repositorios de Ubuntu http://releases.ubuntu.com/. Instalación GNU/Linux Ubuntu -10.04.3-server-i386 Con la ayuda de este sencillo manual podemos ver como instalar Un servidor GNU/Linux, en este caso utilizaremos la distribución Ubuntu -10.04.3-server-i386

Más detalles

Administración y Seguridad de Redes ALUMNA: NANCY NALLELY TIZAPANTZI JIMÉNEZ

Administración y Seguridad de Redes ALUMNA: NANCY NALLELY TIZAPANTZI JIMÉNEZ Administración y Seguridad de Redes ALUMNA: NANCY NALLELY TIZAPANTZI JIMÉNEZ 6-2-2012 Hoy la cosa va de servidores WTF! es lo que ha salido de mi boca varias veces leyendo el post del blog de Chema Alonso,

Más detalles

Introducción a la Administración de Sistemas Unix/Linux

Introducción a la Administración de Sistemas Unix/Linux Introducción a la Administración de Sistemas Unix/Linux Departamento de Sistemas Telemáticos y Computación (GSyC) gsyc-profes (arroba) gsyc.es Febrero de 2009 GSyC - 2009 Introducción 1 c 2009 GSyC Algunos

Más detalles

PROCEDIMIENTO DE PXES

PROCEDIMIENTO DE PXES 1 de 15 01/12/2007 1:51 PROCEDIMIENTO DE PXES Mediante este procedimiento se explica cómo conseguir que un PC con un hardware mínimo y sin todos sus componentes arranque perfectamente el software necesario

Más detalles

Guía de instalación de Debian GNU/Linux para principiantes.

Guía de instalación de Debian GNU/Linux para principiantes. Guía de instalación de Debian GNU/Linux para principiantes. Introducción. La presente guía indica el paso a paso para instalar la version 4.0 de Debian GNU/Linux (nombre código Etch) en un equipo con el

Más detalles

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes

IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes IS23 Mantenimiento de Instalaciones Informáticas Práctica 7. Análisis de redes 1 Objetivos Ingeniería Técnica Informática de Sistemas Curso 2003/2004 En la presente sesión se pretende familiarizar al alumno

Más detalles

Análisis de aplicación: JDownloader

Análisis de aplicación: JDownloader Análisis de aplicación: JDownloader Este documento ha sido elaborado por el Centro de excelencia de software libre de Castilla La Mancha (Ceslcam, http://ceslcam.com). Copyright 2010, Junta de Comunidades

Más detalles

UNIVERSIDAD DON BOSCO FACULTAD DE ESTUDIOS TECNOLÓGICOS ESCUELA DE COMPUTACIÓN

UNIVERSIDAD DON BOSCO FACULTAD DE ESTUDIOS TECNOLÓGICOS ESCUELA DE COMPUTACIÓN UNIVERSIDAD DON BOSCO FACULTAD DE ESTUDIOS TECNOLÓGICOS ESCUELA DE COMPUTACIÓN CICLO: 02/2015 GUÍA DE LABORATORIO #6 Nombre de la Practica: Instalación de FreeBSD para Server. Tiempo Estimado: 2 horas

Más detalles

INTRODUCCIÓN...15 EL PROYECTO UBUNTU...29 2.1 QUÉ ES UBUNTU...29 2.2 VERSIONES DE UBUNTU...31

INTRODUCCIÓN...15 EL PROYECTO UBUNTU...29 2.1 QUÉ ES UBUNTU...29 2.2 VERSIONES DE UBUNTU...31 ÍNDICE INTRODUCCIÓN...15 BIENVENIDOS A LINUX...19 1.1 LOS ORÍGENES...19 1.2 GNU/LINUX VS. WINDOWS: VENTAJAS DE USAR GNU/LINUX...23 1.2.1 Menos cuelgues y desastres...23 1.2.2 Mayor seguridad...24 1.2.3

Más detalles

Instalación de RedHat GNU/Linux Advanced Server 2.1

Instalación de RedHat GNU/Linux Advanced Server 2.1 Instalación de RedHat GNU/Linux Advanced Server 2.1 PROYECTO Documentación DESCRIPCIÓN Este documento describe cómo instalar RedHat GNU/Linux Advanced Server 2.1 en los servidores RACK AUTOR IgnacioBarrancos

Más detalles

Introducción a la Administración de Sistemas Unix/Linux

Introducción a la Administración de Sistemas Unix/Linux Introducción a la Administración de Sistemas Unix/Linux Departamento de Sistemas Telemáticos y Computación (GSyC) gsyc-profes (arroba) gsyc.es Septiembre de 2012 GSyC - 2012 Introducción 1 c 2012 GSyC

Más detalles

Agente local Aranda GNU/Linux. [Manual Instalación] Todos los derechos reservados Aranda Software www.arandasoft.com [1]

Agente local Aranda GNU/Linux. [Manual Instalación] Todos los derechos reservados Aranda Software www.arandasoft.com [1] Todos los derechos reservados Aranda Software www.arandasoft.com [1] Introducción El Agente Aranda para sistemas Linux se encarga de recolectar la siguiente información en cada una de las estaciones de

Más detalles

Configuración del cliente VPN para la UCA en SUSE Linux 10 Solución propietaria de Nortel con IPSec

Configuración del cliente VPN para la UCA en SUSE Linux 10 Solución propietaria de Nortel con IPSec Configuración del cliente VPN para la UCA en SUSE Linux 10 Solución propietaria de Nortel con IPSec Gerardo Aburruzaga García Oficina del Software Libre de la Universidad de

Más detalles

GUÍA CONFIGURACIÓN GNU/LINUX GENÉRICA

GUÍA CONFIGURACIÓN GNU/LINUX GENÉRICA SERVICIO DE ACCESO REMOTO VPN GUÍA CONFIGURACIÓN GNU/LINUX GENÉRICA SERVICIO DE TECNOLOGIAS DE LA INFORMACIÓN Y LA COMUNICACIÓN ACLARACIÓN PREVIA Este documento muestra la configuración básica para establecer

Más detalles

Objetivos Específicos

Objetivos Específicos Antecedentes En el camino hacia el liderazgo empresarial, las compañías abordan la tarea, necesaria y compleja, de implementar herramientas de gestión capaces de dotar de total cobertura en sus áreas y

Más detalles

Introdución a GNU/Linux Edición Abalar

Introdución a GNU/Linux Edición Abalar Introdución a GNU/Linux Edición Abalar Antonio Yáñez Izquierdo Octubre 2012 Antonio Yáñez Izquierdo () Introdución a GNU/Linux Edición Abalar Octubre 2012 1 / 180 Obxectivos Capacitar ao profesorado no

Más detalles

Entorno ubicuo basado en virtualización para la docencia práctica. Entorno ubicuo basado en virtualización para la docencia práctica.

Entorno ubicuo basado en virtualización para la docencia práctica. Entorno ubicuo basado en virtualización para la docencia práctica. Adolfo Albaladejo Blázquez Entorno ubicuo basado en virtualización para la docencia práctica Una sugerencia: sea cual sea la distribución por la que se acabe optando, rogaría que fuera accesible a todos

Más detalles

Migración de un servidor de correo

Migración de un servidor de correo Coloquio Migración de un servidor de correo Laboratorio Docente de Computación. Ciro José Durán Ostos (ciro@ldc.usb.ve) 29 de junio de 2005 1 ÍNDICE 2 Índice 1. Introducción 3 2. Motivación 3 3. Características

Más detalles

Introducción a GNU/Linux

Introducción a GNU/Linux Contenido Networking Quality and Security 15 de marzo de 2006 Contenido Introducción Instalación de / 1 Introducción Contenido Introducción Instalación de / Instalación 2 Instalación Particiones Proceso

Más detalles

PROGRAMA MODULAR EN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED

PROGRAMA MODULAR EN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED Guía de estudio: Parte I Curso 2014-2015 Curso 2014/2015 GUÍA DIDÁCTICA IMPLANTACIÓN DE SISTEMAS OPERATIVOS 1. PRESENTACIÓN DEL MÓDULO Este módulo profesional contiene la formación necesaria para desempeñar

Más detalles

ClonUCA, gestión de clonaciones y de copias de seguridad

ClonUCA, gestión de clonaciones y de copias de seguridad ClonUCA, gestión de clonaciones y de copias de seguridad Autor: Ismael Cano Sánchez Tutor: Daniel Molina Cabrera (1) Calle Mercurio 30, 11510 Puerto Real Cádiz, Tfno: 686105331, ismael.cano@uca.es Aulario

Más detalles