Postfix permission denied probléma

 ( NoMan | 2019. február 28., csütörtök - 15:11 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

spamassassin nincs konfigurálva...

a levelek mennek és jönnek, csak olyan esetlegesen, van amikor egyáltalán nem tudok küldeni, van, amikor semmi gond nincs vele... befelé még nem láttam gondot, ott mintha gond nélkül jönne mindig

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 :/

Az apache tutira nem akart oda irni, azt se tudna, milyen formatban kellene a levelet letenni, stb. Sokkal valoszinubb, hogy a /usr/sbin/postdrop volt a hatterben meghivva (mondjuk sendmail-bol, amit pedig az apache hivott levelkuldeskor) es ez nem fert hozza.

Í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

-

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