Plone 3.3.5 в CentOS 5.7 Apache 2.2 Виртуальный хост RewriteRule Проблема

Question

Я установил Plone 3.3.5 на CentOS 5.7 и поставил Zope позади Apache, чтобы URL-адрес «видел» мой веб-сайт Plone, я использовал понятия виртуального хоста и правила перезаписи. Тем не менее, полученный URL-адрес не очень приятный, хотя веб-страница отображается правильно.

Отредактированный файл httpd.conf:

NameVirtualHost 164.67.141.42:80

<VirtualHost 164.67.141.42:80>
    ServerName www2.oid.ucla.edu
    ServerAlias www2.oid.ucla.edu 
    ServerAdmin web@oid.ucla.edu
    ServerSignature On

    CustomLog  /var/log/httpd/www2-access.log combined
    ErrorLog   /var/log/httpd/www2-error.log
    LogLevel warn

 <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^/(.*) http://www2.oid.ucla.edu:8080/VirtualHostBase/http/www2.oid.ucla.edu:80/Plone/VirtualHostRoot/$1 [L]
 </IfModule>

<IfModule mod_proxy.c>
   ProxyVia On

   # prevent the webserver from being used as proxy
   <LocationMatch "^[^/]">
      Deny from all
      </LocationMatch>
   </IfModule>

</VirtualHost>

---

Полученный URL = "http://www2.oid.ucla.edu:8080/VirtualHostBase/http/www2.oid.ucla.edu:80/Plone/VirtualHostRoot/"

URL должен быть = "http://www2.oid.ucla.edu/"

Если я добавлю «P» в RewriteRule ^ / (. *) http://www2.oid.ucla.edu:8080/VirtualHostBase/http/www2.oid.ucla.edu:80/Plone/VirtualHostRoot/$1 [L,P] Это ошибка "Служба временно недоступна" на веб-странице.

В журнале ошибок написано: [ошибка] (13) Отказано в доступе: прокси: HTTP: попытка подключения к 164.67.141.42:8080 (*) не удалась

Что может быть причиной этого? Заранее спасибо!

Answer 1

Сначала я подумал, что вам, возможно, стоит взглянуть на параметры конфигурации zope, думая, что он может быть привязан к localhost, но ваш пример без флага прокси вызвал бы перенаправление на доменное имя, которое, как я понял, фактически вернуло реальный ответ Plone. , Так что, вероятно, это не так.

У вас могут быть проблемы с настройками SELinux. Чтобы проверить это, попробуйте это как root ...

$ echo 0> / selinux / принудительное исполнение

Это временно отключит SELinux. Если прокси теперь работает, вы нашли проблему. В этом случае вам может помочь следующее ...

$ / usr / sbin / setsebool -P httpd_can_network_connect 1

Но я предлагаю вам не применять это исправление, пока вы не прочтете немного о SELinux. Вероятно, не стоит крутить ручки настройки безопасности вашего сервера, не понимая, что вы делаете.

Возможно, это не имеет прямого отношения к вашему вопросу, но вот несколько других советов:

1) Вам не нужна строка ServerAlias. Указанный домен уже указан как имя сервера.

2) Другие уже отметили, что вам нужен флаг «P». Флаг «L» сам по себе в этом случае будет просто генерировать перенаправление, а это не то, что вам нужно. С флагом 'P' подразумевается буква 'L', поэтому подойдет только [P].

3) Сайт betabug.ch, упомянутый Martijn, в порядке, но обратите внимание, что он также неправильно добавляет флаг 'L' и предполагает, что начальный символ '/' может отсутствовать в некоторых запросах (в контексте VirtualHost путь всегда начинается с '/' - только в контексте Справочника вам следует беспокоиться об этом, чего у вас никогда не было в настройке Plone). Ни один из них не сломает RewriteRule - они просто бесполезно загромождают конфигурацию.

4) Вам не нужен бит LocationMatch для защиты от злоупотребления прокси. Вы настраиваете обратный прокси, а не прямой прокси. Это прямые прокси, которые требуют особого внимания. Если вы не уверены, есть ли у вас прямой прокси-сервер - или если вы параноик - просто отключите поведение прямого прокси-сервера с отключенным «ProxyRequests». Обычно вам не нужно беспокоиться об этом, так как ProxyRequests по умолчанию отключен.

Answer 2

Убедитесь, что у вас активирован и включен mod_proxy, и что ваш apache настроен на прокси. «P» в «[L, P]» означает «прокси», и mod_rewrite не сделает этого сам по себе

Answer 3

$ setenforce 0

с другой стороны, и прочитайте некоторую документацию selinux. Есть способ заставить его проглотить эту конфигурацию apache.

SELinux, это твой друг, конечно, но относись к НИМ с осторожностью:)