Подробный гайд Нет отдельного файла лога с именем var log kyodialog Kyocera в Astra Linux
Проблема отсутствия отдельного файла лога /var/log/kyodialog (или /var/log/kyodialog.log) при работе с проприетарными драйверами Kyocera в Astra Linux — довольно распространенная ситуация.
Чаще всего это происходит по трем причинам:
- Драйвер не создает файл автоматически при установке, ожидая, что это сделает администратор, или скрипт пост-установки отработал с ошибкой.
- Логирование самого диалога Kyocera отключено по умолчанию, и все ошибки пишутся в общие логи CUPS.
- Специфика Astra Linux:
Мандатный контроль доступа (МКЦ/Parsec) или строгие права доступа блокируют создание файла в директории
/var/log/.
Ниже представлен подробный гайд по диагностике, созданию и настройке логирования для Kyocera в среде Astra Linux.
Шаг 1. Проверка штатных логов (Где искать ошибки на самом деле)
Прежде чем создавать файл kyodialog, убедитесь, что вы не упускаете ошибки, которые драйвер уже пишет в системные логи. Драйвер Kyocera интегрируется в CUPS, поэтому основные логи находятся там.
1. Логи CUPS:
sudo cat /var/log/cups/error_log | grep -i kyocera
sudo cat /var/log/cups/error_log | grep -i kyodialog
2. Системный журнал (journald):
sudo journalctl -u cups | grep -i kyodialog
sudo journalctl | grep -i kyocera
Если в этих логах есть ошибки, проблема может быть не в отсутствии файла, а в сетевой доступности принтера или нехватке прав.
Шаг 2. Ручное создание файла/каталога лога Kyocera
Если специфика вашей задачи или документации требует наличия именно файла /var/log/kyodialog (или директории), его нужно создать вручную и назначить правильные права.
Вариант А: Если ожидается ФАЙЛ /var/log/kyodialog
# Создаем файл
sudo touch /var/log/kyodialog
# Назначаем владельца. CUPS и его бэкенды (включая kyodialog) обычно работают от имени пользователя root или группы lp.
sudo chown root:lp /var/log/kyodialog
# Даем права на чтение и запись владельцу и группе
sudo chmod 664 /var/log/kyodialog
Вариант Б: Если ожидается ДИРЕКТОРИЯ /var/log/kyodialog/
# Создаем директорию
sudo mkdir -p /var/log/kyodialog
# Назначаем права
sudo chown root:lp /var/log/kyodialog
sudo chmod 775 /var/log/kyodialog
Шаг 3. Учет специфики Astra Linux (Мандатный контроль и Parsec)
В Astra Linux Special Edition (особенно в профилях безопасности «Орел», «Воронеж», «Смоленск») работает мандатный контроль доступа (МКЦ). Даже если вы создали файл и дали права 777, процесс kyodialog может быть заблокирован ядром.
Как проверить, блокирует ли Parsec запись в лог:
- Попробуйте напечатать тестовую страницу или вызвать ошибку.
2. Проверьте аудит ядра:
sudo dmesg | grep -i parsec
# или
sudo grep kyodialog /var/log/audit/audit.log
3. Если вы видите сообщения вроде parsec: denied или mac denied, значит, у процесса CUPS/kyodialog нет мандатной метки для записи в /var/log/.
Решение для Astra Linux:
* Временное (для теста):
Отключить мандатный контроль (требует перезагрузки или перемычки, не рекомендуется на продакшене).
Правильное:
Добавить правило в конфигурацию Parsec, разрешающее домену cups или kyodialog запись в файл /var/log/kyodialog. Либо перенаправить лог в директорию, куда у процесса уже есть мандатные права (например, /var/log/cups/).
Лайфхак: Создайте симлинк, если драйвер жестко требует путь /var/log/kyodialog:
sudo touch /var/log/cups/kyodialog.log
sudo chown root:lp /var/log/cups/kyodialog.log
sudo ln -s /var/log/cups/kyodialog.log /var/log/kyodialog
Шаг 4. Включение расширенного логирования CUPS
Если файл /var/log/kyodialog так и не заполняется, значит, сам драйвер не генерирует события. Нужно заставить CUPS логировать всё, что происходит с бэкендом Kyocera.
1. Откройте конфигурационный файл CUPS:
sudo nano /etc/cups/cupsd.conf
2. Найдите строку LogLevel и измените её на debug (или debug2 для максимальной детализации):
LogLevel debug
3. Перезапустите службу CUPS:
sudo systemctl restart cups
- Воспроизведите проблему (отправьте задание на печать).
5. Смотрите подробный лог:
tail -f /var/log/cups/error_log
Не забудьте вернуть LogLevel info после диагностики, иначе лог-файлы быстро разрастутся.
Шаг 5. Ручная диагностика бэкенда Kyocera
Чтобы понять, работает ли сам модуль kyodialog без участия CUPS, можно запустить его вручную из командной строки. Это покажет скрытые ошибки (например, отсутствие библиотек или проблемы с SNMP).
1. Найдите путь к бэкенду (обычно он здесь):
ls /usr/lib/cups/backend/ | grep kyocera
# или в новых версиях:
ls /usr/libexec/cups/backend/ | grep kyodialog
2. Запустите его от имени root (без аргументов он должен вывести список доступных принтеров):
sudo /usr/lib/cups/backend/kyodialog3 # (или kyodialog, в зависимости от версии)
- Если при запуске в терминале сыпятся ошибки (например,
error while loading shared libraries), значит, проблема в зависимостях драйвера, а не в логах.
Шаг 6. Переустановка пакета драйвера (если ничего не помогло)
Иногда при установке .deb пакета Kyocera в Astra Linux скрипт postinst не может создать лог-файл из-за прерывания процесса или нехватки прав в момент установки.
1. Переустановите пакет драйвера:
sudo apt update
sudo apt reinstall kyodialog3 # (или kyodialog, kyodialog-cups)
- Следите за выводом в терминале. Если скрипт пост-установки попытается создать
/var/log/kyodialogи у него не выйдет, вы сразу увидите ошибку в консоли.
Важно:
- В 90% случаев в Astra Linux драйвер Kyocera пишет не в
/var/log/kyodialog, а в/var/log/cups/error_log. - Если файл строго необходим, создайте его вручную (
sudo touch /var/log/kyodialog) и отдайте в группуlp(sudo chown root:lp ...). - Если Astra Linux используется в защищенном исполнении, обязательно проверьте
dmesg | grep parsec— мандатный контроль может молча блокировать запись в/var/log/. - Для глубокой диагностики включите
LogLevel debugв/etc/cups/cupsd.conf.
Информация предоставлена в ознакомительных целях. Применение описанных настроек в системах, должно осуществляться только после согласования с ответственными за информационную безопасность и в соответствии с требованиями ФСТЭК, ФСБ и иных уполномоченных органов.