У меня проблемы с настройкой файлов httpd.conf или .htaccess для распознавания нескольких сайтов Zend Framework на одном сервере.
Для разработки у меня есть только один сервер, и я пытаюсь настроить сайты, чтобы я мог получить к ним доступ, например, localhost / app1, localhost / app2 и т. Д.
Так что сейчас, когда я захожу в localhost / app1, он успешно перенаправляет в localhost / app1 / public / index.php, однако, когда я захожу в localhost / app1 / index / index, я получаю 404.
Вот мой файл vhosts:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot "/var/www"
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory "/var/www/app1/public">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ErrorLog logs/error.log
CustomLog logs/access.log common
</VirtualHost>
и вот мой файл .htaccess из каталога / var / www / app1:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ /app1/public/index.php [NC,R,L]
Если я изменю строку DocumentRoot в файле vhosts на DocumentRoot "/var/www/app1/public"
, тогда app1 работает правильно, но я могу получить доступ только к этому ... на http://localhost. Возможно ли это? Я хочу, чтобы / var / www был корнем документа, а затем, если я перехожу на localhost / app1, эти запросы необходимо перенаправить на localhost / app1 / public / index.php, а если я перехожу на localhost / app2, то эти запросы необходимо перенаправить на localhost / app2 / public / index.php.
Надеюсь, я объяснил это ясно, любая помощь приветствуется.
В конце концов
Мне больше всего понравилось решение Фила, потому что я не хотел менять свой локальный файл hosts и использовать директиву ServerName. Было бы хорошо в производственной среде, если у вас есть отдельное доменное имя для каждого приложения, но не для разработки.
В дополнение к этому у меня возникла проблема с 403 при использовании альтернативного каталога для обслуживания веб-контента. Как я уже говорил, perms казался правильным, проблема была в SE_Linux, а контекст безопасности файлов не был установлен в httpd_sys_content_t. Я публикую то решение, которое я нашел здесь , так как оно имеет дело именно с проблемой. Спасибо.