sysmerge IT

23 дек. 2017 г.

Centos: Device eth0 does not seem to be present после восстановления снепшота виртуальной машины

Ситуация с восстановлением снепшота виртуальной машины kvm выглядит довольно не сложно и способов реализации имеет не мало. В моем случае - создание виртуальной машины и dd в устройство со старого снепшота. В этом случае понадобится заменить IP адрес на новый после включения машины.
Но при этом возникает ошибка "Device eth0 does not seem to be present " при попытке поднять интерфейс.  Это случается из-за того что у сетевой карты нового ВПС будет новый MAC, отличный от того, что был сохранен для устройства в снепшоте. Соответственно система добавляет устройства в кач-ве eth1/2/3 etc, оставляя оригинальное, которое, как ни странно, но действительно не существует.
Соответственно нужно удалить старое и подкорректировать записи нового, чтобы он стал eth0.
Делается это вот тут /etc/udev/rules.d/70-persistent-net.rule.

Изначально записи могут выглядеть так:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0d:12:43:cd:b7", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:53:32:8c:df:3d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Необходимо удалить первую запись и NAME у второй сменить на eth0.
Теперь выполняем
start_udev
 
Не забудьте так же, что изменения вносятся так же и сюда /etc/sysconfig/network-scripts/ifcfg-eth0, нужно сменить HWADDR на соответственно 00:53:32:8c:df:3d - это новый MAC. О смене записей IP, шлюза и тд не говорю, это само собой разумеется.
24 нояб. 2017 г.

sed: удалить N строк после совпадения

Имелась задача - много-много-много-много, ну вы поняли, файлов, в которые некто нагадил вредоносным скриптом. Нагажено везде одинаково, отличался номер начальной строки, куда был вставлен код. Сооружать многострочный паттерн для sed как-то очень неудобно, а потому можно просто найти первую строку(она, благо, нигде больше не встречалась в коде) и удалить N строчек после, включая само вхождение паттерна.
Выглядит так
# find /var/www/files/ -type f -name "index.php" -exec sed -i".bak" -e "/ini_set('display_errors','Off'); error_reporting('E_ALL');/,+9d" {} \;
 Ищем мы, как вы поняли, " ini_set('display_errors','Off'); error_reporting('E_ALL');", и удаляем эту строку +  9 следующих. При этом сохраняется оригинал измененного файла .bak
31 окт. 2017 г.

Centos 7: (24)Too many open files: AH00099: could not create /run/httpd/httpd.pid

Свежий сервер, два с половиной виртуалхоста, а при попытке поднять httpd сервер имеем следующее:
[Tue Oct 31 22:14:17.147586 2017] [suexec:notice] [pid 3761] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Oct 31 22:14:17.170277 2017] [so:warn] [pid 3761] AH01574: module ruid2_module is already loaded, skipping
[Tue Oct 31 22:14:17.293573 2017] [auth_digest:notice] [pid 3761] AH01757: generating secret for digest authentication ...
[Tue Oct 31 22:14:17.296495 2017] [:notice] [pid 3761] mod_ruid2/0.9.8 enabled
[Tue Oct 31 22:14:17.299556 2017] [core:error] [pid 3761] (24)Too many open files: AH00099: could not create /run/httpd/httpd.pid
[Tue Oct 31 22:14:17.299579 2017] [core:error] [pid 3761] AH00100: httpd: could not log pid to file /run/httpd/httpd.pid

Интересует нас вот эта часть  "24)Too many open files:". Но системный ulimit тут не особо помогает, необходимо добавить в юнит для httpd параметр для указание LimiNOFILE. Для этого создаем папку
# mkdir /lib/systemd/system/httpd.service.d/
создаем файл limit_nofile.conf
# nano  /lib/systemd/system/httpd.service.d/limit_nofile.conf
с вот таким содержимым
[Service]
LimitNOFILE=65536
После правок делаем
systemctl daemon-reload
Справедливости ради, те же правки можно было внести в  /lib/systemd/system/httpd.service.
11 окт. 2017 г.

Vesta: не работает spamassassin

О некоторых "особенностях" панели Vesta я знал и ранее, а вот о том, что на системах с размером оперативной памяти меньшей 3Gb установка галочки "антиспам" в панели не дает ровном счетом ничего, узнал только недавно.
Исправляется это все довольно легко, в моем случае даже не пришлось доустанавливать Spamassassin, он был установлен, но не работал, так как не был активирован в конфиге Exim.
Что ж, добавляем это
SPAMASSASSIN = yes
SPAM_SCORE = 10
в самое начало конфига exim /etc/exim/exim.conf. Рестартим сервис и проверяем.
15 сент. 2017 г.

nginxconf 2017: Оптимизация веб серверов под большие пропускные способности и низкие задержки. Часть 1.

Перевод доклада Алексея Иванова на nginxConf 2017 на тему "Оптимизация веб серверов под большие пропускные способности и низкие задержки"(Optimizing web servers for high throughput and low latency). Оригинал тут. Перевод вольный, не дословный. Некоторые части(вроде вступлений) опущены.

Часть 1. Железо.

Процессор.
Для высоких показателей ассиметричного RSA / EC (ec - elliptic curve, криптография на эллиптических кривых) необходимо обратить внимание на процессоры с поддержкой технологии AVX2(avx2 в /proc/cpuinfo) а так же расчеты с длинной арифметикой (adx и bmi). В случае с симметричным шифрованием обратите внимание на AES-NI для шифрования AES и AVX512 в случае с ChaCha+Poly. У Intel есть сравнение производительности различных поколений их железа на OpenSSL 1.0.2, которое демонстрирует эффект от выбора того или иного процессора.


Чувствительные к задержкам задачи, как роутинг, к примеру, получат прирост к производительности в случае использования меньшего количество NUMA нод и отключением HT(Hyper-Threading). Задачи, требующие большой пропускной способности, в свою очередь потребуют большего количества ядер и включенного HT, причем зависимость от NUMA минимальна.

Если вы используете железо от Intel, то необходимо выбирать как минимум Haswell/Broadwell, а в идеале  Skylake процессоры. Для AMD идеальным выбором будет EPYC.

NIC(сетевая карта)
Тут вы должны выбирать как минимум 10G,а  лучше даже 25G карточки. Если необходимы еще большие объемы на 1 сервер, то тюнинг, описанный тут, будет не особо эффективен и придется тюнить на уровне ядра. С точки зрения ПО - выбирайте открытые драйверы с активными рассылками и большим комьюнити. Это пригодится вам если (а точнее "когда") вы будете дебажить проблемы на уровне драйверов.

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

Диск
Выбор зависит от требований к буферизации/кешированию, но если вы намереваетесь кешировать большие объемы данных, то стоить выбирать хранилища на основе флеш-памяти.  Некоторые заходят настолько далеко, что используют файловые системы, заточенные под флеш-хранилища, правда, в основном, они не дают производительности лучшей чем чистый ext4/xfs. В любом случае, главное не убейте свой флеш из-за того, что не включили TRIM или забыли обновить прошивку.

21 авг. 2017 г.

VESTA - добавление кириллических доменов

Точно известно, что VESTACP без проблем работает с кириллическими доменами, причем очень даже неплохо работает, без многих свистоплясок с пайникодом. Но вот давеча при добавлении домена обнаружил, что создается пустой домен. При этом VESTA делает все необходимое - днс, файлы конфигов и тд. С одной оговоркой - вместо имени домена там ничего нет.
Как оказалось проблема была в локали и решается очень просто
locale-gen en_US.UTF-8
locale-gen ru_RU.UTF-8
echo LANG=en_US.UTF-8 > /etc/default/locale
source /etc/default/locale
service vesta restart
27 июл. 2017 г.

mysql: восстановление/создание удаленного root пользователя

Давайте представим чисто гипотетическую ситуацию - у вас пропал root юзер у mysql. Удалился, испарился, вы его сами удалили. Как быстро восстановить его не прибегая к, скажем, реинсталлу? Я больше скажу, мне даже dpkg-reconfigure не помог(дело имеет место быть в окружении Debian 7).
Итак, нам нужно попасть в mysql консоль. Начинаем все так же, как при восстановлении/сбросе пароля root юзера mysql
service mysql stop
mysqld_safe --skip-grant-tables &
mysql -u root -p

Теперь, когда мы в консоли, выполняем это

mysql> select * from user;
+-----------+------------------+-------------------------------------------+-------------+-------------+-------------+-------------+-------------+-----------+-------------+---------------+--------------+-----------+------------+-----------------+------------+------------+--------------+------------+-----------------------+------------------+--------------+-----------------+------------------+------------------+----------------+---------------------+--------------------+------------------+------------+--------------+------------------------+----------+------------+-------------+--------------+---------------+-------------+-----------------+----------------------+--------+-----------------------+
| Host      | User             | Password                                  | Select_priv | Insert_priv | Update_priv | Delete_priv | Create_priv | Drop_priv | Reload_priv | Shutdown_priv | Process_priv | File_priv | Grant_priv | References_priv | Index_priv | Alter_priv | Show_db_priv | Super_priv | Create_tmp_table_priv | Lock_tables_priv | Execute_priv | Repl_slave_priv | Repl_client_priv | Create_view_priv | Show_view_priv | Create_routine_priv | Alter_routine_priv | Create_user_priv | Event_priv | Trigger_priv | Create_tablespace_priv | ssl_type | ssl_cipher | x509_issuer | x509_subject | max_questions | max_updates | max_connections | max_user_connections | plugin | authentication_string |
+-----------+------------------+-------------------------------------------+-------------+-------------+-------------+-------------+-------------+-----------+-------------+---------------+--------------+-----------+------------+-----------------+------------+------------+--------------+------------+-----------------------+------------------+--------------+-----------------+------------------+------------------+----------------+---------------------+--------------------+------------------+------------+--------------+------------------------+----------+------------+-------------+--------------+---------------+-------------+-----------------+----------------------+--------+-----------------------+
| localhost | coremgr          | *B36F5EE9244D1AE22E020DD046310DCBF8CB81C8 | Y           | Y           | Y           | Y           | Y           | Y         | Y           | Y             | Y            | Y         | Y          | Y               | Y          | Y          | Y            | Y          | Y                     | Y                | Y            | Y               | Y                | Y                | Y              | Y                   | Y                  | Y                | Y          | Y            | Y                      |          |            |             |              |             0 |           0 |               0 |                    0 |        | NULL                  |
| localhost | debian-sys-maint | *35B6EC84BA62A0E4DE3434B0FABB975E63E1CE84 | Y           | Y           | Y           | Y           | Y           | Y         | Y           | Y             | Y            | Y         | Y          | Y               | Y          | Y          | Y            | Y          | Y                     | Y                | Y            | Y               | Y                | Y                | Y              | Y                   | Y                  | Y                | Y          | Y            | Y                      |          |            |             |              |             0 |           0 |               0 |                    0 |        | NULL                  |
| localhost | test       | *10A3664B014A3B680FAF26AD3A309913132AFF71 | N           | N           | N           | N           | N           | N         | N           | N             | N            | N         | N          | N               | N          | N          | N            | N          | N                     | N                | N            | N               | N                | N                | N              | N                   | N                  | N                | N          | N            | N                      |          |            |             |              |             0 |           0 |               0 |                    0 |        | NULL                  |
+-----------+------------------+-------------------------------------------+-------------+-------------+-------------+-------------+-------------+-----------+-------------+---------------+--------------+-----------+------------+-----------------+------------+------------+--------------+------------+-----------------------+------------------+--------------+-----------------+------------------+------------------+----------------+---------------------+--------------------+------------------+------------+--------------+------------------------+----------+------------+-------------+--------------+---------------+-------------+-----------------+----------------------+--------+-----------------------+


Выглядит страшно, на самом деле это таблица с существующими юзерами. И правда, mysql юзера там нет. Но зато мы видим формат и список параметров каждого юзера. Что же мешает нам просто добавить туда нового юзера? Ничего. Делаем это:
mysql> INSERT INTO user VALUES ('localhost','root',password('НОВЫЙ_ПАРОЛЬ'),'Y','Y ','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','','','','',0,0,0,0,'',NULL);
mysql>FLUSH PRIVILEGES;

Все, выходим, запускаем mysql сервер и проверяем работу.
25 июн. 2017 г.

Ретро ThinkPad'ы снова вернутся! (наверное)

Тут новость вышла в блоuе Lenovo http://blog.lenovo.com/en/blog/retro-thinkpad-its-alive/ о том, что линейка ретро Thinkpad'ов, когда-то так полюбившаяся многим пользователям, снова в деле и я, как большой фанат этот линейки и гордый владелец W520 и X201s, не смог пройти мимо. Искренне надеюсь, что все будет действительно так, как было раньше, особенно что касается клавиатуры, потому что то, что Леново сделали с этими ноутбуками - жуткий пиздец, не удивительно, что многие не меняют свои старые x200, x61, T410  столетней давности - ничто из новых поделок Леновы и в подметки не годится как по качеству сборки так и по юзабилити.

Правда насчет "линейки" я немного приврал, речь скорее об одной модели, насколько я понял.

Скрестим пальцы и будем ждать новостей.
Топовый комментарий под постов Lenovo:
Please don't be a T470 with a different keyboard... Please don't be a T470 with a different keyboard...
21 июн. 2017 г.

установка модулей к php в нестандартной директории

Как установить модуль php к дополнительным версиям php  тут мы уже разбирали. Там мы собирали модуль руками. Но есть способ и попроще - использование pecl.
Рассмотрим, опять таки, случай с ISPManager5 и его дополнительными версиями php в папке /opt/. Последовательность действий крайне проста:

# cd /opt/php70/
# ./bin/pecl install apcu
# /opt/php54/etc/МОДУЛЬ.ini
# ls -la ./lib/php/modules/
  1. Переходим в папку с php. В данном случае - php 7.0
  2. Используем pecl из папки этой версии Php, что логично, именно потому модуль будет собран сюда, а не, скажем, в дефолтный системный php.
  3. Создаем файл конфига и прописываем там путь до модуля
  4. Просто удостоверяемся, что модуль на месте 
По большому счет pecl делает за нас то, что мы делали тут.  Кроме создания конфига, само собой, это бремя так и останется висеть на нас.
9 июн. 2017 г.

Vesta: циклическое ввостановление бекапа v-restore-user [Error 3]

Словил давеча глюк в панели VESTACP. Суть такова - пытаюсь восстановить бекап, а панель сообщает, что задание на восстановление уже работает. Ну ладно, думаю, пойду проверю, как он там работает. Смотрю в логи, вижу следующее:

2017-05-15 13:25:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 13:30:02 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 13:35:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 13:40:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 13:45:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 13:46:58 v-update-sys-queue  [Error 1]
2017-05-15 13:55:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 14:00:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 14:05:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]
2017-05-15 14:10:01 v-restore-user  'admin' 'admin.2017-05-11.tar' 'site.com' 'no' 'no' 'no' 'no' 'no' 'yes' [Error 3]

Что в этом занимательного, спросите вы. А вот в чем - бекапа "admin.2017-05-11.tar" у меня уже нет, он удален был. А восстанавливать я собирался совершенно другой.

То есть по сути VESTA пытается каждые 5 минут выполнить задание, которое уже устарело, а так как оно возвращает ошибку Error 3, что значит отсутствие файла бекапа, то и из очереди не вылетает.
Где хранится очередь заданий бекапа в VESTA? Тут  /usr/local/vesta/data/queue/backup.pipe. Заглядываем в файл, а там и правда задание на восстановление. Очищаем файл, после чего выполняем

sudo /usr/local/vesta/bin/v-update-sys-queue backup
  для обновления очереди бекапирования.
Теперь можно запускать и корректное задание.
27 мая 2017 г.

Nginx 1.10: установка ngx_pagespeed dymamic module (Centos 7)

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

В первую очередь отметим - ура, товарищи, в nginx добавлена поддержка динамических модулей с ветки 1.9.11. Думаю, ни для кого не секрет, что статические модули nginx - тот еще геморрой, требующий ребилда самого nginx для их добавления. Динамические же модули компилируются в виде знакомых всем .so файлов и хранятся в папке nginx/modules и могут быть подключены/отключены без рекомпиляции.

Правда, стоит отметить, что нам компиляция таки пригодится, потому что работа начинается на nginx версии 1.8.1 (у многих и того меньше).

Начнем с подготовки самого модули ngx_pagespeed. Идем сюда https://modpagespeed.com/doc/build_ngx_pagespeed_from_source. Запускаем в консоли

 # bash <(curl -f -L -sS https://ngxpagespeed.com/install) -m  

Ключ -m указывает на то, что мы хотим компилировать nginx с ngx_pagespeed в качестве динамического модуля. В итоге скрипт скачает все необходимые зависимости для сборки и вы увидите папку "ngx_pagespeed-latest-stable" и сообщение от скрипта:

 ngx_pagespeed is ready to be built against nginx.  
 When running ./configure:  
  Give ./configure the following arguments:  
   --add-dynamic-module=/root/ngx_pagespeed-latest-stable  
 If this is for integration with an already-built nginx, make sure  
 to include any other arguments you originally passed to  
 ./configure. You can see these with 'nginx -V'.  

То есть нам теперь остается скачать сорцы nginx(отсюда http://nginx.org/en/download.html и собрать их с добавлением опции --add-dynamic-module=/root/ngx_pagespeed-latest-stable. Приступим.

 # mkdir nginx-src  
 # cd nginx-src/  
 # wget http://nginx.org/download/nginx-1.10.3.tar.gz  
 # tar -xvf nginx-1.10.3.tar.gz  
 # cd nginx-1.10.3  

Теперь необходимо сконфигурировать. Тут удобно для начала вызвать nginx -V для текущей установки, скопировать все и добавить в конец --add-dynamic-module=/root/ngx_pagespeed-latest-stable. Так и сделаем:

 # ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --add-dynamic-module=/root/ngx_pagespeed-latest-stable--add-dynamic-module=/root/ngx_pagespeed-latest-stable--add-dynamic-module=/root/ngx_pagespeed-latest-stable  

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

 # make && make install  

Проверяем

 # service nginx restart  
 # nginx -V  
 nginx version: nginx/1.10.3  
 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)   
 built with OpenSSL 1.0.1e-fips 11 Feb 2013  
 TLS SNI support enabled  
 configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --add-dynamic-module=/root/ngx_pagespeed-latest-stable  

Готово, мы успешно установили динамический модуль ngx_pagespeed в nginx 1.10.3. Кстати, сам модуль вот тут:

 # ls /etc/nginx/modules/  
 ngx_pagespeed.so  

16 мая 2017 г.

Редирект с https на http без ошибки SSL сертификата

Недавно столкнулся с одной просьбой от клиента. Выглядела она следующим образом - у клиента есть сайт, пусть https://site.com, с SSL сертификатом. На этом же сайте у него настроены wildcard  автоподдомены, а вот сертификатик у него только на site.com.  Логично предположить, что открывая поддомен вываливается предупреждение от браузера о несоответствии сертификата домену. И клиент говорит "А вот бы здорово, если б такие запросы на поддомены редиректились на http, чтобы ошибку не видеть". И я подумал "Эх, вот и правда было  здорово", но на самом деле нет.

Увы и ах такая хитрость не пройдет. А все потому что SSL содинение устанавливается самым первым, до всех эти ваших редиректов и других потоков данных, потому что https соединение работает на более низком уровне, проще говоря шифрует сообщения привычного нам http,  которые на той стороне будут расшифрованы. Соответственно ошибку вам выкинет в любом случае, если сертификат не валиден. И только в случе его валидности соединение переходит на следующий уровень. Так вот клиент ушел восвояси, особенно расстроившись, когда увидел цены на wildcard ssl сертификаты.
3 мая 2017 г.

Debian 8: table 'phpmyadmin.pma_table_uiprefs' doesn't exist

Обратился знакомый с такой проблемой - при попытке просмотра любой таблицы в phpmyadmin выводится ошибка"table 'phpmyadmin.pma_table_uiprefs' doesn't exist", в полном виде она выглядела таким образом:
SQL query: DocumentationEdit Edit

SELECT  `prefs`
FROM  `phpmyadmin`.`pma_table_uiprefs`
WHERE  `username` =  'root'
AND  `db_name` =  'testdb'
AND  `table_name` =  'prefix_table'

MySQL said: Documentation

#1146 - Table 'phpmyadmin.pma_table_uiprefs' doesn't exist

 Лезу, значит, в phpmyadmin, а таблицы phpmyadmin там и нет вовсе. Первопричину, судя по всему, мы уже обнаружили. Выполняю

 # dpkg-reconfigure phpmyadmin  

и заполняю необходимые данные(как правило там все интуитивно понятно, логин, пароль администратора бд, название таблицы phpmyadmin, обслуживающий вебсервер).
После успешной установки таблиц пхпадмина идем у него, видим, что база уже создана. Отлично. Пытаемся открыть какую-то таблицу и..... та же ошибка! Всматриваемся внимательнее и внезапно обнаруживаем, что в установленной бд префикс имеет вид "pma__", в то время как в конфиге phpmyadmin указаны префиксы "pma_" (с одним нижним). Вот и вторая проблемка. Открываем /etc/phpmyadmin/config.inc.php и приводим это

   $cfg['Servers'][$i]['pmadb'] = $dbname;  
   $cfg['Servers'][$i]['bookmarktable'] = 'pma_bookmark';  
   $cfg['Servers'][$i]['relation'] = 'pma_relation';  
   $cfg['Servers'][$i]['table_info'] = 'pma_table_info';  
   $cfg['Servers'][$i]['table_coords'] = 'pma_table_coords';  
   $cfg['Servers'][$i]['pdf_pages'] = 'pma_pdf_pages';  
   $cfg['Servers'][$i]['column_info'] = 'pma_column_info';  
   $cfg['Servers'][$i]['history'] = 'pma_history';  
   $cfg['Servers'][$i]['table_uiprefs'] = 'pma_table_uiprefs';  
   $cfg['Servers'][$i]['designer_coords'] = 'pma_designer_coords';  
   $cfg['Servers'][$i]['tracking'] = 'pma_tracking';  
   $cfg['Servers'][$i]['userconfig'] = 'pma_userconfig';  
   $cfg['Servers'][$i]['recent'] = 'pma_recent';  

к такому виду

   $cfg['Servers'][$i]['pmadb'] = $dbname;  
   $cfg['Servers'][$i]['bookmarktable'] = 'pma__bookmark';  
   $cfg['Servers'][$i]['relation'] = 'pma__relation';  
   $cfg['Servers'][$i]['table_info'] = 'pma__table_info';  
   $cfg['Servers'][$i]['table_coords'] = 'pma__table_coords';  
   $cfg['Servers'][$i]['pdf_pages'] = 'pma__pdf_pages';  
   $cfg['Servers'][$i]['column_info'] = 'pma__column_info';  
   $cfg['Servers'][$i]['history'] = 'pma__history';  
   $cfg['Servers'][$i]['table_uiprefs'] = 'pma__table_uiprefs';  
   $cfg['Servers'][$i]['designer_coords'] = 'pma__designer_coords';  
   $cfg['Servers'][$i]['tracking'] = 'pma__tracking';  
   $cfg['Servers'][$i]['userconfig'] = 'pma__userconfig';  
   $cfg['Servers'][$i]['recent'] = 'pma__recent';  

Можно руками, но мы же не так просты, потому можно и sed'ом

 # sed -i 's/pma_/pma__/g' /etc/phpmyadmin/config.inc.php  

После этих нехитрых манипуляций все работает как часы.
16 апр. 2017 г.

Mysql error : Can't create new tempfile: './database/table.TMD'

Порой возникает необходимость починки таблиц в базах данных, когда невнимательные владельцы сайтов забывают следить за местом или считают необходимым, что в случае чего можно просто постоянно ребутать сервер, в конце-концов REPAIR все поправит. Но очередной mysqlcheck -A --auto-repair внезапно выдал следующее:

 Repairing tables  
 database.table  
 error  : Can't create new tempfile: './database/table.TMD'  
 status  : Operation failed  

Что же приключилось с таблицей? Как исправить?
TMD - это временный файл, из которого необходимо восстановить файл данных.
Тут нам на помощь придет утилита myisamchk, которая, как нас заверяют в манах, может исправить почти любые проблемы, кроме, разве что, уникальных ключей, которые на самом деле не уникальны. Последовательность действий проста - идем в папку с данными поломанной базы:

 # cd /var/lib/mysql/database/  

и выполняем следующую команду:

 # myisamchk -r -f table.MYI  
 - recovering (with sort) MyISAM-table 'table.MYI'  
 Data records: 3187017  
 - Fixing index 1  
 - Fixing index 2  

Ключ -r - соответственно восстановление(есть еще "нежное" восстановление с помощью -o), ключ -f - --force перезаписывать старые TMD файлы. Если данных много, то может потребоваться подождать довольно длительное время, но, как результат, получим восстановленные данные.
2 апр. 2017 г.

Centos: удалить без зависимостей пакет

Порой у каждого админа бывает моменты, когда необходимо удалить пакет без зависимостей в системе. В частности, в Centos. Решаешь удалить безобидный mysql, а пакетный менеджер хочет снести половину системы, хотя тебе они еще пригодятся, ведь Mysql ты вернешь из другого репозитория, к примеру.
Тут нам поможет мощный механизм RPM.
Понадобится 2 команды:

 # rpm -qa | grep "mysql"  
 # rpm -e --nodeps "mysql-5.5.54-1199.el5.art.x86_64"  

В первой мы ищем полное название пакета, который необходимо удалить без зависимости. Вторая - непосредственно удаление пакета с ключем --nodeps, который как раз и отвечает за то, что будет удален непосредственно указанный пакет, а его зависимости будут не тронуты.
27 мар. 2017 г.

ERROR 1018 (HY000): Can't read dir of '.' (errno: 24)

При попытке использовать команду 'SHOW DATABASES;' в консоли mysql получаем ошибку вида "ERROR 1018 (HY000): Can't read dir of '.' (errno: 24) ". В первую очередь проверяем, хватает ли места и инод ( df -h и df -i соответственно). Если все в порядке с местом, то очевидно, что проблема с лимитом открытых файлов, решение которой было описано ранее с помощью open-files-limit.
22 мар. 2017 г.

openbsd: процесс обновления снепшота от А до Я

Процесс обновления OpenBSD со снепшотов довольно прост. Итак, по шагам:
  1. Сделайте бекапы нужных данных. Да, всегда нужно иметь бекап. Тут вам помогут встроенные в систему dump/restore
  2. Читаем страницу https://www.openbsd.org/faq/current.html. Тут описываются основные изменения при обновлении снепшота а так же действия, необходимые к выполнению после обновления
  3. Скачиваем файлы снепшота. Я это описывал тут. 
  4. Копируем bsd.rd в корень.
  5. Ребутимся  - reboot
  6. Вместо обычной загрузки при старте системы вводим bsd.rd, это загрузит скачанный ранее ramdisk.
  7.  Дальнейший процесс очень похож на установку системы. Инсталлятор предлагает выбор процедуры  "(I)nstall, (U)pgrade, (A)utointall or (S)hell?", выбираем Upgrade.
  8. Источником обновления в нашем случае будет Disk. Устройство по идее должно быть автоматически смонтировано. В моем случае файлы снепшота лежали тут /mnt/home/USER/update/
  9. После окончания процесса установки опять ребутаемся.
  10. Загружаемся обычным способом. Выполняем sysmerge.
  11. Далее обновленияем пакеты - pkg_add -u
  12. Делаем еще один ребут.
  13. Готово, система обновлена. 
Я провожу данную процедуру 1-2 раза в месяц, занимает минут 20, большая часть времени из которых - скачивание и установка файлов.
16 мар. 2017 г.

certificate routines:X509_check_private_key:key values mismatch - проверяем соответствие ключа сертификату

Если nginx после подключения сертификата выдает "certificate routines:X509_check_private_key:key values mismatch", то, вероятно, ключ и сертификат не соответствуют друг-другу. Как же в этом убедиться и проверить  соответствие ключа сертификату? Просто. Для этого можно воспользоваться утилитой openssl, позволяющей нам просмотреть все подробности сертификатов и ключей. Выполняем следующие 2 команды:

 # openssl x509 -noout -modulus -in ./сертификат.crt | openssl md5   
 # openssl rsa -noout -modulus -in ./ключ.key | openssl md5  

Полученные значения должны быть идентичны.

Разберем некоторые ключи:
  • -modulus вывод модуля ключа
  • -noout - не выводить сам ключ
  • x509 - стандарт сертификата
  • rsa - стандарт кодирования ключа
  • -in использовать файл входных данных
8 мар. 2017 г.

OpenBSD новости: xdm сменен на xenodm, machdep.lidsuspend - на machdep.lidaction

С последнего обновления OpenBSD 6.0 на 6.1 current можно было заметить, что XDM внезапно перестал работать. Все оказалось довольно просто - https://www.openbsd.org/faq/current.html. XDM был заменен на XENODM, что выглядит вполне оправданно, учитывая использование в опенке Xenocara. С обновлением Xenodm автоматически устанавливается, все что нужно сделать это переключиться на него и удалить XDM. Делаем так:

 # rcctl disable xdm  
 # rcctl enable xenodm  

Теперь избавимся от остатков xdm

 # rm -rf /etc/X11/xdm  
 # rm /usr/X11R6/bin/xdm /usr/X11R6/man/man1/xdm.1 /etc/rc.d/xdm  

Все. Внешних признаков замены обнаружить не удалось, просто Тео хочется КРАСИВЫХ НАЗВАНИЙ.

Так же старый добрый machdep.lidsuspend, значения 0 и 1 которого, указанные в sysctl.conf устанавливали поведение системы при закрытии крышки ноутбука, был изменен на  machdep.lidaction. Изменение имени было связано со сменой названия этой переменной - теперь она не только устанавливается в значения 0 или 1, но и 2, которая отправляет систему в гибернацию, а не саспенд. Выглядит все так:

 machdep.lidaction=0   # ничего не делаем 
 machdep.lidaction=1   # сон
 machdep.lidaction=2   # гибернация

Старый вариант с lidsuspend  пока тоже работает, но в будущем будет удален полностью.
5 мар. 2017 г.

OpenBSD: Dokuwiki httpd config

Dokuwiki - крайне удобный инструмент для домашний википедии. Быстро устанавливается, легок в использовании и довольно функционален. Не говоря уже о том, что, в принципе, не требует баз данных.
Для настройки и установки Dokuwiki на OpenBSD 6 придется выполнить всего пару шагов.

 # pkg_add install dokuwiki  

Устанавливаем файлы dokuwiki. Да, мы делаем это с помощью пакетного менеджера, это просто и удобно. Файлы будут установлены сюда /var/www/dokuwiki/. Теперь дело за httpd сервером. Конфиг для нашей вики будет выглядеть так:

 server "wiki.local" {  
     listen on $ext_addr port 80  
     root "/dokuwiki/"  
     directory index index.php  
     location "*.php*" {  
         fastcgi socket "/run/php-fpm.sock"  
     }  
 }  

Почему "root /dokuwiki/" ? Все просто, в OpenBSD по-умолчанию httpd чрутится в /var/www/,а  потому пути в конфигах прописываются из корня в /var/www/. Сохраняем, рестартим httpd:

 # rcctl httpd restart  

В /etv/hosts не помешает указать, что wiki.local - это 127.0.0.1. После чего по адресу http://wiki.local/ вы попадете в установщик Dokuwiki.
1 мар. 2017 г.

debian 8 jessie mysql 5.7

"Искаропки" в Debian 8 идет mysql 5.5. Обновление mysql до 5.7/5.6 выполняется крайне быстро. Тут https://dev.mysql.com/downloads/repo/apt/ качаем актуальную версию mysql-apt-config, в моем случае mysql-apt-config_0.8.2-1_all.deb

 # wget https://dev.mysql.com/get/mysql-apt-config_0.8.2-1_all.deb  

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

 # dpkg -i mysql-apt-config_0.8.2-1_all.deb 

Обновляем списки пакетов и обновляем mysql-server

 # apt-get update  
 # apt-get upgrade mysql-server  

PS: не забываем про mysql_upgrade !
28 февр. 2017 г.

openbsd: автоматическое скачивание файлов snapshot'а

Openbsd я использую в виде снепшотов и обновляюсь, соответственно, от снепшота к снепшоту  без необходимости пересобирать систему из исходников, за меня уже все сделали. Файлы снепшота можно найти тут, к примеру, http://mirror.yandex.ru/openbsd/snapshots/amd64/.
В принципе, можно скачать только bsd.rd и, загрузившись с него, указать путь к файлами и они скачаются. Но как по мне, то проще их скачать заранее и устанавливать с диска.
Файлы я качаю вот этим скриптом

 #!/bin/sh  
 #files="INSTALL.amd64 SHA256 SHA256.sig base58.tgz bsd bsd.mp bsd.rd comp58.tgz man58.tgz xbase58.tgz xfont58.tgz xserv58.tgz xshare58.tgz";  
 ftp="ftp://mirror.yandex.ru/pub/OpenBSD/snapshots/amd64/";  #путь к файлам
 ftp $ftp/index.txt > /dev/null 2>&1  #получаем список файлов в директории
 index=`cat index.txt|awk '{print $10}'`  
 echo $index  
 echo "Preparing directory..."  
 for i in $index ; do  
     rm $i  
     echo "$i has been cleared..."  #удаляем старые файлы
 done  
 for i in $index ; do  
     echo "Downloading $i..."   #качаем новые
     ftp $ftp$i > /dev/null 2>&1  
 done  

Все. Далее можно копировать bsd.rd в корень и продолжать обновление.
24 февр. 2017 г.

Создать цепочку ssl сертификатов. bundle.crt от comodo

Многие после покупки сертификата у Comodo сталкиваются с тем, что не понятно, как все это добро установить, ведь получаем мы кучу файликов. На самом деле все довольно просто, как правило нам нужно в итоге получить сам файл сертификата .crt и цепочку bundle.crt(ca-bundle.crt). Как же получить цепочку ssl сертификатов comodo? Все просто. Ищем эти три файла:

 COMODORSADomainValidationSecureServerCA.crt  
 COMODORSAAddTrustCA.crt  
 AddTrustExternalCARoot.crt  

Именно в этой последовательности содержимое этих трех файлов мы собираем в один:

 # cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > site-bundle.crt  

Готово, теперь его можно подключать.
21 февр. 2017 г.

414 request-uri too large в apache

На одном из сайтов  на известном движке ocStore у знакомого был модуль (вроде как mega filter или что-то типа). И по непонятным причинам сохранение данных из полей происходило посредством GET запроса. Причем в форме были поля textarea. В итоге при отправке текста в 2-3к символов мы натыкаемся 414 request-uri too large ошибку, которая говорит нам, что ваш uri слишком большой. Что ж, передаем привет разработчикам модуля и правим конфиг апача /etc/httpd/conf/httpd.conf (для Centos/RHEL) или /etc/apache2/apache2.conf (Debian/Ubuntu):

 LimitRequestLine 512000  

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

Warning

When name-based virtual hosting is used, the value for this directive is taken from the default (first-listed) virtual host for the NameVirtualHost the connection was mapped to.
А потому в случае с NameVirtualHost будьте осторожнее, чтобы разместить директиву в нужное место.

16 февр. 2017 г.

ispmanager5 установка модулей к дополнительным версиям php

В панели ISPManager5 можно орудовать сразу несколькими версия PHP - основная(системная) и дополнительные. Если ваш сайт использует доп. версию PHP (скажем, 5.4), а системная у вас 5.6, то при необходимости установить модуль к PHP5.4 обычным пакетным менеджером не обойтись. К счастью доп. версии php в ISPManager5 уже снабжены необходимыми утилитами для сборки (phpize, php-config).
Итак, переходим в папку нужной версии php /opt/php54

 # cd /opt/php54/  

качаем необходимый модуль(тут, к примеру, https://pecl.php.net/package/memcache). Распаковываем:

 # tar -xvf memcache-3.0.8.tgz  
 # cd memcache-3.0.8  

Далее

 # /opt/php54/bin/phpize  

После успешного завершения предыдущей команды выполняем

 # ./configure --with-php-config=/opt/php54/bin/php-config  

Теперь можно и установить:

 # make && make install  

.ini конфиг модуля должен находиться тут /opt/php54/etc/МОДУЛЬ.ini, сам модуль тут /opt/php54/lib/php/modules/. 

Не забываем удалить архив и папку с исходниками модуля.
15 февр. 2017 г.

Ispmanager 5 restart панели

Ispmanager4 можно было рестартнуть простым killall:
 # killall -9 ispmgr  

Панель ISPmanager5 в принципе тоже:
 # killall -9 core  

Или же более нативным способом:
 # /usr/local/mgr5/sbin/mgrctl -m ispmgr exit  

14 февр. 2017 г.

Roundcube: Connection to Storage server failed - namespace configuration error: inbox=yes namespace missing

После обновления dovecot  до 2.2.10 Roundcube при логине начал выбивать ошибку "Connection to Storage server failed ". Смотрим в логи dovecot'а, видим следующее:

 Feb 08 18:55:23 imap(info@site.com): Error: user info@site.com: Initialization failed: namespace configuration error: inbox=yes namespace missing  

Судя по всему что-то изменилось в конфиге. Просто выполняем то, о чем говорил данный лог, идем в /etc/dovecot/conf.d/15-mailboxes.conf и находим следующий кусок кода "namespace inbox {", добавляем  "inbox = yes", приводя к виду:

 namespace inbox {  
    inbox = yes  
    .....  

Пробуем логиниться в roundcube
9 февр. 2017 г.

Vesta roundcube PHP Fatal error: Call to undefined function: MDB2_Driver_mysql

После обновления панели Vesta на Debian слетел Roundcubemail, белый экран 500 error  с ошибкой в логах

 [Thu Feb 09 10:35:25 2017] [error] [client XXX] PHP Fatal error: Call to undefined function: MDB2_Driver_mysql::pushErrorHandling(). in /usr/share/php/MDB2.php on line 1950  


Ошибка обусловлена нехваткой драйверов(хотя пакетный менеджер сообщит, что MDB2_Driver_Mysql установлен). Нужно установить недостающие драйвера с помощью pear. Выполняем последовательно:
 # apt-get install php-mdb2-driver-mysql (этот драйвер у вас уже установлен, скорее всего)  
 # apt-get install php-pear  
 # pear install MDB2  
 # pear install MDB2_Driver_Mysql  

После чего Roundcubemail должен работать успешно