sysmerge IT

10 окт. 2019 г.

Centos 7 - Настройка http2 на Apache 2.4 без рекомпиляции Apache сервера - mod_http2

Если для активации http2 в nginx достаточно просто подключить сертификат и добавить опцию http2 в listen, то в случае с apache понадобится пересборка веб-сервера с опцией --enbale-http2.
Но можно обойтись и без! Для этого есть репозиторий от CodeIt с mod_http2.
Устанавливаем репозиторий:
# wget https://repo.codeit.guru/codeit.el`rpm -q --qf "%{VERSION}" $(rpm -q --whatprovides redhat-release)`.repo
# cp codeit.el7.repo /etc/yum.repos.d/
Устанавливаем сам модуль
# yum install mod_http2.x86_64
Загружены модули: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.sh.cvut.cz
 * epel: epel.mirror.liteserver.nl
 * extras: ftp.sh.cvut.cz
 * remi: mirror.serverion.com
 * remi-php55: mirror.serverion.com
 * remi-php56: mirror.serverion.com
 * remi-test: mirror.serverion.com
 * updates: ftp.sh.cvut.cz
Разрешение зависимостей
--> Проверка сценария
---> Пакет mod_http2.x86_64 0:1.15.3-1.codeit помечен для установки
--> Обработка зависимостей: libnghttp2 >= 1.21.1 пакета: mod_http2-1.15.3-1.codeit.x86_64
--> Обработка зависимостей: libnghttp2.so.14()(64bit) пакета: mod_http2-1.15.3-1.codeit.x86_64
--> Проверка сценария
---> Пакет libnghttp2.x86_64 0:1.31.1-2.el7 помечен для установки
--> Обработка конфликта: mod_http2-1.15.3-1.codeit.x86_64 конфликтует с httpd < 2.4.25-8
--> Перепроверка зависимостей с новыми параметрами.
--> Проверка сценария
---> Пакет httpd.x86_64 0:2.4.6-118.el7.centos помечен для обновления
--> Обработка зависимостей: httpd = 2.4.6-118.el7.centos пакета: 1:mod_ssl-2.4.6-118.el7.centos.x86_64
---> Пакет httpd.x86_64 0:2.4.41-4.codeit.el7 помечен как обновление
--> Обработка зависимостей: httpd-tools = 2.4.41-4.codeit.el7 пакета: httpd-2.4.41-4.codeit.el7.x86_64
--> Обработка зависимостей: httpd-filesystem = 2.4.41-4.codeit.el7 пакета: httpd-2.4.41-4.codeit.el7.x86_64
--> Обработка зависимостей: httpd-filesystem пакета: httpd-2.4.41-4.codeit.el7.x86_64
--> Обработка зависимостей: libbrotlienc.so.1()(64bit) пакета: httpd-2.4.41-4.codeit.el7.x86_64
--> Обработка зависимостей: libbrotlicommon.so.1()(64bit) пакета: httpd-2.4.41-4.codeit.el7.x86_64
--> Проверка сценария
---> Пакет brotli.x86_64 0:1.0.7-5.el7 помечен для установки
---> Пакет httpd-filesystem.noarch 0:2.4.41-4.codeit.el7 помечен для установки
---> Пакет httpd-tools.x86_64 0:2.4.6-118.el7.centos помечен для обновления
---> Пакет httpd-tools.x86_64 0:2.4.41-4.codeit.el7 помечен как обновление
---> Пакет mod_ssl.x86_64 1:2.4.6-118.el7.centos помечен для обновления
---> Пакет mod_ssl.x86_64 1:2.4.41-4.codeit.el7 помечен как обновление
--> Обработка зависимостей: sscg >= 2.2.0 пакета: 1:mod_ssl-2.4.41-4.codeit.el7.x86_64
--> Проверка сценария
---> Пакет sscg.x86_64 0:2.5.1-1.el7 помечен для установки
--> Обработка зависимостей: libpath_utils.so.1(PATH_UTILS_0.2.1)(64bit) пакета: sscg-2.5.1-1.el7.x86_64
--> Обработка зависимостей: libtalloc.so.2(TALLOC_2.0.2)(64bit) пакета: sscg-2.5.1-1.el7.x86_64
--> Обработка зависимостей: libpath_utils.so.1()(64bit) пакета: sscg-2.5.1-1.el7.x86_64
--> Обработка зависимостей: libtalloc.so.2()(64bit) пакета: sscg-2.5.1-1.el7.x86_64
--> Проверка сценария
---> Пакет libpath_utils.x86_64 0:0.2.1-32.el7 помечен для установки
---> Пакет libtalloc.x86_64 0:2.1.14-1.el7 помечен для установки
--> Обработка конфликта: httpd-2.4.41-4.codeit.el7.x86_64 конфликтует с apr < 1.5.0-1
--> Перепроверка зависимостей с новыми параметрами.
--> Проверка сценария
---> Пакет apr.x86_64 0:1.4.8-3.el7_4.1 помечен для обновления
---> Пакет apr.x86_64 0:1.5.2-1.el7.codeit помечен как обновление
--> Проверка зависимостей окончена

Зависимости определены

==================================================================================================
 Package                   Архитектура     Версия                           Репозиторий     Размер
==================================================================================================
Установка:
 mod_http2                 x86_64          1.15.3-1.codeit                  CodeIT          208 k
Обновление:
 apr                       x86_64          1.5.2-1.el7.codeit               CodeIT          111 k
 httpd                     x86_64          2.4.41-4.codeit.el7              CodeIT          1.4 M
Установка зависимостей:
 brotli                    x86_64          1.0.7-5.el7                      epel            318 k
 httpd-filesystem          noarch          2.4.41-4.codeit.el7              CodeIT           27 k
 libnghttp2                x86_64          1.31.1-2.el7                     epel             67 k
 libpath_utils             x86_64          0.2.1-32.el7                     base             28 k
 libtalloc                 x86_64          2.1.14-1.el7                     base             32 k
 sscg                      x86_64          2.5.1-1.el7                      epel             53 k
Обновление зависимостей:
 httpd-tools               x86_64          2.4.41-4.codeit.el7              CodeIT          1.3 M
 mod_ssl                   x86_64          1:2.4.41-4.codeit.el7            CodeIT          1.3 M

Итого за операцию
==================================================================================================
Установить  1 пакет  (+6 зависимых)
Обновить    2 пакета (+2 зависимых)

Объем загрузки: 4.8 M
Is this ok [y/d/N]: y

 Обратите внимание, что из репозитория CodeIt так же обновится и сам http сервер.
Так же я заменил старый /etc/httpd/conf.modules.d/00-proxy.conf на новый /etc/httpd/conf.modules.d/00-proxy.conf.rpmnew.

Готово, директива     Protocols h2 http/1.1 готова к использованию в конфигурации apache.
17 сент. 2019 г.

ISPManager 5 - вернуть общий лог /var/log/nginx/access.log

В ispmanager5 общий лог /var/log/nginx/access.log сервера по-умолчанию не пишется, все логи разбиты по доменам и пишутся в соответствующие /var/log/httpd-log/site.ru.access.log . Но иногда бывается очень полезно посмотреть общий лог сервера. И внезапно оказывается, что включить его через глобальный конфиг nginx не выйдет. А чтобы включить логгирование сделать нужно следующее: в директории /etc/nginx/vhosts-includes/ создаем файл log.conf (название файла может быть любым, главное, чтобы он оканчивался на conf ), а в него добавляем:
access_log /var/log/nginx/access.log main;
Сохраняем, делает рестарт сервиса nginx и проверяем лог с помощью tail -f /var/log/nginx/access.log 
4 сент. 2019 г.

Ошибка: Пакет: php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64 (remi-php56) Необходимо: libzip5(x86-64) >= 1.5.1

При обновлении php с версии php5.3 до php5.6 в Centos 6 возникает следующая ошибка
# yum update php
Загружены модули: fastestmirror, security
Подготовка к обновлению
Loading mirror speeds from cached hostfile
 * base: mirrors.daticum.com
 * epel: epel.uni-sofia.bg
 * extras: mirrors.daticum.com
 * remi-php56: mirrors.uni-ruse.bg
 * updates: mirrors.daticum.com
Разрешение зависимостей
--> Проверка сценария
---> Package php.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php.x86_64 0:5.6.40-13.el6.remi will be an update
--> Обработка зависимостей: php-common(x86-64) = 5.6.40-13.el6.remi для пакета: php-5.6.40-13.el6.remi.x86_64
--> Обработка зависимостей: php-cli(x86-64) = 5.6.40-13.el6.remi для пакета: php-5.6.40-13.el6.remi.x86_64
--> Проверка сценария
---> Package php-cli.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php-cli.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-common.x86_64 0:5.3.3-49.el6 will be для обновления
--> Обработка зависимостей: php(api) = 20090626 для пакета: php-mcrypt-5.3.3-5.el6.x86_64
--> Обработка зависимостей: php(zend-abi) = 20090626 для пакета: php-mcrypt-5.3.3-5.el6.x86_64
--> Обработка зависимостей: php-common(x86-64) = 5.3.3-49.el6 для пакета: php-pdo-5.3.3-49.el6.x86_64
--> Обработка зависимостей: php-common(x86-64) = 5.3.3-49.el6 для пакета: php-mbstring-5.3.3-49.el6.x86_64
--> Обработка зависимостей: php-common(x86-64) = 5.3.3-49.el6 для пакета: php-mysql-5.3.3-49.el6.x86_64
---> Package php-common.x86_64 0:5.6.40-13.el6.remi will be an update
--> Обработка зависимостей: php-pecl-jsonc(x86-64) для пакета: php-common-5.6.40-13.el6.remi.x86_64
--> Обработка зависимостей: php-pecl-zip(x86-64) для пакета: php-common-5.6.40-13.el6.remi.x86_64
--> Проверка сценария
---> Package php-mbstring.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php-mbstring.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-mcrypt.x86_64 0:5.3.3-5.el6 will be для обновления
---> Package php-mcrypt.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-mysql.x86_64 0:5.3.3-49.el6 will be как недействительный
---> Package php-mysqlnd.x86_64 0:5.6.40-13.el6.remi will be obsoleting
---> Package php-pdo.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php-pdo.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-pecl-jsonc.x86_64 0:1.3.10-2.el6.remi.5.6 will be для установки
---> Package php-pecl-zip.x86_64 0:1.15.4-1.el6.remi.5.6 will be для установки
--> Обработка зависимостей: libzip5(x86-64) >= 1.5.1 для пакета: php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64
--> Обработка зависимостей: libzip.so.5()(64bit) для пакета: php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64
--> Проверка зависимостей окончена
Ошибка: Пакет: php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64 (remi-php56)
            Необходимо: libzip5(x86-64) >= 1.5.1
Ошибка: Пакет: php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64 (remi-php56)
            Необходимо: libzip.so.5()(64bit)
 Вы можете попробовать --skip-broken чтобы обойти проблему
 Вы можете попробовать запустить: rpm -Va --nofiles --nodigest
То есть нужен libzip5.
Устанавливаем его вручную
yum --enablerepo=remi install libzip5

И пробуем еще раз обновление php
# yum update php
Загружены модули: fastestmirror, security
Подготовка к обновлению
Loading mirror speeds from cached hostfile
 * base: mirrors.daticum.com
 * epel: epel.uni-sofia.bg
 * extras: mirrors.daticum.com
 * remi-php56: mirrors.uni-ruse.bg
 * updates: mirrors.daticum.com
Пробуем другое зеркало.
Разрешение зависимостей
--> Проверка сценария
---> Package php.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php.x86_64 0:5.6.40-13.el6.remi will be an update
--> Обработка зависимостей: php-common(x86-64) = 5.6.40-13.el6.remi для пакета: php-5.6.40-13.el6.remi.x86_64
--> Обработка зависимостей: php-cli(x86-64) = 5.6.40-13.el6.remi для пакета: php-5.6.40-13.el6.remi.x86_64
--> Проверка сценария
---> Package php-cli.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php-cli.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-common.x86_64 0:5.3.3-49.el6 will be для обновления
--> Обработка зависимостей: php(api) = 20090626 для пакета: php-mcrypt-5.3.3-5.el6.x86_64
--> Обработка зависимостей: php(zend-abi) = 20090626 для пакета: php-mcrypt-5.3.3-5.el6.x86_64
--> Обработка зависимостей: php-common(x86-64) = 5.3.3-49.el6 для пакета: php-pdo-5.3.3-49.el6.x86_64
--> Обработка зависимостей: php-common(x86-64) = 5.3.3-49.el6 для пакета: php-mbstring-5.3.3-49.el6.x86_64
--> Обработка зависимостей: php-common(x86-64) = 5.3.3-49.el6 для пакета: php-mysql-5.3.3-49.el6.x86_64
---> Package php-common.x86_64 0:5.6.40-13.el6.remi will be an update
--> Обработка зависимостей: php-pecl-jsonc(x86-64) для пакета: php-common-5.6.40-13.el6.remi.x86_64
--> Обработка зависимостей: php-pecl-zip(x86-64) для пакета: php-common-5.6.40-13.el6.remi.x86_64
--> Проверка сценария
---> Package php-mbstring.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php-mbstring.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-mcrypt.x86_64 0:5.3.3-5.el6 will be для обновления
---> Package php-mcrypt.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-mysql.x86_64 0:5.3.3-49.el6 will be как недействительный
---> Package php-mysqlnd.x86_64 0:5.6.40-13.el6.remi will be obsoleting
---> Package php-pdo.x86_64 0:5.3.3-49.el6 will be для обновления
---> Package php-pdo.x86_64 0:5.6.40-13.el6.remi will be an update
---> Package php-pecl-jsonc.x86_64 0:1.3.10-2.el6.remi.5.6 will be для установки
---> Package php-pecl-zip.x86_64 0:1.15.4-1.el6.remi.5.6 will be для установки
--> Проверка зависимостей окончена

Зависимости разрешены

===============================================================================================
 Пакет                  Архитектура    Версия                         Репозиторий        Размер
===============================================================================================
Установка:
 php-mysqlnd            x86_64         5.6.40-13.el6.remi             remi-php56         280 k
     замена  php-mysql.x86_64 5.3.3-49.el6
Обновление:
 php                    x86_64         5.6.40-13.el6.remi             remi-php56         2.7 M
Установка зависимостей:
 php-pecl-jsonc         x86_64         1.3.10-2.el6.remi.5.6          remi-php56          52 k
 php-pecl-zip           x86_64         1.15.4-1.el6.remi.5.6          remi-php56          54 k
Обновление зависимостей:
 php-cli                x86_64         5.6.40-13.el6.remi             remi-php56         4.0 M
 php-common             x86_64         5.6.40-13.el6.remi             remi-php56         1.1 M
 php-mbstring           x86_64         5.6.40-13.el6.remi             remi-php56         973 k
 php-mcrypt             x86_64         5.6.40-13.el6.remi             remi-php56          52 k
 php-pdo                x86_64         5.6.40-13.el6.remi             remi-php56         122 k

Результат операции
===============================================================================================
Установить     3 пакет(а,ов)
Обновить     6 пакет(а,ов)

Объем загрузки: 9.2 M
Продолжить? [y/N]: y
Загрузка пакетов:
(1/9): php-5.6.40-13.el6.remi.x86_64.rpm                                | 2.7 MB     00:01    
(2/9): php-cli-5.6.40-13.el6.remi.x86_64.rpm                            | 4.0 MB     00:02    
(3/9): php-common-5.6.40-13.el6.remi.x86_64.rpm                         | 1.1 MB     00:00    
(4/9): php-mbstring-5.6.40-13.el6.remi.x86_64.rpm                       | 973 kB     00:00    
(5/9): php-mcrypt-5.6.40-13.el6.remi.x86_64.rpm                         |  52 kB     00:00    
(6/9): php-mysqlnd-5.6.40-13.el6.remi.x86_64.rpm                        | 280 kB     00:00    
(7/9): php-pdo-5.6.40-13.el6.remi.x86_64.rpm                            | 122 kB     00:00    
(8/9): php-pecl-jsonc-1.3.10-2.el6.remi.5.6.x86_64.rpm                  |  52 kB     00:00    
(9/9): php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64.rpm                    |  54 kB     00:00    
-----------------------------------------------------------------------------------------------
Общий размер                                                   1.5 MB/s | 9.2 MB     00:06    
Запуск rpm_check_debug
Проверяем сценарий
Проверка сценария прошла успешно
Запускается сценарий
  Установка   : php-pecl-jsonc-1.3.10-2.el6.remi.5.6.x86_64                               1/16
  Установка   : php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64                                 2/16
  Обновление  : php-common-5.6.40-13.el6.remi.x86_64                                      3/16
warning: /etc/php.ini created as /etc/php.ini.rpmnew
  Обновление  : php-cli-5.6.40-13.el6.remi.x86_64                                         4/16
  Обновление  : php-pdo-5.6.40-13.el6.remi.x86_64                                         5/16
  Установка   : php-mysqlnd-5.6.40-13.el6.remi.x86_64                                     6/16
  Обновление  : php-5.6.40-13.el6.remi.x86_64                                             7/16
  Обновление  : php-mbstring-5.6.40-13.el6.remi.x86_64                                    8/16
  Обновление  : php-mcrypt-5.6.40-13.el6.remi.x86_64                                      9/16
  Удаление    : php-mysql-5.3.3-49.el6.x86_64                                            10/16
  Очистка     : php-5.3.3-49.el6.x86_64                                                  11/16
  Очистка     : php-cli-5.3.3-49.el6.x86_64                                              12/16
  Очистка     : php-pdo-5.3.3-49.el6.x86_64                                              13/16
  Очистка     : php-mcrypt-5.3.3-5.el6.x86_64                                            14/16
  Очистка     : php-mbstring-5.3.3-49.el6.x86_64                                         15/16
  Очистка     : php-common-5.3.3-49.el6.x86_64                                           16/16
=====================================================================

  WARNING : PHP 5.6 have reached its "End of Life" in
  January 2019. Even, if this package includes some of
  the important security fix, backported from 7.1, the
  UPGRADE to a maintained version is very strongly RECOMMENDED.

=====================================================================
  Verifying   : php-5.6.40-13.el6.remi.x86_64                                             1/16
  Verifying   : php-common-5.6.40-13.el6.remi.x86_64                                      2/16
  Verifying   : php-mbstring-5.6.40-13.el6.remi.x86_64                                    3/16
  Verifying   : php-pecl-jsonc-1.3.10-2.el6.remi.5.6.x86_64                               4/16
  Verifying   : php-mcrypt-5.6.40-13.el6.remi.x86_64                                      5/16
  Verifying   : php-cli-5.6.40-13.el6.remi.x86_64                                         6/16
  Verifying   : php-mysqlnd-5.6.40-13.el6.remi.x86_64                                     7/16
  Verifying   : php-pecl-zip-1.15.4-1.el6.remi.5.6.x86_64                                 8/16
  Verifying   : php-pdo-5.6.40-13.el6.remi.x86_64                                         9/16
  Verifying   : php-pdo-5.3.3-49.el6.x86_64                                              10/16
  Verifying   : php-mbstring-5.3.3-49.el6.x86_64                                         11/16
  Verifying   : php-mysql-5.3.3-49.el6.x86_64                                            12/16
  Verifying   : php-mcrypt-5.3.3-5.el6.x86_64                                            13/16
  Verifying   : php-cli-5.3.3-49.el6.x86_64                                              14/16
  Verifying   : php-5.3.3-49.el6.x86_64                                                  15/16
  Verifying   : php-common-5.3.3-49.el6.x86_64                                           16/16

Установлено:
  php-mysqlnd.x86_64 0:5.6.40-13.el6.remi                                                     

Зависимости установлены:
  php-pecl-jsonc.x86_64 0:1.3.10-2.el6.remi.5.6   php-pecl-zip.x86_64 0:1.15.4-1.el6.remi.5.6 

Обновлено:
  php.x86_64 0:5.6.40-13.el6.remi                                                             

Зависимости обновлены:
  php-cli.x86_64 0:5.6.40-13.el6.remi             php-common.x86_64 0:5.6.40-13.el6.remi      
  php-mbstring.x86_64 0:5.6.40-13.el6.remi        php-mcrypt.x86_64 0:5.6.40-13.el6.remi      
  php-pdo.x86_64 0:5.6.40-13.el6.remi           

Заменено:
  php-mysql.x86_64 0:5.3.3-49.el6  
15 авг. 2019 г.

Автообновление wildcard letsencrypt сертификата

Получить wildcard сертификат бесплатно сейчас довольно легко, через Letsencypt. С помощью подтверждения через DNS записи. Проблема лишь в том, что для продления сертификата оперцию придется повторить. У "больших" игроков на рынке есть специальные плагины для автообновления, как то certbot-dns-cloudflare или certbot-dns-digitalocean.  Сегодня же мы рассмотрим для этих целей плагин https://github.com/joohoi/acme-dns-certbot-joohoi .

Скрипт очень прост в использовании. Качаем его:
 # curl -o /etc/letsencrypt/acme-dns-auth.py https://raw.githubusercontent.com/joohoi/acme-dns-certbot-joohoi/master/acme-dns-auth.py
# chmod 0700 /etc/letsencrypt/acme-dns-auth.py
В случае необходимости настройки в скрипте можно отредактировать ( в частности ACMEDNS_URL ).

Теперь нужно выпустить сертификат. Для этого помимо стандартных опций для получения wildcard letsencrypt сертификата добавляется --manual-auth-hook , который указывает на этот самый скрипт, и который будет запомнен в качестве хука для домена на будущее продление.
 # certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py    --preferred-challenges dns --debug-challenges  -d example.org -d \*.example.org

Уточняем, что опция  --debug-challenges тут так же важна, она позволяет приостановить выполнение скрипта до момента, когда вы будете готовы к валидации CNAME записи.

Далее необходимо со стороны днс настроить запрашиваемую CNAME запись, подождать пока запись обновится, продолжить выполнение скрипта и получить сертификат.

Дальнейшее обновление может выполняться с помощью обычного крона и certbot renew.
20 июн. 2019 г.

Centos VestaCP - exim - Malformed value "unlimitedM" (expansion of "${extract{6}{:}{${lookup{$local_part}lsearch{/etc/exim4/domains/$domain/passwd}}}}M") in local_delivery transport

На одном из серверов возникла проблема с получением писем. В логах почтового сервера наблюдаем следующее:
2019-06-20 14:36:37 1hdvMr-0000Iu-Fm DKIM: d=sender.net s=dkim c=relaxed/relaxed a=rsa-sha256 b=1024 [verification failed - signature did not verify (headers probably modified in transit)]
2019-06-20 14:36:37 1hdvMr-0000Iu-Fm <= sender@sender.net H=mail.sender.net [185.14.28.86] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no K S=1527 id=0d4f9076-6cfb-6cfe-90f4-30ca6341e609@sender.net
2019-06-20 14:36:37 1hdvMr-0000Iu-Fm == admin@site.com.ua R=localuser T=local_delivery defer (-1): Malformed value "unlimitedM" (expansion of "${extract{6}{:}{${lookup{$local_part}lsearch{/etc/exim/domains/$domain/passwd}}}}M") in local_delivery transport

Решением будет правка скрипта пересборки почтовых конфигов.
Нужно отредактировать скрипт  /usr/local/vesta/func/rebuild.sh. Ищем там функцию rebuild_mail_domain_conf() и добавляем в конец:
if [ "$QUOTA" = 'unlimited' ]; then
       QUOTA=0
fi
После чего пересобираем конфиги
v-rebuild-mail-domains admin
 Готово, прием почты должен работать корректно.
11 июн. 2019 г.

Критическая уязвимость в Exim CVE-2019-10149 ( версии 4.87 по 4.91 )

6 июня стало известно о критический уязвимости почтового сервера Exim CVE-2019-10149.
Уязвимости подвержены версии с 4.87 по 4.91.
Фрагменты вирусов, эксплуатирующих данную уязвимость могут быть обнаружены в директориях:
/etc/cron.daily/cronlog
/etc/cron.d/root
/etc/cron.d/.cronbus
/etc/cron.hourly/cronlog
/etc/cron.monthly/cronlog
/var/spool/cron/root
/var/spool/cron/crontabs/root
/etc/cron.d/root
/etc/crontab
/root/.cache/
/root/.cache/a
/usr/local/bin/nptd
/root/.cache/.kswapd
/usr/bin/[kthrotlds]
/root/.ssh/authorized_keys
/.cache/*
/.cache/.sysud
/.cache/.a
/.cache/.favicon.ico
/.cache/.kswapd
/.cache/.ntp
Так же могут присутствовать ключи ssh, скрипты автозапуска в  /etc/rc.local .

Для быстрой очистки и обновления Firstvds выкатил небольшой скрипт, который чистит все файлы, вышеперечисленные, обновляет Exim, делает реинсталл curl'а.

Запустить скрипт можно так:
wget http://lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.sh

5 июн. 2019 г.

Firefox - после обновление пропали скрипты greasemonkey

После очередного обновления Firefox все скрипты greasemonkey (включая его самого) стали недоступны.
Речь идет об обновлении с версии Mozilla до 57 на версию выше.
Чтобы достать свои скрипты нужно полезть по следующему пути:
root@debian:/home/user# ls -la.mozilla/firefox/sbza604q.default/gm_scripts/MyUserScript/MyUserScript.user.js

Оттуда его можно выдернуть и перенести на новый greasmonkey
19 мая 2019 г.

Debian: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 88d 16h 32min 47s). Updates for this repository will not be applied.

На Debian 8 после переключения на архивный репозиторий ftp.debian.org на archive.debian.org запуск обновления пакетов командой apt-get update может завершиться ошибкой
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 88d 16h 32min 47s). Updates for this repository will not be applied.
Error executing command, exiting
Для решения этой проблемы apt можно запустить с ключем '' -o Acquire::Check-Valid-Until=false"
apt-get -o Acquire::Check-Valid-Until=false update
Сделать эту опцию перманентной можно так
echo 'Acquire::Check-Valid-Until "0";' > /etc/apt/apt.conf.d/10no-check-valid-until
после чего apt-get update будет работать в штатном режиме.
7 мая 2019 г.

Сброс пароля IMPI supermicro с загруженной ОС

Иногда может понадобится сброс пароля к IPMI . И если у вас уже имеется загруженная и работающая ОС подключенного к IPMI порту сервера, то сброс пароля IMPI  с этого сервера выглядит максимально просто.

Необходима утилита ipmitool. Теперь нужно определить список юзеров и ID необходимого нам:
# ipmitool user list
ID  Name         Callin  Link Auth    IPMI Msg   Channel Priv Limit
1                    true    false      false      Unknown (0x00)
2   ADMIN            true    false      false      Unknown (0x00)
3                    true    false      false      Unknown (0x00)
4                    true    false      false      Unknown (0x00)
5                    true    false      false      Unknown (0x00)
6                    true    false      false      Unknown (0x00)
7                    true    false      false      Unknown (0x00)
8                    true    false      false      Unknown (0x00)
9                    true    false      false      Unknown (0x00)
10                   true    false      false      Unknown (0x00)
Нужный нам юзер с ID 2.
Сбрасываем ему пароль:
# ipmitool user set password 2 passwdipmi
Set User Password command successful (user 2)
Готово.

 
13 февр. 2019 г.

Centos 7 + lvm2: после ребута изчезают созданные lvm тома - Timer to wait for more drives before activating degraded array md128

Имеем систему Centos 7, raid10, поверх него создается vg командой
vgcreate vg1 /dev/md128
Проверяем
# vgdisplay
 --- Volume group ---
 VG Name               vg1
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  7
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                3
 Open LV               2
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               1,75 TiB
 PE Size               4,00 MiB
 Total PE              459820
 Alloc PE / Size       11520 / 45,00 GiB
 Free  PE / Size       448300 / 1,71 TiB
 VG UUID               iW8xBm-WcJQ-ufP8-VzHH-WfgV-gWpo-A0rdS8
После рестарта же lvm не поднимется. Ни vgscan ни pvscan ничего не находят.
# vgscan
 Reading volume groups from cache.
# pvscan
 No matching physical volumes found
В логах можно заметить такие интересные строки
Started Timer to wait for more drives before activating degraded array md128
Stopped Timer to wait for more drives before activating degraded array md128
То есть почему-то при загрузке системы рейд md128 считается за " degraded". Соответственно на нем не могут инициализироваться lvm тома.
Погуглил на эту тему и натолкнулся на похожий баг https://bugzilla.redhat.com/show_bug.cgi?id=1445924 
Автор рекомендует выключить use_lvmetad  в конфиге /etc/lvm/lvm.conf. Что мы и сделали. И внезапно после ребута все работает как должно.

Загадкой осталось то, почему это происходит. В багтрекере причины тоже не были найдены.
10 янв. 2019 г.

Mariadb: Recovering after a crash using tc.log, Bad magic header in tc log

Клиент упустил момент, когда диск оказался заполненным и результатом оказалась неприятность с mysql сервером, который не восстанавливался после проблемы с ошибками в логе

янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [Note] Recovering after a crash using tc.log
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Bad magic header in tc log
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Can't init tc log
янв 10 14:12:06 post4302.vds mysqld[14648]: 2019-01-10 14:12:06 139976785651968 [ERROR] Aborting
янв 10 14:12:09 post4302.vds systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
янв 10 14:12:09 post4302.vds systemd[1]: Failed to start MariaDB 10.1.37 database server.
янв 10 14:12:09 post4302.vds systemd[1]: Unit mariadb.service entered failed state.
янв 10 14:12:09 post4302.vds systemd[1]: mariadb.service failed.

Решение довольно простое, удаляем из директории Mysql файл tc.log
mv /var/lib/mysql/tc.log /var/lib/mysql/tc.log.bkp

Ну не то чтобы удаляем, а скорее убираем.
Делаем рестарт Mysql сервера и все готово
[root@~]# service mysql restart
Restarting mysql (via systemctl):                          [  OK  ]
 
4 янв. 2019 г.

End of script output before headers: php - failed to setgid (1001: php)

Ни с того ни с сего рабочий буквально недавно сайт начал отдавать 500 ошибку с текстом в логе
End of script output before headers: php
В ходе небольших изысканий было обнаружено, что при попытке открыть сайт в лог /var/log/secure сыпятся следующие ошибки от suexec
Jan  3 22:44:58 user300 suexec[7386]: uid: (1001/admin) gid: (1001/admin) cmd: php
Jan  3 22:44:58 user300 suexec[7386]: failed to setgid (1001: php)
Jan  3 22:44:58 user300 suexec[7387]: uid: (1001/admin) gid: (1001/admin) cmd: php
Jan  3 22:44:58 user300 suexec[7387]: failed to setgid (1001: php)
Jan  3 22:44:58 user300 suexec[7388]: uid: (1001/admin) gid: (1001/admin) cmd: php
которые говорят нам о том, что вероятно у бинарника suexec не хватает S флага для установки SUID или SGID. Установить данный флаг можно командой:

chmod u+s /usr/sbin/suexec
после чего ошибки в логе пропадают.