Перенос сервера «1С:Предприятие» с операционной системы Windows на Linux — стандартный шаг в рамках импортозамещения и оптимизации ИТ-инфраструктуры. Однако администраторы часто сталкиваются с тем, что после миграции система отказывается запускаться, выдавая критическую ошибку: «На сервере 1С:Предприятия не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!».
В этой статье мы подробно разберем, почему возникает данная проблема, как правильно диагностировать состояние лицензий и какие шаги необходимо предпринять для полного восстановления работоспособности системы, включая исправление сопутствующих ошибок в работе отчетов.
Основная причина возникновения ошибки привязки программной лицензии (с характерным текстом в логах: Ошибка программного лицензирования. Ошибка привязки программной лицензии к компьютеру: file:///var/1C/licenses/...lic После получения лицензии удалены...) кроется в самом механизме защиты «1С».
Программная лицензия «1С» жестко привязывается к ключевым аппаратным и системным параметрам компьютера. К ним относятся:
Когда мы переносим базу данных и серверную часть с Windows на Linux, меняются абсолютно все параметры операционной системы, а в случае переезда на другое «железо» или новую виртуальную машину — и аппаратные характеристики. Простое копирование файлов лицензий с расширением .lic в каталог Linux (например, в /var/1C/licenses) не сработает. Защитная система платформы мгновенно определяет, что ключевые параметры конфигурации были «удалены» или изменены, и блокирует файл лицензии.
Также важно отметить бесполезность переименования файлов лицензий вручную. Имя файла лицензии вида 6545646444.lic представляет собой уникальный временной штамп (timestamp) и не привязано к регистрационному номеру комплекта программного продукта. Файлы создаются платформой автоматически при активации.
Прежде чем приступать к активным действиям, необходимо точно определить, какая именно лицензия отсутствует — клиентская или серверная. Для этого проанализируем информацию в окне «О программе»:
Если в строке указана только клиентская лицензия (например: 8123456789, клиент 1/20, ООО Рога и Копыта), но отсутствует явное упоминание серверной лицензии (например: Сервер, 64-разрядный), это означает, что сервер «1С» работает без легальной серверной лицензии.
Важное замечание о «бесплатных» сеансах на Linux: в старых релизах платформы «1С:Предприятие 8» под Linux существовала особенность (недокументированная лазейка), позволявшая запускать сервер без лицензии для небольшого количества пользователей (до 10–12 сеансов). Начиная с современных веток платформы (8.3.21, 8.3.22, 8.3.23 и выше), эта уязвимость полностью устранена. Теперь сервер «1С» на Linux требует обязательного наличия полноценной серверной лицензии с первого же подключения.
Для корректного переноса программной лицензии на новый Linux-сервер необходимо выполнить процедуру ее **восстановления (повторной активации)** с использованием резервного пин-кода.
Рассмотрим этот процесс по шагам:
1C:Enterprise License Tools (утилита ring), если сервер работает в консольном режиме.После успешной проверки параметров сервер сформирует новый файл лицензии в каталоге /var/1C/licenses.
Если сервер «1С» на Linux развернут внутри виртуальной машины (Hyper-V, KVM, VMware, Proxmox VE), существует высокий риск повторного «слета» лицензий при динамическом изменении ресурсов хостом. Чтобы предотвратить это, выполним следующие настройки:
Если параметры виртуальной машины или аппаратного сервера часто меняются, стандартная привязка к железу становится неудобной. Рассмотрим альтернативные методы организации защиты:
Мы можем поднять отдельную небольшую виртуальную или физическую машину с фиксированными характеристиками, установить на неё службу «1С» и активировать все имеющиеся клиентские и серверные лицензии там. Основной рабочий сервер «1С» будет запрашивать лицензии у этого сервера по сети, что защитит систему от сбоев при масштабировании основного сервера.
Если у вас есть хотя бы один физический usb-ключ защиты HASP от «1С» версии 8, платформу можно настроить таким образом, чтобы программные лицензии привязывались не к параметрам материнской платы или ОС, а к уникальному ID этого HASP-ключа. В таком случае вы сможете переносить виртуальную машину с Linux на другие хосты и изменять любые ее параметры без риска аннулирования программных лицензий.
Для корректной работы ключей HASP в среде Linux необходимо правильно установить и настроить драйвер защиты (демон aksusbd). Разберем стандартные команды для установки драйвера на Debian/Ubuntu системах:
sudo apt-get update
sudo apt-get install aksusbd
sudo systemctl enable aksusbd
sudo systemctl start aksusbd
После этого проверяем статус службы с помощью команды:
systemctl status aksusbd
Часто после успешного решения проблем с лицензиями и запуска базы ЗКГУ (Зарплата и кадры государственного учреждения) или ЗУП на Linux проявляется другая проблема: при формировании сложных отчетов (например, «Полный свод начислений, удержаний и выплат») система выдает ошибку: «Не удалось сформировать отчет (пустой результат)», хотя данные в регистрах присутствуют.
Проанализируем три основные причины этой проблемы, связанные непосредственно с миграцией на Linux и PostgreSQL:
В некоторых релизах платформы (например, в ветке 8.3.22) существовал зарегистрированный баг: при использовании именно программных лицензий на клиент-серверных базах крупные и сложные отчеты, построенные на Системе компоновки данных (СКД), аварийно возвращали пустой результат. При этом на аппаратных ключах все работало отлично.
Решение: обновите платформу «1С:Предприятие» на актуальный стабильный релиз, где данная ошибка исправлена разработчиками.
В отличие от MS SQL Server под Windows, базы данных PostgreSQL на Linux крайне чувствительны к настройкам локали и кодировкам операционной системы. Если при создании базы данных в PostgreSQL локаль шаблона была настроена некорректно (не установлена русская локаль ru_RU.utf8), то сравнение строк и построение индексов по текстовым полям в запросах «1С» начинает работать непредсказуемо.
Запросы СКД перестают сопоставлять данные, что и приводит к пустым отчетам. Проверим локаль системы в консоли Linux:
locale
В выводе обязательно должны присутствовать строки LANG=ru_RU.UTF-8 и аналогичные для остальных категорий. Если локаль не настроена, ее необходимо сгенерировать:
sudo locale-gen ru_RU.UTF-8
sudo update-locale LANG=ru_RU.UTF-8
Сразу после миграции базы данных через выгрузку/загрузку файла .dt планировщик запросов PostgreSQL не имеет актуальной статистики распределения данных в таблицах. Это приводит к тому, что СУБД выбирает крайне неоптимальные планы выполнения тяжелых запросов СКД для отчетов ЗКГУ. Запросы либо завершаются по таймауту, либо возвращают пустую выборку.
Решение: сразу после загрузки базы данных в СУБД выполните регламентную очистку и сбор статистики. Запустите в консоли PostgreSQL или через утилиту pgAdmin следующую команду для вашей базы данных:
VACUUM FULL ANALYZE;
Это перестроит индексы, освободит неиспользуемое дисковое пространство и соберет актуальную статистику для планировщика, после чего отчеты в ЗКГУ будут формироваться корректно и быстро.