Konkase: 20кк записей по (в среднем) 40 байт на строку - это 800 мегабайт текста. Зачем?! :) Какой глубинный смысл хранить локально 20кк записей? Чтоб не зависеть от всей системы DNS?
Если цель - всего-лишь держать свой локальный DNS для обхода провайдерского - нет ничего зазорного, чтобы раз в день брать файл, перегонять его в нужный формат и скармливать, допустим в формат для unbound, который должен его скушать без проблем, с последующим перезапуском этого самого unbound.
Или этот текстовый файл используется для реализации "заглушки" для сайтов, которые не должны быть доступны из локальной сети? Но в таком случае непонятно, почему там 20кк записей.
copal: nginx.org/ru/docs/http/ngx_http_log_module.html#lo... - здесь указано, что контекст для log_format - http, таким образом log_format надо прописывать в секции http{}. Если посмотрите nginx.conf - там по-умолчанию уже определен один логформат под именем main. Если не заботиться о четкой иерархии файлов конфигов - тогда строку из пункта 1 можно просто вписать рядом. Таким образом мы опишем формат вывода с именем upstreamlog.
Ну а потом останется только в виртуальном хосте, который описывает ваш проект, в качестве формата вывода лога вписать этот upstreamlog. См. пункт 2. Это всего лишь дописывание имени логформата к пути до access_log.
Кстати, logformat, который я привел - это всего лишь пример. Туда можно вписывать любые переменные, которые позволяет обрабатывать nginx... включая значение куки и т.д.
65536: Непонятно. У меня он ничего не стирает. ccze всего-лишь окрашивает текст, который ему скармливают.
У меня есть только соображения, что возможно вы имели ввиду, что tail без -f отрабатывает и потом, допустим, появляется mc? В таком случае, либо надо использовать сабшелл в mc (просто Ctrl+O нажать :) ), либо вообще не запускать mc.
Александр Попов:
4. Если все-таки вести капчу - понизится ваш рейтинг у почтовых систем - т.е. появится бОльшая вероятность влететь в "Спам" автоматически.
5. Обычно на ящик, указанный в From:
P.S. Если юзер задает вопрос в веб-форме, где пишет свой почтовый ящик - будет не лишним предупредить, что ответ осуществляется с помощью email и если он хочет получить ответ на свой вопрос, то ему надо указать свой почтовый ящик. Либо сделать обратную связь не на основе почты, а, например, в виде чата.
Не вижу препятствий, чтобы и в сессию пользователя можно было параллельно пихнуть нужное значение.
1. Меняем джаваскриптом нужный параметр в браузере у пользователя, чтобы смена цвета отобразилась сразу.
2. Пихаем в сессию нужный параметр.
3. При подтверждении пользователем - сохраняем в профиле пользователя в БД.
Просто вместо одного действия запихивания в БД, выполняем несколько.
Александр Попов:
3. Настроить выгребание писем от Mailer Daemon из почтового ящика для отлупов (обычно это ящик, указанный как отправитель) - думаю не очень сложно.
4. Филипп абсолютно прав - не допускается ни капчи, ни каких-либо проверок на валидность пользователя. Поступил запрос - будьте добры исключить ящик из базы. Как вариант - генерировать каждому пользователю уникальную ссылку для отписки, чтобы однозначно его идентифицировать, плюс туда же в урл запихать какой-нибудь хэш, чтобы было сложно подобрать урл руками. Таким образом можно достигнуть того, что пользователь будет идентифицироваться однозначно.
5. Для mail.ru - выгребать почту из ящика, куда приходят отлупы от почтовиков, выделять те, которые "Spam report" и удалять из базы рассылки.
Для Яндекса - не знаю, как насчет почтовых оповещений, но список тех, кто нажал "Спам" можно получить в postmaster.yandex.ru по нажатию на нужную кнопку в веб-интерфейсе... возможно есть еще как-то механизм, но сейчас я про него не в курсе.
Для гмыла - пока непонятно :)
6. PHP-разработчик вообще не должен этим заморачиваться. Его дело - просто сформировать письмо и отправить его на локальный почтовый сервер (просто вызвав стандартную функцию mail, или как там она называется в PHP). Таким образом вызывается системный MTA (Mail Transport Agent) - sendmail или exim или postfix. А дальше уже дело за системным администратором, который и должен настроить почтовый сервер со всеми механизмами подписей.
Если админа под рукой нет - тогда в интернетах есть куча статей по настройке SPF (простая запись в DNS, указывающая, кто имеет право отсылать письма наружу в данной доменной зоне), куча статей по DKIM (здесь немного сложнее - формируется закрытый ключ и открытый ключ, открытый выкладывается, как и SPF-запись, в DNS зоны, а закрытый скармливается почтовому серверу, который подписывает данным ключом все исходящие с нужного домена письма). Есть еще DMARC... тоже настраивается записью в DNS и указывает чужим почтовикам, можно ли принимать письма с домена, если они не подписаны DKIM, но хост есть в SPF или наоборот и другие варианты.
Варианты настройки под каждый конкретный MTA можно с легкостью найти с помощью гугла. У меня довольно узкая специализация в плане MTA (использую exim, а где нет exim - сношу, что там есть и ставлю exim :) и рекомендую ставить exim, ибо у него поддержка DKIM из коробки), поэтому навязывать и говорить, что "вот так правильно и никак иначе" - совсем не хочу.
Тогда хотя бы тестером кабель прозвонить и посмотреть глазами на контакты в разъеме сетевой карты. Если кабель по улице лежит - может у вас сетёвку вообще водой залило.
Больше 3-х лет кабель на улице? Удивительно, как он вообще три года выдержал :) Обычно одна-две зимы и хана. Оплетка трескается, туда заливается вода, дальше мороз-оттепель и "привет КЗ" :)
Борис Белов: там в профиле теперь есть мой твиттер - логин скайпа - такой же, как идентификатор в твиттере. Добавляйся, но я за клавишами окажусь только часа через 2-3.
Я ж вроде написал выше "или вообще любых других хостов". В контексте апача это значит скорее всего - определить первым хостом некий хост, который будет принимать вообще все соединения.
Это, конечно, при условии что "зеркало1" и "зеркало2" - не ваши сайты.
Попробую расписать, но могу ошибиться, потому как с чистым апачем очень давно не работал.
В общем... сейчас у тебя (ничего, что на "ты"?) сделано так - в апаче есть только один виртхост. Вообще один. И как ты не ломись на веб-сервер, по любому адресу или айпишнику, если ты попал на сервер - открывается этот единственный виртхост в апаче.
Надо (учитывая, что у тебя стоит apache 2.2) использовать директиву NameVirtualHost *:80 (вроде так, если не ошибаюсь, можно прямо дописать в ports.conf перед директивой Listen) и сделать в апаче несколько виртхостов (в sites-available), один из которых должен быть примерно вот такой:
А вторым уже ваш сайт.
А теперь, надо сделать, чтобы дефолтный, который с редиректом - схватывался апачем первый.
Когда работал с дебианом, добивался этого именами симлинков виртхостов в sites-enabled. Допустим default.conf ставил симлинков в sites-enable/000-default.conf. А последующим виртхостам делал симлинки прямо по названию файла, которое обычно начинается не с цифры. Таким образом 000-default.conf цепляется в апаче первым и считается дефолтным.
В этом случае на виртхост с именем можно попасть только по имени, а если открыть в браузере IP-адрес или направить туда другое имя или вообще что угодно - сработает 301 редирект и браузер перейдет на сайт, указанный в редиректе.
З.Ы. Если кто-то заметил неточность - я с чистым апачем давно не работал. Всю подобную грязную работу гораздо лучше выполняет nginx.
А... да... вычистить спам-письма из очереди довольно просто. Когда вычислили скрипт, который отправляет спам-письма - просто сделайте поиск файлов по содержимому с названием этого скрипта в /var/spool/exim/input. Здесь уже не до сантиментов, можно их просто тереть. Exim сам разберется с отсутствующими письмами в очереди.
Вычислить спамера довольно просто. Обычно сгенеренные с помощью PHP письма имеют заголовок X-PHP-Originating-Script (если нет, то какой-то параметр надо включить в php.ini... сейчас просто времени нет искать). В этом заголовке указан файл, который и сформировал письмо. Ну а дальше ищем тот самый файл.
Скорее всего, у кого-то дыра в сайтике, через которую залили шелл, либо скрипт, с помощью которого POST-запросами формируют письмо на отправку и скармливают туда же список адресов.
Сразу предупреждаю:
1. На первый взгляд в файле будет все нормально
2. На второй взгляд найдется непонятная строка в base64 (которая и является именно тем недренным кодом, который портит всю малину)
3. Возможно строка не найдется сразу - излюбленные приемы спрятать - вставить строку в конец PHP через сотню-другую пустых строк, либо вставить в самое начало, но с предшествующими несколькими сотнями пробелов в строке, чтобы при открытии в редакторе строка уходила за край консоли (в этом случае, например, в mcedit здорово помогает клавиша F2 в режиме просмотра - она сворачивает строки в размер экрана).
4. Если строка нашлась - выключайте доступ к зараженному сайту (прям наглухо), а затем уже разбирайтесь. Обычно зараженным оказывается не один файл, а сразу несколько... плюс к тому, где-то должен лежать еще бэкдор, через который злоумышленник и изменяет файлы.
Вычислять злоумышленника обычно смысла нет - его работу выполняют боты. Все идет по четкому сценарию. Можно по логам вычленить адреса зловреда и прикрыть его файрволлом, но вряд ли это надолго поможет.
Там еще много чего в загашнике, но это первое, что вспомнилось.
Кирилл: Это зависит от того, кто у тебя принимает почту. Я уже даже забыл, как настраивать почтовик на приём почты :-) У меня обычно приемом почты заведует Yandex или Gmail, это гораздо проще, занимает меньше времени и убирает тучу проблем со спамерами и почтоклиентами.
Тёма Макеев: Если будет больше одного сайта - в этом случае вполне можно оставить только ssl_certificate и ssl_certificate_key в server, остальное вы вряд ли будете менять (ну может еще ssl_session_cache будете менять и dhparam, но сильно вряд ли это будет происходить именно на этой машине).
Заголовок Strict-Transport-Security тоже, имхо, излишен, если не задаются параметры тех самых Security.
Выкручивание буферов при отдаче чистого html - также сомнительная оптимизация, включая client_max_body_size, которого при отсутствии POST-запросов за глаза хватает дефолтного.
rewrite ^/(.+)/$ /$1 permanent; - вообще не сильно понятно, зачем. Чтобы после имени файла никто не дописывал слэш? А как быть с директориями? Обычно наоборот слэш дописывается... при вызове директории сначала сработает реврайт, а затем еще try_files три раза дернет диск, затем выведется index.html в директории, но в адресной строке будет некрасивый урл без слеша :) (У меня просто личная неприязнь к урлам без слешей :-) )
resolver действительно, лучше сделать локальный. Зачем дергать гуглоднс по разным неприятным запросам? Главное, если на сервере ipv6 нет, выключить его в named - встречал я непонятные тормоза и попытки отрезолвить сначала IPv6, а уже затем, после таймаута, IPv4.
nginx -tОн тебе покажет, где ошибка.