Nginx- Невеликий за розмірами, дуже швидкий, досить функціональний веб-сервер і поштовий проксі-сервер, розробник Ігор Сисоєв (rambler.ru). Через дуже невеликого споживання ресурсів системи та швидкості роботи, а також гнучкості конфігурування, інтернет сервер Nginxчасто використовується як фронтенд до більш важких серверів, такими як Apache, у проектах із високим навантаженням. Класичним варіантом є зв'язування, Nginx - Apache - FastCGI. Працюючи у такій схемі, сервер Nginx, приймає всі запити, що надходять по HTTP, і в залежності від конфігурації і самого запиту, вирішує, чи обробити запит самому і віддати клієнту готову відповідь або відправити запит на обробку, одному з бакендів ( Apacheабо FastCGI).

Як відомо, сервер Apache, кожен запит обробляє в окремому процесі (потоку), які треба сказати, віджирають досить велику кількість системних ресурсів, якщо таких процесів 10-20, нісенітниця, а якщо їх 100-500 і більше, системі стає не весело.

Спробуємо уявити таку ситуацію. Припустимо, на Apacheприходить 300 HTTP запитів від клієнтів, 150 клієнтів сидять на швидких виділених лініях, а інші 150, на порівняно повільних інтернет-каналах, нехай навіть не на модемах. Що відбувається у цій ситуації? А відбувається наступне, веб сервер Apache, щоб обробити ці 300 з'єднань, створює на кожне по процесу (потоку), контент він згенерує швидко, і 150 швидких клієнтів тут же заберуть результат своїх запитів, процеси їх обслуговуючі будуть убиті а ресурси вивільнені , а 150 повільних, і забирати результати своїх запитів будуть повільно, через неширокий інтернет канал, внаслідок чого в системі висітиме 150 процесів Apache, що чекають, коли клієнти заберуть згенерований веб сервером контент, пожираючи масу системних ресурсів. Звичайно ситуація гіпотетична, але суть думаю зрозуміла. Виправити вищеописану ситуацію і допомагає зв'язування. Прочитавши весь запит від клієнта, він передає його на обробку Apache, який у свою чергу генерує контент і максимально швидко повертає готову відповідь у Nginx, після чого може зі спокійною совістю прибити процес і звільнити системні ресурси, які він займає. веб сервер Nginx, отримавши результат запиту від Apache, записує його в буфер або взагалі в файл на диску і може скільки завгодно довго віддавати його повільним клієнтам, при цьому його робочі процеси їдять так мало ресурсів, що .. "про це навіть смішно говорити" ©. :) Така схема, суттєво економить системні ресурси, повторюся, але робочі процеси Nginx споживають мізерну кількість ресурсів, це тим більш актуально для великих проектів.

І це лише мала частина того, що вміє сервер Nginx, не варто забувати про можливості кешування даних та роботу з memcached. Наведу список основних функціональних можливостей веб-сервера Nginx.

Функціонал сервера Nginx як HTTP сервер

• обробка статичного контенту, індексні файли, лістинг директорій, кеш дескрипторів відкритих файлів;
• Акселероване проксування з кешування, розподіл навантаження та відмовостійкістю;
• Акселерована підтримка FastCGIсерверів з кешуванням, розподілом навантаження та відмовостійкістю;
• Модульна структура, підтримка різних фільтрів (SSI, XSLT, GZIP, докачування, chunked відповіді);
• Підтримка SSL та розширення TLS SNI;
• Ip-basedабо Name-basedвіртуальні сервери;
• Робота з KeepAlive та pipelined з'єднаннями;
• Можливість конфігурування будь-яких таймаутів і кількості і розмірів буферів, на рівні сервера Apache;
• Виконання різноманітних дій залежно від адреси клієнта;
• Зміна URI за допомогою регулярних виразів;
• Спеціальні сторінки помилок для 4хх та 5хх;
• Обмеження доступу на основі адреси клієнта або паролем;
• Налаштування форматів лог-файлів; ротація логів;
• Обмеження швидкості відповіді клієнту;
• Обмеження кількості одночасних підключень та запитів;
• Підтримка методів PUT, DELETE, MKCOL, COPY та MOVE;
• Зміна налаштувань та оновлення сервера без зупинки роботи;
• Вбудований Perl;

Функціонал сервера Nginx, як поштовий проксі-сервер

• Форвардинг на IMAP/POP3 бакенд, використовуючи зовнішній HTTP сервер аутентифікації;
• Перевірка SMTP користувача на зовнішньому HTTP сервері аутентифікації та форвардинг на внутрішній SMTP сервер;
• Підтримка наступних способів автентифікації:
  • POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI/PLAIN/CRAM-MD5;
• Підтримка SSL;
• підтримка STARTTLS та STLS;

Операційні системи та платформи, що підтримуються веб-сервером Nginx

• FreeBSD, з 3 по 8 - платформи, i386 та amd64;
• Linux, з 2.2 до 2.6 - платформа i386; Linux 2.6 – amd64;
• Solaris 9 - платформи i386 та sun4u; Solaris 10 - платформи i386, amd64 та sun4v;
• MacOS X платформи ppc, i386;
• Windows XP, Windows Server 2003; (на даний момент у стадії бета-тестування)

Архітектура та масштабованість сервера Nginx

• Основний (master) процес, кілька (налаштовується у файлі конфігурації) робочих процесів, які працюють під непривілейованим користувачем;
• Підтримка наступних методів обробки з'єднань:
  • select- Стандартний метод. Відповідний модуль Nginx збирається автоматично, якщо на даній платформі не знайдено ефективнішого методу. Можна примусово ввімкнути або вимкнути збирання цього модуля за допомогою параметрів конфігурації --with-select_module або --without-select_module.
  • poll- Стандартний метод. Відповідний модуль Nginx збирається автоматично, якщо на даній платформі не знайдено ефективнішого методу. Можна примусово ввімкнути або вимкнути збирання цього модуля за допомогою параметрів конфігурації --with-poll_module або --without-poll_module.
  • kqueue- ефективний метод, який використовується в операційних системах FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 та MacOS X. При використанні на двопроцесорних машинах з MacOS X може викликати kernel panic.
  • epoll- ефективний метод, який використовується в Linux 2.6+. У деяких дистрибутивах, наприклад, SuSE 8.2, є патчі для підтримки epoll ядром 2.4.
  • rtsig - real time signals, ефективний метод, який використовується в Linux 2.2.19+. За замовчуванням у черзі для всієї системи, не може бути більше 1024 сигналів. Це мало для серверів з високим навантаженням, розмір черги потрібно збільшити за допомогою параметра ядра /proc/sys/kernel/rtsig-max. Однак, починаючи з Linux 2.6.6-mm2, цей параметр відсутній, натомість у кожного процесу існує окрема черга сигналів, розмір якої визначається за допомогою RLIMIT_SIGPENDING.
  • При переповненні черги, сервер nginxскидає її та обробляє з'єднання за допомогою методу poll доти, доки ситуація не прийде в норму.
  • /dev/poll- ефективний метод, що підтримується в операційних системах Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ та Tru64 UNIX 5.1A+.
  • eventport - event ports, ефективний метод, що використовується в Solaris 10. Перед використанням необхідно встановити патч, щоб уникнути kernel panic.
• Використання можливостей методу kqueue, таких як EV_CLEAR, EV_DISABLE (для тимчасового вимкнення події), NOTE_LOWAT, EV_EOF, кількість доступних даних, коди помилок;
• Робота з sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) та sendfilev (Solaris 8 7/01+);
• Підтримка accept-фільтрів (FreeBSD 4.1+) та TCP_DEFER_ACCEPT (Linux 2.4+);
• На 10000 неактивних HTTP keep-alive з'єднань витрачається приблизно 2.5M пам'яті;
• Мінімальна кількість операцій копіювання даних;

NGINX можна використовувати не тільки як веб-сервер або http-proxy, але й для прокшування пошти за протоколами SMTP, IMAP, POP3. Це дозволить налаштувати:

• Єдину точку входу для масштабованої поштової системи.
• Балансування навантаження між усіма поштовими серверами.

У цій статті встановлення виконується на операційній системі Linux. Як поштовий сервіс, на який передаються запити можна використовувати postfix, exim, dovecot, exchange, складання iredmail та інше.

Принцип роботи

NGINX приймає запити та виконує аутентифікацію на веб-сервері. Залежно від результату перевірки логіну та паролю, проксі поверне відповідь з кількома заголовками.

У разі успіху:

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

У разі невдачі:

Залежно від результату аутентифікації та заголовком, клієнт перенаправляється на потрібний поштовий сервер.

Підготовка сервера

Внесемо деякі редагування в налаштування безпеки сервера.

SELinux

Відключаємо SELinux, якщо використовуємо CentOS або якщо використовуємо цю систему безпеки на Ubuntu:

vi /etc/selinux/config

SELINUX=disabled

Брандмауер

Якщо використовуємо firewalld(за замовчуванням у CentOS):

firewall-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

firewall-cmd --reload

Якщо використовуємо iptables(за замовчуванням в Ubuntu):

iptables -A INPUT -p tcp --dport 25-j ACCEPT

iptables -A INPUT -p tcp --dport 110 -j ACCEPT

iptables -A INPUT -p tcp --dport 143 -j ACCEPT

apt-get install iptables-persistent

iptables-save > /etc/iptables/rules.v4

* у цьому прикладі ми дозволили SMTP (25), POP3 (110), IMAP (143).

Установка NGINX

Залежно від операційної системи, встановлення NGINX трохи відрізняється.

або Linux Centos:

yum install nginx

або Linux Ubuntu:

apt install nginx

Дозволяємо автозапуск сервісу та запускаємо його:

systemctl enable nginx

systemctl start nginx

Якщо в системі вже встановлено NGINX, перевіряємо з якими модулями він працює:

Ми отримаємо список опцій, з якими зібраний веб-сервер - серед них ми маємо побачити --with-mail. Якщо потрібного модуля немає, потрібно оновити nginx

Налаштування NGINX

Відкриваємо конфігураційний файл nginx та додаємо опцію mail:

vi /etc/nginx/nginx.conf

mail (

auth_http localhost:80/auth.php;

Server (
listen 25;
protocol smtp;
smtp_auth login plain cram-md5;
}

Server (
listen 110;
protocol pop3;

}

Server (
listen 143;
protocol imap;
}
}

* де:

• server_name— Ім'я поштового сервера, яке відображатиметься під час привітання SMTP.
• auth_http— веб-сервер та URL-адреса для запиту автентифікації.
• proxy_pass_error_message— дозволяє або забороняє відображення повідомлення під час невдалої автентифікації.
• listen— порт, у якому прослуховуються запити.
• protocol— протокол програми, для якої прослуховується порт.
• smtp_auth— Доступні методи автентифікації для SMTP.
• pop3_auth— Доступні методи автентифікації POP3.

У секції http-server дописуємо:

Server (
listen 80 default_server;
listen [::]:80 default_server;
...

Location ~ \.php$ (
set $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1: 9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Перезапускаємо сервер nginx:

systemctl restart nginx

Встановлення та налаштування PHP

Для виконання аутентифікації за допомогою PHP необхідно встановити в систему наступні пакети.

Якщо CentOS:

yum install php php-fpm

Якщо Ubuntu:

apt-get install php php-fpm

Запускаємо PHP-FPM:

systemctl enable php-fpm

systemctl start php-fpm

Аутентифікація

Перевірка логіну та пароля виконується скриптом, шлях до якого задається опцією auth_http. У нашому прикладі це скрипт на PHP.

Приклад офіційної заготовки для скрипту перевірки логіну та паролю:

vi /usr/share/nginx/html/auth.php

* даний скрипт приймає будь-які логін та пароль і перенаправляє запити на сервери 192.168.1.22 і 192.168.1.33 . Щоб задати алгоритм аутентифікації, редагуємо рядки 61 - 64. За повернення серверів, на які йде перенаправлення, відповідають рядки 73 - 77 - в даному прикладі якщо логін починається на символи "a", "c", "f", "g",то перенаправлення буде на сервер mailhost01, інакше, на mailhost02. Зіставлення імен серверів з IP-адресами можна задати на рядках 31, 32, інакше звернення буде йти по доменного імені.

Налаштування поштового сервера

Обмін даними між проксі NGINX і поштовим сервером йдуть у відкритому вигляді. Необхідно додати у виключення можливість аутентифікації за механізмом PLAIN. Наприклад, для налаштування dovecot, робимо таке:

vi /etc/dovecot/conf.d/10-auth.conf

Додаємо рядки:

remote 192.168.1.11 (
disable_plaintext_auth = no
}

* у цьому прикладі ми дозволили PLAIN-запити на автентифікацію з сервера 192.168.1.11 .

Також перевіряємо:

* якщо sslматиме значення required, перевірка нічого очікувати працювати, оскільки вийде, що з одного боку сервер дозволяє запити у відкритому вигляді, але вимагає шифрування ssl.

Перезапускаємо Dovecot сервіс:

systemctl restart dovecot

Налаштування клієнта

Можна перейти до перевірки налаштування нашого проксі. Для цього в налаштуваннях клієнта як IMAP/POP2/SMTP вказуємо адресу або ім'я сервера nginx, наприклад:

* у цьому прикладі поштовий клієнт налаштовується для підключення до сервера 192.168.1.11 по відкритих портах 143 (IMAP) та 25 (SMTP).

Шифрування

Тепер налаштуємо SSL-підключення. Nginx має бути зібраний з модулем mail_ssl_module- Перевіряємо командою:

За відсутності необхідного модуля перебираємо nginx.

Після цього редагуємо наш конфігураційний файл:

vi /etc/nginx/nginx.conf

mail (
server_name mail.domain.local;
auth_http localhost/auth.php;

Proxy_pass_error_message on;

Ssl on;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Server (
listen 110;
protocol pop3;
pop3_auth plain apop cram-md5;
}

Server (
listen 143;
protocol imap;
}

Причина спрацьовує система безпеки SELinux.

Рішення: вимкнути або настроїти SELinux.

Nginx швидкими темпами набирає популярності, перетворюючись з просто прискорювача віддачі статики для Apache на повнофункціональний і розвинений веб-сервер, який все частіше застосовується окремо. У цій статті ми поговоримо про цікаві та нестандартні сценарії використання nginx, які дозволять вичавити з веб-сервера максимум.

Поштовий проксі

Почнемо з самого очевидного - зі здатності nginx виступати у ролі поштового проксі. Ця функція є в nginx спочатку, а ось використовується в продакшні вона чомусь вкрай рідко, деякі так і взагалі не здогадуються про її існування. Як би там не було, nginx підтримує проксіювання протоколів POP3, IMAP та SMTP з різними методами автентифікації, включаючи SSL та StartTLS, причому робить це дуже швидко.

Навіщо це потрібно? Є як мінімум два застосування цієї функціональності. Перша: використовувати nginx як щит від настирливих спамерів, які намагаються надіслати сміттєві листи через наш SMTP-сервер. Зазвичай спамери не створюють багато проблем, оскільки швидко відбиваються на етапі автентифікації, однак, коли їх стає дійсно багато, nginx допоможе заощадити процесорні ресурси. Друга: використовувати nginx для перенаправлення користувачів на кілька поштових серверів POP3/IMAP. З цим, звичайно, міг би впоратися й інший поштовий проксі, але навіщо городити город серверів, якщо на фронтенді вже встановлено nginx для віддачі статики HTTP, наприклад?

Поштовий проксі-сервер у Nginx зроблений не зовсім стандартно. Він використовує додатковий шар автентифікації, реалізований засобами HTTP, і лише якщо користувач проходить цей бар'єр, він пропускається далі. Забезпечується така функціональність шляхом створення сторінки/скрипту, якою nginx віддає дані користувача, а вона/він повертає відповідь у вигляді стандартних OK або причини відмови (типу Invalid login or password). Скрипт запускається з наступними заголовками:

Вхідні дані скрипта аутентифікації HTTP_AUTH_USER: користувач HTTP_AUTH_PASS: пароль HTTP_AUTH_PROTOCOL: поштовий протокол (IMAP, POP3 або SMTP)

А повертає такі:

HTTP_AUTH_STATUS: OK або причина відмови HTTP_AUTH_SERVER: реальний поштовий сервер для перенаправлення HTTP_AUTH_PORT: порт сервера

Чудова особливість такого підходу в тому, що його можна використовувати зовсім не для самої аутентифікації, а щоб розкидати користувачів по різних внутрішніх серверах, залежно від імені користувача, даних про поточні навантаження на поштові сервери або взагалі організувавши найпростіше балансування навантаження за допомогою round-robin . Втім, якщо потрібно лише перекинути користувачів на внутрішній поштовий сервер, можна використовувати замість реального скрипта заглушку, реалізовану самим nginx. Наприклад, найпростіший SMTP- та IMAP-проксі в конфізі nginx буде виглядати так:

# vi /etc/nginx/nginx.conf mail ( # Адреса скрипта аутентифікації auth_http localhost:8080/auth; # Відключаємо команду XCLIENT, деякі поштові сервери її не розуміють xclient off; # IMAP-сервер server ( listen 143; protocol imap; proxy on; ) # SMTP-сервер server ( listen 25; protocol smtp; proxy on; ) )

# vi /etc/nginx/nginx.conf http ( # Мапінг на потрібний порт поштового сервера залежно від порту, відправленого в заголовку HTTP_AUTH_PROTOCOL map $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # Реалізація « - завжди повертає OK і перекидає користувача на внутрішній поштовий сервер, виставляючи потрібний порт за допомогою наведеного вище мапінг server ( listen 8080; location /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0. ;add_header "Auth-Port" $mailport; return 200; ) ) )

Це все. Така конфігурація дозволяє прозоро перенаправляти користувачів на внутрішній поштовий сервер, не створюючи верхівки у вигляді непотрібного в цьому випадку скрипту. Застосувавши скрипт, таку конфігурацію можна значно розширити: налаштувати балансування навантаження, перевіряти користувачів за базою LDAP та виконувати інші операції. Написання скрипта виходить за рамки цієї статті, проте його дуже легко реалізувати, навіть маючи лише поверхневі знання про PHP та Python.

Потокове мовлення відео

Підняти звичайний відеохостинг на базі Nginx легко. Достатньо лише викласти перекодоване відео в доступний серверу каталог, прописати його в конфіг і налаштувати флеш-або HTML5-програвач так, щоб він брав відео з цього каталогу. Однак, якщо потрібно налаштувати безперервне мовлення відео з якогось зовнішнього джерела або веб-камери, така схема не спрацює, і доведеться дивитись у бік спеціальних потокових протоколів.

Є кілька протоколів, що вирішують це завдання, найбільш ефективний і підтримуваний RTMP. Лихо лише в тому, що майже всі реалізації RTMP-сервера страждають від проблем. Офіційний Adobe Flash Media Server є платним. Red5 і Wowza написані на Java, тому не дають потрібної продуктивності, ще одна реалізація, Erlyvideo, написана на Erlang, що добре в разі налаштування кластера, але не так ефективно для одиночного сервера.

Я ж пропоную інший підхід – скористатися модулем RTMP для nginx. Він має чудову продуктивність і до того ж дозволить використовувати один сервер для віддачі як веб-інтерфейсу сайту, так і відеопотоку. Проблема тільки в тому, що цей модуль неофіційний, тому nginx з його підтримкою доведеться зібрати самостійно. Благо складання здійснюється стандартним способом:

$ sudo apt-get remove nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ unzip nginx-rtmp.zip $ wget http://nginx.org/download/nginx- 1.2.6.tar.gz $tar -xzf nginx-1.2.6.tar.gz $cd nginx-1.2.6 $./configure --add-module=/tmp/nginx-rtmp-module-master $make$ sudo make install

Тепер модуль потрібно настроїти. Робиться це, як завжди, через конфіг nginx:

Rtmp ( # Активуємо сервер мовлення на порту 1935 за адресою сайт/rtmp server ( listen 1935; application rtmp ( live on; ) ) )

Модуль RTMP не вміє працювати в багатопотоковій конфігурації, тому кількість робочих процесів nginx доведеться скоротити до одного (пізніше я розповім, як оминути цю проблему):

Worker_processes 1;

Тепер можна зберегти файл та змусити nginx перечитати конфігурацію. Налаштування nginx завершено, але самого відеопотоку ми ще не маємо, тому його потрібно десь взяти. Наприклад, нехай це буде файл video.avi з поточного каталогу. Щоб перетворити його на потік і завернути в наш RTMP-мовник, скористаємося старим добрим FFmpeg:

# ffmpeg -re -i ~/video.avi -c copy -f flv rtmp://localhost/rtmp/stream

Якщо відеофайл представлений не у форматі H264, його слід перекодувати. Це можна зробити на льоту за допомогою того ж FFmpeg:

# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream

Потік можна захопити прямо з веб-камери:

# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream

Щоб переглянути потік на стороні клієнта, можна скористатися будь-яким програвачем з підтримкою RTMP, наприклад mplayer:

$mplayer rmtp://example.com/rtmp/stream

Або вбудувати програвач прямо на веб-сторінку, яка віддається тим же nginx (приклад з офіційної документації):

Найпростіший веб-програвач RTMP

Важливі рядки тут всього два: "file: "stream"", що вказує на RTMP-потік, і "streamer: "rtmp://localhost/rtmp"", в якій вказана адреса RTMP-стримера. Для більшості завдань таких налаштувань буде цілком достатньо. За однією адресою можна пустити кілька різних потоків, а nginx ефективно їх мультиплексувати між клієнтами. Але це далеко не все, що здатний RTMP-модуль. З його допомогою, наприклад, можна організувати ретрансляцію відеопотоку з іншого сервера. Сервер FFmpeg для цього взагалі не потрібен, достатньо додати наступні рядки до конфіг:

# vi /etc/nginx/nginx.conf application rtmp ( live on; pull rtmp://rtmp.example.com; )

Якщо потрібно створити кілька потоків у різній якості, можна викликати перекодувальник FFmpeg прямо з nginx:

# vi /etc/nginx/nginx.conf application rtmp ( live on; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) application rtmp-320x240 ( live on; )

За допомогою такої конфігурації ми отримаємо відразу два мовники, один з яких буде доступний за адресою rtmp://сайт/rtmp, а другий, що веде мовлення як 320 x 240, - за адресою rtmp://сайт/rtmp–320x240. Далі на сайт можна повісити флеш-плеєр і кнопки вибору якості, які будуть підсовувати плеєру ту чи іншу адресу мовника.

Ну і наостанок приклад мовлення музики в мережу:

While true; do ffmpeg -re -i ``find /var/music -type f -name "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; done

Git-проксі

Система контролю версій Git здатна забезпечувати доступ до репозиторій не лише за протоколами Git та SSH, а й за HTTP. Колись реалізація доступу по HTTP була примітивною та нездатною забезпечити повноцінну роботу з репозиторієм. З версії 1.6.6 ситуація змінилася, і сьогодні цей протокол можна використовувати, щоб, наприклад, обійти обмеження брандмауерів як з того, так і з іншого боку з'єднання або створення власного Git-хостингу з веб-інтерфейсом.

На жаль, офіційна документація розповідає лише про організацію доступу до Git засобами веб-сервера Apache, але, оскільки сама реалізація є зовнішньою програмою зі стандартним CGI-інтерфейсом, її можна прикрутити практично до будь-якого іншого сервера, включаючи lighttpd і, звичайно ж, nginx. Для цього не потрібно нічого, крім самого сервера, встановленого Git і невеликого FastCGI-сервера fcgiwrap, який потрібен, тому що nginx не вміє працювати з CGI безпосередньо, але вміє викликати скрипти за допомогою протоколу FastCGI.

Вся схема роботи виглядатиме так. Сервер fcgiwrap висітиме в фоні і чекатиме запиту на виконання CGI-додатка. Nginx, у свою чергу, буде налаштований на запит виконання CGI-бінарника git-http-backend через FastCGI-інтерфейс щоразу при зверненні до вказаної нами адреси. Отримавши запит, fcgiwrap виконує git-http-backend із зазначеними CGI-аргументами, переданими GIT-клієнтом, та повертає результат.

Щоб реалізувати таку схему, спочатку встановимо fcgiwrap:

$ sudo apt-get install fcgiwrap

Налаштувати його не потрібно, всі параметри передаються протоколом FastCGI. Запущений він буде також автоматично. Тому залишається лише налаштувати nginx. Для цього створюємо файл /etc/nginx/sites-enabled/git (якщо такого каталогу немає, можна писати в основний конфіг) і пишемо до нього наступне:

# vi /etc/nginx/sites-enabled/git server ( # Висимо на порту 8080 listen 8080; # Адреса нашого сервера (не забудь додати запис у DNS) server_name git.example.ru; # Логи access_log /var/log/nginx /git-http-backend.access.log;error_log/var/log/nginx/git-http-backend.error.log; arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) include /etc/nginx/fastcgi_params; # Адреса нашого git-http-backend fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # Адреса Git-репозиторія fastcgi_param GIT_PROJECT_ROOT /srv/git; # Адреса файлу fastcgi_param PATH_INFO $uri; # Адреса сервера fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Адреса для доступу на запис . )$ ( # Повноваження користувача auth_basic "git anonymous read-only, authenticated write"; # HTTP-автентифікація на основі htpasswd auth_basic_user_file /etc/nginx/htpasswd; # Налаштування FastCGI i nclude /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; fastcgi_param GIT_PROJECT_ROOT /srv/git; fastcgi_param PATH_INFO $1; fastcgi_pass 127.0.0.1: 9001; )

Цей конфіг передбачає три важливі речі:

1. Адреса репозиторію буде /srv/git, тому виставляємо відповідні права доступу: $ sudo chown -R www-data:www-data /srv/git
2. Сам репозиторій повинен бути відкритий на читання анонімусами і дозволяти аплоад по HTTP: $ cd /srv/git $ git config core.sharedrepository true
3. Аутентифікація здійснюється за допомогою файлу htpasswd, потрібно його створити і додати до нього користувачів: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1

На цьому все, перезавантажуємо nginx:

Мікрокешування

Уявімо ситуацію з динамічним, часто оновлюваним сайтом, який раптом починає отримувати дуже великі навантаження (ну потрапив він на сторінку одного з найбільших сайтів новин) і перестає справлятися з віддачею контенту. Грамотна оптимізація та реалізація правильної схеми кешування займе довгий час, а проблеми треба вирішувати вже зараз. Що ми можемо вдіяти?

Є кілька способів вийти із цієї ситуації з найменшими втратами, проте найцікавішу ідею запропонував Фенн Бейлі (Fenn Bailey, fennb.com). Ідея в тому, щоб просто поставити перед сервером nginx і змусити його кешувати весь контент, що передається, але не просто кешувати, а всього на одну секунду. Родзинка тут у тому, що сотні та тисячі відвідувачів сайту за секунду, по суті, генеруватимуть лише одне звернення до бекенду, отримуючи здебільшого кешовану сторінку. При цьому різницю навряд чи хтось помітить, бо навіть на динамічному сайті одна секунда звичайно нічого не означає.

Конфіг із реалізацією цієї ідеї виглядатиме не так уже й складно:

# vi /etc/nginx/sites-enabled/cache-proxy # Налаштування кеша proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server ( listen 80; server_name example.com; # Кешована адреса location / ( # Кеш включений за промовчанням set $no_cache ""; # Відключаємо кеш для всіх методів, крім GET і HEAD if ($request_method !~ ^(GET|HEAD)) $) ( set $no_cache "1"; ) # У випадку якщо клієнт завантажує контент на сайт (no_cache = 1), робимо так, щоб дані, що віддаються йому, не кешувалися протягом двох секунд і він зміг побачити результат завантаження if ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1 "; ) # Включаємо/відключаємо кеш залежно від стану змінної no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Проксуємо запити на реальний сервер proxy_pass http://appserver.example.ru; proxy_cache microcache; pro$y_$ request_uri;proxy_cache_valid 200 1s;# Захист від проблеми Thundering herd proxy_cache_use_stale updating;# Додаємо стандартні хідери proxy_set_h eader Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Не кешуємо файли розміром більше 1 Мб proxy_max_temp_file_size 1M; )

Особливе місце в цьому конфізі займає рядок «proxy_cache_use_stale updating;», без якого ми отримали періодичні сплески навантаження на бекенд-сервер через запити, що прийшли під час оновлення кеша. В іншому все стандартно і має бути зрозумілим без зайвих пояснень.

Наближення проксі до ЦА

Незважаючи на глобальне збільшення швидкостей інтернету, фізична віддаленість сервера від цільової аудиторії все одно продовжує грати свою роль. Це означає, що, якщо російський сайт крутиться на сервері, розташованому десь в Америці, швидкість доступу до нього буде апріорі повільніше, ніж з російського сервера з такою ж шириною каналу (звісно, ​​якщо заплющити очі на всі інші фактори). Інша річ, що розміщувати сервери за кордоном найчастіше вигідніше, у тому числі й у плані обслуговування. Тому для отримання профіту у вигляді більш високих швидкостей віддачі доведеться йти на хитрість.

Один із можливих варіантів: розмістити основний продуктивний сервер на Заході, а не дуже вимогливий до ресурсів фронтенд, який віддає статику, розгорнути на території Росії. Це дозволить без серйозних витрат виграти у швидкості. Конфіг nginx для фронтенда в цьому випадку буде простим і всім нам знайомим реалізацією проксі:

# vi /etc/nginx/sites-enabled/proxy # Зберігаємо кеш 30 днів у 100 Гб сховище proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static:32m inactive=30d max_size=100g; server ( listen 80; server_name example.com; # Власне, наш проксі location ~ * .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Адреса бекенда proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_x; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )

Висновки

Сьогодні за допомогою nginx можна вирішити безліч різних завдань, багато з яких взагалі не пов'язані з веб-сервером і протоколом HTTP. Поштовий проксі, сервер потокового мовлення та інтерфейс Git – це лише частина таких завдань.

iRedMail - це готове складання поштового сервера з відкритим вихідним кодом. В основі складання лежить SMTP-сервер Postfix (Mail Transfer Agent, скорочено MTA). Також у збірку входять: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData та NGINX.

Dovecot- IMAP/POP3 сервер.

Spamassassin- Засіб фільтрації спаму.

Greylist- Засіб боротьби зі спамом на основі сірих списків.

ClamAV- Антивірус.

Roundcubeі SOGo- Веб-клієнти для роботи з електронною поштою.

NetData- Програма моніторингу роботи сервера в реальному часі.

Nginx- Веб-сервер.

Підтримує операційні системи: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12і OpenBSD 6.4.

iRedMail має платну та безкоштовну версії, які відрізняються одна від одної функціоналом власного веб-інтерфейсу поштового складання iRedAdmin. У безкоштовній версії можна лише створювати домени, поштові скриньки користувачів та адміністраторів. Якщо вам необхідно створити аліас, то зробити це у безкоштовній версії через iRedAdmin вже не вдасться. На щастя, є безкоштовне рішення, яке називається PostfixAdmin, що дозволяє це реалізувати. PostfixAdmin легко вбудовується в iRedMail і чудово з ним працює.

Встановлення

Для установки нам знадобиться одна з перерахованих вище операційних систем. Я буду використовувати Ubuntu Server 18.04. Також у вас має бути куплене доменне ім'я та налаштована DNS зона. Якщо ви використовуєте DNS сервера вашого доменного реєстратора, необхідно в розділі управління доменною зоною зробити два записи: A і MX. Також можна використовувати свій власний DNS, настроївши делегування в особистому кабінеті реєстратора вашого доменного імені.

Налаштування доменної зони під час використання DNS реєстратора

Зверніть увагу! Час набуття налаштувань DNS від кількох годин до одного тижня. Поки налаштування не набудуть чинності, поштовий сервер не буде коректно працювати.

Для установки викачуємо із сайту iRedMail актуальну версію. На сьогодні це 0.9.9.

# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2

Потім розпаковуємо завантажений архів.

# tar xjf iRedMail-0.9.9.tar.bz2

Розпакування архіву

І переходимо до створеної папки.

# cd iRedMail-0.9.9

Папка з інсталятором iRedMail

Перевіряємо вміст папки

Вміст папки

І запускаємо скрипт установки iRedMail.

# bash iRedMail.sh

Запуститься встановлення поштової системи. У процесі установки потрібно буде відповісти на низку запитань. Погоджуємося розпочати установку.

Початок встановлення

Вибір директорії установки

Тепер потрібно вибрати веб-сервер. Вибір невеликий, тому вибираємо NGINX.

Вибір веб-сервера

Тепер необхідно вибрати сервер баз даних, який буде встановлений та налаштований на роботу з поштовою системою. Вибираємо MariaDB.

Вибір сервера баз даних

Задаємо пароль root на базу.

Створення пароля пароля бази даних

Тепер указуємо наш поштовий домен.

Створення поштового домену

Потім створюємо пароль на скриньку адміністратора [email protected]домен.ru.

Створення пароля поштового адміністратора

Вибір веб-компонентів

Підтверджуємо налаштування.

Підтвердження налаштувань

Встановлення запущено.

Встановлення

Після закінчення установки підтверджуємо створення правила iptablesдля SSHта перезапускаємо firewall. iRedMail працює з iptables. В Ubuntu найчастіше використовують утиліту управління firewall UFW. Якщо у вас з тієї чи іншої причини виникне така потреба, то встановіть UFW (apt install ufw) і додайте правила що б UFW(Приклад: ufw allow "Nginx Full"або ufw allow Postfix) не блокував роботу поштового сервера. Переглянути список доступних правил можна за допомогою команди: ufw app list. Потім увімкніть UFW: ufw enable.

Створення правила iptables

Перезапуск firewall

На цьому встановлення iRedMail завершено. Система вивела нам адреси веб-інтерфейсів та облікові дані для входу. Щоб увімкнути всі компоненти поштової системи, необхідно перезавантажити сервер.

Закінчення установки

Перезавантажуємось.

# reboot

Налаштування

Для початку потрібно переконатись, що все працює. Спробуємо зайти до панелі керування iReadAdmin за адресою https://домен/iredadmin. Логін [email protected]домен.ru, пароль створили під час встановлення. Є російськомовний інтерфейс.

Як бачимо, все працює. При вході в iRedAdmin ви, швидше за все, отримали помилку безпеки, пов'язану з сертифікатом. Це відбувається тому, що iRedMail має вшитий самопідписний сертифікат, на який і лається браузер. Для усунення цієї проблеми необхідно встановити діючий SSL сертифікат. Якщо у вас є куплений, можете встановити його. У прикладі я встановлюватиму безкоштовний SSL від Let's Encrypt.

Установка SSL сертифіката Let's Encrypt

Встановлювати сертифікат ми за допомогою утиліти certbot. Спочатку додамо репозиторій.

# add-apt-repository ppa:certbot/certbot

Потім встановимо сам certboot із необхідними компонентами.

# apt install python-certbot-nginx

Отримуємо сертифікат.

# certbot --nginx -d домен.ru

Після запуску команди, система попросить вас ввести адресу електронної пошти, вводимо. Після цього ви швидше за все отримаєте помилку, що неможливо знайти серверний блок, для якого генерувався сертифікат. В даному випадку це нормально, оскільки ніякого серверного блоку у нас і немає. Для нас головне отримати сертифікат.

Отримання сертифіката

Як бачимо, сертифікат успішно отриманий і система вказала нам шляхи до самого сертифіката і ключа. Вони нам якраз і потрібні. Взагалі ми отримали 4 файли, які зберігаються в папці "/etc/letsencrypt/live/домен". Тепер необхідно повідомити веб-сервер про наш сертифікат, тобто замінити вшитий сертифікат на той, який ми щойно отримали. Для цього нам необхідно відредагувати лише один файл.

# nano /etc/nginx/templates/ssl.tmpl

І змінюємо в ньому два останні рядки.

Замінюємо SSL сертифікат

Змінюємо шляхи у файлі на шляху, які нам повідомила система при отриманні сертифіката.

Заміна сертифіката SSL

І перезапускаємо NGINX.

# service nginx restart

Тепер пробуємо знову зайти в iRedAdmin.

Перевірка SSL сертифіката

Помилки сертифікату немає. Сертифікат є дійсним. Можна натиснути на замок і подивитися його властивості. Після закінчення терміну дії сертифіката certboot має оновити його автоматично.

Тепер повідомимо про сертифікат Dovecot та Postfix. Для цього відредагуємо два конфігураційні файли. Виконуємо:

# nano /etc/dovecot/dovecot.conf

Знаходимо блок:

#SSL: Global settings.

І міняємо прописаний сертифікат на наш.

Заміна сертифікату для Dovecot

Також зверніть увагу на рядок "ssl_protocols". Її значення має бути "!SSLv3", інакше отримайте помилку "Warning: SSLv2 не підтримується OpenSSL. Please consider removing it from ssl_protocols" при перезапуску Dovecot.

# nano /etc/postfix/main.cf

Знаходимо блок:

# SSL key, certificate, CA

І змінюємо в ньому шляхи до файлів нашого сертифіката.

Заміна сертифіката для Postfix

На цьому встановлення сертифіката закінчено. Необхідно перезапустити Dovecot та Postfix, але краще виконати перезавантаження сервера.

# service dovecot restart

# reboot

Установка PHPMyAdmin

Цей пункт є необов'язковим, але я рекомендую виконати його та встановити PHPMyAdmin для зручності роботи з базами даних.

# apt install phpmyadmin

Інсталятор запитає на роботу з яким веб-сервером налаштовувати PHPMyAdmin, тому що NGINX в цьому списку немає, просто натискаємо TAB і йдемо далі.

Установка PHPMyAdmin

Після закінчення установки для того, щоб phpmyadmin заробив потрібно зробити симлінк на директорію з якою за замовчуванням працює NGINX.

# ln -s /usr/share/phpmyadmin /var/www/html

І пробуємо зайти на https://домен/phpmyadmin/

PHPMyAdmin працює. Підключення захищене сертифікатом, жодних помилок немає. Йдемо далі. Створимо адміністратора баз даних MySQL (MariaDB).

# mysql

І потрапляємо у консоль управління MariaDB. Далі по черзі робимо команди:

MariaDB > CREATE USER "admin"@"localhost" IDENTIFIED BY "пароль";
MariaDB > GRANT ALL PRIVILEGES ON *.* TO "admin"@"localhost" WITH GRANT OPTION;
MariaDB > FLUSH PRIVILEGES;

Створення користувача MySQL

Усі OK, вхід виконаний. PHPMyAdmin готовий до роботи.

Установка PostfixAdmin

У принципі PostfixAdmin, як і PHPMyAdmin, можна не встановлювати. Поштовий сервер чудово працюватиме і без цих компонентів. Але тоді ви не зможете створювати поштові аліаси. Якщо вам цього не треба, то сміливо можете пропустити ці розділи. Якщо ж аліаси вам все ж таки потрібні, то варіанти у вас два: покупка платної версії iReaAdmin або встановлення PostfixAdmin. Звичайно, можна робити це і без додаткового ПЗ, прописуючи аліаси в базі даних в ручну, але це не завжди зручно і не для всіх підходить. Я рекомендую використовувати PostfixAdmin, його встановлення та інтеграцію з iRedMail ми зараз і розглянемо. Запускаємо установку:

# apt install postfixadmin

Погоджуємось та створюємо пароль для системної бази програми.

Установка PostfixAdmin

Установка PostfixAdmin

Робимо симлінк за аналогією до установки PHPMyAdmin.

# ln -s /usr/share/postfixadmin /var/www/html

Робимо користувача, від якого запускається веб-сервер власником каталогу. У цьому випадку NGINX запускається від імені користувача www-data.

# chown -R www-data /usr/share/postfixadmin

Тепер нам потрібно відредагувати конфігураційний файл PostfixAdmin та внести до нього інформацію про базу даних, яку використовує iRedAdmin. За промовчанням ця база називається vmail. Якщо зайти в PHPMyAdmin, то можна її там побачити. І так, щоб PostfixAdmin міг вносити зміни в базу даних прописуємо її в конфігурації PostfixAdmin.

# nano /etc/postfixadmin/config.inc.php

Знаходимо рядки:

$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["database_name"] = $dbname;

І приводимо до вигляду:

$CONF["database_type"] = "mysqli"; # Тип бази даних
$CONF["database_host"] = "localhost"; # Хост сервера баз даних
$CONF["database_user"] = "admin"; # Логін із правами на запис до бази vmail. Можна використовувати раніше створений admin
$CONF["database_password"] = "пароль"; # Пароль користувача вказаного вище
$CONF["database_name"] = "vmail"; # Назва бази даних iRedMail

Внесення інформації про базу даних

Якщо ви плануєте використовувати поштовий веб-клієнт SOGo, необхідно зробити ще одну додаткову дію, а саме поміняти шифрування PostfixAdmin в пункті $CONF["encrypt"]з "md5crypt"на "dovecot:SHA512-CRYPT". Якщо ви це не зробите, то при спробі авторизації в SOGo користувачем, створеним у PostfixAdmin, отримаєте помилку невірний логін або пароль.

Зміна типу шифрування

Тепер, щоб успішно завершити установку і не отримати помилок, необхідно виконати запит до бази даних. Зручно це зробити через PHPMyAdmin. Вибираємо базу vmail та переходимо на вкладку SQL. У вікні вводимо:

DROP INDEX domain on mailbox;
DROP INDEX domain on alias;
ALTER TABLE alias ADD COLUMN `goto` text NOT NULL;

Запит до бази даних

І натискаємо "Вперед". Тепер у нас все готово, можна переходити до веб-інтерфейсу PostfixAdmin і завершувати установку. Для цього у браузері необхідно набрати: https://домен/postfixadmin/setup.php.

Повинно з'явитися таке:

Установка PostfixAdmin

Якщо все зроблено за інструкцією, то помилок не повинно бути. Якщо все ж таки будуть, то їх вдається усунути, інакше система не дасть вам продовжити. Задаємо пароль установки і тиснемо " Generate password hashСистема згенерує хеш пароля, який необхідно вставити в параметр $CONF["setup_password"].

Завершення установки PostfixAdmin

Зміна параметрів конфігураційного файлу

Тепер вводимо новий пароль і створюємо адміністратора PostfixAdmin. Адміністратора з логіном postmaster краще не створювати, оскільки можуть бути проблеми із входом до панелі адміністрування iRedAdmin.

Створення адміністратора PostfixAdmin

Все, адміністратор створено. Ви можете виконувати вхід.

Зауважте, що з точки зору безпеки файл setup.php в директорії postfixadmin краще перейменувати або видалити.

Переходимо: https://домен/postfixadmin/і вводимо щойно створені облікові дані. У PostfixAdmin, як і в iRedAdmin, доступна російська мова. Його можна обрати під час авторизації.

Спробуємо створити поштову скриньку користувача.

Увімкнення/Вимкнення модулів iRedMail

За керування модулями iRedMail відповідає iRedAPD. Він має файл конфігурації, в якому прописані працюючі модулі. Якщо той чи інший модуль вам не потрібен, його можна видалити з конфігураційного файлу і він перестане працювати. Виконуємо:

# nano /opt/iredapd/settings.py

Знаходимо рядок " pluginsі видаляємо з неї не потрібні вам компоненти. Я приберу компонент "greylisting". Він звичайно досить ефективно захищає від спаму, але часто не доходять і потрібні листи.

Greylist (сірий список) – технологія автоматичного захисту від спаму, заснована на аналізі поведінки сервера відправника пошти. При включеному "greylisting" сервер вперше відмовляється прийняти листа з невідомої йому адреси, повідомляючи про тимчасову помилку. У такому разі сервер відправник повинен повторити надсилання пізніше. Спамерські програми зазвичай такого не роблять. Якщо лист надсилається повторно, він додається до списку на 30 днів і обмін поштою відбувається з першого разу. Використовувати цей модуль чи ні вирішуйте самі.

Увімкнення/Вимкнення модулів пошти

Після внесення змін необхідно перезапустити iRedAPD.

# service iredapd restart

Тестування поштового сервера

На цьому налаштування поштового сервера iRedMail завершено. Можна приступати до завершального етапу – тестування. Створимо дві поштові скриньки. Для перевірки один через iRedAdmin, другий через PostfixAdmin і відправимо листа з одного ящика на інший і навпаки. У iRedAdmin створимо скриньку [email protected]домен.ru. У PostfixAdmin - [email protected]домен.ru

Створення користувача в iRedAdmin

Створення користувача в PostfixAdmin

Перевіряємо, що користувачі створилися.

Якщо ви звернете увагу на графу "Кому" в переліку ящиків PostfixAdmin, то можна помітити різницю між ящиками створеними в iRedAdmin та PostfixAdmin. Скриньки створені в iRedAdmin відзначені як " Forward only", а створені в PostfixAdmin як -" MailboxЯ спочатку довго не міг зрозуміти чому так відбувається і яка між ними різниця, і нарешті помітив одну річ. Ящики в iRedAdmin створюються без аліасів, а ящики в PostfixAdmin з аліасом на самого себе.

І якщо ці аліаси видалити, то ящики будуть відображатися як і створені в iRedAdmin. Forward only".

Видалення аліасів

Аліас видалені. Перевіряємо PostfixAdmin.

Як бачимо всі ящики стали "Forward only". Так само якщо створити в ящику створеному в iRedAdmin аліас сам на себе, то він стане "Mailbox". В принципі, на працездатність пошти це не впливає. Єдине ви не зможете створити аліас на ящику, створеному в PostfixAdmin. Замість створення аліасу потрібно буде відредагувати вже наявний. До речі про аліаси, у новій версії iRedMail необхідно внести зміну в одну з карток Postfix, яка відповідає за аліаси. І якщо ви цього не зробите, то створені аліаси не працюватимуть. Для цього необхідно у файлі /etc/postfix/mysql/virtual_alias_maps.cfвиправити:

Виконуємо:

# nano /etc/postfix/mysql/virtual_alias_maps.cf

І виправляємо.

Налаштування аліасів

Перезапускаємо Postfix:

# service postfix restart

Після цього все має запрацювати.

І так, приступимо до перевірки пошти. У ящик user1ми зайдемо через Roundcube, а в ящик user2- через SOGo і відправимо лист із скриньки user1на user2і назад.

Надсилання листа з Roundcube

Отримання листа у SOGo

Надсилання листа до SOGo

Отримання листа у Roundcube

Все працює без жодних проблем. Доставка листа займає від двох до п'яти секунд. Так само листи чудово доставляються на сервери яндекса і mail.ru (перевірено).

Тепер перевіримо аліаси. Створимо ящик user3і зробимо аліас із скриньки user1на ящик user2. І відправимо лист із скриньки user3на ящик user1. При цьому лист має прийти на скриньку user2.

Створення аліасу

Надсилання листа з скриньки user3 на скриньку user1

Отримання листа на скриньці user2

З роботою аліасів теж усе гаразд.

Протестуємо роботу поштового сервера через локальний поштовий клієнт. На прикладі розглянемо Mozilla Thunderbird. Створимо ще двох користувачів: client1і client2. Одну скриньку підключимо по IMAP, іншу по POP3 і відправимо лист з однієї скриньки на іншу.

Підключення по IMAP

Підключення через POP3

Надсилаємо листа з Клієнт 1 на Клієнт 2.

Відправлення з Клієнт 1

Отримання на Клієнт 2

І у зворотному порядку.

Відправлення з Клієнт 2

Отримання на Клієнт 1

Все працює.

Якщо перейти на адресу: https://домен/netdata, можна спостерігати графіки стану системи.

Висновок

На цьому встановлення, настроювання та тестування поштової системи iRedMail закінчено. В результаті ми отримали повністю безкоштовний повноцінний поштовий сервер з діючим SSL сертифікатом, двома різними поштовими веб-клієнтами, двома панелями управління, а також вбудованими в пошту антиспамом і антивірусом. За вашим бажанням замість поштових веб-клієнтів можна використовувати локальні поштові клієнти, такі як Microsoft Outlook або Mozilla Thunderbird. Якщо не плануєте використовувати поштові веб-клієнти, їх можна взагалі не встановлювати, щоб не навантажувати зайвим сервер, або встановити щось одне, що вам подобається більше. Мені особисто більше подобається SOGo, тим, що його інтерфейс оптимізований під мобільні пристрої, тим самим дуже зручно переглядати електронну пошту зі смартфона. Те саме стосується NetData і iRedAdmin, якщо не плануєте користуватися, то краще не встановлювати. Ця поштова система не дуже вимоглива до ресурсів. Все це працює на VPS сервері з 1024 Мб оперативної пам'яті та одним віртуальним процесором. Якщо у вас залишилися питання по даній поштовій системі пишіть у коментарях.

P.S. У ході тестування цього продукту на різних операційних системах з 1 Гб оперативної пам'яті (Ubuntu, Debian, CentOS) з'ясувалося, що 1 Гб мало для роботи ClamAV. Майже завжди при використанні 1 Гб пам'яті антивірус посилався на помилку пов'язану з базою даних. При цьому на операційних системах Debian і Ubuntu антивірус просто не сканував пошту, що проходить через сервер, в іншому все працювало нормально. На CentOS ситуація була дещо іншою. Служба clamd повністю вішала систему, тим самим унеможливлюючи нормальну роботу сервера. При спробі входу в веб-інтерфейси періодично NGINX видавав 502 та 504 помилки. Пошта вирушала теж за один раз. При цьому якщо додати оперативної пам'яті до 2 Гб, то у всіх випадках жодних проблем із роботою антивіруса та сервера загалом не спостерігалося. ClamAV сканував поштову сервер, що проходить через поштовий сервер, про що писав у логах. При спробі надіслати вірус у вкладенні оправлення блокувалося. Споживання пам'яті становило приблизно 1.2 – 1.7 Гб.

Ця стаття буде відображатися як configuration NGINX Plus або NGINX Open Source як proxy для mail server або external mail service.

Introduction

NGINX може проксі IMAP, POP3 і SMTP протоколи до однієї з upstream mail servers що host mail accounts and thus може бути використаний як один кінець для електронних клієнтів. Thay may bring in a number of benefits, such as:

• easy scaling the number of mail servers
• choosing a mail server basing on different rules, для прикладу, choosing the nearest server basing on a client’s IP address
• distributing the load among mail servers

Prerequisites

NGINX Plus (додаткове включення електронної пошти необхідний для proxy email traffic) or NGINX Open Source compiled the mail modules using the --with-mail parameter for email proxy functionality and --with-mail_ssl_module parameter для SSL/TLS support:

$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[DIR] /openssl-1.1.1

IMAP, POP3 та/або SMTP mail servers or an external mail service

Configuring SMTP/IMAP/POP3 Mail Proxy Servers

У NGINX configuration file:

mail ( #... )

mail (server_name mail.example.com; #...)

mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; #... )

Власне, особливість, коли ви можете повідомити користувача про помилки від authentication server, specifying the proxy_pass_error_message directive. This may be handy when a mailbox runs out of memory:

mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; #... )

Налаштувати будь-який SMTP, IMAP, або POP3 сервер з блоками сервера. Для кожного server, specify:

• the port numberщо відповідають спеціальному протоколу з listen directive
• the protocol with the protocol directive (якщо не specified, will be automatically detected from the port specified in the listen directive)
• permitted authentication methods with imap_auth , pop3_auth , and smtp_auth directives:

server ( listen 25 ; protocol smtp ; smtp_auth login plain cram-md5 ; ) server ( listen 110 ; protocol pop3 ; pop3_auth plain apop cram-md5 ; ) server ( listen 143 ; protocol imap ; )

Setting up Authentication for a Mail Proxy

Будь-який POP3/IMAP/SMTP запит від клієнта буде першим authenticated an external HTTP authentication server or by an authentication script. Having an authentication server є obligatory для NGINX mail server proxy. Server може бути створений за допомогою в залежності від NGINX authentication protocol which is based on the HTTP protocol.

Якщо authentication successful, the authentication server буде choose an upstream server and redirect the request. У цьому випадку, відповідь від сервера буде складатися з наступних ліній:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # the server name або IP address of the upstream server that will used for mail processing Auth-Port: # the port of the upstream server

Якщо authentication fails, the authentication server буде return an error message. У цьому випадку, відповідь від сервера буде складатися з наступних ліній:

HTTP/1.0 200 OK Auth-Status: # an error message to be returned to the client, for example “Invalid login or password” Auth-Wait: # the number of remaining authentication attempts until the connection is closed

Note that in both cases the response will contain HTTP/1.0 200 OK which might be confusing.

Для того, щоб дізнатися більше про відповіді та відповіді з authentication server, ngx_mail_auth_http_module in NGINX Reference documentation .

Setting up SSL/TLS for Mail Proxy

Використовуючи POP3/SMTP/IMAP через SSL/TLS, ви можете висловити, що дані проходять між клієнтом і електронним сервером.

Щоб відключити SSL/TLS для електронної пошти:

Make sure your NGINX is configured with SSL/TLS support by typing-in the nginx -V command in the command line and then looking for the with -mail_ssl_module line in the output:

$nginx -V configure arguments: ... with-mail_ssl_module

Make sure you hatained server certificates and private key and put them on the server. А Certificate може бути одержана від trusted Certificate Authority (CA) або генерується за допомогою SSL library such as OpenSSL.

ssl on;

starttls on;

Додаткові SSL certificates: specify the path to the certificates (який повинен бути в форматі PEM) з ssl_certificate directive, і specify the path to the private key in the ssl_certificate_key directive:

mail ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )

Ви можете використовувати тільки сильні версії і циферки з SSL/TLS з текстами ssl_process and ssl_ciphers directives, або ви можете встановити ваші власні preferable protocols and ciphers:

mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )

Optimizing SSL/TLS for Mail Proxy

These hints will help you make your NGINX mail proxy faster and more secure:

Набір номерів робітників процесів, які відображаються на кількох процесорах з worker_processes directive set on the same level as the mail context:

worker_processes auto; mail ( #... )

Enable the shared session cache and disable the built-in session cache with the auto; mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; ssl on ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_server key ;ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ;ssl_ciphers HIGH:!aNULL:!MD5 ; ; protocol pop3 ; pop3_auth plain apop cram-md5 ; ) server ( listen 143 ; protocol imap ; ) )

У цьому випадку, є три електронних proxy servers: SMTP, POP3 і IMAP. Всі сервери configured with SSL and STARTTLS support. SSL session parameters will be cached.

Проксі-сервер використовує HTTP authentication server – його configuration is beyond the scope of this article. Всі аварії повідомлення від сервера будуть відновлені до клієнтів.