Настройка хостинга на RU-Center () — KPlus dot blog, как обновить php на хостинге.

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

Tarampampam в Администририрование | 22 января 2016

Tarampampam

Опубликовано

22 января 2016

Tarampampam в Администририрование | 22 января 2016

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

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

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

Вопрос: При регистрации домена может сразу встать вопрос — делегировать домен на руцентр или, например, сразу же на 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@your_domain.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 строки перед секцией <VirtualHost *:8080> : ServerTokens Prod и ServerSignature Off , которые запрещают вывод сигнатур сервера. Если тебе потребуется ещё что-то настраивать у Apache — то делай это в этом файле.

Настройка php

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

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

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

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

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

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

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

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

/backups с текущим бэкапом всех данных. Для автоматизации в «Планировщик заданий» добавь задание вида /home/your_domain/scripts/backup.sh с запуском 1 раз в полночь, например.

На этом в принципе — всё. Если будут вопросы — можешь смело задать их в комментариях.

Tarampampam

Опубликовано

22 января 2016

Отменить ответ

Делаю все, как Вы сказали, но при попытке загрузки блога выдает:

Привет! Извини за поздний ответ.

Если проблема уже решена то, пожалуйста, расскажи как именно ты это сделал. Если же нет — то думаю есть смысл проверить наличие строк в файле