Web-сервер на centos 7.1

Установка MySQL

Сейчас все большее распространение получает форк MySQL — MariaDB. Она имеет полную совместимость с MySQL. В последнее время, я предпочитаю использовать именно ее.

Устанавливаем mariadb в Debian 11 или Ubuntu 20.04

Запускаем скрипт начальной конфигурации mysql и задаем пароль для root. Все остальное можно оставить по-умолчанию.

Откроется серия диалогов, где нужно внести некоторые изменения в параметры безопасности установки MariaDB. Меняем пароль пользователя root для текущей базы данных, потом удаляем анонимных пользователей, отключаем возможность подключаться root удаленно, удаляем тестового пользователя и базу. все предложения мастера.

Файлы настроек mysql/mariadb в Debian лежат в директории /etc/mysql/. Для обычной работы достаточно настроек по-умолчанию. Но если вы решите изменить их, не забудьте перезапустить службу баз данных.

Установка phpmyadmin

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

Идем на сайт https://www.phpmyadmin.net и копируем ссылку на последнюю версию панели. Затем загружаем ее через консоль

Распаковываем исходники в директорию виртуального хоста.

Настройка phpmyadmin

Phpmyadmin готов к работе сразу после установки, дополнительные настройки не обазательны. Закрываем доступ к панели средствами Web сервера. Для использования панели необходимо будет не только знать имя учетной записи mysql, но и пользователя и пароль для доступа непосредственно к панели.

Будем использовать стандартное средство для ограничения доступа к каталогу с помощью .htaccees. Создадим такой файл в папке со скриптами phpmyadmin:

Теперь создадим файл с авторизационными данными:

Где user — имя пользователя, а password пароль.

Чтобы авторизация заработала, необходимо в файле конфигурации виртуального хостинга в разделе Directory добавить параметр AllowOverride перед </VirtualHost>

Перезапускаем Apache.

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

Как установить phpMyAdmin в Windows

Сайт для скачивания phpMyAdmin: phpmyadmin.net.

Прямая ссылка на самую последнюю версию: phpMyAdmin-latest-all-languages.zip.

В каталог c:\Server\data\htdocs\ копируем содержимое только что скаченного архива. Переименовываем эту папку в phpmyadmin.

В каталоге c:\Server\data\htdocs\phpmyadmin\ создаём файл config.inc.php и копируем туда:

<?php
 
/* Servers configuration */
$i = 0;
 
/* Server: localhost  */
$i++;
$cfg = '';
$cfg = 'localhost';
$cfg = '';
$cfg = '';
$cfg = 'tcp';
$cfg = 'cookie';
$cfg = 'root';
$cfg = '';
$cfg = true;
$cfg = true;
 
/* End of servers configuration */
 
$cfg = 'kjLGJ8g;Hj3mlHy+Gd~FE3mN{gIATs^1lX+T=KVYv{ubK*U0V';
$cfg = 'ru';
$cfg = 1;
$cfg = '';
$cfg = '';
 
?>

В браузере набираем http://localhost/phpmyadmin/

В качестве имя пользователя вводим root. Поле пароля оставляем пустым.

Установка tasksel

По умолчанию tasksel обычно установлен, но если это не так, то вы можете установить tasksel командой

apt-get install tasksel

По зависимостям установится также пакет tasksel-data, включающий официальные задачи для установки. Дополнительно можно установить следующие пакеты:

education-tasks — Задачи для Debian Edu, включающие серверную часть и часть для тонких клиентов или рабочих станций

games-tasks — Задачи Debian Games, включающие большое количество игр, разделенных по жанрам, а также задачи для установки эмуляторов, лучших игр и разработки игр

gis-tasks — Задачи Debian GIS, включающие программы для работы с OpenStreetMap, GPS и другие программы, связанные с географической информацией

junior-tasks — Задачи Debian Jr. и Doudou Linux, включающие игры и обучающие программы, программы для видео, обучения печати и другие

и так далее. Полный список пакетов с заданиями можно посмотреть при помощи команды

apt-cache search tasksel

Использование tasksel

Программа tasksel может работать как в режиме командной строки, так и в интерактивном режиме. Если никакие параметры командной строки не указаны, программа будет работать в интерактивном режиме, будет показано меню с конфигурациями, вам только надо будет проставить флажки и затем нажать кнопку «OK».

В командном режиме программа будет работать только тогда, когда указаны параметры командной строки. Их немного:

—list-tasks	Вывести список всех существующих задач
install задача	Установить пакеты, определенные в задаче
remove задача	Удалить пакеты, определенные в задаче
-t, —test	Тестовый режим. Не удалять и не устанавливать пакеты на самом деле
—task-packages задача	Вывести список пакетов, которые относятся к задаче и доступны в данный момент
—task-desc задача	Вывести описание задачи
—new-install	Автоматически выбрать задачи без отображения их пользователю. Используется при новой инсталляции Debian
—debconf-apt-progress опции	Передать указанные опции команде debconf-apt-progress, которую запускает tasksel

Создание desc-файла для задачи tasksel

Tasksel позволяет достаточно быстро создавать собственные задачи. Для этого создается файл c расширением .desc, который размещается в директории /usr/share/tasksel/descs. Каждый файл .desc может включать одну и более задач, а каждая задача должна иметь определенную структуру, состоящую из полей с названием и значением. Вот эти поля:

Task	Название задачи. Например. «Task: web-server» без кавычек
Section	Секция, в которую входит задача. Например, «Section: httpd» или «Section: debian-games»
Description	Описание задачи. Описание может занимать несколько строчек. Первая строчка — краткое описание задачи, а последующие, начинающиеся с пробела, — более подробное описание.
Relevance	Релевантность. Обычно значение в этом поле выставляют равным 10. Пример: «Relevance: 10»
Enhances	Задача, которую расширяет данная задача. Например, «Enhances: desktop»
Key	Ключевое слово задачи. Часто совпадает с названием задачи
Packages	Список пакетов, входящих в задачу. Если пакетов несколько, то после заголовка пишется слово «list», а сами пакеты перечисляются на следующих строках, каждый пакет с новой строки, перед названием пакета пробел

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

Доступ к файловой системе

Для доступа к виртуальному серверу с основной машины удобно установить SMB-сервер. Это позволит подключить каталоги с сайтами в качестве сетевого диска – что может быть проще для редактирования всех файлов вашими любимыми текстовыми и графическими редакторами. В системе уже есть (или его следует поставить в виде rpm) smb сервис. Для его конфигурации используется файл /etc/samba/smb.conf. Укажите в нем следующие строки (или отредактируйте существующие) в секции :

  security = SHARE
  encrypt passwords = No

Далее, создайте секцию (имя секции соответствует имени сетевого ресурса) со следующим содержимым:

  path = /
  force user = root
  force group = root
  read only = No
  guest ok = Yes

Это означает, что мы хотим сделать доступным всю файловую систему сервера (path), доступ будет осуществляться от имени суперпользователя (force user, force group), запись разрешена, авторизация не требуется (guest ok). Поскольку сервер виден только с локального компьютера, такие настройки вполне оправданы. Впрочем, можно ограничить доступ только к каталогу, где будут размещаться сайты (например, /sites), указав соответствующее значение в параметре path.

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

Настройку начнем с того, что завершим конфигурацию Nginx для работы с PHP-FPM. Для этого изменим конфигурационный файл сайта /etc/nginx/sites-available/$WEBSITE_NAME.

Добавим перед секцией server следующий фрагмент конфигурации, который задает способ связи с PHP-FPM:

upstream php {
        server unix:/run/php/php7.2-fpm.sock;
}

# то, что ниже не добавлять в настройку, 
# приведено для примера куда вставить секцию
# upstream
#
server {
        listen 443 ssl;
        listen :443 ssl;

...

Удалим следующие строки конфигурации:

       index index.html;

       location / {
                try_files $uri $uri/ =404;
       }

Добавим следующие строки конфигурации вместо них:

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        index index.php;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass php;
        }

        location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }

Пример полной конфигурации:

server {
    if ($host = website.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


        listen 80;
        listen :80;
        server_name website.com;


}

upstream php {
        server unix:/run/php/php7.2-fpm.sock;
}

server {
	listen 443 ssl;
	listen :443 ssl;

	server_name website.com;

	root /var/www/example.com;

        ssl_certificate /etc/letsencrypt/live/website.com/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/website.com/privkey.pem; # managed by Certbot

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        index index.php;

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ .php$ {
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass php;
        }

        location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

Проверим корректность настроек Nginx и перезапустим его:

sudo nginx -t && sudo service nginx restart

Убедимся, что PHP-скрипты работают корректно. Для этого создадим файл index.php в пути /var/www/$WEBSITE_NAME/index.php со следующим содержимым:

<?php 
echo "Hello\n";

Проверим работоспособность скрипта:

# локально
php /var/www/$WEBSITE_NAME/index.php
Hello

# через web
curl https://$WEBSITE_NAME/index.php
Hello

# удалим скрипт
sudo rm /var/www/$WEBSITE_NAME/index.{php,html}

Настройка сервера LEMP завершена. Теперь вы можете выполнить развертывание сайта в каталоге /var/www/$WEBSITE_NAME и начать его использование, открыв в браузере https://$WEBSITE_NAME/.

Запуск службы

Чтобы запустить сервер, вам нужно открыть терминал в вашей операционной системе и указать в нём папку, содержащую ваш docker-compose.ymlфайл. В Windows 10 самый простой способ — использовать проводник (ранее известный как проводник Windows, и его не следует путать с Internet Explorer). Перейдите в папку, в которой находится ваш docker-compose.yml, затем щёлкните Файл, а затем откройте Windows Powershell. В Linux у большинства файловых менеджеров есть кнопка «Открыть терминал здесь» или аналогичная. В macOS вам сначала нужно включить эту опцию.

Как только ваш терминал будет открыт в правильном месте, введите docker-compose up. Вы должны увидеть результат, подобный изображению ниже.

Если вы получаете сообщения об ошибках, убедитесь, что Docker установлен и работает правильно. Если вы видите вывод, подобный приведённому выше, вы можете подключиться к серверу, посетив http://127.0.0.1 в своём браузере. Если он работает, вы увидите тестовую страницу NGINX, как показано на рисунке ниже.

Почему не Апач?

Прежде чем мы продолжим, вам может быть интересно, почему я здесь не использую Apache. Если вы использовали XAMPP или аналогичный пакет, то используемый вами веб-сервер — Apache. Веб-сервер — это часть сервера, которая слушает запросы веб-браузера и отправляет ему файлы.

Apache в порядке, и он работает, но он существует всегда. Когда был создан Apache, Интернет был совсем другим местом. Apache большой, и есть много разных функций, которые пришли и ушли, но которые Apache всё ещё поддерживает. Интернет сильно изменился с тех пор, как был создан Apache, и, хотя это мощный сервер и будет работать нормально, большинство веб-сайтов в наши дни, как правило, используют NGINX. Его легче настроить, он легче и лучше настроен для задач, которые используются на многих современных веб-сайтах (например, потокового видео), и поэтому его доля на рынке быстро растёт за счёт Apache.

Мой общий совет: если у вас уже есть веб-сайт, на котором запущен Apache, нет причин беспокоиться о его изменении, но если вы начинаете новый проект с нуля, используйте NGINX.

Размещение файлов на сервере

Теперь, когда сервер установлен и работает через Docker, мы можем сделать наши файлы видимыми на сервере. Если вы привыкли к Apache, вы бы поместили их в папку httpdocs, htdocsили publicгде-нибудь на вашем компьютере.

Поскольку сервер работает в контейнере, он не имеет доступа ни к одному из файлов на вашем компьютере. Однако Docker позволяет указать том — файл или папку на вашем компьютере, которые используются совместно с контейнером. Вам понадобятся два тома: nginx.confфайл конфигурации (который мы ещё не создали) и папка, в которой будут храниться файлы вашего сайта. Измените свой, docker-compose.ymlвключив два volumes:

Это делает файл nginx.confи appкаталог из той же папки, что и ваши, docker-compose.ymlдоступными в контейнере. Любые изменения, которые вы вносите в файлы в томах, немедленно изменяются в контейнере, и файлы становятся общими для них.

nginx.confФайл с хоста помещается в /etc/nginx/conf.d/nginx.confвнутри контейнера. Это папка, из которой NGINX читает файлы конфигурации. appПапка создаётся в корне контейнера /appи где вы будете размещать всё ваш сайт PHP скрипты, изображения и файлы JavaScript.

Перед перезапуском сервера создайте файл nginx.confв том же каталоге, что и ваш, docker-compose.ymlсо следующим содержимым:

Это сообщает NGINX, что это конфигурация, которую он должен использовать для сервера по умолчанию, и что он должен обслуживать файлы из каталога /app/public. Мы могли бы просто обслуживать файлы из /appкаталога, но рекомендуется держать большинство файлов PHP вне общедоступного каталога. Поскольку скрипты PHP должны будут загружать файлы../, мы поместим наш общедоступный каталог на один уровень ниже.

Чтобы проверить его работу, создайте страницу «Hello, World» на app/public/index.html, создавая каталоги по мере продвижения. Содержимое может быть таким:

Перезагрузите сервер, вернувшись в терминал и нажав, ctrl-cчтобы остановить сервер, затем docker-compose upснова запустите команду, чтобы перезапустить его. (Вы можете нажать стрелку вверх, а затем Enterвместо того, чтобы вводить её повторно.)

Перезагрузите http://127.0.0.1 в своём браузере, и вы увидите сообщение Hello, World! тестовая страница. Теперь у вас есть рабочий веб-сервер, файлы которого обслуживаются по адресу http://127.0.0.1 из вашего app/publicкаталога.

Собираем PHP

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

$ tar xzf php-4.4.1.tar.gz
$ cd php-4.4.1
$ ./configure --with-mysql=/usr --with-gd=/usr/local --with-apxs=/usr/local/apache/bin/apxs --with-zlib=/usr/local
$ make
# make install

Если поддержка MySQL, ZLib и GD не включилась, при необходимости запустить конфигуратор заново, предварительно удалив файлы config.cache и config.status.

Инсталлятор дописывает в httpd.conf директиву LoadModule и AddModule, но ничего не указывает про обработку нового типа файлов. Делаем это вручную:

# vi /usr/local/apache/conf/httpd.conf

Добавляем строку

AddType application/x-httpd-php .php .phtml

в секцию <IfModule mod_mime.c>, а также имя файла index.php в секцию <IfModule mod_dir.c>, строка с директивой DirectoryIndex. Также копируем конфигурационный файл PHP из дистрибутива на положенное место:

# cp php.ini-recommended /usr/local/lib/php.ini

Тестирование сервера

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

# /usr/local/apache/bin/apachectl start

Создаем файл /usr/local/apache/htdocs/test.php следующего содержимого:

<?php
  phpinfo();
?>

Теперь заходим браузером на сервер:

http://server_name/test.php

На загрузившейся странице должна быть выведена конфигурация сервера и PHP. Проверьте, что в разделе gd указана правильная версия модуля «2.0 or higher», а все форматы изображений (GIF read, GIF create, PNG, JPG) поддерживаются. Также проверьте, что указана внешняя поддержка MySQL: «MYSQL_MODULE_TYPE external».

Особенности создания локального сервера

Итак, у вас есть работающий web-сервер (виртуальный или «настоящий железный»), стоящий у провайдера и имеющий постоянное (будем надеяться, высокоскоростное) соединение с Internet. На нем можно размещать не только сайты но и различные программы, требующие постоянного доступа в Сеть (например, почтовые сервисы, игровые сервера и т.п.). Однако при разработке новых сайтов и программ использование такого сервера может оказаться не самым оптимальным решением по ряду причин. Вот некоторые из них: отладка и редактирование сайта на сервере требует постоянного соединения с Сетью и расходует трафик; при отладке программ существует риск повреждения работающих сайтов и служб, что явно нежелательно; существует вероятность того, что неотлаженными программами, установленными на сервере в Сети, могут воспользоваться злоумышленники для «взлома» сервера. Выход один – для отладки сайтов и программ лучше использовать отладочный сервер, стоящий рядом с вами, в идеале – на вашем рабочем компьютере. Далее я рассказываю об одном из способов создания такого сервера.

Настройка PHP

Скачайте PHP и выберите предпочтительную версию в формате Zip. Различные настраиваемые опции связаны с тем, как PHP-код базы компилируется в двоичный код, и вам ничего не нужно изменять.

Создайте в папке, где у вас устанавливаются программные файлы, директорию под названием PHP.

Найдите загруженный Zip-файл, переместите его во вновь созданную папку и распакуйте архив.

Теперь добавим путь к PHP к глобальной переменной PATH. Для этого следуйте инструкциям, приведенным выше.

Конфигурирование PHP

Конфигурирование PHP сводится к редактированию файла php.ini. Пример файла для различных сценариев уже находятся в вашей папке PHP. Переименуйте файл php.ini-development в php.ini и откройте его в текстовом редакторе

Доступные значения для различных параметров задокументированы в файле php.ini (обратите внимание, что это общие настройки для сервера, применяемые для всех проектов):

max_execution_time — если у вас есть скрипты, которые выполняются слишком долго, и сервер возвращает различные неожиданные результаты, потому что не может выполнить весь процесс;

memory_limit;

error_reporting;

display_errors;

log_errors — переменная, на которую нужно обращать внимание при сценариях разработки;

upload_tmp_dir;

upload_max_filesize;

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

extension_dir = "C:Program FilesPHPext"

• php_curl.dll;
• php_gd2.dll;
• php_mbstring.dll;
• php_mysql.dll;
• php_mysqli.dll;
• php_pdo.dll;
• php_pdo_mysql.dll;
• php_xsl.dll;
• session.save_path.

Установка ОС и web-сервера

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

И в заключение один совет. Поскольку вы с большой вероятностью будете использовать name-based virtual servers (виртуальные сервера, различаемые по имени), самый простой путь обеспечить доступ к ним с локальной машины – вписать все используемые имена сайтов в файл c:\winnt\system23\drivers\etc\hosts (для NT/2k/XP, для Win98 поищите файл hosts в каталоге ОС) с указанием IP-адреса вашего сервера. Тогда не возникнет никаких проблем с DNS при работе. Можно даже сделать два файла hosts (один с именами сайтов, другой без) и менять их для локальной работы и для проверки работы DNS.

Дополнительная настройка web сервера

После установки и настройки необходимо сделать тонкую настройку.

Настройка времени ожидания Nginx

Когда Nginx работает перед Apache, он передает запрос в Apache и ждет по умолчанию 60 секунд, если за это время не пришел ответ от Apache, то Nginx выдаст ошибку 502. Чтобы этого не происходило рекомендую поднять таймоуты до 120 секунд. В секцию location после proxy_pass вставить:

Перегружаем Nginx для применения настроек

К примеру, для виртуального хостинга популярного CMS движка WordPress, я ставлю 180 секунд, потому что во время обновления плагинов или самого движка WordPress Apache может очень долго не отвечать

Передача реального IP клиента в Apache

Когда Nginx работает перед Apache, то в логах Apache, в скриптах будет присутсвовать IP локального 127.0.0.1, что не несет никаких сведений о том, какой пользователь был на сайте. Перестают работать все сервисы, привязанные к IP пользователю на сайтах.

Чтобы убедиться в этом создадим файл ip.php

После этого переходим по адресу http://test.hserv.su/ip.php и видим:

Конфигурирование Nginx

Чтобы это исправить идем в секцию location конфигурации Nginx после proxy_pass добавим:

Перегружаем Nginx для применения настроек

Конфигурирование Apache

Для того, чтобы Apache начал правильно воспринимать и обрабатывать реальный IP пользователя, воспользуемся идущим в стандартном пакете Apache модулем remoteip.

Вначале настроим работу модуля remoteip. Для этого создадим файл remoteip.conf:

Теперь всё это нужно подключить модуль remoteip и перегружаем Apache:

Если все правильно увидим, свой IP адрес. Если вы настраиваете в локальной сети, то там будет ваш локальный IP как у меня на картинке:

SSL между Nginx и Apache

Некоторым скриптам необходимо знать через какую схему они работают, http, или https. Таким образом они формируют ссылки, а иногда принудительно перенаправляют клиентов куда нужно. Из-за не правильной настройки серверного ПО переадресация не может завершиться и браузер покажет нам ошибку ‘too many redirects‘.К примеру, это относится к популярному CMS движку WordPress.

Конфигурирование Nginx

Чтобы это исправить идем в секцию location конфигурации Nginx после proxy_pass добавим:

Перегружаем Nginx для применения настроек

Конфигурирование Apache

Нам необходми модуль setenvif_module, который подключен стандартной установке Apache.

Добавляем в конфигурацию виртуального хостинга перед секцией </VirtualHost>

Перегружаем Apache для применения настроек

Доступ к сайту по sftp

Если вы планируется передавать доступ к сайту другим людям, например для доступа к исходникам сайта, то на текущий момент лучше это делать по протоколу sftp.

Открываем конфиг ssh по пути /etc/ssh/sshd_config и комментируем там одну строку, добавляя далее несколько новых.

Сохраняем и перезапускаем ssh.

Настройка подключения sftp с ограничением доступа за пределами конкретной папки закончена.

Работа с сайтами разных пользователей на одном web сервере

Чтобы к файлам, загруженным через сайт, был доступ через ftp, можно запускать Apache от имени пользователя. Для этого используем модуль Apache mpm_itk. Поставим его.

Добавляем в конфигурацию виртуального хостинга перед секцией </VirtualHost>

Где yuri это имя пользователя, а www-data это группа, под которым будет запускаться Apache

Перегружаем Apache для применения настроек

Ротация логов виртуальных хостов

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

Создадим файл конфигурации logrotate для нашего виртуального хостинга

Сборка web-сервера Apache

Здесь главное – модули, которые надо указать в параметрах конфигуратора. И не забыть про путь, по которому сервер будет установлен. В нашем случае это /usr/local/apache.

$ tar xzf apache_1.3.33.tar.gz
$ cd apache_1.3.33
$ ./configure --prefix=/usr/local/apache --enable-shared=access  
--enable-shared=actions  --enable-shared=alias  --enable-shared=asis  
--enable-shared=auth  --enable-shared=autoindex  --enable-shared=cgi  
--enable-shared=dir  --enable-shared=env  --enable-shared=imap  
--enable-shared=include  --enable-shared=log_config  --enable-shared=mime  
--enable-shared=negotiation  --enable-shared=setenvif  --enable-shared=status  
--enable-shared=userdir  --enable-module=so  --enable-module=vhost_alias 
--enable-module=rewrite --enable-module=proxy --enable-module=info 
--enable-module=headers --enable-shared=vhost_alias  --enable-shared=rewrite
--enable-shared=proxy --enable-shared=info  --enable-shared=headers

Вызов команды configure – это одна строка, здесь я написал команду в несколько строчек исключительно для удобства чтения

Обратите внимание: модуль so нельзя делать динамическим!

$ make 
# make install