5.2.6. Alta disponibilidad y clusters

Nueva opción /etc/sysconfig/pcsd para rechazar la renegociación SSL/TLS iniciada por el cliente

Cuando la renegociación de TLS está habilitada en el servidor, se permite a un cliente enviar una solicitud de renegociación, que inicia un nuevo apretón de manos. Los requerimientos computacionales de un handshake son mayores en un servidor que en un cliente. Esto hace que el servidor sea vulnerable a los ataques DoS. Con esta corrección, el ajuste PCSD_SSL_OPTIONS en el archivo de configuración /etc/sysconfig/pcsd acepta la opción OP_NO_RENEGOTIATION para rechazar las renegociaciones. Tenga en cuenta que el cliente puede seguir abriendo múltiples conexiones a un servidor con un handshake realizado en todas ellas.

Un nodo de clúster eliminado ya no se muestra en el estado del clúster

Anteriormente, cuando se eliminaba un nodo con el comando pcs cluster node remove, el nodo eliminado permanecía visible en la salida de una pantalla de estado de pcs. Con esta corrección, el nodo eliminado ya no se muestra en el estado del clúster.

Los agentes de la valla pueden ahora configurarse utilizando los nuevos nombres de parámetros preferidos o los nombres de parámetros obsoletos

Se ha cambiado el nombre de un gran número de parámetros del agente de la valla, mientras que los antiguos nombres de los parámetros siguen siendo soportados como obsoletos. Anteriormente, pcs no podía establecer los nuevos parámetros a menos que se usara con la opción --force. Con esta corrección, pcs ahora admite los parámetros de agente de valla renombrados mientras mantiene el soporte para los parámetros obsoletos.

El comando pcs ahora lee correctamente el estado XML de un cluster para su visualización

El comando pcs ejecuta la utilidad crm_mon para obtener el estado de un cluster en formato XML. La utilidad crm_mon imprime XML en la salida estándar y las advertencias en la salida de error estándar. Anteriormente, pcs mezclaba el XML y las advertencias en un solo flujo y no podía analizarlo como XML. Con esta corrección, las salidas estándar y de error están separadas en pcs y la lectura del estado XML de un clúster funciona como se espera.

Ya no se aconseja a los usuarios que destruyan los clusters al crear nuevos clusters con nodos de clusters existentes

Anteriormente, cuando un usuario especificaba nodos de un clúster existente al ejecutar el comando de configuración de clústeres de pcs o al crear un clúster con la interfaz web de pcsd, pcs informaba de ello como un error y sugería que el usuario destruyera el clúster en los nodos. Como resultado, los usuarios destruirían el clúster en los nodos, rompiendo el clúster del que formaban parte los nodos, ya que los nodos restantes seguirían considerando que los nodos destruidos formaban parte del clúster. Con esta corrección, se aconseja a los usuarios que eliminen los nodos de su clúster, informándoles mejor de cómo resolver el problema sin romper sus clústeres.

los comandos depcs ya no piden credenciales de forma interactiva

Cuando un usuario que no es root ejecuta un comando de pcs que requiere permiso de root, pcs se conecta al demonio pcsd que se ejecuta localmente y le pasa el comando, ya que el demonio pcsd se ejecuta con permisos de root y es capaz de ejecutar el comando. Anteriormente, si el usuario no estaba autenticado en el demonio pcsd local, pcs pedía un nombre de usuario y una contraseña de forma interactiva. Esto era confuso para el usuario y requería un manejo especial en los scripts que ejecutaban pcs. Con este arreglo, si el usuario no está autenticado, pcs sale con un error que indica qué hacer: Ejecutar pcs como root o autenticarse usando el nuevo comando pcs client local-auth. Como resultado, los comandos de pcs no piden interactivamente las credenciales, mejorando la experiencia del usuario.

El demonio pcsd ahora se inicia con su certificado SSL autogenerado por defecto cuando crypto-policies se establece en FUTURE.

Una configuración de crypto-policies de FUTURE requiere que las claves RSA en los certificados SSL tengan una longitud mínima de 3072b. Anteriormente, el demonio pcsd no se iniciaba cuando se establecía esta política, ya que genera certificados SSL con una clave de 2048b. Con esta actualización, el tamaño de la clave de los certificados SSL autogenerados por pcsd se ha incrementado a 3072b y pcsd se inicia ahora con su certificado SSL autogenerado por defecto.

El servicio pcsd ahora se inicia cuando la red está lista

Anteriormente, cuando un usuario configuraba pcsd para enlazar con una dirección IP específica y la dirección no estaba lista durante el arranque cuando pcsd intentaba arrancar, entonces pcsd fallaba al arrancar y se requería una intervención manual para arrancar pcsd. Con esta corrección, pcsd .service depende de network-online.target. Como resultado, pcsd se inicia cuando la red está lista y es capaz de vincularse a una dirección IP.