В настоящее время популярным решением работы сервера 1С:Предприятие является его установка на ОС Linux различных редакций. Я расскажу, как на таком сервере выполнить публикацию баз 1С через веб сервер Apache на примере дистрибутива Debian. Сейчас это один из самых распространённых бесплатных дистрибутивов на базе ядра Linux.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Введение
В качестве основы я буду иметь ввиду статью по установке и настройке сервера 1С на базе Debian с СУБД PostgreSQL. Расширим её информацией по веб-публикации баз, работающих как на базе непосредственно сервера 1С, так и обычных файловых. Отличий в настройке практически не будет.
Веб-публикация будет выполнена штатным механизмом платформы 1С через утилиту webinst, которая входит в состав комплексного дистрибутива для Linux. Во время установки вы должны выбрать компонент ws примерно так:
# ./setup-full-8.3.24.1586-x86_64.run --mode unattended --enable-components server,ws
Если не сделали это сразу, то придётся доустановить.
Особенность работы с базой 1С через веб-публикацию
Работа баз данных 1С, опубликованных через веб сервер, обладает рядом особенностей, которые нужно иметь ввиду. В первую очередь это касается использования клиентских лицензий. Базу, опубликованную через веб сервер, можно открыть как напрямую в браузере, так и в тонком клиенте. С тонким клиентом всё более-менее понятно. Сначала лицензия ищется локально, если не будет найдена - переходим на сервер. В случае серверных баз, лицензия будет запрошена через сервер 1С, если база файловая - то поиск будет осуществлён на веб сервере.
В случае использования браузера для доступа к опубликованным базам, локально поиск лицензий не производится. Веб-клиент будет искать лицензию на сервере 1С:Предприятие в случае серверных баз, и на сервере, где установлен веб-сервер, в случае файловых. Причём для файловых баз лицензия выдаётся только на сеанс. Сколько баз в браузере будет открыто, столько клиентских лицензий потребуется. Часто это приводит к непониманию, куда потрачены все доступные лицензии. Один человек может открыть очень много вкладок с базами.
Лицензия для сеанса файловой базы по умолчанию остаётся использованной веб-сервером в течении 20 минут после отключения пользователя, если он крестиком закроет вкладку браузера. Я так понимаю, за это отвечает настройка базы время засыпания пассивного сеанса. Для освобождения лицензии надо завершать сеанс штатно через интерфейс 1С и раздел меню Выход. Пользователи так обычно не делают. По идее освободить лицензию можно перезапуском веб сервера, но на практике я не проверял это. Если у вас есть точная информация на этот счёт, поделитесь, пожалуйста, в комментариях.
И ещё один важный момент. Модуль 1С для веб-сервера — однопоточный. Все пользователи, работающие через него, выстраиваются в общую очередь запросов к базе. Для файловых баз это скорее плюс, так как там одновременная работа нескольких пользователей в одной базе приводит к снижению производительности. А для серверных баз, понятное дело, это будет бутылочным горлышком. Так что сфера применения веб-публикации ограничена этим нюансом. Данное ограничение можно обойти запуском нескольких экземпляров веб сервера. 1С не предоставляет никаких инструментов для подобной настройки, но на практике реализовать это несложно. Достаточно вручную подготовить конфигурации apache и запустить их на разных портах.
Установка веб сервера Apache
Переходим к настройке публикации баз 1С. Для этого нам понадобится веб сервер Apache. В общем случае его можно поставить на тот же сервер, где установлен сервер 1С. В дистрибутиве Debian устанавливаем его из базового репозитория, предварительно обновив базу пакетного менеджера:
# apt-get update # apt-get install apache2
После установки он будет автоматически запущен. Можно сразу проверить его работу, зайдя браузером по IP адресу сервера.
Если вы не видите страницу по умолчанию веб сервера Apache, проверьте, запущена ли у вас служба:
# systemctl status apache2
Если не запущена, посмотрите лог работы:
# journalctl -eu apache2.service
Также логи можно посмотреть в фале /var/log/syslog, если у вас установлен rsyslog и ведутся текстовые системные логи. Дополнительно полезная информация может быть в логе самой службы apache2 в файле /var/log/apache2/error.log. Дополнительно проверьте, слушает ли служба 80-й порт:
# ss -tulnp | grep 80 # ss -tulnp | grep apache
Если служба запущена, указанный порт прослушивается, но доступа к дефолтной страничке всё равно нет, проверяйте настройки файрвола. Данная тема выходит за рамки этой статьи. Либо отключите его, либо правильно настройте. По умолчанию в ОС Debian минимальной установки firewall отсутствует.
Теперь внесём небольшие изменения в работу веб сервера. Так как модуль 1С однопоточный, настроим однопоточную работу самого веб сервера. Для этого открываем настройки модуля MPM, которые находятся в файле /etc/apache2/mods-enabled/mpm_event.conf и изменяем там несколько параметров:
StartServers 1 MinSpareThreads 1 MaxSpareThreads 1
Остальные можно оставить по умолчанию. Проверяем конфигурацию apache и перезапускаем его:
# apachectl -t # apachectl restart
В завершении добавьте веб сервер Apache в автозагрузку при старте сервера:
# systemctl enable apache2
Публикация баз 1С
Приступаем к публикации баз. Для каждой опубликованной базы нужен уникальный url. В моём случае это будет IP адрес сервера и имя базы через слеш. Примерно так: 192.168.0.13/basa01. Создаём для каждой публикации отдельную директорию.
# mkdir /var/www/basa01
Публикуем базу с сервера 1С:Предприятие:
/opt/1cv8/x86_64/8.3.24.1586/webinst -publish -apache24 -wsdir basa01 -dir /var/www/basa01 -connstr "Srvr=prox-1csrv;Ref=basa01;" -confpath /etc/apache2/apache2.conf
-wsdir basa01 | часть url базы, которая будет добавляться после слеша, то есть это алиас в терминологии конфигурации apache |
-dir /var/www/basa01 | директория публикации, куда будет скопирован файл default.vrd с описанием подключения к базе |
-connstr "Srvr=prox-1csrv;Ref=basa01;" | параметры подключения к серверной базе, prox-1csrv - имя сервера 1С, basa01 - имя базы |
Публикуем файловую базу:
# /opt/1cv8/x86_64/8.3.24.1586/webinst -publish -apache24 -wsdir basa01 -dir /var/www/basa01 -connstr "File=/opt/basa01;" -confpath /etc/httpd/conf/httpd.conf
Все параметры те же самые, только вместо подключения к серверу, мы указываем директорию, где лежит файловая база: "File=/opt/basa01;".
Утилита webinst выполняет простые действия. Она добавляет в конфигурацию Apache следующие строки:
# 1c publication Alias "/basa01" "/var/www/basa01/" <Directory "/var/www/basa01/"> AllowOverride All Options None Require all granted SetHandler 1c-application ManagedApplicationDescriptor "/var/www/basa01/default.vrd" </Directory> LoadModule _1cws_module "/opt/1cv8/x86_64/8.3.24.1586/wsap24.so"
И копирует файл default.vrd в директорию /var/www/basa01/. В этом файле прописаны параметры подключения к базе в зависимости от типа базы: серверная или файловая. Всё то же самое вы можете выполнить вручную. Обращаю внимание на параметр sessionMaxAge в файле default.vrd. Он определяет время бездействия сеанса, после которого он завершается принудительно (в секундах). Его при желании можно увеличить.
Публикацию мы выполнили. Остаётся перезапустить веб сервер:
# apachectl -t # apachectl restart
Теперь можно идти браузером по адресу 192.168.0.13/basa01 и проверять веб-доступ к базе 1С.
Вы должны увидеть стандартное приветствие для входа с вводом имени пользователя и пароля. К опубликованной базе можно подключиться не только браузером, но и платформой, указав в качестве типа расположения базы веб-сервер:
При выборе того или иного типа подключения стоит руководствоваться не только удобством, но и наличием тех или иных лицензий. Как я уже говорил ранее, веб-клиент и платформа по-разному ищут и используют лицензии. Алгоритм поиска лицензий 1С очень наглядно описан в статье на infostart. Рекомендую ознакомиться и выбрать оптимальный для вас режим работы.
Мы выполнили публикацию базы 1С в локальной сети без использования TLS сертификатов и реального доменного имени. Подобная публикация вполне подходит для работы внутри локальной сети. Программисты могут использовать её для настройки обменов. Если же вам нужен доступ к опубликованной базе через интернет, то я рекомендую для этого использовать ещё один веб сервер на базе Nginx, который будет принимать на себя все пользовательские соединения и направлять их к Apache. В таком режиме работы это будет и удобнее, и безопаснее, так как к серверу 1С не будет прямого доступа из интернета.
Поясню ещё раз, что я имею ввиду. Для максимального быстродействия и снижения сетевых задержек, я установил веб сервер Apache на тот же сервер, где работает сервер 1С, либо лежат файловые базы. Этот сервер не доступен напрямую из интернета. И это хорошо. Но нам нужен доступ к базам из интернета. Мы может просто пробросить порты через маршрутизатор и получить прямой доступ к этому серверу, но это не очень удобно и безопасно.
Я предлагаю другую схему, когда на маршрутизатор, если он на базе Linux, либо на отдельную виртуальную машину с Linux устанавливается веб сервер Nginx. И уже к нему пробрасываются порты для доступа к нему из интернета. Этот сервер Nginx принимает все клиентские подключения и направляет в Apache. На этом же сервере настраивается доменное имя, TLS сертификат, дополнительная парольная защита и т.д. Если в компании используются ещё какие-то веб сервисы, то подобный сервер с Nginx используется как единая точка входа ко всем веб сервисам. Подробно про такой режим работы рассказано в статье Проксирование запросов в nginx с помощью proxy_pass.
Настройка HTTPS и парольного доступа к опубликованным базам 1С
Если вас устраивает простой доступ к базам по HTTP, который мы уже настроили, то дальше можете ничего не делать. Я покажу, как настроить дополнительный веб сервер на базе Nginx, где мы настроим доменное имя, получим TLS сертификат, добавим дополнительную парольную защиту. Это будет отдельная виртуальная машина тоже на базе Debian.
Сначала получим TLS сертификат. Для этого у вас должна быть настроена DNS запись, по которой можно попасть на данный сервер. В моём примере это будет 334427.simplecloud.ru. Устанавливаем certbot для получения сертификатов:
# apt install certbot
Получаем сертификат:
# certbot certonly -d 334427.simplecloud.ru
Отвечаем за на заданный вопрос 1: Spin up a temporary webserver (standalone)
Если у вас корректно настроена доменная запись, то в конце вы успешно получите сертификат.
Сам сертификат и ключ от него будут расположены в директории /etc/letsencrypt/live/334427.simplecloud.ru/.
Устанавливаем Nginx:
# apt-get install nginx
Проверяем, что он работает. Заходим по IP адресу и видим страницу по умолчанию. Создаём файл конфигурации /etc/nginx/conf.d/334427.simplecloud.ru.conf:
server { listen 443 ssl http2; server_name 334427.simplecloud.ru; access_log /var/log/nginx/334427.simplecloud.ru-access.log; error_log /var/log/nginx/334427.simplecloud.ru-error.log; ssl_certificate /etc/letsencrypt/live/334427.simplecloud.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/334427.simplecloud.ru/privkey.pem; location /.well-known/acme-challenge/ { root /tmp; } location / { proxy_pass http://192.168.0.13:80; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto https; } } server { listen 80; server_name 334427.simplecloud.ru; return 301 https://334427.simplecloud.ru$request_uri; }
192.168.0.13 - IP адрес локального сервера, где мы только что настроили веб-публикацию баз 1С.
Проверяем конфигурацию и перезапускаем Nginx:
# nginx -t # nginx -s reload
Теперь пройдя по DNS адресу на 334427.simplecloud.ru/basa01 вы попадёте в веб интерфейс опубликованной базы basa01.
Закроем доступ к веб интерфейсу от посторонних глаз дополнительным паролем самого веб сервера:
# apt-get install apache2-utils # htpasswd -c /etc/nginx/htpasswd.1c user1c
Указываем пароль для пользователя user1c. Мы создали файл htpasswd.1c, в котором будет храниться имя пользователя и пароль от веб доступа. Добавим его в конфигурационный файл /etc/nginx/conf.d/334427.simplecloud.ru.conf, чтобы получилось вот так:
location / { auth_basic "Enter Password"; auth_basic_user_file /etc/nginx/htpasswd.1c; proxy_pass http://192.168.0.13:80; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Proto https; }
Перезапускаем Nginx и проверяем:
# nginx -t # nginx -s reload
После ввода логина с паролем вы попадёте в стандартное приглашение на ввод учётных данных от базы 1С. Подобный пароль позволяет полностью скрыть от посторонних глаз любую информацию о том, что за ним находится. То есть со стороны невозможно понять, что у вас тут опубликованы базы 1С.
На этом всё. Не забудьте настроить автоматическое продление полученного сертификата. Информации на эту тему в интернете много, да и у меня на сайте есть во многих статьях про настройку веб сервера.
На этом сервере с Nginx, при желании, можно настроить fail2ban для блокировки нежелательных IP адресов, которые будут заниматься перебором пароля. Так же можно настроить доступ к публикации баз с помощью списков allow и deny, которые на основе модуля ngx_http_access_module nginx будут блокировать или разрешать доступ к веб серверу.
Заключение
Не забывайте, что сеансы к базам на веб сервере с публикацией расходуют оперативную память. Клиент 1С довольно прожорливый, так что следите за этим моментом. Хотя бы по 2 Гб для пользователя выделяйте.
Дам ещё совет из практики. Если есть возможность, подключайте пользователей через тонкий клиент. Через браузер временами случаются различные проблемы то с печатью, то с отображением какой-нибудь формы, то ещё с чем-то. Хотя последнее время не сталкивался с этим. Если идёт плотная работа в 1С, то через тонкий клиент это будет делать удобнее, чем через браузер. Там и отзывчивость интерфейса лучше.
Могу ещё дать небольшой совет по разворачиванию всей этой инфраструктуры на одиночном сервере для небольшой компании, которая хочет работать с 1С через интернет, но на своём сервере, чтобы базы всегда были под контролем и с полным доступом к ним. Предлагаю такую схему. Арендуется выделенный сервер, например в selectel с 32 или 64 Гб оперативной памяти. Можно на самом бюджетном сервере с 2 SSD, объединив их в RAID1 с помощью mdadm. Там есть готовые шаблоны. И стоить это будет в районе 5000 р. в месяц.
Устанавливаете туда Proxmox и делаете 3 виртуалки:
- Сервер 1С + Apache.
- Сервер с СУБД PostgreSQL.
- Сервер с Nginx. Тут же можно настроить VPN для доступа.
Сервер 1С может быть как на Windows, так и на Linux. Для данной схемы это не принципиально. Если сервер будет на Windows, то у меня есть отдельная статья для публикации баз там. Удобство данной схемы в том, что вы можете бэкапить полностью виртуальные машины. Удобнее, когда их несколько небольших, нежели одна большая. Плюс, вы можете гибко управлять потребляемыми ресурсами. Проще настроить одно приложение, которое точно знает, сколько есть оперативной памяти в его распоряжении. Когда все службы на одном сервере, они начинают конкурировать друг с другом за ресурсы. Также в этой схеме можно без проблем разнести виртуальные машины по разным физическим серверам, если на одном им станет тесно.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Спасибо за материал.
Владимир, был ли опыт автоматической аутентификации в 1С средствами AD под Linux (Debian/Ubuntu + Samba + Apache + файловая база 1C в виде публикации на веб-сервере)?
По найденным гайдам так и не смог добиться автоматического входа в базу, постоянно пароль запрашивает, но после пускает без проблем. Через IIS все успешно работает, и 1С верно определяет пользователя и пускает без ввода пароля.
Спасибо.
Есть еще вариант с развертыванием перед апачем nginx proxy manager вместо простого nginx - оно и серты выдаст и парольную защиту обеспечит.
Еще вариант - это развернуть https://github.com/chaitin/SafeLine . Будет и серты выдавать и waf обеспечит.
Можно и его. Неплохое решение для тех, кто хочет веб панель для управления. Можно ещё веб сервер caddy взять. Там настройка элементарна:
Если DNS записи для example.com настроены, то будет автоматически получен TLS сертификат от let's encrypt. Настройка вообще не нужна. Запускаем caddy с ключами и всё.
хорошая статья , спасибо . А если все находится в закрытом контуре и необходимо выпустить сертификат для домена , при этом letsencrypt zerossl не доступны для получения сертификата.
Если они не доступны для получения, то либо покупайте платные годовые, либо выпускайте свои через свой доверенный центр сертификации и распространяйте среди своих клиентов. Других вариантов тут нет. Можно с других машин получать сертификаты let's encrypt и переносить их на целевые сервера. Это можно автоматизировать тем или иным способом.
Можно пойти иным путём. Всё очень индивидуально, но всё же. Всё зависит от того, где у вас припаркованы доменные имена. У letsencript есть DNS chellenge. Можно выпустить Wildcard на домен. Пусть он у вас крутится где-нибудь и получает серты, вы их передаёте на ваш сервак во внутреннем периметре и пользуетесь. Мож сумбурно получилось, но как-то так. Да, у LE есть заготовки на популяные сервисы для DNS chellenge.