> On 21-08-2007 10:54, Edson Marquezani Filho wrote: > > Olá pessoal. > > > > Estou com um problema com meu servidor LDAP. O log mostra > > constantemente essa mensagem: > > > > slapd[5812]: <= bdb_equality_candidates: (uniqueMember) index_param failed > > (18) > > Isso normalmente indica que algo procurou por uniqueMember > mas você não tem o índice (ou pelo menos não tem ele num estado > "utilizável"). > > > > Recentemente, a base tem ficado corrompida a ponto de parar o > > serviço, vez após vez, e já gerei toda a base novamente várias vezes. > > Isso é ruim. Você tem um grande número de usuários? Acessos? > Você está usando BDB? Você tem checkpoints definidos? Você configurou > o DB_CONFIG para os parâmetros necessários de gerência da base para > grandes quantidades de acessos/objetos?
Não, o número de usuários é pequeno, todos os registros (entre usuários, máquinas e grupos) não passam de 150. As consultas também não são muitas, embore eu esteja considerando a hipótese se algum outro processo estar fazendo consultas execessivas vezes. Estou usando BDB sim, mas não havia configurado o DB_CONFIG, embora como você mesmo já comentou aqui na lista, para pequenas quantidades de registros como essa, não é de extrema necessidade. Mesmo assim, da última vez tomei o cuidade de configurá-lo, a partir do pouco de informação que encontrei a esse respeito na internet. Ficou assim: set_lk_detect DB_LOCK_EXPIRE set_lg_max 5242880 set_cachesize 0 5242880 1 Também não tinha checkpoints, e agora tenho: checkpoint 128 15 > > Tenho esse índice definido no meu arquivo de configuração: > > index uniqueMember pres > > Porque somente pres? Porque não eq,pres? Alguma razão > em especial para estar usando uniqueMember e não member? uniqueMember não aceita o tipo de índice pres. Eu peguei esse servidor já funcionando e ainda não conhece muito bem os detalhes de LDAP, por isso nem saberia te dizer porque não "member" ao invés de "uniqueMember". O fato é que mesmo omitindo esse índice na configuração, e gerando a base do zero, a falta do índice continua a aparecer nos logs. Notei, após enviar essa mensagem, que o índice nunca funcionou corretamente, desde sempre. Só pude pensar que o problema é com o próprio LDAP, que não está gerando o índice corretamente. A versão é a 2.2.13. Mas sinceramente, também não acredito que o problema de corrupção das bases tenha relação com isso. Você acha ? > > E tenho o arquivo DB de índice no diretório da base também. > > -rw------- 1 ldap ldap 8192 Ago 21 10:51 uniqueMember.bdb > > > > Sempre quando gero novamente a base, uso o seguinte procedimento: > > - apago o conteúdo do diretório de dados do ldap > > - slapadd a partir de um ldif extraído anteriormente, seja de uma > > réplica ou do backup diário. > > - mudo o dono dos arquivos para usuário ldap > > - slapindex > > - inicio o serviço > > No Debian (etch) o dono dos arquivos é o openldap . Os > índices são gerados no momento em que você faz o slapadd e deveriam > ser consistentes. Desculpe, sei que essa é uma lista de Debian, e eu tenho servidores Debian também, com LDAP. Mas, nesse caso é um RHEL 4, não homologado (leia-se sem suporte, atualização, etc, etc). Sou plenamente contra, mas... O slapadd gera os índices sim, realmente é besteira rodar o slapindex logo em seguida. =/ > > > Apesar disso a mensagem já mencionada aparece constantemente nos > > logs e a base já se perdeu várias vezes. > > > > Alguém tem idéia do que poderia ser ? Ficaria muito grato se alguém > > pudesse ajudar. > > Versões antigas do OpenLDAP não tinham a habilidade de > indexar o uniqueMember. Além disso, o groupOfUniqueNames não é > exatamente o que a maioria das pessoas pensa com relação à > "unique", o melhor seria usar groupOfNames. > > Outro ponto, é o nss-ldap e a rfc-2307-bis, em certas > versões isso nem sempre funcionava como esperado. A lista do > OpenLDAP respondeu perguntas similares à sua algumas vezes, > você talvez encontre mais detalhes por lá também. Ok. Agradeço muito as informações, pode ter certeza que foram muito úteis. Como você sugeriu, fiz algumas mudanças e estou monitorando para ver se o problema volta a se repetir. Vou procurar a respeita na lista mencionada, que eu acredito ser a LDAP-L. É isso mesmo ? Muito obrigado.
