Архів мітки: nginx

Обмеження швидкості завантаження (upload) у Nginx для тестування

У веб-сервера Nginx є гарна вбудована опція для обмеження швидкості скачування – limit_rate. Але вона впливає лише на швидкість download і ніяк не може обмежити upload.

А в тестових цілях мені потрібно було зробити завантаження повільним, таким як на dial-up каналі. Пошук в інтернеті мене вивів на http://wiki.nginx.org/HttpUploadModule, я навіть зміг його додати до Nginx після встановлення пакунку libssl-dev:

# apt-get install libssl-dev

Цей модуль ніяк не хотів компілюватися без файлів md5.h та sha.h.

Та на жаль, я так і не зміг примусити директиву upload_limit_rate працювати.

Час спливав, і я змушений був шукати альтернативний спосіб зменшення швидкості завантаження файлів на тестовий сервер. Ним виявився пакунок trickle:

# apt-get install trickle

Це така консольна програма, що дозволяє обмежувати швидкість як завантаження так і скачування для програм, які запущені через неї.

Замість обмеження швидкості для Nginx – я обмежив її для браузера, в якому виконую тестування:

$ trickle -u 5 google-chrome

І хром завантажує лише 5 кілобайт на секунду.

 

Лапки у rewrite правилах Nginx

Якщо пишете правило rewrite для веб-сервера Nginx в якому використовуєте регулярні вирази (regexp) – завжди беріть його у лапки!

Тоді вам не побачити помилку при старті (рестарті) цього серверу:

nginx: [emerg] directive "rewrite" is not terminated by ";" in ...

Правило мало досить безневинний вигляд:

rewrite ^/([A-Za-z0-9]{6})$ /dyn/gallery.js?link=$1 last;

А треба було писати так:

rewrite "^/([A-Za-z0-9]{6})$" /dyn/gallery.js?link=$1 last;

Nginx+Tomcat7 та обмеження на розмір WAR-файлу у manager

В розробці та тестуванні програмних продуктів, що використовують Tomcat, досить зручно користуватися Web Application Manager (/manager/).

Я використовую зв’язку Nginx+Tomcat, щоб працювати з 80-м портом. Та Nginx пропускає великі WAR-файли лише за наявності такої опції:

http {
    ...
    client_max_body_size 100m;
}

Тепер файли до 100 Мб буде передано Томкату. Проте виявилось у менеджера Tomcat є власне обмеження в 50 Мб:

org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException:
 the request was rejected because its size (67082177) exceeds
 the configured maximum (52428800)

Виправити його можна у файлі TOMCAT_DIR/webapps/manager/WEB-INF/web.xml. Для 100 Мб я вписав таке:

<multipart-config>
  <!-- 100MB max -->
  <max-file-size>104857600</max-file-size>
  <max-request-size>104857600</max-request-size>
  <file-size-threshold>0</file-size-threshold>
</multipart-config>

Порядок псевдонімів server_name у конфігу Nginx

Веб-сервер Nginx дозволяє доволі гнучко керувати псевдонімами вашого сайту. Можна використовувати декілька директив server_name:

server_name example.com www.example.com alias.com;
server_name www.alias.com;

Мені подобається схема у 2 імені, коли перше іде без www, а друге з www:

server_name example.com www.example.com;
server_name alias.com www.alias.com;

Але перше ім’я домену має найвищій пріоритет і саме воно буде використане за умовчанням при обробці правил rewrite з опціями redirect та permanent.

Простий приклад. Маємо правило:

rewrite ^/user/(.*) /newlook/$1 permanent;

За таким правилом користувача завжди буде перенаправлено до домену example.com:

example.com/user/index.php -> example.com/newlook/index.php
www.example.com/user/index.php -> example.com/newlook/index.php
alias.com/user/index.php -> example.com/newlook/index.php
www.alias.com/user/index.php -> example.com/newlook/index.php

Сторінка maintenance за допомогою Nginx

При оновленні програмного забезпечення на бекенді (back-end) бажано показувати користувачеві пояснювальну інформацію. Наприклад, сторінку на якій написано, що зараз проводяться технічні роботи і сайт буде доступний за мить.

Якщо фронтенд (front-end) у вас Nginx, то це можна зробити за допомогою директиви try_files. Для цього, на час проведення технічних робіт, слід підмінити конфігурацію сайту наступним змістом:

server {
  listen   80;
  server_name ДОМЕНИ;
  location / {
    root /var/www/maintenance;
    try_files $uri /maintenance.html;
  }
}

В порожній директорії /var/www/maintenance повинен бути лише один файл maintenance.html. Саме його і побачить користувач.

Перевагою цього методу є те, що у браузері залишиться поточний URL. Тобто не буде заміни на http://ДОМЕН/maintenance.html

Створення власного SSL сертифікату та застосування його у Nginx

Стисло опишу, як згенерувати SSL сертифікат у Debian.

Встановлюємо пакет ssl-cert:

apt-get install ssl-cert

Створюємо сертифікат для потрібного домену:

make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/ДОМЕН

Ця консольна утиліта запитає назву домену. Ви повинні ввести домен, для якого створюється сертифікат.

Сертифікат матиме вміст:

-----BEGIN RSA PRIVATE KEY-----
 це приватний ключ
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
 це публічний сертифікат
-----END CERTIFICATE-----

Приватний ключ зберігаємо у каталозі /etc/ssl/private. Краще дати йому розширення *.key:

$ cat /etc/ssl/private/ДОМЕН.key
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

Публічну частину – у каталозі /etc/ssl/certs, з розширенням *.pem:

$ cat /etc/ssl/certs/ДОМЕН.pem
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Оригінальній файл можна видалити. Чомусь в мене файл сертифікату був створений зі символічним посиланням на нього. Це посилання – теж видаляємо.

Підключаємо сертифікат до Nginx:

server {

 listen   443;
 server_name ДОМЕН;

 ssl  on;
 ssl_certificate        /etc/ssl/certs/ДОМЕН.pem;
 ssl_certificate_key    /etc/ssl/private/ДОМЕН.key;

 ssl_session_timeout  5m;

 ssl_protocols  SSLv3 TLSv1;
 ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
 ssl_prefer_server_ciphers   on;

 ...
}

Шифрований (https) доступ до wiki (http) за допомогою Nginx

До wiki сайту треба створити зашифрований SSL доступ. Wiki працює всередині віртуальної машини і не має можливості дати йому реального IP. Тому шифрування доступу будемо здійснювати засобами Nginx.

Схема буде такою:

Nginx (https) -> proxy_pass -> Apache (http) with Wiki

Генерація штучного SSL сертифікату доволі тривіальна задача, не будемо зупинятися на цьому.

Налагодження Nginx складається з 3-х частин:

  • переведення всього HTTP трафіку у HTTPs
  • проксування HTTPs з Nginx на Apache з wiki
  • зміна $wgServer у параметрах wiki

1. Перетворюємо HTTP запити у дзеркальні HTTPs

server {
    listen   80;
    server_name ДОМЕН;
    rewrite ^ https://$server_name$request_uri? permanent;
}

2. Проксуємо трафік до wiki

server {
    listen   443;
    server_name ДОМЕН;
    ssl  on;
    ...
    location / {
        proxy_pass       http://ЛОКАЛЬНА_АДРЕСА_WIKI:80;
        proxy_set_header Host      $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_redirect   off;
    }
}

3. Міняємо http на https у змінній $wgServer

Після перших 2-х кроків ми практично зробили шифроване з’єднання, але деякі посилання всередині wiki сторінок містять http протокол.

Треба відредагувати файл LocalSettings.php і замінити:

$wgServer = "http://ДОМЕН";

на

$wgServer = "https://ДОМЕН";