Что такое корневой каталог сайта: Что такое корневая директория ✔ и как ее изменить?

Что такое корневой каталог сайта, как его найти

Корневой каталог (корневая папка, корень) сайта — как его найти, как добавить туда файлы и вообще, что это такое.  В начале работы над сайтом эти вопросы могут ставить в тупик. На самом деле все просто и Вы сами в этом скоро убедитесь.

Корневой каталог — это папка, в которой хранятся файлы сайта.

Есть два способа добраться до этой папки: через панель управления на Вашем хостинге и через FTP. Первый способ проще, с него и начнем.

1.  В панели управления хостинга ищем раздел управление файлами. Названия могут отличаться:  файловый менеджер, файлы. Заходим и видим список папок и файлов. Теперь в этом списке нужно найти папку с названием public html,  www, httpdocs или domains.

На моем хостинге, например, чтобы войти в корневой каталог, нужно открыть папку domains. В ней — папка с названиям моего сайта — tavry. ru. Внутри этой папки находится public html. Вот эта последняя папка и является корнем сайта.

Если Ваш сайт на WordPress, открыв корневую папку, вы должны увидеть список папок, в том числе: wp-admin, wp-content, wp-includes.

На этой же странице Вы наверняка найдете кнопку «Загрузить», с помощью которой можно скопировать файлы со своего компьютера в корневую папку.

Теперь, если понадобится загрузить файл в корень сайта, Вы знаете, как это сделать.

2. Для того, чтобы облегчить себе жизнь, советую использовать  FTP — протокол, который служит для перемещения файлов с Вашего компьютера на сервер.

Все необходимые данные: адрес сервера, имя пользователя и пароль Вам должен был предоставить хостинг-провайдер.

Прежде, чем получить доступ к своим папкам на сервере, нужно установить у себя на компьютере один из FTP — клиентов, например FileZilla. Это бесплатная   программа. Скачать ее можно на сайте разработчиков filezilla.ru.

После установки, Вам нужно будет создать новое подключение. Для этого выбираете «Файл» — «Менеджер сайтов» и в открывшемся окне — «Новый сайт».

На рисунке показан пример заполнения. У Вас должен быть собственный хост (адрес сервера), логин и пароль.

Так как хранить пароли в подобных программах опасно,  в «типе входа» лучше выбрать «Запрос пароля». Тогда  FTP — клиент не будет запоминать пароль и его придется каждый раз вводить заново.

После заполнения жмите кнопку «Соединиться»

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

Чтобы скопировать файлы с компьютера, найдите их в левом окошке, выделите и щелкните по ним правой кнопкой мыши. Появится такое же контекстное меню, как на рисунке, выбирайте «Закачать на сервер»

После копирования файлы должны появиться в правом окне. Если этого не произошло обновите содержимое (Ctrl+R).

Структура корневого каталога Joomla

Вступление

Корневым каталогом сайта называется папка (директория) в которую уже загружены или должны быть загружены, все каталоги вашего сайта (каталоги CMC Joomla). Как правило, корневые каталоги именуются: public_html , www, domains, htdocs.

Структура корневого каталога Joomla — знакомство

Давайте посмотрим, что содержит и для чего нужен каждый каталог находящейся в корне сайта

Корень сайта или корневой каталог

Корневой каталог объединяет все рабочие каталоги и файлы Joomla. Основной файл корневого каталога index. php.Этот файл запускает программу установщика Joomla,он же инициализирует и в том числе запускает, все составляющие сайта Joomla при обращении к серверу хостинга (набора в адресной строке браузера адреса сайта).

На скриншоте вы можете видеть стандартную структуру корневого каталога Joomla версии 2,5.

На фото вы видите файл sitemap.xml, это карта сайта, она не входит в каталог сайта. Также не входят robots.txt, htaccess. Это в других статьях, а здесь начну обзор каталогов Joomla с неприметной папки libraries.

Папка Libraries

Это основная папка, которая обеспечивает работу всей системы. В ней содержится Framework (каркас, ядро) системы и библиотеки разработчиков, которые обеспечивают работу самого ядра, так и всех расширений Joomla. Если вы не разработчик ПО, то трогать эту папку и редактировать ее содержимое не нужно, если вы не увидили логи ошибок имено в этом каталоге. Кстати, как читать логи ошибок, я написал отдельную статью.

Каталог administrator

Это каталог панели управления сайтом. По сути это сайт в сайте. В статье «панель» я писал об этом. Административная панель Joomla по своей структуре это готовый сайт, без функции выпуска статей. Если вы посмотрите на структуру каталога «administrator», то увидите, что она почти полностью совпадает со структурой самого корневого каталога.

Каталог cache

Каталог «cache» это промежуточный буфер, для хранения часто используемых данных. Предназначен «кэш» каталог для ускорения работы системы. Это полезный каталог для больших настроенных проектов, но совершенно вредный при настройке системы. При установке новых расширений и их настройке приходится часто изменять их параметры и из-за этого постоянно приходится чистить кэш сайта. Это не очень удобно,правда нужно отметить, что для чистки этого не нужно постоянно заходить на сервер хостинга. В административной панели Joomla есть пункт меню «Очистить кэш», да и настройках панели (Панель управления>>>Сайт>>>Общие настройки>>>Система) есть пункт «Настройка кэша», где можно его отключить сохранение кэша. Не удаляемый файл папки «cache»,файл index.php.

Кстати, Каталог «cache» есть и в каталоге administrator. Его назначение такое же, только распространяется на backend сайта.

Каталог components

Сюда устанавливаются и здесь храниться все расширения типа компонент Joomla. Именно в эту папку нужно загружать распакованные архивы компонентов, если они не загружаются из панели управления сайтом.

Префикс папок содержимого каталога components “com_”

Каталог images

В этой папке храниться все изображения сайта. В версии Joomla1.5 изображения разделялись по всему каталогу. В папке administrator была отдельная папка с изображениями. В следующих версиях Joomla 1.7+ все изображения свели в общую папку «image» корневого каталога. Каждое расширение joomla работающее с фото создает в каталоге «images» свои подкаталоги. Все подкаталоги «images» имеют названия, совпадающие с названием расширений. Префикса папок нет. Пункт меню для управления этим каталогом: Материалы→ Медиа менеджер.

Каталог includes

В этом каталоге собраны функциональные php файлы для обеспечения прикладных задач и совместимости со старыми версиями Joomla. Без твердых знаний “php” здесь делать нечего.

Каталог installation

По названию понятно, что этот каталог содержащий файлы установщика Joomla. Если вы сами устанавливали Joomla,то, наверное, помните, что в конце работы установщика удаляли каталог «installation». Если не помните, почитайте статью: «Установщик Joomla». Значит, этого каталога после установки вы видеть не должны. Для переустановки Joomla нужно удалить файл configuration.php из корня сайта, заново загрузить каталог «installation» той верии Joomla, которую переустанавливаете и запустить файл index.php (набрать в адресной строке имя вашего сайта слэш index.php.).

Каталог language

Очень важный каталог, к которому вам придется обращаться много раз. Здесь храниться все языковые файлы сисиемы. В этот каталог при локализации (переводе)(о локализации Joomla читать ТУТ подробно или ТУТ кратко) расширений вам придется загружать языковые файлы ru_RU. Не лишний раз поясню. Пакет перевода любого расширения содержит две папки аdministrator и language.Файлы ru_RU из папки administrator грузятся в папку /аdministrator/ language/ru_RU, а файлы ru_RU из папки language грузятся в папку /language/ru_RU.

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

Каталог modules

Это папка для всех модулей, устанавливаемых на сайт Joomla.

Префикс папок “mod_”. Модули Joomla это информационные расширения сайта. Для модулей в каждом шаблоне Joomla выделяются специальные места. Посмотреть размещение модулей в шаблоне можно, если к URL сайта в адресной строке,добавить (?tp=1),через слеш, без скобок.

В третьей версии Joomla просмотр позиций модулей можно посмотреть прямо из админ. панели сайта, на вкладке Менеджер шаблонов (значок глаза), правда для этого нужно включить просмотр позиций модулей в настройках. ( Вкладка Менеджер шаблонов→Настройка→Просмотр позиций модулей → Включить.

Каталог plugins

Здесь хранятся все установленные плагины сайта joomla.Плагины это низкоуровневые расширения, находящиеся на уровне ядра Joomla.Плагины значительно расширяют функциональность Joomla.Все компоненты joomla имеют свои плагины для взаимодействия с ядром. Префикс папок каталога plugins отсутствует.

Каталог media

Это место для хранения всех медийных форматов. Аудио, видео, flash всё здесь.

Каталог templates

В этом каталоге собираются все шаблоны, которые вы устанавливаете на свой сайт. В начале создания своего сайта,при «поиске лица» сайта приходится пробовать несколько различных шаблонов. В административной панели шаблоны открываются в меню Расширения>>>Менеджер шаблонов. Находятся все шаблоны в папке «templates».Сразу отмечу, что удалить лишние шаблоны можно и из административной панели сайта и непосредственно из папки «templates» в корне сайта.

Каталог tmp

Тоже очень важный и сначала незаметный каталог. Каталог «tmp», по умолчанию, это установочный каталог и содержит временные файлы и папки. Если вы откроете панель управления сайтом и войдете в меню Расширения→Установить/Удалить в Joomla 1.5 или Расширения → Менеджер расширения в Joomla 2.5,то увидите три варианта загрузки расширений на сайт Joomla.Один из этих пунктов «Установить из папки» и прописан адрес папки, из которой можно осуществить загрузку. Это как раз папка «tmp» корневого каталога. Папка tmp сама не очищается и поэтому ее периодически нужно чистить. Не удаляемый файл папки tmp, конечно же index.php, хотя если его удалить фатальных ошибок не будет.

Совет. если вы случайно удалили изкаталогов, такие файлы, как index.php, закачайте их из базового релиза Joomla вашей версии.

Каталог logs

В каталоге logs собираются записи всех событий на вашем сайте, в том числе ошибки. При большой посещаемости сайта или в ряде внешних факторов папка «logs» может «разбухать» до неприличных размеров. За ее состоянием тоже нужно периодически следить. Нормальное состояние паки logs это пустая папка с файлом Index.php. Файл index.php не удаляется.

Файлы корневого каталога

Вот и все каталоги корневого каталога Joomla. Кроме каталогов в корне сайта есть несколько обязательных файлов. Здесь я их только перечислю:

• configuration.php. В этом файле указанны все данные системы, включая принципиально важные данные для связи сервера и базы данных, входа в панель сайта и т. д.;
• index.php. Этот файл определяет, как показывать сайт в браузере.

И два файла, нужных, но не обязательных:

• htaccess ( htaccess.txt ; .htaccess) — В коробочной версии этот файл идет с расширением txt, Для задействования файла, его нужно переименовать .htaccess, с точкой вначале. Этот файл позволяет управлять работой сервера HTTP Apache и активирует несколько SEO настроек сайта. 
• robots.txt — создать самостоятельно. Файл robots.txt, при помощи записанных в нём директорий, может управлять поведением роботов поисковых систем. 

©Joomla-abc.ru

Статьи близкие по теме

• VDS сервер для Joomla
• Все способы настройки DNS серверов
• Доменное имя для сайта — Как выбрать домен для сайта Joomla
• Как купить хостинг для сайта Joomla
• Перенос сайта Joomla на другой хостинг

Powered by JV-Relatives

Предоставление WordPress собственного каталога | Справочник по административным и административным вопросам Справочник

Главы

Темы

• Перемещение корневой установки в отдельный каталог
• Способ I (без изменения URL)
• Способ II (с изменением URL)
  • Процесс перемещения
  • модификация . htaccess
• Перемещение определенных папок WordPress
• См. также
• Список изменений

Многие люди хотят, чтобы WordPress использовал корень их веб-сайта (например, https://example.com), но они не хотят, чтобы все файлы WordPress загромождали их корневой каталог. WordPress позволяет вам установить его в подкаталог, но ваш сайт будет обслуживаться из корня сайта.

Начиная с версии 3.5, пользователи Multisite могут использовать все функции, перечисленные ниже. Если вы используете версию WordPress старше 3.5, обновите ее перед установкой многосайтовой установки WordPress в подкаталог.

Примечание для разработчиков тем/плагинов: это не отделит ваш код от WordPress. Темы и плагины по-прежнему будут находиться в папке wp-content

Допустим, вы установили WordPress по адресу example.com . Теперь у вас есть два разных способа переместить установки WordPress в подкаталог:

1. Без изменения SITE-URL (остается example. (/)?$ my_subdir/index.php \[L\]

   Вот и все 🙂

   (p.s. Если вы уже установили WP в подкаталог, некоторые шаги уже могут быть выполнены автоматически).

   1. Создайте новое место для хранения основных файлов WordPress (в наших примерах мы будем использовать /wordpress ). (В Linux используйте mkdir wordpress из вашего каталога www . Вероятно, вы захотите использовать chown apache:apache в созданном вами каталоге wordpress .)
   2. Перейти к основному экрану.
   3. В адресе WordPress (URL): укажите адрес ваших основных файлов ядра WordPress. Пример: http://example.com/wordpress
   .
   4. В Адрес сайта (URL): задайте URL-адрес корневого каталога. Пример: http://example.com
   5. Щелкните Сохранить изменения . (Не беспокойтесь об ошибках, которые происходят сейчас! Продолжить чтение)
   6. Теперь переместите основные файлы WordPress (из корневого каталога) в подкаталог.
   7. Скопируйте (НЕ ПЕРЕМЕЩАЙТЕ!) файлы index.php и .htaccess из каталога WordPress в корневой каталог вашего сайта (адрес блога). Файл .htaccess невидим, поэтому вам может потребоваться настроить FTP-клиент на отображение скрытых файлов. Если вы не используете красивые постоянные ссылки, возможно, у вас нет файла . файл htaccess . Если вы используете WordPress на сервере Windows (IIS) и используете красивые постоянные ссылки, у вас будет web.config , а не файл .htaccess в вашем каталоге WordPress. Для файла index.php инструкции остаются прежними, скопируйте (не перемещайте) файл index.php в корневой каталог. Файл web.config должен обрабатываться иначе, чем файл .htaccess , поэтому вы должны ПЕРЕМЕСТИТЬ (НЕ КОПИРОВАТЬ) файл web.config в корневой каталог.
   8. Откройте файл index.php вашего корневого каталога в текстовом редакторе
   9. Измените следующее и сохраните файл. Измените строку, в которой говорится: require dirname( __FILE__ ) . '/wp-блог-header.php'; на следующее, используя имя вашего каталога для основных файлов WordPress: require dirname( __FILE__ ) . '/wordpress/wp-blog-header.php';
   10. Войдите в новое местоположение. Теперь это может быть http://example.com/wordpress/wp-admin/
   .
   11. Если вы настроили постоянные ссылки, перейдите на экран постоянных ссылок и обновите структуру постоянных ссылок. WordPress автоматически обновит ваши .htaccess , если у него есть соответствующие права доступа к файлам. Если WordPress не может записать в ваш файл .htaccess , он отобразит вам новые правила перезаписи, которые вы должны вручную скопировать в свой файл .htaccess (в том же каталоге, что и основной файл index.php ). .)

   В некоторых случаях некоторым людям нравится устанавливать отдельные версии в подкаталог (например, /2010 , /2011 , /latest и т. д.), и они хотят, чтобы этот веб-сайт (по умолчанию) использовал последнюю версию версии, затем установите WordPress в подкаталог, например 9(/)?$ my_subdir\[L\]

   Теперь, когда пользователи переходят на ваш корневой домен ( example.com ), он автоматически перенаправляется в указанный вами подкаталог.

   Примечание. Этот код взят из сообщения Сайта 5 здесь: Как перенаправить ваш домен в подпапку с помощью .htaccess.

   Следующие ссылки объясняют, как изменить определенные каталоги в WordPress:

   • Перемещение папки wp-content
   • Перемещение папки плагинов
   • Перемещение папки тем
   • Перемещение папки загрузок
   • Использование Caddy для предоставления WordPress собственного каталога
   • 2022-09-11: Исходный контент от предоставления WordPress собственного каталога.

    

   Почему корневой каталог на веб-сервере по умолчанию находится в "/var/www"?

   спросил 10 лет, 10 месяцев назад

   Изменено 1 год, 7 месяцев назад

   Просмотрено 200 тысяч раз

   Tuxfiles говорит следующее о структуре каталогов Linux:

   /вар :

   Этот каталог содержит переменные данные, которые постоянно изменяются во время работы системы.

   FHS на /var говорит следующее:

   /var содержит файлы переменных данных. Сюда входят каталоги и файлы буфера, административные данные и данные журналов, а также временные и временные файлы.

   Затем они говорят, что такие вещи, как журналы, почта и спулер, помещаются в эту папку.

   Традиционно Стандартная установка Apache, Nginx или Arch в Ubuntu Linux размещает каталог по адресу /var/www/ .

   Мне кажется, это не идеальное место для размещения каталога с файлами или другим содержимым, которое должно быть почти постоянным.

   Почему его так часто помещают в /var ?

   С субъективной точки зрения, это то место, куда он должен идти в идеале, в соответствии со структурой каталогов?

   • структура каталогов
   6

   Использование /var/www сбивает с толку только на первый взгляд.

   Согласно FHS, данные веб-сервера должны идти по адресу /srv . Это главное правило.

   Однако в нем также говорится, что решение о структуре /srv является исключительной ответственностью локального администратора! Поэтому пакеты ничего не должны помещать в /srv 9.0034 , а корень документа по умолчанию не должен быть /srv , потому что пакет (apache) не знает, что находится в /srv и ниже. Возможно, репозиторий Subversion с открытым текстовым паролем и другими вещами. Таким образом, должно быть значение по умолчанию за пределами /srv . Это значение по умолчанию становится /var/www .

   /var/www в основном является заполнителем. Пакеты используют /usr/share для статического содержимого HTML или /var/lib для содержимого динамических переменных. Многие люди ошибочно думали, что им следует поместить HTML в /var/www . Это проблема, потому что пакеты тоже иногда используют это. Так недавно придумали /var/www/html для пакетов. Будем надеяться, что люди не начнут этим пользоваться, потому что им снова придется изобретать новый каталог... и так далее.

   Резюме: вы должны использовать /srv и соответствующим образом настроить виртуальные хосты Apache.

   3

   На самом деле это совсем не "традиционное" место. Традиционно все, что вы устанавливали после того, как ОС перешла в /usr/local , и действительно, это «классическая схема пути Apache» (их слова) по сей день. Долгое время это был /home/httpd .

   Вы видите, что Apache, настроенный для конкретной ОС — будь то Red Hat Linux, Mac OS X, GNU и т. д. — будет настраивать местоположение. Исходный код Apache хорошо разработан для этого, фактически, если вы проследите значение для ServerRoot в исходных файлах, вы увидите, что оно начинается в этом файле, config. layout :

   Некоторые выдержки из этого файла покажут вам, что расположение docroot очень разнообразно.

   IIRC, /var/www появился в моей жизни с выпусками Red Hat Linux 7.x 2000-2001 (не Red Hat Enterprise Linux). По всем причинам, которые вы указали выше, я думал, что это не имеет особого смысла, но реальность такова, что в современную эпоху задействовано так много других инструментов и технологий, что местоположение все равно перемещается.

    # Классическая схема пути Apache.
   <Макет Apache>
       префикс: /usr/local/apache2
       каталог данных: ${префикс}
   # Стандарты GNU, соответствующие макету пути.
   # Подробности смотрите в документе `make-stds' проекта FSF GNU.
   <Макет GNU>
       exec_prefix: ${префикс}
       каталог данных: ${prefix}/share+
   # Сервер Mac OS X (Рапсодия)
   <Макет сервера Mac OS X>
       префикс: /Local/Library/WebServer
       каталог данных: ${префикс}
   # Макет Darwin/Mac OS
   <Макет Дарвин>
       префикс: /usr
       каталог данных: /Library/WebServer
   # Макет Red Hat Linux 7. x
   <Макет RedHat>
       префикс: /usr
       каталог данных: /var/www
   # Макет SuSE 6.x
   <Макет SuSE>
       префикс: /usr
       каталог данных: /usr/local/httpd
   # Макет BSD/ОС
   <Макет BSDI>
       префикс: /var/www
       каталог данных: ${префикс}
   # Компоновка Solaris 8
   <Макет Солярис>
       префикс: /usr/apache
       каталог данных: /var/apache
    

   Хотя я согласен с ответом akond, я думаю, что есть более важный аспект. Большинство других местоположений обычно управляются системой (менеджером пакетов). /var обычно содержит файлы, которые не управляются менеджером пакетов (общесистемные «данные»).

   Я также думаю, что определение из FHS немного точнее (данные не должны «постоянно меняться»):

   /var содержит файлы переменных данных. Сюда входят каталоги и файлы буфера, административные данные и данные журналов, а также временные и временные файлы.

   Однако [FHS] (http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE16A) также указывает, что данные www должны поступать в `/srv`

   /srv содержит специфические для сайта данные, которые обслуживаются этой системой.

   Основная цель указания этого заключается в том, чтобы пользователи могли найти расположение файлов данных для конкретной службы, и чтобы службы, которым требуется единое дерево для данных только для чтения, данных с возможностью записи и сценариев (таких как сценарии cgi), могли быть разумно размещены .

   Методология, используемая для именования подкаталогов /srv, не определена, поскольку в настоящее время нет единого мнения о том, как это следует делать. Одним из методов структурирования данных в /srv является протокол, например. ftp, rsync, www и cvs.

   10

   Причины в основном исторические, как говорили другие. /var используется для системных данных, которые постоянно изменяются, например, файлов кеша, журналов, данных времени выполнения (например, файлов блокировки), хранилища почтового сервера, буферизации принтера и т. д. В основном для всего, что не может поставить в /usr (поскольку он содержит локальные данные), не являются сторонними программами, которые входят в /opt , и не могут быть отброшены и изменчивы, как они входят в /tmp .

   По мере развития Unix/Linux, он стал запутанным местом с мешаниной различных непохожих каталогов, собранных вместе. В последние годы наметилась тенденция перемещать некоторые вещи оттуда, особенно контент, обслуживаемый машиной (который теперь, согласно [Стандарт иерархии файловой системы 2.3, стр. 15], должен помещаться в /srv , а не /var/www ).

   То же самое произошло с /var/run несколько лет назад — благодаря усилиям нескольких дистрибутивов он был перемещен из /var/run в /run , который объединил функции ранее использовавшегося /var/lock , /var/run и /dev/shm .

   По моему опыту (я веб-разработчик), содержимое веб-сайта далеко не стабильно. Даже в случае html-файлов (не говоря уже о динамически генерируемом контенте) они подвержены постоянным изменениям (поправкам, упущениям и т. д.).

   Итак, с моей точки зрения, это переменные. Таким образом, они прекрасно подходят в директорию /var и в этом нет ничего плохого.

   6

   IIRC, в старые времена мы всегда монтировали /var как собственную файловую систему (отдельный диск или часть диска).

   Одной из причин этого, как заявляли другие, является интенсивное чтение/запись в эту файловую систему (журналы/и др.). Наличие отдельного диска/слайса означает, что его можно лучше настроить для этого типа ввода-вывода (по сравнению с чтением в основном на 9 дисках).0033/, /usr и т. д.).

   Другая причина заключается в том, что в те дни, если ваша система давала сбой во время операции записи, была очень большая вероятность того, что ваша корневая файловая система может быть повреждена, что приведет к ее трудновосстановимому состоянию. Таким образом, необходимо отделение от /.

   Файловая система и дисковая технология значительно улучшились с течением времени, так что это гораздо менее вероятное явление.

   1

   /var — достойный выбор нейтрального для пользователя «базового» местоположения для многопользовательского доступа, если у вас есть веб-сайт с несколькими запущенными виртуальными хостами, который позволяет загружать FTP или другие загрузки, т. е. если вы являетесь веб-хостингом или подобным .

   /home , возможно, не является оптимальным, потому что с другими учетными записями оболочки пользователя могут произойти плохие вещи, если бездумный или злонамеренный пользователь загрузит данные в ограничение раздела /home (при традиционной настройке /var , /home и т. д., находящиеся на отдельных разделах) это может повлиять на другие учетные записи пользователей.

   Конечно, я думаю, что /srv лучше для этого, но /var в традициях UNIX используется дольше.

   2

   Веб-сервер Apache имеет веб-сайт по умолчанию под /var/www/ , но он предлагает разместить другие веб-сайты под /srv/

   Я заметил это на Ubuntu Server 14.04 LTS. Его файл apache2.conf по умолчанию содержит закомментированный блок:

    #<Каталог /srv/>
   # Индексы опционов FollowSymLinks
   # Разрешить переопределение
   # Требовать все предоставленные
   #
    

   Что я хотел бы добавить, так это то, что размещение веб-«корня» в /usr конфликтует с частью FHS, которая указывает, что /usr доступен для совместного использования и только для чтения, поскольку разные веб-серверы, даже на одном и том же " кластер" может иметь разные файлы, содержащие разные конфигурации, и это не делает его идеальным для /usr.