Подключение через unix сокет moodle
Обновлено: 07.07.2024
Локальное соединение между Unix Domain Socket и PostgreSQL
PostgreSQL, упомянутый в предыдущей главе peer Метод аутентификации, говоря об этом методе аутентификации, осуществляется через Unix Domain Socket Способ подключения сертифицирован. Давайте поговорим подробнее в этой главе Unix Domain Socket И его применение.
Проявление сокета домена Unix
Так файл Форма хранится на машине и обычно не занимает места. Знакомо большинству эксплуатационного и обслуживающего персонала MySQL Например, служба MySQL создаст такой файл при работе в конфигурации по умолчанию:
Местоположение этого файла может немного отличаться для разных операционных систем. См. Конкретное местоположение в файле конфигурации MySQL. socket Элемент конфигурации.
Это немного похоже на Именованная труба (именованный канал), и эффект аналогичен. Но именованные каналы могут поддерживать только байтовые потоки, тогда как Unix Domain Socket может поддерживать как байтовые потоки, так и очереди.
Кроме того, Unix Domain Socket использует адрес системного файла в качестве собственного идентификатора, поэтому его можно использовать для аутентификации разрешений (аутентификация PostgreSQL Peer), и на него могут ссылаться системные процессы. Таким образом, он может поддерживать одновременное использование разных процессов, но именованные каналы не имеют этой функции.
Использование сокета домена Unix
Многие службы, работающие в Linux / Unix, могут отслеживать не только порт TCP / UDP, но и сокет домена Unix. Такие как Mysql socket Конфигурация, redis unixsocket Конфигурация, nginx listen Конфигурация, Postgresql unix_socket_directories Конфигурация и тд. Пока клиент поддерживает сокет домена Unix, он может быть напрямую подключен таким образом.
Такие как MySQL [client] Ниже раздела конфигурации socket Конфигурация напрямую указывает на адрес сокета домена unix, что означает, что соединение сокета домена unix используется по умолчанию. psql Метод подключения по умолчанию также использует сокет домена unix, который будет /var/run/postgresql/ Найти в каталоге .s.PGSQL.5432 Эта розетка. в состоянии пройти psql -h /path/to/socket/directory/ -p port Переключить файлы сокетов в других каталогах.
Большинство использования C/C++ Клиенты, разработанные на этом языке, также поддерживают Unix Domain Socket. Например, драйвер Python Mysql (с использованием официального интерпретатора Cython)Connector/Python, Есть такой способ подключения:
Непосредственно укажите подключение к локальному сокету домена Unix для доступа к службе Mysql.
Другой пример - драйвер Python для PostgreSQL.Psycopg2В документе прямо говорится connect() Функция не указывает host Параметры, сокет домена Unix и т. Д. Используются по умолчанию.
Другой пример - популярный веб-сервер Nginx, многие люди могут не знать Nginx. listen Команда может поддерживать сокет домена unix:
Это может ограничить прямой доступ к виртуальному хосту внешним пользователям. Когда вам нужно открыть его, вы можете добавить обратный прокси-сервер, чтобы сделать некоторые другие ограничения конфигурации:
Ограничения сокета домена Unix
Unix Domain Socket обладает высокой производительностью и хорошей безопасностью.В случае ограниченного количества портов сетевых сокетов Unix Domain Socket не должен занимать ограниченные порты TCP / UDP. Теперь поговорим об ограничениях этого материала. Очевидно, вы можете увидеть два ограничения:
- Доступ к нему можно получить только локально, и его нельзя использовать для удаленного доступа (Docker может использовать форму монтирования для реализации разных контейнеров на этом компьютере или предыдущего доступа между контейнером и хостом, но он все еще находится на том же хосте)
- Только в POSIX Реализованы совместимые системы. Это означает, что в Windows нет соответствующей реализации, поэтому такие службы, как MySQL, работающие в Windows, по умолчанию отключат функцию Unix Domain Socket.
Есть что-то вроде Java Чтобы упростить проблемы межплатформенной совместимости, этот язык программирования не предоставляет поддержку Unix Domain Socket внизу. Такие как JDBC Реализация подключения Unix Domain Socket отсутствует, поэтому URL-адрес jdbc может быть записан только при подключении к локальной службе 127.0.0.1 , Невозможно записать путь к сокету домена Unix.
После выяснения сокета домена Unix, одноранговую аутентификацию PostgreSQL легко понять.
Давайте посмотрим на postgresql при установке по умолчанию pg_hba.conf Файл (отфильтрованы пустые строки и строки комментариев):
среди них host Метод доступа от имени клиента TCP ,и local Это означает, что метод доступа клиента - это Unix Domain Socket. Итак, вы можете ясно видеть local Для конфигурации линии нет раздела конфигурации IP.
Тогда поговорим об этом peer Какой метод аутентификации? Как упоминалось ранее, Unix Domain Socket может получать идентификационную информацию пользователя, это учетная запись пользователя в системе Unix / Linux, и peer Это означает, что пользовательский psql user Запуск от имени удостоверения, и соответствующий идентификатор пользователя для подключения к базе данных user Сюда. и так peer Аутентификация только поддерживает local Способ подключения, поэтому в windows не работает.
Например, если я сейчас использую myuser Войдите в систему Linux с этой учетной записью и запустите psql Команда, затем подключение к базе данных myuser Этот пользователь не требует аутентификации по паролю. Если нет базы данных postgresql myuser Этот пользователь сообщит об ошибке, что этот пользователь не может быть найден.
Посмотри снова postgres Этот пользователь ограничен конфигурацией по умолчанию local Метод подключения, метод аутентификации peer . представитель postgres (Учетная запись администратора postgresql по умолчанию) должна быть подключена через Unix Domain Socket и использовать операционную систему postgres Запускаем как пользователь. Поскольку по умолчанию этой учетной записи не разрешено входить в систему напрямую в системе Linux, нам необходимо su или же sudo Команда для переключения пользователя на запуск, здесь мы используем sudo Например:
sudo -u postgres psql
из-за psql По умолчанию подключение осуществляется через сокет домена Unix (система Windows использует TCP), поэтому нет необходимости указывать другие параметры подключения.
В другом примере мы создали пользователя на postgresql myadmin , Но нет myadmin Эта учетная запись, значит, мы не можем использовать ее в настоящее время local Канал подключен и может быть только host Режим подключения, а именно режим TCP:
Прямо указать -h Параметры 127.0.0.1 или же localhost ,ограничено psql Используйте TCP для подключения к postgresql, вы можете ударить по спине host all all 127.0.0.1/32 md5 Затем эта конфигурация подключается к базе данных.
Psql использует сокет домена unix для подключения к другим экземплярам postgresql этого компьютера:
Аутентификация unix_socket в MySQL и MariaDB
Суть аутентификации по unix_socket в том, что если пользователь уже выполнил вход в систему, то ему не нужно вводить пароль при подключении к СУБД, поскольку его подлинность уже была проверена при входе в ОС.
На практике, большинство работает под обычным пользователем, а подключается к MySQL как root. В результате возникает обозначенная выше ошибка.
Можно выбрать один из вариантов:
1. Всегда использовать sudo при подключении как root.
2. Внести изменения в настройки MySQL, чтобы к СУБД могли подключаться и обычные пользователи.
3. Создать пользователя MySQL с таким же именем, как имя вашего системного пользователя
Как проверить, какой метод аутентификации используется
Для просмотра используемого метода аутентификации можно использовать следующий SQL запрос:
Или такую, для большей наглядности вывода:
Можно увидеть, что в качестве плагина установлены mysql_native_password и unix_socket:
При такой конфигурации, у меня работала только аутентификация по unix_socket.
Включение и отключение аутентификации по unix_socket
Переключиться на аутентификацию по паролю можно следующим SQL запросом:
Обратите внимание, что вам нужно ввести ПАРОЛЬ.
Чтобы переключиться на аутентификацию по unix_socket выполните следующий SQL запрос:
Если выведено mysql_native_password, то это означает, что используется вход по паролю.
На самом деле, аутентификацию по unix_socket можно сочетать с аутентификацией по паролю, но я не буду на этом останавливаться.
Вариант с update user
Если предыдущий способ не сработал для вас, то для получения доступа к базе данных MySQL обычному пользователю без использования sudo привилегий, зайдите в приглашение командной строки MySQL
и запустите следующие команды:
Затем перезапустите службу MySQL и попробуйте войти в базу данных без sudo, как показано ниже.
Ранее похожий эффект - смены аутентификации с unix_socket на аутентификацию по паролю - достигался с помощью последовательности команд:
Подключение к серверу MySQL:
В приглашении MySQL нужно было выполнить команды:
Затем нужно было перезапустить службу:
И можно было подключаться без sudo.
В показанном выше случае также менялся способ аутентификации с unix_socket на пароль, но при этом не происходила установка нового пароля. Если вы хотите такого же эффекта (хотя это становится небезопасным после отключения аутентификации с unix_socket), то вы можете выполнить следующие запросы (то есть установить пустой пароль):
Выбор способа аутентификации при создании пользователя
Создать пользователя с аутентификацией по паролю можно SQL запросом следующего вида:
Чтобы создать пользователя с аутентификацией по unix_socket выполните следующий SQL запрос:
OS: "Linux Debian 8/9/10", "Linux Ubuntu 16/18/20 LTS".
Applications: "Nginx", PHP-FPM, "MySQL".
Задача: подготовить несущий web-сервер, удовлетворяющий требованиям системы управления процессом преподавания посредством "виртуальной рабочей среды", реализованной в виде комплексного PHP-приложения "Moodle" (от аббревиатуры "Modular Object-Oriented Dynamic Learning Environment", "модульная объектно-ориентированная динамическая обучающая среда"). Попросту говоря - это CMS (вообще такого рода программное обеспечение уже выделяется в отдельный класс LMS - "Learning Management System"), позволяющая действительно просто развёртывать сайты для онлайн-обучения.
Прикладное администрирование LMS "Moodle" не будет рассматриваться - да я и не знаю о нём практически ничего - здесь лишь об оптимизации системного окружения, позволяющего web-сервису работать быстрее и надёжнее.
Предварительная подготовка файловой системы.
Самому классическому web-серверу более чем достаточно 50GB на все его нужды, но объём данных учебных курсов LMS "Moodle" может возрастать самым непредсказуемым образом - в зависимости от аппетитов преподавателей. Удобнее всего завести отдельный виртуальный диск для данных, начальными размером до 200-250 Гигабайт, который можно будет расширять по мере появления необходимости, не затрагивая при этом операционную систему.
Исходя из того, что системный диск уже размечен и введён в работу, добавляем диск (в нашем случае второй, предположительно именованный как "sdb") и файловую систему для хранения данных (разумеется, мы живём с LVM):
Защищаем административный вход.
Сразу после инсталляции базовых компонентов операционной системы запрещаем сетевой вход через SSH для суперпользователя.
Предварительно проверяем корректность изменений конфигурационного файла и перезапускаем OpenSSH-сервер:
Устанавливаем программное обеспечение.
Прежде всего обновим имеющееся ПО и укомплектуем операционную систему утилитами комфорта:
Некоторые современные и потому модные подсистемы чаще всего лишние - иногда их есть смысл удалить, чтобы не путались "под ногами":
Устанавливаем наборы пакетов приложений требующихся непосредственно для развёртывания web-сервиса. Полезно сделать это заранее, чтобы далее работать уже с набором автоматически созданных инсталляторами необходимых директорий и файлов.
СУБД (для ОС до 2020-го):
СУБД (для ОС после 2020-го):
Скачиваем и применяем PGP-ключ, которым подписано содержимое официального APT-репозитория "MySQL", формируем выделенный конфигурационный файл описания подключения к репозиторию и устанавливаем ПО:
LMS "Moodle" для работы требуются специфичное ПО - устанавливаем его и проверяем, появились ли нужные утилиты по ожидаемым путям:
Устанавливаем точное системное время.
Виртуальный сервер синхронизирует свои часы через несущую систему виртуализации, но изначально может потребоваться явно указать желаемый часовой пояс (пример для Новосибирска):
Синхронизируемся с каким-нибудь солидным сервером:
Если это аппаратный сервер, то сохраняем полученные показатели времени в постоянную память BIOS:
Дополняем системный набор национальных кодировок.
В свежеустановленном Linux-сервере запросто может не оказаться полноценной поддержки "национальной кодировки" (в нашем случае - русской). Обычно на новых серверах я не трачу время на проверки, а сразу перехожу в режим конфигурирования, добавляя нужные кодировки и удаляя невостребованные:
Естественно, кроме всего прочего, активируем пункт "ru_RU.utf8". В качестве варианта "по умолчанию", применяемого для приложений не требующих определённой кодировки, я выбираю "en_US.UTF-8".
Удостоверяемся в успешности изменения перечня поддерживаемых кодировок:
Файловая структура сайтов.
Исходя из задачи создания выделенного web-сервера, предназначенного для обслуживания одного-двух сайтов, не пытаемся выдумать что-то эксклюзивное в структуре файловых ресурсов, в просто следуем общепринятой идеологии иерархии, лишь слегка дополняя её более точными и удобными определениями прав доступа:
Через расширение POSIX ACL предпишем устанавливать всем создаваемым файлам (и директориям) разрешения полного доступа как для пользователя, так и группы (в отличии от системных установок "umask 0022", разрешающим группе только чтение), при этом полностью убираем доступ всем остальным:
Опция "--no-mask" в команде выше важна - она прямо указывает не использовать какие-либо фильтры при вычислении "итоговых допусков", устанавливая буквально только те, что указаны.
После задания глобальных параметров доступа файловой структуры набора сайтов, для просмотра списка сайтов разрешаем заходить в корень структуры всем (но не глубже - правило не рекурсивное):
Смотреть результаты - так:
Добавляем директории ресурсов LMS-сайта как такового:
Предварительно создадим или обновим параметры прав доступа директории хранения файлов web-сессий - в дальнейшем мы слегка это оптимизируем:
Рассматривать здесь полную настройку PHP-интерпретатора не вижу смысла и обращу внимание лишь на особенности, необходимые для работы LMS "Moodle":
Обязательно проверяем корректность конфигурации, простейшим тестированием:
В настройках FPM-пула изменим ряд параметров для достижения лучшей производительности:
Проверяем корректность конфигурации и перезапускаем FPM-сервис:
Оптимизация работы PHP с дисковой подсистемой.
Для ускорения операций создания и поддерживания PHP-интерпретатором web-"сессий" удобно вынести директорию файлов хранения таковых в специально созданную директорию, смонтированную в область ОЗУ - на мой взгляд это проще и надёжнее применения в этом качестве "Memcached" и тому подобных дополнительных инструментов.
Место сохранения сессий в PHP определяется параметром "session.save_path" и по умолчанию оно располагается в директории "/var/lib/php/sessions". Точнее всего это выявляется через вывод функции "php_info()". Мне представляется самым простым смонтировать поверх этой директории кусочек "tmpfs":
Сразу настраиваем простейший "сборщик мусора", удаляющий устаревшие файлы сессий - ибо их нарастает действительно много:
Слегка корректируем глобальную конфигурацию web-сервиса:
Описываем конфигурацию типового web-сайта под управлением LMS "Moodle":
access_log off;
error_log off;
ssl on;
include /etc/nginx/ssl_wild_params;
access_log off;
error_log off;
Проверяем синтаксическую корректность новой конфигурации и указываем её принять:
Предварительно создадим или обновим параметры прав доступа директории хранения временных файлов - она будет затронута при оптимизации работы СУБД:
Основное требование, предъявляемое LMS "Moodle" к "MySQL" - поддержка формата хранения данных в "InnoDB":
LMS "Moodle" сильно хочет, чтобы СУБД предоставляла ей возможность сохранять данные в современной кодировке "utf8mb4", поддерживающей "четырёхбайтные символы" (в частности, для особо детализированных "смайликов"). С точки зрения общей функциональности это непринципиально, но в общем неплохо заранее перейти на более современные форматы хранения данных:
Проверяем корректность синтаксиса конфигурационных файлов MySQL-сервера и перезапускаем таковой:
Проконтролировать фактическое применение параметров можно посредством SQL-запроса:
Оптимизация работы MySQL с дисковой подсистемой.
Для СУБД, активно создающей и уничтожающей файлы для временных таблиц, выгодно вынести (параметрами "tmpdir") эту работу в файловую систему, смонтированную в область памяти ОЗУ:
Я бы выделил под эту файловую систему до 25% от всей ОЗУ (она не заблокирует всё заявленное место, а будет выбирать блоки памяти по мере появления необходимости).
Создаём БД для Moodle-сайта.
Настраиваем подсистему отправки почты.
Журнал регистрации событий утилита сама создавать не умеет, так что помогаем ей в этом:
Утилита "msmtp" способна полностью эмулировать классический "sendmail", так что для совместимости с настроенным по умолчанию программным обеспечением есть смысл сделать символическую ссылку, направляющую обращения в нужное место:
Для начала настроим один профиль, используемый по умолчанию:
При желании явно указываем PHP отсылать почту через "mSMTP", но на самом деле мы эту возможность уже реализовали ранее посредством символической ссылки к "sendmail":
.; sendmail_path = "/usr/sbin/sendmail -t -i"
sendmail_path = "/usr/bin/msmtp -t -i"
.
Проверяем, способен ли PHP-интерпретатор воспользоваться почтовой подсистемой:
LMS "Moodle" крупный проект, который естественным образом разделился на две кодовых ветви: "latest" и условный LTS (Long-term support). В частности, нынешний LTS - ветка "3.4.6", обновления безопасности для которой обещают выпускать до Мая 2019 года. Учитывая то, что в государственных бюджетных организациях процессы протекают чрезвычайно медленно (например попытка обновления существующего портала до "latest" версии "3.3" в НГУ длилась так долго, что разработчики за это время успели выкатить новый релиз "3.4"), то удобнее играть роль консерватора и в работе использовать LTS-релизы:
Загрузить дистрибутив можно следующим образом:
Развёртывание сайта под управлением LMS "Moodle".
Всё просто - разворачиваем дистрибутивный архив в целевую директорию, отрезав от имён извлекаемых файловых ресурсов предваряющее "moodle/":
Переводим свежераспакованные файлы во владение соответствующего пользователя:
Весь процесс инсталляции реализован через web-интерфейс:
Разработчики LMS "Moodle" реализовали полное разделение данных и средств управления таковыми: абсолютно всё пользовательское сосредоточено в директории "./moodledata", а файлы LMS могут быть заменены совершенно безбоязненно, за исключением несущего ключевые настройки файла "./www/config.php".
Отсюда следует, что если установка LMS "Moodle" пошла "совсем не так", то для её возобновления нужно всего лишь удалить файл "./www/config.php" (он потом будет воссоздан из "./www/config-dist.php").
По завершению установки лучше бы сразу проверить, получилось ли удовлетворить все требования LMS "Moodle" к программному обеспечению:
Корректировка разрешений доступа к пользовательским ресурсам.
Слишком свободные разрешения доступа для создаваемых LMS "Moodle" файлов мне не нравятся - исправим это (запретив доступ всем не членам группы "www-data"), заодно уточнив в конфигурационном файле ресурсов, там ли директория с данными, где предполагается:
Вынос файлов web-сессий в общепринятое место.
Ранее мы уже создали условия для хранения, быстрого к ним доступа и управления файлами "PHP sessions". LMS "Moodle" по умолчанию хранит таковые в своих директориях, что неэффективно - исправим это (для режима хранения сессий в файлах):
Как выяснилось в эксплуатации, LMS "Moodle" почему-то удаляет сессии, исходя из взятого из конфигурации PHP параметра "session.gc_maxlifetime" в 1440 секунд (по умолчанию). При этом переопределение этого параметра из панели администрирования "Moodle -> Администрирование -> Сервер -> Сессии" не срабатывало, без каких-либо предупреждений. Сайт молчком удалял свои "бездействующие" сеансы через 1440 секунд.
Помогло лишь явное указание длительности таймаута бездействия сессии в конфигурационном файле "Moodle". После этого в административной панели сайта у параметра сессии появилась отметка "Значение определено в файле config.php". Похоже, что это мелкий баг, вот таким образом обходящийся.
Вероятно, этого же эффекта глобально можно было добиться изменением параметра PHP "session.gc_maxlifetime" до больших значений.
Вынос хранилища файлов курсов на иную файловую систему.
LMS "Moodle" сам по себе громоздкий web-проект (164 Мегабайта при первичной установке, для v3.4.6), а уж файлы учебных курсов (по умолчанию располагающиеся в директории "./moodledata/filedir/") так быстро отъедают дисковое пространство на сотни Гигабайт, что весьма скоро сервер может стать немобильным. Потому первым делом стоит озаботится явным отделением тяжёлых данных от логики и легковесного контента, вынеся файловое хранилище на отдельную файловую систему. Я подключаю его по NFS или с иного внешнего СХД, в точку вне самого сайта, чтобы не смешивать сущности:
Создаём точку монтирования и подключаем файловую систему:
Перемещаем директорию с данными на выделенную файловую систему:
Для выноса web-ресурсов в пределах файловой структуры доступной PHP вполне достаточно "символической ссылки":
Важно понимать, что целиком выносить ресурс "./moodledata/" на внешнюю СХД нежелательно - в этой директории также расположены "кеши" и временные файлы ("./cache/", "./localcache/", "./temp/" и "./lock/"), постоянно запрашиваемые на чтение и изменение web-сервером. А вот большие и редко запрашиваемые файлы директории "./filedir/" вполне можно сложить на медленной файловой системе - при частом использовании они всё равно будут слегка кешироваться и скорость доступа к ресурсам в целом не снизится.Обеспечиваем возможность запуска заданий по расписанию.
В LMS "Moodle" встроен функционал исполнения заданий по расписанию. Он опирается на вызовы через системный "crontab":
В нашем случае пользовательский "crontab" расположен в "/var/spool/cron/crontabs/www-data", и в него следует внести соответствующее правило:
Включаем антивирусную проверку (опционально).
При желании можно установить антивирус "ClamAV" - в LMS "Moodle" есть плагин, посредством которого можно наладить предварительное сканирование загружаемых пользователями файлов:
<?php // Moodle configuration file
.
Восстановление доступа к учётной записи администратора.
Довольно часто случается, что пароль к учётной записи web-сервиса LMS "Moodle" оказывается забыт или утрачен. В составе сайта имеется соответствующая утилита, посредством которой пароль для известного пользователя сбрасывается в один проход:
== Password reset ==Enter username (manual authentication only)
: admin
.
На самом дела технически ничто не препятствует заменить "хеш" пароля в БД - но это чуть сложнее и не нужно:
После запуска web-сайта в работу возможно захочется проверить, как скоро он сдастся под возрастающей нагрузкой. Для этого можно воспользоваться утилитой "Siege".
Вот так очень просто протестировать сервер в сценарии "250 пользователей 10 минут упорно ходят по сайту":
Lifting the server siege.Transactions: 188316 hits
Availability: 100.00 %
Elapsed time: 599.28 secs
Data transferred: 6127.82 MB
Response time: 0.76 secs
Transaction rate: 314.24 trans/sec
Throughput: 10.23 MB/sec
Concurrency: 238.28
Successful transactions: 185865
Failed transactions: 0
Longest transaction: 2.93
Shortest transaction: 0.00
Ради интереса я запускал тестирование одновременно с нескольких рабочих станций, суммарно эмулирующих хождение по сайту пары тысяч пользователей - компоненты web-сервиса равномерно задействовали все доступные ресурсы, количество конкурентных запросов к дисковой подсистеме возросло до сотни (. ), но в целом сервер под нагрузкой спокойно себя чувствовал и отвечал на запросы без потерь таковых, даже будучи под завязку занят.
[ уже посетило: 3146 ] [ интересно! / нет ]
Поблагодарить автора ( сделайте свой денежный вклад в хорошее настроение )
Вы можете использовать Moodle для облегчения своего онлайн-курса и изучения веб-сайтов без необходимости учиться читать и писать сложные коды и скрипты.
Чтобы узнать больше о Moodle, посетите их домашнюю страницу.
Чтобы начать установку Moodle, выполните следующие действия:
Чтобы установить Nginx в Ubuntu, выполните следующие команды:
После установки Nginx приведенные ниже команды можно использовать для остановки , запуска и включения службы Nginx, которая всегда запускается с загрузкой сервера.
Чтобы проверить, установлен ли и работает ли Nginx, откройте свой веб-браузер и перейдите к IP-адресу или имени хоста сервера.
Если вы видите указанную выше страницу в своем браузере, значит, Nginx работает должным образом.
Шаг 2: Установите сервер базы данных MariaDB
Настоящим сервером базы данных с открытым исходным кодом, который вы можете использовать с Moodle, является сервер базы данных MariaDB. Это быстрый, безопасный и используемый по умолчанию сервер почти для всех серверов Linux.
Чтобы установить MariaDB, выполните следующие команды:
sudo apt-get install mariadb-server mariadb-client
После установки MariaDB следующие команды можно использовать для остановки , запуска и включения службы MariaDB, чтобы она всегда запускалась при загрузке сервера.
Затем запустите приведенные ниже команды, чтобы защитить сервер базы данных паролем root, если вам не было предложено сделать это во время установки.
При появлении запроса ответьте на приведенные ниже вопросы, следуя инструкциям.
- Enter current password for root (enter for none): Just press the Enter
- Set root password? [Y/n]: Y
- New password: введите пароль
- Re-enter new password: повторите пароль
- Remove anonymous users? [Y/n]: Y
- Disallow root login remotely? [Y/n]: Y
- Remove test database and access to it? [Y/n]: Y
- Reload privilege tables now? [Y/n]: Y
Чтобы проверить и убедиться, что MariaDB установлена и работает, войдите в консоль базы данных, используя следующие команды:
sudo mysql -u root -p
при появлении запроса введите пароль root.
Если вы видите экран, похожий на показанный выше, значит сервер успешно установлен.
Затем выполните следующие команды, чтобы открыть файл конфигурации по умолчанию MariaDB.
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
Затем добавьте выделенные строки ниже и сохраните.
После этого перезапустите MariaDB.
Шаг 3. Установите PHP 7.4 и связанные модули
Приведенная ниже команда добавит сторонний PPA в Ubuntu.
Затем обновите и обновите до PHP 7.4.
sudo apt update
Затем выполните приведенные ниже команды, чтобы установить PHP 7.4 и связанные модули.
sudo apt install php7.4-fpm php7.4-common php7.4-mysql php7.4-gmp php7.4-curl php7.4-intl php7.4-mbstring php7.4-soap php7.4-xmlrpc php7.4-gd php7.4-xml php7.4-cli php7.4-zip
После установки PHP 7.4 настройте некоторые базовые параметры, которые могут потребоваться для правильной работы Moodle.
Выполните команды ниже, чтобы открыть PHP.
Ниже приведены хорошие настройки для большинства веб-сайтов Moodle.
При этом должен быть установлен PHP 7.4 с некоторыми базовыми настройками, чтобы Moodle функционировал.
Шаг 4: Создайте базу данных Moodle
Когда все серверы установлены, пора приступить к настройке среды Moodle. Сначала выполните следующие действия, чтобы создать пустую базу данных для использования Moodle.
Войдите в консоль базы данных MariaDB, используя следующие команды:
sudo mysql -u root -p
Затем создайте базу данных с именем moodle
CREATE DATABASE moodle ;
Cоздайте пользователя базы данных с именем moodleuser и установите пароль
CREATE USER ' moodleuser '@'localhost' IDENTIFIED BY ' new_password_here ';
Затем предоставьте пользователю полный доступ к базе данных.
GRANT ALL ON moodle .* TO ' moodleuser '@'localhost' WITH GRANT OPTION;
Наконец, сохраните изменения и выйдите.
Шаг 5: Загрузите Moodle
На этом этапе Moodle готов к загрузке и установке. Используйте приведенные ниже команды, чтобы загрузить последнюю версию Moodle. На момент написания последней версии 38 .
Чтобы просмотреть выпуски Moodle, перейдите на страницу .
sudo apt install git curl
Затем выполните приведенные ниже команды, чтобы установить правильные разрешения для работы Moodle.
Шаг 6. Настройте Nginx
Ниже вы настраиваете файл Nginx VirtualHost для создаваемого сайта Moodle. Этот файл определяет, как обрабатываются и обрабатываются клиентские запросы.
Выполните приведенные ниже команды, чтобы создать новый файл VirtualHost с именем moodle в каталоге /etc/nginx/sites-available/
sudo nano /etc/nginx/sites-available/moodle
Ниже приведены очень хорошие настройки конфигурации для большинства сайтов Moodle на сервере Nginx. Эта конфигурация должна отлично работать.
Скопируйте содержимое ниже и сохраните в файл, созданный выше.
Сохраните файл и выйдите.
После сохранения файла, указанного выше, выполните следующие команды, чтобы включить новый сайт, а затем перезапустите сервер Nginx.
На этом этапе Moodle готов и его можно запустить, перейдя на IP-адрес сервера или имя хоста.
Приведенные выше команды установят инструмент certbot и все зависимости, которые позволят заставить инструмент работать.
Параметры команды выше описаны ниже:
- certonly: Obtain or renew a certificate, but do not install
- –manual: Obtain certificates interactively
- –preferred-challenges=dns: Use dns to authenticate domain ownership
- –server: Specify the endpoint to use to generate
- –agree-tos: Agree to the ACME server’s subscriber terms
- -d: Domain name to provide certificates for
Перейдите на портал своего поставщика DNS, добавьте текстовую запись для строки выше и сохраните.
Подождите несколько минут, прежде чем продолжить из командной строки.
Некоторые поставщики DNS используют хитрость для распространения изменений, поэтому это может зависеть от платформы вашего провайдера.
Подстановочный сертификат создан и готов к использованию.
Чтобы убедиться, что сертификат готов, выполните следующие команды:
sudo certbot certificates
Это должно отобразить аналогичный экран, как показано ниже:
Затем добавьте строку ниже и сохраните.
0 1 * * * /usr/bin/certbot renew >> /var/log/letsencrypt/renew.log
Сохраните, и все готово!
Выполните команды ниже, чтобы открыть файл.
sudo nano /etc/nginx/sites-available/moodle
Затем добавьте выделенные строки в файл VirtualHost, как показано ниже:
После вышеуказанного перезапустите Nginx и PHP 7.4-FPM.
Затем откройте браузер и перейдите к доменному имени сервера. Вы должны увидеть, как мастер установки Moodle завершит работу. Пожалуйста, внимательно следуйте указаниям мастера.
Затем следуйте инструкциям на экране.
Выберите язык установки и нажмите Далее, чтобы продолжить.
На следующем экране выберите диск базы данных [ MariaDB] и нажмите «Далее», чтобы продолжить.
На этом экране введите информацию о базе данных, которую вы создали выше, включая имя базы данных, имя пользователя и пароль.
Затем нажмите Далее, чтобы продолжить.
Здесь вы вводите имя пользователя администратора, создаете пароль и другие данные.
Когда вы закончите, Moodle должен быть установлен и готов к использованию. Войдите как администратор и начните настраивать свой сайт.
Поздравляю! Вы успешно установили Moodle CMS в Ubuntu 18.04 | 20.04. Если вы обнаружите какую-либо ошибку выше, пожалуйста, используйте форму комментария ниже, чтобы сообщить об этом.
Читайте также: