Подробный гайд по настройке cron.d в Astra Linux 1.7
Настройка планировщика заданий через каталог /etc/cron.d/ в Astra Linux 1.7 имеет свою специфику. С одной стороны, Astra Linux (как в редакции «Орёл», так и в защищённой «Смоленск») базируется на пакетной базе Debian, поэтому используется стандартный демон cron. С другой стороны, в игру вступают встроенные механизмы безопасности Astra Linux: мандатный контроль целостности (МКЦ / Parsec), замкнутая программная среда (ЗПС) и строгие политики прав доступа.
1. Фундаментальные правила /etc/cron.d/
Файлы в этом каталоге позволяют пакетам и администраторам добавлять cron-задания без редактирования главного файла /etc/crontab.
Важные правила именования и прав:
- Имя файла НЕ должно содержать точек. Файлы с расширениями (например,
backup.sh,myjob.cron) или просто с точкой в имени будут проигнорированы демоном cron.- Неправильно:
/etc/cron.d/backup_script.sh - Правильно:
/etc/cron.d/backup_script
- Неправильно:
- Владелец: Файл должен принадлежать
root(chown root:root). - Права доступа: Файл не должен быть исполняемым (
chmod -x) и не должен быть доступен для записи группе или остальным.- Рекомендуемые права:
644(chmod 644 /etc/cron.d/myjob) или600. - Если файл имеет бит исполняемости (+x) или доступен на запись не root'у, cron в целях безопасности его проигнорирует без ошибок в логах.
- Рекомендуемые права:
- Обязательный перевод строки: Файл должен заканчиваться пустой строкой (переводом каретки
\n). Без этого cron не прочитает последнюю строчку.
2. Синтаксис файла
В отличие от пользовательских crontab-файлов (где пользователь задается неявно), в /etc/cron.d/ обязательно нужно указывать пользователя, от которого будет выполняться команда.
Формат:
[Переменные окружения]
MINUTE HOUR DAY MONTH DAYOFWEEK USER COMMAND
Пример базового файла /etc/cron.d/sysadmin_tasks:
# Устанавливаем переменные окружения (обязательно укажите PATH, так как cron работает в урезанном окружении)
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO="admin@yourdomain.local"
# Каждые 15 минут запускать скрипт очистки tmp от пользователя root
*/15 * * * * root /opt/scripts/clean_tmp.sh > /dev/null 2>&1
# Каждый день в 02:00 ночи запускать бэкап от пользователя postgres
0 2 * * * postgres /usr/local/bin/db_backup.sh
3. Специфика Astra Linux 1.7 (Смоленск / Parsec)
Если вы используете Astra Linux Special Edition (Смоленск) с включенным мандатным контролем целостности (Parsec), стандартного синтаксиса может быть недостаточно из-за блокировок со стороны системы безопасности.
А. Уровни целостности и мандатные метки
Каждый файл и процесс в Astra Linux имеет уровень целостности (от 0 до 255) и категории.
- Когда cron запускает скрипт, процесс наследует уровень целостности пользователя (например,
rootобычно имеет максимальный уровень). - Если скрипт пытается прочитать файл с более высоким уровнем целостности или записать данные в файл с более высоким уровнем, операция будет заблокирована (ошибка
Permission denied, даже если выroot).
Как проверить и назначить метки:
# Посмотреть текущие метки целостности скрипта
pdpl -l /opt/scripts/backup.sh
# Назначить максимальный уровень целостности (например, 2) и все категории
pdpl 2:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 /opt/scripts/backup.sh
Совет:
Скрипты, выполняемые из /etc/cron.d/ для системных нужд, должны иметь соответствующий уровень целостности, совпадающий с уровнем данных, которые они обрабатывают.
Б. Замкнутая программная среда (ЗПС)
Если в вашей системе включена ЗПС, cron может быть заблокирован от запуска скриптов, которые находятся в "непроверенных" директориях или не имеют правильных мандатных атрибутов.
- Убедитесь, что директория со скриптами (например,
/opt/scripts/) разрешена для исполнения в политиках ЗПС. - Скрипты не должны быть доступны на запись никому, кроме владельца.
4. Отладка и Логирование в Astra Linux 1.7
В Astra Linux 1.7 логирование осуществляется через rsyslog и systemd. Если задание не выполняется, используйте следующий алгоритм поиска проблемы.
Шаг 1. Проверка статуса демона
systemctl status cron
Шаг 2. Анализ системных логов (syslog / cron)
В Astra Linux логи cron по умолчанию могут падать в /var/log/syslog или /var/log/cron (зависит от настроек rsyslog.d).
# Поиск событий cron в системном журнале
grep CRON /var/log/syslog | tail -n 50
# Или использование journalctl
journalctl -u cron --since today
Шаг 3. Анализ мандатных блокировок (Parsec)
Если скрипт падает с Permission denied или не создает файлы, проверьте логи ядра и аудита на предмет вмешательства Parsec:
# Логи ядра (часто содержат сообщения о нарушении целостности)
dmesg | grep -i parsec
dmesg | grep -i "integrity"
# Логи подсистемы аудита (если auditd настроен на отслеживание cron)
ausearch -c "cron" --start today
ausearch -m MAC_STATUS --start today
Шаг 4. Ручной тест окружения cron
Окружение cron очень "бедное". Если ваш скрипт использует специфичные утилиты (например, fly-admin, pdpl, netstat), он может их не находить.
Чтобы протестировать выполнение скрипта в окружении, максимально приближенном к cron, выполните:
env -i /bin/bash -c "cd /path/to/script/dir && ./your_script.sh"
(Флаг -i очищает все переменные окружения).
5. Частые ошибки (Troubleshooting)
| Симптом / Ошибка | Причина | Решение |
|---|---|---|
| Задание просто не выполняется (тишина) | В имени файла есть точка (напр. backup.sh). |
Переименуйте файл: mv backup.sh backup_cron |
| Задание игнорируется | Неверные права доступа. | chown root:root и chmod 644 /etc/cron.d/* |
| Команда не найдена (command not found) | Отсутствует PATH в начале файла. |
Добавьте PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin |
| Permission denied (при работе от root) | Блокировка мандатным контролем (Parsec). | Проверьте уровни целостности скрипта и целевых папок (pdpl, getfattr). |
| Скрипт не выполняется | Нет перевода строки в конце файла. | Откройте файл в nano/vim и нажмите Enter в самом конце. |
| Задание выполняется дважды | Файл скопирован с расширением .dpkg-dist или .bak, но cron его читает. |
Удалите лишние файлы из /etc/cron.d/ (cron читает всё, кроме специфичных суффиксов dpkg). |
6. Лучшие практики для администратора Astra Linux
1. Изоляция скриптов:
Храните исполняемые скрипты для cron в выделенной директории, например /usr/local/lib/cron-scripts/. Не храните их в /tmp или домашних каталогах пользователей (в Astra Linux домашние каталоги часто имеют строгие мандатные метки, которые помешают root-процессу cron их прочитать/исполнить).
2. Экранирование символов:
Символ % в cron имеет специальное значение (используется для разделения вывода и темы письма, если настроен MAILTO). Если вам нужен символ % в команде (например, в дате date +\%Y-\%m-\%d), его обязательно нужно экранировать обратным слэшем: \%.
3. Использование run-parts:
Если вам нужно выполнять множество однотипных скриптов, лучше использовать стандартные директории /etc/cron.daily, /etc/cron.hourly и т.д. В этом случае используется утилита run-parts. Но помните: run-parts в Debian/Astra также игнорирует файлы с точками в имени и требует, чтобы скрипты были исполняемыми (chmod +x).
4. Логирование самого скрипта:
Всегда перенаправляйте вывод внутри скрипта в собственный лог-файл, чтобы не зависеть от почтовой рассылки cron:
* * * * * root /opt/scripts/monitor.sh >> /var/log/monitor_cron.log 2>&1
Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.