Gestión integral de la ampliación de una infraestructura de sistemas y servicios

Transcripción

1 TITULACIÓN: Ingeniería Informática Gestión integral de la ampliación de una infraestructura de sistemas y servicios Alumno/a: D. Miguel Sánchez Martiarena Director/a: D. Roberto Cortiñas Rodriguez Proyecto Fin de Carrera, julio de Miguel Sánchez

2

3 Agradecimientos y dedicatorias Quiero dedicar este proyecto de fin de carrera a mi tía Pilartxo. Nunca podré agradecerte lo mucho que hiciste por mí. A Mariela por el cariño y apoyo de todos estos años. A mis padres ya que sin su ayuda y comprensión no estaría cumpliendo mis sueños. A Fran, Nico y Marcos por todos estos años juntos. A Adrián, Ganger, Iza, Juncal, Ninette, Roman y Vanessa ya que formaís parte de la gente a la que quiero y valoro. A Arturo por tu dedicación e implicación en este proyecto. Gracias por tu esfuerzo y horas de piscina invertidas. Ha sido una suerte tenerte como tutor. A mis compañeros de Ibermática y en especial a los de OM-CPD por su predisposición a ayudarme en lo que fuera posible. A Roberto porque sin tí esto no habría sido posible. Por creer en este proyecto y en mí hasta en los peores momentos. A mis compañeros de esta pequeña aventura llamada carrera, gracias por hacer de estos 5 años un periodo de mi vida inolvidable. La universidad no habría sido lo mismo sin todos vostros. A mis profesores de la facultad ya que sin sus enseñanzas no habría podido desarrollar este proyecto. A los no mencionados... os quiero!

4

5 Gestión integral de la ampliación de una infraestructura de sistemas y servicios Abstract: Este proyecto se sitúa en el ámbito de las empresas que ofertan servicios informáticos a terceros. Estas empresas se dedican a cubrir las necesidades de gestión de la infraestructura de sistemas y servicios de los clientes. En concreto, los proyectos de ampliación de esas infraestructuras suelen ser bastante problemáticos. Este proyecto desarrolla un conjunto de procedimientos que permiten gestionar la ampliación de una infraestructura de sistemas y servicios de acuerdo a una librería de buenas prácticas denominada ITIL. 5

6

7 Índice 1 Introducción Análisis de antecedentes Librería de buenas prácticas ITIL Organización inicial Documento de objetivos del proyecto Objetivos del proyecto Definición de tareas Estimación de la dedicación a las tareas Análisis de factibilidad Metodología Planificación del trabajo Desarrollo Fase 0: Recepción de la información inicial Fase 1: Instalación del Hardware Fase 2: Instalación del Sistema Operativo Fase 3: Instalación de los servicios Fase 4: Pruebas de la nueva infraestructura Fase 5: Traspaso del servicio Seguimiento y control del proyecto Planificación Metodología Problemas Conclusiones Conclusiones personales Bibliografía Glosario Anexo Diagramas de las fases Plantillas Formularios Listas de control Catálogo de servicios Procedimientos

8 Índice de Ilustraciones Figura 1: Las fases que componen el Ciclo de Vida de los Servicios...17 Figura 2: Procesos de Gestión de ITIL...19 Figura 3: Estructura interna...24 Figura 4: Departamentos antes de la transición...27 Figura 5: Departamentos después de la transición...27 Figura 6: Transición de estructura vertical a transversal en CSN...30 Figura 7: Diagrama de Gantt de la planificación del PFC...46 Figura 8: Ciclo de Deming...60 Figura 9: Tipos de monitorización utilizados en CSN...64 Figura 10: Funcionamiento de IRS...65 Figura 11: Diagrama de flujo de la fase Figura 12: Diagrama de comunicaciones de la fase Figura 13: Diagrama de flujo de la fase Figura 14: Diagrama de comunicaciones de la fase Figura 15: Diagrama de flujo de la fase Figura 16: Diagrama de comunicaciones de la fase Figura 17: Diagrama de flujo de la fase Figura 18: Diagrama de comunicaciones de la fase Figura 19: Diagrama de flujo de la fase Figura 20: Diagrama de comunicaciones de la fase Figura 21: Plantilla de tareas para la fase Figura 22: Plantilla de Gantt para la fase Figura 23: Plantilla de tareas para la fase Figura 24: Plantilla de Gantt para la fase Figura 25: Plantilla de tareas para la fase Figura 26: Plantilla de Gantt para la fase Figura 27: Plantilla de tareas para la fase Figura 28: Plantilla de Gantt para la fase Figura 29: Plantilla de tareas para la fase Figura 30: Plantilla de Gantt para la fase

9 Índice de Tablas Tabla 1: Estimación de dedicación a cada tarea...38 Tabla 2: Estimación de dedicación a cada elemento del PFC...39 Tabla 3: Estimación de las reuniones del PFC...47 Tabla 4: Seguimiento de las horas invertidas...69 Tabla 5: Reuniones del PFC...70 Tabla 6: Dedicación a cada elemento del PFC...71 Tabla 7: Desviaciones del PFC

10

11 1 Introducción Una de las prioridades en algunas empresas es por una parte facilitar el trabajo de los empleados en la medida de lo posible y por otra que la empresa se asegure de que los empleados realizan el trabajo siguiendo unas pautas que se han definido anteriormente. Por ello se desarrollan procedimientos internos que son documentos en los que se indica que es lo que se debe hacer, cómo y a quién notificar que el trabajo ha sido realizado. Una de las empresas que tiene implantado este modo de trabajo es Ibermática. Ibermática es una empresa cuya principal actividad está enmarcada en el mercado de los servicios informáticos ofrecidos en el ámbito de las tecnologías de la información (en adelante, únicamente TI). Estructuralmente constituye un grupo de empresas divididas a su vez en áreas y departamentos. A lo largo del presente documento haremos referencia a algunas empresas del grupo tales como Servimática, empresa gestora del CPD de clientes y a varios departamentos. A finales de 2011 y a principios del año 2012 se va a realizar una reestructuración de las diferentes áreas de soporte de los servicios ofrecidos a los clientes por Ibermática. El objetivo de este cambio es migrar de una estructura vertical a una estructura horizontal que se implantará progresivamente en una de las áreas de esta empresa, en concreto el Centro de Servicios Norte (en adelante CSN). En este escenario, el alumno de la facultad de Informática de San Sebastián (UPV/EHU) Miguel Sánchez Martiarena estuvo realizando prácticas en el departamento de Sistemas-UX (encargado de la implantación, configuración y administración de los sistemas UNIX de diferentes clientes), perteneciente a CSN, desde Julio de Durante los 3 meses de prácticas Miguel y su tutor en la empresa, Arturo Pérez del Gállego, detectaron una carencia en los procedimientos que se iban a poner en funcionamiento a lo largo del año

12 El objetivo de este proyecto es planificar y procedimentar todas las comunicaciones y tareas de los futuros proyectos de ampliación de una infraestructura existente cuando ésta sea necesaria. Los proyectos de ampliación se han dividido en seis fases que se detallarán a lo largo del proyecto y cuyo objetivo es facilitar el trabajo a los profesionales involucrados en las futuras ampliaciones de infraestructuras. 12

13 2 Análisis de antecedentes En este apartado se describirá la situación existente cuando se empezó a trabajar en este proyecto para después detallar las partes más importantes necesarias para comprender el alcance del proyecto. Al comenzar a realizar las prácticas en Ibermática, la organización estaba experimentando la transición desde una organización vertical orientada a clientes a una organización horizontal orientada a tecnologías. En el mundo TI, se dice que una organización tiene una estructura vertical cuando sus departamentos están divididos según los clientes, de tal modo que existe un único departamento para realizar todas las labores relativas a un sólo cliente y existen por ello tantos departamentos como clientes. Una estructura horizontal sin embargo divide los departamentos según las tecnologías con el objetivo de especializar a los profesionales en los diferentes productos instalados en los clientes. Las ventajas y desventajas de estas estructuras serán clarificadas a lo largo de los siguientes apartados. La transición se estaba realizando siguiendo una librería de buenas prácticas denominada ITIL. Por ello en el apartado 2.1 se describirá ITIL, qué es y en qué consiste, y en el apartado 2.2 se comentará la estructura organizativa en Ibermática y su transición para adaptarse a los requerimientos de ITIL. 13

14 2.1 Librería de buenas prácticas ITIL Algunos de los servicios que ofrecen las empresas de TI son, consultoría de infraestructuras de sistemas y servicios, gestión de infraestructuras, alojamiento de infraestructuras, soporte de aplicaciones y soporte técnico presencial. Cada día los recursos informáticos de las empresas son más críticos por lo que el objetivo de las empresas de TI es ofrecer unos servicios de alta calidad que aseguren la continuidad del negocio de sus clientes. Por ello se siguen unas pautas de trabajo que aseguren la calidad de los servicios ofrecidos al cliente desde el primer momento. Además, cada vez son más los clientes que requieren en los pliegos de ofertas a concurso que las empresas que aspiran al mismo estén certificadas (en el caso que nos ocupa, avaladas por la ISO 20000) en alguna metodología que garantice la calidad futura del servicio. Una organización o empresa puede obtener esta certificación si la misma aplica ITIL (Information Technology Infrastructure Library), una librería de buenas prácticas que tiene por objeto asegurar la calidad en la gestión de los servicios. En este caso se entiende un servicio como una forma de entregar valor a los clientes facilitando los resultados que estos esperan lograr sin asumir directamente los costes y riesgos específicos. Hay que decir que ITIL es una guía para mejorar la calidad de los procesos internos pero no proporciona ninguna pauta a seguir ni ofrece concreción de ningún tipo. Es trabajo del departamento encargado de implantar ITIL en Ibermática interpretar lo que dice esta librería y aplicarlo de la manera que mejor se ajuste a las circunstancias. De hecho uno de los pocos requisitos para poder aplicar ITIL es que la empresa tenga una organización horizontal. 14

15 El principio en el que se basa ITIL es el ciclo de vida de los servicios, por ello en el apartado se hará una introducción a este concepto. En el apartado se mencionarán los procesos de gestión que se requieren a lo largo del Ciclo de Vida de los Servicios. Finalmente en el apartado se explicarán las funciones que deben ocupar los empleados en una empresa para realizar dichos procesos de gestión. 15

16 2.1.1 Ciclo de Vida de los Servicios El Ciclo de Vida de los Servicios es un modelo organizativo que tiene como objetivo ofrecer una visión global de la vida de un servicio. Se entiende por vida de un servicio los diferentes fases por las que pasa un servicio desde su creación (estrategia del servicio y diseño del servicio) pasando por su implementación en la infraestructura del cliente (transición del servicio) hasta el cumplimiento de su cometido (operación del servicio). Este ciclo permite conocer con más detalle: Cómo se realiza la gestión del servicio. La manera en la que los diversos componentes que forman un servicio se relacionan entre sí. Facilitando la prevención del impacto que los cambios en un componente tendrá sobre el resto de componentes y en el ciclo de vida del servicio. Según ITIL, el Ciclo de Vida de los Servicios consta de cinco fases estrategia del servicio, diseño del servicio, transición del servicio, operación del servicio y mejora continua del servicio. representadas mediante la figura 1. Dicha la figura representa la estrategia del servicio como el núcleo de todas y cada una de las fases. Las tres fases de diseño del servicio, transición del servicio y operación del servicio conforman un ciclo repetitivo alentado por el proceso de mejora continua del servicio. 16

17 Figura 1: Las fases que componen el Ciclo de Vida de los Servicios 1) Estrategia del Servicio: ofrece la orientación para el diseño, desarrollo e implementación de la gestión de servicios no sólo como una capacidad sino como un activo estratégico. La fase de la Estrategia de los Servicios es el eje central del ciclo de vida de la gestión del servicio. Su meta principal es que la organización realice un estudio de mercado para determinar qué servicios deben ser prestados para obtener el mayor retorno de la inversión. En esta fase se analiza el tipo de cliente para decidir qué se le debería de ofrecer y cómo se le debería ofrecer, permitiendo realizar el negocio con éxito. 2) Diseño del Servicio: transforma los objetivos estratégicos definidos en la fase anterior en servicios que se puedan ofrecer a los clientes. Durante esta fase se genera el Catálogo de servicios en el cuál se detallan los servicios ofrecidos a los clientes, los acuerdos de nivel de servicio(sla) y el coste asociado. En los acuerdos de nivel de servicio, el/los proveedor/es de servicios TI y el/los cliente/s, identifican un conjunto de métricas medibles que determinan la calidad del servicio recibido. El diseño del servicio también debe proporcionar una guía indicando lo que se debe hacer para prestar 17

18 el servicio definido en la estrategia del servicio. 3) Transición del Servicio: despliega los servicios TI diseñados en la fase anterior en el entorno de producción del cliente. Dado que los servicios se diseñan de una manera genérica para poder abarcar al mayor número de clientes posibles, la Transición de los Servicios, se encarga de coordinar los procesos, funciones y recursos necesarios para implantar dicho servicio en el cliente según lo pactado en los acuerdos a nivel de servicio. 4) Operación del Servicio: provee las mejores prácticas para la gestión del día a día del servicio. La Operación del Servicio cubre la coordinación y ejecución de las actividades y procesos necesarios para que los servicios sean correctamente prestados a diario, con los niveles de servicio acordados. 5) Mejora Continua del Servicio: proporciona una guía para la mejora del valor ofrecido a los clientes sin dejar de lado el servicio. Las organizaciones TI deben de mejorar continuamente sus servicios y las calidad de los mismos dada la competencia que existe en este mercado. Esta mejora se realiza variando el diseño del servicio y modificando las implicaciones que este cambio tenga en la transición del servicio y la operación del servicio. 18

19 2.1.2 Procesos de Gestión de ITIL ITIL descompone cada una de las cinco fases del ciclo de vida del servicio en procesos de gestión representados en la figura 2. Se define un proceso como: Una serie de acciones o actividades conectadas con el fin de satisfacer un propósito y lograr un objetivo. Figura 2: Procesos de Gestión de ITIL Dado el número de procesos de gestión de ITIL se van a explicar únicamente los abarcados por en este proyecto: Gestión de la Capacidad: Estudiar las necesidades de ampliación de infraestructuras, de una máquina nueva (RAM, disco duro, etc...) o el estudio de la viabilidad de ampliación de la infraestructura existente. En un amplio sentido, analiza y detecta nuevas necesidades de capacidad en cualquier ámbito. 19

20 Gestión de la Disponibilidad: Analizar cómo se va a asegurar que el cliente disponga del servicio que solicita con una disponibilidad no inferior a la acordada. Gestión de la Continuidad: Analizar cómo se reaccionaría en caso de desastre (análisis de amenazas, vulnerabilidades planes de prevención y recuperación) Gestión de la Seguridad: Estudio de cómo se va a asegurar el control de acceso a la información o a la disponibilidad de un servicio. Gestión de Cambios: Estudiar la manera más eficiente de gestionar los cambios (formularios, peticiones, documentación, etc...) Gestión de la Configuración: Métodos necesarios para tener actualizada la información de un servicio/servidor (Hardware, Software, Componentes de red, Detalles de los usuarios, Unidades de negocio y Personal y documentación relacionados) Gestión de Entregas: Se generarán los procedimientos necesarios para el despliegue de los servicios ofrecidos al cliente (pudiera incluir procedimientos internos) 20

21 2.1.3 Funciones de ITIL para la Operación del Servicio Para lograr la satisfacción del cliente durante la fase de operación del servicio, la fase más crítica del ciclo de vida para el cliente, ITIL recomienda que existan cuatro funciones. Se define una función como: Una unidad especializada en la realización de una cierta actividad y es la responsable de su resultado. Las funciones incorporan todos los recursos y capacidades necesarias para el correcto desarrollo de dicha actividad. Estas funciones serán las encargadas de gestionar el día a día de los servicios ofreciendo soporte a distintos niveles. Además algunos profesionales de estas funciones serán los responsables de los procesos de gestión descritos en el apartado anterior. Esas cuatro funciones son: Centro de Servicios (Service Desk): responsable de todos los procesos de interacción con los usuarios de los servicios TI. Los objetivos de esta función son: actuar como punto único de contacto entre los usuarios y la gestión del servicio, resolver rápidamente las interrupciones del servicio, mantener informados a los usuarios y cumplir los acuerdos de nivel de servicio. Gestión de Operaciones TI: responsable de la operación diaria del servicio. Es la unidad responsable del mantenimiento y la gestión continua de la infraestructura de la organización TI. Se centra especialmente en asegurar que los servicios cumplen los niveles acordados. Sus labores son el control de las operaciones (Monitorización, Backups, resolución de incidencias...) y la gestión de los CPD's. Gestión Técnica: incluye a todos los equipos, grupos y departamentos involucrados en la gestión y soporte de la infraestructura TI. Es depositaria de la experiencia y los conocimientos técnicos relacionados con la gestión de la infraestructura TI y se ocupa de los recursos necesarios para dar soporte al Ciclo de Vida de la Gestión de Servicios TI. Entre sus actividades se 21

22 encuentran la formación de todo el personal del servicio TI, selección de personal y el diseño e instalación de nuevos servicios. Gestión de Aplicaciones: es responsable de gestionar las aplicaciones durante su ciclo de vida. La ejecución de esta función corresponde a un departamento, grupo o equipo que participa en la gestión y el soporte de las aplicaciones operativas. Es depositaria del conocimiento relacionado con las aplicaciones y lo pone al servicio del resto de la organización. Las funciones aquí descritas pertenecen a una posible división de una empresa que cuente con una estructura horizontal. Los departamentos que pertenezcan a esas funciones se especializarán en la administración y gestión de los diferentes elementos de esas funciones y aprovecharán ese conocimiento para dar un servicio más especializado en diferentes clientes. 22

23 2.2 Organización inicial Hasta el 31 de diciembre de 2011, el Centro de Servicios Norte de Ibermática (en la figura localizado en el ítem Infraestructuras Norte, en adelante, CSN) se ha dividido en siete áreas diferenciadas cuyas funciones se detallan a continuación: CAU: Centro de Atención a Usuarios. Realiza la atención directa al cliente por diversos medios: correo electrónico, teléfono, etc. Su función principal es la atención, recepción, seguimiento y resolución de incidencias y peticiones de los diferentes clientes del servicio. SD: Soporte Distribuido. Realiza labores de instalación, acondicionamiento y provisión de infraestructura cliente hardware (HW) y software a los diferentes clientes del área. OPE: Operaciones. Realiza labores de ejecución y seguimiento de las tareas en las infraestructuras de cada cliente. Realiza, también labores de seguimiento de las herramientas de monitorización y reporte de incidencias. SIS: Sistemas. Realiza las labores de implantación de nuevos proyectos de incorporación o evolución de la infraestructura de los clientes ya existentes o para nuevos clientes que se incorporan al área de servicios gestionados. Realiza también labores de soporte de nivel especializado para otros soportes y formación en nuevas tecnologías si es requerido. COM: Comunicaciones. Realiza las labores de implantación de infraestructura del área de comunicaciones para clientes ya existentes y nuevos clientes. Realiza también labores de soporte de nivel especializado para otros soportes. HW y Servicios. Se encarga de las labores de preventa, relación con clientes actuales y posibles clientes futuros, recabación de necesidades, establecimiento de requisitos y especificación de la plataforma inicial para los clientes o para el arranque de un servicio gestionado. 23

24 Figura 3: Estructura interna Hasta finales de 2011 en CSN se ha venido trabajando con una organización orientada a clientes (organización vertical). De tal modo que cada vez que se incorporaba un nuevo cliente o servicio a la modalidad de servicio gestionado por CSN se debían asignar por cada área unos recursos dedicados única y exclusivamente a dicho cliente. Este modo de trabajo ha resultado ser ineficiente, además de suponer un sobrecoste para Ibermática. Por ello se decidió analizar las ventajas y desventajas de la organización actual y de las posibles alternativas como se detalla a continuación. 24

25 2.2.1 Ventajas y desventajas de la estructura actual La ventaja de esta estructura es que los técnicos, a lo largo del tiempo, adquieren un conocimiento profundo de las necesidades del cliente y de su forma de trabajar gracias a lo cuál pueden traducir el lenguaje propio del negocio a lenguaje técnico propio del área de sistemas. Esto facilita los comunicaciones con el cliente y conlleva por lo tanto un mayor grado de satisfacción del mismo. Sin embargo desde el punto de vista de Ibermática, esto no es una ventaja ya que conlleva una peligrosa simbiosis entre técnico y cliente que provoca situaciones en las que el técnico se identifica mayoritariamente como parte del cliente y no del proveedor (como realmente debiera de ser). Para paliarlo, en la medida de lo posible, muchas organizaciones obligan a una rotación periódica de sus efectivos desplazados en el cliente. Hasta la fecha, CSN no ha optado por esta modalidad. Otra ventaja es que se habitúan a unas pautas de trabajo propias del cliente que se van refinando, readaptando con el tiempo. Uno de los grandes problemas derivados de esta simbiosis es que los subdepartamentos destinados al servicio de dos clientes diferentes tienen una escasa comunicación que no permite el aprovechamiento de sinergias. La aparición de un determinado problema en grupos diferentes obliga al análisis por separado del mismo para llegar a conclusiones similares y, por lo tanto, a resoluciones parecidas del problema. Es decir, en el caso presentado este modelo lleva a consumir muchos recursos para resolver problemas similares. Este ejemplo es claramente extrapolable a la generación de documentación, diseño y creación de procedimientos y, en definitiva, a gran parte de la actividad de los profesionales de cada subdepartamento. La documentación y procedimientos generados, aunque similar, es redundante. 25

26 Si la organización se estructurara de otro modo, orientada a tecnologías y no a clientes, el aprovechamiento de las sinergias a la que nos referíamos simplifica sobremanera todas estas tareas. Nótese que la simplificación no es total, es decir, siempre habrá que realizar adaptaciones de procedimientos generales a las particularidades de cada cliente. También es interesante esta estructura desde el punto de vista de que es más fácil procedimentar todo lo referente a esa capa transversal y controlar que los procedimientos que se siguen son los correctos siendo los mismos concebidos de manera similar. Esto es debido a que los procedimientos orientados a un cliente suelen ser muy específicos y orientados a un único cliente en particular. Sin embargo, los procedimientos de una organización horizontal se centran en las tecnologías, algo mucho más genérico y reutilizable por toda la organización Transición de la estructura Tras haber analizado las ventajas y desventajas de las estructuras se decidió comenzar la transición hacia una organización transversal reorganizando los departamentos según se muestra en las figuras 4 y 5. De tal modo que a partir de los primeros días de septiembre de 2011, en CSN, se viene trabajando en la transición a un nuevo modelo de organización con la idea de que esta comience ser efectiva a principios de enero de Durante este periodo los diferentes departamentos están manteniendo múltiples reuniones para poner en común sus conocimientos, procedimientos e infraestructura actual de cada cliente. El objetivo es que el cambio no resulte traumático y que los clientes no se resientan con un descenso del rendimiento de los servicios ofrecidos por Ibermática. Tras la transición, CSN quedará constituida por tres áreas cuyas funciones se detallan en las siguientes figuras: 26

27 Figura 4: Departamentos antes de la transición Figura 5: Departamentos después de la transición 27

28 De este modo los departamentos ya no estarán orientados a clientes sino a tecnologías, consiguiendo transversalizar la organización como requiere ITIL. Los nuevos departamentos en CSN están divididos en varios niveles que describiremos a continuación. En la función Gestión de Operaciones (Operation Management, en adelante denominado OM) se incluyen los siguientes departamentos: OM-WINDOWS: Departamento encargado de la resolución de incidencias, peticiones y problemas de toda la infraestructura relacionada con Windows de los clientes de CSN. También se encarga de la gestión de los backups y de las bases de datos MS-SQL. OM-CPD: Departamento encargado de la resolución de incidencias, peticiones y problemas de toda la infraestructura Unix de los clientes de CSN También se encarga de la gestión de entornos virtuales (principalmente VMware), sistemas AS400, sistemas de almacenamiento y bases de datos Oracle y MySQL. OM-COMUNICACIONES: Departamento encargado de la resolución de incidencias, peticiones y problemas de toda la infraestructura de comunicaciones de los clientes de CSN. También se encarga de la seguridad perimetral y de la telefonía VoIP. OM-EXPLOTACION: Departamento encargado de la monitorización de los sistemas de los clientes de CSN. También se encarga de las operaciones de cambios de cintas y su transporte. Se encarga de lanzar tareas periódicas de cada cliente (si procede) y revisar los lanzamientos de las tareas que constituyen el núcleo central del negocio del cliente. 28

29 En la función Gestión Técnica (Technical Management, en adelante los denominaremos únicamente TM) se incluyen los siguientes departamentos: TM-MS: Departamento especializado en tecnologías de Microsoft. TM-UX: Departamento especializado en tecnologías UNIX y BBDD. TM-MAIL: Departamento especializado en infraestructura de correo. TM-CPD: Departamento especializado en infraestructuras físicas relacionadas con los centros de procesamiento de datos (CPD). TM-GES: Departamento especializado en tecnologías de gestión del puesto de trabajo. TM-COM: Departamento especializado en infraestructuras de comunicaciones. TM-MONIT: Departamento especializado en monitorización Anteriormente existía una división dentro de los departamentos en grupos orientados a dar soporte a un único cliente, aglutinando el conocimiento específico de ese cliente. Tras la transición se pretende que ese conocimiento no esté centrado en un grupo sino en todo el departamento. Desde este punto de visto se puede representar la transición de los departamentos mediante la figura 7. Como puede observarse en esa misma figura, quedan fuera de esta transición dos de las cuatro funciones requeridas por ITIL y comentadas en el apartado 2.1.3: el centro de servicios y la gestión de aplicaciones. El centro de servicios lo formarán los antiguos CAU y SD como se aprecia en las figuras 4 y 5. Estos departamentos por su carácter de orientación a clientes no se pueden tranversalizar completamente ya que el impacto que puede tener sobre los clientes es muy elevado. Por otro lado, el departamento encargado de la gestión de aplicaciones no está incluido dentro de CSN sino que es responsabilidad de CIA (véase Figura 3) 29

30 Figura 6: Transición de estructura vertical a transversal en CSN 30

31 2.2.3 Modificaciones posteriores No obstante, durante los primeros meses del año se detectó que este encajonamiento de los técnicos no era óptimo ya que ninguno de los profesionales de TM tienen conocimiento exclusivo de una tecnología sino que los mismos estaban agrupados en varios de los grupos definidos. En la práctica, los profesionales de este área se engloban en un único grupo: TM. Teóricamente, los profesionales de este grupo aglutinan la experiencia y conocimiento de las diferentes tecnologías involucradas en los servicios ofrecidos a los clientes. La realidad, dados los recursos limitados del grupo, puede indicar que no haya en este nivel conocimiento de alguna tecnología en particular. Esta carencia deberá ser asumida por los profesionales de las otras áreas (en concreto de OM). Pudiera suceder que se detectara conocimiento que no residiera en ninguno de los niveles o grupos definidos anteriormente, esta carencia se suple mediante subcontratación de esos servicios o formación externa a cargo de terceros. 31

32 2.2.4 Identificación de carencias de la transición Como se ha comentado anteriormente los departamentos están poniendo en común su documentación y procedimientos en la medida en que la misma está operativa. A día de hoy, no hay departamento encargado de procedimentar la ampliación de la infraestructura ni de otras necesidades futuras; la idea desde el principio de la transición ha sido que los departamentos pongan en común la información de la que se dispone, adaptándola a formatos estándares que faciliten el acceso a la misma. Esta incorporación de contenidos al repositorio común de conocimiento es una tarea paulatina. Las nuevas necesidades surgidas se procedimentarán a medida que estos elementos se incorporen al servicio. Además, hasta ahora la ampliación de la infraestructura (ya sea por la llegada de un nuevo cliente o por la detección de alguna carencia en la infraestructura actual de un cliente) ha sido un procedimiento problemático ya que cada cliente tiene su propia metodología de trabajo, que además suele ser muy particular y, en general, no se adapta a las buenas prácticas que se quieren implantar en CSN. En este punto queda clara la necesidad de poner una base común que facilite la estandarización de este proceso. Ahí es donde nace el objetivo del presente Proyecto de Fin de Carrera (en adelante, PFC). Con la elaboración del mismo se pretende suplir la carencia, tal y como se describirá en el siguiente apartado, del procedimiento de ampliación de la infraestructura dentro de la transición que se está llevando a cabo en Ibermática. 32

33 3 Documento de objetivos del proyecto 3.1 Objetivos del proyecto El objetivo principal de este proyecto es realizar un documento de referencia en el cuál se basarán los profesionales encargados de ampliar una infraestructura de sistemas y servicios de un cliente de Ibermática. Para ello se realizará un análisis de las necesidades de cada fase de la ampliación y se generarán diferentes tipos de documentos. En primer lugar se van a generar los documentos que detallan lo que se debe realizar en cada fase y quién debe de hacerlo. Para facilitar la comprensión de dichos documentos se producirán diagramas por cada una de las fases en los que se representa de una manera más visual las comunicaciones y los roles involucrados. Para que las comunicaciones se lleven de una manera controlada se crearán unos formularios que los profesionales involucrados deberán completar y entregar según la documentación del proyecto. Para ayudar los profesionales involucrados en estos proyectos crearán también plantillas con las tareas a realizar en cada fase y la estimación de las mismas; el objetivo es que se basen en estas plantillas para generar los proyectos reales de ampliación pudiendo modificar algunas tareas en caso de necesidad. Además se van a generar listas de comprobación para que estos trabajadores verifiquen en algunos puntos críticos del proyecto que este se encuentra bajo control. Por último se desarrollarán procedimientos que faciliten la instalación de los servicios ofrecidos en el catálogo de servicios de Ibermática. Para poder entender y aplicar ITIL, ya que como se ha comentado anteriormente es una librería que proporciona unas guías de implantación que necesitan de una interpretación y conocimiento del entorno de aplicación, se deben conocer a fondo ITIL y la estructura de Ibermática. 33

34 3.2 Definición de tareas Tras el análisis del proyecto, se ha decidido dividir cada proyecto de ampliación de la infraestructura en 6 fases, cada una de ellas compuesta por diferentes tareas, personas implicadas e hitos. En la fase 0: Recepción de la información inicial, tras detectar alguna carencia de servicio en la infraestructura actual de un cliente, se procederá a diseñar el modo en el que se va a solventar dicha carencia generando el documento inicial sobre el que se basarán las siguientes fases. Esta fase, que queda fuera del alcance del PFC por su carácter comercial, encaja dentro del diseño del servicio que se ofrecerá al cliente y que tiene su equivalente en el ciclo de vida del mismo definido por ITIL. Durante la fase 1: Instalación de Hardware se detallan los procesos y procedimientos necesarios para que tras haber recibido la información relativa al nuevo proyecto generada en la fase 0 se instale el Hardware necesario para la ampliación de la infraestructura. En la fase 2: Instalación del Sistema Operativo se detallan las tareas y procedimientos necesarios para la instalación del sistema operativo de las máquinas que se acaban de añadir a la infraestructura del cliente. Se instalarán y configurarán además algunas herramientas que facilitarán el trabajo de los profesionales encargados de las siguientes fases del proyecto. Durante la fase 3: Instalación de los servicios se detallan los procedimientos y gestiones que se deben llevar a cabo para instalar los servicios acordados en la fase 0 sobre las máquinas instaladas en las fases anteriores. 34

35 Es decir, durante las fases 1 a 3 se detallan los procesos, procedimientos y gestiones que se deben llevar a cabo para que la ampliación de la infraestructura se haga de manera ordenada, controlada, documentada y correctamente gestionada. De este modo, las personas implicadas en cada fase saben en todo momento su rol dentro del flujo del proceso y con quién deben comunicarse. Estas fases, aunque están centradas en la transición del servicio, hacen uso de información generada durante la fase de diseño generando también información necesaria para la operación del mismo. En un principio se habían unido estas tres fase en una única pero posteriormente se llegó a la conclusión de que sería una fase muy larga y difícil de controlar por lo que se presenta con esta división. A lo largo de la fase 4: Pruebas de la nueva infraestructura se validará que todos los elementos técnicos involucrados en las fases anteriores cubran las carencias detectadas en la fase 0, sean fiables y cumplan con los requisitos exigidos por el cliente (SLA). Esta fase se centra en la gestión de validación y pruebas dentro de la transición del servicio. Por último, la fase 5: Traspaso del servicio recopila la documentación relativa al proyecto y se encarga de transmitir el conocimiento obtenido a lo largo de la implantación del proyecto a las personas implicadas en los servicios gestionados. Tras el análisis del tipo de proyecto que se iba a llevar a cabo se decidió que el enfoque más correcto era el incremental. Dada la dependencia que existe entre las diferentes fases y las comunicaciones que debían existir entre ellas se hace muy difícil definir desde un principio cuál es exactamente la documentación que debe existir en un determinado punto de la ampliación. Con ello, se decidió dividir el proyecto en 8 iteraciones 1. 1 Nota: Dada la coincidencia de que en este proyecto (PFC) se genera documentación relativa a un proyecto de ampliación, se crea una confusión de nombres. Por lo general los proyectos se dividen en fases; para ser coherentes se debería mantener esa nomenclatura para ambos, sin embargo para evitar ambigüedades se ha decidido dividir en PFC en iteraciones y el proyecto de ampliación de la infraestructura en fases. 35

36 La primera servirá para estudiar y comprender en que consiste ITIL, los procesos organizativos actuales de la empresa y posteriormente definir unos documentos básicos describiendo unos esbozos de lo que será la introducción y la fase 1. El objetivo es definir el alcance exacto del proyecto y tener claras las ideas de qué es lo que quiero hacer?, a dónde quiero ir?, cómo lo voy a hacer? Durante la segunda iteración se debe dejar la introducción bastante avanzada (70%), la fase 1 al 40% y empezar a definir la fase 2. A lo largo de la tercera iteración se realizarán avances en la fase 1 y fase 2 dejándolas al 70%, la fase 3 al 40% y se empezará a desarrollar la fase 4. En la cuarta iteración la intención es dejar definido un primer borrador de lo que sería el proyecto completo dejando las fases 3 y 4 al 70% y la fase 5 al 30%. La quinta iteración es la más técnica de todas, en ella se recogerán los procedimientos de instalación de servicios del catálogo que se instalarán en la fase 3. Algunos de estos procedimientos han sido desarrollados durante la estructura vertical anterior y se maquetarán y cambiarán para adaptarlos a la nueva estructura. Para los servicios restantes se realizarán todos los procedimiento de instalación y configuración de los servicios ofrecidos en el catálogo de servicios. Esta fase se creó, además de por necesidad del proyecto, con el objetivo de poder tener una tarea en la que poder avanzar si en algún momento las circunstancias hacen que no pueda seguir con el proyecto. Al ser una fase tan técnica no es necesario, en principio, el apoyo de otras personas. Durante la sexta iteración se pretende revisar toda la documentación y comprobar que se cumplen todas las dependencias, que todas las tareas necesarias existen y están correctamente ubicadas dejando todas las fases a un 80%. La séptima iteración se utilizará para empezar a generar documentación pulida y trabajada que poder presentar al tutor de la universidad para comenzar la revisión de cara a la presentación del proyecto. 36

37 Finalmente durante la octava iteración se terminarán todos los documentos del proyecto, se generará la documentación propia del PFC y se procederá a la maquetación definitiva de toda la documentación Roles del proyecto Para llevar a cabo este proyecto se han definido varios roles que deberán ser asumidos por diferentes personas. A continuación se presentan los roles de este proyecto: Rol Persona/s Tareas Alumno Miguel Sánchez Es el encargado de llevar a cabo el proyecto. Debe planificarlo, redactarlo, y encargarse de que todas las personas implicadas en el proyecto estén organizadas para llegar a buen puerto. Tutor de la empresa Supervisor del proyecto Empresa Arturo Pérez Roberto Cortiñas Trabajadores de la empresa 3.3 Estimación de la dedicación a las tareas Apoya al alumno en todo el proyecto sobre todo con la parte de ITIL, aporta el punto de vista de la empresa y su conocimiento en este área. Apoya al alumno a definir el alcance y los objetivos del proyecto. También aporta una visión externa para que el proyecto no se desvíe de los inicialmente definido. Por último ayuda a la redacción y presentación del escrito de cara a la defensa del PFC. Profesionales afectados por el procedimiento que se va a desarrollar. Una vez definidas las tareas se realizó una estimación de la dedicación necesaria para llevarlas a cabo dando lugar a la siguiente tabla: 37

38 Tabla 1: Estimación de dedicación a cada tarea * El item En la empresa incluye a los roles empresa y tutor. 38

39 Lo que suma un total de 396 horas dejando por lo tanto un margen de 54 horas para desviaciones ya que está estipulado que la dedicación de un PFC no debe sobrepasar 450 horas. Además la tabla 2 presenta una estimación de la dedicación que necesita cada uno de los elementos del proyecto. Ya que en distintas iteraciones se trabaja sobre un mismo elemento, esta tabla sirve para conocer la dedicación total a este tipo de elementos. También se hace mención a algunos elementos (marcos con * ) que aunque no son de la misma naturaleza que los de la tabla también es conveniente que aparecezcan. Elemento Formación* Introducción Fase 1 Fase 2 Fase 3 Fase 4 Fase 5 Documentación del PFC* Horas Estimadas 20h 41h 53h 38h 103h 48h 23h 40h Reuniones* 30h Tabla 2: Estimación de dedicación a cada elemento del PFC El elemento que más horas de dedicación necesita es la fase 3, esto se debe a que todos los procedimientos técnicos se realizarán a lo largo de esta fase con la consecuente necesidad de inversión de horas en estudio de esos servicios y desarrollo de procedimientos así como adaptación y revisión de procedimientos ya existentes. 39

40

41 4 Análisis de factibilidad Mientras se define el proyecto se debe realizar un análisis de factibilidad para saber si realmente es viable el proyecto o los riesgos que se detectan al inicio son tan elevados que no se puede asegurar que llegue a buen puerto. Evidentemente el hecho de que el proyecto no se limite al ámbito técnico sino que se centre en el entorno organizativo empresarial, teniendo en cuenta que el alumno únicamente tiene 3 meses de experiencia en el mercado laboral es un gran riesgo. Además unos meses antes de comenzar este proyecto había suspendido el examen de la asignatura de la carrera que más relación guardaba con este PFC, Planificación y Gestión de Proyectos (PGP). No obstante el contar con el apoyo de un tutor en la empresa, en este caso Arturo Pérez del Gállego, con 15 años de experiencia en Ibermática, muy implicado en la transición de Ibermática y certificado en ITILv3, supone una gran apoyo para llevar adelante este proyecto. Además en Ibermática existen unos cursos internos de ITIL a los cuales el alumno asistirá para mejorar sus conocimientos de esta librería de buenas prácticas. En referencia al riesgo anterior, se considera que el hecho de que exista una persona tan crítica en el desarrollo del proyecto como es el tutor conlleva un grado elevado de riesgo. Debe implicarse en el proyecto sin descuidar sus labores diarias. Además la motivación y tiempo disponible son diferentes a las del alumno. Por ello se adaptará la metodología de trabajo para aprovechar al máximo el tiempo que disponga para elaborar el proyecto. Otro riesgo es que durante el tiempo que dure el proyecto el alumno debe compaginar el tiempo que esté en la empresa entre las prácticas y la elaboración del proyecto. Podría ocurrir que las prácticas absorban tanto tiempo que no se avance en el proyecto. Para reducir este riesgo se firmó un convenio para la realización de este PFC en empresa en el cuál se indica que la dedicación debe ser equitativa. 41

42 También, el hecho de que el proyecto esté tan ligado a la empresa aumenta el riesgo considerablemente y en caso de dejar la empresa el proyecto ya no tendría un entorno en el que ser aplicado ya que qué sentido tiene realizar un procedimiento para una empresa que ya no existe o para la que ya no se trabaja? Con esto en mente se procurará generalizar los más posible el proyecto y personalizar únicamente las partes imprescindibles para facilitar la adaptación del proyecto en otro entorno si fuera necesario. El hecho de que sea un proyecto con implicaciones organizativas conlleva un riesgo añadido. Este riesgo reside en el factor humano y en como van a reaccionar los profesionales que se mencionen en los procedimientos ante el hecho de que se les imponga un nuevo método de trabajo. Para prevenir esto, se seguirá una metodología de trabajo que los implique en el desarrollo del proyecto, escuchando sus necesidades, puntos de vista, comentarios y consejos. Por último y como consecuencia del riesgo anterior, el número de personas implicadas en el proyecto aumenta así como el riesgo del proyecto. Esto se debe a que la calidad del proyecto dependerá de la implicación de estas personas y del tiempo que tengan disponible para el mismo. Para intentar paliar este riesgo se intentarán programar las reuniones con tiempo de antelación y órdenes del día claros y concisos para que estas reuniones sean lo más dinámicas posibles y aumentar su eficacia. Además se ha decidido dividir el proyecto en iteraciones; uno de los objetivos de esta división es que se pueda trabajar concurrentemente en diferentes fases del proyecto dentro de una misma iteración para evitar el bloqueo del proyecto en caso del aplazamiento de una reunión o baja de un profesional. 42

43 5 Metodología Como se ha ido explicado a lo largo en los apartados anteriores, se va a utilizar una metodología para facilitar el trabajo de las personas implicadas en el proyecto; también se ha tenido en cuenta el tipo de proyecto y los objetivos del mismo a la hora de plantear esta metodología. Para la formación en ITIL, el alumno tendrá a su disposición el material de certificación interna de Ibermática. Este curso incluye material didáctico y una serie de exámenes para evaluar los conocimientos. Además dispone de algunos materiales que usó el tutor en su certificación oficial. A la hora de definir las fases que componen cada proyecto de ampliación los asistentes llevarán un borrador con los esbozos de las ideas principales. Durante la reunión, pondrán en común esas ideas y las debatirán apoyándose de la herramienta FreeMind. El objetivo es que sea una reunión muy dinámica en la que todo el mundo puede participar y todas las ideas serán analizadas y aceptadas o descartadas. Inicialmente el alumno y el tutor trabajarán juntos en las iteraciones 1 y 2 ya que se estima que ese es momento en el que más apoyo necesita el alumno. A partir de ahí la metodología será diferente, el alumno generará documentación en un repositorio de documentos compartidos que el tutor revisará a petición del alumno. Tras cada revisión se reunirán para debatir los puntos en los que haya diferencias y se señalar los puntos de acuerdo. Cuando el alumno alcance un punto en el que necesita opinión de algún profesional de CSN (generalmente porque le afecta un procedimiento o formulario) consultará primero esa duda con el tutor (ya que tiene la visión global de la empresa y cuenta con conocimientos de ITIL) y posteriormente, si realmente es necesario, consultará presencialmente con dicho profesional. 43

44 Si se va realizar un procedimiento que implique a más de tres departamentos, se recabará el visto bueno del tutor. Para ello se consultará con el tutor (por los mismos motivos expuestos anteriormente) y se enviará mediante el correo corporativo una invitación a una reunión a los responsables de esos departamentos. Durante esa reunión se debatirán las ideas para ese procedimiento, realizando al final de la misma un borrador. Tras esta reunión el alumno trabajará en ese procedimiento según lo acordado en la reunión. Una vez redactado, este será revisado por el tutor y enviado mediante el correo corporativo a los responsables de los departamentos implicados para que lo aprueben (pudiéndose realizar otra reunión si fuese necesario). Para realizar los procedimientos técnicos durante la quinta iteración, el alumno dispone de dos máquinas con sistemas operativos Linux. La primera es una Debian 5.0 y la segunda una Red Hat 5.8. El objetivo de estas es poder montar y probar todas las configuraciones de las que luego se realizarán procedimientos. En cuanto a las reuniones con el supervisor, estas se realizarán cuando uno de los dos lo estime oportuno. Para ello se intercambiarán correos utilizando sus cuentas de la universidad indicando los motivos para realizar esa reunión así como los puntos a tratar en las mismas. Además se realizarán copias de seguridad diarias de toda la documentación generada. 44

45 6 Planificación del trabajo El planteamiento de la división del proyecto en iteraciones para aumentar la concurrencia de las tareas hace que la planificación de las iteraciones sea secuencial. De este modo las iteraciones se realizarán una tras otra dada la dependencia que existe entre las mismas. La iteración 5 es la más independiente de todas ellas ya que es totalmente técnica, como se ha comentado la idea es poder utilizarla como colchón en caso de que surja algún imprevisto durante las cuatro primeras iteraciones que son las más dependientes de otras personas. El proyecto dará comienzo a mediados de septiembre y finalizará a mediados de abril con un margen suficiente para poder realizar la presentación antes de la fecha límite de entrega del PFC (12 de Julio 2012). La última semana de diciembre no se avanzará en el proyecto por vacaciones. El ser un proyecto en empresa, se ha firmado un convenio para que las horas de dedicación al proyecto sea equitativa a la dedicación de las prácticas en sí, es decir 4 horas al día. Se ha realizado una planificación en la que se tienen en cuenta los riesgos detectados en el análisis anterior (apartado 4) dejando un margen para las desviaciones en cada iteración. La planificación final es la siguiente: 45

46 Figura 7: Diagrama de Gantt de la planificación del PFC 46

47 No se incluyen en la planificación las reuniones ya que se realizarán a lo largo del proyecto a medida que se vayan detectando las necesidades. No obstante se presentan a continuación las reuniones mínimas necesarias para el proyecto: Nº Roles implicados Motivo de la reunión Iteración 1 Tutor Definición del proyecto. Iteración 1 2 Empresa Presentación del proyecto a los profesionales afectados por el proyecto. 3 Supervisor Presentación del proyecto, indicaciones de pautas. 4 Tutor Seguimiento de la iteración 2 e ideas para fases futuras 5 Tutor Seguimiento del proyecto e ideas para fases futuras Iteración 1 Iteración 1 Iteración 2 Iteración 3 6 Supervisor Seguimiento del proyecto Iteración 4 7 Tutor Reunión de cierre Iteración 6 8 Empresa Presentación de los nuevos procedimientos Iteración 6 9 Supervisor Reunión de cara a la presentación del PFC Iteración 7 10 Supervisor Reunión de cierre del PFC Iteración 8 Tabla 3: Estimación de las reuniones del PFC 47

48

49 7 Desarrollo A continuación se presentan las fases que componen los proyectos de ampliación de la infraestructura definidas en el apartado 3.2. A continuación se definen los flujos de información que deben producirse durante cada una de las fases que se complementarán con los diagramas de flujo y de comunicación del apartado También se presentan en el apartado 12.2 las plantillas para las planificaciones de las fases mediante las cuales se generarán las planificaciones reales de proyectos de ampliación. En los apartados 12.3 y 12.4 se incluyen los formularios y check lists necesarios para la comunicación a lo largo de las fases. Por último, en el apartado 12.6 se incluyen los procedimientos de instalación de los servicios ofrecidos en el catálogo de servicios de Ibermática para máquinas UNIX incluido en el apartado 12.5 necesarios para la ampliación de la infraestructura. 49

50 7.1 Fase 0: Recepción de la información inicial El alcance de esta fase se limita a obtener la información inicial (apartado ) básica de la ampliación de la infraestructura para que el proyecto pueda comenzar. La necesidad de la ampliación de la infraestructura de sistemas y servicios existente se detecta en las reuniones que el responsable del cliente (RSC) mantiene periódicamente con éste. Estas necesidades son fruto del día a día, las incidencias registradas en los sistemas, los análisis provenientes del proceso de gestión de la capacidad o disponibilidad o, en definitiva, fruto de las acciones proactivas inherentes a los procesos propiedad de los servicios gestionados. Se pueden plantear necesidades como la implementación de un nuevo servicio, la necesidad de incorporación de un nuevo servidor para ofrecer un nuevo servicio a los usuarios actuales, la ampliación de la infraestructura actual o incluso la migración de la infraestructura en uso por obsolescencia. A partir del momento en el que se detecta la necesidad, el responsable del cliente (con el apoyo de un comercial y/o un técnico preventa dependiendo de la entidad de dicha necesidad) será el encargado de recopilar la información inicial del proyecto mediante sucesivas reuniones informativas que mantendrá con el cliente. El responsable del cliente debe consultar con el gestor de la capacidad cuál es el estado de la infraestructura actual y las posibilidades de ampliación existentes. De esas reuniones se deberá obtener cierta información relativa al proyecto que dé concreción al mismo y que será la base desde la que se inicia este procedimiento. La información inicial será entregada al grupo responsable del proyecto creado a tal efecto. Este grupo estará integrado por, al menos, un jefe de proyecto y uno o más técnicos en función de las necesidades del proyecto (si el volumen del proyecto fuera muy pequeño ambas figuras pudieran englobarse en un único profesional). Los recursos humanos del proyecto son, a priori, personal de TM. 50

51 7.2 Fase 1: Instalación del Hardware En esta fase el objetivo es dejar el Hardware necesario para la ampliación de la infraestructura preparado para poder instalar ciertos requisitos previos de los servicios a implementar (por ejemplo, el sistema operativo, el software base...). Partimos de la situación planteada al final de la fase anterior, una vez obtenida la información inicial el grupo responsable del proyecto entregará el formulario nº1 (apartado ) al RO OM-CPD. La casuística posible en ese momento es la siguiente: No se aportan máquinas físicas nuevas. Se aportan máquinas físicas nuevas No se aportan máquinas físicas nuevas Si la ejecución del proyecto no requiere un nuevo servidor físico (generalmente, debido al carácter virtual de dicho servidor o, rara vez, por reutilización de servidores existentes), el RO OM-CPD deberá determinar si la infraestructura actual del cliente cuenta con la capacidad suficiente para albergar la nueva máquina virtual con las características indicadas en el formulario nº1. No solamente esto, sino que también debe tener en cuenta que la infraestructura actual no se vea afectada por la reducción de su capacidad remanente. Esto se debe a que en entornos virtuales y de alta disponibilidad siempre se debe dejar un margen de seguridad para los problemas eventuales. Existen otras posibilidades (aunque, como ya se ha indicado anteriormente, menos probables): Si se va a reutilizar una máquina existente ya instalada en el CPD, el RO OM- CPD deberá estudiar si la máquina física antigua cumple con los requisitos mínimos para proceder a la nueva instalación. 51

52 Si se trata de un nuevo servicio, el RO OM-CPD deberá estudiar si la máquina a la cuál se le quiere añadir este servicio tiene capacidad suficiente como para albergar este nuevo servicio sin que ello afecte a los ya instalados. En caso de que la infraestructura no cuente con la capacidad suficiente el RO OM-CPD avisará al grupo del proyecto de la deficiencia. Este aviso lo escalarán al responsable del cliente para que este gestione la ampliación de la capacidad de la máquina en cuestión. Una vez solventada la incidencia, el responsable del cliente avisará al grupo del proyecto de que la máquina en cuestión ya cuenta con la capacidad requerida Se aportan máquinas nuevas Si se aporta un servidor físico (tanto si el nuevo servicio debe ir instalado sobre una máquina física como si debe ir instalado sobre una máquina virtual), en el formulario nº1 se indican los requisitos (consumo eléctrico, espacio necesario, etc...) de la nueva máquina. Es responsabilidad del RO OM-CPD cerciorarse de que alguno de los racks de la infraestructura del cliente cuenta con la capacidad física y de consumo eléctrico necesaria para albergar esa máquina sin afectar a la estabilidad de la infraestructura ya existente. En caso de que la infraestructura no cuente con la capacidad física suficiente el RO OM-CPD avisará al grupo del proyecto de la deficiencia. Este aviso lo escalarán al responsable del cliente para que este gestione la ampliación de la capacidad de la infraestructura en cuestión. Una vez solventada la incidencia, el responsable del cliente avisará al grupo del proyecto de que dicha infraestructura cuenta con la capacidad requerida. Dependiendo de la deficiencia el grupo del proyecto podrá seguir adelante con la instalación de la infraestructura, no obstante es imprescindible para dar por concluida la fase 1 que todas las deficiencias hayan ido solventadas. Una vez recibido el material (generalmente se tiene constancia de ello por un 52

53 del responsable del CPD 2 ), el grupo del proyecto deberá comprobar que todos los elementos mencionados en el albarán han sido físicamente entregados y que el albarán de entrega coincide con el pedido realizado por el responsable del cliente (incluido en la información inicial ). Si se detectase que falta algún elemento, se notificará al responsable del proyecto. Una vez estén todos los elementos disponibles, se procederá al montaje en el correspondiente rack del nuevo equipamiento. A su vez, el grupo del proyecto deberá trabajar en el montaje de los switches y del cableado de comunicaciones (si procede) con la información obtenida de la información inicial Actualización de la CMDB Una vez preparada la instalación, el grupo del proyecto procederá a la gestión de reserva de dirección IP del servicio con el departamento de OM-COM (o varias, dependiendo del número de servicios a instalar). Para ello se debe utilizar el formulario nº4 (apartado ). Una vez completado el formulario OM-COM lo reenviará al grupo del proyecto. En caso de que se vaya a instalar un nuevo servicio en una máquina ya existente, el RO OM-CPD actualizará la CMDB con la información del formulario nº1. Si la nueva máquina es virtual, el grupo del proyecto completará con la información requerida el formulario nº2 (apartado ) y lo enviará al RO OM-CPD para que se encargue de actualizar la CMDB Si se ha instalado una nueva máquina, el grupo del proyecto verificará mediante el check list fase 1 (apartado ) que la instalación del Hardware está completada. Tras esto enviará el formulario nº3 (apartado ), con la información de todos los elementos instalados y la electrónica de red, al RO OM-CPD para que se encargue de actualizar la CMDB. 2 La gestión del CPD de clientes es responsabilidad de una empresa del grupo Ibermática (concretamente, Servimática). La relación de CSN con esta empresa es estrictamente profesional comportándose a todos los efectos como una empresa distinta. 53

54 Cuando el RO OM-CPD se haya encargado de solventar las deficiencias detectadas a lo largo de esta fase, haya reservado los recursos (en caso de que no se aporten máquinas nuevas) y disponga de la información relativa a los cambios que se han realizado en la infraestructura mediante los formularios recibidos del grupo de proyecto, actualizará la CMDB. En este punto, tras comunicar al grupo del proyecto que la infraestructura se encuentra completada e inventariada damos por finalizada la fase 1. 54

55 7.3 Fase 2: Instalación del Sistema Operativo El objetivo de esta fase es instalar sobre la nueva máquina un sistema operativo y herramientas para la administración remota (ya que hasta ahora, en general, todas las tareas a realizar sobre el servidor requieren de intervención in situ en el CPD en el que se encuentra ubicada la máquina). Una vez se notifique al grupo del proyecto que el Hardware ya está listo para albergar el nuevo servicio y que la información generada durante la fase 1 ha sido correctamente inventariada, procederá a instalar el SO (Sistema Operativo). La elección del SO vendrá facilitada por el responsable del cliente o el responsable del proyecto en la información inicial. En este documento se proveerá, así mismo, de la licencia necesaria para su activación (en su defecto, dicho código será facilitado por el responsable del proyecto mediante el formulario nº5 (apartado )). Durante el proceso de instalación del SO el técnico solicitará el nombre de la máquina e información de red, esta información está presente en el formulario nº2 o el formulario nº3 según proceda. Para configurar la red en la máquina ver el procedimiento de configuración de red (apartado ) Instalación y configuración de servicios iniciales Actualizaciones En caso de que la instalación del sistema operativo no hubiera accedido a un repositorio de software actualizado (generalmente, a través de Internet) se deberá poner al día el sistema respecto a los parches de seguridad. Aunque esto pudiera parecer trivial es una práctica en extremo poco frecuentada y, en ocasiones, incluso evitada por las exigencias de ciertos fabricantes de software en cuanto a las versiones soportadas por sus productos. Para ello consultar el procedimiento de actualización del sistema operativo (apartado ). 55

56 Creación de un usuario de acceso Para que las diferentes personas implicadas en el proyecto puedan acceder a la nueva máquina y empezar a trabajar en ella se creará un usuario en dicha máquina. Este usuario no tendrá permisos de administrador por seguridad (ver procedimiento de creación de usuarios (apartado )) Acceso remoto Los fabricantes de servidores suelen proporcionar herramientas para la gestión remota de los servidores y poder realizar de este modo reinicios, apagados o encendidos sin tener que desplazarse al CPD. Estas herramientas vienen muy bien en caso de catástrofes como fallo del sistema operativo o pérdida de conectividad ya que permiten acceder a la máquina y realizar las labores necesarias para recuperar un funcionamiento normal (dependiendo, claro está, del nivel de criticidad del evento de contingencia). Se podrían utilizar estas herramientas para el acceso remoto a la máquina para las gestiones del día a día no obstante no es lo idóneo ya que por lo general suelen ser lentas y poco amigables por ello se instalarán sobre el sistema operativo aplicaciones más ágiles e intuitivas (ver procedimiento de instalación de SSH (apartado )) Verificación del software instalado Tras haber instalado los servicios iniciales el grupo del proyecto debe comprobar que la configuración es correcta y que funcionan como se espera, en caso contrario se debe cambiar la configuración del servicio hasta que tenga un comportamiento correcto Actualización de la CMDB Una vez terminada la instalación de los servicios iniciales, el grupo del proyecto, deberá actualizar en la documentación del proyecto los servicios instalados en las máquinas. 56

57 Así mismo se debe enviar al RO OM-CPD el formulario nº5 indicando en él los números de serie de las licencias utilizadas y el inventario de las máquinas actualizadas a lo largo de esta fase mediante el formulario nº6 (apartado ) para que se actualice la CMDB. 57

58 7.4 Fase 3: Instalación de los servicios El objetivo de esta fase es instalar los servicios requeridos por el cliente en la infraestructura habilitada para ello y referida en innumerables ocasiones en las fases anteriores del proyecto. Una vez instalados los servicios iniciales, se tiene una base sólida y fiable sobre la cuál se pueden empezar a instalar los servicios acordados con el cliente. La información minuciosa de los servicios a instalar será proporcionada en el documento de información inicial actualizado por el responsable del cliente mediante entrevistas posteriores a la puesta en marcha del nuevo proyecto Instalación de los servicios Con la instalación del sistema operativo y de los servicios iniciales acabada, el grupo del proyecto tras obtener de la información inicial el detalle de los servicios necesarios en el nuevo servidor instalará dichos servicios. El catálogo de servicios UNIX (apartado 12.5) contiene el listado de los servicios ofrecidos actualmente por Ibermática. Se adjuntan los procedimientos para la instalación, configuración y monitorización de los servicios que se listan en el catálogo. En caso de que la instalación de algún servicio requiera de una licencia, esta deberá ser proporcionada por el responsable del cliente mediante la remisión del formulario nº5. Aunque en el catálogo se mencionen herramientas de monitorización estas son instaladas por los técnicos de OM en la fase Configuración del software instalado Una vez instalados los servicios, el grupo del proyecto debe configurarlos para adaptarlos al uso específico que se les quiera dar en la infraestructura del cliente. Para realizar estas personalizaciones se debe consultar la información en el documento de información inicial o en la documentación del proyecto (recuérdese que el documento de información inicial podía ser un pliego con las bases de la presentación a concurso 58

59 del servicio demandado) Verificación del software instalado Tras haber instalado los servicios se debe comprobar que la configuración es correcta y que los servicios funcionan como se espera, en caso contrario se debe cambiar la configuración del servicio hasta que se observe un comportamiento correcto Actualización de la CMDB Una vez instalados todos los servicios se deberá almacenar esa información en la documentación del proyecto mantenida por el grupo del proyecto. Así mismo se debe enviar al RO OM-CPD el formulario nº5 indicando en él los números de serie de las licencias utilizadas y el inventario de las máquinas actualizadas a lo largo de esta fase mediante el formulario nº6 para que se actualice la CMDB. 59

60 7.5 Fase 4: Pruebas de la nueva infraestructura El objetivo de esta fase es realizar distintas pruebas sobre los nuevos servicios instalados para comprobar que los servicios funcionarán correctamente cuando estén soportando la carga de trabajo para la que fueron inicialmente diseñados. Para ello se seguirá un modelo simple y eficaz para controlar la calidad en entornos productivos adaptado a la fase de prueba actual, el ciclo de Deming. También se conoce como PDCA, cuyas siglas son el acrónimo de Plan, Do, Check, Act (Planificar, Realizar, Comprobar, Actuar). Figura 8: Ciclo de Deming Definición de las pruebas Una vez acabada la instalación de los servicios se debe definir una batería de pruebas a realizar sobre la nueva infraestructura. El objetivo de la misma es detectar (si existieran) comportamientos anómalos o fallos en los servicios al someterlos a dicha batería de pruebas. Las diferentes pruebas que pueden componer esta batería es dependiente de una casuística excesivamente amplia como para poder, de antemano, dilucidar el ámbito concreto de dicha batería. Es decir, la misma es por su variedad muy dependiente del proyecto que se está llevando a cabo y de los servicios implicados, tanto que resulta 60

61 imposible definir un procedimiento a seguir en estos casos. Sin embargo es necesario que estas pruebas se lleven a cabo, por lo que el grupo del proyecto deberá de elaborar un documento detallando las pruebas a realizar utilizando como plantilla el documento de análisis de rendimiento del servicio (apartado ). Cabe destacar que la batería de pruebas debe contemplar todas y cada una de las partes de una infraestructura de manera individual sin descuidar el funcionamiento de la infraestructura en su conjunto Realización de las pruebas Tras haber definido las pruebas que se deben llevar a cabo, el grupo del proyecto deberá realizarlas. Los resultados de las mismas deberán ser anotados en el documento de análisis de rendimiento del servicio Análisis de los resultados Al finalizar la ejecución de la batería de pruebas, el grupo del proyecto deberá elaborar un documento recogiendo la información generada a lo largo de esta fase. En ese documento se detallan las pruebas realizadas, los resultados obtenidos y las acciones correctivas que se deben llevar a cabo (en caso de que esto fuera necesario). Puede ocurrir que el grupo del proyecto decida repetir el ciclo de Deming desde la definición de las pruebas por alguna razón: Se detecta que el conjunto de pruebas no cubre la casuística total posible en el escenario del servicio. Se han quedado algunas partes de la infraestructura sin analizar. Es conveniente profundizar algunas pruebas por el resultado obtenido en la batería de pruebas Corrección de los fallos En caso de que se hubieran detectado errores a lo largo de la fase de pruebas, se deberán llevar a cabo las acciones correctivas detalladas en el documento de análisis de rendimiento del servicio. Una vez implantadas las modificaciones se debe comenzar 61

62 otra iteración del ciclo de Deming; es decir, volver al apartado Definición de las pruebas para verificar que los cambios han solucionado los problemas detectados anteriormente Actualizar la documentación del proyecto Una vez realizadas todas pruebas que estaban definidas en el documento de análisis de rendimiento del servicio, el grupo del proyecto debe actualizar la documentación del proyecto existente adjuntando el documento de análisis de rendimiento del servicio así como el informe de pruebas (apartado ) en el cuál puede hacer algunas peticiones/recomendaciones al responsable del cliente para que se mejore la infraestructura actual porque se ha detectado alguna carencia o error grave. 62

63 7.6 Fase 5: Traspaso del servicio El objetivo final de esta fase es planificar el traspaso de los servicios necesarios para el cliente al grupo de servicios gestionados encargado de realizar la operación de los mismos. Antes de que los servidores, y servicios relacionados, pasen a producción se deben instalar ciertas herramientas de monitorización que facilitarán el día a día de los servicios gestionados. También se deberán crear circuitos de notificaciones en caso de incidencias, procedimiento de copias de seguridad, plan de contingencia, ventanas de intervención, etc... Tras haber concluido la ampliación de la nueva infraestructura y comprobado que las máquinas están listas para dar el salto a producción se debe generar documentación relativa al proyecto para darlo por finalizado (realmente la misma se tiene que generar a lo largo de todo el desarrollo del proyecto). Una vez terminada la fase de instalación, la gestión de la infraestructura pasa a mano de los servicios gestionados. Con el objetivo de que la transición no sea traumática y se realice de manera organizada se han generado una serie de procedimientos y check list con el objetivo de facilitar su supervisión Recepcionar la información del proyecto Siguiendo el check list fase 5 (apartado ) el ROM debe encargarse de comprobar y reclamar al grupo de proyecto la información ausente necesaria a la transición del servicio. Para facilitar esta tarea, detectar la carencia de documentación o necesidad de más documentación acerca de algún punto en concreto, se debe organizar una reunión de traspaso de conocimiento durante la cual el grupo encargado del proyecto explicará a los departamentos implicados (SD y OM) en que consiste la nueva infraestructura. Para ello se comentarán todos los servicios que se han instalado, su funcionamiento y principales puntos de fallo a tener en cuenta. 63

64 7.6.2 Puesta en marcha de la monitorización El día a día de los servicios gestionados necesita que las máquinas de las infraestructuras estén monitorizadas. En CSN, la monitorización se realiza a tres niveles diferenciados: Hardware, Sistema Operativo y Servicios. En la siguiente figura se aprecian los diferentes tipos de monitorización. Figura 9: Tipos de monitorización utilizados en CSN Las distintas monitorizaciones requieren de herramientas específicas cuya utilidad se detalla a continuación Monitorización Hardware Algunos fabricantes proporcionan herramientas de monitorización del Hardware. Estas herramientas monitorizan los componentes físicos de una infraestructura gracias a una máquina dedicada a preguntar continuamente a todos los elementos conectados a la red (servidores, cabinas de fibra, switches de fibra, etc...) por el estado de algunos de sus componentes mediante el protocolo SNMP. En cuanto se detecte que algún componente ha fallado, automáticamente se reportará al soporte técnico del fabricante para que puedan analizar lo que ha ocurrido y de este modo solucionar problemas que, 64

65 posiblemente, todavía no se hubieran percibido de manera proactiva. Algunas herramientas de este tipo son: Compaq Insight Manager, HP Insight Remote Support, Dell OpenManage e IBM Director. En Ibermática, dado que se trabaja mayoritariamente con HP, la herramienta que se utiliza y configura es IRS (ver procedimiento instalación de IRS (apartado )). Figura 10: Funcionamiento de IRS Monitorización de Sistema Operativo La segunda capa de monitorización es el sistema operativo. El objetivo de ésta es por un lado comprobar que la máquina está encendida y por otro lado tener un control sobre la capacidad de la misma. Para verificar que la máquina está operativa, una máquina central encargada de la monitorización realiza un ping cada minuto. Para controlar la capacidad de la máquina, se comprueban el porcentaje de uso de CPU y porcentaje de ocupación de los sistemas de ficheros cada cierto tiempo mediante SNMP. De esta manera se pretende obtener información de manera proactiva para poder tomar medidas correctivas antes de que se vean afectados los servicios (ver procedimiento instalación de SNMP (apartado )). 65

66 Monitorización SW La tercera y última capa de monitorización se encarga de verificar el correcto funcionamiento de las aplicaciones instaladas en la máquina. Para ello se utiliza en CSN una herramienta de software libre llamada Nagios. El funcionamiento es el mismo que en las monitorizaciones anteriores, existe un servidor central que encuesta a diferentes máquinas acerca de los servicios instanciados en éstas (ver procedimiento instalación de Nagios (apartado )). En caso de producirse una alerta durante la ejecución de alguno de los chequeos de las tres capas, el departamento de OM-Explotación abrirá la incidencia a quien proceda en función del circuito de alertas definido a tal efecto Generación de estadísticas En el caso de que se detecte algún comportamiento anómalo es importante tener información de como se encuentra la máquina en ese momento, (incluso podría ser interesante estudiar el comportamiento a posteriori) por ello se instalará en la máquinas UNIX una herramienta capaz de generar y almacenar las estadísticas del comportamiento de la máquina (ver procedimiento generación de estadísticas (apartado )) Apertura de peticiones de monitorización Tras haber recibido la información del proyecto y haber instalado las herramientas de monitorización en la infraestructura, los técnicos de OM deberán ir a abriendo peticiones a OM-Explotación para que se comience a monitorizar la nueva infraestructura. Para este trámite se debe completar el formulario cambios en la monitorización (apartado ). Una vez añadidos a la monitorización los diferentes elementos de la infraestructura, el departamento OM-Explotación remitirá un mensaje a los técnicos del departamento solicitante señalando que se ha procedido a añadir los nuevos chequeos. 66

67 Al recibir la confirmación de que la monitorización ya está activada y se ha puesto en marcha la generación de estadísticas, el ROM confirmará al grupo del proyecto que se han cumplido los plazos de puesta en marcha del servicio. En caso contrario se debería de haber señalado con antelación que no se va a poder cumplir con el plazo de entrega del proyecto y las razones de estos retrasos (generalmente las planificaciones de los proyectos vienen con un margen de error para que no ocurran este tipo de situaciones). A partir de aquí el proyecto deja de existir como tal, pasando a ser un servicio más dentro del día a día de los servicios gestionados. También se disuelve el grupo del proyecto volviendo los técnicos que lo forman a sus labores diarias. 67

68

69 8 Seguimiento y control del proyecto 8.1 Planificación Se ha realizado una tabla en la que se muestran las desviaciones en la planificación detectadas a lo largo del proyecto: Iteración Horas Estimadas Horas Invertidas Desviación Motivo 1 40h 45h +5h Dificultades en la autoformación 2 45h 62h +17h Subestimación de la fase h 80h +15h Reestructuración de las fases 1 y 2, y por lo tanto demasiadas implicaciones. 4 65h 35h -30h Sobreestimación de esta iteración 5 60h 85h +25h Carencias técnicas para realizar algunos procedimientos. 6 30h 30h 0h 7 36h 45h +9h Subestimación de la maquetación. 8 25h 27h +2h Más cambios de lo estimado Total: 366h 409h +43h Tabla 4: Seguimiento de las horas invertidas En total se ha cometido un error en la estimación total del 11,7% lo cuál es bastante significativo. No obstante se han anotado los errores y analizado el porqué de los mismos para evitar cometerlos en el futuro. 69

70 Se han tenido que realizar dos reuniones más de las previstas que se detallan en la siguiente tabla: Nº Roles implicados Motivo de la reunión Fecha Duración 1 Tutor Definición del proyecto. 15/09/11 4 horas 2 Empresa Presentación del proyecto a los profesionales afectados por el proyecto. 3 Supervisor Presentación del proyecto, indicaciones de pautas. 4 Tutor Seguimiento de la iteración 2 e ideas para fases futuras 24/10/11 2 horas 27/10/11 1 hora 01/11/11 2 horas 5 Supervisor Seguimiento del proyecto 22/11/11 2 horas 6 Tutor Seguimiento del proyecto e ideas para fases futuras 21/ horas 7 Supervisor Seguimiento del proyecto 28/02/12 2 horas 8 Tutor Ayuda en la realización de algunos procedimientos 22/03/12 6 horas 9 Tutor Reunión de cierre 28/05/12 2 horas 10 Supervisor Reunión de cierre del proyecto 01/06/12 2 horas 11 Empresa Presentación de los nuevos procedimientos 12 Supervisor Reunión de cara a la presentación del PFC 18/06/12 2 horas 27/06/12 2 horas 13 Supervisor Reunión de cierre del PFC 8/06/12 3 horas Total: 32 horas Tabla 5: Reuniones del PFC Se han sobrepasado las horas planificadas para las reuniones en 2 horas. Lo cuál teniendo en cuenta que se han realizado tres reuniones más de las previstas entra dentro de un margen razonable. 70

71 del proyecto: Por lo tanto al final se han dedicado al proyecto 441 horas. A continuación se detalla el número total de horas invertido en cada elemento Elemento Horas Estimadas Horas Reales Formación* 20h 32h Introducción 41h 48h Fase 1 53h 69h Fase 2 38h 44h Fase 3 103h 115h Fase 4 48h 32h Fase 5 23h 20h Documentación del PFC* 40h 49h Reuniones* 30h 32h Total 396h 441h Tabla 6: Dedicación a cada elemento del PFC Del análisis de la tabla 6 se puede concluir que ha habido un error en la planificación de las dedicaciones de los elementos. No obstante se observa que las desviaciones en las fase 4 y fase 5 son negativas. Lo cuál se debe a que al haber invertido más tiempo del planificado en las fases anteriores quedan más definidas estas fases facilitando su redacción. 71

72 Iteración En la siguiente tabla se muestra la desviación de fechas del proyecto, Fechas Estimadas Fechas reales Desviación 1 19/09-07/10 19/09-21/10 +2 semanas 2 10/10-28/10 24/10-11/ /10-25/11 14/11-23/12 +2 semanas 4 28/11-23/12 02/01-20/01-1 semana 5 02/01-10/02 23/01-27/04 +8 semanas 6 13/02-02/03 30/04-22/ /03-26/03 06/06-27/ /03-10/04 28/06-11/07 Total: 19/09-10/04 19/09-11/ semanas Tabla 7: Desviaciones del PFC Se puede apreciar que el proyecto sufrió un gran retraso en la quinta iteración, este se debe (al igual que los de las iteraciones 1 y 3 aunque en menor medida) a que la compaginación entre trabajo y proyecto no ha sido todo lo buena que debiera de haber sido. Los motivos se explicarán más adelante en la parte de riesgos encontrados. Por último se debe decir que aunque en algunas ocasiones se aprovechó el colchón de la iteración 5 fue algo puntual que no hace falta reseñar. 72

73 8.2 Metodología La metodología utilizada para la formación ha resultado ser eficiente ya que ahora el alumno cuenta con una buena base de conocimientos en ITL, que le ha permitido llevar a cabo el proyecto e incluso participar en labores de transición en la empresa ajenas a este proyecto. Además logró la certificación interna de ITIL de Ibermática. Las lluvias de ideas aunque solo se realizaron dos veces resultaron ser muy dinámica y eficientes, en parte gracias a la herramienta utilizada ya que facilita mucho este tipo de tareas. La utilización de un repositorio documental común ha sido todo un acierto en este proyecto ya que ha permitido llevar adelante el proyecto en momentos en los que estaba muy en peligro. Se ha convertido en una herramienta imprescindible ya que proporcionaba la dinamicidad suficiente para que tanto el tutor como el alumno trabajaran desde diferentes lugares en cuanto tuvieran un rato disponible para ello. A parte el hecho de revisar la documentación y debatir ha sido muy enriquecedor y le ha dado al proyecto una calidad que de otra forma no hubiera obtenido. El hecho consultar con los responsables de departamentos implicados a la hora de realizar algunos procedimientos ha sido muy positivo ya que ha permitido personalizar tanto el proyecto que no va a hacer casi falta una fase de implantación. Esto ha sido posible gracias al diálogo constante que ha permitido escuchar las opiniones de todos ellos y elaborar de manera conjunta los procedimientos. Es decir, el alumno no ha redactado un procedimiento para luego implantarlo sino que ha dado unos esbozos para generar entre todos el procedimiento más adecuado para cada fase. La disposición de dos máquina virtuales ha resultado muy útil pero se ha necesitado una tercera máquina para realizar algunos procedimientos. Además en algunos casos las máquinas han quedado inutilizables tras ciertas pruebas, teniendo que reinstalarlas con lo consecuente pérdida de tiempo. 73

74 8.3 Problemas Problemas previstos En algunos momentos ha sido complicado llevar a cabo el proyecto por falta de experiencia en el entorno organizativo empresarial tanto por carencias de conocimiento como por motivación. No obstante el haber podido contar con el tutor y el Supervisor ha sido de incalculable valor para llevar este proyecto a buen puerto. El hecho de que haya tres personas implicadas en este proyecto (aunque con diferente grado de implicación) ha dificultado de gran manera el avance del proyecto en algunas ocasiones ya que no se puede contar con que todos los miembros tengan una dedicación absoluta en el mismo. Esto implica dedicación al proyecto a deshoras, dificultades para programar reuniones y en definitiva dificultades organizativas. La compaginación entre las prácticas en empresa y la realización del PFC no ha sido la idónea para el avance del PFC. Estaba estipulado que la dedicación al trabajo debía de ser equitativa a la dedicación al PFC pero la balanza se ha inclinado a favor del trabajo llegando a dejar de lado por completo el PFC. Esto se debe a que resulta mucho más atractiva la labor técnica como administrador de sistemas que la elaboración de la documentación del PFC. De hecho por culpa de este error el proyecto sufrió un retraso considerable en la quinta iteración. En ese periodo la dedicación se centró más en el trabajo de la empresa que en el proyecto y como consecuencia el PFC se retrasó ocho semanas más (llevaba ya cuatro semanas de retraso). Esto ha hecho que se tenga que andar con prisas al final de proyecto y tener que centrarse más en él que en la empresa. 74

75 8.3.2 Problemas Aunque se han definido los objetivos de cada iteración en porcentajes de desarrollo de las fases se ha visto que esta no es una medida fiable ya que no es tangible y que puede variar en cuestión de días (p.e.: este caso de uso no pertenece a esta fase sino a esta otra). Personalmente, me ha costado mucho ver el alcance real del proyecto. No tenía claras las ideas ni los objetivos del proyecto. Esta carencia se ha ido resolviendo a medida que avanzaba el proyecto hasta obtener una visión clara y global de todo el proyecto. Todavía no tengo claro si se ha debido a falta de visión del proyecto por no tener las ideas claras, por miedo al proyecto tanto por lo que implica para mi futuro como el volumen del mismo o por que me siento más cómodo en el ámbito técnico que organizativo. 75

76

77 9 Conclusiones Se ha implantado correctamente el procedimiento de ampliación de una infraestructura de sistemas y servicios en Ibermática. Tras la reunión de presentación de los nuevos procedimientos a los profesionales afectados por este proyecto se ha comenzado a utilizar. Dada la reciente realización de dicha reunión el proyecto de ampliación que se está llevando a cabo en este momento se encuentra en la fase 1 del proyecto pero de momento las valoraciones son muy positivas. Las plantillas generadas en la herramienta de gestión de proyectos corporativa han resultado ser de gran utilidad para los profesionales. Además los formularios facilitan el entendimiento entre los diferentes departamentos ya que cada uno de los dos extremos sabe que es lo que el otro necesita de él. Por último los diagramas han causado grandes sensaciones ya que proporcionan una visión clara y concisa de lo que debe hacer cada cuál en cada fase. En conclusión el proyecto está resultando útil para la empresa a la espera de un periodo de evaluación de mayor. 9.1 Conclusiones personales Gracias a la realización de este proyecto ha sido posible superar los miedos iniciales ante algo desconocido y verificar que con esfuerzo, paciencia y dejándose ayudar se puede conseguir realizar un proyecto de cierta envergadura y dificultades iniciales. También ha servido para conocer algunas de las funcionalidades del mundo Linux. Algunas ya eran conocidas gracias a haber cursado la asignatura Administración de Sistemas pero se habían estudiado desde un punto de vista más teórico, sin embargo lo que se ha hecho aquí es implantarlas en entornos productivos lo cuál es más motivador. 77

78 No obstante el haber dispuesto de únicamente dos máquinas (y en ocasiones tres) para realizar los procedimientos de los servicios ha resultado ser insuficiente, no por el número sino porque no se han utilizado las ventajas que ofrece la virtualización desde el principio. Cada vez que una máquina queda inutilizable y no se podía reparar, debía ser reinstalada desde cero. Esto llegó a consumir un tiempo muy valioso hasta que se decidió utilizar las plantillas. Una plantilla es una máquina virtual normal pero gracias a la cuál se pueden desplegar clones muy rápidamente, esto ha hecho que ya no se pierda más tiempo en estos casos y sin duda será utilizado en el futuro. Se debe mencionar también lo útil que ha sido la realización de este proyecto para conocer más a fondo el entorno empresarial y las gestiones que se deben realizar para facilitar la tarea de los profesionales aumentando así la productividad. Esta información podría haber sido obtenida gracias a la experiencia tras algunos años trabajando pero lo que se ha recibido ha sido un curso express que ha facilitado la vida al alumno durante el periodo en el que ha estado de prácticas en Ibermática, comprender los cambios que se están produciendo y no estar perdido ante ellos como les ocurre a algunos profesionales más cuadriculados. Otra conclusión a la que se ha llegado, es que el haber realizado un estudio previo de la metodología que requería este proyecto ha sido de gran ayuda y de hecho ha resultado ser una metodología muy ágil y práctica que será utilizada sin lugar a dudas en proyectos posteriores de características similares. Por último en la fase final de este proyecto, cuando la transición de la estructura estaba bastante avanzada, se han comenzado a ver las ventajas reales de ITIL ya que aunque la transición ha sido complicada en algunas fases la productividad a aumentado y se espera que sigo haciéndolo a medida que los técnicos se vayan adaptando a la nuevo metodología a cumplir y sus procedimientos. 78

79 10 Bibliografía Ibermática, Apuntes para la certificación interna de ITILv3. Consultec & IberExpert, Apuntes para la certificación oficial de ITILv3. Evi Nemeth, Garth Snyder, Trent R. Hein, Ben Whaley (2010), UNIX and Linux System Administration Handbook (4th Edition). Hewlett-Packard (2012), HP Insight Remote Support, Customer presentation 79

80

81 11 Glosario CMDB: Base de datos de la de la Gestión de la configuración en la que se incluye información relativa a la infraestructura. CPD: Centro de Procesamiento de Datos. Lugar/Edificio en el que se almacenan los elementos físicos de la infraestructura con una condiciones de temperatura y humedad controladas. El CPD garantiza una redundancia de todos sus elementos de manera que ofrece unas muy altas garantías de consecución de altos niveles de disponibilidad y contingencia. Rack: Un rack es un armario metálico destinado a alojar equipamiento informático en un CPD. RO OM-CPD: Responsable Operativo de OM-CPD. Es el responsable del departamento OM-CPD. Su labor incluye, entre otras, la organización del trabajo del departamento y el mantenimiento de la CMDB y los planes de contingencia. ROM: Referente OM del cliente. Es el técnico de OM encargado de elaborar los informes mensuales en el que se le informa de las incidencias y la evolución de la infraestructura de un determinado cliente. Este profesional tiene la visión técnica global de los servicios ofrecidos al cliente. RSC: Responsable del Servicio al Cliente. Representa al servicio gestionado en el cliente de su responsabilidad. Su orientación es comercial, no técnica. Servicios gestionados: Conjunto de técnicos de SD y OM que se encargan de llevar el día a día de las infraestructuras de los clientes. Deben resolver incidencias, atender las peticiones y resolver de manera proactiva los problemas en las infraestructuras. SLA: Acuerdos a Nivel de Servicio. Acuerdo escrito entre el proveedor y un cliente en el que se especifica los detalles del servicio que será provisto (disponibilidad, tiempo de respuesta, coste, seguridad, etc...). 81

82

83 12 Anexo En este apartado se incluyen documentos y gráficos que complementan el proyecto llevado a cabo pero que no se incluyen en el apartado de desarrollo ya que su función es la de complementar y facilitar la comprensión de los explicado en dicho apartado Diagramas de las fases Para cada una de las fases que componen este proyecto se han generado un diagrama de flujo y un diagrama de comunicaciones. El primero especifica quien se tiene que encargar de las tareas que componen cada fase y el segundo especifica las interacciones que deben realizarse en esa fase. 83

84 Figura 11: Diagrama de flujo de la fase 1 84

85 Figura 12: Diagrama de comunicaciones de la fase 1 85

86 Figura 13: Diagrama de flujo de la fase 2 86

87 Figura 14: Diagrama de comunicaciones de la fase 2 87

88 Figura 15: Diagrama de flujo de la fase 3 88

89 Figura 16: Diagrama de comunicaciones de la fase 3 89

90 Figura 17: Diagrama de flujo de la fase 4 90

91 Figura 18: Diagrama de comunicaciones de la fase 4 91

92 Figura 19: Diagrama de flujo de la fase 5 92

93 Figura 20: Diagrama de comunicaciones de la fase 5 93

94 12.2 Plantillas Para cada una de las fases que componen este proyecto se han generado una plantilla de tareas y un diagrama de Gantt en la herramienta corporativa de gestión de proyectos (dotproject). La idea es que cuando los miembros de TM tengan que realizar la ampliación de la infraestructura accedan a esta plantilla y se basen en ella para generar la planificación real del proyecto. Figura 21: Plantilla de tareas para la fase 1 94

95 Figura 22: Plantilla de Gantt para la fase 1 95

96 Figura 23: Plantilla de tareas para la fase 2 Figura 24: Plantilla de Gantt para la fase 2 96

97 Figura 25: Plantilla de tareas para la fase 3 Figura 26: Plantilla de Gantt para la fase 3 97

98 Figura 27: Plantilla de tareas para la fase 4 Figura 28: Plantilla de Gantt para la fase 4 98

99 Figura 29: Plantilla de tareas para la fase 5 Figura 30: Plantilla de Gantt para la fase 5 99

100 12.3 Formularios Se presentan a continuación los formularios que se han diseñado para las diferentes fases de la ampliación de la infraestructura. La información de esos debe ser completada y entregada según los diagramas de comunicaciones definidos en el apartado Información inicial La información recogida del cliente deberá hacer mención, al menos, a (el texto en cursiva ha de ser completado): Información relativa a: Descripción del proyecto Descripción exhaustiva del proyecto. Esta información puede ser ofrecida mediante pliego de concurso o, en su defecto, documento de requerimientos del servicio ofrecido por el cliente Servidores Esta información podrá ser ofrecida mediante albarán del fabricante Electrónica de red Esta información podrá ser ofrecida mediante albarán del fabricante aunque también es necesario aportar un esquema de red. Otros elementos Esta información podrá ser ofrecida mediante albarán del fabricante Descripción detallada de servicios: Servicio SLAs Ventana de intervención Copias de seguridad de datos Criticidad Referencia al servicio Porcentaje de disponibilidad Horario disponible para intervenciones planificadas Copia de qué y cuándo Sí/No 100

101 Descripción funcional de los elementos: Función del negocio Servicios (servidores) implicados Correlación de servicios Referencia a la función Lista de servicios (servidores) Dependencia de servicios (servidores) en el arranque/parada de elementos Información adicional: Extracción al exterior de copias de seguridad de datos Elementos involucrados Periodicidad Cifrado de datos Contingencia Sí/No Detección de información involucrada Diaria/Semanal/Mensual Sí/No Existencia de planes de contingencia Información administrativa: Contratos de soporte Licencias Elementos software Referencias a éstos Referencias a éstas Referencias electrónicas a la ubicación del software necesario para su descarga o medios físicos para ello En caso de que varios servicios concurran en un mismo servidor la ventana de intervención a aplicar corresponde a la ventana más restrictiva de todos los servicios contenidos en dicho servidor. En definitiva, se reportará cualquier otra información que estuviera disponible y fuera pertinente para el servicio gestionado de toda o parte de la infraestructura del cliente. 101

102 Formulario nº1 Cliente: Nueva Infraestructura: Potencia consumida 1 :...W Número de fuentes de alimentación 2... Almacenamiento necesario 3 :...GB Medidas 4 :...U Infraestructura existente: Nueva máquina virtual: Almacenamiento necesario:...gb Memoria RAM necesaria:...gb Número de procesadores necesarios:... Nuevo Servicio: Nombre del servicio: Descripción del servicio: Requisitos del servicio: 1 Consumo de potencia aproximado de la solución. 2 Si el pedido incluye servidores y un nuevo rack para contenerlos no será necesario ya que se dispondrá de tomas de corriente suficientes. En caso contrario especificarlo. 3 En caso de que el nuevo servidor requiera de almacenamiento compartido. Si únicamente requiere de almacenamiento local no especificarlo. 4 Al igual que en el caso de las fuentes de alimentación. En caso contrario, especificar el número de U s en el rack que ocupará el servidor. 102

103 Formulario nº2 Infraestructura existente: Nombre de la máquina:... Cluster:... Funcionalidad de la máquina:... Persona responsable:... Correo electrónico:... Teléfono:... Departamento:... Dirección IP asociada:... Puerta de enlace:... Segmento de Red:... Número y tamaño de discos duros:...unidades de...gb...unidades de...gb...unidades de...gb Memoria RAM:......GB Número de procesadores:... Asociación a Pool de Recursos 1 :... 1 Indicar la criticidad de la máquina para automatizar el arranque de la misma en caso de desastre. 103

104 Formulario nº3 Nueva Infraestructura: Nombre del servidor:... Modelo:... Número de Serie:... Medidas:...U Identificación del Rack... CPD:... Dirección IP asociada:... Puerta de enlace:... Persona responsable:... Correo electrónico:... Teléfono:... Departamento:... Dirección IP-gestión 1 :... Puerta de enlace1:... Características del servidor: Número de Serie del procesador...cantidad... Número de Serie de RAM...Cantidad... Capacidad...GB Número de Serie de RAM...Cantidad... Capacidad...GB Número de Serie de RAM...Cantidad... Capacidad...GB Número de Serie de HDD...Cantidad... Capacidad...GB Número de Serie de HDD...Cantidad... Capacidad...GB Número de Serie de HDD...Cantidad... Capacidad...GB Nombre del Proyecto:... Responsable del Proyecto:... 1 Únicamente en caso de que el servidor cuente con la funcionalidad de gestión remota. 104

105 Información del cableado de comunicaciones: La nomenclatura utilizada para referenciar las conexiones se basa en los siguientes puntos: Nomenclatura en cada extremo del cable de red. armario elemento interfaz de red mm nn pp donde mm es la referencia del armario o rack en el que se ubica el elemento, nn identifica al elemento dentro de dicho armario (sea servidor, switch o cualquier otro elemento) y pp identifica cada NIC dentro del elemento. Cada extremo del cable de red hace referencia al extremo opuesto. La referencia numérica de cada armario dependerá de la distribución del CPD. La numeración de los elementos de un mismo armario se hace de arriba a abajo. La numeración de los diferentes NICs de un elemento depende del tipo de elemento. Así: 1. En el caso de que sea un switch la numeración es la correspondiente a cada una de las bocas del mismo. 2. En el caso de un servidor, las interfaces de red se numeran de izquierda a derecha y de arriba a abajo. 105

106 referencia: La primera tabla a completar muestra la relación entre los elementos y su Elemento Nombre del servidor Referencia mmnn 106

107 La segunda tabla a completar relaciona cada extremo del cable con el switch al que está conectado y la dirección IP asociada. Referencia Puerto Switch Dirección IP mmnnpp mmnnpp 107

108 Formulario nº4 Petición de reserva de IP: Nombre de la máquina 1 :... Funcionalidad de la máquina 1 :... Cliente 1 :... Persona responsable 1 :... Correo electrónico 1 :... Teléfono:... Departamento 1 :... Dirección IP 2 :... Puerta de enlace 2 :... Segmento de Red 2 :... 1 A completar por el grupo del proyecto 2 A completar por OM-Comunicaciones 108

109 Formulario nº5 Nombre del producto: Número de licencia: Caducidad: URL de acceso al contrato de soporte: Usuario de acceso: Clave de acceso 1 : 1 La clave de acceso puede estar especificada en el propio formulario o referirse simplemente la información necesaria para su acceso en la herramienta de gestión de usuarios y claves de acceso de CSN, TeamPass. 109

110 Formulario nº6 Actualización de la infraestructura Nombre del servidor:... Sistema Operativo:...Versión:... Información del nuevo servicio instalado Nombre:...Versión:... Persona responsable 1 :... Correo electrónico 1 :... Teléfono 1 :... Departamento 1 :... Fichero principal de configuración:... Particularidades de la instalación 2 : Recomendaciones de monitorización 3 : 1 A completar cuando el servidor entre en la fase de Operación de Servicio 2 Si procede, se deben indicar las diferencias de la instalación existente con la instalación por defecto y razones de las mismas 3 Si procede, en este apartado el grupo del proyecto escribirá las recomendaciones que hace a servicios gestionados para que monitoricen el servicio instalado. 110

111 Documento de análisis de rendimiento del servicio Este documento pretende ser una plantilla a la hora de elaborar un documento durante la fase de pruebas. La información recogida deberá hacer mención, al menos, a (el texto en cursiva ha de ser completado): Información relativa a: Infraestructura implicada Listado de los servidores y otros elementos (librería de cintas, cabinas de discos,etc...) implicados en las pruebas. Servicios a analizar Listado de los servicios implicados en las pruebas y servidor sobre el que son ejecutados. Tipo de prueba Describir brevemente el tipo de prueba a la que se va a someter a la infraestructura. Generalmente suele ser alguno de los siguientes: Prueba de la integridad de los datos y de la base de datos, Prueba de Funcionalidad, Prueba de Estrés, Prueba de la seguridad y del control de acceso, Failover y prueba de recuperación, Prueba de Configuración,etc... Detalle de las pruebas a realizar Descripción detallada de las pruebas a realizar haciendo especialmente hincapié en los objetivos de las mismas y el modo en el que se van a llevar a cabo las pruebas Resultados esperados Descripción de los resultados que se deberían de obtener al lanzar las pruebas. Resultados obtenidos Descripción de los resultados que se han obtenido tras lanzar las pruebas. Análisis de los problemas encontrados En caso de que los resultados obtenidos difieran de los resultados esperados se deben analizar las causas de las diferencias. Solución a los problemas encontrados En caso de haberse encontrado problemas, tras haber analizado sus causas y solventarlos, se debe detallar la solución que se ha encontrado. 111

112 Tiempo invertido Mencionar el tiempo que se ha invertido en cada una de las fase de estas pruebas. 112

113 Informe de pruebas La información recogida deberá hacer mención, al menos, a (el texto en cursiva ha de ser completado): Información relativa a: Tipo de prueba Describir brevemente el tipo de prueba realizadas en la infraestructura. Generalmente suele ser alguno de los siguientes: Prueba de la integridad de los datos y de la base de datos, Prueba de Funcionalidad, Prueba de Estrés, Prueba de la seguridad y del control de acceso, Failover y prueba de recuperación, Prueba de Configuración,etc... Pruebas realizadas Informe de las pruebas realizados Resultados obtenidos Descripción de los resultados que se han obtener tras lanzar las pruebas. Análisis de los resultados obtenidos Análisis de las pruebas realizadas, indicando si se han observado comportamientos anómalos o erráticos Recomendaciones de mejora de la infraestructura En caso de haberse encontrado problemas, tras haber analizado sus causas, se debe realizar alguna propuesta de cambio o mejora en la infraestructura para solventar esas carencias. 113

114 Cambios en la monitorización Cliente: Ubicación Física:(Edificio, Localidad) Tipo de Elemento: (Servidor, Línea, Router ) Nombre del Elemento: Dirección IP: Condición a comprobar: (Disponibilidad, Ocupación de Disco ) Comando de Nagios: Consecuencias de caída del elemento: Periodicidad Del Chequeo Diaria Especificar a quién se debe avisar en caso de caída y su criticidad Intervalo: 5 min 15 min 30 min 1h 2h 6h 12h Otro (especificar): Semanal Lunes Martes Miércoles Jueves Viernes Sábado Domingo Todos Hora: Opciones Adicionales / Específicas 114

115 12.4 Listas de control A continuación se definen unos check lists o listas de control. Gracias a ellas se espera que las personas que las utilicen verifiquen que se cumplen todos los elementos mencionados en ellas y de este modo asegurarse de que no se avanza en el proyecto sin tareas incompletas Check list fase 1 Instalación física: Cableado de Alimentación 1 Cableado de Red 2 Password de BIOS 3 Configuración de ilo (Password y Red) 4 Conexión a KVM 4 Cableado de Almacenamiento 4 Prueba de redundancia de Red Documentación: Documentación inicial completada 5 Formulario nº3 completado 5 1 Nótese que el cableado de alimentación ha de ser necesariamente redundante. En caso de que no sea así hágase constar explícitamente. 2 Al igual que en la referencia anterior la instalación debe contemplar redundancia de todos los elementos. 3 No siempre se contempla esta posibilidad. Indíquese si está contemplado, en caso negativo, las razones para ello. 4 Si procede. 5 Hitos de documentación que necesariamente deben de cumplimentarse para pasar de fase. 115

116 Check list fase 5 Documentación del proyecto completa: Mapa funcional de la infraestructura Detalle de los servicios instalados 1 Credenciales de acceso a la infraestructura 2 Mapa de electrónica de Red Información de Red 3 Información de Licencias 4 Documentación de pruebas Documentación anexa del proyecto: Documentación de copias de seguridad Circuito de incidencias Planes de contingencia de la infraestructura Planes de mantenimiento 4 Planes de recuperación 1 Por cada servidor se deben especificar sus servicios instalados y sus respectivas recomendaciones de monitorización. 2 Esta información deberá estar recogida en la herramienta corporativa de claves 3 Incluye esquemas de Red e inventario de realizaciones IP/Servidor. 4 Esta información deberá estar recogida en la herramienta corporativa de licencias 4 Esta información deberá incluir ventanas de mantenimiento 116

117 12.5 Catálogo de servicios Implementación de monitorización de servicios (Nagios, Solarwinds) Implementación de monitorización Hardware (IRS) Conexión con Active Directory Compartición de ficheros NFSv3 Servidor de páginas WEB (Apache) Servicio de proxy inverso sin/con SSL (Squid) Servicio de proxy (Squid) Servidor DNS (bind) Pasarela de correo (postfix) Servicio antivirus integrado en pasarela de correo (ClamAV) Servicio antispam integrado en pasarela de correo (SpamAssassin) Servicio de BBDD (MySQL, Oracle) Servicio de sincronización de datos (rsync) Servicio de análisis de vulnerabilidades (Nessus, OpenVAS) Servicio de actualización de servidores Servicios colaborativos: Servicio de documentación colaborativa (MediaWiki) Servicio de almacén de claves colaborativo (TeamPass) Servicio colaborativo de tareas (dotproject) 117

118 12.6 Procedimientos A continuación se presentan los diferentes procedimientos que se deben seguir a lo largo de un proyecto de ampliación. Con ellos se pretende facilitar las labores de instalación de los técnicos aunque posteriormente deberán configurar adecuadamente cada servicio y adaptarlo a los requerimientos del proyecto. Índice de procedimientos Procedimiento de configuración de red Procedimiento de creación de usuarios Procedimiento de instalación de SSH Procedimiento de actualización del sistema operativo Instalación de IRS Instalación de SNMP Instalación de Nagios Generación de estadísticas Conexión con Active Directory Compartición de ficheros mediante NFS Instalación de servidor de páginas WEB Instalación de proxy inverso Instalación de proxy Instalación de servidor de DNS Instalación de pasarela de correo Instalación de un servidor de bases de datos MySQL Instalación de un servidor de bases de datos Oracle Servicio de sincronización de datos Instalación del analizador de vulnerabilidades Nessus Instalación del analizador de vulnerabilidades OpenVAS Instalación de servicio de actualizaciones de Sistema Operativo Instalación de servicios colaborativos

119 Procedimiento de configuración de red Objetivo Este procedimiento describe el proceso para configurar una dirección IP fija en una máquina UNIX. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: IP futura Máscara de red Puerta de enlace Servidor/es DNS Procedimiento Para configurar la IP en una máquina UNIX, el procedimiento a seguir es el siguiente: En Debian Cambiar el fichero /etc/network/interfaces de auto eth0 iface eth0 inet dhcp a auto eth0 iface eth0 inet static address xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx gateway xxx.xxx.xxx.xxx Relanzar la red: /etc/init.d/networking restart 119

120 En Red Hat Cambiar el fichero /etc/sysconfig/network-scripts/ifcfg-eth0 (suponiendo que queremos fijar la NIC eth0) de DEVICE=eth0 HWADDR=xx:xx:xx:xx:xx:xx BOOTPROTO=dhcp ONBOOT=yes a DEVICE=eth0 HWADDR=xx:xx:xx:xx:xx:xx BOOTPROTO="none" IPADDR="xxx.xxx.xxx.xxx" NETMASK="xxx.xxx.xxx.xxx" GATEWAY="xxx.xxx.xxx.xxx" ONBOOT=yes Relanzar la red: /etc/init.d/network restart Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que la máquina está en la red: ping xxx.xxx.xxx.xxx (puerta de enlace) Desde otra máquina de la red ping xxx.xxx.xxx.xxx (IP de la máquina) Recomendación de monitorización Se puede recomendar que se monitorice que la máquina responde a ping. 120

121 Procedimiento de creación de usuarios Objetivo Este procedimiento describe el proceso de creación de un usuario para la administración remota de los sistemas UNIX. Este usuario es sistemas Procedimiento Para crear un usuario en una máquina UNIX, el procedimiento a seguir es el siguiente: Iniciar sesión en el servidor con el usuario administrador del sistema. Ejecutar el comando: useradd -m sistemas Una vez creado el usuario sistemas se le debe asignar una contraseña: passwd sistemas Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Salir de la sesión actual mediante el comando: exit Iniciar una nueva sesión en el servidor mediante el usuario sistemas recién creado y su clave de acceso: login as: sistemas sistemas@unix's password: Linux terminal #1 SMP Sat Jun 11 14:54:10 UTC 2011 i686 The programs included with the Debian GNU/Linux system are free software; 121

122 the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. /usr/bin/xauth: creating new authority file /home/sistemas/.xauthority 122

123 Procedimiento de instalación de SSH Objetivo Este procedimiento describe el proceso de instalación de la herramienta de administración remota SSH en máquinas UNIX. Atención: Mediante este procedimiento se inhabilita el acceso del usuario root a la máquina por SSH. Asegurarse antes de realizar este procedimiento de que se dispone de otro usuario para acceder a la máquina (utilizar el Procedimiento de creación de usuarios (apartado )). En cualquier caso esto no inhabilita el acceso a root a la máquina desde la consola local o la herramienta de acceso remoto del fabricante Procedimiento Para instalar SSH en una máquina UNIX, el procedimiento a seguir es el siguiente: Instalar el paquete En Debian: aptitude install openssh-server En Red Hat: yum install openssh-server a no Configurar el paquete Editar el fichero /etc/ssh/sshd_config y cambiar el parámetro PermitRootLogin Relanzar el demonio En Debian: service ssh reload En Red Hat: 123

124 service sshd reload Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el proceso sshd está activo: ps -ef grep /usr/sbin/sshd Comprobar que el puerto 22 está activo con el proceso sshd escuchando en él: netstat -tpln grep 22 escucha Recomendación de monitorización Se puede recomendar que se monitorice que el puerto 22 de la máquina está a la 124

125 Procedimiento de actualización del sistema operativo Objetivo Este procedimiento describe el proceso para actualizar el sistema operativo de una máquina UNIX Procedimiento Para realizar la actualización del Sistema Operativo los pasos a seguir son: En Debian: aptitude update aptitude safe-upgrade En Red Hat: yum update En caso de que se actualice algún paquete de kernel (linux-image-* o glibc) se debe reiniciar la máquina mediante el siguiente comando. shutdown -r now Comprobación del procedimiento En Debian Si se ha actualizado correctamente la salida del comando: aptitude safe-upgrade Debe ser: No se instalará, actualizará o eliminará ningún paquete. 0 paquetes actualizados, 0 nuevos instalados, 0 para eliminar y 0 sin actualizar. Necesito descargar 0 B de ficheros. Después de desempaquetar se usarán 0 B. 125

126 En Red Hat Si se ha actualizado correctamente la salida del comando: yum update Debe ser: Setting up Update Process No Packages marked for Update 126

127 Instalación de IRS Objetivo Este procedimiento describe el proceso de instalación de los agentes de IRS en máquinas UNIX para incluirlas en la monitorización de la infraestructura. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: Nombre del servidor: Modelo del servidor: Versión y distribución del SO: IP del servidor IRS: Credenciales de acceso al servicio IRS: Comunidad de SNMP Instalación de los agentes Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el siguiente: Iniciar sesión en el servidor con el usuario administrador del sistema. Descargar el software necesario Ir a lang=en&cc=us&taskid=135 En la sección servers seleccionar la familia del servidor Seleccionar el modelo del servidor Seleccionar el sistema operativo Buscar en la pestaña Software-System Management el paquete encargado de instalar los agentes del Insight Manager Descargar dicho paquete 127

128 Instalar el paquete tar xf hpmgmt-version-so-modelo.tgz hpmgmt/version/installversionvibs.sh --install Seguir los pasos del instalador y configurar SNMP con los datos de la red y de SNMP Añadir la máquina a la monitorización Conectarse a la máquina que tiene instalado el servicio IRS, mediante la siguiente URL y autenticarse con perfil admin Acceder a Webes Managed Entity (tercer botón superior) y darle a New. Escribir el nombre de la máquina a añadir a la monitorización (asegurarse previamente de que el fichero etc/hosts del servidor IRS resuelve dicho nombre) y darle a Apply Changes. Revisar que los datos que ha obtenido el IRS a través del protocolo SNMP o WMI (según el caso) sean correctos. Si todo es correcto, darle a Apply Changes (y si no, corregirlo y darle a Apply Changes). Una vez añadida la máquina, seleccionar un grupo en el menú de la izquierda en 128

129 el que incluirla. En el Step 1 seleccionar la máquina recién añadida. En el Step 2 y 3 seleccionar el orden en el que añadirla. Finalmente darle a Add new node Comprobación del procedimiento Ir a la consola de la máquina en la que se han instalado los agentes y escribir el siguiente comando: snmptrap -v 1 -c public IP_servidor_IRS IP_servidor s test 129

130 Instalación de SNMP Objetivo Este procedimiento describe el proceso de instalación de los agentes de SNMP en máquinas UNIX para incluirlas en la monitorización de la infraestructura. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: IP del servidor Solarwinds: Comunidad de SNMP: Instalación del servicio Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el siguiente: En Debian: aptitude install snmpd En Red Hat: yum install net-snmp Configuración del servicio Editar el fichero /etc/snmp/snmpd.conf, el contenido del mismo debe ser: rwcommunity private rocommunity comunidad rocommunity comunidad IP_Servidor_Solawinds com2sec notconfiguser default comunidad group notconfiggroup v1 notconfiguser group notconfiggroup v2c notconfiguser view systemview included.1 access notconfiggroup "" any noauth exact \ systemview none none pass /usr/bin/ucd5820stat 130

131 Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el servicio de snmp está activo: ps -ef grep snmpd Comprobar que el puerto 161 está activo con el proceso snmpd escuchando en él: netstat upln grep snmpd 131

132 Instalación de Nagios Objetivo Este procedimiento describe el proceso de instalación de los agentes de Nagios en máquinas UNIX para incluirlas en la monitorización de la infraestructura. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: IP del servidor de Nagios: Versión y distribución del SO: siguiente: Instalar el paquete Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el En Debian: aptitude install nagios-nrpe-server nagios-plugins-basic nagios-plugins-standard En Red Hat: No se puede instalar Nagios en Red Hat (a fecha de la creación de este documento, versión 5.7) desde los repositorios oficiales así que el proceso es un poco más complicado que en Debian. o Para sistemas x86 (32-bits): rpm -Uhv o Para sistemas x64 (64-bits): rpm -Uhv Una vez añadidos los nuevos repositorios, proceder a la instalación yum install nagios-nrpe nagios-plugins 132

133 Configurar el paquete Por defecto el contenido del fichero de configuración (/etc/nagios/nrpe.cfg)es el siguiente (se han eliminado los comentarios y las líneas vacías para facilitar la lectura) log_facility=daemon pid_file=/var/run/nrpe.pid server_port=5666 nrpe_user=nagios nrpe_group=nagios allowed_hosts= dont_blame_nrpe=0 debug=0 command_timeout=60 connection_timeout=300 command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10 command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1 command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200 Este fichero se debe cambiar a: log_facility=daemon pid_file=/var/run/nrpe.pid server_port=5666 nrpe_user=nagios nrpe_group=nagios allowed_hosts=ip de la máquina encargada del chequeo dont_blame_nrpe=0 debug=0 command_timeout=60 connection_timeout=300 #command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10 #command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 #command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1 #command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z #command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c

134 Una vez cambiado el fichero reiniciar nagios para que se tengan en cuenta las modificaciones hechas: En Debian: service nagios-nrpe-server reload En Red Hat: service nrpe reload Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el proceso nrpe está activo: ps -efa grep nrpe Comprobar que el puerto 5666 está activo con el proceso nrpe escuchando en él: netstat -tpln grep Petición de monitorización Realizar una petición a OM-Explotación que se monitorice el puerto 5666 de la máquina adjuntando el formulario Cambios en la monitorización (apartado ). 134

135 Generación de estadísticas Objetivo Este procedimiento describe el proceso de instalación y configuración de una herramienta en máquinas UNIX dedicada a la adquisición de estadísticas Procedimiento Para instalar dicha herramienta en una máquina UNIX, el procedimiento a seguir es el siguiente: En Debian Instalar el paquete aptitude install sysstat Configurar las estadísticas o Editar el fichero /etc/sysstat/sysstat Cambiar el parámetro HISTORY a 35 o Editar el fichero /etc/default/sysstat Cambiar el parámetro ENABLED a "true" Relanzar el servicio /etc/init.d/sysstat reload En Red Hat Instalar el paquete yum install sysstat Configurar las estadísticas o Editar el fichero /etc/sysconfig/sysstat 135

136 Cambiar el parámetro HISTORY a Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que se están generando estadísticas: sar -u 136

137 Conexión con Active Directory Objetivo A continuación se presenta una guía de todos los pasos para unir un equipo Unix 5 a un dominio de Active Directory (AD) de Windows Server ya desplegado. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: Dominio: Nombre del servidor AD: IP del servidor AD: Usuario/Password administrador de AD: Nombre de la máquina cliente Unix: siguiente: Procedimiento Para configurar AD en una máquina UNIX, el procedimiento a seguir es el En Debian Instalar la paquetería necesaria: aptitude install samba smbclient winbind krb5-user krb5-config Resolver equipos de la red Agregar la IP de nuestro equipo Linux y la del Server Active Directory a /etc/hosts. El formato de ese fichero es el siguiente: IP NombreMáquina 5 Dentro del epígrafe Unix englobamos todos aquellos sistemas Unix y similares (HP-UX, AIX, GNU/Linux...) 137

138 quede así: Configurar el cliente kerberos Para configurar el cliente kerberos editar el fichero /etc/krb5.conf para que [libdefaults] default_realm = DOMINIO clockskew = 300 [realms] DOMINIO = { kdc = IP AD default_domain = dominio admin_server = IP AD } [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 try_first_pass = true } Crear tickets Kerberos Para crear los tickets kerberos ejecutar el siguiente comando: kinit usuarioadministrador@dominio Pedirá el password de la cuenta administrador del dominio. Puede utilizarse cualquier cuenta con permisos administrativos en el dominio. El DOMINIO debe ir escrito en mayúsculas. 138

139 Configurar samba Editar el fichero /etc/samba/smb.conf quedando algo similar a lo siguiente: [global] security = ADS netbios name = Nombre Linux realm = dominio password server = Nombre server AD workgroup = AD log level = 1 syslog = 0 idmap uid = idmap gid = winbind separator = + winbind enum users = yes winbind enum groups = yes winbind use default domain = yes template homedir = /home/%d/%u template shell = /bin/bash client use spnego = yes domain master = no server string = linux como cliente de AD encrypt passwords = yes ##compartir el home del usuario solo para él cuando se encuentre en otro equipo de la red [homes] comment = Home Directories valid users = %S browseable = No read only = No inherit acls = Yes [profiles] comment = Network Profiles Service path = %H read only = No store dos attributes = Yes create mask = 0600 directory mask = 0700 Comprobar la instalación de Samba testparm 139

140 resueltos. La salida debe ser la siguiente: Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Loaded services file OK. Agregar la máquina al dominio net ads join -S Nombre_server_AD -U usuarioadministrador Resolver nombres de usuarios y grupos de dominio Editar /etc/nsswitch.conf y modificar las siguientes líneas dejándolas así: Passwd: files winbind group: files winbind shadow: files winbind hosts: files dns winbind Gracias a las lineas anteriores los usuarios y grupos del dominio pueden ser Configurar la autenticación Para configurar el acceso a los usuarios del dominio a la máquina mediante el entorno gráfico hay que configurar pam. Para ello editar los siguientes archivos y agregar/modificar las siguientes lineas: /etc/pam.d/common-account account sufficient pam_winbind.so account required pam_unix.so try_first_pass /etc/pam.d/common-auth auth sufficient pam_winbind.so auth required pam_unix.so nullok_secure try_first_pass /etc/pam.d/common-password password sufficient pam_winbind.so password required pam_unix.so nullok obscure min=4 max=8 md5\ try_first_pass /etc/pam.d/common-session session required pam_mkhomedir.so skel=/etc/skel/ umask=0022 session sufficient pam_winbind.so session required pam_unix.so try_first_pass 140

141 Crear el directorio /home/dominio Nombre del dominio en MAYÚSCULA, que es donde tendrán sus directorios home los usuarios: mkdir /home/dominio Reiniciar los servicios Tras haber instalado y configurado todo se deben reiniciar los servicios: service samba stop service winbind stop service samba start service winbind start service ssh restart En Red Hat Ejecutar el comando: /usr/sbin/system-config-authentication Aparecerá la siguiente pantalla. 141

142 En adelante nos referiremos a esta pantalla como la Pantalla Principal. Para una correcta configuración se deben marcar los items adecuados y completar los campos tal y como aparecen en las imágenes siguientes. Presionando en Configurar Winbind... se obtendrá la siguiente pantalla. Nótese que el controlador de dominio (ServidorAD) especificado deberá de ser accesible por nombre (habiendo añadido una entrada en el fichero /etc/hosts) o bien introducir la IP. 142

143 Principal. Tras presionar Aceptar, seleccionamos la pestaña Autenticación de la Pantalla Seleccionando cada uno de los apartados Configurar Kerberos

144 Configurar SMB... y Configurar Winbind

145 Para finalizar, seleccionar la pestaña Opciones de la Pantalla Principal. Ultimas notas En este apartado se van a hacer algunas consideraciones: 1. Nótese que en la última pantalla se ha marcado la opción de creación del entorno de trabajo del usuario en la máquina objetivo. Este directorio de trabajo se genera en /home/dominio. Por ello, como root, se debe de crear este punto del árbol de directorios con los permisos necesarios para que los usuarios puedan acceder al mismo. mkdir /home/dominio chmod A pesar de que este script de configuración realice la actualización de los ficheros pertinentes pudiera ocurrir que el software necesario no estuviera presente. Revísese la salida del comando para comprobar que los servicios involucrados han sido convenientemente reiniciados: samba, winbind y nscd. 145

146 3. En las pruebas realizadas la instalación del software de samba (necesario para la autenticación) no realizó el enlace necesario para el inicio del servicio en el nivel o niveles correspondientes. Este enlace es imprescindible para que dicho servicio se inicie automáticamente tras cada reinicio del sistema. Es necesario recrear manualmente dicho enlace: chkconfig --level 2345 smb on Comprobación del procedimiento Verificar la integración del dominio Mostrar si la máquina está correctamente integrada al dominio: net rpc testjoin Mostrar información del dominio: net ads join Mostrar información de un usuario del dominio: net rpc info -U nusuario Verificar que winbind esté funcionando Listar los usuarios del dominio: wbinfo -u Listar los grupos del dominio: wbinfo -g Mostrar los usuarios locales y del dominio: getent passwd Mostrar los grupos locales y del dominio: getent group 146

147 Verificar que cualquier usuario del AD se puede logear Al iniciar sesión con el nombre de usuario/contraseña del AD, debe aparecer un mensaje parecido: Creating directory '/home/dominio/nusuario' Recomendación de monitorización Se puede recomendar que se monitorice la salida del comando smbstatus También se pueden monitorizar los puertos 139 y 445 del servidor. 147

148 Compartición de ficheros mediante NFS Objetivo Este procedimiento describe el proceso de instalación de los agentes de NFS en máquinas UNIX tanto para los clientes como para los servidores. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: Nombre del servidor de NFS IP del servidor de NFS Nombre del/os cliente/s de NFS IP del/os cliente/s de NFS Instalación y configuración del servidor Instalación del servicio Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el siguiente: En Debian aptitude install nfs-kernel-server En Red Hat yum install nfs-utils Configuración del servicio Modificar el fichero /etc/exports y añadir la siguiente línea por cada directorio a exportar: Por ejemplo, para compartir el fichero /directorio con las IP's de la red /24 debemos añadir la línea: /directorio /24(rw,no_subtree_check,sync) 148

149 Actualizamos la configuración del servicio En Debian service nfs-kernel-server restart En Red Hat service nfs restart Comprobación del procedimiento Comprobamos que se exportan correctamente los directorios exportfs Instalación y configuración del cliente Instalación del servicio En Debian aptitude install nfs-common En Red Hat yum install nfs-utils Configuración del servicio Montar las unidades: mount -t nfs servidor_nfs:/directorio /punto_de_montaje El comando anterior sirve para un montaje puntual y en el próximo reinicio de la máquina no se mantendrá, si queremos que se monte este directorio en cada reinicio debemos editar el fichero /etc/fstab y añadir la línea: servidor_nfs:/directorio /punto_de_montaje nfs rw Comprobación del procedimiento Ejecutar el comando listado a continuación y comprobar que está montada la unidad que queríamos. mount 149

150 Recomendación de monitorización Se puede recomendar la monitorización del puerto 2049 del servidor. 150

151 Instalación de servidor de páginas WEB Objetivo Este procedimiento describe el proceso de instalación de un servidor WEB en máquinas UNIX Procedimiento Para instalar apache2 en una máquina UNIX, el procedimiento a seguir es el siguiente. De ese modo se tendría en servidor apache en marcha que únicamente presenta la página Web /var/www/index.html En Debian Instalar el paquete aptitude install apache2 Arrancar el servicio service apache2 start Asegurarse de que el servidor se active en el arranque de la máquina update-rc.d apache2 defaults En Red Hat Instalar el paquete yum install httpd Arrancar el servicio service httpd start Asegurarse de que el servidor se active en el arranque de la máquina chkconfig --level 2345 httpd on 151

152 Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servidor Web está activo: service apache2 status (en Debian) service httpd status (en Red Hat) Comprobar que el puerto 80 está activo con el proceso apache2 o httpd escuchando en él : netstat -tpln grep 80 Desde otro cliente conectarse mediante el navegador Web a la máquina en la que hemos instalado el servidor. La URL a introducir es: Recomendación de monitorización Se puede recomendar que se monitorice el puerto 80 del servidor. También es recomendable monitorizar que al lanzar una petición Web al servidor éste responda correctamente Autenticación para acceder a ciertas páginas En este apartado se muestra el procedimiento para conseguir que los usuarios se autentiquen para acceder a una página. Se ha procedimentado la autenticación de dos maneras: fichero y LDAP. Con la primera, se podrán autenticar únicamente los usuarios que se hayan dado de alta en un fichero. Con la segunda, la validación se hará contra un servidor de Active Directory. 152

153 Autenticación mediante fichero En Debian Para restringir el acceso a las páginas que cuelguen de un directorio, se puede crear un fichero con la relación de usuarios y sus respectivas contraseñas para que se autentiquen. Modificar el fichero donde se encuentre la información relativa a las páginas activas, por ejemplo /etc/apache2/sites-enabled/000-default y añadir la siguiente información. <Directory /var/www/pagina> AuthName "Autentíquese para acceder a esta página" AuthType Basic AuthUserFile /var/www/pagina/.htpasswd require valid-user </Directory> Donde /var/www/pagina es la ruta para la cuál se necesita autenticación y /var/www/pagina/.htpasswd es un fichero que contiene la relación de los usuarios y contraseñas que permiten acceder a esa ruta. Para crear ese fichero, el comando a ejecutar es: htpasswd -cs /var/www/pagina/.htpasswd user user. Al ejecutar este comando se solicitará que introduzca una contraseña para el Donde user es uno de los usuarios que requiere autenticación. El resto de los usuarios se deben crear con el comando htpasswd -s /var/www/pagina/.htpasswd user Una vez acabados estos cambios, relanzar el apache service apache2 restart 153

154 En Red Hat Para restringir el acceso a las páginas que cuelguen de un directorio, se puede crear un fichero con la relación de usuarios y sus respectivas contraseñas para que se autentiquen. Modificar el fichero donde se encuentre la información relativa a las páginas activas, por ejemplo /etc/httpd/conf/httpd.conf y añadir la siguiente información. <Directory /var/www/html/pagina> AuthName "Autentiquese para acceder a esta página" AuthType Basic AuthUserFile /var/www/html/pagina/.htpasswd require valid-user </Directory> Donde /var/www/html/pagina es la ruta para la cuál se necesita autenticación y /var/www/pagina/html/.htpasswd es un fichero que contiene la relación de los usuarios y contraseñas que permiten acceder a esa ruta. Para crear ese fichero, el comando a ejecutar es: htpasswd -cs /var/www/html/pagina/.htpasswd user Donde user es uno de los usuarios que requiere autenticación. El resto de los usuarios se deben crear con el comando htpasswd -s /var/www/html/pagina/.htpasswd user Una vez acabados estos cambios, relanzar el apache service httpd restart 154

155 Autenticación mediante LDAP En Debian Para restringir el acceso a las páginas que cuelguen de un directorio mediante LDAP, se debe: Activar el módulo de autenticación LDAP. cd /etc/apache2/mods-enabled ln -s../mods-available/authnz_ldap.load. ln -s../mods-available/ldap.load. ln -s../mods-available/ldap.conf. Modificar el fichero donde se encuentre la información relativa a las páginas activas, por ejemplo /etc/apache2/sites-enabled/000-default y añadir la siguiente información. <Directory /var/www/pagina> AuthType Basic AuthName "Por favor, identifíquese con el directorio activo" AuthBasicProvider ldap AuthLDAPURL "ldap://servidor_ad:389" Require valid-user </Directory> Donde /var/www/html/pagina es la ruta para la cuál se necesita autenticación. Una vez acabados estos cambios, relanzar el apache service apache2 restart En Red Hat Para restringir el acceso a las páginas que cuelguen de un directorio mediante LDAP, se debe modificar el fichero donde se encuentre la información relativa a las páginas activas, por ejemplo /etc/httpd/conf/httpd.conf información. y añadir la siguiente <Directory /var/www/pagina> AuthType Basic AuthName "Por favor, identifíquese con el directorio activo" AuthBasicProvider ldap AuthLDAPURL "ldap://servidor_ad:389" Require valid-user </Directory> 155

156 Donde /var/www/html/pagina es la ruta para la cuál se necesita autenticación. Una vez acabados estos cambios, relanzar el apache service httpd restart 156

157 Servidor Web con conexión segura El servidor que se instala por defecto únicamente permite conexiones no seguras (http). Puede resultar necesario que el servidor permita conexiones seguras (https). A continuación se presenta un procedimiento para configurarlo en Debian y Red Hat. Además se puede recomendar que se monitorice el puerto 443 del servidor En Debian Activar el módulo de SSL cd /etc/apache2/mods-enabled ln -s../mods-available/ssl.conf. ln -s../mods-available/ssl.load. Por defecto apache2 genera el certificado /etc/ssl/certs/ssl-certsnakeoil.pem y su clave privada /etc/ssl/private/ssl-cert-snakeoil.key en caso de querer crear otro certificado ejecutar los siguientes comandos mkdir /etc/apache2/ssl openssl genrsa -out /etc/apache2/ssl/ca.key 2048 openssl req -new -key /etc/apache2/ssl/ca.key -x509 -out \ /etc/apache2/ssl/ca.crt -days 365 Configurar apache para que acepte conexiones seguras En el fichero /etc/apache2/ports.conf comprobar que se encuentra descomentada la línea Listen 443 Configurar apache para que utilice el certificado. En el fichero /etc/apache2/sites-enabled/default-ssl modificar las líneas que hacen referencia a los certificados. SSLEngine on SSLCertificateFile /etc/apache2/ssl/ca.crt SSLCertificateKeyFile /etc/apache2/ssl/ca.key Una vez acabados estos cambios, relanzar el apache 157

158 service apache2 restart En Red Hat Crear un certificado openssl genrsa -out /etc/pki/tls/private/web.key 2048 openssl req -new -key /etc/pki/tls/private/web.key -x509 \ -out /etc/pki/tls/certs/web.crt -days 365 Configurar apache para que utilice el certificado. En el fichero /etc/httpd/conf.d/ssl.conf modificar las líneas que hacen referencia a los certificados. SSLCertificateFile /etc/pki/tls/certs/web.crt SSLCertificateKeyFile /etc/pki/tls/private/web.key Una vez acabados estos cambios, relanzar el apache service httpd restart 158

159 Instalación de un entorno LAMP No es habitual tener que instalar únicamente Apache. Por ello a continuación se detalla como se debe instalar y configurar una máquina con Apache, MySQL y PHP Instalación de PHP En Debian o Instalar los paquetes aptitude install php5 o Relanzar el servidor service apache2 restart En Red Hat o Instalar los paquetes yum install php Relanzar el servidor service httpd restart Instalación de MySQL La instalación de MySQL se encuentra en el procedimiento de instalación de MySQL, por ello no se detallará aquí la instalación de MySQL sino de los módulos necesarios para su funcionamiento junto a PHP. En Debian o Instalar los paquetes aptitude install php5-mysql o Relanzar el servidor service apache2 restart 159

160 En Red Hat o Instalar los paquetes yum install php-mysql o Relanzar el servidor service httpd restart 160

161 Instalación de proxy inverso Objetivo Este procedimiento describe el proceso de instalación de un proxy inverso en máquinas UNIX Procedimiento Para instalar un proxy inverso, instalaremos el servicio squid3. En una máquina UNIX, el procedimiento a seguir es el siguiente: Instalar el paquete En Debian aptitude install squid3 En Red Hat yum install squid Detener el servicio En Debian service squid3 stop En Red Hat: service squid stop Configurar el servicio El uso lógico del proxy inverso es que esté a la escucha en el puerto 80 (y posteriormente en el 443) por lo cuál se debe detener cualquier otro servicio que esté a la escucha en esos puertos. En principio el proceso que está a la escucha en esos puertos es apache (acceder a la documentación de servidor Web para detener este servicio) pero se recomienda asegurarse de ello mediante el comando: 161

162 netstat -tpln grep 80 Por defecto instalaremos un proxy inverso sin SSL. El fichero de configuración se encuentra en /etc/squid3/squid.conf. A continuación se muestra la configuración de un proxy inverso muy sencillo pero que sirve de base para otras configuraciones. Se ha marcado en negrita las diferencias que existen en la configuración de Debian y Red Hat. 162

163 http_port 80 vhost ############################## # En este caso las peticiones a la página serán atendidas por el server_1 # y las de la serán atendidas por el server_2 cache_peer ip_servidor1 parent 80 0 no-query originserver name=server_1 cache_peer ip_servidor2 parent 80 0 no-query originserver name=server_2 ############################## acl pagina1 url_regex -i ^ /) acl pagina2 url_regex -i ^ /) acl all src / ############################## http_access allow pagina1 http_access allow pagina2 http_access deny all ############################## cache_peer_access server_1 cache_peer_access server_1 cache_peer_access server_2 cache_peer_access server_2 allow pagina1 deny all allow pagina2 deny all #estas 2 líneas son para Debian access_log /var/log/squid3/access.log squid coredump_dir /var/spool/squid3 #estas 2 líneas son para Red Hat access_log /var/log/squid/access.log squid coredump_dir /var/spool/squid # La siguiente línea sirve para que en caso de recibir una petición a una página desconocida # se redirija al usuario. deny_info all 163

164 Lanzar el servicio En Debian: service squid3 start En Red Hat: service squid start Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servicio está activo: service squid3 status (en Debian) service squid status (en Red Hat) Comprobar que el puerto 80 está activo con el proceso squid escuchando en él netstat -tpln grep :80 Desde otro cliente conectarse mediante el navegador Web a la máquina en la que hemos instalado el proxy: La URL a introducir es: Desde otro cliente conectarse mediante el navegador Web a la máquina en la que hemos instalado el proxy y comprobar que redirige el tráfico: La URL a introducir es: 164

165 Asegurarse de que el proceso se cree en el arranque update-rc.d squid3 defaults (en Debian) chkconfig --level 2345 squid on (en Red Hat) Recomendación de monitorización Se puede recomendar la monitorización del puerto

166 Instalación con SSL Puede ser necesario que el proxy inverso deba servir a los clientes páginas Web mediante conexión segura Instalación en Debian La instalación de este software se realiza de manera diferente a la especificada en el punto anterior debido a una particularidad en la licencia del mismo. Por ello se ha de realizar una compilación de los fuentes mediante el siguiente procedimiento. Instalar una serie de paquetes necesarios para compilación. apt-get install libssl-dev libcppunit-dev devscripts \ build-essential fakeroot cdbs libsasl2-dev libkrb5-dev \ comerr-dev Asegurarse de que el fichero /etc/apt/sources.list contenga una línea que permita instalar software desde los fuentes de los mismos. Esta línea comienza con debsrc para indicar que se accede a los fuentes y no a los elementos precompilados. Una vez cumplido este prerrequisito se pueden ejecutar los siguientes comandos: mkdir /usr/src cd /usr/src apt-get source squid3 Instalar sus posibles dependencias apt-get build-dep squid3 Compilación del software Para generar los binarios ejecutables a partir de los fuentes obtenidos en el apartado anterior realizar los siguientes pasos: cd /usr/src/squid-version./configure <options> make make install 166

167 Para facilitar esta tarea se ha creado un script que incorpora las opciones necesarias en nuestro caso, configurar, con lo que el procedimiento queda como sigue. cd /usr/src/squid-version Crear el fichero configurar con el siguiente contenido DEB_CONFIGURE_EXTRA_FLAGS="--datadir=/usr/share/squid3 \ --sysconfdir=/etc/squid3 \ --mandir=/usr/share/man \ --with-cppunit-basedir=/usr \ --enable-inline \ --enable-async-io=8 \ --enable-storeio="ufs,aufs,coss,diskd,null" \ --enable-removal-policies="lru,heap" \ --enable-delay-pools \ --enable-cache-digests \ --enable-underscores \ --enable-icap-client \ --enable-follow-x-forwarded-for \ --enable-auth="basic,digest,ntlm" \ --enable-basic-authhelpers="ldap,msnt,ncsa,pam,sasl,smb,yp,getpwnam,multi-domain-ntlm" \ --enable-ntlm-auth-helpers="smb" \ --enable-digest-auth-helpers="ldap,password" \ --enable-external-aclhelpers="ip_user,ldap_group,session,unix_group,wbinfo_group" \ --with-filedescriptors=65536 \ --with-default-user=proxy --enable-ssl"./configure $DEB_CONFIGURE_EXTRA_FLAGS Ejecutar los siguientes comandos: chmod 750 configurar./configurar make make install Se deben generar los certificados para las distintas páginas Web, para ello mirar la documentación de los servidores Web y llevarlos al proxy inverso cambiándoles los permisos mediante chmod 400 certificado.key 167

168 chmod 400 certificado.crt Instalación en Red Hat No es necesaria ninguna instalación adicional ya que por defecto incorpora SSL Detener el servicio En Debian: service squid3 stop En Red Hat: service squid stop Configuración Se deben tener tantos puertos distintos como páginas Web se quieran albergar. Por ejemplo si se quiere que el proxy redirija el tráfico hacia 2 webs existen dos opciones: Que squid esté a la escucha en 2 puertos por ejemplo 443 y 444 (opción no recomendada ya que por defecto el https usa el puerto 443) Montar otra tarjeta de red en el servidor o configurar una ip virtual para que el servidor tenga 2 IP's diferentes y pueda atender por cada una de ellas las peticiones que le lleguen por el puerto 443. Al igual que antes se presenta un fichero de configuración que sirve de base para las configuraciones típicas de este servicio. Se ha marcado en negrita las diferencias que existen en la configuración de Debian y Red Hat. El contenido del fichero de configuración /etc/squid3/squid.conf debe ser: https_port ip_1_proxy:443 cert=/etc/squid3/ssl/pagina1.crt \ key=/etc/squid3/ssl/pagina1.key defaultsite= https_port ip_2_proxy:443 cert=/etc/squid3/ssl/pagina2.crt \ key=/etc/squid3/ssl/pagina2.key defaultsite= ############################## 168

169 # En este caso las peticiones a la página serán atendidas por el server_1 # y las de la serán atendidas por el server_2 cache_peer ip_servidor1 parent no-query proxy-only originserver \ login=pass ssl sslflags=dont_verify_peer name=server_1 cache_peer ip_servidor2 parent no-query proxy-only originserver \ login=pass ssl sslflags=dont_verify_peer name=server_2 ############################## acl pagina1 url_regex -i ^ /) acl pagina2 url_regex -i ^ /) acl all src / ############################## http_access allow pagina1 http_access allow pagina2 http_access deny all ############################## cache_peer_access server_1 cache_peer_access server_1 cache_peer_access server_2 cache_peer_access server_2 cache_peer_access server_3 cache_peer_access server_3 allow pagina1 deny all allow pagina2 deny all allow pagina1 deny all ############################## #estas 2 líneas son para Debian access_log /var/log/squid3/access.log squid coredump_dir /var/spool/squid3 #estas 2 líneas son para Red Hat access_log /var/log/squid/access.log squid coredump_dir /var/spool/squid # La siguiente línea sirve para que en caso de recibir una petición a una página desconocida # se redirija al usuario. deny_info all 169

170 siguientes: Lanzar el servicio En Debian: service squid3 start En Red Hat: service squid start Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servicio está activo: service squid3 status (en Debian) service squid status (en Red Hat) Comprobar que el puerto 443 está activo con el proceso squid escuchando en él. netstat -tpln grep :443 Desde otro cliente conectarse mediante el navegador Web a la máquina en la que hemos instalado el proxy: La URL a introducir es: Desde otro cliente conectarse mediante el navegador Web a la máquina en la que hemos instalado el proxy y comprobar que redirige el tráfico: La URL a introducir es: Asegurarse de que el proceso se cree en el arranque, update-rc.d squid3 defaults (en Debian) chkconfig --level 2345 squid on (en Red Hat) Recomendación de monitorización Se puede recomendar la monitorización del puerto

171 Instalación de proxy Objetivo Este procedimiento describe el proceso de instalación de un proxy en una máquina UNIX Procedimiento Para instalar un proxy inverso, instalaremos el programa squid3. En una máquina UNIX, el procedimiento a seguir es el siguiente: Instalar el paquete En Debian: aptitude install squid3 En Red Hat: yum install squid Detener el servicio En Debian: service squid3 stop En Red Hat: service squid stop 171

172 Configurar el servicio Por defecto instalaremos un proxy que no requiere autenticación, es decir que los usuarios que configuren sus navegadores para navegar mediante el proxy no deberán introducir ningunas credenciales. El fichero de configuración se encuentra en /etc/squid3/squid.conf. acl http proto http acl port_80 port 80 acl port_443 port 443 acl CONNECT method CONNECT # ponemos el proxy a la escucha en el puerto 8080 http_port 8080 cache_peer ip_servidor parent no-query no-digest # rules allowing non-authenticated users http_access allow http port_80 http_access allow CONNECT port_443 # catch-all rule http_access deny all # para la cache cache_effective_user proxy #cache_dir ufs Directory-Name Mbytes L1 L2 [options] # 'Mbytes' is the amount of disk space (MB) to use # 'L1' is the number of first-level subdirectories # 'L2' is the number of second-level subdirectories cache_dir ufs /var/log/squid3/cache/ Arrancar el servicio En Debian: service squid3 start En Red Hat: service squid start 172

173 Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servicio está activo: service squid3 status (en Debian) service squid status (en Red Hat) Comprobar que el puerto en el que hayamos puesto en marcha el proxy está a la escucha (directiva http_port del fichero de configuración): netstat -tpln grep :8080 Desde otro cliente conectarse mediante el navegador Web a cualquier URL introduciendo previamente los datos del proxy. Asegurarse de que el proceso se cree en el arranque update-rc.d squid3 defaults (en Debian) chkconfig --level 2345 squid on (en Red Hat) Recomendación de monitorización Se puede recomendar la monitorización del puerto Proxy con autenticación Se puede requerir a los usuarios que naveguen a través del proxy que se autentiquen. Esta autenticación puede hacerse de dos maneras: fichero y LDAP. Con la primera, se podrán autenticar únicamente los usuarios que se hayan dado de alta en un fichero. Con la segunda, la validación se hará contra un servidor de Active Directory Autenticación en fichero Se debe crear un fichero que contendrá las credenciales de los usuarios autorizados a navegar a través del proxy. Para crear ese fichero, el comando a ejecutar es: htpasswd -cs /etc/squid3/passwd user 173

174 Donde user es uno de los usuarios que requiere autenticación. El resto de los usuarios se deben crear con el comando htpasswd -s /etc/squid3/passwd user 174

175 Cambiar el fichero de configuración de Squid /etc/squid3/squid.conf para que tenga en cuenta ese fichero a la hora de hacer la autenticación. acl http proto http acl port_80 port 80 acl port_443 port 443 acl CONNECT method CONNECT auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid3/passwd auth_param basic children 5 # limitar el numero de procesos para autenticacion auth_param basic realm Introduzca sus credenciales # mensaje para los usuarios auth_param basic credentialsttl 2 hours # tiempo que durará la autenticación http_port 8080 acl ncsa_users proxy_auth REQUIRED http_access allow ncsa_users cache_peer ip_servidor parent no-query no-digest # rules allowing non-authenticated users http_access allow http port_80 http_access allow CONNECT port_443 # catch-all rule http_access deny all # para la cache cache_effective_user proxy cache_dir ufs /var/log/squid3/cache/ visible_hostname proxy Reiniciar el servicio En Debian: service squid3 restart En Red Hat: service squid restart 175

176 Autenticacion mediante LDAP Cambiar el fichero de configuración de Squid /etc/squid3/squid.conf para que utilice LDAP para la autenticación. acl http proto http acl port_80 port 80 acl port_443 port 443 acl CONNECT method CONNECT auth_param basic program /usr/lib/squid/squid_ldap_auth -h servidor_ad auth_param basic children 5 # limitar el numero de procesos para autenticacion auth_param basic realm Introduzca sus credenciales # mensaje para los usuarios auth_param basic credentialsttl 2 hours # tiempo que durará la autenticación http_port 8080 acl ncsa_users proxy_auth REQUIRED http_access allow ncsa_users cache_peer ip_servidor parent no-query no-digest # rules allowing non-authenticated users http_access allow http port_80 http_access allow CONNECT port_443 # catch-all rule http_access deny all # para la cache cache_effective_user proxy cache_dir ufs /var/log/squid3/cache/ visible_hostname proxy Reiniciar el servicio En Debian: service squid3 restart En Red Hat service squid restart 176

177 Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Desde otro cliente conectarse mediante el navegador Web a cualquier URL introduciendo previamente los datos del proxy. Comprobar que solicita credenciales de acceso y que realiza la autenticación correctamente. 177

178 Instalación de servidor de DNS Objetivo Este procedimiento describe el proceso de instalación de un servidor DNS en máquinas UNIX Procedimiento Para instalar un servidor DNS, instalaremos el paquete bind9. En una máquina UNIX, el procedimiento a seguir es el siguiente: Instalar el paquete En Debian: aptitude install bind9 En Red Hat: yum install bind Detener el servicio En Debian: service bind9 stop En Red Hat: service named stop Configurar el servicio El fichero de configuración se encuentra en /etc/bind/named.conf. A continuación se presentas dos configuraciones diferentes. La primera es para que el servidor DNS actúe como cache únicamente delegando la resolución de nombres en otra máquina. La segunda es para que el servidor DNS resuelva las peticiones DNS de una zona. 178

179 Servidor DNS como cache En este caso se debe indicar a la máquina que debe ser la encargada de hacer las resoluciones DNS. Para ello dejar el fichero /etc/resolv.conf como sigue: domain DOMINIO search DOMINIO nameserver Editar el fichero /etc/bind9/named.conf para indicar al servicio donde buscar información en caso de no tenerla: zone "ZONA_DE_DNS" { type forward; forwarders { servidor_dns_1; servidor_dns_2; }; }; Servidor DNS de una zona Dar de alta la zona. Editar el fichero /etc/bind/named.conf.local y añadir: //mi zona zone "prueba.zona" { type master; file "/etc/bind/db.prueba.zona"; }; Configurar la zona en el fichero /etc/bind/db.prueba.zona $TTL IN SOA dns.prueba.zona. hostmaster.prueba.zona. ( ; en caso de error enviar un a hostmaster@prueba.zona ; serial ; refresh (3 horas) 15 ; retry (15 minutos) ; expire (7 días) ; minimum (1 día) ) ; el dominio prueba.zona es controlado por dns.prueba.zona prueba.zona. IN NS dns.prueba.zona. prueba.zona. IN A IP_maquina 179

180 servidor1 IN A IP_servidor1 servidor2 IN A IP_servidor2 mail1 IN MX 10 IP_servidor_mail_1 mail2 IN MX 10 IP_servidor_mail_2 www IN CNAME servidor1 ; si el servidor 1 es el que alberga la Web Lanzar el servicio En Debian: service bind9 start En Red Hat: service named start Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servidor DNS está activo: service bind9 status (en Debian) service named status (en Red Hat) Comprobar que el puerto 53 está activo con el proceso bind9 o named escuchando en él. netstat -tpln grep :53 Desde otro cliente editar el fichero /etc/resolv.conf y poner como primer nameserver la dirección IP del nuevo servidor DNS. A continuación ejecutar el comando y comprobar que responde correctamente. dig Asegurarse de que el proceso se cree en el arranque update-rc.d bind9 defaults (en Debian) chkconfig --level 2345 named on (en Red Hat) 180

181 Recomendación de monitorización Se puede recomendar que se monitorice el puerto 53 del servidor. 181

182 Instalación de pasarela de correo Objetivo Este procedimiento describe el proceso de instalación de una pasarela de correo en máquinas UNIX Procedimiento Para ello debemos instalar postfix en una máquina UNIX, el procedimiento a seguir es el siguiente: En Debian Instalar el paquete aptitude install postfix En un momento de la instalación aparecerá la siguiente pantalla: 182

183 Seleccionar la opción Satellite system. A continuación introducir el nombre del dominio al que pertenecerá la pasarela. En caso de que este sea el servidor de correo expuesto al exterior (accesible desde Internet) se debe dejar esta línea en blanco. 183

184 Editar la configuración en el fichero /etc/postfix/main.cf. Los campos marcados en negrita deben ser cambiados en función de la infraestructura. myhostname = nombre_completo_maquina mydomain = dominio # Esta variable queda libre para que funcione como PASARELA DE CORREO mydestination = smtpd_banner = $myhostname ESMTP biff = no mynetworks = ,dirección_IP_Back_End_Correo relayhost = relay_domains = hash:/etc/postfix/relay_domains transport_maps = hash:/etc/postfix/transport relay_recipient_maps = hash:/etc/postfix/recipt # appending.domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:$ {data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/tls_readme.gz in the postfix-doc package for # information on enabling SSL in the smtp client. alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = ipv4 184

185 Como se puede apreciar, se hace referencia a tres ficheros cuyo uso y contenido se explica a continuación: /etc/postfix/relay_domains En este fichero se deben especificar únicamente los dominios a los que vamos a hacer relay, es decir el correo que debe entrar desde Internet por la pasarela. El formato del mismo debe ser: mi.dominio OK miotro.dominio OK /etc/postfix/transport En este fichero se deben especificar las resoluciones de los Back End de los dominios a los que vamos a hacer relay. El formato del mismo debe ser: miotro. dominio smtp:[ip_servidor] mi.dominio smtp:[ip_servidor] etc/postfix/recipt En este fichero se deben especificar únicamente los usuarios que podrán recibir correo del exterior gracias a la pasarela. (En general este fichero se debe actualizar periódicamente contra el directorio activo del dominio en cuestión). El formato del mismo debe ser: comandos: usuario1@mi.dominio OK usuario2@mi.dominio OK usuario1@miotro.dominio OK Por cada uno de estos ficheros, tras cada cambio, se deben ejecutar los postmap nombrefichero service postfix restart 185

186 Configurar filtros en la pasarela Para añadir diferentes filtros se necesita el paquete amavis. Instalar el paquete aptitude install amavis Comprobar que amavis está en marcha y a la escucha en el puerto Ejecutar el comando netstat -tpln grep Cambiar la configuración de postfix para aplique los filtros. Editar el fichero: /etc/postfix/main.cf y añadir: content_filter = amavis:[ ]:10024 receive_override_options = no_address_mappings Editar el fichero: /etc/postfix/master.cf y añadir: amavis unix smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes :10025 inet n smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= /8 -o strict_rfc821_envelopes=yes -o receive_override_options= \ no_unknown_recipient_checks,no_header_body_checks -o smtpd_bind_address= Volver a lanzar los servicios service postfix reload service amavisd restart 186

187 Configurar filtro Anti-Spam en la pasarela Instalar el paquete: aptitude install spamassassin Editar el fichero /etc/amavis/conf.d/15-content_filter_mode y descomentar las líneas referentes al filtro = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \ $bypass_spam_checks_re); Para no borrar el correo que sea Spam, sino marcarlo como tal, editar el fichero /etc/amavis/conf.d/50-user y añadir la siguiente línea: $final_spam_destiny = D_PASS; Configurar SpamAssassin: siguiente: El contenido recomendado del fichero /etc/spamassassin/local.cf es el # # See 'perldoc Mail::SpamAssassin::Conf' for details of what can be # tweaked. # # Only a small subset of options are listed below # ##################################################################### ###### # Add *****SPAM***** to the Subject header of spam s # rewrite_header Subject ***SPAM (_SCORE_) *** # Save spam messages as a message/rfc822 MIME attachment instead of # modifying the original message (0: off, 2: use text/plain instead) # report_safe 1 # Set which networks or hosts are considered 'trusted' by your mail # server (i.e. not spammers) # 187

188 trusted_networks redes_confiables # Set file-locking method (flock is not safe over NFS, but is faster) # # lock_method flock # Set the threshold at which a message is considered spam (default: 5.0) # required_score 4.5 # Use Bayesian classifier (default: 1) # use_bayes 1 # Bayesian classifier auto-learning (default: 1) # bayes_auto_learn 1 # Set headers which may provide inappropriate cues to the Bayesian # classifier # bayes_ignore_header X-Bogosity bayes_ignore_header X-Spam-Flag bayes_ignore_header X-Spam-Status dns_available yes score BAYES_00 0 score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ score BAYES_ # Sender y Recipient del propio dominio header SENDER_DOMAIN_00 From =~ /mi\.dominio/i header RECIPIENT_DOMAIN_00 ALL =~ /for.*mi\.dominio/i meta FROM_REMOTE_WITH_OWN_DOMAIN_00 ( SENDER_DOMAIN_00 && RECIPIENT_DOMAIN_00) score FROM_REMOTE_WITH_OWN_DOMAIN_ Relanzar el servicio service amavisd reload 188

189 Configurar filtro Anti-Virus en la pasarela Instalar el paquete: aptitude install clamav-daemon Editar el fichero /etc/amavis/conf.d/15-content_filter_mode y descomentar las lineas referentes al filtro de = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \ $bypass_virus_checks_re); Añadir el usuario clamav al grupo amavis usermod -G amavis clamav Relanzar el servicio service amavisd reload Actualizar las bases de datos de clamav: /usr/bin/freshclam --quiet -l /var/log/clamav/freshclam.log En caso de estar detrás de un proxy modificar las variables HTTPProxyServer, HTTPProxyPort, HTTPProxyUsername y HTTPProxyPassword en el fichero /etc/clamav/freshclam.conf. Para hacer actualizaciones periódicas del clamav, ejecutar el siguiente comando: echo "25 1 * * * /usr/bin/freshclam --quiet -l /var/log/clamav/freshclam.log">>/var/spool/cron/crontabs/root 189

190 En Red Hat Instalar el paquete: yum install postfix En un momento de la instalación aparecerá la siguiente pantalla: 190

191 Seleccionar la opción Satellite system. A continuación introducir el nombre del dominio al que pertenecerá la pasarela. En caso de que este sea el servidor de correo expuesto al exterior (accesible desde Internet) se debe dejar esta línea en blanco. 191

192 Editar la configuración en el fichero /etc/postfix/main.cf. Los campos marcados en negrita deben ser cambiados en función de la infraestructura. myhostname = nombre_completo_maquina mydomain = dominio # Esta variable queda libre para que funcione como PASARELA DE CORREO mydestination = smtpd_banner = $myhostname ESMTP biff = no mynetworks = ,dirección_IP_Back_End_Correo relayhost = relay_domains = hash:/etc/postfix/relay_domains transport_maps = hash:/etc/postfix/transport relay_recipient_maps = hash:/etc/postfix/recipt # appending.domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:$ {data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/tls_readme.gz in the postfix-doc package for # information on enabling SSL in the smtp client. alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = ipv4 192

193 Como se puede apreciar, se hace referencia a tres ficheros cuyo uso y contenido se explica a continuación: /etc/postfix/relay_domains En este fichero se deben especificar únicamente los dominios a los que vamos a hacer relay, es decir el correo que debe entrar desde Internet por la pasarela. El formato del mismo debe ser: mi.dominio OK miotro.dominio OK /etc/postfix/transport En este fichero se deben especificar las resoluciones de los Back End de los dominios a los que vamos a hacer relay. El formato del mismo debe ser: miotro. dominio smtp:[ip_servidor] mi.dominio smtp:[ip_servidor] /etc/postfix/recipt En este fichero se deben especificar únicamente los usuarios que podrán recibir correo del exterior gracias a la pasarela. (En general este fichero se debe actualizar periódicamente contra el directorio activo del dominio en cuestión). El formato del mismo debe ser: usuario1@mi.dominio OK usuario2@mi.dominio OK usuario1@miotro.dominio OK comandos: Por cada uno de estos ficheros, tras cada cambio, se deben ejecutar los postmap nombrefichero service postfix restart 193

194 Configurar filtros en la pasarela Para añadir diferentes filtros se necesita el paquete amavis. Instalar el paquete: yum install amavisd-new Comprobar que amavis está en marcha y a la escucha en el puerto Ejecutar el comando netstat -tpln grep Cambiar la configuración de postfix para aplique los filtros. Editar el fichero: /etc/postfix/main.cf y añadir: content_filter = amavis:[ ]:10024 receive_override_options = no_address_mappings Editar el fichero: /etc/postfix/master.cf y añadir: amavis unix smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes :10025 inet n smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= /8 -o strict_rfc821_envelopes=yes -o receive_override_options= \ no_unknown_recipient_checks,no_header_body_checks -o smtpd_bind_address= Editar el fichero /etc/amavisd.conf y descomentar las = (1); # controls running of anti-virus = (1); # controls running of anti-spam code 194

195 Editar el fichero /etc/amavisd.conf y descomentar las líneas $mydomain = = qw( redes_confiables ); $myhostname = 'correo.mi.dominio'; # must be a FQDN Volver a lanzar los servicios service postfix reload service amavisd restart Configurar filtro Anti-Spam en la pasarela Instalar el paquete: yum install spamassassin Para no borrar el correo que sea Spam, sino marcarlo como tal, editar el fichero /etc/amavisd.conf y dejar la siguiente directiva como sigue: $final_spam_destiny = D_PASS; También se debe comentar/borrar la siguiente = (1); # controls running of anti-spam code siguiente: Configurar SpamAssassin Crear el fichero /etc/mail/spamassassin/user-prefs.cf con el contenido header SENDER_DOMAIN_00 Return-Path =~ /mi\.dominio/i header RECIPIENT_DOMAIN_00 X-Envelope-To =~ /mi\.dominio/i meta FROM_REMOTE_WITH_OWN_DOMAIN_00 ( SENDER_DOMAIN_00 ) score FROM_REMOTE_WITH_OWN_DOMAIN_ Relanzar el servicio service amavisd reload 195

196 Configurar filtro Anti-Virus en la pasarela Instalar el paquete yum install clamd Activar el filtro Anti-Virus Editar el fichero /etc/amavisd.conf y comentar/borrar la siguiente = (1); # controls running of anti-virus code Añadir el usuario clamav al grupo amavis usermod -G amavis clamav Relanzar el servicio service amavisd reload Actualizar las bases de datos de clamav: /usr/bin/freshclam --quiet -l /var/log/clamav/freshclam.log En caso de estar detrás de un proxy modificar las variables HTTPProxyServer, HTTPProxyPort, HTTPProxyUsername y HTTPProxyPassword en el fichero /etc/clamav/freshclam.conf. Para hacer actualizaciones periódicas del clamav, añadir al cron de root la siguiente entrada: 25 1 * * * /usr/bin/freshclam --quiet -l /var/log/clamav/freshclam.log 196

197 Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servidor de correo está activo: service postfix status Comprobar que el servicio encargado del filtrado está activo (si procede): service amavisd status Comprobar que los puertos 25,10024 y están a la escucha: netstat -tpln grep :25 netstat -tpln grep :10024 netstat -tpln grep :10025 Asegurarse de que los procesos se creen en el arranque, update-rc.d postfix defaults (en Debian) update-rc.d amavisd-new defaults (en Debian, si procede) chkconfig --level 2345 postfix on (en Red Hat) chkconfig --level 2345 amavisd-new on (en Red Hat, si procede) Si se ha activado el filtro Anti-Spam Comprobar que al ejecutar el siguiente comando se recibe un con el asunto incluyendo *** SPAM *** y en las cabeceras aparecen trazas del SpamAssassin. sendmail usuario_valido@mi.dominio < /usr/share/doc/spamassassin/examples/sample-spam.txt Si se ha activado el filtro Anti-Virus Comprobar que al ejecutar el siguiente comando se recibe un y en las cabeceras aparecen trazas del antivirus (X-Virus-Scanned). servidor. sendmail usuario_valido@mi.dominio < /usr/share/doc/spamassassin/examples/sample-spam.txt Recomendación de monitorización Se puede recomendar que se monitoricen los puertos 25, y del 197

198 Instalación de un servidor de bases de datos MySQL Objetivo Este procedimiento describe el proceso de instalación de un servidor de BBDD en máquinas UNIX Procedimiento Instalación de MySQL En Debian: aptitude install mysql-server En Red Hat: yum install mysql-server Configuración del servicio Por defecto el servicio de bases de datos es accesible desde cualquier lugar, si este no es el comportamiento que se requiere, es recomendable dejarla únicamente accesible localmente. Para ello editar el fichero /etc/my.cnf y modificar una directiva para dejarla como sigue: bind-address= Arrancar el servicio service mysql start 198

199 Comprobación del procedimiento siguientes: Los pasos a seguir para realizar la comprobación de este procedimiento son los Comprobar que el servidor de correo está activo: service mysql status Comprobar que el servicio de MySQL está a la escucha en el puerto 3306: netstat -tpln grep :3306 Asegurarse de que los procesos se creen en el arranque, update-rc.d mysql defaults (en Debian) chkconfig --level 2345 mysql on (en Red Hat) Comprobar que al ejecutar el comando siguiente desde la máquina en la que se ha instalado MySQL se obtiene una conexión al servicio. mysql u root -p Se debe obtener: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3845 Server version: (Debian) Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL v2 license Type 'help;' or '\h' for help. Type '\c' to clear the current input statement Recomendación de monitorización Se puede recomendar que se monitorice el puerto 3306 del servidor. 199

200 Instalación de un servidor de bases de datos Oracle Objetivo Este procedimiento describe el proceso de instalación de un servidor de BBDD en máquinas UNIX. Atención: Antes de realizar este procedimiento cerciorarse de que se dispone de una licencia de Oracle válida para la versión que se va a instalar Procedimiento La instalación de un servidor de bases de datos Oracle en máquinas Linux únicamente está soportada para el sistema operativo Red Hat. Se presenta a continuación un procedimiento de instalación así como algunas recomendaciones de monitorización Preparación del entorno Crear el usuario oracle Logearse como root y crear el usuario oracle perteneciente al grupo dba. Para ello ejecutar los comandos: groupadd dba useradd -g dba oracle Configurar los parámetros del sistema Editar el fichero/etc/sysctl.conf y añadir al final del mismo lo siguiente: kernel.shmall = kernel.shmmax = kernel.shmmni = 4096 kernel.sem = fs.file-max = fs.aio-max-nr = net.ipv4.ip_local_port_range = net.core.rmem_default = net.core.rmem_max = net.core.wmem_default = net.core.wmem_max =

201 Para que se apliquen estos cambios, ejecutar el comando: sysctl -p Por pantalla saldrá algo parecido a esto: net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 kernel.shmall = kernel.shmmax = kernel.shmmni = 4096 kernel.sem = fs.file-max = fs.aio-max-nr = net.ipv4.ip_local_port_range = net.core.rmem_default = net.core.rmem_max = net.core.wmem_default = net.core.wmem_max = siguiente: Editar el fichero/etc/pam.d/login y añadir al final del mismo lo siguiente: session required pam_limits.so Editar el fichero /etc/security/limits.conf y añadir al final del mismo lo oracle soft nproc 2047 oracle hard nproc oracle soft nofile 1024 oracle hard nofile Crear los directorios para Oracle Ejecutar los siguientes comandos: mkdir /opt/oracle mkdir /opt/oracle/product/11.2.0/dbhome_1 chown -R oracle:dba /opt/oracle 201

202 siguiente: continuación. Configurar el entorno de Oracle Editar el fichero /home/oracle/.bash_profile y añadir al final del mismo lo ORACLE_BASE=/opt/oracle ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 ORACLE_SID=bdprueba LD_LIBRARY_PATH=$ORACLE_HOME/lib PATH=$PATH:$ORACLE_HOME/bin ORACLE_UNQNAME=bdprueba export ORACLE_BASE ORACLE_HOME ORACLE_SID LD_LIBRARY_PATH PATH ORACLE_UNQNAME Donde bdprueba es el nombre de la base de datos que se va a crear a Para que se apliquen estos cambios, ejecutar el comando:. /home/oracle/.bash_profile Preparación de la instalación Descargar e instalar los paquetes rpm necesarios para Oracle Se necesitan algunos paquetes para instalar correctamente Oracle, para comprobar si están instalados o si por el contrario hace falta instalarlos se debe ejecutar el comando siguiente: rpm -q binutils elfutils elfutils-libelf elfutils-libelf-devel \gcc gcc-c++ glibc glibc-common glibc-devel compat-libstdc++-33 \cpp make compat-db sysstat libaio libaio-devel unixodbc \unixodbc-devel sort Si por ejemplo se obtiene una salida como la que sigue: binutils compat-db compat-libstdc cpp elfutils elfutils-libelf elfutils-libelf-devel glibc glibc-common

203 libaio make el4 package gcc-c++ is not installed package gcc is not installed package glibc-devel is not installed package libaio-devel is not installed package sysstat is not installed package unixodbc-devel is not installed unixodbc rhel4.1 Quiere decir que faltan los paquetes gcc-c++, gcc, glibc-devel, libaio-devel, sysstat, unixodbc-devel. Para instalarlos se puede montar el CD de instalación en la máquina e instalar los paquetes restantes jugando con las dependencias. cd /media/cdrecorder/redhat/rpms rpm -ivh gcc-c i386.rpm gcc i386.rpm glibc\ -devel i386.rpm libaio-devel i386.rpm \ sysstat el4.i386.rpm unixodbc-devel \ 1.RHEL4.1.i386.rpm comando: Cuando se hayan instalado todos los paquetes correctamente al ejecutar el rpm -q binutils elfutils elfutils-libelf elfutils-libelf-devel \gcc gcc-c++ glibc glibc-common glibc-devel compat-libstdc++-33 \cpp make compat-db sysstat libaio libaio-devel unixodbc \unixodbc-devel sort el resultado debe ser: binutils compat-db compat-libstdc cpp elfutils elfutils-libelf elfutils-libelf-devel gcc gcc-c glibc glibc-common glibc-devel libaio libaio-devel make el4 sysstat el4 unixodbc rhel4.1 unixodbc-devel rhel

204 Descargar el software de Oracle Para ello existen dos opciones: o desde la página web de Oracle o desde el repositorio de software corporativo Descomprimir el fichero: unzip linux.i386_11gr2_database.zip Instalación de Oracle Lanzar la instalación mv database /home/oracle Conectarse mediante interfaz gráfica a la máquina como el usuario oracle y abrir un terminal, allí lanzar lo siguiente: /home/oracle/database/runinstaller 204

205 Aparecerá lo siguiente: Paso 1 Dejar en blanco si no se quiere recibir ninguna notificación y darle a Next 205

206 Paso 2 Seleccionar la opción de instalar el software de bases de datos únicamente 206

207 Paso 3 207

208 Paso 4 208

209 Paso 5 209

210 Paso 6 210

211 Paso 7 Lanzar en una consola como root los siguientes comandos: mkdir /opt/orainventory chown -R oracle:dba /opt/orainventory Una vez hecho esto volver al instalador y darle a Next 211

212 Paso 8 212

213 Paso 9 En este paso se comprueba que se cumplen con los pre-requisitos para el correcto funcionamiento de Oracle, si se cumplen todos se pasará automáticamente al paso 10. En caso contrario aparecerá una pantalla como la de abajo que indica que es lo que falla, si falta algún paquete proceder a su instalación como en el punto de este manual. Si lo que falla son los parámetros de Kernel, cambiar los valores como se explicaba en el punto de este manual. 213

214 Una vez resueltos los pre-requisitos darle a Check Again. 214

215 Paso

216 Paso 11 Es posible que solicite que se ejecuten algunos scripts, en ese caso lanzar en una consola como root los scripts solicitados. 216

217 Paso 12 Enhorabuena! La instalación de Oracle ha concluido. 217

218 Creación del listener de Oracle Paso 1 Conectarse a la máquina como el usuario oracle y ejecutar el siguiente comando: netca Aparecerá una interfaz gráfica Paso 2 218

219 Paso 3 219

220 Paso 4 En este paso se le debe dar un nombre al listener 220

221 Paso 5 221

222 Paso 6 que esté libre Por defecto Oracle usa el puerto 1521 pero se puede seleccionar cualquier otro 222

223 Paso 7 Si se quiere configurar otro listener darle a Yes, en otro caso No. Paso 8 Arrancar el listener por consola con el usuario oracle mediante el comando: lsnrctl start 223

224 Creación de una nueva base de datos Paso 1 Conectarse a la máquina como el usuario oracle y ejecutar el siguiente comando: dbca Aparecerá una interfaz gráfica Paso 2 224

225 Paso 3 225

226 Paso 4 Seleccionar la opción de crear una base de datos personalizada para tener una instalación/configuración limpia 226

227 Paso 5 Darle un nombre a la BD 227

228 Paso 6 Si se quieren habilitar las notificaciones de alerta de esta base de datos se debe activar Enable Alert Notification y configurar los 2 valores que se piden. 228

229 Paso 7 Dado que para administrar la base de datos existen por lo menos 4 usuarios de sistema se puede poner la misma contraseña para todos. Eso sí, se recomienda que la contraseña contenga por lo menos un carácter en minúscula, un carácter en mayúscula y un dígito. 229

230 Paso 8 Seleccionar donde se almacenarán los ficheros de la base de datos. 230

231 Paso 9 Si se quiere habilitar el backup automático que ofrece Oracle se debe: Conectar a la máquina como root y ejecutar lo siguiente: mkdir /opt/oracle/flash chown -R oracle:dba /opt/oracle/flash Esto creará una nueva carpeta en la que se almacenarán los backups. Activar "Specify Flash Recovery Area" y seleccionar la carpeta creada anteriormente y el tamaño máximo de dicha carpeta. También se recomienda activar "Enable Archiving" para que los logs que se vayan generando no se sobre escriban y de este modo poner hacer flash-backs a estados más antiguos. 231

232 Paso 10 A menos que la base de datos necesite por alguna razón especifica gestión de ficheros no se activará "Oracle Text". Del mismo modo, si no se necesita usar coordenadas no se debe activar la casilla "Oracle Spatial" 232

233 Paso 11 En este paso seleccionar la memoria RAM que se le quiere asignar a Oracle, el valor depende del tamaño de la BD, del número de usuarios esperados, etc

234 Paso 12 En este paso generalmente no hace falta cambiar nada 234

235 Paso 13 Se puede crear la BD, guardarla como plantilla o incluso obtener los scripts de creación de la misma. 235

236 Paso 14 Tras darle a Finish saltará esta pantalla de confirmación con los datos que se han ido insertando a lo largo del asistente. 236

237 Paso 15 Comienza la instalación... paciencia! 237

238 Paso 16 Cuando por fin acaba la instalación, aparece esta pantalla en la que se indica la URL a escribir para acceder a la herramienta de control de la BD Nota: si no se consigue conectar desde otra máquina a la consola de administración Web, revisar la configuración del firewall. 238

239 Configurar el arranque automático Para que al arrancar la máquina se inicien de modo automático las bases de datos, los listener y la consola de administración Web se deben crear los siguientes scripts: Iniciar las bases de datos y los listener Como usuario root editar el fichero /etc/oratab y cambiar de N a Y el último carácter de la línea con la base de datos a arrancar, por ejemplo: bdprueba:/opt/oracle/product/11.2.0/dbhome_1:y Editar como usuario root el fichero /etc/init.d/oracle y escribir en él lo siguiente: #!/bin/bash # # oracle Init file for starting and stopping # Oracle Database. Script is valid for 10g and 11g versions. # # chkconfig: # description: Oracle Database startup script # Source function library.. /etc/rc.d/init.d/functions ORACLE_OWNER="oracle" ORACLE_HOME="/opt/oracle/product/11.2.0/dbhome_1" case "$1" in start) echo -n $"Starting Oracle DB:" su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/dbstart $ORACLE_HOME" echo "OK" ;; stop) echo -n $"Stopping Oracle DB:" su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/dbshut $ORACLE_HOME" echo "OK" ;; *) echo $"Usage: $0 {start stop}" esac 239

240 Una vez hecho esto ejecutar lo siguiente: chmod 750 /etc/init.d/oracle chkconfig --add oracle --level 0356 siguiente: Iniciar la consola de administración Web Editar como usuario root el fichero /etc/init.d/oraemctl y escribir en él lo #!/bin/bash # # oraemctl Starting and stopping Oracle Enterprise Manager Database Control. # Script is valid for 10g and 11g versions. # # chkconfig: # description: Enterprise Manager DB Control startup script # Source function library.. /etc/rc.d/init.d/functions ORACLE_OWNER="oracle" ORACLE_HOME="/opt/oracle/product/11.2.0/dbhome_1" case "$1" in start) echo -n $"Starting Oracle EM DB Console:" su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/emctl start dbconsole" echo "OK" ;; stop) echo -n $"Stopping Oracle EM DB Console:" su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/emctl stop dbconsole" echo "OK" ;; *) echo $"Usage: $0 {start stop}" esac Una vez hecho esto ejecutar lo siguiente: chmod 750 /etc/init.d/oraemctl chkconfig --add oraemctl --level

241 Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el servidor de BBDD está activo: service oracle status ps -ef grep pmon Comprobar que el listener está a la escucha (en nuestro caso en el puerto 1521) netstat -tpln grep : Recomendación de monitorización Se puede recomendar que se monitorice el puerto 1521 del servidor. También se puede recomendar la instalación de scripts que aseguren que el servicio pmon esté levantado, se revisen los ficheros de alertas, se generen estadísticas o se compruebe la ocupación de los tablespaces. 241

242 Servicio de sincronización de datos Objetivo Este procedimiento describe el proceso de instalación de los agentes de rsync en máquinas UNIX tanto para los clientes como para los servidores. Para realizar este procedimiento se deben de haber obtenido los siguientes datos: Nombre del servidor de rsync: IP del servidor de rsync: Nombre del/os cliente/s de rsync: IP del/os cliente/s de rsync: Instalación y configuración del servidor Instalación del servicio Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el siguiente: En Debian: aptitude install rsync En Red Hat: yum install rsync Configuración del servicio Añadir al fichero /etc/hosts una entrada por cada una de las máquinas de las que se quiere hacer backup. El formato de ese fichero es el siguiente: IP NombreMáquina Posteriormente escribir el nombre identificativo usado en /usr/local/lib/systemimager/server.list de modo que haya una máquina por línea, siguiendo este formato: NombreMáquina IP 242

243 También se debe crear el fichero de exclusiones /usr/local/lib/systemimager/nombre_del_servidor.excl para cada servidor. En él se listarán por cada línea la ruta a los directorios o ficheros que se deben excluir de la copia. Como mínimo se recomienda que el contenido del mismo sea el siguiente: # Automatic exclusions made by SystemImager. /proc/* /sys/* /dev/pts/* /dev/shm/* /proc/bus/usb/* # SELinux stuff /selinux/* # eventfs in SuSE /lib/klibc/events/* # mounted media devices not reported by mount /media/* # NFS stuff /var/lib/nfs/* # LVM caches and backups (automatically re-created at the first boot) /etc/lvm/.cache /etc/lvm/backup/* /etc/lvm/archive/* # Exclusions from --exclude on the command line. /var/log /mnt/ Crear los directorios que se usarán para los backups: mkdir -p /backup/log/images.server/ mkdir -p /backup/images.server/ 243

244 Creación de scripts de sincronización Para las tareas de lanzamientos de backups, y limpiezas posteriores se deben de crear los siguientes scripts.!/bin/bash /usr/local/bin/backup_sistemas_maquinas.sh #Arrancador para SystemImager LISTA="/usr/local/lib/systemimager/server.list" for MAQUINA in $(cat $LISTA cut -f1); do /usr/local/bin/backup_maquina.sh $MAQUINA done #!/bin/bash /usr/local/bin/backup_donlimpio.sh #Script limpiador de backups antiguos. Borra los tgz anteriores al tiempo de vida declarado. #Vida de las imagenes de SystemImager VIDAIMAGES=2 DIRIMAGES="/backup/images.server/" #Vida de los logs de backup(todos) VIDALOGS=60 DIRLOGS="/backup/log/" #Borrado de las imagenes for DIR in $DIRIMAGES; do find $DIR -maxdepth 1 -name "*.tgz" -mtime +$VIDAIMAGES -exec rm -fv {} \; done #Borrado de los logs de backup for DIR in $DIRLOGS; do find $DIR -maxdepth 3 -name "*.log" -mtime +$VIDALOGS -exec rm -fv {} \; done 244

245 #!/bin/bash /usr/local/bin/backup_maquina.sh LOG=/backup/log/images.server/sincro$1.log LOG_GENERAL=/backup/log/images.server/imagenes_`date +%d%m%y`.log echo `date ` > $LOG echo " Empieza la copia de $1 " >> $LOG rsync -ahsv --numeric-ids --delete --delete-excluded --excludefrom=/usr/local/lib/systemimager/$1.excl rsync://$1:873/root/ /backup/images.server/$1.img >> $LOG 2>> $LOG Obtener_texto() { valor=$1 lista=/usr/local/lib/systemimager/rsync.rc export valor awk -F";" '{if($1==environ["valor"]) print $2}' $lista } rc=$? case $rc in 0);; 23) echo "WARNING: => $(Obtener_texto $rc)" >>$LOG_GENERAL ;; 24) echo "WARNING: => $(Obtener_texto $rc)" >>$LOG_GENERAL ;; *) MSG=$MSG"Error (código $rc) en sincronización del modulo $modulo sobre $punto.\n\t$(obtener_texto $rc)\n" echo `date +%d%m%y` copia de la imagen de $1 incorrecta. >> $LOG_GERNERAL echo "ERROR: => $(Obtener_texto $rc)" >>$LOG_GENERAL exit ;; esac echo `date +%d%m%y` copia de la imagen de $1 correcta. >> $LOG_GENERAL rsync -av rsync://$1:873/root/root/particiones.log /images/multisectorial/log/particiones$1.log if [ $? -ne 0 ]; then echo "ERROR: Al copiar la tabla de particiones"; >> $LOG fi tar -cpzf /backup/images.server/$1.img_`date +%d%m%y`.tgz /backup/images.server/$1.img Darles permisos de ejecución a esos scripts: chmod 750 /usr/local/bin/backup_sistemas_maquinas.sh chmod 750 /usr/local/bin/backup_maquina.sh chmod 750 /usr/local/bin/backup_donlimpio.sh 245

246 Por último añadir la ejecución de los scripts /usr/local/bin/backup_sistemas_maquinas.sh y /usr/local/bin/backup_donlimpio.sh a cron con la periodicidad requerida por el proyecto Instalación y configuración del cliente Instalación del servicio #! /bin/sh En Debian: aptitude install rsync En Red Hat yum install rsync Configuración del servicio En Debian Modificar el fichero /etc/init.d/rsync para que su contenido sea el siguiente:. /lib/lsb/init-functions. /etc/default/rcs export PATH="${PATH:+$PATH:}/usr/sbin:/sbin" case "$1" in start) log_begin_msg "Starting rsync-sysimager daemon: rsync" if [ -s /var/run/rsync-sysimager.pid ] && kill -0 $(cat /var/run/rsync-sysimager.pid) >/dev/null 2>&1; then exit 0 fi if [! -s /etc/rsyncd.conf.sysimager ]; then log_failure_msg " missing or empty config file /etc/rsyncd.conf.sysimager" log_end_msg 1 exit 1 fi stop) ;; /usr/bin/rsync --daemon --config=/etc/rsyncd.conf.sysimager echo $(ps -C rsync -o pid=) >/var/run/rsync-sysimager.pid ES=$? log_end_msg $ES log_begin_msg "Stopping rsync-sysimager daemon: rsync" 246

247 kill $(cat /var/run/rsync-sysimager.pid) ES=$? rm -f /var/run/rsync-sysimager.pid log_end_msg $ES ;; restart) set +e log_begin_msg "Restarting rsync-sysimager daemon: rsync" if [ -s /var/run/rsync-sysimager.pid ] && kill -0 $(cat /var/run/rsync-sysimager.pid) >/dev/null 2>&1; then kill $(cat /var/run/rsync-sysimager.pid) sleep 1 rm -f /var/run/rsync-imager.pid /usr/bin/rsync --daemon --config=/etc/rsyncd.conf.sysimager ES=$? echo $(ps -C rsync -o pid=) >/var/run/rsync-sysimager.pid log_end_msg $ES else rm -f /var/run/rsync-imager.pid /usr/bin/rsync --daemon --config=/etc/rsyncd.conf.sysimager ES=$? echo $(ps -C rsync -o pid=) >/var/run/rsync-sysimager.pid log_end_msg $ES fi ;; *) esac log_success_msg "Usage: /etc/init.d/ {start stop restart}" exit 1 exit 0 En Red Hat Crear el fichero /etc/init.d/rsync con el siguiente contenido: #!/bin/bash # # Init file for SystemImager # # chkconfig: # description: OpenSSH server daemon # # source function library # Red Hat / VMware. /etc/init.d/functions my_log_message() { ACTION=$1 shift case "$ACTION" in 247

248 success) echo -n $* success "$*" echo ;; failure) echo -n $* failure "$*" echo ;; warning) echo -n $* warning "$*" echo ;; *) ;; esac } log_success_msg() { my_log_message success "$*" } log_failure_msg() { my_log_message failure "$*" } log_warning_msg() { my_log_message warning "$*" } export PATH="${PATH:+$PATH:}/usr/sbin:/sbin" case "$1" in start) echo -n "Starting rsync-sysimager daemon: rsync" if [ -s /var/run/rsync-sysimager.pid ] && kill -0 $(cat /var/run/rsync-sysimager.pid) >/dev/null 2>&1; then log_failure_msg " Service is already started" exit 0 fi if [! -s /etc/rsyncd.conf.sysimager ]; then log_failure_msg " missing or empty config file /etc/rsyncd.conf.sysimager" exit 1 fi stop) ;; /usr/bin/rsync --daemon --config=/etc/rsyncd.conf.sysimager echo $(ps -C rsync -o pid=) >/var/run/rsync-sysimager.pid ES=$? log_success_msg echo -n "Stopping rsync-sysimager daemon: rsync" kill $(cat /var/run/rsync-sysimager.pid) if [ $? -eq 0 ]; then rm -f /var/run/rsync-sysimager.pid 248

249 else fi ;; log_success_msg log_failure_msg "Service is already stopped" restart) set +e echo -n "Restarting rsync-sysimager daemon: rsync" if [ -s /var/run/rsync-sysimager.pid ] && kill -0 $(cat /var/run/rsync-sysimager.pid) >/dev/null 2>&1; then kill $(cat /var/run/rsync-sysimager.pid) sleep 1 rm -f /var/run/rsync-imager.pid /usr/bin/rsync --daemon --config=/etc/rsyncd.conf.sysimager ES=$? echo $(ps -C rsync -o pid=) >/var/run/rsync-sysimager.pid log_success_msg $ES else rm -f /var/run/rsync-imager.pid /usr/bin/rsync --daemon --config=/etc/rsyncd.conf.sysimager ES=$? echo $(ps -C rsync -o pid=) >/var/run/rsync-sysimager.pid log_success_msg $ES fi ;; *) esac echo "Usage: /etc/init.d/ {start stop restart}" exit 1 exit 0 Darle permisos de ejecución chmod 755 /etc/init.d/rsync Añadir este proceso al arranque de la máquina con el siguiente comando: chkconfig --add rsync En Debian y Red Hat Crear el fichero /etc/rsyncd.conf.sysimager con el siguiente contenido # Rsync config for SystemImager list = yes timeout = 900 dont compress = *.gz *.tgz *.zip *.Z *.ZIP *.bz2 *.deb *.rpm *.dbf uid = root gid = root hosts allow = /24 IP_servidor_rsync/32 [root] path = / 249

250 Crear el fichero /usr/local/bin/particiones.sh con el siguiente contenido #!/bin/bash # Saber cuales son las particiones y el tamaño de ellas. echo " Servidor `uname -n` a fecha "`date +%d%m%y` echo Datos de df; echo "#################################################################### ##" df -h echo Datos de fstab echo "#################################################################### ##" cat /etc/fstab echo Datos físicos del disco echo "#################################################################### ##" fdisk -l Por último añadir la ejecución del siguiente comando a cron con la periodicidad requerida por el proyecto. /usr/local/bin/particiones.sh > /root/particiones.log Iniciar el servicio service rsync start 250

251 Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el servicio de rsync está activo tanto en el servidor como en los clientes: ps -ef grep rsync Comprobar que el servicio está a la escucha tanto en el servidor como en los clientes: netstat -tpln grep : Recomendación de monitorización Para los clientes se puede recomendar la monitorización del puerto 873. Para el servidor se puede monitorizar los logs de rsync. 251

252 Instalación del analizador de vulnerabilidades Nessus Objetivo Este procedimiento describe el proceso de instalación del analizador de vulnerabilidades Nessus en máquinas UNIX. Atención: Antes de realizar este procedimiento cerciorarse de que se dispone de una licencia de Nessus válida para la versión que se va a instalar Procedimiento Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el siguiente: Instalar el paquete Acceder a la página de descargas de Nessus, y descargar el paquete conveniente según la versión del sistema operativo. A continuación instalar dicho paquete en la máquina: En Debian: dpkg -i paquete.deb En Red Hat: rpm -ivh paquete.rpm Configuración de Nessus Crear un usuario para poder realizar los escaneos En Debian nessus-adduser En Red Hat /opt/nessus/sbin/nessus-adduser 252

253 Activar Nessus Para poder lanzar los escaneos y las actualizaciones de los plugins es necesaria la activación de este producto. Tras solicitar una licencia para uso profesional se recibirá un en el cuál se indica un código de activación a introducir mediante el siguiente comando. En Debian nessus-fetch --register CODIGO En Red Hat /opt/nessus/bin/nessus-fetch --register CODIGO En caso de encontrarse detrás de un proxy, se debe modificar el fichero: /etc/nessus/nessus-fetch.rc (en Debian), /opt/nessus/etc/nessus/nessus-fetch.rc (en RedHat): proxy=ip_proxy proxy_port=puerto_proxy proxy_username=nombreusuario proxy_password=passwordusuario Una vez activado el producto se recomienda forzar una actualización de los plugins. En Debian nessus-update-plugins En Red Hat /opt/nessus/sbin/nessus-update-plugins Arrancar el servicio Para arrancar el servicio se debe ejecutar el siguiente comando: service nessusd start 253

254 Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el puerto 8834 está activo con el proceso nessusd escuchando en él netstat -tpnl grep :8834 Si todo está correcto se puede acceder a la interfaz de nessusd mediante cualquier navegador accediendo a la URL Recomendación de monitorización Se puede recomendar que se monitorice el puerto 8834 del servidor. 254

255 Instalación del analizador de vulnerabilidades OpenVAS Objetivo Este procedimiento describe el proceso de instalación del analizador de vulnerabilidades OpenVAS en máquinas UNIX Procedimiento Para instalar los agentes en una máquina UNIX, el procedimiento a seguir es el siguiente: Instalar el paquete Acceder a la página Web de OpenVAS y seguir las instrucciones de instalación Configuración de OpenVAS Crear un usuario para lanzar los análisis: openvas-adduser Actualizar los plugins de OpenVAS (se recomiendo hacerla cada vez que se vaya a lanzar un nuevo análisis) openvas-nvt-sync Crear un certificado para el servidor openvas-mkcert Si se quiere lanzar los análisis desde otra máquina modificar el fichero /etc/default/openvas-scanner de modo que ponga: SCANNER_ADDRESS=IP_escucha SCANNER_PORT= Arrancar el servidor service openvas-server start 255

256 Puesta en marcha del cliente La versión del cliente vía Web (gracias al paquete greenbone-security-assistant) no funciona bien a día de 01/2012, así que se ha optado por procedimentar la instalación de un cliente de escritorio. La aplicación la compondrán dos elementos: el servidor, que está a la escucha en el puerto 9391, será el encargado de lanzar los análisis y los clientes que con su aplicación se conectan al servidor y realizan las peticiones de análisis. Hasta el día de hoy, las pruebas en Red Hat han sido insatisfactorias por lo que se procedimenta únicamente la instalación en Debian. Para instalar el cliente se debe ejecutar el comando aptitude install openvas-client Lanzar el cliente (se necesita tener X11 instalado) openvas-client Darle a conectar e introducir los datos del servidor: IP_servidor: Comprobación del procedimiento Los pasos a seguir para realizar la comprobación de este procedimiento son los siguientes: Comprobar que el puerto 9391 está activo con el proceso nessusd escuchando en él netstat -tpnl grep :9391 Si todo está correcto se puede acceder al servidor mediante el cliente openvas-client Recomendación de monitorización Se puede recomendar que se monitorice el puerto 9391 del servidor. 256

257 Instalación de servicio de actualizaciones de Sistema Operativo Objetivo Este procedimiento describe el proceso de instalación de repositorios internos para las empresas que tengan máquinas Unix. Nota: Antes de comenzar el procedimiento cerciorarse de que se cuenta con suficiente espacio para albergar una copia de un repositorio (80GB) Atención: Antes de realizar este procedimiento cerciorarse de que se dispone de una licencia válida de Red Hat para todos y cada uno de los servidores que se van a configurar para que se actualicen a través del servidor principal Procedimiento Para instalar los agentes en una máquina Unix, el procedimiento a seguir es el siguiente: Instalar el paquete En Debian: aptitude install apt-mirror En Red Hat: yum install yum-utils 257

258 Configurar el repositorio Para que el repositorio sea accesible por las máquinas de la red, se debe un servidor Web. Seguir el procedimiento instalación de un servidor Web para ello. En Debian Editar el fichero /etc/apt/mirror.list para listar los repositorios de los que se quiere ser replica. El formato del fichero es el siguiente: ############# config ################## # set base_path /var/spool/apt-mirror set mirror_path $base_path/mirror set skel_path $base_path/skel set var_path $base_path/var set cleanscript $var_path/clean.sh set defaultarch <running host architecture> set postmirror_script $var_path/postmirror.sh set run_postmirror 0 set nthreads 20 set _tilde 0 # ############# end config ############## deb squeeze main contrib non-free deb-src squeeze main contrib non-free Si la máquina se encuentra detrás de un proxy crear el fichero /var/spool/aptmirror/.profile y añadir la línea: export http_proxy=usuario:password@ip_proxy:puerto_proxy Añadir al cron de apt-mirror la siguiente entrada: 00,15,30,45 * * * * apt-mirror >> /var/spool/apt-mirror/cron.log Crear un enlace al repositorio para que sea accesible vía Web: ln -s /var/spool/apt-mirror/mirror/ftp.es.debian.org/debian/ /var/www/debian 258

259 En Red Hat Ejecutar los siguientes comandos: mkdir -p /var/www/html/repo/packages createrepo -v /var/www/html/repo reposync -p /var/www/html/repo/ Nota: Por defecto el comando reposync realiza una copia de todos los repositorios que se encuentren configurados para yum, aunque se puede parametrizar con la opción -r. Añadir al cron de root la siguiente entrada: 00,15,30,45 * * * * reposync -p /var/www/html/repo/ >> \ /var/log/reposync.log Configurar las actualizaciones del servidor Para hacer que el servidor se actualice con su propio repositorio y no contra Internet se debe cambiar la configuración de los gestores de paquetes. En Debian: Editar el fichero /etc/apt/sources.list y añadir las siguientes líneas: deb file:/var/spool/apt-mirror/mirror/ftp.es.debian.org/debian/ \ squeeze main contrib non-free A su vez se deben eliminar de ese fichero todos los repositorios que ya se estén sincronizando con apt-mirror. En Red Hat: Editar el fichero /etc/yum.repos.d/local.repo y añadir las siguientes líneas: [base] name=redhat-$releasever - Base baseurl=file:/var/www/html/repo/$releasever/os/$basearch/ protect=1 priority=1 enabled=1 A su vez se deben eliminar del directorio /etc/yum.repos.d/ los repositorios que ya se estén sincronizando con yum. 259

260 Configurar las actualizaciones de los clientes Por defecto los sistemas tienen configurados los repositorios de Internet, se deben realizar algunos cambios para que realicen sus actualizaciones e instalaciones a través del servidor de actualizaciones local. En Debian: Editar el fichero /etc/apt/sources.list y dejar únicamente la siguiente línea: deb squeeze main A su vez se pueden añadir todos los repositorios que estén sincronizando con el servidor de actualizaciones. En Red Hat: Editar el fichero /etc/yum.repos.d/local.repo y añadir las siguientes líneas: [base] name=redhat-$releasever - Base baseurl= \ $basearch/ protect=1 priority=1 enabled=1 A su vez se pueden añadir todos los repositorios que estén sincronizando con el servidor de actualizaciones y borrar el resto de repositorios que estén configurados para acceder a Internet. 260

261 Comprobación del procedimiento Para comprobar que todo está en funcionamiento realizar lo siguiente: Comprobar que se ha creado una copia local de los repositorios: du -sh /var/spool/apt-mirror (en Debian) du -sh /var/www/html/repo (en Red Hat) El resultado debe ser de unos cuantos GB. Comprobar que se ha configurado bien la actualización del servidor y cliente: aptitude update yum check-update (en Debian) (en Red Hat) Recomendación de monitorización Se puede recomendar que se monitoricen los logs de los servicios de actualizaciones (apt-mirror y reposync) 261

262 Instalación de servicios colaborativos A continuación se presentan una serie de procedimientos para la instalación de diferentes herramientas Web colaborativas. En concreto se presentan tres herramientas colaborativa de Software Libre que vienen muy bien en entornos empresariales. De hecho antes de ofrecerse en el Catálogo de servicios han estado en pruebas en Ibermática pasando posteriormente a ser utilizadas como herramientas corporativas. Para la instalación de estas herramientas se requiere de un Servidor Web con MySQL y PHP, consultar el procedimiento de instalación correspondiente Instalación de MediaWiki El procedimiento es el siguiente: Instalar el paquete En Debian aptitude install mediawiki En Red Hat En Red Hat, Mediawiki no se encuentra en los repositorios oficiales como ocurre en Debian. Por lo tanto se debe descargar el paquete e instalarlo manualmente. comandos: Descargar el paquete desde la siguiente URL: Transferir ese fichero al directorio /tmp del servidor. Y ejecutar los siguientes cd /var/www tar -zxf /tmp/mediawiki-version.tar.gz ln -s mediawiki-version/ mediawiki rm /tmp/mediawiki-version.tar.gz 262

263 Configurar apache En Debian: Cambiar el fichero /etc/apache2/conf.d/mediawiki.conf y descomentar la línea Alias /mediawiki /var/lib/mediawiki Reiniciar apache: service apache2 reload En Red Hat: Reiniciar apache: service httpd reload Preparar la base de datos Ejecutar el siguiente comando: mysql -u UsuarioAdministrador -h IP_Servidor_MySql -p Solicitará la contraseña del UsuarioAdministrador, tras introducirla ejecutar los siguientes comandos dentro de la consola de MySQL. create database wikidb; CREATE USER 'wikiuser'@'localhost' IDENTIFIED BY 'password'; GRANT ALL ON wikidb.* TO 'wikiuser'@'localhost'; exit 263

264 Instalación de MediaWiki Acceder al servidor mediante el navegador Web a la URL: Darle a Set up the wiki para verificar que se cumple con los requisitos de la instalación. En caso de no cumplir con los requisitos corregirlos y volver a lanzar la instalación. Tras esto aparecerá la siguiente pantalla: 264

265 Personalizar la configuración, introducir los datos de la base de datos que se ha configurado previamente: Al terminar se obtendrá el siguiente mensaje: Installation successful! Move /var/lib/mediawiki/config/localsettings.php to /etc/mediawiki, then follow this link to your wiki. You should change file permissions for LocalSettings.php as required to prevent other users on the server reading passwords and altering configuration data. Volver a la consola y ejecutar los siguientes comandos: En Debian: mv /var/lib/mediawiki/config/localsettings.php /etc/mediawiki/ chmod 600 /etc/mediawiki/localsettings.php En Red Hat: chmod 600 /etc/mediawiki/localsettings.php 265

266 Comprobación del procedimiento Para comprobar que la instalación ha ido bien acceder mediante un navegador a la URL: Se debe obtener la siguiente pantalla: Activar LDAP En este tipo de herramientas es interesante la integración con el Active Directory para la autenticación de los usuarios Acceder a la URL Seleccionar la extensión que se quiere añadir a mediawiki, en este caso LdapAuthentication y darle a continue Seleccionar la versión instalada de MediaWiki y darle a continue Descargar el paquete y dejar su contenido en el directorio /tmp. Ejecutar los siguientes comandos: chmod 600 /etc/mediawiki/localsettings.php tar xf /tmp/ldapauthentication-version.tar.gz -C \ /var/lib/mediawiki/extensions/ rm /tmp/ldapauthentication-version.tar.gz 266

267 Editar el fichero /var/lib/mediawiki/localsettings.php y añadir al final del mismo reemplazando todos los datos en negrita en función del entorno: # Mis extensiones #LDAP Autentication require_once( 'extensions/ldapauthentication LdapAuthentication.php' ); $wgauth = new LdapAuthenticationPlugin(); $wgldapdomainnames = array( "bcbl" ); $wgldapservernames = array( "bcbl"=>"pfc.bcbl.local"); $wgldapsearchstrings = array( "bcbl"=>"bcbl\\user-name" ); $wgldapencryptiontype = array( "bcbl"=>"none" ); $wgminimalpasswordlength = 1; $wgldapuselocal = true; $wgldapbasedns = array( "bcbl"=>"dc=bcbl,dc=local" ); $wgldapsearchattributes = array( "bcbl"=>"samaccountname" ); # Fin Mis extensiones 267

268 Instalación de DotProject Descargar el software Acceder a darle a Download y dejarlo en el directorio /tmp y ejecutar los siguientes comandos: cd /tmp unzip -x dotproject.zip mkdir /var/lib/dotproject mv dotproject/* /var/lib/dotproject/ chown www-data:www-data -R /var/lib/dotproject rm /tmp/dotproject.zip En Debian: Crear el fichero /etc/apache2/conf.d/dotproject.conf con el contenido: Alias /dotproject /var/lib/dotproject <Directory /var/lib/dotproject/> Options +FollowSymLinks AllowOverride All order allow,deny allow from all </Directory> Reiniciar apache: service apache2 reload En Red Hat: Editar el fichero /etc/httpd/conf/httpd.conf y añadir las siguientes líneas: Alias /dotproject /var/lib/dotproject <Directory /var/lib/dotproject/> Options +FollowSymLinks AllowOverride All order allow,deny allow from all </Directory> Reiniciar apache: service httpd reload 268

269 Preparar la base de datos Ejecutar el siguiente comando: mysql -u UsuarioAdministrador -h IP_Servidor_MySql -p Solicitará la contraseña del UsuarioAdministrador, tras introducirla ejecutar los siguientes comandos dentro de la consola de MySQL. create database dotproject; CREATE USER IDENTIFIED BY 'password'; GRANT ALL ON dotproject.* TO exit Instalación de dotproject Acceder al servidor mediante el navegador Web a la URL: Aparece lo siguiente: Y automáticamente se redirige a una página en la que se muestra si se cumplen o no los requisitos mínimos de la instalación. Una vez se hayan corregido los errores que hubieran podido aparecer darle a Start Installation 269

270 En la siguiente pantalla se deben especificar los parámetros de acceso a la base de datos y darle a Install db & write cfg Una vez acabada la instalación se recibirá el siguiente mensaje: 270

271 Comprobación del procedimiento Para comprobar que la instalación ha ido bien acceder mediante un navegador a la URL: Se debe obtener la siguiente pantalla: Acceder mediante las credenciales admin/passwd Activar LDAP En este tipo de herramientas es interesante la integración con el Active Directory para la autenticación de los usuarios Ir al apartado System Admin y luego a System Configuration 271

272 Rellenar los campos como sigue: Se necesita un usuario (al cual se ha llamado en este ejemplo usuario ) con permisos para hacer consultas sobre todos los usuarios que se quieran conectar a dotproject. Darle a Save y los usuarios ya podrán conectarse mediante LDAP. 272

273 Instalación de TeamPass Descargar el software Acceder a darle a Download y dejarlo en el directorio /tmp, a continuación ejecutar los siguientes comandos: cd /tmp unzip -x master.zip mkdir /var/lib/teampass mv nilsteampassnet-teampass-version/* /var/lib/teampass/ chown www-data:www-data -R /var/lib/teampass rm /tmp/master.zip En Debian: Crear el fichero /etc/apache2/conf.d/teampass.conf con el contenido: Alias /teampass /var/lib/teampass <Directory /var/lib/teampass/> Options +FollowSymLinks AllowOverride All order allow,deny allow from all </Directory> Reiniciar apache: service apache2 reload En Red Hat: Editar el fichero /etc/httpd/conf/httpd.conf y añadir las siguientes líneas: Alias /teampass /var/lib/teampass <Directory /var/lib/teampass/> Options +FollowSymLinks AllowOverride All order allow,deny allow from all </Directory> Reiniciar apache: service httpd reload 273

274 Preparar la base de datos Ejecutar el siguiente comando: mysql -u UsuarioAdministrador -h IP_Servidor_MySql -p Solicitará la contraseña del UsuarioAdministrador, tras introducirla ejecutar los siguientes comandos dentro de la consola de MySQL. create database teampass; CREATE USER IDENTIFIED BY 'password'; GRANT ALL ON teampass.* TO exit Instalación de TeamPass Acceder al servidor mediante el navegador Web a la URL: Aparece lo siguiente: 274

275 Pulsar sobre la casilla I've read and I accept the License y darle a Next. Escribir la ruta en la que se encuentra instalado TeamPass y la URL de acceso y pulsar sobre Launch. En caso de error con la línea PHP PHP extension "mcrypt" ir a la línea de comando y ejecutar: En Debian: aptitude update aptitude install php5-mcrypt service apache2 restart En Red Hat: yum install php-mcrypt service httpd restart Tras esto pulsar en Launch y luego en Next 275

276 en Next Introducir los datos de conexión a la base de datos y pulsar en Launch y luego El parámetro Table Prefix sirve para fijar el prefijo con el cuál se crearán las tablas que TeamPass necesita en base de datos. El parámetro Encryption Key sirve para definir una clave mediante la cuál se cifrarán las contraseñas y se guardarán en la base de datos. Evidentemente esta clave ha 276

277 de ser fuerte. El resto de parámetros sirven para definir los parámetros que necesita TeamPass para realizar las notificaciones a los usuarios de la herramienta. Una vez completados los parámetros pulsar en Launch y luego en Next. 277

278 Tras unos pasos en los que hay que limitarse a pulsar en Launch y luego en Next aparecerá la siguiente pantalla: Comprobación del procedimiento Para comprobar que la instalación ha ido bien acceder mediante un navegador a la URL: Se debe obtener la siguiente pantalla: Acceder con las credenciales admin/admin 278

279 Activar LDAP En este tipo de herramientas es interesante la integración con el Active Directory para la autenticación de los usuarios Ir al apartado Settings, luego a la pestaña LDAP options y activar LDAP haciendo click en Yes. Rellenar los campos como sigue: Darle a Save y los usuarios ya podrán conectarse mediante LDAP. 279