При администрировании инфраструктуры 1С:Предприятие системные администраторы часто сталкиваются с ситуацией, когда необходимо обновить платформу на сервере под управлением операционной системы Linux. Особенно остро эта проблема встает в унаследованных (legacy) системах, где операционная система не обновлялась годами, а бизнес-требования диктуют необходимость перехода на новые релизы 1С. В этой статье мы подробно разберем, как узнать системные требования платформы непосредственно из файлов поставки 1С, проанализируем ограничения устаревших ОС на примере CentOS 5.5 и рассмотрим наиболее жизнеспособные варианты миграции.
Распространенное мнение о том, что внутри дистрибутива платформы 1С для Linux невозможно посмотреть список поддерживаемых операционных систем, является техническим заблуждением. Действительно, вы не найдете там текстового файла с маркетинговыми названиями ОС вроде "Ubuntu 22.04" или "RedHat Enterprise Linux 9". Однако технические ограничения жестко зашиты в метаданных пакетов установки. Любая операционная система Linux определяется версиями системных библиотек, главная из которых — glibc (GNU C Library).
Поскольку дистрибутивы 1С для Linux поставляются в стандартных форматах пакетов (.deb для Debian/Ubuntu и .rpm для RedHat/CentOS/Fedora), мы можем легко извлечь требования к зависимостям еще до начала установки платформы на сервер.
Рассмотрим подробнее, как это сделать с помощью стандартных консольных утилит Linux.
Для RPM-пакетов (CentOS, RedHat, РОСА, ALT Linux):
Если мы работаем с дистрибутивом в формате RPM, мы можем использовать менеджер пакетов rpm с ключами запроса зависимостей. Для этого выполним команду:
rpm -qpR 1C_Enterprise83-common-*.rpm
Или альтернативный вариант с явным указанием ключа --requires:
rpm -q --requires -p 1C_Enterprise83-common-8.3.12-1234.x86_64.rpm
В результате выполнения этой команды утилита выведет полный список системных библиотек и их минимальных версий, необходимых для работы данного пакета. Главный маркер, на который нам нужно обратить внимание — это ветка libc.so.6, указывающая на требуемую версию библиотеки glibc (например, libc.so.6(GLIBC_2.12)(64bit)).
Для DEB-пакетов (Ubuntu, Debian, Astra Linux):
Если сервер работает под управлением Debian-подобной системы, мы можем извлечь информацию о зависимостях с помощью утилиты dpkg:
dpkg -I 1c-enterprise83-common_8.3.12-1234_amd64.deb
В выводе команды нас интересует строка Depends. В ней будут перечислены все пакеты и библиотеки с указанием условий на версии (например, libc6 (>= 2.12)), без удовлетворения которых операционная система просто заблокирует установку платформы 1С.
Для новых унифицированных установщиков (начиная с версии 8.3.20):
В современных релизах 1С поставляется в виде самораспаковывающихся файлов с расширением .run. Чтобы исследовать их содержимое, запустим установщик с ключом распаковки без фактической установки в систему:
./1c-enterprise-8.3.20.1674-installer.run --extract /tmp/1c_extracted
После этого перейдем в каталог /tmp/1c_extracted, где мы обнаружим стандартные пакеты RPM и DEB, к которым можно применить описанные выше методы анализа.
Проанализируем практический кейс: попытку обновить платформу 1С с версии 8.2 до 8.3 на сервере под управлением CentOS 5.5. Сразу отметим, что данная затея технически невыполнима напрямую. Выясним причину этого ограничения.
Операционная система CentOS 5.5 была выпущена в 2010 году. Ее системное окружение базируется на критически устаревшей библиотеке glibc 2.5. В то же время:
glibc версии не ниже 2.12.error: Failed dependencies: libc.so.6(GLIBC_2.12)(64bit) is needed.glibc на работающем сервере CentOS 5.5 — это гарантированный способ полностью уничтожить операционную систему. Библиотека glibc является ядром пользовательского пространства Linux; на нее завязаны абсолютно все системные вызовы и утилиты (включая командный интерпретатор bash и менеджер пакетов yum). Ее ручная сборка и замена приведут к состоянию "Kernel Panic" при следующей загрузке.Таким образом, запуск сервера приложений 1С:Предприятие 8.3 на CentOS 5.5 невозможен.
Существует заблуждение, транслируемое иногда даже службой технической поддержки, что "состав ОС Linux не менялся с момента появления платформы 8.3". Это утверждение в корне неверно. Платформа 1С активно развивается, и требования к окружению Linux меняются от релиза к релизу. Разберем наиболее существенные вехи этих изменений:
libwebkitgtk-3.0.so.0. В современных дистрибутивах Linux (таких как Ubuntu 22.04+, CentOS 8/9, Debian 11+) эта библиотека полностью удалена из соображений безопасности. Из-за этого старые платформы 1С невозможно штатно установить на современные ОС. Начиная с версии 8.3.20, разработчики 1С перешли на актуальную библиотеку webkit2gtk, что решило проблему совместимости с новыми дистрибутивами, но закрыло путь назад.init.d (скрипты V-style). Начиная с версии 8.3.21, платформа полностью перешла на использование современных юнит-файлов systemd. Это кардинально изменило структуру каталогов, логику запуска служб и методы логирования процессов сервера приложений.glibc не ниже 2.17, а для сопутствующих инновационных компонентов (например, технологии "1С:Элемент") планка поднята до glibc 2.31.Если перед компанией стоит задача обеспечить функционирование обновленной базы 1С 8.3 на короткий промежуток времени (например, один год) при минимальных затратах ресурсов на администрирование, рассмотрим и сравним три возможных сценария действий.
В этом варианте сервер базы данных (например, PostgreSQL) остается работать на старом сервере с CentOS 5.5, а сервер приложений 1С разворачивается на новой машине под управлением Windows. Это рабочее решение, но оно несет в себе скрытые риски совместимости версий СУБД:
Новые платформы 1С 8.3 выдвигают повышенные требования к СУБД PostgreSQL. Если на вашей старой CentOS 5.5 установлена столь же древняя версия PostgreSQL (например, 8.4 или 9.0), то современный сервер приложений 1С просто откажется подключаться к ней, выдав ошибку несовместимости версий СУБД. Обновить же PostgreSQL на CentOS 5.5 до версии 10+ практически невозможно, так как официальные репозитории для этой ОС давно перенесены в архив (vault) и новые пакеты под нее не собираются.
Попытка перевести базу данных в файловый режим и разместить ее на сетевом ресурсе Samba, развернутом на CentOS 5.5, для работы 10 пользователей — крайне опасный шаг. Рассмотрим причины, почему этого делать не стоит:
Сетевой режим работы файловой 1С через протокол SMB/CIFS под нагрузкой более 5 пользователей неизбежно приводит к сетевым коллизиям, частым блокировкам таблиц и взаимным исключениям (deadlocks). Из-за нестабильности сетевого протокола на старой версии Samba велика вероятность регулярного разрушения индексов и повреждения самой базы данных 1С (ошибки формата потока, незавершенные транзакции). В результате системный администратор будет тратить больше времени на утилиту chdbfl.exe и восстановление бэкапов, чем на первоначальную правильную настройку сервера.
В условиях жесткого дефицита времени самым дешевым и надежным решением будет полный отказ от использования CentOS 5.5 для задач 1С. Посмотрим на алгоритм реализации этого сценария:
.dt).Такой подход полностью исключает любые проблемы несовместимости системных библиотек, минимизирует время настройки до нескольких часов и гарантирует стабильную работу информационной системы на протяжении всего оставшегося года эксплуатации.