1с консоль кластера linux

Администрирование серверов 1с под linux (ubuntu)

1с и web разработка

В Windows есть оснастка «Администрирование серверов 1С: Предприятие», которая позволяет подключаться к кластерам серверов и управлять базами данных. А как управлять кластерами и базами в linux? Интересно? Тогда под кат

Пройдемся по пунктам выполняя наиболее востребованные команды. Заметьте, что я использовал 32 битную систему и 1С соответственно, поэтому если Вы используете 64 битную версию — путь к 1С будет скорее всего таким:/opt/1C/v8.3/x86_64/

Для начала запустим кластер серверов 1С следующей командой:

Информация о кластерах

Для получения информации о кластере в терминале надо ввести команду:

Вывод этой команды будет примерно такой:

В данном выводе нас особо интересует идентификатор кластера. В моем случае это «ef89b672-c6a6-11e4-ea91-0800274e0291». Мы будем использовать его для дальнейших манипуляций.

Список баз

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

Для получения списка баз вводим в терминале команду:

Удаление базы

Вводим команду с использование идентификатора кластера и базы, которую хотим удалить:

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

И не забываем удалить базу из postgresql, если наша цель — полное удаление базы.

Тут важный момент — после имени базы обязательно ставим точку с запятой.

Добавление базы

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

У этой команды будет вывод:

Который соответственно показывает идентификатор только что созданной базы.

А теперь разъяснения:

—create-database
при создании информационной базы создать базу данных

—name=
(обязательный) имя информационной базы

—dbms=MSSQLServer|PostgreSQL|IBMDB2|OracleDatabase
(обязательный) тип СУБД, в которой размещается информационная база:
MSSQLServer — MS SQL Server
PostgreSQL — PostgreSQL
IBMDB2 — IBM DB2
OracleDatabase — Oracle Database

—db-server=
(обязательный) имя сервера баз данных

—db-name=
(обязательный) имя базы данных

—locale=
(обязательный) идентификатор национальных настроек информационной базы

—db-user=
имя администратора базы данных

пароль администратора базы данных

—descr=
описание информационной базы

—date-offset=
смещение дат в информационной базе

—security-level=
уровень безопасности установки соединений с информационной базой

—scheduled-jobs-deny=on|off
управление блокировкой выполнения регламентных заданий:
on — выполнение регламентных заданий запрещено
off — выполнение регламентных заданий разрешено

—license-distribution=deny|allow
управление выдачей лицензий сервером 1С:Предприятия
deny — выдача лицензий запрещена
allow — выдача лицензий разрешена

Источник

Утилиты для администрирования кластера серверов 1С на Linux

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

Но! Подвижки в этом направлении есть.

Реализована возможность управления кластером сервером из встроенного языка. Управление выполняется с использованием сервера ras, без использования технологии COM.

Реализована возможность реализовать кроссплатформенный интерфейс администрирования кластера серверов «1С:Предприятия», не требующий точного совпадения версий клиентского приложения и кластера серверов. Стало возможно реализовать консоль кластера при работе под управлением ОС Linux. Стало возможно отказаться от консоли кластера, работающей под управлением Microsoft Management Console.

Так что в недалеком будущем, я полагаю, нас ждет GUI-шное управление сервером на Linux. Возможно, в виде отдельной конфигурации?

На данный момент можно “админить” сервер с помощью консольных утилит rac/ras, что не удобно.

ras.exe – непосредственно сам сервер администрирования.

rac.exe – утилита командной строки для обращения к серверу и выполнения операций с кластером серверов.

Различные обертки ras/rac:

Здесь – о ras/rac и программе-обертке на языке OneScript deployka.

Официальный Java-интерфейс для административного сервера.

Интерфейсная библиотека (oscript) к утилите администрирования кластера серверов 1С (rac).

Rac GUI – многоплатформенный GUI для управления кластером серверов 1С:Предприятия.

DroidRAC2 – реализация raс под Android.

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

UPDATE:

Оказывается, 19.03.2018 1С сделала анонс о создании, а недавно (18.11.2019) объявила о выпуске финальной версии своего нового инструментария 1С:Центр администрирования для автоматизации задач администрирования и эксплуатации информационных систем, построенных на платформе 1С:Предприятие 8 (здесь есть описание).

Продукт входит в состав «1С:Корпоративный инструментальный пакет 8» (1С:КИП), и я так понимаю, доступен лишь для владельцев лицензии КОРП.

Содержит набор готовых для использования наиболее распространенных сценариев автоматизации. Среди них:

Источник

Централизованное управление кластером 1С Предприятия, состоящим из нескольких рабочих серверов, работающих на платформе GNU/Linux

0. Общие моменты
В контексте задачи, обозначенной в заголовке статьи, предполагается что управлять серверами кластера 1С Предприятия мы будем из консоли GNU/Linux посредством bash-скрипта. Указанный скрипт, в свою очередь, взаимодействует с серверами кластера по протоколу ssh.
Осуществлять централизованное управление серверами кластера, можно с любого компьютера, работающего под управлением операционной системы GNU/Linux (например, таковым может стать один из центральных серверов кластера 1С Предприятия). Для наглядности излагаемого материала, будем исходить из следующей инфраструктуры: компьютер work — рабочий компьютер администратора, с которого будет осуществляться централизованное управление серверами кластера; сервера server_a, server_b, server_c — сервера из состава кластера серверов 1С Предприятия.
Вместе с тем предполагается, что на компьютере, с которого планируется осуществлять централизованное управление (запуск скрипта), уже существует пользователь (не root) и у него уже созданы ключи для ssh-клиента. Информация о том, как создать пользователя в ОС GNU/Linux и как создать ключи для ssh-клиента не является предметом данной статьи. Подробнее об этом можно узнать из страниц справочного руководства (man 8 useradd и man 1 ssh-keygen).
Все описанное в статье прошло проверку работоспособности на кластере 1С Предприятия, работающем под управлением ОС CentOS 7, но вполне может быть адаптировано под любой имеющийся дистрибутив GNU/Linux.

ВАЖНО: Ответственность за любые последствия, возникшие в результате внесения изменений в работающую систему по материалам данной статьи, лежат исключительно на лице, внесшим данные изменения!

1. Подготовка инфраструктуры серверов к централизованному управлению
Предполагается, что на всех серверах кластера (в нашем случае server_a, server_b и server_c) уже существует пользователь операционной системы (не
root), от имени которого будут выполняться удаленные команды. Одним из возможных вариантов, которым мы и воспользуемся, может быть задействование пользователя, созданного при установке серверных пакетов 1С Предприятия — usr1cv8 (имя пользователя может несколько отличаться, в зависимости от используемой версии 1С Предприятия).

1.1. Настройки sudo на рабочих серверах
На всех серверах кластера необходимо наделить выбранного пользователя правами на управление сервисами 1С Предприятия (сам сервер 1С Предприятия и сервер RAS, в случае его использования). Для этого мы создадим файл с именем, соответствующим имени пользователя (однако, имя файла может быть любым), в каталоге /etc/sudoers.d следующего содержания:

Текст 1: Содержимое файла /etc/sudoers.d/usr1cv8

Таким образом мы наделили пользователя usr1cv8 возможностью запускать и останавливать сервисы srv1cv83 и ras1cv83 без ввода пароля.
Для более детального изучения структуры конфигурационного файла рекомендуется обратиться к страницам справочного руководства (man 5 sudoers).
Проверить правильность сделанных настроек можно выполнив от имени выбранного пользователя соответствующие команды. В нашем случае, для сервера server_a эти команды будут иметь следующий вид:

Обе команды должны выполниться без запроса пароля и без каких-либо ошибок (дополнительных сообщений). После выполнения первой команды не должно остаться выполняющихся процессов, относящихся к серверу 1С Предприятия (ragent, rmngr и rphost). После выполнения второй команды все указанные процессы должны присутствовать в списке выполняющихся процессов.

Информацию о том как посмотреть список рабочих процессов можно почерпнуть в станицах справочного руководства (man 1 ps, man 1 pgrep).

1.2. Настройки ssh на рабочих серверах
Следующим этапом необходимо настроить возможность подключения к серверам кластера по протоколу ssh без необходимости ввода пароля пользователя. Для этого на всех серверах кластера, мы добавляем в домашнем каталоге пользователя usr1cv8 в каталог .ssh файл authorized_keys, в который помещаем публичный ключ пользователя, от имени которого мы будем запускать скрипт управления. В нашем случае это пользователь fedotov на компьютере work:

Текст 2: Примерное содержимое файла /home/usr1cv8/.ssh/authorized_keys

ВАЖНО: Права доступа к файлу authorized_keys должны быть не выше чем rw-r—r— (644). В противном случае сервер ssh будет все равно запрашивать пароль, т. к. будет считать что этот файл может быть скомпрометирован. Подробнее о назначении прав доступа можно узнать из страниц справочногоруководства (man 1 chmod).

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

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

На этом подготовительный этап можно считать завершенным!

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

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

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

Файл server_a.stoped при этом будет удален.
В «ручном» варианте в качестве параметра скрипту необходимо указать имя файла, содержащего список серверов, которыми требуется управлять. Запуск скрипта будет выглядеть следующим образом:

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

Источник

Сервер приложений 1С на Linux

В последнее время, всё чаще и чаще меня начинает душить жаба.
Большая, зелёная, она угнездилась где-то внутри и формирует категорическое нежелание платить за что либо, даже если это не мои личные деньги! Не платить вообще, или же по максимуму минимизировать затраты там, где это возможно.
И если ко всему прочему, необходимо организовать работу с 1С в малой или средней компании, при ограниченном бюджете, то напрашивается желание собрать сервер из того что есть и накатить на него что-нибудь бесплатное.
Это всё к тому, что совсем необязательно покупать для 1С-сервера, лицензии от MS Windows Server+Terminal Cals и MS SQL сервер. Также необязательно рассматривать различные утилиты бэкапа и прочего софта реализующего все фишки работы терминального сервера 1С.

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

Наименование	Стандартное лицензирование (руб.)	Вариант Linux + Postgres SQL (руб.)
Лицензии Windows
Windows Server 2012 Std.	45012	0
MS Windows Terminal Services Client Access License 2012 Single Language 1-device NoLevel OLP	102960 (20×78)	0
Лицензии 1С
1С: Предприятие 8.3.Лицензия на сервер (x86-64)	86400	86400
1С: Предприятие 8.3 Клиентская лицензия на 20 рабочих мест	78000	78000
Лицензии SQL
Лицензия на сервер MS SQL Server Standard 2012 Runtime для пользователей 1С: Предприятие 8	13381	0
Клиентский доступ на 20 рабочих мест к MS SQL Server 2012 Runtime для 1С: Предприятие 8	117748	0
Итого	443501	164400
Экономия	0	279101

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

Постановка задачи

• Создание шаблона виртуальной машины со следующими параметрами:
• ОС без потери производительности.
• Полноценный сервер терминалов.
• Возможность подключения по RDP(для совместимости клиентов).
• Возможность подключения через Web.
• Возможность поддержки от 1С.
• Возможность бэкапа баз как на локальные диски(сетевые шары), так и в облако.
• Возможность бэкапа всей виртуальной машины.

Итак, поехали:
Логически, наша цель выглядит вот так:

Сначала определимся с ОС. Я сразу выбрал CentOS-контейнер на системе виртуализации Proxmox, т.к. при контейнерной виртуализации LXC, VM использует ресурсы самого гипервизора, т.е. потери производительности нет.
Тем более, что в дальнейшем, можно добавить серверы в инфраструктуру и создать отказоустойчивый кластер совершенно бесплатно!
Собственно тема установки 1С на различные версии Linux — достаточно избита, поэтому здесь я постарался объединить в один рабочий мануал, все варианты установки и публикации сервиса, и бэкап.
Установка гипервизора Proxmox простейшая, качаем его отсюда.
Инсталлируется буквально в несколько кликов и ввод пароля админа.

Установка VM CentOS 6(занимает 2-3 минуты):

Загружаем шаблон LXC CentOS-6-default_20160205 из списка и жмем кнопку “Создать СТ”.
Также, при желании можно выбрать шаблон с Ubuntu, особой разницы нет.
Далее задаем параметры VM и выбираем скачанный шаблон.
Всё, в течении минуты у вас в наличии готовая ОС.
В файле /etc/hosts не должно быть записей формата localhost.localdomian или относящихся к IPv6, в случае отсутствия DNS-сервера, в нем должно быть прописано четкое соответствие IP-адрес сервера – FQDN имя – короткое имя. Пример правильного файла hosts:

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

Далее через терминал:

Здесь samba можно и не ставить, а все что нужно закачивать через WinSCP, но если мы делаем не для себя, а отдаем сервер клиенту, лучше установить, т.к. может понадобиться и регистрация в клиентском DNS, и закачка файлов именно через неё.
Проверяем включен ли SELinux:

Если нет (не Disabled), то правим файл /etc/sysconfig/selinux

Далее настраиваем терминальный сервер:

Добавляем необходимые шрифты и прочие утилиты:

Далее через RDP (или vnc):

1. Система-Параметры-Клавиатура-Раскладки-Параметры раскладки
2. В переключениях на другую раскладку, оставим только одну комбинацию (я сделал Левый Ctrl-Левый Shift)
3. Запустите приложение «Установка и удаление программ»
4. Введите в строку поиска слово «LibreOffice» и нажмите Поиск
5. Среди найденных пакетов выберите «Russian language pack for LibreOffice» и нажмите «Применить»

Всё, сервер в принципе готов (у меня ушло полчаса).

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

Варианты установки 1С:

Для того чтобы оптимизировать затраты, не всегда нужно сразу закупать клиент-серверную платформу. Ее стоимость, сопоставима со стоимостью недорогого сервера. Если в наличии имеется небольшая компания, с 5-6 одновременными подключениями к базе 1С, то можно просто купить клиентские лицензии для файлового варианта, что выйдет гораздо дешевле!
1. У нас есть клиентские лицензии на N клиентов (файловый режим).
В этом режиме клиенты будут работать с базой через веб-интерфейс (хочется сразу избежать проблем с подключением принтеров и пробросом дисков), а для административных задач — будет использоваться RDP. Да, можно конечно работать нативным клиентом через сетевую шару, установив Samba. Но это не имеет смысла для того, что мы делаем.
2. У нас есть лицензия на клиент-серверную платформу (SQL режим).
В SQL режиме клиенты могут работать и нативным клиентом с указанием сервера 1С Предприятия, и через веб, кому как удобнее. Также, есть доступ по RDP для администратора 1С.
Сначала качаем установочные пакеты с портала 1С (необходима авторизация):
rpm64.tar.gz — пакет серверных приложений
client.rpm64.tar.gz -пакет клиентских приложений
demodt.zip — тестовая база

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

Устанавливаем 1С предприятие:

-wsdir – имя алиаса веб-сервера для соединения с базой, в последствии мы будем обращаться к ней набирая в браузере адрес.сервера/base
-dir – директория где будут располагаться файлы web-интерфейса 1с (точнее один файл default.vrd);
-connStr – строка соединения с базой 1с предприятия;
-confPath – расположение конфигурационного файла web-сервера apache.

Рестартуем настраиваем Apache:

Набираем в браузере centos6-1c/demo и получаем знакомый интерфейс 1С:

Пробуем соединиться через RDP:

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

Установка для второго, SQL варианта:

Качаем 2 пакета, сам сервер и addon от 1С отсюда (нужен логин и пароль). Потом копируем с помощью winscp и распаковываем их в отдельную папку.
К сожалению, версия 9.4 ставится с ошибками (проблема с библиотекой libicu), поэтому ставим 9.3. Python из аддонов ставить не надо, выдаст ошибку.

Далее создаем русскую локализацию и инициируем служебную базу Postgres

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

Создаем пароль пользователю: postgres, пользователь postgres является администратором баз данных по умолчанию. И в данном примере пароль будет 123654:

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

После сохранения файла, перезапускаем сервис postgres:

Публикуем через http:

Рестартуем апач и 1С:

Проверяем работает ли сервер 1с предприятия. Для этого на сервере выполняем следующую комманду:

Через интерфейс Администрирования 1С Предприятия (клиент Windows) создаем базу:

Повторюсь, сервер должен отвечать клиенту по имени. Т.е. должен быть прописан либо в DNS, либо в hosts файле компьютера клиента.

Через конфигуратор (на windows-клиенте, или RDP), закачиваем бэкап вашей или демонстрационной базы.
Всё работает так же, как и в первом варианте, мы можем соединяться как через http, так и через RDP, плюс возможность соединения нативным клиентом.

Лицензирование:

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

Для компаний с малым количеством пользователей 1С подойдет вот этот вариант (на 5 пользователей).

Программная лицензия на сервер терминалов(веб-сервер):
Если 1С при запуске не затребует её сразу, то идём в Конфигуратор-Сервис-Лицензирование.
Программную лицензию (любую) рекомендуется получать «На этот компьютер» и «Всем пользователям данного компьютера».

USB ключ(HASP):
Сначала необходимо пробросить USB устройство в VM.
На proxmox:

Ищем нужное нам устройство и смотрим его ID: XXXX:YYYY
qm set 101 –usb0 host=XXXX:YYYY
где 101 — ID виртуальной машины куда будем пробрасывать порт.
Перезагружаем виртуалку.
Далее устанавливаем службу haspd:

Во время установки некоторые демоны не стартуют. Это нормально, потому что для их старта нужен модуль из пакета haspd-modules. Но haspd-modules нельзя поставить раньше, потому что по зависимостям haspd должен ставиться первым. Модуль, который выдает ошибку (фейлит) будет нормально запущен после установки модулей при следующем запуске сервера.
Правим конфиг /etc/haspd/hasplm.conf. Добавим в него строчку:
NHS_IP_LIMIT = 127.0.0.1, 172.16.2.0/24

Именно в этой строчке мы перечисляем сети (вместо 172.16.2.0 добавьте свою) и хосты, которые смогут видеть HASP-ключ.

Проверим работу демона haspd:

Демон haspd имеет встроенный веб сервер доступный по адресу: xx.xx.xx.xx:1947

Бэкап:

Можем сделать автоматический бэкап целой VM на удаленное хранилище (или же на другой диск) прямо из Proxmox:
Т.е. через веб-интерфейс Proxmox заходим во вкладку «Хранилище» и добавляем NFS-массив. Это может быть как обыкновенная NAS-хранилка, так и xNIX-сервер с папкой доступной через NFS (кому что удобнее). Затем, указываем содержимое (backup).
Сама 1С рекомендует вот это (нужны имя и пароль). Там говорится, что для файловой версии, достаточно простое копирование файлов, а клиент-серверную версию рекомендуется бэкапить средствами СУБД.

Если просто и быстро (без очистки), то можно в два действия:

и добавим задание в crontab:

В принципе, здесь нет ничего сложного — сейчас любая хранилка поддерживает NFS, так что подмонтировать и создать автоматический бэкап на нее не составит никаких проблем, так же как и на Windows ресурс.
Однако, очень часто возникает вопрос о безопасности хранения бэкапа. Правилом хорошего тона является хранение бэкапа минимум в двух географически разнесенных местах. Рассмотрим два варианта: классический FTP и облачный.

Простой бэкап с копированием по FTP:

Бэкап в облако с шифрованием:
В production рекомендую пользоваться консольным клиентом яндекс-диска.
Также, если вы используете какое то другое облако, поддерживающее webdav, можно монтировать его при помощи davfs.

Для корректной работы GPG добавляем строчку в /sbin/ifup-local:

В зависимости от того, в каком виде у вас БД (файловая или SQL) закомментируйте ненужные строки. В этом тестовом скрипте, использовался юзер postgres с паролем 123654 и БД — test2. Файловая база находилась в /home/1C.
На тот случай, если необходимо работать с диском яндекса напрямую, я оставил строки с CURL.
Даём скрипту права на запуск:

Добавим задание в crontab:

Постинсталл:

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

Правильная настройка:
Консоли администрирования нужен доступ к агенту сервера (ragent) по порту 1540, а для создания базы понадобится еще и доступ к рабочим процессам по портам 1562-1591. Толстому клиенту нужен доступ к менеджеру сервера (rmngr) по порту 1541 и рабочим процессам порты 1562-1591. Менеджеру haspd нужны порты 475 и 1947.
Остальное зависит от Ваших настроек. Для стандартно настроенного фаервола в CentOS набор разрешающих правил в /etc/sysconfig/iptables будет выглядеть приближенно так:

Обновление:
Обновление конфигурации происходит абсолютно так же, как и на windows версии, т.е. через конфигуратор.
Платформа обновляется простой процедурой скачивания rpm пакетов с сайта releases.1c.ru/project/Platform83, далее необходимо зайти в каталог с ними и выполнить команду:

Перед выполнением не забудьте сделать снэпшот и удостоверьтесь в наличии свежего бэкапа баз (предыдущие rpm пакеты тоже пока не удаляйте).

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

По умолчанию процесс ras запускается на TCP 1545.
rac обращается к ras, который уже обращается (управляет) кластером серверов.
1) Просто help на всякий случай (кстати, он довольно понятный и ясный)

1C:Enterprise 8.3 Remote Administrative Client Utility ‘1C’ 1996-2015
Утилита администрирования платформы 1С: Предприятие

rac [mode] [command] [options] [arguments]

help Отображение справочной информации для указанного режима.
agent Режим администрирования агента кластера серверов
cluster Режим администрирования кластера серверов
manager Режим администрирования менеджера кластера серверов
server Режим администрирования рабочего сервера
process Режим администрирования рабочего процесса
service Режим администрирования сервиса менеджера кластера
infobase Режим администрирования информационной базой
connection Режим администрирования соединений
session Режим администрирования сеансов информационных баз
lock Режим администрирования блокировок
rule Режим управления требованиями назначения
profile Режим управления профилями безопасности кластера

2) Просмотр списка доступных кластеров серверов 1с для управления

3) Создание информационной базы

4) Просмотр списка информационных баз кластера

5) Просмотр списка подключений к информационным базам кластера

Оптимизация PostgreSQL:

• postgresql.conf — основной файл с настройками СУБД
• pg_hba.conf — файл с настройками доступа для клиентов. В частности, тут можно указать каким пользователям с каких IP-адресов можно подключаться к определенным БД, и требуется ли проверять пароль пользователя, и если требуется — каким методом.
• pg_ident.conf — файл с преобразованием имен пользователей из системных во внутренние (вряд ли он потребуется большинству пользователей)

Для более тонкой настройки БД необходимо править файл postgresql.conf воспользовавшись онлайн сервисом. Либо вручную подобрать значения, почитав например эту статью. Подробно параметры расписаны в этой статье.

Подключение принтеров
Осуществляется через сервис CUPS, который устанавливается автоматом.
В сеансе RDP заходим по адресу localhost:631
При нажатии кнопки установить принтер — видим все сетевые принтеры в сети.
Если вы хотите пробросить свой личный принтер — дайте к нему доступ.

Выводы:

Мы сэкономили на лицензиях Windows Server + Terminal CALs, MS SQL Server + Connection CALs. Даже если посчитать стоимость лицензий от 1С, то Linux-вариант выигрывает! Также, собрав сервер из подручного железа, убедились в том, что по тестам(файловая версия), он работает быстрее чем windows-версия установленная на голом железе.
В итоге, мы смогли получить сервер (шаблон можно размножить), который можно рекомендовать в продакшн. Также, в дальнейшем, Proxmox как систему виртуализации, можно расширить и создать кластер.

P.S: Почему CentOS 6, а не 7? Потому что на момент написания статьи публикация приложения 1С через http поддерживала только apache 2.2. К тому же, в процессе настройки 7-й версии, появились какие то непонятные проблемы с polkitd.
P.P.S: Платформа, через некоторое время тестирования, все же потребовала лицензию.

Спасибо за внимание, жду Ваших комментариев!

Источник