Yum Update quebrou Slapd

Question

Primeiro, eu não sou um especialista em openldap.

Eu tenho o openldap (slapd) em execução em um servidor que está funcionando há anos. Hoje corri o yum update e atualizei alguns pacotes, incluindo os pacotes openldap. Uma vez terminado (sem erros), nosso servidor LDAP não estava em execução. Eu tentei um slapd start de serviço simples (e /etc/init.d/slapd start), ambos de repente falharem.

Se eu olhar no arquivo /var/log/ldap.log , vejo estas entradas:

@(#) $OpenLDAP: slapd 2.4.40 (May 10 2016 23:30:49) $#012#[email protected]:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/build-servers/servers/slapd
read_config: no serverID / URL match found. Check slapd -h arguments.
slapd stopped.
connections_destroy: nothing to destroy.

Alguém pode oferecer sugestões?

Muito apreciado!

Atualização: esqueci de acrescentar que tanto o slapest quanto o slaptest -u são bem sucedidos:

# slaptest
config file testing succeeded
# slaptest -u
config file testing succeeded

Atualização # 2: aqui estão as versões do openldap:

openldap-clients-2.4.40-12.el6.x86_64
openldap-servers-2.4.40-12.el6.x86_64
openldap-devel-2.4.40-12.el6.x86_64
compat-openldap-2.3.43-2.el6.x86_64
openldap-2.4.40-12.el6.x86_64

Aqui também está o meu arquivo slapd.conf (que funcionou antes da atualização do yum):

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/misc.schema
include         /etc/openldap/schema/passwordSelfReset.schema

allow bind_v2

pidfile     /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args

modulepath /usr/lib64/openldap

moduleload syncprov.la
moduleload unique.la

database monitor
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
        by dn.exact="cn=admin,dc=am5up,dc=com" read
        by * none

database    bdb
suffix      "dc=am5up,dc=com"
rootdn      "cn=admin,dc=am5up,dc=com"
rootpw {SSHA}0yFFC0BTYdZLDRNtSHVz1I6YC4zJ3Z0AZ09123
directory   /var/lib/ldap

index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber               eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

overlay unique
unique_attributes mail

ServerID        1 "ldap://ldap.am5up.com"

overlay         syncprov
syncprov-checkpoint     10 1
syncprov-sessionlog     100

    

Answer 1

Para qualquer pessoa com esse problema, descobri o problema. Durante o upgrade, a versão um pouco mais recente exige que o host corresponda à definição do servidor no arquivo de configuração.

Por exemplo, no seu arquivo slapd.conf tem uma linha como:

ServerID 1 "ldap://myldapserver"

Em seguida, seu script de inicialização (ou quando você inicia o slapd) você deve definir o host como "ldap: // myldapserver".

Isso parece fazer sentido; no entanto, através dos meus problemas hoje, aprendi que o arquivo padrão /etc/init.d/slapd que foi adicionado durante a instalação inicial lista o host como em branco. Assim, o script de inicialização padrão, basicamente, executa:

slapd -h "" -u <user> -g <group>

Uma vez editei o script de inicialização para garantir que a opção -h no slapd corresponde ao que está no meu arquivo de configuração e tudo começou a funcionar novamente.