openldap: arquivos de log enormes no nível de log 'stats'

Question

Eu tenho um servidor Linux executando o openldap para a administração de usuários. O nível de log é definido como 'stats', que eu vi como sendo o nível de log "recomendado" em algum lugar. Agora, o problema é que os arquivos de log estão crescendo rapidamente, com a grande parte das entradas geradas por consultas dos poucos clientes do KDE 4: Por segundo, dozends de entradas do seguinte formulário são criadas

Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26379 SRCH base="dc=###" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=####))"
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26379 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26379 SEARCH RESULT tag=101 err=0 nentries=1 text=
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26380 SRCH base="dc=###" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=####))"
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26380 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Apr 19 13:21:50 ###### slapd[1429]: conn=1001 op=26380 SEARCH RESULT tag=101 err=0 nentries=1 text=

Eu não tenho uma ideia clara de qual componente exato dos clientes está criando essa enxurrada de perguntas. Meu palpite é que ele vem de algum componente padrão do KDE rodando em segundo plano quando algum usuário está logado.

• Esse comportamento é normal ou os clientes estão ficando loucos? Algum palpite de onde vêm as perguntas?
• Se isso é normal, não posso usar o nível 'stats'. Existe algo mais detalhado do que o nível de log 'none', o que faz sentido na minha situação?

Answer 1

O loglevel=stats é de fato o nível de registro padrão, conforme descrito no manual .

Essas parecem consultas perfeitamente válidas para um sistema Linux que possui um backend LDAP.

O filtro: "(&(objectClass=posixAccount)(uid=####))" procura uma conta com um nome de login específico. Eu esperaria tais consultas de sua pilha PAM quando um usuário tenta efetuar login.

O filtro: (&(objectClass=posixAccount)(uidNumber=####)) procura as informações associadas ao numérico uidNumber. Eu esperaria tais consultas quando seu sistema precisa converter os números numéricos UID usados pelo seu sistema para os nomes de login mais humanos, por exemplo, quando um ls -l é executado.

Os seguintes atributos de conta são solicitados: attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass , que são os atributos normais da conta POSIX para uma conta de usuário.

Essa consulta LDAP é bem-sucedida e, como esperado, produz exatamente 1 resultado: SEARCH RESULT tag=101 err=0 nentries=1 text . 0 resultado também seria esperado, um nome de usuário ou o numérico uidNumber é desconhecido, mais de 1 resultado seria interessante, as contas de usuário e o numérico uidNumber deveriam ser únicos e distintos para cada usuário único.

Você pode configurar seus clientes Linux para criar e manter um cache com os resultados de tais consultas em um diretório de usuários central, que deve reduzir a carga no servidor LDAP, resultar em menos entradas de log e fazer com que os clientes funcionem melhor. bem.

Instale e ative o nscd (o Daemon de armazenamento em cache do serviço de nomes) nos clientes. O ajuste do nscd geralmente não é necessário.