Делаю сайт, Впервые! Опции

[indеx]

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

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

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

[Создатель Галакт...]

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

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

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

[The Mentalist]

пить больше жидкости.

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

но и там давно есть готовые интернет-магазины, что еще туда писать?

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

Сообщение отредактировал The Mentalist - 1.07.2017 - 21:53

[indеx]

Введение.

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

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

[indеx]

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

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

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

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

[indеx]

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

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

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

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

[Создатель Галакт...]

 И если проект связан с деньгами,

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

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

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

[indеx]

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

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

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

[indеx]

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

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

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

Код

Select name from users where email is null

Прямо как песню спел! Я люблю этот язык!
Слава панели управления, базы данных на сервер устанавливаются легко, поэтому начало работы с БД не заставило себя долго ждать.

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

[indеx]

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

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

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

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

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

[indеx]

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

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



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

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

[indеx]

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

BitrixVM 5
BitrixVM 7
Centos 6
Centos 7
Debian 7
Debian 8
Ubuntu 14.04 LTS
Ubuntu 16.04 LTS

Что же выбрать? Придётся изучать данный вопрос... В процессе изучения выяснилось, что разработчиками чаще всего обновляется Ubuntu, у неё лучше поддержка, её сейчас используют больше всего, особенно начинающие системные администраторы. Это я что-ли ещё и системный администратор теперь, получается? Ну надо же. Короче говоря, мой выбор был очевиден — это Ubuntu 16.04 LTS. Слово LTS означает "Long Term Support", то есть, данная версия будет поддерживаться в течении 5 лет, а именно до 2021 года. Меня это устраивает, устанавливаю... готово. Но что делать дальше? Куда и как закачивать файлы с моим сайтом?

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

[indеx]

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


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


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

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

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

[льдинка]

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

[indеx]

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

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

[indеx]

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

Значит, нам нужно было закачать наши файлы на хостинг. Для передачи файлов по сети традиционно используют протокол ftp. Это означает, что с одного конца (на моём компьютере) одна программа ftp отправляет файлы, а на другом конце (на сервере) другая программа ftp принимает эти файлы. То есть, эта программа должна работать на обоих концах. На моём компьютере в качестве такой программы я могу использовать, например, FileZilla. Но с файлами мне больше нравится работать в программе Total Commander, и выяснилось, что в ней тоже есть поддержка работы с протоколом ftp. Ясно, с одного конца программа есть. Теперь другой конец, сервер. Выясняется, что на сервере для этого можно использовать программу vsftpd или же программу proftp, по желанию на выбор. Я выбрал первую попавшуюся мне на глаза — vsftpd. Устанавливается она следующим образом... В консоли вводятся буквы:

Код

apt install 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-туннель. Ещё раз повторю, что через туннель можно передавать практически любую информацию, и в дальнейшем я ещё буду говорить об этом.

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

[indеx]

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

Прокси это конечно хорошо, но нам нужно было залить файлы на сервер. Для этого мы собирались использовать 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, то попадёте прямиком в файловую систему сервера. И теперь в нашем любимом Тотал Командере мы можем закачивать файлы на сервер и скачивать файлы с сервера, как будто они у нас на компьютере. Классно! Ниужели нам это удалось? О да, и это оказалось не так уж и сложно. Тем более, что сегодня при помощи Интернета в нашем распоряжении весь мир, где мы можем найти ответы на любые вопросы и удовлетворить любые желания!

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

[indеx]

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

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

Код

passwd root

, после чего система предложит ввести новый пароль, два раза, чтобы избежать ошибки.
Так, пароль сменили. Но и это не гарантирует вероятность взлома злоумышленниками. Дело в том, что протокол SSH по умолчанию использует порт с номером 22, все компьютерщики это знают, в том числе и хакеры. Эти хакеры создают программы-боты, которые буквально ЛОМЯТСЯ на чужие серверы, т.е. многократно и бесконечно пытаются зайти на серверы через SSH, используя порт 22, логин root и тупо перебирая различные варианты пароля. Вероятность угадывания пароля, конечно, невелика, но если через пару лет это произойдёт, то для коммерческого проекта ущерб может быть просто убийственным, поэтому этот вариант нужно считать уязвимостью, и обязательно его исключать. Для этого мы можем поменять номер порта со значения 22 на любое другое в пределах от 1024 до 65535. Делается это просто...
В файле /etc/ssh/sshd_config есть строка:

Код

Port 22

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

Код

systemctl restart ssh

Всё, теперь на нашем сервере SSH работает не на 22-м порту, а на другом, выбранном нами. Это сразу снизит количество попыток взлома от самых тупых программ-ботов. Однако, боты поумнее могут определить, какие порты у сервера открыты, и всё равно найдут номер нашего порта. В этом можно не сомневаться, т.к. есть даже сайты, на которых можно быстро узнать, какие порты открыты на моём сервере. Например, вот на этом сайте http://www.t1shopper.com/tools/port-scan/ можно выбрать диапазон портов, просканировать свой сервер, и найти там порт, который отвечает. Поэтому одним только изменением номера порта здесь не обойтись. Что ещё мы можем изменить? Логин! То есть, нужно создать новую учётную запись пользователя с другим именем, которое никто не знает. Например, с именем kamikadze9705. Для этого вводим в консоли следующую команду:

Код

adduser kamikadze9705

, после чего система предложит ввести пароль, два раза, как обычно, а также предложит ввести полное имя, номер комнаты, рабочий телефон, домашний телефон и "другое". Всё это, кроме пароля, можно не заполнять, оставлять пустым и просто нажимать Enter. Таким образом будет создана новая учётная запись пользователя kamikadze9705, под которым теперь можно зайти через SSH. Но изначально новый пользователь лишён возможности выполнять администрирование сервера, и чтобы дать ему такую возможность, нужно написать в консоли:

Код

usermod -aG sudo kamikadze9705

Это означает, что пользователя kamikadze9705 нужно добавить в группу sudo, которая как раз и даёт право действовать от имени администратора. Всё, теперь наш новый пользователь стал полноценным, и можно пробовать зайти им на сервер через программу PuTTY. Только нужно не забыть, что мы сменили 22-й номер порта на новый, и изменить его в настройках программы, иначе зайти не получится. Меняем порт и заходим с новым логином и паролем. А теперь внимание! Любому другому пользователю, кроме root, перед вводом администраторских команд, нужно писать слово "sudo". То есть, из-под пользователя root мы писали:

Код

apt install vsftpd

, а из-под любого другого пользователя, нужно писать:

Код

sudo apt install vsftpd

И кроме этого, система ещё и попросит ввести пароль (пароль этого пользователя, а не root-а). Это, конечно, неудобно, но так нужно для обеспечения безопасности сервера.
Итак, мы зашли на сервер под новым пользователем. Но ведь старый пользователь, root, никуда не делся, и под ним тоже можно зайти. А мы для безопасности хотели, чтобы было нельзя. Значит, пользователя root нужно как-то удалить. Но удалить его в системе невозможно, а возможно только отключить. Делается это удалением пароля. И если мы выполняем администраторские команды, привыкаем каждый раз в начале строки писать слово sudo, а также вводить свой пароль:

Код

sudo passwd -l root

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

Код

sudo apt update

При этом система обновляет информацию о доступных обновлениях и сообщает нам в ответ, сколько пакетов может быть обновлено. Затем мы пишем:

Код

sudo apt upgrade

При этом система запускает обновление и просит нас подтвердить данную операцию. Подтверждаем нажатием клавиши "Y" и видим, как по экрану побежало много букв. Это началось обновление системы, чтобы на нашем сервере работали самые последние, самые безопасные и самые модные версии программ. Ждём минут 5. Теперь, для упрощения работы на сервере, устанавливаем чудо-программу, которая сделает нашу консоль намного более наглядной и удобной. Эта программа называется Midnight Commander. Ничего не напоминает? Устанавливается она как обычно:

Код

sudo apt install mc

, после чего запускается:

Код

mc

В первый раз эту программу нужно запускать именно так и именно от любого другого пользователя, кроме root. После чего можно выходить из неё нажатием клавиши F10 и запускать в администраторском режиме, чтобы были доступны все возможности:

Код

sudo mc

Если Вы уже смирились с тем, что работать на сервере можно только через командную строку, то увидев эту программу Вы будете удивлены. Она похожа на программу Total Commander, только более простую её версию, но всё равно это намного лучше, чем просто командная строка. Здесь можно лазать по каталогам файловой системы, смотреть, какие файлы там лежат, открывать их для просмотра клавишей F3, открывать их для редактирования клавишей F4, копировать клавишей F5, перемещать F6, создавать новые каталоги F7, удалять F8, и радоваться, радоваться, радоваться, как легко и быстро мы поменяли, поперемещали и поудаляли много разных файлов, которые были нужны для работы нашего сервера! Что ещё раз подтверждает общий закон нашей жизни: больше свободы — больше ответственности.

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

[indеx]

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

» Кликните сюда для просмотра оффтоп текста.. «

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

Код

apt install nginx

, после чего, как обычно, спросят подтверждение, и побегут по экрану буквы, означающие, что программа устанавливается.
После завершения установки, веб-сервер сразу же начинает работать. И на наш сайт сразу же можно зайти из браузера. Допустим, адрес нашего сайта: example.com. Вводим в браузере этот адрес и видим страницу, которая всегда появляется после установки программы. То есть, это не наш сайт, а просто "страница-заглушка", назначение которой просто показать, что сайт работает:

» Кликните сюда для просмотра оффтоп текста.. «

Однако, этот веб-сервер Nginx, в отличие от Apache, не умеет работать с файлами PHP. Поэтому нам нужно установить ещё одну программу, которая это умеет. Называется она php-fpm, и устанавливается обычным уже для нас способом:

Код

apt install php7.0-fpm

Вот теперь наш веб-сервер сможет работать с файлами PHP. Но нам и этого мало. Нужна же ещё база данных, а точнее, сервер баз данных, а ещё точнее, СУБД (система управления базами данных) под названием MySQL. Это та, которая с красивым языком. Ставим её тоже обычным способом:

Код

apt install mysql-server

, за исключением лишь того, что во время установки нам нужно будет придумать и ввести пароль учётной записи администратора 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. Соответственно, нужно сделать его таковым. Для этого через консоль даём серверу команду:

Код

chown kamikadze9705 /var/www/html

, что в переводе означает: "Сервер, будь добр, сделай пожалуйста пользователя kamikadze9705 владельцем папки /var/www/html". И сервер тут же всё сделает, на то он и сервер. После чего наш файл-архив легко и непринуждённо закачается в эту папку. Теперь нам нужно его распаковать. Для этого установим на сервер ещё одну программу-архиватор под одноимённым названием 7z:

Код

apt install p7zip-full

Программа устанавливается, и мы сразу же используем её, чтобы разархивировать наш архив с файлами сайта. Но перед этим удалим тот файл, что был в этой папке до закачки архива. Это тот файл, в котором написана страница-заглушка, и он нам больше не нужен. Не помню, как он называется, я его уже удалил Короче говоря, разархивируем наш архив... Стоп! Я же сейчас нахожусь в программе MC, запущенной от имени администратора, а значит, все файлы, созданные в системе, будут принадлежать пользователю root, и получить к ним доступ от других пользователей будет невозможно. Значит, сначала выходим из программы MC, и снова заходим в неё, только не от имени администратора, а от своего имени, kamikadze9705:

Код

mc

Затем, открываем чёрный экран нажатием Ctrl+O и вводим команду для разархивирования файла:

Код

7z x arhiv.7z

, где 7z — программа-архиватор, которую мы установили,
буква "x" — означает, что нужно не ЗАархивировать, а именно РАЗархивировать,
и arhiv.7z — это имя нашего файла-архива, содержащего файлы сайта.
После ввода команды по экрану побегут буквы, после чего в папке появятся файлы нашего сайта. И с наивной надеждой, что сайт наш наконец-то заработает на VPS-хостинге, мы идём спать.

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

[indеx]

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

Код

ls -l /var/www/html

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

Код

drwx------  2 kamikadze9705 kamikadze9705      4096 Jul 24 14:13 css
-rw-rw-r--  1 kamikadze9705 kamikadze9705     10296 May 21 13:50 index.html

Каждая строка показывает информацию об одном файле или каталоге, находящемся в каталоге /var/www/html. И мы видим, что все файлы и каталоги принадлежат пользователю kamikadze9705 и группе с таким же названием kamikadze9705. Теперь давайте рассмотрим, собственно, значения прав доступа. У каталогов эти значения равны:

Код

drwx------

, а у файлов:

Код

-rw-rw-r--

Что это значит?
Первая буква "d" означает, что это каталог (directory), понятно.
Затем идут три блока по три символа для трёх видов субъектов: 1) владелец, 2) группа, 3) все остальные.
То есть, у каталога css права:

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

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

Код

user www-data;

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

Код

usermod -g kamikadze9705 www-data

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

Код

chmod -R 770 /var/www/html

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

Код

ls -l /var/www/html

и видим, что они действительно изменились.
Так, теперь проверяем, как работает сайт...
Картинки показываются, форматирование правильное и цветастое всё, цветастое!
Ура! Теперь точно ура!
Продолжение следует...

[indеx]

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

Код

apt install zip

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

Код

unzip arhiv.ZIP

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

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

Код

pstree

Результат выглядит так:

» Кликните сюда для просмотра оффтоп текста.. «

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

Код

include /etc/nginx/sites-enabled/*;

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

» Кликните сюда для просмотра оффтоп текста.. «

Код

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# http://wiki.nginx.org/Pitfalls
# http://wiki.nginx.org/QuickStart
# http://wiki.nginx.org/Configuration
#
# Generally, you will want to move this file somewhere, and start with a clean
# file but keep this around for reference. Or just disable in sites-enabled.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # SSL configuration
    #
    # listen 443 ssl default_server;
    # listen [::]:443 ssl default_server;
    #
    # Note: You should disable gzip for SSL traffic.
    # See: https://bugs.debian.org/773332
    #
    # Read up on ssl_ciphers to ensure a secure configuration.
    # See: https://bugs.debian.org/765782
    #
    # Self signed certs generated by the ssl-cert package
    # Don't use them in a production server!
    #
    # include snippets/snakeoil.conf;

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    include snippets/fastcgi-php.conf;
    #
    #    # With php7.0-cgi alone:
    #    fastcgi_pass 127.0.0.1:9000;
    #    # With php7.0-fpm:
    #    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny all;
    #}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#    listen 80;
#    listen [::]:80;
#
#    server_name example.com;
#
#    root /var/www/example.com;
#    index index.html;
#
#    location / {
#        try_files $uri $uri/ =404;
#    }
#}

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

» Кликните сюда для просмотра оффтоп текста.. «

Код

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        try_files $uri $uri/ =404;
    }
}

То есть, осталось всего 10 скромненьких строчек, совсем не страшных и даже очень милых

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

[indеx]

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

Код

    #location ~ \.php$ {
    #    include snippets/fastcgi-php.conf;
    #
    #    # With php7.0-cgi alone:
    #    fastcgi_pass 127.0.0.1:9000;
    #    # With php7.0-fpm:
    #    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    #}

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

Код

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

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

Код

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}

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

Код

systemctl restart nginx

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

» Кликните сюда для просмотра оффтоп текста.. «

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

mysqli_connect function does not exist, is mysqli extension installed?

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

Функция mysqli_connect не существует, установлено ли расширение mysqli?

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

Код

apt install php7.0-mysqli

Теперь перезапускаем PHP:

Код

systemctl restart php7.0-fpm

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

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

[indеx]

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

» Кликните сюда для просмотра оффтоп текста.. «

Что означает: "Отказано в доступе для пользователя..." Вот это уже действительно ответ от СУБД 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 -u root -p

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

» Кликните сюда для просмотра оффтоп текста.. «

Это означает, что мы подключились к MySQL через консоль. И теперь всё, что мы вводим в консоли, будет являться не командами для операционной системы Ubuntu, а командами для СУБД MySQL. То есть, теперь нам нужно писать команды на другом языке, на языке SQL, который понравился нам своей красотой. Как же будет выглядеть на этом языке команда создания новой базы данных? А вот как:

Код

CREATE DATABASE `my_db` CHARACTER SET utf8 COLLATE utf8_general_ci;

Что означает "Создать базу данных с именем my_db и с использованием кодировки utf8". Кодировка — это способ кодирования символов в компьютере. Кодировки бывают разные, но UTF8 — это универсальная кодировка, которая всё шире и шире используется в сети. Более подробно мы будем разбираться с кодировкой далее. А пока нужно обратить внимание на кавычки, в которые заключено имя базы данных my_db. Эти кавычки не обычные, а обратные, их можно ввести с клавиатуры, если нажать кнопку с буквой "ё", только в английской раскладке. Если ввести другие кавычки, то MySQL не примет у нас команду. Если же кавычки правильные, то MySQL ответит:

Код

Query OK, 1 row affected (0.00 sec)

» Кликните сюда для просмотра оффтоп текста.. «

Что означает "Запрос принят, задействована 1 строка". То есть, база данных с именем my_db создана. Это то, чего нам не хватало, и из-за чего возникала ошибка. Указываем имя новой базы данных my_db в файле config.php, сохраняем файл и снова обновляем страницу. В результате снова видим новую ошибку:

» Кликните сюда для просмотра оффтоп текста.. «

Которую рассмотрим в следующий раз.

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

[indеx]

Основное сообщение в тексте ошибки следующее:

Код

Table 'my_db.phpbb_ext' doesn't exist

Что переводится как: "Таблица '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:

» Кликните сюда для просмотра оффтоп текста.. «

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

» Кликните сюда для просмотра оффтоп текста.. «

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

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

[indеx]

Итак, текст ошибки:

Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'my_db.s.session_viewonline' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by [1055]

Вкратце это означает, что какой-то написанный в нашем сайте запрос к базе данных несовместим с одной настройкой 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" напишем следующий запрос:

Код

SELECT @@GLOBAL.sql_mode;

Затем жмём кнопку "Execute" ("Выполнить") и видим следующий результат:

» Кликните сюда для просмотра оффтоп текста.. «

После чего копируем этот результат нажатием правой кнопки мыши и выбором пункта "Copy Field" (Скопировать поле):

» Кликните сюда для просмотра оффтоп текста.. «

Затем вставляем в блокнот и видим:

Код

'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FO
R_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

Такое значение имеет настройка сейчас. А нам нужно было выключить only_full_group_by. Смотрим, в самом начале строки как раз написано ONLY_FULL_GROUP_BY. Попробуем убрать это и записать изменённую строку. Значит, новая строка у нас получается такая:

Код

'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

Записываем её следующим образом... Стираем "SELECT @@GLOBAL.sql_mode;" и пишем на том же месте:

Код

SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

В конце ставим точку с запятой, снова нажимаем кнопку "Execute" и видим результат:

» Кликните сюда для просмотра оффтоп текста.. «

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

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

[indеx]

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

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

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

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

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

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

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

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

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

[indеx]

Чтобы работало несколько сайтов, нужно настроить веб-сервер nginx. А именно, в настройках нужно для каждого сайта создать свой раздел "server". Где у нас находится раздел "server"? В файле /etc/nginx/sites-enabled/default. И вот как он выглядит:

Код

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}

Этот один раздел 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, будет отправлять пользователя на данный сайт.
Далее идёт блок:

Код

    location / {
        try_files $uri $uri/ =404;
    }

Который означает, что все файлы, находящиеся в каталоге /var/www/html и в его подкаталогах, должны отправляться браузеру.
Следующий блок:

Код

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }

Означает, что все файлы с расширением .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 {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}

А затем исправим значения на нужные нам.
То есть, в первой копии раздела 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.

Итого, у нас получится:

» Кликните сюда для просмотра оффтоп текста.. «

Код

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/site1.ru;
    index index.html;
    server_name site1.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site2.ru;
    index index.html;
    server_name site2.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}

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

Код

systemctl restart nginx

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

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

[indеx]

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

Код

reboot now

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

Код

[mysqld]
sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_A
UTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Затем сохранить файл и перезапустить MySQL:

Код

systemctl restart mysql

После этого ошибка больше не появится даже после рестарта сервера.

[indеx]

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

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

[indеx]

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

Код

apt install letsencrypt

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

Да, я совсем забыл, что такой сертификат может быть выдан для одного домена и для одного поддомена. Это означает, что мы можем получить один общий сертификат для site1.ru и для www.site1.ru, что очень удобно, ибо это одно и то же. Но поддомен www.site1.ru не описан у нас в настройках nginx, а описан только домен site1.ru. Давайте опишем и поддомены для каждого из двух доменов. Итого у нас получится 4 раздела server:

» Кликните сюда для просмотра оффтоп текста.. «

Код

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/site1.ru;
    index index.html;
    server_name site1.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site1.ru;
    index index.html;
    server_name www.site1.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site2.ru;
    index index.html;
    server_name site2.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site2.ru;
    index index.html;
    server_name www.site2.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}

То есть, два домена 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 нужно добавить блок:

Код

    location ~ /.well-known {
        allow all;
    }

Такой блок нужно добавить для каждого раздела server. И это делается только на время получения сертификата, а затем этот блок можно будет удалить. В итоге файл /etc/nginx/sites-available/default будет содержать следующие настройки:

» Кликните сюда для просмотра оффтоп текста.. «

Код

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/site1.ru;
    index index.html;
    server_name site1.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ /.well-known {
        allow all;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site1.ru;
    index index.html;
    server_name www.site1.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ /.well-known {
        allow all;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site2.ru;
    index index.html;
    server_name site2.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ /.well-known {
        allow all;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    root /var/www/site2.ru;
    index index.html;
    server_name www.site2.ru;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ /.well-known {
        allow all;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}

И теперь, когда мы всё подготовили, давайте получим сертификаты. Для этого введём в консоли следующую команду:

Код

letsencrypt certonly -a webroot --webroot-path /var/www/site1.ru -d site1.ru -d www.site1.ru

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

Код

letsencrypt certonly -a webroot --webroot-path /var/www/site2.ru -d site2.ru -d www.site2.ru

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

[indеx]

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

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

Код

ln -s /etc/nginx/sites-available/site1.ru /etc/nginx/sites-enabled/site1.ru

Код

ln -s /etc/nginx/sites-available/site2.ru /etc/nginx/sites-enabled/site2.ru

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

Код

systemctl restart nginx

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

» Кликните сюда для просмотра оффтоп текста.. «

Код

server {
    listen 80;
    listen [::]:80;
    server_name site1.ru;
    root /var/www/site1.ru;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ /.well-known {
        allow all;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    server_name www.site1.ru;
    return 301 http://site1.ru$request_uri;
    server_tokens off;
}

» Кликните сюда для просмотра оффтоп текста.. «

Код

server {
    listen 80;
    listen [::]:80;
    server_name site2.ru;
    root /var/www/site2.ru;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ /.well-known {
        allow all;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    }
}
server {
    listen 80;
    listen [::]:80;
    server_name www.site2.ru;
    return 301 http://site2.ru$request_uri;
    server_tokens off;
}

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

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

[indеx]

...полученных 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 и после этого запустим генерацию параметров:

Код

openssl dhparam -out /etc/ssl/dh/dh.pem 2048

Процесс генерации будет сопровождаться выводом на экран точек и плюсиков, означающих для нас только то, что процесс ещё не закончился. Это может занять несколько минут, но для повышения безопасности наших сайтов, стоит подождать, тем более если это единственный раз. В результате, в каталоге /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:

» Кликните сюда для просмотра оффтоп текста.. «

Код

# редирект с http на https и сразу без www
server {
    listen 80;
    listen [::]:80;
    server_name site1.ru www.site1.ru;
    return 301 https://site1.ru$request_uri;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
}

# редирект по https с www на без www
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    ssl_certificate /etc/letsencrypt/live/site1.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.ru/privkey.pem;
    ssl_dhparam /etc/ssl/dh/dh.pem;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_stapling on; # Разрешение прикрепления сервером OCSP-ответов
    ssl_stapling_verify on; # Разрешение проверки сервером OCSP-ответов
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    return 301 https://site1.ru$request_uri;
}

# основной раздел, выдающий файлы
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    ssl_certificate /etc/letsencrypt/live/site1.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.ru/privkey.pem;
    ssl_dhparam /etc/ssl/dh/dh.pem;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_stapling on; # Разрешение прикрепления сервером OCSP-ответов
    ssl_stapling_verify on; # Разрешение проверки сервером OCSP-ответов
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    root /var/www/site1.ru;
    index index.php index.html;
    location / {
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    }
}

Это содержимое файла /etc/nginx/sites-available/site1.ru. Для сайта же site2.ru настройки будут располагаться в своём файле /etc/nginx/sites-available/site2.ru и будут выглядеть точно так же, за исключением того, что домен site1.ru заменён на домен site2.ru.
Всё, теперь перезапускаем nginx:

Код

systemctl restart nginx

И проверяем, как работают сайты. В браузере набираем http://site1.ru — попадаем на https://site1.ru с замочком в начале адресной строки, что означает, что наш сайт использует теперь защищённое подключение. Затем пробуем набрать http://www.site1.ru и https://www.site1.ru. В обоих случаях мы также попадаем на https://site1.ru, как мы и хотели. Сайт site2.ru работает у нас точно так же. И теперь наши сайты будут иметь выше рейтинг в поисковых системах не только из-за объединения доменов с www и без www, но и из-за использования защищённого соединения с доверенным SSL-сертификатом.

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

[indеx]

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

Код

letsencrypt renew

и программа автоматически обновляет все сертификаты, находящиеся в папке /etc/letsencrypt/live, выдавая на экран вот такой ответ:

Код

Processing /etc/letsencrypt/renewal/site1.ru.conf
Processing /etc/letsencrypt/renewal/site2.ru.conf

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/site1.ru/fullchain.pem (skipped)
  /etc/letsencrypt/live/site2.ru/fullchain.pem (skipped)
No renewals were attempted.

Этот ответ означает, что наши сертификаты не были обновлены, т.к. время их обновления ещё не подошло. Это и понятно, ведь мы только недавно их получили. На самом деле сертификат обновляется только если до окончания срока его действия осталось 30 дней или меньше. Но самому следить за этими сроками не очень удобно. Было бы неплохо, если бы команда обновления сертификатов запускалась в системе как-нибудь автоматически и регулярно, например, раз в неделю, чтобы сертификаты сами вовремя обновлялись, и чтобы нам не нужно было думать и помнить об этом. И оказывается, такая возможность есть. Называется эта возможность — программа Cron. Она постоянно работает и выполняет указанные нами команды по указанному нами расписанию. Давайте сразу и составим такое расписание. Для этого, от имени root введём команду:

Код

crontab -e

Откроется редактор текстовых файлов, в котором каждая строка — это отдельное задание. Выглядит эта строка, например, так:

Код

11 5 * * 1 letsencrypt renew

В этой строке сначала идут 5 числовых значений (или звёздочка), а затем — команда. Эти значения по порядку означают следующее:

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

То есть, в данном случае команда "letsencrypt renew" будет выполняться каждый понедельник в 5:11 утра. Почему именно ранним утром? Потому что в это время посещаемость сайтов обычно самая низкая, нагрузка на сервер, соответственно, тоже. Поэтому все подобные вещи, связанные с администрированием сервера, обновлениями и т.п. обычно проводят в это время. Но в данном случае, чтобы обновлённые сертификаты начали использоваться, нужно ещё и перезагрузить веб-сервер nginx. То есть, нужно выполнить ещё одну команду. Эту команду можно вставить второй строкой, указав время выполнения, например, на 5 минут позже. Но мы сделаем ещё лучше — создадим скрипт, т.е. файл, содержащий сразу несколько команд. Например, скрипт следующего содержания:

Код

#!/bin/bash
date +%Y-%m-%d\ \ %H:%M:%S
echo "—————————————————————————————————————————————————————"
letsencrypt renew
systemctl reload nginx
echo ''
echo ''
echo ''

Где первая строка — это комментарий, но комментарий не простой. Это директива, указывающая, какая программа будет выполнять этот скрипт. В данном случае это программа Bash. Вторая строка — это вывод на экран текущей даты и времени. Третья строка — просто вывод линии на экран. Четвёртая строка — это наша команда обновления сертификатов. Пятая строка — перезагрузка nginx. А строки с шестой по восьмую — это просто отступ высотой в три строки, чтобы в файле истории расстояние между записями было сразу заметное (будет понятно ниже). Сохраним этот файл с названием, например, ssl_le_renew.bash в папке /home/kamikadze9705/ssl. И чтобы этот скрипт мог выполняться, как программа, нужно дать ему право на исполнение. Делается это так:

Код

chmod +x /home/kamikadze9705/ssl/ssl_le_renew.bash

И теперь если в командной строке мы напишем

Код

/home/kamikadze9705/ssl/ssl_le_renew.bash

, то этот скрипт выполнится, т.е. произойдёт запрос на обновление сертификатов и затем перезагрузится nginx. Значит теперь мы можем прописать запуск этого файла в программе Cron. Запускаем crontab -e и меняем строку на следующую:

Код

11 5 * * 1 /home/kamikadze9705/ssl/ssl_le_renew.bash

Теперь по расписанию будет запускаться наш скрипт. Но мы сделаем ещё круче! Мы направим вывод результатов не на экран, а в файл /home/kamikadze9705/ssl/log.txt, чтобы в этом файле сохранялась история запусков обновлений, т.е. это будет лог-файл. Для этого дополним строку, чтобы получилось следующее:

Код

11 5 * * 1 /home/kamikadze9705/ssl/ssl_le_renew.bash >> /home/kamikadze9705/ssl/log.txt

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

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

[indеx]

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

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

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

Код

iptables -L

которая выведет нам на экран следующую информацию:

Код

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

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

Код

iptables -A INPUT -p tcp --dport 55555 -j ACCEPT

Запрещаем все остальные входящие порты:

Код

iptables -P INPUT DROP

После этого на нашем сервере будет открыт только один входящий порт — 55555, для подключения SSH. А потры 80 и 443, используемые для всех сайтов, будут закрыты. Проверяем — пробуем зайти на наши сайты site1.ru и site2.ru и видим, что они действительно недоступны. Теперь аналогично открываем два этих порта:

Код

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Код

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Снова проверяем сайты и видим, как они стали доступны. Давайте посмотрим, как выглядят при этом настройки iptables:

Код

iptables -L -n --line-numbers

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

Код

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:55555
2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

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

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

[indеx]

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

Сообщение отредактировал indеx - 3.08.2017 - 19:24

[indеx]

Забыли, забыли... Мы же ещё к серверу MySQL подключаемся удалённо через SSH-туннель. Значит нужно открыть ещё один порт — 3306. Причём, открыть так, чтобы доступ к серверу MySQL был только с локального компьютера, а из Интернета его не было. Пишем в командной строке:

Код

iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT

Это разрешит входящие подключения к серверу MySQL через SSH-туннель. Но передача информации между программой-клиентом и программой-сервером MySQL организована двумя подключениями, одно входящее, другое исходящее. То есть, нужно открыть ещё и исходящие подключения. Пишем:

Код

iptables -A OUTPUT -p tcp -d 127.0.0.1 -j ACCEPT

Этим мы открываем исходящие подключения не только с порта 3306, но и со всех остальных портов. Однако, не для всех пунктов назначения, а только для локального компьютера (IP-адрес назначения = 127.0.0.1), т.е. для подключений, не выходящих за пределы сервера. А вот подключения, выходящие за пределы сервера, нужно закрыть, чтобы наши секреты никто не узнал Для этого пишем сначала:

Код

iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT

а затем:

Код

iptables -P OUTPUT DROP

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

Код

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

И для ещё большего спокойствия давайте запретим все перенаправления (forward):

Код

iptables -P FORWARD DROP

После внесения всех этих правил давайте проверим, что же у нас получилось:

Код

iptables -L -n --line-numbers

На экране появится следующая информация:

Код

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:60201
2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
4    ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0            tcp dpt:3306
5    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED

Chain FORWARD (policy DROP)
num  target     prot opt source               destination

Chain OUTPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     tcp  --  0.0.0.0/0            127.0.0.1
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED

После чего убеждаемся, что всё работает — пробуем подключиться к серверу MySQL и проверяем работу сайтов. Если всё работает, то это означает, что мы настроили так называемый файрволл (firewall).

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

[indеx]

Настроили-то настроили, но оказывается, все эти настройки сбрасываются (пропадают), если перезагрузить сервер. Упс. В Интернете есть несколько разных советов, как сделать так, чтобы они не пропадали, но мне понравился один. Он заключается в том, что настройки сохраняются в текстовом файле, а при запуске сети (когда сервер запускается) эти настройки восстанавливаются из файла. Для этого файла давайте создадим каталог iptables в нашем домашнем каталоге:

Код

mkdir /home/kamikadze9705/iptables

И теперь, собственно, сохраним наши настройки в файле /home/kamikadze9705/iptables/rules.txt:

Код

iptables-save > /home/kamikadze9705/iptables/rules.txt

Теперь откроем этот файл и посмотрим, что же там сохранилось. Видим следующее:

» Кликните сюда для просмотра оффтоп текста.. «

Код

# Generated by iptables-save v1.6.0 on Sun Aug  6 13:43:24 2017
*filter
:INPUT DROP [4:281]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp -m tcp --dport 60201 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 127.0.0.1/32 -p tcp -m tcp --dport 3306 -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -d 127.0.0.1/32 -p tcp -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED -j ACCEPT
COMMIT
# Completed on Sun Aug  6 13:43:24 2017

То есть, именно те правила, что были у нас на экране. Отлично. Теперь нужно, чтобы эти правила загружались из файла при запуске сети. Для этого в каталоге /etc/network/if-up.d создадим файл с названием 0000-iptables.bash и напишем в нём следующие две строки:

Код

#!/bin/bash
iptables-restore < /home/kamikadze9705/iptables/rules.txt

Сохраним файл и попробуем перезагрузить сервер:

Код

reboot now

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

Код

iptables -L -n --line-numbers

и видим на экране:

» Кликните сюда для просмотра оффтоп текста.. «

Код

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:60201
2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
4    ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0            tcp dpt:3306
5    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED

Chain FORWARD (policy DROP)
num  target     prot opt source               destination

Chain OUTPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     tcp  --  0.0.0.0/0            127.0.0.1
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED

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

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

[Айя-Софи]

» Кликните сюда для просмотра оффтоп текста.. «

Так все мудрено

Сообщение отредактировал Айя-Софи - 7.08.2017 - 15:14

[Эллочка]

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

[Apokaliptius]

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

» Кликните сюда для просмотра оффтоп текста.. «

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

Сообщение отредактировал Apokaliptius - 7.08.2017 - 15:17

[Айя-Софи]

» Кликните сюда для просмотра оффтоп текста.. «

Apokaliptius ты такой умный?
Боже!…куда я попала?

Сообщение отредактировал Айя-Софи - 7.08.2017 - 15:13

[Apokaliptius]

» Кликните сюда для просмотра оффтоп текста.. «

Apokaliptius ты такой умный?
Боже!…куда я попала?

» Кликните сюда для просмотра оффтоп текста.. «

Я пытаюсь учиться...
Не мешай!
Нафлудили уже на пол страницы!

Сообщение отредактировал Apokaliptius - 7.08.2017 - 15:50

[indеx]

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

Продолжаем...
Файрвол мы настроили, а именно, закрыли все внешние порты, кроме тех, что нам нужны. В дальнейшем мы, возможно, будем вносить какие-то дополнения в эти правила, но пока этого нам достаточно.
Теперь давайте сделаем защиту от той самой кнопки F5, с помощью которой любой дурак может задудосить наш сайт. Защита эта делается в настройках веб-сервера nginx. Именно из-за таких возможностей и был выбран nginx вместо более широко известного apache. Каким способом делается? Просто ограничивается частота запросов от одного клиента, например, максимум один запрос в секунду. Открываем файл /etc/nginx.nginx/conf для редактирования и в разделе http добавляем одну строку:

Код

limit_req_zone $binary_remote_addr zone=max:10m rate=1r/s;

Эта строка означает, что создана зона под названием "max", в которой от одного клиента разрешён максимум один запрос в секунду. Название зоны можно выбрать другое, количество запросов в секунду тоже на Ваше усмотрение. Теперь в эту зону нужно включить наши сайты. Открываем настройки сайта site1.ru — файл /etc/nginx/sites-available/site1.ru. И добавляем в него две одинаковые строки:

Код

limit_req zone=max burst=3;

в два раздела location. В результате файл получается следующим:

» Кликните сюда для просмотра оффтоп текста.. «

Код

# редирект с http на https и сразу без www
server {
    listen 80;
    listen [::]:80;
    server_name site1.ru www.site1.ru;
    return 301 https://site1.ru$request_uri;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
}

# редирект по https с www на без www
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    ssl_certificate /etc/letsencrypt/live/site1.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.ru/privkey.pem;
    ssl_dhparam /etc/ssl/dh/dh.pem;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_stapling on; # Разрешение прикрепления сервером OCSP-ответов
    ssl_stapling_verify on; # Разрешение проверки сервером OCSP-ответов
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    return 301 https://site1.ru$request_uri;
}

# основной раздел, выдающий файлы
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    ssl_certificate /etc/letsencrypt/live/site1.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.ru/privkey.pem;
    ssl_dhparam /etc/ssl/dh/dh.pem;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_stapling on; # Разрешение прикрепления сервером OCSP-ответов
    ssl_stapling_verify on; # Разрешение проверки сервером OCSP-ответов
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    root /var/www/site1.ru;
    index index.php index.html;
    location / {
        limit_req zone=max burst=3;
        try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        limit_req zone=max burst=3;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    }
}

Значение burst=3 в каждой из этих строк означает, что допустимы кратковременные всплески в 3 раза больше, т.е. 3 запроса в секунду. Но среднее значение частоты запросов всё равно будет не более чем 1r/s. Теперь сохраняем файл и перезапускаем nginx:

Код

systemctl restart nginx

Заходим на наш сайт site1.ru и пробуем зажать кнопку F5 на клавиатуре. В результате получаем на экране сообщение:

» Кликните сюда для просмотра оффтоп текста.. «

То есть, при частом обновлении сайт становится нам недоступен. Вопрос: доступен ли он в это время для других? Пробуем... Заходим на сайт с телефона. Теперь снова зажимаем кнопку F5 на клавиатуре компьютера и держим. Пока держим F5, обновляем страницу на телефоне и видим, что с телефона сайт доступен. Продолжаем держать F5, снова обновляем на телефоне и снова видим, что для других клиентов сайт вполне доступен. То есть, сайт становится недоступен только для того, кто его атакует. Для другого сайта защиту делаем точно так же. Всё, защиту от самой примитивной DDoS-атаки мы сделали.

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

[indеx]

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

Код

limit_req zone=max burst=3;

Эту строку нужно прописывать только в разделе location, который обрабатывает php-файлы, т.е. вот здесь:

Код

    location ~ \.php$ {
        limit_req zone=max burst=3;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    }

А в разделе, обрабатывающем все остальные файлы (html, css, картинки) эту строку прописывать не нужно. То есть, должно быть так:

Код

    location / {
        try_files $uri $uri/ =404;
    }

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

[indеx]

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

php-mbstring
php-curl
php-gd
php-memcache
php-cli
php-mcrypt

То есть, установка выглядит следующим образом:

Код

apt install php-mbstring php-curl php-gd php-memcache php-cli php-mcrypt

После чего перезапустил PHP:

Код

systemctl restart php7.0-fpm

И все функции на сайте сразу же заработали.
Кроме одной функции 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. Устанавливаем её:

Код

apt install ssmtp

Теперь настраиваем файл /etc/ssmtp/ssmtp.conf. Удаляем оттуда всё полностью и добавляем следующие строки:

Код

root=support@site1.ru
mailhub=smtp.yandex.ru:465
UseTLS=Yes
AuthUser=support@site1.ru
AuthPass=MyPassword1234
hostname=localhost
FromLineOverride=Yes

Сохраняем изменения. Теперь редактируем второй файл /etc/ssmtp/revaliases. Тоже удаляем оттуда всё и вставляем строки:

Код

root:support@site1.ru:smtp.yandex.ru:465
kamikadze9705:support@site1.ru:smtp.yandex.ru:465
www-data:support@site1.ru:smtp.yandex.ru:465

Сохраняем изменения. Теперь нужно сделать так, чтобы PHP знал, что для отправки письма нужно запускать именно программу ssmtp. Открываем файл /etc/php/7.0/fpm/php.ini, находим там строку:

Код

sendmail_path =

И исправляем её так, чтобы получилось:

Код

sendmail_path = /usr/sbin/ssmtp -t

Сохраняем изменения. Перезапускаем PHP:

Код

systemctl restart php7.0-fpm

И пробуем отправить тестовое письмо через PHP. Для этого в корне сайта site1.ru (в каталоге /var/www/site1.ru) создаём файл sendmail.php, и пишем в нём:

Код

<?php
if (mail("support@site2.ru", "Тема письма", "Текст письма", "support@site1.ru"))
    echo "Письмо отправлено"
else
    echo "Ошибка при отправке письма. Письмо не отправлено";
?>

То есть, мы пытаемся с ящика support@site1.ru отправить письмо на ящик support@site2.ru.
Сохраняем файл. И запускаем его через браузер, введя в адресной строке:

Код

https://site1.ru/sendmail.php

Если в браузере на странице появилась надпись "Письмо отправлено", то проверяем ящик support@site2.ru на наличие пришедшего письма. Если всё было сделано правильно, то письмо придёт. Однако, если мы попробуем указать в качестве ящика отправителя не support@site1.ru, а любой другой ящик, то Яндекс откажется отправлять такое письмо. Адрес отправителя в письме должен точно совпадать с адресом на данном аккаунте, иначе, пользователь, получивший письмо, будет обманут. И в этом обмане будет участвовать Яндекс, отправивший такое письмо. На месте Яндекса я тоже отказался бы участвовать в таком обмане, ибо мало ли кто и для чего это использует. То есть, с помощью программы ssmtp мы можем отправлять письма только с одного выбранного ящика. И такой способ хорошо подходит для сервера с одним сайтом. Но на нашем сервере два сайта: site1.ru и site2.ru. Эти два сайта в реальной жизни могут иметь совершенно разные адреса. Например, первый сайт у нас shkola-57.ru, а второй — online-porno.ru. И если пользователь, зарегистрировавшийся на сайте Школы №57, получит письмо с ящика mail@online-porno.ru, то это будет выглядеть очень странно. Поэтому для серверов с несколькими сайтами такой способ отправки писем не подходит. До установки программы ssmtp мне это не было известно, т.к. я делаю это впервые. По всей видимости, всё-таки придётся устанавливать для отправки писем свой почтовый сервер, который мы настроим так, чтобы он разрешал отправлять письма с ящиков разных отправителей. Попробуем сделать это в следующий раз.

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

[indеx]

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

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

Код

ClientAliveInterval 7200
ClientAliveCountMax 0

Где 7200 — это кол-во секунд до отключения с момента последней активности, в данном случае = 2 часа.
После чего нужно перезагрузить службу SSH:

Код

systemctl restart ssh

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

[indеx]

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

» Кликните сюда для просмотра оффтоп текста.. «

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

[indеx]

Теперь о настройке почты.
У нас на одном сервере несколько сайтов, и каждый сайт должен отправлять письма со своего почтового ящика, принадлежащего этому же домену. То есть, сайт 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
И т.д...

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

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

Код

adduser u-site1-ru

Код

adduser u-site2-ru

В имени пользователей недопустимы точки, поэтому мы используем дефисы. Также советую перед именем сайта делать какой-нибудь свой префикс (я сделал "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, а также владельцем всех файлов, находящихся внутри:

Код

chown -R u-site1-ru:u-site1-ru /home/u-site1-ru/www

Ведь у нас PHP будет работать именно от имени пользователя u-site1-ru, и если владельцем файлов будет другой пользователь, то PHP не сможет работать с этими файлами.
Но теперь веб-сервер nginx должен знать, что рабочий каталог сайта переместился. А значит, в файле настроек /etc/nginx/sites-available/site1.ru меняем соответствующую строчку:

Код

root /var/www/site1.ru;

на

Код

root /home/u-site1-ru/www;

После чего можно перезапустить nginx:

Код

systemctl restart nginx

И сайт заработает из нового каталога. Но при этом PHP не сможет создавать файлы и делать записи в файлы существующие, т.к. пока у нас ещё нет отдельного процесса PHP, работающего под пользователем u-site1-ru. Значит, создаём такой процесс. Для этого в каталоге /etc/php/7.0/fpm/pool.d создаём файл site1.ru.conf со следующим содержимым:

» Кликните сюда для просмотра оффтоп текста.. «

Код

[site1.ru]
listen = /var/run/php/site1.ru.sock
listen.mode = 0664
; Пользователь и группа, под кoторыми будет работать пул
user = u-site1-ru
group = u-site1-ru
; По умолчанию сокет работает под теми же учетками, что указaны в user/group, nginx должен его читать
; Иногда нужно использовать другие учетные данные
listen.owner = www-data
listen.group = www-data
chdir = /home/u-site1-ru/www
; Под планиpуемую нагрузку проставляем количество процессов
pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 6
; При необходимости
php_admin_value[error_log] = /home/u-site1-ru/logs/php.error.log
php_admin_value[session.save_path] = /home/u-site1-ru/www/tmp
php_admin_value[open_basedir] = "/home/u-site1-ru/www/"
php_admin_value[post_max_size] = 20M
php_admin_value[cgi.fix_pathinfo] = 0

Где строка 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, что у нас там указано? А вот что:

Код

fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;

Соответственно, тоже меняем на:

Код

fastcgi_pass unix:/var/run/php/site1.ru.sock;

Сохраняем файл. После чего перезапускаем PHP и Nginx:

Код

systemctl restart php7.0-fpm

Код

systemctl restart nginx

Заходим на сайт, убеждаемся, что всё работает, и понимаем, что первый этап нашей задачи мы выполнили.

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

[indеx]

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

Теперь второй этап — установить программу почтового сервера postfix и настроить её так, чтобы разные пользователи операционной системы отправляли письма с разных почтовых ящиков.
Установка postfix выполняется один раз обычным способом:

Код

apt install postfix

После чего в файл настроек /etc/postfix/main.cf вносим следующие изменения:
1) удаляем строку

Код

relayhost =

2) строку

Код

mydestination = $myhostname, localhost.$mydomain, $mydomain

меняем на следующую:

Код

mydestination = localhost

3) две строки с параметрами "myhostname" и "mydomain" делаем, чтобы выглядели следующим образом:

Код

myhostname = site1.ru
mydomain = site1.ru

То есть, в обеих строках прописываем один любой домен, настроенный на наш сервер (можно site2.ru).
4) В конец файла добавляем следующие строки:

» Кликните сюда для просмотра оффтоп текста.. «

Код

sender_canonical_maps = hash:/etc/postfix/private/sender_canonical
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/private/sender_relayhost
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/private/sasl_passwd
smtp_sasl_security_options =
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
relayhost = [smtp.yandex.ru]:submission

В результате чего, содержимое файла /etc/postfix/main.cf у нас получается следующее:

» Кликните сюда для просмотра оффтоп текста.. «

Код

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = site1.ru
mydomain = site1.ru
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all


sender_canonical_maps = hash:/etc/postfix/private/sender_canonical
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/private/sender_relayhost
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/private/sasl_passwd
smtp_sasl_security_options =
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
relayhost = [smtp.yandex.ru]:submission

Проверяем, сохраняем файл и перезапускаем почтовый наш сервер postfix:

Код

systemctl restart postfix

С такими настройками наш почтовый сервер не будет отправлять письма сам, а будет подключаться к серверу Яндекс (smtp.yandex.ru) и доверять ему отправку писем. Такой подход лучше использовать, если мы не уверены, что сможем правильно настроить свой почтовый сервер. Ибо при неправильных настройках нашего почтового сервера, отправленные с него письма могут попадать в спам на стороне получателя. Серверы же Яндекс наверняка настроены правильно, что даёт гарантию практически стопроцентной доставки писем. Кроме того, у этого подхода есть ещё одно преимущество, которое я уже описывал выше: Если наш сервер вместе со всеми сайтами вдруг перестанет работать, то письма от наших клиентов мы всё равно сможем получать и отвечать на них, т.к. это будет происходить через серверы Яндекса.
Всё, вот эти настройки делаются один раз, независимо от того, сколько на нашем сервере сайтов.
Теперь давайте сделаем настройки, разруливающие, какие сайты с какого ящика будут отправлять письма.
В каталоге /etc/postfix создаём каталог private, в котором создаём три текстовых файла:

1) sender_canonical
2) sender_relayhost
3) sasl_passwd

И записываем в эти файлы следующие данные:
1) /etc/postfix/private/sender_canonical:

Код

u-site1-ru mail@site1.ru
u-site2-ru mail@site2.ru

2) /etc/postfix/private/sender_relayhost:

Код

mail@site1.ru [smtp.yandex.ru]:465
mail@site2.ru [smtp.yandex.ru]:465

3) /etc/postfix/private/sasl_passwd:

Код

mail@site1.ru mail@site1.ru:Password1234
mail@site2.ru mail@site2.ru:Password5678

То есть, в первом файле прописано, какой пользователь с какого ящика отправляет. Во втором файле прописано, какой ящик к какому серверу подключается (оба к Яндексу). А в третьем для каждого ящика прописано, какой логин и пароль используются для подключения к серверу.
Сохраняем эти файлы, после чего обязательно владельцем каталога /etc/postfix/private (вместе со всеми файлами) делаем пользователя root:

Код

chown -R root:root /etc/postfix/private

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

Код

postmap hash:/etc/postfix/private/sender_canonical
postmap hash:/etc/postfix/private/sender_relayhost
postmap hash:/etc/postfix/private/sasl_passwd

Смотрим, действительно, рядом с этими текстовыми файлами появились три файла красного цвета с названиями: sender_canonical.db, sender_relayhost.db, sasl_passwd.db. Всё нормально, так и должно быть.
И теперь чтобы настройки вступили в силу перезапускаем postfix:

Код

systemctl restart postfix

Теперь нам нужно проверить, отправляют ли разные сайты письма с разных ящиков.
Создаём текстовый файл sendmail.php со следующим содержанием:

Код

<?php
mail("ivan@yandex.ru", "Тест", "Здравствуйте! Это тестовое письмо.");
?>

Заливаем этот файл в корень одного сайта и в корень второго сайта. То есть, в папки /home/u-site1-ru/www и /home/u-site2-ru/www.
Делаем владельцами этих файлов соответствующих пользователей:

Код

chown u-site1-ru:u-site1-ru /home/u-site1-ru/www/sendmail.php

Код

chown u-site2-ru:u-site2-ru /home/u-site2-ru/www/sendmail.php

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

Код

iptables -A OUTPUT -p tcp -d smtp.yandex.ru --dport 465 -j ACCEPT

А затем проверяем, что получилось, командой:

Код

iptables -L -n --line-numbers

И видим на экране:

» Кликните сюда для просмотра оффтоп текста.. «

Код

Chain INPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED
2    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:55555
3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5    ACCEPT     tcp  --  127.0.0.1            0.0.0.0/0            tcp dpt:3306

Chain FORWARD (policy DROP)
num  target     prot opt source               destination

Chain OUTPUT (policy DROP)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state ESTABLISHED
2    ACCEPT     tcp  --  0.0.0.0/0            127.0.0.1
3    ACCEPT     tcp  --  0.0.0.0/0            87.250.250.38        tcp dpt:465
4    ACCEPT     tcp  --  0.0.0.0/0            213.180.204.38       tcp dpt:465
5    ACCEPT     tcp  --  0.0.0.0/0            77.88.21.38          tcp dpt:465
6    ACCEPT     tcp  --  0.0.0.0/0            93.158.134.38        tcp dpt:465
7    ACCEPT     tcp  --  0.0.0.0/0            213.180.193.38       tcp dpt:465

О как! Вместо smtp.yandex.ru мы видим 5 IP-адресов. Это означает, что у Яндекса аж целых 5 машин, принимающих подключения пользователей по протоколу smtp. С таким сверхнадёжным подходом нам действительно не стоит бояться за доставку наших писем. Главное — отправить письмо Яндексу, а он уже разберётся.
И теперь нам важно не забыть сохранить настройки iptables в наш файл, иначе после перезагрузки сервера они сбросятся. Сохраняем:

Код

iptables-save > /home/kamikadze9705/iptables/rules.txt

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

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

Сообщение отредактировал indеx - 16.08.2017 - 21:33

[indеx]

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

Код

AllowUsers kamikadze9705

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

Код

AllowUsers kamikadze9705 u-site1-ru u-site2-ru

Затем сохранить файл и перезапустить SSH:

Код

systemctl restart ssh

[indеx]

Выяснилось, что совет по сохранению конфигурации iptables, описанный в сообщении http://tochek.net/index.php?showtopic=5999...t&p=2436477, а также в конце сообщения http://tochek.net/index.php?showtopic=5999...t&p=2441008, не всегда работает. То есть, новые настройки после перезагрузки не восстанавливаются. Попробовал найти решение самостоятельно и нашёл способ, который сработал.
В каталоге /etc/iptables есть файл rules.v4, в котором прописаны правила iptables. И по всей видимости, именно этот файл используется при восстановлении настроек после перезагрузки. Пробуем сохранить наши настройки в этот файл:

Код

iptables-save > /etc/iptables/rules.v4

а файл 0000-iptables.bash, созданный нами ранее в каталоге /etc/network/if-up.d, удаляем из этого каталога, как не прошедший проверку на надёжность.
Перезагружаем сервер:

Код

reboot now

и смотрим, восстановились ли правила:

Код

iptables -L -n --line-numbers

Да, все правила восстановились. Но вдруг они восстанавливаются не из этого файла, а откуда-нибудь ещё? Чтобы проверить это, давайте удалим переместим этот файл в другое место и перезагрузим сервер. После перезагрузки смотрим — правила не восстановились без этого файла. Значит, это точно тот самый файл. Возвращаем его на своё место /etc/iptables/rules.v4, перезагружаем сервер, проверяем правила и снова видим, что правила восстановились. Берём этот способ на вооружение.

[indеx]

Таким образом получается, что у нас в памяти сервера работают несколько процессов PHP — для каждого сайта свой процесс. Или даже не один? Хм, интересно, а сколько? Давайте посмотрим...
Есть одна команда:

Код

ps aux --sort -rss

которая выводит на экран список всех процессов:

» Кликните сюда для просмотра оффтоп текста.. «

Код

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1075  0.0 20.2 1116364 205888 ?      Ssl  Aug17   1:14 /usr/sbin/mysqld
u-site1+  5179  0.0  3.3 346616 34300 ?        S    Aug17   0:07 php-fpm: pool site1.ru
u-site1+  5181  0.0  3.3 346364 33784 ?        S    Aug17   0:06 php-fpm: pool site1.ru
u-site1+  5180  0.0  3.3 346608 33768 ?        S    Aug17   0:07 php-fpm: pool site1.ru
u-site2+  5182  0.0  3.2 346356 33368 ?        S    Aug17   0:00 php-fpm: pool site2.ru
u-site2+  5184  0.0  3.2 346248 33308 ?        S    Aug17   0:00 php-fpm: pool site2.ru
u-site1+  5337  0.0  3.0 346468 31364 ?        S    Aug17   0:06 php-fpm: pool site1.ru
u-site3+  9615  0.0  2.7 344508 28396 ?        S    06:37   0:03 php-fpm: pool site3.ru
u-site2+  6932  0.0  2.7 344248 27792 ?        S    00:38   0:00 php-fpm: pool site2.ru
u-site3+  5186  0.0  2.7 344436 27672 ?        S    Aug17   0:03 php-fpm: pool site3.ru
u-site2+  5183  0.0  2.7 342180 27668 ?        S    Aug17   0:00 php-fpm: pool site2.ru
root      5175  0.0  2.6 341296 27408 ?        Ss   Aug17   0:05 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
u-site3+  5187  0.0  2.5 342572 26372 ?        S    Aug17   0:03 php-fpm: pool site3.ru
u-site3+  5185  0.0  2.5 342384 26204 ?        S    Aug17   0:03 php-fpm: pool site3.ru
root       671  0.0  2.3 278516 23436 ?        Ssl  Aug17   0:08 /usr/lib/snapd/snapd
u-site5+  5212  0.0  2.2 418812 23128 ?        S    Aug17   0:00 php-fpm: pool site5.ru
u-site5+  5267  0.0  2.2 418812 23060 ?        S    Aug17   0:00 php-fpm: pool site5.ru
u-site5+  5195  0.0  2.2 418812 23008 ?        S    Aug17   0:00 php-fpm: pool site5.ru
u-site5+  5214  0.0  2.2 418748 22988 ?        S    Aug17   0:00 php-fpm: pool site5.ru
u-site5+  5193  0.0  2.2 418748 22628 ?        S    Aug17   0:00 php-fpm: pool site5.ru
u-site5+  5310  0.0  2.1 418812 22244 ?        S    Aug17   0:00 php-fpm: pool site5.ru
u-site4+  5190  0.0  1.3 341576 13504 ?        S    Aug17   0:00 php-fpm: pool site4.ru
www-data  5210  0.0  0.9 194612  9740 ?        S    Aug17   0:04 nginx: worker process
u-site4+  5188  0.0  0.8 341248  8320 ?        S    Aug17   0:00 php-fpm: pool site4.ru
u-site4+  5189  0.0  0.8 341248  8320 ?        S    Aug17   0:00 php-fpm: pool site4.ru
postfix  13751  0.0  0.8  97768  8304 ?        S    16:40   0:00 smtp -t unix -u -c
root     12076  0.0  0.7  52304  7332 pts/0    S+   12:48   0:02 mc
...
...
...

И в этом списке мы можем видеть количество процессов, сколько они занимают памяти и на сколько загружают процессор. Этот список, по всей видимости, упорядочен по объёму занимаемой памяти. И самый большой объём, как мы видим, занимает наша СУБД MySQL — 20% оперативки. Всего на сервере 1 Гб памяти, значит MySQL занимает 200 МБ. Также мы видим, что для одного сайта выделено от 3 до 6 процессов PHP. Это как раз те значения, что мы прописывали в файлах в каталоге /etc/php/7.0/fpm/pool.d. Этот список неполный, там ниже есть ещё процессы, которые занимают меньше памяти. Но сколько же памяти занимают все процессы вместе? Им вообще хватает одного гигабайта, или мало? Давайте узнаем... Есть такая команда:

Код

free

которая выводит на экран кратко:

Код

              total        used        free      shared  buff/cache   available
Mem:        1016028      364904      131664       49552      519460      413600
Swap:             0           0           0

Где мы видим, что всего — 1016028, а используется 364904. Но свободно почему-то всего-лишь 131664. А доступно почему-то 413600. Видимо, доступное уже не считается свободным. А кроме того, есть ещё слово Swap, по всей видимости означающее, что бывает файл подкачки, но на данный момент он не используется (размер 0).
А давайте, чтобы не рисковать переполнением памяти, попробуем подключить к оперативке ещё и файл подкачки. Сколько у нас там свободного места на диске? Проверяем командой:

Код

df

Смотрим на экран:

Код

Filesystem     1K-blocks    Used Available Use% Mounted on
udev              487848       0    487848   0% /dev
tmpfs             101604   10756     90848  11% /run
/dev/vda1       10286264 4727292   5018428  49% /
tmpfs             508012       0    508012   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs             508012       0    508012   0% /sys/fs/cgroup
tmpfs             101604       0    101604   0% /run/user/1000

То есть, из 10 Гигабайт на диске, у нас свободно половина — 5 Гб. Отлично, тогда давайте к 1 Гб оперативки подключим ещё 1 Гб файлом подкачки, что увеличит память в 2 раза. Вводим команду создания файла:

Код

fallocate -l 1G /swapfile

Проверяем — в корне должен появиться файл swapfile. Теперь превращаем этот файл в файл подкачки... Сначала отрубаем к нему доступ всем пользователям, кроме root:

Код

chmod 600 /swapfile

Теперь внутри этого файла создаём файловую систему, используемую специально для файлов подкачки:

Код

mkswap /swapfile

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

Код

swapon /swapfile

Проверяем, что изменилось у нас со свободным местом:

Код

free

Видим явные изменения:

Код

              total        used        free      shared  buff/cache   available
Mem:        1016028      367328      125272       50016      523428      410668
Swap:       1048572           0     1048572

Теперь наш файл используется в системе для расширения оперативной памяти. Но если оставить так, то это дело будет работать только до перезагрузки сервера. А чтобы работало и после перезагрузки, нужно в конец файла /etc/fstab добавить одну строку:

Код

/swapfile none swap sw 0 0

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

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

[indеx]

Небольшая заметка.

По умолчанию PHP обрабатывает скрипты только в таких вставках:

Код

<?php ... ?>

Но для удобства и для эстетики лично мне хочется использовать вставки вот такие:

Код

<? ... ?>

Чтобы такие вставки работали, нужно в файле php.ini найти строку:

Код

short_open_tag = Off

и заменить её на:

Код

short_open_tag = On

Само собой, после этого нужно перезапустить PHP:

Код

systemctl restart php7.0-fpm

[indеx]

Компьютерная техника обычно работает чётко, строго по инструкциям и программам. Но всё-таки иногда случаются непредвиденные ситуации, в результате которых информация на сервере может частично пропасть. Особенно ценной является информация, хранящаяся в базе данных сайта. Например, все наши сообщения на этом форуме хранятся в базе данных сайта tochek.net. И если часть сообщений однажды вдруг пропадёт, то это будет очень печально. Такое, кстати, однажды было на этом форуме. В разделе "Непознанное -> Прочие религии и учения" модератор Сладкая Смерть случайно удалила все темы. А потом заполняла этот раздел вновь созданными с нуля темами. Чтобы такого не происходило, системные администраторы сайтов регулярно делают так называемые дампы базы данных. То есть, сохраняют всю информацию из базы данных в файл, чтобы потом её можно было восстановить из этого файла. База данных коммерческого сайта, хранящая записи о движении денежных средств, ещё более ценна, поэтому её сохраняют обычно каждый день. Мы можем делать это вручную с помощью программы MySQL Workbench, как уже было описано выше, но гораздо удобнее, чтобы это делалось автоматически. А для этого нужна командная строка. Ещё один минус сохранения базы данных через программу Workbench заключается в том, что я подключаюсь ей через SSH-туннель, который из-за своей шифровки сильно снижает скорость передачи данных по сети, и большая база данных будет сохраняться таким способом очень долго. В командной же строке сохранение идёт не через сеть, а в пределах этого же сервера — из базы данных в файл, что проходит намного быстрее при сохранении больших объёмов информации.
Короче говоря, нам нужно уметь делать в командной строке две операции: 1) сохранение БД в файл, 2) восстановление БД из файла.

Сохранение базы данных в файл.
В командной строке сервера пишем:

Код

mysqldump -R -u admin -p dbname > dump.sql

• где:
  -R — параметр, указывающий, что в файл нужно сохранять не только таблицы и view, но и хранимые программы (процедуры и функции);
  admin — имя пользователя СУБД MySQL, имеющего права администратора, ибо только он имеет право читать содержимое хранимых функций и процедур (иначе хранимые программы не сохранятся в файл);
  dbname — имя базы данных, которую мы сохраняем в файл;
  dump.sql — имя файла, куда мы сохраняем базу данных (файл с этим именем будет создан в текущем каталоге).

затем нажимаем Enter, вводим пароль пользователя username и ещё раз Enter.
Ждём пару секунд и видим, что база данных dbname сохранилась в файле dump.sql. Файл текстовый, его можно открыть и увидеть, что он написан на языке SQL. Размер этого файла получается большой, поэтому его обычно архивируют.


Восстановление базы данных из файла.
Если сохранение БД выполняется одной командой, то для восстановления необходимо сначала войти в командную строку mysql. Для этого в командной строке сервера пишем:

Код

mysql -u admin -p

затем нажимаем Enter, вводим пароль пользователя admin (имеющего права администратора) и ещё раз Enter.
Это мы вошли в командную строку mysql.
Сначала выбираем базу данных, в которую мы будем восстанавливать данные из файла:

Код

use dbname2

и нажимаем Enter. СУБД ответит ниже: Database changed.
А теперь, собственно, восстанавливаем:

Код

source dump.sql

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

Сообщение отредактировал indеx - 25.10.2017 - 16:05

[indеx]

Настройка NGINX. Белый список расширений файлов. Запуск только из корня.

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

1. Статические файлы. Это файлы, которые скачиваются браузером. Готовые HTML-страницы, CSS-файлы, JS-файлы, картинки, иконки, MP3 и другие. Название этих файлов и их содержимое не является секретом, а значит этими файлами можно делиться с окружающим миром.

2. Динамические файлы. Это по сути программы (скрипты), которые не скачиваются, а запускаются браузером. У нас это только PHP-файлы. Название этих файлов также не является секретом, т.к. по названию происходит их запуск. А вот содержимое этих файлов по-хорошему должно быть секретом, чтобы злоумышленники не знали, как устроен сайт изнутри, и соответственно, не смогли подобрать ключик к нашему сайту.

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

Так вот, управлением доступа к файлам занимается веб-сервер, в нашем случае это NGINX.
Соответственно, нам нужно в настройках NGINX (для каждого сайта) описать правила доступа для каждого типа файлов.

1. Сначала опишем статику:

Код

    location ~* \.(htm|html|css|js|ico|jpg|jpeg|png|gif|mp3|msi)$ {
        try_files $uri $uri/ =404;
        }

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

2. Теперь опишем динамику:

Код

    location ~* ^/(\w|-|\.)+\.php$ {
        limit_req zone=max burst=5;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/site1.ru.sock;
        }

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

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

Код

^/catalog/directory/file.php$

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

Код

    location @php {
        limit_req zone=max burst=5;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/site1.ru.sock;
        }

Этот блок называется именованным, т.к. имеет имя @php. По этому имени мы и сможем к нему обращаться.
Теперь делаем два блока регулярных выражений:

Код

    location ~* ^/(\w|-|\.)+\.php$ {
        error_page 480 = @php;
        return 480;
        }
    location ~ ^/catalog/directory/file.php$ {
        error_page 480 = @php;
        return 480;
        }

Как видите, мы использовали это имя блока обработки. Отправка файлов в именованный блок делается именно так.

Теперь нам нужно обработать ситуацию, когда пользователь зашёл на сайт без указания файла. То есть, просто написал в браузере "site1.ru" или "site1.ru/" (без слеша и со слешем в конце). Здесь ведь нет расширения файла .php, значит, нам нужно сделать ещё одно регулярное выражение для этих двух случаев, вот такое:

Код

(^$|^/$)

И блок у нас получится, соответственно:

Код

    location ~* (^$|^/$) {
        error_page 480 = @php;
        return 480;
        }

Который тоже будет отправлять файл в блок обработки. Но возникает закономерный вопрос: Какой файл будет отправлен в обработку, если в адресной строке не указано никакого файла? Ответ прост: Файл по умолчанию, указанный в файле snippets/fastcgi-php.conf (в блоке обработки этот файл подключается к конфигурации). И какой же там указан файл по умолчанию? Смотрим в файл /etc/nginx/snippets/fastcgi-php.conf и видим строку:

Код

fastcgi_index index.php

То есть, тот файл, который обычно и используется по умолчанию. Значит, если пользователь не укажет никакой файл, то будет использоваться файл index.php, и это как раз то, что нам нужно.
В результате, динамическая часть у нас получается следующая:

Код

    location ~* (^$|^/$) {
        error_page 480 = @php;
        return 480;
        }
    location ~* ^/(\w|-|\.)+\.php$ {
        error_page 480 = @php;
        return 480;
        }
    location ~ ^/catalog/directory/file.php$ {
        error_page 480 = @php;
        return 480;
        }
    location @php {
        limit_req zone=max burst=5;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/site1.ru.sock;
        }

3. А теперь опишем секретные файлы.

Код

    location / {
        deny all;
        }

Что означает "Запретить всё!". А так как блок без регулярных выражений обрабатывается после блоков с регулярными выражениями, то это означает "Запретить всё остальное!". То есть, в блоках с регулярными выражениями мы описываем так называемый "белый список" разрешённых запросов к сайту (статика и динамика), а все остальные запросы тупо запрещаем. В результате, всё это мы собираем вместе, вставляем в файл конфигурации сайта site1.ru, и у нас получается следующий файл конфигурации:

» Кликните сюда для просмотра оффтоп текста.. «

Код

# редирект с http на https и сразу без www
server {
    listen 80;
    listen [::]:80;
    server_name site1.ru www.site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    return 301 https://site1.ru$request_uri;
    }

# редирект по https с www на без www
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    ssl_certificate /etc/letsencrypt/live/site1.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.ru/privkey.pem;
    ssl_dhparam /etc/ssl/dh/dh.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_stapling on; # Разрешение прикрепления сервером OCSP-ответов
    ssl_stapling_verify on; # Разрешение проверки сервером OCSP-ответов
    return 301 https://site1.ru$request_uri;
    }

# основной раздел
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name site1.ru;
    server_tokens off; # Запрещение выдачи версии nginx в HTTP-заголовках
    ssl_certificate /etc/letsencrypt/live/site1.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/site1.ru/privkey.pem;
    ssl_dhparam /etc/ssl/dh/dh.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    ssl_stapling on; # Разрешение прикрепления сервером OCSP-ответов
    ssl_stapling_verify on; # Разрешение проверки сервером OCSP-ответов
    root /home/site1-ru/www;
    
    # даём доступ для Let's Encrypt
    location ~ /.well-known {
        allow all;
        }

    # выдаём статические файлы
    location ~* \.(htm|html|css|js|ico|jpg|jpeg|png|gif|mp3|msi)$ {
        try_files $uri $uri/ =404;
        }

    # даём доступ переходу на сайт без указания страницы
    # это не ошибка, а переход к обработчику @php
    location ~* (^$|^/$)    { error_page 480 = @php; return 480; }

    # даём доступ для вызова php-файлов только из корня, и имя которых состоит
    # из латинских символов, знаков подчёркивания, дефисов и точек
    # это не ошибка, а переход к обработчику @php
    location ~* ^/(\w|-|\.)+\.php$    { error_page 480 = @php; return 480; }

    # даём доступ другому сайту для вызова скриптов
    location ~ ^/catalog/directory/file1.php$    { error_page 480 = @php; return 480; }
    location ~ ^/catalog/directory/file2.php$    { error_page 480 = @php; return 480; }
    location ~ ^/catalog/directory/file3.php$    { error_page 480 = @php; return 480; }

    # запрещаем всё остальное
    location / {
        deny all;
        }

    # блок обработки php-файлов
    location @php {
        limit_req zone=max burst=5;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/site1.ru.sock;
        }
    }

Который обеспечивает нам безопасность запросов к веб-серверу.

[indеx]

Свободное место на диске

Заметил, что свободное место на жёстком диске сервера как-то очень быстро кончается.
Вот в этом сообщении видно, что места свободного было 4 гига, а теперь осталось:

Код

root@ez:/# df -t ext4
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/vda1       10286264 9116100    629620  94% /

Всего 630 мегабайт.

Разбираемся, какие папки в корне занимают больше всего места...

» Кликните сюда для просмотра оффтоп текста.. «

Код

root@ez:/# du -s *|sort -nr
du: cannot access 'proc/25333/task/25333/fd/4': No such file or directory
du: cannot access 'proc/25333/task/25333/fdinfo/4': No such file or directory
du: cannot access 'proc/25333/fd/4': No such file or directory
du: cannot access 'proc/25333/fdinfo/4': No such file or directory
2615148 lib
2271848 usr
1844492 var
1048580 swapfile
744912  home
547732  boot
15944   bin
13232   sbin
10908   run
7516    etc
36      tmp
24      root
16      lost+found
8       media
4       srv
4       snap
4       opt
4       mnt
4       lib64
0       vmlinuz.old
0       vmlinuz
0       sys
0       proc
0       initrd.img.old
0       initrd.img
0       dev

Самая тяжёлая папка /lib, лезем в неё...

» Кликните сюда для просмотра оффтоп текста.. «

Код

root@ez:/lib# du -s *|sort -nr
2348816 modules
216812  firmware
24824   x86_64-linux-gnu
12540   udev
10080   systemd
1324    xtables
208     terminfo
104     cryptsetup
72      klibc-k3La8MUnuzHQ0_kG8hokcGAC0PA.so
60      crda
52      recovery-mode
52      modprobe.d
40      lsb
36      open-iscsi
28      ufw
20      apparmor
16      libhandle.so.1.0.3
16      init
16      hdparm
12      ifupdown
8       resolvconf
8       modules-load.d
0       libhandle.so.1
0       cpp

Здесь самая тяжёлая папка /lib/modules, лезем в неё...

» Кликните сюда для просмотра оффтоп текста.. «

Код

root@ez:/lib/modules# du -s *|sort -nr
213808  4.4.0-98-generic
213784  4.4.0-97-generic
213780  4.4.0-96-generic
213692  4.4.0-104-generic
213692  4.4.0-103-generic
213680  4.4.0-101-generic
213292  4.4.0-93-generic
213276  4.4.0-92-generic
213276  4.4.0-91-generic
213276  4.4.0-89-generic
213256  4.4.0-87-generic

Чё эт тут такое? Одинаковые почти по размеру папки...
Оказывается, это модули для ядра соответствующей версии. Они обновляются автоматически (надо будет узнать, как отключить это дело; не люблю, когда без моего ведома что-то само обновляется, тем более на сервере).
Узнаём, какая версия ядра используется сейчас:

Код

root@ez:/# uname -r
4.4.0-101-generic

Ага, значит все остальные папки можно поудалять Или нет?
В Интернете пишут, что можно поудалять, но лучше не вручную, а воспользоваться командой:

Код

sudo apt-get autoremove

Пробуем...

Код

root@ez:/# apt autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  linux-headers-4.4.0-87 linux-headers-4.4.0-87-generic linux-headers-4.4.0-89 linux-headers-4.4.0-89-generic
  linux-headers-4.4.0-91 linux-headers-4.4.0-91-generic linux-headers-4.4.0-92 linux-headers-4.4.0-92-generic
  linux-headers-4.4.0-93 linux-headers-4.4.0-93-generic linux-headers-4.4.0-96 linux-headers-4.4.0-96-generic
  linux-headers-4.4.0-97 linux-headers-4.4.0-97-generic linux-headers-4.4.0-98 linux-headers-4.4.0-98-generic
  linux-image-4.4.0-87-generic linux-image-4.4.0-89-generic linux-image-4.4.0-91-generic
  linux-image-4.4.0-92-generic linux-image-4.4.0-93-generic linux-image-4.4.0-96-generic
  linux-image-4.4.0-97-generic linux-image-4.4.0-98-generic linux-image-extra-4.4.0-87-generic
  linux-image-extra-4.4.0-89-generic linux-image-extra-4.4.0-91-generic linux-image-extra-4.4.0-92-generic
  linux-image-extra-4.4.0-93-generic linux-image-extra-4.4.0-96-generic linux-image-extra-4.4.0-97-generic
  linux-image-extra-4.4.0-98-generic
0 upgraded, 0 newly installed, 32 to remove and 83 not upgraded.
After this operation, 2,379 MB disk space will be freed.
Do you want to continue? [Y/n]

Хмм...

Ладно, удаляем, была-не-была!

» Кликните сюда для просмотра оффтоп текста.. «

Код

root@ezsoft:/# apt autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  linux-headers-4.4.0-87 linux-headers-4.4.0-87-generic linux-headers-4.4.0-89 linux-headers-4.4.0-89-generic
  linux-headers-4.4.0-91 linux-headers-4.4.0-91-generic linux-headers-4.4.0-92 linux-headers-4.4.0-92-generic
  linux-headers-4.4.0-93 linux-headers-4.4.0-93-generic linux-headers-4.4.0-96 linux-headers-4.4.0-96-generic
  linux-headers-4.4.0-97 linux-headers-4.4.0-97-generic linux-headers-4.4.0-98 linux-headers-4.4.0-98-generic
  linux-image-4.4.0-87-generic linux-image-4.4.0-89-generic linux-image-4.4.0-91-generic
  linux-image-4.4.0-92-generic linux-image-4.4.0-93-generic linux-image-4.4.0-96-generic
  linux-image-4.4.0-97-generic linux-image-4.4.0-98-generic linux-image-extra-4.4.0-87-generic
  linux-image-extra-4.4.0-89-generic linux-image-extra-4.4.0-91-generic linux-image-extra-4.4.0-92-generic
  linux-image-extra-4.4.0-93-generic linux-image-extra-4.4.0-96-generic linux-image-extra-4.4.0-97-generic
  linux-image-extra-4.4.0-98-generic
0 upgraded, 0 newly installed, 32 to remove and 83 not upgraded.
After this operation, 2,379 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 390621 files and directories currently installed.)
Removing linux-headers-4.4.0-87-generic (4.4.0-87.110) ...
Removing linux-headers-4.4.0-87 (4.4.0-87.110) ...
Removing linux-headers-4.4.0-89-generic (4.4.0-89.112) ...
Removing linux-headers-4.4.0-89 (4.4.0-89.112) ...
Removing linux-headers-4.4.0-91-generic (4.4.0-91.114) ...
Removing linux-headers-4.4.0-91 (4.4.0-91.114) ...
Removing linux-headers-4.4.0-92-generic (4.4.0-92.115) ...
Removing linux-headers-4.4.0-92 (4.4.0-92.115) ...
Removing linux-headers-4.4.0-93-generic (4.4.0-93.116) ...
Removing linux-headers-4.4.0-93 (4.4.0-93.116) ...
Removing linux-headers-4.4.0-96-generic (4.4.0-96.119) ...
Removing linux-headers-4.4.0-96 (4.4.0-96.119) ...
Removing linux-headers-4.4.0-97-generic (4.4.0-97.120) ...
Removing linux-headers-4.4.0-97 (4.4.0-97.120) ...
Removing linux-headers-4.4.0-98-generic (4.4.0-98.121) ...
Removing linux-headers-4.4.0-98 (4.4.0-98.121) ...
Removing linux-image-extra-4.4.0-87-generic (4.4.0-87.110) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-87-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
Found linux image: /boot/vmlinuz-4.4.0-91-generic
Found initrd image: /boot/initrd.img-4.4.0-91-generic
Found linux image: /boot/vmlinuz-4.4.0-89-generic
Found initrd image: /boot/initrd.img-4.4.0-89-generic
Found linux image: /boot/vmlinuz-4.4.0-87-generic
Found initrd image: /boot/initrd.img-4.4.0-87-generic
done
Removing linux-image-4.4.0-87-generic (4.4.0-87.110) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-87-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-87-generic /boot/vmlinuz-4.4.0-87-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
Found linux image: /boot/vmlinuz-4.4.0-91-generic
Found initrd image: /boot/initrd.img-4.4.0-91-generic
Found linux image: /boot/vmlinuz-4.4.0-89-generic
Found initrd image: /boot/initrd.img-4.4.0-89-generic
done
Removing linux-image-extra-4.4.0-89-generic (4.4.0-89.112) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-89-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
Found linux image: /boot/vmlinuz-4.4.0-91-generic
Found initrd image: /boot/initrd.img-4.4.0-91-generic
Found linux image: /boot/vmlinuz-4.4.0-89-generic
Found initrd image: /boot/initrd.img-4.4.0-89-generic
done
Removing linux-image-4.4.0-89-generic (4.4.0-89.112) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-89-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-89-generic /boot/vmlinuz-4.4.0-89-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
Found linux image: /boot/vmlinuz-4.4.0-91-generic
Found initrd image: /boot/initrd.img-4.4.0-91-generic
done
Removing linux-image-extra-4.4.0-91-generic (4.4.0-91.114) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-91-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
Found linux image: /boot/vmlinuz-4.4.0-91-generic
Found initrd image: /boot/initrd.img-4.4.0-91-generic
done
Removing linux-image-4.4.0-91-generic (4.4.0-91.114) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-91-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-91-generic /boot/vmlinuz-4.4.0-91-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
done
Removing linux-image-extra-4.4.0-92-generic (4.4.0-92.115) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-92-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
Found linux image: /boot/vmlinuz-4.4.0-92-generic
Found initrd image: /boot/initrd.img-4.4.0-92-generic
done
Removing linux-image-4.4.0-92-generic (4.4.0-92.115) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-92-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-92-generic /boot/vmlinuz-4.4.0-92-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
done
Removing linux-image-extra-4.4.0-93-generic (4.4.0-93.116) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-93-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
Found linux image: /boot/vmlinuz-4.4.0-93-generic
Found initrd image: /boot/initrd.img-4.4.0-93-generic
done
Removing linux-image-4.4.0-93-generic (4.4.0-93.116) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-93-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-93-generic /boot/vmlinuz-4.4.0-93-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
done
Removing linux-image-extra-4.4.0-96-generic (4.4.0-96.119) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-96-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
Found linux image: /boot/vmlinuz-4.4.0-96-generic
Found initrd image: /boot/initrd.img-4.4.0-96-generic
done
Removing linux-image-4.4.0-96-generic (4.4.0-96.119) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-96-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-96-generic /boot/vmlinuz-4.4.0-96-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
done
Removing linux-image-extra-4.4.0-97-generic (4.4.0-97.120) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-97-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
Found linux image: /boot/vmlinuz-4.4.0-97-generic
Found initrd image: /boot/initrd.img-4.4.0-97-generic
done
Removing linux-image-4.4.0-97-generic (4.4.0-97.120) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-97-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-97-generic /boot/vmlinuz-4.4.0-97-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
done
Removing linux-image-extra-4.4.0-98-generic (4.4.0-98.121) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-98-generic
W: mdadm: /etc/mdadm/mdadm.conf defines no arrays.
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
Found linux image: /boot/vmlinuz-4.4.0-98-generic
Found initrd image: /boot/initrd.img-4.4.0-98-generic
done
Removing linux-image-4.4.0-98-generic (4.4.0-98.121) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
update-initramfs: Deleting /boot/initrd.img-4.4.0-98-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 4.4.0-98-generic /boot/vmlinuz-4.4.0-98-generic
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-104-generic
Found initrd image: /boot/initrd.img-4.4.0-104-generic
Found linux image: /boot/vmlinuz-4.4.0-103-generic
Found initrd image: /boot/initrd.img-4.4.0-103-generic
Found linux image: /boot/vmlinuz-4.4.0-101-generic
Found initrd image: /boot/initrd.img-4.4.0-101-generic
done

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

Код

root@ez:/# df -t ext4
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/vda1       10286264 5984440   3761280  62% /

Вооот, другое дело! Освободилось более 3 гигов.
Теперь надо поставить эту команду на Крон, чтобы каждый день освобождалось, не накапливалось:

Код

45 07 * * * apt autoremove -y

То есть, каждый день в 7:45 будет удаляться всё ненужное.
Вот так. А то ишь!

[indеx]

Создание поддомена

Когда наш сайт уже работает, но при этом мы занимаемся его развитием, совершенствованием, очень часто возникает ситуация, когда нам нужно протестировать обновление, но мы боимся, а вдруг оно не заработает и всё испортит. Для этой цели можно, конечно, зарегистрировать у регистратора доменных имён ещё один домен, например "mytest1234.ru", создать для него отдельный сайт на сервере и тестировать на нём наше обновление. Но за регистрацию нового домена нам придётся заплатить деньги. Вместо этого лучше к нашему рабочему домену "site1.ru" зарегистрировать поддомен, который будет выглядеть, например, так: "test.site1.ru". То есть, к имени сайта слева через точку добавляется ещё одно имя, и всё это вместе будет являться именем нового сайта. Но в отличии от нового домена, новый поддомен можно зарегистрировать бесплатно на хостинге, где у нас размещён сайт. Например, хостинг spaceweb.ru предоставляет такую возможность. Чтобы создать поддомен для домена, нужно в панели управления зайти в раздел "DNS":

» Кликните сюда для просмотра оффтоп текста.. «

Затем нужно: 1) выбрать домен, для которого мы хотим сделать поддомен, и 2) зайти на вкладку "Записи поддоменов".

» Кликните сюда для просмотра оффтоп текста.. «

После этого, как показано на рисунке ниже: 1) ввести имя нового поддомена, 2) ввести IP-адрес сервера, на котором этот сайт будет расположен, 3) нажать кнопку "Добавить".

» Кликните сюда для просмотра оффтоп текста.. «

Выше появится запись с названием "test".
Если нам нужно, чтобы сайт откликался не только на "test.site1.ru", но и на "www.test.site1.ru", то для этого предусмотрена формочка ниже, в которой в начале написано "www." Вписываем туда всё то же самое, что и в формочку ниже, и нажимаем кнопку "Добавить". После этого выше появится ещё одна запись с названием "www.test".
Это будет означать, что регистрация поддомена началась, и он заработает через некоторое время (несколько часов или сутки), когда обновятся записи на DNS-серверах провайдеров, через узлы которых пакеты проходят до нашего сервера.

Только SSL-сертификат, полученный для домена site1.ru через бесплатную службу letsencrypt, не будет работать для поддомена. Поэтому для поддомена нужно будет получить свой сертификат, как для обычного домена, по инструкции, описанной в одном из предыдущих сообщений.

[indеx]

Оказывается...
PHP может работать на сервере в двух режимах:

1) FPM (FastCGI Process Manager)
2) CLI (Command Line Interface)

В первом режиме PHP висит в памяти, как служба, на готове, и в режиме шлюза ждёт команд, например, от веб-сервера NGINX. А во втором режиме PHP не висит в памяти, а запускается только когда его вызовут через командную строку операционной системы. Соответственно, первый режим не может обрабатывать вызовы из командной строки, а второй режим не может работать в режиме шлюза.

Для каждого из этих двух вариантов существует своя версия установки.
1) PHP-FPM устанавливается так

Код

apt install php7.0-fpm

2) PHP-CLI устанавливается так

Код

apt install php7.0-cli

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

Расширения PHP можно устанавливать после основной установки как для первого варианта, так и для второго:

Код

apt install php7.0-mbstring php7.0-mcrypt php7.0-curl php-memcache

[indеx]

Настройка сервера без сайтов

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

У меня так получилось, что примерно половину нагрузки создавали скрипты PHP, запускающиеся из командной строки. Именно их нужно было перенести на второй сервер, а на первом сервере оставить всё остальное. То есть, на втором сервере не будет ни сайтов, ни баз данных, только голый PHP, который будет брать данные из Интернета, обрабатывать их и помещать в базу данных на первый сервер. Эдакий вспомогательный сервер, подносящий патроны основному боевому серверу. Соответственно, этот вспомогательный сервер нужно настроить. В принципе, его можно настроить точно так же, как я настраивал основной сервер на всех этих 6 страницах темы. Но некоторые программы не понадобятся на втором сервере совсем, поэтому устанавливать и настраивать их я не буду. Кроме того, я не буду и растягивать описание настроек на ещё 6 страниц, а опишу их как краткую инструкцию, что нужно сделать для настройки.

» Кликните сюда для просмотра оффтоп текста.. «

- Установить ОС из ЛК хостинга (хостер устанавливает автоматически)
- Получить пароль root на почту (хостер присылает)
- Войти в систему и сменить пароль root на свой собственный

Код

passwd root

- Создать нового пользователя (например, x-admin), который будет администратором сервера

Код

adduser x-admin

- Сделать нового пользователя админом (добавить его в группу sudo)

Код

usermod -aG sudo x-admin

- Войти в систему под именем нового пользователя
- Отключить возможность входа под именем root (удалить пароль)

Код

sudo passwd -l root

- Обновить систему

Код

sudo apt update
sudo apt upgrade

- Установить программу Midnight Commander

Код

sudo apt install mc

- Запустить MC в обычном режиме, чтобы создался файл настроек

Код

mc

- Выйти из MC нажатием клавиши F10
- Запустить MC в режиме администратора (чтобы потом не писать каждый раз "sudo")

Код

sudo mc

- Сменить номер порта SSH

Код

в файле
        /etc/ssh/sshd_config

в строке
Port 22
заменить значение 22 на своё, не более 65535[/code]
- Создать белый список пользователей, которым позволено входить через SSH

Код

в файле
        /etc/ssh/sshd_config
добавить строку
        AllowUsers x-admin

- Перезапустить SSH

Код

systemctl restart ssh

- Перенастроить PuTTY на новый порт
- Войти в систему через новый порт
- Если после каждой команды появляется надпись "unable to resolve host...",

Код

то в файле
        /etc/hostname
нужно придумать и прописать имя нашего хоста, например
        server1
а затем в файле
        /etc/hosts
прописать это придуманное имя хоста вместе с IP-адресом нашего сервера
        77.222.68.241 server1
сохранить оба файла и перезапустить сервер
        reboot now

- Посмотреть, сколько места занимает ОС Ubuntu после установки:

Код

df

Код

Filesystem     1K-blocks    Used Available Use% Mounted on
udev              487620       0    487620   0% /dev
tmpfs             101584    4360     97224   5% /run
/dev/vda1       10286264 2297580   7448140  24% /
tmpfs             507904       0    507904   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs             507904       0    507904   0% /sys/fs/cgroup
tmpfs             101584       0    101584   0% /run/user/1000

- Удалить ненужные пакеты из системы (чтобы увеличить свободное место на диске)

Код

apt autoremove -y

- Посмотреть, сколько теперь свободного места:

Код

df

- Добавить в планировщик заданий автоудаление ненужных пакетов

Код

В командной строке от имени root ввести:
        crontab -e
Откроется тексовый редактор, добавить в самый низ строку:
        45 7 * * * apt autoremove -y
Сохранить файл по F2 и выйти из редактора
Теперь каждое утро в 7:45 все ненужные пакеты будут удаляться

- Установить boot-time загрузчик правил для файрвола

Код

apt install iptables-persistent

- Настроить файрвол

Код

С другого, уже настроенного, сервера взять файл настроек файрвола
        /etc/iptables/rules.v4
и поместить его в такой же каталог на этом сервере
Затем загрузить эти настройки из файла в систему
        iptables-restore < /etc/iptables/rules.v4
Изменить настройки под задачи данного сервера и сохранить новые настройки
        iptables-save > /etc/iptables/rules.v4
Чтобы они восстанавливались после каждой перезагрузки сервера

- Установить PHP для командной строки

Код

apt install php7.0-cli

- Установить расширения PHP

Код

apt install php7.0-mbstring php7.0-mcrypt php7.0-curl php-memcache

- Включить короткие теги PHP-CLI

Код

в файле
        /etc/php/7.0/cli/php.ini
прописать
        short_open_tag = On

- Для каждого проекта создать рабочего пользователя, от имени которого будет работать PHP

Код

adduser u-site1-ru

- Войти в систему под этим пользователем и запустить MC

Код

mc

- В домашнем каталоге этого пользователя создать папку "job", в которой будут находиться все скрипты

- Установить архиватор ZIP

Код

apt install zip

- На сервере, где установлен MySQL, открыть доступ к БД со всех адресов

Код

в файле
        /etc/mysql/mysql.conf.d
найти строку
        #bind-address = ...
раскомментировать её и заменить на
        bind-address = 0.0.0.0
После этого MySQL начнёт принимать запросы со всех адресов
А белый список адресов лучше задать на уровне файрвола iptables

[Лиса)]

indеx а я очень хочу стать верстальщиком, сейчас смотрю ролики на ютюбе, но как-то результатов маловато. Может можете посоветовать толковые курсы по изучению верстки?

[Фарит]

indеx а я очень хочу стать верстальщиком, сейчас смотрю ролики на ютюбе, но как-то результатов маловато. Может можете посоветовать толковые курсы по изучению верстки?

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

[indеx]

indеx а я очень хочу стать верстальщиком, сейчас смотрю ролики на ютюбе, но как-то результатов маловато. Может можете посоветовать толковые курсы по изучению верстки?

Если коротко ответить, то нет, не могу Потому что сам никогда не смотрел курсы. Хорошо это или плохо, я не знаю, просто мне так было удобнее — я брал и просто начинал делать сначала просто странички на HTML, потом постепенно добавлял туда CSS, потом постепенно добавлял PHP-обработку, и вот скоро начну учиться добавлять JS. Откуда я брал информацию о том, что именно нужно писать? Из сайтов-справочников в Интернете. Вот, например...

Справочник по HTML+CSS: https://webref.ru/
Справочник по PHP: http://php.net/manual/ru/

Но просто брать справочники и начинать их читать — безсмысленное занятие, потому что в голове от этого получится каша.
Вместо этого я бы посоветовал самому себе ставить конкретные задачи. Например: 1) "Сверстать страничку резюме с фотографией", 2) сверстать страничку с таблицей, и так далее.

Вопрос: "Что изучать сначала, а что потом?".
У меня ответ однозначный — нужно изучать языки в следующем порядке:
1) HTML,
2) CSS,
3) PHP,
4) JavaScript.
То есть, сначала взять язык HTML и научиться верстать странички только на нём. Потом добавить CSS и научиться верстать на HTML+CSS. Ну, и так далее.

А чтобы было нескучно, можете создать в этом разделе форума свою тему и вести её как дневник. Обещаю — буду подсказывать

[indеx]

Чтобы сразу увидеть результат и порадоваться первому успеху , можно сделать следующее:

1) создать текстовый файл с названием "index.html".
2) открыть его в любом текстовом редакторе, например, в Блокноте, и написать там следующий текст:

Код

<!DOCTYPE html>
<html>
<head>
    <title>Моя первая страничка</title>
</head>
<body>
    <h1>Всем привет, я Лиса)</h1>
</body>
</html>

3) Сохранить изменения в файле.
4) Запустить этот файл "index.html", он должен открыться в Вашем браузере и показать Вашу первую страничку.

А затем в эту страничку уже можно добавлять и другие элементы.

[indеx]

Бывают случаи, когда сайт выдаёт сообщение:

MYSQL connection failed: Too many connections

Это означает дословно:

Подключение к MYSQL не удалось. Слишком много подключений

Возникает такая ситуация обычно, когда у Вас на сайте увеличивается количество пользователей. Как решить эту проблему?
Дело в том, что изначально в MySQL задано ограничение на максимальное количество подключение к серверу. Чтобы узнать, какое значение установлено в качестве ограничения, нужно выполнить следующий SQL-запрос:

Код

SHOW VARIABLES WHERE `variable_name`='max_connections';

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

1) в папке /etc/mysql/conf.d создать файл max_connections.cnf
2) в созданном файле написать следующий текст:

Код

[mysqld]
  max_connections = 500

3) сохранить изменения в файле
4) в папке /etc/systemd/system создать папку mysql.service.d
5) внутри созданной папки создать файл limits.conf
6) в созданном файле написать следующий текст:

Код

[Service]
  LimitNOFILE = 65535

7) сохранить изменения в файле
8) в системной командной строке выполнить две команды:

Код

systemctl daemon-reload

Код

systemctl restart mysqld

После этого необходимо убедиться, что новое значение вступило в силу. То есть, снова выполнить тот же самый SQL-запрос. Если всё прошло нормально, то сервер выдаст значение 500. Если же новое значение 500 Вас не устраивает, и Вы хотите увеличить его, например, до 1000, то выполните заново пункты 2 и 3 со значением 1000 вместо 500. Все 8 пунктов заново выполнять не нужно.