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 успешно запустилась с сохранением всех данных.

Скрипт загрузки дампов MySQL

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

На загрузку большого количества дампов MySQL требуется не мало времени. Небольшой скрипт значительно облегчит эту задачу. Скрипт необходимо скопировать в каталог с дампами, затем проверить что бы в MySQl не было баз сходных по имени с восстанавливаемыми из дампа. После запуска скрипт автоматически зальет все дампы.

#!/bin/bash -   
#title          :mysql-dbs-restore.sh
#description    :This script will Script to restore multiple DB to mysql from .sql files;
#		 asumes the dbname is the name of the .sql file
#author         :Sergio Aguilar
#date           :20120518
#version        :0.0.1  
#usage          :./mysql-dbs-restore.sh
#notes          :       
#bash_version   :4.2.24(1)-release
#============================================================================

# Config Variables:
USER="root"
HOST="localhost"

# Read mysql root password:
echo -n "Type mysql root password: "
read -s PASS
echo ""

# Extract files from .gz archives:
function gzip_extract {

  for filename in *.gz
    do
      echo "extracting $filename"
      gzip -d $filename
    done
}

# Look for sql.gz files:
if [ "$(ls -A *.sql.gz 2> /dev/null)" ]  ; then
  echo "sql.gz files found extracting..."
  gzip_extract
else
  echo "No sql.gz files found"
fi

# Exit when folder doesn't have .sql files:
if [ "$(ls -A *.sql 2> /dev/null)" == 0 ]; then
  echo "No *.sql files found"
  exit 0
fi

# Get all database list first
DBS="$(mysql -u $USER -h $HOST -p$PASS -Bse 'show databases')"

echo "These are the current existing Databases:"
echo $DBS

# Ignore list, won't restore the following list of DB:
IGGY="test information_schema mysql"


# Restore DBs:
for filename in *.sql
do
  dbname=${filename%.sql}
  
  skipdb=-1
  if [ "$IGGY" != "" ]; then
    for ignore in $IGGY
    do
        [ "$dbname" == "$ignore" ] && skipdb=1 || :
        
    done
  fi      

  # If not in ignore list, restore:
  if [ "$skipdb" == "-1" ] ; then
  
    skip_create=-1
    for existing in $DBS
    do      
      #echo "Checking database: $dbname to $existing"
      [ "$dbname" == "$existing" ] && skip_create=1 || :
    done
  
    if [ "$skip_create" ==  "1" ] ; then 
      echo "Database: $dbname already exist, skiping create"
    else
      echo "Creating DB: $dbname"
      mysqladmin create $dbname -u $USER -p$PASS
    fi
    
    echo "Importing DB: $dbname from $filename"
    mysql $dbname < $filename -u $USER -p$PASS
  fi    
done

Скрипт взят с GitHub

Установка 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

phpbb_sessions’ is marked as crashed and should be repaired

Дата: 21.06.2017

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

General Error
SQL ERROR [ mysqli ]

Table '.\forum\phpbb_sessions' is marked as crashed and should be repaired [145]

An sql error occurred while fetching this page. Please contact an administrator if this problem persists.

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

REPAIR TABLE phpbb_sessions;