Problemas de permissions con NFS-montado / var / spool / mail para dovecot y procmail

Mi configuration del server de correo trabajó durante años. Recientemente he comenzado experimentando el problema siguiente:

Configuración del correo: sendmail + dovecot + procmail

Servidor de files de host: CentOS 6.8, NFS exporta directorys de correo a …

Servidor de correo: CentOS 7.3, que se ejecuta como invitado VM en el host a través de libvirtd / qemu, NFS monta / var / spool / correo del host.

Síntomas: Tanto dovecot como procmail han emitido errores (detalles a continuación) que parecen indicar que no tienen permiso para escribir en / var / spool / mail. Sin embargo, / var / spool / mail tiene los permissions más generales que sé dar, tanto en el server de files NFS como en el cliente NFS de correo.

En el server de correo (cliente NFS):

$ ls -lhd /var/spool/mail drwxrwxrwt 5 root mail 6.8M Mar 29 12:37 /var/spool/mail 

En el server de correo: / etc / fstab:

  filehost:/mail/inbox /var/spool/mail nfs defaults 0 0 

En el host NFS:

  $ ls -lhd /mail/inbox drwxrwxrwt. 5 root mail 6.8M Mar 29 12:41 /mail/inbox 

En filehost: / etc / exports:

  /mail/inbox mailserver(rw,no_root_squash,async,nohide) 

Ninguno de los dos sistemas ejecuta SELinux o iptables (confío en el firewall de nuestro sitio).

Los types de cosas que veo:

  • Archivos con nombres como BOGUS.normaluser.hex-string. El post de logging correspondiente es

    Mar 29 12:14:34 mailserver procmail [20922]: Renombrado falso "/var/spool/mail/normaluser.lock" en "/var/spool/mail/BOGUS.normaluser.xGAs"

    Esto puede ser excepcionalmente molesto, ya que ha habido veces en que no es sólo el file de locking que se ha declarado falso, sino la bandeja de input de normaluser. Desde la perspectiva de normaluser, su bandeja de input se desvanece mientras están leyendo su correo.

  • Archivos con nombres que comienzan con subrayados, por ejemplo, _2-E, eu92YB.mailserver.domain.

    No hay posts de logging correspondientes. El contenido de estos files (que son siempre 1 byte o 31-33 bytes) sugieren que estos son files de locking. Una página web que vi ayer describió a alguien usando strace para identificar que procmail está escribiendo estos files, pero no sé cómo usar strace para confirmar esto por mí mismo (y no puedo encontrar la página hoy).

    Cuando list los files, veo que son chmod 400, que puede ser por qué no están siendo eliminados:

 -r -------- 1 normaluser correo 1 Mar 29 12:30 _uZF% kE-2YB.mailserver.domain
 -r -------- 1 normaluser correo 1 Mar 29 12:30 _uZF + kE-2YB.mailserver.domain
 -r -------- 1 normaluser correo 1 Mar 29 12:31 _uZF, kF-2YB.mailserver.domain
 -r -------- 1 normaluser correo 1 Mar 29 12:31 _uZF.kF-2YB.mailserver.domain
 -r -------- 1 normaluser correo 1 Mar 29 12:31 _uZF + kF-2YB.mailserver.domain
  • Lockfiles que no se van. Entrada de logging de correo típica:
 Mar 29 12:31:01 server de correo dovecot: imap (normaluser): Error: unlink (/var/spool/mail/normaluser.lock) falló: Operación no permitida

 Mar 29 12:31:01 server de correo dovecot: imap (normaluser): Error: file_dotlock_create () falló con el file mbox / var / spool / mail / normaluser: Operación no permitida

Para los usuarios, un file de locking que no desaparece significa que todo su procesamiento de correo se detiene hasta que elimine manualmente el file de locking. Los permissions parecen normales:

 -rw ------- 1 normaluser theirgroup 33 Mar 29 12:30 normaluser.lock

He jugado un poco con las opciones de dovecot, basado en el wiki dovecot, con la esperanza de que he cometido un error en alguna parte. Los valores relevantes actuales son:

  mmap_disable = yes dotlock_use_excl = yes mail_fsync = optimized mail_nfs_storage = no mail_nfs_index = no mail_privileged_group=mail 

Configurar mail_nfs_storage = yes no parece cambiar nada, ya que ese parámetro (de acuerdo con la wiki dovecot) tiene que ver con varios serveres de correo accediendo al mismo directory a través de NFS, lo cual no es el caso aquí.

He googled y jugueteado, y no puedo rastrear el problema. Estoy pidiendo cualquier cosa que he pasado por alto, o para las sugerencias para los diagnósticos adicionales que podría funcionar.

Luego:

Me estoy acercando a una solución. En el server de correo del cliente:

  $ cd /var/spool/mail $ sudo -u normaluser touch test $ sudo -u normaluser rm test 

No hay problema.

  $ sudo -u dovenull touch test $ sudo -u dovenull rm test rm: cannot remove 'test': Operation not permitted $ ls -lh test -rw-r--r-- 1 nobody nobody 0 Mar 31 12:03 test 

¡Ah! La count dovenull no puede hacer nada en el directory importado por NFS. He intentado agregar una count dovenull al server NFS (con el mismo uid / gid), pero eso no ha resuelto el problema:

  $ sudo -u dovenull rm test rm: cannot remove 'test': Operation not permitted $ ls -lh test -rw-r--r-- 1 dovenull dovenull 0 Mar 31 12:03 test 

Esto se siente como un problema de idmap. Aquí están las únicas líneas uncommented en idmap.conf en el cliente y el server:

 [General] Domain = mydomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobody [Translation] Method = nsswitch 

Estoy cerca … puedo sentirlo …

Más tarde:

Puedo sentir todo lo que quiero, pero eso no significa que tenga la respuesta. Tengo la count dovenull para poder crear y eliminar en / var / spool / mail (tenía que ver con mirar atentamente /etc/nssswitch.conf y darse count de que tenía que reiniciar NIS), pero eso no solucionó mi problema. La count dovenull no escribe en / var / spool / mail.

He utilizado auditctl:

 auditctl -w /var/spool/mail -p war -k mail-inbox ausearch -k mail-inbox > mail-inbox.txt 

y verificó que los files extra lock y BOGUS estaban siendo creados por dovecot, y los files de subrayado "_" estaban siendo creados por procmail. No voy a molestar en publicar los loggings de auditoría a less que alguien quiera verlos; lo que muestran es que los files se están creando con los permissions correctos (uid, gid, euid, etc.) y las eliminaciones no tienen éxito aunque la llamada de eliminación se realiza con los mismos permissions.

Entonces, ¿qué puede causar la creación de un file, pero no puede ser eliminado?

Me las arreglé para resolver este problema, aunque reveló otro problema (less crucial).

La pista era que ocasionalmente, cuando listría / var / spool / mail en el cliente NFSv4, vería algo como esto:

 -r-------- 1 4294967294 mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain -r-------- 1 4294967294 mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain -rw------- 1 normaluser mail 1 Mar 29 12:31 normaluser 

Entonces cuando yo haría un "ls-lh" inmediatamente después, vería:

 -r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF%kE-2YB.mailserver.domain -r-------- 1 normaluser mail 1 Mar 29 12:30 _uZF+kE-2YB.mailserver.domain -rw------- 1 normaluser mail 1 Mar 29 12:31 normaluser 

Ese número, 4294967294, es -2 en integers sin signo de 32 bits, ya menudo es el UID asignado a la count nfsnobody. Esto me sugirió que podría haber problemas transitorios idmapd. Eso sería coherente con lo que observé: a veces el server de correo actuaría como si no tuviera permissions de rwx a través de NFS, incluso después de que acaba de crear ese file. Dado que sólo NFSv4 utiliza idmapd (al less para las versiones NFS), cambié a NFSv3 cambiando una línea en / etc / fstab en el cliente NFS del server de correo:

 filehost:/mail/inbox /var/spool/mail nfs defaults,vers=3 0 0 

Luego reinicié el server de correo, y voila! Los problemas NFS desaparecieron. Para el logging, he reiniciado el server de correo varias veces al diagnosticar el problema, por lo que este no es un caso de "fijo por simple reinicio".

Por supuesto, esto plantea la cuestión de por qué idmapd tiene problemas. Cualquier persona curiosa puede ver mi configuration de idmapd.conf arriba. Pero esa es una pregunta separada, y una de mucha menor prioridad para mí. Puedo publicar esa pregunta en serverfault algún día.

Luego:

Una búsqueda rápida en la web me dio esto: Mapeo de uid parcialmente incorrecto con nfs4 / idmapd / ldap-auth

Una corrección fue implementada en el núcleo 3.13, pero el actual CentOS7 es el núcleo 3.10. No sé si Redhat ha respaldado la corrección en su núcleo actual de CentOS7.

Eso me indaga sobre lo que causó el problema: estoy constantemente agregando nuevos usuarios activos a nuestro entorno de clúster. En algún momento debo haber inclinado sobre el número de usuarios en / var / spool / mail para activar el error idmapd.