postfix / smtp: fatal: serviço desconhecido: smtp / tcp - mas / var / spool / postfix / etc / services existe

3

Estou executando uma caixa Debian GNU / Linux 8.7 com o Postfix 2.11.3-1 como MTA. De repente, isto é, sem alteração na configuração do MTA, os e-mails pararam de ser entregues e o erro a seguir foi exibido em /var/log/mail.err :

root@schroeder:~# tail /var/log/mail.err
Mar 21 12:51:01 schroeder postfix/smtp[25421]: fatal: unknown service: smtp/tcp
Mar 21 12:54:11 schroeder postfix/smtp[26397]: fatal: unknown service: smtp/tcp
Mar 21 12:54:12 schroeder postfix/smtp[26398]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26553]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26554]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26555]: fatal: unknown service: smtp/tcp
Mar 21 12:59:26 schroeder postfix/smtp[26556]: fatal: unknown service: smtp/tcp
Mar 21 13:04:30 schroeder postfix/smtp[27797]: fatal: unknown service: smtp/tcp

De acordo com a documentação do Postfix e duas outras perguntas similares no ServerFault, isso ocorre porque o postfix executa chrooted, mas não possui arquivos necessários, presumivelmente, /etc/services , em seu diretório de spool, ou seja, /var/spool/postfix .

Eu verifiquei e, de fato, /etc/services estava faltando em /var/spool/postfix . Então eu copiei ( não symlinked) /etc/services para /var/spool/postfix/etc . Infelizmente, sem sucesso.

Eu então brinquei com a desativação do chroot jail para o postfix 'smtp binary em /etc/postfix/master.cf e descobri que, quando desativo o chrooting para o tipo de serviço unix, o email é entregue normalmente. Ou seja, o seguinte /etc/postfix/master.cf funciona bem:

root@schroeder:~# grep -v ^# /etc/postfix/master.cf
smtp      inet  n       -       -       -       -       smtpd
pickup    unix  n       -       -       60      1       pickup
cleanup   unix  n       -       -       -       0       cleanup
qmgr      unix  n       -       n       300     1       qmgr
tlsmgr    unix  -       -       -       1000?   1       tlsmgr
rewrite   unix  -       -       -       -       -       trivial-rewrite
bounce    unix  -       -       -       -       0       bounce
defer     unix  -       -       -       -       0       bounce
trace     unix  -       -       -       -       0       bounce
verify    unix  -       -       -       -       1       verify
flush     unix  n       -       -       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
proxywrite unix -       -       n       -       1       proxymap
# The setting below is the one that I've changed.
# The vendor default is a dash in the fifth column.
smtp      unix  -       -       n       -       -       smtp
relay     unix  -       -       -       -       -       smtp
showq     unix  n       -       -       -       -       showq
error     unix  -       -       -       -       -       error
retry     unix  -       -       -       -       -       error
discard   unix  -       -       -       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       -       -       -       lmtp
anvil     unix  -       -       -       -       1       anvil
scache    unix  -       -       -       -       1       scache
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix  -       n       n       -       2       pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

Eu percebi que outra coisa, isto é, diferente de /etc/services não estar presente na jaula chroot em /var/spool/services , deve estar errada com minha configuração chroot.

Então, eu reativei o chrooting, baixei a fonte do Postfix, verifiquei o script de configuração do chroot para Linux que vem com a distribuição da fonte do Postfix e o executei:

root@schroeder:~# cd /usr/local/src/
root@schroeder:/usr/local/src# curl https://fourdots.com/mirror/postfix/postfix-release/official/postfix-3.2.0.tar.gz | tar -xz 
root@schroeder:/usr/local/src# sh postfix-3.2.0/examples/chroot-setup/LINUX2
postfix/postfix-script: refreshing the Postfix mail system

Mais uma vez, no entanto, isso não corrigiu minha configuração.

Eu também tentei adicionar "-v" à configuração do smtp em /etc/postfix/master.cf , mas os relatórios de erros não foram mais detalhados.

Neste momento, estou no meu juízo final. O que mais posso verificar? Como posso consertar minha configuração para que eu possa reabilitar o chrooting para o postfix 'smtp binary?

Para referência, minha configuração:

root@schroeder:~# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
inet_interfaces = 127.0.0.1 ::1
mailbox_size_limit = 0
mydestination = schroeder.phl.univie.ac.at, localhost.phl.univie.ac.at, localhost
myhostname = schroeder.phl.univie.ac.at
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/phl.univie.ac.at.pem
smtpd_tls_key_file = /etc/ssl/private/phl.univie.ac.at.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

O postfix não é (ainda) protegido pelo AppArmor:

root@schroeder:~# apparmor_status
apparmor module is loaded.
apparmor filesystem is not mounted.

Eu verifiquei se este é um bug conhecido na página inicial do Postfix e no rastreador de bugs do Debian para o pacote postfix.

Eu também pesquisei os recursos vinculados na página inicial do Postfix e nas listas de discussão, mas o único 'solução' que encontrei é construir o Postfix a partir da fonte. Eu tentei isso também, mas o erro persistiu.

    
por Odin Kroeger 21.03.2017 / 13:33

3 respostas

0

Eu não encontrei a fonte real do erro, mas - para minha surpresa (e desânimo) - eu pude corrigi-lo por:

apt remove --purge postfix
apt install postfix postfix-doc

Além disso, até onde eu sei, isso não alterou qualquer configuração relevante. Mantive um backup da configuração de pré-eliminação em /etc/postfix.backup , e /etc/postfix/main.cf não não difere de forma relevante de /etc/postfix.backup/main.cf :

root@schroeder:/etc/postfix# diff main.cf ../postfix.backup/main.cf
18c18
< readme_directory = /usr/share/doc/postfix
---
> readme_directory = no
21c21
< smtpd_tls_cert_file=/etc/ssl/certs/phl.univie.ac.at.crt
---
> smtpd_tls_cert_file=/etc/ssl/certs/phl.univie.ac.at.pem
38d37
< mailbox_command = procmail -a "$EXTENSION"
42d40
< html_directory = /usr/share/doc/postfix/html

E /etc/postfix/master.cf difere de /etc/postfix.backup/master.cf apenas na medida em que o chrooting é ativado novamente (e funciona):

root@schroeder:/etc/postfix# diff master.cf ../postfix.backup/master.cf
53c53
< smtp      unix  -       -       -       -       -       smtp
---
> smtp      unix  -       -       n       -       -       smtp

Nenhum outro arquivo em /etc/postfix difere da cópia correspondente em /etc/postfix/backup .

Eu, por curiosidade, verifiquei o que acontece quando volto a usar o arquivo de configuração antigo:

root@schroeder:/etc/postfix# cp main.cf main.cf.backup
root@schroeder:/etc/postfix# cp ../postfix.backup/main.cf .
root@schroeder:/etc/postfix# postfix reload
postfix/postfix-script: refreshing the Postfix mail system
echo 'A test.' | mail -s Test <censored>

O email de teste chega. Então, os arquivos de configuração em /etc/postfix , aparentemente, não causaram o problema em primeiro lugar.

Eu ainda não tenho ideia do que aconteceu.

    
por 22.03.2017 / 11:07
0

Eu tropecei no mesmo assunto. No meu caso isso foi devido a minha configuração usando zfs com / var / spool montado com flag noexec set. A solução foi limpar esse sinalizador no sistema de arquivos montado.

Veja o link para saber mais.

Em conclusão, o Postfix aparentemente depende de uma biblioteca vinculada dinamicamente que também é colocada no chroot jail em / var / spool / postfix para ler seu banco de dados de serviços. No caso de executar esta pasta ou qualquer uma de suas pastas pai em um sistema de arquivos separado que é montado com a opção noexec conjunto, esta biblioteca não será carregada para conter o código a ser executado . Do ponto de vista do Postfix, isso não é considerado em particular. Em vez disso, ele vê e registra um problema mais genérico com a leitura do banco de dados de serviços.

    
por 21.07.2018 / 00:41
0

O mesmo problema que desenvolvi depois de tentar instalar o postfix no Fedora 28 com o chroot ativado para o smtp através do arquivo /etc/postfix/master.cf.

depois de ler um dos muitos arquivos leia-me, especificamente

/postfix-3.3.1/README_FILES/BASIC_CONFIGURATION_README

Consegui perceber que havia um script que precisava ser executado para executar corretamente o postfix chrooted.

Note that a chrooted daemon resolves all filenames relative to the Postfix
queue directory (/var/spool/postfix). For successful use of a chroot jail, most
UNIX systems require you to bring in some files or device nodes. The examples/
chroot-setup directory in the source code distribution has a collection of
scripts that help you set up Postfix chroot environments on different operating
systems.

o problema que eu descobri foi o culpado foi que eu precisava executar o

LINUX2

Arquivo de script

localizado em

/postfix-3.3.1/examples/chroot-setup/

assim:

[[email protected] ~]$ cd postfix-3.3.1/examples/chroot-setup/   
[[email protected] chroot-setup]$ ls
AIX42  BSDI2  BSDI3  FreeBSD2  FREEBSD3  HPUX10  HPUX9  IRIX5  IRIX6  LINUX2     NETBSD1  NEXTSTEP3  OPENSTEP4  OSF1  Solaris10  Solaris2  Solaris8
[[email protected] chroot-setup]$ chmod +x LINUX2
[[email protected] chroot-setup]$ ./LINUX2

você deve executar este script como root ou sudo enquanto copia arquivos para o diretório / var / spool / postfix de etc, lib, lib64 e usr, e eles devem ser de propriedade de root. Foi só depois de executar o script, ele correu bem, e recarregou o postfix, mas eu ainda tinha erros, então eu depurei o script muito antigo e descobri que havia uma barra faltando na função cond_copy () .

a função correta cond_copy () deve ser semelhante a

cond_copy() {
    # find files as per pattern in $1
    # if any, copy to directory $2
    dir='dirname "$1"'
    pat='basename "$1"'
    lr='find "$dir/" -maxdepth 1 -name "$pat"'
    if test ! -d "$2" ; then exit 1 ; fi
    if test "x$lr" != "x" ; then $CP $1 "$2" ; fi
}

então se este é o seu erro e você está executando um postfix chroot jailed, primeiro encontre o script que copia os arquivos corretos em / var / spool / postfix / corrija o erro no função copy_cond () e executar como root, ou pelo menos é assim que eu fiz isso.

um pequeno adendo:

para aqueles que estão executando o SELinux, provavelmente não seria uma má idéia entrar / var / spool / postfix / e rodar o restaurorecon -Rv se você estiver preocupado, isso pode atrapalhar algo basta executá-lo nos arquivos que você moveu

[[email protected] postfix]# restorecon -Rv etc/ lib/ lib64/ usr/
    
por 13.11.2018 / 18:13