Как установить веб сервер apache на debian

Внутри секции виртуального хоста размещаем еще одну секцию <Directory /var/www/example.com>, которая включает директивы, применяемые не к хосту, а к каталогу, в нашем случае к корневому каталогу виртуального хоста. Там располагается директива Options, которая содержит следующие опции (перед каждой из которых ставится + или -, разрешая или запрещая опцию):

• ±Includes — разрешает / запрещает SSI (Server Side Includes — включения на стороне сервера), в нашем случае выключено в целях безопасности. Имеет смысл включать только в том случае, если ваш сайт явно требует данной опции.
• ±Indexes — разрешает / запрещает показывать содержимое каталога при отсутствии индексного файла, отключено в целях безопасности.
• ±ExecCGI — разрешает / запрещает выполнение сценариев CGI, отключаем в целях безопасности.

За ней следует директива AllowOverride, которая устанавливает использование директив из файлов .htaccess, по умолчанию сервер устанавливает для /var/www данную директиву в None, что запрещает использовать директивы .htaccess во всех вложенных директориях. Для того чтобы разрешить использование директив .htaccess установите данную директиву в All, что разрешит использовать в .htaccess любые директивы.

Этим список доступных опций (как и директив) не исчерпывается, но их рассмотрение выходит за рамки данной статьи и будет рассмотрено в отдельном материале. Вы можете самостоятельно ознакомиться с ними в официальной документации.

Закрываем открытые секции: </Directory> и </VirtualHost>, затем сохраняем файл. Конфигурация виртуального хоста готова.

Чтобы включить сайт необходимо сделать символьную ссылку на файл конфигурации в каталоге sites-enabled, а, чтобы выключить — удалить эту ссылку. Это можно сделать вручную, при помощи команды ln -s, или использовать специальную утилиту apache:

Данная команда включит сайт, для выключения введите:

В качестве опции команде передается имя конфигурационного файла из sites-available, в случае Apache 2.4 без расширения. После каждого такого действия веб-сервер необходимо перезапустить:

Чтобы проверить работу виртуального хоста разместите в его корневой директории любой html-файл и обратитесь к серверу по имени домена (при этом А-запись домена должна быть настроена и указывать на ваш веб-сервер).

Например, создадим индексный файл:

И разместим в нем строку:

В итоге в браузере вы должны увидеть следующее:

Установка PHP

Если веб-сервер был нужен вам для размещения статического содержимого или сторонних веб-приложений, например, публикации баз 1С:Предприятия, то дальше можно не читать. Но если вы собираетесь создать сайт на основе популярных CMS — вам потребуется поддержка скриптового языка PHP, на базе которого разработаны большинство современных «движков».

Важно! В современных дистрибутивах используется более новая версия PHP7, чтобы работать с новой версией языка вместо php5 в приведенных ниже командах следует указывать php7.x или просто php, например, вместо php5-imagick нужно набрать php7.0-imagick или php-imagick.

Будет установлен сам интерпретатор и необходимые для работы с веб-сервером модули. Модули позволяют гибко изменять функциональность PHP, управление модулями осуществляется аналогично Apache, когда конфигурации модулей располагаются в одной директории, а для их подключения делается символьная ссылка в другую.

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

Например, для работы с графикой вам потребуется поддержка графической библиотеки GD2, поэтому установим соответствующий модуль:

После чего не забудьте перезапустить веб-сервер:

Кстати, GD2, на наш взгляд не самый лучший выбор, в актив библиотеки можно записать низкое потребление ресурсов и высокую скорость работы, но по качеству работы с изображениями она уступает альтернативной утилите imagemagick, иногда значительно. Поэтому имеет смысл установить обе утилиты и выбрать ту, работа которой наиболее вам подойдет. Если ресурсы сервера позволяют, то предпочтительно использовать imagemagick.

Установим утилиту и модуль PHP для нее:

Для проверки работы PHP создадим в корневой директории сайта специальный скрипт:

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

Теперь наберем в браузере http://example.com/info.php, в результате работы данного скрипта вы увидите стандартную страницу с информацией о PHP, установленных модулях, настройках и т.д.

Установка MySQL

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

Установим сервер баз данных и модуль PHP для работы с ним:

Важно! В свежих выпусках Debian (и его производных) вместо пакета mysql-server следует установить mariadb-server, который полностью совместим с MySQL.

В процессе установки вам будет предложено ввести пароль для суперпользователя MySQL (root), которого не следует путать с суперпользователем системы.

Для удобного управления базами данных имеет смысл установить phpMyAdmin — удобную веб-утилиту для управления сервером MySQL:

Инсталлятор утилиты умеет автоматически настраивать популярные веб-сервера Apache и Lighttpd, нужный сервер следует указать при установке:

Веб-интерфейс утилиты будет доступен по адресу http://example.com/phpmyadmin, для входа следует использовать учетные данные пользователя MySQL, в нашем случае это root (других еще нет) с паролем, который мы указали во время установки MySQL.

В Ubuntu 14.04 мы столкнулись с небольшой проблемой, утилита сообщила нам, что расширение mcrypt не найдено, хотя соответствующий модуль PHP был установлен среди зависимостей.

Проверим. В /etc/php5/apache2/conf.d ссылка на данный модуль отсутствует, в то время как в /etc/php5/mods-available нужный файл есть. Следовательно, модуль установлен, но, по какой-то причине, не подключен. Возможно это связано с Apache 2.4 и тогда подобная ситуация может иметь место и в Debian 8.

Однако ничего страшного не произошло, все что нам нужно — это подключить модуль, создав символьную ссылку:

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

Откроем phpMyAdmin и перейдем на страницу Привилегии (Пользователи), где выберем Добавить нового пользователя.

Теперь прокрутим страничку чуть ниже и установим опцию Предоставить полные привилегии на базы данных подпадающие под шаблон (имя пользователя\_%)

Это позволит лишний раз не отвлекаться на установку прав, а просто создавать базы с именами вида ivanov_base1 или petrov_base2, предоставляя соответствующим пользователям полные права на них, а также быстро определять принадлежность баз данных. В тоже время данная настройка не является догмой, вы можете поступать на свое усмотрение. Остальные параметры оставляем по умолчанию.

Для проверки создадим базу данных phpMyAdmin — Базы данных — Новая база данных.

При создании БД обращайте внимание на кодировку. Сегодня большинство движков и веб-приложений работают с UTF-8 (utf8_general_ci), однако старые версии движков могут использовать национальные кодировки, поэтому нужно будет правильно указать их еще на стадии создания базы, в противном случае, залив в базу, созданную в UTF-8 дамп в кодировке Windows-1252 вместо русских букв на сайте окажутся «крякозяблики».

Создав базу, проверим ее привилегии, нажав одноименную ссылку рядом с именем базы.

Как видим, все правильно, полные права на базу имеет указанный в имени пользователь и суперпользователь root, хотя никаких настроек доступа при создании базы мы не указывали.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

История создания домашнего облака. Часть 2. Создание сервера — настройка LAMP в Debian

На пути создания своего облачного сервиса пока мы только освоились в системе Debian. Теперь пришла пора для следующего шага — создание и настройка веб-сервера, на базе которого можно будет запустить Nextcloud. />

Оглавление

Быстрая навигация по главе

Предисловие

В первой части этой истории был показан один из возможных вариантов настройки графического интерфейса Debian для удобного и привычного (исключительно субъективная точка зрения автора) использования человеком, пришедшим в Linux из Windows. И если для настройки виртуальной машины с Debian я пользовался только хостовой системой, то далее я специально работал только в этой виртуальной машине, ища информацию в интернете, конспектируя её в Notepadqq или gedit, слушая музыку через Аudacious, открывая файлы через LibreOffice и тому подобное. Таким образом можно обжиться и гораздо глубже почувствовать и оценить работу с операционной системой и её окружения, которое в стандартной поставке Debian довольно полноценно и функционально.

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

Текущая цель – создание сервера, чему и будет посвящена эта часть. Сервер можно настроить как с установкой и использованием графического интерфейса, так и без него. Во втором случае из предыдущей части можно просто пропустить разделы, касающиеся установки и настройки ПО для графического интерфейса и его настройки, установки пакетов графический программ и vmware-tools.

Я ничего не вижу плохого в использовании графического интерфейса при создании сервера: если человеку привычнее, удобнее и комфортнее сделать свой первый или второй сервер с графической средой – почему бы и нет? В конце концов, мой веб-сервер с графическим интерфейсом отработал год и отработает еще столько лет, сколько потребуется. Однако нужно иметь ввиду некоторые моменты.

В идеальном варианте единожды настроенная система должна будет работать без нашего вмешательства очень долго время. Мой сервер в «чистовом» варианте был настроен за два дня, а отработал без вмешательства практически год. Это значит, что графический интерфейс был задействован 0,05% времени активного существования сервера (компьютер работает только половину суток) и при этом занимал ресурсы: оперативную память, дисковое пространство, процессорное время. Все эти ресурсы лучше направить на обеспечение функционирования самого сервера: например, поднять memory_limit для PHP или вместить больше пользовательских данных на жесткий диск. Кроме этого, в случае проблем и неполадок при работе с реально удалённым сервером зачастую гораздо проще задействовать SSH-доступ. В данном контексте наличие графического интерфейса нежелательно и именно поэтому вторым сервером в моей сети уже была виртуальная машина без графического окружения, на которой из графического ПО был установлен только Midnight Commander, который я использовал для перемещения по файловой системе и редактирования файлов настроек через его редактор mcedit. Поэтому ниже приведена универсальная инструкция: даны команды с упором на использование командной строки, однако подразумевается, что в самый первый раз пользователь настраивает машину с графическим окружением, чем обусловлено использование браузера для локальной проверки доступности созданных сайтов и некоторые особенности настройки почтовой программы.

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

Примечание
При дальнейшем чтении в конструкциях вида http:// 127.0.0.1 (https:// 127.0.0.1) пробел после http:// (https://) необходимо убирать при вводе в адресную строку браузера. Пробел вставлен при публикации этой статьи с целью воспрепятствовать автоматической конвертации движком сайта текста в ссылки.

Установка программного обеспечения

Apache и Nginx – это пара веб-серверов с открытым исходным кодом, на которых построено порядка 55% серверов во всего мира. Apache является самым популярным веб-сервером с 1995 года и я выбрал именно его надеясь на хорошую задокументированность, популярность и, так сказать, хотелось начать с истоков. Это не значит, что Nginx хуже: Nginx эффективнее по потреблению ресурсов и работой под нагрузкой. В российском сегменте интернета сервер Nginx занимает порядка 65%, в то время как Apache – около 18%. Неплохая сравнительная статья двух серверов размещена на хабре.

Установка веб-сервера Apache2:

# apt-get install apache2 apache2-doc

И это – всё. Каких-то двадцать мегабайт и веб-сервер уже установлен. Не надо никаких перезагрузок или настроек — сервер уже умеет открывать странички HTML. Однако современный сайт в интернете – это не только набор статичных файлов, стилей, шрифтов и прочего подобного как двадцать лет назад. Современный сайт содержит скрипты, написанные на PHP, а динамическая информация (например, текстовой контент, комментарии, профили пользователей) пишется не в файлы рядом с PHP файлами, а в специальную базу данных SQL. Для полноценного сервера необходимо обеспечить поддержку этих технологий. Тем более – это несложно:

# apt-get install mysql-server mysql-client phpmyadmin
# apt-get install php5 php5-mysql libapache2-mod-php5

В процессе установки MySQL будет задан запрос для установки пароля суперпользователя mysql и нужно будет выбрать сервер apache2 для автоматической настройки работы с mysql. При установке пакета phpmyadmin я согласился с автоматической настройкой пакета и везде ввёл пароль суперпользователя mysql. Установка PHP происходит без каких-либо запросов.

Я не стал использовать более быстрый PHP7 или свободный MariaDB в качестве альтернативной открытой замены SQL и решил построить свой сервер на «каноническом» LAMP = Linux + Apache + MySQL + PHP, используя старые и проверенные решения, в случае проблем с которыми я бы мог быстро и беспроблемно найти информацию в интернете.

Три команды (которые на самом деле можно свести в одну) и у нас локально установлен полноценный и современный сервер. Это совсем просто!

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

Настройка веб-сервера Apache2

Для начала необходимо убедиться в том, что веб-сервер работает. Для этого нужно открыть браузер и набрать адрес http:// 127.0.0.1 (localhost). Должна открыться веб-страница с обнадёживающей надписью: «Apache2 Debian Default Page. It’s works!». Сервер действительно работает. Если у вас есть набор файлов сайта 2000-го года, то его можно разместить в директории /var/www/html и он наверняка будет открываться на нашем сервере.

Все основные настройки веб-сервера хранятся по пути /etc/apache2. Если открыть эту директорию, то можно увидеть основной файл конфигурации apache2.conf и директории conf-available, mod-available, sites-available. В этих директориях содержатся заранее сконфигурированные файлы с настройками (так называемые сниппеты), которые можно просто использовать по умолчанию, со своими правками или взять их как шаблон для создания своих конфигураций. Например, в директории sites-available находится конфигурационный файл хоста по умолчанию 000-default.conf. Если его открыть и поизучать, то окажется, что этот файл как раз и задаёт путь, по которому открывается наш сайт по адресу http:// 127.0.0.1: «DocumentRoot /var/www/html». Мало того, строчка «<VirtualHost *:80>» означает, что если я выпущу свою машину в локальную сеть и буду обращаться к ней по порту 80 (порт для HTTP), то мне будет открываться сайт, расположенный по пути /var/www/html. Как в этом убедиться?

Сначала нужно узнать IP адрес, который был назначен виртуальной машине после её загрузки. Для просмотра конфигурации сетевых адаптеров выполним:

В информации, выведенной на консоль несложно определить, что для адаптера eth0 установлен следующий адрес:

Теперь на хостовой машине я открываю в браузере адрес http:// 192.168.233.138 и ожидаю, что откроется знакомая страница. Но… она не открывается. Через некоторое время мой браузер пишет: «Время ожидания соединения истекло». И правильно пишет. Ведь в первой части я включил файрвол, но порт 80 не открыл! Исправим это:

# ufw allow 80

Снова пробуем открыть адрес http:// 192.168.233.138 и убеждаемся, что ожидаемая страница открывается. Виртуальный хост в виртуальной машине открылся из вне всей этой виртуализации. Мы сделали небольшой шаг в деле постройки своего маленького виртуального интернета.

Помимо директорий -available так же присутствуют ещё директории -enabled, которые содержат то, что на данный момент «включено». Если заглянуть в них, то можно увидеть, что эти директории содержат ссылки на файлы, находящиеся в директориях -available. В директории sites-enabled на данный момент только одна ссылка – на файл /etc/apache2/sites-available/000-default.conf. Это очень удобно — ярлыками мы можем управлять включением или отключением хостов без правки их конфигурационных файлов. Кроме этого источник конфигурации – один файл в независимости включена эта конфигурация сейчас или нет и это предотвращает ошибки, когда что-то правится в каком-то одном файле, а в другом — забывается. Для отключения нашего хоста нужно удалить требуемый ярлык, а для его включения – создать его. Для того, чтобы не удалять или создавать ярлыки вручную проще и надёжнее использовать специальные утилиты.

Отключаем виртуальный хост:

# a2dissite 000-default

Включаем виртуальный хост:

# a2enssite 000-default

После каждого изменения нужно перезагрузить конфигурации хостов или перезапустить сервер:

# service apache2 reload

# service apache2 restart

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

Начать нужно с того, что при отключении виртуального хоста 000-default отключения как такового не происходит. То есть, сайт как открывался изнутри и снаружи виртуальной машины – так и будет открываться в независимости от нахождения его конфигурации в папке sites-enabled. Это было неожиданно и я потратил относительно много времени, чтобы понять всё ли я правильно сделал или понял. До конца я с этим так и не разобрался, видимо это связано с тем, что путь /var/www/html задан глобально как директория по умолчанию для DocumentRoot. Так как мне не хотелось, чтобы было включено и доступно что-то лишнее я решил избавиться от самой директории html, а для всех вложенных /var/www по умолчанию доступ запретить.

Для настройки виртуального хоста по умолчанию я отредактировал его конфигурационный файл:

# nano /etc/apache2/sites-available/000-default.conf

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

Этой конфигурацией я переустановил директорию по умолчанию на /var/www, разрешил серверу следовать по символическим ссылкам в этой директории, разрешил серверу выполнять все директивы, объявленные в найденных файлах .htaccess и запретил доступ в этот каталог. Логика этих действий в том, чтобы я мог управлять доступом в эту директорию не обращаясь к настройкам веб-сервера вообще и не перезагружая его. Теперь нужно проверить это решение.
Переносим файл:

# mv /var/www/html/index.html /var/www/index.html

И удаляем каталог:

# rm /var/www/html

Перезапускаем сервер для вступления в силу новых настроек виртуального хоста по умолчанию:

# service apache2 restart

# nano /var/www/.htaccess

В котором прописываем одну строку (без кавычек): «Require all granted».

Подытожим. Теперь пути /var/www/html нет, но хост по умолчанию переконфигурирован на путь /var/www, по которому находится файл index.html, причём по умолчанию, на уровне веб-сервера, доступ в эту директорию запрещён, но разрешается содержимым локально расположенного там файла .htaccess.

Открываем в браузере http:// 127.0.0.1 и видим уже знакомую страницу «Apache2 Debian Default Page. It’s works». Теперь проверим работоспособность «локального» управления доступом:
Удаляем файл .htaccess:

# rm /var/www/.htaccess

И обновляем в браузере открытую страничку — должна открыться страница с уведомлением об ограничении доступа (Forbidden). Да, всё это работает, значит всё сделано правильно.

В принципе, этих нехитрых настроек вполне достаточно для дальнейшей беспроблемной работы веб-сервера. Но мне этого показалось мало. Сейчас наш веб-сервер умеет работать только по протоколу HTTP. Но как быть с протоколом HTTPS? Ведь если в будущем выводить проекты на базе этого веб-сервера в интернет, то умение работать по этому протоколу как минимум желательно. И я решил организовать поддержку HTTPS на основе создания самоподписного сертификата SSL.

Сначала нужно получить SSL сертификат, который будет установлен на наш сервер. Никакого домена у нас нет, да и статичного IP адреса тоже по сути не имеется. Но это всё неважно, потому что сертификат я буду генерировать самостоятельно, используя средства своей системы.

Внимание! В приведённой ниже инструкции считается, что сервер установлен на «безымянную» машину. Если имеется реальный IP или доменное имя, то их нужно указать в ТРЁХ местах: <Common Name IP/Domain>; <ServerName IP/Domain>; <Redirect «/» «https: //IP/Domain/»> — в соответствующих конструкциях заменить IP/Domain на IP адрес или доменное имя. В приведённом ниже тексте вместо IP/Domain используется localhost.

# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt

Данная команда создаст самоподписной сертификат стандарта Х.509 сразу аж на 10 лет с пропуском опции защиты сертификата парольной фразой — это нужно чтобы при запуске сервер Apache имел возможность читать файл без вмешательства пользователя, так как установив пароль, придется вводить его после каждой загрузки или перезагрузки сервера. Вместе с сертификатом будет создан новый ключ RSA на 2048 бит, которым и будет подписан сертификат. Опции –keyout и –out указывают пути, по которым OpenSSL должен сгенерировать ключ и сертификат.

В процессе создания сертификата будут заданы вопросы, на которые я указал следующие данные:

Далее нужно создать ключи Диффи-Хеллмана для обеспечения поддержки PFS:

# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

В терминале побегут точечки и плюсики и после окончания мультфильма можно создать файл ssl-params.conf, в котором будут определены параметры SSL для сервера:

# nano /etc/apache2/conf-available/ssl-params.conf

Для безопасной актуальной настройки я использовал код, сгенерированный в генераторе для конфигурации SSL на mozilla.github.io. В генераторе я выбрал сервер Apachе2, профиль Modern и правильно выставил версии сервера и OpenSSL, которые можно узнать по следующим командам:

# apache2 -v
# openssl version

В результате у меня получился следующий текст:

Теперь настроим виртуальный хост с поддержкой SSL:

# nano /etc/apache2/sites-available/default-ssl.conf

Текст этого файла я привёл к следующему виду:

Из вышеприведённого следует, что у нас в качестве директории DocumentRoot определена так же /var/www, доступ к которой настроен аналогично предыдущим настройкам. Включен механизм HSTS, который способствует принудительной установке соединения через протокол HTTPS. Включена поддержка SSL с указанием используемых сертификата и ключа, а также подключена поддержка обработки данных сертификата в PHP и CGI-скриптах. Последняя секция призвана обеспечить совместимость с ранними версиями браузера Internet Explorer и, в целом, необходимой не является.

Теперь сделаем финальные штрихи.

Откроем порт для SSL:

# ufw allow 443

Включим модули apache для поддержки SSL и HSTS:

# a2enmod ssl
# a2enmod headers

Включим конфигурацию SSL:

# a2enconf ssl-params

Включим виртуальный хост с поддержкой SSL:

# a2ensite default-ssl

Перезапустим сервер для принятия всех новых настроек:

# service apache2 restart

Вот и наступил интересный момент – проверки работоспособности нового функционала настроенной системы.

# nano /var/www/.htaccess

В котором прописываем одну строку: «Require all granted».

Открываем в браузере https:// 127.0.0.1. Должна открыться страница о неизвестном сертификате, после принятия которого (однократное или постоянное разрешение) откроется уже знакомая страница с уведомлением о запущенном веб-сервере.

Удаляем файл .htaccess:

# rm /var/www/.htaccess

И обновляем в браузере открытую страничку — должна открыться страница с уведомлением об ограничении доступа (Forbidden). Всё работает корректно. Теперь наши сайты доступны и по HTTP и через HTTPS.

Доступ по HTTP можно оставить включенным, отключить или сделать принудительное перенаправление на HTTPS.

Для включенного доступа HTTP делать ничего не нужно, так как запросы на порты 80 и 443 сервер обрабатывает индивидуально и наш сайт в папке /var/www будет открываться как через HTTP, так и через HTTPS.

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

# a2dissite 000-default
# service apache2 restart

Теперь, если открыть в браузере http:// 127.0.0.1 должна открыться страница с уведомлением об отсутствии страницы (Not Found).

Самый интересный третий вариант. В этом случае HTTP формально остаётся включенным, но обработка данных будет принудительно перенаправлена через HTTPS.

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

# a2enmod rewrite

Теперь откроем файл 000-default.conf:

# nano /etc/apache2/sites-available/000-default.conf

И перед закрывающимся тегом добавим нижеприведённый текст:

# service apache2 restart

# nano /var/www/.htaccess

В котором прописываем одну строку: «Require all granted».

Теперь, если открыть в браузере адрес http:// 127.0.0.1 нас автоматически перенаправит на https:// 127.0.0.1 с предупреждением о неизвестном сертификате (если ранее он не был внесён в список исключений в браузере), после принятия которого откроется уже знакомая страница с уведомлением о запущенном веб-сервере.

Настройка SQL

Для первичной настройки mysql достаточно выполнить следующую команду:

# mysql_secure_installation

После ввода пароля суперпользователя mysql я ответил на задаваемые вопросы в следующем порядке:

• отказался от изменения пароля root;
• подтвердил удаление анонимных пользователей из БД;
• подтвердил блокировку удаленного подключения для root (в целях безопасности пуcть root подключается только локально);
• подтвердил удаление тестовых БД;
• согласился с перезагрузку таблиц привилегий.

# mysql -uroot -p

После ввода пароля суперпользователя mysql мы видим приглашение mysql – значит сервис запущен и работает. Выйти из терминала mysql можно введя команду «exit».

Для проверки работоспособности phpmyadmin открываем в браузере адрес http:// 127.0.0.1/phpmyadmin. Если открылась страница c приглашением войти в phpmyadmin значит сервис запущен и работает.

Настройка PHP

После установки PHP я открыл файл его настроек:

# nano /etc/php5/apache2/php.ini

И привёл некоторые параметры к следующему виду:

• memory_limit = 1024M
• default_charset = «UTF-8»
• upload_max_filesize = 256M
• sendmail_path = /usr/bin/fake_sendmail.sh

[ Данный текст написан специально для сайта geektimes.ru автором AlexanderS.
Ссылка на источник необязательна, но его упоминание крайне желательно! ]

# apt-get install memcached php5-memcached

Посмотрим на настройки конфигурации сервиса:

# nano /etc/memcached.conf

В настройках я увеличил размер используемой памяти для кеширования: -m 64 -> -m 256. И проверил наличие режима работы только в локальной зоне: -l 127.0.0.1.

Перезапускаем сервис кеширования и веб-сервер:

# service memcached restart
# service apache2 restart

Теперь нужно убедиться в работоспособности сервиса. Для этого создаём файл:

# nano /var/www/info.php

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

Не забываем проверить наличие файла .htaccess в директории /var/www с соответствующим разрешающим содержимым, если его там нет – создаём.

Теперь можно открыть в браузере http:// 127.0.0.1/info.php — должна открыться страница со сведениями о PHP, в которой нужно проверить наличие в ней секции memcached. Если таблица появилась — PHP работает.

Проверить запущенный сервис memcached можно так:

$ ps -aux | grep memcached

В терминале должна вернуться строка, содержащая настройки memcached.

Создание почтовой заглушки для PHP

При настройках PHP в качестве параметра sendmail_path был указан шелл-скрипт. Функция этого скрипта — сохранять письма, отправленные через стандартную функцию php mail(), на локальной машине, в какой-то удобной папке, а не отправлять их куда-то.

# nano /usr/bin/fake_semdmail.sh

Со следующим содержимым:

Сделаем этот файл исполняемым:

# chmod +x /usr/bin/fake_semdmail.sh

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

# mkdir /var/mail/sendmail /var/mail/sendmail/cur /var/mail/sendmail/new /var/mail/sendmail/tmp

И назначаем права, чтобы сервер мог записывать файлы в этой папке:

# chmod 777 -R /var/mail/sendmail

Теперь все исходящие письма будут складываться в /var/mail/sendmail. Их можно просматривать текстовым редактором, а можно собирать почтовой программой. В комплекте предустановленного ПО Debian есть почтовый клиент Evolution. При настройке учётной записи в качестве типа сервера нужно выбрать «Почтовые каталоги в формате Maildir» и указать путь к почтовому каталогу (/var/mail/sendmail), а в качестве сервера указать «Sendmail».

Всё. В целом с сервером мы закончили — получена универсальная виртуальная машина, на базе которой можно строить свои сетевые сервисы. Я оставил и HTTP, и HTTPS доступы. Однако, после того как получен опыт по созданию и настройке сервера, а также добавлению сайтов (см. ниже) на него, я бы рекомендовал создать новую виртуальную машину с сервером без графического интерфейса как более оптимальную по потреблению ресурсов.

Настройка доступа SSH

Сервер не был бы полноценным сервером без наличия доступа через SSH. Так называемый «шелл» позволяет быстро и безопасно подключиться к удалённому серверу, используя, например, небольшую программку putty, — на локальном компьютере мы получаем прямой доступ к терминалу удалённого сервера.

# apt-get install ssh

Откроем порт для SSH (вообще-то, порт по умолчанию должен быть под номером 22, но ниже я переопределил порт в конфигурации SSH):

# ufw allow 106

Для организации доступа для нашего пользователя user нужно открыть файл:

# nano /etc/ssh/sshd_config

И добавить в конец файла директиву:

Кроме этого, в целях безопасности я сделал в этом файле следующие изменения:

• сменил порт с 22 на какой-то другой (список портов): Port 22 -> Port 106
• отключил устаревший протокол: Protocol 2,1 -> Protocol 2
• отключил удалённый доступ для root: PermitRootLogin yes (или PermitRootLogin without-password) -> PermitRootLogin no

# service sshd restart

Теперь я могу запустить программу putty на хостовой машине и подключиться к своему серверу в консольном режиме введя адрес подключения 192.168.233.138, порт 106 и имя пользователя user. При подключении необходимо ответить утвердительно на принятие ключей и ввести пароль пользователя user. Если понадобиться выполнить команды от суперпользователя, то можно использовать уже известную команду su.

Защита доступа

Я не стал заниматься защитой веб-сервера от DDoS, изначально полагая, что если он будет размещаться на VPS/VDS, то эффективную защиту обеспечит хостинг, а если делать свой сервер «торчащий» в интернет, то этим вопросом надо заниматься серьёзно и это тема отдельной статьи. Защита от Slow HTTP DDoS делается относительно просто в соответствии с многочисленными инструкциями в интернете, но она не спасёт от распределенной атаки, производимой с множества разных IP адресов.

При DDoS наш сервер просто перестанет работать на какое-то время. Но после атаки, которая не будет длиться вечно, работа сервера восстановится. А вот если кто-то сумеет заполучить доступ по SSH, то контроль за сервером будет потерян, а данные на нём скомпроментированы, поэтому контроль доступа к серверу по SSH – здравая идея.

Самое простое и банальное, что можно сделать – сменить стандартный порт, что мы и сделали при настройке SSH. Лет пять назад я «выставил» только что созданный сервер в интернет по недавно полученному реальному IP адресу и был удивлён тому, что за неделю существования сервера, про который ещё никто ничего не знал, в логах системы накопилось большое количество записей о неудачных попытках авторизации по SSH и FTP. Очевидно, что в современном интернете существует немалое количество сервисов-роботов, которые ищут компьютеры с открытыми портами и пытаются к ним подключиться, перебирая пароли по имеющейся базе или используя метод полного перебора.

К счастью для нас, существует такая штука как fail2ban:

# apt-get install fail2ban

Сразу после установки утилита уже сконфигурирована на защиту большинства портов и если в логах системы за десять минут появится больше шести провальных попыток подключиться, то нарушитель будет заблокирован на десять минут. Механизм работы fail2ban довольно прост – по определённым триггерам срабатывают так называемые джейлы, которые определяют действие, предназначенное для защиты приложения.

Параметры блокировки можно задавать индивидуально:

# nano /etc/fail2ban/jail.local

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

# общие настройки
[DEFAULT]
ignoreip = 127.0.0.1
bantime = 2592000
findtime = 43200
maxretry = 6
banaction = iptables-multiport
# настройка отправки сообщения на почту
destemail = user@localhost
sendername = Fail2Ban
mta = sendmail
action = %(action_mwl)s

# защита SSH
[ssh]
enabled = true
port = 106
filter = sshd
logpath = /var/log/auth.log

# выявляем неудачные попытки ввода пароля
[apache]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache*/*error.log

# выявляем потенциальные сканирования для применения эксплойтов и php уязвимостей
[apache-noscript]
enabled = true
port = http,https
filter = apache-noscript
logpath = /var/log/apache*/*error.log

# выявляем попытки переполнения Апача
[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2

# выявляем неудачные попытки в поиске домашней директории на сервере
[apache-nohome]
enabled = true
port = http,https
filter = apache-nohome
logpath = /var/log/apache*/*error.log
maxretry = 2

Приведённая выше настройка позволяет не контролировать локальный доступ, а при шести неверных попыток входа в течение 12 часов банит IP адрес атакующего, используя iptables, на 30 дней. Контролируется не только доступ по порту для SSH, но и подозрительные действия, направленные на дестабилизацию работы веб-сервера.

Справочный материал по веб-серверу

Запуск, остановка и перезагрузка сервера:

# service apache2 start
# service apache2 stop
# service apache2 restart

Перезагрузка конфигураций сервера:

# service apache2 reload

Включение и отключение хоста test:

# a2ensite test
# a2dissite test

Включение и отключение конфигурации test:

# a2enconf test
# a2disconf test

Проверка синтаксиса файлов (должно вернуться: «Syntax OK»):

# apache2ctl configtest

Вариант добавление сайта с доступом по HTTP или HTTPS используя имеющийся виртуальный хост

Допустим, на наш сервер нужно добавить новый сайт, размещённый в директории site.com, расположенной в /home/user/www. Это может быть удобно, так как пользователю user не нужно будет покидать пределы своего домашнего каталога при работе с сайтом.

Выставляем права для пользовательского каталога (на всякий случай):

# chmod 755 /home/user

Создаём каталога для сайта:

$ mkdir /home/user/www /home/user/www/site.com

Размещаем символическую ссылку на каталог сайта:

# ln -s /home/user/www/site.com /var/www/site.com

Для добавления доступа по HTTP открываем файл:

# nano /etc/apache2/sites-available/000-default.conf

Или для добавления доступа по HTTPS открываем файл:

# nano /etc/apache2/sites-available/default-ssl.conf

И добавляем в открытый файл нижеприведённое содержимое перед закрывающимся тегом /VirtualHost:

# service apache2 restart

Проверяем доступность сайта по адресу http:// 127.0.0.1/site.com или https:// 127.0.0.1/site.com (методика проверки — см. ниже). Нужно обратить внимание, что сайт будет открываться в независимости от наличия файла .htaccess, так как для директории с сайтом установлена директива: «Require all granted».

Вариант добавление сайта с доступом по HTTP или HTTPS используя новый виртуальный хост и настройкой обращения к сайту через его доменное имя, а не IP

Условия задачи – те же, что и выше: допустим, на наш сервер нужно добавить новый сайт, размещённый в директории site.com, расположенной в /home/user/www. Но теперь я ещё хочу обращаться к сайту вводя в строку браузера только его доменное имя.

Выставляем права для пользовательского каталога (на всякий случай):

# chmod 755 /home/user

Создаём каталога для сайта:

$ mkdir /home/user/www/site.com

Размещаем символическую ссылку на каталог сайта:

# ln -s /home/user/www/site.com /var/www/site.com

Для добавления доступа по HTTP создаём файл:

# nano /etc/apache2/sites-available/site.com.conf

И добавляем в него следующее содержимое:

Или для добавления доступа по HTTPS создаём файл:

# nano /etc/apache2/sites-available/site.com-ssl.conf

И добавляем в него следующее содержимое:

В /etc/hosts добавляем строку «127.0.0.1 site.com»:

# echo >> /etc/hosts 127.0.0.1 site.com

Активируем HTTP хост:

# a2ensite site.com.conf

Или активируем HTTPS хост:

# a2ensite site.com-ssl.conf

# service apache2 restart

Проверяем доступность сайта по адресу http:// site.com или https:// site.com (методика проверки – см. ниже). Нужно обратить внимание, что сайт будет открываться в независимости от наличия файла .htaccess, так как для директории с сайтом установлена директива: «Require all granted».

Все действия производятся внутри гостевой виртуальной машины. Было бы интересно «открыть» сайт в браузере хостовой системы. Это несложно. Мы знаем доменное имя и IP адрес гостевой машины. Если хостовая система Windows, то необходимо открыть файл c:\Windows\System32\drivers\etc\hosts и в самый конец добавить следующую строчку:

После этого изменения компьютер или хостовую систему придётся перезагрузить. Теперь, при открытии в браузере сайта site.com обращение к нему будет перенаправлено на нашу виртуальную машину. Фактически, мы сделали простейшую маршрутизацию в своём личном интернете на уровне хостовой операционной системы.

В случае, если нужен доступ к виртуальному хосту только по HTTPS, но не хочется терять соединения по протоколу HTTP можно настроить редирект:

— создать файл /etc/apache2/sites-available/site.com.conf по вышеприведённой инструкции, если он не создан
— в файле /etc/apache2/sites-available/site.com.conf раскомментировать три строки RewriteEngine/RewriteCond/RewriteRule
— активировать хост site.com.conf, если он не активирован
— перезапустить сервер: # service apache2 restart

Проверка работоспособности добавленного сайта

Самый простой способ проверки доступности сайта — разместить в его корневой директории файл index.html с каким-то содержимым.

Создаём файл index.html:

$ nano /home/user/www/site.com/index.html

И добавляем в него следующее содержимое:

В зависимости от метода добавления сайта открыть в браузере адрес http:// 127.0.0.1/site.com (https:// 127.0.0.1/site.com) или http:// site.com (https:// site.com) — должна открыться страница содержащая текст «TEST OK».

Справочный материал по MySQL

Создание пользователя user123 с паролем pass123 и базой данных db123 через консоль.

Войти в mysql, введя пароль суперпользователя mysql при запросе:

# mysql -u root -p

И создать базу данных (префикс «mysql>» набирать не нужно, точка с запятой в конце обязательна):

mysql> CREATE DATABASE `db123`;

Создать пользователя user123 с паролем pass123:

mysql> CREATE USER ‘user123’@’localhost’ IDENTIFIED BY ‘pass123’;

Выдать привилегии пользователю на базу данных:

mysql> GRANT ALL PRIVILEGES ON `db123`.* TO ‘user123’@’localhost’;

Обновить таблицу привилегий:

mysql> FLUSH PRIVILEGES;

Для проверки открыть адрес http:// 127.0.0.1/phpmyadmin и авторизоваться с реквизитами доступа user123/ pass123. Должен открыться доступ к базе данных db123.

Изменение пароля для root mysql c pass123 на pass456:

# mysqladmin -uroot -ppass123 password pass456

Изменение пароля пользователя user123 c pass123 на pass456:

# mysqladmin -uuser123 -ppass123 password pass456

Удаление пользователя user123:

mysql> DROP USER ‘user123’@’localhost’;

Удаление таблицы db123:

mysql> DROP DATABASE `db123`;

Справочный материал по fail2ban

# service fail2ban restart

Проверка запущенных правил:

# fail2ban-client status

Подробная статистика по правилу sshd:

# fail2ban-client status ssh

# fail2ban-client set ssh unbanip Banned_IP

История создания домашнего облака. Часть 2. Создание сервера — настройка LAMP в Debian.
Версия текста: 1.0.2.
Дата первой публикации: 30.01.2018.
Дата последней правки: 29.12.2021.

1.0.2 [29-12-2021]
Правка ссылок оглавления.

1.0.1 [15-01-2020]
Обновление оглавления.

1.0.0 [30-01-2018]
Первая версия.
Описывается установка и настройка LAMP в Debian 8.7.x.