Помогите решить проблему.) На домашнем сервере debian squeeze установлен Barracuda Octopus Aegir - мультисайтинг менеджмент версии 2.0.4. nginx 1.3.8\ php-fpm 5.3\MariaDB 5.5\ Redis Конфиг nginx очень сложный, разбросан по множеству файлов. Часть его касается aegir, а часть - виртуальных хостов им создаваемых посредством drush. Конфиг очень заточен именно под друпал и его модули. Исполнение, php за исключением разрешённых в конфиге относящимся к модулям drupal - запрещено, а то что разрешено - относится не к самим сайтам, а к платформам - одна платформа типа pressflow 6.26.2 - prod через drush может может "порождать" неограниченное число сайтов этого типа, расшаривая модули на всех.Доступ к самим сайтам через wildcard dns.
Недостатки этого способа есть - один из них, это огромное число конфигов, разбросанных по серверу, трудность с не стандартными для этого метода решениями. Достоинства - скорость и защищённость, а также лёгкость создания, сайтов и управления через aegir. Развёртывание происходит в автоматическом режиме скриптами, - на то чтобы вручную проделать подобное нужно в десятки раз больше времени. Ну и самое главное - легко создать сайт, потренироваться с ним, уничтожить, забэкапить, клонировать, портировать. В общем, есть свои плюсы. Час - два и готовый мультихостинг))) Это не реклама. Это к тому, почему я не хочу отказаться от BOA. Да и в этом случае, чего будет стоить перевести сайт на "ручное управление" по времени. Ну как вариант это можно рассмотреть, если совсем худо будет. )))
Короче, пока дело касалось Drupal, проблем практически не возникало. Главная - не забывать права в папках расставлять, заливая файлы на сервер, чтобы автомейшен не сбоил в drush. Вот и всё. К длинным путям внутри сервера тоже привык. Всё уже натыкано. Да, на сервере поднял bind, который в локалке обеспечивает wildcard dns, а наружу только один сайт смотрит. Это потому, что у меня динамический ip. Я ещё только месяца четыре осваиваю drupal, пока рано выходить на серьёзную платформу. Есть ещё рутер, потому внутренний ip постоянный, и сервер привязан к нему. Я использовал dyndns.org. Домена два - *.dyndns.org и *.dyndns.info.
По первому привязан drupal и сервер. А второй я попытался привязать к форуму. Вот из-за форума и проблема. Друпаловский форум не вдохновил, я попробовал установить phpBB3. Установил, даже нашёл где в конфигах nginx отключить запрет на исполнение php и добитлся установки. Ну думал что сначала так с дырой в безопасности поживу, потом разберусь как octopus приручить. И оно даже работало, за исключением того, что запросы связанные с search.php вместо исполнения выдавали скрипт на закачку. Ну это стоило долгого копания в этом осминоге, безрезультатно. Да и дыра не вдохновляла. Следующей идеей было поставить форум отдельно. Но в BOA всё настолько взаимосвязано, да и все основные порты заняты. Я почитал поддержку от производителя - они просто отмазались, что их система - только для drupal. Попробывал поднять другой сервер nginx в chroot, но но что-то всё стало тормозить))). Короче, просто воткнул апач, привязал его к 81 порту, и на нём установил форум. Конечно, когда я набираю *.dyndns.info:81 - так сразу попадаешь в рутовую директорию форума. С этим нет проблем, и вообще нет с форумом. Но если по дефолтному порту - nginx бодро отправляет в "under constuction" - стандартную отмазку осминога, для wildcard name домена не привязанного к конкретному сайту. В локальной сети bind обе зоны адресует на локальный ip сервера. Так что сортировать их можно только по порту и собственно имени. 8080, 80, 443 заняты nginx. Я нашёл в конфиге nginx include которые относятся не к платформам, а к управлению хостингом - то есть самому aegir и серверу. Это серверы управляющего уровеня, так что на этом уровне я завёл ещё один виртуальный сервер. Он слушает 81 и проксирует на апач, не фильтруя контент. В корне форума индексный файл с метатегом делает редирект на главную страницу форума. Под это дело даже google analitics заработал. Но есть одна проблема. Если указать в браузере просто *.dyndns.info - то попадаем в under constuction. А если *.dyndns.info/la-la-la - то корректный переход и результат, в зависимости от того la-la-la - соответствует реальному адресу на форуме, или нет. То есть всё работает, но чисто по имени сайта попадаем в яму. И в доверешении всего, хоть analitics нормально работает, google webmaster не может подтвердить права на сайт. (форум). Я так понимаю, что бот тоже обломается. Конфиг проксирования приведу ниже. Остальные конфиги BOA nginx я восстановил в фабричном виде. Так что добавлен только один виртуальный хост с заднего хода))) Простите, что так долго описывал. Хотел чтобы понятнее было в общем ситуацию. Сейчас конфиг приведу.

nano /var/aegir/config/server_master/nginx/vhost.d/xxxx.dyndns.info

Это конфиг хоста который я добавил.

server {
include /var/aegir/config/includes/fastcgi_params.conf;
limit_conn gulag 30;
listen 192.168.1.101:80;
server_name xxxx.dyndns.info;
root /var/www/xxxx;
# index index.php index.html;
access_log off;
location / {

proxy_pass http://127.0.0.1:81;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}

Я заменил реальный префикс на xxxx. Раскомментирование # index index.php index.html; ничего не меняет.

Ближайшее, что приходит на ум - это проверка на точное соответствие xxx.dyndns.info в запросе к серверу, замена его его xxx.dyndns.info/index.htm .html .php и продолжение сервировки осминогом. Я догадываюсь, что эта фильтрация происходит где-то раньше. Я даже знаю в какой папке это under constract... - сама картинка. Я найду в конфигах, гда это происходит. Но я не знаю, как сделать эту проверку - в смысле как выглядит строка с условием, какие переменные задействуются. Осминог скорее всего пропускает запрос через фильтры, а остаток который не пришёлся полезным - отправляет в яму. Учитывая размеры конфигов, поиски могут затянуться. )))Может быть этот перехват проще сделать средствами debian - например iptables или скрипт?

Блин, глупо запарился. Проблема решилась банально rewrite.

server {
server_name xxx.dyndns.info;
rewrite (.*) http://xxx.dyndns.info/index.php$1;
}

Всё работает. Остался тюнинг параметров чтобы google бот не "думал", что его с одного сервака на другой кидают. IP внутренний один. Надо подумать. И как скрыть в строке браузера index.php. Но это уже апч крутить.

Конфиг принял вид:

server {
server_name xxx.dyndns.info;
rewrite (.*) http://xxx.dyndns.info/index.php$1;
}

server {
include /var/aegir/config/includes/fastcgi_params.conf;
limit_conn gulag 30;
listen 192.168.1.101:80;
server_name xxxx.dyndns.info;
root /var/www/xxxx;
# index index.php index.html;
access_log off;
location / {

proxy_pass http://127.0.0.1:81;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}

Ну и в итоге я снова выкинул апач и вернулся на php-fpm. Весь этот путь чтобы вычислить как работает nginx в этой среде BOA.

Теперь так

server {
server_name veda.dyndns.info;
rewrite (.*) http://veda.dyndns.info/index.php$1;
}

server {
include /var/aegir/config/includes/fastcgi_params.conf;
limit_conn gulag 30;
listen 192.168.1.101:80;
server_name veda.dyndns.info;
root /var/www/veda/forum;
# index index.php index.html;
access_log off;


location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name;
include fastcgi_params;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_intercept_errors on;
fastcgi_ignore_client_abort off;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 180;
fastcgi_read_timeout 180;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
try_files $uri =404;

}
}

Всё пучком.