Proyecto Fin de Carrerabibing.us.es/proyectos/abreproy/12483/fichero/PFC-2483...5 Proyecto Fin de...
108
Equation Chapter 1 Section 1 Proyecto Fin de Carrera Ingeniería de Telecomunicación Estandarización de Sistemas Operativos Linux: Herramientas de Gestión y Ciclo de Vida Autor: Miguel Ángel Romo Moruno Tutor: Rafael María Estepa Alonso Dep. Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2018
Transcript of Proyecto Fin de Carrerabibing.us.es/proyectos/abreproy/12483/fichero/PFC-2483...5 Proyecto Fin de...
Equation Chapter 1 Section 1
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Estandarización de Sistemas Operativos Linux:
Herramientas de Gestión y Ciclo de Vida
Autor: Miguel Ángel Romo Moruno
Tutor: Rafael María Estepa Alonso
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
2
3
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Estandarización de Sistemas Operativos Linux:
Herramientas de Gestión y Ciclo de Vida
Autor:
Miguel Ángel Romo Moruno
Tutor:
Rafael María Estepa Alonso
Profesor titular
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2018
4
5
Proyecto Fin de Carrera: Estandarización de Sistemas Operativos Linux: Herramientas de Gestión y Ciclo de
Vida
Autor: Miguel Ángel Romo Moruno
Tutor: Rafael María Estepa Alonso
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2018
6
El Secretario del Tribunal
7
A mi familia
8
9
Contenido ÍNDICE DE FIGURAS ....................................................................................................................................... 13
1 Introducción ........................................................................................................................................ 17
2 Objetivos y Metodología ..................................................................................................................... 19 2.1 Estructura del Proyecto ............................................................................................................................. 20
3 Estado de la Tecnología ....................................................................................................................... 23 3.1 Necesidad de Estandarización .................................................................................................................. 23 3.2 Pasos para definir un SOE ......................................................................................................................... 25
3.2.1 Definir un mapa físico y lógico de la infraestructura ...................................................................... 25 3.2.2 Definir la Biblioteca de Medios Definitiva ........................................................................................ 25 3.2.3 Definir los Entornos del Ciclo de Vida .............................................................................................. 26 3.2.4 Definir el Core Build ........................................................................................................................... 26 3.2.5 Definir contenido de aplicaciones .................................................................................................... 26 3.2.6 Automatizar el aprovisionamiento ................................................................................................... 26 3.2.7 Definir roles del departamento de TI ............................................................................................... 27 3.2.8 Gestion Continua del Contenido del Ciclo de Vida.......................................................................... 27 3.2.9 Automatización, escalabilidad y mejora continua .......................................................................... 27
3.3 Tareas a Gestionar ..................................................................................................................................... 27 3.3.1 Gestión de la Biblioteca de Medios Definitiva ................................................................................. 27 3.3.2 Gestión del Entorno del Ciclo de Vida .............................................................................................. 28 3.3.3 Gestión de la Configuración .............................................................................................................. 28 3.3.4 Gestión del Aprovisionamiento ........................................................................................................ 29 3.3.5 Gestión de Actualizaciones ............................................................................................................... 30 3.3.6 Gestión de la Seguridad .................................................................................................................... 30
4 Estandarización de Sistemas Linux con Red Hat Satellite ..................................................................... 31 4.1 Descripción y alcance de la herramienta de gestión Red Hat Satellite .................................................. 31
4.1.1 Componentes ..................................................................................................................................... 31 4.1.2 Integración y automatización ........................................................................................................... 32 4.1.3 Gestión centralizada .......................................................................................................................... 32
4.2 Entorno Operativo Estandar basado en Red Hat Satellite 6 ................................................................... 33 4.2.1 Repositorios de software .................................................................................................................. 33
4.2.1.1 Almacenamiento de Repositorios ............................................................................................ 33 4.2.1.2 Sincronizador de Repositorios .................................................................................................. 33 4.2.1.3 Presentación de Repositorios ................................................................................................... 34 4.2.1.4 Registro de sistemas a Repositorios ......................................................................................... 36 4.2.1.5 Gestión de paquetes de Repositorios ...................................................................................... 36
4.2.2 Gestión de la Configuración .............................................................................................................. 36 4.2.2.1 Sistemas de Repositorios de Objetos de Configuración ......................................................... 36 4.2.2.2 Categorizador de sistemas y Objetos de configuración .......................................................... 37 4.2.2.3 Sistema de envío de Objetos de configuración ....................................................................... 38 4.2.2.4 Aplicación de configuración ...................................................................................................... 38 4.2.2.5 Sistema de informes de ejecución de configuación ................................................................ 39
4.2.3 Relación entre componentes ............................................................................................................ 40 4.2.4 Automatización de despliegue y aprovisionamiento ...................................................................... 41
4.2.4.1 Métodos de aprovisionamiento ............................................................................................... 41 4.2.4.2 Proceso de aprovisionamiento y despliegue ........................................................................... 42
4.2.5 Auditoría de Suscripciones, Inventario y Compliance ..................................................................... 44 4.2.5.1 Auditoría y control de Suscripciones ........................................................................................ 44
10
4.2.5.2 Inventario de sistemas .............................................................................................................. 44 4.2.5.3 Gestión de la seguridad y compliance ..................................................................................... 45
4.2.6 Gestión de actualizaciones y erratas................................................................................................ 47 4.3 Versionado de Satellite y ciclo de actualizaciones .................................................................................. 48
5 Estandarización de Sistemas Operativos con Herramientas de Software Libre ................................... 51 5.1 Gestión de sistemas con Foreman y Katello ............................................................................................ 52
5.1.1 Foreman ............................................................................................................................................. 52 5.1.2 Katello ................................................................................................................................................ 52
5.2 Gestión de la configuración con Puppet y Ansible .................................................................................. 53 5.2.1 Puppet ................................................................................................................................................ 53 5.2.2 Ansible ................................................................................................................................................ 54
5.3 Gestión de la Seguridad con OWASP Zap, OpenVAS y Metasploit Framework Community ............... 54 5.3.1 OWASP Zap ........................................................................................................................................ 54 5.3.2 OpenVAS ............................................................................................................................................ 55 5.3.3 Metasploit Framework Community ................................................................................................. 55
6 Elección de la Tecnología ..................................................................................................................... 57
7 Implantación de Red Hat Satellite ........................................................................................................ 59 7.1 Preparación del servidor y configuración previa ..................................................................................... 59
7.1.1 Creación de una máquina virtual para Satellite .............................................................................. 59 7.1.2 Instalación del Sistema Operativo .................................................................................................... 59 7.1.3 Configuración previa del servidor .................................................................................................... 60
7.1.3.1 Particionado ............................................................................................................................... 60 7.1.3.2 Configuración del firewall ......................................................................................................... 62 7.1.3.3 Verificación de resolución DNS ................................................................................................ 63 7.1.3.4 Sincronización de hora .............................................................................................................. 63
7.2 Instalación y configuración inicial de Satellite ......................................................................................... 63 7.2.1 Registro del servidor e instalación de paquetes ............................................................................. 63
7.2.1.1 Registro del servidor con Subscription Manager .................................................................... 63 7.2.1.2 Instalación de paquetes de Satellite ........................................................................................ 64
7.2.2 Instalación de Satellite ...................................................................................................................... 64 7.2.3 Creación e instalación del Manifiesto .............................................................................................. 65 7.2.4 Envío de notificaciones por correo .................................................................................................. 65
7.3 Implementación del Core Build................................................................................................................. 66 7.3.1 Activación y Sincronización de Respositorios .................................................................................. 66 7.3.2 Creación de Content Views .............................................................................................................. 68 7.3.3 Creación de Lifecycle Environments ................................................................................................ 71 7.3.4 Creación de Activation Keys ............................................................................................................. 71 7.3.5 Creación de Host Groups .................................................................................................................. 73
7.3.5.1 Nivel 1 (Entornos de Ciclo de Vida) .......................................................................................... 74 7.3.5.2 Nivel 2 (Versión de Sistema Operativo) ................................................................................... 74
7.4 Registro de Servidores en Satellite ........................................................................................................... 75 7.4.1 Registro de un servidor RHEL 7.2 x86_64 ........................................................................................ 75
7.5 Gestión de la configuración con Puppet .................................................................................................. 77 7.5.1 Creación de entornos de Puppet ..................................................................................................... 77 7.5.2 Carga de módulos de Puppet en Satellite ....................................................................................... 78 7.5.3 Configuración de clases de Puppet .................................................................................................. 79
7.5.3.1 motd ........................................................................................................................................... 79 7.5.3.2 resolv.conf .................................................................................................................................. 80
7.5.4 Aplicación de configuración a clientes ............................................................................................. 81 7.6 Aprovisionamiento de servidores con Satellite........................................................................................ 82
7.6.1 Creación de un Dominio ................................................................................................................... 82
11
7.6.2 Creación de una subred .................................................................................................................... 83 7.6.3 Creación de plantillas ........................................................................................................................ 84
7.6.3.1 Plantillas de particionado .......................................................................................................... 84 7.6.3.2 Plantillas de aprovisionamiento ............................................................................................... 86 7.6.3.3 Configuración de parámetros globales para le Aprovisionamiento ...................................... 87
7.6.4 Asignación de plantillas a Sistemas Operativos ............................................................................... 88 7.6.5 Creación de Host Group para despliegues ...................................................................................... 88 7.6.6 Aprovisionamiento mediante Boot ISO ........................................................................................... 92
7.6.6.1 Creación del host ....................................................................................................................... 92 7.6.6.2 Generación de imagen de arranque ........................................................................................ 96
7.6.7 Aprovisionamiento mediante PXE-less Discovery ........................................................................... 97 7.6.7.1 Instalación de paquetes y configuración de kexec .................................................................. 97 7.6.7.2 Arranque del Servidor y Configuración de Parámetros de Red ............................................. 97
7.7 Informes de Seguridad SCAP ..................................................................................................................... 98 7.7.1 Instalación de paquetes OpenSCAP en Satellite ............................................................................. 99 7.7.2 Carga del contenido OpenSCAP en Satellite .................................................................................... 99 7.7.3 Importar módulos de Puppet de OpenSCAP en Satellite ............................................................. 100 7.7.4 Creación de una nueva política ...................................................................................................... 100 7.7.5 Añadir una política a un host .......................................................................................................... 101 7.7.6 Visualización de Informes de Seguridad ........................................................................................ 101
8 Conclusiones y líneas de avance ......................................................................................................... 105
9 Bibliografía.......................................................................................................................................... 107 Documentos ......................................................................................................................................................... 107 Páginas web ......................................................................................................................................................... 107
12
13
ÍNDICE DE FIGURAS
Figura 3-1. Diagrama de bloques para el aprovisionamiento de sistemas 29
Figura 3-2. Objetivos adicionales en el aprovisionamiento de sistemas 30
Figura 4-1. Componenetes de Satellite 31
Figura 4-2. Gestión centralizada de Organizaciones y Localizaciones 33
Figura 4-3. Repositorios en Satellite 34
Figura 4-4. Versiones de Content Views 35
Figura 4-5. Tipos de Content Views 35
Figura 4-6. Entornos de Ciclo de Vida 35
Figura 4-7. Arquitectura de Puppet 39
Figura 4-8. Informe de Puppet 40
Figura 4-9. Mapa de la relación de componentes de Satellite 41
Figura 4-10. Procceso de aprovisionamiento 42
Figura 4-11. Flujo de aprovisionamiento en Satellite 43
Figura 4-12. Relación de bloques de Satellite para el aprovisionamiento 43
Figura 4-13. Dashboard de suscripciones 44
Figura 4-14. Dashboard de estado de los hosts 45
Figura 4-15. Contenido SCAP 45
Figura 4-16. Informes de cumplimiento de reglas SCAP 46
Figura 4-17. Detalle de informes SCAP 47
Figura 4-18. Gestión de actualizaciones 47
Figura 4-19. Visualización del número de actualizaciones en Content Views 48
Figura 4-20. Detalle de tarea de aplicación de actualizaciones 48
Figure 5-1. Componentes de OpenVAS 55
Figura 7-1. Carga de Manifiesto de Suscripciones en Satellite 65
Figura 7-2. Activación de Repositorios 67
Figura 7-3. Detalle del plan de sincronización 68
Figura 7-4. Productos asociados al plan de sincronización 68
Figura 7-5. Visualización de repositorios asociados a un Content View 69
14
Figura 7-6. Versionado de Conent Views 70
Figura 7-7. Promoción de un Content View a un Entorno 70
Figura 7-8. Ruta de Entonos de Ciclo de Vida 71
Figura 7-9. Parámetros de una Activation Key 72
Figura 7-10. Suscripciones asociadas a una Activation Key 72
Figura 7-11. Repositorios asociados a una Activation Key 73
Figura 7-12. Formas de organizar los host groups 73
Figura 7-13. Host Groups jerárquicos 74
Figura 7-14. Menú de acceso a Certificados de servidores 76
Figura 7-15. Firma del Certificado de un servidor 77
Figura 7-16. Detalle de parámetros de un host registrado en Satellite 77
Figura 7-17. Entornos de Puppet en Satellite 78
Figura 7-18. Carga de nuevos módulos a un entorno de puppet 79
Figura 7-19. Clases de puppet 79
Figura 7-20. Modificación del parámetro content de la clase motd 80
Figura 7-21. Modificación del parámetro nameservers de la clase resolv_conf 81
Figura 7-22. Modificación del parámetro searchpath de la clase resolv_conf 81
Figura 7-23. Aplicación de clases de puppet a un host 82
Figura 7-24. Creación de un Dominio en Satellite 82
Figura 7-25. Visualización del Dominio creado en Satellite 83
Figura 7-26. Creación de una subred en Satellite 84
Figura 7-27. Visualización de la subred creada en Satellite 84
Figura 7-28. Asociación de una plantilla de particionado a una Organización 86
Figura 7-29. Asociación de un sistema operativo a una plantilla de aprovisionamiento 87
Figura 7-30. Parámetro Global creado en Satellite 87
Figura 7-31. Selección de la plantilla de particiones en un sistema operativo 88
Figura 7-32. Selección de plantilla de aprovisionamiento en un sistema operativo 88
Figura 7-33. Creación de un nuevo host group 89
Figura 7-34. Selección de clases de puppet en un host group 89
Figura 7-35. Selección de red en un host group 90
Figura 7-36. Selección de sistema operativo en un host Group 90
Figura 7-37. Selección de parámetros en un host group 91
Figura 7-38. Selección de Localización en un host group 91
Figura 7-39. Selección de Organización en un host group 91
Figura 7-40. Selección de activation key en un host group 92
Figura 7-41. Creación de un nuevo host para aprovisionar 93
Figura 7-42. Selección de clases de puppet asociadas a un host 93
Figura 7-43. Detalle de los parámetros de red de un nuevo host 94
15
Figura 7-44. Interfaz de red de un nuevo host 94
Figura 7-45. Selección de sistema operativo en un nuevo host 95
Figura 7-46. Selección de parámetros de un nuevo host 95
Figura 7-47. Parámetros adicionales en un nuevo host 96
Figura 7-48. Generación de la imagen de aprovisionamiento de un host 96
Figura 7-49. Selección de kexec para PXE-less Discovery 97
Figura 7-50. Reglas de descubrimiento para aprovisionar un host 98
Figura 7-51. Menú de cumplimiento SCAP 99
Figura 7-52. Contenido SCAP disponible en Satellite 99
Figura 7-53. Clases de puppet de SCAP 100
Figura 7-54. Nueva política SCAP 101
Figura 7-55. Asignación de una política a un host 101
Figura 7-56. Informes de SCAP en Satellite 102
Figura 7-57. Detalle de informe SCAP de un servidor 102
Figura 7-58. Informe completo SCAP de un servidor 103
16
17
1 INTRODUCCIÓN
oy en día, la evolución de la tecnología y los sistemas de información han dado lugar a la existencia de
complejas infraestructuras y granjas de servidores de gran tamaño y capacidad, que almacenan datos de
distinta naturaleza y ofrecen diversos tipos de servicios para su explotación por parte de empresas,
organismos públicos o usuarios finales.
La administración manual e individualizada de una infraestructura que cuenta con un gran número de servidores,
del orden de cientos o miles, tiene un elevado coste no sólo económico, sino de recursos técnicos y esfuerzo de
profesionales que se dedican a su gestión. Este esfuerzo dedicado a tareas de gestión clásicas, impide utilizar el
tiempo y personal necesarios para mejorar procedimientos y revisar indicadores, por lo cual no es posible
acometer tareas de mejora continua que hacen que un departamento o equipo de personas evolucione, efectúe
sus tareas y resuelva los problemas de forma cada vez más eficaz.
A la hora de administrar y gestionar estos sistemas, cada vez se hace más necesario el uso de metodologías
eficientes y la aplicación de procedimientos adecuados por parte de los administradores y equipos de TI, que
eviten la realización de tareas repetitivas, disminuyan la probabilidad de error en la administración de los
sistemas debidas al factor humano y aumenten la seguridad y disponibilidad de la infraestructura.
Los equipos de TI que deben administrar centros de datos con gran número de servidores se enfrentan, entre
otros, a dos problemas derivados de la gestión clásica de pequeñas infraestructuras, como son la escasa
automatización y la ejecución de tareas repetitivas. Estos problemas provocan una falta evidente de eficiencia,
un mal aprovechamiento de los recursos técnicos y humanos, ventanas de mantenimiento de larga duración, que
en determinados entornos productivos puede llegar a no ser admisible, y una probabilidad de error en la
ejecución de procedimientos y manuales de actuación innecesariamente alta.
Una gestión de sistemas moderna y actual debe enfocar los esfuerzos en conseguir un ecosistema lo más
homogéneo posible, y disponer de un número no muy elevado de herramientas o consolas centralizadas desde
las que acometer las distintas tareas de forma coordinada, controlada, automática y segura.
H
La enseñanza que deja huella no es la que se hace de
cabeza a cabeza, sino de corazón a corazón.
- Howard G. Hendrick -
18
19
2 OBJETIVOS Y METODOLOGÍA
l presente Proyecto pretende mostrar distintas herramientas que nos ayudarán a gestionar el ciclo de vida
completo de sistemas Linux.
En primer lugar, se añanizará la herramienta Red Hat Satellite, identificando los distintos proyectos que
la conforman, y cómo se integran en una sola consola desde la que podemos realizar cualquier tarea de
adiministración.
En segundo lugar, se describirán distintas herramientas open source con las que podemos realizar operaciones
relacionadas con cada uno de los aspectos del ciclo de vida de servidores, dejando en manos de los
administradores de sistemas la relación y compenetración entre ellas.
De este modo, abarcaremos la gestión de sistemas Linux, desde su creación hasta su etapa final, lo cual
proporcionará un mejor aprovechamiento de los recursos técnicos y de personal, con el consiguiente ahorro
económico, disminución de los tiempos de actuación y de respuesta ante incidencias, así como una mayor
disponibilidad de los servicios que albergan los servidores.
Se va a definir una estrategia de gestión capaz de dar respuesta a las necesidades de unos centros de datos que
cuentan cada vez más con un mayor número de servidores, diferenciando distintas etapas en el ciclo de vida de
los sistemas, desde su aprovisionamiento, configuración, tiempo durante el que ofrece un determinado servicio,
ya sea en el ámbito de desarrollo, pruebas o producción, y fase final o retirada del servidor.
Para conseguirlo, debemos centrar esfuerzos en la estandarización de los sistemas, mediante la creación de
una línea base común sobre la que se implementarán y configurarán los distintos servicios, permitiendo una
diversidad de configuraciones y posibilidades partiendo de un marco común.
Los objetivos que se pretenden conseguir con la estandarización son los siguientes:
Misma configuración base de los sistemas, obteniendo entornos más homogéneos y minimizando las
paradas de servicio y errores derivados de la configuración inicial.
Optimización de los procesos de despliegue de nuevos servidores y gestión de la configuración.
Reducción de errores al implantar una gestión de cambios con control de versiones.
Simplificación de las tareas de administración de los sistemas.
Ahorro de tiempo y gestión de recursos más eficiente, obteniendo una mayor productividad del personal
técnico.
E
20
Aplicación controlada de actualizaciones y parches de seguridad, evaluando el impacto y prioridad antes
de su instalación.
2.1 Estructura del Proyecto
El trabajo está estructurado en una serie de apartados, donde se desarrollarán, en primer lugar, los conceptos
teóricos esenciales que debemos tener en cuenta a la hora de gestionar de sistemas, tales como la necesidad de
estandarización y cómo definir un Entorno Operativo Estándar (SOE), detallando los conceptos y alcance de los
elementos involucrados.
Posteriormente, se describirán las tareas principales que debemos gestionar en cuanto a la administración de
sistemas, donde podremos tener una visión general de las necesidades a cubrir.
A continuación, se estudiarán distintas herramientas para gestionar todos los elementos definidos. Se analizará
una solución privativa como Satellite, que integra diferentes proyectos Open Source, disponible a través del
modelo de suscripciones de la compañía Red Hat, así como distintas aplicaciones Open Source que pueden ser
utilizadas de forma independiente, y cuya orquestación caerá bajo la responsabilidad del administrador. Con
estas herramientas cubriremos las necesidades de gestión en cada una de las etapas del ciclo de vida de los
sistemas.
Una vez analizadas las distintas herramientas, se justificará por cuál nos decantamos, destacando los puntos
fuertes y débiles de cada uno de los casos dependiendo de la infraestructura y entorno donde se vaya a utilizar.
Se detallará una implantación de la tecnología elegida, desde la implantación a la definición de todas las
configuraciones y parámetros necesarios para sacar todo el provecho a la herramienta.
Para finalizar, describiremos las conclusiones y líneas de avance de proyecto.
Pasamos a enumerar los apartados que conforman el Proyecto:
Estado de la tecnología
o Necesidad de estandarización
o Pasos para definicinir un SOE
o Tareas a Gestionar
Gestión de la Biblioteca de Medios Definitiva
Gestión de los Entornos del Ciclo de Vida
Gestión del Aprovisionamiento
Gestión de la Configuración
Gestión de Actualizaciones
Gestión de la Seguridad
Estandarización de Sistemas Linux con Red Hat Satellite
o Descripción y alcance de la herramienta de gestión Red Hat Satellite
o Entorno Operativo Estandar basado en Red Hat Satellite
o Repositorios de software
o Gestión de la Configuración
o Relación entre Componentes
o Automatización de Despliegue y Aprovisionamiento
o Auditoría de Suscripciones, Inventario y Compliance
o Gestión de Actualizaciones y Erratas
21
Estandarización de Sistemas Linux con herramientas Open Source
o Gestión de sistemas con Foreman y Katello
o Gestión de la configuración con Puppet y Ansible
o Gestión de la Seguridad con OWASP Zap, OpenVAS y Metasploit Framework Community
Elección de la Tecnología
Implantación de Red Hat Satellite
o Preparación del servidor y configuración Previa
o Instalación y configuración inicial de Satellite
o Implementación del Core Build
o Registro de servidores en Satellite
o Gestión de la configuración con Puppet
o Aplicación de módulos de Puppet a clientes
o Informes de Seguridad SCAP
Conclusiones y líneas de avance
22
23
3 ESTADO DE LA TECNOLOGÍA
ctualmente, ante la gran variedad de sistemas operativos y versiones, configuraciones hardware de los
servidores y herramientas de gestión de software, la administración de los sistemas e infraestuctura se
hace difícil en el mejor de los casos. Esta complejidad requiere un amplio departamento de TI con el
personal y el nivel de experiencia adecuado en todas las áreas del entorno, lo cual implica un incremento en los
costes.
Además, estos desafíos en la gestión suponen mayores tiempos de pérdida de servicio ante operaciones de
mantenimiento, lo cual supone un menor control de los recursos disponibles y los servicios a controlar. Estos
problemas también incrementan los riesgos a la hora de cumplir con la normativa y protocolos de seguridad.
Cuando tenemos múltiples procedimientos para cada configuración o versión de sistema operativo, las tareas de
aprovisionar nuevas herramientas, aplicaciones, máquinas virtuales y servidores se hacen lentas e impiden una
operativa de TI ágil, afectando al negocio.
3.1 Necesidad de Estandarización
Podemos reducir toda esta problemática o incluso eliminarla disminuyendo la complejidad y estandarizando
parte o todo el entorno de TI en un conjunto de procesos y procedimientos. Con un Entorno Operativo Estándar
(SOE, Standard Operating Environment), aumentando la escalabilidad y productividad del personal de TI. Como
el coste de cada tarea influye en el coste total de TI, aumentar la eficiencia y la productividad supondrá un ahorro
y un TCO (total cost of ownership) más bajo. Un entorno operativo estándar (SOE) también mejorará la
productividad en términos de una mayor disponibilidad de los servicios y menores tiempos de mantenimiento.
Mediante procedimientos y procesos de operaciones estandarizados, las aplicaciones, máquinas virtuales y el
hardware pueden será aprovisionados y configurados de forma rápida, aumentando la escalabilidad, flexibilidad,
agilidad y productividad. Además, reducir la complejidad de la infraestructura nos permitirá tener un mayor
control de los recursos de TI, aumentando la seguridad y reduciendo los riesgos.
La estandarización supone aumentar la consistencia y reducir la complejidad dentro de un entorno operativo. Un
SOE ideal definiría una serie de componentes, interfaces y procesos que serían utilizados por toda la
infraestructura de TI. Como es lógico, la estandarización no supone que todos los sistemas sean iguales, sino
que los sistemas tendrán unos fundamentos definidos y conocidos a partir de los cuales se pueden instalar
aplicaciones, crear máquinas virtuales o utilizar herramientas.
Por lo tanto, la estandarización se centra en tres áreas principales:
Simplificar la infraestructura de TI.
Automatización.
A
24
Optimización de la gestión y tareas de administración.
Enumeramos las ventajas que supone la estandarización:
Infraestructura consistente y simplificada
El objetivo de la estandarización es aumentar la consistencia y reducir la complejidad. Definir los
fundamentos de todos los sitemas y simplificar la infraestructura y operaciones.
Debemos tener cuidado de no aplicar esta regla al límite, lo cual nos puede llevar a tener procesos
pobremente documentados que pueden caer en el olvido, e imposibles e llevar a cabo cuando surge
algún problema.
Operaciones optimizadas
Cuando se utiliza un número reducido de versiones de sistema operativo en la infraestructura de TI, es
posible definir un conjunto único de procesos y procedimiento de operación, con el fin de simplificar y
aumentar la eficiencia de las operaciones.
Automatización
La automatización reduce el esfuerzo y el tiempo dedicado a aprovisionar nuevos servicios y recursos,
aumenta la consistencia a lo largo de los entornos y permite que una plantilla con no más personal del
necesario gestione las tareas del día a día.
Reducción del tiempo de parada
Tener un número reducido de Sistemas Operativos disminuye la probabilidad de incidencias debidas a
operaciones y de seguridad que puedan causar paradas de servicio. Al tener una infraestructura
consistente, la aplicación de buenas prácticas de gestión supone poder anticiparnos a las incidencias
antes de que ocurran y ocasionen la caída de sistemas y aplicaciones.
La aplicación de actualizaciones y parches de seguridad de forma simplificada, al haber menos variedad
de versiones, nos asegura que los sistemas siempre estarán actualizados y online de una forma más fácil
y menos costosa.
Costes de operaciones más bajo
Cada tarea tiene un peso en el coste total de TI, por lo que al aumentar la eficiencia y productividad del
personal supone un ahorro de costes y un TCO más bajo.
Aumentar la eficiencia de la plantilla de TI optimizando operacione y procesos permite que un menor
número de personas administre un mayor número de sistemas físicos y virtuales de forma más fácil y
eficiente.
Aumentar la productividad
Al poder encargarse cada administrador de un mayor número de servidores y usuarios, la infraestructura
puede crecer y escalar sin aumentar el número de administradores más de lo necesario.
Reducir carga de trabajo a nivel de soporte
Al ofrecer mejores servicios el número de incidencias de soporte técnico se reduce, disminuyendo
también el tiempo dedicado a ellas, por lo que de nuevo aumenta la productividad.
El tiempo de repuesta se ve reducido al automatizar procedimientos. Es posible aprovisionar
aplicaciones en un mayor número de sistemas dedicando una fracción de tiempo del que se necista si se
realizara de forma manual.
Incrementar la seguridad y control sobre la infraestructura
Una buena estrategia de seguridad va más allá de un simple sistema de autenticación centralizado en un
sistema de gestión de identidades. La capa de seguridad debe extenderse en todos los aspectos de nuestra
infraestructura para aumentar la resistencia a posibles ataques.
La definición de un Entorno Operativo Estándar hace que proteger nuestra infraestructura nos sea
25
mucho más sencillo. Un número reducido de variantes de nuestro sistema base nos permite tener un
mayor control sobre nuestro entorno y mantener los sistemas actualizados. Una mayor consistencia de
nuestra infraestructura nos facilia la interoperatividad y la integración de medidas de seguridad a lo
largo de toda la infraestructura.
Sin embargo, demasiada seguridad puede evitar que determinadas personas no tengan acceso a
aplicaciones y datos que necesitan, por lo que se debe identificar quién debe tener acceso a qué, y evaluar
aplicaciones y datos para controlar los efectos potenciales de un uso no autorizado. Únicamente
entonces, podemos definir una política que proporcione un equilibrio entre riesgos y accesibilidad, con
el objetivo de mantener la infraestructura segura sin afectar a la productividad del usuario.
Mayor escalabilidad bajo demanda
Los cambios son inevitables, especialmente en TI. A lo largo del ciclo de vida de un servicio, la
demanda y carga del mismo puede fluctuar. Si nuestra infraestructura tiene una naturaleza estática y no
está preparada para adaptarse, no podremos satisfacer una alta demanda de determinado servicio. Los
métodos tradicionales de aprovisionamiento hacen que debamos utilizar numerosos recursos para
satisfacer picos o niveles de demanda ocasionales.
Un Entorno Operativo Estándar nos permite escalar nuestra infraestructura y los recursos de forma
dinámica. Si nuestros sistemas tienen una línea base común, podrán proporcionar una mayor variedad
de servicios en lugar de dedicarse a una aplicación concreta. El mismo recurso podría proporcionar
múltiples servicios en momentos diferentes según la demanda. De esta forma, podremos mantener una
infraestructura más pequeña y de forma más eficiente, además de disminuir consumos, mejorar
refrigeración y reducir costes de las instalaciones.
Mejor alineamiento con negocio y mayor agilidad
El ahorro de tiempo permite al personal de TI centrarse en tareas con el propósito de aumentar sus
capacidades ofreciendo más servicios y de mejor calidad, alineándose con los objetivos de negocio de
la empresa.
3.2 Pasos para definir un SOE
A continuación se describen los pasos necesarios para definir un Entorno Operativo Estándar.
3.2.1 Definir un mapa físico y lógico de la infraestructura
Debemos tener bien esquematizada la localización física de nuestra infraestructura, así como de la topología
lógica de nuestro Datacenter.
Los esquemas deben detallar en la medida de lo possible los siguientes elementos:
Infraestructura física.
Infraestructura virtualizada.
Topología de red: identificar sistemas y direccionamiento de los diferentes segmentos de red.
o Zona LAN: Red de Área Local
o Zona DMZ: Zona Desmilitarizada
Equipos perimetrales.
Electrónica de red.
Dominios de red.
3.2.2 Definir la Biblioteca de Medios Definitiva
La Biblioteca de Medios Definitiva contiene el software que utilizarán nuestros sistemas. Engloba tanto el
26
software del Sistema Operativo como las aplicaciones instaladas porteriormente. Por lo tanto, deben quedar
definidos los siguientes puntos:
Paquetería que se va a instalar tanto en servidores como en estaciones de trabajo. Para ello, se definirán
los repositorios de paquetes que se van a utilizar, que pueden estar basados en diferentes formatos (rpm,
deb…)
Aplicaciones de terceros, o repositorios adicionales, para software específico no incluído en los
repositorios base del Sistema.
Plan de sincronización y actualización de la Biblioteca.
Firma digital y cifrado de paquetes (GPG Keys).
3.2.3 Definir los Entornos del Ciclo de Vida
En este punto debemos definir los diferentes entornos que mejor encajen con nuestris sistemas, servicios,
políticas... Se debe decider el camino que seguirán nuestros servidores definiendo entornos de Desarrollo,
Calidad, Pruebas, Preproducción, Producción…
Teniendo en cuenta que no todos los servidores pasarán por los mismos entornos, se pueden crear distintos
caminos con los entornos que más nos convengan para nuestros propósitos. Cada Sistema pertenecerá a un
entorno en un momento determinado, no teniendo que pasar necesariamente por todos los entornos de un camino
a lo largo de su ciclo de vida.
Cada entorno que definamos tendrá asociada en todo momento una determinada versión de Sistema Operativo
y de las aplicaciones que utilizaremos. Las versiones podrán cambiar a lo largo del tiempo.
Esta estructura de caminos, entornos y versiones, nos permitirá dividir nuestras tareas en capas diferentes, por
ejemplo, definiendo unos procesos para el Sistema Operativo y otros para las aplicaciones que se ejecutan en él.
3.2.4 Definir el Core Build
Mediante el Core Build definimos la línea base de Sistemas Operativos sobre los que se ejecutarán las
aplicaciones.
Además, debemos definir la configuración inicial común que tendrán nuestros sistemas, o crear distintos grupos
de configuración si tenemos un número suficiente de servidores con configuraciones communes.
Por lo tanto, la definición del Core Build engloba a los Sistemas Operativos, aplicaciones de terceros y
configuración base de nuestros sistemas.
El Core Build no debe entrar en la configuración específica de los servicios de cada sistema, pero sí en los
comunes a todos, como pueden ser los servidores DNS, servicio de sincronización de hora, o cualquiera que
consideremos que debe entrar en esta categoría.
3.2.5 Definir contenido de aplicaciones
En este punto se definen las diferentes versiones en la capa de aplicación, así como las configuraciones y la
forma de integrarlas con el Sistema Operativo. Debemos diferenciar diferentes roles y perfiles y separar
responsabilidades entre Sistema Operativo y aplicaciones.
También podemos utilizar grupos de configuración que nos sirvan para organizar mejor los elementos que
forman la capa de aplicación.
3.2.6 Automatizar el aprovisionamiento
Debemos configurar el aprovisionamiento automatizado de los Sistemas Operativos, configuraciones iniciales
y aplicaciones de terceros definidas en los puntos anteriores.
Dependiendo de la finalidad de cada sistema, podemos agrupar los hosts, y mejorar el aprovisionamiento
definiendo plantillas de instalación y tablas de particionado dinámico para cada scenario.
27
Para automatizar el aprovisionamiento podemos utilizar sistemas de arranque e instalación por red, plantillas
predefinidas de aprovisionamiento, plantillas de particionado, herramientas de despligue de configuraciones…
3.2.7 Definir roles del departamento de TI
Debemos definir diferentes perfiles en base al modelo RBAC: role-based access control.
Cada rol tendrá una serie de permisos sobre la infraestructura según una matriz de reponsabilidad. El objetivo
de esta matriz es reducir la complejidad de las entidades visibles por cada usuario en las herramientas de gestión.
También podremos definir grupos de usuarios para perfiles que tengan los mismos permisos.
3.2.8 Gestion Continua del Contenido del Ciclo de Vida
Existen algunos aspectos como las actualizaciones y parches de seguridad, nuevas versiones de software y
cambios en configuraciones que requieren de una revision continua.
Se debe definir con qué periodicidad se ejecutarán estas operaciones, ya que habrá entornos menos suscetibles
a cambios y actualizaciones (entornos productivos) y otros donde se deberá actualizar con más frecuencia
(entornos de pruebas).
3.2.9 Automatización, escalabilidad y mejora continua
Una vez definidos todos los elementos anteriores, nuestra infraestructura debe estar preparada para adaptarse de
forma rápida y eficaz a posibles mejoras: inclusion de nuevos hosts, optimización de procesos de TI.
En definitiva, debemos estar siempre abiertos a nuevas ideas que mejoren nuestros procedimientos, y tener la
infraestructura suficientemente estandarizada o organizada para adaptarse sin demasiado esfuerzo a cualquier
mejora.
3.3 Tareas a Gestionar
A continuación se describe la forma en la que se dará sólución a cada una de las principales tareas en la gestión
de los sistemas.
3.3.1 Gestión de la Biblioteca de Medios Definitiva
Los archivos necesarios para que un programa funcione se agrupan en paquetes instalables en el Sistema
Operativo. En GNU/Linux estos paquetes son gestionados por terceras aplicaciones, con las cuales podremos
realizar cualquier operación necesaria con los mismos. Un programa puede estar formado por uno o varios
paquetes, donde residirán ejecutables, librerías, ficheros de configuracion necesarios para el software funcione.
Existen normalmente tres formatos o tipos de paquetes en GNU/Linux:
rpm: utilizados en distribuciones basadas en Red Hat, como CentOS, Fedora, Scientific Linux… pueden
contener tanto binarios como código fuente.
deb: empleados en distribuciones basadas en Debian, como Ubuntu
tar.gz: código fuente preparado para ser compilado e instalado directamente en el sistema.
Los paquetes se almacenan en repositorios ubicados en servidores accesibles a través de internet, de forma que
podemos realizar distintas operaciones sobre ellos a través de los gestores de paquetes.
Cada distribución mantiene sus propios repositorios oficiales, con sus políticas particulares de versiones y
actualizaciones, dependiendo de la criticidad de los programas. Por otro lado, existen repositorios no oficiales,
que contienen aplicaciones no soportadas directamente por la distribución, pero que pueden funcionar bajo el
soporte de los propios desarrolladores de los programas.
Para realizar operaciones con los paquetes almancenados en los repositorios, se utilian los gestores de paquetes.
Existen distintos gestores de paquetes según el tipo de paquetes que gestiona. Para el formato deb,
28
principalmente se utiliza el gestor de paquetes apt (Advanced Packaging Tool), mientras que los paquetes rpm
se gestionan con la herramienta yum (Yellowdog Updater Modifier).
Las principales operaciones que se pueden realizar con los gestores de paquetes son:
Instalar
Desinstalar
Actualizar
Consultar
Verificar
Listar
Además de estas tareas, cada herramienta tiene sus opciones y comandos para realizar tareas más avanzadas
sobre los paquetes.
Los paquetes tar.gz se descomprimen con la herramienta tar, y normalmente contienen en un directorio los
archivos de código fuente, de documentación y scripts necesarios para el programa. A continuación se ejecutan
los siguientes pasos:
1. ./configure: mediante este comando ejecutamos el script de configuración, donde se verifcan las
dependencias y se preparan las variables del compilador.
2. make: en este paso se compila el código fuente y se convierte a binario.
3. make install: el programa se instalará en las rutas especificadas para que pueda ser ejecutado en el
sistema.
3.3.2 Gestión del Entorno del Ciclo de Vida
El ciclo de vida de las aplicaciones y servidores se divide en entornos de ciclo de vida, que representan cada
etapa por la que la aplicación o servidor puede pasar a lo largo de su existencia.
Los entornos de ciclo de vida pueden variar de una aplicación a otra, o de un servidor a otro. Normalmente, los
entornos de Desarrollo, Pruebas y Producción están presentes en la mayoría de infraestructuras, aunque puede
haber más o menos entornos según las necesidades y la naturaleza de las aplicaciones.
Las aplicaciones son desarrolladas en el entorno de Desarrollo, donde se crean nuevas versiones o se añaden
nuevas funcionalidades.
Posteriormente se ponen a prueba en el entrono de Pruebas (testing o preproducción), para verificar el
funcionamiento y detector posibles fallos.
Finalmente, una vez probada la aplicación, estaría preparada para su lanzamiento en Producción.
3.3.3 Gestión de la Configuración
La configuración de servidores es una tarea que suele realizarse después de la instalación de un Sistema
Operativo, para habilitar o deshabilitar servicios, funcionalidades y parámetros según el propósito de cada
servidor.
Aunque las configuraciones suelen ser muy variadas, normalmente existe un elenco de parámetros comunes a
los servidores de una organización. Es en este punto donde podemos sacar provecho de la estandarización, y del
uso de una herramienta que nos proporcione una forma automatizada de aplicar las diferentes configuraciones
en distintos grupos de servidores.
Existen numerosas herramientas de despliegue de configuraciones tales como Puppet, Ansible, con las cuales
podemos aumentar la eficiencia a la hora de realizar tareas repetitivas en distintos servidores.
29
3.3.4 Gestión del Aprovisionamiento
Uno de los objetivos que se persiguen tras la estandarización es ahorrar costes en tiempo de provisionamiento y
automatización de los sistemas, reutilizando componentes, bloques o secciones de código común entre diferentes
core-builds.
Figura 3-1. Diagrama de bloques para el aprovisionamiento de sistemas
Los principales objetivos a cubrir deberían ser, como mínimo:
1. Provisionar un servidor físico o virtual en cuestión de minutos.
2. Instalación de paquetería y software preparado para entornos de infraestructura (IaaS) o de aplicación
(PaaS).
3. Evitar intervención manual antes y durante el despliegue.
4. Evitar, en la medida de lo posible, intervención manual post-despliegue.
5. Definición de perfiles para sistemas físicos y/o virtuales, independientes y optimizados para cada
plataforma.
6. Integración con herramientas de inventariado o de control IT (ITSM).
7. Tras la fase de aprovisionamiento, disponer de un sistema preparado para ser productivo.
El esfuerzo de implementar y asegurar estos puntos anteriores puede resultar costoso en tiempo y esfuerzo al
principio, pero rápidamente se obtienen mejoras en eficiencia operativa gracias a la gestión centralizada.
Este mismo esquema puede adaptarse para otros objetivos que se consideren potencialmente optimizables,
como:
1. Recuperación ante desastres
2. Clonado de sistemas
3. Escalado dinámico y controlado
30
Figura 3-2. Objetivos adicionales en el aprovisionamiento de sistemas
3.3.5 Gestión de Actualizaciones
La aplicación de actualizaciones es otra de las tareas que deben realizarse de forma periodica en cualquier
infraestructura, para mantener unos niveles de seguridad y corregir problemas de las aplicaciones y servicios
que se ejecutan en nuestros servidores.
Normalmente, estas actualizaciones pueden ser de distintos tipos:
Actualizaciones de seguridad (muy recomendables)
Actualizaciones de corrección de errors (recomendables)
Actualizaciones de mejoras, que añaden nuevas funcionalidades.
Es altamente aconsejable mantener una política periódica de revision de actualizaciones e instalación de las
mismas para tener nuestros servidores protegidos ante posibles ataques.
3.3.6 Gestión de la Seguridad
SCAP es una solución de verificación de cumplimiento para la estructura a nivel empresarial de Linux. Es una
línea de especificaciones mantenida por el National Institute of Standards and Technology (NIST) para mantener
la seguridad de sistemas en sistemas empresariales.
OpenSCAP es una herramienta de auditoría que utiliza el Formato de descripción de verificación de
configuración extendible (XCCDF). XCCDF es una forma estándar de expresar el contenido de verificación y
definir verificaciones de seguridad. También se combina con otras especificaciones tales como CPE, CCE, y
OVAL, para crear una lista de verificación SCAP-expressed que puede ser procesada por productos de SCAP-
validated.
31
4 ESTANDARIZACIÓN DE SISTEMAS LINUX CON
RED HAT SATELLITE
4.1 Descripción y alcance de la herramienta de gestión Red Hat Satellite
ed Hat Satellite es un sistema escalable de gestión de servidores, que proporciona herramientas tanto de
despliegue como gestión de subscripciones, ciclo de vida de software y de configuración orientado
específicamente para la gestión centralizada de amplios parques de sistemas Red Hat Enterprise Linux.
Recientemente, Red Hat Satellite también permite gestionar contenedores de manera integrada, para dar
respuesta a una necesidad creciente de gestión de ciclo de vida de contenedores en un entorno empresarial.
4.1.1 Componentes
Satellite 6 incluye los siguientes componentes, cada uno con unas funcionalidades muy específicas e integrados
en una solución de gestión de sistemas RHEL única:
Figura 4-1. Componenetes de Satellite
Puppet es una herramienta diseñada para administrar la configuración de sistemas Linux y Microsoft
Windows de forma procedimental y posibilitar la gestión de infraestructura como código.
R
32
Foreman es una aplicación que se utiliza para el aprovisionamiento y el ciclo de vida de la gestión de
sistemas físicos y virtuales. Foreman configura automáticamente estos sistemas utilizando diversos
métodos, incluyendo Kickstart y módulos de Puppet. Foreman también proporciona datos históricos
para presentación de informes, auditoría y resolución de problemas.
Katello es una aplicación de administración de suscripciones y repositorios. Proporciona un medio para
suscribirse a los repositorios de Red Hat y descargar contenido. Con Katello se pueden crear y gestionar
diferentes versiones de este contenido y aplicarlos a sistemas especificados por el usuario dentro de las
etapas definidas del ciclo de vida de la aplicación.
Pulp es un servicio dentro de Katello que maneja repositorios y gestión de contenidos.
Candlepin es un servicio dentro de Katello que se encarga de la administración de suscripciones.
4.1.2 Integración y automatización
Red Hat Satellite 6 ofrece una interfaz accesible a través de un navegador web para una gestión cómoda, así
como una CLI y un API REST para automatizar procesos:
Hammer es una herramienta CLI que ofrece la mayoría de las funciones de la interfaz de usuario Web
a través de la línea de comandos.
Red Hat Satellite 6 incluye un servicio API REST que permite a los administradores de sistemas y los
desarrolladores escribir scripts personalizados y aplicaciones de terceros que interactúan con Red Hat
Satellite.
4.1.3 Gestión centralizada
Red Hat Satellite dispone de una arquitectura preparada para soportar múltiples organizaciones y localizaciones,
de manera jerárquica:
33
Figura 4-2. Gestión centralizada de Organizaciones y Localizaciones
Red Hat Satellite Capsule Server actúa como proxy para algunas de las principales funciones de Satellite 6
incluyendo almacenamiento de repositorios, DNS, DHCP y configuración de Puppet Master. Cada servidor
Satellite también contiene servicios integrados de Red Hat Capsule.
4.2 Entorno Operativo Estandar basado en Red Hat Satellite 6
4.2.1 Repositorios de software
4.2.1.1 Almacenamiento de Repositorios
Red Hat Satellite 6 proporciona un sistema para el almacenamiento de los repositorios basado en sistemas de
ficheros locales para su presentación a los sistemas gestionados en forma de repositorios YUM.
Dicho sistema de ficheros locales evita la duplicidad de paquetes, es decir, si el mismo repositorio se presenta
en varios Productos, Red Hat Satellite 6 creará una jerarquía de directorios que enlacen con la copia única
descargada del repositorio elegido para evitar así duplicar paquetes existentes y ya descargados.
4.2.1.2 Sincronizador de Repositorios
Red Hat Satellite 6 utiliza Pulp como tecnología para la sincronización con repositorios externos de manera
34
manual o planificada periódicamente.
Las operaciones de configuración de repositorios externos y sincronización se pueden realizar desde la interfaz
web de Red Hat Satellite 6, a través de la línea de comandos CLI (Hammer) o vía API REST.
Los repositorios susceptibles de ser sincronizados pueden ser proporcionados por Red Hat como base para el Sistema Operativo o de otros proveedores de software, incluido uno o varios orígenes de software
personalizados o de terceros que presenten su información en forma de repositorio a través de http/https.
Red Hat Satellite 6 permite que esta sincronización pueda suceder a través del proxy de la organización o con
conexión directa a los repositorios YUM públicos a través de Internet (Red Hat Content Delivery Network o
CDN).
4.2.1.3 Presentación de Repositorios
Pulp es la tecnología que proporciona los paquetes existentes en formato de repositorios YUM presentados a los
clientes utilizando protocolo HTTPS, además Pulp permite el copiado de paquetes entre diferentes repositorios
gestionados internamente.
Estas capacidades son utilizadas por Red Hat Satellite 6 para la creación de repositorios lógicos denominados
Productos.
Figura 4-3. Repositorios en Satellite
Estos Productos se agrupan en Vistas de Contenido (Content Views), que no son más que una especie de
instantáneas de los repositorios en un momento determinado:
35
Figura 4-4. Versiones de Content Views
Figura 4-5. Tipos de Content Views
Sobre estos Content Views se define un ciclo de vida en el que se representan los entornos definidos y sobre los
cuales se asocian los equipos que van a ser gestionados por la plataforma.
Figura 4-6. Entornos de Ciclo de Vida
36
Definiciones relacionadas:
Entorno de Ciclo de Vida: Un entorno define cada una de las fases del ciclo de vida de una Vista de
Contenido.
o Por ejemplo, Integración, Pre-Producción y Producción.
o Se puede tener distintos Ciclos de Vida, con distintos Entornos.
Vista de Contenido: Es una agrupación de repositorios de Paquetes RPM/Módulos Puppet, en un
momento determinado. Una Vista de Contenido tiene varias características principales:
o Sujeta bajo un número de versionado
o Una vez publicada, una versión es invariable
o El contenido publicado puede ser filtrado, de forma que no se tiene por qué incluir todo un
repositorio entero sino solamente aquellos Paquetes RPM/Módulos Puppet relevantes.
o Una versión puede promocionar a lo largo de uno (o más de uno) ciclo de vida definido, pero
no puede haber dos versiones de una Vista de Contenido en el mismo Entorno del Ciclo de
Vida.
Todas las operaciones asociadas con la creación y mantenimiento de Productos, Vistas de Contenido, Ciclos de
Vida y Sincronización, se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de línea de
comandos o vía API REST.
4.2.1.4 Registro de sistemas a Repositorios
La asociación de Vistas de Contenido y sistemas gestionados es proporcionada por Red Hat Satellite 6. El
registro de sistemas en Red Hat Satellite 6 se realiza desde los propios sistemas gestionados (de manera manual
o automática).
La herramienta encargada del registro es subscription-manager la cual proporciona métodos, además, de gestión
de repositorios.
Las operaciones de modificación de estas asignaciones se pueden realizar desde la interfaz web de Red Hat
Satellite 6, a través de línea de comandos o vía API REST.
4.2.1.5 Gestión de paquetes de Repositorios
Yellow Dog Updater Modified (YUM) es la herramienta de gestión de paquetes RPM instalados o con
posibilidad de ser instalados para Red Hat Enterprise Linux.
YUM se provee como parte de la instalación de Red Hat Enterprise Linux por defecto y se utilizará para el
consumo de los repositorios ofrecidos ya sea por Red Hat Satellite 6 o de forma local en cada sistema gestionado.
Sin embargo, la activación/desactivación de los repositorios se realiza a través de subscription-manager, el cual
tiene visibilidad sobre los repositorios a los que tiene acceso un equipo.
4.2.2 Gestión de la Configuración
4.2.2.1 Sistemas de Repositorios de Objetos de Configuración
Red Hat Satellite 6 proporciona un sistema de gestión de repositorios de módulos Puppet. Los módulos Puppet
actúan como contenedores de las clases Puppet, que se aplican a equipos y/o grupos de equipos.
Esta funcionalidad permite la creación de repositorios para almacenar los módulos, mantener los repositorios de
forma manual y/o mantenerlos sincronizados con otros repositorios externos (PuppetForge, por ejemplo) de
forma periódica o bajo demanda.
En Red Hat Satellite 6 los repositorios se agrupan en Productos, de forma que un Producto puede estar formado
por varios repositorios, y cada repositorio tiene asociado su propio plan de sincronización (si fuera el caso).
37
Estas operaciones se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de la CLI o vía API
REST.
4.2.2.2 Categorizador de sistemas y Objetos de configuración
Red Hat Satellite 6 actúa también como ENC (External Node Classifier) para Puppet Master, permitiendo:
1. Categorizar los sistemas gestionados en grupos de sistemas, denominados dentro de la herramienta por
su nombre en inglés “Host Groups”.
2. Asignar clases Puppet a diferentes grupos de sistemas de acuerdo a los requisitos de cada tipología de
sistemas. Estos grupos de sistemas pueden ser anidados en una jerarquía de padres e hijos de forma que
las clases aplicadas a un grupo padre son aplicadas también a sus grupos hijos.
3. Asignar valores a los parámetros de las clases a diferentes niveles: global, entorno, grupo de sistemas
y/o sistema. Tiene mayor prioridad el valor definido en un nivel más cercano al sistema, de forma que
un valor de parámetro definido en el sistema prevalece sobre un valor del mismo parámetro definido en
el entorno.
Definiciones relacionadas:
Módulo Puppet: Es la unidad de empaquetado de clases Puppet.
o El formato de empaquetado que se va a usar es un formato conocido y definido, con una
estructura de carpeta y metadatos concreto.
o Este formato específico es el que permite a Red Hat Satellite seleccionar los paquetes por su
número de versión para cada caso.
Clase Puppet: Una clase Puppet define la configuración deseada para un elemento concreto del
dispositivo (un fichero, un servicio, un paquete de software, etc.).
o Las Clases Puppet están escritas en Python, pueden tener parámetros de clase y soportan
herencia de clases.
Parámetro de Clase: Las Clases Puppet pueden tener parámetros de clase en su definición, permitiendo
comportamientos diferentes en función de estos parámetros.
o Por ejemplo, una misma Clase Puppet puede servir para configurar un servidor NTP diferente
en función del Parámetro de Clase.
o Los valores de estos Parámetros de Clase pueden ser especificados desde el ENC integrado en
Red Hat Satellite 6, prevaleciendo sobre los escritos en el código de la Clase Puppet.
Parámetro Global: Un tipo más general de Variable de Clase. Es un parámetro definido en el ENC
integrado en Red Hat Satellite 6 que puede ser usado desde cualquier Clase Puppet.
Ámbito de una Variable/Parámetro:
o Los Parámetros Globales, Variables de Clase y Parámetros de Clase pueden definirse en el
ENC a distintos niveles de la jerarquía de Sistemas Gestionados/Grupos de Sistemas y
aplicando condiciones complejas.
o Esta granularidad permite reutilizar el código de las Clases Puppet y mantener distintos tipos
de Sistemas Gestionados.
o En caso de asignar valores distintos a una misma Variable/Parámetro en distintos ámbitos,
prevalece el valor en el ámbito más cercano al Sistema Gestionado.
Grupo de Sistemas:
o Para facilitar la administración, los Sistemas Gestionados se pueden agrupar, permitiendo
actuar sobre el Grupo de Sistemas Gestionados para realizar cambios a más de un Sistema
Gestionado al mismo tiempo.
o Un Sistema Gestionado únicamente puede pertenecer a un único Grupo de Sistemas.
38
o Los Grupos de Sistemas pueden anidarse, creándose una jerarquía entre ellos que facilita la
herencia de Parámetros ya sean de Clase o Globales.
Organización y Localización: Red Hat Satellite 6 permite clasificar y agrupar los Sistemas Gestionados
por organizaciones y localizaciones. Esta clasificación es útil en caso de que la administración de los
equipos esté delegada a distintos grupos de forma que cada usuario únicamente pueda actuar sobre su
Organización y/o Localización.
Todas las operaciones de gestión del ENC se pueden realizar desde la interfaz web de Red Hat Satellite 6, a
través de la CLI o via API REST.
4.2.2.3 Sistema de envío de Objetos de configuración
Puppet Master es un componente embebido e integrado dentro de la solución de Red Hat Satellite 6 y se encarga
de atender las solicitudes de los clientes (Puppet Client) instalados en los sistemas gestionados.
El servidor Puppet Master recibe las peticiones de configuración de los sistemas gestionados (a través de Puppet
Client), compila y parametriza las clases de configuración asignadas para el sistema específico (de acuerdo a la
asignación realizada en el ENC) y se las envía para que se apliquen en el sistema gestionado.
En la arquitectura de Red Hat Satellite 6 se contempla la opción de que los sistemas gestionados se conecten al
servidor central o a una de las capsulas donde están replicados todos los módulos de Puppet necesarios. Esta
característica proporciona a Red Hat Satellite 6 capacidad para distribuir la carga que supone atender solicitudes
de más sistemas al mismo tiempo.
4.2.2.4 Aplicación de configuración
Puppet Client es un componente incluido dentro de Red Hat Enterprise Linux y se encarga de realizar solicitudes
a un servicio (Puppet Master) instalado en un sistema remoto para obtener un conjunto de políticas de
configuraciones (acorde con su clasificación en el ENC y su estado actual) y aplicarlas en el sistema gestionado.
39
Figura 4-7. Arquitectura de Puppet
Como parte de la ejecución de Puppet Client hay tres puntos claves:
Envío del estado actual:
o Puppet Client envía el estado actual del sistema Puppet Master para obtener las políticas de
configuración a aplicar.
o Esta información incluye datos como servicios en marcha, procesos en ejecución, usuarios
locales, números de serie de hardware, e incluso datos personalizados.
o El resultado es que se tiene información de los sistemas gestionados periódicamente que puede
usarse para realizar estadísticas, consultas o inventariado.
Ejecución de la aplicación:
o Puppet Client realiza todas aquellas tareas necesarias para asegurar el estado del dispositivo
acorde con la política de configuración recibida.
Envío del informe de resultados:
o Puppet Client envía el resultado de la ejecución de vuelta a Puppet Master para su análisis.
La ejecución de Puppet Client puede ser ejecutada bajo demanda o periódicamente desde el sistema gestionado,
así como solicitada bajo demanda desde la interfaz web de Red Hat Satellite 6, a través de la CLI o vía API
REST.
4.2.2.5 Sistema de informes de ejecución de configuación
Una vez que Puppet Client ha terminado de aplicar las configuraciones pertinentes, envía el resultado de la
ejecución de la configuración al Puppet Master.
Esta información es almacenada en Red Hat Satellite 6 que la presenta a través de su interfaz web para su
visualización y explotación posterior.
40
Figura 4-8. Informe de Puppet
Se incluye en el resultado la siguiente información (puede variar según las necesidades):
Tiempo total de la ejecución, así como desglosado (obtener configuración, aplicar servicios, editar
ficheros o instalar software).
Número de eventos de cada tipo (pendiente, reiniciado, omitido, aplicado, fallido).
Mensajes de diagnóstico que se envíen desde las clases Puppet (catalogados por criticidad: aviso,
notificación, error, etc.).
En caso de modificar ficheros, se incluye un resumen de las diferencias entre el fichero original y el
final.
4.2.3 Relación entre componentes
Todos los componentes (a excepción de los parámetros, variables y ámbitos) explicados anteriormente se
agrupan/relacionan en el siguiente mapa:
41
Figura 4-9. Mapa de la relación de componentes de Satellite
4.2.4 Automatización de despliegue y aprovisionamiento
Red Hat Satellite 6 ofrece la posibilidad de gestionar de manera centralizada y ordenada las siguientes entidades:
Plantillas de provisionamiento (basadas en kickstart).
Parametrización constante y variable (en tiempo de despliegue).
Bloques de código reutilizables (snippets).
Agrupaciones de Hosts con perfiles de configuración diferentes (para diferentes perfiles de sistemas).
Core-build: Por defecto, Red Hat Satellite 6 ya ofrece un diseño para sistemas RHEL 6 y 7 basado en
un core-build mínimo, que incluye “out-of-the-box” lo siguiente:
o Particionamiento de sistemas de ficheros.
o Instalación de software base (rpms) para el sistema operativo y gestión de configuración.
o Configuración de red estática o dinámica.
o Configuración básica de componentes core:
o NTP
o DNS
o Integración con proveedores de identidad (RHEL Identity Management, LDAP…).
o Integración de clientes de monitorización (Zabbix, Nagios…).
4.2.4.1 Métodos de aprovisionamiento
Red Hat Satellite 6 dispone de los siguientes métodos de aprovisionamiento y despliegue:
PXE:
o Basado en el estándar Pre-boot Execution Environment.
42
o La cápsula de Satellite dispone de servicios TFTP y DHCP para gestionar el despliegue
centralizado y local para cada organización/localización.
o Combinado con la automatización de la instalación basada en kickstart, esta aproximación
permite automatizar por completo el proceso de despliegue.
Boot ISO:
o Método tradicional que requiere intervención manual para inyectar la imagen ISO a desplegar.
o Bajo grado de automatización.
Basado en imagen:
o Solo disponible para plataformas de virtualización tradicional (RHEV, vSphere) o Cloud
(OpenStack, AWS, Azure).
o Método más rápido y efectivo para plataformas no bare-metal.
Satellite Discovery:
o Creación de una imagen ISO que contiene los elementos necesarios para dar de alta
automáticamente un sistema físico o virtual.
o Pueden declararse reglas más o menos complejas para gestionar la automatización de
despliegue por este método.
4.2.4.2 Proceso de aprovisionamiento y despliegue
Para asegurar un despliegue completo y automatizado, cada fase y aplicar los bloques lógicos en orden:
Figura 4-10. Procceso de aprovisionamiento
El flujo completo de aprovisionamiento tal cual lo plantea Red Hat Satellite 6 es el siguiente:
43
Figura 4-11. Flujo de aprovisionamiento en Satellite
Figura 4-12. Relación de bloques de Satellite para el aprovisionamiento
44
Durante el proceso de análisis y diseño, todos estos bloques tienen que ser analizados con cuidado y determinar
la manera más óptima de crearlos o reutilizar lo que ya dispone el entorno a analizar.
4.2.5 Auditoría de Suscripciones, Inventario y Compliance
4.2.5.1 Auditoría y control de Suscripciones
Red Hat Satellite 6 dispone de Candlepin como componente de gestión de subscripciones. A través de la GUI,
CLI y API REST de Satellite, es posible obtener información actualizada en tiempo real del uso de
subscripciones de Red Hat para todos nuestros entornos.
Figura 4-13. Dashboard de suscripciones
Al estar preparado para gestionar compañías multi-organización, este control es completamente aislado entre
organizaciones, por lo que la privacidad está garantizada.
4.2.5.2 Inventario de sistemas
Red Hat Satellite 6 permite controlar de manera fácil y sencilla el inventario de los sistemas pertenecientes a una
misma organización, indicando su nivel de reporting, estado actual, aplicación de configuración y eventos más
importantes:
45
Figura 4-14. Dashboard de estado de los hosts
El agente de puppet en cada sistema es el encargado de reenviar periódicamente los “facts” de cada sistema,
alimentando el servidor de Satellite 6 central y nutriendo de información muy valiosa para la explotación y
correcta operación de los sistemas.
4.2.5.3 Gestión de la seguridad y compliance
Red Hat Satellite 6 permite gestionar reglas de compliance para todos nuestros sistemas, de manera fácil y
centralizada. Para ello se apoya en OpenSCAP, integrado en RHEL 6 y RHEL 7.
Desde Red Hat Satellite, de manera centralizada se pueden crear test de compliance compatibles con el estándar
SCAP, políticas de seguridad y asignarlas a grupos de hosts de manera fácil y sencilla (para sistemas RHEL 6 y
RHEL 7):
Figura 4-15. Contenido SCAP
Gracias al componente Foreman-OpenSCAP, En Red Hat Satellite es posible recibir informes de
46
vulnerabilidades de seguridad y compliance/auditoría de todos aquellos sistemas administrados por Red Hat
Satellite.
Figura 4-16. Informes de cumplimiento de reglas SCAP
OpenSCAP genera informes ARF (Asset Reporting Format) e incluso es capaz de aplicar remediación ante
riesgos de manera automatizada, para asegurar que el conjunto de sistemas gestionados no es objeto de
vulnerabilidades de sistema o seguridad.
Se puede navegar por los diferentes menús y observar el nivel de compliance de cada sistema:
47
Figura 4-17. Detalle de informes SCAP
4.2.6 Gestión de actualizaciones y erratas
Cualquier herramienta de gestión que pretenda servir como pieza central de un SOE, precisa de mecanismos
para facilitar la actualización y ciclo de vida de software, pudiendo lanzar tareas de manera centralizada y
actualizar/parchear un conjunto de sistemas por entornos, de acuerdo a las políticas establecidas por la
organización y/o cliente.
Red Hat Satellite 6 permite realizar esta tarea gracias a los grupos de host y a Katello como herramienta principal
de que permite lanzar operaciones de actualización de cualquiera de los productos incluidos en una vista de
contenido:
Figura 4-18. Gestión de actualizaciones
Gracias a las vistas de contenido, se pueden publicar y manejar diferentes versiones y agrupaciones de paquetes
con sus correspondientes niveles de parcheado:
48
Figura 4-19. Visualización del número de actualizaciones en Content Views
Además, podemos publicar vistas de contenido entre entornos, definiendo así el ciclo de vida de cada uno de
los productos gestionados por Red Hat Satellite 6.
Así mismo, es posible revisar la aplicación correcta de los parches fácilmente via GUI:
Figura 4-20. Detalle de tarea de aplicación de actualizaciones
O también haciendo uso de Hammer como CLI o del API REST.
4.3 Versionado de Satellite y ciclo de actualizaciones
Actualmente Satellite se ecuentra en su versión 6 y mantiene un ciclo de actualizaciones y revisiones periódico,
diferenciando versiones mayores y menores del producto.
Las versiones mayores son enumeradas como 6.1, 6.2, 6.3, y proporcionan saltos significativos en las
49
funcionalidades de la herramienta, mientras que las versiones menores (6.1.x, 6.2.x, 6.3.x) están enfocadas a
mejorar la integración de las herramientas, resolver problemas y pulir los procesos internos de funcionamiento.
La última versión mayor, la 6.3, publicada recientemente, ha introducido una serie de nuevas características y
mejoras, entre las que podemos destacar las siguientes:
Integración con Ansible Tower: con Ansible Tower podemos automatizar taras de gestión como
aprovisionamiento cloud, configuración y despliegue de aplicaciones. Satellite proporciona un
inventario dinámico y la capacidad de ejecutar playbooks después del aprovisionamiento.
Soporte EC2: Satellite puede funcionar en la nube de Amazon (Amazon Elastic Compute Cloud, EC2).
Utilidad de clonado: capacidad para restarurar Satellite en un entorno bare metal, clonando un backup
de la versión 6.1 o 6.2, y actualizando el clon a la versión 6.3.
Selección de la política de sincronización de repositorios: bajo demanda, background, inmediato o
heredado del repositorio.
Soporte para suscripciones futuras: podemos generar manifiestos que incluyen suscripciones con fecha
futura.
Panel de notificaciones: esta versión añade un panel de notificaciones en la interfaz web de usuario, que
informará de los eventos y cambios más importantes en el entorno (descubrimiento de hosts, borrado
de hosts, aprovisonamiento exitoso de un sistema, host importado sin propietario asociado).
Soporte para Puppet 4
Soporte para Red Hat Virtualization 4
Soporte UEFI: se soporta el arranque PXE de sistemas UEFI.
50
51
5 ESTANDARIZACIÓN DE SISTEMAS
OPERATIVOS CON HERRAMIENTAS DE
SOFTWARE LIBRE
xisten nuemoras herramientas basadas en software libre que nos pueden ayudar a realizar las tareas que
necesitamos para mantener nuestra infraestructura con unos niveles de calidad y estandarización
adecuados.
A continuación, veremos qué alternativas tenemos y qué tareas podemos realizar con estas herramientas de
código libre en cuanto a la estandarización y automatización, así como sus ventajas e inconvenientes respecto a
la herramienta Satellite.
Las herramientas que vamos a ver para la gestión de sistemas son las siguientes:
Foreman: gestión del ciclo de vida (aprovisionamiento, configuración…)
Katello: gestión de contenido
Estas herramientas utilizan otro conjunto de aplicaciones para realizar distintas tareas de forma orquestada, tales
como:
Pulp: gestión de repositorios de paquetes, contenedores, módulos de puppet
Candlepin: gestión de suscripciones y canales
Puppet: gestión de la configuración
Ansible: gestión de la configuración
E
52
5.1 Gestión de sistemas con Foreman y Katello
5.1.1 Foreman
Foreman es una suite para la gestión del ciclo de vida, que se encarga de todas las tareas necesarias para
aprovisionar, configurar y monitorizar sistemas, independientemente de si tenemos que gestionar sistemas
físicos, virtuales o contenedores docker.
Podemos crear sistemas mediante arranque por red, automatizando y estandarizando el proceso con Foreman.
Además, utilizando plugins adicionales, podemos realizar estas tareas en distintas infraestructuras de
virutalización, cloud o escenarios híbridos, tales como:
VMware
oVirt
Amazon EC2
Microsoft Azure
XEN
OpenStack, OpenNebula
Para la gestión de la configuración Foreman utiliza Puppet por defecto, mediante el uso de plugins. De este
modo, se añaden funcionalidades de forma modular. También puede funcionar con otras herramientas como
Ansible.
Foreman estructura su contenido en base a organizaciones y localizaciones, controlando los accesos a la
configuración mediante roles. Además, es compatible con distintos tipos de autenticación, tales como Microsoft
Active Directory, LDAP o FreeIPA.
Otra caracerística positiva de Foreman es que incluye una RESTful API muy bien documentada, en base a la
cual se han desarrollado los multiples plugins que soporta. La herramienta de línea de comandos hammer utiliza
esta API para interactuar con Foreman.
A través de un Dashboard obtenemos gran cantidad de información de nuestra infraestructura:
Visión de la configuración de los hosts
Últimas actividades
Visión de tareas y errores
Útimos parches importados
También disponemos de una completa funcionalidad de auditoria, donde podemos ver los últimos cambios
ejecutados en nuestros sistemas.
5.1.2 Katello
Katello es una herramienta que amplía las funciones de Foreman añadiendo la gestión del contenido,
combinando los proyectos de software Pulp y Candlepin.
La función principal de Pulp es la sincronización de paquetes RPM, Docker y módulos de Puppet a través de
respositorios (también repositorios con contenido OSTree para despligues).
Además, con Pulp es posible importar información de erratas, que no son más que actualizaciones de paquetes
con la siguiente información adicional:
Tipo (corrección de error, corrección de seguridad, o mejora de alguna característica)
Resumen y descripción detallada de la actualización
Información CVE (Common Vulnerabilities and Exposures)
53
Actualmente sólo soporta disribuciones basadas en RPM, aunque hay un proyecto en desarrollo (pulp_deb en
github) para dar soporte a distribuciones basadas en Debian (paquetes DEB), pero aún no está en un estado
estable para su utilización.
Candlepin añade funcionalidades de gestión de suscripciones y permisos en canales. De este modo, mediante
la suscripción de sistemas podemos accede a fuentes de software importadas por Pulp.
Una característica de Katello es que puede hacer snaphots del contenido de sus repositorios en un momento
determinado, de modo que tenemos un número de posibilidades ilimitadas para las pruebas y evaluación de, por
ejemplo, módulos de Puppet en distintas etapas del ciclo de vida de los servidores (entornos): desarrollo, purebas,
producción…
De esta forma antes de instalar las últimas actualizaciones, podremos testearlas y validarlas en equipos de prueba
y desarrollo. Esta es una buena práctica para tener nuestro software en versiones validadas minimizando los
errores.
5.2 Gestión de la configuración con Puppet y Ansible
Las herramientas Puppet y Ansible nos proporcionan diferentes formas de gestionar la configuración de nuestra
infraestructura de una forma eficiente, minimizando el número de administradores y desarrolladores
involucrados en la gestión de los sistemas.
Estas cuatro herramientas de gestión de la configuración han sido diseñadas para reducir la complejidad a la
hora de configurar distintos recursos de nuestra infraestructura.
5.2.1 Puppet
Puppet es una herramienta de automatización de la configuración para infraestrucutras y aplicaciones
distribuídas.
Originalmente fué desarrollada para automatizar tareas que ocupaban mucho tiempo a los administradores de
sistemas, facilitando operaciones de configuración, aprovisionamiento, resolución de problemas y
mantenimiento de servidores.
Es una herramiena de código abierto que está desarrollada en Ruby, y utiliza DSL (Domain Specific Language)
y ERB (Embebed Ruby) para la creación de plantillas de configuración. Podemos decir que utiliza un leguaje
declarativo a la hora de programar y confeccionar los ficheros necesarios para la creación de módulos.
Puppet utiliza una arquitectura agente/master, en la que los agentes se ejecutan en los nodos donde se aplica la
configuración, y solicitan la información de master que controla con configuración a desplegar.
Las ventajas de Puppet son las siguientes:
Alto nivel de automatización y herramientas de generación de informes.
Una comunidad muy activa que ofrece soporte y un extenso repositorio de módulos.
Es muy robusto.
La configuración inicial tiene una curva de aprendizaje suave y soporta una gran variedad de sistemas
operativos.
Resulta muy útil en grandes organizaciones, es estable y podemos decir que es una solución con un
estado de madurez elevado por el tiempo que lleva en desarrollo.
Como aspectos negativos, podemos mencionar los siguientes:
Puede resultar difícil para nuevos usuarios que tengan que aprender Puppet DSL o Ruby. Tareas
avanzadas deben hacerse mediante línea de comandos.
No tiene una buena escalabilidad. El código DSL puede resultar compliacdo al crecer demasiado.
El uso de multiples masters puede complicar la gestión. La ejecución remota puede llegar a ser un
54
desafío.
Al estar basado en ejecución periódica del agente, que debe recibir la información del master, los
cambios no se ejecutan de manera inmediata en los nodos.
5.2.2 Ansible
Ansible ha sido desarrollado para simplificar las tareas de gestión de la configuración. Es una plataforma escrita
en Python y permite a los usuarios utilizar scripts en formato YAML.
La comunicación con los nodos se realiza vía ssh y los comandos se ejecutan de forma secuencial.
Ansible no requiere agentes en cada sistema, y los módulos pueden residir en cualquier servidor. Normalmente
se utiliza una estación de trabajo centralizada para ejecutar los comandos a través de servidores intermedios para
llegar a las máquinas finales.
Como características principales podemos destacar una provision de configuración moderna y optimizada, y la
posibilidad de desplegar aplicaciones. Además, integra políticas de seguridad en los procesos que se ejcutan de
forma automática.
Enumeramos sus principales ventajas:
Fácil ejecución remota.
Encaja perfectamente en entornos que tienen alta escalabilidad.
Tiene un motor de orquestación muy poderoso, proporcionando actualizaciones sin tiempo de caída.
Fácil instalación y configuración inicial.
Sintaxis y workflow fáciles para nuevos usuarios.
Orden de ejecución secuencial.
La ausencia de master elimina potenciales puntos de fallo y rendimiento. El despliegue sin agente
proporciona una mayor velocidad que en los modelos basados en master y agente.
Seguridad proporcionada por el protocolo SSH.
Como puntos débiles podemos establecer los siguientes:
Demasiado foco en la orquestación, en detrimento de la gestión de configuración.
En determinados entornos altamente escalables la comunicación SSH puede resultar lenta.
Requiere acceso SSH con privilegios y Python instalado en los equipos (aunque no necesita un agente
instalado).
Ansible es nuevo en comparación con Puppet, el cual podemos considerar un producto más maduro.
5.3 Gestión de la Seguridad con OWASP Zap, OpenVAS y Metasploit Framework Community
5.3.1 OWASP Zap
OWASP Zap (Zed Attack Proxy) es una herramienta de tests de penetración Open Source mantenida por Open
Web Application Security Project (OWASP), que ejecuta escaneos para comprobar vulnerabilidades en
aplicaciones web. Podemos decir que se situa entre la navegador y la aplicación web interceptando e
inspeccionando mensajes enviados por el navegador, modificándolos si es necesario, y redirigiéndolos al
destino.
Con Zap, podemos realizar tres tipos de escaneos automáticos:
Escaneo pasivo: escaneo de la aplicación web observando las respuestas sin alterarlas.
55
Escaneo activo: además del escaneo, se realizan ataques a la aplicación web.
Fuzzing: técnica de escaneo que nos permite modificar el tráfico y ver la respuesta de la aplicación web
ante datos de entrada manipulados.
Los distintos tipos de escaneo realizados por la herramienta nos permiten detectar vulnerabilidades, pero en
ningún caso se realizarán ataques directos en en servidor.
Dispone de una interfaz web desde la que podemos controlar todos los parámetros de configuración, realizar las
pruebas de escaneo y visualizar los resultados.
5.3.2 OpenVAS
OpenVAS es otra alternativa para realizar auditorías de seguridad en redes y encontrar vulnerabilidades de forma
automática.
Se trata de una herramienta modular, siendo el modulo principal el motor de escaneo, basado en NVTs (Network
Vulnerability Tests). Dispone también de un servicio manager que es el encargado de interactuar con el resto de
módulos (CLI, Framework, Scanner…), además de un servicio cliente que proporciona una interfaz web
(Greenbone Security Assistant) desde la que podemos configurar la herramienta, presentar resultados o generar
informes.
A continuación podemos ver los componentes principales de OpenVAS:
Figure 5-1. Componentes de OpenVAS
5.3.3 Metasploit Framework Community
Metasplot Framework Community es una herramienta Open Source que permite ejecutar y desarrollar exploits
56
contra sistemas objetivos de forma automatizada. Entre los objetivos podemos encontrar sistemas operativos,
aplicaciones y redes.
Con Metasploit podemos explotar las vulerabilidades de nuestros sistemas y tener una medida del grado de
seguridad implementado en nuestra infraestructura.
Esta herramienta utiliza un intérprete de comandos bastante robusto llamado msfconsole. Algunos conceptos
utilizados por Metasploit son:
Auxiliary: programa que permite obtener información del objetivo para determinar las vulnerabilidades
que le pueden afectar. Este tipo de programas son útiles para definir las medidas defensivas de nuestros
sistemas o determinar los exploits que pueden comprometer el objetivo.
Exploit: programa que explota una o varias vulnerabilidades en un software determinado. Normalmente
utilizado para accede a un Sistema y tener control sobre él.
Payload: es un programa que acompaña a un exploit para realizar determinadas funciones en el sistema
objetivo, una vez que ha sido comprometido.
57
6 ELECCIÓN DE LA TECNOLOGÍA
na vez analizadas las bondades de la herramienta Satellite y las distintas herramientas de software libre,
debemos elegir la tecnología adecuada para implantar en nuestra infraestructura.
En la elección intervienen muchos factores, y la inclinación hacia una tecnología en determinados casos,
no implica que la otra no sea la adecuada en diferentes situaciones. La clave es decidir si queremos utilizar un
producto all in one certificado como Satellite asumiendo el coste que conlleva, o usar tecnologías con soporte
comunidad sin pagar un precio, a priori.
Un aspecto que puede decantar la balanza a favor de utilizar una herramienta privativa como Satellite es el
soporte del fabricante. Ante cualquier problema o fallo de alguna de las herramientas que se utilizan, tenemos
una empresa detrás que soluciona de forma rápida y eficiente los errores proporcionando actualizaciones del
producto.
Lo que el fabricante hace es utilizar las herramientas open source foreman, katello, pulp, candlepin, puppet,
ansible y desarrollar un producto todo en uno que abarca de forma completa la gestión del ciclo de vida de los
sistemas. De este modo, tendremos una única herramienta centralizada desde la que podemos realizar todas
las tareas.
Evidentemente el soporte del fabricante tiene un coste, por lo que debemos analizar y evaluar la conveniencia
de adquirir una suscripción.
En entornos empresariales de determinada envergadura, es preferible asumir ese coste, a cambio de un equipo
de soporte que responde ante cualquier eventualidad.
La utiliación de herramientas open source por separado, aumenta la complejidad de despliegue y no se asegura
el correcto funcionamiento de forma orquestada de todas ellas. Mientras Satellite utiliza versiones de las
herramientas certificadas para funcionar de forma integrada, esto no ocurre cuando utilizamos herramientas
open source por separado.
Si una aplicación presenta un problema o fallo, debemos esperar a que la comunidad lo resuelva mediante alguna
actualiación, sin saber los tiempos de respuesta que sí que se pueden acordar o están establecidos con el
fabricante.
Sí que resulta interesante mencionar que las herramientas open source tienen un ciclo de actualizaciones e
incorporan nuevas funcionalidades más rápido que Satellite, a cambio de una mayor inestabilidad y de tener un
software con un mayor numero de problemas. Esto no es admisible en determinadas organizaciones donde la
U
58
seguridad es un aspecto primordial, y debe estar suficientemente cubierta.
Por todo lo expuesto anteriormente, elegimos Satellite como la solución más conveniente en grandes
infraestructuras, entornos empresariales u organismos públicos para la gestión completa del ciclo de vida de los
sistemas.
En el siguiente apartado se describen los pasos y configuraciones necesarias para la implantación de la
herramienta Satellite.
59
7 IMPLANTACIÓN DE RED HAT SATELLITE
continuación se van a detallan los pasos seguidos en la implantación de la herramienta de gestión de
servidores Red Hat Satellite, con la que se podrán realizar todas las tareas de mantenimiento,
configuración y despliegues en cualquier servidor registrado en la herramienta.
A raíz de las características ya comentadas de Satellite, podemos decir que es la herramienta ideal para entornos
con un número elevado de servidores linux Red Hat o derivados que utilicen repositorios de software
empaquetado en formato rpm, como CentOS, Scientific Linux…
7.1 Preparación del servidor y configuración previa
7.1.1 Creación de una máquina virtual para Satellite
Se utilizará una máquina virtual VMware para instalar el servidor Satellite.
Los recursos hardware asignados a la máquina virtual son los siguientes:
CPU: 8 cores
RAM: 16 GB
Disco SO: 100 GB
Disco DATOS: 600 GB
Driver de red: vmxnet3
7.1.2 Instalación del Sistema Operativo
El Sistema Operativo utilizado para la instalación es Red Hat Enterprise Linux Server versión 7.4.
A continuación detallamos los parámetros de instalación:
Idioma: Inglés (Estados Unidos)
Teclado: es
A
60
Zona horaria: Madrid (GMT+1)
Particionado Disco SO:
o LVM rhel-root: / 68 GB
o LVM rhel-home: /home 5 GB
o LVM rhel-var: /var/log 10.3 GB
o xfs: /boot 1 GB
o swap: 16 GB
Selección de paquetes: Minimal Installation
Kdump: Disabled
Parámetros de red:
o Dispositivo: ens192
o Nombre del servidor: satellite.prpm.org
o Dirección de red: 192.168.0.38
o Máscara de subred: 255.255.255.0
o Gateway: 192.168.0.3
o DNS: 192.168.0.32, 192.168.0.14, 192.168.0.34
o Search: prpm.org
7.1.3 Configuración previa del servidor
7.1.3.1 Particionado
A continuación se muestra el particionado del disco principal con el sistema recién instalado:
[root@satellite ~]# df -h
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/mapper/rhel-root 68G 942M 68G 2% /
devtmpfs 7,9G 0 7,9G 0% /dev
tmpfs 7,9G 0 7,9G 0% /dev/shm
tmpfs 7,9G 8,5M 7,9G 1% /run
tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
/dev/mapper/rhel-var_log 11G 36M 11G 1% /var/log
/dev/mapper/rhel-home 5,0G 33M 5,0G 1% /home
/dev/sda1 1014M 125M 890M 13% /boot
tmpfs 1,6G 0 1,6G 0% /run/user/0
Creamos un volumen físico asociado al segundo disco:
[root@satellite ~]# pvcreate -f /dev/sdb
Physical volume "/dev/sdb" successfully created.
Creamos el volume group vg_sat asociado al segundo disco:
[root@satellite ~]# vgcreate vg_sat /dev/sdb
Volume group "sat_vg" successfully created
Creamos los siguientes volúmenes lógicos:
61
[root@satellite ~]# lvcreate -L 20GB -n lv_cachepulp vg_sat
Logical volume "lv_cachepulp" created.
[root@satellite ~]# lvcreate -L 100GB -n lv_mongodb vg_sat
Logical volume "lv_mongodb" created.
[root@satellite ~]# lvcreate -L 10GB -n lv_psql vg_sat
Logical volume "lv_psql" created.
[root@satellite ~]# lvcreate -L 10GB -n lv_foreman vg_sat
Logical volume "lv_foreman" created.
[root@satellite ~]# lvcreate -L 10GB -n lv_candlepin vg_sat
Logical volume "lv_candlepin" created.
[root@satellite ~]# lvcreate -L 10GB -n lv_puppet vg_sat
Logical volume "lv_puppet" created.
[root@satellite ~]# lvcreate -L 10GB -n lv_puppetenv vg_sat
Logical volume "lv_puppetenv" created.
[root@satellite ~]# lvcreate -l 100%FREE -n lv_pulp vg_sat
Logical volume "lv_pulp" created.
Creamos los puntos de montaje para los volúmenes lógicos:
[root@satellite ~]# mkdir -p /var/cache/pulp
[root@satellite ~]# mkdir -p /var/lib/mongodb
[root@satellite ~]# mkdir -p /var/lib/pgsql
[root@satellite ~]# mkdir -p /var/lib/foreman
[root@satellite ~]# mkdir -p /var/lib/candlepin
[root@satellite ~]# mkdir -p /var/lib/puppet
[root@satellite ~]# mkdir -p /etc/puppet/environments
[root@satellite ~]# mkdir -p /var/lib/pulp
Formateamos los volúmenes lógicos en xfs:
[root@satellite ~]# for i in $(lvs | grep vg_sat | awk '{print $1}');
do mkfs.xfs /dev/vg_sat/$i; done
Montamos los volúmenes lógicos en el sistema:
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_cachepulp
/var/cache/pulp/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_mongodb
/var/lib/mongodb/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_psql /var/lib/pgsql/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_foreman
/var/lib/foreman/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_candlepin
/var/lib/candlepin/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_puppet
/var/lib/puppet/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_puppetenv
/etc/puppet/environments/
[root@satellite ~]# mount /dev/mapper/vg_sat-lv_pulp /var/lib/pulp/
Comprobamos que se han montado correctamente:
[root@satellite ~]# df -h
S.ficheros Tamaño Usados Disp Uso% Montado en
/dev/mapper/rhel-root 68G 942M 68G 2% /
62
devtmpfs 7,9G 0 7,9G 0% /dev
tmpfs 7,9G 0 7,9G 0% /dev/shm
tmpfs 7,9G 8,6M 7,9G 1% /run
tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
/dev/mapper/rhel-var_log 11G 36M 11G 1% /var/log
/dev/mapper/rhel-home 5,0G 33M 5,0G 1% /home
/dev/sda1 1014M 125M 890M 13% /boot
tmpfs 1,6G 0 1,6G 0% /run/user/0
/dev/mapper/vg_sat-lv_cachepulp 20G 33M 20G 1% /var/cache/pulp
/dev/mapper/vg_sat-lv_mongodb 100G 33M 100G 1% /var/lib/mongodb
/dev/mapper/vg_sat-lv_psql 10G 33M 10G 1% /var/lib/pgsql
/dev/mapper/vg_sat-lv_foreman 10G 33M 10G 1% /var/lib/foreman
/dev/mapper/vg_sat-lv_candlepin 10G 33M 10G 1% /var/lib/candlepin
/dev/mapper/vg_sat-lv_puppet 10G 33M 10G 1% /var/lib/puppet
/dev/mapper/vg_sat-lv_puppetenv 10G 33M 10G 1%
/etc/puppet/environments
/dev/mapper/vg_sat-lv_pulp 430G 33M 430G 1% /var/lib/pulp
Creamos las entradas correspondientes al montaje de los volúmenes lógicos en /etc/fstab:
Fichero /etc/fstab:
/dev/mapper/rhel-root / xfs defaults 0 0
UUID=758df6d6-df58-42cd-8c76-4c7d8ed11ace /boot xfs defaults 0 0
/dev/mapper/rhel-home /home xfs defaults 0 0
/dev/mapper/rhel-var_log /var/log xfs defaults 0 0
/dev/mapper/rhel-swap swap swap defaults 0 0
/dev/mapper/vg_sat-lv_cachepulp /var/cache/pulp xfs defaults 0 0
/dev/mapper/vg_sat-lv_mongodb /var/lib/mongodb xfs defaults 0 0
/dev/mapper/vg_sat-lv_psql /var/lib/pgsql xfs defaults 0 0
/dev/mapper/vg_sat-lv_foreman /var/lib/foreman xfs defaults 0 0
/dev/mapper/vg_sat-lv_candlepin /var/lib/candlepin xfs defaults 0 0
/dev/mapper/vg_sat-lv_puppet /var/lib/puppet xfs defaults 0 0
/dev/mapper/vg_sat-lv_puppetenv /etc/puppet/environments xfs defaults
0 0
/dev/mapper/vg_sat-lv_pulp /var/lib/pulp xfs defaults 0 0
7.1.3.2 Configuración del firewall
Abrimos los puertos del firewall del sistema necesarios para que los clientes se comuniquen con el servidor
Satellite:
[root@satellite ~]# # firewall-cmd --permanent --add-port="53/udp" --
addport=" 53/tcp" --add-port="67/udp" --add-port="69/udp" --add-
port="80/tcp" --addport=" 443/tcp" --add-port="5647/tcp" --add-
port="8000/tcp" --add-port="8140/tcp" --add-port="9090/tcp"
success
[root@satellite ~]# firewall-cmd --reload
success
[root@satellite ~]# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: ens192
sources:
services: ssh dhcpv6-client
63
ports: 53/udp 53/tcp 67/udp 69/udp 80/tcp 443/tcp 5647/tcp 8000/tcp
8140/tcp 9090/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
7.1.3.3 Verificación de resolución DNS
Nos aseguramos de que localhost y el hostname resuelven correctamente:
[root@satellite ~]# ping -c1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.081 ms
--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.081/0.081/0.081/0.000 ms
[root@satellite ~]# ping -c1 `hostname -f`
PING satellite.prpm.org (192.168.0.38) 56(84) bytes of data.
64 bytes from satellite.prpm.org (192.168.0.38): icmp_seq=1 ttl=64
time=0.059 ms
--- satellite.prpm.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.059/0.059/0.059/0.000 ms
7.1.3.4 Sincronización de hora
A continuación instalamos y configuramos el servicio de sincronización de hora:
[root@satellite ~]# yum install chrony
[root@satellite ~]# systemctl enable chronyd
[root@satellite ~]# vim /etc/chrony.conf
server fdc01.prpm.org iburst
server fdc03.prpm.org iburst
[root@satellite ~]# systemctl start chronyd
7.2 Instalación y configuración inicial de Satellite
7.2.1 Registro del servidor e instalación de paquetes
7.2.1.1 Registro del servidor con Subscription Manager
Registramos el servidor Satellite:
[root@satellite ~]# subscription-manager register
Asociamos el pool de la suscripción de Satellite al servidor:
[root@satellite ~]# subscription-manager attach --pool=POOL_ID
Deshabilitamos todos los repositorios del sistema:
[root@satellite ~]# subscription-manager repos --disable "*"
64
Habilitamos los siguientes repositorios:
Red Hat Satellite
Red Hat Enterprise Linux
Red Hat Software Collections
[root@satellite ~]# subscription-manager repos --enable=rhel-7-server-
rpms --enable=rhel-server-rhscl-7-rpms --enable=rhel-7-server-
satellite-6.2-rpms
El repositorio 'rhel-7-server-rpms' está habilitado para este sistema.
El repositorio 'rhel-7-server-satellite-6.2-rpms' está habilitado para
este sistema.
El repositorio 'rhel-server-rhscl-7-rpms' está habilitado para este
sistema.
7.2.1.2 Instalación de paquetes de Satellite
En primer lugar actualizamos el sistema:
[root@satellite ~]# yum update
Instalamos el paquete necesario para lanzar el instalador de Satellite y todas sus dependencias:
[root@satellite ~]# yum install satellite
7.2.2 Instalación de Satellite
Procedemos a instalar Satellite:
[root@satellite ~]# satellite-installer --scenario satellite --
foreman-initialorganization "PRPM" --foreman-initial-location
"CENTRAL" --foreman-adminusername admin --foreman-admin-password
xxxxxxxx --foreman-proxy-dnsmanaged= false --foreman-proxy-dhcp-
managed=false
Installing Done [100%]
[....................................................................
.................]
Success!
* Satellite is running at https://satellite.prpm.org
Initial credentials are admin / xxxxxxxx
* To install additional capsule on separate machine continue by
running:
capsule-certs-generate --capsule-fqdn "$CAPSULE" --certs-tar
"~/$CAPSULE-certs.tar"
The full log is at /var/log/foreman-installer/satellite.log
Donde hemos especificado los siguientes parámetros:
Organización: PRPM
Localización: CENTRAL
Usuario administrador: admin
Password del usuario administrador: xxxxxxxx
65
También indicamos que los ficheros de DNS y DHCP configurados por el instalador queden fuera de la gestión
de Puppet. De esta forma, si ejecutamos el instalador con posterioridad, algo que puede hacerse para añadir o
eliminar características de Satellite, cualquier cambio manual en estos ficheros no será reescrito por el instalador.
Podemos acceder a la interfaz web de Satellite en la URL:
https://satellite.prpm.org
7.2.3 Creación e instalación del Manifiesto
Desde el Portal de Cliente, creamos un nuevo manifiesto con las siguientes suscripciones asociadas:
Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes): 41
Red Hat Enterprise Linux for Virtual Datacenters, Standard: 13
Smart Management: 44
Smart Management for Unlimited Guests: 13
En la interfaz web, Content → Red Hat Subscriptions → Manage Manifest → Upload, seleccionamos el
manifiesto descargado del Portal de Cliente y lo subimos a Satellite.
Figura 7-1. Carga de Manifiesto de Suscripciones en Satellite
7.2.4 Envío de notificaciones por correo
Configuramos Satellite para que envíe correos de notificaciones a través del servidor de correo del Patronato.
Para ello, modificamos el fichero /etc/foreman/email.yaml:
production:
delivery_method: :smtp
smtp_settings:
enable_starttls_auto: true
address: correoserver.prpmalaga.es
port: 25
domain: prpm.org
66
authentication: none
Reiniciamos los servicios de Satellite para activar los cambios:
# katello-services restart
7.3 Implementación del Core Build
7.3.1 Activación y Sincronización de Respositorios
Una vez subido el manifiesto, podemos seleccionar los repositorios disponibles a través de las suscripciones que
gestiona Satellite.
En la interfaz Web, accedemos a Content → Red Hat Repositories, y habilitamos los siguientes repositorios:
Red Hat Enterprise Linux Server
5.11
o Red Hat Enterprise Linux 5 Server Kickstart i386 5.11
o Red Hat Enterprise Linux 5 Server RPMs i386 5.11
o Red Hat Enterprise Linux 5 Server Kickstart x86_64 5.11
o Red Hat Enterprise Linux 5 Server RPMs x86_64 5.11
6.6
o Red Hat Enterprise Linux 6 Server - Optional RPMs x86_64 6.6
o Red Hat Enterprise Linux 6 Server - Supplementary RPMs x86_64 6.6
o Red Hat Enterprise Linux 7 Server Kickstart x86_64 6.6
o Red Hat Enterprise Linux 6 Server RPMs x86_64 6.6
7.2
o Red Hat Enterprise Linux 7 Server - Optional RPMs x86_64 7.2
o Red Hat Enterprise Linux 7 Server - Supplementary RPMs x86_64 7.2
o Red Hat Enterprise Linux 7 Server Kickstart x86_64 7.2
o Red Hat Enterprise Linux 7 Server RPMs x86_64 7.2
Red Hat Enterprise Linux 7 Server - Extras RPMs x86_64
Red Hat Enterprise Linux 6 Server - Extras RPMs x86_64
Red Hat Satellite Tools 6.2 for RHEL 7 Server RPMs x86_64
Red Hat Satellite Tools 6.2 for RHEL 6 Server RPMs x86_64
Red Hat Satellite Tools 6.2 for RHEL 5 Server RPMs x86_64
Red Hat Satellite Tools 6.2 for RHEL 5 Server RPMs i386
67
Figura 7-2. Activación de Repositorios
A continuación creamos un plan de sincronización que lanzará una tarea para mantener los repositositorios
gestionados por Satellite actualizados en todo momento.
Para ello, accedemos a Content → Sync Plans → New Sync Plan:
Name: PRPM
Description: Sincronización periódica de los repositorios
Start Date: 2017/11/28 05:00:00 CET
Next Sync: 2017/11/29 05:00:00 CET
Sync Enabled: Yes
Interval: daily
68
Figura 7-3. Detalle del plan de sincronización
La programación de la sincronización de los repositorios se realiza a nivel de Productos, por lo que todos los
repositorios pertenecientes a los Productos asociados al plan, se actualizarán según los parámetros definidos:
Producto asociado al Plan de sincronización:
Red Hat Enterprise Linux Server
Figura 7-4. Productos asociados al plan de sincronización
7.3.2 Creación de Content Views
Se crean inicialmente los siguientes Content Views para las versiones de Red Hat 5.11, 6.6 y 7.2 desde la interfaz
web (Content→ Content Views)
A cada content view se le asocian los repositorios respectivos (Yum Content → Repositories → Add).
69
Figura 7-5. Visualización de repositorios asociados a un Content View
cv-os-rhel-5.11
o Red Hat Satellite Tools 6.2 for RHEL 5 Server RPMs x86_64
o Red Hat Satellite Tools 6.2 for RHEL 5 Server RPMs i386
o Red Hat Enterprise Linux 5 Server RPMs x86_64 5.11
o Red Hat Enterprise Linux 5 Server RPMs i386 5.11
cv-os-rhel-6.6
o Red Hat Satellite Tools 6.2 for RHEL 6 Server RPMs x86_64
o Red Hat Enterprise Linux 6 Server - Supplementary RPMs x86_64 6.6
o Red Hat Enterprise Linux 6 Server RPMs x86_64 6.6
o Red Hat Enterprise Linux 6 Server - Optional RPMs x86_64 6.6
o Red Hat Enterprise Linux 6 Server - Extras RPMs x86_64
cv-os-rhel-7.2
o Red Hat Satellite Tools 6.2 for RHEL 7 Server RPMs x86_64
o Red Hat Enterprise Linux 7 Server - Supplementary RPMs x86_64 7.2
o Red Hat Enterprise Linux 7 Server RPMs x86_64 7.2
o Red Hat Enterprise Linux 7 Server - Optional RPMs x86_64 7.2
o Red Hat Enterprise Linux 7 Server - Extras RPMs x86_64
Una vez creados los Content Views y asociados los repositorios a cada uno de ellos, publicamos la primera
versión de los Content Views (Publish New Version):
70
Figura 7-6. Versionado de Conent Views
Al publicar la primera versión, el entorno de Ciclo de Vida asociado al Content View es Library. Si queremos
promocionar un Content View a un nuevo entorno, debemos darle al botón Promote, y seleccionar el entorno
donde queremos tener disponible el Content View:
Figura 7-7. Promoción de un Content View a un Entorno
Cada vez que se realice alguna modificación en un Content View (añadir o eliminar repositorios…) debemos
publicar una nueva versión del mismo (Publish New Version), para que los servidores reciban la nueva
configuración.
71
7.3.3 Creación de Lifecycle Environments
Se crea inicialmente una ruta con los siguientes Entornos en el Ciclo de Vida de los servidores (Content →
Lifecycle Environments):
Library (entorno creado por defecto y común a todas las rutas)
TEST
PRE
PRO
Figura 7-8. Ruta de Entonos de Ciclo de Vida
7.3.4 Creación de Activation Keys
Las Activation Keys se utilizan para registrar inicialmente los servidores a Satellite. En ellas se define la versión
de RHEL, el entorno al que se añadirá el servidor, las suscripciones disponibles para los servidores, los
repositorios…
Se crean inicialmente las siguientes Activation Keys (Content → Activation Keys):
act-lib-os-rhel-5.11-i386
act-lib-os-rhel-5.11-x86_64
act-lib-os-rhel-6.6-x86_64
act-lib-os-rhel-7.2-x86_64
En la pestaña Detalis definimos Release Version y Environment:
72
Figura 7-9. Parámetros de una Activation Key
En la pestaña Subscriptions, añadimos las suscripciones necesarias para los servidores:
Figura 7-10. Suscripciones asociadas a una Activation Key
En la pestaña Product Content podemos seleccionar los repositorios que queramos tener activados en los
servidores a la hora de registrarlos:
73
Figura 7-11. Repositorios asociados a una Activation Key
7.3.5 Creación de Host Groups
Los Hosts Groups se utilizan para categorizar los servidores registrados en Satellite, definiendo una serie de
opciones y características comunes a los equipos configurados en el mismo Host Group.
Figura 7-12. Formas de organizar los host groups
Se ha optado por una organización jerárquica de Host Groups, donde cada nivel tendrá definidos los parámetros
que se van a detallar a continuación.
74
7.3.5.1 Nivel 1 (Entornos de Ciclo de Vida)
En el nivel 1 configuraremos los siguientes parámetros:
Nombre
o lib (usado para registro de servidores)
o test
o pre
o pro
Puppet CA: satellite.prpm.org
Puppet Master: satellite.prpm.org
7.3.5.2 Nivel 2 (Versión de Sistema Operativo)
En el nivel 2 configuraremos Nombre, Entorno Puppet y Sistema Operativo.
Nombre
o rhel-5-i386
o rhel-5-x86_64
o rhel-6-x86_64
o rhel-7-x86_64
Puppet Environment
o Production
Arquitectura
o i386
o x86_64
Sistema Operativo
Medio
Tabla de particiones
A continuación, se muestra una captura de los Hosts Groups creados:
Figura 7-13. Host Groups jerárquicos
75
7.4 Registro de Servidores en Satellite
Para registrar servidores se utiliza un script de python que proporciona el propio Satellite (bootstrap.py).
Este script recibe los siguientes parámetros:
-l: usuario de login en Satellite (debe ser administador)
-s: servidor Satellite (rhsatellite.chap.junta-andalucia.es)
-o: organización (PRPM)
-L: localización (CENTRAL)
-g: hostgroup (debe tener un sistema operativo y un entorno de puppet confgurado en Satellite)
-a: activation-key (debe tener añadidas las suscripciones necesarias)
--force: fuerza el registro (borra katello y certificado de puppet antes de instalar los nuevos)
7.4.1 Registro de un servidor RHEL 7.2 x86_64
Realizamos unos primeros pasos para verificar la versión de RHEL y la resolución DNS:
[root@pruebasrhel7 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
[root@pruebasrhel7 ~]# ping -c1 `hostname -f`
PING pruebasrhel7.prpm.org (192.168.0.142) 56(84) bytes of data.
64 bytes from pruebasrhel7.prpm.org (192.168.0.142): icmp_seq=1 ttl=64
time=0.059 ms
--- pruebasrhel7.prpm.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.059/0.059/0.059/0.000 ms
[root@pruebasrhel7 ~]# nslookup 192.168.0.142
Server: 192.168.0.32
Address: 192.168.0.32#53
142.0.168.192.in-addr.arpa name = pruebasrhel7.prpm.org.
[root@pruebasrhel7 ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search prpm.org
nameserver 192.168.0.32
nameserver 192.168.0.14
nameserver 192.168.0.34
Descargamos el script de registro de la url de Satellite:
[root@pruebasrhel7 ~]# wget http://satellite.prpm.org/pub/bootstrap.py
--2017-11-30 12:31:17-- http://satellite.prpm.org/pub/bootstrap.py
Resolviendo satellite.prpm.org (satellite.prpm.org)... 192.168.0.38
Conectando con satellite.prpm.org
(satellite.prpm.org)[192.168.0.38]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 41377 (40K)
Grabando a: “bootstrap.py”
76
100%[================================================================
===============================================================>]
41.377 --.-K/s en 0s
2017-11-30 12:31:17 (132 MB/s) - “bootstrap.py” guardado [41377/41377]
Damos permisos de ejecución al script:
[root@pruebasrhel7 ~]# chmod +x bootstrap.py
Ejecutamos el script de registro:
[root@pruebasrhel7 ~]# ./bootstrap.py -l admin -s satellite.prpm.org -
o PRPM -L CENTRAL -g lib/rhel7-x86_64 -a act-lib-os-rhel-7.2-x86_64 --
force
Foreman Bootstrap Script
This script is designed to register new systems or to migrate an
existing system to a Foreman server with Katello
admin's password:
…
[RUNNING], [2017-11-30 12:35:58], [/usr/bin/puppet agent --test --noop
--tags no_such_tag --waitforcert 10]
El script realizará el registro del servidor con Satellite e instalará el agente de puppet en el servidor. Una vez
instalado el agente lo ejecutará por primera vez con el parámetro --waitforcert 10, por lo que esperará haciendo
sondeos cada 10 segundos hasta que firmemos el certificado en la interfaz web de Satellite.
Par ello nos dirigimos a Infraestructure → Capsules, y en la cápsula satellite.prpm.org hacemos clic en Actions
→ Certificates.
Figura 7-14. Menú de acceso a Certificados de servidores
Filtramos los certificados pendientes (Pending) y le damos a Sign.
77
Figura 7-15. Firma del Certificado de un servidor
Una vez firmado el certificado, el script ejecutará los pasos finales. Podemos ver el servidor correctamente
registrado en la sección (Hosts → Content Hosts):
Figura 7-16. Detalle de parámetros de un host registrado en Satellite
7.5 Gestión de la configuración con Puppet
7.5.1 Creación de entornos de Puppet
Se han creado dos entornos de puppet, uno para pruebas y testeo de módulos, y otro para producción:
Testing: en este entorno se crearán nuevos módulos y se realizarán pruebas de funcionamiento.
78
Production: a este entorno se asociarán los módulos validados que sean aptos para aplicar en servidores.
Figura 7-17. Entornos de Puppet en Satellite
7.5.2 Carga de módulos de Puppet en Satellite
Podemos crear nosotros mismos los módulos de puppet, o utilizar módulos de puppet ya creados compatibles
con nuestra versión de puppet instalada en el servidor Satellite. La versión de puppet instalada en Satellite es la
3.8.6-2.el7sat.
En la web puppetforge disponibles numerosos módulos de puppet ya creados disponibles para su descarga y
ser utilizados en nuestro entorno.
Hemos de tener precaución de utilizar las versiones de los módulos que son compatibles con nuestra versión de
puppet. Cada módulo incluye esta información de compatibilidad en su página web (pestaña Compatibility).
Se han configurado dos módulos de puppet:
Configuración del fichero motd (message of the day)
Nombre del módulo: motd
URL: https://forge.puppet.com/puppetlabs/motd/1.4.0
Versión: 1.4.0
Descripción: el módulo configura el fichero /etc/motd con un mensaje de texto que visualizaremos al
hacer login en el servidor por consola.
Clases de puppet: motd
Configuración del fichero resolv.conf (servidores DNS)
Nombre del módulo: resolv_conf
URL: https://forge.puppet.com/saz/resolv_conf/3.3.0
Versión: 3.3.0
Descripción: este módulo controla el fichero /etc/resolv.conf, donde se configuran los servidores DNS
y dominio de búsqueda.
Clases de puppet: resolv_conf
Una vez descargados de las URLs indicadas, hemos de descomprimir los ficheros en las siguientes rutas del
servidor Satellite:
/etc/puppet/environments/testing/modules/motd
/etc/puppet/environments/testing/modules/resolv_conf
79
Para subir los módulos de puppet en Satellite debemos acceder a Configure → (Puppet) Environments, y le
damos a Import from satellite.prpm.org.
Seleccionamos la casilla testing y le damos a Update (vemos los módulos motd y resolv_conf):
Figura 7-18. Carga de nuevos módulos a un entorno de puppet
7.5.3 Configuración de clases de Puppet
Para configurar las clases de puppet de un módulo subido a Satellite, accedemos a Configure → (Puppet)
Classes:
Figura 7-19. Clases de puppet
7.5.3.1 motd
Seleccionamos la clase motd para editarla, y le damos a la pestaña Smart Class Parameter.
Seleccionamos el parámetro Content, activamos la casilla Override para que Satellite gestione el valor de la
clase y establecemos su valor en el campo Default value:
PRPM
Operating System: <%= @host.operatingsystem.name %> <%=
@host.operatingsystem.major %>.<%= @host.operatingsystem.minor %>
<%- -%>
80
Figura 7-20. Modificación del parámetro content de la clase motd
7.5.3.2 resolv.conf
Seleccionamos la clase resolv_conf para editarla, y le damos a la pestaña Smart Class Parameter.
Seleccionamos el parámetro nameservers, activamos la casilla Override para que Satellite gestione el valor de
la clase y establecemos los siguientes valores:
Key type: array
Default value: ["192.168.0.32","192.168.0.14","192.168.0.34"]
81
Figura 7-21. Modificación del parámetro nameservers de la clase resolv_conf
A continuación seleccionamos el parámetro searchpath, activamos la casilla Override para que Satellite gestione
el valor de la clase y establecemos los siguientes valores:
Key type: array
Default value: ["prpm.org"]
Figura 7-22. Modificación del parámetro searchpath de la clase resolv_conf
Finalmente, le damos al botón Submit para aplicar los cambios.
7.5.4 Aplicación de configuración a clientes
Podemos aplicar los módulos a los hosts de múltiples formas.
82
Una de ellas es asignando los módulos de puppet en el Host Group correspondiente. El Host Group debe tener
configurado el entorno donde se encuentran lo módulos que queremos aplicar.
En nuestro caso hemos optado por aplicar las configuraciones en los hosts directamente, editando el host desde
la sección Hosts → All hosts, y dándole al botón Edit.
A continuación se muestra la pantalla de edición del host pruebasrhel7.prpm.org, pestaña Puppet Classes, con
las clases de puppet motd y resolv_conf:
Figura 7-23. Aplicación de clases de puppet a un host
Para que las clases estén disponibles para seleccionar, el host debe tener configurado el entorno de puppet
correspondiente en la pestaña principal, en nuestro caso, testing.
Esta configuración de edición a nivel de host, prevalece sobre la configuración del Host Group al que pertenece
el host.
7.6 Aprovisionamiento de servidores con Satellite
7.6.1 Creación de un Dominio
En la sección Infraestructure → Domains podemos crear dominios de aprovisionamiento para los servidores. El
dominio propio del servidor Satellite se crea de forma automática: prpm.org
Configuramos la Organización y Localización en las pestañas correspondientes (PRPM y CENTRAL,
respectivamente).
Figura 7-24. Creación de un Dominio en Satellite
83
Figura 7-25. Visualización del Dominio creado en Satellite
7.6.2 Creación de una subred
También debemos crear una subred donde se aprovisionarán los nuevos servidores.
En la sección Infraestructure → Subnets se crea la subred RED0 con los siguientes parámetros:
Network: 192.168.0.0
Subnet: 255.255.255.0
Gateway: 192.168.0.3
Primary DNS: 192.168.0.32
Secondary DNS: 192.168.0.14
IPAM: Internal DB
Boot mode: Static
Además, configuramos los siguientes parámetros en el resto de pestañas:
Remote Execution: satellite.prpm.org
Domains: prpm.org
Capsulas: satellite.prpm.org (Discovery Capusle)
Localizaciones: CENTRAL
Organizaciones: PRPM
84
Figura 7-26. Creación de una subred en Satellite
Figura 7-27. Visualización de la subred creada en Satellite
7.6.3 Creación de plantillas
7.6.3.1 Plantillas de particionado
Para crear una nueva plantilla de particionado, debemos clonar la que incluye Satellite por defecto: Kickstart
default.
Para ello, accedemos a Hosts → (Provisioning Setup) Partition Tables, y seleccionamos Clone en el desplegable
de la plantilla Kickstart default.
Debemos modificar el nombre de la plantilla clonada para diferenciarla de la original, y editar el código de la
plantilla.
Se han creado plantillas con particionado personalizado para RHEL 6 y para RHEL 7:
85
Kickstart default PRPM RHEL6
<%#
kind: ptable
name: Kickstart default PRPM RHEL6
oses:
- CentOS 5
- CentOS 6
- CentOS 7
- Fedora 16
- Fedora 17
- Fedora 18
- Fedora 19
- Fedora 20
- RedHat 5
- RedHat 6
- RedHat 7
%>
zerombr
clearpart --all --initlabel
part /boot --fstype ext4 --size=500
part pv.01 --size=1000 --grow --ondisk=sda
volgroup vg_rhel pv.01
logvol swap --fstype swap --vgname=vg_rhel --name=lv_swap
logvol / --fstype=ext4 --vgname=vg_rhel --name=lv_root --size=1000 --
grow
Kickstart default PRPM RHEL7
<%#
kind: ptable
name: Kickstart default PRPM RHEL7
oses:
- CentOS 5
- CentOS 6
- CentOS 7
- Fedora 16
- Fedora 17
- Fedora 18
- Fedora 19
- Fedora 20
- RedHat 5
- RedHat 6
- RedHat 7
%>
zerombr
clearpart --all --initlabel
part /boot --fstype xfs --size=500
part pv.01 --size=1000 --grow --ondisk=sda
volgroup vg_rhel pv.01
logvol swap --fstype swap --vgname=vg_rhel --name=lv_swap
logvol / --fstype=xfs --vgname=vg_rhel --name=lv_root --size=1000 –
grow
86
Una vez creada la tabla de particiones, debemos seleccionar las Localizaciones y Organizaciones en las pestañas
correspondientes, en nuestro caso, CENTRAL y PRPM respectivamente:
Figura 7-28. Asociación de una plantilla de particionado a una Organización
7.6.3.2 Plantillas de aprovisionamiento
Para crear una nueva plantilla de aprovisionamiento, debemos clonar la que incluye Satellite por defecto:
Satellite Kickstart Default.
Para ello, accedemos a Hosts → (Provisioning) Templates, y seleccionamos Clone en el desplegable de la
plantilla Satellite Kickstart default.
Debemos modificar el nombre de la plantilla clonada para diferenciarla de la original, y editar el código de la
plantilla.
Se ha creado la plantilla Satellite Kickstart Default PRPM clonada de la plantilla Satellite Kickstart Default.
En esta plantilla se ha modificado la configuración del teclado y el idioma a español:
lang es_ES.UTF-8
keyboard es
Se pueden modificar y configurar numeroso parámetros según nuestras necesidades:
Habilitar o deshabilitar selinux
Instalar paquetes adicionales
Habilitar o deshabilitar del firewall (o servicios concretos)
Configurar la zona horaria
…
Una vez creada la plantilla de aprovisionamiento, debemos asociarle los sistemas operativos donde la queramos
tener disponible en la pestaña Association. También debemos asignarle las Localizaciones y Organizaciones
en las pestañas correspondientes (CENTRAL y PRPM respectivamente):
87
Figura 7-29. Asociación de un sistema operativo a una plantilla de aprovisionamiento
7.6.3.3 Configuración de parámetros globales para le Aprovisionamiento
La plantilla de aprovisionamiento hace uso del parámetro de host time-zone.
timezone --utc <%= @host.params['time-zone'] || 'UTC' %>
Podemos crear parámetros a nivel global accediendo a Configure → Global parameters, y haciendo clic en New
Parameter en la interfaz web. Estos parámetros estarán disponibles en cualquier servidor.
También podemos definirlos a nivel de Host Groups, editando el Host group, en la pestaña Parameters, sección
Global parameters (Add Parameter).
Hemos creado el parámetro global time-zone con el valor Europe/Madrid (Configure → Global parameters).
Figura 7-30. Parámetro Global creado en Satellite
88
7.6.4 Asignación de plantillas a Sistemas Operativos
Una vez creadas las plantillas, debemos configurarlas en los Sistemas Operativos. Para ello accedemos a Hosts
→ (Provisioning Setup) Operating systems y seleccionamos el sistema operativo.
En la pestaña Partition table, seleccionamos la tabla de particiones que queramos:
Figura 7-31. Selección de la plantilla de particiones en un sistema operativo
En la pestaña Templates, tendremos un desplegable para cada tipo de plantilla. Estas plantillas serán las
utilizadas en el aprovisionamiento de servidores. Sólo tendremos que modificar Provisioning template por
alguna de las que hemos creado.
Figura 7-32. Selección de plantilla de aprovisionamiento en un sistema operativo
7.6.5 Creación de Host Group para despliegues
Se ha creado el Host group /lib/rhel7-x86-64/provision7.2 para aprovisionar nuevos servidores RHEL.
Accedemos a Configure → Host Groups, y en el grupo rhel7-x86-64 le damos a Nest. A continuación
rellenamos los datos en cada una de las pestañas:
Host Group
89
Figura 7-33. Creación de un nuevo host group
Puppet Classes
Figura 7-34. Selección de clases de puppet en un host group
Network
90
Figura 7-35. Selección de red en un host group
Operating System
Figura 7-36. Selección de sistema operativo en un host Group
Parameters
91
Figura 7-37. Selección de parámetros en un host group
Locations
Figura 7-38. Selección de Localización en un host group
Organizations
Figura 7-39. Selección de Organización en un host group
Activation Keys
92
Figura 7-40. Selección de activation key en un host group
Finalmente, le damos a Submit.
7.6.6 Aprovisionamiento mediante Boot ISO
Este método de aprovisionamiento no requiere servicio PXE ni DHCP. Para aprovisionar un host mediante una
iso de arranque debemos crear manualmente el host, y posteriormente generar la iso con la que arrancar el
servidor.
7.6.6.1 Creación del host
Para crear un nuevo host debemos ir a la sección Hosts → New Host. En la pestaña Host seleccionamos el Host
Group lib/rhel-x86_64/provision7.2, y automáticamente se rellenan los campos definidos en el Host Group.
Especificamos el resto de parámetros en las pestañas correspondientes:
Host
93
Figura 7-41. Creación de un nuevo host para aprovisionar
Puppet Classes
Figura 7-42. Selección de clases de puppet asociadas a un host
Interfaces (edit para introducir los parámetros)
94
Figura 7-43. Detalle de los parámetros de red de un nuevo host
Figura 7-44. Interfaz de red de un nuevo host
Operating System
95
Figura 7-45. Selección de sistema operativo en un nuevo host
Parameters
Figura 7-46. Selección de parámetros de un nuevo host
96
Additional Information
Figura 7-47. Parámetros adicionales en un nuevo host
7.6.6.2 Generación de imagen de arranque
Una vez creado el host podemos ver su información en Satellite (Hosts → All Hosts). Para descargar la imagen
ISO de arranque le damos al botón Boot disk, y en el menú desplegable, Host ‘provisiontest’ image:
Figura 7-48. Generación de la imagen de aprovisionamiento de un host
97
7.6.7 Aprovisionamiento mediante PXE-less Discovery
Este método de aprovisionamiento, al igual que el de Boot iso, no requiere servicio PXE ni DHCP.
7.6.7.1 Instalación de paquetes y configuración de kexec
Los siguientes paquetes deben estar instalados en Satellite:
foreman-discovery-image: Foreman Discovery Image
rubygem-smart_proxy_discovery: Smart Proxy Discovery Plugin (ya instalado)
tfm-rubygem-foreman_discovery: Foreman Discovery Plugin (ya instalado)
El paquete foreman-discovery-image nos proporciona la imagen con la que debemos arrancar los servidores
para el autodescubrimiento:
# yum install foreman-discovery-image
La imagen se encuentra en la siguiente ruta:
/usr/share/foreman-discovery-image/foreman-discovery-image-3.1.1-
22.iso
Todos los Sistemas Operativos que vamos a utilizar con aprovisionamiento PXE-less deben tener asociada la
plantilla kexec. Para ello accedemos a Hosts → Operating Systems, seleccionamos el Sistema Operativo, y en
la pestaña Templates seleccionamos para kexec la plantilla Discovery Red Hat kexec:
Figura 7-49. Selección de kexec para PXE-less Discovery
7.6.7.2 Arranque del Servidor y Configuración de Parámetros de Red
Arrancamos el servidor con la imagen anterior, y configuramos manualmente todos los parámetros de red
siguiendo las instrucciones.
Una vez completados todos los pasos, aparecerá el host en la interfaz web de Satellite en la sección Hosts →
Discovered Hosts. Debemos seleccionar el host y darle al botón:
98
Provision: se nos abrirá una nueva pantalla de creación del Host, en la cual le especificamos
manualmente todos los parámetros del Host en Satellite, tal y como se indica que el punto 11.6.1
(Creación manual de un nuevo host)
Autoprovision: en este caso la instalación del Sistema Operativo comienza automáticamente. Para ello,
en la configuración PXE-less del host, hemos debido establecer con un fact personalizado la versión de
SO a instalar.
Este fact debe definirse previamente en Satellite. Para ello nos vamos a Configure → Discovery Rules, New
Rule, y creamos una regla especificando los campos name, campo search (valor de la regla), host group (donde
se habrán definido los parámetros SO para el aprovisionamiento).
Figura 7-50. Reglas de descubrimiento para aprovisionar un host
7.7 Informes de Seguridad SCAP
Satellite se instala con el plugin de OpenSCAP habilitado. Podemos ver la sección correspondiente a los
informes y contenido SCAP en la interfaz web (Hosts → Compliance):
Policies
SCAP Content
Reports
99
Figura 7-51. Menú de cumplimiento SCAP
7.7.1 Instalación de paquetes OpenSCAP en Satellite
Instalamos el paquete que proporciona contenido OpenSCAP en el servidor Satellite:
# yum install puppet-foreman_scap_client
7.7.2 Carga del contenido OpenSCAP en Satellite
Ejecutamos el siguiente comando para subir el contenido OpenSCAP por defecto a Satellite:
# foreman-rake foreman_openscap:bulk_upload:default
Saved /usr/share/xml/scap/ssg/content/ssg-firefox-ds.xml as Red Hat
firefox default content
Saved /usr/share/xml/scap/ssg/content/ssg-jre-ds.xml as Red Hat jre
default content
Saved /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml as Red Hat
rhel6 default content
Saved /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml as Red Hat
rhel7 default content
Podemos ver el contenido SCAP en Satellite en la sección Hosts → SCAP Contents
Figura 7-52. Contenido SCAP disponible en Satellite
100
7.7.3 Importar módulos de Puppet de OpenSCAP en Satellite
En primer lugar, accedemos a la sección de Puppet de la interfaz web Configure → Environments. Previamente
debemos crear los entornos (a través de línea de comandos) en la ruta /etc/puppet/environments:
# mkdir -p /etc/puppet/environments/production/modules
# mkdir -p /etc/puppet/environments/testing/modules
En segundo lugar, importamos el módulo de OpenSCAP en los entornos de puppet. Para ello le damos al botón
Import from satellite.prpm.org, seleccionamos los entornos, y le damos a Update. El módulo
foreman_scap_client se añadirá a los entornos.
Verificamos que el módulo se ha añadido accediendo a Configure → Environments, seleccionamos Classes en
el entorno correspondiente, y vemos que aparece el módulo foreman_scap_client.
Figura 7-53. Clases de puppet de SCAP
7.7.4 Creación de una nueva política
En la interfaz web accedemos a Hosts → Policies. Le damos a New Compliance Policy y seguimos los pasos:
Nombre: rhel7
SCAP Content: Red Hat rhel7 default content
XCCDF Profile: Common Profile for General-Purpose Systems
Schedule: Weekly, Sunday
Locations: CENTRAL
Organizations: PRPM
Hostgroups: lib/rhel7-x86_64
101
Figura 7-54. Nueva política SCAP
7.7.5 Añadir una política a un host
Podemos añadir una política a un host en la pestaña Hosts → All hosts, seleccionamos el host y le damos al
botón Select Action.
Le damos a Assign Compliance Policy en el menú desplegable, y seleccionamos la política en la ventana
emergente:
Figura 7-55. Asignación de una política a un host
7.7.6 Visualización de Informes de Seguridad
Podemos ver los informes de seguridad en la sección Hosts → Reports:
102
Figura 7-56. Informes de SCAP en Satellite
Si hacemos clic en el campo Reported At de alguno de los servidores, podremos ver el informe detallado:
Figura 7-57. Detalle de informe SCAP de un servidor
El informe completo lo tenemos dándole al botón Full Report. En el informe completo tenemos información
detallada de los test y de la solución a aplicar en el servidor para resolver los fallos:
103
Figura 7-58. Informe completo SCAP de un servidor
104
105
8 CONCLUSIONES Y LÍNEAS DE AVANCE
n el presente proyecto se han detallado las distintas necesidades de gestión de sistemas que surgen de la
evolución tecnológica y crecimiento de las infraestructuras actuales. Para dar respuesta a estas necesidades,
hemos descrito las pautas para definir un Entorno Operativo Estándar, que es un marco de reglas, contenidos
y procedimientos bajo el que funcionarán todos nuestros sistemas. La definición de un SOE nos ayudará a tener
un mayor control sobre nuestros servidores, proporcinándonos una infraestructura escalable, segura y
automatizada.
Se han descrito distintas herramientas para realizar las tareas más comunes de administración, dando a conocer
algunos proyectos Open Source y una herramienta como Satellite que integra varios de estos proyectos, haciendo
que funcionen de forma orquestada e integrada en una única consola de gestión, lo que la convierte en una
solución ideal todo-en-uno para los administradores de sistemas.
Con Satellite podemos aprovisionar sistemas, parametrizando el sistema operativo, particionado e instalación
inicial. A través de su intregración con puppet, podemos realizar despliegues de múltiples configuraciones. Una
vez creado el servidor, podemos categorizarlo y asignarlo a un entorno, donde tendremos el control de las
versiones de paquetes instaladas. A través de la gestión de actualizaciones, podremos instalar parches de
seguridad de forma individualizada o en grupo, con información detallada de bugs y vultnerabiliades.
Además, con Satellite podemos establecer políticas de seguridad basadas en SCAP, con las que tendremos un
conocimiento detallado de grado de cumplimiento de seguridad de nuestros servidores.
Con todas estas características damos respuesta a las necesidades de gestión y administración definidas, lo que
nos hace concluir que es una de las herramientas más completas, con un elevado grado de estandarización y
flexibidad para adaptarse a diferentes ecosistemas, siendo el cliente el que define el contenido que más se adapte
a sus necesidades.
Puede suceder que una herramienta de estandarización que proporciona homogeneidad a nuestros sistemas, nos
lleve a la falsa sensación de ser poco flexibles cuando tenemos necesidad de diferentes configuraciones, pero
nada más lejos de la realidad. Podemos llegar a un elevado grado de flexibilidad categorizando nuestros sistemas
y teniendo bien definidas las distintas configuraciones a aplicar.
Como líneas de investigación adicionales al presente proyecto, podemos enumerar las siguientes:
El trabajo se ha centrado principalmente en la herramienta Satellite, por lo que se puede ampliar una
línea de investigación de las herramientas Open Source descritas, detallando diferentes implantaciones
de cada una de ellas. De esta forma tendremos una visión más completa de las posiblidades que nos
E
106
ofrecen estos proyectos por separado.
Además de un estudio más detallado de las herramientas Open Source, se podría realizar un análisis del
funcionamiento en conjunto de varias de ellas en una misma infraestructura.
Con una visión más profunda de las herramientas Open Source, se podría realizar un estudio del
esfuerzo personal y económico de utilizar estas herramientas, comparándolo con el que supone cuando
usamos una herramienta como Satellite. De este modo, la elección de una u otra opción depende de las
necesidades y capacidades de cada organización.
107
9 BIBLIOGRAFÍA
Documentos
- Documentación de Red Hat Satellite (https://access.redhat.com/documentation/en-us/red_hat_satellite)
- 10 steps to build a Standard Operating Environment
(https://www.redhat.com/files/summit/2015/13749_10-steps-to-build-a-standard-operating-
environment-soe.pdf)
Páginas web
- The Foreman Project (https://www.theforeman.org/)
- Katello (https://theforeman.org/plugins/katello/)
- Open Source Puppet (https://puppet.com/docs)
- Ansible (https://www.ansible.com/)
108
