Procedimento para auxilio em ambientes com redundância para o MFA da CAFe versão 4.2.1
Em instalações com redundância, existem alguns passos manuais adicionais que devem ser executados. Verifique atentamente cada um dos pontos apresentados.
Uma questão importante em relação a ambientes redundantes, é que a instalação é realizada de forma diferente nos servidores secundários. Ou seja, NÃO se deve clonar a instalação do servidor principal e achar que automaticamente o servidor clonado irá operar adequadamente como secundário.
Isso acontece porque os dados precisam estar sincronizados entre as base de dados. Para garantir a sincronização de forma segura, evitando qualquer inconsistência nos dados, somente a base de dados do servidor principal opera em modo escrita.
A Figura apresenta ilustra o cenário. A base de dados no servidor secundário opera em modo somente leitura. Toda vez que o usuário está no servidor secundário e realiza alguma operação que envolve escrita na base de dados, o servidor secundário se comunica com o primário e pede para o primário realizar a escrita. Tudo que é escrito/alterado no banco de dados do servidor principal é então replicado para o banco de dados secundário.
Seguem etapas adicionais a serem realizadas após a execução dos procedimentos já descritos anteriormente.
Cópia de chaves de segurança
No servidor principal, em /opt/shibboleth-idp/credentials, copie os arquivos a seguir para a mesma pasta no servidor secundário (sobrescrevendo no secundário os arquivos existentes):
cafesealer.kver
cafesealer.jks
Acerto de /etc/hosts
Em ambientes redundantes, precisamos garantir que os componentes em cada servidor comuniquem entre si de forma adequada.
Como as configurações são realizadas através da definição do FQDN, caso o DNS resolva um IP diferente a cada vez, isso pode ser um problema.
Assim é necessário editar o arquivo /etc/hosts de cada servidor para forçar que o servidor sempre resolva para o próprio IP.
Exemplo: Suponha IDP redundante de FQDN idp.instituicao.br que tem o servidor principal com IP 1.1.1.1 e o IP do servidor secundário seja 2.2.2.2.
Para este caso hipotético, teremos:
Servidor principal - /etc/hosts terá uma entrada como:
1.1.1.1 idp.instituicao.br
Servidor secundário - /etc/hosts terá uma entrada como:
2.2.2.2 idp.instituicao.br
Nos casos em que o servidor secundário se comunica com o primário, excepcionalmente o apontamento é realizado diretamente via IP.
Por conta deste requisito, é necessário que o certificado do servidor IDP contenha no alternative names uma entrada para 1.1.1.1 (no exemplo que estamos considerando como cenário).
O exemplo a seguir como deveria ser o arquivo de configuração do certificado a ser gerado com a informação do IP no alternative names para o cenário que estamos considerando como exemplo.
Gerenciando o serviço do painel de segurança
systemctl stop mfa.service: para o serviço
systemctl status mfa.service: verifica o status do serviço
systemctl start mfa.service: inicia o serviço
Verificando os logs
Painel de segurança: /opt/dashboard/logs
Shibboleth: /opt/shibboleth-idp/logs/mfa-plugins.log (onde são logados dados específicos associados ao MFA)
Ocorreu um erro durante a execução do script, o que devo fazer?
Copie o texto de erro (copiar tudo que apareceu na tela) e encaminhe para o e-mail atendimento@rnp.br para análise do erro.