@@ -1751,6 +1751,83 @@ Luego de que la última playbook haya terminado su ejecución sin error, debemos
\end{enumerate}
\section{Interaccción con Openstack}
Esta sección se realizó utilizando el dashboard de Openstack...
\subsection{Ejemplo de uso}
- dos redes conectadas por un router y una máquina en cada una, ping entre ellas \\
- acceso SSH a una de las máquinas con una floating IP
\section{Inconvenientes encontrados}
\subsubsection{Bloqueo de paquetes}
En los servidores virtuales y el servidor físico las reglas por defecto del firewall de CentOS bloquean tanto el tráfico utilizado para interconectar los servicios de Openstack como el empleado para las conexiones con redes externas. Para solucionar esto de forma momentánea se eliminaron estas reglas con los comandos:
Como se mencionó en la sección de correcciones, OSA ha perdido el mantenimiento de este módulo de seguridad, por lo cual fue necesario aplicar los parches realizados para la siguiente versión (Rocky) a la utilizada en la instalación (Queens) para discontinuar el uso de dicho módulo.
\subsubsection{Percona-release en playbook setup-infrastructure}
Durante la instalación de la playbook mencionada se detecta el siguiente error a la hora de instalar los componentes del contenedor de galera :
\begin{lstlisting}[gobble=0]
warning: /var/cache/yum/x86_64/7/percona-release-x86_64/packages/qpress-11-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
The GPG keys listed for the \"Percona-Release YUM repository - x86_64\" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Failing package is: qpress-11-1.el7.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Percona
\end{lstlisting}
La solución para este problema es actualizar el paquete percona-release, dentro del contenedor de galera. Para esto se deben seguir los siguientes pasos:
\begin{enumerate}
\item Acceder por ssh al nodo infra1
\begin{lstlisting}
$ ssh root@10.0.1.11
\end{lstlisting}
\item Listar los contenedores LXC existentes hasta el momento y obtener el nombre del contenedor pertinente:
\begin{lstlisting}
$ lxc-ls galera
\end{lstlisting}
\item Acceder a dicho contenedor:
\begin{lstlisting}
$ lxc-attach -n infra1_galera_container-15357d7d
\end{lstlisting}
\item Actualizar el paquete mencionado
\begin{lstlisting}
$ yum upgrade percona-release -y
\end{lstlisting}
\item Volver a ejecutar la playbook setup-infrastructure.
\end{enumerate}
\subsubsection{Subred reservada}
Debido a que no se encuentra especificado en la documentación oficial de Openstack-Ansible, en las primeras instalaciones realizadas la subred definida para la red de tunelización (vxlan) fue la 10.0.3.0/24. Esto generaba grandes inconsistencias de red que no tenían una causa identificada claramente. Luego de un extenso análisis de la situación se logró determinar que la red creada internamente por Openstack para la comunicación entre contenedores LXC utiliza dicho rango. En función de esta observación es que se especificó el rango 10.0.10.0/24 para la red vxlan.
\section{Trabajo a futuro}
\subsubsection{Firewall}
Deshabilitar por completo la denegación de paquetes por defecto en el firewall de CentOS deja el servidor expuesto ante vulnerabilidades, lo cual para un ambiente de producción es inadmisible. Como aspecto a mejorar se propone analizar y documentar todas las conexiones HTTP realizadas por Openstack Ansible durante su instalación y en su posterior ejecución entre cada uno de los nodos involucrados. Una vez identificadas, se debe agregar en cada nodo las reglas iptables correspondientes que habiliten dichas conexiones en particular.
\\
- generar una arquitectura segura separando adecuadamente las redes de acceso \\
- brindar conexión directa a internet \\
- investigar y documentar la gestión de openstack una vez en operación \\
\section{Conclusiones}
- importancia de la herramienta openstack \\
- vital importancia de utilizar un gestor de instalación como ansible \\
- aun así adquirir los conocimientos necesarios para desplegar un datacenter con OSA no es para nada trivial (casi 500 horas de trabajo salu2)
