X-сообщение из StackOverflow
Я прочитал бесчисленное количество сообщений на форуме об этом, но ни один из ответов, похоже, не помог в моей ситуации. Вот выдержка из журнала:
[proxy_fcgi:error] [pid XXXX] [client redacted] AH01071: Got error 'Unable to open primary script: /home/user-account/public_html/www/index.php (No such file or directory)'
Я проверил вручную, что этот файл доступен для чтения через SSH; Кроме того, через браузер можно получить доступ к другим файлам, отличным от php.
Моя структура каталогов выглядит следующим образом:
/home/user-account
/home/user-account/apps
/home/user-account/apps/old
/home/user-account/apps/current
/home/user-account/public_html
/home/user-account/public_html/old > symlink to > /home/user-account/apps/old
/home/user-account/public_html/test > symlink to > /home/user-account/apps/current
/home/user-account/public_html/www > symlink to > /home/user-account/apps/current
У меня есть 2 поддомена на domain.com:
old.domain.com
test.domain.com
Поэтому из-за того, как cPanel / WHM / Apache записывает свои виртуальные хосты (с учетом директивы ServerAlias), результирующая структура домена выглядит так:
old.domain.com
www.old.domain.com (I ignore this)
test.domain.com
www.test.domain.com (I ignore this)
domain.com (.htaccess redirects to www.domain.com)
www.domain.com (This is the domain with the issue; also domain.com would be an issue if not for the redirect)
До сих пор я разрабатывал свой сайт на wordpress в реальном каталоге. /home/user-account/public_html/test. Сайт в идеальном рабочем состоянии. Тогда я решил пойти вживую. Я переместил настоящую папку в ее текущее местоположение (/home/user-account/apps/current) и символические ссылки /home/user-account/public_html/test к нему. Я перезапустил Apache и проверил test.domain.com сайт по-прежнему работал, как ожидалось (тестирование символической ссылки). Чувствуя уверенность в настройке символической ссылки, я удалил свою исходную символическую ссылку /home/user-account/public_html/www (указывая на мое старое приложение для рельсов на /home/user-account/apps/old) и создал новый, указывающий на /home/user-account/apps/current. Вот тогда и началась проблема.
httpd.conf:
Единственное заметное различие между тестовым поддоменом и основным доменом (с псевдонимом www) заключается в том, что автоматически сгенерированные директивы тестового поддомена указывают на истинное расположение папки с псевдонимом (DocumentRoot / Directory / ScriptAlias все используют /home/user-account/public_html/test). Я считаю, что это произошло потому, что я использовал cPanel для создания поддомена, который должен был указывать на каталог внутри /home/user-account/public_html. Но все автоматически сгенерированные директивы основного домена указывают на /home/user-account/public_html вместо того /home/user-account/public_html/www.
тем не мение, apache 2.4 позволяет мне включать настраиваемые параметры конфигурации виртуального хоста, помещая мои файлы custom.conf в соответствующие каталоги. Так что для тестового поддомена они мне не нужны, но мне пришлось использовать их для основного домена; Я знаю, что они работают, потому что журнал ошибок (находится в верхней части этого сообщения) показывает, что он использует правильный DocumentRoot. Вот отрывок из std custom.conf, показывающий, что помимо установки DocumentRoot я также явно переопределяю другие автоматически сгенерированные директивы:
DocumentRoot /home/user-account/public_html/www
<IfModule mod_include.c>
<Directory "/home/user-account/public_html/www">
SSILegacyExprParser On
</Directory>
</IfModule>
<IfModule alias_module>
ScriptAlias /cgi-bin/ /home/user-account/public_html/www/cgi-bin/
</IfModule>
<IfModule ssl_module>
<Directory "/home/user-account/public_html/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
</IfModule>
Права доступа к файлам:
Я не изменил права доступа к файлам по сравнению с их исходными настройками и уже подтвердил их правильность. Очередной раз, test.domain.com работал как положено. Это только (www.?)domain.com это не так.
Другие «исправления», которые ничего не сделали:
Статистика сервера:
Что бы вы ни рассматривали, помните, что практически нет разницы между файлами в тестовом поддомене и в основном домене (включая .htaccess); они оба связаны с одним и тем же каталогом. Единственное различие, которое я вижу, заключается в том, что test - это зарегистрированный поддомен, и поэтому httpd.conf обрабатывает его немного иначе, чем основной домен. Однако я не могу просто добавить субдомен «www» через cPanel - это не позволит мне - возможно, потому, что он все равно является псевдонимом www.
Я копался, пытаясь исправить это, и мой общедоступный веб-сайт не работал более 24 часов, поэтому я был бы очень признателен за любую помощь, которую вы можете предоставить!
Дополнение:
Я не знаю, актуально ли это (похоже, это не повлияло на мое старое приложение rails), но в WHM> Manage SSL Hosts мой основной домен и субдомен www указывают на корень документа /home/user-account/public_html, тогда как мои поддомены указывают на правильные соответствующие каталоги.
Я также попытался настроить vhost в основном домене для использования тестового каталога (такого же, как тестовый субдомен), но это дает мне ту же ошибку. Я не думаю, что это проблема с разрешением / файлом.
Я также создал файл test.php в /public_html каталог, чтобы проверить прямой доступ. Он по-прежнему ошибался и регистрировался:
AH01071: Got error 'Unable to open primary script: /home/user-account/public_html/www/index.php (No such file or directory)', referer: https:// domain.com/test.php
И ответ заключается в том, что мне пришлось установить doc_root через конфигурацию PHP-FPM для данного домена. Зачем? Я не знаю - если кто-то может пролить свет на это, я бы предпочел не делать что-то через конфигурацию FPM и, если возможно, настраивать ее через Apache. Мне не нужно этого делать для поддоменов ...