Настройка Moodle cron ubuntu

Обновлено: 05.07.2024

Хотя это не является очевидной частью установки Moodle, настройка Cron очень важна, когда речь идет о Moodle.

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

Вы можете проверить время последнего запуска Cron, выбрав Администрирование сайта > Уведомления.

Если cron не запускался в течение последних 24 часов, вы увидите что-то вроде:

"Сценарий обслуживания cron.php не запускался в течение как минимум 24 часов.

Если вы ничего об этом не видите, скорее всего, Cron время от времени запускается автоматически.

Также существует вероятность того, что ошибка мешает Cron работать должным образом. Вероятность этого намного ниже, чем в Moodle 2.7. Вы должны иметь возможность вручную запустить Cron и увидеть результаты, войдя в систему как администратор Moodle и перейдя по ссылке:

Просто замените "http://example.com/" URL-адресом вашего сайта Moodle. В Moodle есть некоторые настройки, которые могут препятствовать работе этого URL-адреса, поэтому, если он не работает, не думайте, что Cron не работает. Это могут быть просто какие-то настройки Moodle. Если Cron работает регулярно, отображаемый журнал может быть довольно коротким, поскольку есть элементы, которые запускаются только один раз в день и могут не отображаться в списке. Это особенно заметно, если вы дважды подряд запускаете Cron вручную.

Никогда не поздно настроить Cron. Вы обнаружите, что ваш сайт Moodle работает не только лучше, но и быстрее.

Процесс Moodle cron — это PHP-скрипт (часть стандартной установки Moodle), который необходимо регулярно запускать в фоновом режиме. Сценарий хрона Moodle запускает разные задачи с разным запланированным интервалом.

ВАЖНО: Не пропустите настройку процесса cron на вашем сервере для вашего Moodle. Без него ваш сайт не будет работать должным образом.

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

Программа cron (которая запускает сценарий Moodle) – это основная часть систем на базе Unix (включая Linux и OSX), которая используется для запуска всевозможных сервисов, зависящих от времени. В Windows самым простым решением является создание задачи в планировщике задач Windows и настройка ее запуска через равные промежутки времени. На виртуальном хостинге вы должны найти документацию (или спросить поддержку), как настроен cron. Большинство систем виртуального хостинга используют CPanel для управления сайтами, и обычно на панели есть раздел для заданий Cron.

По сути, задача заключается в добавлении одной команды в список операций cron в вашей системе. В системах на основе Unix этот список представляет собой файл с именем «crontab», который есть у всех пользователей.

Содержание

Общие обсуждения

См. следующие разделы для вашего типа сервера; этот раздел содержит некоторую общую справочную информацию.

Существует два основных этапа внедрения cron:

  1. определение правильной команды для запуска
  2. нахождение нужного места в вашей системе для размещения команды

Отработка команды cron Moodle

У Moodle есть два разных способа развертывания cron, которые используют разные сценарии в рамках установки Moodle. Они следующие.

Веб-команда Moodle cron

  • Если у вас есть выбор, не используйте веб-cron. Скорее всего, он будет удален в будущей версии Moodle.
  • Начиная с Moodle 2.9, задание cron больше нельзя запускать из Интернета по умолчанию. Вы получите сообщение об ошибке:
  • Вы можете изменить это в «Панель управления ► Администрирование сайта ► Безопасность ► Политики сайта», сняв флажок «Выполнение Cron только через командную строку».
    • Вы будете предупреждены о том, что "Запуск cron из веб-браузера может предоставить привилегированную информацию анонимным пользователям". Поэтому рекомендуется запускать cron только из командной строки или устанавливать пароль cron для удаленного доступа.'
    • Затем вы можете написать «пароль Cron для удаленного доступа». Если это поле оставить пустым, пароль не требуется.
    • Это означает, что сценарий cron.php не может быть запущен из веб-браузера без указания пароля с использованием следующей формы URL:

    Нахождение правильного места для размещения команды

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

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

    Пример. установка cron на Ubuntu/Debian Linux. Предполагая, что вы вошли в систему как root..

    используйте команду crontab, чтобы открыть окно редактора crontab для пользователя www-data. Это пользователь, под которым работает Apache (веб-сервер) в системах на основе Debian

    Откроется окно редактора. Чтобы запускать скрипт cli cron каждую минуту, добавьте строку:

    ПРИМЕЧАНИЕ: окончательный >/dev/null отправляет все выходные данные в «корзину» и перестает получать электронные письма каждую минуту.

    Настройка cron в вашей системе

    Выберите информацию для вашего типа сервера:

      - Службы Cron в различных операционных системах UNIX и Linux. - Службы Cron в Windows.
    • Apple OSX — используйте встроенную службу crontab, которая точно такая же, как Cron в Unix или Linux. Тем не менее, вы можете сделать это «путем Apple» с помощью launchd — см. Cron с MAC OS X — службы Cron в различных примерах веб-хостинга.

    Вот еще несколько инструкций для определенных хостов (пожалуйста, убедитесь, что они обновлены):

    Использование сторонней службы cron

    Помимо использования cron, размещенного на вашем собственном сервере, вы можете использовать стороннюю службу cron (обычно называемую webcron):

      является бесплатным сервисом. (Возможен 1-минутный cron)
      - Поставщик услуг webcron, который устраняет необходимость в crontab или других планировщиках задач для установки задания cron.
      - Бесплатный и простой поставщик услуг webcron.

    Настройки Cron в Moodle

    Администратор может установить запуск cron только через командную строку или пароль cron для удаленного доступа в «Настройках безопасности сайта» в администрировании сайта.

    Удаленный хрон

    При использовании «веб-версии» cron процесс cron можно разместить на другом компьютере, а не на сервере Moodle. Например, служба cron на сервере Unix может вызывать веб-страницу cron на сервере Moodle под управлением Windows.

    Планирование задач

    Администратор может очень точно запланировать задачи cron, выбрав Администрирование > Администрирование сайта > Сервер > Запланированные задачи, см. Запланированные задачи

    Запуск cron для нескольких серверов Moodle

    Отладка запланированных задач

    Иногда конкретная задача cron может работать неправильно. В версиях Moodle до 2.7 любая задача cron, выбрасывающая исключения, мешала бы запуску остальной части cron. Единственный способ отслеживать, завершается ли cron каждый раз, заключался в том, чтобы добавить некоторую автоматическую проверку вывода запущенного cron (например, поиск строки «Cron завершен в»).

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

    Ведение журнала и мониторинг

    В идеале вы также должны где-то регистрировать выходные данные cron и отслеживать их на наличие проблем. Вы можете следить за общим состоянием cron, чтобы убедиться в отсутствии ошибок, посетив:

    Администрирование сайта/Отчеты/Статус системы (/report/status/index.php)

    Если есть ошибки, вы можете получить более подробную информацию о недавно запущенных задачах в столбце Журналы на странице запланированных задач, но это не будет отображать сбои специальных задач:

    Администрирование сайта/Сервер/Задачи/Запланированные задачи (/admin/tool/task/scheduledtasks.php)

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

    Специальные задачи с малой задержкой

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

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

    Начиная с Moodle 3.9, опция Keep-alive работает как демон, поэтому, когда очередь пуста, а не выход, она ожидает, пока в очередь будут поставлены новые задачи, чтобы начать обработку как можно скорее.

    Увеличение масштаба cron с несколькими процессами

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

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

    По умолчанию одновременно могут выполняться только 3 запланированных задачи и 3 нерегламентированные задачи, поэтому при добавлении дополнительных процессов необходимо повысить уровень допустимого параллелизма:

    Администрирование сайта > Сервер > Задачи > Обработка задач

    Или в config.php:

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

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

    У меня такой вопрос.

    Может кто-нибудь объяснить мне, шаг за шагом, как именно я могу заставить файл cron выполняться автоматически каждые x минут. Я никогда раньше не устанавливал задание cron, и мне очень нужна помощь!

    Что ж, возможно, вы захотите посмотреть раздел в crontab перед разделом о том, что добавить в crontab. ;=>

    НО, прежде чем что-либо делать, проверьте документацию по вашей локальной системе, так как существует множество разновидностей инструментов для управления crontab в зависимости от ОС, и вы можете очень запутаться, почему ваше задание cron не выполняется, когда вы создал личный cron, у которого нет разрешений для запуска ваших заданий. и в некоторых ОС нет функций редактирования, которые есть в других, а для некоторых требуются специальные символы в файлах crontab. Так что прочитайте документацию по вашей ОС (и я не имею в виду общую документацию по Linux, я имею в виду документацию по вашему дистрибутиву), особенно если вы используете Unix.

    Наконец, сначала я хотел бы проверить ваши усилия. Запустите свою реальную команду из командной строки, а также придумайте какое-нибудь ванильное действие, чтобы проверить работу вашего cron (без фактического запуска cron.php). Подумайте о вызове задания cron таким образом, чтобы вы получали информацию об отладке из скрипта и cron — иногда проще выбросить их, чем потом гадать, что пошло не так, — так что настройте его и сбрасывайте почту, когда она будет недельной давности. или что-то в этом роде (вы можете генерировать почти 300 в день) или записывать результаты.

    Я бы посоветовал воспользоваться tinme сейчас, чтобы посмотреть на использование cron для целей резервного копирования (у меня есть примечание на странице обсуждения BackupFAQ, я думаю о некоторых вариантах), и вы можете посмотреть на фактическое создание пакетного файла, который включает в себя все ваши задачи, связанные с настроением, хотя вам, вероятно, придется некоторое время проверять в cron.php, когда запускать или не запускать то или иное, что, возможно, предполагает простое добавление задач в существующий cron. php??)

    Я знаю, что напишу вам "Хелен", но это хороший совет, который пойдет на пользу статье cron в документации.

    Пока мы на этом, общее впечатление, что сейчас кажется, что скрипт cron запускается не с помощью wget, а скорее как скрипт командной строки PHP.

    Вот запись cron из одного из моих ящиков Ubuntu, если это поможет.

    */15 * * * * /usr/local/bin/php -f /home/blahdeblah/public_html/admin/cron.php >/dev/null

    Я знаю, что напишу вам "Хелен", но это хороший совет, который пойдет на пользу статье cron в документации.

    Я знаю, когда меня подбрасывает моя собственная петарда, Ховард, и если бы я был нанят партнером Moodle, я бы, вероятно, понял это правильно . К сожалению, я думаю, что на данный момент я перегружен, но внесу это в свой список дел - LOL.

    Хотя я знаю, что Стив критикует Moodle из-за проблем с безопасностью, и я понимаю, что отсутствует какое-то другое действие cron.php (а также все остальное в admin) выставлено, вы думаете, что я ошибаюсь, предполагая, что единственная реальная угроза, запускающая cron.php через wget, заключается в том, что он, возможно, предлагает доступ к невероятно простой DoS-атаке (и я уверен есть те, кто будет счастлив, что никто не предпринял усилий, чтобы продемонстрировать, как это будет работать) в том смысле, что я не верю, что это делает какую-либо блокировку, в то время как если вы задаете пароль, ваш пароль отображается в вашем crontab (как Moodle не различать команду, запускаемую через wget, по URL-адресу настроения и запуск той же команды из окна браузера).

    Так что да, Говард, вы абсолютно правы (но будьте осторожны, особенно на веб-хостингах, так как вам может понадобиться полный путь к бинарному файлу php, который вы хотите вызвать, и там, где есть множественная установка php, указывающая на неправильный место или позволить ОС решить, какой двоичный файл через PATH может привести к проблемам), но не должно ли быть общего ограничения безопасности, применяемого к функциям администратора, даже если только через htaccess?

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

    Итак, я прав, думая, что если я выполню следующую команду, то cron.php будет запускаться каждые 30 минут навсегда:

    crontab -e
    */30 * * * * wget -q -O /dev/null /var/www/admin/cron.php

    Неужели все так просто?

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

    Но да, это должно сработать.

    У меня небольшая проблема.

    Я зашел в Konsole и ввел: 'sudo crontab -e', и я попаду в редактор. Я перешел на вторую строку и ввел: «*/30 * * * * wget -q -O /dev/null /var/www/admin/cron.php» — затем я нажал «Ctrl + O», и он сказал, что в файл было записано 2 строки.

    Однако всякий раз, когда я снова вхожу (crontab -e), он исчезает, как будто я никогда не входил в него! Так что не залипает, значит не работает. Кто-нибудь знает, почему это происходит?

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

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

    Поэтому я бы сначала проверил cron из командной строки, затем wget, регистрируя все, из командной строки (если вы планируете использовать wget), а затем проверил вашу вкладку cron с помощью простого скрипта (убедившись, что пользователь, чей crontab вы использование в качестве завивки) и т. д. и т. д.

    Если вы чем-то похожи на меня, фраза "внести это в мой список дел" примерно переводится как "ни за что, черт возьми, я этим не занимаюсь"

    Конечно, есть возможность ограничить веб-доступ к сценарию cron. К сожалению, он не включен по умолчанию, поэтому ваше замечание о возможной DoS-атаке справедливо. Я предполагаю, что это должно быть сбалансировано с уровнем путаницы, который может быть вызван изменением этого сейчас.

    О, и. Стив кто?

    Мой список дел на 2 кубических фута бумаги ближе ко мне, чем моя круглая папка. так что может быть надежда для меня Говард. а слабину всегда можно наверстать - LOL

    Насколько я понимаю, в 1.9.2 параметр командной строки отключает параметр пароля, а Moodle не различает вызов wget и браузера (я думаю, что метки интерфейса здесь вводят в заблуждение, хотя я полагаю, что код мог бы проверить для того, как вызывался URL-адрес. ), что означает, что если вы используете пароль, пароль также должен использоваться через wget. я ошибаюсь здесь? И это означает, что пароль отображается в виде открытого текста в вашем crontab и передается в виде открытого текста всякий раз, когда запускается cron.php, поэтому, как минимум, НЕ используйте пароль, который вы используете для чего-либо еще!! Конечно, очень просто написать веб-клиент для взлома пароля cron.php (примерно такой же код для автоматизации участия в онлайн-конкурсах). С другой стороны, любой, у кого есть доступ к вашей системе, может также запустить cron.php как часто, как они хотят, даже если вы настроили Moodle для работы только с командной строкой, и на многих веб-хостингах это может означать любого, кто использует ваш сервер.

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

    Конечно, установка галочки в командной строке означает, что она вообще не будет работать как веб-страница. То есть и wget, и прямой доступ к браузеру отключены. Я так во всяком случае воспринял. Затем вам *нужно* использовать PHP CLI (как в моем примере). еще одна очень веская причина для этого (и, да, предпочтительная конфигурация для безопасности).

    Полагаю, чтобы расширить ваш аргумент, единственный способ быть на 100% безопасным — это выключить сервер. Есть мысль.

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

    Пароль cron.php означает, что вы должны добавлять пароль при любом вызове (включая wget), а пароль передается в виде открытого текста и легко взломан (без блокировок и т. д.)

    Хотя я согласен с вами, что отключение сервера было бы лучшим техническим решением с текущей конфигурацией, я думаю, что почти все в /admin вызывает require_login(), кроме cron.php, так как это должно вызываться извне, но это не означает, что мы не должны пытаться защитить его вызов.

    Я думаю, что это сводится к тому же обсуждению, которое у меня было по поводу механизма EGP для обеспечения оценок. что на самом деле не более чем скрытие с помощью javascript. никакой реальной безопасности. Если школьный округ с 50 000 учащихся предоставит личную информацию в сети, доступ к которой не будет зашифрован или защищен каким-либо иным образом, кроме сокрытия ее местонахождения, будет ли это соответствовать требованиям FERPA? Что ж, взлом легко осуществить, и он регулярно публиковался в сети, но это, по-видимому, не разубедило субъекта Дистрикта, чья позиция, по-видимому, заключается в том, что данные достаточно безопасны. Это нормально для политики до тех пор, пока некоторые г/т дети не получат галочку, потому что они вынуждены ходить в школу, где им скучно до смерти, и решить, что «теперь пришло время для чего-то совершенно другого». и взломать новый пароль пользователя (все настроено на одно и то же), а затем начать публиковать районы всей Active Directory или что-то еще.

    Как пел Джимми Хендрикс, "Ты мишень, ты когда-нибудь был мишенью?"

    Эй, куда делся этот?

    Да, проверьте CLI и убедитесь, что знаете, какой php вы вызываете - LOL

    MG и другие секретные агенты пассивно прослушивают этот форум,

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

    Кстати, безопасность криптографических данных — одна из моих специальностей. Тссс. Никому не говори.

    Пожалуйста, сожгите этот пост, прежде чем читать его.

    Я думаю, что все это может показаться немного глупым

    Честно говоря, я понятия не имею, является ли cron вектором DoS-атаки. Моя интуиция такова, что я сомневаюсь, что это хуже, чем другие страницы Moodle, на которые вы можете ориентироваться, не входя в систему.

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

    Нет совпадений, но все улики растворены в HF.
    Переключитесь на канал 127 и введите код FFA69AFD. ;)

    Я думаю, что вы указали на это, когда предположили, что обслуживание в LMS через внешнюю LMS немного примитивно; Я согласен. К сожалению, интерфейс командной строки тоже не помешал бы. Кстати, мой список дел включает в себя демон perl с вызовом процедур резервного копирования и крючков для других разных вещей, таких как обновления cvs. это в списке ;=> LOL

    Но что касается DoS, помимо определения определения, я должен предположить, что степень, в которой хакер может повлиять на систему, запустив cron.php, должна подвергаться некоторому общему вычислению, которое может потребовать одного определить, есть ли время по умолчанию, когда cron.php выполняет A, B или C, в какой степени задействует cron.php через Интернет создает любые файлы блокировки (в /tmp, /moodledata или в базе данных), в отличие от запуска нескольких экземпляров wget через демон cron и т. д. У меня очень маленькие мудлы, но если кто-то имеет доступ к некоторым мудлам с тысячами активных студентов и курсов предполагалось, что 10 или 20 пользователей нацеливают свою систему на cron-флуд в разное время, что может совпадать с различными предопределенными функциями cron.php, мы могли получить довольно точную оценку возможных последствий.

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

    Что касается вашего скрипта, я думаю, что большинство людей посоветовали бы не использовать внутренние процедуры Moodle для создания резервной копии вашего сайта. Обычно вместо этого нужно просто сбросить, скопировать или реплицировать всю базу данных на другую машину и скопировать папку moodledata. Внутренние процедуры резервного копирования требуют больших вычислительных ресурсов и полезны в основном для восстановления одного курса. Вам также, вероятно, порекомендуют не автоматизировать обновления cvs, поскольку конфликты скриптов могут нарушить работу вашего сайта, что особенно вероятно, если вы настроили какие-либо скрипты.

    Возможно, переместив cron.php в другое место и заменив его скриптом, который сообщает хакеру, что IP-адрес вызываемой удаленной системы зарегистрирован, ищет владельцев сети, получает контактную информацию и отправляет электронную почту. соответствующим органам, указывающим, что пользователь с таким-то и таким-то IP-адресом пытается взломать систему. LOL - опять же, все это просто балансирование - насколько безопасно вы хотите чувствовать себя по сравнению с количеством ресурсов, которые вы хотите посвятить безопасности. единственная реальная проблема здесь, если хотите, это степень, в которой неправильное использование cron.php может вызвать проблемы. Тем не менее, демон, вероятно, был бы немного более безопасным, но тогда зачем тратить ресурсы на эстетику, если нет проблем с безопасностью ;=>

    Что касается резервного копирования, я не говорил об использовании чего-либо внутреннего в Moodle для создания резервных копий — я ссылался на обсуждение на странице обсуждения раздела часто задаваемых вопросов о резервном копировании. Приняв соответствующие меры предосторожности, чтобы любой скрипт мог вернуться к предыдущей конфигурации, использование CVS не должно вызывать никаких проблем, задача состоит в предоставлении соответствующих автоматических тестов для проверки успешного автоматического обновления, что можно сделать довольно просто с помощью программирования веб-клиента. Конечно, предполагается, что все обновления cvs тестируются и проходят QA, как и все остальное, при прочих равных условиях. пока человек не сбивается с пути, он должен быть на вес золота, не так ли?

    Это вырезка и вставка из блога "Стива Кто",

    Насколько я знаю, нет реальной возможности DoS-атаки с тем, как Moodle обрабатывает cron, Стив.

    cron.php не выполняет десятки тяжелых задач каждый раз, когда он вызывается. Наоборот. Он выполняет эти тяжелые задачи только в определенном проценте времени, когда он вызывается, или если пришло время для их запуска.

    Поэтому, хотя вы можете запускать cron.php несколько раз в секунду, он не будет выполняться. сообщения форума (чтобы назвать, возможно, тяжелую задачу) каждый раз, но только если прошло достаточно времени с момента их последней обработки. Другие задачи выполняются только в 20% случаев, и эти задачи уменьшают объем работы, выполняемой каждый раз при их вызове (например, обработка статистики). Поэтому, если вы позвоните им тысячу раз, первые несколько раз у них будет много работы, а после этого они просто вернутся, ничего не делая.

    Конечно, вы может вывести из строя ваш веб-сервер, если вы вызовете cron.php через Интернет тысячу раз в секунду, но вы можете сделать это и со статической страницей

    Кстати, это справедливо и для сценария PHP CLI.

    Обязательно вырезать и вставить *к* (не откуда)

    Очень хорошее замечание! Стив, Который знает всё - он должен был это заметить!!

    Сказать, что DoS-атака не является D0S-атакой, потому что риску подвергается только демон Apache? Даже пинг-флуд — это DoS-атака, как бы банально это ни звучало. Или подумайте о пердоне, который получил учетную запись электронной почты и настроил ее для пересылки почты на внешнюю учетную запись, которую он настроил для пересылки обратно, и в пятницу отправил себе файл размером 1 мегабайт. Одно время около 50% процессорного времени одного из моих веб-серверов потребляли боты.

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

    Суть здесь в том, что если cron.php не представляет возможную проблему безопасности, то нет абсолютно никаких причин предоставлять или рекомендовать опцию CLI. А для тех, кто совместно использует веб-хосты, поскольку обычно все пользователи вашей системы могут читать этот файл, он может быть запущен любым, у кого есть доступ к системе, и не требует полномочий root.

    Сказать, что DoS-атака не является D0S-атакой, потому что риску подвергается только демон Apache?

    Я не говорил, что это не DoS-атака, потому что это всего лишь DoS-атака Apache. Я имел в виду, что это не специфичный для Moodle DoS. То есть, отказ в обслуживании не является результатом ошибки Moodle или дефекта кода, как это заставляет поверить сообщение в блоге Стива Хайндмана (вот оно, прямая ссылка на блог "Стива Кто").

    Суть здесь в том, что если cron.php не представляет возможную проблему безопасности, то нет абсолютно никаких причин предоставлять или рекомендовать опцию CLI.

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

    При запуске из командной строки все эти задачи просто игнорируются, и PHP-скрипт сразу же запускается, а объем памяти CLI PHP также меньше.

    Вы думаете, я ошибаюсь, предполагая, что единственная реальная угроза запуска cron.php через wget заключается в том, что он, возможно, предлагает доступ к невероятно простой DoS-атаке?

    Wget часто отключается системными администраторами для предотвращения атак DOS и проверки серверов по сценариям, поэтому wget обычно отключается на защищенных серверах. Не связанная с Moodle проблема (да, кто-то может написать скрипт wget для вашего cron, но он просто запускает то, что вы хотите запускать регулярно и чаще).

    Поэтому, если wget работает, попросите вашего системного администратора отключить его, а затем настройте запуск cron через интерфейс командной строки.

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

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

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

    Разделы в этом документе:

    1. Требования

    Moodle в основном разрабатывается для Linux с использованием Apache, MySQL и PHP (также иногда называемой платформой LAMP), но также регулярно тестируется с PostgreSQL и операционными системами Windows XP, Mac OS X и Netware 6

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

    1. Программное обеспечение веб-сервера. Большинство людей используют Apache, но Moodle должен нормально работать на любом веб-сервере, поддерживающем PHP, например IIS на платформах Windows. язык сценариев (версия 4.1.0 или выше). PHP 5 поддерживается, начиная с Moodle 1.4.
    2. рабочий сервер базы данных: MySQL или PostgreSQL полностью поддерживаются и рекомендуются для использования с Moodle.

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

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

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

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

    Если вы загружаете Moodle на свой локальный компьютер, а затем загружаете его на свой веб-сайт, обычно лучше загрузить весь архив одним файлом, а затем выполнить распаковку на сервере. Даже интерфейсы веб-хостинга, такие как Cpanel, позволяют распаковывать архивы в «Диспетчере файлов».

    3. Структура сайта

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

    • admin/ — код для администрирования всего сервера
    • auth/ — подключаемые модули для аутентификации пользователей
    • blocks/ — подключаемые модули для небольших боковых блоков на многих страницах
    • calendar/ — весь код для управления и отображения календарей
    • course/ — код для отображения курсов и управления ими
    • doc/ — справочная документация для Moodle (например, эта страница)
    • files/ — код для отображения загруженных файлов и управления ими
    • lang/ — тексты на разных языках, по одному каталогу на каждый язык
    • lib/ — библиотеки основного кода Moodle
    • login/ — код для входа в систему и создания учетной записи
    • mod/ — здесь собраны все основные модули курса Moodle
    • pix/ – общая графика сайта
    • theme/ — наборы тем/обложек для изменения внешнего вида сайта.
    • user/ — код для отображения пользователей и управления ими

    4. Запустите скрипт установщика, чтобы создать config.php

    (Установщик попытается установить файл cookie сеанса. Если в браузере появится всплывающее предупреждение, убедитесь, что вы принимаете этот файл cookie!)

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

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

    4.1 Общие настройки веб-сервера

    Во-первых, убедитесь, что ваш веб-сервер настроен на использование index.php в качестве страницы по умолчанию (возможно, в дополнение к index.html, default.htm и т. д.).

    Просто убедитесь, что index.php находится в списке (и желательно ближе к началу списка, для эффективности).

    В-третьих, для работы Moodle необходимо активировать ряд настроек PHP. На большинстве серверов это уже будут настройки по умолчанию. Однако некоторые серверы PHP (и некоторые из более поздних версий PHP) могут иметь разные настройки. Они определены в файле конфигурации PHP (обычно называемом php.ini):

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

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

    Проще всего просто скопировать файл примера из lib/htaccess и отредактировать его в соответствии с вашими потребностями. Он содержит дальнейшие инструкции. Например, в оболочке Unix:

    4.2 Создание базы данных

    Вам необходимо создать пустую базу данных (например, "moodle") в вашей системе баз данных вместе со специальным пользователем (например, "moodleuser"), который имеет доступ к этой базе данных (и только к этой базе данных). . Вы можете использовать пользователя «root», если хотите, для тестового сервера, но это не рекомендуется для производственной системы: если хакерам удастся узнать пароль, то под угрозой окажется вся ваша система баз данных, а не только одна база данных.

    Если вы используете веб-хостинг, у них, вероятно, будет веб-интерфейс панели управления для создания базы данных.

    Система Cpanel — одна из самых популярных из них. Чтобы создать базу данных в Cpanel,

    1. Нажмите значок "Базы данных MySQL".
    2. Введите "moodle" в поле базы данных и нажмите "Добавить базу данных".
    3. Введите имя пользователя и пароль (не те, которые вы используете где-либо еще) в соответствующих полях и нажмите "Добавить пользователя".
    4. Теперь используйте кнопку "Добавить пользователя в базу данных", чтобы предоставить этой новой учетной записи пользователя "ВСЕ" права на новую базу данных.
    5. Обратите внимание, что имя пользователя и имена баз данных могут начинаться с имени вашей учетной записи Cpanel. При вводе этой информации в установщик Moodle используйте полные имена.

    Если у вас есть доступ к командным строкам Unix, вы можете делать то же самое, вводя команды.

    Вот несколько примеров командных строк Unix для MySQL:

    И несколько примеров командных строк для PostgreSQL:

    4.3 Создание каталога данных

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

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

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

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

    На компьютерах с Unix это означает, что владельцем каталога должно быть что-то вроде «никто» или «apache», а затем предоставлены права на чтение, запись и выполнение.

    В системах Cpanel вы можете использовать «Диспетчер файлов», чтобы найти папку, щелкнуть по ней, затем выбрать «Изменить разрешения». На многих серверах общего хостинга вам, вероятно, потребуется ограничить доступ ко всем файлам вашей «группе» (чтобы другие клиенты веб-хостинга не могли просматривать или изменять ваши файлы), но предоставить полный доступ для чтения/записи всем остальным (что позволит веб-сервер для доступа к вашим файлам).

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

    5. Перейдите на страницу администратора, чтобы продолжить настройку

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

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

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

    СОЗДАТЬ ТАБЛИЦУ курс ( id int(10) unsigned NOT NULL auto_increment, категория int(10) unsigned NOT NULL по умолчанию '0', пароль varchar(50) NOT NULL по умолчанию '', полное имя varchar(254) NOT NULL по умолчанию ' ', краткое имя varchar(15) NOT NULL по умолчанию '', текст сводки NOT NULL, формат tinyint(4) NOT NULL по умолчанию '1', учитель varchar(100) NOT NULL по умолчанию 'Учитель', дата начала int(10) unsigned NOT NULL по умолчанию '0', enddate int(10) unsigned NOT NULL по умолчанию '0', timemodified int(10) unsigned NOT NULL по умолчанию '0', PRIMARY KEY (id)) TYPE=MyISAM

    <р>. и т. д., а затем: Основные базы данных успешно настроены.

    Если вы их не видите, возможно, возникла какая-то проблема с базой данных или настройками конфигурации, которые вы определили в config.php. Убедитесь, что PHP не находится в ограниченном «безопасном режиме» (иногда на коммерческих веб-хостингах включен безопасный режим). Вы можете проверить переменные PHP, создав небольшой файл, содержащий его, и просмотрев его в браузере. Проверьте все это и повторите попытку на этой странице.

    Прокрутите страницу вниз до самого низа и нажмите ссылку "Продолжить".

    Теперь вы должны увидеть форму, в которой вы можете определить дополнительные переменные конфигурации для вашей установки, такие как язык по умолчанию, хосты SMTP и т. д. Не беспокойтесь слишком сильно о том, чтобы сделать все правильно прямо сейчас - вы всегда можете вернуться и отредактировать их позже, используя интерфейс администратора. Значения по умолчанию разработаны так, чтобы быть полезными и безопасными для большинства сайтов. Прокрутите вниз и нажмите "Сохранить изменения".

    Если (и только если) вы обнаружите, что застряли на этой странице и не можете продолжить, то, вероятно, на вашем сервере возникла проблема, которую я называю "глючным реферером". Это легко исправить: просто отключите настройку "secureforms" и попробуйте продолжить снова.

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

    Прокрутите страницу вниз до самого низа и нажмите ссылку "Продолжить".

    Следующая страница — это форма, в которой вы можете определить параметры для вашего сайта Moodle и главной страницы, такие как имя, формат, описание и т. д. Заполните это (вы всегда можете вернуться и изменить их позже), а затем нажмите "Сохранить изменения".

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

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

    (Если по какой-либо причине ваша установка прервана или возникла какая-то системная ошибка, которая не позволяет вам войти в систему с использованием учетной записи администратора, вы обычно можете войти в систему, используя имя пользователя по умолчанию "admin" с паролем " админ".)

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

    • создание и удаление курсов
    • создание и редактирование учетных записей пользователей
    • управление учетными записями преподавателей
    • изменение настроек сайта, таких как темы и т. д.

    Но вы еще не закончили установку!Осталось сделать еще одну очень важную вещь (см. следующий раздел о cron).

    6. Настройте cron — ВАЖНО!

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

    Сценарий, который все это делает, находится в каталоге admin и называется cron.php. Однако он не может запускаться сам по себе, поэтому вам необходимо настроить механизм, при котором этот скрипт будет запускаться регулярно (например, каждые пять или десять минут). Это обеспечивает «пульс», чтобы сценарий мог выполнять функции в периоды времени, определенные каждым модулем. Такой обычный механизм известен как служба cron.

    Обратите внимание, что машина, выполняющая cron, не обязательно должна быть той же машиной, на которой работает Moodle. Например, если у вас есть ограниченная служба веб-хостинга, в которой нет службы cron, вы можете запустить cron на другом сервере или на своем домашнем компьютере. Важно только то, что файл cron.php вызывается регулярно.

    Нагрузка этого скрипта не очень высока, поэтому 5 минут обычно разумно, но если вас это беспокоит, вы можете сократить период времени до 15 или даже 30 минут. Лучше не делать период времени слишком длинным, так как задержка рассылок может замедлить активность в рамках курса.

    Сначала проверьте работу скрипта, запустив его прямо из браузера:

    Теперь вам нужно настроить автоматический и регулярный запуск скрипта.

    В системах Windows

    Самый простой способ — использовать этот небольшой пакет moodle-cron-for-windows.zip, который упрощает все это за счет установки небольшой службы Windows. Запустите его и забудьте об этом!

    Об услугах веб-хостинга

    На вашей веб-панели управления может быть веб-страница, на которой можно настроить этот процесс cron. Например, в системе Cpanel найдите кнопку «Задания Cron». Туда вы можете поместить те же команды Unix, что и перечисленные ниже.

    Использование командной строки в Unix

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

    Например, вы можете использовать такую ​​утилиту Unix, как wget:

    Обратите внимание, что в этом примере выходные данные удаляются (в /dev/null).

    То же самое с lynx:

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

    Использование программы crontab в Unix

    Все, что делает Cpanel, — это предоставляет веб-интерфейс утилите Unix, известной как crontab. Если у вас есть командная строка, вы можете самостоятельно настроить crontab с помощью команды:

    а затем добавить одну из приведенных выше команд, например:

    Обычно команда "crontab" переводит вас в редактор "vi". Вы входите в «режим вставки», нажимая «i», затем вводите строку, как указано выше, затем выходите из режима вставки, нажимая ESC. Вы сохраняете и выходите, набрав «: wq», или выходите без сохранения, используя «: q!» (без кавычек).

    7. Создать новый курс

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

    Выберите «Создать новый курс» на странице администратора (или по ссылкам администратора на главной странице).

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

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

    После этого курс готов к настройке и доступен по ссылке "Курсы" на главной странице.

    Дополнительную информацию о создании курсов см. в "Документации для преподавателей".

    Приятных исследований и счастливого Мудлинга!

    Если вам нравится Moodle, рассмотрите возможность сделать пожертвование, чтобы помочь нам покрыть наши расходы!

    © 2000-2012 WAO.
    Все права защищены.

    Веб-сайт также поддерживается в рамках
    неограниченного образовательного гранта от

    Отказ от ответственности
    -->

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