Инструкция по установке 1с на сервер

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

 Понятие клиент-серверной 1С

На самом деле 1С всегда работает в варианте клиент-сервер. Но в случае, когда работа осуществляется на локальном компьютере (файловый вариант) 1С сама делит память компьютера на условно-клиентскую и условно-серверную часть и использует свою встроенную систему управления базами данных. В клиентской части формируются запросы к 1С, затем передаются в серверную и там обрабатываются, результат возвращается обратно в клиентскую. Однако принято называть это файловым вариантом работы с базой.

Вариант работы с 1С называется клиент-серверным тогда, когда для работы с базой используют сторонние СУБД. 1С поддерживает работу с: IBM DB2, MS SQL, Oracle DB, PostgreSQL. Сторонние системы управления базами данных являются намного более мощными по сравнению со встроенными в 1С и обеспечивают лучшее быстродействие, а также повышают защищенность баз. Далее в статье мы будем рассматривать внедрение клиент-серверной архитектуры на базе MS SQL. Именно SQL считается лучшим для работы с 1С. Postgree, например, требует частого реиндексирования баз, DB2, в сравнении со своими конкурентами, имеет существенные ограничения по максимальной длине числа, а Oracle имеет известные проблемы с упорядочиванием данных.

Когда стоит переносить базу из файлового варианта в серверный?

• Если с базой работают до 5-7 человек и база имеет небольшой размер — достаточно файлового варианта.
• Если с базой работают 8-12 человек и вес базы приближается к 4Гб, то имеет смысл задуматься о переходе на “клиент-сервер.” В данном случае многое зависит от личных ощущений от работы с базой при большом одновременном количестве пользователей. Дело в том, что при работе в базе каждый пользователь, обращаясь к регистрам, блокирует доступ к ним для других пользователей и другие пользователи, при попытке обращения к заблокированному регистру, встают в очередь. А в это время 1С висит. Поэтому, если подвисания при большом количестве пользователей начинают мешать работе, пора совершенствовать архитектуру.
• Если с базой работают более 15 человек и размер базы более 4Гб, то клиент-сервер необходим.

Установка клиент-серверной 1С

Для того, чтобы развернуть клиент-серверную 1С необходимо выполнить несколько шагов.

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

 Рассмотрим каждый шаг подробно.

Установить MS SQL на сервер

На сервере, или мощном компьютере, который будет работать как сервер, запустите файл “setup.exe” из папки/диска с дистрибутивом SQL. В случае, если на компьютере нет компоненты Microsoft.NET Framework установщик выдаст предупреждение. Нужно обновить операционную систему, либо просто скачать и установить framework с официального сайта Microsoft. Это бесплатно.

После запуска установщика, потребуется ввести лицензионный ключ продукта, затем, как всегда, внимательно прочитать текст лицензионного соглашения, отметить галочку “Я согласен, принимаю” и двигаться далее.

На этапе выбора компонент, если вы собираетесь использовать SQL только для работы с 1С, имеет смысл оставить всего несколько галочек: напротив “Службы компонента Database Engine”, Средства связи клиентских средств (или “Client Tool Connectivity” для английской версии) и Средства управления (Management Tool). Другие компоненты SQL при работе с 1С не используются, их устанавливать не нужно.

Нажимайте “Далее”.

На закладке “Параметры сортировки” Конфигурации сервера проверьте, что выбрано “Cyrillic_General_CI_AS”.

В “Конфигурации сервера” отметьте “Смешанный режим”, как показано на рисунке, и введите пароль для суперпользователя SQL (Логин суперпользователя: sa). На этой же закладке укажите администратора данного экземпляра SQL, их может быть несколько.

На соседней закладке “Каталоги данных” выберите для пользовательских баз данных и баз данных TEMP расположение на максимально производительных дисках (например на SSD, желательно на RAID)

Нажимайте “Далее” и “Установка”. Дальнейшие настройки можно оставить по умолчанию. Дождитесь завершения установки и SQL готов к работе.

Установить платформу 1С на сервер

Установка платформы 1С описана в другой нашей статье — “Администрирование 1С”, в разделе “Установка 1С”. Установка на сервер почти полностью совпадает с установкой на локальный компьютер, с одной лишь разницей. В серверном варианте при выборе устанавливаемых компонент необходимо выбрать “Сервер 1С:Предприятия” и “Администрирование сервера 1С:Предприятия”.

Установить 1С на клиентских компьютерах, с которых будет осуществляться подключение к серверу

Установка на клиентских компьютерах ничем не отличается от способа, описанного ранее в статье “Администрирование 1С”.

Оставьте заявку на консультацию

Создать информационную базу в SQL

Создание информационной базы в SQL тоже очень похоже на создание базы в файловом варианте. Разница заключается в том, что на этапе выбора типа расположения информационной базы необходимо выбрать “На сервере 1С:Предприятия”.

И далее задать необходимые параметры.

В пункте “Кластер серверов” укажите имя (а лучше IP-адрес) сервера, на который устанавливали SQL.

В пункте “Имя информационной базы” укажите любое имя, которое хотите дать базе.

Тип СУБД — SQL.

Пользователь базы данных и его пароль — тот самый суперпользователь, о котором говорилось выше, на этапе установки MS SQL.

Смещение дат оставьте по умолчанию.

Необходимо отметить пункт “Создать базу данных в случае ее отсутствия” и нажать “Далее”.

Теперь база успешно создана на сервере SQL и добавлена в список доступных баз. Внизу на картинке можно увидеть результат проделанной работы.

Стоить отметить, что созданная база пока еще пустая. Это каркас, место, выделенное в SQL под вашу информационную базу. Для того, чтобы загрузить свою базу в этот каркас — необходимо воспользоваться средствами Выгрузки/Загрузки информационной базы. Процедура Выгрузки/Загрузки также описана в другой нашей статье “Администрирование 1С”.

Для того, чтобы довести систему до идеального состояния в дальнейшем необходимо будет настроить “план обслуживания” созданной базы данных. План обслуживания — это набор процедур, которые SQL будет выполнять регулярно по заданному расписанию. Например, будет регулярно делать резервные копии и удалять временные файлы. Работа с SQL выходит за рамки темы статьи и будет описана в одной из следующих.

Мы также готовы оказать помощь в установке и настройке сервера 1С, оптимизации.

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

Открываем папку с файлами установки сервера «1С:Предприятие» и нажимаем на файл setup.exe.

Запуститься помощник установки «1С:Предприятия». Нажимаем «Далее».

На следующей странице требуется выбрать те компоненты, которые будут установлены:

• «Сервер 1С:Предприятие» — компоненты сервера «1С:Предприятие»
• «Администрирование сервера 1С:Предприятия» — дополнительные компоненты для администрирования серверов «1С:Предприятия»

Сделав выбор, нажимаем «Далее».

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

Если сервер «1С:Предприятие» устанавливается как служба Windows (а так в большинстве случаев и следует его устанавливать) — рекомендуем сразу создать отдельного пользователя, из-под которого будет запускаться эта служба.

• Оставляем включенным флаг «Установить сервер 1С:Предприятие как сервис Windows (рекомендуется)».
• Переключаем соответствующий переключатель в «Создать пользователя USR1CV8».
• Вводим 2 раза пароль для создаваемого пользователя. По умолчанию пароль должен отвечать политики паролей Windows.
• Можно также и выбрать существующего пользователя для запуска сервера «1С:Предприятия». В этом случае выбранный пользователь должен обладать правами:
  • Вход в систему как сервис (Log on as a service);
  • Вход в систему как пакетное задание (Log on as a batch job);
  • Пользователи журналов производительности (Performance Log Users).

Также данному пользователю обязательно следует дать необходимые права на каталог служебных файлов сервера (по умолчанию C:Program Files1cv8srvinfo для 64-х разрядного и C:Program Files (x86)1cv8srvinfo для 32-х разрядного сервера).

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

Заполнив соответствующие параметры, жмем «Далее».

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

По завершении установки помощник предложит установить драйвер защиты — HASP Device Driver. Если используется программная лицензия на сервер «1С:Предприятия», производить установку драйвера нет необходимости. Оставляем или снимаем флаг «Установить драйвер защиты» и жмем «Далее».

Если установка завершена успешно, откроется последняя страница помощника установки. Нажимаем «Готово» для завершения работы мастера.

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

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

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

На следующем этапе необходимо указать смешанный режим проверки подлинности и указать пароль пользователя sa, а также добавить пользователя Windows, которые будет иметь право администрировать СУБД.

На вкладке «Каталоги данных» необходимо указать дефолтное размещение пользовательских баз данных, а также указать каталоги системных баз данных. Для повышения производительности SQL Server желательно разносить функционально разные базы данных. Так на отдельные физические диски необходимо разносить пользовательские данные, журнал пользовательских баз данных, базу данных temp и ее журнал. Также возможно указать дефолтный каталог для хранения резервных копий баз данных.

Если все сделано правильно, остается прощелкать кнопку «Далее» и дождаться установки SQL Server.

3.1. Включаем режим Shared memory.

«Shared Memory» включится только на платформе начиная с 1С 8.2.17, на более ранних релизах включится «Named Pipe» – несколько уступающий в скорости работы. Актуально, если службы 1С и MS SQL установлены на одном физическом или виртуальном сервере.

3.2. Настройка кластера 1С:Предприятие.

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

• Интервал перезапуска – отвечает за частоту перезапуска рабочих процессов кластера. Автоматический перезапуск был разработан в платформе «для минимизации отрицательных последствий фрагментации и утечки памяти в рабочих процессах». Однако, автоматический перезапуск может приводить к разрыву соединений в активных сессиях, поэтому в некоторых случаях предпочтительнее регламентные операции по перезапуску процессов 1С и очистке серверного кэша проводить вручную, либо с помощью скрипта.
• Допустимый объем памяти – защищает сервера 1С от перерасхода памяти. При превышении процессом этого объема в интервале превышения допустимого объема, процесс перезапускается. По сути – это максимальный размер ОЗУ, занимаемый процессами «rphost» в периоды пиковой нагрузки серверов. Рекомендуется установить небольшой порог превышения допустимого объема.
• Допустимое отклонение количества ошибок сервера. Платформа рассчитывает среднее количество ошибок сервера по отношению к числу обращений к серверу в течение 5 минут. Если это отношение превысит допустимое, то рабочий процесс считается «проблемным», и может быть завершен системой, если установлен флаг «Принудительно завершать проблемные процессы».
• Выключенные процессы останавливать через « ». При превышении допустимого объема памяти, рабочий процесс не завершается сразу, а становится «выключенным», чтобы было время «перенести» рабочие данные без потери на новый запущенный рабочий процесс. Если указан этот параметр, то «выключенный» процесс в любом случае завершится по истечении этого времени. Если наблюдаются «зависшие» рабочие процессы в работе сервера 1С, то рекомендуем рассмотреть использование данного параметра путем установки таймера на 3-5 минут.

3.3. Настройка сервера 1С:Предприятие.

Эти настройки устанавливаются для каждого сервера 1С персонально.

• Максимальный объем памяти рабочих процессов – это объем совокупной памяти, которую могут занимать рабочие процессы (rphost) на текущем кластере.
  • Если параметр установлен в «0», то процесс может потреблять до 80% ОЗУ сервера.
  • Если «1» — без ограничений.

  Когда на одном сервере работают СУБД и сервер 1С, им нужно делить между собой оперативную память. Если в процессе эксплуатации выяснится, что серверу СУБД не хватает ОЗУ, то с помощью этого параметра есть возможность вручную ограничить память, выделяемую серверу 1С:Предприятие.

• Безопасный расход памяти за один вызов. Отдельные вызовы процедур не должны занимать всю оперативную память, выделенную рабочему процессу.
  • Если параметр установлен в «0», то объем безопасного расхода ОЗУ будет равен 5 % от «Максимального объема памяти рабочих процессов».
  • «1» — без ограничения, что крайне не рекомендуется. В большинстве случаев этот параметр лучше оставлять «0».
• С помощью параметров «Количество ИБ на процесс» и «Количество соединений на процесс» можно управлять распределением работы сервера 1С:Предприятие по рабочим процессам rphost. Например, запускать под каждую информационную базу отдельный «rphost». Эти параметры стоит подбирать индивидуально под каждую конфигурацию сервера 1С.

4.1. Настройка SQL сервера.

• Включаем Shared memory (показано на картинке). Актуально если службы 1С и MSSQL установлены на одном физическом или виртуальном сервере.

Проверить можно, выполнив запрос:

select program_name, net_transport 
from sys.dm_exec_sessions as t1 
left join sys.dm_exec_connections AS t2 
ON t1.session_id=t2.session_id 
where not t1.program_name is null

• Устанавливаем максимально отведенное серверу количество памяти.

• Устанавливаем сжатие БД при резервном копировании и дефолтные места для хранения файлов БД

4.2. Настройка Базы данных.

После того, как сервер СУБД оптимизирован – переходим к настройкам баз.

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

4.3. Настройка регламентных заданий.

• Ежедневные:
  • Дефрагментация

  Например: ежедневно (кроме субботы) в 22:00

• Еженедельные:
  • Реиндексация

  Например: запускается раз в неделю в субботу в 22.00

В данной статье приводится подробная пошаговая инструкция по установке сервера системы «1С:Предприятия» 8.3 (в версиях 8.1 и 8.2 набор действий аналогичен) в операционных системах семейства Windows (Windows Server 2008 (R2) или Windows Server 2012) на СУБД MS SQL Server (Microsoft SQL Server 2008 R2 или Microsoft SQL Server 2012).

0. Оглавление

1. Начальные сведения
2. Установка СУБД MS SQL Server
3. Настройка Брандмауэра Windows для работы СУБД
4. Добавление пользователя в MS SQL Server
5. Установка сервера «1С:Предприятия»
6. Настройка Брандмауэра Windows для работы сервера «1С:Предприятие»
7. Установка лицензий
8. Заключение

1. Начальные сведения

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

Где:

• Клиентские приложения, тонкие клиенты и веб-клиенты — это и есть «1С:Предприятие» в различных режимах запуска, с которыми работает конечный пользователь. Для клиентских приложений и тонких клиентов требуется установка клиента «1С:Предприятия» на компьютеры пользователей (или на сервер терминалов), для веб-клиента достаточно веб-браузера.
• Кластер серверов «1С:Предприятие» представляет собой совокупность рабочих процессов, функционирующих на одном или нескольких компьютерах и списка информационных баз, которые размещены в этом кластере. В кластере серверов выполняется вся работа прикладных объектов, выполняется подготовка к отображению форм (чтение объектов информационной базы, заполнение данных форм, расположение элементов и т.д.) и командного интерфейса, формируются отчеты, выполняются фоновые задания. На клиентах происходит лишь отображение информации, подготовленной в кластере серверов. Кроме того на сервере кластера «1С:Предприятия» хранятся служебные файлы, а также журнал регистрации информационных баз.
• Сервер баз данных — на сервере баз данных происходит непосредственное хранение и работа с данными, обеспечиваемое одной из следующих, поддерживаемых системой «1С:Предприятие», систем управления базами данными (СУБД):
  • Microsoft SQL Server начиная с версии Microsoft SQL Server 2000 и выше;
  • PostgrageSQL начиная с версии 8.1;
  • IBM DB2 начиная с версии 9.1;
  • Oracle Database начиная с версии 10g Release 2.
• Веб-сервер необходим только для работы веб-клиентов и одного из вариантов работы тонкого клиента. Обеспечивает взаимодействие данных видов соединения с кластером серверов «1С:Предприятия».

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

В данной статье я буду описывать установку сервера «1С:Предприятия» версии 8.3.4.389 (для других версий платформы «1С:Предприятие» 8.1, 8.2 и 8.3 действия аналогичны) на один компьютер под управлением Windows Server 2008 (R2) или Windows Server 2012 (R2). В качестве СУБД будет рассматриваться Microsoft SQL Server 2008 (R2) или Microsoft SQL Server 2012. Для этого нам понадобится:

1. Компьютер, отвечающий системным требованиям для установки сервера «1С:Предприятия» и с установленной на данный компьютер ОС Windows Server 2008 (R2) или Windows Server 2012.
2. Компьютер для сервера баз данных, также под управлением ОС Windows Server 2008 (R2) или Windows Server 2012 (может быть компьютером из п.1).
3. Права локального администратора на обоих компьютерах.
4. Дистрибутив для установки сервера «1С:Предприятия» 8.
5. Программная лицензия или ключ защиты HASP4 Net для сервера «1С:Предприятия».
6. Дистрибутив для установки Microsoft SQL Server 2008 (R2) или Microsoft SQL Server 2012.

2. Установка СУБД MS SQL Server

Устанавливаем СУБД  MS SQL Server на компьютер, служащий сервером баз данных. Для работы системы «1С:Предприятие» достаточно установки компонент:

• Службы компонента Database Engine (Database Engine Services)
• Средства управления — основные (Management Tools — Basic)
  • Средства управления — полный набор (Management Tools — Complete).

Параметры сортировки выбираем «Cyrillic_General_CI_AS». Подробно про установку систем

• Microsoft SQL Server 2008 (R2) я писал здесь.
• Microsoft SQL Server 2012 я писал здесь.

3. Настройка Брандмауэра Windows для работы СУБД

Если сервер баз данных и сервер кластера «1С:Предприятия» находятся на разных физических компьютерах, необходимо на сервере баз данных настроить Брандмауэр Windows таким образом, чтобы сервер «1С:Предприятия» мог работать с СУБД, а именно открыть входящие подключения по порту 1433 (для экземпляра SQL Server по умолчанию).

• Подробно про настройку Брандмауэра Windows для работы Microsoft SQL Server 2008 (R2) / 2012 я писал здесь.

4. Добавление пользователя в MS SQL Server

Далее добавим в MS SQL Server отдельного пользователя, под которым будут подключаться базы данных сервера «1С:Предприятия». Этот пользователь будет также владельцем этих баз данных. Добавляемый пользователь должен авторизовываться на сервере с помощью пароля и обладать набором ролей: dbcreator, processadmin, public. Подробно про добавление пользователя на

• Microsoft SQL Server 2008 (R2) я писал здесь.
• Microsoft SQL Server 2012 я писал здесь.

5. Установка сервера «1С:Предприятия»

Теперь переходим к установке файлов сервера «1С:Предприятия» и запуску соответствующей службы. Для установки требуется дистрибутив технологической платформы «1С:Предприятия». Из перечня поставляемых дистрибутивов подойдут следующие:

• Технологическая платформа 1С:Предприятия для Windows — позволяет установку 32-разрядного сервера «1С:Предприятия»
• Сервер 1С:Предприятия (64-bit) для Windows — позволяет установку как 32-разрядного, так и 64-разрядного сервера «1С:Предприятия»

(Также существует и расширенная версия КОРП сервера 1С:Предприятия 8.3, подробности можно посмотреть на сайте 1С)

Открываем каталог с файлами установки сервера «1С:Предприятия» и запускаем файл setup.exe.

Запуститься помощник установки системы «1С:Предприятия». На первой странице жмем «Далее».

На следующей странице необходимо выбрать те компоненты, которые будут устанавливаться, нам требуются компоненты:

• Сервер 1С:Предприятия — компоненты сервера «1С:Предприятия»
• Администрирование сервера 1С:Предприятия 8 — дополнительные компоненты для администрирования кластера серверов «1С:Предприятия»

Остальные компоненты (перечень компонент может зависеть от конкретного дистрибутива), в зависимости от необходимости, также могут быть установлены на данный компьютер. Сделав выбор жмем «Далее».

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

Если сервер «1С:Предприятия» устанавливается как служба Windows (а так в большинстве случаев и следует его устанавливать) рекомендую сразу создать отдельного пользователя, из под которого будет запускаться создаваемая служба. Для этого

• Оставляем включенным флаг «Установить сервер 1С:Предприятие как сервис Windows (рекомендуется)»;
• Переводим соответствующий переключатель в «Создать пользователя USR1CV8».
• Вводим 2 раза пароль для создаваемого пользователя. По умолчанию пароль должен отвечать политики паролей Windows. Подробнее об этом можно прочитать:
  • Для Microsoft Windows Server 2008 (R2) — здесь;
  • Для Microsoft Windows Server 2012 — здесь.

Можно также и выбрать существующего пользователя для запуска сервера «1С:Предприятия». В этом случае выбранный пользователь должен обладать правами:

• Вход в систему как сервис (Log on as a service)
• Вход в систему как пакетное задание (Log on as a batch job)
• Пользователи журналов производительности (Performance Log Users).

Также пользователю обязательно следует дать необходимые права на каталог служебных файлов сервера (по умолчанию C:Program Files1cv8srvinfo для 64-х разрядного и C:Program Files (x86)1cv8srvinfo для 32-х разрядного сервера).

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

Заполнив соответствующие параметры, жмем «Далее».

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

По завершении установки помощник предложит установить драйвер защиты  — HASP Device Driver. Если используется программная лицензия на сервер «1С:Предприятия», производить установку драйвера нет необходимости. Оставляем или снимаем флаг «Установить драйвер защиты» и жмем «Далее».

Если установка завершена успешно, откроется последняя страница помощника установки. Нажимаем «Готово» для завершения работы мастера.

Убедимся также что появилась и запущена соответствующая служба.

6. Настройка Брандмауэра Windows для работы сервера «1С:Предприятие»

Если к серверу «1С:Предприятия» будут подключаться пользователи через толстый и тонкий клиенты с других компьютеров в сети (а так скорее всего и будет), необходимо позаботиться, чтобы на компьютере, где запущен сервер «1С:Предприятия» были разрешены входящие подключения для портов 1541, 1560—1591. О том как добавить разрешающее правило в Брандмауэр Windows я писал

• Для Microsoft Windows Server 2008 (R2) — здесь;
• Для Microsoft Windows Server 2012 — здесь.

7. Установка лицензий

Теперь пришло время установки программной лицензии на сервер «1С:Предприятия», либо настройка серверного ключа защиты HASP Net 4.

• Подробно, про систему программного лицензирования «1С:Предприятие» 8 я писал здесь. Про первичную установку программных лицензий — здесь.
• Про назначение, установку и администрирование ключей защиты HASP4 Net для «1С:Предприятие» 8 можно прочитать здесь.

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

На этом установка кластера серверов «1С:Предприятие» на СУБД MS SQL Server завершена. Теперь можно переходить к следующим этапам развертывания инфраструктуры «1С:Предприятия», таким как:

• Установка клиентских приложений «1С:Предприятие»
• Установка шаблонов конфигураций
• Добавление баз данных на сервер «1С:Предприятие»
• Настройка веб-доступа к базам данных «1С:Предприятие» 8.3

Пошаговое руководство по установке и первичной настройке сервера 1С:Предприятия 8.3 версии 8.3.19.1229 в ОС Microsoft Windows Server 2019 Standard с использованием СУБД PostgreSQL-11.7-5-1C и системы защиты HASP (USB-ключа).

Подготовка

Запускаем службу Вторичный вход в систему и в свойствах выбираем Запускать автоматически

# services.msc

На машинах, где будет установлено 1С-Предприятие, открываем в блокноте с правами администратора сервера файл C:WindowsSystem32driversetchosts и допишем в нём:

192.168.1.15	SRV15

• 192.168.1.15 — IP-адрес сервера
• SRV15 — имя хоста сервера

Скачиваем с официального ресурса 1С https://releases.1c.ru/ платформу 1c-enterprise-8.3 full (текущую версию) и СУБД postgresql-11.7-5.1C-x64 (или текущую версию).

Установка и настройка СУБД postgresql-11.7-5.1C

Запускаем дистрибутив postgresql-11.7-5.1C(x64) для установки

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

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

Запускаем службу: Пуск — PostgreSQL 11.7-5.1C(x64) — Start Service

Распаковываем архив и в нём запускаем setup.exe

Для установки сервера выбрать компоненты

• Сервер 1С:Предприятия 8
• Администрирование сервера 1С:Предприятия
• Сервер хранилища конфигураций 1С:Предприятия
• Дополнительные функции администрирования
• Контроль целостности
• Интерфейсы на различных языках: Английский и Русский

Выбираем язык интерфейса — Русский

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

Устанавливаем драйвер аппаратных ключей защиты

и завершаем установку.

Настройка сервера 1С:Предприятие 8.3

После установки запускаем сервер: Пуск — 1С Предприятие 8 (x86-64) — Запуск сервера x86-64

Регистрирует утилиту администрирования серверов: Пуск — 1С Предприятие 8 (x86-64) — Регистрация утилиты администрирования серверов x86-64

Запускаем консоль администратора: Пуск — 1С Предприятие 8 (x86-64) — Администрирование серверов 1С Предприятия x86-64

на пункте Central 1C:Enterprise 8.3 servers жмём правой кнопкой мыши — Создать — Центральный сервер 1С:Предприятия 8.3

Вводим имя сервера и, если необходимо, описание

Теперь сервер отображается в консоли

Создадим информационную базу

Пропишем имя ИБ, описание, адрес сервера БД: localhost (если сервер развёрнут на той же машине, что и СУБД), имя БД, пользователя postgres и пароль, а также отметим чек-бокс Создать базу данных в случае её отсутствия

и информационная база появилась в оснастке консоли

Теперь вставляем USB-ключ HASP и на всякий случай перезагрузим машину.

Установка и настройка клиента 1С:Предприятие 8.3

Распаковываем архив и в нём запускаем setup.exe

Будут отмечены компоненты:

• 1С:Предприятие 8
• Интерфейсы на различных языках — Английский и Русский

Этого вполне достаточно.

Будет создан ярлык 1С Предприятие. Запускаем его и сразу будет предложено добавить информационную базу

Соглашаемся.

Выбираем существующую информационную базу

Выберем тип расположения — На сервере 1С:Предприятия.

Заполним: Кластер серверов: SRV15, Имя информационной базы: db_1c (то же, что и было добавлено в консоли администрирования)

В Версию 1С:Предприятия впишем 8.3, в Разрядность — 64 (x86_64)

и информационная база появится в списке

Заключение

Если при установке и настройке вышеперечисленных пунктов не возникало никаких сообщений об ошибках, значит настройка прошла корректно. Но нельзя забывать о лицензии — это USB-ключ аппаратной защиты HASP. При работе в 1С-Предприятии его наличие обязательно.

Данная статья довольно необычна для нашего ресурса, потому что мы в своей работе используем дистрибутивы Debian / Ubuntu, но многие наши читатели, в рамках импортозамещения, пробуют переходить на Альт. Сервер 1С:Предприятия — также одна из самых востребованных ролей. И вот мы начали получать сообщения, что многие испытывают сложности с настройкой этой связки, хотя проблемам там взяться, вроде бы неоткуда. Поэтому мы самостоятельно изучили данный вопрос и подготовили практическую инструкцию с учетов всех особенностей и подводных камней для Альт Сервер 10

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Лицензионное соглашение Альт Сервер 10 допускает его неограниченное использование физическими лицами, юридические лица могут бесплатно воспользоваться им для тестирования, для промышленной эксплуатации потребуется приобрести лицензию, ее стоимость на момент написания статьи составляла 13 200 руб.

На платформе Альт работает только x86-64 версия сервера 1С:Предприятие, ее стоимость составляет 86 400 руб. Для малых предприятий можно использовать Сервер МИНИ на 5 подключений, цена которого 14 400 руб. Технически сервер 1С на Linux позволяет открыть 12 сеансов без наличия серверной лицензии, но такой режим эксплуатации однозначно нарушает лицензионное соглашение.

Сборка PostgresSQL для 1С от компании PostgresPRO предоставляется бесплатно.

Установка и предварительная подготовка сервера

Мы будем устанавливать Альт Сервер 10, дистрибутив которого можно бесплатно скачать на сайте разработчика. Он имеет графический установщик и процесс не должен вызвать затруднений. Но есть определенные тонкости, так если вы хотите использовать автоматическую разметку диска, то вам понадобиться не менее 24 ГБ свободного места на диске, учтите это при выделении ресурсов виртуальным машинам. Альтернативой этому является ручная разметка диска.

Предлагаемый по умолчанию профиль Офисного сервера также содержит много лишнего и если наша цель — выделенный сервер 1С, то выбираем Минимальную установку, которая займет на диске всего 1,6 ГБ.

Сервер SSH включен в нее по умолчанию, поэтому можно открыть удаленную консоль сразу после установки, вход от имени root по SSH заблокирован, поэтому входим под обычным пользователем и повышаем права командой:

su - 

После которой вам потребуется ввести пароль суперпользователя.

Первым делом обновим систему:

apt-get update
apt-get dist-upgrade

Затем добавим некоторые необходимые утилиты, файловый менеджер Midnight Commander уже установлен, но нет wget, которая нам позже понадобится.

apt-get install wget

Затем откроем /etc/hosts и добавим в него явное соответствие адреса узла и имени хоста, в нашем случае это:

192.168.233.148 host-148

При сохранение этого файла вы получите предупреждение, что файл содержит жесткие ссылки и следует ли их отсоединить, отвечаем — нет.

Если вы использовали разметку по умолчанию, то в системе отсутствуют пространства подкачки, эксплуатировать серверную систему в таком режиме нежелательно, поэтому создадим файл подкачки, в нашем случае размером 4 ГБ:

fallocate -l 4G /swapfile

Установим на него нужные права:

chmod 600 /swapfile

Создадим в нем пространство подкачки:

mkswap /swapfile

И подключим его:

swapon /swapfile

Для того, чтобы он монтировался каждый раз при входе в систему, добавим в /etc/fstab строку:

/swapfile    none    swap    sw    0 0

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

Установка PostgreSQL для 1C

Во всех своих внедрениях мы используем бесплатную сборку от компании Postgres Professional, получить ее можно на сайте 1c.postgres.ru, выбираете необходимые вам параметры, заполняете короткую анкету и получаете инструкции по установке на электронную почту. Но при выборе версии сервера СУБД обязательно сверяйтесь со списком системных требований 1С и требованиями используемого прикладного решения (конфигурации).

Обычно, ничего страшного от использования «несовместимой» версии не бывает, но иногда это может вызвать затруднения. Кроме того, официальная поддержка также может указать на факт использования несовместимой версии и отказать вам в решении вашего вопроса. Исходя их этих соображений мы выбираем 14-ю версию PostgreSQL.

Прежде всего перейдем в домашнюю директорию и скачаем скрипт для установки репозиториев Postrges Pro:

cd
wget https://repo.postgrespro.ru/1c-14/keys/pgpro-repo-add.sh

После чего запустим его командой:

sh pgpro-repo-add.sh

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

apt-get install postgrespro-1c-14

Сервер СУБД будет автоматически добавлен в автозагрузку и запушен, в чем не трудно убедиться при помощи команды:

systemctl status postgrespro-1c-14

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

Оптимизация производительности PostgreSQL для работы с 1С:Предприятие

В завершении нам нужно установить пароль для суперпользователя СУБД postgres, для этого войдем в систему под его именем, не обращаем внимание на ошибку доступа:

su postgres

Открываем консоль PSQL:

psql 

И выполняем:

ALTER USER postgres WITH PASSWORD 'MyPa$$word';

Где MyPa$$word — желаемый пароль.

Выходим из консоли PSQL и из сеанса пользователя postgres:

q
exit

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

Установка сервера 1C:Предприятие

Еще раз напомним, что сервер СУБД, сервер 1С:Предпритяие и веб-сервер — это разные, полностью самостоятельные компоненты и могут быть установлены как на одном узле, так и на разных. Поэтому мы специально построили наш материал таким образом, чтобы каждый раздел приводил к созданию законченной части решения.

Платформа 1С актуальных релизов выпускается в виде единого дистрибутива, который можно получить на Портале ИТС, вам потребуется скачать Технологическая платформа 1С:Предприятия (64-bit) для Linux нужного выпуска. Мы будем устанавливать релиз 8.3.22.1709, если у вас другая версия платформы — то вам потребуется исправить номер версии во всех приведенных ниже командах.

Единый дистрибутив построен по принципу «все свое ношу с собой», поэтому вопрос установки необходимых зависимостей практически не стоит. Но кое-что все-таки придется установить вручную, прежде всего это шрифты от Microsoft, распространять их в составе пакета нельзя по лицензионным соображениям.

Для их установки выполните:

apt-get install fonts-ttf-ms

Но если оставить все как есть, то 1С не увидит эти шрифты, поэтому создадим символическую ссылку:

ln -rs /usr/share/fonts/ttf/ms /usr/share/fonts/msttcorefonts

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

apt-get install unixodbc

Далее будем считать, что архив с дистрибутивом находится в домашней директории суперпользователя в которой мы и находимся. Распакуем его:

tar -xzvf server64_8_3_22_1709.tar.gz

Затем установим компоненты сервера и модуля расширения веб-сервера:

./setup-full-8.3.22.1709-x86_64.run --mode unattended --enable-components server,ws

Зарегистрируем юнит службы:

systemctl link /opt/1cv8/x86_64/8.3.22.1709/srv1cv8-8.3.22.1709@.service

И добавим его в автозагрузку:

systemctl enable srv1cv8-8.3.22.1709@

Запустим наш экземпляр сервиса и проверим его статус:

systemctl start srv1cv8-8.3.22.1709@default
systemctl status srv1cv8-8.3.22.1709@default

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

ss -tpln

Должны быть активны процессы: ragent — TCP 1540, rmngr — TCP 1541 и один или несколько rphost — TCP 1560 — 1591.

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

Подключение клиентов, создание баз

Для подключения клиентов нужно чтобы прежде всего они находили сервер по имени узла, для этого нам нужно либо добавить запись на DNS-сервере предприятия или добавить запись в файл hosts. В Windows он находится по пути C:WindowsSystem32driversetchosts, в Linux — /etc/hosts. Внесите в него строку:

192.168.233.148 host-148

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

Обратим внимание на некоторые параметры: прежде всего на имя информационной базы в кластере и имя базы данных. Это разные сущности и не стоит их путать. Информационная база — это объект, который существует и работает на уровне сервера 1С:Предприятие. База данных — это связанная с ней база в СУБД, где физически хранятся данные. Чтобы отличать одно от другого мы для себя создали следующее соглашение: имя информационной базы записывается в верхнем регистре, базы данных — в нижнем.

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

На устройстве нет свободного места /tmp/v8_3xha48_12.tmp'. 28(0x0000001 С): No space left on device

Это как так? Ведь у нас должно быть много свободного места! Но не будем спешить, перед нами одна из типично Альтовских особенностей, дело в том, что Альт Сервер по умолчанию выносит директорию /tmp на tmpfs в оперативную память и использует для этого раздела половину установленной на сервере памяти.

Проверим:

df -h 

Для нашего тестового сервера мы создали виртуальную машину с 4 ГБ памяти и как видим, свободного места в /tmp осталось всего 1,1 ГБ, вполне ожидаемо, что при попытке загрузить дамп размером около гигабайта мы потерпели неудачу.

Как быть? Можно временно отключить создание tmpfs, для этого откройте /etc/fstab и временно закомментируйте строку:

tmpfs    /tmp    tmpfs    nosuid    0 0

После чего перезагрузите сервер.

Также, возможно, вы захотите более явно управлять размерами раздела /tmp и не выделять ему половину оперативки, особенно если ее много. В таком случае запись следует изменить, укажите:

tmpfs    /tmp    tmpfs    size=4g,nr_inodes=1m,nosuid    0 0

В данном случае параметр size указывает желаемый размер раздела, в нашем случае 4 ГБ, можно также указывать размер в процентах.

Разобравшись с tmpfs мы, наконец-то, сможем залить нашу базу и начать работать с ней. Проверить параметры работы базы можно вызвав пункт меню О программе.

Как видим, ничего сложного с работой сервера 1С:Предприятие размешенного на платформе Альт нет, но есть некоторые специфические моменты, которые следует знать и учитывать.

Публикация информационной базы на веб-сервере

Установка веб-сервера не является обязательной для работы сервера 1С:Предприятие, но это достаточно популярный сценарий, поэтому коротко рассмотрим и его.

Начнем с установки Apache 2:

apt-get install apache2

После чего включим пользователя веб-сервера в группу пользователей сервера 1С:

usermod -a -G grp1cv8 apache2

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

mkdir /var/www/acc30

Рекомендуем называть каталоги по имени баз, чтобы было меньше путаницы. Владельцем каталога следует сделать 1С:Предприятие:

chown -R usr1cv8:grp1cv8 /var/www/acc30

Теперь перейдем в директорию с платформой:

 cd /opt/1cv8/x86_64/8.3.22.1709

И выполним публикацию базы:

 ./webinst -publish -apache24 -wsdir ACC30 -dir /var/www/acc30 -connstr "Srvr=host-184;Ref=ACC30;" -confpath /etc/httpd2/conf/httpd2.conf

Коротко поясним используемые параметры:

• publish — указывает необходимое действие, в данном случае публикацию, может быть опущен, так как это действие по умолчанию
• apache24 — задает тип веб-сервера, для Apache 2.4 следует указывать apache24.
• wsdir — имя публикации, по которому к базе следует обращаться из браузера, обратите внимание, что оно регистрозависимое
• dir — путь публикации, ранее созданная нами директория
• connstr — строка соединения, состоит из нескольких частей: Srvr — имя сервера, Ref — имя базы на сервере, каждая часть должна заканчиваться служебным символом «;«
• confpath — путь к конфигурационному файлу веб-сервера

Перезапустим веб-сервер:

systemctl restart httpd2

Быстрее всего проверить работу базы можно в браузере, обращаться можно как по имени узла, так и по IP: http://192.168.233.184/ACC или http://host-184/ACC. Если вы увидели заставку 1С:Предприятия или окно аутентификации — то значит все работает. Войти в базу вы не сможете, так как при работе через браузер компонента веб-расширения ищет лицензию сначала локально, потом на сервере 1С, но если мы их туда не устанавливали, то вы получите сообщение об ее отсутствии. Однако такое поведение говорит, что публикация на веб-сервере выполнена без ошибок и работает.

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

Убедиться в том, что мы работаем именно через веб-сервер также можно при помощи пункта меню О программе:

В данной статье мы коснулись только самых базовых настроек, особенно в том, что касается веб-сервера. Но и цель данной статьи — помочь вам быстро начать работать с сервером 1С:Предприятие на платформе Альт Сервер 10. Для более тонкой настройки можно воспользоваться иными статьями с нашего ресурса, но с оглядкой на используемый дистрибутив.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Подробная инструкция по установке платформы 1С на сервер (серверная часть платформы 1C aka сервер 1С).

 
Эта статья посвящена установке сервера 1С.
Если Вам нужно установить платформу 1С (клиент 1С) — смотрите установку платформы 1С.
Если Вам нужно установить конфигурацию 1С — смотрите установку конфигурации 1С.

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

Окно приветствия установки сервера 1С, нажимаем «Далее».

После этого появится страница выбора параметров установки сервера 1С. Вам необходимо выбрать пункт Сервер 1С:Предприятие.

Если Вы планируете использование тонкого клиента, то при установке сервера 1С нужно, чтобы ДО установки 1С был установлен веб-сервер (IIS / Apache) и тогда при установке сервера 1С установить дополнительно галочку «Модули расширения веб-сервера».

На этой закладке установки сервера 1С нужно выбрать (не трогать уже выбранный) основной язык.

Сервер 1С может быть установлен как «программа» и как «сервис».

В первом случае, при загрузке сервера 1С будет всплывать окно с программой, во втором, сервис работает в фоне. Лучше – устанавливать как сервис.

Также нужно уточнить под каким пользователем будет запускаться сервер 1С (сервис или программа). Можно выбрать существующего или создать «стандартного пользователя 1С». Лучше – создать пользователя и установить для него пароль.

Нажимаем Установить сервер 1С.

Собственно установка сервера 1С.

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

Если это переустановка платформы 1С, то этот этап можно пропустить. Если Вы устанавливаете какую-то «необычную» 1С, то на этом моменте следуйте инструкциям по ее особенностям в установке.

Драйвер ключа можно скачать более новый с сайта его изготовителя:

 
Менеджер лицензий 1С

Если Вы ставите 1С на машину, в которую воткнут пользовательский ключ, который будут использовать многие пользователи в сети, то дополнительно нужно установить менеджер лицензий.

Менеджер лицензий поставляется вместе с дистрибутивом 1С, но его также можно скачать с сайта его производителя.

Его установка достаточно проста и мы не будем ее проходить по страницам. Также можно выбрать – запускать его как программу или как сервис, лучше выбрать сервис.

Установка платформы 1С >>

Установка конфигурации 1С >>

Скачать подробную инструкцию по установке с картинками на каждое действие #7 ->>>

Часть 1. Установка PostgreSQL

На настоящий момент фирма 1С предоставляет возможность установки своего основного программного продукта на ОС Windows, Linux и MacOS (только клиентского приложения).

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

Однако, сама фирма 1С в своей документации и справочных материалах довольно прозрачно намекает, что ОС Windows далеко не единственный вариант установки ПО, в особенности серверной части и что ОС Linux гораздо более предпочтительна в качестве серверной ОС.

На портале 1С мы можем найти разные наборы установочных пакетов для 64-битных и 32-битных систем, для систем из семейства Linux, основанных на deb-пакетах (для системы Debian и её производных — Ubuntu, Mint и других) и основанных на rpm-пакетах (для ОС RedHat и её производных — CentOS, Suse, Fedora и других).

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

Для того, чтобы установить систему 1С в клиент-серверном варианте, требуется установка не только самого сервера 1С, но и сервера СУБД. Начнём установку именно с этого, так как без работоспособной базы данных устанавливать сервер 1С не имеет смысла.

Вариантов для выбора СУБД весьма немного. Система 1С может работать всего лишь с 4-мя различными СУБД: Microsoft SQL Server, PostgreSQL, IBM DB2 и Oracle Database. Все эти СУБД могут быть установлены на Linux, однако в полноценном варианте Microsoft SQL Server, IBM DB2 и Oracle Database являются платными коммерческими продуктами с немалой стоимостью. А на настоящий момент все эти три корпорации с РФ не работают (Microsoft, IBM, Oracle). У PostgreSQL тоже есть платная версия, но той версии, которая распространяется как свободный и открытый программный продукт, вполне достаточно для работы с сервером 1С. Поэтому при использовании свободной ОС Linux выбор в первую очередь, конечно, падает на PostgreSQL.

Но здесь есть некоторые нюансы. Фирма 1С достаточно серьёзно переработала и пропатчила эту СУБД под свою систему, поэтому использовать оригинальную версию PostgreSQL сервера не получится. Как минимум, в эту СУБД был добавлен тип данных mchar, которого нет в оригинальной версии. И при попытке создать базу данных 1С на непропатченном PostgreSQL мы получим ошибку об отсутствии типа данных mchar.

На портале 1С выложена для скачивания специальная уже пропатченная версия этого сервера. Однако здесь также есть некоторые подводные камни. В документации к этой версии мы читаем про совместимость с ОС.

«Cписок поддерживаемых дистрибутивов:

Windows 7, 8, 10

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

Windows Server 2016

Fedora Core 30.1.2

Debian 9

Debian 10

Red Hat Enterprise Linux 7

Centos 7

Ubuntu 18.04

Ubuntu 20.04

Astra Linux Special Edition «Смоленск» 1.6

Astra Linux Special Edition «Смоленск» 1.7

Astra Linux Common Edition «Орел» 2.12»

Как мы видим, список поддерживаемых версий ОС Linux довольно ограничен. В отношении ОС Fedora указан устаревший уже на настоящий момент дистрибутив версии 30 (на момент написания этой статьи текущая версия 36). И вообще, слово «Core» из названия Fedora было убрано уже много лет назад. Что даёт нам понять, что разработчики 1С не особо следят за развитием этого дистрибутива. А когда мы открываем скачанный архив rpm-пакетов (если мы хотим поставить сервер на ОС Fedora), то и вовсе оказывается, что там лежат пакеты для Red Hat Enterprise Linux 7-й версии.

Конечно, при определённых манипуляциях, эти пакеты можно поставить на Fedora 36, но добиться работоспособности от установленного таким образом сервера PostgreSQL автору так и не удалось.

Можно задаться вопросом, зачем нам в принципе ставить 1С на Fedora, если она особо не поддерживается, вместо того, чтобы взять «надёжную» Ubuntu или устаревший CentOS. И, вообще, бытует мнение, что Fedora может содержать в себе много багов, так как является экспериментальным дистрибутивом от RedHat, в котором используется самое новое и непроверенное временем ПО, и использовать её на серьёзных производственных серверах категорически не рекомендуется.

Однако опыт многолетнего использования этого дистрибутива в действительности показал обратное. Дистрибутив, на самом деле, во многом весьма прогрессивен, но в то же время довольно стабилен в своей работе. Какие-то явные недоработки проявляются в нём крайне редко и сравнительно быстро исправляются. Перед очередным релизом дистрибутивы проходят массу проверок и тестирований. Говорить, что Fedora — это сырой и непроверенный дистрибутив, можно только никогда по-серьёзному им не пользуясь.

Поэтому автор рассматривает вариант запуска сервера 1С именно на этом дистрибутиве и эта статья посвящена именно этому.

Итак, с официального портала мы не имеем установочных пакетов для Fedora. Но на портале выложена эта СУБД и патчи к ней в виде архива исходных кодов. Вот с этими файлами мы и будем работать.

Скачиваем архив, который называется Патч СУБД PostgreSQL (tar.bz2) (или .zip, это не имеет значения). В нашем примере это будет файл Patch_SUBD_PostgreSQL_14.4_1.1C.tar.bz2. То есть, у нас должен в итоге установиться пропатченный сервер PostgreSQL версии 14.4.

Внутри этого архива мы обнаруживаем несколько файлов:

00001-1C-FULL.patch

postgresql-14_14.4-1.1C.dsc

postgresql-14_14.4-1.1C_source.changes

postgresql14-1c-14.4-1.el7.src.rpm

postgresql-14_14.4-1.1C.debian.tar.xz

postgresql-14_14.4-1.1C_source.buildinfo

postgresql-14_14.4.orig.tar.bz2

На том же самом портале 1С можно найти статью, описывающую порядок установки патча из исходных кодов, в настоящий момент она располагается на портале по адресу https://its.1c.ru/db/metod8dev/content/5942/hdoc и называется «Методика сборки дистрибутива СУБД PostgreSQL 9.6 c патчами для работы с 1С:Предприятие».

Как мы видим из названия, статья описывает сборку PostgreSQL версии 9.6, а последняя выложенная версия на текущий момент 14.4. То есть, статья несколько устарела, но всё ещё может использоваться как отправная точка. Идём в раздел «Сборка для RPM на примере CentOS 7 x86_64» и адаптируем предложенный алгоритм к современной версии дистрибутива Fedora (Fedora 36).

Конечно, все команды установки пакетов и других административных действий требуют права root. Поэтому эти команды должны даваться либо напрямую из-под учётной записи root, либо от пользователя, обладающего такими правами, используя команду sudo. Далее для упрощения все команды будут написаны без sudo, в варианте работы сразу в учётной записи root.

Итак, чтобы собрать PostgreSQL на Fedora 36, выполняем следующие действия.

dnf install rpmdevtools

rpmdev-setuptree

Как и написано в статье на портале, «данная команда создаст каталог rpmbuild и подкаталоги BUILD, BUILDROOT, RPMS, SOURCES, SPECS, SRPMS с расположением «по умолчанию» в домашнем каталоге пользователя». В нашем упрощённом случае, домашним каталогом будет каталог /root

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

dnf install gcc

Далее, по инструкции, готовим исходный пакет. Из вышеуказанного архива берём файл postgresql14-1c-14.4-1.el7.src.rpm и помещаем в его в заранее созданный для этого каталог, например, как предлагается в инструкции, ~/Postgres/Rpm.

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

dnf install bison clang-devel e2fsprogs-devel flex krb5-devel libicu-devel libselinux-devel libuuid-devel libxml2-devel libxslt-devel llvm-devel lz4-devel openldap-devel openssl-devel pam-devel perl perl-ExtUtils-Embed perl-IPC-Run perl-generators python3-devel readline-devel systemd-devel tcl-devel

Также в списке зависимостей для PostgreSQL есть ещё один пакет — pgdg-srpm-macros, но в федоровских репозиториях его нет. Взять его можно непосредственно с ftp-сервера проекта postgresql, но там есть только пакет с исходным кодом (src). В настоящий момент, для ОС Fedora 36 это можно сделать по адресу https://ftp.postgresql.org/pub/repos/yum/srpms/common/fedora/fedora-36-x86_64/, скачиваем оттуда файл pgdg-srpm-macros-1.0.24-1.f36.src.rpm.

Устанавливаем скачанный пакет. Это можно сделать, например, открыв его через MidnightCommander, если мы войдём в этот файл через mc, то он раскроется как архив, в котором мы найдём файл INSTALL, который можно также запустить здесь же, через mc.

После установки в созданном ранее командой rpmdev-setuptree каталоге ~/rpmbuild/SPECS появится файл pgdg-srpm-macros.spec, который можно собрать командой

rpmbuild -ba pgdg-srpm-macros.spec

(Перед выполнением команды мы либо перемещаемся в каталог SPECS, либо указываем полный путь к файлу в команде. Это будет справедливо и ко всем последующим подобным командам.)

В результате выполнения этой команды, в каталоге ~/rpmbuild/RPMS/noarch появится готовый бинарный пакет pgdg-srpm-macros-1.0.24-1.fc36.noarch.rpm, который теперь можно установить командой

dnf install pgdg-srpm-macros-1.0.24-1.fc36.noarch.rpm

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

Перемещаемся в каталог с src-пакетом:

cd ~/Postgres/Rpm

И распаковываем его для дальнейшей компиляции:

rpm2cpio postgresql14-1c-14.4-1.el7.src.rpm | cpio —extract —make-directories

Как написано в статье на портале, «в результате в каталоге ~/Postgres/Rpm будет находиться архив с оригинальными исходниками postgresq-9.6.3.tar.bz2, патчи (.patch), прочие источники для формирования rpm-пакета и файл postgresql-9.6.3.spec – «главный» конфигурационный файл, инструкция для сборки. В нём указывается информация об исходных файлах (Source), патчах (Patch) и зависимостях сборки (BuildRequires и Requires). Необходимо убедиться, что все файлы, перечисленные в разделе Source, присутствуют в каталоге ~/Postgres/Rpm, переместим их с помощью команды mv в каталог ~/rpmbuild/SOURCES.»

Написано всё правильно, только в нашем случае это будут файлы postgresql-14.4.tar.bz2 и postgresql-14.spec.

Все распакованные файлы (кроме postgresql-14.spec) мы перемещаем или копируем, как там и написано, в ~/rpmbuild/SOURCES, включая и файл postgresql-14-A4.pdf. Файл postgresql-14.spec помещаем в ~/rpmbuild/SPECS

Теперь можно запускать процесс компиляции. В статье на портале предлагают сделать это командой rpmbuild -ba, а затем «информация о ходе сборки будет выводиться на экран. После её завершения автоматически запустятся регрессионные тесты сформированных пакетов, статус их выполнения также будет выведен. В случае ошибки сборка будет прекращена. В случае успешного её завершения бинарные rpm-пакеты будут находиться в директории ~/rpmbuild/RPMS, пакет postgresql96-9.6.3-1.1C.src.rpm – в ~/rpmbuild/SRPMS».

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

Основываясь на практическом опыте, можно сказать, что действительно при компиляции вываливается несколько некритичных ошибок, а затем компилятор спотыкается на моменте указания нестандартного пути к библиотекам postgres, которые будут располагаться в /usr/pgsql-14/lib, а не в стандартных каталогах ОС. И, таким образом, просто так предлагаемая команда компиляции действительно не сработает.

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

export QA_SKIP_RPATHS=1; rpmbuild -ba postgresql-14.spec

По завершении процесса компиляции в каталоге ~/rpmbuild/RPMS/x86_64 появятся собранные пакеты:

postgresql14-1c-14.4-1.fc36.x86_64.rpm

postgresql14-1c-contrib-14.4-1.fc36.x86_64.rpm

postgresql14-1c-contrib-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-debugsource-14.4-1.fc36.x86_64.rpm

postgresql14-1c-devel-14.4-1.fc36.x86_64.rpm

postgresql14-1c-devel-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-docs-14.4-1.fc36.x86_64.rpm

postgresql14-1c-libs-14.4-1.fc36.x86_64.rpm

postgresql14-1c-libs-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-llvmjit-14.4-1.fc36.x86_64.rpm

postgresql14-1c-llvmjit-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plperl-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plperl-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plpython3-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plpython3-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-pltcl-14.4-1.fc36.x86_64.rpm

postgresql14-1c-pltcl-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-server-14.4-1.fc36.x86_64.rpm

postgresql14-1c-server-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-test-14.4-1.fc36.x86_64.rpm

postgresql14-1c-test-debuginfo-14.4-1.fc36.x86_64.rpm

Теперь все эти пакеты можно установить. У пакетов есть определённые зависимости друг от друга, поэтому устанавливать надо в такой последовательности:

dnf install postgresql14-1c-libs-14.4-1.fc36.x86_64.rpm

postgresql14-1c-14.4-1.fc36.x86_64.rpm

postgresql14-1c-server-14.4-1.fc36.x86_64.rpm

postgresql14-1c-contrib-14.4-1.fc36.x86_64.rpm

postgresql14-1c-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-debugsource-14.4-1.fc36.x86_64.rpm

postgresql14-1c-devel-14.4-1.fc36.x86_64.rpm

postgresql14-1c-docs-14.4-1.fc36.x86_64.rpm

postgresql14-1c-llvmjit-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plperl-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plpython3-14.4-1.fc36.x86_64.rpm

postgresql14-1c-pltcl-14.4-1.fc36.x86_64.rpm

postgresql14-1c-test-14.4-1.fc36.x86_64.rpm

postgresql14-1c-contrib-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-devel-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-libs-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-llvmjit-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plperl-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-plpython3-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-pltcl-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-server-debuginfo-14.4-1.fc36.x86_64.rpm

postgresql14-1c-test-debuginfo-14.4-1.fc36.x86_64.rpm

После установки всех этих пакетов в нашей ОС появится служба postgresql-14.service, которая запускается и останавливается через команду systemctl.

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

postgresql-14-setup initdb

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

systemctl start postgresql-14

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

Часть 2. Настройка PostgreSQL

В предыдущей части мы полностью установили PostgreSQL-сервер. Теперь его надо настроить, чтобы с ним мог взаимодействовать сервер 1С.

Перед запуском службы postgresql-14 мы инициировали базу данных. По умолчанию базы данных располагаются в каталоге /var/lib/pgsql/14/data

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

Путь к базам PostgreSQL хранится в переменной PGDATA. Эта переменная устанавливается при запуске службы postgresql-14.

Чтобы поменять её значение нужно отредактировать 2 файла:

/var/lib/pgsql/.bash_profile в строчке PGDATA= пишем новый путь к базам

и

/usr/lib/systemd/system/postgresql-14.service

в разделе [Service]

Environment=PGDATA=новый путь

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

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

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

Далее можно инициализировать базу данных, либо командой postgresql-14-setup initdb, либо, если нужно указывать ещё какие-то опции, например, кодировку, то можно так:

из-под учётной записи root временно станем пользователем postgres

su -l postgres

запустим инициализацию базы данных с указанием каталога и кодировки, например

/usr/pgsql-14/bin/initdb -D /нужный/нам/каталог —locale=ru_RU.UTF-8 -E UTF8

при выполнении этой команды вы увидите примерно такие сообщения:

«Файлы, относящиеся к этой СУБД, будут принадлежать пользователю «postgres».

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

Кластер баз данных будет инициализирован с локалью «ru_RU.UTF-8».

Выбрана конфигурация текстового поиска по умолчанию «russian».

Контроль целостности страниц данных отключён.

исправление прав для существующего каталога /альтернативный_путь/pgsql/14/data… ок

создание подкаталогов… ок

выбирается реализация динамической разделяемой памяти… posix

выбирается значение max_connections по умолчанию… 100

выбирается значение shared_buffers по умолчанию… 128MB

выбирается часовой пояс по умолчанию… Europe/Moscow

создание конфигурационных файлов… ок

выполняется подготовительный скрипт… ок

выполняется заключительная инициализация… ок

сохранение данных на диске… ок

initdb: предупреждение: включение метода аутентификации «trust» для локальных подключений

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

—auth-local или —auth-host при следующем выполнении initdb.

Готово. Теперь вы можете запустить сервер баз данных:

/usr/pgsql-14/bin/pg_ctl -D /альтернативный_путь/pgsql/14/data -l файл_журнала start»

Возвращаемся в пользователя root:

exit

Командой «/usr/pgsql-14/bin/pg_ctl -D /альтернативный_путь/pgsql/14/data -l файл_журнала start» запускать сервис необязательно.

Попробуем сделать это системными средствами:

systemctl start postgresql-14

Если мы всё сделали правильно, то сервис должен запуститься без ошибок. Проверяем:

systemctl status postgresql-14

Статус демона должен быть active (running).

Но на этом настройка не закончена. Для того, чтобы сервер PostgreSQL мог обслуживать сервер 1С, нужно сделать ещё некоторые действия.

Есть 2 конфигурационных файла: postgresql.conf и pg_hba.conf. По-умолчанию они лежат в /var/lib/pgsql/14/data, либо в том каталоге, где мы только что создали кластер базы данных.

В файле postgresql.conf следует обратить внимание на строчку listen_addresses=.

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

Стандартный порт, который слушает PostgreSQL — 5432, можно проверить, что это действительно так:

netstat -ant | grep 5432

tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN

tcp6 0 0 ::1:5432 :::* LISTEN

Помимо этого, ограничение на подключение еще настраивается в файле pg_hba.conf. Данный файл содержит строки в таком формате:

local база пользователь метод-аутентификации [параметры-аутентификации]

host база пользователь адрес метод-аутентификации [параметры-аутентификации]

Строка с local задает правила для подключений по локальным UNIX-сокетам. Строка с host — подключения по TCP/IP.

«# TYPE DATABASE USER ADDRESS METHOD

# «local» is for Unix domain socket connections only

local all all trust

# IPv4 local connections:

host all all 127.0.0.1/32 trust

# IPv6 local connections:

host all all ::1/128 trust

# Allow replication connections from localhost, by a user with the

# replication privilege.

local replication all trust

host replication all 127.0.0.1/32 trust

host replication all ::1/128 trust»

Далее необходимо произвести тонкую настройку сервера. Необходимо подобрать настройки, исходя из параметров своего оборудования. Расчёт необходимо осуществить на основании рекомендаций фирмы «1С», изложенных здесь https://its.1c.ru/db/metod8dev/content/5866/hdoc. Существуют и другие ресурсы с рекомендациями и описаниями всех параметров.

Идём в пользователя postgres:

su -l postgres

Открываем командную строку сервера PostgreSQL:

psql

Приглашение командной строки будет выглядеть так: postgres=#

Посмотреть текущие значения параметров можно или так: SHOW ALL; Это будут все параметры сразу. Или так: SHOW имя параметра; Например, SHOW shared_buffers;

Изменить параметры можно командой:

ALTER SYSTEM SET параметр = ‘значение’;

Например:

ALTER SYSTEM SET shared_buffers = ’16GB’;

Выход из оболочки сервера q

Выход из пользователя postgres

exit

Часть параметров применяется только после перезапуска сервера PostgreSQL.

systemctl restart postgresql-14

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

Опции, которые были заданы подобным образом, будут записаны в файле postgresql.auto.conf в каталоге с базами и остальными конфигами.

Следующее действие — это создать отдельного пользователя на сервере базы данных для управления базами. Снова становимся пользователем postgres и открываем консоль сервера:

su -l postgres

psql

create user pg1cv8 with superuser;

alter user pg1cv8 password ‘password’;

q

exit

systemctl restart postgresql-14

Включим автозапуск PostgreSQL при старте системы:

systemctl enable postgresql-14

Часть 3. Установка сервера 1С и драйвера USB-ключа

Мы установили и произвели первичную настройку сервера баз данных PostgreSQL, теперь можно устанавливать собственно сервер 1С.

Программа 1С требует наличия лицензий. Для запуска серверной части нужна серверная лицензия, для клиентской — клиентская. Лицензии бывают аппаратные, зашитые на USB-токен, и электронные, которые активируются через ввод ПИН-кода при первом запуске программы.

Если у нас аппаратная лицензия на USB-токене, то нужно установить драйвер HASP.

Драйвер этот выпускает компания Etersoft. Эта же компания выпускает свою платную версию WINE, адаптированную к запуску windows-версии 1С на Linux и других специфических программ, типа Консультант Плюс, Гарант и т. д.

Готовые файлы находятся здесь: https://download.etersoft.ru/pub/Etersoft/HASP/ Но, судя по текущему состоянию этого ресурса, разработка этого драйвера не является приоритетной задачей, особенно для ОС Fedora. Последняя версия драйвера — 8.23 от сентября 2021 года. Для Федоры пакета не наблюдается. Есть пакет для CentOS.

Последняя версия драйвера, выложенного для Федоры — 7.90 от 12 июля 2019 года. Находится она здесь https://download.etersoft.ru/pub/Etersoft/HASP/7.90/x86_64/Fedora/27/, пакет для Fedora 27.

Мы будем использовать его, за неимением лучшего. Скачиваем, устанавливаем.

dnf install haspd-7.90-eter2fedora.x86_64.rpm

dnf install haspd-modules-7.90-eter2fedora.x86_64.rpm

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

systemctl status haspd

Теперь можно заняться установкой сервера 1С. Идём на портал 1С и скачиваем оттуда технологическую платформу 8.3

Последняя версия на настоящий момент — 8.3.21.1393 от 19.07.2022 г. Когда мы заходим в этот раздел на портале, там будет очень много разных вариантов для скачивания, нас интересует Технологическая платформа 1С:Предприятия (64-bit) для Linux. Должен скачаться файл server64_8_3_21_1393.tar.gz. Распаковываем его. Обнаруживаем там 3 файла:

LibericaJDK-8-9-10-licenses.pdf

Liberica-Notice.txt

setup-full-8.3.21.1393-x86_64.run

Запускаем файл setup-full-8.3.21.1393-x86_64.run. Это файл-инсталлятор 1С. До недавнего времени 1С ставилась путём установки нескольких пакетов. Сейчас разработчики1С свели этот процесс к запуску графического инсталлятора, аналогичного тому, кому, который запускается на Windows. Поэтому после запуска мы будем видеть графические окошки и кнопки «далее».

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

«Не удалось установить пакеты, требуемые для работы. Чтобы установка платформы «1С:Предприятие» завершилась успешно, необходимо самостоятельно установить отсутствующие пакеты с помощью пакетного менеджера операционной системы и заново запустить установку платформы. Отсутствующие пакеты приведены ниже и их можно скопировать в буфер обмена:

libgtk-3-0 libenchant1c2a libharfbuzz-icu0 libgstreamer1.0-0 libgstreamer-plugins-base1.0-0 gstreamer1.0-plugins-good gstreamer1.0-plugins-bad libsecret-1-0 libsoup2.4-1 libsqlite3-0 libgl1 libegl1 libxrender1 libxfixes3 libxslt1.1 geoclue-2.0»

Пока игнорируем и нажимаем «ОК». Процесс инсталляции продолжится и вполне успешно дойдёт до конца.

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

Правда, чтобы программа 1С запустилась, нужно сделать ещё кое-что. Сначала запустим сервер 1С. Программа 1С установилась в каталог /opt/1cv8. Заходим туда, в каталог x86_64 и далее в каталог 8.3.21.1393. Там мы увидим знакомые файлы программы 1С. Для запуска сервера нужен файл ragent. Это исполняемый файл агента сервера. Запускается он с рядом опций, либо в режиме демона, либо нет.

Пробуем запустить (пока без демона):

./ragent -port 1540 -regport 1541 -range 1560:1591

Получаем ответ:

1C:Enterprise 8.3 (x86-64) (8.3.21.1393) Server Agent started. Ctrl+C to exit.

1C:Enterprise 8.3 (x86-64) (8.3.21.1393) Server Agent finished.

То есть сервер запускается и тут же падает. Оказывается, чтобы этот агент работал, нужно, чтобы в файле /etc/hosts был прописан наш ip-адрес и имя хоста, не localhost, а именно настоящий ip-адрес и конкретное имя хоста. Прописываем эти данные, запускаем заново:

./ragent -port 1540 -regport 1541 -range 1560:1591

Ответ:

1C:Enterprise 8.3 (x86-64) (8.3.21.1393) Server Agent started. Ctrl+C to exit.

1C:Enterprise 8.3 (x86-64) (8.3.21.1393) Working Process started. Ctrl+C to exit.

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

1C:Enterprise 8.3 (x86-64) (8.3.22.1603) Server Agent started. Ctrl+C to exit.

1C:Enterprise 8.3 (x86-64) (8.3.22.1603) Cluster Manager started. Ctrl+C to exit.

1C:Enterprise 8.3 (x86-64) (8.3.22.1603) Working Process started. Ctrl+C to exit.

Получилось. Сервер 1С запущен и не падает. Как служба он нигде не прописался. Можно, конечно, задаться целью и сделать это самостоятельно. Пока нам это не нужно так сильно, поэтому можно сделать по-простому — записать запуск сервиса в файл /etc/rc.d/rc.local. В режиме демона нужно добавить опцию -daemon.

Теперь, когда все серверы установлены и запущены, можно попробовать запустить клиентскую программу и создать базу данных. Программная оболочка запускается файлом /opt/1cv8/common/1cestart. Или через графическое меню нашей графической среды, которую мы выбрали для установки на сервер (KDE, GNOME, MATE, XFCE, LDXE и т. д.), в разделе «офис». Запускать надо уже не от root, а от обычного пользователя. Однако, и здесь есть подводные камни. Просто так она не запустится. При попытке запустить этот файл в консоли мы увидим сообщение:

./1cestart: /opt/1cv8/common/libstdc++.so.6: version `GLIBCXX_3.4.30′ not found (required by /lib64/libicuuc.so.69)

Удивительно, но эта ошибка исправляется так: из каталогов /opt/1cv8/common и /opt/1cv8/x86_64/8.3.21.1393 удаляется файл libstdc++.so.6.

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

Это так, если запускать через консоль. Если через графическое меню, то тут тоже требуется некоторая доработка. В меню появилось несколько значков:

1С:Предприятие 64

1С:Предприятие 64 (8.3.21.1393)

1С:Предприятие — Толстый клиент 64 (8.3.21.1393)

1С:Предприятие — Тонкий клиент 64 (8.3.21.1393)

И значок «1С:Предприятие 64» не работает, так как почему-то ссылается на несуществующий файл /opt/1cv8/x86_64/8.3.21.1393/1cestart, хотя должен был ссылаться на /opt/1cv8/common/1cestart.

Давайте исправим эту недоработку, отредактируем файл /usr/share/applications/1cestart-8.3.21-1393.desktop. В строчке Exec= нужно исправить путь к исполняемому файлу.

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

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

Теперь можно попытаться создать базу данных 1С через программу 1С на нашем сервере баз данных PostgreSQL.

Запускаем программу, нажимаем «Да», выбираем «создание новой информационной базы». Пока у нас не установлено никаких шаблонов, выбираем создание без конфигурации. И выбираем создание базы на сервере 1С:Предприятие. Зададим, для начала, такие параметры:

Кластер серверов 1С:Предприятие ip-адрес нашего сервера

Имя информационной базы в кластере любое имя, например test1

Защищённое соединение Выключено

Тип СУБД PostgreSQL

Сервер баз данных 127.0.0.1

Имя базы данных test1

Пользователь базы данных тот, которого мы создавали во 2 части, pg1cv8

Пароль пользователя заданный во 2 части пароль пользователя pg1cv8

Смещение дат 0

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

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

Всё, сервер 1С установлен, произведено его соединение с сервером баз данных и получено работающее клиентское приложение. Далее можно загружать дампы баз или создавать новые из шаблонов. Или делать собственные конфигурации.

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

Часть 4. Терминальный сервер

Наиболее известным терминальным сервером является сервер на ОС Windows по протоколу RDP. У нас стоит задача сделать нечто подобное, не прибегая к программным продуктам Microsoft, а используя исключительно свободное ПО.

Есть несколько разных вариантов, как можно организовать систему с удалёнными рабочими столами. Это может быть: удалённое подключение к X-серверу (особенно для клиентов на Линуксе), запуск графических приложений или целиком рабочего стола через ssh, подключение по протоколу VNC (Virtual Network Computing), смешанный вариант (инициализация и расшаривание ресурсов по ssh плюс рабочий стол по vnc). В зависимости от ситуации и условий подключения клиентов можно применять разные варианты на одном и том же сервере.

Удалённое подключение к X-серверу мы здесь рассматривать не будем, так как это не самый оптимальный вариант, весьма чувствительный к сетевой нагрузке.

Начнём с сервера vnc без всякого использования ssh. Данный вариант вполне успешно можно использовать для клиентов на разных ОС.

Установим необходимый пакет:

dnf install tigervnc-server

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

Чтобы настроить сервис для какого-либо пользователя нужно проделать следующие действия:

• Залогиниваемся в командной строке настраиваемым пользователем (предварительно этот пользователь должен быть создан в системе):

su имя_пользователя (если мы работаем под пользователем root, либо просто залогиниваемся нужным пользователем и открываем командную строку)

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

vncpasswd

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

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

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

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

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

При этом файл нужно переименовать, добавив имя пользователя, например vncserver-vasya@.service

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

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

[Unit]

Description=Remote desktop service (VNC)

After=syslog.target network.target

[Service]

Type=forking

ExecStartPre=+/usr/libexec/vncsession-restore %i

ExecStart=/usr/libexec/vncsession-start %i

PIDFile=/run/vncsession-%i.pid

SELinuxContext=system_u:system_r:vnc_session_t:s0

[Install]

WantedBy=multi-user.target

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

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

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

:1=vasya

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

:2=fedya

Помимо того, что это будет номер дисплея, назначенный этому пользователю, это также будет смещением для номера порта, на котором будет запускаться vnc-сервер для данного пользователя. По-умолчанию, в единичном экземпляре, vnc-сервер запускается на порту 5900. Но если нужно запускать несколько сеансов (тем более, одновременно), нужно несколько портов для этого. Поэтому здесь номер дисплея будет смещением для номера порта. То есть для пользователя vasya сервер будет запущен на порту 5901, для пользователя fedya — на порту 5902. И так далее.

Настройка отдельного пользователя на этом заканчивается. Для проверки можно запустить vnc-сервер для нашего пользователя:

systemctl start vncserver-vasya@:1.service

Обратите внимание, что перед словом service также указывается номер дисплея.

Если всё сделано правильно, то сервер запустится. Можно проверить статус службы:

systemctl status vncserver-vasya@:1.service

Или посмотреть системные процессы:

ps -eF | grep vnc

Должен быть примерно такой процесс:

vasya 61134 61124 15 44729 75460 9 13:01 ? 00:00:16 /usr/bin/Xvnc :1 -geometry 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. Пишем туда следующее:

[Unit]

Description=vnc pre-socket

PartOf=vnc-for-vasya.service

[Socket]

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

RemoveOnStop=on

[Install]

WantedBy=sockets.target

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

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

[Unit]

Description=vnc-pre-service

Requires=vnc-for-vasya.socket

[Service]

Type=simple

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

[Install]

WantedBy=multi-user.target

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

#!/bin/bash

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

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

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

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

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

systemctl start vnc-for-vasya.socket

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

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

systemctl status vnc-for-vasya.socket

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

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

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

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

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

Triggers: ● vnc-for-vasya.service

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

Tasks: 0 (limit: 154557)

Memory: 8.0K

CPU: 951us

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

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

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

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

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

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

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

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

Давайте именно это и сделаем. Нужно добавить одну строку в файл /etc/systemd/system/vncserver-vasya@.service и привести файл к следующему виду:

[Unit]

Description=Remote desktop service (VNC)

After=syslog.target network.target

[Service]

Type=forking

ExecStartPre=+/usr/libexec/vncsession-restore %i

ExecStart=/usr/libexec/vncsession-start %i

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

PIDFile=/run/vncsession-%i.pid

SELinuxContext=system_u:system_r:vnc_session_t:s0

[Install]

WantedBy=multi-user.target

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

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

#!/bin/bash

systemctl start vnc-for-$1.socket

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

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

systemctl daemon-reload

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

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

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

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

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

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

#!/bin/bash

while read line;

do

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

vnc_socket.sh $vnc_user

done < /etc/tigervnc/vncserver.users

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

:1=vasya

:2=fedya

:3=masha

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

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

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

#!/bin/bash

vnc_boot.sh

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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