Настройка виртуальных хостов apache

HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP (hypertext transfer protocol). Как следует из названия, HTTP указывает, как передавать гипертекст (т.е. связанные веб-документы) между двумя компьютерами.

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

Текстовый (Все команды представлены в текстовом виде и пригодны для восприятия человеком) .
Не сохраняет состояние(ни клиент, ни сервер, не помнят о предыдущих соединениях. Например, опираясь только на HTTP, сервер не сможет вспомнить введенный вами пароль или на каком шаге транзакции вы находитесь. Для таких задач, вам потребуется сервер приложений.)

HTTP задает строгие правила, как клиент и сервер должны общаться. Мы рассмотрим непосредственно HTTP далее в техническом разделе. Вот некоторые из них:

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

На веб-сервере, HTTP сервер отвечает за обработку входящих запросов и ответ на них:

При получении запроса, HTTP сервер сначала проверяет существует ли ресурс по данному URL.
Если это так, веб-сервер отправляет содержимое файла обратно в браузер. Если нет, сервер приложений создает необходимый ресурс.
Если это не возможно, веб-сервер возвращает сообщение об ошибке в браузер, чаще всего “404 Not Found”. (Это ошибка настолько распространена, что многие веб-дизайнеры тратят большое количество времени на разработку 404 страниц об ошибках.)

Настройка виртуальных хостов Apache?

Я уже подробно рассматривал как настроить Apache в отдельной статье. Поэтому не буду полностью расписывать здесь все конфигурационные файлы. Остановимся на файлах виртуальных хостов. Для удобства они вынесены в отдельные папки:

/etc/apache2/sites-available
/etc/apache2/sites-enabled

Ясно, что это разделение очень условно. Вы можете его убрать и добавлять свои виртуальные хосты прямо в основной конфигурационный файл. Все файлы из этих папок подключаются к нему с помощью директив Include. Но ведь так намного удобнее. В папке sites-available находятся все конфигурационные файлы, но они пока еще не активированы и отсюда не импортируются никуда. При активации нужного хоста на него просто создается ссылка в папку /etc/apache2/sites-enabled.

Для примера, создадим новый конфигурационный файл для виртуального хоста site1.ru. Для этого просто скопируем существующую конфигурацию для хоста по умолчанию — 000-default:

Сначала рассмотрим синтаксис того, что вы увидите в этом файле:

<VirtualHost адрес_хоста_для прослушивания:порт>ServerName доменServerAlias псевдоним_доменаServerAdmin емейл@администратораDocumentRoot /путь/к/файлам/сайтаErrorLog /куда/сохранять/логи/ошибок/error.logCustomLog /куда/сохранять/логи/доступа/access.log combined</VirtualHost>

Это минимальная конфигурация, которую вам нужно указать, чтобы создать виртуальный хост Apache. Конечно, здесь вы можете использовать и другие директивы Apache, такие как Deny, Allow и многие другие. А теперь рассмотрим наш пример для тестового сайта site1.ru:

Здесь мы используем звездочку вместо ip адреса, это значит, что веб-сервер будет слушать соединения на всех адресах, как на внешнем, так и на localhost. Порт 80, это порт по умолчанию. Затем указываем домен, электронный адрес администратора, и путь к папке, в которой будут находиться данные сайта. Две строчки Log говорят куда сохранять логи, но добавлять их необязательно. Дальше, нам нужно активировать этот хост. Мы можем вручную создать ссылку или использовать уже заготовленную команду:

Затем перезапустите Apache:

И нам осталось все это протестировать. Если ваш сервер имен еще не направляет запросы к домену на ваш ip, а вы хотите уже проверить как все работает, можно пойти обходным путем. Для этого достаточно внести изменения в файл /etc/hosts на машине, с которой вы собрались открывать сайт. Этот файл, такой себе локальный DNS. Если компьютер находит ip для домена в нем, то запрос в интернет уже не отправляется. Если вы собираетесь тестировать с той же машины, на которую установлен Apache2, добавьте:

Если же это будет другой компьютер, то вместо 127.0.0.1 нужно использовать адрес вашего сервера, на котором установлен Apache. Затем можете открыть сайт в браузере:

Доступ к файловой базе 1с через интернет в браузере

Теперь перемещаемся на виртуальную машину с nginx. Предварительно не забудьте добавить dns запись в каком-то домене, по которой вы будете ходить в базу через интернет. Она нам нужна, чтобы выпустить бесплатный tls сертификат, чтобы ходить в базу по https. Я не буду привязываться к какой-то конкретной операционной системе и рассказывать, как все делать именно в ней. Систему выбирайте на свой вкус. Настройка будет одинаковой. Нам нужны будут в системе 2 пакета: nginx и certbot. Установите их:

# yum install nginx certbot

или

# apt install nginx certbot

На данную виртуальную машину должны быть проброшены 80 и 443 порты с внешнего ip адреса. Как это будет сделано, зависит от ваших сетевых настроек. В случае с proxmox я настраиваю подобный проброс с самого хоста с помощью iptables. Пример настройки iptables читайте в отдельной статье. Там есть и про проброс. Не буду на этом задерживаться в статье про 1С.

Теперь нам нужно получить сертификат. Для этого запускайте в консоли certbot и следуйте инструкциям. Перед этим остановите nginx. Для быстрого получения сертификата certbot предлагает временно запустить свой веб сервер на 80-м порту.

# systemctl stop nginx
# certbot certonly

Подробно получение сертификата let’s encrypt с помощью certbot я рассматриваю в статье про . Результатом работы certbot должны быть tls сертификаты в директории /etc/letsencrypt/live. Используем их в настройке виртуального хоста nginx для публикации баз 1С. Создаем в директории /etc/nginx/conf.d/ конфиг 1c.site.ru.conf примерно следующего содержания. Взял его с рабочего сервера.

server {
    listen 443 ssl http2;
    server_name 1c.site.ru;
    access_log /var/log/nginx/1c-access.log;
    error_log /var/log/nginx/1c-error.log;

    ssl_certificate /etc/letsencrypt/live/1c.site.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/1c.site.ru/privkey.pem;

    location /.well-known/acme-challenge/ {
    root /tmp;
    }

    location / {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/htpasswd.1c;
    proxy_pass http://10.10.10.11: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 1c.site.ru;
    return 301 https://1c.site.ru$request_uri;
}

В данном случае 10.10.10.11 — локальный ip адрес виртуальной машины с windows, где опубликована база 1С через apache. Доступ к 1С сразу же закрыт отдельным паролем и механизмом веб сервера auth basic. Создадим файл с именем пользователя и паролем, указанным в конфиге.

# htpasswd -c /etc/nginx/htpasswd.1c user1c

Если у вас нет в системе утилиты htpasswd, то установите пакет httpd-tools. Она из него. user1c — имя пользователя. Пароль вам предложат задать в консоли.

Теперь можно запускать nginx и проверять доступ к базе 1с по https с дополнительной авторизацией. Так как в конфиге nginx настроен proxy_pass всех запросов через location / , то на самой виртуалке с 1С вы можете публиковать сколько угодно баз через алиасы, например /buh3, /zup3 и т.д. Все они будут автоматом направляться с nginx на apache. При этом на самом nginx конфигурацию менять не придется.

Вот и все. Можно относительно безопасно выставлять такую конструкцию в интернет. В случае необходимости можно настроить fail2ban, если кто-то надумает перебирать пароли или просто выполнять непонятные запросы к веб серверу с опубликованными базами. При желании в том же nginx с помощью директив allow и deny можно ограничить доступ к виртуальному хосту с базами на уровне ip адресов. Это на случай, если не умеете делать то же самое на фаерволе. В nginx проще и быстрее.

Не забудьте настроить автоматическое обновление tls сертификатов. Как это сделать, я рассказываю в статье с настройкой web сервера. Ссылку на нее я дал выше.

Минусы и недостатки

Когда посетителей на сервере много, Апач работает медленно. А всё потому, что в 1995 году высокой нагрузкой считалось, условно, 1000 посетителей в минуту, а сейчас — миллион. И когда обращений к сайту становится слишком много (а Апач обрабатывает каждое соединение по очереди) — сервер не справляется и тормозит.

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

Публикация баз 1С на веб сервере

Идем на виртуалку с windows и работаем там с 1С. Кстати, если хотите обойтись вообще без windows, то есть возможность настроить публикацию баз 1С на linux на примере Centos.

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

Создаем там необходимую вам базу данных. Я покажу на примере публикации типовой базы Бухгалтерия 3.0. При первом запуске необходимо будет установить на этот компьютер софтовые лицензии. Они будут использоваться при доступе к базам через браузер.

Установка и настройка Apache 2.4 в Windows

Теперь устанавливаем apache 2.4. С ним опубликовать базы 1С проще и быстрее, чем с iis. Качаем apache отсюда — https://www.apachelounge.com/download/

Если у вас не установлен Visual C++ Redistributable for Visual Studio 2015-2019, то скачайте дистрибутивы там же. Бинарники apache скачали, теперь распакуем их в папку C:/apache24/. Затем идем в конфигурационный файл apache C:\Apache24\conf\httpd.conf, открываем его блокнотом и изменяем там несколько параметров:

ServerName localhost:80
ErrorLog "|C:/apache24/bin/rotatelogs.exe -l C:/apache24/logs/errorlog.%Y-%m-%d.log 2592000"

Последняя строка это автоматическая ротация логов. Рекомендую ее сразу настроить, а не откладывать на потом. Если у вас по какой-то причине нет возможности использовать стандартный порт 80, потому что он занят кем-то другим, то можно использовать любой другой, например 81. Я всегда так и делал раньше. Но с недавних пор это стало приводить к ошибке, так как после публикации баз 1c через reverse proxy с https, стали вылезать ссылки вида https://1c.server.ru:81. Подобные ссылки невозможно открыть. Это приводит к ошибкам в работе некоторых разделов базы, где эти ссылки вылезают. Подробнее этот момент я рассмотрю ниже, в разделе с возможными ошибками.

Если вы настраиваете apache на Windows Server, то скорее всего 80-й порт у вас будет занимать Служба веб-публикаций (World Wide Web Publushing Service) или W3SVC. Ее можно остановить и отключить.

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

netstat -ao

Дальше через диспетчер задач смотрите, какой процесс имеет указанный pid. В моем случае это apache. Если это какой-то системный процесс, у него будет pid 4.

Итак, конфиг apache отредактировали, порт 80 указали. Теперь установим apache 2.4 как службу windows

Для этого открываем командную строку от администратора (это важно), переходим в каталог C:\Apache24\bin и выполняем:

httpd.exe -k install

Вы можете увидеть ошибку, связанную с отсутствием fqdn имени у сервера. Но реально это не представляет проблемы, можно игнорировать.

Errors reported here must be corrected before the service can be started.
AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using fe80::955f:6a46:c404:c1f7. Set the 'ServerName' directive globally to suppress this message.

Переходим в оснастку windows Службы и запускаем Apache2.4.

Убедимся, что веб сервер нормально работает. Для этого в браузере достаточно открыть страницу http://localhost.

Вы должны увидеть сообщение It works! Если видите, то все в порядке.

Дальше выполняем непосредственно публикацию базы 1С через web сервер apache. Открываем базу через Конфигуратор, выбираем Администрирование -> Публикация на веб-сервере. В качестве каталога можно указать тот же, где лежит сам файл с базой.

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

После этого можно зайти в браузере по адресу http://localhost/buh3 и увидеть локальную файловую базу, которую мы только что опубликовали.

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

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

Первое, что нужно иметь ввиду: все сайты работаю на серверах с Linux. За 15 лет разработки я ни разу не встретил сервер, работающий на Windows. Обусловленно это тем, что Linux надежнее, быстрее, а главное – бесплатный

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

На сервере обычно установлена какая-нибудь Ubuntu или CentOS, т.к. с ними проще и быстрее работать. И разработчик (то есть – вы!) может установить туда любое программное обеспечение (программы, короче).

Вы знали, что когда вы открываете сайт, запрос от браузера обрабатывает не только конкретный компьютер (сервер), но и конкретная программа? Обычно эта программа называется «веб-сервер» и работает по порту 80. Когда вы открываете сайт, то порт 80 не указывается для краткости (является стандартом). А когда вы открываете сайт, работающий через https, то для работы используется порт 443, а не 80. Но на запрос отвечает та же программа – веб-сервер.

Сервер – это компьютер, на котором работает сайт. Веб-сервер – это программа, запущенная на этом компьютере, которая срабатывает при открытии вашего сайта.

Я пишу эту статью в 2019ом году, но уверен, что и много лет позже самым популярным сервером останется nginx. Чуть раньше самым популярным веб-сервером был Apache 2. Так называется программа, котороая откроет ваш сайт. Вы можете установить nginx на сервере простой командой (если на сервере Ubuntu):

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

Окей, мы поняли, что нам нужен веб-сервер (программа!), чтобы обрабатывать запросы пользователя.

На самом деле не важно, какой язык – веб-сервер вам всё равно понадобится, просто он может называться по-другому (не nginx и apache). Следующим шагом надо будет установить PHP и «соединить» его с веб-сервером таким образом, чтобы веб-сервер запускал интерпретатор PHP и передавал ему запрос, который пришел от пользователя

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

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

Обычно сайты используют еще и базу данных. Обычно это MySQL, всё по той же причине: она быстрая, мощная и бесплатная. Опять же, в обычном случае PHP (или другой язык) обращается к базе данных, чтобы забрать оттуда какие-то данные или что-нибудь туда записать. Например, нужно отобразить комментарий пользователя – нужно обратиться к базе данных и получить этот комментарий. Или администратор сайта написал новую статью (это я и делаю сейчас) – нужно обратиться к базе данных и записать новую статью туда.

Таким образом полная схема выглядит так: пользователь открывает сайт, происходит запрос к вашему серверу-компьютеру (или виртуальному компьютеру), запрос принимает программа-веб-сервер, запускает интерпретатор PHP (или другой язык), в свою очередь PHP обращается к базе данных и забирает оттуда конкретные данные (статьи, комментарии и т.п.). Потом PHP собирает страничку, отдает ее обратно веб-серверу и веб-сервер возвращает ее пользователю. Давайте посмотрим на мега-картинку (которую я нашел в гугле):

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

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Бэкап баз 1С

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

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

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

На windows сервере можно просто расшарить директорию с базами 1С, а на виртуалке для бэкапов подключить ее. Я обычно использую Linux систему для этого. В ней монтирую шару по smb. Как это сделать рассказываю в отдельной статье — Как быстро подмонтировать сетевой диск в Linux. После того, как подключили папку с базами 1С к бэкап серверу, можете делать с ними все, что угодно. Например, куда-то копировать с помощью rsync и сохранять изменившиеся базы. Подробно схему бэкапов с помощью rsync описываю тоже отдельно — настройка rsync для бэкапа. Обязательно одну копию держу локально на сервере с бэкапами, вторую отправляю куда-то в удаленный приемник. После этого шару отмонтирую. Она подключена только для копирования баз с windows машины на linux.

Так же для бэкапов вы можете использовать какое-нибудь S3 хранилище, например у того же Selectel. По моим недавним сравнениям по ценам там наиболее выгодные условия из известных хостеров. По крайней мере я дешевле не нашел. Заливать бэкапы в S3 можно с помощью утилиты rclone. У Selectel еще очень удобно сделано в плане настройки времени хранения данных в контейнерах. Я обычно создаю 3 разных контейнера:

Day — в него заливаются архивы каждый день. Срок хранения файлов в этом контейнере — 7 дней. Настраивается это штатно в панели управления. На стороне хоста, с которого заливаются данные, ничего делать не надо.
Week — архивы заливаются раз в неделю и хранятся 31 день.
Month — архивы заливаются раз в месяц и хранятся условно бесконечно.

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

Еще один вариант бэкапа — копировать базы по nfs на какой-то сервер. В общем, тут вариантов может быть очень много. Я для этого и использую такую схему — подключение директории с базами к linux серверу, а там уже возможности по работе с бэкапами безграничные. Можно на тот же Яндекс.Диск их передавать. Вот тоже статья по этому поводу — бэкап на яндекс диск. Правда там речь идет про сайт, но принципиальной разницы нет.

Программы для настройки сети

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

Программа Hamachi и ее настройка

Обзор и настройка модема D-Link Dir-320 Это одним из самых популярных сервисов для простого и быстрого создания виртуальных сетей.

Обратите внимание! Есть две вариации утилиты: бесплатная, которая способна создать одновременный доступ к сети для 16-ти человек, и платная расширенная версия с большим функционалом, созданным для упрощения работы. Стоимость составляет примерно 200 $ в год

Эта программа очень проста в настройке и в использовании в целом. Подключение Hamachi происходит в несколько шагов:

Стоимость составляет примерно 200 $ в год. Эта программа очень проста в настройке и в использовании в целом. Подключение Hamachi происходит в несколько шагов:

Сперва нужно запустить само приложение и открыть подменю «Параметры» во вкладке «Система».
В данном меню найти два ключевых параметра: «Шифрование» и «Сжатие». Во всплывающем списке следует установить значение «Любой».
Далее для настройки программы стоит перейти во вкладку «Дополнительные параметры» и запретить использование прокси-сервера. Там же установить параметр разрешения имен по протоколу mDNS. Стоит также проследить, чтобы для опции «Фильтрация трафика» было выбрано «Разрешить все».

Важно! Когда подключение к Интернету происходит через роутер, в настройках Hamachi нужно открыть порты для исправного функционирования. После проделанных операций можно считать, что локальная сеть через Интернет настроена

Программа будет функционировать в полном объёме, другие пользователи могут смело подключаться

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

Создание виртуальной сети, используя OpenVPN

Для создания более безопасного подключения к LANчерез Интернет стоит рассмотреть вариант установки OpenVPN. Эта программа использует вместо стандартных ключей известные сертификаты TLS/SSL. Для создания сети рекомендуется использовать ОС CentOS. Но официальном сайте OpenVPN можно найти вариации и для других ОС. Для установки и настройки нужно подключить репозиторий EPEL Linux.

Затем из распакованного репозитория устанавливается сам OpenVPN. Для настройки виртуальной сети используется конфигурационный файл, который копируется в используемую папку. Затем следует запустить редактор Nano для открытия и корректировки файла. Там нужно убрать комментарий из строки со словом «push» в начале. Это позволит клиентской версии программы маршрутизироваться через OpenVPN.

Важно! Аналогичную операцию стоит проделать и для строк, отвечающих за корневые DNS-сервера Google

Генерация ключей и сертификатов

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

После этого нужно найти и внести изменения в файл «vars», в нем можно будет найти всю необходимую информацию для скрипта: vim/etc/openvpn/easy-rsa/vars.

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

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

Настройка параметров маршрутизации

Для запуска нужно создать правило для Firewall Iptables для обеспечения правильной маршрутизации VPN подсети. Стоит также проверить возможность маршрутизации пакетов сервером, для чего стоит отредактировать файл Sysctl.

После всех правок настройки Sysctl применяются, и сервер можно запускать. Как только он начнет работать, стоит поместить его в автозагрузку.

Только тогда VPN сервер настроен и готов к работе.

Просмотр заблокированных строк в 1С

Ввиду своей деятельности, мне часто приходится рассказывать про различные аспекты оптимизации и в том числе про блокировки.
Очень часто слушатели задают следующие вопросы:
Как посмотреть в реальном времени, какие именно данные сейчас заблокированы?
Как понять, что сейчас заблокировано в терминах 1С?
Если гранулярность блокировки страница, как увидеть, какие данные в ней находятся?

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

1 стартмани

Какие бывают проблемы с работой в 1С через браузер

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

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

Еще один нюанс, связанный с обменом между базами. После обновления платформы на сервере, он перестает работать через браузер. Возникает ошибка доступа к COM объекту. Чтобы это исправить, надо выполнить на сервере регистрацию comcntr.dll примерно так.

regsvr32 "C:\Program Files\1cv8\8.3.18.1208\bin\comcntr.dll"

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

С недавних пор я столкнулся с новой для меня ошибкой при подобной публикации баз с использованием nginx и proxy_pass. Раньше я использовал отличный от 80-го порт в apache. Но периодически стали проскакивать ссылки при работе с опубликованной базой 1с примерно такого вида — https://1c.site.ru:81/ в случае, если вы используете 81-й порт. Запросы извне по этой ссылке уходят в никуда и возникают ошибки. На стороне клиента они выглядят так:

Uncaught TypeError: Cannot read property ‘toUpperCase’ of undefined on https://……./mod_main_loader.js

Ошибка совершенно не гуглится, так что потратил много времени на ее решение. Помог режим отладки в chrome. Я просто проверил все запросы и нашел ошибочные с кривыми урлами. И так и сяк пытался их решить редиректами на веб серверах, но в итоге пришлось в apache переехать на 80-й порт и ошибка ушла.

Ну и еще одно отмечу. Иногда apache зависает или начинает сильно тупить. Обычно после долгого аптайма в несколько недель. Я подробно не разбирался в проблеме. Предпочел просто перезапускать его раз в сутки ночью. Для этого сделал обычный bat файл и настроил запуск через планировщик Windows.

@echo off
sc stop "Apache2.4"
timeout 90
sc start "Apache2.4"

Понятно, что это грубый костыль, но проблему решает. Ночью все равно с 1С никто не работает. Это история не про отказоустойчивость, резервирование и работу 7/24/365.

Ngnix против Apache: Сравнение лицом к лицу

Apache

Простота. Легко разрабатывать и внедрять новые функции благодаря своей модели «одно соединение на весь процесс»
Производительность. Медленно в отображении статического контента, но быстрая в отображении динамического контента
Поддержка ОС. Поддерживает все ОС — Unix, в том числе и Windows
Гибкость. Можно настроить, добавив модули. Apache имел самую долгую динамическую загрузку модулей.
Поддержка и документация. Отличная поддержка и документация, как это было на рынке в течение очень долгого времени.

Ngnix

Простота. Сложный в разработке, поскольку он имеет сложную архитектуру для одновременной обработки нескольких соединений.
Производительность. В 2,5 раза быстрее, чем Apache, и потребляет меньше памяти
Поддержка ОС. Поддерживает все ОС — как Unix, так и Windows, однако производительность в Windows сравнительно менее стабильна.
Гибкость. NGINX версии 1.11.5 и NGINX Plus Release R11 представили совместимость для динамических модулей.
Поддержка и документация. В начале у NGINX была слабая поддержка, но с ростом популярности поддержка и документация стала доступной.

Как работает веб-сервер Apache?

Хоть Apache и называется веб-сервер, но в реальном положении вещей он является не сервером, а программой, которая запускается на сервере. Его задача установить соединение между сервером и браузером посетителей (Firefox, Google Chrome, Safari и др.) при доставке файлов туда и обратно между ними (клиент-серверная структура). Apache – это кроссплатформенное программное обеспечение, что значит оно хорошо работает как на Unix, так и на Windows серверах.

Когда посетитель хочет загрузить страницу вашего сайта, например, домашнюю страницу или страницу «О нас», его браузер отправляет запрос на ваш сервер и Apache возвращает ответ со всеми запрошенными файлами (текст, изображение и так далее). Сервер и клиент взаимодействуют по протоколу HTTP и Apache ответственен за гладкое и безопасное соединение между двумя машинами.

Apache хорошо и удобно настраиваемый поскольку имеет модульную структуру. Модули позволяют администраторам сервера включать или выключать дополнительную функциональность. У Apache есть модули безопасности, кэширования, редактирования URL, аутентификации посредством пароля и другие. Вы можете установить свою собственную конфигурацию через файл .htaccess, который является файлом настроек для Apache и поддерживается всеми тарифными планами Hostinger.

Знаете ли вы, что в Hostinger есть специальные предложения? Посетите нашу страницу купонов и сэкономьте до 75%! Не стоит забывать, что это предложение ограничено во времени!

Настройка Apache

Уже прошло то время, когда конфигурация Apache хранилась в одном файле. Но оно и правильно, когда все распределено по своим директориям, в конфигурационных файлах легче ориентироваться.

Все настройки содержатся в папке /etc/apache/:

Файл /etc/apache2/apache2.conf отвечает за основные настройки
/etc/apache2/conf-available/* — дополнительные настройки веб-сервера
/etc/apache2/mods-available/* — настройки модулей
/etc/apache2/sites-available/* — настойки виртуальных хостов
/etc/apache2/ports.conf — порты, на которых работает apache
/etc/apache2/envvars

Как вы заметили есть две папки для conf, mods и site. Это available и enabled. При включении модуля или хоста создается символическая ссылка из папки available (доступно) в папку enable (включено). Поэтому настройки лучше выполнять именно в папках available. Вообще говоря, можно было бы обойтись без этих папок, взять все и по старинке свалить в один файл, и все бы работало, но сейчас так никто не делает.

Сначала давайте рассмотрим главный файл конфигурации:

Timeout — указывает как долго сервер будет пытаться продолжить прерванную передачу или прием данных. 160 секунд будет вполне достаточно.

KeepAlive On — очень полезный параметр, позволяет передавать несколько файлов, за одно соединение, например, не только саму html страницу, но и картинки и css файлы.

MaxKeepAliveRequests 100 — максимальное количество запросов за одно соединение, чем больше, тем лучше.

KeepAliveTimeout 5 — таймаут соединения, обычно для загрузки страницы достаточно 5-10 секунд, так что больше ставить не нужно, но и рвать соединение раньше чем загрузились все данные тоже не нужно.

User, Group — пользователь и группа, от имени которых будет работать программа.

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

LogLevel — уровень логирования ошибок. По умолчанию используется warn, но чтобы логи заполнялись медленнее достаточно включить error

Include — все директивы include отвечают за подключение рассмотренных выше конфигурационных файлов.

Директивы Directory отвечают за настройку прав доступа к той или иной директории в файловой системе. Синтаксис здесь такой:

Здесь доступны такие основные опции:

AllowOverride — указывает нужно ли читать .htaccess файлы из этой директории, это такие же файлы настроек и таким же синтаксисом. All — разрешать все, None — не читать эти файлы.

DocumentRoot — устанавливает из какой папки нужно брать документы для отображенияа пользователю

Options — указывает какие особенности веб-сервера нужно разрешить в этой папке. Например, All — разрешить все, FollowSymLinks — переходить по символическим ссылкам, Indexes — отображать содержимое каталога если нет файла индекса.

Require — устанавливает, какие пользователи имеют доступ к этому каталогу. Require all denied — всем запретить, Require all granted — всем разрешить. можно использовать вместо all директиву user или group чтобы явно указать пользователя.

Order — позволяет управлять доступом к директории. Принимает два значения Allow,Deny — разрешить для всех, кроме указанных или Deny,Allow — запретить для всех, кроме указанных. Теперь мы можем запретить доступ к директории для всех: Deny from all, а затем разрешить только для приложения от losst.ru: Allow from losst.ru.

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

У нас остался файл /etc/apache2/ports.conf:

В нем только одна директива, Listen, которая указывает программе на каком порту нужно работать.

Последний файл /etc/apache2/envvars, его вы вряд ли будете использовать, в нем указанны переменные, которые можно использовать в других конфигурационных файлах.

Дальше поговорим немного о htacess. Совсем немного.