Web

= точное совпадение ^~ - не пробовать другие регекспы после совпадения, более строгие локейшены, чем простые * - регистро зависимый регексп ~* - регистро независимый регексп

Если вы столкнулись с ошибкой, подобной той, что написана в заголовке, это может означать, что ваше приложение может не работать при попытке использовать расширение memcache из-за неправильной или отсутствующей сборки расширения. “php: symbol lookup error: /usr/local/lib/php/extensions/no-debug-non-zts-20131226/memcache.so: undefined symbol: mmc_queue_pop” Чтобы исправить эту проблему, вам нужно передать опцию «fgnu89-inline» компилятору с переменной среды CFLAGS при установке пакета через pecl. Эта опция указывает компилятору C использовать традиционную семантику GNU для встроенных функций. Если модуль memcache был установлен из пакетов, нужно его удалить. 1 $ pecl uninstall memcache После установим заново, но немного иначе 1 $ yes|CFLAGS="-fgnu89-inline" pecl install memcache-3.0.8 Готово! Аналогичное решение можно применить при ручной сборке модуля. Нужно добавить -fgnu89-inline в переменную CFLAGS=. Чем я и занимался. Статья частично переведена google translate, особо времени доволить до ума небыло.

Очень краткая заметка с примером как можно ограничить скорость обработки запросов от IP адресов, но исключив при этом роботов с определённым “юзер агентом”. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 # ref: https://gist.github.com/supairish/2951524 # IP адреса в белом списке - для них не будет применяться лимитирование geo $geo_whitelist { default 0; 1.2.3.4 1; 2.3.4.5/24 1; } # Юзер агенты в белом списке - для них не будет применяться лимитирование map $http_user_agent $whitelist { default $geo_whitelist; ~*(google) 1; } # Если в белом списке 0, то помещаем "binary IP address" в $limit для применения к ним ограничений map $whitelist $limit { 0 $binary_remote_addr; 1 ""; } limit_req_zone $limit zone=perip:30m rate=1r/s;​

В этой статье опишу небольшую инструкцию для установки сертификата с помощью acme.sh на базе алгоритма ECDSA P-384, этот алгоритм имеет высокий уровень быстродействия и защищенности. Например 256 битный ECDSA соответствует 3072 битному RSA по степени защиты, но при этом скорость работы в несколько раз выше. Установка acme.sh 1 curl https://get.acme.sh | sh Получение сертификата Метод 1 : использование одной и той же директории для всех acme challenge запросов Первоначально нам необходимо создать файл acme.conf в директории /etc/nginx/common/ со следующим содержанием: 1 location /.well-known/acme-challenge/ { alias /var/www/html/.well-known/acme-challenge/; } После этого установим пользователя www-data (или вашего) владельцем директории /var/www/html : 1 chown -R www-data:www-data /var/www/html Последним шагом нам нужно включить acme.conf в вашу конфигурацию виртуального хоста nginx, добавлением следующей строки : 1 include common/acme.conf; Перечитываем конфигурацию nginx командой service nginx reload и уже сейчас вы можете получить свой первый сертификат с помощью acme.sh: ECDSA Certificates (384 Bits) 1 acme.sh --issue -d yourdomain.tld -d www.yourdomain.tld -d blog.yourdomain.tld --keylength ec-384 -w /var/www/html Метод 2 : используем Cloudflare DNS API Настраиваем ваши API ключи 1 2 export CF_Key="sdfsdfsdfljlbjkljlkjsdfoiwje" export CF_Email="[email protected]" ECDSA Certificates (384 Bits) 1 acme.sh --issue -d yourdomain.tld -d www.yourdomain.tld -d blog.yourdomain.tld --keylength ec-384 --dns dns_cf Устанавливаем SSL сертификат в Nginx НЕ ИСПОЛЬЗУЙТЕ сертификаты в директории ~/.acme.sh/, они только для служебного использования, структура директории может измениться в будущем. Создайте директорию для хранения ваших сертификатов в продакшене. ...

Во время отладки иногда необходимо сначала выявить проблему и понять это проблема из-за PHP или Nginx делает что-то не правильно. В этом случае может пригодиться cgi-fcgi. Установка cgi-fcgi на Ubuntu Достаточно запустить команду: 1 apt-get install libfcgi0ldbl Подключение к PHP-FPM на прямую Предполагаем что вы запустили PHP-FPM используя TCP/IP с IP и PORT значениями 127.0.0.1 и 9000 соответственно. Ниже приведены некоторые примеры кода, которые вы можете использовать. Тест ответа PHP-FPM Ping Вы можете запустить следующий код из командной строки что бы протестировать ответ FPM: 1 2 3 4 SCRIPT_NAME=/ping \ SCRIPT_FILENAME=/ping \ REQUEST_METHOD=GET \ cgi-fcgi -bind -connect 127.0.0.1:9000 Должен быть возвращён подобный ответ: 1 2 3 4 Content-Type: text/plain Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, max-age=0 pong Тест ответа PHP-FPM Status Вы можете запустить следующий код из командной строки что бы протестировать ответ FPM 1 2 3 4 SCRIPT_NAME=/status \ SCRIPT_FILENAME=/status \ REQUEST_METHOD=GET \ cgi-fcgi -bind -connect 127.0.0.1:9000 Должен быть возвращён подобный ответ: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Content-Type: text/plain pool: www process manager: dynamic start time: 08/Jan/2014:15:04:57 +0530 start since: 93492 accepted conn: 1215 listen queue: 0 max listen queue: 1 listen queue len: 0 idle processes: 26 active processes: 4 total processes: 30 max active processes: 34 max children reached: 0 slow requests: 150 Тест ответа PHP-FPM Full Status Если вы хотите протестировать ответ PHP-FPM Full Status, вы можете использовать команды: ...

Сложность в том, что некоторым скриптам необходимо знать через какую схему они работают, http, или https. Таким образом они формируют ссылки, а иногда принудительно перенаправляют клиентов куда нужно. Из-за не верной настройки серверного ПО переадресация не может завершиться и браузер покажет нам ошибку ‘too many redirects’. В статье рассмотрим две схемы: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) nginx (front1, server2) -> nginx (front2, server1) -> apache (back, server1) Первой рассмотрим схему с php-fpm: nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1) На сервере nginx (front1, server2) у нас обязательно должны быть строки 1 2 3 4 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded_For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; среди которых нам важна последняя. На сервере nginx (front2, server1) в секцию http добавляем 1 2 3 4 5 6 7 8 http { ... map $http_x_forwarded_proto $fastcgi_https { default off; https on; } ... } Если его добавить в любое другое место - получите следующую ошибку при перезапуске nginx: 1 nginx: [emerg] "map" directive is not allowed here Если прописать просто $https вместо $fastcgi_https - получите следующую ошибку: 1 nginx: [emerg] the duplicate "https" variable in /etc/nginx/nginx.conf Дело в том, что начиная с какой-то бородатой версии NginX имеет встроенную переменную $https, поэтому ее повторно использовать не получится. ...

Давно искал что-то подобное. Конфигурация nginx позволяет перенаправлять посетителей сайта на мобильную версию по UserAgent‘у. И казалось бы… это совсем не сложно, но у нас есть ещё и плюшки. Плюшки в том что мы можем добавить в адресную строку параметр для переключения на полную версию, или обратно на мобильную. Всё это записывается в cookies и сохраняется на заданное нами время. т.е. людей не будет напрягать то, что их при каждом входе принудительно перенаправляет на мобильную версию, а они то хотят полную. Таким образом принудительное переключение с полной версии на мобильную происходит добавлением example.com?mobile=yes, а переключение с мобильной на полную добавлением example.com?mobile=no 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 #with regex from http://detectmobilebrowsers.com/ #map suggestion via kolbyjack #not tested map $http_user_agent $mobile_agent{ default 0; ~* "android.+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino" 1; ~* "^(1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(di|rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-)" 1; } #set $mobile_rewrite variable set $mobile_rewrite do_not_perform; if($mobile_agent = 1){ set $mobile_rewrite perform; } #check if query arg = yes (example.com?mobile=yes), set variable if ($arg_mobile = 'yes') { add_header Set-Cookie mobile=yes; set $mobile_rewrite perform; } #check if cookie mobile=yes, set variable if ($cookie_mobile = 'yes') { set $mobile_rewrite perform; } #check if cookie mobile=no, break if ($cookie_mobile = 'no') { set $mobile_rewrite do_not_perform; } #check if query arg = no (example.com?mobile=no), break if ($arg_mobile = 'no') { add_header Set-Cookie mobile=no; } #if $mobile_rewrite = perform, do the redirect if ($mobile_rewrite = perform) { return 301 $scheme://mobile.domain.com$request_uri; } Ниже должна быть ссылка на оригинальный скрипт, но она потерялась в процессе очередного переезда :(

Пару лет назад думал что настроил на вэб сервере поддержку ipv6, все онлайн тесты проходили на ура. Но сейчас, настроив у себя ipv6, понял что при обращении к сайтам получаю в ответ “403 Forbidden”. Не приятно конечно, но надо что-то делать. Тогда, при настройке, была информация что нужно добавлять в конфиг сервера запись вида 1 listen [::]:80 ipv6only=on; при чём если её добавлять в несколько виртуальных серверов, то nginx выкидывал ошибку. Пришёл к выводу что достаточно одной директивы в конфиге по умолчанию. Ошибался. В общем смысл таков: В конфиге по умолчанию должно быть прописано 1 2 listen 80 default_server; listen [::]:80 default_server ipv6only=on; а в конфигах каждого виртуального хоста прописываем 1 2 listen 80; listen [::]:80; Таким образом все сайты работают с ipv4 и ipv6. Если поддержка ipv6 для сайта не нужна, то строку 1 listen [::]:80; прописывать не нужно! А ошибку “403 Forbidden” получал из-за того, что у меня хост по умолчанию её отдаёт для всех желающих ломиться по IP, или подбирать поддомены.

Заметка об использовании переменных в домене на web сервере nginx, или динамические поддомены. Важно не забыть выше расположить статические поддомены, чтоб динамические их не перебивали. Ну и примеры ниже: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 server { server_name www.example.com; location / { proxy_pass 127.0.0.1:80; } } server { server_name ~^(?<dynamic>[a-z0-9\-]+)\.example.com$; location / { proxy_pass 127.0.0.1:80/sites/$dynamic$uri$is_args$args; } } Вот ещё вариант: Если у вас много поддоменов или вы хотите создавать их автоматически, тогда имеет смысл создать одну универсальную конфигурацию, которая будет обслуживать все поддомены, направляя запросы посетителей в соответствующие каталоги. В первую очередь, необходимо настроить DNS: добавить поддомен с именем * (звездочка, без кавычек) и направить его на IP вашего веб-сервера. Измените секцию server вашего сайта следующим образом: 1 2 3 4 5 6 7 8 9 10 11 12 server { listen 80; server_name example.com *.example.com; root /var/www/example.com/$subdomain; set $subdomain ""; if ($host ~* ^([a-z0-9-\.]+)\.example.com$) { set $subdomain $1; } if ($host ~* ^www.example.com$) { set $subdomain ""; } } Не забудьте поменять example.com на имя вашего домена. Эта конфигурация работает следующим образом: ...

Http-соединения могут быть переадресованы на https с помощью модуля apache mod_rewrite, который должен быть доступен в любой версии apache. Создайте файл с именем .htaccess в корневом каталоге сайта, который содержит следующие строки: 1 2 3 RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} Если Вы используете ISPConfig 2 или 3, Вы можете также добавить эти строки в поле директив apache в настройках сайта, вместо их добавления в файл a .htaccess. Но метод с использованием файла .htaccess будет также работать и на ISPCONFIG. Источник Комтет