apache + redmine 403 - представления хороши

Question

Я много об этом искал, но решения не очень помогают. Я пытался обновить Redmine до версии 2.6.5 на моем FreeBSD, но у меня ошибка 403.

журнал ошибок apache:

[autoindex: error] AH01276: Невозможно обслуживать каталог /usr/local/www/redmine/public/: не найдено соответствующего DirectoryIndex (нет), а сгенерированный сервером индекс каталога запрещен директивой Options

мой httpd conf:

<VirtualHost example.com:80>
   DocumentRoot "/usr/local/www/redmine/public"
    ServerName example.com

      FastCgiServer /usr/local/www/redmine/public/dispatch.fcgi -idle-timeout 120 -initial-env RAILS_ENV=production -initial-env PATH=/usr/local/bin -processes 2

<Directory "/usr/local/www/redmine/public">
   AddHandler fastcgi-script fcgi
   Order allow,deny
   Allow from all
   AllowOverride all
   Options  +FollowSymLinks +ExecCGI
   RewriteEngine On
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^(.*)$ dispatch.fcgi
</Directory>
    ErrorLog /logs/error.log
</Virtualhost>

я должен сказать: если я добавляю + индексы в Option, я вижу файлы в своем браузере, так что я думаю, что предпочтения хорошие. Кто-нибудь может дать мне любую подсказку? заранее спасибо 4 ваша помощь

Answer 1

В моей ситуации проблема была вызвана ошибкой в ​​модуле apache ModAutoIndex. Отключение модуля сделало свое дело.

См. https://serverfault.com/a/731859

Отключение автоматического индексации модуля (которое является причиной неправильного поведения, предотвратит ошибку).

#LoadModule autoindex_module modules/mod_autoindex.so

Phusion решит эту проблему в версии Passenger 5.0.22 до выпуска Apache 2.5.0.

Answer 2

Я столкнулся с той же проблемой при установке ArchLinux с Apache 2.4 и Redmine 2.6.5. Вместо fcgi я использую сервер веб-приложений Phusion Passenger, но при доступе к серверу я всегда попадал на страницу 403 Forbidden.

С +Indexes Я также получил содержимое общедоступного каталога Redmine в браузере.

При использовании webrick или пассажира непосредственно для размещения Redmine все было хорошо. Вот как вы можете убедиться, что ваш Redmine не поврежден. Из корневого каталога Redmine запустите:

bundle exec ruby scripts/rails server -e production 

Поскольку я использую RVM для управления версиями ruby ​​и наборами гемов в системе, я также могу сказать, что поведение не связано с ruby ​​(я пробовал каждую версию с 1.8.x до 2.2.x без каких-либо изменений).

В конце концов я заменил Apache на nginx 1.8.0 (стабильный выпуск) и вернул Redmine к работе. Так что с пассажиром довольно легко прокатиться. Просто беги

gem install passenger

так что вы получите пассажирский пакет. А затем скомпилируйте nginx с пассажирским модулем, используя

passenger-install-nginx-module

Вы получите автоматический диалог, который загружает nginx и компилирует его с соответствующей конфигурацией. По умолчанию он будет установлен в /opt/nginx

В ArchLinux вы бы предпочли использовать ABS для получения PKGBUILD и добавить следующее в часть конфигурации

--add-module=$(passenger-config --nginx-addon-dir) \

Таким образом, вы также получаете системный файл для запуска и остановки nginx.service

И последнее, но не менее важное: вот конфигурация nginx, которую я использую для запуска Redmine:

server {                                                                    
  listen 80;                                                              
  server_name redmine.example;                                        
  root /usr/share/webapps/redmine-2.6.5/public;                           
  passenger_base_uri /;                                                   
  passenger_app_root /usr/share/webapps/redmine-2.6.5;                    
  passenger_document_root /usr/share/webapps/redmine-2.6.5/public;        
  passenger_enabled on;                                                   

  passenger_ruby /usr/local/rvm/gems/ruby-1.9.3-p551@redmine/wrappers/ruby;
}

Использование другого веб-сервера может быть непростым шагом, но мне потребовалось менее 2 часов, чтобы запустить Redmine и запустить его с nginx по сравнению с почти 2 днями потраченного впустую времени, чтобы выяснить, почему, черт возьми, Apache больше не обслуживает веб-приложение.