Postfix permission denied probléma

Linux-haladó

Sziasztok,

A napokban került át egy VPS összes szolgáltatása egy új VPS-re. Oprendszer maradt, etc maradt... minden a régi, legalábbis látszólag és már kifogytam az ötletekből.

- A mail.log tele van az alábbi bejegyzésekkel: postfix/postdrop[9282]: warning: mail_queue_enter: create file maildrop/56448.9282: Permission denied
Kb minden 2. sor ez... Végig túrtam az egész internetet. Volt javaslat az újraindításra, ami nem segített, be kellett állítani a binárisok és a /var/spool/postfix mappákba a jogosultságokat. De semmi nem segített... Google kb 2. oldaláig mindent kipróbáltam, amit írtak, de egyik sem segített.

- Ezen kívül az SMTP szerverem gyakorlatilag használhatatlan. Lehet, hogy nincs összefüggés. A működése jobban hasonlít az esti mesére, mint bármi másra, úgy mint: egyszer volt, hol nem volt. Ami szó szerint értendő. Van, amikor percekig nem tudok levelet küldeni vele, mert elérhetetlen, van amikor meg tökéletesen működik.

- És végül pedig a MySQL, amit szerintem valami megborít. A komplett levelezés adatbázisául a mysql szolgál. Abba vannak az SMTP hozzáférések és a inbox fiókok, átirányítások...stb. Tehát minden ami levelezés a mysql szolgálja ki. Kivéve a leveleket, mert az ugye maildir. De nem ritka, hogy a postfix irányába nem ad életjelet. Timeout-ra fut, de látszólag semmi baja, mert számos web is megy ebből az adatbázisból, azokkal akkor nincs gondja a rendszernek.

Bármilyen építő jellegű véleményt, javaslatot elfogadok, mert már teljesen tanácstalan vagyok. A google féle linkeket hagyjuk ki. 48 órája a google-t bújtam egy rövid alvási szünettel. Ami ott van és másnak segített, az nekem nem segített.

Köszi előre is.

  • 1280 megtekintés

( 3r1c v | 2019. 02. 28., cs – 14:20 )

Hello,

Átmeneti megoldásként szerintem vedd ki main.cf-ből és master.cf-ből a spamassassinre vonatkozó részt. Ekkor már a leveleknek menniük kell ha csak ezzel van gond.
Utána spamassasin törlése, majd telepítése, ezt követően konfigurálása újra a postfixbe.

( eff | 2019. 02. 28., cs – 14:51 )

Az a gond, hogy relativ a path, amit kidob, igy nehez megmondani hol akar a maildrop mappaba fajlokat pakolgatni.
Erre most ket otletem van:
1: nincs meg a maldrop mappa, amibe a file-t letre akarja hozni
2: apparmor nem engedi (parszor mar futottam bele ilyenbe atpakolt data konyvtarakkalkulonbozo service-eknel)

1: postfix config alapján elvileg /var/spool/postfix (ld.: queue_directory = /var/spool/postfix)... ott viszont minden mappa a helyén

# ls -la /var/spool/postfix
total 18
drwxr-xr-x 16 root root 1024 Feb 28 14:45 .
drwxr-xr-x 7 root root 1024 Feb 21 18:59 ..
-rw-r--r-- 1 root root 0 Feb 28 14:45 .keep_mail-mta_postfix-0
drwx------ 2 postfix root 1024 Feb 28 15:34 active
drwx------ 2 postfix root 1024 Feb 28 15:33 bounce
drwx------ 2 postfix root 1024 Feb 21 19:00 corrupt
drwx------ 18 postfix root 1024 Feb 26 21:06 defer
drwx------ 12 postfix root 1024 Feb 28 06:48 deferred
drwx------ 2 postfix root 1024 Feb 21 19:00 flush
drwx------ 2 postfix root 1024 Feb 21 19:00 hold
drwx------ 2 postfix root 1024 Feb 28 15:34 incoming
drwx-ws--- 2 postfix postdrop 3072 Feb 28 15:32 maildrop
drwxr-xr-x 2 root root 1024 Feb 27 18:51 pid
drwx------ 2 postfix root 1024 Feb 28 08:42 private
drwx--s--- 2 postfix postdrop 1024 Feb 28 08:42 public
drwx------ 2 postfix root 1024 Feb 21 19:00 saved
drwx------ 2 postfix root 1024 Feb 21 19:00 trace

2: nem használok apparmort

+1 még a systemd-re gyanakszom, mert a régi vps openrc-t használt, ez pedig systemd-t. Ennyi különbség van a két VPS között viszont és a systemd alap beállításait használom, ami csak remélhető, hogy jó és őszintén szólva még csak most tanulgatom, de ott még lehet gond, mert ahogy néztem, befolyásolni tudja a szolgáltatások jogait is.

# cat /etc/systemd/system/multi-user.target.wants/postfix.service
[Unit]
Description=Postfix Mail Transport Agent
After=network.target

[Service]
Type=forking
ExecStartPre=-/usr/bin/newaliases
ExecStart=/usr/sbin/postfix start
ExecStop=/usr/sbin/postfix stop
ExecReload=/usr/sbin/postfix reload
# Hardening
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=full
ReadWritePaths=-/etc/mail/aliases.db
CapabilityBoundingSet=~ CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE
MemoryDenyWriteExecute=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true

[Install]
WantedBy=multi-user.target

permission denied megoldódott... az apache felhasználó akart oda fájlt letenni, ami nem sikerült neki
azt ugyan még nem tudom, hogy milyen életszerű folyamat szeretne az apache-ból postfix mappába turkálni, de legalább kiderült, hogy az apache-nak nem volt joga

viszont a többi probléma sajnos még mindig adott :/

Így vakon azt mondanám, hogy a 2. az a 3. miatt lehet, ha a postfix megpróbál mysql-ből adatokat/konfigokat vadászni, és vár csóri a működő db kapcsolatra.
Hogy az mi miatt lehet, már jó kérdés, ott mysql/posftix debug loggingból talán lehet valami használható infot kibányászni.

esetleg érdekes lehet, hogy melyik kliens hogy kapcsolódik a db-hez (unix socket/network).

szerk: esetleg megnézni, nincs-e valami connection throttling bárhol beállítva, ami miatt időnként nem engedi kapcsolódni a postfixet a db-hez

( NoMan | 2019. 03. 05., k – 16:38 )

valóban a mysql okozta a problémát, nem adott időbe választ, mert sok query futott be hozzá egy elszabadult ütemezett script miatt

tehát végül kiderült, hogy mégis én okoztam a problémát és nem a költözés