Autenticação LDAP do OpenBSD - alto uso de CPU do ypldap

0

Eu tenho um servidor OpenBSD com login_ldap , ypldap, ypbind e portmapper são configurados de acordo com esses guias que eu consegui encontrar com cortesia do Google.

Para os usuários remotos do LDAP, não encontrei uma maneira de criar automaticamente o diretório home para os usuários, mas o usuário remoto pode efetuar login no servidor do OpenBSD sem problemas. Se eu criar o diretório home manualmente, parece fazer o truque.

Mas eu tenho um problema com o ypldap. Parece que o ypldap está acumulando conexões com o servidor LDAP ao longo do tempo. Logo após a reinicialização, há apenas uma conexão estabelecida, mas quando o servidor está funcionando há algumas horas, talvez haja 10-15 conexões estabelecidas e, após 24 horas, pode haver 40-50. Em algum lugar durante esse período, o serviço ypldap está começando a usar toda a CPU disponível. Como o servidor não é usado para nada além de testes agora, o "cliente ypldap: ldap" está usando 99,9% da CPU.

Alguém tem alguma idéia de por que isso está acontecendo, é um problema de configuração ou provavelmente um bug?

    
por kongekrabben 03.03.2018 / 23:53

1 resposta

0

Tente com o OpenBSD 6.1 / OpenLDAP 2.4.44, funciona bem para mim - quando eu atualizei para o OpenBSD 6.2 / OpenLDAP 2.4.45 eu tive o mesmo problema com o ypldap, a quantidade de conexões ldap continua crescendo e quão rápido depende do que é ldap read interval value especificado no arquivo ypldap.conf. Isso soa como um bug para mim.

Atualização, este foi realmente um bug na versão estável do OpenBSD 6.2. Muito obrigado ao Stu do openbsd group que me avisou sobre isso. Tomei o seu conselho e consegui trabalhar. Isto é o que ele disse: "Um vazamento de filedescriptor em ypldap foi corrigido após 6.2. Se você tem uma verificação CVS da árvore de fontes 6.2, você pode tentar atualizar apenas /usr/src/usr.sbin/ypldap para -current (mude para o diretório, cvs up -PdA) então reconstruindo (make obj; make; doas make install). "

    
por 19.03.2018 / 15:08