Ни думал, ни гадал, что когда-нибудь возьмусь за такое занятие. Во-первых, у меня не было идеи, о чём должен быть сайт. Во-вторых, я никогда не делал сайты, и у меня нет соответствующих навыков. Но тут у друга появилась идея для сайта, которая мне понравилась. А у меня начало появляться свободное время, которое нужно было использовать. Начинать что-то новое я никогда не боялся, поэтому решил начать. Тем более, что общие навыки программирования у меня есть. Сразу скажу: Идею сайта пока рассказывать не буду, не просите! Даже если просто поржать . Да и дело пока не в идее, а в приобретении навыков веб-программирования.
Честно говоря, я уже начал делать сайт, и есть кое-какие наработки. Можно было, конечно, не создавать эту тему, а просто продолжать делать своё дело. Но я человек ленивый, и если не с кем пообщаться на эту тему, то работоспособность у меня почему-то снижается. А если на форуме в теме будет с кем поговорить, то это дело должно стать более захватывающим для меня и пойти веселее . Да и ответственность появится какая-то перед участниками темы, уже так просто не бросишь, будешь стараться доводить дело до конца. Плюс, мне поначалу нужна какая-то записная книжка, в которой будут множественные технические подробности, как именно я сделал то-то и то-то, и чтобы эта информация была доступна мне как с работы, так и из офиса, ибо она может понадобиться повторно. А если эта информация будет доступна ещё и другим людям, то хуже от этого точно не будет никому. Тем более, что на форуме могут найтись участники, способные подсказать, направить, дать совет или ещё как-то помочь мне в моём начинании, что будет для меня весьма кстати. Вот поэтому я и решил создать данную тему.

Обычно я веду беседы совсем на другие темы, не связанные с техникой, что может стать неожиданностью для участников, знакомых со мной на форуме. В связи с этим я считаю необходимым сделать следующее предупреждение.
ПРЕДУПРЕЖДЕНИЕ:
В данной теме предполагается углубленное рассмотрение информационно-алгоритмических подробностей с использованием сложных и неоднозначных для обычных людей понятий, применяемых в этой области. Это способно вызвать у неподготовленного читателя состояние трудно-идентифицируемой дезориентации, во избежание чего, во время прочтения данной темы рекомендуется не пытаться осознать сразу всё, что написано, а также рекомендуется делать перерывы и пить больше жидкости. За психическое состояние читателей автор ответственности не несёт.

Продолжение следует...

Не впадая в
состояние трудно-идентифицируемой дезориентации,
хочется спросить: а зачем там что-то программировать?
Сейчас сатйы делаются за 6 минут в ... просто ворде - положили картинку, надпись, более хитрые - сначала таблицу, в левую часть одну картинку, в правую другую, в середине одна надпись, ниже другая....
Далее "Сохранить как Html", отправить на любой бесплатный хостинг - и вуаля...

Конечно, это касается сайта типа визитки или "Я, Вася Ппукин и моя собака" - на котором лежат фото Васи Пупкина в Париже около Эйфелевой, в Берлине около Браденбургских и в Риме около Колизея, а также на даче со своей собакой.

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

Спиртосодержащей?)


Шаблонов полно. Под себя просто некоторые скрипты прописать (на той же Яве), для удобства )

Введение.

Как выяснилось, чтобы делать сайты, необходимо знать:
HTML, CSS, PHP, MySQL, JavaScript
Ничего из этого, я, разумеется, не знал, а значит, нужно было всё это учить. Учить сразу всё было как-то неудобно, и нужно было выбрать что-то одно. Начал разбираться... Оказалось, на начальном этапе можно вполне обойтись без JavaScript. Так, уже легче. Что такое MySQL? Это система управления базами данных (СУБД). Она нужна для сайта? Да, для хорошего сайта нужна. Но в принципе, сайт может работать и без неё, используя только лишь файлы. Отлично! Оставляем MySQL на потом. Что такое PHP? Это язык программирования, предназначенный для предварительной подготовки веб-страниц сайта. Ура, наконец-то началось что-то про веб-страницы! Предварительная подготовка это хорошо, но сами-то веб-страницы из чего делаются? Оказалось, они делаются из инструкций на языках HTML и CSS. На HTML пишется разметка страниц (что будет выше, что ниже, что внутри, что снаружи, какой текст где будет написан и т.д.), а на CSS пишется стиль страницы (какого цвета будут элементы, какого размера, с какими рамочками, каким шрифтом написаны и т.д.). Это та информация, которую принимает наш браузер с сайта, и из чего рисует для нас красивую картинку на экране. Отлично! С этого и стоит начинать.
Начал изучать HTML + CSS. Но одна голая теория без практики мало что даёт, и нужно сразу пробовать писать свои собственные поделки. Поделки, то есть, крохотные сайты. А сайты, как известно, должны находиться на серверах в Интернете. Вопрос: Где взять сервер? Выяснилось, что существуют так называемые хостеры, предоставляющие так называемый хостинг с возможностью так называемого удалённого доступа. О как! Ну, то есть, существуют организации, у которых есть серверы, и они сдают их в аренду. При этом, мне не обязательно ехать к ним, чтобы заключить договор, и что очень важно, не обязательно сидеть рядом с этим сервером, чтобы им управлять. Договор можно заключить через Интернет, это понятно, это уже давно применяется. Но как можно управлять сервером через Интернет? Оказывается, и это возможно. Сначала ты просто регистрируешься на сайте организации, оплачиваешь электронными средствами платежа, и вуаля — перед тобой целая панель управления твоим сервером. Уау! Всё-таки, в удивительные времена мы с вами живём, ребята. Я покупаю сервер, который в глаза не видел, за виртуальные деньги, которые вообще нельзя даже в руках подержать, в результате чего, с помощью картинок на экране, я управляю этим сервером, который находится где-то далеко. При этом мне совсем не важно, где именно находится сервер, который я купил! Это что вообще такое? Сказка? Фантастика?

Продолжение следует...

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

Можно и такой, только но не злоупотребляйте там


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

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

http://humanclub.ru/1s/INDEX.htm

Cтраниц там несколько десятков
Даже помнится написал рукоаодство для ноаичков, как делать сайт.
На сегодня оно устарело, так как и CSS, и базы данных теперь в моде, а я ими не заморачивался - не нужны были.

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

Ну так вот...
Стал я пользоваться этой панелью управления сервером. Серверы для сайтов называют "хостинг", приучаюсь использовать модные словечки Как оказалось, хостинги бывают разные, например:
1) Виртуальный хостинг
2) VPS
3) Выделенный сервер
Самый простой это первый, виртуальный хостинг, с панелью управления, который я и взял. VPS — это уже сложнее, там нет панели управления, и я даже думать о нём пока не стал, как и о выделенном сервере, который по сути такой же сложный, только мощнее и дороже. Начал я пробовать загружать на свой сервер новые написанные мною файлики, из которых и будет состоять сайт.
Да, ещё я забыл сказать, что перед этим я приобрёл себе домен. Домен — это имя и одновременно адрес сайта в Интернете. Например, "tochek.net" — это домен, который был куплен, по всей видимости, админом нашего форума. Этот домен является как именем, так и адресом, который мы набираем в адресной строке браузера. Так вот, для своего сайта мне нужно было придумать такое имя, а затем зарегистрировать его у компании-регистратора доменных имён. Причём, имя нужно придумывать как можно более короткое и как можно более запоминающееся. Маркетинг, знаете ли Но придумать такое имя оказалось непросто, т.к. все короткие и запоминающиеся имена уже давно заняты, и с каждым годом становится всё труднее и труднее такое имя придумать. Несколько дней мы с другом придумывали домен. Я даже написал небольшую программу для генерации случайных имён, состоящих из 5 английских букв. Но выбрать среди них что-то подходящее всё равно не удалось. Красивые имена были действительно заняты, а некрасивые были некрасивыми. Но, о чудо, однажды по дороге с работы мне пришло в голову имя из шести букв, которое сразу понравилось как мне, так и другу, и я сразу его зарегистрировал. Называть его я тоже не буду, это пока секрет. Но надеюсь, придёт время, когда оно перестанет быть секретом.
Так вот, этот зарегистрированный домен я "прикрепил" к своему серверу, чтобы Интернет знал, на каком сервере находится сайт под этим именем. И получалось, что я загружаю файлы на сервер, потом набираю в браузере имя сайта, и вуаля, на экране появляется мой сайт. Затем я меняю что-то в файлах у себя на компьютере, скидываю на сервер новые версии этих файлов, обновляю страницу в браузере, и на экране появляется новая версия сайта. Класс! Просто чудеса!

Продолжение следует...

Это я описываю прошлое, что уже сделал, и мне нужно догнать сегодняшний день. Поэтому приступим...

Итак, используя виртуальный хостинг, я начал тренироваться писать на HTML + CSS. Как выяснилось чуть позже, это языки довольно старенькие, и самое главное, они изначально предназначены для разметки текста. И если я ставлю задачу использовать на своём сайте графику, то с этим у меня начинаются сложности. Например, поначалу я никак не мог сообразить, как сделать блоки на странице. Вернее, блоки у меня получались, но потом я начинал делать вложенные блоки, и у меня всё начинало съезжать то в одну сторону, то в другую, и отступы были разного размера, в общем, непредсказуемо всё как-то было. Но через какое-то время я всё-таки выработал свой стиль написания, и блоки стали получаться ровненькие с такими размерами отступов, как мне было нужно. К языку CSS у меня вообще сложилось особое отношение. Там используются понятия "классы", "наследование", "родитель", "потомок". То есть, понятия из ООП (объектно-ориентированного программирования), которое я люблю использовать. Но почему-то одни свойства объектов наследуются потомками, а другие — нет. И это считается нормальным, в сети есть целые таблицы этих свойств, где для каждого указано, наследуется оно или нет. Это что за подход вообще? Почему я должен помнить для каждого свойства его наследуемость. У меня голова что, мусорный ящик? В общем, для графического дизайна на сайте языки HTML и CSS приспособлены плохо, приходится сильно изворачиваться, чтобы добиться нужного результата. Но пока альтернативы этому, говорят, нет, поэтому придётся изворачиваться. Хотя, пишут, что языки эти развиваются, выходят их новые версии с новыми возможностями, в удобство которых остаётся только верить. Но сейчас я в это углубляться не буду, т.к. пока мне достаточно и того, что имею.

Разобрался я более-менее в основе HTML + CSS. Теперь можно было приступать к изучению PHP. Данный язык оказался очень похож на язык C++, поэтому особых сложностей с его изучением у меня не возникло. Сложность возникла поначалу в понимании того, как организовать динамику на сайте. Выяснилось, что в динамике обязательно принимает участие база данных (БД). То есть, различные данные хранятся в БД, а PHP занимается тем, что берёт эти данные из БД, вставляет их в шаблоны страничек, и получаются странички, заполненные нужными данными. Точно так же и в обратную сторону PHP берёт данные со странички (например, пользователь ввёл своё имя) и сохраняет их в БД (базе данных) для дальнейшего использования. Ну круто, чё! Очень простая и понятная система. Только есть одно "но". У базы данных свой язык, и она требует, чтобы все люди и программы общались с ней только на её языке. Твою жеш мать! Это ведь ещё один язык надо учить — SQL. Начал читать документацию по MySQL. На удивление обнаружил для себя, что язык этот вполне себе несложный. Более того, он даже красивый!
Прямо как песню спел! Я люблю этот язык!
Слава панели управления, базы данных на сервер устанавливаются легко, поэтому начало работы с БД не заставило себя долго ждать.

Продолжение следует...

В общем, начал я постепенно использовать эти инструменты одновременно: HTML, CSS, PHP, MySQL. Начал чувствовать себя настоящим веб-программистом! А между делом у нас возникла новая идея — написать программу для Windows, которую можно будет продавать. Написание такой программы — это не веб-программирование, поэтому я справился с этим легко, за 2 месяца первая версия программы была готова. Только для продажи программы нужен был небольшой сайт-визитка. Сделали быстренько сайт-визитку, рядом с сайтом сделали небольшой форум для поддержки клиентов. Форум я сделал на готовом бесплатном движке phpBBex, и это тоже не заняло много времени. Сделали рекламку для целевой аудитории, программу начали покупать. Сайт работал, форум работал, и всё это крутилось на обычном виртуальном хостинге, который меня устраивал. Но, как выяснилось позже, для более крупного проекта, а тем более связанного с электронными деньгами, такой хостинг не подходил. Причин было несколько. Во-первых, виртуальный хостинг не давал возможности защититься от спама. Спам — это когда кто-то посылает сайту много-много запросов, которые сайт не выдерживает, виснет, и становится недоступен для других пользователей. Вы, наверно, будете сильно удивлены, если я скажу, что данный форум также не защищён от спама. Причём, от простейшего спама, который может сделать любой пользователь. Например, в браузере Mozilla Firefox обновить страницу любого сайта можно нажатием на клавишу F5 на клавиатуре. Так вот, если на странице данного форума зажать и держать эту клавишу, то запросы на обновление страницы будут отправляться сайту часто-часто, сайт не выдержит, возникнет ошибка базы данных, и форум станет недоступен для всех:

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

Другая причина заключается в следующем. На сайте будут регистрироваться пользователи. У них будет личный кабинет, в котором будут находиться так называемые виртуальные ценности. Как, например, здесь на форуме у каждого из нас есть "монеты", которые мы получаем за сообщения. Думаю, никто не хочет, чтобы кто-то узнал Ваш пароль, зашёл в Ваш аккаунт и потратил все Ваши монеты. В данном случае, конечно, беда окажется невелика. Но в моём проекте подобные "монеты" будут связаны с реальными деньгами, и подобная ситуация там может иметь серьёзные последствия как для пользователя, так и для репутации сайта. К чему я всё это говорю — к тому, что все имена, пароли, явки и т.д. должны быть зашифрованы при передаче по сети. Чтобы ни один злоумышленник не смог их узнать. Естественно, эта мысль пришла в голову мне не первому в этом мире, и для такой шифровки уже давно есть хорошие средства. Самое распространённое из них называется SSL. Если для защиты сайта используется этот протокол, то мы с вами можем видеть это в браузере в самом начале адресной строки в виде замочка. Например, в браузере Mozilla Firefox это выглядит так:

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

Продолжение следует...

Но была ещё одна причина — это работа с базой данных. А именно, данный виртуальный хостинг во-первых, не давал возможности работать в базе данных MySQL с хранимыми процедурами, а во вторых, не давал возможности создавать в MySQL нескольких пользователей. Для одного аккаунта, видите ли, используется только один пользователь базы данных, а с хранимыми процедурами мы вообще запрещаем работать, говорили представители хостинга. Ну ништяк, чё сказать. Это, конечно же, сильно снижает уровень безопасности базы данных, ибо пароль этого единственного пользователя будет храниться в файлах на хостинге, а пользователь этот имеет право менять данные в таблицах базы. И если кто-то из сотрудников хостинга продаст этот пароль злоумышленникам, то кто-то сможет накручивать себе счётчики в нашей базе данных, и мы этого, скорее всего, не заметим, а значит, будем терять деньги. Но возникает вопрос: Что изменится, если в базе данных можно будет создать нескольких пользователей и если можно будет использовать хранимые процедуры? А вот что... Если мы в базе данных MySQL создаём пользователя с одним единственным правом "Запускать хранимые процедуры", то этот пользователь не сможет менять данные в таблицах базы и накручивать себе счётчики. Он сможет только запускать хранимые процедуры, а внутри каждой из них будет стоять ограничивающее условие, плюс, каждую операцию хранимая процедура будет записывать в историю операций, которая затем будет сравниваться с историей поступления денег, и эта накрутка будет обнаружена довольно быстро, после чего исправлена и приняты меры по обезвреживанию злоумышленника (баном адресов), а также изменён пароль этого пользователя базы. Полный же доступ к базе данных будет у другого пользователя, который не будет использоваться скриптами в основной работе, а значит, его пароль не будет храниться нигде на хостинге. Этот пользователь будет использоваться в администраторских целях, и использоваться удалённо. Удалённо, разумеется, с шифрованием данных. Например, с помощью того же самого SSL-сертификата. Или через туннель SSH, о котором более подробно я расскажу ниже. Такая схема намного повышает безопасность данных в проекте, связанном с деньгами или другой информацией, требующей строгого учёта. Конечно, стопроцентной защиты не бывает в принципе, но для сервера, который физически находится "не у меня", это неплохая защита данных.

Всё это, конечно, хорошо. Но оказывается, на виртуальном хостинге реализовать такое невозможно. Общение с другими хостерами дало мне понять, что для моих требований нужно брать VPS или выделенный сервер. Тем более, что цены на VPS сейчас невысокие — за 350 рублей в месяц можно взять вполне неплохой вариант. Вот там-то у меня и будет полная свобода действий, говорили они. И всё это тоже, конечно, хорошо. Но в нашем мире существует один закон: В придачу к свободе всегда идёт ответственность за ошибки. Тебе дали свободу, ты сделал ошибку — отвечай! А чтобы не совершать ошибки, нужны знания. Вывод: чтобы пользоваться свободой, нужны знания. Это было философское отступление, а для моей ситуации это означает следующее. VPS — это услуга, дающая полный доступ к операционной системе. В данном случае это операционная система Linux, которая вообще не похожа на Windows, и этой операционной системой нужно уметь правильно пользоваться. Чтобы вы понимали, о чём идёт речь, я покажу вам скриншот экрана сервера, на котором мне придётся работать:



То есть, никаких окошек, никакой мышки, никаких браузеров, скайпов и других прелестей современной компьютерной жизни человека. А только лишь чёрная, холодная, бездушная командная строка, которая ждёт от меня с клавиатуры только те команды, которые допустимы. И упаси меня Бог ошибиться в них хоть на один символ! Вот в каких условиях придётся работать мне, если я возьму VPS! При этом, речь здесь идёт уже не об управлении сайтом, а об управлении всем сервером. Мало того, что на одном сервере может находиться несколько сайтов, и корректную работу с ними нужно как-то организовывать, так кроме этого, на сервере должно постоянно работать ещё и множество программ, без которых ни один сайт вообще работать не будет. Эти программы нужно уметь правильно установить, потом правильно настроить и затем правильно ими пользоваться. И всё это нужно делать вот в таком вот неудобном текстовом режиме. При этом одна маленькая ошибка может остановить работу сразу всех сайтов, и это как раз та ответственность, которую я получу в придачу к той самой хвалёной свободе. И чтобы этой свободой пользоваться, мне придётся добыть немалое количество знаний об управлении сервером под операционной системой Linux, что займёт немало времени. Все эти мысли были для меня очень страшны, и какое-то время они останавливали меня перед шагом брать VPS. Но однажды я всё-таки собрался с силами и сделал это!

Продолжение следует...

Итак, за 350 рублей в месяц я взял VPS. Оказалось, у этой услуги тоже есть панель управления, в которой всего несколько функций, таких как: "Настройка DNS", "Привязка доменов", "Статистика используемых ресурсов", "VNC-консоль", "Переустановка операционной системы", и в общем-то, всё. Остальные функции придётся выполнять самому вручную через текстовую консоль. В разделе "ДНС" всё было уже настроено. Домены привязать один раз, это легко, я их просто добавил. Статистику использования процессора, памяти, диска и сети наблюдать потом во время работы сайтов будет очень удобно. VNC-консоль это как раз тот чёрный жуткий экран, с которым мне придётся подружиться. А переустановка операционной системы (ОС) это ещё более удобно — не нужно устанавливать ОС самому, вводить при этом разные параметры, тратить на это своё время. Просто выбрал название ОС, нажал кнопку "Установить", и через 5-7 минут ОС установлена. Классно. Пароль пользователя root при этом высылается системой автоматически на почту, указанную в панели управления. Я захожу в VNC-консоль, ввожу логин и пароль, и уже можно работать.
Но возникает вопрос: Какую ОС лучше установить?
В списке операционных систем имеются:
Что же выбрать? Придётся изучать данный вопрос... В процессе изучения выяснилось, что разработчиками чаще всего обновляется Ubuntu, у неё лучше поддержка, её сейчас используют больше всего, особенно начинающие системные администраторы. Это я что-ли ещё и системный администратор теперь, получается? Ну надо же. Короче говоря, мой выбор был очевиден — это Ubuntu 16.04 LTS. Слово LTS означает "Long Term Support", то есть, данная версия будет поддерживаться в течении 5 лет, а именно до 2021 года. Меня это устраивает, устанавливаю... готово. Но что делать дальше? Куда и как закачивать файлы с моим сайтом?

Продолжение следует...

Прежде чем закачивать файлы, выяснилось, что в чёрную консоль можно зайти не только через личный кабинет на сайте хостера, но и с помощью программ-клиентов, работающих по протоколу SSH (не путать с SSL, это разные вещи). Самой распространённой из них для Windows является программа PuTTY. Устанавливаем её, вписываем в ней IP-адрес нашего сервера и порт 22 (он уже вписан):


Нажимаем кнопку "Open", и видим, что появилось новое окно:


В котором написано "login as:", значит, нужно вводить логин. А какой у меня логин? Так, нам же было письмо на электронку, смотрим письмо:
Логин (SSH): root
Пароль: irezabakuv
Вводим, появляется какой-то текст и ниже, собственно, приглашение системы:

Это сервер ждёт от меня команды. Кстати, слово "serve" в переводе с английского означает "служить", а "server" получается "служитель"... не-не, "СЛУГА", точно! То есть, передо мной на экране сейчас находится слуга, который послушно ждёт от меня приказаний. А я хозяин! Like a BOSS! Ничего так ощущение, приятненькое. Осталось только научиться командовать.

Продолжение следует...

Ты потом покажешь, что получилось?

Обязательно!

Итак, продолжаем...

Значит, нам нужно было закачать наши файлы на хостинг. Для передачи файлов по сети традиционно используют протокол ftp. Это означает, что с одного конца (на моём компьютере) одна программа ftp отправляет файлы, а на другом конце (на сервере) другая программа ftp принимает эти файлы. То есть, эта программа должна работать на обоих концах. На моём компьютере в качестве такой программы я могу использовать, например, FileZilla. Но с файлами мне больше нравится работать в программе Total Commander, и выяснилось, что в ней тоже есть поддержка работы с протоколом ftp. Ясно, с одного конца программа есть. Теперь другой конец, сервер. Выясняется, что на сервере для этого можно использовать программу vsftpd или же программу proftp, по желанию на выбор. Я выбрал первую попавшуюся мне на глаза — vsftpd. Устанавливается она следующим образом... В консоли вводятся буквы:
, где:
apt — менеджер установки,
install — команда "установить",
vsftpd — название программы, которую надо установить.
Далее система просит подтвердить установку, мы подтверждаем нажатием на клавиатуре "y" и затем "Enter", что означает "Yes! Погнали!". После этого программа устанавливается, и с ней можно работать. Однако, при дальнейшем изучении вопроса закачки файлов выяснилось, что файлы передаются по сети тоже в открытом виде, без шифрования. И все данные, которые в них содержатся, могут быть доступны злоумышленникам. Далее выяснилось, что шифрование в программе можно настроить, и для этого нужно использовать сертификат SSL. Всё это можно сделать, и файлы будут шифроваться, но ещё чуть позже выяснилось, что для ЛЮБОГО доступа к серверу можно использовать так называемый SSH-туннель. Этот SSH-туннель представляет собой защищённое (зашифрованное) соединение, внутри которого можно передавать любую информацию. То есть, между моим компьютером и сервером, как бы, прокладывается ТРУБА, которую никто не может "прогрызть" и увидеть, что я там передаю. А передавать можно что угодно, например, файлы закачивать (sftp), или с базой данных общаться на нашем красивом языке (MySQL), или даже использовать наш сервер как прокси (http) и заходить на сайты с другого IP. То есть, любой протокол можно впихнуть в эту трубу, в этот SSH-туннель. Для меня это было вообще открытие, такая классная вещь! Соответственно, пропадает надобность в установке на сервер программы vsftpd и создавать для неё сертификат. Меньше разных программ на сервере — меньше проблем и выше безопасность. Один туннель для всего — это очень удобно. И на моё счастье, оказалось, что программа PuTTY как раз умеет делать такие туннели. И вот как это делается...

В списке слева выбираем Connection -> SSH -> Tunnels. В поле Source port вводим любой номер порта выше 1024 и ниже 65535, например, 44444. Чуть ниже выбираем пункт Dynamic, как показано на скрине:

Затем переходим в основную вкладку Session. Вводим как обычно адрес сервера, порт и название нашего подключения, например, SSH-Tunnel:

И нажимаем кнопку Save, чтобы у нас появилась сохранённая запись, и нам не приходилось каждый раз заново всё это вводить:

Теперь после двойного клика на эту запись у нас появится обычная уже известная нам чёрная консоль. Но особенность её будет в том, что после ввода логина и пароля, кроме возможности вводить команды, одновременно будет работать SSH-туннель, через который можно передавать любую информацию. Это будет происходить через указанный нами порт с номером 44444. Например, чтобы пустить через этот туннель http-трафик браузера Mozilla Firefox, в настройках браузера (Дополнительные -> Сеть -> Соединение -> [Настроить]) нужно указать:

И нажать кнопку ОК. После этого, если зайти, например, на yandex.ru и ввести там "ip", то Яндекс покажет, с какого IP-адреса мы заходим на сайты. В данном случае Яндекс покажет нам IP-адрес сервера, а не нашего домашнего компьютера. И если сервер, например, находится не в России, то эту особенность можно использовать для беспрепятственного входа на запрещённые в России сайты, например, на rutracker.org.
И это только один пример, как можно использовать SSH-туннель. Ещё раз повторю, что через туннель можно передавать практически любую информацию, и в дальнейшем я ещё буду говорить об этом.

Продолжение следует...

Чтобы не делать коту больно, решил продолжить сразу...

Прокси это конечно хорошо, но нам нужно было залить файлы на сервер. Для этого мы собирались использовать SSH-туннель, и желательно, чтобы была возможность пользоваться программой Total Commander. Берём поисковую систему, вводим туда соответствующий запрос, и находим ответ. Оказывается, для Тотал Командера есть плагин wfx_sftp, который можно установить, и он будет работать совместно с программой PuTTY. Этот плагин можно скачать, например, отсюда. Установка плагина заключается в следующем:
1. Скачиваем архив, распаковываем его.
2. В настройках программы (Конфигурация -> Настройка -> Плагины) под пунктом "Плагины файловой системы (.WFX)" нажимаем кнопку "Настройка":

3. Появляется окно, в котором нужно нажать кнопку "Добавить", затем найти распакованный плагин и выбрать оттуда файл plugin_sftp.wfx (или файл plugin_sftp.wfx64 в зависимости от того, 32- или 64-битная версия Total Commander у Вас установлена). В результате, в списке должна появиться новая строка, как на скрине:

4. Нажимаете кнопку ОК, затем закрываете основное окно настроек, и всё, плагин установлен.

Теперь как пользоваться:
В Тотал Командере нажимаете кнопку "Сеть / FS-плагины" и выбираете пункт "Secure FTP Connections":

После чего появится список подключений, которые Вы настроили в программе PuTTY, одно из которых мы назвали SSH-Tunnel:

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

Продолжение следует...

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

На данный момент я научился:
— подключаться к консоли через SSH,
— делать SSH-туннель к серверу,
— настраивать Total Commander на работу с файлами сервера через SSH-туннель.
Но этого, конечно же, мало. Если закачать файлы на сервер, то ничего особенного не произойдёт, и сайт не начнёт работать автоматически. Чтобы на сервере начал работать хоть какой-нибудь сайт, нужно установить программу веб-сервер. Но прежде чем начать эту тему, и чтобы закончить про SSH, я расскажу о повышении безопасности при работе через SSH.
Когда я захожу в консоль, то ввожу логин root и пароль, который пришёл мне по почте.
Во-первых, этот пароль нужно сразу сменить, т.к. неизвестно, пришёл он ко мне через защищённое соединение, или нет. Делается это следующей командой в консоли:
, после чего система предложит ввести новый пароль, два раза, чтобы избежать ошибки.
Так, пароль сменили. Но и это не гарантирует вероятность взлома злоумышленниками. Дело в том, что протокол SSH по умолчанию использует порт с номером 22, все компьютерщики это знают, в том числе и хакеры. Эти хакеры создают программы-боты, которые буквально ЛОМЯТСЯ на чужие серверы, т.е. многократно и бесконечно пытаются зайти на серверы через SSH, используя порт 22, логин root и тупо перебирая различные варианты пароля. Вероятность угадывания пароля, конечно, невелика, но если через пару лет это произойдёт, то для коммерческого проекта ущерб может быть просто убийственным, поэтому этот вариант нужно считать уязвимостью, и обязательно его исключать. Для этого мы можем поменять номер порта со значения 22 на любое другое в пределах от 1024 до 65535. Делается это просто...
В файле /etc/ssh/sshd_config есть строка:
, в которой значение 22 нужно заменить на новое. После чего сохранить файл и перезапустить службу SSH с помощью ввода команды:
Всё, теперь на нашем сервере SSH работает не на 22-м порту, а на другом, выбранном нами. Это сразу снизит количество попыток взлома от самых тупых программ-ботов. Однако, боты поумнее могут определить, какие порты у сервера открыты, и всё равно найдут номер нашего порта. В этом можно не сомневаться, т.к. есть даже сайты, на которых можно быстро узнать, какие порты открыты на моём сервере. Например, вот на этом сайте http://www.t1shopper.com/tools/port-scan/ можно выбрать диапазон портов, просканировать свой сервер, и найти там порт, который отвечает. Поэтому одним только изменением номера порта здесь не обойтись. Что ещё мы можем изменить? Логин! То есть, нужно создать новую учётную запись пользователя с другим именем, которое никто не знает. Например, с именем kamikadze9705. Для этого вводим в консоли следующую команду:
, после чего система предложит ввести пароль, два раза, как обычно, а также предложит ввести полное имя, номер комнаты, рабочий телефон, домашний телефон и "другое". Всё это, кроме пароля, можно не заполнять, оставлять пустым и просто нажимать Enter. Таким образом будет создана новая учётная запись пользователя kamikadze9705, под которым теперь можно зайти через SSH. Но изначально новый пользователь лишён возможности выполнять администрирование сервера, и чтобы дать ему такую возможность, нужно написать в консоли:
Это означает, что пользователя kamikadze9705 нужно добавить в группу sudo, которая как раз и даёт право действовать от имени администратора. Всё, теперь наш новый пользователь стал полноценным, и можно пробовать зайти им на сервер через программу PuTTY. Только нужно не забыть, что мы сменили 22-й номер порта на новый, и изменить его в настройках программы, иначе зайти не получится. Меняем порт и заходим с новым логином и паролем. А теперь внимание! Любому другому пользователю, кроме root, перед вводом администраторских команд, нужно писать слово "sudo". То есть, из-под пользователя root мы писали:
, а из-под любого другого пользователя, нужно писать:
И кроме этого, система ещё и попросит ввести пароль (пароль этого пользователя, а не root-а). Это, конечно, неудобно, но так нужно для обеспечения безопасности сервера.
Итак, мы зашли на сервер под новым пользователем. Но ведь старый пользователь, root, никуда не делся, и под ним тоже можно зайти. А мы для безопасности хотели, чтобы было нельзя. Значит, пользователя root нужно как-то удалить. Но удалить его в системе невозможно, а возможно только отключить. Делается это удалением пароля. И если мы выполняем администраторские команды, привыкаем каждый раз в начале строки писать слово sudo, а также вводить свой пароль:
, вводим пароль, и пользователь root отключен. Чтобы убедиться в этом, пробуем зайти на сервер под root-ом, и странное дело, радуемся, когда у нас это не получается Всё, теперь программы-злоумышленники тоже не смогут зайти под стандартным логином root. А смогут зайти только если угадают И логин, И пароль одновременно, что уже практически нереально, а значит, мы с вами можем спать спокойно.
Теперь снова входим под нашим камикадзой и пишем в консоли следующее:
При этом система обновляет информацию о доступных обновлениях и сообщает нам в ответ, сколько пакетов может быть обновлено. Затем мы пишем:
При этом система запускает обновление и просит нас подтвердить данную операцию. Подтверждаем нажатием клавиши "Y" и видим, как по экрану побежало много букв. Это началось обновление системы, чтобы на нашем сервере работали самые последние, самые безопасные и самые модные версии программ. Ждём минут 5. Теперь, для упрощения работы на сервере, устанавливаем чудо-программу, которая сделает нашу консоль намного более наглядной и удобной. Эта программа называется Midnight Commander. Ничего не напоминает? Устанавливается она как обычно:
, после чего запускается:
В первый раз эту программу нужно запускать именно так и именно от любого другого пользователя, кроме root. После чего можно выходить из неё нажатием клавиши F10 и запускать в администраторском режиме, чтобы были доступны все возможности:
Если Вы уже смирились с тем, что работать на сервере можно только через командную строку, то увидев эту программу Вы будете удивлены. Она похожа на программу Total Commander, только более простую её версию, но всё равно это намного лучше, чем просто командная строка. Здесь можно лазать по каталогам файловой системы, смотреть, какие файлы там лежат, открывать их для просмотра клавишей F3, открывать их для редактирования клавишей F4, копировать клавишей F5, перемещать F6, создавать новые каталоги F7, удалять F8, и радоваться, радоваться, радоваться, как легко и быстро мы поменяли, поперемещали и поудаляли много разных файлов, которые были нужны для работы нашего сервера! Что ещё раз подтверждает общий закон нашей жизни: больше свободы — больше ответственности.

Продолжение следует...

Поэтому, если поначалу Вы не уверены в своих действиях, то можно запускать программу Midnight Commander (MC) в обычном режиме, без префикса "sudo". В таком режиме ничего страшного натворить не удастся — система не позволит. Я же в дальнейшем буду использовать администраторский режим. Это удобнее тем, что не нужно перед каждой командой писать слово "sudo". Написал один раз перед запуском MC, и больше это слово тебя не беспокоит. Очень удобно. Только в программе MC командная строка представляет из себя не весь чёрный экран, как обычно, а действительно одну строчку внизу экрана. Это неудобно, т.к. мы не видим на экране результаты введённых команд. И чтобы их увидеть, а точнее, увидеть весь чёрный экран полностью, не выходя из программы MC, достаточно нажать сочетание клавиш Ctrl+O. Вернуться в программу MC можно будет таким же нажатием. Вот как выглядит программа MC:


Итак, теперь нам нужно установить на сервер программу веб-сервер. Две самых распространённых программы веб-сервера называются: Apache и Nginx. Какую же выбрать? Почитаем, что люди пишут... Оказывается, программа Apache легче в настройке и использовании, и она рекомендуется для начинающих админов. Nginx, соответственно, сложнее в настройке, но у неё есть одно очень важное для меня преимущество: в ней можно настроить защиту от разного рода спамов, в том числе и от простейшего спама кнопкой F5, о котором я писал выше. Вот, это как раз то, что мне нужно. Кроме того, пишут, что Nginx быстрее работает и чаще используется на сайтах с высокой посещаемостью. Это тоже то, что надо. В общем, берём Nginx! Берём и устанавливаем. Для установки необходимо ввести в консоли следующую команду:
, после чего, как обычно, спросят подтверждение, и побегут по экрану буквы, означающие, что программа устанавливается.
После завершения установки, веб-сервер сразу же начинает работать. И на наш сайт сразу же можно зайти из браузера. Допустим, адрес нашего сайта: example.com. Вводим в браузере этот адрес и видим страницу, которая всегда появляется после установки программы. То есть, это не наш сайт, а просто "страница-заглушка", назначение которой просто показать, что сайт работает:

Однако, этот веб-сервер Nginx, в отличие от Apache, не умеет работать с файлами PHP. Поэтому нам нужно установить ещё одну программу, которая это умеет. Называется она php-fpm, и устанавливается обычным уже для нас способом:
Вот теперь наш веб-сервер сможет работать с файлами PHP. Но нам и этого мало. Нужна же ещё база данных, а точнее, сервер баз данных, а ещё точнее, СУБД (система управления базами данных) под названием MySQL. Это та, которая с красивым языком. Ставим её тоже обычным способом:
, за исключением лишь того, что во время установки нам нужно будет придумать и ввести пароль учётной записи администратора MySQL. Придумываем, вводим... Кстати, название учётной записи администратора MySQL такое же, как и администратора Ubuntu — root. Это название используется в качестве учётной записи администратора ещё во многих других информационных системах, поэтому, приучаемся не путать одного "рута" с другими.

В общем, мы установили на наш хостинг три основных компонента веб-сервера:
1) Nginx, который обрабатывает статические HTML-страницы,
2) php-fpm, который обрабатывает PHP-файлы,
3) MySQL-Server, который хранит данные и выдаёт их нам по нашему запросу.

Все эти три компонента работают в команде, рука об руку, для достижения одной важной цели — чтобы наш сайт работал. Какие молодцы! Но пока мы видим на странице браузера не наш сайт, а какую-то заглушку. Это потому, что мы не загрузили наши файлы на сервер. Заходим в наш любимый Total Commander, подключаемся к файловой системе сервера через SSH-туннель и видим следующую картину:

Возникает закономерный вопрос: "А в какую папку закачивать файлы?" Ищем ответ, как обычно, в Интернете, где пишут, что это папка /var/www/html. Что ж, начнём-ка закачивать-ка... Но перед этим заархивируем наши файлы в один архив, чтобы они быстрее закачались на сервер. Выбираем для этого самый лучший архиватор 7z, который есть в наборе архиваторов в нашем Тотал Командире, и делаем архив. Затем просто копируем этот архив в папку /var/www/html и проверяем, работает ли сайт. Опа! Не тут-то было... Файл не закачивается, нам пишут ошибку. А всё дело в том, что любая операционная система Linux, и в частности, Ubuntu, использует права доступа к файлам. И видимо, для записи файлов в эту папку пользователем kamikadze9705, недостаточно прав. Чтобы не углубляться здесь во все хитрости системы прав доступа Linux, скажу проще... Пользователь kamikadze9705 не является владельцем папки /var/www/html. Соответственно, нужно сделать его таковым. Для этого через консоль даём серверу команду:
, что в переводе означает: "Сервер, будь добр, сделай пожалуйста пользователя kamikadze9705 владельцем папки /var/www/html". И сервер тут же всё сделает, на то он и сервер. После чего наш файл-архив легко и непринуждённо закачается в эту папку. Теперь нам нужно его распаковать. Для этого установим на сервер ещё одну программу-архиватор под одноимённым названием 7z:
Программа устанавливается, и мы сразу же используем её, чтобы разархивировать наш архив с файлами сайта. Но перед этим удалим тот файл, что был в этой папке до закачки архива. Это тот файл, в котором написана страница-заглушка, и он нам больше не нужен. Не помню, как он называется, я его уже удалил Короче говоря, разархивируем наш архив... Стоп! Я же сейчас нахожусь в программе MC, запущенной от имени администратора, а значит, все файлы, созданные в системе, будут принадлежать пользователю root, и получить к ним доступ от других пользователей будет невозможно. Значит, сначала выходим из программы MC, и снова заходим в неё, только не от имени администратора, а от своего имени, kamikadze9705:
Затем, открываем чёрный экран нажатием Ctrl+O и вводим команду для разархивирования файла:
, где 7z — программа-архиватор, которую мы установили,
буква "x" — означает, что нужно не ЗАархивировать, а именно РАЗархивировать,
и arhiv.7z — это имя нашего файла-архива, содержащего файлы сайта.
После ввода команды по экрану побегут буквы, после чего в папке появятся файлы нашего сайта. И с наивной надеждой, что сайт наш наконец-то заработает на VPS-хостинге, мы идём спать.

Продолжение следует...

Ура, сайт заработал!
Эммм... Только как-то странно заработал — картинок нет, форматирования страницы нет, цвета текста и цвета фона красивых тоже нет, один только чёрный текст на белом фоне, и всё это в столбик снизу доверху. Что за дела? Файлы .html, находящиеся в каталоге сайта, значит, работают, а файлы картинок, находящиеся в подкаталоге images и файлы .css, находящиеся в подкаталоге css, не работают. Значит, не работают подкаталоги? Ааа, видимо, это связано с правами доступа к файлам и каталогам. Угу, значит, придётся всё-таки углубиться немного в особенности прав доступа в системах Linux.
Дело в том, что для каждого файла и каждого каталога назначается не только владелец-пользователь, но и владелец-группа. Давайте помотрим этих владельцев командой:

На экране консоли появляется список вот таких строк:

Каждая строка показывает информацию об одном файле или каталоге, находящемся в каталоге /var/www/html. И мы видим, что все файлы и каталоги принадлежат пользователю kamikadze9705 и группе с таким же названием kamikadze9705. Теперь давайте рассмотрим, собственно, значения прав доступа. У каталогов эти значения равны:
, а у файлов:
Что это значит?
Первая буква "d" означает, что это каталог (directory), понятно.
Затем идут три блока по три символа для трёх видов субъектов: 1) владелец, 2) группа, 3) все остальные.
То есть, у каталога css права:

• для владельца: rwx
• для группы: ---
• для всех остальных: ---

Как Вы сами уже наверно поняли, доступ к этому каталогу имеет только владелец каталога, то есть, пользователь kamikadze9705. Пользователи же, входящие в группу kamikadze9705 (кроме владельца), а также все остальные пользователи не имеют прав доступа к каталогу. Ага, теперь понятно, почему веб-сервер не работает с подкаталогами — ведь он действует НЕ от имени пользователя kamikadze9705. Давайте посмотрим, от какого имени действует веб-сервер Nginx. Для этого заходим в каталог /etc/nginx и открываем там файл nginx.conf (клавишей F3). В самом начале этого файла видим строчку:

Всё понятно, nginx действует от имени пользователя www-data.
В этой ситуации (чтобы nginx имел доступ ко всем файлам и каталогам) можно сделать по-разному. Можно приказать nginx действовать от имени kamikadze9705, т.е. от имени владельца файлов. Для этого нужно в файле nginx.conf исправить одного пользователя на другого. А можно сделать похитрее — не менять пользователя nginx (www-data), но включить его в группу-владельца файлов, т.е. в группу kamikadze9705. Только при этом нужно будет поменять значения прав доступа к файлам. Такой подход лучше в том смысле, что за доступ пользователя kamikadze9705 будет отвечать первый блок прав, а за доступ пользователя www-data — второй блок. То есть, права доступа будут разграничены, и можно будет изменить права одному субъекту, не изменяя другому. Давайте сделаем это...
Сначала включим пользователя www-data в группу kamikadze9705:

А теперь изменим значения прав доступа к файлам в каталоге /var/www/html таким образом, чтобы файлы были доступны и пользователю, и группе:

, где -R означает "включая все вложенные файлы, каталоги и подкаталоги всех уровней вложенности",
а 770 — это значения прав "rwxrwx---", только в числовом виде.
То есть, "rwx" = 7, а "---" = 0.
Соответственно, первая семёрка означает полный доступ к файлам для пользователя-владельца kamikadze98705, вторая семёрка означает полный доступ к файлам для всех членов группы kamikadze9705, в которую входит пользователь www-data, от имени которого работает nginx, а третья цифра, ноль, означает отсутствие каких либо прав доступа к файлам для всех остальных пользователей.
Сделали. Теперь проверяем, изменились ли наши права:
и видим, что они действительно изменились.
Так, теперь проверяем, как работает сайт...
Картинки показываются, форматирование правильное и цветастое всё, цветастое!
Ура! Теперь точно ура!
Продолжение следует...

Однако, при разработке сайта менять файлы приходится очень часто, и каждый раз устанавливать нужные значения прав на каталоги очень неудобно. Было бы гораздо лучше, если файлы и каталоги сразу распаковывались бы с нужными правами. Как выяснилось, это архиватор 7z распаковывает каталоги с такими правами. Почему? Ответ мне пока неизвестен. Как сделать, чтобы он распаковывал их сразу с нужными правами? Тоже не нашёл я ответа. Попробовал использовать архиватор zip... В Тотал Командире он уже есть, а вот на сервер его нужно установить:

Упаковал файлы в своём любимом Тотал Командире, затем переслал архив arhiv.ZIP на сервер, и выполнил там команду:

В результате все файлы и каталоги распаковались с теми правами, которые мне нужны. И это выход! Конечно, архиватор 7z намного лучше сжимает информацию, чем zip, и поэтому я буду продолжать искать решение с 7z. Но в моём случае степень сжатия архива не так важна, как удобство при работе с архивами, поэтому пока я буду использовать zip.

В общем, теперь после распаковки архивов, мне не нужно менять никакие права, и html-страницы сайта в браузере сразу предстают передо мной в полноценном виде. Но html-страницы, это так называемая "статика", т.е. страницы, содержание которых определено заранее и хранится в самом файле. А на моём сайте уже есть и так называемая "динамика", т.е. страницы, содержание которых наполняется информацией из базы данных. И эти страницы сейчас не работают. Более того, файлы *.php даже не запускаются. Вместо этого, они зачем-то начинают скачиваться с сайта. Выше я писал, что в работе сайта принимают участие три основных программы: 1) веб-сервер, 2) база данных, 3) PHP. Давайте проверим, все ли три программы у нас работают... Для этого введём в консоли команду:
Результат выглядит так:

Конечно, разноцветных линий, стрелочек и букв в консоли не было. Это я добавил, чтобы показать, где там что. И мы видим, что все три основных программы, на которых работает сайт, у нас работают. Значит, они просто неправильно настроены. В нашем случае php-файлы должны исполняться, а не скачиваться. За выбор этого действия отвечает веб-сервер, nginx. Значит, смотрим настройки nginx, которые, как мы уже знаем, расположены в файле /etc/nginx/nginx.conf. Открываем этот файл и видим множество строк с разными настройками, от которых нам становится страшно. Но все эти настройка нам пока не нужны, мы успокаиваемся и ищем в этих строках раздел "server". Такого раздела в файле нет, однако, есть строка:

Которая означает, что в этом месте наши настройки дополняются настройками из всех файлов, расположенных в каталоге /etc/nginx/sites-enabled. Звёздочка перед точкой с запятой как раз означает "все файлы". Переходим в каталог /etc/nginx/sites-enabled и смотрим в него. Видим один файл с названием default. Значит, настройки из этого файла добавляются к настройкам основного файла. Открываем файл, чтобы посмотреть, нет ли там раздела "server", и видим, что он там есть. Вот текст всего файла:

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

Продолжение следует...

Итак, нам нужно разобраться в этих 10 строчках. А именно, выяснить, как сделать так, чтобы php-файлы не скачивались браузером, а запускались на выполнение, ибо php-файлы это по сути программы, которые выполняются на стороне сервера, и выполняет их программа php-fpm, которую мы устанавливали. Что нужно написать в файле default, чтобы php-файлы выполнялись программой php-fpm? Чтобы это выяснить, как обычно, лезем во всезнающий Интернет. И оказывается, написать нужно несколько строк, которые мы удалили вместе с другими комментариями. Эти строки нужно было не удалять, а "раскомментировать", т.е. убрать символы "#" в начале соответствующих строк. Так, какие именно строки? А вот эти:

Удаляем символы "#", находящиеся в начале строки, затем, удаляем строку "fastcgi_pass 127.0.0.1:9000;", т.к. у нас работает не php7.0-cgi, а php7.0-fpm, а также удаляем две строки с комментариями, где стоят ещё по одному символу "#". И у нас остаётся:

Добавляем эти 4 строки в файл default к имеющимся 10 строкам, и получается:

Сохраняем файл, и тем самым меняем настройки веб-сервера nginx. Однако, nginx уже работает, а "на ходу" настройки не меняются. То есть, нужно ещё и перезапустить nginx. Перезапускаем:

Заходим на сайт, на динамическую страницу, и видим, что php-файлы уже не скачиваются, а выполняются программой php-fpm, как мы и хотели. Однако, всё равно результат не такой, как мы ожидали. Браузер показывает не страницу, заполненную информацией из базы данных, а страницу с ошибкой:

В самом начале ошибки написано "SQL ERROR [mysqli]", из-за чего может показаться, что это наша база данных MySQL ругается. Однако, ниже почему-то идут ссылки на файлы *.php. Так в чём же дело? Давайте попробуем перевести с английского языка содержательную часть этого ругательства:

И вот наш перевод:

Ага, всё понятно. mysqli_connect — это функция в языке PHP. Но для того, чтобы она работала, нужно установить расширение mysqli для PHP. Устанавливаем:
Теперь перезапускаем PHP:

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

Продолжение следует...

А ошибка следующая:

Что означает: "Отказано в доступе для пользователя..." Вот это уже действительно ответ от СУБД MySQL (системы управления базами данных). И ответ логичный — мы же нигде не указывали, с каким логином и паролем наша программа на PHP будет подключаться к MySQL. Более того, в MySQL мы не создали ни одной базы данных с информацией. Всё это нам нужно сделать. Давайте начнём с подключения. Вспоминаем, какой там логин у администратора MySQL... Логин: root. А пароль мы указывали при установке. Значит, эти логин с паролем нужно прописать в нашей программе, написанной на языке PHP, в файлах *.php. Открываю свой файл config.php (у Вас он может называться по-другому), и прописываю там:
1) хост: "localhost",
2) логин: "root",
3) пароль: "***********" (здесь нужно в открытом виде указать пароль).
Как именно выглядит файл config.php, и как именно прописывать эти значения, мы рассмотрим позже, когда будем писать программу сайта на языке PHP.
Сохраняем файл и снова обновляем страницу сайта. Видим следующее:

Старая ошибка пропала, но опять появилась новая, чтоб ей пусто было. "Unknown database db_name" означает "Неизвестная база данных db_name". И в отличии от предыдущей ошибки, это означает, что мы уже подключились к MySQL, прошли этот этап. Теперь следующий — создание базы данных.
Чтобы создать новую, пустую базы данных, мы можем подключиться к MySQL через нашу уже любимую консоль, следующим образом:

Система попросит ввести пароль, мы его вводим и на экране появляется следующее:

Это означает, что мы подключились к MySQL через консоль. И теперь всё, что мы вводим в консоли, будет являться не командами для операционной системы Ubuntu, а командами для СУБД MySQL. То есть, теперь нам нужно писать команды на другом языке, на языке SQL, который понравился нам своей красотой. Как же будет выглядеть на этом языке команда создания новой базы данных? А вот как:
Что означает "Создать базу данных с именем my_db и с использованием кодировки utf8". Кодировка — это способ кодирования символов в компьютере. Кодировки бывают разные, но UTF8 — это универсальная кодировка, которая всё шире и шире используется в сети. Более подробно мы будем разбираться с кодировкой далее. А пока нужно обратить внимание на кавычки, в которые заключено имя базы данных my_db. Эти кавычки не обычные, а обратные, их можно ввести с клавиатуры, если нажать кнопку с буквой "ё", только в английской раскладке. Если ввести другие кавычки, то MySQL не примет у нас команду. Если же кавычки правильные, то MySQL ответит:
Что означает "Запрос принят, задействована 1 строка". То есть, база данных с именем my_db создана. Это то, чего нам не хватало, и из-за чего возникала ошибка. Указываем имя новой базы данных my_db в файле config.php, сохраняем файл и снова обновляем страницу. В результате снова видим новую ошибку:
Которую рассмотрим в следующий раз.

Продолжение следует...

Основное сообщение в тексте ошибки следующее:
Что переводится как: "Таблица 'my_db.phpbb_ext' не существует".
Дело в том, что любая база данных, в том числе и my_db, которую мы создали, состоит из так называемых таблиц. Каждая таблица — это, собственно, таблица, состоящая из колонок и строк, как любая обычная таблица. В эти таблицы можно добавлять строки, можно удалять из них строки, менять значения в строках, выполнять поиск значений по всей таблице, делать выборку значений и т.д. То есть, вся информация в базе данных хранится в этих самых таблицах. Например, мы можем создать в базе данных my_db таблицу с названием "cars", где каждая строка будет соответствовать одному автомобилю. В этой строке будет марка автомобиля, модель, цена, а также другие характеристики. В этой же базе данных мы можем создать ещё одну или несколько других таблиц для заполнения их другой информацией, которую мы хотим хранить и использовать в работе сайта. Так вот, в нашей новой базе данных никаких таблиц ещё нет, и данных тоже нет. А файлы сайта требуют таблицы и требуют данные, поэтому и возникает такая ошибка. Дело в том, что при переносе сайта с одного хостинга на другой, перенести только лишь одни файлы — мало. Кроме файлов нужно перенести ещё и базу данных со всеми таблицами и всеми данными. А я базу данных не перенёс, а перенёс только файлы. Ошибка? Нет, это я специально так сделал, чтобы здесь на форуме последовательно описать всё по порядку.

Итак, у меня есть база данных с предыдущего хостинга, сохранённая в файле, и мне нужно перенести её на этот новый хостинг. Это можно сделать и через консоль, если загрузить файл на сервер. Но мне удобнее пользоваться программой MySQL Workbench, которая может удалённо (то есть, с моего домашнего или офисного компьютера) подключаться к СУБД MySQL. Эта программа удобна тем, что в ней, как в обычных программах для Windows всё наглядно, есть окошки и возможность работать мышкой. По сравнению с текстовой консолью это намного удобнее. Скачать программу MySQL Workbench можно бесплатно по ссылке: https://dev.mysql.com/downloads/workbench/ После установки, нужно создать в программе подключение к нашей СУБД MySQL. Делается это следующим образом... Нажимаем мышкой плюсик:
Появляется новое окошко:
В котором мы щёлкаем выпадающий список и выбираем в нём пункт "Standard TCP/IP over SSH":
После чего мы видим настройки, заполненные не нашими данными:
Соответственно, заполняем их нашими данными:
Красными стрелками указаны кнопки, которые нужно по очереди нажать, и по очереди появятся два маленьких окошка:
в которых нужно ввести два пароля:
1) пароль пользователя kamikadze9705 в системе,
2) пароль пользователя root в СУБД MySQL, который мы вводили при установке MySQL.
В каждом окошке нажать кнопку "ОК", и затем общую кнопку "ОК" в окне настроек. После этого в основном окне программы появится ярлык настроенного подключения:
И если все настройки были введены правильно, то при нажатии на этот ярлык произойдёт подключение к СУБД MySQL, и в программе появится новая вкладка с интерфейсом управления базами данных:

И в этом интерфейсе в списке слева мы с Вами уже можем наблюдать название нашей новой базы данных "my_db", которую мы создавали через текстовую консоль. Эта база данных пока пустая, но мы как раз и подключились с помощью программы MySQL Workbench, чтобы наполнить её данными из файла. И вот как это делается... В основном меню программы выбираем "Server -> Data Import":
Появляется формочка для заполнения:
В которой мы делаем 4 действия:
1) щёлкаем переключатель,
2) выбираем файл, в котором сохранены наши старые данные,
3) выбираем, в какую из существующих баз данных нужно эти данные внести,
4) нажимаем кнопку "Start Import".
После чего ждём, пока на этой странице не появится последнее слово "finished":
Это будет означает, что данные загрузились в базу. И не только данные загрузились, но и создались таблицы, в которых эти данные хранятся. Чтобы убедиться в этом, нужно нажать маленькую кнопочку "Обновить", и раскрыть список таблиц нашей базы данных my_db:
Как мы видим, в базе данных появилось много таблиц с разными названиями, в которых теперь лежат данные с нашего старого хостинга. А значит, последняя ошибка о том, что таблица не существует, должна исчезнуть с нашего сайта. Обновляем сайт:
И видим, что действительно, старая ошибка исчезла. Но как обычно, появилась ошибка новая, и исправлять мы её конечно же будем, только в следующей серии.

Продолжение следует...

Итак, текст ошибки:
Вкратце это означает, что какой-то написанный в нашем сайте запрос к базе данных несовместим с одной настройкой sql_mode=only_full_group_by
Но на старом хостинге всё работало, не было никаких проблем. В чём же дело? Задаём вопрос Интернету... Там пишут, что начиная с версии MySQL 5.7, эта настройка по умолчанию включена. То есть, в предыдущих версиях, видимо, она была выключена. Давайте посмотрим, а какая версия MySQL работает у нас на сервере... Для этого в программе MySQL Workbench во вкладке "Management" нажимаем пункт "Server Status" и видим следующую информацию о сервере:
Среди которой видна и версия MySQL: version 5.7.19. Значит, на нашем сервере эта настройка включена, и поэтому у нас возникает ошибка. А на предыдущем хостинге, видимо, версия MySQL была ниже 5.7, настройка была выключена, и поэтому ошибки не было. Давайте попробуем выключить эту настройку. Снова лезем в Интернет за советом, как именно эта настройка выключается, и находим... Сначала давайте узнаем, какое значение имеет настройка в данный момент. Для этого в программе MySQL Workbench, во вкладке "Query 1" напишем следующий запрос:
Затем жмём кнопку "Execute" ("Выполнить") и видим следующий результат:
После чего копируем этот результат нажатием правой кнопки мыши и выбором пункта "Copy Field" (Скопировать поле):
Затем вставляем в блокнот и видим:
Такое значение имеет настройка сейчас. А нам нужно было выключить only_full_group_by. Смотрим, в самом начале строки как раз написано ONLY_FULL_GROUP_BY. Попробуем убрать это и записать изменённую строку. Значит, новая строка у нас получается такая:
Записываем её следующим образом... Стираем "SELECT @@GLOBAL.sql_mode;" и пишем на том же месте:
В конце ставим точку с запятой, снова нажимаем кнопку "Execute" и видим результат:
Где снизу, в журнале выполненных операций, можно заметить маленький зелёненький значок, означающий успешное выполнение операции.
Таким образом получается, что мы изменили настройку, из-за которой у нас возникала ошибка. Проверяем... Заходим на динамическую страницу нашего сайта и видим, что всё работает без ошибок. Ну наконец-то, мы это сделали! Оглядываясь вверх на все эти сообщения, прямо даже не верится, что мы САМИ проделали такую работу. А ведь поначалу всё это было так страшно

Продолжение следует...

Итак, подведём промежуточные итоги...
На данный момент на нашем сервере VPS работает:

1) веб-сервер nginx,
2) PHP,
3) СУБД MySQL.

Это три основных компонента, которые обеспечивают работу сайта, и сайт работает.
При этом управление сервером происходит:

1) общее — из консоли через подключение SSH,
2) обмен файлами — по протоколу SFTP через туннель SSH,
3) управление базами данных — из программы MySQL Workbench через туннель SSH.

То есть, всё управление идёт через защищённые подключения SSH, что обеспечивает нам информационную безопасность.

Теперь давайте посмотрим, что у нас ещё не сделано...

1) на сервере работает только один сайт, а нам нужно сделать, чтобы работало несколько,
2) для защиты пользовательских данных (логинов, паролей и т.д.) нужно настроить SSL-протокол,
3) нужно защитить сайты от различных видов атак злоумышленников,
4) на нашем сервере нет электронной почты, а нужно, чтобы была для поддержки пользователей.

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

Продолжение следует...

Чтобы работало несколько сайтов, нужно настроить веб-сервер nginx. А именно, в настройках нужно для каждого сайта создать свой раздел "server". Где у нас находится раздел "server"? В файле /etc/nginx/sites-enabled/default. И вот как он выглядит:
Этот один раздел server соответствует одному сайту. Значит для ещё одного сайта нам нужно создать ниже ещё один такой же раздел. Такой же, да не такой. А какой? Чтобы разобраться в этом, давайте рассмотрим каждую строчку...
listen 80 default_server; — Означает, что веб-сервер работает на порту № 80. Это стандартный порт для протокола HTTP, на котором работают все сайты. То есть, когда в строке браузера мы пишем, например: tochek.net, то подразумевается, что используется 80-й порт. И если мы напишем tochek.net:80, то это будет то же самое, и браузер откроет нам наш любимый форум. А вот если мы напишем, например, tochek.net:81 или поставим какое-нибудь другое число вместо 80, то форум нам не ответит, т.к. он работает на порту № 80. Кроме того, слова default_server в строке означают "сайт по умолчанию". То есть, этот сайт откроется, если веб-сервер не смог определить, какой сайт нужен пользователю.
listen [::]:80 default_server; — Эта строка нужна для поддержки протокола IPv6, который нужен для будущего, но он пока ещё недостаточно распространён в сети. Просто оставляем эту строчку как есть.
root /var/www/html; — Это каталог на сервере, в котором расположены файлы данного сайта. То есть, для другого сайта нужно будет указать другой каталог, в котором находятся файлы этого другого сайта.
index index.html index.htm index.nginx-debian.html; — Здесь после слова index указывается, с какого файла сервер должен начать обзор сайта, если в браузере указано, например, просто tochek.net. В данном случае веб-сервер должен начать обзор сайта с файла index.html. А если такого файла нет, то начать с файла index.htm. И так далее, по порядку, если указано несколько файлов.
server_name _; — Это домен. То есть, имя и одновременно адрес сайта, по которому пользователи будут заходить на сайт. Например, для сайта tochek.net здесь должно быть указано tochek.net. В данном случае у нас указано имя "_". Такого домена не существует, поэтому на сайт можно зайти только если ввести в браузере IP-адрес сервера. Вопрос: Почему же тогда мы можем зайти на сайт по домену? Ответ: Потому что указана директива default_server, и попытка зайти на любой домен, привязанный к хостингу, но неизвестный для веб-сервера nginx, будет отправлять пользователя на данный сайт.
Далее идёт блок:
Который означает, что все файлы, находящиеся в каталоге /var/www/html и в его подкаталогах, должны отправляться браузеру.
Следующий блок:
Означает, что все файлы с расширением .php, прежде чем отправляться браузеру, должны быть обработаны интерпретатором PHP (php-fpm), который является одним из трёх основных компонентов для работы сайта.
Так, разобрались. Значит, для двух разных сайтов, нам нужно сделать два таких раздела server с указанием 1) двух разных доменов и 2) двух разных каталогов с файлами, соответствующих каждому сайту.
Для начала давайте создадим два разных каталога. Допустим, у нас два сайта: 1) site1.ru, 2) site2.ru. Не будем ничего усложнять и в каталоге /var/www создадим два подкаталога: 1) site1.ru, 2) site2.ru. В первый каталог поместим файлы первого сайта, а во второй, соответственно, второго. Создать эти каталоги можно, например, из установленной нами на сервере программы Midnight Commander, если с её помощью зайти в каталог /var/www, нажать там кнопку F7 и ввести название нового каталога, например, site1.ru. Только обратите внимание, что создавать каталоги нужно от имени пользователя kamikadze9705, чтобы у веб-сервера не было проблем с доступом к файлам сайтов. То есть, в программу Midnight Commander нужно заходить не так: sudo mc, а так: mc. После этого можно создавать каталоги и копировать файлы сайтов.
Теперь в файле /etc/nginx/sites-enabled/default сделаем копию всего раздела server, чтобы получилось их два одинаковых. Вот так:
А затем исправим значения на нужные нам.
То есть, в первой копии раздела server:

1) заменим root /var/www/html; на root /var/www/site1.ru;,
2) заменим server_name _; на server_name site1.ru;,
3) в строке index index.html index.htm index.nginx-debian.html; оставим только index index.html;, т.к. index.html будет единственный главный файл на нашем сайте.

А во второй копии раздела server:

1) заменим root /var/www/html; на root /var/www/site2.ru;,
2) заменим server_name _; на server_name site2.ru;,
3) в строке index index.html index.htm index.nginx-debian.html; оставим только index index.html;, т.к. index.html будет единственный главный файл на нашем сайте.
4) уберём слова default_server, т.к. сайт по умолчанию должен быть только один, и в нашем случае это будет site1.ru.

Итого, у нас получится:
Сохраняем файл с этими настройками. И, внимание, копируем его не в папку /etc/nginx/sites-enabled, а в папку /etc/nginx/sites-available. Потому что в первой папке на самом деле находится не сам файл, а ссылка на него. А сам файл находится во второй папке. И если мы изменим файл во второй папке, то автоматически изменится и в первой, т.к. это просто ссылка. Так сделано для удобства управления сайтами — чтобы легче было включать и выключать определённые сайты.
После изменения этих настроек, нужно перезапустить веб-сервер nginx:

Таким образом мы создали на сервере два сайта: site1.ru и site2.ru. И если всё было сделано правильно, то из браузера мы сможем зайти как на первый наш сайт, так и на второй. То есть, мы платим за один хостинг, а сайта у нас два. Классно!

Продолжение следует...

Обнаружилось, что после рестарта сервера (вместе со всеми сайтами и программами), который делается вот так:
Снова возникает ошибка типа this is incompatible with sql_mode=only_full_group_by
Это происходит потому, что все переменные, установленные методом SET, сбрасываются после перезагрузки. И если мы хотим, чтобы они не сбрасывались, то нужно прописать их в файле /etc/mysql/my.cnf. В данном случае в этот файл нужно добавить следующие 2 строки:
Затем сохранить файл и перезапустить MySQL:
После этого ошибка больше не появится даже после рестарта сервера.

Теперь давайте настроим SSL-протоколы для наших сайтов, чтобы личные данные пользователей шифровались при передаче и не были перехвачены злоумышленниками. Обязательным компонентом SSL-протокола является SSL-сертификат. Каждому сайту выдаётся свой собственный SSL-сертификат, привязанный к домену сайта. Выдать своему сайту сертификат мы можем сами с помощью специальной программы, делается это несложно, и такой сертификат называется самоподписанным. А можем запросить сертификат у организации, являющейся доверенной в Интернете, и такой сертификат называется доверенным. В чём разница? Дело в том, что при входе на сайт с самоподписанным сертификатом, пользователь сначала не видит сайт, а видит предупреждение от системы безопасности браузера. Мол, сертификат данного сайта не является доверенным, неизвестно, как он работает, и безопасна ли передача личных данных при этом. Пользователи, не разбирающиеся в этом деле, сразу начинают сомневаться вообще заходить на такой сайт, что очень сильно снижает репутацию сайта. Поэтому очень важно установить на свой сайт именно доверенный сертификат, выданный доверенной организацией. Как я уже писал выше, существует много организаций, выдающих такие сертификаты платно, за деньги. Однако, недавно в Интернете появилась одна организация, выдающая их бесплатно. Сервис по выдаче сертификатов, который она предоставляет, называется Let's Encrypt. Сайт этого сервиса расположен по адресу: https://letsencrypt.org/.

Продолжение следует...

И чтобы для наших сайтов установить SSL-сертификаты, нам на нашем сервере нужна программа-клиент, которая будет общаться с программой-сервером на сервере службы Let's Encrypt. Установить эту программу-клиент можно обычным способом:

Обратите внимание, что сертификаты не будут попадать на наш домашний или офисный компьютер, а будут приходить с сервера Let's Encrypt на наш сервер напрямую.

Да, я совсем забыл, что такой сертификат может быть выдан для одного домена и для одного поддомена. Это означает, что мы можем получить один общий сертификат для site1.ru и для www.site1.ru, что очень удобно, ибо это одно и то же. Но поддомен www.site1.ru не описан у нас в настройках nginx, а описан только домен site1.ru. Давайте опишем и поддомены для каждого из двух доменов. Итого у нас получится 4 раздела server:
То есть, два домена site1.ru и www.site1.ru ссылаются на один и тот же сайт, файлы которого расположены в папке /var/www/site1.ru.
А два домена site2.ru и www.site2.ru ссылаются на один и тот же сайт, файлы которого расположены в папке /var/www/site2.ru.
Проверяем в браузере — действительно всё так.
Теперь мы можем получить общий SSL-сертификат для каждого домена и его поддомена с "www". Но сервер службы Let's Encrypt будет обязательно проверять, действительно ли это наш сервер. Проверка происходит следующим образом... Программа-клиент, которую мы только что установили, в подкаталог нашего сайта запишет какие-то свои файлы, а затем сервер их службы зайдёт на наш сайт в этот подкаталог и убедится, что это те же самые файлы. Таким образом служба убедится, что сайт и программа-клиент расположены на одном и том же компьютере. Подкаталог, который создаст программа-клиент, называется ".well-known", и мы должны открыть доступ к этому каталогу клиентам сайта. Для этого в настройках веб-сервера nginx нужно добавить блок:
Такой блок нужно добавить для каждого раздела server. И это делается только на время получения сертификата, а затем этот блок можно будет удалить. В итоге файл /etc/nginx/sites-available/default будет содержать следующие настройки:

И теперь, когда мы всё подготовили, давайте получим сертификаты. Для этого введём в консоли следующую команду:
Программа получения сертификата запустится, попросит нас ввести e-mail (для получения уведомлений об истечении срока сертификата, если вы вдруг не захотите настроить автопродление) и согласиться с лицензионным соглашением. Вводим почту, соглашаемся с соглашением и нажимаем Enter. Программа "зависнет" на какое-то время, после чего с поздравлениями сообщит нам, что сертификат для сайта получен. Сертификат для одного нашего сайта site1.ru. Для другого сайта site2.ru сертификат получаем точно так же:

Продолжение следует...

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

Тем временем мы видим, как наш файл настроек становится всё больше и больше. А ведь нам нужно ещё настроить в нём использование полученных сертификатов, что сделает его ещё больше. Поэтому, чтобы нам удобнее было работать, давайте разделим этот файл на два — для каждого сайта сделаем свой файл. В каталоге /etc/nginx/sites-available создадим файлы site1.ru и site2.ru, в которые скопируем, соответственно, первую и вторую половины текста из файла default. Но после этого данные файлы не заработают, т.к. их нужно ещё "включить". Включение каждого файла происходит созданием на него символической ссылки в каталоге /etc/nginx/sites-enabled. Создаём ссылки:

А ссылку /etc/nginx/sites-enabled/default удаляем — она нам больше не нужна. Сам же файл настроек /etc/nginx/sites-available/default можно не удалять, оставить его для истории. После этого перезагружаем сервер nginx:

Теперь давайте сделаем так, чтобы пользователи, вошедшие на домен www.site1.ru, автоматически попадали на site1.ru. Говорят, это повышает рейтинг сайта в поисковых системах, т.е. наш сайт будет находиться выше в результатах поисковых запросов, что увеличит посещаемость нашего сайта. Для этого исправим файлы настроек таким образом, чтобы получилось следующее:
Сохраняем файлы, снова так же перезагружаем nginx и проверяем результат. В браузере вводим: www.site1.ru, но попадаем на site1.ru. Вводим: www.site2.ru, но попадаем на site2.ru. Это как раз тот результат, который мы хотели получить перед тем, как начать настройку полученных SSL-сертификатов.

Продолжение следует...

...полученных SSL-сертификатов. Где же они, эти сертификаты? Можно ли на них посмотреть? Да, можно, если открыть файлы /etc/letsencrypt/live/site1.ru/fullchain.pem и /etc/letsencrypt/live/site2.ru/fullchain.pem, соответственно. Но если внимательно на эти файлы посмотреть, то можно обнаружить, что они также являются символьными ссылками, а сами сертификаты находятся в файлах /etc/letsencrypt/archive/site1.ru/fullchain1.pem и /etc/letsencrypt/archive/site2.ru/fullchain1.pem, соответственно. Такая манипуляция со ссылками, опять же, используется для удобства. Если открыть файлы сертификатов для просмотра, то можно увидеть наборы каких-то непонятных символов. Это нормально, так и должно быть.

Сертификаты у нас готовы. Но специалисты по защите информации, для более надёжной защиты, рекомендуют также сгенерировать так называемые параметры Диффи-Хеллмана. Эти параметры будут находиться в отдельном файле и тоже будут представлять из себя набор непонятных символов. Но в отличии от сертификатов, настройки Диффи-Хеллмана можно использовать одни общие для всех сайтов на сервере. Давайте создадим для этих настроек каталог /etc/ssl/dh и после этого запустим генерацию параметров:
Процесс генерации будет сопровождаться выводом на экран точек и плюсиков, означающих для нас только то, что процесс ещё не закончился. Это может занять несколько минут, но для повышения безопасности наших сайтов, стоит подождать, тем более если это единственный раз. В результате, в каталоге /etc/ssh/dh появится файл dh.pem с параметрами ДХ.

Всё, параметры ДХ сгенерировали. Но перед тем, как мы приступим к настройке использования веб-сервером nginx этих сертификатов, хочу обратить внимание на следующие особенности... Если сайт использует SSL-сертификат для защиты передаваемых данных, то такое соединение называется защищённым и использует уже не 80-й порт как обычно, а порт № 443. Кроме этого, для такого соединения используется другое название протокола — не HTTP, а HTTPS, что отражается в адресной строке, как https:// вместо обычного http://. И если в браузере вместо http://site1.ru пользователь напишет https://site1.ru, то он автоматически попадёт на порт № 443 вместо обычного порта № 80. Всё это нам необходимо учесть в настройках. Кроме того, в настройках я хочу сделать так, чтобы пользователь вообще не мог использовать незащищённое соединение для доступа на сайт. То есть, чтобы при попытке зайти на http:// (порт 80), пользователь автоматически перенаправлялся на https:// (порт 443). Это убережёт неопытных пользователей от неосмотрительной передачи своих личных данных в открытом виде. Найдя в Интернете список подобных настроек, я адаптировал их немного под свои сайты, и вот что у меня получилось для сайта site1.ru:
Это содержимое файла /etc/nginx/sites-available/site1.ru. Для сайта же site2.ru настройки будут располагаться в своём файле /etc/nginx/sites-available/site2.ru и будут выглядеть точно так же, за исключением того, что домен site1.ru заменён на домен site2.ru.
Всё, теперь перезапускаем nginx:
И проверяем, как работают сайты. В браузере набираем http://site1.ru — попадаем на https://site1.ru с замочком в начале адресной строки, что означает, что наш сайт использует теперь защищённое подключение. Затем пробуем набрать http://www.site1.ru и https://www.site1.ru. В обоих случаях мы также попадаем на https://site1.ru, как мы и хотели. Сайт site2.ru работает у нас точно так же. И теперь наши сайты будут иметь выше рейтинг в поисковых системах не только из-за объединения доменов с www и без www, но и из-за использования защищённого соединения с доверенным SSL-сертификатом.

Продолжение следует...

Этот сертификат, бесплатно полученный нами от службы Let's Encrypt, действителен только в течении 3 месяцев. Однако, его можно продлить ещё на 3 месяца, затем ещё на 3, и так далее. То есть, пока существует служба Let's Encrypt, пока она работает и не создаёт никаких ограничений по продлению, наш сертификат можно считать вечным. Остаётся только научиться его обновлять. И оказывается, делается это очень просто. Вводим в командной строке (от имени root):
и программа автоматически обновляет все сертификаты, находящиеся в папке /etc/letsencrypt/live, выдавая на экран вот такой ответ:
Этот ответ означает, что наши сертификаты не были обновлены, т.к. время их обновления ещё не подошло. Это и понятно, ведь мы только недавно их получили. На самом деле сертификат обновляется только если до окончания срока его действия осталось 30 дней или меньше. Но самому следить за этими сроками не очень удобно. Было бы неплохо, если бы команда обновления сертификатов запускалась в системе как-нибудь автоматически и регулярно, например, раз в неделю, чтобы сертификаты сами вовремя обновлялись, и чтобы нам не нужно было думать и помнить об этом. И оказывается, такая возможность есть. Называется эта возможность — программа Cron. Она постоянно работает и выполняет указанные нами команды по указанному нами расписанию. Давайте сразу и составим такое расписание. Для этого, от имени root введём команду:
Откроется редактор текстовых файлов, в котором каждая строка — это отдельное задание. Выглядит эта строка, например, так:
В этой строке сначала идут 5 числовых значений (или звёздочка), а затем — команда. Эти значения по порядку означают следующее:

1) минута
2) час
3) число месяца
4) месяц
5) день недели

То есть, в данном случае команда "letsencrypt renew" будет выполняться каждый понедельник в 5:11 утра. Почему именно ранним утром? Потому что в это время посещаемость сайтов обычно самая низкая, нагрузка на сервер, соответственно, тоже. Поэтому все подобные вещи, связанные с администрированием сервера, обновлениями и т.п. обычно проводят в это время. Но в данном случае, чтобы обновлённые сертификаты начали использоваться, нужно ещё и перезагрузить веб-сервер nginx. То есть, нужно выполнить ещё одну команду. Эту команду можно вставить второй строкой, указав время выполнения, например, на 5 минут позже. Но мы сделаем ещё лучше — создадим скрипт, т.е. файл, содержащий сразу несколько команд. Например, скрипт следующего содержания:
Где первая строка — это комментарий, но комментарий не простой. Это директива, указывающая, какая программа будет выполнять этот скрипт. В данном случае это программа Bash. Вторая строка — это вывод на экран текущей даты и времени. Третья строка — просто вывод линии на экран. Четвёртая строка — это наша команда обновления сертификатов. Пятая строка — перезагрузка nginx. А строки с шестой по восьмую — это просто отступ высотой в три строки, чтобы в файле истории расстояние между записями было сразу заметное (будет понятно ниже). Сохраним этот файл с названием, например, ssl_le_renew.bash в папке /home/kamikadze9705/ssl. И чтобы этот скрипт мог выполняться, как программа, нужно дать ему право на исполнение. Делается это так:
И теперь если в командной строке мы напишем
, то этот скрипт выполнится, т.е. произойдёт запрос на обновление сертификатов и затем перезагрузится nginx. Значит теперь мы можем прописать запуск этого файла в программе Cron. Запускаем crontab -e и меняем строку на следующую:
Теперь по расписанию будет запускаться наш скрипт. Но мы сделаем ещё круче! Мы направим вывод результатов не на экран, а в файл /home/kamikadze9705/ssl/log.txt, чтобы в этом файле сохранялась история запусков обновлений, т.е. это будет лог-файл. Для этого дополним строку, чтобы получилось следующее:
И каждый понедельник в 5:11 утра этот лог-файл будет пополняться одной записью о запуске обновления сертификатов. При этом сертификаты наши будут обновляться вовремя, не беспокоя нас этими мелочами и освобождая наше время и внимание для серьёзных, больших и успешных проектов.

Продолжение следует...

Всё, с SSL-сертификатами мы разобрались.
Следующий этап — это защита сайта от атак злоумышленников.
Для начала давайте закроем все неиспользуемые порты. Какие порты у нас используются?

Порт 80 — HTTP (для переадресации на HTTPS),
Порт 443 — HTTPS (для защищённого доступа пользователей к сайту),
Порт 55555 — SSH (для защищённого доступа администратора к серверу, этот номер порта мы выбрали сами, он может иметь любое другое значение ниже 65535).

Эти порты должны быть открыты на сервере, а все остальные закрыты. Для этого в операционной системе существует инструмент (программа) под названием iptables. Чтобы проверить, в каком состоянии находятся порты нашего сервера, введём следующую команду:
которая выведет нам на экран следующую информацию:
Здесь три таблицы: INPUT, FORWARD, OUTPUT. Это таблицы правил, которые означают, соответственно: ВХОДЯЩИЕ, ПЕРЕНАПРАВЛЯЮЩИЕ, ИСХОДЯЩИЕ соединения. И в каждой из этих таблиц пока нет ни одного правила. Но у каждой таблицы есть общая политика, которая может быть РАЗРЕШАЮЩЕЙ (ACCEPT) или ЗАПРЕЩАЮЩЕЙ (DROP). И как мы видим, у всех трёх таблиц общая политика разрешающая все соединения. То есть, все порты у нашего сервера открыты. Это небезопасно, особенно для входящих соединений. Поэтому для таблицы INPUT мы будем использовать ЗАПРЕЩАЮЩУЮ общую политику — DROP, а разрешим только нужные нам три порта. При этом, если сначала изменить общую политику на запрещающую, то связь с сервером у нас пропадёт сразу же. Поэтому мы сделаем так: сначала разрешим порт SSH, потом изменим общую политику на DROP, а потом разрешим порты сайта. Разрешаем порт SSH:
Запрещаем все остальные входящие порты:
После этого на нашем сервере будет открыт только один входящий порт — 55555, для подключения SSH. А потры 80 и 443, используемые для всех сайтов, будут закрыты. Проверяем — пробуем зайти на наши сайты site1.ru и site2.ru и видим, что они действительно недоступны. Теперь аналогично открываем два этих порта:

Снова проверяем сайты и видим, как они стали доступны. Давайте посмотрим, как выглядят при этом настройки iptables:
Дополнительный ключ "-n" нужен чтобы порты выводились на экран не в буквенной, а в числовой форме, т.е. номерами портов. Ключ "--line-numbers" нужен, чтобы на экране отображались номера правил в начале каждой строки. В результате на экране мы видим:
То есть, теперь у нас на сервере открыты только три порта, а остальные закрыты, как мы и хотели.

Продолжение следует...

Опять случайно нажал какую-то кнопку
Скоро будет сообщение...

Забыли, забыли... Мы же ещё к серверу MySQL подключаемся удалённо через SSH-туннель. Значит нужно открыть ещё один порт — 3306. Причём, открыть так, чтобы доступ к серверу MySQL был только с локального компьютера, а из Интернета его не было. Пишем в командной строке:
Это разрешит входящие подключения к серверу MySQL через SSH-туннель. Но передача информации между программой-клиентом и программой-сервером MySQL организована двумя подключениями, одно входящее, другое исходящее. То есть, нужно открыть ещё и исходящие подключения. Пишем:
Этим мы открываем исходящие подключения не только с порта 3306, но и со всех остальных портов. Однако, не для всех пунктов назначения, а только для локального компьютера (IP-адрес назначения = 127.0.0.1), т.е. для подключений, не выходящих за пределы сервера. А вот подключения, выходящие за пределы сервера, нужно закрыть, чтобы наши секреты никто не узнал Для этого пишем сначала:
а затем:
Последняя из этих двух строк как раз запрещает все исходящие подключения, кроме указанных разрешённых. А вот первая строка особенная — она разрешает исходящую информацию для уже установленных (established) подключений, т.к. практически всегда во входящих подключениях есть ответы в обратную сторону. Аналогично, и в исходящих подключениях также всегда есть ответы в обратную сторону, и их нам тоже нужно разрешить:
И для ещё большего спокойствия давайте запретим все перенаправления (forward):
После внесения всех этих правил давайте проверим, что же у нас получилось:
На экране появится следующая информация:
После чего убеждаемся, что всё работает — пробуем подключиться к серверу MySQL и проверяем работу сайтов. Если всё работает, то это означает, что мы настроили так называемый файрволл (firewall).

Продолжение следует...

Настроили-то настроили, но оказывается, все эти настройки сбрасываются (пропадают), если перезагрузить сервер. Упс. В Интернете есть несколько разных советов, как сделать так, чтобы они не пропадали, но мне понравился один. Он заключается в том, что настройки сохраняются в текстовом файле, а при запуске сети (когда сервер запускается) эти настройки восстанавливаются из файла. Для этого файла давайте создадим каталог iptables в нашем домашнем каталоге:
И теперь, собственно, сохраним наши настройки в файле /home/kamikadze9705/iptables/rules.txt:
Теперь откроем этот файл и посмотрим, что же там сохранилось. Видим следующее:
То есть, именно те правила, что были у нас на экране. Отлично. Теперь нужно, чтобы эти правила загружались из файла при запуске сети. Для этого в каталоге /etc/network/if-up.d создадим файл с названием 0000-iptables.bash и напишем в нём следующие две строки:
Сохраним файл и попробуем перезагрузить сервер:
После перезагрузки сервера смотрим, какие правила действуют у нас в файрволе:
и видим на экране:
То есть, после перезагрузки сервера наши настройки восстановились из файла, как нам и было нужно.

Продолжение следует...

я в состоянии трудно-идентифицируемой дезориентации )))

Айя-Софи, Эллочка
Пожалуйста не сбивайте Indexа...
Он так интересно и доходчиво всё расписывает!
Хоть тему создал не я, но мне очень интересно и
думаю что его эти записи мне в скором времени понадобятся!
Слежу за темой и тоже стараюсь не перебивать.
Спасибо!

Спасибо за тёплые комментарии. Очень приятно, что в эту тему хоть кто-то ещё заглядывает, кроме меня.

Продолжаем...
Файрвол мы настроили, а именно, закрыли все внешние порты, кроме тех, что нам нужны. В дальнейшем мы, возможно, будем вносить какие-то дополнения в эти правила, но пока этого нам достаточно.
Теперь давайте сделаем защиту от той самой кнопки F5, с помощью которой любой дурак может задудосить наш сайт. Защита эта делается в настройках веб-сервера nginx. Именно из-за таких возможностей и был выбран nginx вместо более широко известного apache. Каким способом делается? Просто ограничивается частота запросов от одного клиента, например, максимум один запрос в секунду. Открываем файл /etc/nginx.nginx/conf для редактирования и в разделе http добавляем одну строку:
Эта строка означает, что создана зона под названием "max", в которой от одного клиента разрешён максимум один запрос в секунду. Название зоны можно выбрать другое, количество запросов в секунду тоже на Ваше усмотрение. Теперь в эту зону нужно включить наши сайты. Открываем настройки сайта site1.ru — файл /etc/nginx/sites-available/site1.ru. И добавляем в него две одинаковые строки:
в два раздела location. В результате файл получается следующим:
Значение burst=3 в каждой из этих строк означает, что допустимы кратковременные всплески в 3 раза больше, т.е. 3 запроса в секунду. Но среднее значение частоты запросов всё равно будет не более чем 1r/s. Теперь сохраняем файл и перезапускаем nginx:
Заходим на наш сайт site1.ru и пробуем зажать кнопку F5 на клавиатуре. В результате получаем на экране сообщение:
То есть, при частом обновлении сайт становится нам недоступен. Вопрос: доступен ли он в это время для других? Пробуем... Заходим на сайт с телефона. Теперь снова зажимаем кнопку F5 на клавиатуре компьютера и держим. Пока держим F5, обновляем страницу на телефоне и видим, что с телефона сайт доступен. Продолжаем держать F5, снова обновляем на телефоне и снова видим, что для других клиентов сайт вполне доступен. То есть, сайт становится недоступен только для того, кто его атакует. Для другого сайта защиту делаем точно так же. Всё, защиту от самой примитивной DDoS-атаки мы сделали.

Продолжение следует...

Только что обнаружил странное поведение сайта, но нашёл причину и исправил.
То картинки грузились не все, то форматирование не работало. Оказалось, это зря я в настройках nginx прописал две строки
Эту строку нужно прописывать только в разделе location, который обрабатывает php-файлы, т.е. вот здесь:
А в разделе, обрабатывающем все остальные файлы (html, css, картинки) эту строку прописывать не нужно. То есть, должно быть так:
Иначе загрузятся только три файла максимум (burst=3). Например, один файл html, один css, и одна картинка. А все остальные картинки не загрузятся.
Отсутствие ограничения на этот раздел не должно повлиять на загруженность сервера, т.к. прямая выдача файлов почти не загружает сервер. Основная нагрузка на сервер идёт как раз от обработки php-файлов, где у нас стоит ограничение, а также от работы базы данных.

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

То есть, установка выглядит следующим образом:
После чего перезапустил PHP:
И все функции на сайте сразу же заработали.
Кроме одной функции mail(), отправляющей электронное письмо. Вообще, отправкой электронных писем занимается почтовый сервер. Этот почтовый сервер может быть реальным сервером, а может быть программой, установленной на нашем сервере. Почитав советы по установке разных программ почтового сервера, решил попробовать обойтись без них. Как обойтись? Например, почтовый сервис Yandex предлагает абсолютно бесплатно подключить наши домены к их серверу. То есть, к своему уже имеющемуся аккаунту на yandex (например, ivan@yandex.ru) подключаете свой домен, например, site1.ru, настраиваете его, заводите там почтовые ящики, например: admin@site1.ru, support@site1.ru, ivan@site1.ru. И все письма, направленные на эти ящики, будут приходить на серверы yandex. Отправлять свои письма тоже можно будет с сервиса yandex, но от имени почтовых ящиков своего домена: ivan@site1.ru, support@site1.ru и т.д. И создать таких ящиков на Яндексе я могу до тысячи штук. Очень удобно. И самое главное — не нужно запускать на своём сервере программу почтового сервера. Получается, что сайты site1.ru, site2.ru, расположены на нашем сервере, а почтовые ящики ...@site1.ru, ...@site2.ru расположены на серверах yandex. Такой подход удобен тем, что если вдруг наш сервер по каким-то причинам перестал работать, то независимо от этого, наша почта будет работать, т.к. она расположена на Яндексе. И всем нашим клиентам, написавшим нам письма с беспокойством о сайте, мы сможем ответить, успокоив их, что скоро всё будет.
Рассказывать подробно о подключении доменов к Яндексу я не буду, т.к. Яндекс об этом уже рассказал вот здесь: https://yandex.ru/support/pdd/about.html.
А сам сервис "Почта для домена" находится здесь: https://pdd.yandex.ru/

После того, как домены к Яндексу подключены и почтовые ящики созданы, нужно установить на наш сервер программу, которая будет подключаться к почтовому серверу Яндекс, чтобы отправлять письма. Для этого есть разные программы, но я выбрал программу ssmtp. Устанавливаем её:
Теперь настраиваем файл /etc/ssmtp/ssmtp.conf. Удаляем оттуда всё полностью и добавляем следующие строки:
Сохраняем изменения. Теперь редактируем второй файл /etc/ssmtp/revaliases. Тоже удаляем оттуда всё и вставляем строки:
Сохраняем изменения. Теперь нужно сделать так, чтобы PHP знал, что для отправки письма нужно запускать именно программу ssmtp. Открываем файл /etc/php/7.0/fpm/php.ini, находим там строку:
И исправляем её так, чтобы получилось:
Сохраняем изменения. Перезапускаем PHP:
И пробуем отправить тестовое письмо через PHP. Для этого в корне сайта site1.ru (в каталоге /var/www/site1.ru) создаём файл sendmail.php, и пишем в нём:
То есть, мы пытаемся с ящика support@site1.ru отправить письмо на ящик support@site2.ru.
Сохраняем файл. И запускаем его через браузер, введя в адресной строке:
Если в браузере на странице появилась надпись "Письмо отправлено", то проверяем ящик support@site2.ru на наличие пришедшего письма. Если всё было сделано правильно, то письмо придёт. Однако, если мы попробуем указать в качестве ящика отправителя не support@site1.ru, а любой другой ящик, то Яндекс откажется отправлять такое письмо. Адрес отправителя в письме должен точно совпадать с адресом на данном аккаунте, иначе, пользователь, получивший письмо, будет обманут. И в этом обмане будет участвовать Яндекс, отправивший такое письмо. На месте Яндекса я тоже отказался бы участвовать в таком обмане, ибо мало ли кто и для чего это использует. То есть, с помощью программы ssmtp мы можем отправлять письма только с одного выбранного ящика. И такой способ хорошо подходит для сервера с одним сайтом. Но на нашем сервере два сайта: site1.ru и site2.ru. Эти два сайта в реальной жизни могут иметь совершенно разные адреса. Например, первый сайт у нас shkola-57.ru, а второй — online-porno.ru. И если пользователь, зарегистрировавшийся на сайте Школы №57, получит письмо с ящика mail@online-porno.ru, то это будет выглядеть очень странно. Поэтому для серверов с несколькими сайтами такой способ отправки писем не подходит. До установки программы ssmtp мне это не было известно, т.к. я делаю это впервые. По всей видимости, всё-таки придётся устанавливать для отправки писем свой почтовый сервер, который мы настроим так, чтобы он разрешал отправлять письма с ящиков разных отправителей. Попробуем сделать это в следующий раз.

Продолжение следует...

Полезный совет.

Программа PuTTY, с помощью которой мы заходим на сервер через SSH, через какое-то время отключается, если мы не проявляем активности. Это сервер её отключает. И если такой расклад нас не устраивает, то увеличить это время можно в настройках SSH. Для этого в файл /etc/ssh/sshd_config нужно добавить следующие две строки:
Где 7200 — это кол-во секунд до отключения с момента последней активности, в данном случае = 2 часа.
После чего нужно перезагрузить службу SSH:
А если мы хотим, чтобы уже сейчас наша сессия стояла 2 часа без отключений, то нужно отключиться и подключиться заново.

Это был полезный совет из Интернета, который... не работает
А теперь мой совет, проверенный на практике.
Чтобы сессия PuTTY не отключалась, нужно в настройках PuTTY указать, чтобы программа через каждые, например, 60 секунд отсылала серверу пустой пакет, означающий: "Эй там, не сервере! Я не отключилась, я на связи!". Таким образом связь с сервером будет поддерживаться до тех пор, пока мы сами её не отключим. Как именно указать? А вот как:
1. Запустить PuTTY, выбрать название сохранённой сессии и нажать кнопку "Load", чтобы параметры сессии загрузились в соответствующие поля.
2. Перейти на вкладку "Connection" и в поле "Seconds between keepalives (0 to turn off)" указать значение "60", как показано на скрине:

3. Снова перейти в основную вкладку "Session" и нажать кнопку "Save", чтобы эта настройка сохранилась вместе с остальными настройками выбранной сессии.
Всё, теперь при следующих запусках, эта сессия будет работать без отключений. Проверено.

Теперь о настройке почты.
У нас на одном сервере несколько сайтов, и каждый сайт должен отправлять письма со своего почтового ящика, принадлежащего этому же домену. То есть, сайт site1.ru должен отправлять почту с ящика, например, mail@site1.ru, а сайт site2.ru — с ящика mail@site2.ru.
Нашёл способ, как это можно сделать, проверил, работает.
Этот способ состоит из двух этапов:
1. Нужно запустить сайты от разных пользователей. А точнее, чтобы каждый сайт работал от своего пользователя операционной системы. А ещё точнее, нужно настроить PHP так, чтобы для каждого сайта запускался свой отдельный процесс PHP, и чтобы процесс этот работал от отдельного пользователя операционной системы.
2. Нужно установить программу почтового сервера postfix и настроить её так, чтобы разные пользователи операционной системы отправляли письма с разных почтовых ящиков.
То есть, для каждого сайта у нас должна получиться связка: Сайт1 работает от имени Пользователя1, который отправляет письма с Почтового_ящика1.
И более наглядно:

Сайт1 — Пользователь1 — Ящик1
Сайт2 — Пользователь2 — Ящик2
Сайт3 — Пользователь3 — Ящик3
И т.д...

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

Итак, приступим к первому этапу — настроим работу сайтов от разных пользователей.
Для этого сначала заведём этих пользователей в системе. Для каждого сайта — свой новый пользователь:
В имени пользователей недопустимы точки, поэтому мы используем дефисы. Также советую перед именем сайта делать какой-нибудь свой префикс (я сделал "u-"), чтобы злоумышленникам, пытающимся зайти на сервер через SSH, было сложнее подобрать логин. Для этих новых пользователей система создаст домашний каталоги с одноимёнными названиями: /home/u-site1-ru и /home/u-site2-ru.
И теперь мы сделаем одну манипуляцию — переместим рабочие каталоги сайтов из каталогов /var/www/site1.ru и /var/www/site2.ru в домашние каталоги пользователей /home/u-site1-ru/www и /home/u-site2-ru/www, соответственно. Так удобнее — при входе в систему мы оказываемся в своём домашнем каталоге, и сразу вот он рядом наш сайт.
Для этого в домашней папке мы создаём каталог www и копируем в него все файлы из каталога /var/www/site1.ru (в программе mc это делается легко). А затем пользователя u-site1-ru делаем владельцем каталога /home/u-site1-ru/www, а также владельцем всех файлов, находящихся внутри:
Ведь у нас PHP будет работать именно от имени пользователя u-site1-ru, и если владельцем файлов будет другой пользователь, то PHP не сможет работать с этими файлами.
Но теперь веб-сервер nginx должен знать, что рабочий каталог сайта переместился. А значит, в файле настроек /etc/nginx/sites-available/site1.ru меняем соответствующую строчку:
на
После чего можно перезапустить nginx:
И сайт заработает из нового каталога. Но при этом PHP не сможет создавать файлы и делать записи в файлы существующие, т.к. пока у нас ещё нет отдельного процесса PHP, работающего под пользователем u-site1-ru. Значит, создаём такой процесс. Для этого в каталоге /etc/php/7.0/fpm/pool.d создаём файл site1.ru.conf со следующим содержимым:
Где строка listen = /var/run/php/site1.ru.sock указывает на то, что обмен данными между PHP и Nginx происходит через файл /var/run/php/site1.ru.sock. Этот файл особенный, служебного типа, его называют "сокет". И Nginx тоже должен знать, что именно этот сокет используется для сайта site1.ru. Смотрим в настройки nginx, файл /etc/nginx/sites-available/site1.ru, что у нас там указано? А вот что:
Соответственно, тоже меняем на:
Сохраняем файл. После чего перезапускаем PHP и Nginx:
Заходим на сайт, убеждаемся, что всё работает, и понимаем, что первый этап нашей задачи мы выполнили.

Продолжение следует...

Для второго сайта site2.ru первый этап выполняем аналогично.

Теперь второй этап — установить программу почтового сервера postfix и настроить её так, чтобы разные пользователи операционной системы отправляли письма с разных почтовых ящиков.
Установка postfix выполняется один раз обычным способом:
После чего в файл настроек /etc/postfix/main.cf вносим следующие изменения:
1) удаляем строку
2) строку
меняем на следующую:
3) две строки с параметрами "myhostname" и "mydomain" делаем, чтобы выглядели следующим образом:
То есть, в обеих строках прописываем один любой домен, настроенный на наш сервер (можно site2.ru).
4) В конец файла добавляем следующие строки:
В результате чего, содержимое файла /etc/postfix/main.cf у нас получается следующее:
Проверяем, сохраняем файл и перезапускаем почтовый наш сервер postfix:
С такими настройками наш почтовый сервер не будет отправлять письма сам, а будет подключаться к серверу Яндекс (smtp.yandex.ru) и доверять ему отправку писем. Такой подход лучше использовать, если мы не уверены, что сможем правильно настроить свой почтовый сервер. Ибо при неправильных настройках нашего почтового сервера, отправленные с него письма могут попадать в спам на стороне получателя. Серверы же Яндекс наверняка настроены правильно, что даёт гарантию практически стопроцентной доставки писем. Кроме того, у этого подхода есть ещё одно преимущество, которое я уже описывал выше: Если наш сервер вместе со всеми сайтами вдруг перестанет работать, то письма от наших клиентов мы всё равно сможем получать и отвечать на них, т.к. это будет происходить через серверы Яндекса.
Всё, вот эти настройки делаются один раз, независимо от того, сколько на нашем сервере сайтов.
Теперь давайте сделаем настройки, разруливающие, какие сайты с какого ящика будут отправлять письма.
В каталоге /etc/postfix создаём каталог private, в котором создаём три текстовых файла:

1) sender_canonical
2) sender_relayhost
3) sasl_passwd

И записываем в эти файлы следующие данные:
1) /etc/postfix/private/sender_canonical:
2) /etc/postfix/private/sender_relayhost:
3) /etc/postfix/private/sasl_passwd:
То есть, в первом файле прописано, какой пользователь с какого ящика отправляет. Во втором файле прописано, какой ящик к какому серверу подключается (оба к Яндексу). А в третьем для каждого ящика прописано, какой логин и пароль используются для подключения к серверу.
Сохраняем эти файлы, после чего обязательно владельцем каталога /etc/postfix/private (вместе со всеми файлами) делаем пользователя root:
Иначе у нас не получится следующее действие. А следующее действие такое: В командной строке выполняем три команды, которые из этих текстовых файлов делают индексированные файлы (для быстрой работы postfix с этими настройками):
Смотрим, действительно, рядом с этими текстовыми файлами появились три файла красного цвета с названиями: sender_canonical.db, sender_relayhost.db, sasl_passwd.db. Всё нормально, так и должно быть.
И теперь чтобы настройки вступили в силу перезапускаем postfix:
Теперь нам нужно проверить, отправляют ли разные сайты письма с разных ящиков.
Создаём текстовый файл sendmail.php со следующим содержанием:
Заливаем этот файл в корень одного сайта и в корень второго сайта. То есть, в папки /home/u-site1-ru/www и /home/u-site2-ru/www.
Делаем владельцами этих файлов соответствующих пользователей:

И теперь в адресной строке браузера вводим сначала: site1.ru/sendmail.php, а затем site1.ru/sendmail.php. После чего проверяем, не пришло ли письмо на почтовый ящик ivan@yandex.ru. И оказывается, что не пришло В чём может быть причина? Точно! Мы же забыли открыть порт в программе iptables для исходящего подключения. По какому порту мы подключаемся к Яндексу? Правильно, по 465-му. А по какому адресу? Правильно, по smtp.yandex.ru. Значит, вводим следующую команду:
А затем проверяем, что получилось, командой:
И видим на экране:
О как! Вместо smtp.yandex.ru мы видим 5 IP-адресов. Это означает, что у Яндекса аж целых 5 машин, принимающих подключения пользователей по протоколу smtp. С таким сверхнадёжным подходом нам действительно не стоит бояться за доставку наших писем. Главное — отправить письмо Яндексу, а он уже разберётся.
И теперь нам важно не забыть сохранить настройки iptables в наш файл, иначе после перезагрузки сервера они сбросятся. Сохраняем:

Но с отправкой письма Яндексу могут возникнуть и другие проблемы. Например, Яндекс отказывается подключать нас по протоколу smtp до тех пор, пока мы не войдём в свой аккаунт mail@site1.ru через веб-интерфейс и не заполним свои данные: имя, фамилию, пол и дату рождения. Только после этого подключения будут успешны. Но даже если после этого, письма всё равно не приходят на ящик ivan@yandex.ru, то причины можно посмотреть в лог-файле почты /var/log/mail.log.
А у меня письма приходят. Отправленные с разных сайтов приходят с разных почтовых ящиков, что мне и было нужно.

Продолжение следует...

Забыл сказать...
Если мы хотим иметь возможность заходить на сервер через SSH под учётными записями пользователей u-site1-ru и u-site2-ru, то нам нужно разрешить это дело в файле /etc/ssh/sshd_config. А именно, в строку
добавить имена этих пользователей через пробел, чтобы получилось:
Затем сохранить файл и перезапустить SSH: