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

[warn] [client x.x.x.x] mod_fcgid: HTTP request length 138329 (so far) exceeds MaxRequestLen (131072)

Установлен apache + mod_fcgi. При аплоаде файлов свыше 128к получаем 500-ю ошибку, а в логе пишется сабж.
Фикс простой. Открываем конфиг mod_fcgi и увеличиваем максимальный размер, например в 10 мб:

# nano /etc/apache2/mods-enabled/fcgid.conf
<IfModule mod_fcgid.c>
  AddHandler    fcgid-script .fcgi
  FcgidConnectTimeout 20
  MaxRequestLen 10485760
</IfModule>

после релоада апачи - все работает.

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 полный автомат

Как добавить 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

Перенаправление трафика через .htaccess без параметров в адресной строке

Бывают случаи, когда нужно перенаправить весь трафик с одного сайта на другой. Однако структура сайтов различна и необходимо перенаправить посетителей с www.site-1.com на главную страницу www.site-2.com, но при этом не передавать параметры запроса в адресной строке.
Например, посетитель пришел по ссылке www.site-1.com/index.php?f=12&as=23 при этом редирект установлен на www.site-2.com. При обычном перенаправлении, параметр f=12&as=23 так же будет передан.
Чтобы этого избежать, необходимо создать два файла в корне site-1.com.
файл .htaccess:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ http://www.site-1.com/redirect.php


Данные директивы указывают перенаправлять весь трафик на php-скрипт redirect.php
Создадим файл redirect.php и напишем внутри:
<?php
header ("Location: http://www.site-2.com");
?>

В результате мы получаем "чистый" редирект с site-1.com на site-2.com без параметров в запросе

Nginx как проксирующий фронт-енд к Apache

Что имеем:

Самый обычный набор namebased хостинг-провайдера:
- apache 1.3.x
- DirectAdmin
- на сервер на базе CentOS 5.x и тормоза при отдаче страниц клиентам

Что получим:
- Nginx в качестве фронт-енда для Апачи
- автосоздание конфигов для виртуал.хостов из Directadmin
- ограничение количества коннектов с одного IP
- ощутимое снижение нагрузки на сервер и на Apache

Установка nginx.
Скачиваем стабильную ветку (на момент написания 0.6.32 - последняя стабильная версия) :
# wget http://sysoev.ru/nginx/nginx-0.6.32.tar.gz
# tar -zxvf ./nginx-0.6.32.tar.gz
# cd nginx-0.6.32

в файле configure указываем нужные модули, а неиспользуемые лучше отключить. Большое количество модулей немного замедляет работу nginx.
У меня nginx собирается такой:

cat ./myconfigure
#!/bin/sh
./configure \
--prefix=/usr/local/nginx \
--sbin-path=/usr/bin \
--without-http_ssi_module \
--without-http_auth_basic_module \
--without-mail_pop3_module \
--without-mail_imap_module \
--without-mail_smtp_module \
--user=apache \
--group=apache \
--with-http_stub_status_module \
--with-http_realip_module \
--without-http_charset_module \
--without-http_memcached_module \
--without-http_upstream_ip_hash_module \
--without-http_browser_module \
--with-http_flv_module \
--with-http_sub_module \
--error-log-path=/var/log/nginx/error.log \
--http-log-path=/var/log/nginx/access.log

# ./myconfigure
....
# make ; make install

Далее надо будет настроить конфиг nginx и шаблоны апачевского конфига от директадмина
...
Будет больше времени, допишу как это все это сделал....