sysmerge IT

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  

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