Здравствуйте, гость ( Авторизация | Регистрация )


6 страниц V  « < 4 5 6  
Reply to this topicStart new topic
> Делаю сайт, Впервые!
indеx
сообщение 17.08.2017 - 13:36
Сообщение #51
  


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2880
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15

Пол: М


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


My Signature


--------------------
Подарки: (Всего подарков: 34 )
Подарок
Подарил(а): Дедушка Мороз
Подарок
Подарил(а): Бульбаш
Подарок
Подарил(а): Дедушка Мороз
Go to the top of the page
 
+Quote Post
 
indеx
сообщение 18.08.2017 - 19:14
Сообщение #52
  


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2880
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15

Пол: М


Репутация:   267  
 
 
Таким образом получается, что у нас в памяти сервера работают несколько процессов PHP — для каждого сайта свой процесс. Или даже не один? Хм, интересно, а сколько? Давайте посмотрим...
Есть одна команда:
Код
ps aux --sort -rss
которая выводит на экран список всех процессов:
» Кликните сюда для просмотра оффтоп текста.. «
И в этом списке мы можем видеть количество процессов, сколько они занимают памяти и на сколько загружают процессор. Этот список, по всей видимости, упорядочен по объёму занимаемой памяти. И самый большой объём, как мы видим, занимает наша СУБД MySQL20% оперативки. Всего на сервере 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
И сохранить файл.
После этого мы перезагружаем сервер, убеждаемся, что после перезагрузки файл подкачки тоже используется, и радуемся, что теперь-то у нас точно хватит памяти для всех процессов на сервере.

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


My Signature


--------------------
Подарки: (Всего подарков: 34 )
Подарок
Подарил(а): Дедушка Мороз
Подарок
Подарил(а): Бульбаш
Подарок
Подарил(а): Дедушка Мороз
Go to the top of the page
 
+Quote Post
 
indеx
сообщение 17.10.2017 - 20:27
Сообщение #53
  


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2880
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15

Пол: М


Репутация:   267  
 
 
Небольшая заметка.

По умолчанию PHP обрабатывает скрипты только в таких вставках:
Код
<?php ... ?>

Но для удобства и для эстетики лично мне хочется использовать вставки вот такие:
Код
<? ... ?>
Чтобы такие вставки работали, нужно в файле php.ini найти строку:
Код
short_open_tag = Off
и заменить её на:
Код
short_open_tag = On
Само собой, после этого нужно перезапустить PHP:
Код
systemctl restart php7.0-fpm


My Signature


--------------------
Подарки: (Всего подарков: 34 )
Подарок
Подарил(а): Дедушка Мороз
Подарок
Подарил(а): Бульбаш
Подарок
Подарил(а): Дедушка Мороз
Go to the top of the page
 
+Quote Post
 
indеx
сообщение 25.10.2017 - 16:03
Сообщение #54
  


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2880
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15

Пол: М


Репутация:   267  
 
 
Компьютерная техника обычно работает чётко, строго по инструкциям и программам. Но всё-таки иногда случаются непредвиденные ситуации, в результате которых информация на сервере может частично пропасть. Особенно ценной является информация, хранящаяся в базе данных сайта. Например, все наши сообщения на этом форуме хранятся в базе данных сайта tochek.net. И если часть сообщений однажды вдруг пропадёт, то это будет очень печально. Такое, кстати, однажды было на этом форуме. В разделе "Непознанное -> Прочие религии и учения" модератор Сладкая Смерть случайно удалила все темы. ag.gif А потом заполняла этот раздел вновь созданными с нуля темами. ab.gif Чтобы такого не происходило, системные администраторы сайтов регулярно делают так называемые дампы базы данных. То есть, сохраняют всю информацию из базы данных в файл, чтобы потом её можно было восстановить из этого файла. База данных коммерческого сайта, хранящая записи о движении денежных средств, ещё более ценна, поэтому её сохраняют обычно каждый день. Мы можем делать это вручную с помощью программы 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, работа с которой описана выше. Только пароль в этом случае вручную уже не введёшь, и его придётся прописывать в файле, а это потенциально опасно, если сервер физически находится не у меня. И это дилемма. Если автоматизированно, то могут пароли из файлов достать. Если вручную изредка, то можно потерять новые данные из-за какого-нибудь сбоя. Если вручную каждый день, то это лень. ca.gif В общем, пока сохраняю вручную изредка, а дальше видно будет...

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


My Signature


--------------------
Подарки: (Всего подарков: 34 )
Подарок
Подарил(а): Дедушка Мороз
Подарок
Подарил(а): Бульбаш
Подарок
Подарил(а): Дедушка Мороз
Go to the top of the page
 
+Quote Post
 
indеx
сообщение 5.12.2017 - 1:37
Сообщение #55
  


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2880
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15

Пол: М


Репутация:   267  
 
 
Настройка 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, и у нас получается следующий файл конфигурации:
» Кликните сюда для просмотра оффтоп текста.. «
Который обеспечивает нам безопасность запросов к веб-серверу. rs.gif


My Signature


--------------------
Подарки: (Всего подарков: 34 )
Подарок
Подарил(а): Дедушка Мороз
Подарок
Подарил(а): Бульбаш
Подарок
Подарил(а): Дедушка Мороз
Go to the top of the page
 
+Quote Post
 
indеx
сообщение 19.12.2017 - 18:07
Сообщение #56
  


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2880
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15

Пол: М


Репутация:   267  
 
 
Свободное место на диске

Заметил, что свободное место на жёстком диске сервера как-то очень быстро кончается.
Вот в этом сообщении видно, что места свободного было 4 гига, а теперь осталось:
Код
root@ez:/# df -t ext4
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/vda1       10286264 9116100    629620  94% /
Всего 630 мегабайт.

Разбираемся, какие папки в корне занимают больше всего места...
» Кликните сюда для просмотра оффтоп текста.. «
Самая тяжёлая папка /lib, лезем в неё...
» Кликните сюда для просмотра оффтоп текста.. «
Здесь самая тяжёлая папка /lib/modules, лезем в неё...
» Кликните сюда для просмотра оффтоп текста.. «
Чё эт тут такое? Одинаковые почти по размеру папки...
Оказывается, это модули для ядра соответствующей версии. Они обновляются автоматически (надо будет узнать, как отключить это дело; не люблю, когда без моего ведома что-то само обновляется, тем более на сервере).
Узнаём, какая версия ядра используется сейчас:
Код
root@ez:/# uname -r
4.4.0-101-generic
Ага, значит все остальные папки можно поудалять ab.gif ai.gif Или нет?
В Интернете пишут, что можно поудалять, но лучше не вручную, а воспользоваться командой:
Код
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]
Хмм... bw.gif

Ладно, удаляем, была-не-была! ag.gif
» Кликните сюда для просмотра оффтоп текста.. «
Ого! А я ещё хотел вручную что-то там сделать.
Так, сайт работает, форум работает, уже хорошо ag.gif
Анука, смотрим теперь, сколько места...
Код
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 будет удаляться всё ненужное.
Вот так. А то ишь!


My Signature


--------------------
Подарки: (Всего подарков: 34 )
Подарок
Подарил(а): Дедушка Мороз
Подарок
Подарил(а): Бульбаш
Подарок
Подарил(а): Дедушка Мороз
Go to the top of the page
 
+Quote Post
 

6 страниц V  « < 4 5 6
Reply to this topicStart new topic


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
 






Moderation Panel
 
 

Яндекс цитирования         







Текстовая версия Сейчас: 19.01.2018 - 2:47