apache и htaccess

Итак, дано: сервер с директадмином и стандартными настройками apache.
До определенного момента все прекрасно работало и "вдруг" перестало.

Симптомы:
у одного из юзеров перестали выполняться cgi скрипты, на многих доменах вместо сайта - 404 ошибка или 403.
В корне доменов (domain/public_html/...) файла htaccess нет, но такое впечатление, что делается переопределение с index.php на index.html и другие манипуляции с типами.
Конфиги апачи правильные, ничего подозительного нет. У пользователя в аккаунте более 300 доменов, подумалось, может какие грабли у апачи при таком количестве доменов на одном пользователе.
Оказалось что проблема совсем в другом и достаточно тривиальна.

Фикс проблемы.
Выяснил, что в корне хомки (/home/username/) лежит файлик .htaccess, где все и реврайтилось.
После переименования /home/username/.htaccess все заработало как прежде.

Дополнение.
Точно также себя ведет вебсервер под ISPmanager-ом.

Вывод.
Не создавайте .htaccess выше public_html, т.е. выше корня сайта.
По крайней мере это касается серверов с directadmin-ом

mod_ruid2 и php mail() = sender verify failed

При использовании apache + mod_ruid2 в некоторых случаях может не доставляться почта, отправленная с помощью php-шной функции mail(), не смотря на все корректно заполненные заголовки.

При попытке отправить письмо приходит "отлуп":

Subject: Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could
not be delivered to one or more of its recipients. This is a permanent error.
The following address(es) failed: remoteuser@domain.com
SMTP error from remote mail server after
RCPT TO:: host mx.domain.com.ua [89.1xx.xx.xx]: 550 Can't verify sender

Кто-то уже сталкивался с таким ?

Update:
Вылечилось легкой правкой конфига Exim-а

Причина проявления данного эффекта связана с тем, что вот эта директива, указанная в юзеровском httpd.conf:

    php_admin_value sendmail_path '/usr/sbin/sendmail -t -i -f user@domain.net'

полностью игнорировалась.

Фикс такой - добавляем в конфиг ексима следующее:

local_from_check = false
local_sender_retain = true
untrusted_set_sender = *

Перезапускаем и наслаждаемся отсутствием описанной выше проблемы.

Для справки.
до установки мода mod_ruid2 php скрипты работали под именем apache. В свою очередь, пользователь apache входит в trusted_users в конфигурации ексима.
Поэтому заголовок 'Sender:' изменялся с помощью "sendmail -t -i -f user@domain.net" вполне нормально.

После установки mod_ruid, скрипты выполняются уже от имени владельца, который не входит в trusted_users и естественно не мог сделать подмену 'Sender:' и 'From:'

Обновляем Exim для Directadmin

Все еще используете ексим 4.69 ?
Пора обновить версию.
Можно, конечно, собрать из исходников (как описано тут), а можно просто поставить уже готовый пакет.
Скачиваем и ставим пакет с сайта directadmin.
Для Debian:

# cd /usr/local/directadmin/custombuild
# wget http://files.directadmin.com/services/debian_5.0/da_exim-4.72.deb
# dpkg -i da_exim-4.72.deb

Для Debian 64bit:

http://files.directadmin.com/services/debian_5.0_64/da_exim-4.72.deb

Для CentOS:

# cd /usr/local/directadmin/custombuild
# wget http://files.directadmin.com/services/es_5.0/da_exim-4.72-2.i386.rpm
# rpm -Uvh da_exim-4.72-2.i386.rpm

Возможно понадобится доставить отсутствующие библиотеки (libperl5.10, db4 и т.д.).
Если отвалился TLS - выставить нужные права на /etc/exim.key (chown mail: /etc/exim.key)

Еще можно использовать dkim, достаточно поправить exim.conf и добавить проверки:

acl_smtp_dkim    = acl_check_dkim
.....
.....
###############################
#       ACL check_dkim        #
###############################
acl_check_dkim:
  defer dkim_status = fail
     logwrite   = DKIM test failed: $dkim_verify_reason
     message    = DKIM test failed: $dkim_verify_reason
     add_header = X-DKIM-FAIL: DKIM test failed: \
                  (address=$sender_address domain=$dkim_cur_signer), \
                  signature is bad.
  warn  dkim_status = invalid
     add_header = :at_start:Authentication-Results: \
                  $dkim_cur_signer ($dkim_verify_status); $dkim_verify_reason
     logwrite   = DKIM test passed (address=$sender_address domain=$dkim_cur_signer), \
                  but signature is invalid.
  accept dkim_status = pass
     add_header = :at_start:Authentication-Results: dkim=$dkim_verify_status, \
                  header.i=@$dkim_cur_signer
     logwrite   = DKIM test passed (address=$sender_address domain=$dkim_cur_signer), \
                  good signature.
  accept

Теперь ексим будет проверять цифровую подпись (если она есть) для входящих писем.
Для проверки можно отправить письмо с гугло- или mail.ru ящика. При получении письма в логе можно увидеть результат проверки:

2010-12-27 09:31:21 1PXxxx-000xxx-PR DKIM: d=gmail.com s=gamma c=relaxed/relaxed a=rsa-sha256 [verification succeeded]
2010-12-27 09:31:21 1PXxxx-000xxx-PR DKIM test passed (address=user@gmail.com domain=gmail.com), good signature.
...
2010-12-27 12:01:26 xxxx-xxx-FX DKIM: d=mail.ru s=mail c=relaxed/relaxed a=rsa-sha256 [verification succeeded]
2010-12-27 12:01:26 xxxx-xxx-FX DKIM test passed (address=user@mail.ru domain=mail.ru), good signature.

DKIM можно использовать как дополнительную проверку для фильтрации почты.

apache и mod_ruid — исполнение скриптов от имени пользователя

При использовании mod_php все скрипты исполняются от имени веб-сервера (www-data, apache, etc), из-за чего довольно трудно определить чем занят тот или иной процесс и кто делает нагрузку.
Да, можно использовать suPHP, fastCGI и т.д. Но в таком случае можно забыть про выставление параметров в .htaccess, потеря производительности, невозможность использования mod_php и другие фишки.
Можно использовать peruser или mpm-itk. В первом случае будут плодиться процессы, каждый из которых будет кушать память, что не особо хорошо.
Во втором случае - нужно пересобирать апач.

Как же быть ?
Как вариант - использовать модуль mod_ruid2. Почему именно mod_ruid ? Одна из причин - модуль поддерживается и развивается. Последний коммит в svn сделан неделю назад (от даты данного поста), это вселяет определенную надежду, что модуль и дальше будет развиваться, а найденные баги будут исправляться. mod_ruid не требует пересборки ни apache ни чего либо еще, будут нормально работать акселераторы (eAccelerator, xcache).

Читать дальше apache и mod_ruid — исполнение скриптов от имени пользователя

Directadmin+nginx полный автомат

Доброго всем LOCALTIME ! 🙂

Решил поделиться с общественностью своими скриптами для связки directadmin и nginx.

В свое время для снижения нагрузки на apache было решено поставить nginx. После некоторого гугления была сделана первая попытка связать панель и nginx. На тот момент скрипт умел совсем немного - только создавать и удалять конфигурационные файлы виртуальных хостов. Он не умел работать ни с поддоменами, ни с алиасами, не умел и переименовывать конфиги доменов.

Затем последовала вторая попытка. Этот скрипт уже был немного "умнее". Он умел создавать, удалять не только домены, но и поддомены. Однако, после того, как количество вирт. хостов выросло и управляться с большим количеством доменов стало как-то трудно, было решено полностью переписать всю схему работы связки directadmin и nginx. Все домены/поддомены/алиасы будут описываться в map-файле, а в конфиге будут использоваться соответствующие переменные, тем самым будет использоваться всего один небольшой общий конфиг, в котором и описывается виртуальный хост.
"Особые" домены описываются в отдельных конфигурационных файлах.
Кроме того, логи для всех вирт. хостов будет писать nginx, освободим нашего монстра apache от этой обязанности и оставим ему писать только error_log. Что положительно скажется на производительности.

Сказано - сделано.
По моей просьбе и некоторому подобию ТЗ, мой друг Александр Русских написал совсем новый и удобный скрипт, который и будет использоваться в этой статье.
Еще одна моя просьба была направлена Кириллу Коринскому, который написал небольшой патч для nginx. Данный патч выдает 503 ошибку, если уровень load average системы выше заданного в конфиге значения. Да, это грубо, но зато может уберечь сервер от ухода в глубокий своп. Поэтому уровень LA необходимо указывать заведомо высокий.

Итак, поехали.

Часть первая (Если nginx уже установлен - смотрим вторую часть)
У нас в распоряжении сервер с установленной панелькой DirectAdmin (отличная, кстати, панель). Чтобы не делать из системы свалку, nginx будет ставиться из репозитария.

Добавляем репозитарий в список, импортируем ключи и ставим nginx:

# echo "deb http://ftp2.debian.org.ua/debian-dou/ lenny main" >> /etc/apt/sources.list
# gpg --keyserver keys.gnupg.net --recv-keys 0A3D4789
gpg: requesting key 0A3D4789 from hkp server keys.gnupg.net
gpg: key 0A3D4789: public key "Debian.org.ua Custom Repository " imported
gpg: Total number processed: 1
gpg:               imported: 1
# gpg --armor --export 0A3D4789 | apt-key add -
OK
# aptitude update
# aptitude install nginx

Стоит заметить, что в этот пакет включено два неофициальных патча, которые описаны в блоге автора

После установки nginx не запустится - это нормально, так как на 80-м порту все еще работает apache.
Дальше будем приводить в порядок конфигурационные файлы apache и nginx.
Читать дальше Directadmin+nginx полный автомат

mysql init-скрипт для directadmin

Мне крайне не нравится дефолтовый mysql инит скрипт, который идет в поставке Directadmin, потому как работает он крайне некорректно. Взял я штатный дебиановский инит-скрипт и приспособил его для работы с mysqld, который поставляется с панелью Директадмин.
Работает на все 100%, как и полагается в Дебиане.

Сам скрипт качаем тут

Выслушаю любые предложения/пожелания относительно данной модификации.

Как добавить XSL без пересборки php на сервере с DirectAdmin

Если после сборки остался каталог с исходниками php, то включить модуль довольно просто:

# cd /usr/local/directadmin/custombuild
# cd php-5.2.12/ext/xsl
# phpize
# ./configure
# make && make install

после чего, модуль xsl.so будет находится в /usr/local/lib/php/extensions/no-debug-non-zts-20060613

Добавляем в php.ini

extension=xsl.so

И напоследок делаем "мягкий" рестарт апача:

apachectl graceful

Конфиг exim.conf для DirectAdmin

Притомил меня спам от всяких левых и правых серверов.
Решил немного пошаманить над конфигом ексима. Шаманство довело до того, что был полностью переработан штатный конфиг, прикручен небольшой избирательный грейлистинг и dspam-фильтр, а также черные и белые списки.
От spamassasin отказался полностью (в пользу dspam, который будет описан в отдельной статье) ибо памяти кушает не слабо, особенно когда вал входящей почты идет, а эффективность его немного страдает.

После шаманства спам упал практически на 80-90%. Остальное проходит через грейлистинг и потом dspam.

Принцип фильтрации следующий.
На стадии connect дропаются все динамические сети типа *.pool.* *.dsl.* *.dialup.*и т.д. (ну откуда там будет нормальный почтовик ?)
Далее дропаются все хосты с некорректным/непрописанным HELO
В check_recipient дропаются хосты, которые в черном списке. Там же проверка на наличие обратной зоны, прописанного хостнейма и присутствия данного хоста в RBL-списках. Причем почта от таких не дропается, а направляется на грейлист.
В грейлист так же уходят те хосты, которые решили зайди по smtp вместо esmtp.
Решил проблему (вроде бы) c backscatterer.org (что сие есть - см. на их сайте) и спамом  через bounce (отлупы)

Особо расписывать не буду, конфиг приложил. Черный список тоже.

При написании конфига была использована информация с рассылки exim.org.ua, mta.org.ua и lissyara.su

Если кто вдруг наткнется и будет использовать у себя - за последствия я не отвечаю.
Используйте на свой страх и риск.

Однако, я буду рад любым комментариям, дополнениям и изменениям.

Файлы:
exim.conf
blacklist_helo
blacklist_host_name

Exim + Greylist + Directadmin

В предыдущей статье я описывал как ставил грейлист  на тазик с панелью directAdmin на CentOS-е.

Нашел время написать как я ставил greylist  под Debian
Итак, имеем: Debian Lenny, DirectAdmin, exim из комплекта панели. Потребуется установить демон greylistd и после чуть подправить конфиг ексима.
Приступаем:

aptitude update
aptitude install  greylistd

Теперь необходимо поправить конфиг ексима. Ищем первый accept  в acl_smtp_rcpt и добавляем перед ним:
[eng]Now need to change exim.conf. Find first 'accept' in 'acl_smtp_rcpt' and add before:

# GreyListing
    defer   message    = Sender verification for $sender_host_address in progress. Please try later.
        log_message    = greylisted.
        !senders       = :
        !hosts         = : +relay_hosts : +whitelist_hosts : +whitelist_hosts_ip
        !authenticated = *
        !domains       = : ${if exists {/etc/greylistd/skip-greylist}\
                                 {/etc/greylistd/skip-greylist}{}}
        domains        = +local_domains : +relay_domains
        verify         = recipient/callout=20s,use_sender,defer_ok
        condition      = ${readsocket{/var/run/greylistd/socket}\
                            {--grey \
                                  $sender_host_address \
                                  $sender_address \
                                  @$domain}\
                              {5s}{}{false}}
    deny   message = $sender_host_address is blacklisted
        log_message = blacklisted.
        !senders       = :
        !authenticated = *
        verify         = recipient/callout=20s,use_sender,defer_ok
        condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--black \
                                  $sender_host_address \
                                  $sender_address \
                                  $local_part@$domain}\
                                 {5s}{}{false}}

Далее, ищем в ACL acl_smtp_data первый accept и вставляем перед ним:
Next, find first 'accept' in ACL acl_smtp_data and add before this code:

     defer
        message        = Sender verification for $sender_host_address in progress. Please try later.
        log_message    = greylisted.
        senders        = :
        !hosts         = : +relay_hosts : +whitelist_hosts : +whitelist_hosts_ip
        !authenticated = *
        condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--grey \
                                  $sender_host_address \
                                  $recipients}\
                                  {5s}{}{false}}
    deny
        message = $sender_host_address is blacklisted from delivering \
                     mail from <$sender_address> to <$recipients>.
        log_message   = blacklisted.
        !senders       = :
        !authenticated = *
        condition      = ${readsocket{/var/run/greylistd/socket}\
                                 {--black \
                                  $sender_host_address \
                                  $recipients}\
                                  {5s}{}{false}}

В файле /etc/greylistd/skip-greylist можно прописать домены (локальные) для которых не включать грейлистинг. Формат файла простой - один домен на строчку.
Вот собственно все.

In file /etc/greylistd/skip-greylist you can write whitelisted domains. One domain per line.

Если будет свободное время, напишу как прикрутить DSPAM  + Exim + Directadmin