Serveur de messagerie Nginx. Configuration de NGINX pour le proxy de messagerie

Cet article explique comment configurer NGINX Plus ou NGINX Open Source en tant que proxy pour un serveur de messagerie ou un service de messagerie externe.

Introduction

NGINX peut transmettre les protocoles IMAP, POP3 et SMTP à l'un des serveurs de messagerie en amont qui hébergent les comptes de messagerie et peut donc être utilisé comme point de terminaison unique pour les clients de messagerie. Cela peut apporter un certain nombre d’avantages, tels que :

• mise à l'échelle facile du nombre de serveurs de messagerie
• choisir un serveur de messagerie en fonction de différentes règles, par exemple choisir le serveur le plus proche en fonction de l'adresse IP d'un client
• répartir la charge entre les serveurs de messagerie

Conditions préalables

NGINX Plus (inclut déjà les modules Mail nécessaires au trafic de messagerie proxy) ou NGINX Open Source a compilé les modules Mail en utilisant le paramètre --with-mail pour la fonctionnalité de proxy de messagerie et le paramètre --with-mail_ssl_module pour la prise en charge SSL/TLS :

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

Serveurs de messagerie IMAP, POP3 et/ou SMTP ou service de messagerie externe

Configuration des serveurs proxy de messagerie SMTP/IMAP/POP3

Dans le fichier de configuration NGINX :

mail ( #... )

mail (nom_serveur mail.exemple.com; #...)

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

Vous pouvez également spécifier s'il faut informer un utilisateur des erreurs du serveur d'authentification en spécifiant la directive proxy_pass_error_message. Cela peut être pratique lorsqu'une boîte aux lettres manque de mémoire :

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

Configurez chaque serveur SMTP, IMAP ou POP3 avec les blocs de serveur. Pour chaque serveur, précisez :

• le numéro de port qui correspondent au protocole spécifié avec la directive d'écoute
• le protocole avec la directive de protocole (s'il n'est pas spécifié, sera automatiquement détecté à partir du port spécifié dans la directive d'écoute)
• permis méthodes d'authentification avec les directives imap_auth , pop3_auth et smtp_auth :

serveur (écouter 25 ; protocole smtp ; smtp_auth login plain cram-md5 ; ) serveur (écouter 110 ; protocole pop3 ; pop3_auth plain apop cram-md5 ; ) serveur (écouter 143 ; protocole imap ; )

Configuration de l'authentification pour un proxy de messagerie

Chaque requête POP3/IMAP/SMTP du client sera d'abord authentifiée sur un serveur d'authentification HTTP externe ou par un script d'authentification. Avoir un serveur d'authentification est obligatoire pour le proxy du serveur de messagerie NGINX. Le serveur peut être créé par vous-même conformément au protocole d'authentification NGINX qui repose sur le protocole HTTP.

Si l'authentification réussit, le serveur d'authentification choisira un serveur en amont et redirigera la demande. Dans ce cas, la réponse du serveur contiendra les lignes suivantes :

HTTP/1.0 200 OK Auth-Status : OK Auth-Server : # le nom du serveur ou l'adresse IP du serveur en amont qui sera utilisé pour le traitement du courrier Auth-Port : # le port du serveur en amont

Si l'authentification échoue, le serveur d'authentification renverra un message d'erreur. Dans ce cas, la réponse du serveur contiendra les lignes suivantes :

HTTP/1.0 200 OK Auth-Status : # un message d'erreur à renvoyer au client, par exemple « Login ou mot de passe invalide » Auth-Wait : # le nombre de tentatives d'authentification restantes jusqu'à la fermeture de la connexion

Notez que dans les deux cas, la réponse contiendra HTTP/1.0 200 OK ce qui pourrait prêter à confusion.

Pour plus d'exemples de demandes et de réponses du serveur d'authentification, consultez le ngx_mail_auth_http_module dans la documentation de référence NGINX.

Configuration de SSL/TLS pour un proxy de messagerie

En utilisant POP3/SMTP/IMAP sur SSL/TLS, vous vous assurez que les données transmises entre un client et un serveur de messagerie sont sécurisées.

Pour activer SSL/TLS pour le proxy de messagerie :

Assurez-vous que votre NGINX est configuré avec la prise en charge SSL/TLS en tapant la commande nginx -V dans la ligne de commande, puis en recherchant la ligne with --mail_ssl_module dans la sortie :

$ nginx -V configurer les arguments : ... with--mail_ssl_module

Assurez-vous d'avoir obtenu des certificats de serveur et une clé privée et placez-les sur le serveur. Un certificat peut être obtenu auprès d'une autorité de certification (CA) de confiance ou généré à l'aide d'une bibliothèque SSL telle qu'OpenSSL.

SSL activé ;

démarre ;

Ajouter des certificats SSL : précisez le chemin d'accès aux certificats (qui doivent être au format PEM) avec la directive ssl_certificate, et précisez le chemin d'accès à la clé privée dans la directive ssl_certificate_key :

mail ( #... certificat_ssl /etc/ssl/certs/server.crt ; clé_certificat_ssl /etc/ssl/certs/server.key ; )

Vous pouvez utiliser uniquement des versions et des chiffrements forts de SSL/TLS avec les directives ssl_protocols et ssl_ciphers, ou vous pouvez définir vos propres protocoles et chiffrements préférés :

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

Optimisation de SSL/TLS pour le proxy de messagerie

Ces conseils vous aideront à rendre votre proxy de messagerie NGINX plus rapide et plus sécurisé :

Définissez le nombre de processus de travail égal au nombre de processeurs avec la directive worker_processes définie au même niveau que le contexte de messagerie :

travailleur_processus auto ; mail ( #... )

Activez le cache de session partagé et désactivez le cache de session intégré avec l'auto ; mail ( nom_serveur mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message sur ; ssl sur ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server. clé ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache partagé :SSL:10m ; ssl_session_timeout 10m ; serveur (écouter 25 ; protocole smtp ; smtp_auth login plain cram-md5 ; ) serveur (écouter 1 10 ; protocole pop3 ; pop3_auth plain apop cram-md5 ; ) serveur (écouter 143 ; protocole imap ; ) )

Dans cet exemple, il existe trois serveurs proxy de messagerie : SMTP, POP3 et IMAP. Chacun des serveurs est configuré avec le support SSL et STARTTLS. Les paramètres de session SSL seront mis en cache.

Le serveur proxy utilise le serveur d'authentification HTTP – sa configuration dépasse le cadre de cet article. Tous les messages d'erreur du serveur seront renvoyés aux clients.

iRedMail est assemblage prêt serveur de messagerie avec ouvert code source. L'assemblage est basé sur le serveur SMTP Postfix (Mail Transfer Agent, en abrégé MTA). L'assemblage comprend également : Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData et NGINX.

Dovecot - Serveur IMAP/POP3.

Spamassassin est un outil de filtrage du spam.

Greylist est un outil anti-spam basé sur une liste grise.

ClamAV est un antivirus.

Roundcube et SOGo sont des clients Web permettant de travailler avec le courrier électronique.

NetData est un programme de surveillance de serveur en temps réel.

Nginx est un serveur Web.

Prend en charge les systèmes d'exploitation : CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 et OpenBSD 6.4.

iRedMail propose des versions payantes et gratuites, qui diffèrent les unes des autres par la fonctionnalité de leur propre interface Web de l'assemblage de messagerie iRedAdmin. DANS version gratuite Vous pouvez uniquement créer des domaines, des boîtes aux lettres d'utilisateurs et d'administrateurs. Si vous devez créer un alias, vous ne pourrez plus le faire dans la version gratuite via iRedAdmin. Heureusement, il existe une solution gratuite appelée PostfixAdmin qui vous permet de le faire. PostfixAdmin s'intègre facilement à iRedMail et fonctionne très bien avec celui-ci.

Installation

Pour l'installer, nous aurons besoin de l'un des systèmes d'exploitation répertoriés ci-dessus. J'utiliserai Ubuntu Server 18.04. Vous devez également avoir acheté Nom de domaine et la zone DNS configurée. Si vous utilisez Serveurs DNS votre registraire de domaine, vous devez alors faire deux entrées dans la section de gestion de la zone de domaine : A et MX. Vous pouvez également utiliser votre propre DNS en configurant une délégation dans compte personnel votre registraire de nom de domaine.

Configuration d'une zone de domaine lors de l'utilisation d'un registraire DNS

Note! Heure d'entrée Paramètres DNS d'une durée de plusieurs heures à une semaine. Jusqu'à ce que les paramètres prennent effet, le serveur de messagerie ne fonctionnera pas correctement.

Pour installer, téléchargez depuis le site Web iRedMail version actuelle. Actuellement, il s'agit de la version 0.9.9.

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

Décompressez ensuite l'archive téléchargée.

# tar xjf iRedMail-0.9.9.tar.bz2

Déballage de l'archive

Et allez dans le dossier créé.

# cd iRedMail-0.9.9

Dossier d'installation d'iRedMail

Vérification du contenu du dossier

Contenu du dossier

Et exécutez le script d'installation d'iRedMail.

# bash iRedMail.sh

L'installation du système de messagerie va démarrer. Pendant le processus d'installation, vous devrez répondre à un certain nombre de questions. Nous acceptons de commencer l'installation.

Commencer l'installation

Sélection du répertoire d'installation

Vous devez maintenant sélectionner un serveur Web. Il n'y a pas beaucoup de choix, nous choisissons donc NGINX.

Sélection d'un serveur Web

Vous devez maintenant sélectionner un serveur de base de données qui sera installé et configuré pour fonctionner avec le système de messagerie. Sélectionnez MariaDB.

Sélection d'un serveur de base de données

Définissez le mot de passe root pour la base de données.

Création d'un mot de passe root de base de données

Nous indiquons maintenant notre domaine de messagerie.

Créer un domaine de messagerie

Ensuite, nous créons un mot de passe pour la boîte aux lettres de l'administrateur [email protected].

Création d'un mot de passe d'administrateur de messagerie

Sélection de composants Web

Confirmez les paramètres spécifiés.

Confirmation des paramètres

L'installation a commencé.

Installation

Une fois l'installation terminée, confirmez la création de la règle iptables pour SSH et redémarrez le pare-feu. iRedMail fonctionne avec iptables. Dans Ubuntu, l'utilitaire de gestion de pare-feu le plus couramment utilisé est UFW. Si pour une raison ou une autre vous avez un tel besoin, alors installez UFW (apt install ufw) et ajoutez des règles pour que UFW (exemple : ufw autorise "Nginx Full" ou ufw autorise Postfix) ne bloque pas le fonctionnement du serveur de messagerie. Vous pouvez afficher la liste des règles disponibles en exécutant la commande : ufw app list . Activez ensuite UFW : ufw activate.

Créer une règle iptables

Redémarrer le pare-feu

Ceci termine l’installation d’iRedMail. Le système nous a fourni des adresses d’interface Web et des informations de connexion. Pour activer tous les composants du système de messagerie, vous devez redémarrer le serveur.

Fin de l'installation

Redémarrons.

# redémarrage

Paramètres

Vous devez d’abord vous assurer que tout fonctionne. Essayons de nous connecter au panneau de contrôle iReadAdmin sur https://domain/iredadmin. Connectez-vous [email protected], mot de passe créé lors de l'installation. Il existe une interface en russe.

Comme vous pouvez le constater, tout fonctionne. Lors de la connexion à iRedAdmin, vous avez probablement reçu une erreur de sécurité liée au certificat. Cela se produit parce que iRedMail possède un certificat auto-signé intégré, dont le navigateur se plaint. Pour résoudre ce problème, vous devez installer un certificat SSL valide. Si vous en avez acheté un, vous pouvez l'installer. Dans l'exemple, j'installerai SSL gratuit de Let's Encrypt.

Installer un certificat SSL Let's Encrypt

Nous installerons le certificat à l'aide de l'utilitaire certbot. Tout d’abord, ajoutons un référentiel.

# add-apt-repository ppa:certbot/certbot

Ensuite, nous installerons certboot lui-même avec les composants nécessaires.

# apt installer python-certbot-nginx

Nous recevons un certificat.

# certbot --nginx -d domaine.ru

Après avoir exécuté la commande, le système vous demandera de saisir votre adresse e-mail, entrez. Ensuite, vous recevrez très probablement une erreur indiquant qu'il n'est pas possible de trouver le bloc serveur pour lequel le certificat a été généré. Dans ce cas, c’est normal, puisque nous n’avons aucun blocage de serveur. L'essentiel pour nous est d'obtenir un certificat.

Obtention d'un certificat

Comme nous pouvons le voir, le certificat a été reçu avec succès et le système nous a montré les chemins vers le certificat lui-même et vers la clé. Ils sont exactement ce dont nous avons besoin. En général, nous avons reçu 4 fichiers qui seront stockés dans le dossier "/etc/letsencrypt/live/domain". Nous devons maintenant informer le serveur Web de notre certificat, c'est-à-dire remplacer le certificat intégré par celui que nous venons de recevoir. Pour ce faire, nous devons éditer un seul fichier.

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

Et nous y modifions les deux dernières lignes.

Remplacement du certificat SSL

Nous modifions les chemins du fichier par les chemins que le système nous a indiqués lors de la réception du certificat.

Remplacement d'un certificat SSL

Et redémarrez NGINX.

# redémarrage du service nginx

Essayons maintenant de nous connecter à nouveau à iRedAdmin.

Vérification du certificat SSL

Il n'y a plus d'erreur de certificat. Le certificat est valide. Vous pouvez cliquer sur le verrou et voir ses propriétés. Lorsque le certificat expire, certboot doit le renouveler automatiquement.

Nous allons maintenant parler des certificats Dovecot et Postfix. Pour ce faire, nous allons éditer deux fichiers de configuration. Nous faisons:

# nano /etc/dovecot/dovecot.conf

Trouver le bloc :

#SSL : Paramètres globaux.

Et nous remplaçons le certificat qui y est enregistré par le nôtre.

Certificat de remplacement pour Pigeonnier

Faites également attention à la ligne "ssl_protocols". Sa valeur doit être "!SSLv3", sinon vous recevrez l'erreur "Avertissement : SSLv2 non pris en charge par OpenSSL. Veuillez envisager de le supprimer de ssl_protocols" lors du redémarrage de Dovecot.

# nano /etc/postfix/main.cf

Trouver le bloc :

# Clé SSL, certificat, CA

Et nous modifions les chemins d'accès vers les fichiers de notre certificat.

Remplacer un certificat pour Postfix

Ceci termine l’installation du certificat. Il est nécessaire de redémarrer Dovecot et Postfix, mais il vaut mieux redémarrer le serveur.

# redémarrage du service Dovecot

# redémarrage

Installation de PHPMyAdmin

Cette étape est facultative, mais je recommande de la faire et d'installer PHPMyAdmin pour faciliter l'utilisation des bases de données.

# apt installer phpmyadmin

Le programme d'installation vous demandera avec quel serveur Web configurer PHPMyAdmin pour travailler, puisque NGINX ne figure pas sur cette liste, appuyez simplement sur TAB et continuez.

Installation de PHPMyAdmin

Une fois l'installation terminée, pour que phpmyadmin fonctionne, vous devez créer un lien symbolique vers le répertoire avec lequel NGINX fonctionne par défaut.

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

Et on essaie d'aller sur https://domain/phpmyadmin/

PHPMyAdmin est en cours d'exécution. La connexion est protégée par un certificat, il n'y a aucune erreur. Poursuivre. Créons un administrateur de base de données MySQL (MariaDB).

#mysql

Et nous arrivons à la console de gestion MariaDB. Ensuite, nous exécutons les commandes une par une :

MariaDB > CRÉER UN UTILISATEUR "admin"@"localhost" IDENTIFIÉ PAR "mot de passe" ;
MariaDB > ACCORDEZ TOUS LES PRIVILÈGES SUR *.* À "admin"@"localhost" AVEC OPTION D'ACCORD ;
MariaDB > PRIVILÈGES FLUSH ;

Création d'un utilisateur MySQL

Tout va bien, la connexion est terminée. PHPMyAdmin est prêt à fonctionner.

Installation de PostfixAdmin

En principe, PostfixAdmin, comme PHPMyAdmin, n'a pas besoin d'être installé. Le serveur de messagerie fonctionnera correctement sans ces composants. Mais vous ne pourrez alors pas créer d'alias de messagerie. Si vous n'en avez pas besoin, vous pouvez ignorer ces sections en toute sécurité. Si vous avez encore besoin d'alias, vous avez deux options : acheter la version payante d'iReaAdmin ou installer PostfixAdmin. Bien sûr, vous pouvez le faire sans logiciel supplémentaire, en enregistrant manuellement les alias dans la base de données, mais cela n'est pas toujours pratique et ne convient pas à tout le monde. Je recommande d'utiliser PostfixAdmin ; nous allons maintenant examiner son installation et son intégration avec iRedMail. Commençons l'installation :

# apt installer postfixadmin

Nous acceptons et créons un mot de passe pour la base de données système du programme.

Installation de PostfixAdmin

Installation de PostfixAdmin

Nous créons un lien symbolique de la même manière que lors de l'installation de PHPMyAdmin.

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

Nous faisons de l'utilisateur au nom duquel le serveur Web est lancé le propriétaire de l'annuaire. Dans notre cas, NGINX est lancé en tant qu'utilisateur www-data.

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

Nous devons maintenant modifier le fichier de configuration de PostfixAdmin et ajouter des informations sur la base de données utilisée par iRedAdmin. Par défaut, cette base de données s'appelle vmail. Si vous allez sur PHPMyAdmin, vous pouvez le voir là-bas. Ainsi, pour que PostfixAdmin puisse apporter des modifications à la base de données, nous l'enregistrons dans la configuration de PostfixAdmin.

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

On retrouve les lignes :

$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["nom_base de données"] = $nom_base de données;

Et rappelons-le :

$CONF["database_type"] = "mysqli"; # Type de base de données
$CONF["database_host"] = "localhost"; # Hôte du serveur de base de données
$CONF["database_user"] = "admin"; # Connectez-vous avec les droits d'écriture sur la base de données vmail. Vous pouvez utiliser l'administrateur créé précédemment
$CONF["database_password"] = "mot de passe"; # Mot de passe pour l'utilisateur spécifié ci-dessus
$CONF["nom_base de données"] = "vmail"; # Nom de la base de données iRedMail

Saisir des informations sur la base de données

Si vous envisagez d'utiliser le client de messagerie Web SOGo, vous devez effectuer une étape supplémentaire supplémentaire, à savoir modifier le cryptage PostfixAdmin dans l'élément $CONF["encrypt"] de "md5crypt" à "dovecot:SHA512-CRYPT" . Si vous ne le faites pas, lorsque vous essayez de vous connecter à SOGo en tant qu'utilisateur créé dans PostfixAdmin, vous recevrez une erreur : identifiant ou mot de passe incorrect.

Modification du type de cryptage

Désormais, afin de terminer avec succès l'installation et de ne pas recevoir d'erreurs, vous devez exécuter une requête sur la base de données. Il est pratique de le faire via PHPMyAdmin. Sélectionnez la base de données vmail et accédez à l'onglet SQL. Dans la fenêtre, nous entrons :

Domaine DROP INDEX sur la boîte aux lettres ;
Domaine DROP INDEX sur l'alias ;
ALTER TABLE alias ADD COLUMN `goto` texte NOT NULL ;

Requête de base de données

Et cliquez sur « Suivant ». Maintenant que nous sommes tous prêts, nous pouvons accéder à l'interface Web de PostfixAdmin et terminer l'installation. Pour ce faire, vous devez taper dans votre navigateur : https://domain/postfixadmin/setup.php.

Les éléments suivants devraient apparaître :

Installation de PostfixAdmin

Si tout est fait conformément aux instructions, il ne devrait y avoir aucune erreur. S'il y en a, il faut les éliminer, sinon le système ne vous permettra pas de continuer. Définissez le mot de passe d'installation et cliquez sur "Générer le hachage du mot de passe". Le système générera un hachage de mot de passe, qui devra être inséré dans le paramètre $CONF["setup_password"].

Terminer l'installation de PostfixAdmin

Modification des paramètres du fichier de configuration

Entrez maintenant le mot de passe nouvellement créé et créez l'administrateur PostfixAdmin. Il est préférable de ne pas créer d'administrateur avec le login postmaster, car des problèmes de connexion au panneau d'administration iRedAdmin peuvent survenir.

Création d'un administrateur PostfixAdmin

Ça y est, l'administrateur a été créé. Vous pouvez vous connecter.

Attention, d'un point de vue sécurité, il est préférable de renommer ou de supprimer le fichier setup.php dans le répertoire postfixadmin.

Accédez à : https://domain/postfixadmin/ et saisissez les informations d'identification nouvellement créées. Dans PostfixAdmin, ainsi que dans iRedAdmin, la langue russe est disponible. Vous pouvez le sélectionner lors de l'autorisation.

Nous essayons de créer une boîte aux lettres utilisateur.

Activation/Désactivation des modules iRedMail

iRedAPD est responsable de la gestion des modules iRedMail. Il dispose d'un fichier de configuration dans lequel les modules de travail sont enregistrés. Si vous n'avez pas besoin d'un module particulier, vous pouvez le supprimer du fichier de configuration et il cessera de fonctionner. Nous faisons:

# nano /opt/iredapd/settings.py

Recherchez la ligne « plugins » et supprimez les composants dont vous n’avez pas besoin. Je vais supprimer le composant "greylisting". Bien sûr, il protège assez efficacement contre le spam, mais souvent les lettres nécessaires n'arrivent pas.

Greylist est une technologie de protection automatique contre le spam basée sur l'analyse du comportement du serveur de l'expéditeur du mail. Lorsque la « liste grise » est activée, le serveur refuse pour la première fois d'accepter une lettre provenant d'une adresse inconnue, signalant une erreur temporaire. Dans ce cas, le serveur expéditeur devra répéter l'envoi ultérieurement. Les programmes de spam ne le font généralement pas. Si la lettre est renvoyée, elle est ajoutée à la liste pendant 30 jours et l'échange de courrier a lieu une première fois. Décidez vous-même si vous souhaitez utiliser ce module ou non.

Activation/Désactivation des modules de messagerie

Après avoir apporté des modifications, vous devez redémarrer iRedAPD.

# redémarrage du service iredapd

Test du serveur de messagerie

Ceci termine la configuration du serveur de messagerie iRedMail. Vous pouvez passer à la dernière étape : les tests. Créons deux boîtes aux lettres. Pour en vérifier un via iRedAdmin, le second via PostfixAdmin et envoyer une lettre d'une boîte aux lettres à une autre et vice versa. Dans iRedAdmin, nous créerons une boîte aux lettres [email protected]. Dans PostfixAdmin - [email protected]

Créer un utilisateur dans iRedAdmin

Créer un utilisateur dans PostfixAdmin

Nous vérifions que les utilisateurs ont été créés.

Si vous faites attention à la colonne « À » dans la liste des boîtes aux lettres PostfixAdmin, vous remarquerez la différence entre les boîtes aux lettres créées dans iRedAdmin et PostfixAdmin. Les boîtes aux lettres créées dans iRedAdmin sont marquées comme « Transférer uniquement » et celles créées dans PostfixAdmin sont marquées comme « Boîte aux lettres ». Au début, je n’ai pas pu comprendre pendant longtemps pourquoi cela se produisait et quelle était la différence entre eux, et finalement j’ai remarqué une chose. Les boîtes aux lettres dans iRedAdmin sont créées sans alias et les boîtes aux lettres dans PostfixAdmin sont créées avec un alias pour elles-mêmes.

Et si ces alias sont supprimés, alors les boîtes aux lettres seront affichées comme celles créées dans iRedAdmin "Forward only".

Supprimer les alias

Les alias ont été supprimés. Vérification de PostfixAdmin.

Comme vous pouvez le constater, toutes les cases sont devenues « Forward only ». De la même manière, si vous vous créez un alias dans une boîte aux lettres créée dans iRedAdmin, elle deviendra « Mailbox ». En principe, cela n'affecte en rien les performances du courrier. La seule chose est que vous ne pourrez pas créer d'alias sur une boîte aux lettres créée dans PostfixAdmin. Au lieu de créer un alias, vous devrez en modifier un existant. En parlant d'alias, dans nouvelle version iRedMail doit apporter une modification à l'une des cartes Postfix qui gère les alias. Et si vous ne le faites pas, les alias créés ne fonctionneront pas. Pour ce faire, vous devez corriger les éléments suivants dans le fichier /etc/postfix/mysql/virtual_alias_maps.cf :

Nous faisons:

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

Et nous le réparons.

Configuration d'alias

Redémarrez Postfix :

# redémarrage du postfix du service

Après cela, tout devrait fonctionner.

Et donc, commençons à vérifier le courrier. Nous nous connecterons à la boîte aux lettres de l'utilisateur 1 via Roundcube et à la boîte aux lettres de l'utilisateur 2 via SOGo et enverrons une lettre de la boîte aux lettres de l'utilisateur 1 à l'utilisateur 2 et inversement.

Envoi d'un email avec Roundcube

Recevoir une lettre dans SOGo

Envoi d'un email à SOGo

Recevoir une lettre dans Roundcube

Tout fonctionne sans aucun problème. La livraison de la lettre prend de deux à cinq secondes. De la même manière, les lettres sont parfaitement livrées aux serveurs Yandex et mail.ru (testés).

Vérifions maintenant les alias. Créons une boîte aux lettres user3 et créons un alias de la boîte aux lettres user1 vers la boîte aux lettres user2. Et nous enverrons une lettre de la boîte aux lettres user3 à la boîte aux lettres user1. Dans ce cas, la lettre devrait arriver dans la boîte aux lettres de l'utilisateur 2.

Créer un alias

Envoi d'une lettre de la boîte aux lettres user3 à la boîte aux lettres user1

Recevoir une lettre sur la boîte aux lettres de l'utilisateur 2

Le travail des alias est également très bien.

Testons le fonctionnement du serveur de messagerie via local client de messagerie. Pour un exemple, considérons Mozilla Thunderbird. Créons deux autres utilisateurs : client1 et client2. Nous connecterons une boîte aux lettres via IMAP, l'autre via POP3 et enverrons une lettre d'une boîte aux lettres à l'autre.

Connexion IMAP

Connexion via POP3

Nous envoyons une lettre du Client 1 au Client 2.

Envoi depuis le client 1

Réception sur le client 2

Et dans l'ordre inverse.

Envoi depuis le client 2

Réception sur Client 1

Tout fonctionne.

Si vous allez à l'adresse : https://domain/netdata, vous pouvez voir des graphiques de l'état du système.

Conclusion

Ceci termine l'installation, la configuration et les tests du système de messagerie iRedMail. En conséquence, nous avons reçu un serveur de messagerie entièrement gratuit et à part entière avec un certificat SSL valide, deux clients de messagerie Web différents, deux panneaux de contrôle, ainsi qu'un antispam et un antivirus intégrés au courrier. Si vous le souhaitez, au lieu des clients de messagerie Web, vous pouvez utiliser des clients de messagerie locaux tels que Microsoft Outlook ou Mozilla Thunderbird. Si vous ne prévoyez pas d'utiliser des clients de messagerie Web, vous ne pouvez pas les installer du tout, afin de ne pas surcharger le serveur, ni installer quelque chose que vous préférez. Personnellement, j'aime mieux SOGo car son interface est optimisée pour appareils mobiles, ce qui rend la visualisation très pratique e-mail depuis un smartphone. Il en va de même pour NetData et iRedAdmin, si vous ne prévoyez pas de l'utiliser, il vaut mieux ne pas l'installer. Ce système de messagerie est peu gourmand en ressources. Tout cela fonctionne sur un serveur VPS de 1024 Mo mémoire vive et un processeur virtuel. Si vous avez des questions sur ce système de messagerie, écrivez dans les commentaires.

P.S. Lors du test de ce produit sur différents systèmes d'exploitation avec 1 Go de RAM (Ubuntu, Debian, CentOS), il s'est avéré que 1 Go n'est pas suffisant pour que ClamAV fonctionne. Dans presque tous les cas, lors de l'utilisation de 1 Go de mémoire, l'antivirus a cité une erreur liée à la base de données. Dans le même temps, sur les systèmes d'exploitation Debian et Ubuntu, l'antivirus n'analysait tout simplement pas le courrier transitant par le serveur, sinon tout fonctionnait bien. Sur CentOS, la situation était légèrement différente. Le service clamd a complètement fait planter le système, rendant ainsi impossible le fonctionnement normal du serveur. Lors de la tentative de connexion aux interfaces Web, NGINX produisait périodiquement des erreurs 502 et 504. Le courrier était également envoyé une fois sur deux. De plus, si l'on ajoute jusqu'à 2 Go de RAM, dans tous les cas, il n'y a eu aucun problème avec le fonctionnement de l'antivirus et du serveur dans son ensemble. ClamAV a analysé le courrier transitant par le serveur de messagerie, dont il a parlé dans les journaux. Lors de la tentative d'envoi d'un virus en pièce jointe, la livraison était bloquée. La consommation de mémoire était d'environ 1,2 à 1,7 Go.

Nginx est un petit serveur Web et un serveur proxy de messagerie très rapide et assez fonctionnel, développé par Igor Sysoev (rambler.ru). En raison de la très faible consommation de ressources système et de la vitesse de fonctionnement, ainsi que de la flexibilité de configuration, le Web Serveur Nginx souvent utilisé comme interface pour des serveurs plus lourds, tels que Apache, dans des projets à forte charge. L'option classique est la combinaison Nginx - Apache - FastCGI. Travailler dans un tel schéma, Serveur Nginx, accepte toutes les demandes provenant via HTTP et, en fonction de la configuration et de la demande elle-même, décide s'il faut traiter la demande elle-même et donner au client une réponse prête ou envoyer la demande pour traitement à l'un des backends ( Apache ou RapideCGI).

Comme vous le savez, le serveur Apache traite chaque requête dans un processus distinct (thread), qui, il faut le dire, consomme une assez petite quantité de ressources système, s'il y a 10 à 20 processus de ce type, cela n'a aucun sens, et s'il y en a 100-500 ou plus, le système ne devient plus amusant.

Essayons d'imaginer une situation similaire. Supposons que Apache vient 300 Requêtes HTTP Parmi les clients, 150 clients utilisent des lignes louées rapides et les 150 autres utilisent des canaux Internet relativement lents, même s'ils ne sont pas connectés à des modems. Que se passe-t-il dans cette situation ? Et ce qui suit se produit : le serveur web Apache, pour traiter ces 300 connexions, crée un processus (thread) pour chacune, il générera du contenu rapidement, et 150 clients rapides prendront immédiatement le résultat de leurs requêtes, les processus les servant seront tués et les ressources seront libérées, et 150 sont lents et recevront les résultats de leurs demandes lentement, en raison du canal Internet étroit, ce qui entraînera le blocage de 150 processus dans le système Apache, attendant que les clients récupèrent le contenu généré par le serveur Web, dévorant beaucoup de ressources système. Bien entendu, la situation est hypothétique, mais je pense que l’essentiel est clair. Le bundle permet de corriger la situation décrite ci-dessus. Après avoir lu l'intégralité de la demande du client, il la soumet pour traitement Apache, qui à son tour génère du contenu et renvoie la réponse prête à Nginx le plus rapidement possible, après quoi il peut arrêter le processus en toute conscience et libérer les ressources système qu'il occupe. Serveur Web Nginx, recevant le résultat de la requête de Apache, l'écrit dans un tampon ou même dans un fichier sur le disque et peut le laisser ralentir les clients aussi longtemps qu'il le souhaite, tandis que ses processus de travail consomment si peu de ressources que .. "c'est même drôle d'en parler" ©. :) Ce schéma économise considérablement les ressources système, je le répète, mais les processus de travail Nginx consomment une infime quantité de ressources, cela est particulièrement vrai pour les grands projets.

Et ce n'est qu'une petite partie de ce que le serveur Nginx peut faire ; n'oubliez pas les capacités de mise en cache des données et de travail avec memcaché. Je vais donner une liste des principaux Fonctionnalité Serveur Web Nginx.

Fonctionnalité du serveur Nginx en tant que serveur HTTP

• Traitement contenu statique, fichiers d'index, listes de répertoires, cache de descripteur de fichier ouvert ;
• Proxy accéléré avec mise en cache, répartition de la charge et tolérance aux pannes ;
• Assistance accélérée RapideCGI serveurs avec mise en cache, répartition de la charge et tolérance aux pannes ;
• Structure modulaire, prise en charge de divers filtres (SSI, XSLT, GZIP, reprise, réponses fragmentées) ;
• Prise en charge des extensions SSL et TLS SNI ;
• Basé sur IP ou Basé sur le nom Serveurs virtuels;
• Travailler avec KeepAlive et les connexions pipeline ;
• Possibilité de configurer les éventuels timeouts ainsi que le nombre et la taille des buffers, au niveau Serveur Apache;
• Effectuer diverses actions selon l’adresse du client ;
• Modification des URI à l'aide d'expressions régulières ;
• Pages d'erreur spéciales pour 4xx et 5xx ;
• Restreindre l'accès en fonction de l'adresse ou du mot de passe du client ;
• Configuration des formats de fichiers journaux, rotation des journaux ;
• Limiter la rapidité de réponse au client ;
• Limiter le nombre de connexions et de requêtes simultanées ;
• Prend en charge les méthodes PUT, DELETE, MKCOL, COPY et MOVE ;
• Modification des paramètres et mise à jour du serveur sans arrêter le travail ;
• Intégré Perl;

Fonctionnalité du serveur Nginx en tant que serveur proxy de messagerie

• Transfert vers le backend IMAP/POP3 à l'aide d'un serveur d'authentification HTTP externe ;
• Vérification du SMTP de l'utilisateur sur un périphérique externe serveur HTTP authentification et transfert vers un serveur SMTP interne ;
• Prend en charge les méthodes d'authentification suivantes :
  • POP3 - UTILISATEUR/PASS, APOP, CONNEXION AUTH/PLAIN/CRAM-MD5 ;
  • IMAP - CONNEXION, CONNEXION AUTH/PLAIN/CRAM-MD5 ;
  • SMTP - AUTH LOGI/PLAIN/CRAM-MD5 ;
• Prise en charge SSL ;
• Prise en charge de STARTTLS et STLS ;

Systèmes d'exploitation et plates-formes pris en charge par le serveur Web Nginx

• FreeBSD, de 3 à 8 - plateformes, i386 et amd64 ;
• Linux, de 2.2 à 2.6 - plateforme i386 ; Linux 2.6-amd64 ;
• Plateformes Solaris 9 - i386 et sun4u ; Solaris 10 - plates-formes i386, amd64 et sun4v ;
• Plateformes MacOS X ppc, i386 ;
• Windows XP, Serveur Windows 2003 ; (actuellement en version bêta)

Architecture et évolutivité du serveur Nginx

• Le processus principal (maître), plusieurs processus de travail (configurés dans le fichier de configuration) exécutés sous un utilisateur non privilégié ;
• Prise en charge des méthodes de traitement de connexion suivantes :
  • select est une méthode standard. Le module Nginx correspondant est construit automatiquement si aucune méthode plus efficace n'est trouvée sur une plateforme donnée. Vous pouvez forcer l'activation ou la désactivation de la construction d'un module donné à l'aide des options de configuration --with-select_module ou --without-select_module.
  • le sondage est la méthode standard. Le module Nginx correspondant est construit automatiquement si aucune méthode plus efficace n'est trouvée sur une plateforme donnée. Vous pouvez forcer l'activation ou la désactivation de la construction d'un module donné à l'aide des options de configuration --with-poll_module ou --without-poll_module.
  • kqueue - méthode efficace, utilisé sur les systèmes d'exploitation FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 et MacOS X. Lorsqu'il est utilisé sur des machines à double processeur exécutant MacOS X, il peut provoquer une panique du noyau.
  • epoll est une méthode efficace utilisée sous Linux 2.6+. Certaines distributions, comme SuSE 8.2, disposent de correctifs pour prendre en charge epoll dans le noyau 2.4.
  • rtsig - signaux en temps réel, une méthode efficace utilisée sous Linux 2.2.19+. Par défaut, il ne peut pas y avoir plus de 1 024 signaux dans la file d’attente pour l’ensemble du système. Cela n'est pas suffisant pour les serveurs à forte charge ; la taille de la file d'attente doit être augmentée à l'aide du paramètre de noyau /proc/sys/kernel/rtsig-max. Cependant, depuis Linux 2.6.6-mm2, cette option n'est plus disponible, mais chaque processus dispose d'une file d'attente de signaux distincte, dont la taille est déterminée à l'aide de RLIMIT_SIGPENDING.
  • Quand la file d'attente est pleine, serveur nginx le réinitialise et traite les connexions à l'aide de la méthode d'interrogation jusqu'à ce que la situation revienne à la normale.
  • /dev/poll est une méthode efficace, prise en charge sur les systèmes d'exploitation Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ et Tru64 UNIX 5.1A+.
  • eventport - ports d'événements, une méthode efficace utilisée dans Solaris 10. Avant de l'utiliser, vous devez installer un correctif pour éviter la panique du noyau.
• Utilisation des capacités de la méthode kqueue telles que EV_CLEAR, EV_DISABLE (pour désactiver temporairement un événement), NOTE_LOWAT, EV_EOF, nombre de données disponibles, codes d'erreur ;
• Fonctionne avec sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) et sendfilev (Solaris 8 7/01+) ;
• Prise en charge des filtres d'acceptation (FreeBSD 4.1+) et TCP_DEFER_ACCEPT (Linux 2.4+) ;
• 10 000 connexions HTTP persistantes inactives consomment environ 2,5 M de mémoire ;
• Nombre minimum d'opérations de copie de données ;

NGINX peut être utilisé non seulement comme serveur Web ou proxy http, mais également pour transmettre du courrier via les protocoles SMTP, IMAP, POP3. Cela vous permettra de configurer :

• Un point d'entrée unique pour un système de messagerie évolutif.
• Équilibrage de charge entre tous les serveurs de messagerie.

Dans cet article, l’installation est réalisée en salle d’opération. Système Linux. En tant que service de messagerie auquel les demandes sont envoyées, vous pouvez utiliser postfix, exim, dovecot, Exchange, iredmail assembly et bien plus encore.

Principe d'opération

NGINX accepte les demandes et s'authentifie auprès du serveur Web. En fonction du résultat de la vérification du login et du mot de passe, le proxy renverra une réponse avec plusieurs en-têtes.

En cas de succès :

Ainsi, nous déterminons le serveur et le port du serveur de messagerie en fonction de l'authentification. Cela offre de nombreuses opportunités avec une connaissance appropriée des langages de programmation.

En cas de défaillance:

En fonction du résultat de l'authentification et de l'en-tête, le client est redirigé vers le serveur de messagerie dont nous avons besoin.

Préparation du serveur

Apportons quelques modifications aux paramètres de sécurité du serveur.

SELinux

Désactivez SELinux si nous utilisons CentOS ou si nous utilisons ce système sécurité sur Ubuntu :

vi /etc/selinux/config

SELINUX=désactivé

Pare-feu

Si nous utilisons firewalld (par défaut sur CentOS) :

pare-feu-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

pare-feu-cmd --reload

Si nous utilisons iptables (par défaut dans Ubuntu) :

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

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

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

apt-get installe iptables-persistant

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

* dans cet exemple, nous avons autorisé SMTP (25), POP3 (110), IMAP (143).

Installation de NGINX

En fonction de la système opérateur L'installation de NGINX est un peu différente.

ou Linux Centos :

miam, installe nginx

ou Linux Ubuntu :

apte à installer nginx

Nous autorisons le démarrage automatique du service et le démarrons :

systemctl activer nginx

systemctl démarrer nginx

Si NGINX est déjà installé sur le système, vérifiez avec quels modules il fonctionne :

Nous recevrons une liste d'options avec lesquelles le serveur Web est construit - parmi elles, nous devrions voir --with-mail . Si le module requis n'est pas là, vous devez mettre à jour nginx

Configuration de NGINX

Ouvrez le fichier de configuration nginx et ajoutez l'option mail :

vi /etc/nginx/nginx.conf

mail (

auth_http localhost:80/auth.php;

Serveur (
écoutez 25 ;
protocole smtp ;
smtp_auth connexion simple cram-md5 ;
}

Serveur (
écoutez 110 ;
protocole pop3 ;

}

Serveur (
écoutez 143 ;
image du protocole ;
}
}

* Où:

• nom_serveur est le nom du serveur de messagerie qui sera affiché dans le message d'accueil SMTP.
• auth_http - serveur Web et URL pour la demande d'authentification.
• proxy_pass_error_message - autorise ou refuse l'affichage d'un message lorsque l'authentification échoue.
• écouter - port sur lequel les requêtes sont écoutées.
• protocole - le protocole d'application pour lequel le port correspondant écoute.
• smtp_auth - méthodes d'authentification disponibles pour SMTP.
• pop3_auth - méthodes d'authentification disponibles pour POP3.

Dans la section http - serveur, ajoutez :

Serveur (
écoutez 80 default_server;
écoutez [::]:80 default_server;
...

Emplacement ~ \.php$ (
définir $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;
inclure fastcgi_params ;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Redémarrez le serveur nginx :

systemctl redémarrer nginx

Installer et configurer PHP

Pour effectuer l'authentification à l'aide de PHP, vous devez installer les packages suivants sur votre système.

Si CentOS :

miam, installez php php-fpm

Si Ubuntu :

apt-get installer php php-fpm

Lancez PHP-FPM :

systemctl active php-fpm

systemctl démarre php-fpm

Authentification

La vérification de l'identifiant et du mot de passe est effectuée par un script dont le chemin d'accès est spécifié par l'option auth_http. Dans notre exemple, il s'agit d'un script PHP.

Un exemple de modèle officiel pour un script de vérification de login et de mot de passe :

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

* ce script accepte n'importe quel identifiant et mot de passe et redirige les demandes vers les serveurs 192.168.1.22 et 192.168.1.33. Pour définir l'algorithme d'authentification, éditez les lignes 61 à 64. Les lignes 73 à 77 sont chargées de renvoyer les serveurs vers lesquels la redirection est effectuée - dans cet exemple, si la connexion commence par les caractères « a », « c », « f », « g », alors la redirection se fera vers le serveur mailhost01, sinon, vers mailhost02. Le mappage des noms de serveur aux adresses IP peut être défini sur les lignes 31, 32, sinon l'appel sera effectué en utilisant le nom de domaine.

Mise en place d'un serveur de messagerie

L'échange de données entre le proxy NGINX et le serveur de messagerie s'effectue dans formulaire ouvert. Il faut ajouter à l'exception la possibilité d'une authentification par le mécanisme PLAIN. Par exemple, pour configurer Dovecot, procédez comme suit :

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

Ajoutez les lignes :

à distance 192.168.1.11 (
désactiver_plaintext_auth = non
}

* dans cet exemple, nous avons autorisé les demandes d'authentification PLAIN du serveur 192.168.1.11.

Nous vérifions également :

* si ssl est défini sur requis , la vérification ne fonctionnera pas, car il s'avère que d'une part le serveur autorise les requêtes en texte clair, mais nécessite un cryptage SSL.

Redémarrez le service Dovecot :

systemctl redémarrer Dovecot

Configuration du client

Vous pouvez procéder à la vérification de nos paramètres de proxy. Pour ce faire, dans les paramètres du client, précisez l'adresse ou le nom du serveur nginx comme IMAP/POP2/SMTP, par exemple :

* dans cet exemple, le client de messagerie est configuré pour se connecter au serveur 192.168.1.11 via ports ouverts 143 (IMAP) et 25 (SMTP).

Chiffrement

Établissons maintenant une connexion SSL. Nginx doit être construit avec le module mail_ssl_module - vérifiez avec la commande :

Si le module requis est manquant, nous reconstruisons nginx.

Ensuite nous éditons notre fichier de configuration :

vi /etc/nginx/nginx.conf

mail (
nom_serveur mail.domaine.local ;
auth_http localhost/auth.php;

Proxy_pass_error_message activé ;

SSL activé ;
certificat_ssl /etc/ssl/nginx/public.crt ;
ssl_certificate_key /etc/ssl/nginx/private.key ;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache partagé : SSL : 10 min ;
ssl_session_timeout 10 min ;

Serveur (
écoutez 110 ;
protocole pop3 ;
pop3_auth simple apop cram-md5 ;
}

Serveur (
écoutez 143 ;
image du protocole ;
}

Raison : Le système de sécurité SELinux est déclenché.

Solution : désactivez ou configurez SELinux.

Nginx gagne rapidement en popularité, passant d'un simple accélérateur de livraison statique pour Apache à un serveur Web entièrement fonctionnel et développé, de plus en plus utilisé de manière isolée. Dans cet article, nous parlerons de scénarios intéressants et non standards d'utilisation de nginx qui vous permettront de tirer le meilleur parti de votre serveur Web.

Mandataire de messagerie

Commençons par le plus évident : avec la capacité de nginx à agir comme un proxy de messagerie. Cette fonction est initialement présente dans nginx, mais pour une raison quelconque, elle est extrêmement rarement utilisée en production ; certaines personnes ne connaissent même pas son existence. Quoi qu'il en soit, nginx prend en charge le proxy des protocoles POP3, IMAP et SMTP avec diverses méthodes d'authentification, notamment SSL et StartTLS, et le fait très rapidement.

Pourquoi est-ce nécessaire ? Il existe au moins deux utilisations pour cette fonctionnalité. Premièrement : utilisez nginx comme bouclier contre les spammeurs ennuyeux qui tentent d'envoyer des courriers indésirables via notre serveur SMTP. En règle générale, les spammeurs ne créent pas beaucoup de problèmes, car ils sont rapidement rejetés au stade de l'authentification. Cependant, lorsqu'ils sont vraiment nombreux, nginx permettra d'économiser les ressources du processeur. Deuxièmement : utilisez nginx pour rediriger les utilisateurs vers plusieurs serveurs de messagerie POP3/IMAP. Bien sûr, un autre proxy de messagerie pourrait gérer cela, mais pourquoi clôturer les serveurs si nginx est déjà installé sur le front-end pour servir du contenu statique via HTTP, par exemple ?

Le serveur proxy de messagerie dans nginx n'est pas tout à fait standard. Il utilise une couche d'authentification supplémentaire mise en œuvre via HTTP, et ce n'est que si l'utilisateur franchit cette barrière qu'il est autorisé à continuer. Cette fonctionnalité est fournie en créant une page/un script auquel nginx envoie les données de l'utilisateur, et celui-ci renvoie une réponse sous la forme d'un OK standard ou d'un motif de refus (tel que « Identifiant ou mot de passe invalide »). Le script s'exécute avec les en-têtes suivants :

Données d'entrée du script d'authentification HTTP_AUTH_USER : utilisateur HTTP_AUTH_PASS : mot de passe HTTP_AUTH_PROTOCOL : protocole de messagerie (IMAP, POP3 ou SMTP)

Et il renvoie ce qui suit :

Sortie du script d'authentification HTTP_AUTH_STATUS : OK ou raison de l'échec HTTP_AUTH_SERVER : serveur de messagerie réel à rediriger HTTP_AUTH_PORT : port du serveur

Une caractéristique remarquable de cette approche est qu'elle peut être utilisée non pas pour l'authentification elle-même, mais pour disperser les utilisateurs sur différents serveurs internes, en fonction du nom d'utilisateur, des données sur la charge actuelle sur les serveurs de messagerie, ou même en organisant un simple équilibrage de charge. en utilisant le round-robin. Cependant, si vous avez simplement besoin de transférer des utilisateurs vers un serveur de messagerie interne, vous pouvez utiliser un stub implémenté par nginx lui-même au lieu d'un véritable script. Par exemple, le proxy SMTP et IMAP le plus simple dans la configuration nginx ressemblera à ceci :

# vi /etc/nginx/nginx.conf mail ( # Adresse du script d'authentification auth_http localhost:8080/auth ; # Désactivez la commande XCLIENT, certains serveurs de messagerie ne la comprennent pas xclient off ; # Serveur serveur IMAP ( écoute 143 ; protocole imap ; proxy activé; ) # Serveur serveur SMTP (écouter 25; protocole smtp; proxy activé; ) )

# vi /etc/nginx/nginx.conf http ( # Mappage vers le port du serveur de messagerie souhaité en fonction du port envoyé dans le map d'en-tête HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport ( par défaut 25; smtp 25; imap 143; ) # Implémentation de l'authentification "script" - renvoie toujours OK et transfère l'utilisateur vers le serveur de messagerie interne, en définissant le port souhaité à l'aide du serveur de mappage ci-dessus (écouter 8080; emplacement /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Auth-Port" $mailport ; renvoie 200 ; ) ) )

C'est tout. Cette configuration permet de rediriger de manière transparente les utilisateurs vers le serveur de messagerie interne, sans créer de surcharge sous forme de script inutile dans ce cas. À l'aide d'un script, cette configuration peut être considérablement étendue : configurez l'équilibrage de charge, vérifiez les utilisateurs à l'aide de la base de données LDAP et effectuez d'autres opérations. L'écriture du script dépasse le cadre de cet article, mais il est très facile à mettre en œuvre même avec seulement une connaissance passagère de PHP et Python.

Streaming vidéo

Il est facile de configurer un hébergement vidéo régulier basé sur nginx. Il suffit de télécharger la vidéo transcodée dans un répertoire accessible au serveur, de l'enregistrer dans la config et de configurer le lecteur Flash ou HTML5 pour qu'il récupère la vidéo de ce répertoire. Toutefois, si vous devez configurer une diffusion vidéo continue à partir de certains source externe ou une webcam, ce schéma ne fonctionnera pas et vous devrez vous tourner vers des protocoles de streaming spéciaux.

Il existe plusieurs protocoles qui résolvent ce problème, le plus efficace et le plus pris en charge est RTMP. Le seul problème est que presque toutes les implémentations de serveurs RTMP souffrent de problèmes. Le serveur Adobe Flash Media officiel est payant. Red5 et Wowza sont écrits en Java et ne fournissent donc pas performances requises, Une autre implémentation, Erlyvideo, est écrite en Erlang, ce qui est bon pour une configuration en cluster, mais pas aussi efficace pour un seul serveur.

Je suggère une approche différente : utilisez le module RTMP pour nginx. Il offre d’excellentes performances et vous permettra également d’utiliser un seul serveur pour servir à la fois l’interface Web du site et le flux vidéo. Le seul problème est que ce module n'est pas officiel, vous devrez donc construire vous-même nginx avec son support. Heureusement, le montage s'effectue de manière standard:

$ sudo apt-get supprimer nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ décompresser 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

Le module doit maintenant être configuré. Cela se fait, comme d'habitude, via la configuration nginx :

Rtmp ( # Activer le serveur de diffusion sur le port 1935 à l'adresse site/serveur rtmp ( écouter 1935; application rtmp ( live on; ) ) )

Le module RTMP ne peut pas fonctionner dans une configuration multithread, le nombre de processus de travail nginx devra donc être réduit à un (je vous expliquerai plus tard comment contourner ce problème) :

Processus_travailleur 1 ;

Vous pouvez maintenant enregistrer le fichier et forcer nginx à relire la configuration. La configuration de nginx est terminée, mais nous n'avons pas encore le flux vidéo lui-même, nous devons donc l'obtenir quelque part. Par exemple, supposons qu'il s'agisse du fichier video.avi du répertoire actuel. Pour le transformer en flux et l’envelopper dans notre diffuseur RTMP, nous utiliserons le bon vieux FFmpeg :

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

Si le fichier vidéo n'est pas au format H264, il doit être réencodé. Cela peut être fait à la volée en utilisant le même FFmpeg :

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

Le flux peut également être capturé directement depuis une webcam :

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

Pour visualiser le flux côté client, vous pouvez utiliser n'importe quel lecteur prenant en charge RTMP, par exemple mplayer :

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

Ou intégrez le lecteur directement dans une page Web, qui est servie par le même nginx (exemple tiré de la documentation officielle) :

Le lecteur Web RTMP le plus simple

jwplayer("container").setup(( modes : [( type : "flash", src: "/jwplayer/player.swf", config: ( longueur du tampon : 1, fichier : "stream", streamer : "rtmp:/ /localhost/rtmp", fournisseur : "rtmp", ) )] ));

Il n'y a ici que deux lignes importantes : « file : « stream » », indiquant le flux RTMP, et « streamer : « rtmp://localhost/rtmp » », qui indique l'adresse du streamer RTMP. Pour la plupart des tâches, ces paramètres seront tout à fait suffisants. Vous pouvez envoyer plusieurs flux différents à une seule adresse, et nginx les multiplexera efficacement entre les clients. Mais ce n'est pas tout ce dont le module RTMP est capable. Avec son aide, vous pouvez par exemple organiser le relais d'un flux vidéo provenant d'un autre serveur. Le serveur FFmpeg n'est pas du tout nécessaire pour cela, ajoutez simplement les lignes suivantes à la configuration :

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

Si vous devez créer plusieurs flux de qualité différente, vous pouvez appeler le transcodeur FFmpeg directement depuis nginx :

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

Avec cette configuration, nous obtiendrons deux diffuseurs à la fois, dont l'un sera disponible à l'adresse rtmp://site/rtmp, et le second, diffusant en qualité 320 x 240, à l'adresse rtmp://site/rtmp –320x240. Ensuite, vous pouvez ajouter un lecteur Flash et des boutons de sélection de qualité au site, qui donneront au joueur l'une ou l'autre adresse de diffuseur.

Et enfin, un exemple de diffusion de musique sur le réseau :

Bien que vrai ; faire 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; fait

Proxy Git

Le système de contrôle de version Git est capable de fournir un accès aux référentiels non seulement via les protocoles Git et SSH, mais également via HTTP. Il était une fois la mise en œuvre de l'accès HTTP était primitive et incapable de fournir un travail à part entière avec le référentiel. Avec la version 1.6.6, la donne a changé, et aujourd'hui ce protocole peut être utilisé pour, par exemple, contourner les restrictions du pare-feu des deux côtés de la connexion ou pour créer votre propre hébergement Git avec une interface web.

Malheureusement, la documentation officielle ne parle que de l'organisation de l'accès à Git à l'aide du serveur Web Apache, mais comme l'implémentation elle-même est application externe avec une interface CGI standard, il peut être connecté à presque n'importe quel autre serveur, y compris lighttpd et, bien sûr, nginx. Cela ne nécessite rien d'autre que le serveur lui-même, Git installé et un petit serveur FastCGI fcgiwrap, ce qui est nécessaire car nginx ne sait pas travailler directement avec CGI, mais peut appeler des scripts en utilisant le protocole FastCGI.

L'ensemble du plan de travail ressemblera à ceci. Le serveur fcgiwrap se bloquera en arrière-plan et attendra une demande pour exécuter l'application CGI. Nginx, à son tour, sera configuré pour demander l'exécution du binaire CGI git-http-backend via l'interface FastCGI à chaque accès à l'adresse que nous spécifions. Dès réception de la requête, fcgiwrap exécute git-http-backend avec les arguments CGI spécifiés transmis par le client GIT et renvoie le résultat.

Pour implémenter un tel schéma, installez d'abord fcgiwrap :

$ sudo apt-get install fcgiwrap

Il n'est pas nécessaire de le configurer, tous les paramètres sont transmis via le protocole FastCGI. Il se lancera également automatiquement. Il ne reste donc plus qu'à configurer nginx. Pour ce faire, créez un fichier /etc/nginx/sites-enabled/git (s'il n'existe pas de tel répertoire, vous pouvez écrire dans la configuration principale) et écrivez-y ce qui suit :

# vi /etc/nginx/sites-enabled/git server ( # Nous sommes suspendus au port 8080, écoutez 8080 ; # L'adresse de notre serveur (n'oubliez pas d'ajouter une entrée dans DNS) nom_serveur git.example.ru ; # Logs access_log /var/log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Adresse principale pour l'emplacement d'accès anonyme / ( # Lors de la tentative de téléchargement, envoyer l'utilisateur à une adresse privée if ($ arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) include /etc/nginx/fastcgi_params; # Adresse de notre git-http-backend fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # Adresse du référentiel Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Adresse du fichier fastcgi_param PATH_INFO $uri; # Adresse du serveur fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Adresse d'accès en écriture location ~/private(/.* )$ ( # Autorisations utilisateur auth_basic "git anonyme en lecture seule, écriture authentifiée"; # Authentification HTTP basée sur htpasswd auth_basic_user_file /etc/nginx/htpasswd; # Les paramètres FastCGI incluent /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 ; ) )

Cette configuration suppose trois choses importantes :

L'adresse du référentiel sera /srv/git, nous définissons donc les droits d'accès appropriés : $ sudo chown -R www-data:www-data /srv/git

Le référentiel lui-même doit être ouvert à la lecture par des utilisateurs anonymes et permettre le téléchargement via HTTP : $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true

L'authentification s'effectue à l'aide du fichier htpasswd, vous devez le créer et y ajouter des utilisateurs : $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

C'est tout, redémarrez nginx :

Microcache

Imaginons une situation avec un site Web dynamique et fréquemment mis à jour qui commence soudainement à recevoir des charges très lourdes (enfin, il s'est retrouvé sur la page de l'un des plus grands sites d'information) et cesse de faire face au retour du contenu. Une optimisation et une mise en œuvre appropriées du système de mise en cache approprié prendront beaucoup de temps et les problèmes doivent être résolus dès maintenant. Ce que nous pouvons faire?

Il existe plusieurs façons de sortir de cette situation avec le moins de pertes, mais l'idée la plus intéressante a été proposée par Fenn Bailey (fennb.com). L'idée est simplement de placer nginx devant le serveur et de le forcer à mettre en cache tout le contenu transmis, mais pas seulement en cache, mais pendant une seconde seulement. Le problème ici est que des centaines et des milliers de visiteurs du site par seconde généreront en fait une seule requête au backend, recevant une page principalement en cache. En même temps, presque personne ne remarquera la différence, car même sur un site dynamique, une seconde ne signifie généralement rien.

La configuration avec la mise en œuvre de cette idée n'aura pas l'air si compliquée :

# vi /etc/nginx/sites-enabled/cache-proxy # Configuration du cache proxy_cache_path /var/cache/nginxlevels=1:2 keys_zone=microcache:5m max_size=1000m; serveur ( écoute 80; nom_serveur exemple.com; # Emplacement de l'adresse mise en cache / ( # Le cache est activé par défaut, set $no_cache ""; # Désactive le cache pour toutes les méthodes sauf GET et HEAD if ($request_method !~ ^(GET|HEAD) $) ( set $no_cache "1"; ) # Si le client télécharge du contenu sur le site (no_cache = 1), on s'assure que les données qui lui sont données ne sont pas mises en cache pendant deux secondes et qu'il peut voir le résultat du téléchargement 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 "; ) # Activer/désactiver le cache en fonction de l'état de la variable no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Requêtes proxy au serveur réel proxy_pass http://appserver.example.ru; proxy_cache microcache ; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Protection contre le problème du troupeau Thundering proxy_cache_use_stale mise à jour; # Ajouter des en-têtes standard proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Nous ne mettons pas en cache les fichiers de plus de 1 Mo proxy_max_temp_file_size 1M ; ) )

Une place particulière dans cette configuration est occupée par la ligne « proxy_cache_use_stale update ; », sans laquelle nous aurions reçu des rafales de charge périodiques sur le serveur backend en raison des requêtes reçues lors de la mise à jour du cache. Sinon, tout est standard et doit être clair sans explication inutile.

Rapprocher les proxys du public cible

Malgré l'augmentation généralisée des vitesses d'Internet à l'échelle mondiale, la distance physique entre le serveur et le public cible continue de jouer un rôle. Cela signifie que si un site russe fonctionne sur un serveur situé quelque part en Amérique, la vitesse d'accès à celui-ci sera a priori plus lente que depuis un serveur russe avec la même largeur de canal (bien sûr, si vous fermez les yeux sur tous les autres facteurs ). Autre chose, placer des serveurs à l'étranger est souvent plus rentable, y compris en termes de maintenance. Par conséquent, pour obtenir des bénéfices, sous la forme de taux de paiement plus élevés, vous devrez utiliser quelques astuces.

Une des options possibles : placer le serveur productif principal en Occident, et déployer un frontend peu gourmand en ressources et produisant des données statiques en Russie. Cela vous permettra de gagner en vitesse sans frais importants. La configuration nginx pour le frontend dans ce cas sera une implémentation de proxy simple et familière pour nous tous :

# vi /etc/nginx/sites-enabled/proxy # Stockez le cache pendant 30 jours dans 100 Go de stockage proxy_cache_path /var/cache/nginxlevels=1:2 keys_zone=static:32m inactive=30d max_size=100g; serveur (écouter 80; nom_serveur exemple.com; # En fait, notre emplacement proxy ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Adresse backend 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_for; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_cache static; proxy_cache_valid 30d ; proxy_ignore_headers "Cache-Control" "Expire" ; proxy_cache_key "$uri$is_args$args" ; proxy_cache_lock on ; ) )

conclusions

Aujourd'hui, avec l'aide de nginx, vous pouvez résoudre de nombreux problèmes différents, dont beaucoup ne sont pas du tout liés au serveur Web ni au protocole HTTP. Le proxy de messagerie, le serveur de streaming et l'interface Git ne sont que quelques-unes de ces tâches.