Итак, вчера Webmin удалил мой / etc / passwd, и хотя похоже, что все работает, я не могу заставить sendmail работать при использовании в сценарии PHP.
Использование mail () возвращает false, использование PHPMailer приводит к тому, что «Mailer не может выполнить sendmail».
Я на 100% уверен, что эта проблема возникла из-за файла passwd, просто не могу понять, как это исправить.
Я заметил, что несколько пользователей испортились, и мне пришлось их заменить.
Я, вероятно, должен упомянуть, что если я попытаюсь отправить его через сам sendmail, он будет работать отлично.
Для людей, говорящих о восстановлении / etc / passwd, я уже сделал это, и проблема все еще остается.
grep smmsp /etc/group
smmsp:x:51:
ls -ld /var/spool/mqueue/
drwx------ 2 root mail 4096 Nov 8 02:56 /var/spool/mqueue/
ls -ld /var/spool/clientmqueue/
drwxrwx--- 2 smmsp smmsp 4096 Nov 8 02:55 /var/spool/clientmqueue/
ls -ld /var/spool/mail/
drwxrwxr-x 2 root mail 4096 Nov 8 02:18 /var/spool/mail/
ls -l /usr/sbin/sendmail
lrwxrwxrwx 1 root root 21 Aug 8 21:29 /usr/sbin/sendmail -> /etc/alternatives/mta
ls -l /usr/sbin/sendmail.sendmail
-rwxrwsrwx 1 root smmsp 806460 Aug 11 17:32 /usr/sbin/sendmail.sendmail
ошибка
Nov 8 15:58:18 jbrunton sendmail[6222]: pA8FwIPJ006222: SYSERR(UID0): Who are you?: Permission denied
Nov 8 15:58:18 jbrunton sendmail[6222]: pA8FwIPJ006222: from=apache@jbrunton.net, size=456, class=0, nrcpts=1, msgid=<1320767898.6199@jbrunton.net>, relay=root@localhost
Nov 8 15:58:18 jbrunton sendmail[6225]: pA8FwIdW006225: SYSERR(root): collect: Cannot write ./dfpA8FwIdW006225 (bfcommit, uid=0, gid=51): Permission denied
Nov 8 15:58:18 jbrunton sendmail[6225]: pA8FwIdW006225: from=<apache@jbrunton.net>, size=598, class=0, nrcpts=1, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
Nov 8 15:58:18 jbrunton sendmail[6222]: pA8FwIPJ006222: to=jbhero@gmail.com, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30456, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 421 4.3.0 collect: Cannot write ./dfpA8FwIdW006225 (bfcommit, uid=0, gid=51): Permission denied
Файл passwd можно восстановить, но это потребует больших усилий. Вместо этого вы можете использовать следующий образец файла passwd, чтобы хотя бы некоторые из ваших системных учетных записей работали /
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
smmsp:x:511:511:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
messagebus:x:102:107::/var/run/dbus:/bin/false
Поскольку я добавил пользователя smmmp в файл passwd, так что ваш sendmail может работать нормально.
Также ищите / etc / passwd- файл, так как он также является резервной копией, хранящейся в ОС. это могло быть там.
Чтобы избежать этой проблемы в будущем, вы можете управлять версиями / etc, поэтому в случае возникновения ошибок вы всегда можете просто вернуться к предыдущей версии. Пакет etckeeper может помочь в этом, отслеживая разрешения в репозитории управления версиями и интегрируя коммиты в операции обслуживания.
Добавить apache пользователь к smmsp group и попробуйте еще раз:
# usermod -a -G smmsp apache