Tag Archives: Apache

Ubuntu: установка и настройка связки nginx + apache + php + mysql

В это статье я расскажу как быстро развернуть LAMP сервер на Ubuntu с кеширующим nginx

Для всех команд необходим sudo, потому сразу войдем для удобства в этот режим:

Далее, обновляем данные из репозитариев:

Установка MySQL сервер:

Во время установки нас попросят ввести пароль root для сервера MySQL, вводим 2 раза. Дожидаемся окончания установки.

Установка Apache, nginx, php:

Дожидаемся окончания установки.
Включаем модули rewrite и include в apache2 при помощи утилиты — a2enmod:

Меняем порт в apache2 со стандартного 80 на 8080 (2 строчки):

Создаем новый веб сервер (VirtualHost), создаем файл конфигурации:

И вставляем в него следующий текст:

Далее, создаем папку сайта и запускаем сайт:

Проверяем в браузере — http://domain.com:8080

Конфигурируем nginx:

Приводим конфиг к такому виду:

Далее создаем и правим конфиг нашего сайта:

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

Перезапускаем сервисы и проверяем работу:

Источник: http://evolan.org/linux/ubuntu-ustanovka-i-nastrojka-svyazki-nginx-apache-php-mysql/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

3D визуализация и дизайн

Защита файла wp-config.php в nginx

Автор: Рудюк С . А.
https://corp2.net

E-Mail: rs@corp2.net

В файле wp-config.php CMS WordPress хранит пароли и логины для доступа к базе данных. Это очень безопасная информация. Есть вероятность, что в момент отладки приложения или веб-сервера данный файл может быть доступен злоумышленникам, поэтому, рекомендуется защищать данный файл от доступа в веб-серверах.

Защита в веб-сервере Apache указывается в файле .htaccess:

Защита в веб-сервере Nginx:

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Дизайн интерьеров

Дизайн интерьеров

Безопасность WordPress. 3 самых эффективных способа защиты от брутфорса

По статистике, около 19% от общего количества всех сайтов Интернета, работают на WordPress — это почти каждый пятый сайт. Успех платформы вполне логичен и закономерен, не зря еще 5 лет назад я сделал ставку именно на нее. Но сегодня речь пойдет не о преимуществах WordPress, а о его безопасности. Высокая популярность платформы активизировала злые силы, и вот уже на протяжении нескольких месяцев в Рунете идут массовые атаки на сайты, работающие на WordPress. Атаки настолько серьезные и настолько массовые, что не выдерживают даже самые мощные серверы. Хостинг-провайдеры, конечно, принимают меры, порой даже самые радикальные, вплоть до полной блокировки администраторских консолей WordPress. Поэтому, если вас еще не заблокировали, лучше самостоятельно провести ряд несложный действий по укреплению обороны вашего WordPress.

В этой статье я расскажу о самых эффективных способах защиты вашего сайта именно от брутфорса (brute force) — метода подбора и взлома пароля путем перебора всех теоретически возможных вариантов. Так как все последние массовые атаки работают по этому методу.

1. Первое с чего нужно начать — это избавиться от пользователя admin. Если у вас нет пользователя admin, можете сразу переходить к пункту 2. В WordPress начиная с 3 версии это делается очень просто. Достаточно создать нового пользователя, наделить его администраторскими правами, а старого пользователя «admin» — удалить. При его удалении, WordPress предложит вам выбрать нового пользователя, который станет автором публикаций старого администратора.

В старых версиях WordPress эта процедура проделывается с помощью пары SQL-запросов:

2. Очень важно обратить внимание на пароль администратора. Лучше если это будет хаотичная комбинация заглавных и строчных букв, знаков и цифр не менее чем из 10-12 символов.

3. При бутфорсе WordPress, производится огромное количество запросов к файлу авторизации «wp-login.php», и будет правильно обеспечить ему двойную защиту.

Если вы работаете с сайтом один, и ваш интернет-провайдер предоставляет вам статичный IP-адрес, вы можете разрешить доступ к директории «wp-admin» только с вашего IP-адреса, заблокировав тем самым для всех остальных даже возможность авторизации. Делается это следующим образом. В директории «wp-admin» создаем файл «.htaccess» следующего содержания:

Где IP — это ваш IP-адрес. Узнать его вы можете, например, здесь.

Если же, кроме вас с сайтом работают еще люди со статическими IP-адресами, вы можете просто добавить их в список ниже. Например, так:

Где, IP1, IP2, IP3 — разрешенные IP-адреса.

Благодаря этому, все пользователи (боты) с IP-адресами, не указанными в списке разрешенных, просто не получат доступа к директории «wp-admin» и, соответственно, не смогут брутфорсить файл «wp-login.php». Всем им будет возвращаться ошибка 403.

Если провайдер вам выдает динамический IP-адрес, меняющийся с каждым новым подключением к Интернету, тогда этот способ не пройдет, т.к «.htaccess» придется редактировать при каждом вашем подключении к Сети. С помощью все того же «.htaccess» мы можем установить дополнительную серверную HTTP-авторизацию. Делается это следующим образом.

Все в той же директории «wp-admin» создаются два файла: «.htaccess» и «.htpasswd». В первом будут храниться инструкции, во втором разрешенные данные для доступа к директории.

В «.htaccess» пишем следующее:

Где fullpath — полный путь к файлу «.htpasswd». Обратите на это должное внимание, т.к это самая частая ошибка. Полный путь вы можете узнать у своего хостинг-провайдера или с помощью небольшого php-скрипта:

Или другим способом:

Если вы по каким-то причинам не хотите паролить всю директорию «wp-admin», вы можете запаролить непосредственно файл «wp-login.php». Делается это аналогично, но в «.htaccess» нужно написать следующее:

Файл «.htpasswd» в обоих случаях должен выглядеть следующим образом:

Где username — это имя разрешенного пользователя, а password — это пароль. Обратите внимание, что пароль хранится в зашифрованном виде. Поэтому, предварительно ваш пароль нужно зашифровать. Сделать это можно, например, с помощью этого сервиса. На пароль действуют те же правила, что указаны в пункте 2 данной публикации.

Для использования нескольких пользователей с паролями, вы можете просто перечислить их по-порядку. Например, вот так:

Если вы сделаете все правильно, перед авторизацией в WordPress вам будет предложено ввести логин и пароль доступа к директории (файлу). И только после успешного входа вы сможете авторизоваться и войти в администраторскую консоль.

В Safari 6.0.5 на Mac OS это выглядит примерно так:

htpasswd

В других браузерах возможно немного иначе.

Выполнив хотя бы эти 3 пункта, вы в разы снизите вероятность взлома вашего WordPress.

Дополнительные меры по защите WordPress

Дополнительно вы можете защитить таким же образом файл настроек WordPress «wp-config.php». Я бы рекомендовал его защитить, потому что в нем содержатся данные для подключения к БД MySQL. Делается это аналогично:

Также, я бы рекомендовал вам проверить директории вашего сайта. Дело в том, что очень многие хостеры и безалаберные сисадмины не закрывают по-дефолту просмотр директорий сайтов своих клиентов. Если, к примеру, ввести в адресную строку браузера: http://вашсайт/wp-includes/ и вы увидете содержимое этой директории — нужно бить тревогу и срочно закрывать просмотр. Для этого можно создать в директориях, которые вы хотите закрыть от просмотра, пустые файлы «index.html» или дописать в ваш «.htaccess» всего одну строку:

Которая запретит серверу показывать содержимое директорий.

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

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

Если в процессе настройки защиты WordPress от брутфорса у вас возникнут сложности — вы всегда можете обратиться ко мне за помощью. Контакты здесь.

3D визуализация и интерьер

3D визуализация и интерьер

Настройка кеширования страниц в PHP: XCACHE

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

Настраиваем кеш: Файл настройки /etc/php5/apache2/conf.d/xcache.ini.

Также можно указать число ядер вашего процессора:

понятно, что это для 2-х процессоров.


Источник: http://help.ubuntu.ru/wiki/web-server

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

3D визуализация и интерьер

Разгоняем WordPress до скорости света

7337481781ba67dec1Скорость и отказоустойчивость – одни из тех факторов, что неизменно влияют на популярность вашего ресурса, ведь даже с лучшим в мире контентом медленно работающий сайт будет раздражать читателей и рано или поздно вы их потеряете. В этой статье мы будем оптимизировать самый популярный блоговый движок — WordPress, работающий на PHP. А заодно рассмотрим несколько общих моментов в оптимизации сайтов.

1 Тестируем текущую скорость

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

1.1 Pingdom

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

habr1Бенчмарк одного довольно известного ресурса.

1.2 YSlow

YSlow– плагин для Firefox, который встраивается в, пожалуй лучший плагин для веб разработчика, Firebug. Он анализирует более 20 факторов, которые влияют на скорость работы сайта и оценивает общую производительность по 100 бальной системе, а каждый отдельный элемент оценкой от A до F.

habr2

1.3 Количество запросов и время их выполнения

Вставив небольшой кусок PHP кода, можно вывести в футер количество запросов к БД и время, затраченное на их выполнение.

<?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.

 

2 Web Hosting

Хотите верьте, хотите — нет, но веб хостинг одна из важнейших деталей, влияющих на производительность блога. Не вдаваясь в подробности, вот очень простая характеристика наиболее популярных типов хостинга, которая поможет вам примерно оценить нагрузку на сервер:

  • Shared Hosting – на одном сервере может хоститься в среднем около 100 человек;
  • VPS – на одном сервере может хоститься около 20 человек;
  • Dedicated – сервер будет использоваться только вами.

Чтоб просмотреть примерную нагрузку на сервер, залогиньтесь через ssh и введите в консоли команду top.

Это, конечно, не означает, что вы не сможете ускорить блог, работающий на виртуальном хостинге(Shared Hosting), однако стоит помнить – производительность тем выше, чем большие ресурсы мы имеем в своем распоряжении.

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

3 Установка и настройка сервера

Удостоверьтесь, планируемая нагрузка соответствует мощности сервера и он сможет с ней справиться. В первую очередь это будет зависеть от объема оперативной памяти и процессора. Как правило, WordPress ставят на Apache, но много удачных решений существует и на базе других http серверов: nginx, lighttpd и т.д.

Не забудьте обновить до последней версии PHP и Apache.

3.1 Отключите неиспользуемые сервисы

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

  • Удалите ClamD;
  • Настроить SpamD на использование только 1 дочернего процесса;
  • Удалите Mailman, если, конечно, вы не собираетесь запускать почтовый сервис.

 

3.2 MYSQL Query Cache

Поскольку стабильность и скорость WordPress довольно сильно зависит от работы БД, стоит убедиться, что настройки в my.cnf соответствуют возможностям сервера. В первую очередь следует установить настройки кэширования запросов, добавив в my.cnf следующие строки:

query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 20M

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

3.3 Кэш компилятора: XCache или Eaccelerator?

Кэш компилятора увеличивает производительность откомпилированных скриптов на сервере, кэшируя их – это поможет сократить время выполнения PHP скриптов. Стоит попробовать и то и другое решение, однако по результатам опытов увеличение производительности при использовании Xcache на 5% выше, чем с Eaccelerator.

3.4 Увеличьте максимальное число соединений на Apache

Увеличение максимального количества соединений в httpd.conf повысит производительность, т.к. сервер сможет обрабатывать большее количество подключений за раз. Однако, следует изменять этот параметр осторожно, дабы не исчерпать весь объем оперативной памяти и не замедлить работу сервера, потому всегда тестируйте новые настройки прежде чем запускать их в работу. Установим к примеру 150 коннектов:

max_connections = 150

Не забудьте рестартить сервис Apache, чтоб применить настройки.

4 Оптимизация кода и графики

Итак, сервер заработал и теперь настало самое время поиграть с кодом WordPress.

4.1 Отключите хотлинки

Каждый раз когда вы используете свой сервер для хранения изображений вы существенно больше используете его ресурсов. Довольно часто люди заимствуют ваши изображения, ставя хотлинки на своих серверах. Это не только занимает канал, но и создает определенную нагрузку на сервер.
Добавьте следующий код в .htaccess файл, заменив example.com на имя вашего домена, чтобы отключить использование хотлинков:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example\.com/.*$ [NC]
RewriteRule .*\.(gif|jpg|png|ico)$ - [F,L]
</ifModule>

 

4.2 Используйте внешний хостинг для хранения изображений

Хостинг изображений на внешних серверах поможет значительно снизить нагрузку на сервер. В примере ниже вы можете видеть снижение объема используемой оперативной памяти на одном из блогов после переноса изображений на сервис Amazon S3.

amazons3images

4.3 Сжимайте java-скрипт код

Сжатие javascript довольно простая задача. Поскольку он выполняется при каждом просмотре страницы, вы можете уменьшить размер Javascript, удалив все незаполненное пространство. Вот простой инструмент, который поможет сделать это за вас — JavaScript Compressor.

4.4 Javascript в начале страницы

Часто случается так, что сайт начинает загружаться медленно или вообще останавливается, т.к. другой ресурс, с которого вызывается javascript(на пример Digg badges, Tweetmeme и т.д.), не доступен или оффлайн. Чтобы избежать этого вынесите весь javascript код в конец страницы, а то что по каким-то причинам вынести не удалось – попробуйте заключить в iFrame.

4.5 Используйте кэш браузера

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

FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch "\.(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

 

4.6 Сжимайте статические данные

Вы можете уменьшить размер загружаемой страницы позволив браузеру принимать и передавать данные в сжатом виде. Это также снизит загрузку канала и количество загружаемых данных.
Следующий код в .htaccess может помочь вам в этом:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

 

4.7 Используйте CDN для статических файлов

Если хранить все изображения на одном и том же домене, то браузер будет ожидать их загрузки одного за другим. Допустим на странице их у вас есть 12 штук, если вы разделите их между тремя поддоменами, они будут загружаться одновременно из трех «разных» источников вместо того, чтоб загружаться браузером по очереди из одного.
Можете попробовать перенести все css & javascript файлы на files.yoursite.com, а изображения и временные файлы на static.yoursite.com. Или же просто использовать CDN(Content Delivery Network) – большая сеть серверов, расположенных по всему миру, которые позволят не только хранить ваши файлы на разных поддоменах, а значит загружать их параллельно, но и доставлять пользователю данные с самого близкого к нему сервера. Все это позволит загружать данные намного быстрее.

5 WordPress

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

5.1 Обновитесь до последней версии

Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность. Для примера в wordpress 2.8 была существенно оптимизирована работа с БД.

5.2 Отключите Post Revisions

Во всех версиях wordpress, начиная с 2.6, редакции ваших статей каждый раз во время правки автоматически сохранялись. Это замедляет работу БД и увеличивает ее размер без особой надобности.
Чтоб отключить post revisions, добавьте следующую строку в wp-config.php:

define('WP_POST_REVISIONS', false);

Чтобы удалить сохраненные ранее ревизии текста, выполните следующий запрос в PHPmyadmin:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

 

5.3 Сократите количество запросов

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

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Мы запросто можем переписать в:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Уже на два запроса меньше. Довольно просто, не правда ли?

6 WordPress Plugins

И на последок предлагаю вашему вниманию несколько плагинов, которые могут повысить производительность wordpress. Как только все, описанное выше, будет выполнено, эти плагины помогут добиться еще более высокой производительности.

WP Super Cache
Это, пожалуй, лучший плагин к WordPress. WP Super Cache создает статические html версии каждой страницы и загружает их каждый раз, обходясь тем самым без запросов к БД. Это значительно увеличивает скорость загрузки страниц и снижает нагрузку на сервер. Строго рекомендуется к установке.

PHP Speedy WP
Этот плагин решает другую проблему, обозначенную в этой статье – удаление незаполненного пространства в CSS & javascript. Однако есть некоторые проблемы совместимости этого плагина с WP Super Cache, кроме того он долгое время уже не обновлялся, потому используйте на свой страх и риск.

Optimize DB
Плагин позволяет оптимизировать таблицы MySQL без помощи PHPmyadmin.


Источник: http://habrahabr.ru/post/69046/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Попытка создать почти идеальный htaccess №2

Конфиг .htaccess:

 

Используемые модули
  • mod_headers
  • mod_setenvif
  • mod_deflate
  • mod_filter
  • mod_expires
  • mod_rewrite
  • mod_autoindex

Анализ демонстрационной версии блога на фреймворке Yii инструментом Google PageSpeed Tool
(кликабельно)

До использования .htaccess:

0zp9oПосле использования .htaccess:

w3PlKА так же график загрузки и демонстрация работы сжатия
До:

UIXoVПосле:

zlzEw

 

Количество передаваемых данных уменьшилось на 84,27 килобайт (меньше в 2.6 раз).
Так же мы получаем более тонкое управление кэшированием и некоторые фиксы.


Источник: http://habrahabr.ru/sandbox/55709/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Дизайн интерьеров

Дизайн интерьеров

Включение модулей для работы кеширования в WordPress Super Cache

Автор: Рудюк С . А.
https://corp2.net

E-Mail: rs@corp2.net

Для корректной работы кеширования в компоненте WordPress WP Super Cache необходимо включить такие модули Apache:

Включаются они простым указанием симлинка с папки /etc/apache2/mods-available в папку /etc/apache2/mods-enabled.

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

3D визуализация и интерьер

.htaccess и php_value mbstring.func_overload

Автор: Рудюк С . А.
https://corp2.net

E-Mail: rs@corp2.net

В 1С-Битрикс требуют установку параметров php.ini:

Но, с некоторых пор данные параметры не изменяются в файле .htaccess. Изменение же в php.ini может отрицательно сказаться на работе других сайтов.

Решением может настройка конфига виртуального хоста:

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Предметная визуализация

2-й экземпляр apache

Автор: Рудюк С . А.
https://corp2.net

E-Mail: rs@corp2.net

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

Определимся, чем должны, отличаться наши экземпляры.
Это конфигурационными файлами:
/etc/apache2/apache2.conf  — указаны порты и специфичные для каждого из Апачей виртуальные хосты
/etc/apache2/ports.conf — содержит прослушиваемые порты.
/etc/apache2/envvars — путь к файлу для сохранения pid запущенного демона.

Стоит разделить логи директивами в в apache2.conf:
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/other_vhosts_access.log vhost_combined

Идем в папку init скриптов:
cd /etc/init.d

Создаем копию init скрипта родного Apache:
cp apache2 apache2_srv

Где apache2_srv — это название нового экземпляра Apache.

Сразу Добавляем фейловер Апача в автозапуск:
update-rc.d apache2_srv defaults

Корректируем скрипт apache2_srv:

Вместо блока:
PIDFILE=. /etc/apache2/envvars ; echo $APACHE_PID_FILE
if [ -z «$PIDFILE» ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars >&2
exit 2
fi

Вставляем:
PIDFILE=. /etc/apache2/envvars_apache2_srv ; echo $APACHE_PID_FILE
if [ -z «$PIDFILE» ] ; then
echo ERROR: APACHE_PID_FILE needs to be defined in /etc/apache2/envvars_apache2_srv >&2
exit 2
fi

Чуть выше корректируем ENV:
ENV=»env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin APACHE_ENVVARS=/etc/apache2/envvars_apache2_srv»

Корректируем конфиги:
cp /etc/apache2/envvars /etc/apache2/envvars_apache2_srv

Заменяем
export APACHE_PID_FILE=/var/run/apache2.pid
на
export APACHE_PID_FILE=/var/run/apache2_apache_2.pid

Создаем файл портов /etc/apache2/ports_apache_srv.conf:
В нем пишем:
Listen 81

Создаем файлы логов:
touch /var/log/apache2/error_apache2_srv.log
touch /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:root /var/log/apache2/other_vhosts_access_apache2_srv.log
chown root:adm /var/log/apache2/error_apache2_srv.log
chmod 640 /var/log/apache2/error_apache2_srv.log

Теперь давайте посмотрим, как осуществляется управление демоном Апача. Сразу скажу, что кэш мы не используем и следовательно «check_htcacheclean» всегда будет выдавать ложь.
Запуск:

start)
log_daemon_msg «Starting web server» «apache2»
if $APACHE2CTL start; then
if check_htcacheclean ; then
log_progress_msg htcacheclean
start_htcacheclean || log_end_msg 1
fi
log_end_msg 0
else
log_end_msg 1
fi
;;

То есть все вопросы к: $APACHE2CTL, его мы будем использовать не как SysV инит скрипт, а будем им проксировать все наши вопросы к apache

Для этого в верху скрипта делаем замену:

APACHE2CTL=»$ENV /usr/sbin/apache2ctl»

на

APACHE2CTL=»$ENV /usr/sbin/apache2ctl -f /etc/apache2/apache2_srv.conf»

Далее изменяем все параметры вызов APACHE2CTL:

$APACHE2CTL start на $APACHE2CTL -k start
$APACHE2CTL stop на $APACHE2CTL -k stop
$APACHE2CTL graceful на $APACHE2CTL -k graceful
$APACHE2CTL configtest на $APACHE2CTL -t

Теперь надо скорректировать функцию pidof_apache, иначе при stop мы будем убивать всех Апаче разом:

Делаем замену:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=pidof apache2 || true

на:

pidof_apache() {
# if pidof is null for some reasons the script exits automagically
# classified as good/unknown feature
PIDS=ps aux | grep 'apache2_srv' | grep -v 'grep' | awk '{print $2}' | xargs || true

Теперь попробуем запустить второго Апача:

/etc/init.d/apache2_srv  start
Starting web server: apache2apache2: Could not open configuration file /etc/apache2/apache2_failover.conf: No such file or directory
failed!

Теперь необходимо на основе apache2.conf составить /etc/apache2/apache2_srv.conf

Скопируем оригинал

cp /etc/apache2/apache2.conf /etc/apache2/apache2_srv.conf

И далее корректируем пути к файлами, которые обсуждали выше.

CustomLog /var/log/apache2/other_vhosts_access_apache2_srv.log vhost_combined
ErrorLog /var/log/apache2/error_apache2_srv.log
Include /etc/apache2/ports_apache2_srv.conf

Теперь надо поменять порты у директив NameVirtualHost xx.xx.xx.xx:80 и VirtualHost xx.xx.xx.xx:81.

Повторяем попытку запуска:

/etc/init.d/apache2_srv  start
Starting web server: apache2.

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)