5.2.6. Alta disponibilidade e clusters

Nova opção /etc/sysconfig/pcsd para rejeitar a renegociação SSL/TLS iniciada pelo cliente

Quando a renegociação do TLS é habilitada no servidor, um cliente tem permissão para enviar um pedido de renegociação, o que inicia um novo aperto de mão. Os requisitos computacionais de um aperto de mão são mais altos em um servidor do que em um cliente. Isto torna o servidor vulnerável a ataques do DoS. Com esta correção, a configuração PCSD_SSL_OPTIONS no arquivo de configuração /etc/sysconfig/pcsd aceita a opção OP_NO_RENEGOTIATION para rejeitar renegociações. Note que o cliente ainda pode abrir múltiplas conexões a um servidor com um aperto de mão realizado em todas elas.

Um nó de cluster removido não é mais exibido no status de cluster

Anteriormente, quando um nó era removido com o comando remover nó de cluster pcs, o nó removido permanecia visível na saída de uma exibição de status pcs. Com esta correção, o nó removido não é mais exibido no status do cluster.

Os agentes de vedação podem agora ser configurados usando nomes de parâmetros mais recentes e preferidos ou nomes de parâmetros depreciados

Um grande número de parâmetros de agentes de vedação foram renomeados enquanto os antigos nomes de parâmetros ainda são suportados como depreciados. Anteriormente, os pcs não eram capazes de definir os novos parâmetros, a menos que fossem usados com a opção --force. Com esta correção, pcs agora suporta os parâmetros renomeados de agente de cerca enquanto mantém o suporte para os parâmetros depreciados.

O comando pcs agora lê corretamente o status XML de um cluster para exibição

O comando pcs executa o utilitário crm_mon para obter o status de um cluster em formato XML. O utilitário crm_mon imprime XML para saída padrão e avisos para saída de erro padrão. Anteriormente o pcs misturava XML e avisos em um único fluxo e depois não era capaz de analisá-lo como XML. Com esta correção, as saídas de erro padrão e de erro são separadas em pcs e a leitura do status XML de um cluster funciona como esperado.

Os usuários não são mais aconselhados a destruir clusters ao criar novos clusters com nós de clusters existentes

Anteriormente, quando um usuário especificava nós de um cluster existente ao executar o comando de configuração do cluster pcs ou ao criar um cluster com a interface Web pcsd, pcs relatou isso como um erro e sugeriu que o usuário destruísse o cluster nos nós. Como resultado, os usuários destruiriam o cluster nos nós, quebrando o cluster do qual os nós faziam parte, pois os nós restantes ainda considerariam os nós destruídos como parte do cluster. Com esta correção, os usuários são aconselhados a remover os nós de seu aglomerado, informando-os melhor sobre como abordar o problema sem quebrar seus aglomerados.

os comandospcs não mais pedem credenciais de forma interativa

Quando um usuário não root executa um comando pcs que requer permissão de root, o pcs se conecta ao daemon pcsd em execução local e passa o comando para ele, já que o daemon pcsd roda com permissões de root e é capaz de executar o comando. Anteriormente, se o usuário não fosse autenticado no daemon pcsd local, pcs pedia um nome de usuário e uma senha interativamente. Isto era confuso para o usuário e exigia um tratamento especial em scripts rodando pcsd. Com esta correção, se o usuário não for autenticado, então o pcs sai com um erro que aconselha o que fazer: Executar pcs como root ou autenticar usando o novo comando de autenticação local do cliente pcs. Como resultado, os comandos pcs não pedem credenciais de forma interativa, melhorando a experiência do usuário.

O daemon pcsd agora começa com seu certificado SSL padrão auto-gerado quando as políticas criptográficas estão definidas para FUTURO.

Uma configuração cripto-política de FUTURO requer que as chaves RSA em certificados SSL tenham pelo menos 3072b de comprimento. Anteriormente, o daemon pcsd não começaria quando esta política fosse definida, já que gera certificados SSL com uma chave 2048b. Com esta atualização, o tamanho da chave dos certificados SSL auto-gerados do pcsd foi aumentado para 3072b e o pcsd agora começa com seu certificado SSL auto-gerado padrão.

O serviço pcsd agora começa quando a rede estiver pronta

Anteriormente, quando um usuário configurava o pcsd para ligar-se a um endereço IP específico e o endereço não estava pronto durante a inicialização quando o pcsd tentou iniciar, então o pcsd não conseguiu iniciar e foi necessária uma intervenção manual para iniciar o pcsd. Com esta correção, o pcsd.service depende do network-online.target. Como resultado, o pcsd inicia quando a rede está pronta e é capaz de se ligar a um endereço IP.