Este comportamento LDAP normal está no CentOS Linux?

Question

Olá pessoal!

Como novato no mundo Linux, consegui aprender o suficiente para colocar em produção um servidor ClearOS 5.2 executando o CentOS Linux Distro. Esta caixa serve como meu controlador de domínio primário, servidor LDAP e servidor OpenVPN, bem como todos os serviços relacionados (compartilhamento de arquivos, etc). Tudo funciona bem, exceto que ultimamente tenho notado o seguinte:

Estou vendo muito as duas linhas a seguir durante a reinicialização do servidor:

Sep 30 02:02:23 server1 dbus-daemon: nss_ldap: failed to bind to LDAP server ldap://localhost: Can't contact LDAP server
Sep 30 02:02:23 server1 dbus-daemon: nss_ldap: could not search LDAP server - Server is unavailable

Usando htop , estou vendo várias instâncias do slapd sendo executadas simultaneamente (consulte a imagem anexada):

Também vejo muito as duas linhas seguintes em / var / log / messages:

Sep 30 02:02:32 server1 dbus-daemon: nss_ldap: failed to bind to LDAP server ldap://localhost: Can't contact LDAP server
Sep 30 02:02:32 server1 dbus-daemon: nss_ldap: could not search LDAP server - Server is unavailable

Como mencionei anteriormente, o servidor está funcionando bem. Eu esperaria que a autenticação de domínio estivesse falhando se o servidor LDAP não pudesse ser alcançado (como o log aponta), mas esse não é o caso. Eu tenho um ambiente de 50 estações de trabalho com alguns laptops e todos os meus usuários podem fazer o login e se conectar aos compartilhamentos sem nenhum problema. Além disso, as cargas do servidor (conforme exibido por htop ) parecem muito boas para mim.

Então, eu acho que minha pergunta é, isso é um comportamento normal ou eu deveria estar preocupado?

    

Answer 1

Isso não é um comportamento normal. Além disso, sua captura de tela é pequena demais para ser lida.

Tente fazer telnet para a porta 389. Se você puder se conectar, isso significa que provavelmente não é um problema de porta. Se você não consegue se conectar, isso significa que alguma outra coisa está assumindo essa porta ou que você tem um problema de firewall / selinux.

Se for um problema de firewall, desligue o selinux ou configure o selinux corretamente se você o tiver. Então verifique se o iptables tem a porta 389 aberta.

Se não for um problema de firewall, você precisará iniciar o slapd mais cedo em seus scripts crontab / init.d:

Primeiro, edite a linha chkconfig em /etc/rc.d/init.d/slapd to chkconfig: - 27 73 , escreva, saia e, em seguida:

chkconfig --del slapd
chkconfig slapd on
service slapd stop
service slapd start

Você pode testar seu servidor LDAP usando uma ferramenta de consulta LDAP, como: ldapadmin link

Se você conseguir se conectar, então parabéns, está funcionando como deveria. Se você não conseguir se conectar, isso provavelmente significa que seu serviço slapd está sobrecarregado.

Quando você usar htop, realce todo o texto na tela com o mouse, copie-o para um arquivo de texto e cole-o na sua pergunta aqui.

Tente ver se o seu slapd tem usuários autenticando:

getent passwd

Se você receber uma lista de usuários do ldap, isso significa que o serviço slapd está funcionando, mas está sobrecarregado e causando o seu problema. Não consigo ver os resultados do seu htop, por isso não posso dizer se isso faz sentido ou não.

Observação: suas estações de trabalho podem ter credenciais armazenadas em cache se forem caixas do Windows; o que significa que eles podem não estar autenticando em relação ao servidor LDAP após a primeira vez (eles podem tentar novamente mais tarde, mas nem sempre).