Часть 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 x86_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, либо просто залогиниваемся нужным пользователем и открываем командную строку)

• Задаём пароль vnc для этого пользователя:

vncpasswd

При этом будет задан вопрос, делать ли пароль на режим «только просмотр», для наших целей это не нужно, на этот вопрос следует ответить отрицательно.

Пароль следует запомнить или записать, так как его нужно будет выдать конечному пользователю.

Также пароль в кодированном виде сохранится в домашнем каталоге пользователя в файле ~/.vnc/passwd. Этот файл можно использовать для подключения к удалённому экрану вместо словесного пароля (например, если подключение делается через командную строку).

В этом же каталоге находится файл config, содержащий конкретные настройки для этого пользователя, например, разрешение экрана, которое будет включаться по-умолчанию. При необходимости, этот файл нужно будет отредактировать под этого пользователя.

• Копируем файл /lib/systemd/system/vncserver@.service в /etc/systemd/system/

При этом файл нужно переименовать, добавив имя пользователя, например 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

Далее нужно задать номер дисплея, на котором будет запускаться удалённый сеанс.

• Редактируем файл /etc/tigervnc/vncserver.users:

дописываем туда номер дисплея и имя пользователя

: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 1280x1024 -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.

Указываем там путь к серверу и порт — сервер:порт. Далее нужно будет ввести созданный ранее пароль.

Ещё раз скажем, что данная статья не затрагивает настройку систем безопасности. Если в ОС работает Selinux, firewalld или настроены какие-либо запрещающие правила в iptables, то это может мешать доступу к удалённому экрану.

Если всё сделано верно, то на клиенте мы увидим наш удалённый сеанс в виде рабочего стола графической среды.

Таким образом, мы настроили сервер для удалённого рабочего стола. В принципе, можно настроенный сервер поставить куда-нибудь в автозагрузку и успокоиться.

systemctl enable vncserver-vasya@:1.service

Однако такая схема годится для двух-трёх-четырёх пользователей. А что, если у нас их не один десяток? Не будем же мы держать запущенными на сервере 50 — 150 открытых сеансов ради того, чтобы кто-нибудь из этих пользователей когда-нибудь соблаговолил залогиниться на свой удалённый рабочий стол. Каждый сеанс забирает определённое количество оперативной памяти, даже если там никто не работает. И нерационально тратить ресурсы сервера на бесполезные неиспользуемые сеансы.

Здесь нам на помощь приходит функционал, заложенный в systemd. Используя его, можно настроить систему так, что она будет прослушивать заданный порт и только после получения запросов по нему запустит нужный нам процесс.

Для такой настройки нужно сделать некоторые дополнительные действия.

На этом этапе мы также должны подумать не только о том, как клиент будет подключаться к нашему серверу, но и что будет происходить, когда он отключится.

Если ничего дополнительно не настраивать и оставить так, как всё описано выше, то при первом запросе от клиента на порт 5901 будет запущен vnc-сервер с сеансом нашего пользователя. И далее он будет работать, пока его кто-нибудь или что-нибудь не остановит вручную. Если сервер будет работать бесконечно долго, а пользователь больше никогда не подключится, то открытый сеанс так и будет висеть в памяти сервера.

Поэтому, чтобы избежать такой ситуации, мы зададим некоторый таймаут, в течение которого vnc-сервер будет ожидать повторных подключений, а при их отсутствии выключится.

Это делается с помощью опции MaxDisconnectionTime, с которой нужно будет запускать сервер vnc. Опции можно задавать как в командной строке, так и в конфигурационных файлах пользователей, так и в общих конфигурационных файлах сервера. В данном случае нам надо задать единое правило для всех подключений, поэтому открываем файл /etc/tigervnc/vncserver-config-defaults и пишем туда строку:

MaxDisconnectionTime=время_в_секундах

Здесь возникает некоторый вопрос, а какое время задать для ожидания повторного коннекта. В принципе, можно погасить сервер сразу или через 5 секунд, или минуту. Но представим себе пользователя, который работал на сервере, открыл там 100500 окон, программ и файлов и случайно закрыл соединение. Может, у него рука дёрнулась, может, электричество кончилось. Или он просто ушёл с работы домой до следующего рабочего дня. Убить сразу его сеанс, значит ликвидировать возможную массу несохранённой работы.

С другой стороны, держать бесконечно запущенный сеанс в течение дней, недель и месяцев тоже нерационально. Поэтому здесь каждый выбирает себе сам адекватное количество времени. Но думаю, несколько часов для этого будет более чем достаточно.

Теперь можно снова запустить нашу службу:

systemctl start vncserver-vasya@:1.service

И сейчас это будет работать так: после запуска служба запустит сокет и будет слушать 5901 порт, пока кто-нибудь туда не постучится. Затем служба запустит vnc-сервер на том же 5901 порту. Удалённый клиент сможет зайти и что-то сделать в своём сеансе. После того, как клиент отключится, сервер vnc будет ожидать повторного соединения заданное число секунд. Если соединений не будет, сервер vnc остановится. Как остановится и служба, которая его запустила.

Чтобы автоматизировать процесс подключения пользователей создадим несколько новых файлов.

Нам нужен сокет, который будет слушать назначенный пользователю порт. Также нужна дополнительная служба, с которой этот сокет будет взаимосвязан. Службу, которую мы только что настроили, мы пока не трогаем, она выполняет свою функцию запуска vnc-сервера, больше от неё почти ничего не нужно.

Создаём файл, управляющий сокетом, в каталоге /etc/systemd/system. Назовём его, например, vnc-for-vasya.socket. Пишем туда следующее:

[Unit]

Description=vnc pre-socket

PartOf=vnc-for-vasya.service

[Socket]

ListenStream=ip_адрес_сервера:5901

RemoveOnStop=on

[Install]

WantedBy=sockets.target

В строке ListenStream нужно указать конкретный адрес сервера и прослушиваемый порт. Сокет будет взаимосвязан с одноимённой службой и здесь мы на неё сразу ссылаемся — PartOf=vnc-for-vasya.service.

Создадим файл для запуска службы в том же самом каталоге /etc/systemd/system. Назовём его vnc-for-vasya.service.

[Unit]

Description=vnc-pre-service

Requires=vnc-for-vasya.socket

[Service]

Type=simple

ExecStart=/bin/bash -c 'vnc_start.sh vasya 1'

[Install]

WantedBy=multi-user.target

Служба требует для своей работы запущенного сокета, это указано в строке Requires=vnc-for-vladix.socket. Назначением этой службы будет запуск той первой службы, которую мы уже настроили. В данном случае запуск предлагается осуществлять небольшим bash-скриптом, который нужно разместить в каталоге /usr/local/bin. Скрипт vnc_start.sh следующего содержания:

#!/bin/bash

systemctl start vncserver-$1@:$2.service

Скрипт требует два аргумента: первый — это имя пользователя vnc, второй — номер дисплея. В файле запуска службы скрипт вызывается с этими аргументами:

ExecStart=/bin/bash -c 'vnc_start.sh vasya 1'

Так как мы расположили скрипт в системном каталоге /usr/local/bin, то путь к нему прописывать не надо, этот путь есть в системной переменной $PATH. Если его там нет или скрипт будет лежать в другом каталоге, то в файле нужно указывать полный путь.

Чтобы запустить прослушивание сокета, нужно дать команду:

systemctl start vnc-for-vasya.socket

Обратите внимание, что запускать нужно именно сокет, а не связанную с ним службу. Если запустить службу, то сокет тоже запустится, но мы получим несколько неадекватный результат — служба будет всё время останавливаться и пытаться перезапускаться и выдаст ошибку, что перезапуск слишком частый. Если мы всё-таки разрешим ей не обращать на это внимание, то она будет постоянно перезапускаться.

Проверим состояние сокета:

systemctl status vnc-for-vasya.socket

Ответ должен быть приблизительно такой:

● vnc-for-vasya.socket - vnc pre-socket

Loaded: loaded (/etc/systemd/system/vnc-for-vasya.socket; disabled; vendor preset: disabled)

Active: active (listening) since Sat 2022-10-15 10:22:47 MSK; 2min 40s ago

Until: Sat 2022-10-15 10:22:47 MSK; 2min 40s ago

Triggers: ● vnc-for-vasya.service

Listen: здесь адрес сервера:5901 (Stream)

Tasks: 0 (limit: 154557)

Memory: 8.0K

CPU: 951us

CGroup: /system.slice/vnc-for-vasya.socket

То есть, сокет запущен и ждёт запросов по 5901 порту. Как только такой запрос поступит, сокет стартанёт службу vnc-for-vasya.service, которая выполнит скрипт vnc_start.sh, который, в свою очередь уже запустит нужную нам службу vncserver-vasya@:1.service, которая теперь запустит vnc-сервер на 5901 порту для пользователя vasya. Сам сокет vnc-for-vasya.socket после запуска службы остановится. Служба vnc-for-vasya.service после выполнения своей функции также остановится.

Да, путь получился довольно непростой, но, тем не менее, эта схема рабочая.

Единственный заметный для пользователя минус состоит в том, что при первом запуске или после окончания таймаута, который был задан выше для сервера vnc (MaxDisconnectionTime), пользователю придётся повторить свой запрос на подключение дважды. Так с первого запроса сервер vnc запуститься не успеет. То есть последовательность будет такая: пользователь посылает запрос на сервер через программу-vncviewer на подключение. В этот момент на сервере ещё не работает vnc для этого пользователя, в этот момент сервер только начнёт запускать vnc. Пользователю, скорей всего, его программа-просмотровщик выдаст ошибку подключения и, скорей всего, предложит повторить запрос. На момент повторного запроса сервер vnc будет уже запущен и ответит пользователю вопросом о вводе пароля. Если таймаут не прошёл, то сервер vnc будет ещё в запущенном состоянии и сразу спросит у пользователя пароль.

Здесь есть два пути решения — либо найти просмотровщик, где можно задать больший таймаут ожидания ответа сервера, но при беглом исследовании программ-промотровщиков с такой опцией не нашлось. Либо просто объяснить пользователю, что так может быть и что не надо этого смущаться. От одного лишнего клика мышкой пользователь помереть не должен.

Итак, мы добились, что сеанс пользователя стартует только по входящему запросу от пользователя. Однако, пока что мы ничего не сделали с завершением работы пользователя. Сейчас, при всех наших настройках, после того, как пользователь отключится от своего сеанса, произойдёт следующее: сервер vnc подождёт окончания своего таймаута MaxDisconnectionTime и закончит свою работу, все созданные нами службы и сокет также останутся в остановленном состоянии. То есть, у пользователя не будет никаких шансов подключиться снова.

Таким образом, нам нужно сделать так, чтобы после отключения vnc-сервера снова запускался на прослушку сокет.

Момент окончания работы vnc-сервера в нашем варианте знает служба vncserver-vasya@:1.service. Она остаётся в активированном состоянии, пока жив запущенный ею vnc-сервер. Отключается она сразу по завершении vnc-сервера. То есть, логично что-то добавить, чтобы именно эта служба, которую мы пока никак не редактировали, выполняла дополнительные действия.

Давайте именно это и сделаем. Нужно добавить одну строку в файл /etc/systemd/system/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

ExecStopPost=/bin/bash -c 'vnc_socket.sh vasya'

PIDFile=/run/vncsession-%i.pid

SELinuxContext=system_u:system_r:vnc_session_t:s0

[Install]

WantedBy=multi-user.target

Мы добавили строчку ExecStopPost=/bin/bash -c 'vnc_socket.sh vasya'. Опция ExecStopPost означает, что после окончательной остановки службы нужно выполнить указанную команду или команды. В нашем случае командой будет /bin/bash -c 'vnc_socket.sh vasya'

Предлагается создать ещё один bash-скрипт в каталоге /usr/local/bin с названием vnc_socket.sh следующего содержания:

#!/bin/bash

systemctl start vnc-for-$1.socket

Скрипт требует указания одного аргумента — имени пользователя vnc. При выполнении скрипта будет снова запущен прослушивающий сокет для указанного пользователя.

Чтобы изменения в файле /etc/systemd/system/vncserver-vasya@.service вступили в силу нужно дать команду:

systemctl daemon-reload

Или целиком перезагрузить операционную систему.

Теперь, после завершения работы службы vncserver-vasya@:1.service будет заново запускаться сокет и запросы пользователя снова смогут быть обработанными.

Таким образом мы мы полностью разработали алгоритм подключения и отключения пользователя.

Осталось добиться, чтобы сокеты для прослушки пользовательских портов запускались автоматически при загрузке ОС. Как будто бы для этого достаточно просто включить сокет на запуск при загрузке командой systemctl enable vnc-for-vasya.socket. Однако практика показала, что таким образом сокет не запускается, он попадает в состояние failed и ничего не работает. Поэтому пришлось использовать выполнение команд при загрузке через файл /etc/rc.d/rc.local. Этот файл исполняется при загрузке системы в последнюю очередь и в таком варианте сокет запускается нормально.

Чтобы не дописывать каждый раз при создании нового пользователя команду запуска сокета в этот файл попробуем этот момент автоматизировать.

Нам нужен дополнительный скрипт, который будет перебирать всех пользователей vnc и запускать для них сокеты. Предлагается сделать третий, последний, bash-скрипт в каталоге /usr/local/bin с названием vnc_boot.sh следующего содержания:

#!/bin/bash

while read line;

do

vnc_user=`echo $line | cut -d= -f2`

vnc_socket.sh $vnc_user

done < /etc/tigervnc/vncserver.users

Так как все пользователи vnc-сервера уже перечислены в файле /etc/tigervnc/vncserver.users, то скрипт просто будет последовательно перебирать строки этого файла. Чтобы скрипт не сбивали строки с комментами и пустые строки, их надо удалить и оставить только перечисление пользователей. То есть файл /etc/tigervnc/vncserver.users нужно привести к следующему виду:

:1=vasya

:2=fedya

:3=masha

Скрипт считывает строку, вычленяет из неё имя пользователя (echo $line | cut -d= -f2) и запускает для этого пользователя созданный ранее скрипт vnc_socket.sh, который и запускает сокет.

Обратите внимание, что в строчке vnc_user=`echo $line | cut -d= -f2` не должно быть пробелов у первого знака равно, иначе bash вам скажет, что в этой строчке ошибка.

Запуск скрипта vnc_boot.sh помещаем в файл /etc/rc.d/rc.local. Если там не было никаких записей или вообще не было такого файла, то он будет выглядеть так:

#!/bin/bash

vnc_boot.sh

Отметим, что все создаваемые bash-скрипты и файл rc.local должны иметь права на исполнение.

Всё, теперь при полной перезагрузке операционной системы на сервере все нужные нам сокеты запустятся автоматически.

Таким образом, чтобы подключить нового пользователя к серверу vnc нужно выполнить последовательность шагов:

• создать пользователя в операционной системе (useradd или adduser)

• задать ему пароль в системе (passwd от имени пользователя)

• задать ему пароль vnc (vncpasswd) (для удобства пользователя, скорей всего, пароли нужно делать одинаковые)

• назначить ему номер дисплея и вписать это в файл /etc/tigervnc/vncserver.users

• создать для него 3 файла в /etc/systemd/system: vnc-for-имя_пользователя.socket, vnc-for-имя_пользователя.service, vncserver-имя_пользователя@.service, указав в них параметры данного пользователя

• запустить сокет vnc-for-имя_пользователя.socket

• сообщить пользователю адрес сервера, персональный порт пользователя, пароль пользователя (можно ещё логин, но в данной реализации он нигде не использовался для подключения к серверу)

Ещё момент относительно безопасности соединения vnc. В данной статье описан самый простой способ подключения к vnc, который допустимо использовать, если vnс-сервер и vnc-клиенты находятся в отдельной надёжно защищённой локальной сети или в сети VPN. Если нужен более открытый доступ, то, конечно, для сервера vnc нужно применять более защищённые схемы подключения с использованием ssh, ssl, файерволов и так далее.

Так как мы всё это настраивали для работы с системой 1С, то, помимо всех предыдущих настроек, все пользователи, которые будут работать с 1С должны быть включены в группу пользователей grp1cv8.

Команда: usermod -G grp1cv8

Как было сказано в начале этой части, кроме сервера VNC, можно использовать протокол SSH. При использовании SSH есть некоторые моменты, которые надо учитывать.

С одной стороны, SSH — это надёжный защищённый шифрованный протокол и, конечно, такое соединение будет гораздо безопаснее, чем просто по vnc без шифрования.

С другой стороны, клиент в таком случае должен иметь либо ключ ssh от сервера, либо пароль ssh. В случае с ключом ситуация спорная. Хотя это будет и пользовательский ключ с ограниченным доступом, но, тем не менее, это ключ от весьма важного сервера и недопустимо, чтобы с ним что-то случилось (чтобы он потерялся или попал в чужие руки). Если же это пароль, то также вряд ли это будет действительно сложный пароль. Пользователю нужен либо пароль попроще, чтобы легко запомнить, либо пароль будет запомнен где-то программно, то есть возникнет та же ситуация, что и с ключом.

Также, если мы работаем в рамках своей локальной сети или VPN, то большой надобности шифровать трафик может и не быть. Шифрование трафика может наоборот замедлять скорость работы, особенно если у нас не сильно быстрое соединение с сервером.

Однако, использование ssh даёт ряд дополнительных возможностей. Если клиент тоже работает на Линукс и у него установлен ssh-ключ от сервера, то для запуска сеанса сокеты можно не использовать. На клиенте можно сделать отдельный bash-скрипт для подключения к серверу, который сам запустит сеанс vnc на сервере с нужными клиенту параметрами, может сразу задать разрешение экрана, дисплей, порт, смонтировать какие-нибудь локальные каталоги на сервер, пробросить звук и запустить просмотровщик-vnc уже на полностью готовый сеанс через файл с паролем. В общем, в полной мере использовать всю мощь командной строки как на клиенте, так и на сервере.

Подобный же функционал реализован в программном продукте X2go, он имеет продвинутый клиент для линукс и для windows. С клиентом под Mac OS всё не так однозначно, в app store его нет, можно скачать с их сервера версию 2020 года для Mac OS 10, будет ли она работать на Mac OS 11 и 12 и, вообще, как это работает на маке автор не проверял. Что касается клиентов для Android и iOS, то там всё ещё более загадочно. (Для VNC клиенты есть для любых вариантов — Linux, Windows, Mac OS, Android, iOS.)

Чтобы использовать x2go, нужно установить на сервер пакет x2goserver (с зависимостями), а на клиент — x2goclient (для windows установить программу через графический инсталлятор). Для функционирования x2go сервера настраивать на сервере особо ничего не надо, кроме того, что там должна быть запущена служба sshd и подключения не блокируются файерволом.

Клиент предварительно либо обменивается с сервером ключом ssh, либо получает пароль ssh. Далее клиент запускает графическое приложение, где указывает адрес сервера, порт, имя пользователя, ключ или пароль, разрешение экрана, настраивает какие папки расшаривать с клиента на сервер, пробрасывать ли звук, выбирает какая графическая среда запускается на сервере, либо какой командой на сервере её запустить (для KDE это, например, startplasma-x11 или startplasma-wayland). Настроенное соединение можно сохранить в виде значка запуска на рабочий стол или куда-то ещё.

Если всё задано верно, то откроется новое поле, где можно запустить удалённый сеанс. Программа-клиент подсоединяется к серверу по ssh и запускает на нём указанную ранее команду плюс все дополнительные настройки.

Вся работа удалённого сеанса идёт через ssh.

Если смотреть с точки зрения сложности настроек, то, конечно, такой вариант требует меньше усилий, чем описанная выше технология запуска vnc-сервера через сокет. Остальные моменты такого подключения описаны выше.

Думаю, что однозначного ответа, что лучше использовать для работы нет. И это будет зависеть от конкретных условий на месте. Например, проброс звука для пользователя 1С может понадобиться крайне редко. Папку расшарить можно не только по ssh, а, например, через samba-сервер, что в каком-то отношении может быть удобнее для пользователя, если папка должна использоваться не только одним пользователем. Принтеры также расшариваются по сети с разграничением доступа по пользователям. Такого эффекта, что файлы копируются просто перетаскиванием с одного рабочего стола на другой, как в windows через rdp-соединение, нет ни в vnc-сервере, ни в x2go.

Поэтому, вполне возможно, параллельное использование всех описанных выше способов подключения удалённых пользователей.

Ну и для мобильных клиентов, скорей всего, x2go не подойдёт.

Существуют, конечно, ещё такие средства просмотра удалённого рабочего стола, как TeamViewer или AnyDesk, но эти программы рассчитаны на то, что они подключаются к какому-то пользователю, в уже загруженный у него рабочий стол. В принципе, AnyDesk может с тем же успехом подключиться и в запущенный сеанс vnc, но это никак не влияет на технологию организации vnc-сервера, кроме того, что в удалённом сеансе должен будет работать ещё и AnyDesk, настроенный на приём подключений по паролю. Также AnyDesk-у для подключения в любом случае нужен доступ во внешний интернет, так как данные о том, где находятся рабочие места AnyDesk хранит на своих внешних серверах.

Чтобы подключиться к KDE через AnyDesk, TeamViewer или VNC, KDE или любая другая графическая среда должна быть запущена в варианте X11, графический сервер Wayland не имеет нужного функционала для удалённого подключения.

Часть 5. Настройка сеанса пользователя, взаимодействие между ОС пользователя и ОС сервера

Пользователь, зашедший на сервер через удалённый стол, не может выключить/перезагрузить сервер и выключить/включить сетевые интерфейсы через свои пользовательские графические инструменты. Надо полагать, что данный момент предусмотрен в имеющихся графических средах.

Все варианты запуска автор не проверял. Есть опыт использования LXDE и KDE. В LXDE ничего особо настраивать не требуется, но это довольно аскетичный рабочий стол со скудным количеством пользовательских настроек, с архаично выглядящим рабочим столом. Функционал часто приходится настраивать через дополнительные скрипты. То есть его можно использовать, но надо учитывать эти моменты.

Можно использовать KDE, тут есть ряд преимуществ. Более повёрнутая к пользователю среда, куча пользовательских настроек. При подключении через vnc или x2go KDE на лету схватывает изменение размера экрана (разрешения) и переключение оконного/полноэкранного режима (практически это схоже с поведением удалённого рабочего стола windows через rdp).

Но без дополнительной настройки KDE при запуске и работе может выдавать лишние сообщения и окна и загружать ненужные в данном режиме апплеты. Как минимум, нужно выключить из автозагрузки: демон управления цветом, диспетчер уведомлений о состоянии, модуль для управления сетью, подключение внешних носителей, сенсорную панель, состояние сети, Bluetooth. В графической среде это делается через меню настройка → параметры системы → запуск и завершение → управление службами.

Также желательно убрать из трея в панели уведомления, настройку экранов, сенсорную панель, сети и Bluetooth. В графической среде это делается через режим редактирования рабочего стола (правая кнопка мыши по панели, режим редактирования, затем правой кнопкой по трею, редактировать).

Могут быть некоторые нестыковки при трансляции на сервер нажатий клавиатуры, например, было замечено, что может не передаваться русская буква «э». Чтобы такого не происходило, нужно настроить переключатель раскладок. Выключить там глобальные настройки и включить локальные, добавить в них русскую раскладку и настроить комбинацию клавиш для переключения (обычно левые alt+shift).

В удалённом режиме в KDE пользователю доступны кнопки «выключить», «перезагрузить», «выйти из сеанса». Корректно работает последняя, остальные выводят чёрный экран. После закрытия окна удалённого сеанса и перезапуска этого сеанса вход снова будет доступен. Однако, стоит отметить, что при использовании описанной выше технологии подключения к сеансу по vnc через сокет перезапуск сеанса произойдёт автоматически по завершении работы vnc-сервера, а по ssh и x2go такого не будет, кому-то придётся заходить на командную строку сервера и убивать нужный процесс вручную, иначе при повторном заходе пользователь снова увидит чёрный квадрат.

Управление сетевыми интерфейсами недоступно пользователю.

То есть, после того, как мы полностью завели пользователя и настроили его системно, нужно доделать его персональные настройки уже на его рабочем столе.

Чтобы не делать это каждый раз при создании очередного пользователя, можно этот процесс автоматизировать. Шаблон домашнего каталога пользователя, который используется при создании нового пользователя, находится в каталоге /etc/skel. Обычно по-умолчанию там весьма скудный набор конфигурационных файлов и каталогов, но туда можно положить любые файлы и тогда, когда мы будем создавать пользователя, такие же файлы сразу окажутся в его домашней папке.

Можно сделать так — создать нового пользователя, сделать все нужные настройки через графическую среду, потом скопировать настроенные конфигурационные файлы и каталоги из его домашней папки в /etc/skel, поменять владельца скопированных файлов на root.

Следующий создаваемый пользователь сразу получит себе в домашний каталог все сохранённые настройки.

Что можно сказать ещё относительно взаимодействия между пользовательской операционной системой и серверной. Должен работать двухсторонний буфер обмена (это не касается помещения в буфер обмена файлов), то есть можно скопипастить текст на удалённом экране и вставить его на локальной машине и наоборот.

Относительно проброса папок, принтеров, USB-портов, звука и так далее, то в vnc нет такого функционала, как в RDP-протоколе. Поэтому здесь данные вопросы нужно решать в зависимости от ситуации.

Если мы находимся в общей локальной сети, то папки расшариваются по сети, например, на сервере делается шара для обмена файлами с пользователем, пользователю она подключается как сетевой диск или папка. Принтеры тоже настраиваются напрямую на сервере (если они сетевые), а, если это локальные принтеры, то они расшариваются на клиенте и настраиваются на сервере. Если клиент на ОС Linux, то можно расшарить и сканеры, а также пробросить звук с сервера на клиента.

В общем, организация совместно используемых аппаратных ресурсов — это отдельная тема для продолжения данной статьи, требующая отдельного описания. Полагаю, что для минимального запуска и настройки терминального сервера 1с на ОС Fedora данного описания будет достаточно.

Следующей темой, по всей видимости, должно быть подключение фискальных регистраторов к такому серверу и организация рабочего места кассира.

Спасибо за внимание, работайте на правильных операционных системах.