Taurus

Один знакомый сисадмин помог решить проблему:
fastcgi_ignore_client_abort on

То, что доктор прописал!

Решил углубится в тему, вот результаты:

Директива open_file_cache применяется для кеширования информации о статических файлах: js, css, jpeg, html,..
Если файл не существует, или не прав на чтение, то эта информация также может хранится в кеше.
По умолчанию: open_file_cache off;

Пример с описанием:

# Информация о 1000 файлов, может хранится в кеше. Если не было активности к файлу в течение 5 мин, то информация о нем удаляется из кеша
open_file_cache max=1000 inactive=5m;  

# Активностью считается обращение к файлу хотя бы 2 раза. В кеш они также попадают, если было хотя бы 2 обращения к файлу
open_file_cache_min_uses 2;             

# Вся информация о файлах в кеше обновляться раз в 1 минуту
open_file_cache_valid 1m;               

# Сохранять ли информацию об ошибках, например, если файла, к которому вы обратились - нет, то это будет тоже в кеше, информация тоже обновится через 1 мин
open_file_cache_errors on;

При работе со статическими файлами, когда они изменяются, например верстке.
На время работ желательно отключать open_file_cache, либо параметр open_file_cache_min_uses делать достаточно большим, чтобы файл не попадал в кеш, но это фактически тоже самое что и отключить open_file_cache.

Если файл находится в кеше, при этом происходит изменение файла, то сервер выдаст ошибку ERR_EMPTY_RESPONSE, что значит, что сервер отказал в доступе и не отдал контент.
При этом сам сервер работает нормально и если обратится к другим файлам, то они легко загружаются.
Примечателен факт, что если восстановить измененный файл, то сервер его начинает отдавать до проверки open_file_cache_valid. Видимо проверяется контрольная сумма файла, так как дата изменения файла меняется.

При работе с файловой системой NFS, рекомендуется не включать open_file_cache, так как информация о файлах может не обновляться даже после open_file_cache_valid.

Написал, а то может кому интересно будет или я забуду :)

Буквально вчера занимался подобной проблемой на сайте знакомых с Joomla.

1. Зайдите по ssh и сделайте архив всего сайта, скачайте его к себе на машину.
2. Натравите на архив Касперского или Sophos (опыт показал, что они отлично выявляют зловреды, хотя и не все)
Все обнаруженные уязвимости вычистите прямо на сайте через vi. Если обнаружится, что eval запихали в EXIF картинок, то их просто надо пересохранить и залить обратно на сайт.

Пока антивирус делает свое дело, займитесь следующим:
1. Проверьте .htaccess на наличие левых редиректов. В моем случае все пользователи отправлялись на страницу phpinfo.php c какой-то порнухой.
2. Поищите код, который не найдут антивирусы:
2.1 В некоторых файлах встроена конструкция, позволяющая сохранить файл в произвольное место на сайте. В моем случае это находилось при помощи команды

find. -type file | grep php | xargs grep -l "<?php if (@"

2.2 Поищите и проанализируйте файлы, которые обращаются к exif

find. -type file | grep php | xargs grep -l exif_read_data

2.3 Найдите картинки с троянами

find. -type file | grep jpg | xargs grep -l eval

2.4 Поищите preg_replace, который потом выполняет код

find. -type file | grep php | xargs grep -l preg_replace.*\/e

3. Анитивирусы наверняка найдут какие-то файлы. Загляните в них на хостинге, как правило там идет закодированная хрень и проверка каких-нибудь паролей. Вот эти самые проверки могут дать дополнительные ключи для поиска. В моем случае я нашел еще ряд файлов при помощи команд

find. -type file | grep php | xargs grep -l 2970d43d7bf4115cdc60e2453bf48b52
find. -type file | grep php | xargs grep -l security_code

4. Внимательно проанализируйте файлы, которые находятся рядом с файлами бекдоров, скорее всего именно в них и находится уязвимость.
5. Слейте дамп базы и поищите в нем eval, preg_replace и прочие прелести
6. После зачистки всей дряни снова сделайте бекапный архив сайта

Это все были шаги по приведению сайта в рабочее состояние. К сожалению, они не могут дать ответ на вопрос, а как же нас ломанули. Переходим к активным действиям по выявлению точек входа.

На сервере, где хостятся мои знакомые есть только cvs, им и воспользуемся. Аналогичные действия можно сделать и при помощи git или svn.

1. Вышли в домашнюю директорию

cd

2. Создали пустую директорию для нашего репозитория

mkdir cvsroot

3. Заинитили репозиторий

cvs -d ~/cvsroot init

4. Перешли в директорию, где находится корень сайт. Пусть у вас есть такая структура /home/myusername/mysite/htdocs. Тогда

cd ~/mysite/htdocs

5. Делаем первичный импорт в репозиторий

cvs -d ~/cvsroot import htdocs initial_import initial

6. Сейчас будем удалять старый сайт и забирать его из репозитория

cd ~/mysite
mv htdocs htdocs.bak
cvs -d ~/cvsroot checkout www

7. Добавляем в .htaccess правило, защищающее служебные файлы

RedirectMatch 404 /CVS(/|$)

8. Что это нам дает? Возможно быстрой проверки измененных файлов

cd ~/mysite/htdocs
cvs -qn update

Если все было сделано правильно, то ответ будет

M .htaccess

9. Записываем наши изменения в репозиторий

cvs -q commit -m update

Далее, включаем в cron команду cvs -q commit -m update, да хоть бы и раз в минуту (если сайт сильно посещаемый), включаем лог файлы и ловим изменения, которые происходят в системе. Определив время и изменившиеся файлы, по логам смотрим что, кто, куда и как делал.

Работая по ссылке с foreach можете налететь на очень неприятны грабли, которые незаметны и сильно попортят вам нервы.
Особенно когда разработчики неопытные.
И именно - ссылку после foreach нужно удалять.
array_walk для работы по ссылке - само-то, лишь тем и лучше.
В других случаях — будь попроще — используй foreach.

Кроме того в array_walk становится очень удобный для оперирования многомерными массивами,
а также замыкания могут также наследовать переменные из родительской области видимости.

Пример:

array_walk($guide['postInGuides'], function (&$postInGuide, $key) use ($guide, $viewRenderer) {
    $postInGuide['post']['url'] = [
        'read' => $viewRenderer->url('guide/guide/post', [
            'slugGuide' => $guide['name'],
            'slugPost'  => $postInGuide['post']['slug'],
        ]),
        'update' => $viewRenderer->url('post/post/action', [
            'slugPost'  => $postInGuide['post']['slug'],
            'action' => 'update',
        ]),
        'delete' => $viewRenderer->url('post/post/action', [
            'slugPost'  => $postInGuide['post']['slug'],
            'action' => 'delete',
        ]),
    ];
});

1. вариант и я тебе его крайне рекомендую.
Делигируй почту на яндекс PDD, ( по сути штатный вараиант для битиркс вм)
Битрикс вм по умолчанию использует не smtpd а msmtpd который по сути умеет только автаризовывать на чужом почтовом сервере.
редактируем файлик
/home/bitrix/.msmtprc( рестартовать демон не нужно)
пишем туда вот это

# smtp account configuration for default
account default
logfile /home/bitrix/msmtp_default.log
host smtp.yandex.ru
port 587
from norepay@shop.wildorchid.ru
keepbcc on
auth on
user norepay@shop.wildorchid.ru
password ТУТ_ТВОЙ_ПАРОЛЬ
tls on
tls_certcheck off
tls_starttls on

Смотрим логи отправки в этой же папке
Да и не забудь активировать акаунт на яндексе!
Плюсы
+у каждого проекта свой почтовый сервер без настроек
+ админка яндекса
+антиспам яндекса
+spf dkim dmarck работают валидно сертификаты подписаны. ( требуется отправить токен для активации DKIM
- почта уходит со внешнего сервера

Настройки можешь посмотреть у этого домена в записях.

Теперь как сделать так чтоб почта отправлялась с лькального компа.
yum install postfix ...

Ну и чтоб сайт начал отправлят ьпочту через постфикс, коментишь строчку в виртуал хосте соответствующего сайта
php_admin_value sendmail_path "msmtp -t -i -a Тут_имя_твтего_сайта"
релоад апача и все.

+почта своя
- нет антиспама
-ставить веб морду, если нужна то roundcube рекомендую.
- настраивать все ящики и тд нужно самому или опять крутить веб морду.
- нужно настраивтаь самому dkim , ставить opendkim Писал как это сделатьл тут

https://klondike-studio.ru/blog/nastroyka-dkim-na-...

Да, нужно указывать.

не станет ли это проблемой в будущем

Наоборот, они помогут избежать проблем. Можно, конечно, и вручную все это прописывать, но зачем?

Если все-таки нужно указывать внешние ключи в БД, помогите определиться какие действия ставить на ON DELETE или ON UPDATE, например для таблицы users и posts.

Зависит от типа связи.

Пример:

Профиль - настройки пользователя (предположим, что они хранятся в отдельной таблице). Без пользователя настройки не имеют смысла, поэтому их также нужно удалить при удалении юзера.

Публикации в блоге - пользователь. Здесь уже на выбор:

1. Можно запретить удаление пользователя, если у него есть хотя бы один пост
2. Удалить все посты юзера вместе с аккаунтом

ip addr add ${ip_a}/${netmask} dev ${interface}
где ${ip_a} - ваш ip-адрес
${netmask} -ваша маска
${interface} - интерфейс на который довешиваем ip.

Если адрес шлюза отличается от шлюза по умолчанию видимо надо будет добавить еще правила маршрутизации, например так:

ip ru add from ${ip_a} lookup ${table}
ip ro add default via ${ip_gw} dev ${interface}  table ${table}

где ${ip_gw} - адрес шлюза для нового ip
${table} - произвольный номер таблицы, например 100.