Установка компонентов 1C в Linux
Компания 1С за время своего существования выпустила множество различных программ и баз данных, которые достаточно часто применяются не только в деловых сферах, но и используются для ведения домашних задач. Наиболее известным считается продукт 1С:Предприятие. После приобретения софта пользователь сталкивается с надобностью установки его в операционную систему для дальнейшей настройки и работы. Далее мы бы хотели пошагово разобрать выполнение этой процедуры в дистрибутивах ОС, разработанных на ядре Linux.
Устанавливаем компоненты 1C в Linux
Каждый юзер загружает на ПК только необходимые ему компоненты программного обеспечения после приобретения продукции на официальном сайте 1C. Мы хотим показать решение поставленной задачи на примере нескольких библиотек, учитывая процесс их дальнейшей подготовки для запуска. Что касается различий между дистрибутивами ОС, здесь необходимо придерживаться синтаксиса командной оболочки и при скачивании выбрать пакет подходящего формата. В остальном все действия остаются идентичными.
Шаг 1: Загрузка и установка компонентов
Изначально пользователю потребуется зарегистрироваться на официальном сайте компании и приобрести компоненты через встроенный магазин. После этого в личном профиле откроется раздел с перечнем доступных для загрузки библиотек. Вот с их скачивания и следует начать процедуру подготовки системы для работы с программным обеспечением.
- Перейдите по указанной выше ссылке, чтобы отыскать подходящие релизы. Нажмите на интересующие компоненты и загрузите подходящие пакеты для своего дистрибутива, это может быть DEB или RPM-пакет.
- Перейдите в файловый менеджер и убедитесь в том, что все пакеты хранятся в одной директории. Так будет гораздо проще осуществлять инсталляцию.
Если во время установки каких-либо компонентов у вас возникли ошибки, потребуется добавить в систему дополнительную утилиту, чтобы исправить все неполадки. Осуществляется это буквально в несколько кликов:
- Пропишите в консоли sudo apt-get install libwebkitgtk-1.0-0 и нажмите на клавишу Enter.
- Подтвердите добавление новых файлов, выбрав вариант Д.
- По окончании инсталляции введите sudo apt-get -f install .
Осталось только перезагрузить операционную систему и повторить процедуру инсталляции.
Каждый скачанный пакет потребуется установить точно таким же образом, меняя в команде только название. Перемещайтесь к следующему шагу только после добавления всех компонентов.
Шаг 2: Настройка 1С и ключей лицензии
Сразу же после завершения инсталляции работать с софтом не получится, ведь нужно настроить саму оболочку и лицензионные ключи. Делается это путем добавления определенных утилит и инструментов в саму систему. Как обычно, придется воспользоваться терминальными командами.
- В первую очередь пропишите sudo apt-get install imagemagick , введите пароль и дожидайтесь окончания добавления файлов.
- Далее укажите sudo apt-get install unixodbc и подтвердите уменьшение дискового пространства после совершаемой операции.
- Теперь внедряется другая библиотека через sudo apt-get install libgsf-bin .
- Напоследок остается дополнение t1utils, устанавливаемое через команду sudo apt-get install t1utils .
- Настройте конфигурационный файл 1C, добавив в него новые данные, введя sudo /opt/1C/v8.3/i386/utils/config_system /usr/share/fonts .
Как известно, работа во многих программах от 1C производится с помощью баз данных, поэтому последним шагом будет именно создание такого каталога.
Шаг 3: Создание базы данных
Одна или несколько информационных баз обязательно нужны для корректной работы с программным обеспечением 1С. Поэтому пользователю понадобится освоить взаимодействие с кластерами сервера. Первоначально следует запустить его через команду /opt/1C/v8.3/i386/ras —daemon cluster , где /opt/1C/v8.3/i386/ras — путь к серверу.
Теперь из кластера необходимо получить идентификатор, введя /opt/1C/v8.3/i386/rac cluster list . За создание новой базы данных отвечает достаточно объемная команда и выглядит следующим образом:
/opt/1C/v8.3/i386/rac infobase —cluster=»Идентификатор_Вашего_Кластера_Серверов» create —create-database —name=»Имя_Информационной_Базы» —dbms=»Тип_СУБД» —db-server=»Имя_Сервера_Баз_Данных» —db-name=»Имя_Базы_Данных» —locale=ru —db-user=»Имя_Администратора» —db-pwd=»Пароль_Администратора» —license-distribution=allow
Указанные выражения в кавычках требуется заменить на подходящие.
После завершения всех трех шагов вы смело можете запускать софт через иконки, которые были добавлены в меню, выполнять аутентификацию и приступать к работе в программе. Крайне рекомендуем обращать внимание на все уведомления, показываемые в «Терминале». Иногда они свидетельствуют о появлении неполадок, и своевременное обнаружение ошибки позволит быстрее от нее избавиться.
Записки IT специалиста
Единый дистрибутив 1С:Предприятие для Linux. Установка клиента
- Автор: Уваров А.С.
- 14.10.2021
Установка клиентской платформы 1С:Предприятие на платформе Linux являлась достаточно непростой задачей, особенно для пользователей, не имеющих достаточного опыта администрирования системы. Начиная с платформы 8.3.20 фирма 1С кардинально пересмотрела свой подход, отказавшись от выпуска отдельных пакетов для разных видов дистрибутивов (DEB и RPM) и представив единый дистрибутив 1С:Предприятие для Linux. Шаг вполне ожидаемый, 1С сейчас активно развивает поддержку данной ОС в своих приложениях. Остается разобраться как все это работает, начнем с клиента.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
В настоящее время на портале ИТС опубликована платформа версии 8.3.20.1549, которая предлагает для скачивания единый дистрибутив в вариантах для 32-х и 64-битных систем. Мы будем использовать 64-х битную платформу, которую попробуем установить на Ubuntu 20.04 LTS, но все сказанное ниже будет справедливо для любого поддерживаемого 1С дистрибутива Linux с поправкой на особенности работы пакетного менеджера.
Архив с единым дистрибутивом имеет наименование вида server64_8_3_20_1549.tar.gz, где 64 указывает на архитектуру пакета, а 8_3_20_1549 — является версией платформы. Распаковав его, мы обнаружим .run файл дистрибутива платформы и два файла с описанием и лицензией для Liberica JDK, входящей в состав дистрибутива.
Если запустить run-файл двойным кликом, то даже запустится установка, но дистрибутив не умеет запрашивать повышение прав, поэтому попытка завершится неудачей. Надеемся в будущих версиях это будет исправлено, так как консоль — это далеко не то место, куда следует отправлять обычного пользователя. А обновление платформы — задача весьма частая и не представляющая особых затруднений, во всяком случае на платформах Windows и macOS.
Хорошо, запускаем в папке с дистрибутивом терминал, для этого можно кликнуть правой кнопкой мыши и выбрать во всплывающем меню пункт Открыть в терминале:
Затем можно либо сразу повысить права до суперпользователя, либо выполнить установку через sudo, последнее более предпочтительно, так как с повышенными правами нам требуется выполнить разовое действие.
В процессе установки программа установки может отобразить список пакетов, которые требуются для корректной работы системы «1С:Предприятие». Этот список формируется в том случае, если программа установки не обнаружила эти пакеты на компьютере. Вам следует самостоятельно установить недостающие пакеты (из выданного списка) с помощью пакетного менеджера используемой операционной системы. Для этой установки потребуются права суперпользователя (root).
При этом большинство зависимостей уже включено в пакет поставки, хотя это и идет вразрез в принятыми в среде Linux соглашениями и принципами. С другой стороны, это по-всякому лучше, чем устанавливать в ОС пакеты от предыдущей версии только потому, что их безальтернативно требует 1С:Предприятие. В нашем случае никаких дополнительных пакетов не потребовалось.
В Debain 11 перед установкой нужно добавить репозиторий от предыдущего выпуска для установки библиотеки libenchant1c2a, иначе процесс завершится с ошибкой:
Графический установщик 1С:Предприятия выполнили максимально похожим на свой Windows-аналог, поэтому сам процесс установки не должен вызвать никаких затруднений.
Видно, что разработчики проделали большую работу по приданию Linux-дистрибутиву «человеческого лица» и если еще будет корректно реализован запрос на повышение прав, то основная задача будет выполнена. Для установки платформы достаточно будет скачать дистрибутив и запустить его двойным кликом. А это значит, что Linux станет еще немного ближе к простому пользователю.
После установки будут добавлены ярлыки для программы запуска, толстого и тонкого клиента. Они относятся к подкатегории Finance категории Office. В окружении рабочего стола Gnome, который используется по умолчанию в Ubuntu и Debian, ярлыки добавляются в общую панель запуска и определить какой из них за что отвечает с первого взгляда довольно сложно, но если добавить их в Избранное (на боковую панель), то появляется всплывающая подсказка. Таким образом можно выяснить, что ярлыки идут в следующем порядке: толстый клиент, тонкий клиент, программа запуска. Запускать 1С:Предприятие следует через третий ярлык, его же советуем вывести в Избранное.
Но если мы запустим платформу, то с удивлением увидим довольно неприглядную картину, со шрифтами все окажется очень плохо:
Несмотря на заявленный контроль зависимостей инсталлятор не проверяет наличие шрифтов Microsoft Core Fonts и никак не сообщает об этом. Но, к счастью, это несложно исправить. Обратите внимание, что данные шрифты относятся к несвободному ПО и в Debian вам потребуется подключить репозитории. Это можно сделать как в графическом режиме, запустив приложение Software & Updates и выбрав в нем репозитории contrib и non-free:
так и в терминале, открыв файл /etc/apt/sources.list и добавив в каждую строку после main contrib и non-free:
Теперь следует обновить список пакетов и установить шрифты Microsoft, команду следует выполнить с правами суперпользователя или через sudo:
Снова запустим 1С:Предприятие, как видим со шрифтами все стало нормально.
Следует также отметить, что начиная с платформы 8.3.18 возможна установка сразу нескольких версий 1С:Предприятие на Linux, установка производится в /opt/1cv8/i386/8.3.xx.xxxx или /opt/1cv8/x86_64/8.3.xx.xxxx и со временем возможно накопление неиспользуемых версий платформы. Для их удаления следует воспользоваться скриптом деинсталляции, который называется uninstaller-full и расположен в директории платформы. Так для удаления только что установленной 8.3.20.1549 выполните с правами суперпользователя или через sudo:
После чего указанная версия платформы будет полностью удалена:
В целом работа с единым дистрибутивом нам понравилась, сделан большой шаг навстречу простым пользователям, приближая платформу Linux по удобству использования к привычным альтернативам на Windows и macOS.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Установка сервера 1С, Postgresql и терминального сервера для клиентских приложений 1С на ОС Fedora Linux
На настоящий момент фирма 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 Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2016
Fedora Core 30.1.2
Red Hat Enterprise Linux 7
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 и помещаем в его в заранее созданный для этого каталог, например, как предлагается в инструкции,
Забегая немного вперёд, можно сказать, что для сборки 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-пакетом:
И распаковываем его для дальнейшей компиляции:
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 в каталог
Написано всё правильно, только в нашем случае это будут файлы postgresql-14.4.tar.bz2 и postgresql-14.spec.
Все распакованные файлы (кроме postgresql-14.spec) мы перемещаем или копируем, как там и написано, в
/rpmbuild/SOURCES, включая и файл postgresql-14-A4.pdf. Файл postgresql-14.spec помещаем в
Теперь можно запускать процесс компиляции. В статье на портале предлагают сделать это командой rpmbuild -ba, а затем «информация о ходе сборки будет выводиться на экран. После её завершения автоматически запустятся регрессионные тесты сформированных пакетов, статус их выполнения также будет выведен. В случае ошибки сборка будет прекращена. В случае успешного её завершения бинарные rpm-пакеты будут находиться в директории
/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 данного описания будет достаточно.
Следующей темой, по всей видимости, должно быть подключение фискальных регистраторов к такому серверу и организация рабочего места кассира.
Спасибо за внимание, работайте на правильных операционных системах.
PostgreSQL+1C на Ubuntu Linux
Рассмотрим установку PostgreSQL+1С на Ubuntu — актуальная на 2023 год сборка.
В данной инструкции задействована ВМ с ОС Ubuntu Server 22.04 LTS. Рекомендованные минимальные характеристики для данных сервисов следующие: 6 ядер ЦП, 60 ГБ системный диск SSD и как минимум 12 ГБ ОЗУ. Однако, ресурсы следует рассчитывать из дальнейшего сценария использования и количества пользователей, работающих в базах.
Установка PostgreSQL
Если установлена английская версия Ubuntu, то требуется переконфигурировать локали с помощью команды:
И выбрать ru_RU.UTF-8 UTF-8 (по умолчанию число номер 392), а затем перезагрузить сервер.
Далее приведена последовательность действий, необходимых для успешной установки PSQL:
-
Добавить репозиторий последней актуальной версии PSQL (на момент написания данной инструкции таковой является 15.4)
Раскомментируем эту строчку и присваиваем ей следующее значение:
Создаём отдельную директорию (например, /var/lib/postgesqldb ) и монтируем раздел нашего SSD-диска (в нашем случае — это /dev/sda2).
Отключаем службу psql:
Находим строчку data_directory и заменяем значение на ‘/var/lib/postgesqldb’. После чего инициализируем там кластер PSQL:
И заодно добавим в fstab директорию для хранения баз, чтобы она не размонтировалась при следующем перезапуске. Для этого нужно зайти в blkid и найти UUID раздела.
Заходим в /etc/fstab:
И добавляем следующую строчку:
(Где иксы заменяем на UUID раздела, который нашли в blkid).
При необходимости открыть доступ к базе извне, вместо all all указываем базу данных и пользователя соответственно, а подсеть заменяем на 0.0.0.0/0.
Если всё настроено правильно, то будет следующий вывод:
Рисунок 1 — Проверка работы службы PostgreSQL
Вместо postgrespwd можем указать свой пароль.
Установка сервера 1С
- Скачиваем нужную нам версию сервера 1С на портале ИТС.
- Распаковываем с помощью tar архив и запускаем файл .run:
Если всё настроено корректно, получим примерно такой вывод:
Рисунок 2 — Проверка работы службы 1C
Убедившись, что всё работает, устанавливаем службу:
Подключение базы 1С
Создать базу 1С можно и в терминале Linux через команду, однако, для удобства, мы воспользуемся оснасткой администрирования сервера 1С, установленной на соседнюю машину на ОС Windows Server.
- Перед тем как присоединять базу, если компьютеры не объединены в домен Active Directory, рекомендуется внести имя сервера СУБД и его IP-адрес в «C:\Windows\System32\drivers\etc\hosts», иначе возможно получение ошибки “Этот хост неизвестен” в 1С.
- Не пытайтесь создать пустую базу в PSQL, а затем подключить её в оснастке 1С! Для PostgreSQL базы 1С не являются нормальными, поэтому все базы создаются средствами 1С, как описано ниже.
- Заходим в оснастку администрирования и добавляем Центральный Сервер 1С. В имени сервера вводим имя или IP-адрес сервера СУБД, на котором устанавливали 1С.
- Далее заходим в кластер и добавляем базу: Правой кнопкой мыши нажать на “Информационные базы (Далее ИБ)” > “Создать” > “ИБ”. Заполняем поля:
Рисунок 3 — Параметры информационной базы
Мы добавили ИБ для запуска, можно заходить в конфигуратор и загружать имеющую конфигурацию. Итак, структура готова к работе в 1С.
Нужна помощь? Администрирование linux-серверов и PostgreSQL мы осуществляем в рамках услуги администрирование серверов.