Web-сервер на CentOS 7: Nginx, PHP 7.x, PerconaDB

У меня уже были ранее записи, про установку PHP 7 на CentOS. В этот раз у меня появилась задача поднять сразу веб-сервер с нуля на базе операционной системы CentOS 7. Пользуясь случаем, решил записать последовательность действий для экономии времени в будущем. Возможно, вы тоже решили установить веб-сервер под CentOS 7 с последней версией PHP 7, тогда этот материал вам тоже будет полезен.

Список актуальных версий пакетов на момент установки:

  • Веб-сервер Nginx 1.13.4
  • Менеджер процессов FastCGI PHP 7.1.7
  • MySQL сервер Percona 5.7

Предварительная настройка

Настройку сервера начнем с предварительной настройки сервера. Для начала я отключу firewalld, в дальнейшем доступ к серверу будет ограничен через iptables. Для отключения firewalld в CentOS 7 выполните следующие команды:

systemctl disable firewalld
systemctl stop firewalld

Создаем файл с правилами iptables:

mkdir -p /etc/iptables
vi /etc/iptables/rules.v4

Добавляем в содержимое файла следующие строки:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# DROP INVALID PACKETS
-A INPUT -m conntrack --ctstate INVALID -j DROP

# ICMP
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# SSH
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
# Если у вас статический ip, ограничьте доступ к SSH по ip-адресу.
# Меняем адрес 1.2.3.4 на свое значение и меняем строку выше на следующую:
#-A INPUT -s 1.2.3.4/32 -p tcp -m tcp --dport 22 -j ACCEPT

# NGINX
-A INPUT -i -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT

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

Применяем правила:

iptables-restore < /etc/iptables/rules.v4

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

chmod +x /etc/rc.local
vi /etc/rc.local

Добавляем содержимое файла:

#!/bin/bash
# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.

iptables-restore < /etc/iptables/rules.v4

touch /var/lock/subsys/local

Установка Nginx в CentOS

Установку Nginx в CentOS будем из официального репозитория, я рекомендую использовать более свежую mainline-версию. Для настройки репозитория yum для CentOS необходимо создать файл:

/etc/yum.repos.d/nginx.repo

C таким содержимым:

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/
gpgcheck=0
enabled=1

Устанавливаем Nginx:

yum install nginx

Запускаем и добавляем nginx в атозапуск при старте системы:

systemctl start nginx
systemctl enable nginx

Откройте файл:

vi /etc/nginx/nginx.conf

Приведите значение параметров к следующему виду:

worker_processes auto;
access_log off;
server_tokens off;

sendfile on;
tcp_nopush on;
tcp_nodelay on;

keepalive_timeout 0;

Применяем значения параметров:

service nginx restart

Установка PHP 7 в CentOS

На данный момент PHP 7 нет в официальных репозиториях. Для установки PHP 7.1 в CentOS 7 нам понадобится добавить в систему репозиторий Webtatic. Для установки модулей есть PEAR, но его поддерживают не все модуля. Связи с чем установки неподдерживаемых PHP PEAR модулей нужно выполнять из репозитория Webtatic.

Добавим в систему EPEL и Webtatic репозитории:

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

Устанавливаем PHP 7.1 и наиболее часто используемые расширения:

yum install php71w-fpm php71w-opcache php71w-cli php71w-common php71w-gd php71w-mbstring php71w-mcrypt php71w-mysqlnd php71w-xml

Расширение OPcache, но я рекомендую его использовать для более быстрой работы ваших сайтов. OPcache теперь официально включен в исходный дистрибутив и поддерживается командой PHP. Это дает ему преимущество по сравнению с другим кэшем Opcode.

Список доступных для установки расширений PHP 7.1 есть на официальной странице репозитория Webtatic, в разделе Packages.

Запускаем и добавляем php-fpm в атозапуск при старте системы:

systemctl start php-fpm
systemctl enable php-fpm

Теперь переходим к настройке PHP-FPM, откройте следующий файл:

vi /etc/php-fpm.d/www.conf

Раскомментируйте и приведите значение параметров к следующему виду:

user = apache
group = apache

listen = /var/run/php-fpm.sock

listen.owner = nginx
listen.group = nginx
listen.mode = 0660

Перезапустим php-fpm:

service php-fpm restart

Для взаимодействия Nginx с php-fpm создайте следующую конфигурацию:

vi /etc/nginx/conf.d/default.conf

Замените содержимое файла на:

server {
    listen       80;
    server_name  test.net;

    root   /usr/share/nginx/html;
    index  index.php index.html;

    location ~ .php$ {
        try_files $uri = 404;
        fastcgi_pass unix:/var/run/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Применяем значение параметров:

service nginx restart

Установка Percona в CentOS

Устанавливать PerconaDB, MySQL или MariaDB — дело личного предпочтения. В данной статье речь пойдет о установке PerconaDB на CentOS, для этого добавим в систему официальный репозиторий пакетов:

yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm

Устанавливаем Percona Server:

yum install Percona-Server-server-57

Запускаем и добавляем Percona в атозапуск при старте системы:

systemctl start mysql

Наверно, у вас возникнет вопрос: где взять пароль root для доступа к Percona Server? В этом плане Percona проявит самостоятельность, вместо нас придумает пароль и запишет его в лог.Что бы узнать пароль root в Percona выполните команду:

cat /var/log/mysqld.log |grep generated
2017-08-13T15:25:44.331443Z 1 [Note] A temporary password is generated for root@localhost: ************

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

# mysql_secure_installation

Securing the MySQL server deployment.

Enter password for user root:
The 'validate_password' plugin is installed on the server.
The subsequent steps will run with the existing configuration
of the plugin.
Using existing password for root.

Estimated strength of the password: 100
Change the password for root ? ((Press y|Y for Yes, any other key for No) : y

New password:

Re-enter new password:

Estimated strength of the password: 100
Do you wish to continue with the password provided?(Press y|Y for Yes, any other key for No) : y
By default, a MySQL installation has an anonymous user,
allowing anyone to log into MySQL without having to have
a user account created for them. This is intended only for
testing, and to make the installation go a bit smoother.
You should remove them before moving into a production
environment.

Remove anonymous users? (Press y|Y for Yes, any other key for No) : y
Success.


Normally, root should only be allowed to connect from
'localhost'. This ensures that someone cannot guess at
the root password from the network.

Disallow root login remotely? (Press y|Y for Yes, any other key for No) : y
Success.

By default, MySQL comes with a database named 'test' that
anyone can access. This is also intended only for testing,
and should be removed before moving into a production
environment.


Remove test database and access to it? (Press y|Y for Yes, any other key for No) : y
 - Dropping test database...
Success.

 - Removing privileges on test database...
Success.

Reloading the privilege tables will ensure that all changes
made so far will take effect immediately.

Reload privilege tables now? (Press y|Y for Yes, any other key for No) : y
Success.

All done!

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

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

Открываем следующий файл:

vi /etc/percona-server.conf.d/mysqld.cnf

В секцию [mysqld] добавляем следующие параметры:

bind-address=127.0.0.1
# Вредный параметр, но иногда необходимо отключить проверку пароля условиям безопасности
# validate-password=off
innodb_buffer_pool_size=24G
innodb_log_file_size=256M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method=O_DIRECT
max_connections=300

Что означают и для чего используются некоторые из этих параметров вы можете прочитать в статье MySQL 5.7 Performance Tuning Immediately After Installation на официальном сайте.

Самый важный параметр — innodb_buffer_pool_size. Устанавливаем равным 50%-80% от оперативной памяти, но не более размера вашей базы. Если у вас база на 100Mb устанавливаем значение параметра 200M с запасом. Для базы на 100Gb, при условии недостатка нужного количества оперативной памяти на сервере, значение параметра устанавливаем в пределах 50%-80% от оперативной памяти.

Установить свой сертификат в Proxmox

Дата: 13.08.2017Метки:

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

/etc/pve/nodes/<node>/pve-ssl.pem
/etc/pve/nodes/<node>/pve-ssl.key

После заменяем файлы сертификата и ключа на свои:

cp private.ssl /etc/pve/nodes/<node>/pveproxy-ssl.pem
cp private.key /etc/pve/nodes/<node>/pveproxy-ssl.key

Перезапустим web-интерфейс Proxmox:

systemctl restart pveproxy

Не запускается MySQL

Дата: 11.08.2017Метки:

Проблема замечено на MariaDB, не запускается служба mariadb.service. В логах следующие ошибки:

[root@server ~]# systemctl start mariadb.service
Job for mariadb.service failed because the control process exited with error cod                                                                                                       e. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[root@server ~]# journalctl -xe
--
-- A new session with the ID 427 has been created for the user root.
--
-- The leading process of the session is 31608.
Aug 08 07:06:14 server.ru systemd[1]: Starting Session 427 of user root.
-- Subject: Unit session-427.scope has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit session-427.scope has begun starting up.
Aug 08 07:06:14 server.ru sshd[31608]: pam_unix(sshd:session): session opened for user root by (uid=0)
Aug 08 07:06:29 server.ru polkitd[467]: Registered Authentication Agent for unix-process:31678:1499682 (system bus name :1.883 [/usr/bin/pkttyagent --notify-fd 5 --fallback], objec
Aug 08 07:06:29 server.ru systemd[1]: Starting MariaDB database server...
-- Subject: Unit mariadb.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has begun starting up.
Aug 08 07:06:29 server.ru mariadb-prepare-db-dir[31684]: [74B blob data]
Aug 08 07:06:29 server.ru mariadb-prepare-db-dir[31684]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mariadb-prepare-db-dir[31684]: [74B blob data]
Aug 08 07:06:29 server.ru mariadb-prepare-db-dir[31684]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mariadb-prepare-db-dir[31684]: [74B blob data]
Aug 08 07:06:29 server.ru mariadb-prepare-db-dir[31684]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mariadb-wait-ready[31713]: [74B blob data]
Aug 08 07:06:29 server.ru mariadb-wait-ready[31713]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mariadb-wait-ready[31713]: [74B blob data]
Aug 08 07:06:29 server.ru mariadb-wait-ready[31713]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mysqld_safe[31712]: [74B blob data]
Aug 08 07:06:29 server.ru mysqld_safe[31712]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mysqld_safe[31712]: [74B blob data]
Aug 08 07:06:29 server.ru mysqld_safe[31712]: Fatal error in defaults handling. Program aborted
Aug 08 07:06:29 server.ru mysqld_safe[31712]: 170808 07:06:29 mysqld_safe Logging to '/var/lib/mysql/server.ru.err'.
Aug 08 07:06:29 server.ru mysqld_safe[31712]: 170808 07:06:29 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Aug 08 07:06:29 server.ru mysqld_safe[31712]: 170808 07:06:29 mysqld_safe mysqld from pid file /var/lib/mysql/server.ru.pid ended
Aug 08 07:06:30 server.ru systemd[1]: mariadb.service: control process exited, code=exited status=1
Aug 08 07:06:30 server.ru systemd[1]: Failed to start MariaDB database server.
-- Subject: Unit mariadb.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has failed.
--
-- The result is failed.
Aug 08 07:06:30 server.ru systemd[1]: Unit mariadb.service entered failed state.
Aug 08 07:06:30 server.ru systemd[1]: mariadb.service failed.

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

Далее удаляем пакеты MariaDB:

yum remove mariadb mariadb-server

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

cd /var/lib/mysql
mv mysql mysql_backup

Удаляем файл:

rm /etc/my.cnf

В ручную закачиваем пакеты MariaDB той версии, которая была установлена:

wget http://***/Packages/mariadb-5.5.52-1.el7.x86_64.rpm
wget http://***/Packages/mariadb-server-5.5.52-1.el7.x86_64.rpm

Запускаем MariaDB, если все работает, подсовываем сделанный ранее бекап:

cd /var/lib/mysql
mv mysql mysql_
cp mysql_backup mysql

Запускаем MariaDB. В моем случае после выполнения описанных действий MariaDB успешно запустилась с сохранением всех данных.

Установка ImageMagick в CentOS 7

Дата: 01.08.2017Метки:

Небольшая заметка на тему установки ImageMagick в CentOS 7. Изначально имеется web-сервер, который установлен с помощью панели ISPmanager. Сначала нам нужно установить пакеты, которые необходимы для установки ImageMagick и расширения IMagick для PHP:

yum install gcc php-devel php-pear

После завершения установки необходимых пакетов, выполним установку непосредственно самого ImageMagick:

yum install ImageMagick ImageMagick-devel

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

pecl install imagick
echo "extension=imagick.so" > /etc/php.d/imagick.ini

После выполнения вышеуказанных действий, вам необходимо перезапустить apache, для этого используйте следующую команду:

service httpd reload

Can’t load private ssl_key: Key is for a different cert than ssl_cert

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

# tail -5 /var/log/mail
Jul 09 07:36:43 ***** dovecot[862]: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul 09 07:36:43 ***** dovecot[764]: master: Error: service(imap-login): command startup failed, throttling for 2 secs
Jul 09 07:37:31 ***** dovecot[862]: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul 09 07:37:31 ***** dovecot[764]: master: Error: service(imap-login): command startup failed, throttling for 4 secs
Jul 09 07:38:51 ***** dovecot[862]: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert

Вывод журнала systemd:

# journalctl -b -u dovecot
Jul  9 08:30:23 ***** dovecot: pop3-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:30:23 ***** dovecot: master: Error: service(pop3-login): command startup failed, throttling for 2 secs
Jul  9 08:30:25 ***** dovecot: pop3-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:30:25 ***** dovecot: master: Error: service(pop3-login): command startup failed, throttling for 4 secs
Jul  9 08:30:25 ***** dovecot: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:30:25 ***** dovecot: master: Error: service(imap-login): command startup failed, throttling for 2 secs
Jul  9 08:30:27 ***** dovecot: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:30:27 ***** dovecot: master: Error: service(imap-login): command startup failed, throttling for 4 secs
Jul  9 08:34:56 ***** dovecot: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:34:56 ***** dovecot: master: Error: service(imap-login): command startup failed, throttling for 8 secs
Jul  9 08:46:12 ***** dovecot: pop3-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:46:12 ***** dovecot: master: Error: service(pop3-login): command startup failed, throttling for 8 secs
Jul  9 08:46:20 ***** dovecot: pop3-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:46:20 ***** dovecot: master: Error: service(pop3-login): command startup failed, throttling for 16 secs
Jul  9 08:46:21 ***** dovecot: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:46:21 ***** dovecot: master: Error: service(imap-login): command startup failed, throttling for 16 secs
Jul  9 08:46:37 ***** dovecot: imap-login: Fatal: Can't load private ssl_key: Key is for a different cert than ssl_cert
Jul  9 08:46:37 ***** dovecot: master: Error: service(imap-login): command startup failed, throttling for 32 secs

Для начала выводим конфигурацию dovecont:

doveconf -n

Нас интересует расположение сертификата и ключа:

ssl_cert = </etc/exim/ssl/exim.crt
ssl_key = </etc/exim/ssl/exim.key

Переходим в указанный каталог:

cd /etc/exim/ssl/

Генерируем самоподписанный сертификат:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout exim.key -out exim.crt

Перезапустим exim и dovecot:

service dovecot restart
service exim restart

add-apt-repository: command not found

Дата: 22.06.2017Метки:

Часто при заказе VPS на сервер устанавливается система с минимальным набором пакетов. Вот недавно на новом VPS при выполнении команды add-apt-repository получил вот такую ошибку:

add-apt-repository: command not found

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

apt-get install software-properties-common python-software-properties

Установка PHP 5.6 в Ubuntu 16.04

Дата: 22.06.2017Метки: ,

В Ubuntu 16.04 Xenial уже давно из репозитория убрали PHP 5.6 и вместо него по умолчанию устанавливается новая версия PHP 7.0. Но как быть тем, кто по той или иной причине не может перейти на новую версию? В этом случае, если вы хотите использовать PHP 5.6 вам необходимо предварительно добавить репозиторий для старой версии.

Добавим ppa-репозиторий в систему:

sudo add-apt-repository ppa:ondrej/php
upt-get update

Далее запускаем установку PHP 5.6 и дополнительно указываем необходимые модули:

sudo apt-get install php5.6-mbstring php5.6-mysql php5.6-gd php5.6-xml

SMART мониторинг SSD в Linux

Дата: 21.06.2017Метки:

У каждого производителя SSD есть специализированная утилита для мониторинга состояния диска в Windows. Что касается Linux, то ситуация состоит сложнее. По моему опыту я сталкивался с наличием такой утилиты под Linux только для PRO и энтерпрайз серии SSD дисков. Но если говорить по сути, то особой нужды в них нет. В качестве альтернативы мы будем использовать утилиту smartmontools доступную для большинства дистрибутивов Linux.

Для начала выполним установку. В CentOS необходимо выполнить команду:

yum install smartmontools

Для Debian и Ubuntu аналогично:

apt-get install smartmontools

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

find /dev -name 'sd*'

Теперь, когда известно название диска, можем вывести информацию SMART. У меня результат выполнения команды выглядит следующим образом:

# smartctl -A /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.10.0-514.21.1.el7.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       215
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       9
177 Wear_Leveling_Count     0x0013   100   100   000    Pre-fail  Always       -       0
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   069   063   000    Old_age   Always       -       31
195 Hardware_ECC_Recovered  0x001a   200   200   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       2
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       1357065631

Теперь немного информации о данных, которые содержат важную информацию о состоянии вашего диска. В первую очередь обратите внимание на значение RAW_VALUE для параметра Reallocated_Sector_Ct — количество переназначенных секторов. Нулевое значение говорит нам, что диск в полном порядке. Далее обратите внимание на Power_On_Hours, параметр отображает информацию о суммарном времени работы диска. Информация может быть полезна при аренде сервера и дает общее представление о времени его работы. Далее второй по значимости параметр Total_LBAs_Written — общее количество записанных байт.

Что бы предоставить информацию из Total_LBAs_Written можно воспользоваться онлайн калькулятором. В калькуляторе важно указать размер сектора диска, его можно посмотреть командой:

fdisk -l /dev/sda

Установка ionCube Loader в Ubuntu 16.04

IonCube — расширение модуля PHP, которое загружает зашифрованные файлы PHP и ускоряет выполнение PHP-скриптов. Для установки ionCube необходимо прописать соответствующий модуль в файл конфигурации php.ini. Краткий мануал по установке ionCube Loader в Ubuntu 16.04. Предварительно система подготовлена следующим образом. На сервер автоматически установлен PHP 7 вместе с установкой панели Vesta.

Скачиваем последнюю версию Ioncube Loader для системы 64-bit:

cd /tmp
wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86-64.tar.gz

Или Ioncube Loader для системы 32-bit:

cd /tmp
wget http://downloads3.ioncube.com/loader_downloads/ioncube_loaders_lin_x86.tar.gz

Распаковываем:

tar xfz ioncube_loaders_lin_x86.tar.gz

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

php --ini |grep Loaded
Loaded Configuration File:         /etc/php/7.0/cli/php.ini

Следует отметить что путь будет указан для php-cli, каталог для php.ini модуля php-fpm должен быть на уровень выше.

Выясним расположение каталога модулей PHP:

# php -i |grep extension_dir
extension_dir => /usr/lib/php/20151012 => /usr/lib/php/20151012

Копируем модуль Ioncube Loader в каталог с расширениями:

cd /tmp/ioncube
cp ioncube_loader_lin_7.0.so /usr/lib/php/20151012

Добавим загрузку модуля в файл php.ini. Откройте файл:

nano /etc/php.ini

И добавьте в его начало следующую строку:

zend_extension = "/usr/lib/php/20151012/ioncube_loader_lin_7.0.so"

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

Перезапустим php-fpm или apache:

service apache2 restart
service php-fpm restart

Если все сделали правильно, то вы должны увидеть следующий результат выполнения команды:

# php -v
PHP 7.0.15-0ubuntu0.16.04.4 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v6.0.8, Copyright (c) 2002-2015, by ionCube Ltd.

Проксирование в Nginx

Дата: 20.05.2017Метки:

Простой пример конфига Nginx для проксирования HTTP трафика. Смысл заключается в том, что бы перенаправить запросы с frontend сервера, который у меня обозначен как 1.1.1.1 на back-end сервер 2.2.2.2. Дополнительно мы включаем кэширование, что позволяет существенно снизить нагрузку на сервер.

Для начала кратко напишу про настройки кэширования Nginx. В proxy_cache_path мы указываем расположение кэша. Для максимальной производительности я буду хранить его в оперативной памяти. Параметр levels задаёт уровни иерархии кэша. В нашем случае файлы будут сохранятся в каталог по аналогии примеру ниже:

/var/run/proxy_cache/c/29/b7f54b2df7773722d382f4809d65029c

Далее мы указываем имя зоны, время хранения файлов и размер кэша. Если к данным не обращаться более 8 минут, то закэшированные элементы будут удалены. Директива proxy_cache_key используется для создания схемы идентификации — оставляем без изменений. В proxy_cache_valid задаем время кэширования кодов ответа.

В директивах listen 1.1.1.1:80 и server_name proxy.com мы указываем ip-адрес и доменное имя сервера на котором запущен Nginx. После чего proxy_pass указываем адрес сервера на который будут передаваться запросы.

proxy_cache_path /var/run/proxy_cache levels=1:2 keys_zone=backcache:8m max_size=100m;
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args";
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;

server {
    listen 1.1.1.1:80;
    server_name proxy.com;

    location / {
        proxy_pass http://2.2.2.2;

        proxy_set_header HOST $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_cache backcache;
        proxy_cache_bypass $http_cache_control;
        add_header X-Proxy-Cache $upstream_cache_status;
    }
}