Если вам нужно запустить ещё один процесс веб-сервера Apache, то с вероятностью 99,99% вам это, на самом деле, не нужно. Практически все задачи, для которых может потребоваться ещё один процесс Apache можно решать в рамках одного единственного процесса и конфигурационного файла. Продолжите изучение документации по веб-серверу и вы сможете решить вашу задачу более правильным путём, без запуска второго экземпляра Apache.
К примеру, если вы хотите чтобы на одном компьютере можно было запустить несколько сайтов, то смотрите статьи:
Если вы хотите, чтобы веб-сервер работал сразу на нескольких портах, то смотрите статьи:
Если вы хотите, чтобы веб-сервер одновременно работал и с обычными и безопасными соединениями HTTPS (используя сертификат SSL), то изучите:
Тем не менее, если вы твёрдо знаете, что вам нужен именно второй процесс Apache, то вы можете использовать опцию -f, после которой нужно указать альтернативный конфигурационный файл сервера. Если Apache уже запущен, то вам, как минимум, во втором конфигурационном файле нужно указать другой порт, поскольку в противном случае веб-сервер не запустится из-за ошибки: порт уже занят другой программой.
К примеру, я хочу запустить второй экземпляр Apache, исполнимый файл которого расположен по пути c:\Server\bin\Apache24\bin\httpd.exe при этом я хочу использовать конфигурационный файл c:\Server\bin\Apache24\conf\test_httpd.conf и я хочу выполнять запуск в режиме отладки (без отсоединения процесса от консоли) (-X):
В дополнении к опциям -f и -X также при запуске второго экземпляра программы могут пригодиться опции:
1С и Linux
Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.
суббота, 2 мая 2020 г.
Запуск нескольких экземпляров Apache для разных версий сервера 1с
Задача есть сервер с нескольким кластерами 1с разных версий. Нужно запустить несколько экземпляров Apache (на разных портах) и опубликовать базы 1с.
Первый сервер 1с на стандартных портах и путях (стандартная установка)
$ dpkg -l | grep 1c ii 1c-enterprise83-common 8.3.17-1386 amd64 1C:Enterprise 8.3 common components ii 1c-enterprise83-server 8.3.17-1386 amd64 1C:Enterprise 8.3 server for Linux ii 1c-enterprise83-ws 8.3.17-1386 amd64 1C:Enterpise 8.3 Web-services components for Linux
Где /var/www/ib/ demo — директория где будет создан vrd-файл, demo — имя ИБ, u2004 — адрес сервера 1С:Предпрятие, /etc/apache2 -web1 /conf-available/ demo .conf — путь до конфигурационного файла Apache.
#Подключаем базу test в кластере на не стандартных портах 1с
#Создаем директорию для vrd-файла: sudo mkdir -p /var/www/ib/ test
#А также файл конфигурации Apache:
sudo touch /etc/apache2 -web2 /conf-available/ test .conf
#Переходим в каталог со утилитой публикации веб-клиента (нестандартное расположение):
Запускаем утилиту публикации базы 1с: sudo ./webinst -apache24 -wsdir test -dir ‘/var/www/ib/ test ‘ -connstr ‘Srvr=» u2004 :1741 «;Ref=» test «;’ -confPath /etc/apache2 -web2 /conf-available/ test .conf
Где /var/www/ib/ test — директория где будет создан vrd-файл, test — имя ИБ, u2004 :1741 — адрес сервера 1С:Предпрятие, /etc/apache2 -web2 /conf-available/ test .conf — путь до конфигурационного файла Apache.
#Проверяем модуль wsap24.so должен быть правильно расположен, в данном случае #стандартный путь:
cat /etc/apache2- web2 /conf-available/ test .conf LoadModule _1cws_module «/opt/1C/v8.3.16.1148/x86_64/wsap24.so»
#Подключаем конфигурацию: sudo a2enconf -web2 test
#Отключаем конфигурацию: #sudo a2disconf -web2 test #не сейчас
Многоликий Apache. Размещаем несколько сайтов на одном веб-сервере
Архив номеров / 2005 / Выпуск №12 (37) / Многоликий Apache. Размещаем несколько сайтов на одном веб-сервере
Рубрика: Веб / Веб
ПАВЕЛ МАЛАХОВ
Многоликий Apache Размещаем несколько сайтов на одном веб-сервере
Установив веб-сервер Apache и предоставив через него на всеобщее обозрение свой сайт, некоторые и не подозревают, каким мощным инструментом они владеют. С его помощью можно управлять сотнями сайтов с разными именами и уровнями доступа. Денежная стоимость и временные затраты на добавление каждого сайта при этом минимальны.
Веб-сервер Apache, популярный благодаря своей прозрачности для программистов и администраторов и не в последнюю очередь благодаря бесплатности, реализован под все более-менее популярные операционные системы. Его настройки для всех ОС одинаковы, различаются только пути, где хранятся конфигурационные файлы. На одном сервере может быть запущено несколько экземпляров Apache, прослушивающих разные адреса и/или порты. Один экземпляр может обслуживать несколько сайтов (подробнее об этом ниже). Проект настолько популярен, что постоянно обрастает новой функциональностью. О степени популярности можно судить либо по статистике, что, на мой взгляд, довольно опрометчиво, либо по конкретным фактам. Фактов популярности Apache мы приведём два. Во-первых, его наличие в качестве веб-сервера по умолчанию в большинстве UNIX-подобных операционных систем. Во-вторых, такой гигант в области ИТ, как компания Oracle, принял его в состав своего продукта Oracle Application Server 10g, где он играет одну из ключевых ролей.
Компьютер с установленным пакетом Apache 1.3 или 2.0.
Адрес сервера в Интернете: 10.0.10.15 и имя: teo.mynetwork.ru.
Адрес сервера в локальной сети: 192.168.100.18.
Несколько сайтов.
Несколько имён для одного сайта.
Разместить все сайты на одном сервере.
Сделать доступ к каждому сайту по отдельному URL.
Ограничить доступ к некоторым сайтам.
Сделать перенаправление нескольких имён на один сайт.
Пойдём от простого к сложному. Для начала рассмотрим случай, когда у нас два сайта и два имени teo.mynetwork.ru и logos.mynetwork.ru. Эти имена должны быть доступны, т.е. держатель зоны mynetwork.ru должен прописать в ней узлы teo и logos.
Для каждого сайта создаём каталог в корневом каталоге документов Apache (teo и logos соответственно). Для Linux это по умолчанию /var/www/html, но чтобы убедиться, где он расположен на нашем сервере, смотрим значение директивы DocumentRoot в /etc/httpd/conf/httpd.conf. Итак, создаём:
# mkdir /var/www/html/teo /var/www/html/logos
Мы будем разделять журналы для каждого сайта, поэтому создадим соответствующие каталоги:
# mkdir /var/log/httpd/teo /var/log/httpd/logos
Если у нас уже был создан сайт, то всё его содержимое переносим в созданный для него каталог, т.е. из /var/www/html в /var/www/html/teo. Новый сайт logos.mynetwork.ru размещаем в /var/www/html/logos.
Теперь настраиваем Apache. Добавляем в конец файла /etc/httpd/conf/httpd.conf:
Все настройки, не заданные для сайта явным образом в директиве VirtualHost, наследуются от глобальных настроек Apache, указанных выше в этом же файле.
Теперь, обращаясь по DNS-именам, мы будем получать разные сайты. Если обратиться по IP-адресу, то получим сайт teo.mynetwork.ru, т.к. он подключен первым.
Создаём ссылки с нескольких DNS-адресов на один сайт
Это можно осуществить двумя способами: созданием синонимов или перенаправлением всех обращений с другого сайта.
Синонимы задаются директивой ServerAlias, могут содержать маску и разделяются пробелом. Вот несколько примеров создания синонимов:
Синоним – это DNS-имя. Имена могут быть абсолютно любыми, в том числе и из разных доменов, но все они должны разрешаться в IP-адреса, то есть их предварительно нужно зарегистрировать в DNS.
Перенаправление задаётся директивой Redirect. Создаём новый пустой сайт pantheon.ru. Как и для предыдущих сайтов, это делается в три шага: создание каталога для документов, для журналов и добавление конфигурации в httpd.conf:
Можно перенаправлять не со всего сайта, а только с определённого каталога или даже документа:
Redirect /samag http://samag.ru
Redirect /ftp/ ftp://citkit.ru/pub/
Redirect /find/ya.htm http://yandex.ru
При этом Apache воспринимает первый параметр директивы Redirect не как URL, а как набор символов, при совпадении с которым происходит перенаправление. Отсюда следует, что он не проверяет наличие указанных каталогов и файлов, а ссылки /samag и /samag/ не считает одинаковыми.
Ограничиваем доступ к сайтам
Теперь если пользователь обратится к нам по IP-адресу либо по имени, на которые наш сервер откликается (см. врезку), то Apache сначала определяет, не удовлетворяет ли запрос описанным директивами VirtualHost сайтам, и если не находит ни один из них, то выдаёт сайт по умолчанию, который находится в каталоге, заданном глобальной директивой DocumentRoot, т.е. уровнем выше остальных. Таким образом, получается, что пользователь может попасть на любой из виртуальных сайтов не тем путём, какой мы для него приготовили, т.е. http://logos.mynetwork.ru/. Например, набрав в адресной строке браузера «http://192.168.100.18/logos/», он получит сайт logos.mynetwork.ru. Правда, в этом случае документы, использующие ссылки на ресурсы этого же сайта, будут некорректно отображаться, потому что ссылки делаются относительно корня сайта, и если это была ссылка /img/picture.jpg, то во втором случае этот же файл уже нужно искать по ссылке /logos/img/picture.jpg, этого же браузер не знает. Таким образом, здесь все зависит от того, догадывается ли пользователь, в каких каталогах мы храним наши сайты. В принципе в этом нет ничего плохого, ведь мы в любом случае выложили сайты, чтобы их посещали (правила по ограничению доступа к ресурсу всё равно будут действовать, о них мы поговорим чуть позже), но как-то это выглядит некрасиво (для того и двери, чтобы в окна не лазить). Чтобы устранить эту некрасивость, можно поместить сайт по умолчанию на тот же уровень, что и остальные сайты, т.е. создать каталог /var/www/html/default и указать его в двух директивах глобальных настроек (т.е. до описания виртуальных сайтов).
# This should be changed to whatever you set DocumentRoot to
Теперь перейдём непосредственно к раздаче прав доступа. Существует два способа указать права доступа к каталогу веб-сайта средствами Apache: поместить в каталог файл .htaccess либо использовать директиву в файле конфигурации. В обоих случаях правила распространяются и на вложенные каталоги.
Перечислим преимущества использования файла .htaccess:
при его изменении не нужно перезапускать Apache;
при одинаковом уровне доступа к разным ресурсам можно пользоваться ссылками на один файл .htaccess;
можно предоставить пользователю право редактирования этого файла, что удобно, если у нас сервер с множеством клиентских сайтов.
Есть и недостатки:
для того чтобы ответить на вопрос: «какие ограничения доступа существуют на сайте?» – администратору необходимо помнить, в каких каталогах лежат эти файлы и ссылки;
если сайт будет переноситься на другой сервер, и, что очень вероятно, будет размещён в другом каталоге, то для корректировки ссылок уйдёт много времени;
повышается нагрузка сервера, т.к. при каждом запросе на ресурс он обращается к .htaccess в этом каталоге и всех верхних по иерархии, наследуя их настройки т.е. запрос на ресурс http://teo.mynetwork.ru/olimp/staff/zeus.htm инициирует проверку .htaccess-файлов в каталогах «./», «./olimp/», «./olimp/staff/».
Определяя настройки доступа к каталогам сайта с помощью директивы в одном конфигурационном файле всего сайта, мы получим следующие преимущества:
можно быть уверенным, что ничего не пропустим, если вдруг нужно изменить уровень доступа к какому-нибудь ресурсу;
повышаем скорость реакции сервера на запросы, т.к. все настройки загружаются при старте Apache.
Ну а мириться придётся с тем, что для каждого каталога необходимо описывать права отдельно (помним, что для подкаталогов права наследуются), даже если они одинаковые.
Правда, есть поддержка масок, например:
будет соответствовать именам каталогов в /www/ состоящим из трёх цифр, но это не всегда может облегчить ситуацию.
Мы рассмотрим оба способа и изменим права доступа к двум каталогам сайта logos.
Первый. Описываем права доступа к каталогам в главном конфигурационном файле httpd.conf:
Многоликий Apache. Размещаем несколько сайтов на одном веб-сервере
Многоликий Apache. Размещаем несколько сайтов на одном веб-сервере
ПАВЕЛ МАЛАХОВ
