Каталог данных и файлы, возможно, доступные из Интернета. Файл htaccess не работает

Обновлено: 21.11.2024

Директивы в файлах конфигурации могут применяться ко всему серверу или могут применяться только к определенным каталогам, файлам, узлам или URL-адресам. В этом документе описывается, как использовать контейнеры раздела конфигурации или файлы .htaccess для изменения области действия других директив конфигурации.

См. также

Типы контейнеров раздела конфигурации

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

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

В следующем примере директива MimeMagicFile будет применяться, только если доступен mod_mime_magic.

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

Файловая система, веб-пространство и логические выражения

Контейнеры файловой системы

Директивы и, наряду с их аналогами регулярных выражений, применяют директивы к частям файловой системы. Директивы, заключенные в секцию, применяются к названному каталогу файловой системы и всем подкаталогам этого каталога (а также к файлам в этих каталогах). Тот же эффект можно получить с помощью файлов .htaccess. Например, в следующей конфигурации индексы каталогов будут включены для каталога /var/web/dir1 и всех подкаталогов.

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

Для адресации файлов, находящихся в определенной части файловой системы, разделы и можно комбинировать. Например, следующая конфигурация запретит доступ к /var/web/dir1/private.html , /var/web/dir1/subdir2/private.html , /var/web/dir1/subdir3/private.html и любым другим Экземпляр private.html находится в каталоге /var/web/dir1/.

Контейнеры веб-пространства

Перекрывающееся веб-пространство

Чтобы иметь два перекрывающихся URL-адреса, необходимо учитывать порядок, в котором оцениваются определенные разделы или директивы. Для этого будет:

То же самое относится и к директивам ProxyPass:

Подстановочные знаки и регулярные выражения

Директивы , , и могут использовать подстановочные знаки в стиле оболочки, как в fnmatch из стандартной библиотеки C. Символ «*» соответствует любой последовательности символов, «?» соответствует любому одиночному символу, а "[seq]" соответствует любому символу в seq. Символ «/» не будет соответствовать никакому подстановочному знаку; это должно быть указано явно.

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

Раздел подстановочных знаков без регулярных выражений, который изменяет конфигурацию всех пользовательских каталогов, может выглядеть следующим образом:

Используя разделы регулярных выражений, мы можем запретить доступ ко многим типам файлов изображений одновременно:

Регулярные выражения, содержащие именованные группы и обратные ссылки, добавляются в среду с соответствующим именем в верхнем регистре. Это позволяет ссылаться на элементы путей и URL-адресов файлов из выражений и модулей, таких как mod_rewrite .

Булевы выражения

Директива изменяет конфигурацию в зависимости от условия, которое может быть выражено логическим выражением. Например, следующая конфигурация запрещает доступ, если заголовок HTTP Referer не начинается с «http://www.example.com/».

Что использовать, когда

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

Важно никогда не использовать при попытке ограничить доступ к объектам в файловой системе. Это связано с тем, что множество различных расположений веб-пространства (URL) могут сопоставляться с одним и тем же расположением файловой системы, что позволяет обойти ваши ограничения. Например, рассмотрим следующую конфигурацию:

Если вы, возможно, думаете, что ничего из этого не относится к вам, поскольку вы используете файловую систему с учетом регистра, помните, что существует много других способов сопоставить несколько местоположений веб-пространства с одним и тем же расположением файловой системы. Поэтому вы всегда должны использовать контейнеры файловой системы, когда можете. Однако есть одно исключение из этого правила. Размещение ограничений конфигурации в разделе совершенно безопасно, поскольку этот раздел будет применяться ко всем запросам независимо от конкретного URL-адреса.

Вложенность разделов

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

Вложенные разделы объединяются после невложенных разделов того же типа.

Виртуальные хосты

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

Прокси

Какие директивы разрешены?

Чтобы узнать, какие директивы разрешены в каких типах разделов конфигурации, проверьте контекст директивы. Все, что разрешено в разделах, также синтаксически разрешено в , , , , ,

разделы. Однако есть некоторые исключения:

Директива AllowOverride работает только в разделах.
Параметры FollowSymLinks и SymLinksIfOwnerMatch работают только в разделах или файлах .htaccess.
Директиву Options нельзя использовать в разделах и.

Как объединяются разделы

Разделы конфигурации применяются в особом порядке. Поскольку это может серьезно повлиять на интерпретацию директив конфигурации, важно понимать, как это работает.

Порядок слияния:

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

Несколько важных замечаний:

Кроме того, внутри каждой группы разделы обрабатываются в порядке их появления в файлах конфигурации. Например, запрос /foo/bar будет соответствовать и (в данном случае группе 4): будут оцениваться оба раздела, но в том порядке, в котором они указаны в файлах конфигурации.
(группа 1 выше) обрабатывается в порядке от самого короткого до самого длинного компонента каталога. Например, будет обработан раньше .
Если несколько разделов применяются к одному и тому же каталогу, они обрабатываются в порядке файла конфигурации.
Конфигурации, включенные с помощью директивы Include, будут обрабатываться так, как если бы они находились внутри файла включения в месте расположения директивы Include.
Разделы внутри разделов применяются после соответствующих разделов вне определения виртуального хоста. Это позволяет виртуальным хостам переопределять конфигурацию основного сервера.
Когда запрос обслуживается mod_proxy ,

Техническое примечание

На самом деле непосредственно перед фазой преобразования имен выполняется последовательность / (где псевдонимы и корни документов используются для сопоставления URL-адресов с именами файлов). Результаты этой последовательности полностью удаляются после завершения перевода.

Связь между модулями и разделами конфигурации

Это верно и для .htaccess, так как они имеют тот же приоритет, что и Directory в порядке слияния. Важно понимать, что разделы конфигурации, такие как Directory и FilesMatch, несопоставимы с директивами для конкретных модулей, такими как Header или RewriteRule, поскольку они работают на разных уровнях.

Несколько полезных примеров

Ниже искусственный пример, показывающий порядок слияния. Предполагая, что все они применяются к запросу, директивы в этом примере будут применяться в порядке A > B > C > D > E.

В качестве более конкретного примера рассмотрим следующее. Независимо от каких-либо ограничений доступа, установленных в разделах, этот раздел будет оцениваться последним и разрешать неограниченный доступ к серверу. Другими словами, важен порядок слияния, так что будьте осторожны!

WP Engine решил отказаться от использования файла .htaccess для всех клиентов.В этой статье обсуждается почему, а также какие альтернативы мы рекомендуем заменить директивы.

Некоторые веб-сайты временно сохранят устаревшую поддержку .htaccess. Узнайте больше здесь.

Что такое файл .htaccess и почему он устарел?

Серверы Apache используются для выполнения PHP-кода, на котором работает WordPress. .htaccess — это файл конфигурации Apache, который веб-администратор может использовать, чтобы указать Apache, как взаимодействовать с веб-сайтом. Он может контролировать любое количество вещей на каждом сайте, например, как формируются ваши URL-адреса или ограничивать доступ к каталогу.

Самое главное, файлы .htaccess связывают нашу архитектуру с Apache как внутренним веб-сервером. По мере появления новых захватывающих технологий и открытия новых функций и производительности, которые мы хотели бы сделать доступными для наших клиентов, становится первостепенной задачей избавиться от этой зависимости по мере того, как мы развиваемся как Платформа цифрового опыта. Мы невероятно рады эволюции и скорости, которую мы сможем обеспечить как часть этого изменения в будущем.

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

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

Хотя наша служба поддержки не поддерживает PHP или разработку кода, если у вас есть какие-либо вопросы или опасения по поводу этого изменения, обращайтесь в нашу службу поддержки в любое время.

Некоторые веб-сайты временно сохранят устаревшую поддержку .htaccess. Узнайте больше здесь.

Директивы WordPress .htaccess по умолчанию

Согласно нашему анализу, большинству веб-сайтов WP Engine не потребуется никаких дополнительных изменений в .htaccess, поскольку они используют версию этого файла WordPress по умолчанию.

Перезаписи WordPress по умолчанию будут обрабатываться WP Engine непосредственно с уровня сервера Apache. Таким образом, если ваши файлы .htaccess выглядят как-либо из перечисленных ниже, это прекращение поддержки не повлияет на ваш веб-сайт.

Вордпресс по умолчанию .htaccess

Многосайтовый субдомен .htaccess

Подкаталог Multisite .htaccess

Директивы и альтернативы

Если на вашем сайте используются директивы .htaccess, выходящие за рамки правил WordPress по умолчанию (см. выше), мы составили список рекомендуемых альтернатив.

По умолчанию файлы PHP защищены на уровне платформы, что предотвращает их обслуживание. Другие статические файлы обслуживаются Nginx, а не Apache.
При необходимости можно добавить правила Nginx для воспроизведения этого поведения, обратившись в службу поддержки.

Файлы PHP защищены на уровне платформы, что предотвращает их обслуживание. Другие статические файлы обслуживаются Nginx, а не Apache.
При необходимости можно добавить правила Nginx для воспроизведения этого поведения, обратившись в службу поддержки.

Используйте плагин.

Нет
Статические ресурсы обслуживаются Nginx, а не Apache (где будет обрабатываться .htaccess).

Нет
По умолчанию WP Engine уже запрещает индексирование каталогов.

Заголовки следует отправлять с кодом PHP.

Статические ресурсы обслуживаются Nginx, а не Apache (где будет обрабатываться .htaccess).
Если нужны дополнительные правила, их можно добавить в конфигурацию Nginx, обратившись в службу поддержки.

По умолчанию WP Engine управляет правилами кэширования на уровне сервера.
Дополнительными правилами кэширования можно управлять в коде PHP.
Дополнительные правила кэширования для статических ресурсов можно применить к Nginx, обратившись в службу поддержки.

Подключаемые модули WordPress часто добавляют правила безопасности в файл .htaccess. WP Engine уже применяет эти правила по умолчанию на уровне сервера.
Плагины должны обрабатывать дополнительные директивы в своем PHP-коде.

Обработка перенаправлений 301 и 302

Если на вашем сайте есть перенаправления в .htaccess, их нужно будет переместить, чтобы они оставались функциональными и оптимизированными. Всегда рекомендуется объединять как можно больше правил с помощью RegEx, независимо от количества необходимых перенаправлений или способа их применения.

Менее 1000 переадресаций

Перенаправления можно добавить в конфигурацию Nginx WP Engine
Массовый импорт перенаправлений, обратившись в службу поддержки WP Engine

Более 1000 переадресаций

Импорт перенаправлений в конфигурацию WP Engine Nginx будет неэффективен при таком количестве из-за раздувания и накладных расходов.
Мы рекомендуем загружать перенаправления в подключаемый модуль Redirection или, если вы используете Yoast SEO, управлять перенаправлениями в Yoast Premium.

Массовый перенос перенаправлений из файла .htaccess

Все рекомендуемые варианты переадресации допускают массовый импорт переадресаций Apache (в формате .htaccess). Это означает, что импортировать существующие перенаправления из .htaccess можно быстро и легко, и не требуется перемещать перенаправления по одному. Просто скопируйте правила из файла .htaccess, а затем импортируйте с помощью руководства:

Веб-правила

Управлять правилами веб-доступа теперь можно с пользовательского портала в качестве альтернативы размещению этих правил в файле .htaccess.

Эта страница позволяет блокировать/разрешать IP-адреса, ограничивать трафик на основе заголовка или управлять трафиком по типу запроса. Все веб-сайты на WP Engine автоматически включают эту страницу веб-правил.

Устаревшие обновления

Некоторым веб-сайтам, например тем, версия PHP которых была изменена автоматическим процессом безопасности WP Engine, будет предоставлена временная поддержка .htaccess. Это не постоянная функция, и вы должны использовать этот короткий промежуток времени, чтобы внести окончательные изменения, необходимые для удаления .htaccess с вашего веб-сайта.

Для этих устаревших веб-сайтов поддержку .htaccess можно включить или отключить на странице веб-правил пользовательского портала:

Включение веб-правил отключает поддержку .htaccess.
Включение поддержки .htaccess отключает все веб-правила.
Для устранения неполадок можно одновременно отключить как веб-правила, так и поддержку .htaccess.

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

Мы рекомендуем перенести правила из .htaccess на страницу веб-правил как можно скорее.

Если вы просто хотите попробовать Moodle на отдельном компьютере, существуют установщики «в один щелчок» для Windows (см. Полные установочные пакеты для Windows) и для OSX (см. Полные установочные пакеты для Mac OS X) или для установки на OS X. , Они не подходят для рабочих серверов.

Содержание

Требования

Moodle в основном разработан для Linux с использованием Apache, PostgreSQL/MySQL/MariaDB и PHP (иногда называемого платформой LAMP). Обычно таким же образом запускается Moodle, хотя есть и другие варианты, если соблюдены программные требования выпуска.

Основные требования к Moodle следующие:

Оборудование

Дисковое пространство: 200 МБ для кода Moodle плюс столько, сколько необходимо для хранения содержимого. 5 ГБ, вероятно, является реалистичным минимумом.
Процессор: 1 ГГц (минимум), рекомендуется двухъядерный 2 ГГц или выше.
Память: 512 МБ (минимум), рекомендуется 1 ГБ или больше. 8 ГБ плюс, скорее всего, на большом рабочем сервере.
Рассмотрите возможность использования отдельных серверов для веб-интерфейса и базы данных. Его гораздо проще «настроить»

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

Для очень больших сайтов гораздо лучше начать с небольшого пилотного проекта и набраться опыта и знаний. «Какое оборудование мне нужно для 50 000 пользователей?» сообщения в стиле на форумах вряд ли получат полезный ответ.

Программное обеспечение

Требования к программному обеспечению см. в примечаниях к выпуску в документации для разработчиков.

Настройте свой сервер

В зависимости от варианта использования сервер Moodle может быть чем угодно: от настольного ПК (например, для тестирования и оценки) до стоечного или кластерного решения, облачных виртуальных машин или других размещенных решений. Как упоминалось выше, существует множество возможностей для установки базового серверного программного обеспечения, подробнее см.:

Если используется хостинг-провайдер, перед попыткой установки убедитесь, что все требования Moodle (например, версия PHP) соблюдены хостинговой платформой. Это поможет ознакомиться с изменением настроек на платформе хостинг-провайдера (например, максимальное количество загружаемых файлов PHP), поскольку предоставляемые параметры и инструменты различаются.

Загрузить и скопировать файлы на место

У вас есть два варианта:

Для более подробного обсуждения см. Git для администраторов.

Любое из вышеперечисленных действий должно привести к созданию каталога moodle, содержащего несколько файлов и папок.

Защитите файлы Moodle. Крайне важно, чтобы файлы не могли быть записаны пользователем веб-сервера. Например, в Unix/Linux (от root):

(файлы принадлежат администратору/суперпользователю и доступны только для записи им, а для чтения всем остальным)

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

Создать пустую базу данных

Затем создайте новую пустую базу данных для вашей установки. Вам необходимо найти и записать следующую информацию для использования на заключительном этапе установки:

dbhost — имя хоста сервера базы данных. Вероятно, localhost, если база данных и веб-сервер — одна и та же машина, в противном случае имя сервера базы данных
dbname — имя базы данных. Как бы вы это ни называли, например. мудл
dbuser — имя пользователя для базы данных. Что бы вы ни назначили, например. moodleuser — не используйте учетную запись root/superuser. Создайте правильный аккаунт с минимальными необходимыми разрешениями.
dbpass – пароль для указанного выше пользователя.

Если ваш сайт размещен на хостинге, вы должны найти веб-страницу администрирования баз данных как часть панели управления (или обратиться к своему администратору). Для всех остальных или для получения подробных инструкций см. страницу выбранного сервера базы данных:

Создайте каталог данных (moodledata)

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

Из-за того, что Moodle кэширует данные по умолчанию, у вас могут возникнуть серьезные проблемы с производительностью, если вы используете относительно медленное хранилище (например, NFS) для этого каталога. Внимательно прочитайте рекомендации по производительности и рассмотрите возможность использования (например) Redis или memcached для кэширования.

ВАЖНО: Этот каталог НЕ должен быть доступен напрямую через Интернет. Это будет серьезной дырой в безопасности. Не пытайтесь поместить его в корневую папку вашего веб-сайта или в папку с программными файлами Moodle. Moodle не устанавливается. Это может быть любое другое удобное место.

Вот пример (Unix/Linux) создания каталога и установки разрешений для любого пользователя на сервере для записи сюда. Это подходит только для серверов Moodle, которые не являются общими. Обсудите это с администратором вашего сервера, чтобы получить лучшие разрешения, которые просто позволяют пользователю веб-сервера получать доступ к этим файлам.

Защита данных настроения в веб-каталоге

Если вы используете размещенный сайт и у вас нет другого выбора, кроме как поместить 'moodledata' в каталог, доступный через Интернет. Вы можете защитить его, создав файл .htaccess в каталоге «moodledata». Это не работает на всех системах - обратитесь к вашему хосту/администратору. Создайте файл с именем .htaccess, содержащий только следующие строки:

Начать установку Moodle

Пришло время запустить программу установки, чтобы создать таблицы базы данных и настроить новый сайт. Рекомендуемый метод — использовать установщик командной строки. Если вы не можете сделать это по какой-либо причине (например, на сервере Windows), веб-установщик по-прежнему доступен.

Установщик из командной строки

Лучше запускать командную строку от имени веб-пользователя вашей системы. Вам нужно знать, что это такое — см. документацию по вашей системе (например, Ubuntu/Debian — это «www-data», Centos — это «apache»)

Пример использования командной строки (как пользователь root — замените «www-data» на имя веб-пользователя):

Chowns позволяет сценарию записывать новый файл config.php. Дополнительную информацию о параметрах можно найти с помощью

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

Интернет-установщик

Для простоты использования вы можете установить Moodle через Интернет. Мы рекомендуем настроить веб-сервер таким образом, чтобы страница не была общедоступной до завершения установки.

Чтобы запустить скрипт веб-установщика, просто перейдите по основному URL-адресу Moodle с помощью веб-браузера.

Процесс установки займет у вас несколько страниц.Вас попросят подтвердить авторские права, просмотреть создаваемые таблицы базы данных, указать данные учетной записи администратора и указать данные сайта. Создание базы данных может занять некоторое время — наберитесь терпения. В конечном итоге вы должны оказаться на главной странице Moodle с приглашением создать новый курс.

Вполне вероятно, что вам будет предложено загрузить новый файл config.php и загрузить его в вашу установку Moodle — просто следуйте инструкциям на экране.

Окончательная конфигурация

Настройки в Moodle

На экранах администрирования сайта Moodle имеется ряд параметров (доступных на вкладке «Администрирование сайта» в блоке «Администрирование» (классическая тема) или с помощью кнопки «Администрирование сайта» на панели навигации (ускоренная). Вот несколько из наиболее важных, которые вы, вероятно, захотите проверить:

Оставшиеся задачи

Настройка Cron: фоновые задачи Moodle (например, отправка электронных писем форума и создание резервных копий курса) выполняются с помощью сценария, который вы можете настроить для выполнения в определенное время дня. Это известно как скрипт cron. Пожалуйста, обратитесь к инструкциям Cron.
Настройка резервного копирования: см. Резервное копирование сайта и Автоматическое резервное копирование курса.
Защитите свой сайт Moodle: ознакомьтесь с рекомендациями по безопасности.
Увеличение максимального размера загружаемого файла См. Часто задаваемые вопросы по установке Максимальный размер загружаемого файла — как его изменить?
Проверка работоспособности почты. В меню «Администрирование сайта» > «Сервер» > «Проверить конфигурацию исходящей почты» используйте ссылку, чтобы отправить себе тестовое электронное письмо. Не поддавайтесь искушению пропустить этот шаг.

Установка завершена :)

Создание нового курса. Теперь вы можете получить доступ к Moodle через веб-браузер (используя тот же URL-адрес, который вы указали в процессе установки), войти в систему как администратор и создать новый курс. См. статью о создании нового курса.

Если что-то пойдет не так.

Вот что вам следует попробовать.

Ознакомьтесь с часто задаваемыми вопросами по установке
Внимательно проверьте права доступа к файлам. Может ли ваш веб-сервер читать (но не записывать) программные файлы Moodle? Может ли ваш веб-сервер читать и записывать ваш каталог данных Moodle? Если вы не совсем понимаете, как право собственности на файлы и права доступа работают в вашей операционной системе, было бы очень хорошо потратить время, чтобы выяснить это.
Проверьте права доступа к базе данных. Настроили ли вы пользователя базы данных с правильными правами и разрешениями для вашей конфигурации (особенно если веб-сервер и сервер базы данных — это разные машины)?
Создайте файл конфигурации (config.php) вручную. Скопируйте config-dist.php (в корне каталога программы Moodle) в config.php, отредактируйте его и установите там параметры вашей базы данных/сайта. Установка продолжится с правильного места.
Если у вас есть файл config.php (см. предыдущий совет), вы можете отредактировать его, чтобы включить отладку (см. раздел 8). Это может дать вам дополнительную информацию, которая поможет отследить проблему. Если у вас есть доступ, проверьте журнал(ы) ошибок вашего веб-сервера.
Перепроверьте настройки php.ini/.htaccess. Подходят ли они (например, memory_limit), редактировали ли вы правильный файл php.ini / .htaccess и (при необходимости) перезапускали ли вы веб-сервер после внесения изменений?
Включали ли вы какие-либо неосновные (необязательные) подключаемые модули, темы или другой код перед запуском сценария установки? Если это так, удалите его и повторите попытку (он может быть поврежден или несовместим).
Объясните свою проблему на форуме проблем с установкой. ПОЖАЛУЙСТА, укажите версии вашего программного обеспечения; объясните, что вы делали, что произошло и какие сообщения об ошибках вы видели (если они были); объясни что пробовал. Нет такого понятия, как «ничего», даже пустая страница — это что-то!

Инструкции для конкретных платформ

Примечание. Большая часть этой информации предоставлена сообществом. Возможно, он не был проверен и может быть устаревшим. Прочтите вместе с приведенными выше инструкциями по установке.

Найдите ответы, руководства и учебные пособия, чтобы повысить эффективность доставки контента.

Файл доступа к гипертексту, более известный как .htaccess , представляет собой файл конфигурации для веб-серверов Apache, который можно использовать для определения очень специфических параметров конфигурации. Конфигурации могут стать довольно детализированными с использованием регулярных выражений, однако большинство пользователей обычно придерживаются популярных примеров .htaccess, таких как перенаправление веб-страниц или установка пользовательских заголовков.

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

Распространенные проблемы с .htaccess

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

.htaccess должен быть включен с помощью AllowOverride

Имя файла написано с ошибкой или не начинается с точки

Если вы создаете файл .htaccess с нуля (т. е. вы не используете CMS, которая поставляется с включенным файлом .htaccess), вы должны убедиться, что имя файла правильное и начинается с точки ( . ). Без точки в начале Apache проигнорирует файл — то же самое, если файл написан с ошибкой. Кроме того, дважды проверьте, чтобы имя файла было в нижнем регистре. Ваш файл .htaccess должен называться точно так же, как .htaccess .

Расположение ваших правил должно быть выше или ниже других

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

Конфликтующие файлы .htaccess

Хотя большинство пользователей просто используют один файл .htaccess, у вас есть возможность использовать несколько. Поскольку правила файла .htaccess применяются к каталогу, в котором они находятся, а также ко всем другим подкаталогам, может случиться так, что два или более файла .htaccess конфликтуют друг с другом. Чтобы убедиться в этом, попробуйте отключить каждый дополнительный файл .htaccess один за другим, чтобы увидеть, в чем проблема.

Используется неправильный синтаксис

Часто причиной того, что файл .htaccess не работает, является синтаксическая ошибка. Если вы знакомы с тем, как читать и настраивать правила .htaccess, дважды проверьте свою конфигурацию. В противном случае вы можете воспользоваться советами по устранению неполадок, приведенными в следующем разделе, чтобы определить причину проблемы.

Как устранить неполадки, связанные с неработающим файлом .htaccess

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

Использование валидатора .htaccess

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

- Вы также можете использовать средство проверки синтаксиса .htaccess, предлагаемое Lyxx. Этот инструмент аналогичен упомянутому выше, за исключением того, что он не позволяет загружать файл .htaccess, вы можете только копировать и вставлять свой синтаксис.

Проверка журнала ошибок Apache

Если после внесения изменений в файл .htaccess ваш веб-сайт не работает, вы также можете проверить журнал ошибок Apache для получения дополнительной информации об отладке. Файл журнала ошибок Apache обычно находится в каталоге /var/log/apache2/. Поэтому предположим, например, что у нас есть следующий контент в нашем файле .htaccess.

Как видите, я добавил "Это какая-то тарабарщина", чтобы намеренно вызвать ошибку. После сохранения этого файла и перезагрузки страницы мы можем проверить журналы ошибок с помощью следующей команды.

В этом случае Apache выдает следующую ошибку:

Мы можем использовать эту информацию, чтобы затем вернуться к нашему файлу .htaccess и удалить или изменить любые части файла, отмеченные в журнале ошибок.

Отладка с помощью файла конфигурации Apache

Наконец, вы также можете отлаживать содержимое файла .htaccess, вставив его вместо этого в файл конфигурации Apache. Все правила .htaccess по-прежнему будут применяться в вашем файле конфигурации, однако теперь Apache будет анализировать и проверять файл конфигурации. Обязательно включите в директиву все содержимое вашего .htaccess. Используя тот же пример, что и выше, часть вашего файла конфигурации может выглядеть следующим образом.

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

В этом случае Apache возвращает сообщение об ошибке, в котором говорится о синтаксической ошибке в строке 72 моего файла конфигурации. Если вы используете этот метод, вы также можете проверить журналы ошибок, если там была записана какая-либо дополнительная информация.

Отладка mod_rewrite с журналами

Если вы используете модуль Apache mod_rewrite, вы также можете включить журнал перезаписи, чтобы предоставить вам дополнительные сведения об отладке. Для этого вам необходимо иметь доступ к файлу конфигурации вашего веб-сервера Apache.Начните с открытия файла конфигурации и добавления соответствующих значений директив по мере необходимости. Например:

В приведенном выше фрагменте будут зарегистрированы все ошибки mod_rewrite вплоть до уровня "alert" в вашем файле error.log. Ознакомьтесь с директивой уровня журнала Apache, чтобы узнать больше. Следует отметить, что чем выше уровень журнала трассировки, который вы задаете, тем медленнее будет работать ваш веб-сервер Apache.

Обзор

Файлы .htaccess во многих случаях чрезвычайно полезны для пользователей, у которых либо нет прав суперпользователя, либо для пользователей, которым просто неудобно вносить изменения в файл конфигурации своего веб-сервера. Попытка отладить неработающий .htaccess не всегда самая простая задача, однако, надеюсь, проверив вышеупомянутые распространенные проблемы .htaccess, а также советы по устранению неполадок, вы лучше поймете, что вам, возможно, придется изменить. чтобы ваш файл .htaccess работал без сбоев.

Кроме того, если вы хотите провести дополнительное тестирование, попробуйте инструмент для тестирования htaccess. Он позволяет вам указать определенный URL-адрес, а также правила, которые вы хотите включить, а затем показывает, какие правила были протестированы, какие из них соответствовали критериям, а какие были выполнены.

Читайте также: