Установка сервера 1С, Postgresql и терминального сервера для клиентских приложений 1С на ОС Fedora Linux
Часть 1. Установка PostgreSQL
На настоящий момент фирма 1С предоставляет возможность установки своего основного программного продукта на ОС Windows, Linux и MacOS (только клиентского приложения).
На официальном портале 1С зарегистрированный пользователь может скачать установочные наборы программ для этих операционных систем. С системами из семейства ОС Windows в данном случае есть достаточно большая ясность, они поддерживаются хорошо, так как имеют наибольшее распространение среди пользователей.
Однако, сама фирма 1С в своей документации и справочных материалах довольно прозрачно намекает, что ОС Windows далеко не единственный вариант установки ПО, в особенности серверной части и что ОС Linux гораздо более предпочтительна в качестве серверной ОС.
На портале 1С мы можем найти разные наборы установочных пакетов для 64-битных и 32-битных систем, для систем из семейства Linux, основанных на deb-пакетах (для системы Debian и её производных — Ubuntu, Mint и других) и основанных на rpm-пакетах (для ОС RedHat и её производных — CentOS, Suse, Fedora и других).
Но при более тщательном изучении документации, можно столкнуться со следующим интересным моментом.
Для того, чтобы установить систему 1С в клиент-серверном варианте, требуется установка не только самого сервера 1С, но и сервера СУБД. Начнём установку именно с этого, так как без работоспособной базы данных устанавливать сервер 1С не имеет смысла.
Вариантов для выбора СУБД весьма немного. Система 1С может работать всего лишь с 4-мя различными СУБД: Microsoft SQL Server, PostgreSQL, IBM DB2 и Oracle Database. Все эти СУБД могут быть установлены на Linux, однако в полноценном варианте Microsoft SQL Server, IBM DB2 и Oracle Database являются платными коммерческими продуктами с немалой стоимостью. А на настоящий момент все эти три корпорации с РФ не работают (Microsoft, IBM, Oracle). У PostgreSQL тоже есть платная версия, но той версии, которая распространяется как свободный и открытый программный продукт, вполне достаточно для работы с сервером 1С. Поэтому при использовании свободной ОС Linux выбор в первую очередь, конечно, падает на PostgreSQL.
Но здесь есть некоторые нюансы. Фирма 1С достаточно серьёзно переработала и пропатчила эту СУБД под свою систему, поэтому использовать оригинальную версию PostgreSQL сервера не получится. Как минимум, в эту СУБД был добавлен тип данных mchar, которого нет в оригинальной версии. И при попытке создать базу данных 1С на непропатченном PostgreSQL мы получим ошибку об отсутствии типа данных mchar.
На портале 1С выложена для скачивания специальная уже пропатченная версия этого сервера. Однако здесь также есть некоторые подводные камни. В документации к этой версии мы читаем про совместимость с ОС.
»Cписок поддерживаемых дистрибутивов:
Windows 7, 8, 10
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2016
Fedora Core 30.1.2
Debian 9
Debian 10
Red Hat Enterprise Linux 7
Centos 7
Ubuntu 18.04
Ubuntu 20.04
Astra Linux Special Edition «Смоленск» 1.6
Astra Linux Special Edition «Смоленск» 1.7
Astra Linux Common Edition «Орел» 2.12»
Как мы видим, список поддерживаемых версий ОС Linux довольно ограничен. В отношении ОС Fedora указан устаревший уже на настоящий момент дистрибутив версии 30 (на момент написания этой статьи текущая версия 36). И вообще, слово «Core» из названия Fedora было убрано уже много лет назад. Что даёт нам понять, что разработчики 1С не особо следят за развитием этого дистрибутива. А когда мы открываем скачанный архив rpm-пакетов (если мы хотим поставить сервер на ОС Fedora), то и вовсе оказывается, что там лежат пакеты для Red Hat Enterprise Linux 7-й версии.
Конечно, при определённых манипуляциях, эти пакеты можно поставить на Fedora 36, но добиться работоспособности от установленного таким образом сервера PostgreSQL автору так и не удалось.
Можно задаться вопросом, зачем нам в принципе ставить 1С на Fedora, если она особо не поддерживается, вместо того, чтобы взять «надёжную» Ubuntu или устаревший CentOS. И, вообще, бытует мнение, что Fedora может содержать в себе много багов, так как является экспериментальным дистрибутивом от RedHat, в котором используется самое новое и непроверенное временем ПО, и использовать её на серьёзных производственных серверах категорически не рекомендуется.
Однако опыт многолетнего использования этого дистрибутива в действительности показал обратное. Дистрибутив, на самом деле, во многом весьма прогрессивен, но в то же время довольно стабилен в своей работе. Какие-то явные недоработки проявляются в нём крайне редко и сравнительно быстро исправляются. Перед очередным релизом дистрибутивы проходят массу проверок и тестирований. Говорить, что Fedora — это сырой и непроверенный дистрибутив, можно только никогда по-серьёзному им не пользуясь.
Поэтому автор рассматривает вариант запуска сервера 1С именно на этом дистрибутиве и эта статья посвящена именно этому.
Итак, с официального портала мы не имеем установочных пакетов для Fedora. Но на портале выложена эта СУБД и патчи к ней в виде архива исходных кодов. Вот с этими файлами мы и будем работать.
Скачиваем архив, который называется Патч СУБД PostgreSQL (tar.bz2) (или .zip, это не имеет значения). В нашем примере это будет файл Patch_SUBD_PostgreSQL_14.4_1.1C.tar.bz2. То есть, у нас должен в итоге установиться пропатченный сервер PostgreSQL версии 14.4.
Внутри этого архива мы обнаруживаем несколько файлов:
00001–1C-FULL.patch
postgresql-14_14.4–1.1C.dsc
postgresql-14_14.4–1.1C_source.changes
postgresql14–1c-14.4–1.el7.src.rpm
postgresql-14_14.4–1.1C.debian.tar.xz
postgresql-14_14.4–1.1C_source.buildinfo
postgresql-14_14.4.orig.tar.bz2
На том же самом портале 1С можно найти статью, описывающую порядок установки патча из исходных кодов, в настоящий момент она располагается на портале по адресу https://its.1c.ru/db/metod8dev/content/5942/hdoc и называется »Методика сборки дистрибутива СУБД PostgreSQL 9.6 c патчами для работы с 1С: Предприятие».
Как мы видим из названия, статья описывает сборку PostgreSQL версии 9.6, а последняя выложенная версия на текущий момент 14.4. То есть, статья несколько устарела, но всё ещё может использоваться как отправная точка. Идём в раздел »Сборка для RPM на примере CentOS 7×86_64» и адаптируем предложенный алгоритм к современной версии дистрибутива Fedora (Fedora 36).
Конечно, все команды установки пакетов и других административных действий требуют права root. Поэтому эти команды должны даваться либо напрямую из-под учётной записи root, либо от пользователя, обладающего такими правами, используя команду sudo. Далее для упрощения все команды будут написаны без sudo, в варианте работы сразу в учётной записи root.
Итак, чтобы собрать PostgreSQL на Fedora 36, выполняем следующие действия.
dnf install rpmdevtools
rpmdev-setuptree
Как и написано в статье на портале,»данная команда создаст каталог rpmbuild и подкаталоги BUILD, BUILDROOT, RPMS, SOURCES, SPECS, SRPMS с расположением «по умолчанию» в домашнем каталоге пользователя». В нашем упрощённом случае, домашним каталогом будет каталог /root
Естественно, для компиляции исходного кода в системе должен быть установлен компилятор. Если его нет, то нужно предварительно его установить:
dnf install gcc
Далее, по инструкции, готовим исходный пакет. Из вышеуказанного архива берём файл postgresql14–1c-14.4–1.el7.src.rpm и помещаем в его в заранее созданный для этого каталог, например, как предлагается в инструкции, ~/Postgres/Rpm.
Забегая немного вперёд, можно сказать, что для сборки PostgreSQL потребуется наличие ещё некоторых пакетов, поэтому можно установить их уже сейчас.
dnf install bison clang-devel e2fsprogs-devel flex krb5-devel libicu-devel libselinux-devel libuuid-devel libxml2-devel libxslt-devel llvm-devel lz4-devel openldap-devel openssl-devel pam-devel perl perl-ExtUtils-Embed perl-IPC-Run perl-generators python3-devel readline-devel systemd-devel tcl-devel
Также в списке зависимостей для PostgreSQL есть ещё один пакет — pgdg-srpm-macros, но в федоровских репозиториях его нет. Взять его можно непосредственно с ftp-сервера проекта postgresql, но там есть только пакет с исходным кодом (src). В настоящий момент, для ОС Fedora 36 это можно сделать по адресу https://ftp.postgresql.org/pub/repos/yum/srpms/common/fedora/fedora-36-x86_64/, скачиваем оттуда файл pgdg-srpm-macros-1.0.24–1.f36.src.rpm.
Устанавливаем скачанный пакет. Это можно сделать, например, открыв его через MidnightCommander, если мы войдём в этот файл через mc, то он раскроется как архив, в котором мы найдём файл INSTALL, который можно также запустить здесь же, через mc.
После установки в созданном ранее командой rpmdev-setuptree каталоге ~/rpmbuild/SPECS появится файл pgdg-srpm-macros.spec, который можно собрать командой
rpmbuild -ba pgdg-srpm-macros.spec
(Перед выполнением команды мы либо перемещаемся в каталог SPECS, либо указываем полный путь к файлу в команде. Это будет справедливо и ко всем последующим подобным командам.)
В результате выполнения этой команды, в каталоге ~/rpmbuild/RPMS/noarch появится готовый бинарный пакет pgdg-srpm-macros-1.0.24–1.fc36.noarch.rpm, который теперь можно установить командой
dnf install pgdg-srpm-macros-1.0.24–1.fc36.noarch.rpm
Вот теперь у нас удовлетворены все зависимости для сборки PostgreSQL и можно вернуться к этой сборке.
Перемещаемся в каталог с src-пакетом:
cd ~/Postgres/Rpm
И распаковываем его для дальнейшей компиляции:
rpm2cpio postgresql14–1c-14.4–1.el7.src.rpm | cpio --extract --make-directories
Как написано в статье на портале,»в результате в каталоге ~/Postgres/Rpm будет находиться архив с оригинальными исходниками postgresq-9.6.3.tar.bz2, патчи (.patch), прочие источники для формирования rpm-пакета и файл postgresql-9.6.3.spec — «главный» конфигурационный файл, инструкция для сборки. В нём указывается информация об исходных файлах (Source), патчах (Patch) и зависимостях сборки (BuildRequires и Requires). Необходимо убедиться, что все файлы, перечисленные в разделе Source, присутствуют в каталоге ~/Postgres/Rpm, переместим их с помощью команды mv в каталог ~/rpmbuild/SOURCES.»
Написано всё правильно, только в нашем случае это будут файлы postgresql-14.4.tar.bz2 и postgresql-14.spec.
Все распакованные файлы (кроме postgresql-14.spec) мы перемещаем или копируем, как там и написано, в ~/rpmbuild/SOURCES, включая и файл postgresql-14-A4.pdf. Файл postgresql-14.spec помещаем в ~/rpmbuild/SPECS
Теперь можно запускать процесс компиляции. В статье на портале предлагают сделать это командой rpmbuild -ba, а затем »информация о ходе сборки будет выводиться на экран. После её завершения автоматически запустятся регрессионные тесты сформированных пакетов, статус их выполнения также будет выведен. В случае ошибки сборка будет прекращена. В случае успешного её завершения бинарные rpm-пакеты будут находиться в директории ~/rpmbuild/RPMS, пакет postgresql96–9.6.3–1.1C.src.rpm — в ~/rpmbuild/SRPMS».
Особенно «радует» здесь фраза »в случае ошибки сборка будет прекращена». То есть разработчики сами не уверены в успехе этого предприятия.
Основываясь на практическом опыте, можно сказать, что действительно при компиляции вываливается несколько некритичных ошибок, а затем компилятор спотыкается на моменте указания нестандартного пути к библиотекам postgres, которые будут располагаться в /usr/pgsql-14/lib, а не в стандартных каталогах ОС. И, таким образом, просто так предлагаемая команда компиляции действительно не сработает.
Чтобы компилятор не обращал внимания на пути, нужно запускать процесс компиляции следующим образом:
export QA_SKIP_RPATHS=1; rpmbuild -ba postgresql-14.spec
По завершении процесса компиляции в каталоге ~/rpmbuild/RPMS/x86_64 появятся собранные пакеты:
postgresql14–1c-14.4–1.fc36.x86_64.rpm
postgresql14–1c-contrib-14.4–1.fc36.x86_64.rpm
postgresql14–1c-contrib-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-debugsource-14.4–1.fc36.x86_64.rpm
postgresql14–1c-devel-14.4–1.fc36.x86_64.rpm
postgresql14–1c-devel-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-docs-14.4–1.fc36.x86_64.rpm
postgresql14–1c-libs-14.4–1.fc36.x86_64.rpm
postgresql14–1c-libs-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-llvmjit-14.4–1.fc36.x86_64.rpm
postgresql14–1c-llvmjit-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plperl-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plperl-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plpython3–14.4–1.fc36.x86_64.rpm
postgresql14–1c-plpython3-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-pltcl-14.4–1.fc36.x86_64.rpm
postgresql14–1c-pltcl-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-server-14.4–1.fc36.x86_64.rpm
postgresql14–1c-server-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-test-14.4–1.fc36.x86_64.rpm
postgresql14–1c-test-debuginfo-14.4–1.fc36.x86_64.rpm
Теперь все эти пакеты можно установить. У пакетов есть определённые зависимости друг от друга, поэтому устанавливать надо в такой последовательности:
dnf install postgresql14–1c-libs-14.4–1.fc36.x86_64.rpm
postgresql14–1c-14.4–1.fc36.x86_64.rpm
postgresql14–1c-server-14.4–1.fc36.x86_64.rpm
postgresql14–1c-contrib-14.4–1.fc36.x86_64.rpm
postgresql14–1c-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-debugsource-14.4–1.fc36.x86_64.rpm
postgresql14–1c-devel-14.4–1.fc36.x86_64.rpm
postgresql14–1c-docs-14.4–1.fc36.x86_64.rpm
postgresql14–1c-llvmjit-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plperl-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plpython3–14.4–1.fc36.x86_64.rpm
postgresql14–1c-pltcl-14.4–1.fc36.x86_64.rpm
postgresql14–1c-test-14.4–1.fc36.x86_64.rpm
postgresql14–1c-contrib-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-devel-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-libs-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-llvmjit-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plperl-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-plpython3-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-pltcl-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-server-debuginfo-14.4–1.fc36.x86_64.rpm
postgresql14–1c-test-debuginfo-14.4–1.fc36.x86_64.rpm
После установки всех этих пакетов в нашей ОС появится служба postgresql-14.service, которая запускается и останавливается через команду systemctl.
Перед запуском службы нужно инициализировать базу данных и создать каталоги для неё, это можно сделать командой (если не нужно менять стандартное расположение баз)
postgresql-14-setup initdb
Затем сервис должен запуститься без ошибок:
systemctl start postgresql-14
На этом процесс установки PostgreSQL сервера заканчивается. Можно переходить к его настройке и последующей установке собственно сервера 1С.
Часть 2. Настройка PostgreSQL
В предыдущей части мы полностью установили PostgreSQL-сервер. Теперь его надо настроить, чтобы с ним мог взаимодействовать сервер 1С.
Перед запуском службы postgresql-14 мы инициировали базу данных. По умолчанию базы данных располагаются в каталоге /var/lib/pgsql/14/data
Если нам хочется расположить файлы базы данных в каком-то своём каталоге, а не в каталоге по-умолчанию, то это можно сделать следующим образом.
Путь к базам PostgreSQL хранится в переменной PGDATA. Эта переменная устанавливается при запуске службы postgresql-14.
Чтобы поменять её значение нужно отредактировать 2 файла:
/var/lib/pgsql/.bash_profile в строчке PGDATA= пишем новый путь к базам
и
/usr/lib/systemd/system/postgresql-14.service
в разделе [Service]
Environment=PGDATA=новый путь
Важное примечание. Здесь может возникнуть проблема с системой безопасности Selinux. Она не разрешает просто так менять эти значения. Нужно либо настроить Selinux, чтобы он не мешал, либо вообще отключить. Это же относится и к демону firewalld, который является прослойкой к iptables. Было замечено, что даже с настройками по-умолчанию, когда всё разрешено, firewalld может препятствовать каким-то действиям. В практике встречалось, например, что не печатает сетевой принтер, хотя никаких блокировок в firewalld не прописывалось.
Данная статья не затрагивает вопросы безопасности, поэтому для простоты будем считать что Selinux и firewalld отключены.
Прежде чем делать следующие действия нужно убедиться, что альтернативный каталог для базы существует и принадлежит пользователю postgres и группе postgres.
Далее можно инициализировать базу данных, либо командой postgresql-14-setup initdb, либо, если нужно указывать ещё какие-то опции, например, кодировку, то можно так:
из-под учётной записи root временно станем пользователем postgres
su -l postgres
запустим инициализацию базы данных с указанием каталога и кодировки, например
/usr/pgsql-14/bin/initdb -D /нужный/нам/каталог --locale=ru_RU.UTF-8 -E UTF8
при выполнении этой команды вы увидите примерно такие сообщения:
»Файлы, относящиеся к этой СУБД, будут принадлежать пользователю «postgres».
От его имени также будет запускаться процесс сервера.
Кластер баз данных будет инициализирован с локалью «ru_RU.UTF-8».
Выбрана конфигурация текстового поиска по умолчанию «russian».
Контроль целостности страниц данных отключён.
исправление прав для существующего каталога /альтернативный_путь/pgsql/14/data… ок
создание подкаталогов… ок
выбирается реализация динамической разделяемой памяти… posix
выбирается значение max_connections по умолчанию… 100
выбирается значение shared_buffers по умолчанию… 128MB
выбирается часовой пояс по умолчанию… Europe/Moscow
создание конфигурационных файлов… ок
выполняется подготовительный скрипт… ок
выполняется заключительная инициализация… ок
сохранение данных на диске… ок
initdb: предупреждение: включение метода аутентификации «trust» для локальных подключений
Другой метод можно выбрать, отредактировав pg_hba.conf или используя ключи -A,
--auth-local или --auth-host при следующем выполнении initdb.
Готово. Теперь вы можете запустить сервер баз данных:
/usr/pgsql-14/bin/pg_ctl -D /альтернативный_путь/pgsql/14/data -l файл_журнала start»
Возвращаемся в пользователя root:
exit
Командой »/usr/pgsql-14/bin/pg_ctl -D /альтернативный_путь/pgsql/14/data -l файл_журнала start» запускать сервис необязательно.
Попробуем сделать это системными средствами:
systemctl start postgresql-14
Если мы всё сделали правильно, то сервис должен запуститься без ошибок. Проверяем:
systemctl status postgresql-14
Статус демона должен быть active (running).
Но на этом настройка не закончена. Для того, чтобы сервер PostgreSQL мог обслуживать сервер 1С, нужно сделать ещё некоторые действия.
Есть 2 конфигурационных файла: postgresql.conf и pg_hba.conf. По-умолчанию они лежат в /var/lib/pgsql/14/data, либо в том каталоге, где мы только что создали кластер базы данных.
В файле postgresql.conf следует обратить внимание на строчку listen_addresses=.
Там должны быть прописаны либо конкретные адреса, либо стоять звёздочка, если мы разрешаем доступ с любых хостов.
Стандартный порт, который слушает PostgreSQL — 5432, можно проверить, что это действительно так:
netstat -ant | grep 5432
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN
tcp6 0 0::1:5432:::* LISTEN
Помимо этого, ограничение на подключение еще настраивается в файле pg_hba.conf. Данный файл содержит строки в таком формате:
local база пользователь метод-аутентификации [параметры-аутентификации]
host база пользователь адрес метод-аутентификации [параметры-аутентификации]
Строка с local задает правила для подключений по локальным UNIX-сокетам. Строка с host — подключения по TCP/IP.
»# TYPE DATABASE USER ADDRESS METHOD
# «local» is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all::1/128 trust»
Далее необходимо произвести тонкую настройку сервера. Необходимо подобрать настройки, исходя из параметров своего оборудования. Расчёт необходимо осуществить на основании рекомендаций фирмы »1С», изложенных здесь https://its.1c.ru/db/metod8dev/content/5866/hdoc. Существуют и другие ресурсы с рекомендациями и описаниями всех параметров.
Идём в пользователя postgres:
su -l postgres
Открываем командную строку сервера PostgreSQL:
psql
Приглашение командной строки будет выглядеть так: postgres=#
Посмотреть текущие значения параметров можно или так: SHOW ALL; Это будут все параметры сразу. Или так: SHOW имя параметра; Например, SHOW shared_buffers;
Изменить параметры можно командой:
ALTER SYSTEM SET параметр = 'значение';
Например:
ALTER SYSTEM SET shared_buffers = '16GB';
Выход из оболочки сервера \q
Выход из пользователя postgres
exit
Часть параметров применяется только после перезапуска сервера PostgreSQL.
systemctl restart postgresql-14
Все эти параметры зависят от аппаратной конфигурации сервера и предполагаемой нагрузки. Чем лучше они будут настроены, тем эффективнее будет работать сервер.
Опции, которые были заданы подобным образом, будут записаны в файле postgresql.auto.conf в каталоге с базами и остальными конфигами.
Следующее действие — это создать отдельного пользователя на сервере базы данных для управления базами. Снова становимся пользователем postgres и открываем консоль сервера:
su -l postgres
psql
create user pg1cv8 with superuser;
alter user pg1cv8 password 'password';
\q
exit
systemctl restart postgresql-14
Включим автозапуск PostgreSQL при старте системы:
systemctl enable postgresql-14
Часть 3. Установка сервера 1С и драйвера USB-ключа
Мы установили и произвели первичную настройку сервера баз данных PostgreSQL, теперь можно устанавливать собственно сервер 1С.
Программа 1С требует наличия лицензий. Для запуска серверной части нужна серверная лицензия, для клиентской — клиентская. Лицензии бывают аппаратные, зашитые на USB-токен, и электронные, которые активируются через ввод ПИН-кода при первом запуске программы.
Если у нас аппаратная лицензия на USB-токене, то нужно установить драйвер HASP.
Драйвер этот выпускает компания Etersoft. Эта же компания выпускает свою платную версию WINE, адаптированную к запуску windows-версии 1С на Linux и других специфических программ, типа Консультант Плюс, Гарант и т. д.
Готовые файлы находятся здесь: https://download.etersoft.ru/pub/Etersoft/HASP/ Но, судя по текущему состоянию этого ресурса, разработка этого драйвера не является приоритетной задачей, особенно для ОС Fedora. Последняя версия драйвера — 8.23 от сентября 2021 года. Для Федоры пакета не наблюдается. Есть пакет для CentOS.
Последняя версия драйвера, выложенного для Федоры — 7.90 от 12 июля 2019 года. Находится она здесь https://download.etersoft.ru/pub/Etersoft/HASP/7.90/x86_64/Fedora/27/, пакет для Fedora 27.
Мы будем использовать его, за неимением лучшего. Скачиваем, устанавливаем.
dnf install haspd-7.90-eter2fedora.x86_64.rpm
dnf install haspd-modules-7.90-eter2fedora.x86_64.rpm
После установки служба просто так почему-то не появляется, нужно перезапустить систему, тогда мы обнаруживаем, что уже запущена служба haspd.
systemctl status haspd
Теперь можно заняться установкой сервера 1С. Идём на портал 1С и скачиваем оттуда технологическую платформу 8.3
Последняя версия на настоящий момент — 8.3.21.1393 от 19.07.2022 г. Когда мы заходим в этот раздел на портале, там будет очень много разных вариантов для скачивания, нас интересует Технологическая платформа 1С: Предприятия (64-bit) для Linux. Должен скачаться файл server64_8_3_21_1393.tar.gz. Распаковываем его. Обнаруживаем там 3 файла:
LibericaJDK-8–9–10-licenses.pdf
Liberica-Notice.txt
setup-full-8.3.21.1393-x86_64.run
Запускаем файл setup-full-8.3.21.1393-x86_64.run. Это файл-инсталлятор 1С. До недавнего времени 1С ставилась путём установки нескольких пакетов. Сейчас разработчики1С свели этот процесс к запуску графического инсталлятора, аналогичного тому, кому, который запускается на Windows. Поэтому после запуска мы будем видеть графические окошки и кнопки «далее».
После выбора нужных компонентов, нажимаем кнопку «далее» и получаем следующее сообщение:
»Не удалось установить пакеты, требуемые для работы. Чтобы установка платформы »1С: Предприятие» завершилась успешно, необходимо самостоятельно установить отсутствующие пакеты с помощью пакетного менеджера операционной системы и заново запустить установку платформы. Отсутствующие пакеты приведены ниже и их можно скопировать в буфер обмена:
libgtk-3–0 libenchant1c2a libharfbuzz-icu0 libgstreamer1.0–0 libgstreamer-plugins-base1.0–0 gstreamer1.0-plugins-good gstreamer1.0-plugins-bad libsecret-1–0 libsoup2.4–1 libsqlite3–0 libgl1 libegl1 libxrender1 libxfixes3 libxslt1.1 geoclue-2.0»
Пока игнорируем и нажимаем «ОК». Процесс инсталляции продолжится и вполне успешно дойдёт до конца.
Если мы попытаемся установить вышеобозначенные пакеты, то пакетный менеджер скажет нам, что таких пакетов нет. И на данном этапе не совсем понятно, действительно ли нужны эти пакеты, так как система запустится и без них.
Правда, чтобы программа 1С запустилась, нужно сделать ещё кое-что. Сначала запустим сервер 1С. Программа 1С установилась в каталог /opt/1cv8. Заходим туда, в каталог x86_64 и далее в каталог 8.3.21.1393. Там мы увидим знакомые файлы программы 1С. Для запуска сервера нужен файл ragent. Это исполняемый файл агента сервера. Запускается он с рядом опций, либо в режиме демона, либо нет.
Пробуем запустить (пока без демона):
./ragent -port 1540 -regport 1541 -range 1560:1591
Получаем ответ:
1C: Enterprise 8.3 (x86–64) (8.3.21.1393) Server Agent started. Ctrl+C to exit.
1C: Enterprise 8.3 (x86–64) (8.3.21.1393) Server Agent finished.
То есть сервер запускается и тут же падает. Оказывается, чтобы этот агент работал, нужно, чтобы в файле /etc/hosts был прописан наш ip-адрес и имя хоста, не localhost, а именно настоящий ip-адрес и конкретное имя хоста. Прописываем эти данные, запускаем заново:
./ragent -port 1540 -regport 1541 -range 1560:1591
Ответ:
1C: Enterprise 8.3 (x86–64) (8.3.21.1393) Server Agent started. Ctrl+C to exit.
1C: Enterprise 8.3 (x86–64) (8.3.21.1393) Working Process started. Ctrl+C to exit.
Опыт установки более поздней версии 1С показал, что может быть и такой ответ:
1C: Enterprise 8.3 (x86–64) (8.3.22.1603) Server Agent started. Ctrl+C to exit.
1C: Enterprise 8.3 (x86–64) (8.3.22.1603) Cluster Manager started. Ctrl+C to exit.
1C: Enterprise 8.3 (x86–64) (8.3.22.1603) Working Process started. Ctrl+C to exit.
Получилось. Сервер 1С запущен и не падает. Как служба он нигде не прописался. Можно, конечно, задаться целью и сделать это самостоятельно. Пока нам это не нужно так сильно, поэтому можно сделать по-простому — записать запуск сервиса в файл /etc/rc.d/rc.local. В режиме демона нужно добавить опцию -daemon.
Теперь, когда все серверы установлены и запущены, можно попробовать запустить клиентскую программу и создать базу данных. Программная оболочка запускается файлом /opt/1cv8/common/1cestart. Или через графическое меню нашей графической среды, которую мы выбрали для установки на сервер (KDE, GNOME, MATE, XFCE, LDXE и т. д.), в разделе «офис». Запускать надо уже не от root, а от обычного пользователя. Однако, и здесь есть подводные камни. Просто так она не запустится. При попытке запустить этот файл в консоли мы увидим сообщение:
./1cestart: /opt/1cv8/common/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /lib64/libicuuc.so.69)
Удивительно, но эта ошибка исправляется так: из каталогов /opt/1cv8/common и /opt/1cv8/x86_64/8.3.21.1393 удаляется файл libstdc++.so.6.
Это системная библиотека и она уже есть в нашей системе в системных каталогах. Зачем она здесь продублирована, неизвестно, но это мешает работе программы. После удаления программа чудесным образом запустится и скажет, что список баз пуст и предложит добавить базу.
Это так, если запускать через консоль. Если через графическое меню, то тут тоже требуется некоторая доработка. В меню появилось несколько значков:
1С: Предприятие 64
1С: Предприятие 64 (8.3.21.1393)
1С: Предприятие — Толстый клиент 64 (8.3.21.1393)
1С: Предприятие — Тонкий клиент 64 (8.3.21.1393)
И значок »1С: Предприятие 64» не работает, так как почему-то ссылается на несуществующий файл /opt/1cv8/x86_64/8.3.21.1393/1cestart, хотя должен был ссылаться на /opt/1cv8/common/1cestart.
Давайте исправим эту недоработку, отредактируем файл /usr/share/applications/1cestart-8.3.21–1393.desktop. В строчке Exec= нужно исправить путь к исполняемому файлу.
Вот теперь программа действительно запускается из пользовательского меню. И лучше всего запускать именно этот значок, так как остальные запускаются довольно долго и создаётся впечатление, что ничего не происходит.
Позже эта ошибка со значками запуска была исправлена фирмой 1С и, например, в версии 8.3.22.1603 все значки работают сразу без дополнительных манипуляций.
Теперь можно попытаться создать базу данных 1С через программу 1С на нашем сервере баз данных PostgreSQL.
Запускаем программу, нажимаем «Да», выбираем «создание новой информационной базы». Пока у нас не установлено никаких шаблонов, выбираем создание без конфигурации. И выбираем создание базы на сервере 1С: Предприятие. Зададим, для начала, такие параметры:
Кластер серверов 1С: Предприятие ip-адрес нашего сервера
Имя информационной базы в кластере любое имя, например test1
Защищённое соединение Выключено
Тип СУБД PostgreSQL
Сервер баз данных 127.0.0.1
Имя базы данных test1
Пользователь базы данных тот, которого мы создавали во 2 части, pg1cv8
Пароль пользователя заданный во 2 части пароль пользователя pg1cv8
Смещение дат 0
Если мы всё сделали правильно, то база данных создастся и попадёт в список баз, теперь можно открыть её конфигуратором или пользовательской оболочкой.
На этом этапе возникнет вопрос с лицензией. Если лицензия электронная, то здесь нужно будет вводить электронный ключ. Также нужно учесть, что для запуска клиентского приложения понадобится не только серверный ключ, но и клиентский. Если это USB-ключи, то в сервер должно быть вставлено оба ключа.
Всё, сервер 1С установлен, произведено его соединение с сервером баз данных и получено работающее клиентское приложение. Далее можно загружать дампы баз или создавать новые из шаблонов. Или делать собственные конфигурации.
Следующий шаг — настройка терминального доступа к серверу, чтобы удалённые клиенты могли подключаться к нашему серверу и запускать там удалённый рабочий стол также, как они это привыкли делать при работе с ОС Windows по протоколу RDP.
Часть 4. Терминальный сервер
Наиболее известным терминальным сервером является сервер на ОС Windows по протоколу RDP. У нас стоит задача сделать нечто подобное, не прибегая к программным продуктам Microsoft, а используя исключительно свободное ПО.
Есть несколько разных вариантов, как можно организовать систему с удалёнными рабочими столами. Это может быть: удалённое подключение к X-серверу (особенно для клиентов на Линуксе), запуск графических приложений или целиком рабочего стола через ssh, подключение по протоколу VNC (Virtual Network Computing), смешанный вариант (инициализация и расшаривание ресурсов по ssh плюс рабочий стол по vnc). В зависимости от ситуации и условий подключения клиентов можно применять разные варианты на одном и том же сервере.
Удалённое подключение к X-серверу мы здесь рассматривать не будем, так как это не самый оптимальный вариант, весьма чувствительный к сетевой нагрузке.
Начнём с сервера vnc без всякого использования ssh. Данный вариант вполне успешно можно использовать для клиентов на разных ОС.
Установим необходимый пакет:
dnf install tigervnc-server
Стоит отметить, что запуск службы vnc-server настраивается отдельно для каждого пользователя, которому будет нужен удалённый рабочий стол.
Чтобы настроить сервис для какого-либо пользователя нужно проделать следующие действия:
su имя_пользователя (если мы работаем под пользователем root, либо просто залогиниваемся нужным пользователем и открываем командную строку)
vncpasswd
При этом будет задан вопрос, делать ли пароль на режим «только просмотр», для наших целей это не нужно, на этот вопрос следует ответить отрицательно.
Пароль следует запомнить или записать, так как его нужно будет выдать конечному пользователю.
Также пароль в кодированном виде сохранится в домашнем каталоге пользователя в файле ~/.vnc/passwd. Этот файл можно использовать для подключения к удалённому экрану вместо словесного пароля (например, если подключение делается через командную строку).
В этом же каталоге находится файл config, содержащий конкретные настройки для этого пользователя, например, разрешение экрана, которое будет включаться по-умолчанию. При необходимости, этот файл нужно будет отредактировать под этого пользователя.
При этом файл нужно переименовать, добавив имя пользователя, например vncserver-vasya@.service
В интернете можно найти не одно описание того, как это делать. И там можно прочитать, что этот файл надо отредактировать, вписав туда имя конкретного пользователя.
Однако, на настоящий момент, никаких правок в этом файле делать не надо. Содержимое файла должно быть таким:
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
ExecStartPre=+/usr/libexec/vncsession-restore %i
ExecStart=/usr/libexec/vncsession-start %i
PIDFile=/run/vncsession-%i.pid
SELinuxContext=system_u: system_r: vnc_session_t: s0
[Install]
WantedBy=multi-user.target
Далее нужно задать номер дисплея, на котором будет запускаться удалённый сеанс.
дописываем туда номер дисплея и имя пользователя
:1=vasya
Для следующего пользователя:
:2=fedya
Помимо того, что это будет номер дисплея, назначенный этому пользователю, это также будет смещением для номера порта, на котором будет запускаться vnc-сервер для данного пользователя. По-умолчанию, в единичном экземпляре, vnc-сервер запускается на порту 5900. Но если нужно запускать несколько сеансов (тем более, одновременно), нужно несколько портов для этого. Поэтому здесь номер дисплея будет смещением для номера порта. То есть для пользователя vasya сервер будет запущен на порту 5901, для пользователя fedya — на порту 5902. И так далее.
Настройка отдельного пользователя на этом заканчивается. Для проверки можно запустить vnc-сервер для нашего пользователя:
systemctl start vncserver-vasya@:1.service
Обратите внимание, что перед словом service также указывается номер дисплея.
Если всё сделано правильно, то сервер запустится. Можно проверить статус службы:
systemctl status vncserver-vasya@:1.service
Или посмотреть системные процессы:
ps -eF | grep vnc
Должен быть примерно такой процесс:
vasya 61134 61124 15 44729 75460 9 13:01? 00:00:16 /usr/bin/Xvnc:1 -geometry 1280×1024 -auth /home/vasya/.Xauthority -desktop localhost:1 (vasya) -fp catalogue:/etc/X11/fontpath.d -pn -rfbauth /home/vasya/.vnc/passwd -rfbport 5901
Чтобы подключиться к этому сеансу со стороны клиента нужно запустить любую программу-просмотровщик vnc, например tiger vnc viewer.
Указываем там путь к серверу и порт — сервер: порт. Далее нужно будет ввести созданный ранее пароль.
Ещё раз скажем, что данная статья не з
