Разворачиваем рабочий сервер OneScript для конфигурации АИТП

Публикация № 1058386

Разработка - Языки и среды - OneScript

26
В статье описана методика развертывания рабочего сервера OneScript для конфигурации АИТП, на ОС CentOS 7.

Введение

Поскольку одной из возможностей конфигурации АИТП (проект на GitHub), является взаимодействие с компьютерами и оборудованием с использованием рабочих серверов, на основе http-сервисов OneScript, было-бы неплохо иметь справочные материалы по развертыванию этих самых серверов. Собственно, результатом попытки создать такие материалы и является настоящая статья.

Также, настоящая публикация может помочь в развертывании любых web-приложений OneScript, основанных на http-сервисах в среде ОС CentOS.

Данная операционная система выбрана ввиду того, что она достаточно распространена в корпоративной среде, а конфигурация АИТП также ориентирована на применение на предприятиях.

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

Подготовка лабораторной среды

Для тестового развертывания, на основе технологии Hyper-V, была создана лабораторная среда, включающая в себя платформу 1С:Предприятие, развернутую в клиент-серверном варианте, клиентский компьютер и DNS сервер (см. рис. 1.).

Рисунок 1. Схема лабораторной среды.

 

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

Далее предполагается, что все действия выполняются из-под аккаунта root, если не оговорено иное.

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

su -

Установка системы

Поскольку процесс установки CentOS является интуитивно понятным и достаточно хорошо описан в различных источниках, останавливаться на нем нет смысла. Поэтому, будем считать, что у нас уже имеется виртуальная машина, с установленной ОС – Centos 7 в минимальной конфигурации.

Начальная настройка firewall

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

Используя принцип наименьших привилегий, настроим firewall рабочего сервера таким образом, чтобы доступ к нему был ограничен протоколом SSH и был возможен только с компьютера управления. В качестве firewall в CentOS 7 по умолчанию используется firewalld, поэтому воспользуемся предлагаемой документацией, для реализации нашей цели.

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

firewall-cmd –zone=ИмяЗоны –list-all

Результаты представлены в таблице ниже:

Зона

Сервисы

Примечания

Trusted

 

Открыты все входящие соединения

Internal

ssh, mdns, samba-client, dhcpv6-client

 

Block

 

 

dmz

 

 

drop

 

 

external

ssh

 

home

ssh, mdns, samba-client, dhcpv6-client

 

public

ssh, dhcpv6-client

Является зоной по умолчанию после установки.

work

ssh, dhcpv6-client

 

 

Поскольку мы не планируем использование ipv6, использование сервиса mdns, а также работу с файлами по SMB – удалим эти сервисы (mdns, samba-client, dhcpv6-client) из всех зон:

firewall-cmd –zone=ИмяЗоны –remove-service=ИмяСервиса

Сохраним наши изменения:

firewall-cmd –runtime-to-permanent

Перезагрузим набор правил:

firewall-cmd –reload

Соотнесем все компьютеры и подсети для административных подключений с зоной internal.

Для этого, добавим источники в вышеуказанную зону:

firewall-cmd –zone=internal –add-source=ПодсетьИлиКомпьютерДляАдминистрирования

В нашем случае – это компьютер 172.16.210.36/32

Заблокируем все входящие подключения, установив зону по умолчанию – block

firewall-cmd –set-default-zone=block

Удалим сервис ssh из всех зон, кроме internal, т.к. в ней будут располагаться наши компьютеры для администрирования:

firewall-cmd –zone=ИмяЗоны –remove-service=ssh

Сохраним изменения:

firewall-cmd –runtime-to-permanent

Перезагрузим набор правил:

firewall-cmd –reload

Настройка сетевого интерфейса

Настроим сетевой интерфейс нашей виртуальной машины таким образом, чтобы он использовал статический ip адрес. Это можно сделать, отредактировав соответствующий файл (в данном случае ifcfg-eth0), который расположен в папке /etc/sysconfig/network-scripts. В качестве справочного пособия, можно воспользоваться этой статьей.

Конфигурация будет выглядеть примерно следующим образом:

Рисунок 2. Ip-конфигурация рабочего сервера.

 

Перезагружаем сервер:

reboot

Если все настроено правильно, Вы сможете подключиться к серверу удаленно, с использованием, к примеру – putty, только с компьютера управления.

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

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

Удаляем postfix:

systemctl stop postfix
yum remove postfix

Удаляем chronyd:

systemctl stop chronyd
yum remove chrony

Обновление системы

Обновим систему:

yum upgrade

Подготовка среды для web-приложения

Установка Apache

Для установки apache, выполним нижеследующую команду:

yum install httpd

Разрешаем старт Apache при загрузке

Systemctl enable httpd

Запускаем сервис:

systemctl start httpd

Разрешим доступ по протоколу http с компьютера администратора:

firewall-cmd –zone=internall –add-service=http
firewall-cmd –runtime-to-permanent
firewall-cmd –reload

Тестируем работоспособность сервера, обратившись к нему из браузера. Если все настроено правильно, Вы получите резульат, аналогичный рис. 3.

Рисунок 3. Результат теста http-сервера.

 

Установка mono

Для установки, воспользуемся штатной документацией:

Подключаем репозитарий и устанавливаем mono:

rpm --import "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF"
curl https://download.mono-project.com/repo/centos7-stable.repo | tee /etc/yum.repos.d/mono-centos7-stable.repo
yum install mono-complete

 

Устанавливаем поддержку mono в Apache:

yum install httpd mod_mono mono-web

Исправляем файлы /bin/mod-mono-server и /bin/mod-mono-server2

Рисунок 4. Содержимое файлов mod-mono-server & mod-mono-server2

 

Запрещаем политику selinux, для этого, редактируем файл /etc/sysconfig/selinux.

SELINUX=disabled

В папке /var/www/html создаем тестовый файл index.aspx, с содержимым, как в этой публикации.

Перезагружаем сервер:

reboot

Если все настроено верно, при обращении к серверу из браузера, мы должны увидеть, созданную страницу (см. рис. 5).

Рисунок 5. Тестовая страница ASP.NET

 

Включение поддержки OneScript

В нашем тестовом случае, хоть это и не рекомендуется, отредактируем файл /etc/httpd/conf.d/mod_mono.conf.

Добавим расширение файлов OneScript (*.os) в список расширений, обрабатываемых ASP.NET

AddType application/x-asp-net .os

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

Сохраняем файл и рестартуем Apache.

Настройка SSL

Поскольку взаимодействие между 1С:Предприятие и web-приложением осуществляется по сети, существует некоторая вероятность перехвата и анализа траффика злоумышленниками. И хотя эта вероятность небольшая, хорошей идеей является шифрование траффика. Для реализации этой задачи используем технологию SSL, которая в свою очередь опирается на инфраструктуру публичных лючей (PKI). Как правило, в крупных организациях развернута своя PKI, которая удовлетворяет внутренние потребности организации. Также, можно воспользоваться самоподписанными сертификатами, однако их придется размещать также и на всех компьютерах, с которых производится доступ, дабы обеспечить доверие к сертификату сервера. Ввиду относительно небольшого риска записи траффика и просмотра конфиденциальной информации, а также дополнительной нагрузки на администраторов по размещению и обновлению сертификатов, возможно настройка SSL в некоторых случаях будет избыточной. Однако, поскольку данная тема выходит за рамки настоящей статьи, будем полагать, что у нас уже имеется необходимый серификат для web-сервера. Для нашей лабораторной среды, при помощи сервиса sslforfree был создан тестовый сертификат , который вполне подходит под нашу задачу.

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

Устанавливаем модуль поддержки ssl:

yum install mod_ssl

Скопируем архив с файлами сертификата на сервер (можно использовать к примеру WinSCP) .

В нашем случае, архив был скопирован в папку /home/coadmin.

Разархивируем архив и переместим файлы в соответствующие папки.

Файл сертификата:

cp /home/coadmin/certificate.crt /etc/pki/tls/certs/itpa.cf.crt

Приватный ключ:

cp /home/coadmin/private.key /etc/pki/tls/private/itpa.cf.key

Отредактируем файл /etc/httpd/conf.d/ssl.conf

Редактируем ключи:

<VirtualHost *:443>
SSLCertificateFile=/etc/pki/tls/certs/itpa.cf.crt
SSLCertificateKeyFile=/etc/pki/tls/private/itpa.cf.key
ServerName itpa.cf

Раскомментируем строки:

DocumentRoot “/var/www/html”
SSLCACertificateFile=/etc/pki/tls/certs/ca-bundle.crt

Добавим возможность доступа по https с компьютеров администраторов:

firewall-cmd –zone=internal –add-service=https
firewall-cmd –runtime-to-permanent
firewall-cmd –reload

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

systemctl restart httpd

Обратимся к серверу из браузера по протоколу https. Если все настроено правильно, увидим примерно следующую страницу (см. рис. 6):

Рисунок 6. Результаты тестирования ssl

 

Поскольку мы обратились к серверу по ip-адресу и имя хоста не совпадает с указанным в url, мы увидим соответствующее предупреждение безопасности. Также следует отметить, что не все программные компоненты могут работать, игнорируя это несоответствие, поэтому, создадим на DNS-сервере A-запись нашего сервера таким образом, чтобы DNS-имя хоста совпадало с указанным в сертификате (см. рис. 1).

Обратимся к серверу по DNS-имени и убедимся, что предупреждение безопасности исчезло (см. рис. 7).

Рисунок 7. Результат тестирования ssl по DNS-имени.

 

Настройка проверки подлинности

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

В качестве статьи-руководства, можно использовать эту статью или эту.

Создаем пользователя приложения с именем onescript:

htpasswd -c /etc/httpd/.htpasswd onescript

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

Отредактируем файл /etc/httpd/conf/httpd.conf

В нем уже имеется записи Directory нижеследующего вида:

<Directory “/var/www”>
    AllowOverride none
    Require all granted
</Directory>
<Directory “/var/www/html>
    AllowOverride none
    Require all granted
</Directory>

Заменим директиву AllowOverride none на:

AllowOverride All

Сохраним изменения

Отредактируем файл /etc/httpd/conf.d/ssl.conf

Найдем фрагмент:

<Directory “/var/www/cgi-bin”>
    SSLOptions +StdEnvVars
</Directory>

Поскольку мы не планируем использование cgi, изменим путь на /var/www/html

Также добавим нижеследующие строки:

AuthName “Access Restricted”
AuthType Basic
AuthUserFile /etc/httpd/.htpasswd
Require valid-user

Сохраним файл и рестартуем Apache

systemctl restart httpd

Проверим необходимость ввода имени пользователя и пароля, обратившись к серверу из браузера (см. рис 8.).

Рисунок 8. Результаты проверки ограничения доступа к web-приложению.

 

Удаление поддержки протокола HTTP

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

Для этого, закомментируем строку Listen 80, в файле /etc/httpd/conf/httpd.conf

Сохраним файл и рестартуем Apache:

systemctl restart httpd

Просмотрим порты, которые прослушивает наш сервер, воспользовашись утилитой ss (см. рис 9.).

Рисунок 9. Прослушиваемые порты.

 

Удалим доступ к серверу по протоколу http из правил firewall:

firewall-cmd –zone=internal –remove-service=http
firewall-cmd –runtime-to-permanent
firewall-cmd –reload

Разрешение доступа к рабочему серверу с серверов приложений 1С:Предприятие

Соотнесем серверы приложений 1С:Предприятие с зоной work (в нашем случае, это один сервер – 172.16.210.44/32):

firewall-cmd –zone=work –add-source=172.16.210.44/32

Разрешим доступ только по протоколу https:

firewall-cmd –zone=work –add-service=https

Сохраняем настройки и перезагружаем правила:

firewall-cmd –runtime-to-permanent
firewall-cmd –reload

Развертывание web-приложения

Далее предполагается, что имеется развернутая в клиент-серверном варианте платформа 1С:Предприятие, и уже существует информационная база, с загруженной конфигурацией АИТП, версии не ниже 0.2.4.42.

Размещение файлов web-приложения

Подключимся к информационной базе в режиме конфигуратора и сохраним содержимое макета РабочийСерверOneScriptWebПриложениеАИТП на диск, как zip-архив.

Скопируем полученный архив на рабочий сервер, скажем в папку home пользователя, используя что-нибудь типа WinSCP.

Разархивируем архив в папку /var/www/html.

cd /home/ВашПользователь
unzip workserver.zip –d /var/www/html

После разархивации папка /var/www/html будет иметь примерно следующий вид (см. рис 10.).

Рисунок 10. Содержимое папки html.

 

Удалим файл web.config, так как он предназначен для ОС Windows:

rm web.config

Переименуем файл web.config.linux в web.config

mv web.config.linux web.config

Обновление для версии 0.4.10.61 и старше

Если Вы использовали макет из версии 0.4.10.61 и старше, состав папки /var/www/html будет несколько отличаться (см. рис. 10а).

Рисунок 10а. Состав папки /var/www/html для версии 0.4.10.61 и старше.

 

Как можно увидеть, появились две новые папки: Log и JobResults, а также файл serviceurl. Папка Log используется для хранения логов загрузки web-приложения. По умолчанию, логгирование отключено и может быть активировано раскомментированием соответствующего ключа в web.config.

Папка JobResults и файл serviceurl используются в механизме асинхронного выполнения скриптов. В папку JobResults сохраняются результаты, возвращаемые асинхронно выполняемыми скриптами, а файл serviceurl содержит идентификатор web-приложения.

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

# Устанавливаем владельца
chown -R apache /var/www/html/Log
chown -R apache /var/www/html/JobResults
# Удаляем все права
chmod -R ugo-rwx /var/www/html/Log
chmod -R ugo-rwx /var/www/html/JobResults
# Добавляем права на папку
chmod -R u+rw /var/www/html/Log
chmod -R u+rw /var/www/html/JobResults
# Добавляем возможность просмотра папки
chmod u+rwx /var/www/html/Log
chmod u+rwx /var/www/html/JobResults

Настроим идентификатор сервиса, отредактировав файл serviceurl. Его содержимое, должно соответствовать коду элемента справочника Сервисы OneScript в конфигурации (см. рис. 10b.).

Рисунок 10b. Настройка файла serviceurl.

 

На этом развертывание web-приложения завершено.

Настройка подключения к рабочему серверу OneScript из 1С:Предприятие

Запустим конфигурацию АИТП в режиме предприятие.

Выберем раздел Сервисы OneScript и запустим консоль OneScript (см. рис. 11.).

Рисунок 11. Консоль OneScript.

 

Настроим соединение с рабочим сервером (см. рис. 12.).

Рисунок 12. Настройка соединения с рабочим сервером.

 

В качестве учетных данных используем учетные данные пользователя, созданные на этапе настройки проверки подлинности web-сервера.

Тестирование взаимодействия

Для теста, напишем простейший скрипт:

Результат = “Hello World!”;

Нажмем кнопку “Выполнить скрипт”. Если настройки были произведены правильно, мы получим примерно следующий результат (см. рис. 12).

Рисунок 13. Результат выполнения кода на рабочем сервере.

 

Поскольку целью создания данного программного пакета является автоматизация, в том числе задач администрирования компьютеров, попробуем подключиться к серверу СУБД. Для этого используем компонент для работы с SSH, который встроен в web-приложение рабочего сервера.

В консоли, введем следующий код: 

	Попытка
		
		Клиент = Обработки.ФункцииКлиентSSH.НовыйКлиентSSH(Параметры["Хост"], Параметры["Порт"], Параметры["Пользователь"], Параметры["Пароль"]);
		Соединение = Клиент.ПолучитьСоединение();
		// Создаем команду
		Команда = Соединение.НовыйКомандаSSH(Параметры["Команда"], "UTF-8");
		Результат = Команда.ВыполнитьКоманду();
		Соединение.Разорвать();
		
	Исключение
		
		Ошибка = ОписаниеОшибки();
		
		Попытка
			Соединение.Разорвать();
		Исключение
		КонецПопытки;
		
		ВызватьИсключение Ошибка;		

	КонецПопытки;

Создадим параметры, заполним значения и выполним скрипт (см. рис. 14).

Рисунок 14. Результаты выполнения скрипта

 

Таким образом, можно вполне реализовать agentless управление компьютерами и оборудованием.

Заключение

Надеюсь, что настоящая публикация поможет вам в развертывании любого web-приложения на основе http-сервисов OneScript, включая штатную реализацию, поможет в использовании конфигурации АИТП для решения ваших задач, а также снимет некоторую часть вопросов, относительно безопасности использования http-сервисов OneScript.

P.S.

Всем удачи и с праздником Победы!

26

См. также

Специальные предложения

Избранное Подписка Сортировка: Древо
В этой теме еще нет сообщений.
Оставьте свое сообщение