Как установить 1с на linux

/rpmbuild/RPMS, пакет postgresql96-9.6.3-1.1C.src.rpm – в

Особенно «радует» здесь фраза «в случае ошибки сборка будет прекращена». То есть разработчики сами не уверены в успехе этого предприятия.

Основываясь на практическом опыте, можно сказать, что действительно при компиляции вываливается несколько некритичных ошибок, а затем компилятор спотыкается на моменте указания нестандартного пути к библиотекам 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]

Важное примечание. Здесь может возникнуть проблема с системой безопасности 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

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 файла:

Запускаем файл 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 (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

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

На этом этапе возникнет вопрос с лицензией. Если лицензия электронная, то здесь нужно будет вводить электронный ключ. Также нужно учесть, что для запуска клиентского приложения понадобится не только серверный ключ, но и клиентский. Если это 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

В интернете можно найти не одно описание того, как это делать. И там можно прочитать, что этот файл надо отредактировать, вписав туда имя конкретного пользователя.

Однако, на настоящий момент, никаких правок в этом файле делать не надо. Содержимое файла должно быть таким:

Description=Remote desktop service (VNC)

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

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

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

Для следующего пользователя:

Помимо того, что это будет номер дисплея, назначенный этому пользователю, это также будет смещением для номера порта, на котором будет запускаться 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.

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

Ещё раз скажем, что данная статья не затрагивает настройку систем безопасности. Если в ОС работает 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. Пишем туда следующее:

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

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

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

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

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

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

Tasks: 0 (limit: 154557)

То есть, сокет запущен и ждёт запросов по 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 и привести файл к следующему виду:

Description=Remote desktop service (VNC)

ExecStopPost=/bin/bash -c ‘vnc_socket.sh vasya’

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

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

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 следующего содержания:

while read line;

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

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

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

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

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

Отметим, что все создаваемые 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 данного описания будет достаточно.

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

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

От экспертов «1С‑Рарус»: Установка серверной части 1С в Linux среде (сентябрь 2021)

ВАЖНО: Читайте обновлённое руководство по установке сервера 1С под Linux в статье «От экспертов „1С‑Рарус“: Российские дистрибутивы Linux и установка в них сервера 1С» (январь 2023).

Информация о руководстве

Руководство рассчитано на технических специалистов с опытом установки операционных систем семейства Windows. После изучения материалов статьи вы сможете установить серверную часть 1С в ОС GNU/Linux для эксплуатации на больших и маленьких проектах.

В руководстве описывается установка и настройка серверной системы на базе ОС GNU/Linux, а именно дистрибутива Ubuntu 18.04 с сервером 1С:Предприятия 8.3. Система включает следующие компоненты: сервер 1С, сервер СУБД PostgreSQL, менеджер лицензий платформы, сервер лицензирования СЛК, веб-сервер Apache.

Данное руководство по установке 1С в Linux рассчитано под версии:

• Ubuntu-18.04.-server-amd64.
• PostgreSQL 1C 12.8.1 от компании PostgresPro.
• Apache 2.4.
• Сервера 1С 8.3.16.1973, 8.3.17.2306, 8.3.18.1616, 8.3.19.1264.

Но также может быть адаптировано и под другие версии.

Оглавление

1. Термины

• Пакеты (deb— пакет для ОС Debian/Ubuntu; rpm — пакет для ОС RedHat/Centos) — формат предоставления программного обеспечения в виде пакетов, содержащих помимо дистрибутива программного обеспечения, набор определённых метаданных, которые могут включать в себя полное имя пакета, номер версии, описание пакета, имя разработчика, контрольную сумму, зависимости с другими пакетами.
• tar — формат файла архива, а также название традиционной для Unix (ru.wikipedia.org/wiki/Unix) программы для работы с такими архивами.
• Локаль (locale) — региональные настройки.
• Репозиторий, хранилище — место, где хранятся и поддерживаются какие-либо данные, необходимые для обновлений/установки приложений/пакетов.
• Менеджер пакетов (apt — debian, rpm — RedHat) — система управления пакетами с программным обеспечением, занимается корректной установкой/удалением пакетов разрешает зависимости, а также ведет базу установленного ПО, например, rpm и dpkg, можно сказать, что это аналог msi из мира Windows.
• Зависимости — одна из важнейших сфер деятельности менеджера пакетов. Менеджер пакетов отслеживает зависимости между пакетами, что значительно облегчает задачи администратора. Зависимости возникают в тех случаях, когда работоспособность ПО из одного пакета зависит от ПО, входящего в состав другого пакета.
• sudo — команда для запуска приложений от имени другого пользователя, по умолчанию от пользователя root.

2. Установка ОС Ubuntu (серверный вариант)

Существует множество дистрибутивов ОС GNU/Linux, многие из них специализированные для каких-то конкретных задач, а есть и дистрибутивы общего назначения. С кратким описанием каждого и выбором по параметрам можно ознакомиться на сайте distrowatch.com.

Так как мы выбираем ОС для установки сервера «1С:Предприятие», то логично использовать ОС из списка поддерживаемых операционных систем (v8.1c.ru/tekhnologii/sistemnye-trebovaniya-1s-predpriyatiya-8/), а именно:

• Astra Linux:
  • Common Edition, версии 1.11, 2.12.
  • Special Edition, версии 1.4, 1.5, 1.6.

  Все поддерживаемые дистрибутивы можно сразу разделить на 2 категории.

  RPM-based

  Red Hat Enterprise Linux (RHEL)

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

  CentOS

  Ранее дистрибутив поддерживался сообществом и позиционировался как полностью бинарно совместимый с Red Hat Enterprise Linux для тех, кому не нужна корпоративная поддержка со стороны Red Hat, но, после того как CentOS ушла под крыло Red Hat, были пересмотрены цели дистрибутива, и теперь он будет развиваться как роллинг дистрибутив CentOS Stream, на базе срезов которого, будут формироваться сборки Red Hat Enterprise Linux.

  Поддержка CentOS 8, вместо 10 лет, сократилась до 2,5 лет и будет прекращена 31 декабря 2021 года. Поддержку CentOS 7 сохранили до 24 июня 2024 года, т. к. фаза основной поддержки уже закончилась в 4 квартале 2020 года, а устранение критических уязвимостей уже не отнимает так много сил. На фоне таких веяний доверие к дистрибутиву было подорвано, появилось несколько дистрибутивов, заменяющих CentOS, но т. к. все они молодые, пока доверия к ним нет.

  Бинарно совместим значит, что собран из точно тех же исходных кодов теми же инструментами, и, соответственно, если в каком-либо софте заявляется гарантированная работа в RHEL, то данный софт без переборки заработает и в CentOS.

  Роллинг — это постоянно обновляющаяся система без выпуска дистрибутивов с замороженными версиями софта.

  Альт Линукс

  Пакеты rpm, но менеджер пакетов apt, более присущий дистрибутивам на базе deb пакетов.

  DEB-dased

  Debian

  Один из старейших дистрибутивов GNU/Linux на базе deb, в большинстве случаев deb‑based дистрибутивы основаны на его пакетной базе.

  Ubuntu

  Дистрибутив от компании Canonical, ввиду огромного сообщества и популяризации его силами компании, наверное, самый распространенный дистрибутив GNU/Linux.

  Linux Mint

  Дистрибутив, основанный на базе Ubuntu, в серверной части мало чем отличается от Ubuntu, т. к. использует репозитории Ubuntu.

  Astra Linux

  Российская производная Debian GNU/Linux.

  Выбираем и устанавливаем Ubuntu 18.04 LTS

  Мы будем использовать дистрибутив Ubuntu 18.04 LTS, потому что:

  • С CentOS происходят изменения и его дальнейшая судьба не совсем ясна.
  • Поддержка Debian 9 версии заканчивается в 2022 году.
  • Поддержка дистрибутивов Ubuntu расширена с 5 лет до 10 лет для серверных дистрибутивов.

  Дистрибутив Ubuntu можно взять на официальном сайте (releases.ubuntu.com/18.04.5/). Для этого понадобится ISO-файл (releases.ubuntu.com/18.04.5/ubuntu-18.04.5-live-server-amd64.iso) серверного образа для платформы х64 PC (AMD64). Для развертывания сервера можно использовать как платформы виртуализации так и развертывать непосредственно на железе. Для виртуализации подойдет практически любая платформа:

  • Hyper-V (ru.wikipedia.org/wiki/Hyper-V),
  • VmWare ESXi (www.vmware.com/ru/products/esxi-and-esx.html),
  • Citrix XenServer (www.citrix.com/ru-ru/products/citrix-hypervisor/),
  • Proxmox (www.proxmox.com/en/proxmox-ve),
  • oVirt (www.ovirt.org),
  • и другие.

  Сравнение систем виртуализации может оказаться очень обширным и выходит за рамки данной статьи.

  Для установки дистрибутива на физический сервер можно воспользоваться разными способами. Например, подготовить загрузочную флешку с помощью Rufus (rufus.ie), использовать мультизагрузочные флешки EasyToBoot (easy2boot.xyz) или Ventoy (www.ventoy.net). Системы виртуализации могут подключать iso образ к виртуальному CD\DVD приводу.

  После запуска с загрузочного носителя нас приветствует стандартное меню установки Ubuntu Server.

  Выбираем 2 пункт, т. к. будет использовано более новое ядро Linux 5.4. от Ubuntu 20.04.

  

  Далее выбираем язык и раскладки клавиатуры системы которую будем устанавливать.

  

  

  

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

  

  Далее разметка диска. Рекомендуется выбрать пункт с созданием LVM (ru.wikipedia.org/wiki/LVM), что в последующем позволит более гибко управлять дисковым пространством. Если у вас несколько дисков или аппаратных RAID (Redundant Array of Independent Disks) массивов, то можно настроить разметку диска вручную. Стоит создать отдельные разделы для /var и /home, и для /var использовать самый быстрый диск, следующий по скорости для /home и самый небольшой под корневой раздел /.

  

  

  Далее создаем пользователя в системе, под которым и будем заходить на сервер. Это необходимо сделать, т. к. в Ubuntu по умолчанию root отключен, после установки можно будет создать еще пользователей.

  

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

  

  Далее предоставляется выбор установки пакетов SNAP, ни один из них нам не нужен для сервера 1С, поэтому ничего не выбираем.

  

  Далее происходит установка системы, после установки подсветится пункт Reboot Now, его и нажимаем для загрузки в установленную систему.

  

  После перезагрузки вводим логин и пароль и попадаем в shell свежеустановленной системы.

  

  Если вы устанавливали систему в виртуальной машине, то скорее всего так же была установлена система cloud-init, которая предназначена для автоматической конфигурации виртуальной машины, но если вы её не используете, то проще всего ее удалить, т. к. она замедляет загрузку сервера.

  Далее необходимо настроить временную зону, сгенерировать локали, настроить сеть, если это не было сделано во время установки. Поставить минимум необходимого софта с которым удобнее работать.

  Настраиваем временную зону

  Посмотреть текущие настройки временной зоны:

  Посмотреть список зон:

  Установить временную зону:

  Настраиваем локали

  

  Напротив необходимых локалей ставим пробелом звездочку, после чего по tab переходим на пункт OK и сохраняем список.

  Рекомендуется также добавить локаль ru_RU.CP1251, если на сервере планируется использовать программный продукт КриптоПРО для работы с электронным документооборотом из 1С:Предприятия.

  

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

  Важно выбрать локаль по умолчанию ru_RU.UTF-8, т. к. это повлияет на правильную установку PostgreSql.

  Настройка сети

  Примеры конфигурационных файлов можно посмотреть в установленной системе в каталоге /usr/share/doc/netplan/examples. Мы будем настраивать статический ip-адрес:

  Для этого удаляем предыдущую конфигурацию что бы ничего нам не мешало:

  Копируем пример со статической конфигурацией:

  Узнаем название интерфейса, т. к. имя нам понадобится для правки конфигурации:

  Нам нужны физические Ethernet-интерфейсы, они могут иметь название, начинающееся на en. Расшифровка префиксов обозначения интерфейсов:

  • en — Ethernet,
  • ib — InfiniBand,
  • sl — serial line IP (slip),
  • wl — wlan,
  • ww — wwan,
  • lo — loopback.

  И исправляем пример под свою конфигурацию:

  После исправления, применяем конфигурацию:

  После применения конфигурации, проверим что адрес соответствует нашим настройкам:

  

  После чего обновляем список пакетов и устанавливаем обновления на систему:

  Устанавливаем софт для более удобной работы и мониторинга в реальном времени:

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

  mc — удобный двухпанельный менеджер файлов наподобие Norton Commander.

  htop — интерактивный диспетчер процессов.

  iftop — утилита для мониторинга сетевой активности.

  iotop — утилита для мониторинга дисковой активности.

  После чего перезагружаем сервер и переходим к следующему этапу.

  3. Удаленное управление GNU/Linux сервером

  Если вы ранее не работали с системами GNU/Linux, а работали только с системами Windows, то навыки традиционных способов управления системами как RDP или RSAT не подойдут для этого. Но для управления GNU/Linux-серверами есть много различных инструментов и способов.

  Например, web-панель webmin (www.webmin.com), позволяющая настроить различные аспекты операционной системы и служб. Или специализированные интерфейсы от программных продуктов, а также программы управления системой в различных графических оболочках (gnome, kde, xfce и другие).

  В большинстве своем все эти программы занимаются одним и тем же, а именно правкой конфигурационных файлов, что иногда бывает достаточно удобно. В случае возникновения аварий или нештатных ситуаций может не хватить предлагаемых сервисов и потребуется использование прямого редактирования. Поэтому традиционно для администрирования GNU/Linux серверов используется текстовый терминал, для удаленного подключения к нему протокол Secure Shell — ssh, а для передачи файлов протоколы scp и sftp.

  В современных операционных системах Windows, а именно Windows 10 начиная с релиза 1809 и Windows Server 2019 клиент ssh уже встроен и ничего дополнительно устанавливать не нужно. На GNU/Linux машинах клиент ssh предустановлен или установить его не составляет проблемы, т. к. он содержится в стандартных репозиториях системы.

  Как в Windows, так и в GNU/Linux в качестве реализации протокола используется набор программ OpenSSH, поэтому далее будет рассматриваться только данный набор программ, использование которого будет одинаковым под разными операционными системами. Для более старых версий Windows рекомендуется использовать клиент putty (www.chiark.greenend.org.uk/

  sgtatham/putty/latest.html), в состав которого входят клиенты для передачи файлов pscp и psftp, аналоги программ scp и sftp из пакета OpenSSH.

  Если при установке ОС вы пропустили шаг установки сервера OpenSSH, это можно сделать командой:

  

  Если сервис не запущен или отключён, то включим его и запустим:

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

  На своей машине запустим терминал. В случае с Windows это может быть оболочка PowerShell или cmd, под GNU/Linux может быть любая оболочка, зачастую во многих дистрибутивах используется по умолчанию bash. Подключимся к серверу.

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

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

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

  Сгенерировать ключи просто, нужно запустить программу ssh-keygen:

  Далее скопировать публичный ключ на сервер.

  C клиента на Windows из cmd:

  или из PowerShell:

  C клиента на GNU/Linux:

  После чего уже можно подключаться с использованием ключа

  Более подробно ознакомиться с документацией по OpenSSH можно на сайте проекта (openssh.com/manual.html).

  Так же рекомендуется длительные операции запускать через мультиплексор терминалов tmux или screen. Это даст возможность оставлять запущенные программы в окне терминала и отключаться от терминала, а также при случайном обрыве соединения ваши приложения не закрываются, поэтому подключившись к серверу снова можно вернуться к своему прошлому сеансу и продолжить работу. Также tmux позволяет разделять одно окно терминала на несколько окон и рабочих областей.

  Подключиться к своему прошлому сеансу можно командой tmux attach, а отключиться комбинацией клавиш ctrl+b d.

  4. Установка и настройка сервера 1С

  Сервер у нас подготовлен и мы научились к нему подключаться. Настало время установить на него сервера 1С:Предприятия.

  Установка серверов 1С

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

  Будем устанавливать 4 платформы разных версий — последние на момент написания статьи — 8.3.16.1973, 8.3.17.2306, 8.3.18.1616, 8.3.19.1264.

  Для начала скачиваем необходимые дистрибутивы с сайта «1С» (releases.1c.ru/project/Platform83) на свой компьютер. Т.к. мы используем сервер на платформе x86_64 на базе deb, то соответственно и дистрибутивы будем скачивать «Cервер 1С:Предприятия (64-bit) для DEB-based Linux-систем».

  Откроем командную строку в каталоге со скачанными файлами. В нашем случае все дистрибутивы сохранены в каталог 1C-Server расположенном в папке Downloads. Копируем файлы дистрибутива на сервер командой:

  Далее подключаемся к серверу по ssh:

  Проверим, что файлы скопировались:

  Должен отобразиться список всех файлов, что мы скопировали. Если все нормально, приступим к установке пакетов необходимых для сервера 1С:

  Теперь займемся дистрибутивами сервера 1С. Т. к. с 18 релиза поменялось расположение файлов сервера и клиента 1С, то стоит привести их всех к одному виду, поэтому перепакуем пакеты старых релизов 16 и 17 и приведем их по структуре к новым. Так же это даст нам возможность ставить несколько версий сервера 1С старых релизов из пакетов.

  Скрипт для перепаковки:

  Сохраняем данный скрипт в файл

  /distr/1c-enterprise83-server-repack.sh и делаем его исполняемым:

  Переходим в каталог со скопированными дистрибутивами для их распаковки:

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

  И дистрибутивы 8.3.16 и 8.3.17 перепаковываем под новый формат:

  После чего вместо старых deb пакетов в каталоге будут новые пакеты.

  Сразу их и установим:

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

  На этом установка сервера закончена, и можно переходить к настройке сервисов.

  Настройка серверов 1С

  Т. к. мы будем одновременно запускать несколько версий сервера 1С, то необходимо разнести сервера на разные порты, чтобы не было конфликта. По умолчанию сервер 1С использует порты 1540-1541,1560-1691.

  Мы перепаковали старые дистрибутивы, поэтому будем все сервисы настраивать по новому. Будем настраивать по следующей схеме:

  • 8.3.16.1973 — порты 1540-1541,1560-1691, имя службы srv1cv83-1540;
  • 8.3.17.2306 — порты 2540-2541,2560-2691, имя службы srv1cv83-2540;
  • 8.3.18.1616 — порты 3540-3541,3560-3691, имя службы srv1cv83-3540;
  • 8.3.19.1264 — порты 4540-4541,4560-4691, имя службы srv1cv83-4540.

  Копируем init файл из каталога установленного сервиса в каталог /etc/init.d:

  И файл конфигурации в каталог /etc/default:

  После чего изменяем конфигурационный файл:

  Нужно раскомментировать и поменять значение следующих параметров:

  SRV1CV8_PORT=1540
  SRV1CV8_REGPORT=1541
  SRV1CV8_RANGE=1560:1691
  SRV1CV8_DEBUG=1
  SRV1CV8_DATA=/home/usr1cv8/.1cv8/srv1cv83-1540

  Чтобы системный менеджер увидел новые файлы, необходимо их перечитать:

  Затем включить сервис и запустить его:

  И проверим статус сервера:

  Если все нормально, то продолжаем и копируем аналогично файлы для других служб:

  Далее будем править конфигурационные файлы для сервиса srv1cv83-2540:

  Нужно раскомментировать и поменять значение следующих параметров:

  SRV1CV8_PORT=2540
  SRV1CV8_REGPORT=2541
  SRV1CV8_RANGE=2560:2691
  SRV1CV8_DEBUG=1
  SRV1CV8_DATA=/home/usr1cv8/.1cv8/srv1cv83-2540

  Аналогично правим конфигурационные файлы остальных сервисов.

  Приведем тут только измененные строки:

  SRV1CV8_PORT=3540
  SRV1CV8_REGPORT=3541
  SRV1CV8_RANGE=3560:3691
  SRV1CV8_DEBUG=1
  SRV1CV8_DATA=/home/usr1cv8/.1cv8/srv1cv83-3540

  SRV1CV8_PORT=4540
  SRV1CV8_REGPORT=4541
  SRV1CV8_RANGE=4560:4691
  SRV1CV8_DEBUG=1
  SRV1CV8_DATA=/home/usr1cv8/.1cv8/srv1cv83-4540

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

  Сервис Remote Administration Service (RAS)

  Далее настроим сервисы Remote Administration Service (RAS) для каждого из созданных кластеров 1С.

  Также, как и сервера 1С, распределим сервисы RAS по портам:

  • 8.3.16.1973 — порт 1545, имя службы ras-srv1cv83-1540;
  • 8.3.17.2306 — порт 2545, имя службы ras-srv1cv83-2540;
  • 8.3.18.1616 — порт 3545, имя службы ras-srv1cv83-3540;
  • 8.3.19.1264 — порт 4545, имя службы ras-srv1cv83-4540.

  Компания «1С» не предоставляет init файлов для создания сервисов RAS, поэтому создадим их сами:

  Со следующим содержимым:

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

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

  sudo systemctl daemon-reload

  Проверяем статус запущенных служб:

  

  Дальше проверим подключение к кластеру с помощью утилиты Remote Administration Client (rac):

  

  Утилита rac не так сильно привязана к версии сервера и поэтому можно с помощью неё же и проверить и остальные кластеры:

  Сервер хранилища конфигураций

  Настройка сервера хранилища конфигураций не сильно отличается от настройки сервиса RAS. Юнит файл для запуска будет примерно таким же, отличаться только названием и командой запуска сервиса, но тут стоит поменять схему выбора портов для хранилищ. Тут подходим к выбору порта от версии платформ и, чтобы не пересекаться с уже запущенными сервисами, будем использовать порты выше 10000. Соответственно схема выбора порта будет 1xxxx, где xxxx — последние 4 цифры билда платформы:

  • 8.3.16.1973 — порт 11973, имя службы crserver-16.1973.
  • 8.3.17.2306 — порт 12306, имя службы crserver-17.2306.
  • 8.3.18.1616 — порт 11616, имя службы crserver-18.1616.
  • 8.3.19.1264 — порт 11264, имя службы crserver-19.1264.

  Каталог с хранилищами будет один для всех, и разместим его в каталоге /var/opt/1C/crserver.

  Для начала создадим каталог для хранилища:

  И изменим владельца каталога:

  Создаем Unit файл для сервиса:

  Так же копируем Unit файлы под другие сервисы с помощью sed заменяем параметры:

  После перечитываем списки сервисов, включаем и запускаем их:

  Так же проверяем статус запуска:

  

  На этом установка и настройка сервисов 1С закончены.

  5. Установка PostgreSQL для 1С

  Теперь дошло дело до установки и настройки сервера баз данных PostgreSQL. Сначала сверимся со списком совместимоcти версий PostgreSQL для 1С на сайте «1С»: v8.1c.ru/tekhnologii/postgrespro/ и v8.1c.ru/tekhnologii/sistemnye-trebovaniya-1s-predpriyatiya-8/. В списках совместимости самая последняя версия 12.7.1 совместимая со всеми выше указанными версиями сервера 1С, а 13 версия совместима только начиная с релиза 8.3.20.

  Версия 12.7.1 протестирована «1С» на совместимость, но т. к. в пределах крупных выпусков не делается изменений, меняющих работу сервера, а исправляются только ошибки и закрываются дыры в безопасности, можно ставить и более свежую версию.

  Ввиду того что компания «1С» не готовила новых выпусков сервера Postgres после 12.7.1, будем ставить версию 12.8.1 от компании Postgres Pro. Ее версии сервера postgres-1c так же, как и от компании «1С», построены на чистом коде оригинального проекта с патчами 1С.

  Пройдем короткий опросник на сайте 1c.postgres.ru, и на почту придут инструкции по установке данной сборки.

  Перейдем в каталог с дистрибутивами и создадим в нем каталог postgres:

  Далее действуем по присланной инструкции, скачиваем скрипт, которой добавит apt репозиторий и публичный ключ подписи пакетов в систему, и выполним его:

  Далее устанавливаем сам сервер:

  После установки сервер должен сам запустится, проверим это:

  

  Далее необходимо установить пароль пользователя postgres и создать пользователя для 1С — usr1cv8:

  Вводим 2 раза пароль для пользователя postgres:

  

  Создаем пользователя usr1cv8:

  Проверим создался ли пользователь:

  

  Также можно создать отдельные табличные пространства, которые 1С будет автоматически использовать:

  • v81c_data — для данных;
  • v81c_index — для индексов.

  После чего выходим из утилиты psql:

  6. Оптимизация параметров PostgreSQL

  Рекомендации «1С» по настройке postgresql можно посмотреть на сайте ИТС (its.1c.ru/db/metod8dev#content:3788:hdoc). Большая их часть уже учтена в сборке от PostgresPro, и даже проведены оптимизации под железо по памяти и количеству ядер процессора. Но не учитывается дисковая подсистема, поэтому стоит оптимизировать эти параметры: random_page_cost и effective_io_concurrency. Для этого воспользуемся сервисом pgtune.leopard.in.ua.

  На странице сервиса необходимо указать параметры настраиваемой системы и сервера:

  • Версии нашей СУБД = 12.
  • Тип ОС = Linux.
  • Количество ОЗУ.
  • Количество процессоров.
  • Количество подключений к базе (оптимально максимально возможное значение).
  • Тип жесткого диска (HDD/SSD/NAS).

  

  Нажать Generate и скопировать данные из правого окна в конец конфигурационного файла расположенного по адресу /var/lib/pgpro/1c-12/data/postgresql.conf:

  После сохранения конфигурационного файла нужно перезапустить сервер postgres командой:

  Теперь можно озаботится более удобным управлением сервером БД. Хоть управление через psql может покрыть все потребности и подходит для скриптования, но зачастую визуальное представление данных проще и удобнее. Поэтому установим на сервер средство для визуальной настройки и управления postgresql — PGAdmin 4.

  На сайте проекта PGAdmin (pgadmin.org/download/pgadmin-4-apt/) приведена простая инструкция по установке системы.
  Скачиваем публичный ключ репозитория проекта и добавляем в доверенные ключи apt:

  Далее добавляем репозиторий проекта в менеджер пакетов apt и обновляем список доступных пакетов:

  Далее устанавливаем вариант PGAdmin с WEB-интерфейсом, т. к. на сервере у нас нет графической подсистемы.

  Ставить будем с небольшим отличием от оригинальной инструкции. В команду установки необходимо добавить —no-install-recommends, чтобы не ставились рекомендованные пакеты из зависимостей, а именно postgresql-client и postgresql-client-10, т. к. postgresql-client-10 будет конфликтовать с установленным у нас клиентом postgresql 12:

  В процессе установки по зависимостям так же будет установлен и WEB-сервер Apache.

  После установки запускаем мастер настройки системы, в котором надо будет создать первую учетную запись PGAdmin и указать какой веб-сервер будет использоваться:

  

  Далее перейдем по указанному в мастере URL заменив только адрес 127.0.0.1 на адрес или имя сервера, в нашем случае http://192.168.12.112/pgadmin4, где авторизуемся под только что созданной учетной записью.

  

  После входа, попадаем на главную страницу программы, где необходимо добавить обслуживаемый сервер.

  

  

  

  Нажимаем Save, после чего сервер добавится в интерфейс.

  

  7. Установка драйверов HASP

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

  Скачиваем дистрибутив Sentinel SDK Runtime (thales-sentinel.ru/helpdesk/download-space/) для Linux. Копируем его на сервер со своего компьютера:

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

  Будет установлено 2 службы — aksusbd (драйвер HASP) и hasplmd (Hasp License Manager).

  Проверим, что они работают:

  

  Разрешаем подключение к консоли hasplm не только с локалхост:

  Теперь можно через браузер зайти по адресу http://192.168.12.112:1947/ и настроить сервис на странице конфигурации. Не забудьте поставить пароль на доступ к Sentinel ACC.

  

  8. Управление кластером 1С

  Управление кластером 1С под Linux ничем не отличается от такого же установленного на Windows, поэтому удобнее всего воспользоваться консолью mmc для Windows. Так же создавать базы можно из стандартного мастера добавления базы клиента 1С, но для правильной работы клиента, должен работать резолвинг имен. Поэтому если у вас нет DNS-сервера для разрешения имен, то для правильной работы на клиентском компьютере необходимо добавить запись в файл %WINDIR%\System32\drivers\etc\hosts в формате IPAddress HostName. После чего, можно подключаться клиентом к серверу с базами.

  Но также можно управлять кластером 1С и из консоли GNU/Linux сервера с помощью утилиты Remote Administration Client (RAC). Для этой возможности мы и настраивали в 3 разделе статьи сервис RAS. Управлять сервером с помощью этой утилиты можно локально и удаленно с машин под Windows и Linux.

  Утилита rac совместима с серверами ras и не привязана к версии с релиза платформы 8.3.9, поэтому для управления, например, сервером на платформе 8.3.19 можно пользоваться клиентом версии 8.3.9 и наоборот. Исключение составляют только те функции и возможности, которые появились в более поздних релизах, соответственно этими функциями можно управлять утилитой той версии, в которой они появились или выше.

  В 3 разделе мы уже воспользовались утилитой rac для проверки работоспособности сервера. Теперь с помощью этой же утилиты создадим базу данных.

  Перейдем в каталог с установленной платформой:

  И запустим утилиту rac без аргументов, чтобы посмотреть краткую справку по использованию:

  

  Для того чтобы создать базу, нам необходимо узнать UUID кластера. Узнаем uuid кластера 8.3.19. Как и планировали в начале статьи RAS для данного кластера работает на порту 4545.

  

  Создадим базу данных testdb:

  В ответ утилита сообщит uuid созданной базы:

  

  Теперь выведем список баз в кластере:

  

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

  Утилита позволяет полностью администрировать функции кластера 1С, аналогично консоли mmc.

  9. Установка и настройка веб-сервера

  Apache — популярный тип веб-сервера и является веб-сервером по умолчанию для многих операционных систем, доступен в стандартном репозитории Ubuntu.

  Устанавливаем и запускаем Apache2

  Мы уже установили сервер apache2, когда разворачивали PGAdmin, но он был установлен как зависимость к PGAdmin. В случае, если PGAdmin будет удален, и затем будет выполнена рекомендованная команда удаления более неиспользуемых пакетов, то и apache2 будет удален. А нам этого не нужно, поэтому переведем пакет в режим установки вручную командой:

  У нас установлено 4 платформы и сложность публикации баз разных релизов 1С, в том, что сервер может загрузить только 1 модуль wsapi. Соответственно 1 экземпляр сервера apache2 сможет работать только с 1 платформой, модуль которой загрузит первым.

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

  Основной каталог с конфигурацией Apache2 мы будем использовать как шаблон для остальных экземпляров сервера. Также остановим и выключим основную службу Apache2. Исправлять будем производные конфигурации. Инструкция по работе с такой конфигурацией есть в составе сервера и расположена в файле /usr/share/doc/apache2/README.multiple-instances, прочитать ее можно командой:

  Для начала создадим 1 экземпляр сервера с названием web, который и будет у нас отвечать на стандартном 80 порту:

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

  После чего остановим этот экземпляр сервера и отключим его:

  Включим и запустим наш первый созданный экземпляр web и проверим что он работает, а PGAdmin у нас открывается, как и раньше:

  Проверим, что служба запустилась и её статус:

  

  Служба запущена и работает. Откроем в браузере адрес pgadmin и чтобы убедиться что он работает http://192.168.12.112/pgadmin4.

  Теперь создадим еще 4 экземпляра сервера и добавим к ним суффикс, также как и к именам серверов 1С, то есть у нас будут экземпляры работающие на портах:

  • 1540 — port 8140.
  • 2540 — port 8240.
  • 3540 — port 8340.
  • 4540 — port 8440.

  Настройка Apache2 для 1С

  Перейдем к настройкам. Для удобства можно воспользоваться двухпанельным файловым менеджером Midnight Commander или просто mc. Запустим его от имени root, чтобы свободно перемещаться по файловой системе и править конфигурации сервера:

  

  Перейдем в каталог конфигурации, который будет использоваться для публикации конфигураций кластера 1С 1540, и откроем файл ports.conf на изменение клавишей F4.

  Исправим порт, на котором будет слушать наш сервер, а остальное закомментируем.

  Должно получиться следующее содержимое:

  

  Сохраняем по клавише F2 наши изменения и по ESC выходим из редактора mcedit.

  Теперь включим и запустим этот экземпляр, проверим, что он работает и отвечает на порту 8140. Чтобы переключится в режим командной строки нажимаем комбинацию клавиш Ctr+O, после чего вводим команды. Стоит обратить внимание, что теперь sudo мы не используем, т. к. и так все будет запущено от имени пользователя root:

  

  Так же проверим браузером, что по данному порту открывается стандартная страница web-сервера Apache2. По адресу http://192.168.12.112:8140/, должна отобразиться следующая страница:

  

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

  

  Далее опубликуем базу, что мы создавали в предыдущем разделе. Хоть она и пустая — для теста подойдет.

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

  И запускаем утилиту webinst соответствующей версии:

  Теперь включим созданную конфигурацию и попросим Apache2 перечитать конфиги:

  Теперь проверим, что отвечает по адресу нашей публикации:

  

  А также проверим из браузера:

  

  Далее настроим обратный прокси, чтобы наша публикация открывалась на стандартном 80 порту.

  Для начала включим модули proxy и headers для экземпляра apache2-web:

  Далее создаем файл /etc/apache2-web/conf-available/proxy.conf:

  Со следующим содержимым:

  После чего перезапускаем apache2-web и проверяем, работает ли по пути http://192.168.12.112/4540/testdb/ наша публикация:

  

  

  Публикация работает. По аналогии можно опубликовать и другие базы.

  Включаем SSL

  Теперь для защиты подключения к серверу настроим шифрование и перенаправление при подключении по не зашифрованному каналу на защищенный.

  Сначало необходимо приобрести сертификат или получить бесплатный сертификат Let’s Encrypt (letsencrypt.org) или ZeroSSL (zerossl.com).

  Мы будем использовать wildcard сертификат Let’s Encrypt полученный для всех узлов в домене lan.rarus.ru и rarus.ru.

  Важным условием работы сервера по защищенному каналу является настроенная служба DNS, которая выдаст IP-адрес по имени сервера или наличие в файле hosts FQDN имени сервера и его IP.

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

  Теперь на сервере перенесем ключи и сертификат в свои каталоги — fullchain.pem в каталог /etc/ssl/certs, а закрытый ключ privkey.pem в /etc/ssl/private. Назовем их так, чтобы было понятно, что это за сертификаты и ключи:

  Исправим права и владельца этих файлов, особенно это касается закрытого ключа:

  После чего исправим конфигурацию инстанса web:

  И добавим в него следующее содержимое после строки <VirtualHost *:80>:

  RewriteEngine On
  RewriteCond % !=on
  RewriteRule ^/?(.*) https://%/$1 [R,L]

  Сохраняем и правим следующий конфигурационный файл /etc/apache2-web/sites-available/default-ssl.conf:

  В строчках SSLCertificateFile и SSLCertificateKeyFile прописываем пути к нашим скопированным файлам. После чего включаем модуль ssl, для защищенного соединения, модуль rewrite, что бы работало перенаправление, и сайт default-ssl, после чего перезапускаем apache:

  Теперь проверим работает ли у нас все через защищенное соединение. Переходим по адресу http://FQDN_имя_сервера/4540/testdb/, нас автоматически перенаправит на https://FQDN_имя_сервера/4540/testdb/ и откроется база:

  

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

  Также опубликовать базы в интернете можно выделив серверу отдельный белый IP (не забыв настроить файрвол) или настроить отдельный сервер публикации, на котором не будет самих серверов 1С и баз данных, или настроить на отдельном сервере обратный прокси для перенаправления запросов на данный сервер.

  10. Установка сервера лицензирования СЛК

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

  Зайдем на сайт prom.licencecenter.ru, выберем последний комплект сервера для конечного пользователя, скопируем ссылку на загрузку в буфер обмена. Загружать и распаковывать дистрибутив будем непосредственно на сервере. Для загрузки файлов по http и ftp в GNU/Linux есть утилита wget.

  Перейдем в наш каталог с дистрибутивами:

  Создадим каталог для дистрибутива СЛК и перейдем в него:

  Скачаем дистрибутив по скопированной ссылке:

  После распаковки установим, как и делали ранее:

  Сервер установлен и запущен, проверим статус сервиса:

  

  Так же со своего компьютера зайдем на страничку управления сервером на порту 9099 — http://192.168.12.112:9099. Логин и пароль по умолчанию admin, рекомендуется его сменить.

  11. Заключение

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

  12. Ссылки

  • Ubuntu server 18.04.5 (releases.ubuntu.com/18.04.5/)
  • Postgrepro 1C (1c.postgres.ru)
  • Apache 2.4 (httpd.apache.org/download.cgi)
  • Дистрибутивы 1С (releases.1c.ru/project/Platform83)
  • PgAdmin (pgadmin.org)
  • Сервер СЛК (prom.licencecenter.ru)
  • Документация по Ubuntu Server (help.ubuntu.ru/wiki/руководство_по_ubuntu_server)
  • Документация по файлуsrv1cv83 (its.1c.ru/db/v8316doc#bookmark:adm:TI000000418)
  • Документация по postgresql pro (postgrespro.ru/docs/postgresql/12/index)
  • Оптимизация postgresql (pgtune.leopard.in.ua/#/)
  • Документация по Apache(eng) (httpd.apache.org/docs/2.2/)
  • Команды консоли Ubuntu (help.ubuntu.ru/wiki/командная_строка)
  • Tmux (tmuxguide.readthedocs.io/en/latest/tmux/tmux.html#help)
  • OpenSSH (man.openbsd.org/ssh)

  ВАЖНО: Читайте обновлённое руководство по установке сервера 1С под Linux в статье «От экспертов „1С‑Рарус“: Российские дистрибутивы Linux и установка в них сервера 1С» (январь 2023).

   
  Похожие публикации:

  1. Как открыть код программы exe
  2. Как посмотреть удаленные звонки на айфоне
  3. Как узнать какая версия 1с установлена на компьютере
  4. Почему нет интерпретатора в pycharm