Настройка web хостинга разберем детали


1GAME.ua - Веб-хостинг - Установка и настройка PsychoStats



Настройка хостинга на RU-Center (nic.ru)

Paramtamtam · 2016.1.22 · 11 min

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

Итак, отбросим причины в сторону. Первым делом - что нам понадобится для того чтоб всё сделать “под ключ”, т.е. владельцем домена/хостинга был заказчик (как физ.лицо), а ты был лишь лицом, которое выполняет работу? От заказчика тебе потребуется:

  • Фотографии/сканы разворота паспорта и страницы с пропиской,
  • Логин/пароль от почтового ящика, который будет фигурировать при регистрации,
  • Необходимая сумма денег для оплаты требуемых услуг.

Вопрос: При регистрации домена может сразу встать вопрос - делегировать домен на руцентр или, например, сразу же на DNS-хостинге от Яндекса?

Ответ: На руцентр. Так как для делегирования на Яндекс потребуется подтвердить права на владение доменом. И проще всего это сделать с помощью проверки наличия определенного файла с кодом в корне сайта. Поэтому - смело всё делай по дефолту, потом переделегируем, если потребность такая возникнет.

Сразу скажу - если “с сайта” будут отправляться письма и при этом хостить DNS у Яндекса - возникнут проблемы с отправкой писем. DKIM настроить на Яндекс будет невозможно, а у руцентра он принципиально не настраиваемый. Поэтому считай это тонкостью использования руцентра в целом.

Итак, считаем что аккаунт у нас заведен, домен - зарегистрирован, хостинг - заказан. Не забудь а Личных данных приложить сканы/фотографии паспорта клиента для верификации личности, так правильнее будет.

Настройка почты

Переходим “Панель управления” → “Почтовый сервер”. Выбираем наш почтовый домен (должен быть создан автоматически, в противном случае создаем его с именем основного домена). Первым делом лезем в “Почтовые ящики” → “[email protected]_domain.ltd”, и добавляем синонимы к ящику вида [email protected] [email protected] [email protected] [email protected] . Таким образом все “важные” письма будут первым делом попадать именно на этот ящик, а владелец сайта сможет написать на своих визитках “клёвый” почтовый адрес [email protected]_domain.ltd :) Так же заходим в интерфейс самого почтового ящика (нажимаем на его адрес вверху страницы) и настраиваем переадресацию всех входящих писем на email-адрес заказчика.

Далее “Панель управления” → “Почтовый сервер” → “Параметры”, и в поле “Обработка нераспознанной почты” вводим [email protected]_domain.ltd . Таким образом письма, отправленные на несуществующий ящик (_например blabla@yourdomain.ltd) будут уходить на [email protected]_domain.ltd , а оттуда - нашему заказчику. Если же будут заведены дополнительные адреса (например - для сотрудников нашего заказчика) - ничего перенастраивать не придется.

Настройка СУБД

Настройку СУБД производить в соответствии с используемой системой управления контента. Рекомендую “выключать” все привилегии для пользователя, которые ему критически не важны. В идеале ему должно хватать лишь INSERT UPDATE SELECT и DELETE . Но это лишь в идеале. Ещё раз - тут смотри сам.

Больше особо интересных моментов в настройке для хостинга нет.

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

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

Выключаем WP_CRON для WordPress

В WordPress Есть такая штука как WP_CRON, которая позволяет выполнять “отложенные” действия, такие как отложенная публикация постов, проверка наличия обновлений и прочие весьма полезные штуки. Но это довольно тяжелая задача, надо признать, и выполнять её при каждом посещении пользователя/администратора сайта - иметь лишнюю задержку. Что мы делаем чтоб ситуацию исправить? Мы выключаем WP_CRON в WordPress путем добавления строки:

В wp-config.php , и добавляем отдельную задачу в “Панель управления” → “Веб-сервер” → “Планировщик заданий” с именем, например - “wp cron” и выполняемой командой:

Теперь пользователи не будут ощущать задержку, а все задачи крона WP будут выполняться “в фоне” с заданным интервалом (выставь “Каждые 5 минут”).

Настраиваем модули

Переходим в “Управление модулями”. Здесь нам необходимо выполнить предварительную настройку как веб-сервера (Apache, а точнее просто указать какие модули ему загружать), выбрать используемую версию php (не знаю почему, но я всё ещё пользуюсь версией 5.3 ), и указать необходимые параметры для php, такие как кодировка (выставляй везде UTF-8), максимальный размер загружаемого файла, и модули php (выставляй их в соответствии с требованиями сайта).

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

Перевод сервера в ручной режим

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

Теперь цепляемся к хостингу по ssh (реквизиты для соединения указаны в “Панель управления” → “Помощь”), и все дальнейшие настройки будем выполнять только в нем.

Настройка nginx

Первым делом нам необходимо настроить:

  • Отдачу статического контента с помощью nginx
  • Включить его сжатие с помощью gzip
  • Настроить его хранение на стороне клиента (вместо того, чтоб каждый раз скачивать его с нашего сервера)

Для этого выполняем в консоли:

И смотрим как у нас был настроен nginx в автоматическом режиме. Он отдавал статику, но сжатие и хранение статики на стороне клиента - отсутствует. Испраляем-с :) Копируем из этого конфига все location -ы (в моем случае это были location / , location

* ^.+/.(jpg|jpeg|gif|. и location @fallback ) в конфиг

/etc/nginx/nginx.conf , вставляя их в секцию server <. >. Сделать по образу и подобию не думаю что составит трудность.

Для включения gzip-сжатия статики необходимо в секцию http <. >добавить:

Добавить можно в принципе в любом месте перед началом секции server <. >. Теперь статика будет отдаваться значительно быстрее :)

Для того чтоб она лишний раз не загружалась с сервера, а хранилась на стороне клиента мы немного подправил location который отвечает за отдачу статики, а точнее добавим в него строку expires 30d, , чтоб получилось примерно следующее:

Так же приведу для сравнения полный листинг получившегося у меня конфига:

Теперь перезапускаем nginx и проверяем чтоб всё работало как надо с помощью, например, PageSpeed Insights:

Настройка apache

Конфиг Apache теперь храниться по пути

/etc/apache_2.4/httpd.conf , и для его перезапуска необходимо будет выполнить команду:

Всё что нам необходимо сделать здесь - это добавить 2 строки перед секцией : ServerTokens Prod и ServerSignature Off , которые запрещают вывод сигнатур сервера. Если тебе потребуется ещё что-то настраивать у Apache - то делай это в этом файле.

Настройка php

Для того, чтоб веб-сервер Apache начал читать именно наш конфиг, а не тот что лежит в директории

/etc/ - нам необходимо скопировать соответствующий в домашнюю директорию. Поясню - например, мы используем php версии 5.3 . Смотрим в

Конфиг есть, но писать в него мы соответственно не можем. Копируем его в домашнюю директорию под именем php.ini :

И добавляем в него строку expose_php=Off , которая скроет версию используемого php и заголовках ответов веб-сервера. Перезапускаем Apache:

И проверяем чтоб всё работало, но ничего лишнего наружу “не светилось”.

Настраиваем резервное копирование

Хоть администраторы хостинга и выполняют резервное копирование - но лишней копия всё же не будет. Хранить мы будем бэкапы 31 день (все настройки указываются в начале скрипта), не забудь указать настройки ID хостинга (т.е. названия твоей домашней директории) и реквизиты для подключения к mysql базе примерно в 84 строке скрипта (+ там же проверка на наличие итогового бэкапа бд):

По итогу его выполнения у нас должна появиться директория

Настройка web хостинга,

В Интернете десятки, а может даже и сотни статей о настройке Linux серверов для хостинга Web-сайтов, что же такого нового в этой статье?

Все просто — эта статья наиболее актуальна на текущий момент, все что в ней описано было сделано на реальном сервере который вводился в эксплуатацию для хостинга небольшого Интернет-магазина (суточная посещаемость — примерно 2000 уникальных посетителей).

Итак приступим к настройке.

Исходные данные:
VPS сервер, арендованный в ihor.ru (4 CPU, 3 GB RAM, 40 GB SSD)
На сервере установлена ОС Debian 9 (minimal)
Задача:
Настроить сервер для Web-хостинга сайта Интернет-магазина, в качестве Web-сервера использовать Nginx, в качестве бэкенда — php-fpm7, в качестве ftp-сервера — pure-ftpd с локальной базой пользователей, из дополнительного софта для разработчиков развернуть phpMyAdmin.

1. Базовая настройка Debian 9.

Обновляем систему до последней версии:

Устанавливаем правильную часовую зону (Asia/Yekaterinburg):

Устанавливаем вспомогательные пакеты (все они понадобятся нам в дальнейшем):

Добавим настройки среды для пользователя root (опционально, Вы можете это не делать):

Указанные выше настройки среды делают следующее (Многие из них описаны в моей статье про ведение истории команд):
1. Включают подсветку синтаксиса в vim,
2. Включают возможность копировать текст открытый в vim с помощью выделения его мышкой в терминале Putty.
3. При вызове vi будет запускаться редактор vim,
4. Устанавливают настройки хранения и вывода истории команд в консоле,
5. Изменяют командную строку терминала,

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

Настраиваем sudo для нашего пользователя:

Хочу обратить Ваше внимание на формат добавляемой строки в файл /etc/sudoers, обычно многие администраторы добавляют такую строку:

Это неправильно и нарушает безопасность сервера, никогда так не делайте!
Обязательно указывайте вместо первого ALL имя сервера, а вместо второго ALL логин пользователя с правами которого Вы запустите команду из sudo.
Так же не следует указывать NOPASSWD, т.к. таким образом для выполнения sudo не будет запрошен пароль пользователя, а значит — это потенциальная возможность для злоумышленника получить полные привилегии на сервер без знания вашего пароля.
И вместо последнего ALL всегда указывайте какую конкретно команду Вы разрешаете выполнить пользователю с повышеными привилегиями, не нужно давать пользователю право на все команды, дайте только на те, которые действительно нужны.

Итак, наша правильная строка выглядит так:

$(hostname) будет заменено на имя сервера и в файл /etc/sudoers добавиться строка:

то есть, мы дали пользователю mgrigorev право выполнить команду su с правами пользователя root и только с нашего сервера myserver.ru и обязательно с запросом пароля пользователя mgrigorev.

Проверяем коректность настроек sudo:

Теперь заходим на наш сервер через Putty под пользователем mgrigorev и добавляем свой публичный ssh-ключ:

Разлогиневаемся и пробуем зайти по ssh-ключу, если после подключения к серверу у Вас не был запрошен пароль и в окне Putty при подключении было написано:

то Вы авторизовались по ssh-ключу.

Пробуем перейти в привилигерованный режим выполнив команду:

Обратите вниание на знак ‘-‘ после su, он не просто так написан, указав ‘-‘ при получении доступа под root мы установим все переменные среды именно пользователя root.
Если мы не укажем знак ‘-‘ , то некоторые переменные среды унаследуются от нашего пользователя mgrigorev, что в последствии может сыграть злую шутку.

Будет запрошен пароль пользователя mgrigorev, вводим его и мы должны увидеть приглашение вида:

Если все получилось, то отключаем возможность входа на сервер под пользователем root:

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

2. Установка БД MariaDB 10.3

Я не буду останавливаться на установке и первоначальной настройки MariaDB 10.3, т.к. у меня в блоге есть отдельная полная статья на эту тему, на данном сервере я все делал как в статье.

3. Установка и базовая настройка Nginx

Скачиваем и добавляем ключ Nginx Inc. на нашу систему:

Если нужно установить Nginx из ветки Stable, то выполняем:

Если нужно установить Nginx из ветки Mainline, то выполняем:

Обновляем список пакетов:

Устанавливаем Nginx и OpenSSL (опционально):

Проверим открытые порты:

Теперь займемся базовой настройкой Nginx.

Создадим директорию для хранения SSL сертификатов и DH-ключей, а также создаем файл с параметрами для DHE-шифров:

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

Создадим директории для хранения настроек Web-сайтов:

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

Скачать уже готовый файл для Nginx версии 1.13.x (1.15.x) и выше Вы можете командой:

После того, как мы сохранили наш новый файл настроек nginx.conf проверим конфигурацию Nginx:

Если ошибок нет, то выполняем (это заставит Nginx перечитать конфигурацию):

Меняем системные лимиты на кол.открытых файлов.

Т.к. мы указали в nginx.conf параметр worker_rlimit_nofile = 10000, то будем исходить из него.

Традиционно во всех статьях в Интернет все меняют лимиты через редактирование файла /etc/security/limits.conf, но это неправильно, т.к. для Debian 8 и Debian 9 этот файл не работает.

В Debian 8 и Debian 9 используется система инициализации systemd и поэтому лимиты на максимальное количество открытых файлов нужно настроить для systemd, для этого выплняем:

Теперь проверим лимиты, для этого смотрим строку «Max open files» в выводе:

Все отлично! Nginx работает, лимит открытых файлов мы поменяли.

4. Установка и базовая настройка PHP 7.0 и PHP-FPM

Установим все необходимые пакеты:

Отредактируем некоторые настройки PHP (cli):

Отредактируем некоторые настройки PHP (fpm):

Мы установили следующие базовые настройки для php (cli):

И установили базовые настройки для php (fpm), которые будут применяться для всех php-fpm пулов по умолчанию:

Вы можете дописать необходимые Вам настройки.

5. Создание и настройка площадки для сайта

Далее следовало бы написать огромную кучу команд для создания отдельного пользователя и группы для работы отдельного пула php-fpm от имени этого пользователя, создания php-fpm пула с минимумом настроек, создания иерархии каталогов для размещения сайта, выставления правильных прав на эти каталоги, настройка файла конфигурации нашего сайта для Nginx, создания файла для ротации логов Nginx и т.д.
Но для автоматизации всей этой рутины я написал 2 простых скрипта на bash, они открыты и размещены у меня на github.com

Скачиваем мои скрипты и распаковываем:

Теперь создадим все необходимое для хостинга сайта mysite.ru (у Вас будет другой домен):

Результат работы скрипта:

Что делает этот скрипт ?

Он выполняет вот такие команды на основе введенных данных и файла настройки /etc/nginx/settings.conf:

Как видите, скрипт делает довольно много работы, а главное делает он ее с предварительной проверкой многих параметров системы. А после выполнения практический каждой команды он проверяет результат ее выполнения и если что-то пойдет не так, то выполнение будет остановлено.
Именно из-за необходимости выполнения большого числа рутиных команд я и написал скрипт автоматизации nginx-create-vhost.sh

Скрипт ./nginx-create-vhost.sh создает следующую иерархию каталогов для размещения web-сайта:

Все файлы конфигурации Nginx будут создаваться в каталоге /etc/nginx/sites-available
Все активные сайты активируются путем создания симлинка в каталоге /etc/nginx/sites-enabled на соответствующий файл в /etc/nginx/sites-available
Все файлы настроек пулов php-fpm для Debian 9 будут создаваться в каталоге /etc/php/7.0/fpm/pool.d, для Debian 8 или Oracle Linux каталоги будут другие.
Все файлы правил ротации логов будут создаваться в каталоге /etc/logrotate.d

Ниже представлен типовой файл настроек Nginx (/etc/nginx/sites-available/mysite.ru.vhost)
Файлы называются по имени сайта с добавлением расширения vhost.
Вы можете изменить шаблон файла template/nginx_virtual_host.template на основе которого создается конфигурация vhost.

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

Например если у Вас сайт на WordPress, то файл может принять такой вид (привожу только часть блоков location):

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

Ниже представлен типовой файл настроек пула php-fpm (/etc/php/7.0/fpm/pool.d/web1.conf)
Файлы пула называются по логину создаваемого пользователя от имени которого данный пул будет работать.
Вы можете изменить файл шаблона template/php_fpm.conf.template на основе которого создаются настройки пула php-fpm.

Вы можете добавлять в этот файл уникальные для каждого сайта настройки php, например увеличим лимит памяти (memory_limit) для сайта, для этого добавим в файл /etc/php/7.0/fpm/pool.d/web1.conf настройку

Проверим корректность настроек и перезапустим php-fpm (для Debian 9):

Так же в комплекте со скриптом создания типовой хостинговой площадки (nginx-create-vhost.sh) идет скрипт ее удаления — nginx-remove-vhost.sh
Скрипту удаления площадки (nginx-remove-vhost.sh) нужно указать чуть больше настроек (нужно указать имя сайта, логин пользователя и имя группы), например:

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

Удалим каталог сайта, все настройки php-fpm, nginx, logrotate, а так же пользователя и группу с правами которой работал php-fpm:

ВНИМАНИЕ! Скрипт nginx-remove-vhost.sh удаляет все настройки созданные скриптом nginx-create-vhost.sh включая каталог с сайтом, логами и т.п., он не спросит подтверждения, он удалит тот каталог в /var/www что Вы укажите в опции -d и удалит пользователя и группу указанные в опциях -u и -g

6. Расширенная настройка Nginx

Почему я выделил эти настройки в отдельный пункт и что сюда входит ?

При настройке работы Nginx многие администраторы не уделяют должного внимания таким вещам как порядок обработки запросов web-сервером Nginx и правильная настройка default_server. В результате когда у Вас на сервере размещается несколько сайтов и Вы случайно заходите на сайт не по доменному имени, а например по IP адресу Вашего web-сервера и получает страницу «Welcome to Nginx» или еще хуже того — страницу случайного сайта, расположенного на Вашем сервере.

Чтобы этого избежать нужно настроить default_server на Nginx — это тот виртуальный сервер, который Nginx будет использовать для обработки HTTP-запросов в поле Host которых указан сервер не подходящий под Ваши существующие настройки или отсутствующий у Вас в настройках в принципе.

Например, у вашего сервера IP адрес 194.10.12.13 (для примера), для сайтов mysite1.ru, mysite2.ru и mysite3.ru в качестве A-записи указан Ваш IP адрес 194.10.12.13. Для сайтов mysite1.ru и mysite2.ru у Вас создан виртуальный сервер Nginx (есть конфиг), а вот для mysite3.ru не создан виртуальный сервер. Тогда если Вы откроете в браузере mysite3.ru, то получите либо страницу «Welcome to Nginx», либо откроется первый из сайтов расположенных на Вашем сервере (первый, это тот чей виртуальный сервер будет первым в списке на обработку запросов у Nginx).

Чтобы этого избежать нужно создать виртуальный сервер по умолчанию, который будет обрабатывать все неизвестные запросы, как правило обрабатывать эти запросы не нужно, т.к. это создаст дополнительную нагрузку на Ваш web-сервер, правильнее всего все эти соединения закрывать. Для этого разработчики Nginx придумали специальный код 444 (его нет в стандарте HTTP), который закрывает соединение.

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

Сохраняем это в файл /etc/nginx/conf.d/fallback.conf, правим под себя IP адрес вашего сервера.
Чтобы Nginx подключил конфигурацию из файла /etc/nginx/conf.d/fallback.conf нужно чтобы каталог /etc/nginx/conf.d был определен в директиве include в файле /etc/nginx/nginx.conf, примерно так:

Данный fallback.conf определяет default_server как для соединений по 80 порту (HTTP), так и для соединений по порту 443 (HTTPS). Для обработки HTTPS соединений нам нужно создать минимальный самоподписной сертификат, он будет нужен лишь для того, чтобы браузер на этапе установки TLS-соединения (Handshake) попытался все таки его установить, хоть и с выводом ошибки, что сертификат самоподписной, ну а далее уже на этапе HTTP соединение будет закрыто самим Nginx. Если кому-то интересно почитать как работает TLS, то я рекомендую статью Александра Венедюхина, там много интересного.

Создаем простой самоподписной сертификат (194.XX.XX.XX замените на свой IP):

После этого проверяем конфигурацию Nginx и перезагружаем ее:

Теперь пробуем открыть сервер по IP адресу:
http://194.XX.XX.XX
https://194.XX.XX.XX
http://mysite3.ru
https://mysite3.ru
* Сайты mysite3.ru я взял для примера, у Вас конечно же будут свои сайты.
В браузере соединение по HTTP будет закрыто сразу, а по HTTPS к примеру Google Chrome скажет вначале, что у нас самоподписной сертификат (NET::ERR_CERT_AUTHORITY_INVALID), далее если принять сертификат и перейти на сайт, то соединение по HTTPS так же будет закрыто.

Можно попробовать с другого сервера установить соединение с помощью curl, например так:

Мы видим, что соединение сразу же закрывается — этого мы и хотели добиться.
Вместо кода 444 Вы можете написать в fallback.conf код 403 и тогда соединение будет открываться и возвращаться HTTP код 403, но лучше не доводить соединение до стадии открытия.

7. Установка и настройка phpMyAdmin

Для Web-разработчиков phpMyAdmin необходим как собственно и сам PHP, поэтому давайте установим и настроим его.

Во-первых давайте определимся по какому URL мы и web-разработчики будут заходить в phpMyAdmin.
Обычно для phpMyAdmin выделают отдельный поддомен, например phpmyadmin.mysite.ru, но у нас же на сервере будет куча сайтов и делать для каждого такого вида поддомен просто неудобно.
Давайте сделаем URL такого вида http://mysite.ru/phpmyadmin и при входе на него наш web-сервер будет делать 301 редирект на какой-то постоянный сервисный домен http://phpmyadmin.myorg.ru
Пусть сайт phpmyadmin.myorg.ru так же будет на этом сервер, для простоты настройки.

Воспользуемся моим скриптом nginx-create-vhost.sh для создания этой сервисной площадки:

Я опущу вывод процесса создания площадки, она успешно создастся, наш рабочий каталог для php-скриптов phpMyAdmin будет /var/www/phpmyadmin.myorg.ru/web

Теперь скачаем последнюю версию phpMyAdmin и развернем ее в каталоге /var/www/phpmyadmin.myorg.ru/web:

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

Далее настроим конфигурацию phpMyAdmin, для этого перейдите в браузер по адресу http://phpmyadmin.myorg.ru/setup/ и создайте файл конфигурации config.inc.php для вашей БД, в самом простом виде он выглядит так:

Параметр $cfg[‘blowfish_secret’] генерируется автоматически и очень важен для защиты.

После создания файла конфигурации Вы можете зайти на http://phpmyadmin.myorg.ru/ и авторизоваться введя данные пользователя MySQL.

Так же я настоятельно рекомендую настроить HTTPS для нашего поддомена phpmyadmin.myorg.ru, но эту тему я оставляю на Вашей совести. Про правильную настройку HTTPS на Nginx я расскажу в отдельной статье.

8. Установка и настройка Pure-FTPd

Теперь установим и настроим ftp-сервер Pure-FTPd.

В качестве базы хранения пользователей мы будем использовать локальную базу Pure-FTPd.
Для начала отключим авторизацию по системный учетным записям через подсистему PAM, для этого остановим Pure-FTPd и выполним ряд команд:

Настроим некоторые полезные опции Pure-FTPd:
1. Запретим анонимный вход,
2. Включим поддержку chroot, это значит, что пользователь будет ограничен своим домашним каталогом и не сможет перейти выше уровнем,
3. Включим расширенное ведение логов,
4. Оставим поддержку только IPv4,
5. Увеличим максимальное число клиентов до 100,
6. Разрешим отображение в директориях файлов начинающихся с точки,
7. Определим список пассивных портов,
8. Зададим кодировку по умолчанию,
9. Увеличим лимиты на количество отображаемых в директориях файлов и глубину вложенности,

Проверим, что демон pure-ftpd запустился:

Посмотрим список открытых портов:

Отлично, Pure-FTPd работает.

Теперь можно добавить виртуального пользователя (логин mysite):

В опции -u мы указали UID нашего виртуального пользователя, он должен соответствовать UID реального пользователя имеющего право на чтение и запись в домашний каталог.
В опции -g мы указывается GID нашего виртуального пользователя, он должен так же должен соответствовать GID реальной группы.
В опции -d мы указали домашний каталог нашего виртуального пользователя, он должен соответствовать корневому каталогу нашей площадки для сайта mysite.ru в которой располагаются каталог web, log, private и tmp.

При первом запуске данная команда создает базу пользователей, а после любых операций с пользователями — обновляет (не забывайте ее запускать каждый раз):

Чтобы избежать использования команды ‘pure-pw mkdb’ после каждого изменения данных я рекомендую использовать опцию ‘-m’ в командах модификации. Ниже Вы увидите ее в примерах.

Просмотрим список пользователей:

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

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

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

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

Для удаления пользователя mysite выполните:

Pure-FTPd пишет логи в файл /var/log/messages, поэтому для просмотра логов нужно отфильтровать их по слову pure-ftpd, например так:

Расширенный лог пишется в файл /var/log/pure-ftpd/transfer.log, в нем можно посмотреть кто, когда и какие операции выполнял после прохождения аутентификации. Сами попытки аутентификации (удачные и не удачные) нужно смотреть в файле /var/log/messages

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

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

9 комментариев

Доброго времени суток.

Спасибо за ваши статьи )

sed -i «s/,cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/» /etc/php/7.0/fpm/php.ini и другие можно сократить:

sed -i -e ‘s/,(/cgi.fix_pathinfo/)//1=0/’ /etc/php/7.0/fpm/php.ini

echo «vnoremap :w !xsel -b» >>

/.vimrc не работает.
echo ‘vnoremap :w !xsel -b’ >>

Да, все верно. Спасибо, исправил в статье. У меня там вообще была неправильная строка.

Ссылка «размещены у меня на github.com» не работает.

Спасибо, что написали. Ссылку исправил.

Выдает ошибку,всю голову сломал.
[email protected]:/home/linux-scripts-master/nginx# ./nginx-create-vhost.sh -d test.de
Detecting your OS Linux (x86_64)
Detecting Linux distrib Debian (SYSTEMD)
Detecting your php-fpm Found php-fpm7.0
Detecting nginx owner Found www-data
Error: In file /etc/nginx/settings.conf not found parameter NEXTWEBUSER.
Usage: ./nginx-create-vhost.sh [ -d domain_name -s site_directory -u user_name -g group_name]

-d sitename : Domain name, domain.com
-s sitedir : Site directory, /var/www/domain.com
-u username : User name, www-data
-g group : Group name, www-data
-h : Print this screen

Проверьте наличие файла /etc/nginx/settings.conf, его содержимое при создании первого хостингового домена должно быть примерно такое

SERVERIP=XX.XX.XX.XX
SERVERPORT=80
NEXTWEBUSER=web1
NEXTWEBGROUP=client1

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

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

Михаил добрый день!
Очень хорошо расписываете все шаги, интересно читать!
Ждем пока доберетесь до — Про правильную настройку HTTPS на Nginx я расскажу в отдельной статье.
Спасибо!

Как с нуля настроить свой хостинг для сайтов на Linux CentOS 7

Обращаю особое внимание, что в данной инструкции идет речь о создании виртуального хостинга — веб-сервера для размещения сайтов изолированных друг от друга.

В качестве примера используются команды на Linux CentOS. Однако, справедливости ради, нужно заметить, что данными методами без проблем удастся настроить любой Linux и (с небольшими правками) FreeBSD.

  • Частный хостинг для небольшого количества клиентов.
  • Размещение сайтов компании.
  • Тестовый сервер для веб-мастера.
  • Установка корпоративных порталов.
  • Домашний сервер для компьютерных игр.

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

Содержание

Как выбрать сервер для хостинга

Железо

Основной потребляемый ресурс виртуального хостинга — объем жесткого диска. Небольшие сайты-визитки могут иметь размер менее 100 Мб. Но Интернет-магазины или фото- видео-порталы требуют больших ресурсов. В зависимости от целей, необходимо выделить от 50 Гб до 4 Тб. Больше или меньше для наших целей нецелесообразно.

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

Оперативной памяти также требуется небольшое количество

Отзывы

Фатина
giodeatosing1988
Лучезар
darencast
enitcomli

Написать отзыв

Success! Your message has been sent.