• Главная

Настройка виртуальных хостов на Apache для начинающих. Настройка виртуального хостинга


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

Завоевав невероятную популярность еще в 1996 году, веб-сервер Apache и по сей день является одним из самых распространенных решений для хостинга. По данным британского аналитического агентства Netcraft, его доля на рынке в 2015 году составила почти 51%, что, по сути, является абсолютной монополией. Столь оглушительный успех объясняется целым рядом факторов, но главный из них - гибкость. Сервер поддерживает подключение внешних модулей, работу с различными интерпретаторами языков программирования и базами данных, что делает его поистине универсальным и позволяет работать с любыми типами веб-приложений.

HTTPS-сервер Apache является частью связки веб-серверов (вместе с Nginx), которая используется в качестве основы ПО на хостинге Timeweb. Сегодня наша задача – разобраться с настройками Apache и установкой виртуального хостинга.

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

Установка и настройка виртуального хостинга позволит Вам:

  • обеспечить работу на VDS нескольких сайтов;
  • разграничить доступ к администрированию данных отдельных сайтов, размещенных на виртуальном хостинге;
  • работать с базовой частью - virtual host – для каждого сайта.

Файл .htaccess

Главным инструментом в работе с настройками виртуального хостинга является файл .htaccess – в отличие от httpd.conf файл работает для каталога, в котором расположен, и подкаталогов, тогда как второй отвечает за настройки конфигурации в целом, для всего массива сайтов под эгидой Apache, расположенных на виртуальном хостинге.

Управление конфигурацией осуществляется посредством директив – языка, на котором, собственно, и работает веб-сервер Apache: директивы прописываются в текстовых файлах (уже упомянутых httpd.conf и .htaccess).

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

  • httpd.conf
  • .htaccess
  • srm.conf

Отметим, что в текстовых файлах с директивами довольно много «лишней» для пользователя информации. В основном это комментарии-разъяснения, которые не несут никакой функциональной нагрузки. То есть просто информация, описание того, за что отвечает та или иная директива. Если установка и настройка виртуального хостинга для Вас – дело новое, их можно удалить, предварительно сохранив копию конфигурационного файла для изучения. Нефункциональные пояснительные строки обозначены в документе знаком решетки: #.

Файл httpd.conf

Установка виртуального хостинга завершается этапом внесения изменений в httpd.conf и проверки работоспособности сервера после их сохранения.

Самыми важными директивами, на которые нужно обратить внимание в этом конфигурационном файле, являются:

  • ServerName – отвечает за то, какое имя будет присвоено основному серверу;
  • ServerAlias;
  • NameVirtualHost;
  • VirtualHost.

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

Отметим, что директивы (команды) ServerName не нужно путать с NameVirtualHost. Последние отвечают за имена как раз виртуальных серверов.

И ещё об именах и о преобразовании численных адресов (IP) в имена доменные. В файле httpd.conf можно найти директиву HostnameLookups. Значения on и off, соответственно, позволяют преобразовать численные IP-адреса в доменные имена. Хотя теоретически значение on должно увеличить нагрузку на мощности сервера, этого обычно не происходит.

Файл srm.conf

Файл srm.conf включает директивы, которые позволяют управлять структурой каталогов, расположенных на сервере. Главными среди них являются DocumentRoot и UserDir, а также DirectoryIndex.

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

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

Настройки .htaccess

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

Базовые приемы

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

Задаем индексный файл

Индексный файл - это веб-документ на языке html, php или другом, который загружается в тот момент, когда посетитель обращается к какому-либо каталогу сайта напрямую. По умолчанию, он носит название index с приписанным на конце расширением.

Когда пользователь переходит по ссылке site-name.ru, он попадает в корневой каталог проекта. При этом происходит загрузка индексного файла, представляющего собой главную страницу сайта. В том случае, если таковой отсутствует в директории, веб-сервер Apache возвращает ошибку 403 (Forbidden, отказано в доступе).

Какой именно файл считать индексным, определяет директива DirectoryIndex. В большинстве случаев, в ней перечислены следующие варианты: index.php, index.html и index.htm. Но что делать, если Вы используете CMS, написанную, к примеру, на Python? Тогда можно указать индексный файл самостоятельно, добавив в .htaccess всего одну строчку. Для index.py она будет выглядеть следующим образом:

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

DirectoryIndex index.py, index.php, index.html

Устанавливаем страницы ошибок

.htaccess позволяет задавать собственные страницы ошибок в виде статичных документов. Эта опция весьма полезна, так как позволяет скрыть от злоумышленников версию CMS (в том случае, если страница генерируется на уровне движка) или сервера. Для этого можно воспользоваться следующим шаблоном:

ErrorDocument код_ошибки /каталог/страница_ошибки.html

Так, для самой известной ошибки “404 страница не найдена” директива будет такой:

ErrorDocument 404 /errors/404.html

Управляем кодировкой

Довольно часто при работе с CMS можно столкнуться с проблемой отображения текстовой информации. Как правило, это происходит из-за ошибок в кодировке. .htaccess позволяет принудительно переопределить ее значение:

AddType "text/html; charset=utf-8" .html .htm

В примере выше мы дали понять Apache, что все документы с расширением .html и .htm необходимо отдавать в кодировке UTF-8.

Боремся с воровством

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

Данный термин обозначает не просто копирование контента, а его “встраивание” в код другого веб-ресурса. Таким образом воруют различные изображения. При этом каждый раз, когда посетитель заходит на страницу, где размещен хотлинк, картинка подгружается с Вашего сайта, создавая дополнительную нагрузку и расходуя трафик. Однако, внеся изменения в настройки сервера Apache с помощью htaccess, это легко предотвратить. Метод основан на проверке переменной HTTP_REFERER. В случае выявления ее подмены, вместо запрашиваемого изображения будет выводиться любое другое, например, Ваш логотип:

Включаем проверку HTTP_REFERER

RewriteEngine On RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(.+\.)?site-name\.ru/ [NC]

Меняем запрошенный файл на картинку с логотипом Вашего проекта:

RewriteCond %{REQUEST_URI} !logo.jpg$ [NC] RewriteRule .(jpg|jpeg|gif|bmp|png)$ http://site-name.ru/logo.jpg [L] </IfModule>

Другая напасть - отображение информации с Вашей площадки на другом сайте посредством тега <iframe>. С его помощью можно воровать даже видео, поэтому такую возможность обязательно следует заблокировать:

<IfModule mod_headers.c> Header always append X-Frame-Options SAMEORIGIN </IfModule>

Здесь мы прописали запрет в заголовок, отдаваемый сервером. SAMEORIGIN означает, что использование <iframe> возможно только в пределах оригинального ресурса.

Оптимизируем работу сайта

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

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

Перечисляем расширения файлов, которые хотели бы закэшироовать

<FilesMatch ".(gif|jpg|jpeg|png|ico|swf|flv|pdf|doc|docx|odf)$">

Устанавливаем время хранения кэша полгода (в секундах)

Header set Cache-Control "max-age=14515200, private" </FilesMatch> </IfModule>

Кэшировать таблицы стилей и JavaScript следует на менее продолжительное время:

<ifModule mod_headers.c> <FilesMatch ".(js|css)$">

Время жизни кэша составляет 1 день (также в секундах)

Header set Cache-Control "max-age=86400, private" </FilesMatch> </IfModule>

Динамические скрипты лучше вообще исключить из кэша во избежание ошибок при обновлении страниц:

<ifModule mod_headers.c> <FilesMatch ".(php|cgi|scgi|fcgi)$"> Header unset Cache-Control </FilesMatch> </IfModule>

timeweb.com

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

Apache — это один из самых популярных веб-серверов для размещения сайтов на хостингах и VPS, а также для создания тестовых окружений. Если на вашем сервере один сайт, то все довольно просто, все запросы, поступающие к серверу, отправляется этот единственный сайт. А что если сайтов несколько? Как Apache будет понимать кому адресован запрос?

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

Содержание статьи:

Как работают виртуальные хосты Apache?

Не будем пока о локальных системах. Если у вас есть веб-сайт, то наверное, вы занимались парковкой домена и уже знаете как все настраивается. Сначала используется DNS сервер, который выдает IP адрес вашего сервера всем клиентам, запросившим адрес этого домена. Затем клиенты отправляют запрос на ip вашего сервера, а веб-сервер уже должен его обработать.

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

Вы настраиваете виртуальные хосты Apache, а затем веб-сервер сравнивает домен, переданный в заголовке «Host» с доступными виртуальными доменами и если находит совпадение, то возвращает содержимое настроенной папки или содержимое по умолчанию, или ошибку 404. Нужно сказать, что вы можете настроить виртуальный хост для любого домена, например, vk.com или losst.ru. Но пользователи смогут получить доступ к этому домену у вас, только если к вам будут поступать запросы от браузеров, в которых будет значиться этот домен. А теперь детальнее про настройку.

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

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

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

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

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

$ sudo cp /etc/apache2/sites-enabled/000-default.conf /etc/apache2/sites-enabled/site1.ru.conf

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

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

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

<VirtualHost *:80>ServerName site1.ruServerAdmin webmaster@localhostDocumentRoot /var/www/html/site1.ru/ErrorLog ${APACHE_LOG_DIR}/error.logCustomLog ${APACHE_LOG_DIR}/access.log combined</VirtualHost>

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

sudo a2ensite site1.ru

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

sudo systemctl restart apache2

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

sudo vi /etc/hosts

127.0.0.1 site1.ru

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

site1.ru

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

Если вы хотите использовать современный безопасный протокол https для работы вашего виртуального хоста, то вам кроме обычного хоста на порту 80 будет необходимо создать виртуальный хост на порту 443. Здесь будет не так много отличий, вот пример, для нашего сайта site1.ru:

<IfModule mod_ssl.c><VirtualHost *:443>ServerAdmin webmaster@localhostDocumentRoot /var/www/htmlServerName site1.ruErrorLog ${APACHE_LOG_DIR}/error.logCustomLog ${APACHE_LOG_DIR}/access.log combinedSSLEngine onSSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pemSSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key<FilesMatch "\.(cgi|shtml|phtml|php)$">SSLOptions +StdEnvVars</FilesMatch></VirtualHost></IfModule>

Теперь о каждой новой строчке более подробно:

  • <IfModule mod_ssl.c> — весь код в этой секции будет выполнен только в том случае, если активирован модуль mod_ssl. Это нужно для безопасности, чтобы если модуль не активирован, то код не вызывал ошибок;
  • SSLEngine — включает поддержку SSL;
  • SSLCertificateFile, SSLCertificateKeyFile — пути к файлам сертификата и приватного ключа;
  • SSLOptions — для скриптов php, cgi и других мы передаем стандартные SSL опции.

Вот и все. Как видите, не так сложно. Осталось перезапустить Apache и проверить как все работает:

sudo a2enmod sslsudo a2ensite site1.ru-sslsudo systemctl restart apache2

Затем откройте https адрес в браузере:

https://site1.ru

 

Выводы

В этой статье мы рассмотрели как выполняется настройка виртуальных хостов Apache. Как видите, один веб-сервер может обслуживать сотни сайтов, а создание виртуальных хостов apache совсем не сложно. Надеюсь, эта статья была вам полезной. Если у вас остались вопросы, спрашивайте в комментариях!

Оцените статью:

Загрузка...

losst.ru

Виртуальный хостинг – настройка и как работает

Разберем по этапам понятие «виртуальный хостинг» и технологию его создания (настройки). Он представляет собой методику хранения содержимого Web-сайтов с разными именами доменов или хостов на одном сервере. Например, именам www.mystore.com и www.frankspage.com в DNS может соответствовать один и тот же IP-адрес, и Apache обслуживает оба этих сайта (равно как и собственное имя хоста, которое задано директивой ServerName). Какое программное обеспечение нужно для виртуального хостинга? Для обслуживания всех запросов достаточно одного Apache, что упрощает администрирование и позволяет экономить IP адреса. Однако увеличивается вред при взломе, потому что взломщик получает доступ ко всем сайтам.

Протокол НТТР/1.0 не указывает имя хоста. Поэтому ранее виртуальный хостинг был возможен лишь в том случае, когда каждому имени хоста был поставлен в соответствие отдельный IP-адрес (с последующим созданием IP-псевдонимов, указывающих на одну и ту же Ethernet-карту). Каждый виртуальный хост определялся по IP-адресу, и запрос, приходящий от Web-браузера, всегда получал в ответ страницу соответствующего Web-сайта. Недостатком такого подхода было то, что привязка больших блоков IP-адресов к одной и той же карте становилась громоздкой и приводила и к излишнему потреблению адресного IP-пространства.

С появлением версии протокола НТТР/1.1 данный процесс значительно упростился. Обязательный заголовок Host: указывает искомое имя хоста, поэтому виртуальные хосты, различаемые по имени, стали нормой в современном Internet. Клиенты, не поддерживающие заголовка Host: теперь чрезвычайно редки. Далее обсуждается исключительно новый вариант виртуального хостинга. Если вы заинтересованы в использовании виртуального хостинга на базе IP-адресов, обратитесь к документации, имеющейся на Web-сайте Apache.

Большая часть файла httpd.conf определяет сервер по умолчанию — глобальный набор определений, применяющихся ко всем запросам, получаемым сервером Apache. В сервере по умолчанию директива ServerName используется в первую очередь для конструирования URL-перенаправления с кодом 301. Можно также воспользоваться небольшим набором директив, отменяющим глобальные настройки в том случае, когда заголовок Host: совпадает с определенным именем хоста. Такие наборы правил и представляют собой виртуальные хосты.

Предположим, что сервер называется stripes.somewhere.com. Его имя задано в главной директиве ServerName. Для настройки виртуального хостинга по именам следует воспользоваться директивой NameVirtualHost с аргументом * (этот символ-заместитель означает "все хосты"), за которой следует необходимое число различных блоков :

Пример блока VirtualHost:

NameVirtualHost * ServerName www.somewhere.com DocumentRoot /usr/local/www/data ServerAdmin [email protected] ErrorLog logs/www.somewhere.com-error_log CustomLog logs/www.somewhere.com-access_log common ServerName www.frankspage.com ServerAlias frankspage.com DocumentRoot /home/frank/public_html ServerAdmin [email protected] ErrorLog logs/www.frankspage.com-error_log CustomLog logs/www.frankspage.com-access_log common

Внутри контейнера директива ServerName определяет имя хоста. Директива DocumentRoot указывает, где находится корневой каталог файловой системы для приходящего запроса, a ErrorLog и CustomLog - альтернативные log файлы для каждого виртуального хоста. ServerAlias позволяет перечислить псевдонимы виртуального хоста. В блоке можно включить и любые другие директивы.

Важно отметить, что при настройках, приведенных ранее, запрос к серверу по умолчанию (stripes.somewhere.com) или к любому другому имени хоста, соответствующему IP-адресу сервера, но не совпадающему ни с одним из блоков , обработан не будет.

Пример более корректного блока VirtualHost:

NameVirtualHost * ServerName stripes.somewhere.com ServerAlias *.somewhere.com DocumentRoot /usr/local/www/data ServerAdmin [email protected] ErrorLog logs/www.somewhere.com-error_log CustomLog logs/www.somewhere.com-access_log common ServerName www.frankspage.com ServerAlias frankspage.com DocumentRoot /home/frank/public_html ServerAdmin frank@ frankspage.com ErrorLog logs/www.frankspage.com-error_log CustomLog logs/www.frankspage.com-access_log common

Виртуальные хосты можно создавать множеством способов: указывая различные IP-адреса и порты в блоках . Синтаксис таких методов можно уточнить по адресу http://httpd.apache.org/docs/vhosts/.

www.hostland.ru

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

Https-сервер Apache является частью связки вебсерверов (вместе с Nginx 1.6), которая используется в качестве основы ПО на хостинге Timeweb. Сегодня наша задача – разобраться с настройками Apache и установкой виртуального хостинга.

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

Установка и настройка виртуального хостинга позволит вам:

• Обеспечить работу на VDS нескольких сайтов.• Разграничить доступ к администрированию данных отдельных сайтов, размещенных на виртуальном хостинге.• Работать с базовой частью - virtual host – для каждого сайта.

Файл .htaccess

Главным инструментом в работе с настройками виртуального хостинга является файл .htaccess – в отличие от httpd.conf файл работает для каталога, в котором расположен и подкаталогов, тогда как второй отвечает за настройки конфигурации в целом, для всего массива сайтов под эгидой Apache, расположенных на виртуальном хостинге.

Управление конфигурацией осуществляется посредством директив – языка, на котором, собственно, и работает веб-сервер Apache: директивы прописаны/прописываются в текстовых файлах (уже упомянутых httpd.conf и .htaccess).

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

• httpd.conf.• .htaccess.• srm.conf.

Отметим, что в текстовых файлах с директивами довольно много «лишней» для пользователя информации. В основном это комментарии-разъяснения, не несущие никакой функциональной нагрузки. То есть просто информация, описание того, за что отвечает та или иная директива. Если установка и настройка виртуального хостинга для вас – дело новое, их можно удалить, сохранив, предварительно копию конфигурационного файла для изучения. Нефункциональные пояснительные строки обозначены в документе знаком решетки: #.

Настройка в файле httpd.conf

Установка виртуального хостинга завершается этапом внесения изменений в httpd.conf и проверки работоспособности сервера после их сохранения.

Самыми важными директивами, на которые нужно обратить внимание в этом конфигурационном файле, являются:

• ServerName – отвечает за то, какое имя будет присвоено основному серверу.• ServerAlias.• NameVirtualHost.• VirtualHost.

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

Отметим, что директивы (команды) ServerName не нужно путать с NameVirtualHost. Последние отвечают за имена как раз виртуальных серверов.

И ещё об именах и о преобразовании численных адресов (IP) в имена доменные. В файле httpd.conf можно найти директиву HostnameLookups. Значения on и off, соответственно, позволяют преобразовать численные IP-адреса в доменные имена. Хотя, теоретически, значение on должно увеличить нагрузку на мощности сервера, этого обычно не происходит.

Настройки конфигурации в srm.conf

Файл srm.conf включает директивы, которые позволяют управлять структурой каталогов, расположенных на сервере. Главными среди них являются DocumentRoot и UserDir, а также DirectoryIndex.

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

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

Настройки .htaccess

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

timeweb.com

Настройка виртуальных хостов на Apache для начинающих / Песочница / Хабр

В прошлых статьях мы установили и настроили на локальном компьютере сервер Apache. В принципе, на этом можно было бы остановиться, так как сервер находится в рабочем состоянии и его можно спокойно использовать в работе. Но, по личному опыту, могу сказать, что использование только одного хоста localhost не очень удобно при разработке нескольких сайтов, так как для каждого сайта нужно будет создавать в каталоге localhost отдельный каталог и со временем в ней (папке localhost) будет очень трудно разобраться и что-то найти. Да и при тестировании разрабатываемого проекта гораздо удобнее набирать в браузере адрес вида test, чем localhost/test. Поэтому мы приступаем к настройке виртуальных хостов на локальном сервере.

Вообще, существует два способа конфигурирования виртуальных хостов: на основе имени и на основе IP-адреса. Но, так как мы настраиваем локальный сервер и у нас только один IP (кстати, для локалки он 127.0.0.1), то вариант с привязкой к IP нам не подходит и мы будем рассматривать вариант с привязкой к имени.

В прошлой статье я уже упоминал, что в файле конфигурации httpd.conf сервера есть строчка Include conf/extra/httpd-vhosts.conf. Мы ее уже раскомментировали, поэтому собственно и переходим к этому файлу. Найти его можно в папке Apache/conf/extra/.

Начнем рассматривать содержимое файла. Первая директива – это NameVirtualHost *:80 привязывает виртуальные хосты, указываемы далее, к именам сайтов указанных в секциях <VirtualHost …>. Здесь вместо звездочки можно вписать IP 127.0.0.1, но тогда во всех секциях <VirtualHost> нужно будет указать то же самый IP. Принцип работы этой директивы заключается в том, что при обращении, допустим, к адресу localhost, сервер проверяет, соответствует ли входящий адрес и порт, описанным в секциях VirtualHost и имеется ли запись 127.0.0.1:80 в директиве NameVirtualHost. Если соответствует, то он перебирает секции VirtualHost, в заголовках которых указан входящий адрес. Таким образом, запрос 127.0.0.1:80 будет распределяться только между виртуальными хостами, в которых он указан.

Дальше в файле идут секции VirtualHost. Как видно из названия, каждая секция описывает настройки каждого виртуального хоста. Обязательно должна быть хотя бы одна такая секция, которая описывает настройки для localhost.<VirtualHost *:80> DocumentRoot “D:/server/localhost/www” ServerName localhost ErrorLog “D:/server/logs/localhost.error.log” CustomLog “D:/server/logs/localhost.access.log” common

Директива DocumentRoot в этой секции указывает на папку, к которой будет происходить обращение при вызове адреса localhost.ServerName как раз содержит имя нашего виртуального хоста, то есть его адрес. Сюда можно вписывать как адреса вида localhost, test, site, так и адреса localhost.ru, test.com, www.site.org. В ErrorLog и CustomLog мы указываем, где будут хранится логи этого виртуального хоста. Обратите внимание, имеет смысл для каждого хоста добавлять в имя файла лога название этого хоста, чтобы в будущем было легко найти лог требуемого хоста. Эти директивы можно и не указывать, но тогда логи этого виртуального хоста будут храниться в общих логах сервера.

В таком виде секция виртуального хоста уже работоспособна и на этом можно остановиться. Но можно добавить такие директивы как:

  • ServerAdmin [email protected] – адрес электронки администратора виртуального хоста
  • ServerAlias www.site.ru – зеркало хоста
Кроме того, можно добавить секции для индивидуальной настройки хоста:

<IfModule alias_module> ScriptAlias /cgi-bin/ “d:/server/host_name/cgi-bin”

Создает ссылку на папку скриптов cgi-bin для хоста host_name.

<Directory “d:/server/host_name/www”> Options Indexes Includes FollowSymLinks AllowOverride All Order allow,deny Allow from all

Настройки директории хоста host_name, их мы разбирали в прошлой статье.

После настройки файла httpd-vhosts.conf проверим правильность его конфигурации. В каталоге D:\server\Apache\bin\ создайте файл httpd-S.cmd с содержимым:“D:\server\Apache\bin\httpd.exe” –S pause

После запуска этого файла вы увидите окно с отчетом о проверке, Syntax OK в конце говорит о том, что все настройки в порядке.

Теперь нужно прописать созданные хосты в файл C:\Windows\system32\drivers\etc\hosts. Для этого открываем его текстовым редактором и вносим следующие записи:

127.0.0.1 www.host1.ru host1.ru #Чтобы не набирать www перед именем сайта, создаем зеркало 127.0.0.1 www.host2 host2 #Можно и без .ru создавать хосты 127.0.0.1 host3 #Самый распространенный вариант для локалки 127.0.0.1 localhost # Обычно уже указано, проследите чтобы случайно не удалили и не закомментировали.

Сохраните файл и перезапустите Apache. Попробуйте разместить в каталогах созданных вами виртуальных хостов какие-нибудь тестовые файлы (например index.html) и из браузера открыть хосты по адресам, указанным в директории ServerName каждого хоста.

Если вам приходится часто создавать виртуальные хосты и не очень хочется каждый раз редактировать все эти файлы и перезапускать Apache вручную, создайте в папке сервера (D:\server\) файл createVH.cmd с таким содержимым:

@cls @rem Получаем текущую папку. Если у вас структура папок сервера как у меня, но он установлен, например на другом диске, укажите здесь вместо %~dp0 путь с нему (например, D:\server\) косая черта в конце обязательна. @set server_path=%~dp0 :dir_exist @set /P new_dir="Enter new VHost name:" @set /P ip_add="Enter your IP address:" @ if exist %server_path%%new_dir% echo "VHost %new_dir% already exist. Please re-enter Vhost name." @ if exist %server_path%%new_dir% goto dir_exist @md %server_path%%new_dir%

@rem Здесь указывается путь до конфиг файла виртуальных хостов, если у вас другой , поменяйте @set outputfile=%server_path%Apache\conf\extra\httpd-vhosts.conf @echo. >> %outputfile% @echo ^<VirtualHost %ip_add%:80^> >> %outputfile% @echo ServerName %new_dir% >> %outputfile% @echo DocumentRoot "%server_path%%new_dir%" >> %outputfile% @echo ErrorLog "%server_path%logs\%new_dir%.error.log" >> %outputfile% @echo CustomLog "%server_path%logs\%new_dir%.access.log" common >> %outputfile% @echo ^</VirtualHost^> >> %outputfile% @if %ip_add%==* set ip_host=127.0.0.1 @if not %ip_add%==* set ip_host=%ip_add% @set hostfile=%windir%\system32\drivers\etc\hosts @echo. >> %hostfile% @echo %ip_host% %new_dir% >> %hostfile% @set htmlfile=%server_path%%new_dir%\index.html @echo ^<html^> >> %htmlfile% @echo ^<head^> >> %htmlfile% @echo ^<title^>%new_dir%^</title^> >> %htmlfile% @echo ^</head^> >> %htmlfile% @echo ^<body^> >> %htmlfile% @echo %new_dir% >> %htmlfile% @echo ^</body^> >> %htmlfile% @echo ^</html^> >> %htmlfile% @rem Здесь путь до самого сервера, если у вас другой, поменяйте @start %server_path%Apache\bin\httpd.exe -k restart

Теперь для создания хоста просто запустите этот файл, впишите в ответ имя нового хоста и IP, который будет указываться в секции VirtualHost файла httpd-vhosts.conf. По окончанию работы программа сама закроется. Вам останется только проверить созданный хост, набрав в адресной строке браузера имя, которое вы вписали в программу. Если все успешно прошло, то вы увидите страницу с именем нового хоста.

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

habr.com

Как правильно настроить виртуальные хосты веб-сервера Apache на Linux?

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

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

В веб-сервере Apache существует возможность настройки виртуальных хостов[1]. Концепция виртуального хоста позволяет множеству сайтов быть привязанным к одному IP-адресу. Apache определяет полное доменное имя[2], которое запрашивает пользователь, ищет в конфигурации нужную директорию и работает с ней в дальнейшем. Это в полной мере удовлетворяет вышеописанные пожелания разработчиков, позволяет им настраивать проекты отдельно друг от друга и комфортно осуществлять резервное копирование.

В предыдущей статье мы поэтапно рассмотрели установку PHP, Apache и MySQL на операционную систему Linux. Теперь, когда мы имеем рабочую версию веб-сервера на локальной машине, перейдем к настройке виртуальных хостов.

Настройка доменных имен локальных сайтов

При вводе полного доменного имени в адресную строку, браузер посылает запрос к DNS. Так он узнает IP-адрес машины, на которой располагается ваш сайт. Естественно, что DNS ничего не знает о сайтах, расположенных на вашей локальной машине и не может связать доменное имя с её IP-адресом.

Мы можем заставить браузер не осуществлять запросы к DNS для определенных доменных имен. Допустим, мы хотим, чтобы сайт с адресом http://my-test-site был расположен в конкретной директории файловой системы, а при запросе ваша операционная система сообщала браузеру, что сайт расположен на вашей локальной машине.

Для этого мы должны выполнить приведенные ниже команды. Они добавят в начало конфигурационного файла /etc/hosts информацию о доменном имени, привязанном к вашей локальной машине. Либо просто откройте файл в текстовом редакторе (от имени администратора) и добавьте туда строку «127.0.0.1 localhost my-test-site».

sudo sed -i '1 i 127.0.0.1 localhost my-test-site' /etc/hosts

Создание и настройка виртуального хоста

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

В папке /etc/apache2 лежат конфигурационные файлы, отвечающие за настройки общие для всех сайтов. Нас интересует файл /etc/apache2/apache2.conf. Откройте его в текстовом редакторе (с правами администратора) и найдите конструкцию <Directory /var/www/>. Необходимо удалить её полностью от открывающего тега до закрывающего и заменить на конструкцию, приведенную ниже.

<Directory /home/user/http> AllowOverride All Require all denied Require ip 127.0.0.1 Require host localhost </Directory>

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

Теперь добавим нашего пользователя в группу веб-сервера, создадим папку в файловой системе и зададим ей права доступа.

sudo usermod -a -G www-data user mkdir /home/user/http sudo chgrp www-data /home/user/http chmod -R 775 /home/user/http

Следующий конфигурационный файл расположен в папке /etc/apache2/sites-available. В ней хранятся конфигурационные файлы каждого отдельного сайта. Сразу после установки в этой папке лежат два файла 000-default.conf и default-ssl.conf. Они содержат конфигурационные структуры, созданные по умолчанию для сайтов, работающих через протокол HTTP и HTTPS. Нас интересует файл 000-default.conf. Скопируем его в эту же папку под другим именем.

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/my-test-site.conf

Теперь откроем его в визуальном редакторе (от имени администратора) и удалим все содержимое. Вместо удаленных строк вставим конструкцию, приведенную ниже.

<VirtualHost *:80>     ServerName my-test-site     ServerAdmin webmaster89localhost     DocumentRoot /home/user/http/my-test-site     ErrorLog ${APACHE_LOG_DIR}/error.log     CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>

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

Если вы выбрали другое расположение корневой папки или локальное доменное имя, исправьте строки начинающиеся с ServerName и DocumentRoot.

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

mkdir /home/user/http/my-test-site sudo chgrp www-data /home/user/http chmod -R 775 /home/user/http/my-test-site sudo a2ensite my-test-site sudo service apache2 restart

Мы закончили с настройками, теперь протестируем, все ли работает нормально. В папке нашего тестового сайта «/home/user/http/my-test-site» создадим файл с именем index.html. Добавьте в него HTML-разметку, приведённую ниже.

<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> </head> <body> <h2>Виртуальный хост настроен</h2> </body> </html>

Если все этапы настройки были сделаны правильно, то при открытии нового окна браузера и вводе в адресную строку «http://my-test-site» вы увидите следующий ответ.

Рис 1. Сообщение, свидетельствующее о правильнойнастройке виртуального хоста.

Термины, использованные в статье

  1. Виртуальный хост — технология, которая позволяет многим сайтам быть привязанным к одному IP-адресу. Ей пользуются хостинговые компании, разделяя дисковое пространство между сайтами. Но при этом они предоставляют доступ к одному и тому же программному обеспечению всем пользователям.
  2. Полное доменное имя - включает полную спецификацию с определением имени хоста и доменов, в которые он входит. К примеру, «site-name.ru» говорит, что информация об IP-адресе этого хоста хранится в Российском сегменте DNS, а именем хоста является «site-name».

coder-booster.ru

Безопасная настройка виртуального хостинга Debian + Apache2 + vsftpd / Хабр

1. Постановка задачи
Дано Debian-сервер «из коробки» (установлен из дистрибутива)

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

  • Ограничить возможность обзора файловой системы определенной папкой для пользователя проекта.
  • Ограничить возможность запуска бинарников пользователями
  • Ограничить возможность открытия портов на сервере (нужно как-то по другому сформулировать)
  • Автоматизировать добавление пользователя в систему: создание папки, конфига apache, пользователей mysql или postgres
2. Решение
  • 2.0 Обновление системы
  • 2.1 SSH
  • 2.2 Файловая система
  • 2.3 Apache
  • 2.3.1 Права пользователей [apache2-mpm-itk ]
  • 2.3.2 Отдельные tmp для каждого сайта
  • 2.3.3 Sendmail
  • 2.4 FTP
  • 2.5 MySQL + Postgres
  • 2.6 Firewall
  • 2.7 chroot
  • 2.8 Автоматизация
2.0 Обновляемся
Ставим свежие версии пакетов. Вот мой список репозиториев:# file: /etc/apt/sources.list # Yandex deb http://mirror.yandex.ru/debian/ lenny main deb http://mirror.yandex.ru/debian/ lenny contrib non-free deb-src http://mirror.yandex.ru/debian/ lenny main deb-src http://mirror.yandex.ru/debian/ lenny contrib non-free # Security fix deb http://security.debian.org/ lenny/updates main deb http://security.debian.org/ lenny/updates contrib non-free deb-src http://security.debian.org/ lenny/updates main deb-src http://security.debian.org/ lenny/updates contrib non-free debian:~# apt-get update debian:~# apt-get dist-upgrade
2.1 Генерируем ключи для SSH
Дабы исключить возможность перехвата парольной фразы, мы сгенерируем rsa ключи для входа на сервер.neoveneficus@book:~$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/neoveneficus/.ssh/id_rsa): /home/neoveneficus/.ssh/id_rsa already exists. Overwrite (y/n)? y Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/neoveneficus/.ssh/id_rsa. Your public key has been saved in /home/neoveneficus/.ssh/id_rsa.pub. The key fingerprint is: cb:07:dd:67:21:37:ab:93:e1:60:40:ce:0e:b8:b8:e3 neoveneficus@book The key's randomart image is: +--[ RSA 2048]----+ | . | | . + | |. . + . + | |.. o . . + + | |+ . o S . o o | |.o . + = . o | |.E . * o | | . o | | . | +-----------------+

Обратите внимание — ключи генерируются на Вашей рабочей машине, а затем публичный ключ заливается на сервер:

neoveneficus@book:~/.ssh$ scp ~/.ssh/id_rsa.pub [email protected]:.ssh/authorized_keys neoveneficus@book:~/.ssh$ cat ~/.ssh/id_rsa.pub | ssh [email protected] "cat > ~/.ssh/authorized_keys; chmod 600 ~/.ssh/authorized_keys"

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

2.2 Файловая система. Права пользователей.
Поговорим про файловую систему. Я предлагаю выделить для наших сайтов отдельную папку в корне файловой системы.debian:~# cd / debian:/# mkdir -m 755 web

Домашние папки наших пользователей будут такого вида:

Создаем пользователей и расставляем права:debian:~# useradd site1 -b /web/ -m -U -s /bin/false debian:~# passwd site1 debian:~# chmod 754 /web/site1 debian:~# mkdir -p -m 754 /web/site1/public_html/www debian:~# mkdir -p -m 777 /web/site1/tmp debian:~# chmod +t /web/site1/tmp debian:~# chown -R site1:site1 /web/site1/

Пользователь site1 будет иметь домашнюю папку /web/site1. Ключ -m означает, что папка будет создана автоматически. -U — так же будет создана одноименная группа, куда пользователь будет помещен. Пользователь не будет иметь шелла. Все, что будет доступно из веба — будет находится в папке public_html. Если когда-нибудь захочется иметь поддомены — разместим их в папках рядом с www.

2.3 Apache
2.3.1 Права пользователей. Модификация Apache [apache2-mpm-itk]

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

Для исправления этого недоразумения нам понадобится установить модифицированную версию аpache. Пакет называется apache2-mpm-itk. Установив пакет, мы получим возможность в конфигах файла указывать, от какого пользователя и группы должен работать apache при обработке сайта.

debian:~# apt-get install apache2-mpm-itk

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

AssignUserId site1 site1

В тоже время мы хотим, чтобы, используя web-шелл, нельзя было править файлы нашего проекта, кроме тех, на которыx стоят права o+w.

drwxr-xr-- 2 site1 site1 4096 Мар 5 10:17 . drwxr-xr-x 3 site1 site1 4096 Мар 5 10:14 .. -rwxr-x--- 1 site1 site1 0 Мар 5 10:14 index.php -rwxrw---- 1 site1 site1 0 Мар 5 10:17 tmp.txt

Для этого в нашем конфиге мы будем писать:

AssignUserId www-data site1

Таким образом apache сможет прочитать index.php, выполнить и отдать в браузер, но не сможет изменить его. А tmp.txt изменить сможет. Важный момент — нужно запретить консоль у пользователя www-data

debian:~# usermod -s /bin/false www-data
2.3.2 Отдельный tmp для каждого сайта
Предотвращаем инклуд сессий с соседнего сайта. + Запрещаем php выходить выше пользовательской домашней дирректории.

В конфиг нашего сайта нужно добавить диррективы open_basedir, upload_tmp_dir, session.save_path

Получаем такой минималистичный конфиг:

# file: /etc/apache2/sites-available/site1 <VirtualHost *:80> DocumentRoot "/web/site1/public_html/www/" ServerName "test1" ErrorLog /web/site1/error_log CustomLog /web/site1/access_log combined AssignUserId www-data site1 php_admin_value open_basedir "/web/site1/:." php_admin_value upload_tmp_dir "/web/site1/tmp" php_admin_value session.save_path "/web/site1/tmp" </VirtualHost>

После создания конфига нужно сделать сайт активным с помощью команды:

debian:~# a2ensite site1

А затем перечитать конфиги:

debian:~# /etc/init.d/apache2 reload
2.3.3 Sendmail
Почему я вынес Sendmail отдельным пунктом? Потому что по умолчанию он не работал. Пришлось повозится. Я расскажу самый простой способ. Чтобы php умел отправлять письма, проделываем следующие операции.# file: /etc/php5/apacge2/php.ini [раскомментируем и изменим строку] ++ sendmail_path = /usr/sbin/exim4 -t

Для конфигурации Exim4 (по умолчанию в качестве Mail Transfer Agent используется именно он) существует пакет exim4-config. Воспользоваться им можно так:

debian:~# dpkg-reconfigure exim4-config

После этого вам начнут задавать вопросы. На первый (Общий тип почтовой конфигурации) отвечаем:

  • интернет-сайт; прием и отправка почты напрямую, используя SMTP
А далее жмем Enter до конца настройки. Теперь все должно работать.
2.4 vsftpd
Теперь разберемся с FTP. Для работы был выбран vsftpd.debian:~# apt-get install vsftpd

Далее меняем конфиг:

# file:/etc/vsftpd.conf listen=YES # Запрещаем анонимный доступ anonymous_enable=NO # Открываем локальным пользователям доступ к домашним директориям по FTP local_enable=YES # Разрешаем команды на запись write_enable=YES dirmessage_enable=YES xferlog_enable=YES connect_from_port_20=YES ascii_upload_enable=YES ascii_download_enable=YES ftpd_banner=Welcome to our FTP service. # "Запираем" пользователей в домашних папках chroot_local_user=YES secure_chroot_dir=/var/run/vsftpd pam_service_name=vsftpd rsa_cert_file=/etc/ssl/certs/vsftpd.pem

Говорим демону vsftpd перечитать конфиги:

debian:~# /etc/init.d/vsftpd reload
2.5 MySQL + PostgreSQL
Ставим MySQLdebian:~# apt-get install mysql-server phpmyadmin

Создаем нового пользователя.

debian:~# echo "CREATE USER 'site1'@'localhost' IDENTIFIED BY 'Пароль_для_пользователя_site1'; GRANT USAGE ON * . * TO 'site1'@'localhost' IDENTIFIED BY 'Пароль_для_пользователя_site1' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0; CREATE DATABASE IF NOT EXISTS site1 DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci; ; GRANT ALL PRIVILEGES ON site1 . * TO 'site1'@'localhost';" | mysql --user=root --password=Пароль_mysqlroot mysql

Ставим Postgres

debian:~# apt-get install postgressql phppgadmin

Меняем пароль на пользователя postgres:

debian:~# echo "\password" | sudo -u postgres psql Enter new password: Новый_пароль_postgres Enter it again: Новый_пароль_postgres

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

#file /etc/postgresql/8.3/main/pg_hba.conf -- local all postgres ident sameuser -- local all all ident sameuser ++ local all postgres md5 ++ local all postgres md5

В /etc/phppgadmin/apache.conf открываем доступ извне.

order deny,allow deny from all allow from 127.0.0.0/255.0.0.0 ::1/128 # allow from all

Меняем на:

order deny,allow deny from all allow from 127.0.0.0/255.0.0.0 ::1/128 # allow from all

Говорим apache перечитать конфиги:

debian:~# /etc/init.d/apache2 reload

У постгрес есть один нюанс. Юзеры всегда видят названия соседних БД. Чтобы они не мозолили глаз нашим пользователям в phppgadmin, правим конфиг:

# file:/etc/phppgadmin/config.inc.php -- $conf['owned_only'] = false; ++ $conf['owned_only'] = true;

Пользователи создаются такой командой:

debian:~# echo "CREATE USER site1 WITH PASSWORD 'Пароль_для_пользователя_site1' NOCREATEDB NOINHERIT NOCREATEUSER ; CREATE DATABASE site1 owner site1;" | sudo -u postgres psql
2.6 Firewall
В нашем случае цели просты — запретить злоумышленнику открывать порты. Поэтому решение будет простым — мы не будем вдаваться в нюансы правил iptables, а воспользуемся пакетом arno-iptables-firewall, который упростит нам жизнь. Он сам спросит нас, что мы хотим во время установки. Ответы на вопросы ниже.debian:~# apt-get install arno-iptables-firewall * Do you want to manage the firewall setup with debconf? : Да * External network interfaces: eth0 * Open external TCP-portrs: 21 22 53 80 443 3128 5432 5001 5900 6881:6889 * Open external UDP-portrs: 53 3130 5001 6881:6889 * Internal network interfaces: <в нашем случае оставляем пустым> * Соглашаемся на перезагрузку firewall'а.
2.7 Запуск Apache2 в chroot среде [посредством libapache2-mod-chroot]
Что такое chroot'инг? Это создание специальной среды (песочницы), изолированной от окружения. Скажем, процесс apache не должен иметь доступа к папкам home. В тоже время в изолированную среду нужно брать все, что нужно для работы. Самый простой способ — это воспользоваться libapache2-mod-chroot.debian:~# apt-get install libapache2-mod-chroot debian:~# a2enmod mod_chroot debian:~# /etc/init.d/apache2 restart

Chroot'инг — это интересная тема с кучей своих проблем, связанных с тем, что помимо apache обычно требуется куча дополнительных программ, библиотек и средств для работы. Поэтому я не буду делать статью в статье, и отправлю Вас на отличный материал по этой теме. Используйте программу ldd и берите с собой в изолированное окружение все, что нужно именно Вам.

sudouser.com/zapusk-web-servera-apache2-v-srede-chroot-v-debian-i-ubuntu.html

2.8 Автоматизация добавления новых пользователей
Начал писать скрипт и понял, что монстр, который может все, будет использовать неудобно. В статье все команды писались так, чтобы их потом просто было засунуть в sh скрипт. Поэтому я думаю, что каждый пользователь за несколько минут легко состряпает сценарий, необходимый и удобный именно ему.
Постскриптум
Буду рад замечаниям. Особенно интересны мысли по поводу chroot. Кто знает простые рецепты?

habr.com