Que coisas estão bagunçadas depois da reinicialização no Linux? Problema muito estranho: LDAPS pára de funcionar somente após a reinicialização

Question

Eu tenho um instantâneo de VM virtualbox Centos 6.3 com configuração LDAPS (openldap). Eu configurei isso alguns dias atrás seguindo dicas de diferentes fontes e escrevi tudo depois. Mas quando tento repetir a instalação (seguindo minhas próprias instruções), não consigo fazer isso: o handshake de SSL é descartado como se o servidor tivesse configurado erroneamente certificados SSL. Parece que eu apontei a configuração do servidor para um arquivo de certificado inexistente. Estou executando todas as verificações localmente (usando ldapsearch e "openssl s_client"). Para tornar as coisas ainda piores, os LDAPS no meu instantâneo param de funcionar com o mesmo problema após a reinicialização. Reiniciar os serviços slapd / nslcd / nscd sem reinicializar não o quebra 0_o Copiar configurações exatas e certs para limpar (sem a instalação de LDAPS) a captura instantânea da mesma VM e a configuração adequada não funciona. É por isso que o problema parece não estar relacionado à configuração e aos certificados. Eu passei cavando mais de 10 horas, mas ainda tenho um strong desejo de entender a causa.

É importante (educacional) para mim entender por que esse problema ocorre somente após a reinicialização e não após a reinicialização do serviço. Por favor, sinta-se livre para postar qualquer idéia de coisas que são redefinidas para padrão / esmagado / confuso quando o host do Linux for reinicializado. Em outras palavras, de que maneira a reinicialização do sistema pode diferir da reinicialização do serviço no escopo de um serviço separado capturado em uma captura instantânea da VM?

Eu já verifiquei:

• Claro, logs / netstat / ps
• um diretório tmp (ele é limpo a cada reinicialização, mas não contém arquivos relacionados)
• variáveis de ambiente
• date (no snapshot, a data está errada. Corrigir data e reiniciar os serviços não quebra o LDAPS)
• hostname / ip (estou usando o IP atribuído manualmente para esta instância. Após reiniciar e restaurar as configurações de rede, tentei reiniciar os serviços sem êxito)
• argumentos de serviço e arquivo slapd.args no diretório / var / run
• escrevendo lixo em arquivos de configuração de um serviço e o reiniciando para ver se exatamente esse arquivo é usado.
Os arquivos
• / etc / env / .bashrc / .bash_aliases NÃO foram modificados e não devem interferir.

Talvez o SELinux seja uma causa (talvez tenha sido desativado no instantâneo, verifique amanhã no trabalho)

Alguma outra sugestão? Muito cansado para lutar ainda mais hoje ...

    

Answer 1

O problema foi realmente causado pelo SELinux de uma maneira complicada.

Para pessoas futuras que encontrarão esta resposta pelo google, aqui está um texto de erro exato:

[root@va21 ~]# ldapsearch -d 1 -v -x -H ldaps://localhost:636
ldap_url_parse_ext(ldaps://localhost:636)
ldap_initialize( ldaps://localhost:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://localhost:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)'                 certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/openldap/certs prefix .
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

e abre a saída s_client:

[root@va21 ~]# openssl s_client -connect localhost:636 -showcerts
CONNECTED(00000003)
140066435413832:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake     failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 113 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Isso significa (deve significar!) que os certificados ssl não estão disponíveis / legíveis / acessíveis / válidos quando o servidor slapd é inicializado.

Eu estava preparando a imagem da VM para o teste de controle de qualidade de alguns aplicativos. Este aplicativo desativa o SELinux durante a instalação. Então, eu tive o SELinux desativado durante a configuração do openldap e não tive nenhum problema quando os certificados foram colocados na pasta / certs.

Meus problemas começaram quando tive que implantar o openldap com a mesma configuração em uma VM limpa ou reinicializar um já existente. O SELinux foi habilitado aqui e impediu que o slapd lesse certificados do lugar não permitido. Os registros de serviço ou a saída não continham nenhuma reclamação clara sobre a negação de permissão. Eu deveria colocar os certificados em algum lugar em / etc / ssl / certs / e / etc / openldap / certs para que funcione.

    

Answer 2

As conexões SSL com falha geralmente são causadas pelo momento em que estão fora de sincronia. As VMs tendem a fazer isso, portanto, certifique-se de executar o ntpd em todas as suas MVs e que um ntpdate seja executado na inicialização antes do início do ntpd.