O console do Linux não pode ser usado quando o servidor LDAP está inativo

Question

Quando nosso servidor OpenLDAP perdeu energia, o console das máquinas CentOS ficou quase inutilizável.

Estávamos tentando fazer login com uma conta local, mas cada comando levaria alguns minutos para retornar. Até mesmo comandos simples como ls estavam lá.

Isso não parece ser um problema com a mesma configuração no Ubuntu. Demora um tempo para o login inicial ter sucesso para a conta local, mas quando você está em tudo funciona.

Estou procurando uma maneira de atenuar o problema e desenvolvi algumas ideias:

• Defina um valor de tempo limite (se houver) para o módulo ldap-pam
• Executa um banco de dados local do ldap e autentica com isso (seria um escravo do principal)
• Crie uma tarefa cron para ativar / desativar se perdermos a conectividade com o servidor ldap

Existe alguma solução melhor para gerenciar algum tipo de redundância / failover com o LDAP?

    

Answer 1

Você tem várias opções.

Usamos a replicação para ter vários servidores LDAP na rede, ocultos atrás de um balanceador de carga. Portanto, se um deles ficar inativo, ainda temos um disponível. Usamos keepalived para nosso balanceamento de carga. Você também pode usar keepalived em uma configuração de failover, onde você tem um escravo de backup quente.

Em segundo lugar, você pode ter um servidor LDAP local em cada estação de trabalho, mas isso resultará em uma grande dor de cabeça de manutenção, pois você precisa administrar tudo isso e monitorá-los para garantir que eles estejam acompanhando a replicação. Você não quer que eles fiquem fora de sincronia.

Quando você tem um servidor escravo, certifique-se de configurar sua opção updateref para que qualquer tentativa de atualização seja enviada ao servidor mestre.

Existem várias configurações no /etc/ldap.conf que você pode usar para melhorar a situação. O mais importante é:

bind_policy soft

O padrão é "hard", que continuará tentando contatar o servidor com uma espera entre eles. Se você configurá-lo para soft, ele retornará imediatamente. Você também pode usar as opções de tempo limite para reduzir a quantidade de tempo que espera.

# Search timelimit
timelimit 30

# Bind/connect timelimit
bind_timelimit 30

    

Answer 2

Eu sei que você tem uma resposta aceita de David, mas eu gostaria de propor uma abordagem diferente aqui e compartilhar algumas das minhas experiências.

Descobri que o problema de usar bind_policy soft é que, se você não obtiver uma resposta do servidor imediatamente, por exemplo, se ele estiver ocupado ou se você tiver uma alta carga de rede, receberá uma falha no LDAP imediatamente. Para o nss_ldap, isso significa que sua pesquisa nss falhará e qualquer que seja o processo que esteja tentando usá-la, simplesmente informará que não encontrou o usuário ou o grupo que estava procurando e falhou. Isso pode ser um problema durante as operações normais quando seu servidor LDAP está ativo, o que é pior do que problemas quando o servidor está inoperante.

Encontrei uma solução mais aceitável usando as seguintes configurações:

bind_policy hard
nss_reconnect_tries 3
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 2

Dessa forma, você ainda terá uma política de conexão rígida, mas as configurações de nss_reconnect_* reduzirão drasticamente a quantidade de tempo que seu cliente LDAP gastará ao tentar obter um resultado LDAP. Isso também significa que, durante o uso normal, se ele não conseguir obter um resultado LDAP na primeira tentativa, ele tentará novamente e geralmente obterá a segunda vez. Isso significa menos falhas durante o uso normal.

No que diz respeito à execução de um servidor LDAP local em cada estação de trabalho, não recomendo isso. O que eu posso lhe indicar é nsscache . Ele foi escrito por alguns engenheiros do Google e resolve esse problema criando um cache local do banco de dados LDAP e atualizando-o de forma incremental por meio de um cron job. Você então configura sua fonte nsswitch para usar sua biblioteca em vez de nss_ldap e todas as pesquisas são locais. Isso tem a vantagem de reduzir bastante a carga do servidor LDAP e disponibilizar todas as pesquisas se a conexão com o servidor estiver inativa. Não tem a maior documentação no momento, e não está em uso generalizado, mas funciona bem e as listas de discussão são bastante responsivas.

    

Answer 3

Tivemos esse problema e nossa solução foi informar ao LDAP para não ser a fonte dos grupos necessários para a execução dos servidores. Isso é feito colocando o seguinte no final de nosso ldap.conf

# We need to ensure that various things can work without LDAP being available
# for example: booting, ssh in as root, apache ...
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,daemon,dhcp,dhcpd,games,gdm,gnats,haldaemon,hplip,irc,klog,libuuid,list,lp,mail,man,messagebus,munin,mysql,nbd,news,ntp,nut,polkituser,proxy,pulse,root,sshd,statd,sync,sys,syslog,uucp,www-data

Na página do manual nss_ldap

nss_initgroups_ignoreusers <user1,user2,...,userN>
          This option directs the nss_ldap implementation of initgroups(3)
          to return NSS_STATUS_NOTFOUND if called with a listed  users  as
          its argument.

Então, basicamente, o LDAP finge que não conhece esses usuários sem nem mesmo entrar em contato com o servidor master, então o NSS recai sobre os usuários locais e o sistema funciona bem.

Também configuramos réplicas de LDAP em vários servidores para uma abordagem de cinto e chaves.