Affichage des résultats pour « Web Assistant ».

Bonjour, Objectif de ce tutoriel : Pouvoir gérer de façon centralisée votre propre messagerie électronique sur votre NAS Synology lorsque vous disposez d’une adresse IP externe dite « dynamique » chez un Fournisseur d’Accès Internet (FAI) tel que ORANGE. L’idée est donc de vous permettre de créer votre propre messagerie électronique sur la base de votre propre domaine « votredomaine.tld » afin que vous puissiez recevoir et envoyer des eMAILs vers tous les fournisseurs tels que GMAIL et autres sans que ces eMAILs ne puissent être déclarés comme du SPAM (courrier indésirable non sollicité). En clair être autonome de ce point de vue ! Pour cela (et surtout pour faire simple) nous allons utiliser un outil à notre disposition sur nos NAS Synology qui n’est autre que le package Synology « MailPus Server » (« MPS »). Avec ce package notre NAS devient alors un système de messagerie prenant en charge les protocoles « SMTP », « POP3 » et « IMAP ». Les comptes d'utilisateurs et les eMails y sont également gérés et archivés de manière centralisée ce qui répond déjà à une partie de l’objectif fixé. En outre, associé à ce serveur, le package « MailPlus » va fournir aux utilisateurs du NAS, un client de messagerie basé sur un navigateur facile à utiliser pour afficher, gérer et envoyer leurs messages. Alors pourquoi s’en priver ? Autant aussi être d’entrée très clair, vous constaterez que ce tutoriel présente beaucoup de similitudes avec l’excellent tutoriel « [TUTO] Serveur MailPlus DSM6 » proposé par @unPixel sur le présent forum. Ceci est normal : on va utiliser le même outil logiciel (à la version près, celle décrite ici est la dernière à la date de rédaction du présent tutoriel), c’est juste que le tutoriel de @unPixel ne s’adresse qu’aux « chanceux » possesseurs d’une @IP externe fixe, cette condition est expressément explicitée dès le début de celui-ci. En conséquence et théoriquement, ce tutoriel ne s’avère pas applicable aux possesseurs d’une @IP externe dite « dynamique ». Mais, et bien heureusement il y a un « MAIS », on peut contourner le problème de l’@IP externe fixe et ainsi s’en affranchir, pour disposer au final d’un serveur de messagerie bien opérationnel tout en utilisant une @IP dynamique. Il faut donc voir le présent tutoriel comme un complément qui répond à un autre besoin. Chacun, toujours selon son besoin, s’adaptera et suivra l’un ou l’autre de ces tutoriels. Oh, j’entends déjà d’ici des voix qui vont dire que le serveur de messagerie ainsi configuré, va tout au plus « marchoter » et que sans @IP fixe il n’y a point de salut viable. Eh bien, la configuration décrite ci-après devrait en prouver le contraire. Cela étant, il convient cependant en préalable, de garder en mémoire quelques points : Tous les NAS Synology ne sont pas compatibles avec le package « MPS ». Je vous invite donc avant toute chose, à contrôler que votre NAS figure bien dans la liste de compatibilité établie par Synology. Faute de quoi et j’en suis désolé pour vous, ce présent tutoriel ne sera pas applicable. Le package « MPS » ne fournit GRATUITEMENT en standard, la possibilité de créer que 5 @MAIL pour nos propres besoins. Il est vrai que c’est peu mais c’est déjà cela en termes de gratuit. Cependant, si vous souhaitez acquérir des @MAIL supplémentaires pour vos propres besoins, sachez que c’est possible mais que ces licences Synology ne sont disponibles que par lot de 5 ou lot de 20, à un prix que personnellement, je trouve prohibitif pour un particulier du moins. Si vous êtes un « Pro », c’est un autre débat ... En tous cas, voyez et jugez vous-même par exemple ICI (à la date de la présente rédaction) pour un simple lot de 5 licences (je vous laisse découvrir vous-même le coût de 20 licences !). Maintenant pour être complet, vous pouvez aussi vous rabattre sur l’ancienne version du package Synology « MailServer » qui est à ce jour encore disponible et opérationnelle et qui elle, certes, ne limite pas le nombre d’@MAIL créables. Cependant ses fonctionnalités sont bien moindres que celles de l’actuel « MPS ». Ceci dit, cet ancien package peut aussi très bien suffire à certains. À vous de voir selon vos besoins … En toute rigueur dans le processus de configuration de votre serveur de messagerie, il faudrait pouvoir paramétrer le « rDNS » d’Orange. Entendez par là, le « reverse DNS », c’est-à-dire la possibilité d’obtenir le nom de domaine correspondant à une @IP, ce que font automatiquement les serveurs d’Orange (mais aussi les autres FAI) pour vérifier que l'eMAIL émis, provient bien de l’enregistrement « MX » associé à ce domaine auquel cas l’eMAIL est rejeté. Or, cette inscription ne peut normalement se faire que chez le propriétaire de l’@IP externe en l’occurrence ici : Orange. Mais voilà, là c’est impossible chez eux (a priori, et à ma connaissance il semblerait que seul Free le permette). Bon, heureusement il semble qu’à l’usage ce ne soit finalement pas un problème bloquant dans notre affaire comme on le verra plus loin (au § 7 ci-dessous) lors du test « mail-tester.com ». Il faut juste le savoir. Il est également nécessaire que le port 25, qui est un port de communication entre serveurs MAIL, ne soit pas bloqué ni en entrée, ni en sortie. En fait chez Orange, il n’est pas bloqué comme on pourrait le croire et comme le croient certains, mais c’est juste qu’un serveur SMTP Orange ignore les connexions provenant d'un autre réseau si elles lui arrivent sur le port 25. Sachez que ce comportement est devenu le standard et tous les opérateurs appliquent ce type de restriction. Pour mémoire, Il semblerait que Free bloque aussi par défaut le port 25 mais au moins chez eux il serait possible toutefois, de débloquer cette fonction via l’interface de leur box. Donc au final, pour contourner ce « blocage » du port 25, il suffit et il est même impératif de passer par le serveur SMTP du FAI pour émettre des eMAILs et si on ne veut pas se les faire rejeter. Par conséquent et c’est là toute l’astuce que l’on va mettre en œuvre dans la configuration décrite ci-après, on va utiliser : · un serveur SMTP d’Orange (ce qu’on appellera par la suite un relais SMTP) où l’on a un compte, · via le protocole SSL avec le port 465 ou via le protocole TLS avec le port 587 qui servira pour la communication du client vers le serveur (c’est cette dernière solution que nous exploiterons ici), · et avec une authentification par mot de passe. C’est la condition sine qua non au bon fonctionnement de votre serveur de messagerie. De façon pratique, si vous faites des Copier/Coller de paramètres, d’instructions de commandes, etc … à partir du présent tutoriel, je vous invite expressément à passer par l’intermédiaire d’un fichier « .txt » afin de bien visualiser le contenu exact de la chaîne de caractères copiée. Cette disposition vous évitera notamment lors du « Copier » de prendre de façon aveugle des caractères parasites qui viendront immanquablement ensuite perturber les systèmes mis en œuvre dans leur analyse de ces paramètres et/ou commandes avec tous leurs cortèges de messages d’erreurs associés. Voilà, vous êtes prévenus … Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ... D’ores et déjà, je tiens aussi à remercier ici, @Thierry94 et @PiwiLAbruti qui, au cours de multiples échanges (que vous pourrez retrouver sur le présent forum), m’ont fourni de la matière pour alimenter et compléter un certain nombre d’explications que vous trouverez dans ce tutoriel. Ils se reconnaitront dans certains couplets que j’ai repris quasiment tels quels. Sinon pour une grande partie, toutes ces explications sont issues de synthèses de mes lectures sur la toile. Les « initiés » ne manqueront pas de corriger mes éventuels défauts d’interprétations. Voilà pour le discours préliminaire, on passe aux choses sérieuses … Prérequis : Vous devez disposer de : Un NAS Synology compatible et surtout sécurisé (voir le Tutoriel « [TUTO] Sécuriser les accès à son nas » de @Fenrir). Un nom de domaine personnalisé (« votredomaine.tld »). Un accès à la « zone DNS » de votre domaine chez votre fournisseur de domaine (pour l’exemple ici ce sera mon fournisseur : OVH). Un serveur DNS installé et configuré pour gérer votre domaine sur votre NAS ou sur votre Routeur Synology (voir le Tutoriel « [TUTO] DNS Server » de @Fenrir). Une @IP externe dynamique sur laquelle « pointe » un nom d’hôte qui n’est autre que « votredomaine.tld » et configurée sur votre NAS pour être prise en charge par un DDNS (pour l’exemple ici ce sera le DynDNS d’OVH). Optionnel mais recommandé : un reverse proxy configuré sur votre NAS (voir le Tutoriel « [TUTO] Reverse proxy » de @Kawamashi). Nota : Juste pour attirer votre attention sur le fait que par abus de langage en parlant d’@IP externe chez Orange, on réduit trop souvent à l’utilisation du qualificatif « dynamique ». En fait et en pratique (source Orange), en fonction du modèle de votre Livebox (Livebox 2, Livebox Play, Livebox 4) et de votre connexion (ADSL, VDSL2, Fibre), vous bénéficiez soit d’une @IP dite « dynamique », soit d'une @IP dite « préférentielle » telles que : Fibre et VDSL : IPv4 préférentielle, IPv6 dynamique, ADSL : IPv4 préférentielle ou dynamique selon éligibilité, Ipv6 dynamique selon éligibilité, LiveBox2 : IPv4 dynamique et uniquement en ADSL. Les différences entre les « @IP dynamiques » et les « @IP préférentielles » sont celles-ci : Les « @IP dynamiques » : elles sont modifiées périodiquement par Orange ou en cas de reconnexion de la Livebox. Les « @IP préférentielles » : elles sont stables dans la durée et ne changent qu'en cas de déconnexion de la Livebox supérieure à 7 jours. Toutefois, pour des raisons techniques, Orange peut procéder au renouvellement de votre adresse IPv4 si cela est nécessaire. Dans ce cas, ce renouvellement est activé lors de la prochaine connexion de la Livebox au réseau. L’« @IP préférentielle » quant à elle ne concerne que les adresses de type IPv4. C’est pour cela que l’on peut considérer/assimiler une « @IP préférentielle » à une « @IP fixe » compte tenu de son caractère stable dans le temps même si au final ce n’est pas complétement vrai je vous l’accorde. À titre d’exemple qui vaut ce qu’il vaut, j’ai une LiveBox4 en fibre et mon @IP externe n’a pas changé depuis bientôt 6 mois. Pourvu que cela dure … 1 Ajout des enregistrements DNS internes sur le NAS Peu importe que votre serveur DNS soit installé sur votre Routeur Synology ou sur votre NAS Synology, c’est la même application « DNS Server » que l’on va utiliser. Il est bien entendu que votre serveur DNS est déjà configuré sur votre NAS ou votre Routeur pour gérer votre domaine comme indiqué en prérequis. Rendez-vous sur l’application « DNS Server » et ouvrez-la à partir du bureau de DSM ou de SRM selon. On va créer deux (2) nouveaux enregistrements dans la zone master correspondante de votre domaine : - Un de type « A » afin de rediriger le client mail vers votre NAS. - Un de type « MX » pour que votre NAS puisse communiquer avec le serveur MAIL. Nota : Pour l’exemple et dans toute la suite du présent tutoriel : - l’@IP du NAS sera notée « 1.2.3.4 ». Bien évidemment il vous faudra remplacer cette valeur d’@IP par l’@IP locale « réelle » de votre NAS. - l’@IP externe de votre Box/Routeur sera notée « 10.20.30.40 » et de la même façon il vous faudra remplacer cette valeur d’@IP par l’@IP externe « réelle » de votre Box/Routeur. Pour cela : Dans le menu « Zones » sélectionnez la zone correspondante à votre domaine. 2xCliquez sur cette zone master OU dans le popup « Modifier » sélectionnez l’item « Enregistrement de ressources » Une fenêtre « Modifier un enregistrement de ressource » s’ouvre. Dans le popup « Créer » sélectionnez l’item « A Type » Saisissez ensuite tel que ci-après : Validez en cliquant sur « OK » Dans le popup « Créer » sélectionnez l’item « MX Type » Saisissez ensuite tel que ci-après : Validez en cliquant sur « OK » Dans la fenêtre « Modifier un enregistrement de ressource » vous devriez obtenir quelque chose comme ci-après : votredomaine.tld MX 3600 10 mail.votredomaine.tld mail.votredomaine.tld A 3600 1.2.3.4 Cliquez sur « Terminer » pour valider, vous pouvez ensuite quitter l’application « DNS Server » on en a fini avec elle. 2 Installation du package MailPlus Server et du client MailPlus 2.1 Installation de « MailPlus Server » Via le centre de paquets sur votre NAS Synology, on va maintenant installer le package « MPS ». Ne soyez pas surpris, en lançant l’installation de ce package, celle-ci nécessite l’installation concomitante de dépendances nécessaires au fonctionnement de « MPS » par le biais de deux autres packages qui sont respectivement : « Perl » et « Python Module ». Un message qu’il vous faudra valider vous en informe : ⚠ Il est possible à la fin de l’installation des trois paquets (durée 2 à 3 minutes), que vous receviez un message d’erreur signalant que l’installation a échoué et vous demandant de vous reconnecter à DSM. Ignorez ce message car en fait tout s’est bien passé. Il s’agit d’un bug lié au lancement automatique de « MPS » et de toute façon quittez DSM et reconnectez-vous. Donc après la phase d’installation vous devriez avoir ceci dans le centre de paquets : 2.2 Installation du client « MailPlus » Via le centre de paquets sur votre NAS Synology, on va maintenant installer le package « MailPlus ». Ne soyez pas surpris, en lançant l’installation de ce package, celle-ci nécessite l’installation concomitante de dépendances nécessaires au fonctionnement du client « MailPlus » par le biais de trois autres packages qui sont respectivement : « Node.js v8 », « Node.js v12 » et « Service d’application Synology ». Un message qu’il vous faudra valider vous en informe : 3 Pré configuration de MailPlus Server Donc suite à cette installation, on va maintenant effectuer un minimum de configuration/paramètrage de « MPS » afin de disposer des éléments nécessaires pour configurer plus loin aux § 4.2.3, § 4.2.4 et § 4.2.5 ci-dessous, la « zone DNS » de votre domaine chez OVH. Rassurez-vous on reviendra après cela pour finaliser la configuration et sécuriser le présent serveur de messagerie. Rendez-vous sur l’application « MPS » et ouvrez-la à partir du bureau de DSM (ou du centre de paquets). L’assistant de configuration de « MPS » propose de créer un nouveau système de messagerie. Validez en cliquant sur « Suivant ». Il vous faut alors saisir : Nom de domaine : « votredomaine.tld » Nom d’hôte (FQDN) : « votredomaine.tld » (FQDN : « Fully Qualified Domain Name » ou nom de domaine pleinement qualifié, est un nom de domaine qui donne la position exacte de son nœud dans l'arborescence DNS en indiquant tous les domaines de niveaux supérieurs). Validez en cliquant sur « Suivant ». L’assistant présente alors un résumé de la mise en place de votre domaine : Validez en cliquant sur « Appliquer ». L’assistant applique les différents paramètres : Validez en cliquant sur « Terminer ». Maintenant, on va générer une clé publique liée à votre domaine personnalisé qui va être utilisée plus loin (voir § 4.2.4 ci-dessous) lors de la configuration de la « zone DNS » de votre domaine chez OVH. Mais avant de générer cette clé, il est nécessaire de fixer la longueur de cette clé (à l’instar d’une clé de chiffrement de type RSA). Pour cela : Dans la section « SECURITE » sélectionnez l’onglet « Authentification ». Dans la fenêtre qui s’affiche alors : Nota : Bien que les définitions succinctes des trois notions citées ci-après soient données dans cette fenêtre, ces notions seront présentées plus en détail plus loin au §4.2 ci-dessous lors de la configuration de la « zone DNS » de votre domaine chez OVH. Cochez respectivement les cases qui vont permettre l’activation des processus de vérification « SPF » et « DKIM » et l’activation du processus « DMARC ». Sous SPF, laissez décochée la case « Rejeter les pannes souples SPF ». Dans la partie « DKIM », sélectionnez dans le popup la valeur « 2048 » pour fixer la longueur de votre clé publique. Validez en cliquant sur « Appliquer ». Dans la section « DOMAINE » sélectionnez la ligne correspondante de votre domaine : Cliquez sur le bouton « Modifier » OU 2xCliquez sur cette ligne. Le détail de votre domaine s’affiche : Profitez-en pour renseigner au passage la description de votre domaine, par exemple : « Messagerie associée à votredomaine.tld ». Au moins ce sera toujours cela de fait … 😀 Cliquez ensuite sur le bouton « Avancé ». Dans la fenêtre qui s’affiche alors : Cochez la case « DKIM » Saisissez pour « Préfixe du sélecteur DKIM » un terme quelconque composé de caractères et éventuellement de chiffres. Il est d’usage d’en limiter le nombre de caractères (entre 5 et 8 c’est bien). Mais dans tous les cas veillez à NE PAS utiliser de majuscules, ni de caractères « spéciaux » ou « exotiques » ; ceci afin de ne pas perturber les serveurs qui analyseront ce préfixe. Nota : Pour votre présente information mais on reverra cela plus loin dans la suite de ce tutoriel : Le sélecteur DKIM est spécifié dans l'en-tête de l’eMAIL contenant la signature DKIM. Il indique où la partie de la clé publique de la paire de clés DKIM se trouve dans le DNS. Le serveur de réception utilise quant à lui le sélecteur DKIM pour localiser et récupérer la clé publique afin de vérifier que le message électronique est authentique et n’a pas été altéré. Cliquez ensuite sur le bouton « Générer la clé publique ». Le message suivant s’affichera alors : Comme on a déjà précédemment fixé cette longueur de clé « DKIM », il est inutile de le refaire donc ignorez ce message et validez en cliquant sur « Oui ». Copiez et sauvegardez précieusement cette clé dans un fichier « .txt » sur votre PC/Mac. On va s’en resservir plus loin dans le présent tutoriel. À discuter mais je ne recommande pas d’activer la fonction « Catch-all ». En effet, avec cette fonction il vous est possible de recevoir des eMAILs ayant pour origine un utilisateur inconnu et surtout qui n’existe pas. Donc avec cette option activée c'est quelque part la porte ouverte aux usurpateurs. Il suffit ensuite d'une seconde d'inattention et un clic malheureux dans un eMail de ce genre pour se retrouver dans la panade. Voilà ce n’est que mon interprétation de cette fonction, elle vaut ce qu’elle vaut. Maintenant c’est vous qui voyez … Validez en cliquant sur « OK ». 4 Configuration de la zone DNS chez OVH Maintenant que l’on a tous les éléments nécessaires on peut procéder à la configuration de la zone DNS associée à votre domaine chez OVH. Pour cela : Connectez-vous à OVH avec votre identifiant principal et votre mot de passe. Rendez-vous sur le tableau de bord de votre domaine : menu « Web » / section « Domaines » / « votredomaine.tld ». 4.1 Optionnel : création d'une @MAIL de secours chez OVH Mais avant de configurer la zone DNS, il convient de régler un point qui reste toutefois tout à fait optionnel pour vous. Libre à vous de le suivre ou pas. En effet, si vous avez souscrit une offre « gold » (appelée aussi « Start10M ») lors de l'initialisation de votre abonnement pour un nom de domaine chez OVH, sachez qu’il vous est gracieusement offert avec cet abonnement la possibilité de gérer une @MAIL avec 5GO de stockage sur leurs serveurs ainsi qu’un hébergement web de 10 Mo. Aussi, à moins que ce ne soit déjà fait et auquel cas, passez directement au §4.2 ci-dessous, je vous invite à créer cette @MAIL et cet hébergement Web même si en fin de compte vous n’utiliserez pas ce dernier (quoique dans le futur, on ne sait jamais, cela pourrait être une bonne base pour bâtir votre propre site Web. Comme toujours à vous de voir …). Dans tous les cas, ce qui vous intéresse donc ici c’est l’@MAIL offerte car d’une part elle est gratuite donc pourquoi s’en priver ? En plus, elle peut toujours servir à autre chose. Mais d’autre part, c’est surtout que cette création d’@MAIL va pouvoir vous servir en quelque sorte d’@MAIL de secours. Nota : Si vous estimez avoir besoin de plus d’@MAIL, il vous faudra modifier votre abonnement OVH pour acheter des @MAIL supplémentaires. Pour cela : rendez-vous sur le tableau de bord de votre domaine : menu « Web » / section « Emails » / « votredomaine.tld » / Abonnement / Offre MXPLAN 1 hosting et cliquez sur le bouton cerclé « … » et choisissez l’offre qui vous convient En effet, toute l’astuce ici, est de définir cette @MAIL de façon identique à celle que l’on va configurer pour votre utilisateur « principal » dans votre serveur de messagerie « MPS» sur votre NAS. Ainsi, pour le cas où votre NAS ne serait plus joignable de l’extérieur ou qu’il ne réponde plus aux sollicitations externes (pour cause de panne, d’arrêt pour maintenance ou toute autre raison) vous pourrez continuer à pouvoir émettre et surtout recevoir des eMAILs sur cette @MAIL. Intéressant, non ? Seule contrainte, s’il en est, c’est qu’il vous faudra soit vous connecter directement à votre compte OVH pour gérer ces eMAILS, soit avoir installé et configuré un client MAIL comme décrit dans la phase n°3 du guide cité au point 2 ci-après. Donc, après vous être connecté sur votre compte OVH, rendez-vous sur le tableau de bord de votre compte client OVH : Activez votre offre d’hébergement gratuit « Start10M » en suivant les étapes de ce guide. A la fin de du guide vous trouverez un lien permettant de créer votre @MAIL gratuite. Cliquez sur ce lien (qui est rappelé ici) et suivez les étapes de ce second guide. Bien évidemment et c’est ce qui est important, vous créerez votre adresse eMAIL avec le nom de votre utilisateur principal que vous aurez choisi parmi les utilisateurs déjà déclarés ou que vous créerez pour l’occasion sur votre NAS. Au final, votre @MAIL sera donc du type : « utilisateurprincipal@votredomaine.tld ». 4.2 Configuration de la zone DNS chez OVH Si vous avez suivi l’étape précédente du §4.1 ci-dessus alors repositionnez-vous sur votre domaine menu « Web » / section « Domaines » / « votredomaine.tld » sinon ce n’est pas la peine vous y êtes déjà. 4.2.1 Enregistrements « A » · Vérifiez que vous n’avez pas d’enregistrements de type « A » associés à « mail.votredomaine.tld ». Si c’est le cas : supprimez-le ou les. 4.2.2 Enregistrements « MX » Deux cas de figure se présentent ici selon que vous ayez créé ou non une @MAIL de secours en suivant le processus décrit au §4.1 ci-dessus. Si vous n’en avez pas créée alors passez directement au point 2 ci-après. Si vous avez créé une @MAIL de secours « utilisateurprincipal@votredomaine.tld », alors normalement vous devriez trouver dans votre zone DNS, trois (3) enregistrements de type « MX » (ils ont été automatiquement ajoutés par OVH avec la création de l’@MAIL de secours) tels que : votredomaine.tld. 0 MX 1 mx1.mail.ovh.net. votredomaine.tld. 0 MX 5 mx2.mail.ovh.net. votredomaine.tld. 0 MX 100 mx3.mail.ovh.net. Ici les priorités (4ème champ de l’enregistrement) de ces serveurs d’OVH, sont définies de telle façon que ces derniers interviendront en premier pour gérer les flux d’eMAILs entrants et sortants de votre adresse @eMAIL « utilisateurprincipal@votredomaine.tld ». Nota : les priorités vont de la plus forte (1) à la plus faible (100 et plus). Afin que votre @MAIL devienne une @MAIL de secours, on va donc modifier ces priorités en les diminuant pour chacun des deux premiers enregistrements « MX » (mx1 et mx2) .Pour le serveur mx3, c’est inutile vue sa priorité déjà très faible. Pour réaliser cela : o À droite de chaque enregistrement « MX », cliquez sur le bouton cerclé « … » et sélectionnez dans le popup l’item « Modifier l’entrée ». o Dans le champ « Priorité », saisissez respectivement les valeurs suivantes : 5 puis 10. o Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS trois (3) enregistrements « MX » tels que : votredomaine.tld. 0 MX 5 mx1.mail.ovh.net. votredomaine.tld. 0 MX 10 mx2.mail.ovh.net. votredomaine.tld. 0 MX 100 mx3.mail.ovh.net. En premier lieu, vérifiez la présence dans votre zone DNS, d’un enregistrement « MX » tel que : votredomaine.tld. 0 MX 1 redirect.ovh.net. S’il existe effectivement, alors supprimez le purement et simplement. Cet enregistrement, créé par défaut par OVH lors de la mise en place de votre domaine, est inutile dans notre actuelle démarche de configuration de votre propre serveur de messagerie. On va maintenant créer un nouvel enregistrement « MX » qui va rediriger tout le flux d’eMAILs entrants et sortants de votre adresse @eMAIL « utilisateurprincipal@votredomaine.tld » vers votre serveur de messagerie « MPS » sur votre NAS tout en lui donnant la priorité maximum, c’est-à-dire : 1. De cette façon, si vous avez créé une @MAIL de secours « utilisateurprincipal@votredomaine.tld » comme décrit précédemment, alors les serveurs d’OVH tels que configurés au point 1, reprendront automatiquement la main dans le cas où votre NAS et donc implicitement votre serveur de messagerie « MPS », ne répondrait plus aux sollicitations externes. Le flux entrant de vos eMAILs serait alors redirigé automatiquement vers la boîte MAIL de secours chez OVH. Ceci pour tous les eMAILs qui sont adressés à votre @MAIL « utilisateurprincipal@votredomaine.tld » et uniquement pour ceux-là. Pour les autres @MAIL de vos autres utilisateurs définis sur le NAS (donc pour le cas où vous n’auriez pas ajouté d’autres @MAIL sur votre compte OVH), sachez que normalement lorsqu'un serveur MAIL n'arrive pas à joindre un autre serveur pour lui envoyer des eMAILs, le protocole d'échange prévoit que le serveur émetteur réessaye la connexion pendant 14 jours avant d'abandonner l’eMAIL. Donc, même si vous n’avez pas de solution de secours comme décrite ci-avant, le risque de perdre des eMAILs demeure assez limité. De plus, on peut penser que vous n’allez pas rester 14 jours sans réagir, Non ? Donc : o Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». o Cliquez dans la zone « Champs mails » sur « MX ». o Saisissez les informations suivantes : ▪ Sous-domaine : laissez vide ▪ TTL : 3600 ▪ Priorité : 1 ▪ Cible : « votredomaine.tld. » (N’oubliez pas le « . » à la fin, c’est important !) o Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « MX » tel que : votredomaine.tld. 3600 MX 1 votredomaine.tld. 4.2.3 Ajout d’un enregistrement TXT de type « SPF » Avant toutes choses, il convient de vous expliquer à minima ici de façon rapide et simple (enfin je l’espère !) ce qu’est un enregistrement « SPF » et à quoi il sert. Il est très important de bien comprendre tous les tenants et aboutissants de cette notion pour pouvoir ensuite maîtriser votre serveur de messagerie « MPS ». Rassurez-vous, il n’y a rien de bien compliqué en soi mais prenez bien le temps de bien lire ce qui suit pour en assimiler le concept. Donc : Le protocole Simple Mail Transfer Protocol (SMTP) utilisé pour le transfert du courrier électronique sur Internet ne prévoit pas de mécanisme de vérification de l'expéditeur, c'est-à-dire qu'il est facile d'envoyer un eMAIL avec une adresse d'expéditeur factice, voir usurpée. Pour réduire les possibilités d'usurpation, on va publier, dans la zone DNS de votre domaine, un enregistrement spécifique indiquant la liste de toutes les @IP qui sont autorisées à envoyer des eMAILs au nom de votre domaine (implicitement les autres @IP sont interdites). Cet enregistrement spécifique est nommé : « SPF » (Sender Policy Framework) ou enregistrement « SPF TXT ». « SPF » est un protocole d'authentification des eMAILs. Fonctionnement : Lorsqu'un expéditeur tente de transférer un eMAIL à un serveur de réception pour qu'il lui soit livré, le serveur de MAILs vérifie si l'expéditeur figure sur la liste des expéditeurs autorisés du domaine. Si c'est le cas, un lien a été établi entre l’eMAIL et le domaine de messagerie. Si ce n'est pas le cas, le serveur continue à traiter le courrier électronique comme d'habitude sans ce lien et là, l’eMAIL a toutes les chances d’être considéré comme du SPAM. La plupart du temps il est purement et simplement rejeté. Avec un enregistrement « SPF » en place, vous allez protéger ainsi votre domaine de messagerie contre les attaques de spoofing et de phishing en faisant savoir au monde entier quels sont les serveurs autorisés à envoyer des eMAILs authentifiés en votre nom. Il vous faut aussi savoir que les « RFC »(Request for Comments) sur le domaine « DNS » ont initialement introduit le type d’enregistrement « SPF » pour prendre en charge ce scénario. Pour prendre en charge des serveurs de noms plus anciens, elles autorisaient également l’utilisation du type d’enregistrement « TXT » pour spécifier les enregistrements « SPF ». Nota : Cet enregistrement « TXT » est aussi appelé « SPF TXT » car on utilise aussi les enregistrements de type « TXT » pour d’autres notions. Cette ambiguïté a entraîné une certaine confusion qui a été résolue par la norme RFC 7208. Celle-ci stipule notamment que les enregistrements « SPF » doivent être créés à l’aide du type d’enregistrement « TXT » (« SPF TXT »). Elle stipule également que le type d’enregistrement « SPF » est déprécié. L’ajout dans la zone DNS de votre domaine d’un enregistrement « SPF TXT » est l'un des mécanismes le plus important lorsqu'on met en place un serveur MAIL. Comme la configuration sur un NAS Synology est souvent faite avec un seul domaine et un seul serveur principal, l'adresse à définir correspond à l'enregistrement « MX » du domaine. L'intérêt de choisir cet enregistrement, est que l’enregistrement « SPF TXT » suivra implicitement les modifications de cet enregistrement « MX » qui pourraient intervenir par ailleurs ensuite. Donc dans le cas du présent tutoriel, l’enregistrement « SPF TXT » sera de la forme et syntaxe suivante : votredomaine.tld. 0 TXT "v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all" Où : « v=spf1 » : indique la version du protocole SPF. « mx » : indique au mécanisme de contrôle d’examiner les @IP définies dans les enregistrements « MX ». « a :smtp.smtpout.orange.fr » : indique la liste des @IP autorisées à émettre des eMAILs pour le domaine. Ici cela correspond à votre serveur relais SMTP chez Orange. « include :mx.ovh.com » : indique la liste complémentaire d’@IP également autorisées à émettre des eMAILs pour le domaine. Ici cela correspond aux serveurs d’OVH que l’on utilise comme serveurs de secours. « -all » : indique la politique et la rigueur à appliquer lorsqu'un serveur récepteur détecte un serveur qui n'est pas répertorié (autorisé) dans votre enregistrement « SPF TXT ». Ici, la balise « all » comporte en préfixe l’option « - » qui signifie « échec » : les eMAILs non autorisés seront donc rejetés. Si vous êtes en phase de configuration ou de test de votre serveur, vous pouvez utiliser à la place l'opérateur "~" (tilde) qui signifie (soft fail) et qui vous évitera des blocages intempestifs. Dans ce cas, les eMAILs non autorisés seront acceptés mais marqués. Pour les plus curieux d’entre vous qui souhaiteraient aller plus loin, sachez que si vous utilisez plusieurs domaines et que votre enregistrement « SPF TXT » est identique pour tous ces domaines, la directive « redirect » permet de faire pointer l'enregistrement « SPF TXT » d'un domaine vers celui d'un autre domaine. Ainsi, en cas de modification de l’enregistrement « SPF TXT », la modification sera appliquée à tous les autres domaines. La syntaxe à employer est celle-ci : v=spf1 redirect=votredomaine.tld D'où la bonne pratique qui est de le faire même si vous ne possédez qu'un seul domaine afin d’anticiper l'acquisition d'autres domaines ultérieurement, la syntaxe de votre enregistrement « SPF TXT » pour votre domaine devient par exemple : votredomaine.tld 0 TXT "v=spf1 mx -all" autredomaineA.tld 0 TXT "v=spf1 redirect=votredomaine.tld" autredomaineB.tld 0 TXT "v=spf1 redirect=votredomaine.tld" autredomaineC.tld 0 TXT "v=spf1 redirect=votredomaine.tld" autredomaineD.tld 0 TXT "v=spf1 redirect=votredomaine.tld" . . . Pour terminer cet aparté, sachez enfin que vous pouvez résoudre récursivement les enregistrements « SPF TXT » pour vérifier les hôtes autorisés. En voici un exemple avec « mx.ovh.com » : Dans une fenêtre de commande Windows ou d’un terminal Mac, tapez ceci : > nslookup -type=TXT mx.ovh.com mx.ovh.com text = "v=spf1 ptr:mail-out.ovh.net ptr:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all" > nslookup mail-out.ovh.net Name: mail-out.ovh.net Address: 87.98.222.13 > nslookup mail.ovh.net Name: mail.ovh.net Address: 193.70.18.148 Le problème de la constitution et de la syntaxe de votre enregistrement « SPF TXT » étant réglé, on va procéder à un contrôle des paramètres de l’enregistrement « SPF TXT » afin d’être sûr à 100% de sa syntaxe et donc que celle-ci est correcte. Pour ce faire, il y a deux façons : La première et la plus sage à mon sens, consiste à effectuer le contrôle avant de créer effectivement cet enregistrement « SPF TXT » dans la zone DNS de votre domaine. Vous verrez et comprendrez par la suite, que l’on perd moins de temps avec cette méthode. La seconde, consiste à créer directement l’enregistrement dans la zone DNS de votre domaine, ce qui va déclencher sa diffusion sur tous les serveurs DNS de la toile (sachant que la propagation complète de l’enregistrement est loin d’être instantanée) et ensuite de procéder au contrôle de l’enregistrement « SPF TXT » (vous verrez plus loin aussi que cette dernière méthode apporte une petite nuance, par rapport à la première méthode, qui vous sera explicitée). Vous avez donc le choix de la méthode à appliquer. C’est vous qui voyez … Néanmoins pour ce tutoriel, on va appliquer la première méthode. Ceci dit, vous trouverez plus loin, après la description du déploiement de l’enregistrement « SPF TXT », la description de la seconde méthode de contrôle suscitée. Soyez patient, chaque chose en son temps …. Donc pour contrôler la syntaxe de votre enregistrement « SPF TXT », on va utiliser les services d’un site internet dédié : Dans un navigateur Web, rendez-vous sur le site « kitterman.com ». (Il en existe certes d’autres mais celui-là est réputé être très efficace). Dans la zone « Test an SPF record », saisissez les données suivantes dans les champs correspondants : IP address : 10.20.30.40 (votre @IP externe, i.e. celle de votre Box/Routeur). SPF Record v=spf1...://--> : v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all (la chaîne de paramètres SPF et sans les guillemets !) Mail From address: : utilisateurprincipal@votredomaine.tld HELO/EHLO Address://--> : votredomaine.tld Cliquez sur le bouton « Test SPF record ». Le résultat du contrôle s’affiche après quelques secondes : Input accepted, querying now... Mail sent from this IP address: 10.20.30.40 Mail from (Sender): utilisateurprincipal@votredomaine.tld Mail checked using this SPF policy: v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all Results - PASS sender SPF authorized Mail sent from this IP address: 10.20.30.40 Mail Server HELO/EHLO identity: votredomaine.tld HELO/EHLO Results - PASS sender SPF authorized « PASS sender SPF authorized » : Parfait, la syntaxe de votre enregistrement « SPF TXT » est validée et sans erreur, on va donc pouvoir créer effectivement ce fameux enregistrement « SPF TXT » dans la zone DNS de votre domaine. Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs étendus » sur « TXT ». Saisissez les informations suivantes : Sous-domaine : laisser vide TTL : laisser « Valeur par défaut » Valeur : « v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all » (sans les guillemets !) Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « TXT » tel que : votredomaine.tld. 0 TXT "v=spf1 mx a:smtp.smtpout.orange.fr include:mx.ovh.com -all" Nota : Dans la dernière fenêtre, juste avant de valider, vous avez certainement remarqué et lu l’avertissement suivant :« La modification sera immédiate dans la zone DNS, mais veuillez prendre en compte le temps de propagation (maximum 24h). ». Cet avertissement est loin d’être anodin. Il va falloir prendre votre mal en patience si je puis dire …Le temps de propagation vers tous les serveurs DNS de la toile est en effet assez long. Parfois, il semble rapide mais ce n’est que parfois. Pour suivre en quelque sorte l’avancement de ce déploiement, vous pouvez utiliser le moyen suivant : Dans un navigateur Web, rendez-vous sur le site « whatsmydns.net »: Saisissez l’intitulé de votre domaine : « votredomaine.tld ». Dans le popup à droite du champ domaine, sélectionnez l’item « TXT ». Cliquez sur le bouton « Search ». (Recliquez périodiquement jusqu’au déploiement complet). Lorsque la propagation complète sera achevée, vous aurez un affichage semblable à celui-ci : Une fois la propagation achevée, c’est là que vous pouvez appliquer la seconde méthode de contrôle de l’enregistrement « SPF TXT ». Différents sites sur la toile proposent des outils en ligne pour ce faire. Donc, dans un navigateur Web, rendez-vous sur le site « dmarcanalyzer.com » (Il en existe certes d’autres mais celui-là est l’un des plus efficace et complet) Saisissez l’intitulé de votre domaine et après avoir coché la case « Je ne suis pas un robot » et satisfait à l’éventuel Captcha, cliquez sur le bouton « Valider DNS ». Après quelques secondes d’analyse le résultat du contrôle de votre domaine s’affiche. Après le rappel de votre chaîne de paramètres, le détail des @IP autorisées à émettre des eMAILs pour votre domaine vous est présenté. En l’occurrence pour le relais SMTP d’Orange que l’on a indiqué, on a la liste d’@IP suivante : A la suite, on trouve la liste des serveurs MAIL autorisés avec leur @IP : Enfin, on trouve l’enregistrement « SPF TXT » propre aux serveurs d’OVH que l’on a inclus afin de servir de serveurs de secours. Figurent également les @IP de ces serveurs qui sont autorisées à émettre des eMaILs avec/sur votre domaine. A ce stade, vous avez bien évidemment remarqué l’avertissement formulé à propos des serveurs d’OVH et qui soit dit en passant, n’avait pas été relevé lors du contrôle de l’enregistrement « SPF TXT » avec la première méthode précédente (c’est la fameuse nuance suscitée). En fait, cet enregistrement « SPF TXT » pour les serveurs d’OVH n’est pas obsolète. Il est parfaitement fonctionnel et valide, mais l’usage des balises d’instructions « PTR » qu’il fait, est simplement déconseillé au sens de la norme RFC 7208 citée précédemment. Techniquement, le mécanisme est intéressant en soi car il permet une double validation DNS du serveur d'expédition. Mais la résolution inverse pose des problèmes de performances et donc de fiabilité. En clair selon les « initiés » de ce forum, si cela posait vraiment des problèmes de fiabilité, on peut penser qu'OVH aurait déjà rectifié la chose. Et en l’occurrence ce qui n’est pas le cas. Maintenant si vous êtes vraiment gênés par cet avertissement, il existe une parade. Vous pouvez toujours créer un nouvel enregistrement « SPF TXT » dans votre zone DNS en ayant pris soin de remplacer les instructions « ptr » par un « a » et inclure celui-ci dans votre enregistrement « SPF TXT » principal. Ce qui donnerait quelque chose comme cela : ovh.domain.tld 0 TXT "v=spf1 a:mail-out.ovh.net a:mail.ovh.net ip4:8.33.137.105/32 ip4:192.99.77.81/32 ?all" votredomain.tld 0 TXT "v=spf1 mx a:smtp.smtpout.orange.fr include:ovh.domain.tld -all" Néanmoins sachez que le gros inconvénient de cette méthode est qu'elle est statique et donc non viable dans le temps. En effet, l'enregistrement « ovh.domain.tld » sera obsolète dès qu'OVH modifiera son enregistrement « SPF TXT », et cela vous ne pourrez le maîtriser. Au final les « initiés » de ce forum, préconisent de laisser tel quel l’enregistrement « SPF TXT » d'OVH même s'il n'est pas optimal. Je vous invite donc à suivre cette recommandation. De toute façon, on le reverra plus loin (voir § 8.1 ci-dessous) lors des tests de diffusion d’eMAILs avec votre serveur de messagerie « MPS », que ce n’est pas un point bloquant. Toutefois et comme toujours, c’est vous qui voyez … 4.2.4 Ajout d’un enregistrement TXT de type « DKIM » Comme pour l’enregistrement « SPF TXT », il convient aussi de vous expliquer à minima ici de façon rapide et simple (enfin je l’espère !) ce qu’est un enregistrement « DKIM » et à quoi il sert. La bonne compréhension de tous les tenants et aboutissants de cette notion est aussi très importante pour pouvoir ensuite maîtriser votre serveur de messagerie « MPS ». Donc : Domain Keys Identified Mail (DKIM) est l'une des méthodes d'authentification utilisée par les opérateurs de messagerie, permettant de déterminer l'identité d'un expéditeur et donc de l’authentifier. Comme « SPF », « DKIM » est une norme ouverte pour l'authentification des eMAILs utilisée pour ce qu’on appellera plus loin : « l‘alignement DMARC ». L’avantage de « DKIM » est qu’il peut survivre à la transmission, ce qui le rend supérieur à « SPF » et c’est une base pour sécuriser votre eMAIL. Fonctionnement : Les serveurs de MAILs sont configurés pour attacher en en-tête de chaque eMAIL qu’ils envoient, une signature dite « DKIM ». Cette signature « DKIM » contient des informations sur l'expéditeur et le message, nécessaires à la vérification qui sera effectuée en cours de route par les serveurs MAIL qui acheminent les MAILs vers leur destination finale. Cet en-tête de signature « DKIM » qui est ajouté à l'eMAIL, est sécurisé avec une paire de clés publique / privée dites clés « DKIM » et un certificat. La signature « DKIM » agit alors comme un filigrane pour les eMAILs afin que les destinataires de ces eMAILs puissent vérifier que chaque eMAIL provient bien du domaine indiqué et qu'il n'a pas été altéré voire falsifié. Ainsi selon leur propre méthode, les serveurs de MAILs établissent la réputation et la fiabilité d'un expéditeur, augmentant ou diminuant selon, de fait la délivrabilité des eMAILs de ce dernier. Cette signature « DKIM » contient également toutes les informations nécessaires à un serveur de messagerie pour qu’il puisse vérifier que la signature « DKIM » est bien réelle. Le serveur de messagerie d'origine possède ce qu'on appelle la «clé privée», qui peut être vérifiée par le serveur de messagerie ou le FAI récepteur avec l'autre moitié de la paire de clés, qui est appelée la «clé publique». La clé publique figure dans l’enregistrement « DKIM » inclus dans la zone DNS de votre domaine sous forme d’un enregistrement de type « TXT ». Afin de connecter et de déchiffrer ces signatures chiffrées, un « sélecteur DKIM » est utilisé. Le « sélecteur DKIM », tout comme la signature « DKIM », est aussi spécifié dans l'en-tête de l’eMAIL. Il indique où la partie de la clé « publique » de la paire de clés « DKIM » se trouve dans le DNS du domaine concerné. Le serveur MAIL de réception utilise alors le « sélecteur DKIM » pour localiser et récupérer cette clé « publique » afin de vérifier que l’eMAIL est authentique et n’a pas été altéré. Pour mémoire, lors de la pré configuration de votre « MPS » au § 3 ci-dessus, vous avez défini ce « sélecteur DKIM » sous forme d’un « préfixe » afin de pouvoir générer la partie « publique » de votre clé « DKIM ». Sachez qu’en même temps, la partie « privée » de votre clé « DKIM » a aussi été générée et ce de façon complétement transparente pour vous. Elle est stockée dans les arcanes de votre NAS. Je ne saurais vous dire où et peu importe, on n’en a pas besoin dans le cadre de ce tutoriel. Les plus curieux d’entre vous pourront toujours la rechercher mais je doute que cela leur apporte grand-chose … 🤔 Comme vous pouvez le constater, les éléments du puzzle commencent à s’imbriquer progressivement … 😀 Voilà pour les explications contextuelles préalables. Donc dans le cas du présent tutoriel, l’enregistrement « DKIM » sera de la forme et syntaxe suivante : prefixe._domainkey.votredomaine.tld. 0 TXT "v=DKIM1; q=dns; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" Où : « v=DKIM1 » : indique la version du protocole DKIM. « q=dns » : indique le type de requête. Ici « dns ». « p= xxxxxx…………xxxxxx » : votre clé « publique » encodée base64. Le problème de la constitution et de la syntaxe de votre enregistrement « DKIM » étant réglé, on va procéder à un contrôle des paramètres de l’enregistrement « DKIM » afin d’être sûr à 100% de sa syntaxe et donc que celle-ci est correcte. Pour ce faire, on va utiliser les services d’un site internet dédié : Dans un navigateur Web, rendez-vous sur le site « dmarcanalyzer.com ». (Le même que précédemment vous l’aurez remarqué …). Saisissez l’intitulé de votre « prefixe » de sélecteur DKIM tel que vous l’avez défini au § 3 ci-dessus. Saisissez l’intitulé de votre domaine et après avoir coché la case « Je ne suis pas un robot » et satisfait à l’éventuel Captcha, cliquez sur le bouton « Valider DNS ». Après quelques secondes d’analyse le résultat du contrôle du dossier « DKIM » de votre domaine s’affiche. Après le rappel de votre chaîne de paramètres, le détail du dossier est présenté. Il vous donne : la longueur de la clé de chiffrement utilisée et une explication de chacune des balises qui ont été utilisées. « Ceci semble être un dossier DKIM valide » Parfait, la syntaxe de votre enregistrement « DKIM » est validée et sans erreur, on va donc pouvoir procéder à la création de ce fameux enregistrement « DKIM » dans la zone DNS de votre domaine chez OVH. Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs étendus » sur « TXT ». Saisissez les informations suivantes : Sous-domaine : prefixe._domainkey (bien évidemment et pour rester cohérent, reprenez pour prefixe la valeur que vous aviez choisie précédemment au § 3 ci-dessus, et n’oubliez pas le « . » derrière, c’est important !) TTL : laissez « Valeur par défaut » Valeur : « v=DKIM1; q=dns; p=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx » (sans les guillemets !) en remplaçant xxxxxxxxxxxxxxxxxxxxxxxxxx par la valeur de votre clé « publique » précédemment sauvegardée. ⚠ Pour le coup, soyez très vigilant avec votre Copier/Coller !!! Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « TXT » tel que : prefixe._domainkey.votredomaine.tld. 0 TXT "v=DKIM1; q=dns; p=xxxxxxxx…………..xxxxxxxx" 4.2.5 Ajout d’un enregistrement TXT de type « DMARC » Vous l’aurez compris, comme pour les enregistrements « SPF TXT » et « DKIM », il convient aussi de vous expliquer à minima ici toujours de façon rapide et simple (enfin je l’espère !) ce qu’est un enregistrement « DMARC » et à quoi il sert. La bonne compréhension de tous les tenants et aboutissants de cette notion est elle aussi très importante pour pouvoir ensuite maîtriser votre serveur de messagerie « MPS ». Donc : Pour mémoire, l’eMAIL a été initialement créé sans une vraie protection, en se reposant sur le protocole SMTP pour sa diffusion. C’est pour cette raison que l’on a vu apparaître au fil des années, des protections destinées à améliorer la sécurité des échanges en SMTP. Les protocoles « SPF » et « DKIM » vus précédemment en font partie et sont efficaces chacun dans leur domaine. Je vous les rappelle succinctement : « SPF » (Sender Policy Framework) : permet de déclarer les@IP autorisées à envoyer des eMAILs au nom de votre domaine. Il peut, à lui seul, associer un eMAIL à un domaine. « DKIM » (Domain Keys Identified Mail) : permet grâce à une signature cryptographique de s’assurer que le message que vous envoyez/recevez ne va pas se faire altérer en cours de route. Par contre, à lui seul il n'est pas un moyen fiable d'authentifier l'identité de l'expéditeur de l'eMAIL et en plus il ne fait rien pour empêcher l'usurpation d'identité du domaine visible dans l'en-tête de cet eMAIL. En pratique, les protocoles « SPF » et « DKIM » viennent chacun vérifier dans l’entête de l’eMAIL, le « Mailfrom : », i.e. le domaine l’expéditeur extrait à partir de son @MAIL. Cependant, ils ne vont pas inspecter le « From : », qui correspond au vrai expéditeur de l’eMAIL. En fait, ces deux protocoles ne vérifient pas que ces informations concordent, ce qui rend au passage, un possible contournement par des malfaisants. Cela dit, les protocoles « SPF » et « DKIM » restent toutefois et sont deux protocoles de protections indispensables. Pour répondre à cette problématique de possible contournement, il a été mis en place le protocole « DMARC » (Domain-based Message Authentification Reporting and Conformance) qui est lui-même construit sur les protocoles « SPF » et « DKIM ». Sachant que les protocoles « SPF » et « DKIM » peuvent associer un eMAIL à un domaine, le protocole « DMARC » va lui, tenter de lier les résultats des protocoles « SPF » et « DKIM » au contenu de l’eMAIL lui-même et plus précisément au domaine figurant dans la voie de retour (« Return-Path: ») ou dans l'en-tête « From : » de cet eMAIL. C’est ce domaine trouvé dans l'en-tête « From : » qui va être l'entité commune à tous les traitements « DMARC ». Le schéma suivant (extrait de l’entête d’un eMAIL) vous sera peut-être plus parlant : Comme tout le monde peut acheter un domaine et mettre en place des enregistrements « SPF » et « DKIM » dans la zone DNS de son domaine (y compris les malfaiteurs), les résultats du traitement « SPF » et « DKIM » doivent donc être liés au domaine trouvé dans l'en-tête « From : » pour être pertinents pour le protocole « DMARC ». Ce concept de liaison s’appelle « l’alignement d’ identifiants ». Il vient ainsi agir sur les eMAILs là où les protocoles « SPF » et « DKIM » ont échoués. « L'alignement des identifiants » est donc la manière dont les technologies d'authentification existantes sont rendues pertinentes pour le contenu d'un eMAIL. L'alignement des identifiants constitue une grande partie du travail de déploiement de la norme « DMARC ». Ensemble, ces protocoles constituent ainsi la meilleure pratique pour éviter le spoofing d’eMAILs et rendre vos eMAILs plus fiables. Mais attention, le protocole « DMARC » ne fonctionne que si vous avez configuré un enregistrement « SPF » et « DKIM » dans la zone DNS de votre domaine. Fonctionnement : Durant le contrôle « DMARC », le contenu figurant dans le « Mailfrom : », et le « From : » figurants dans l’entête de l’eMAIL, est donc examiné. S’il est différent, alors le protocole « DMARC » peut traiter l’eMAIL de trois manières possibles (appelées aussi « politiques DMARC ») : DMARC policy none : On vient juste surveiller les résultats mais on ne prend aucune mesure concernant ces eMAILs. Vous les recevrez, mais un message sera envoyé à l’administrateur du domaine expéditeur pour le prévenir que l’alignement n’est pas respecté. DMARC policy quarantine : Tous les eMAILs qui échouent au respect des protections, sont mis en quarantaine, ils peuvent être traités ultérieurement. DMARC policy reject : Les eMAILs qui ne passent pas les vérifications de la norme, vont s’annuler directement pour qu’ils ne soient pas envoyés au destinataire. Encore un schéma qui résume bien le processus « DMARC » dans sa globalité : Ainsi, la norme « DMARC » permet de lutter plus efficacement contre le spam et le phishing. Si les renseignements de l’eMAIL respectent les contrôles « SPF » et « DKIM » et respectent l’alignement, alors l’eMAIL passera la protection DMARC. Cette norme est donc indispensable pour assurer une protection optimisée. Voilà pour les explications contextuelles préalables. Donc dans le cas du présent tutoriel, l’enregistrement « DMARC » sera de la forme et syntaxe suivante : _dmarc.votredomaine.tld. 0 TXT "v=DMARC1; p=quarantine; rua=mailto:utilisateurprincipal@votredomaine.tld; ruf=mailto: utilisateurprincipal@votredomaine.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject" Où : « v=DMARC1 » : indique la version du protocole DMARC. « p=quarantine » : indique la politique à appliquer aux eMAILs qui échouent à la vérification DMARC Ici on souhaite que les eMAIL en échec soient placés en quarantaine afin de pouvoir les examiner. Néanmoins, vous pouvez modifier ce paramètre pour « none » ou « reject » comme expliqué précédemment. C’est vous qui voyez … « rua=mailto :utilsateurprincipal@votredomaine.tld » : indique une liste d’URI (Uniform Ressource Identifier) pour que les FAI envoient des commentaires XML. Vous noterez que ce n’est normalement pas une liste d’@MAIL. DMARC requiert simplement une liste d’URI de la forme «mailto:test@exemple.com». Ici, néanmoins j’ai fait le choix de mettre l’URL de l’utilisateur principal du NAS. Mais cela peut se discuter … « ruf=mailto :utilsateurprincipal@votredomaine.tld » : indique une liste d’URI (Uniform Ressource Identifier) pour que les FAI envoient des rapports légaux. Vous noterez que ce n’est normalement pas une liste d’@MAIL. DMARC requiert simplement une liste d’URI de la forme «mailto:test@exemple.com». Ici, néanmoins j’ai fait aussi le choix de mettre l’URL de l’utilisateur principal du NAS. Mais cela peut se discuter … « fo=1 » : indique de générer des rapports si DKIM ou SPF ne produit pas de résultat de réussite DMARC. Vous pouvez aussi utiliser les valeurs suivantes : « 0 » pour générer des rapports si DKIM et SPF échouent, « d » pour générer des rapports si DKIM a échoué ou « s » si SPF a échoué. C’est vous qui voyez … « adkim=s » : indique le « Mode d’alignement » pour les signatures DKIM, cela peut être « r » (Relâché) ou « s » (Strict). En mode Relâché, les domaines de signature DKIM authentifiés (d=) qui partagent un Domaine Organisationnel avec un domaine « From » d’eMails passeront la vérification DMARC. En mode Strict, une correspondance exacte est requise. Ici le mode strict est retenu. « aspf=s » : indique le « Mode d’alignement » pour SPF, cela peut être « r » (Relâché) ou « s » (Strict). En mode Relâché, également les domaines SPF authentifiés qui partagent un Domaine Organisationnel avec un domaine «From» d’eMAILs passeront la vérification DMARC. En mode Strict, une correspondance exacte est requise. Ici le mode strict est retenu. « pct=100 » : indique aux FAI d’appliquer uniquement la politique DMARC à un pourcentage d’eMAILs défaillants. « pct=50 » indiquera aux récepteurs d’appliquer la politique « p= » seulement 50% du temps contre les emails qui échouent à la vérification DMARC. Notez que ceci ne fonctionnera pas pour la politique « none », mais uniquement pour les politiques « quarantine » ou « reject ». Ici 100% soit tous les eMAILs sont traités. Adaptez la valeur à vos besoins … « ri=86400 » : indique l’intervalle de génération de rapports pour la fréquence à laquelle vous souhaitez recevoir des rapports XML cumulés. Ceci est une préférence et les FAI pourraient (et probablement vont) envoyer le rapport à différents intervalles (normalement ce sera chaque jour). Ici 86400 secondes soit un jour. Adaptez à vos besoins … « sp=reject » : indique la politique qui doit être appliquée aux eMAILs provenant d’un sous-domaine de ce domaine qui échouent à la vérification DMARC. En utilisant cette étiquette, les propriétaires de domaines peuvent publier une politique « générique » pour tous les sous-domaines. Ici on rejette les eMAILS concernés. Le problème de la constitution et de la syntaxe de votre enregistrement « DMARC » étant réglé, on va procéder à un contrôle des paramètres de l’enregistrement « DMARC » afin d’être sûr à 100% de sa syntaxe et donc que celle-ci est correcte. Pour ce faire, on va encore utiliser les services d’un site internet dédié : Dans un navigateur Web, rendez-vous sur le site « dmarcanalyzer.com ». (Encore le même que précédemment, on ne change pas une équipe qui gagne … 🤣) Saisissez l’intitulé de votre domaine et après avoir coché la case « Je ne suis pas un robot » et satisfait à l’éventuel Captcha, cliquez sur le bouton « Valider DNS ». Après quelques secondes d’analyse le résultat du contrôle du dossier « DMARC » de votre domaine s’affiche. Après le rappel de votre chaîne de paramètres, le détail du dossier est présenté. Il vous donne une explication de chacune des balises qui ont été utilisées. Dans le cas présent, le résultat du contrôle vous indique avoir trouvé un problème avec le dossier DMARC : « Info : Nous avons trouvé une adresse personnalisée dans votre dossier DMARC. Veuillez-vous assurer de faire suivre les rapports entrants à votre adresse personnalisée pour voir les statistiques dans . ». Rassurez-vous, cette « anomalie » n’est pas bloquante et vous pouvez considérer la syntaxe de votre enregistrement « DMARC » comme correcte. Un autre contrôle effectué via un autre site dédié tel que « mxtoolbox.com » vous en apportera la preuve si besoin en est. Donc, la syntaxe de votre enregistrement « DMARC » est validée et sans erreur, on va donc pouvoir procéder à la création de ce fameux enregistrement « DMARC » dans la zone DNS de votre domaine chez OVH. Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs étendus » sur « TXT ». Saisissez les informations suivantes : Sous-domaine : _dmarc TTL : laissez « Valeur par défaut » Valeur : « v=DMARC1; p=quarantine; rua=mailto:utilisateurprincipal@votredomaine.tld; ruf=mailto: utilisateurprincipal@votredomaine.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject» (sans les guillemets !) en remplaçant utilisateurprincipal@votredomaine.tld par la valeur d’@MAIL de votre utilisateur principal. Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « TXT » tel que : _dmarc.votredomaine.tld. 0 TXT "v=DMARC1; p=quarantine; rua=mailto:utilisateurprincipal@votredomaine.tld; ruf=mailto: utilisateurprincipal@votredomaine.tld; fo=1; adkim=s; aspf=s; pct=100; ri=86400; sp=reject" 4.2.5 Ajout d’un enregistrement TXT de type « CNAME » pour « mail.votredomaine.tld » La configuration décrite ci-après n’est à réaliser que si et seulement si vous souhaitez pouvoir accéder à l’application « MailPlus » depuis l’extérieur (à l’aide de votre reverse proxy) en saisissant un simple « mail.votredomaine.tld » dans un navigateur Web. Elle est parfaitement optionnelle (voir § 7 ci-dessous). Dans la zone DNS de votre domaine, cliquez sur « Ajouter une nouvelle entrée ». Cliquez dans la zone « Champs de pointage » sur « CNAME ». Saisissez les informations suivantes : Sous-domaine : « mail » TTL : laissez « Valeur par défaut » Cible : « votredomaine.tld. » (N’oubliez pas le « . » à la fin, c’est important !) Cliquez sur « Suivant » puis sur « Valider ». Au final, vous devriez alors avoir dans votre zone DNS un nouvel enregistrement « CNAME » tel que : mail.votredomaine.tld. 0 CNAME votredomaine.tld. Voilà, on en a terminé avec la configuration de la « zone DNS » de votre domaine « votredomaine.tld ». Vous pouvez à présent normalement vous déconnecter de votre compte OVH. 5 Finalisation de la configuration de MailPlus Server Maintenant que la partie concernant la « zone DNS » de votre domaine est claire chez OVH, on va reprendre et finaliser la configuration de « MailPlus Sever » (« MPS ») tout en sécurisant ce dernier. Pour ce faire, on va passer en revue chaque section (pas forcément dans leur ordre d’affichage dans l’interface d’administration) pour paramétrer et/ou ajuster ce qui doit l’être dans celles-ci par rapport à la configuration par défaut mise en place automatiquement lors de l’installation du package « MPS ». Notez bien que cette revue de configuration ne va pas non plus, se substituer au guide de l’Administrateur Synology « MPS » qui lui vous fournira tous les détails nécessaires pour toutes les fonctions. Un grand nombre de réglages complémentaires resteront de votre libre arbitre. 5.1 Section « Administration du serveur » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de consulter le trafic de messagerie entrant/sortant ainsi que l'état du ou des serveurs de votre système de messagerie. 5.2 Section « Surv menace » Dans notre cas cette section n’a pas d’intérêt. Vous y trouverez des statistiques détaillées de divers types, sur les menaces liées aux eMAILs entrants et sortants et leurs sources. Ces informations vous sont présentées sous forme de graphiques clairs. Ainsi leur exploitation vous permettra d’ajuster les paramètres de « MPS » de manière appropriée pour une sécurité optimale. 5.3 Section « Domaine » En principe et dans un premier temps, il n’y a rien de plus à paramétrer dans cette section qui n’ait déjà été fait lors de la phase de pré configuration de « MPS » au § 3 ci-dessus. Par contre dans un second temps, vous pourrez ici ajouter de nouveaux utilisateurs à votre serveur de messagerie en ayant au préalable pris soin de les créer comme utilisateurs locaux de votre NAS avec le même identifiant/pseudo (c’est mieux !). Cela dit, vous pourrez tout aussi bien choisir d’utiliser des utilisateurs issus d’un annuaire Active Directory ou LDAP si votre NAS est associé à l’un d’entre eux. C’est ici aussi que vous pourrez selon vos propres besoins, affiner le paramétrage de chaque utilisateur, créer des alias de regroupement d’utilisateurs (appelées aussi listes de distribution) pour l’émission/réception d’eMAILs ou encore la création de règles BCC (Blind Copy Carbone) automatiques pour par exemple sauvegarder les messages importants et ainsi protéger la confidentialité du destinataire. 5.4 Section « Distribution » Dans cette section on va paramétrer notre « facteur Internet » à savoir le protocole « SMTP » (Simple Mail Transfer Protocol) qui a en charge d’assurer la livraison/distribution des eMAILs entrants et/ou sortants de votre serveur de messagerie. Partie « SMTP » : Normalement, le protocole « SMTP » utilise trois (3) ports de communication pour fonctionner. Dans « MPS », ils sont affichés comme : SMTP (numéro de port: 25), SMTP-SSL (Numéro de port: 465), SMTP-TLS (Numéro de port: 587). Dans le cas du présent tutoriel, l’utilisation du relai SMTP d’Orange nécessite uniquement l’activation des protocoles « SMTP » et « SMPT-TLS ». En conséquence : Cochez uniquement les deux cases correspondantes : « SMTP » et « SMTP-TLS ». Nota 1 : Pour mémoire, l’usage de« SMTP-TLS » nécessite une authentification. Celle-ci sera configurée dans la section « Remise de message » au § 5.5 ci-dessous. Nota 2 : Si vous avez configuré sur votre NAS (« Panneau de configuration DSM / Sécurité / Avancé ») le « Niveau de profil TLS / SSL » sur « Compatibilité moderne » , certains clients de messagerie (par ex., Outlook 2016) peuvent s'avérer incapables d'établir des connexions en raison de ce paramètre. Dans ce cas, pour assurer une meilleure compatibilité avec les clients de messagerie, fixez alors le « Niveau de profil TLS/SSL » à « Compatibilité intermédiaire ». Vérifiez que les affectations de ports correspondantes sont bien respectivement : 25 et 587. Partie « Interface réseau » : Vérifier que l’interface « LAN1 » avec l’@IP de votre NAS (« 1.2.3.4 ») soit sélectionnée. Partie « IMAP/POP3 » : Pour l’exemple de ce tutoriel, comme l’on va faire « simple » en utilisant le client de messagerie « MailPlus » de Synology, l’activation du service POP3 n’est donc pas nécessaire. Toutefois, si vous souhaitez utiliser un client de messagerie « tiers » tel que Microsoft Outlook ou Apple Mail pour récupérer vos MAILs, alors il vous faut cocher la case « Activer POP3 SSL/TLS » pour autoriser une connexion client POP3 protégée (chiffrée) avec SSL/TLS et ainsi permettre à vos utilisateurs d'extraire des eMAILs à partir de « MPS » vers ce client de messagerie. Cochez la case « Activer IMAP SSL/TLS » pour autoriser une connexion client IMAP protégée (chiffrée) avec SSL/TLS et ainsi permettre à vos utilisateurs d'extraire des eMAILs à partir de « MPS » vers le client de messagerie (que vous utilisez) et de gérer leur boîte de MAILs. « Partie recherche en texte intégral » : Cochez cette case pour activer la recherche par mots-clés à l’intérieur de vos eMAILs. C’est une fonction utile mais qui reste cependant une option pour vous. C’est vous qui voyez … Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.5 Section « Remise de message » 5.5.1 Onglet « Général » Pour éviter que n’importe qui utilise votre serveur d’envoi de MAILs, il est nécessaire d’activer « l’authentification SMTP ». De toutes façons, cette activation est aussi implicitement requise du fait de l’usage du protocole « SMTP‑TLS » lui-même imposé par l’usage du serveur relai SMTP d’Orange nécessaire au bon fonctionnement de votre serveur de messagerie. Par ailleurs, les utilisateurs qui ne passent pas l'authentification ne pourront pas transférer leurs eMAILs. Cela empêchera ainsi votre serveur d'être inscrit sur les listes noires. Cochez la case « Activer l’authentification SMTP » Sans les identifiants de connexion, les clients d'un réseau local de « MPS » pourraient recevoir et envoyer directement des eMAILs en utilisant un terminal. Aussi par sécurité, Ignorez l'authentification pour les connexions réseau locales à partir d'un terminal. Ne cochez pas la case « Ignorer l'authentification pour les connexions réseau locales à partir d'un terminal ». Lors de l'envoi d'eMAILs, par sécurité il est préférable d’imposer à l'utilisateur connecté d’utiliser l’@MAIL d'un utilisateur qui appartient au compte de connexion et implicitement on n’ignorera pas la vérification de l’@MAIL de l’expéditeur pour voir s’il appartient au compte de connexion pour les eMAILs envoyés depuis des réseaux fiables. Cochez la case « Vérifier si les adresses e-mails des expéditeurs appartiennent aux comptes de connexion ». Ne cochez pas la case « Ignorer la vérification de l’@MAIL de l’expéditeur … ». Dans « MPS » le nom d'hôte doit être spécifié au format FQDN (« Fully Qualified Domain Name » ou nom de domaine pleinement qualifié, est un nom de domaine qui donne la position exacte de son nœud dans l'arborescence DNS en indiquant tous les domaines de niveaux supérieurs). Dans le cas du présent tutoriel il s’agit simplement de votre nom de domaine « votredomaine.tld ». « Nom d’hôte (FQDN) » : Saisissez « votredomaine.tld » Il est important ici de renseigner le champ « SMTP Banner ». Indépendamment du fait qu’il indique le texte qui s’affichera sur le terminal TELNET d’un client SMTP (information qui peut paraître optionnelle), il concourt à la note finale qui sera donnée à vos envois de MAILs lors du test final que l’on réalisera à l’issue de la configuration de « MPS » (voir § 8.1 ci-dessous). « SMTP Banner » : Saisissez « votredomaine.tld » Vous pouvez laisser tels quels (à leur valeur par défaut) les autres paramètres de nombre et de taille. Vous pouvez aussi les modifier et les adapter à vos besoins si vous savez ce que vous faites. Cliquez sur le bouton « Administrateur externe » Dans la fenêtre qui s’affiche : Cochez la case « Activer l’administrateur externe ». Il vous faut alors désigner un utilisateur (via son @MAIL) qui pourra recevoir les messages système envoyés au démon de messagerie par les administrateurs d'autres serveurs de messagerie. Sélectionnez à l’aide du popup, un utilisateur local. Cliquez sur « OK » pour valider. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.5.2 Onglet « Delivery » Comme je vous l’ai indiqué au point 4 du préambule de ce tutoriel, le serveur SMTP Orange ignore les connexions provenant d'un autre réseau si elles lui arrivent sur le port 25, ce qui donne l’impression que ce port est bloqué. Donc, pour contourner ce pseudo « blocage » du port 25, et c’est l’astuce principale de ce tutoriel, on va donc ici utiliser la particularité de « MPS » qui lui permet d’envoyer des messages via d'autres serveurs de messagerie sans être lui-même exposé à Internet ou à d'éventuelles attaques. On va donc spécifier précisément à « MPS » passer par le serveur SMTP d’Orange pour émettre vos eMAILs. Ainsi, vous n’aurez aucun risque de vous les faire rejeter. Pour ce faire : Sélectionnez l’option « Tous les messages sont envoyés via un unique hôte actif » « Serveur : » : Saisissez « smtp.orange.fr » « Port : » : Saisissez « 587 » Cochez la case : « Authentification requise » « Compte : » :Saisissez « votreidentifiantdeconnexionOrange » « Mot de passe : » : Saisissez « votremotdepassedeconnexionOrange » Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.5.3 Onglet « Relayer le contrôle » Dans notre cas cet onglet n’a pas d’intérêt. Au besoin, à vous de voir quoi en faire … 5.5.4 Onglet « Sécurité » Partie « Listes noires et blanches » : Paramétrez ou non ces listes selon vos éventuels besoins spécifiques. Partie « Stratégie de l’expéditeur » : Ici on va définir certains critères (appelés aussi « politiques ») pour rejeter les eMAILs reçus. Lorsque le nom de domaine de l'expéditeur « MAIL FROM » ne correspondra pas au format FQDN standard fixé par les RFC, les eMAILs seront rejetés. Cochez la case : « Rejeter les expéditeurs sans nom de domaine complet (FQDN) ». Lorsque « MPS » n'est pas le terminal de réception final et que le domaine de l'expéditeur de « MAIL FROM » ne correspond à aucun enregistrement DNS de type « A » ou « MX » ou lorsque l'enregistrement de type « MX » est incorrect, les eMAILs seront rejetés. Cochez la case : « Rejeter les expéditeurs utilisant des domaines inconnus ». Partie « Stratégie de connexion » : Ici on va paramétrer les critères pour rejeter les connexions client ou bloquer les adresses IP en raison d’un trop grand nombre de connexions simultanées, de messages envoyés sur une minute ou de connexions sur une minute au server de messagerie. Cochez la case : « Rejeter les noms d’hôtes de clients inconnus ». Cochez ou non les trois cases suivantes et ajustez les valeurs limites selon vos éventuels besoins spécifiques. Partie « Avancé » : Ici on va ajuster les paramètres de sécurité pour la distribution des eMAILs. Cochez la case : « Rejeter les demandes de conduite non autorisée ». Cochez la case : « Rejeter les noms d’hôtes HELO sans nom de domaine entièrement qualifiés (FQDN) ». Cochez la case : « Rejeter les noms d’hôtes HELO inconnus ». Cochez ou non les deux cases suivantes et ajustez les valeurs limites selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6 Section « Sécurité » Cette section est l’une des plus importante pour la mise en place d’une stratégie de sécurisation de votre serveur de messagerie et de ses clients. Toutefois, il convient d’être prudent et de ne pas tout activer immédiatement mais plutôt de procéder par étapes pour obtenir des réglages parfaitement ajustés à vos besoins spécifiques. En effet, des réglages d’emblée trop agressifs pourraient peut-être vous empêcher d’envoyer ou de recevoir des eMAILs de certaines personnes. Ce serait bien dommage et ce n’est pas le but de votre serveur de messagerie … On va donc ici n’activer qu’un minimum de règles d’analyses de vos eMAILs entrants. 5.6.1 Onglet « Spam » Donc à minima on va commencer par activer le moteur anti-spam. Pour mémoire, « MPS » utilise le moteur anti-spam « Rspamd » ainsi que les règles de la base de données « SpamAssassin ». Il filtre le spam en fonction de règles de correspondance du contenu et du seuil de score de spam. Lorsqu'un eMAIL correspond à une règle de détection prédéfinie, un point sera ajouté au score. Les eMAILs dépassant le seuil seront alors marqués comme « spam ». Cochez la case : « Activer le moteur anti-spam (recommandé) ». Modifiez l’intervalle de spam (en jours) ainsi que les paramètres anti-spam selon vos besoins spécifiques. Vous pouvez notamment utiliser « l’auto apprentissage » pour ajuster au mieux le seuil de score de spam. Lors de votre première activation du moteur anti-spam, la base de données des règles anti-spam a besoin d’être mise à jour manuellement. Programmez ensuite sa mise à jour automatique à l’heure de votre choix. Cochez la case : « Automatiquement mettre à jour les règles anti-spam ». Cliquez sur le bouton « Mise à jour manuelle ». L’encart « Information du le moteur » vous affichera par la suite la date de dernière mise à jour. Dans la lutte contre le SPAM il peut être aussi intéressant d’activer la protection postscreen en consultant des serveurs « DNSBL » (« DNS Black Listing ») même si ces derniers sont controversés du fait que leurs critères d’exclusion ne relèvent que de leur seul gestionnaire. Pour mémoire le « DNSBL » est une méthode permettant de consulter une liste noire d'émetteurs d’eMAILs en utilisant le protocole DNS. Aussi soyez vigilant avec l’usage de ce type de serveurs qui peuvent très bien, indépendamment de vous protéger, placer votre serveur de messagerie sur leur liste noire (vous blacklister) et donc vous empêcher d’émettre mais aussi de recevoir des eMAILs. C’est un choix donc à faire de façon très réfléchie. Encore une fois c’est vous qui voyez … Cochez la case : « Activer la protection postscreen contre les spam » et observez le comportement dans le temps et selon, décochez-la si nécessaire ensuite. Cochez ou non la case « Activer la liste grise … » selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6.2 Onglet « Antivirus » Partie « Antivirus » : Il va de soi qu’il faut activer le moteur antivirus pour assurer une protection contre les menaces de logiciels malveillants qui auraient été introduits insidieusement dans les eMAILS que vous recevez. Cochez la case : « Activer le moteur antivirus ». Sélectionnez un moteur dans le popup. Pour votre information, « ClamAV » est le système antivirus par défaut de « MPS » et en plus il est gratuit contrairement à « McAfee » qui lui est payant et pour le quel il faut souscrire un abonnement. Le moteur antivirus « ClamAV » utilise des bases de données externes pour améliorer certaines fonctions. Si vous disposez de suffisamment de mémoire installée sur votre NAS, vous pourrez utiliser sans problème la base de données « Google SafeBrowsing » afin de détecter si vos eMAILs contiennent des liens malveillants. Notez qu’il vous est aussi possible d’utiliser d’autres bases de données du même type. Cochez ou non la case « Utiliser la base de données Google SafeBrowsing » selon la capacité mémoire de votre NAS. Lors de votre première activation du moteur antivirus, la base de données des définitions de virus a besoin d’être mise à jour manuellement. Programmez ensuite sa mise à jour automatique à l’heure de votre choix. Cochez la case : « Mettre à jour automatiquement les définitions de virus ». Cliquez sur le bouton « Mise à jour du manuel ». L’encart « Informations système sur le moteur antivirus » vous affichera par la suite la date de dernière mise à jour. Partie « Actions » : Paramétrez ou non ces actions selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6.3 Onglet « Authentification » Le paramétrage de cet onglet a déjà été effectué et décrit au § 3 ci-dessus lors de la pré configuration de « MPS ». Il n’y a donc à faire de plus. 5.6.4 Onglet « Analyser le contenu » Partie « Filtre joint » : · Paramétrez ou non ces filtres selon vos éventuels besoins spécifiques. Partie « Analyser le contenu » : Là c’est évident et on n’y va pas par quatre chemins, à moins que vous ne voyiez un inconvénient à cela et donc libre à vous de faire autrement : Cochez les cases de toutes les options. Positionnez tous les popup sur la valeur « Rejeter ». Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.6.5 Onglet « Protection des données » Paramétrez ou non ces options selon vos éventuels besoins spécifiques. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. 5.7 Section « File » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de vérifier tous les eMAILs en attente d'être envoyés à d'autres serveurs, ou à renvoyer à d'autres serveurs après qu’ils aient été rejetés pour X raisons. 5.8 Section « Audit en cours » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de visualiser et configurer tous les journaux d’activité de votre serveur de messagerie. Vous y verrez tous les mails passant par votre serveur. Ces journaux vous permettront de comprendre les éventuels problèmes que vous pourriez rencontrer et ainsi de leurs trouver une solution. Vous pourrez également y générer, selon vos besoins, des rapports statistiques d’utilisation du serveur « MPS ». 5.9 Section « Licence » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de visualiser le nombre de licences i.e. le nombre d’@MAILs que vous pouvez utiliser. C’est dans cette section que vous pourrez ajouter des licences supplémentaires le cas échéant. Par défaut vous y retrouvez les cinq (5) licences gratuites associées à « MPS ». « MPS » synchronise automatiquement l'état de vos licences avec votre compte Synology. Sachez aussi les restrictions/contraintes liées à l’usage de ces clés : Une clé de licence ne peut être appliquée qu’à un seul serveur DSM à la fois. Une clé de licence ne peut être distribuée ni fournie à un tiers. Si la clé de licence n’est pas activée et qu’elle est perdue, Synology ne vous fournira aucune clé de rechange. La clé de licence et les informations de votre NAS (N° de série, @MAC et nom de modèle) sont envoyées à Synology pour validation. 5.10 Section « Compte » Avant d’utiliser pleinement « MPS », vous devez activer les comptes utilisateurs locaux à DSM qui utiliseront votre service de messagerie. Mais avant, il est nécessaire de leur donner au préalable un certain nombre de droits sur les applications « MPS » et « MailPlus », mais aussi sur le répertoire partagé qui contiendra vos boites MAIL (« Volume1/MailPlus »), faute de quoi votre utilisateur ne pourra ni envoyer ni recevoir de MAILs : Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Utilisateur ». Créez un nouvel utilisateur OU sélectionnez et modifiez un utilisateur existant (pour l’exemple ici « oracle7 »). Dans l’onglet « Permissions », dans la colonne « Lecture/écriture » cochez la case en regard correspondante de « MailPlus ». Cliquez sur le bouton « OK » pour sauvegarder vos choix. Dans l’onglet « Applications », dans la colonne « Autoriser » cochez la case en regard correspondante à « MPS » et celle correspondante à « MailPLus ». Cliquez sur le bouton « OK » pour sauvegarder vos choix. On peut maintenant effectivement activer l’utilisateur. Pour cela : Rendez-vous dans « MPS » section « Compte » onglet « Utilisateur ». Dans la colonne « Activer » cochez la case en regard correspondante de votre utilisateur. Cliquez sur le bouton « Appliquer » pour sauvegarder vos choix. Reproduisez la présente procédure pour chacun de vos utilisateurs en veillant bien à ne pas configurer plus d’utilisateurs que vous ne disposez de licences valides. De toutes façons, si vous dépassez le nombre d’utilisateurs possibles, les opérations de l'interface utilisateur de « MPS » seront restreintes et les services relatifs à la sécurité stoppés, tant que vous n'aurez pas suffisamment de clés de licence valides dans votre système de messagerie. Eh eh, ils ne sont pas idiots chez Synology … 😊 Nota : En matière de sécurité des comptes utilisateurs de « MPS », je vous renvoie vers le Tutoriel « [TUTO] MailPlus Server DSM6 » de @UnPixel qui propose une stratégie très intéressante (couplet en bleu dans le texte). Je ne vais pas vous la décrire ici mais je vous invite à la consulter voire même de l’appliquer. Pour mémoire, pour le présent tutoriel j’ai joué la carte de la simplicité en adoptant le même nom (identifiant) pour le compte eMAIL que celui-ci utilisé pour l’utilisateur local du NAS. A vous de voir et d’adapter le paramétrage des utilisateurs selon vos besoins spécifiques … Par ailleurs, si vous appliquez cette stratégie, veillez à rester cohérent avec les dispositions décrites au §4.1 ci-dessus pour la création d’une @MAIL dite de secours chez OVH. Sinon cela marchera beaucoup moins bien … 5.11 Section « Personnel » Dans notre cas cette section n’a pas d’intérêt. Elle vous permet simplement de paramétrer les options liées au transfert d’eMAILs et de réponse automatique lors de la réception de ces deniers. 6 Configuration du pare-feu du NAS et de la Box/Routeur Encore une dernière chose à paramétrer et on en aura terminé pour la configuration. En effet, pour que tous ce qui précède fonctionne correctement sans blocages, il est nécessaire d’ouvrir les ports de communication adéquats sur votre NAS ainsi que sur la Box/Routeur. Vous l’aurez sûrement deviné et compris, il s’agit d’ouvrir respectivement des ports 25 (« SMTP »), 587 (« SMPTP-TLS ») et 993 (« IMAP SSL/TLS »). Pour cela : 6.1 Pare-feu du NAS Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Sécurité / Pare-feu ». Sélectionnez votre profil actif de pare-feu et cliquez sur le bouton « Modifier les règles ». Normalement, avec l’installation de « MPS » une règle intitulée « MailPlus Server » a déjà été créée dans le pare-feu. Sélectionnez cette règle et cliquez sur le bouton « Modifier » ou 2xCliquez sur celle-ci. Dans la nouvelle fenêtre, pour la partie « Ports », cliquez sur le bouton « Sélectionner » en regard de l’item « Sélectionner dans une liste d’applications intégrées ». Assurez-vous que les lignes correspondantes des ports 25, 587 et 993 pour l’application « MPS » sont bien activées (case cochée). Nota : Si vous utilisez un autre client MAIL que « MailPlus », et que celui-ci utilise le protocole « POP3 » pour récupérer les eMAILS, il vous faudra sans doute activer aussi les lignes correspondantes pour les ports 110 (« POP3 ») et 995 (« POP3 SSL/TLS »). Référez-vous au manuel de ce client MAIL pour plus de détails. Cliquez sur le bouton « OK » pour sauvegarder vos choix. 6.2 Pare-feu de la Box/Routeur 6.2.1 Cas de la LiveBox Si votre NAS est directement connecté derrière votre LiveBox : Connectez-vous à l’interface d’administration de la LiveBox en saisissant dans un navigateur Web l’URL : http://192.168.1.1. Rendez-vous dans le menu « Réseau » / onglet « NAT/PAT » et créez les trois (3) règles de transfert de ports suivantes : 6.2.2 Cas d’un routeur Synology Si votre NAS est directement connecté derrière votre Routeur Synology : Connectez-vous à l’interface d’administration du routeur en saisissant dans un navigateur Web l’URL : http://routeur.synology.com ou en saisissant directement son @IP comme URL. Rendez-vous dans le menu « Centre réseau » / Section « Transmission de port » et créez les trois (3) règles de transmission de ports suivantes : Nota : On ne crée pas ces règles directement dans le pare-feu car il n’y a pas besoin de leur affecter une quelconque localisation. 7 Configurer le Reverse Proxy sur le NAS C’est la dernière opération de configuration mais qui reste optionnelle (d’autant plus si vous n’avez pas déjà configuré votre Reverse proxy). On va donc ici configurer une redirection du domaine de second rang « mail.votredomaine.tld » vers l’application « MailPlus ». Ainsi depuis l’extérieur, il vous sera facile d’accéder à cette l’application pour consulter et gérer tous vos eMAILs et ce à partir d’un navigateur Web en saisissant simplement : « mail.votredomaine.tld ». Pour ce faire, suivez ces deux étapes : 7.1 Configurer la zone DNS chez OVH Cette opération est décrite au § 4.2.6 ci-dessus. 7.2 Configurer le Reverse Proxy sur le NAS Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Portail des applications » o Rendez-vous sur l’onglet « Application ». o Sélectionner la ligne « MailPlus » et 2xCliquez sur celle-ci OU Cliquez sur le bouton « Modifier ». o Une fenêtre « Règles d’accès aux applications » s’ouvre. o Dans l’onglet « Général » : ▪ Cochez la case « Activer un alias personnalisé ». ▪ Cochez la case « Activer un port personnalisé (HTTP) ». ▪ Saisissez les informations suivantes : * « Alias: » : mail * « Port: » : 21680 ▪ Dans les deux cas une URL de connexion à utiliser vous est indiquée. Respectivement : * https://votreNAS.votredomaine.tld/mail/ * http://votreNAS.votredomaine.tld:21680 o Cliquez sur « OK » pour valider. Sur votre NAS Synology, rendez-vous dans DSM :« Panneau de configuration / Portail des applications / Application ». o Rendez-vous sur l’onglet « Proxy inversé ». o Cliquez sur le bouton « Créer » o Une fenêtre « Règles de proxy inversé » s’ouvre. o Dans l’onglet « Général » : ▪ Saisissez les informations suivantes : ⚠Saisissez bien les informations, les champs paraissent déjà renseignés mais en fait ce n’est que de l’affichage ! Si vous validez sans faire de saisie effective, ces champs ne seront pas renseignés. * « Description: » : MAIL Partie « Source » : * « Protocole: » : sélectionnez dans le popup l’item « HTTPS » * « Nom d’hôte: » : mail.votredomaine.tld * « Port: » : 443 * Cochez la case « Activer HTTP/2 ». Partie « Destination » : * « Protocole: » : sélectionnez dans le popup l’item « HTTP » * « Nom d’hôte: » : localhost * « Port: » : 21680 o Cliquez sur « OK » pour valider. 8 Contrôle des eMAILs de votre serveur de messagerie Votre serveur de messagerie basé sur « MPS » est maintenant configuré et opérationnel. On va donc contrôler que les eMAILs que vous allez envoyer sont corrects et qu’ils ne risquent pas d’être considérés comme du SPAM par les serveurs de messagerie institutionnels. On contrôlera également la bonne réception des eMAILs qui vous seront destinés. 8.1 Contrôle de l’envoi Pour réaliser ce contrôle d’indésirabilité de vos eMAILs, on va utiliser les services du site « mail-tester.com ». Mais avant d’utiliser les services de ce site, il vous faut savoir ceci : « Mail-tester.com » ne vous offre en tout et pour tout, le droit d’exécuter que trois (3) tests par jour. Au-delà, si vous voulez en faire plus, il vous faudra passer à la caisse ! Donc soyez parcimonieux dans son usage sinon il vous faudra prendre votre mal en patience pour rester dans le domaine du gratuit … Donc, pour tester vos eMAILs, c’est on ne peut plus simple : Copiez l‘URL qui vous est proposée en page d’accueil de « mail-tester.com ». Rendez-vous sur l’application « MailPlus » et ouvrez celle-ci depuis le bureau de DSM sur le NAS ou si vous avez mis en place le reverse proxy : tapez l’URL « mail.votredomaine.tld » dans un navigateur Web sur votre PC/Mac. Cliquez sur le bouton « Rédiger » pour créer un nouvel eMAIL. Collez l’URL de test dans la zone « A : » Saisissez un texte quelconque pour l’objet de l’eMAIL. Veillez à ne pas être trop succinct car cela pourrait affecter votre note finale. Saisissez un texte consistant dans le corps de texte de l’eMAIL. Idem veillez à ne pas être trop succinct car cela pourrait aussi affecter votre note finale. Cliquez sur le bouton « Envoyer ». Revenez sur la page de « mail-tester.com » dans votre navigateur Web. Attendez 2 à 3 secondes (le temps que l'eMAIL arrive) et cliquez sur le bouton « Ensuite, vérifier votre Score ». Et là c’est tout bon ou tout mauvais … Le résultat des différents tests réalisés par « mail-tester.com » sur votre eMAIL s’affichent avec votre note obtenue. Si vous avez suivi correctement le paramétrage que je vous ai indiqué au cours du présent tutoriel, vous devriez normalement obtenir une note de 10/10. Si ce n’est pas le cas, c’est que vous avez raté quelque chose quelque part ! A vous d’analyser le problème … Heureusement pour vous, le compte-rendu produit par « mail-tester.com » est très explicite et très bien fait. L’analyse attentive de ce compte-rendu (développez chaque item pour en consulter le détail) devrait vous donner toutes les pistes à suivre pour corriger les problèmes relevés. Cela dit, même avec une note de 10/10, tout ne sera pas passé au « vert ». Il restera certains contrôles marqués en « orange » mais qui ne sont pas bloquants pour la suite. Typiquement, le compte-rendu vous annoncera que : « Vous n’êtes pas parfaitement authentifié » « Votre message pourrait être amélioré » Donc si vous développez chacun de ces deux items pour de plus amples détails, vous constaterez : Pour le premier Item : « Votre reverse DNS ne correspond pas avec votre domaine d’envoi » : Comme je vous l’ai expliqué au point 3 ci-dessus du préambule, il faudrait pouvoir paramétrer le « rDNS » d’Orange et c’est impossible. Donc, vis à vis de ce message d’« erreur » qui finalement n’impacte pas la note finale du test, on s’en tiendra là mais sans l’ignorer toutefois. Pour le second item : « Votre message ne contient pas d'en-tête List-Unsubscribe » : Je n’ai pas trouvé (peut-être mal cherché aussi) dans la documentation ni dans l’interface de « MPS » un quelconque moyen d’introduire cet « entête List-Unsubscribe » (à moins qu’un « Initié » ne sache). Donc, vis à vis de ce message d’« erreur » qui finalement n’impacte pas non plus la note finale du test, on s’en tiendra aussi là. 8.2 Contrôle de la réception Pour contrôler la réception de vos eMAILs, il suffit de demander à des personnes ayant un compte chez les principaux FAI institutionnels, de vous adresser un eMAIL (à « utilisateurprincipal@votredomaine.tld ») et de constater ou non la bonne réception de cet eMAIL. Dans le cas d’une non réception (ce qui serait tout de même étonnant si vous avez suivi correctement le présent tutoriel), vous pouvez toujours commencer par vérifier que votre serveur de messagerie n’est pas tout simplement quelque part sur liste noire. Pour cela, consultez notamment le site « spamhaus.org » en testant tour à tour votre « @IP externe » et votre « domaine.tld ». Vous saurez immédiatement si vous êtes ou non sur une liste noire quelque part. A vous alors, de vous rendre sur le site en question, pour trouver la procédure spécifique qui vous fera faire sortir de leur liste noire. ⚠Pour être totalement honnête, il vous faut savoir qu’il se produit parfois d’une façon encore inexpliquée à la date de la présente rédaction, une activation des serveurs de secours d’OVH que je qualifierai d’intempestive. Cette « anomalie », ayant été récemment relevée par quelques « initiés », a pour conséquence que les eMAILS, ayant pour origine certains FAI, ne sont pas récupérés sur la boite MAIL de votre utilisateur « principal » par votre serveur de messagerie. Rassurez-vous, ces eMAILs qui vous étaient destinés, ne sont pas perdus ! Les serveurs d’OVH que l’on utilise normalement en secours, ont simplement pris la main et ont redirigé ces eMAILS vers la boîte MAIL dite de secours que l’on a configurée à cet effet chez OVH (comme quoi cette fonction de secours que l’on a mise en place, fonctionne bien !). Sachez que vous pourrez donc toujours consulter et gérer ces eMAILs, mais pour cela, il vous faudra vous connecter à votre compte OVH. Il est vrai que cela pourrait vite devenir une contrainte si l’on ne trouve pas une solution à ce problème (on y travaille …). Par ailleurs et bien heureusement, le problème ne concerne que quelques FAI (ce qui est étonnant, c’est que ce n’est pas forcément les mêmes FAI d'un utilisateur à l'autre), ce qui en soi, est un moindre mal et donc heureusement pas totalement bloquant, si je peux m’exprimer ainsi. J’espère toutefois que la connaissance de cette anomalie, ne « refroidira » pas certains dans leur volonté d’appliquer le présent tutoriel pour mettre en place leur propre serveur de messagerie. Forcément, une solution sera trouvée à terme … Voilà c’est fini ! Vous pouvez souffler. Cela a été un peu long mais avec un minimum d’attention cela ne devrait pas vous avoir posé de problèmes. Beaucoup d’explications vous ont été fournies à propos des différents concepts abordés. J’espère en cela ne pas avoir été trop confus mais surtout que vous aurez bien pris le temps de toutes les lire et de les assimiler ! J’estime personnellement que c’est un passage obligé pour que vous compreniez parfaitement ce que vous faites et à terme que vous maîtrisiez votre serveur de messagerie. Remplir les cases « bestialement » ne vous aurait rien apporté au bout du compte si ce n’est des messages d’erreurs et une sérieuse prise de tête pour les résoudre. C’est quelque part le prix à payer pour être vraiment autonome de ce point de vue. Maintenant vous êtes seul propriétaire de vos choix et décisions … Ce tutoriel n’est jamais qu’un guide pour vous aider à configurer « MPS », mais comme vous avez pu le constater, il vous laisse souvent et largement toute la latitude nécessaire pour répondre à vos propres besoins spécifiques. Sachez enfin que depuis que j’ai mis en place cette configuration (cela fait bientôt 3 mois), je n’ai eu à faire à AUCUN problème d’eMAIL spammé et/ou d’@IP blacklistée pour le serveur de MAILs. Je dispose donc, comme vous maintenant, de mon propre système de messagerie et cela en totale autonomie. Donc pour moi le but initial, de ce point de vue ainsi que sur l’aspect technique avec cette contrainte initiale d’@IP externe « dynamique », est atteint et c’est le plus important 😊😊😊 Le fichier « .pdf » de ce tutoriel : [TUTO] Configuration MailPlusServer avec une @IP dynamique_20200616.pdf Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Cordialement Oracle7😉

Bonjour à tous, J'ai un petit souci qui semble ne pas être grand chose mais qui m'agace gentillement, et que je n'ai pas résolu malgré le fait que j'y ai passé quelques heures... J'ai un NAS Synology branché en Ethernet à ma LiveBox. Depuis mon ordi portable (sous Win11, via WiFi), j'arrive à accèder à l'interface de gestion de mon NAS (via l'IP locale 192.168.1.38:5000) depuis un navigateur Or, quand j'essaie d'accèder à ce même NAS depuis Windows (via le réseau ou un raccourci que je créé), impossible d'y accéder. Pourtant: - Windows détecte bien mon DiskStation, il apparaît dans les équipements réseaux (mais quand je double clique dessus, erreur: Windows ne peut accéder à [Nom du Diskstation]) - mon NAS est bien trouvé par le Synology Assistant - Comme précisé auparavant, j'arrive à y accèder via mon navigateur et son IP locale, et je peux parfaitement le manager - Je ne pense pas que le problème vienne d'un problème de redirection de port configuré sur ma LiveBox - Dans l'interface de gestion du DiskStation, je suis en configuration manuelle https://ibb.co/ZGP6vZw - J'ai un autre ordi (un fixe, qui tourne sur Win11 également, mais branché en filaire sur le réseau) et je n'ai pas ce problème, je peux bien accéder aux répertoires partagés de mon NAS depuis Windows Bref je suis un peu dérouté, si vous avez quelques pistes je suis preneur 🙂 Merci !

le 13 février 20242 a
40 réponses

Bonjour à tous, Nous somme de plus en plus nombreux à posséder une seedbox pour stocker et diffuser plein de choses qui regarde que nous, mais dernièrement j'ai cherché à transférer du contenue de ma seedbox vers mon nas et le seul moyen que l'on m'a conseiller c'est un client ftp en ligne de commande sur mon nas ou de passer par mon PC Comme j'administre ce genre de tache à distance quand j'y pense c'était pas super pratique Mais j'ai trouvé une solution pour le faire depuis l'interface web du syno et pareille pour la seedbox Prérequis -Downloadstation installer -gestion à distance du NAS via le client web possible -une seedbox Tout d'abord il faut récupter l'adresse ftp de la seedbox. ftp://front75.seedbox.co Vous enregistrer la pages dans vos favori et vous aller modifier votre url pour avoir une adresse dans ce style ftp://votrelogin:%votremotdepasse%@front??.seedbox.co ou les ?? sont les numéros de votre front Vous enregistrez tout les modifs, et quand vous cliquer sur votre favoris, vous arrivez normalement dans le répertoir index de votre serveur ftp Il ne vous restes plus qu'à faire un clique droit sur le fichier que vous voulez charger sur votre syno puis copier l'adresse du lien Sur votre interface syno vous ouvrez download station Cliquez sur ajouter vous coller l'url qui va être du type ftp://votrelogin:%votremdp%@front71.seedbox.co/Helix%film%de%vacance.mkv choisissez la destination du fichier Penser a vérifier le mdp, car il rajoute des % et si vous ne les enlevez pas vous aurez un message d'erreur Et voilou, normalement votre fichier charge, mais il ne sera visible qu'une fois completer, avant il est charger dans un fichier temp je ne sais plus où. En espérant en avoir dépanné quelques uns avec cette bricole. Bonne journée

le 17 février 201412 a
27 réponses
1

Bonjour tout le monde, J'ai l'impression qu'il y a pas mal de monde intéressé par la possibilité d'utiliser un NAS Synology pour faire du Reverse proxy (depuis DSM 6.0). Je voulais ajouter ma pierre à l'édifice en complétant les tutos réalisés, sur ce topic ou ailleurs. Tout d'abord, je voulais remercier InfoYann pour son tuto et ses réponses à mes questions. Merci également à Fender, qui a écrit le 1er tuto sur le sujet. Pour finir, merci à Fenrir, pour son méga tuto de sécurisation d'un NAS (une vraie bible...), qui aborde le sujet du reverse proxy. LE REVERSE PROXY DE A à Z I. Utilité et intérêt d'un Reverse proxy Un Reverse proxy redirige des noms de domaines vers des équipements présents sur le réseau local ou des applications présentes sur le NAS. Cela permet de ne pas avoir à retenir et taper le port des différents services pour y accéder. Par conséquent, ça évite d'avoir à ouvrir sur l'extérieur autant de ports que de services : on se sert juste du port utilisé par défaut pour les connexions HTTPS, le port 443. Par exemple, si on a affecté le port 45000 à Audio Station et le 45001 à Video Station, il faut normalement taper https://nomdedomaine.fr:45000 ou https://nomdedomaine.fr:45001 pour accéder à ces 2 services. Ce n'est pas très explicite, et il faut que les ports 45000 et 45001 soient ouverts sur le routeur. Plus y il y a de services, pire c'est. Grâce à un reverse proxy, on se contente de taper https://music.nomdedomaine.fr ou https://video.nomdedomaine.fr, et tout passe par le port 443 utilisé par le protocole HTTPS. C'est beaucoup plus simple. Pour plus d'infos, consultez ce tuto et celui-là. Par contre, il faut absolument préciser https dans l'URL, sans quoi on utilise le HTTP par défaut et ça ne marche pas. Pour éviter ce problème, on va mettre en place une redirection automatique grâce à Web Station. II. Configuration du nom de domaine chez le registrar Je prends le cas d'une IP fixe car j'ai la chance de ne pas être confronté au problème des IP dynamiques ! Avoir son nom de domaine (NDD) va nous permettre d'accéder à notre réseau local depuis Internet. Une fois le NDD loué, il faut ajouter 2 entrées dans sa zone DNS : - une entrée de type A qui redirige le NDD vers l'IP fixe de la box (ndd.fr. => IP fixe) - une entrée de type CNAME qui redirigera l'ensemble des sous-domaines vers le NDD (*.ndd.fr. => ndd.fr.) Après cette étape, les tentatives de connexion à fichiers.ndd.fr, video.ndd.fr,… seront acheminées à la box. III. Configuration du routeur De l'extérieur, on a besoin que le port 443 soit ouvert pour pouvoir se connecter aux applications du NAS de manière simple (pas de port exotique à préciser) et sécurisée (car 443 = HTTPS). Let's Encrypt se connecte par le port 80 pour délivrer le certificat SSL et pour le renouveler. De plus, si on profite de Web Station pour créer un site web, il faut également ouvrir le port 80 pour autoriser les connexions à ce site en HTTP. Donc on va utiliser les ports externes 80 et 443. Du côté du NAS, le Reverse proxy "écoute" sur le port 443 ou sur le port DSM sécurisé. Vu que je ne trouve pas souhaitable d'exposer DSM sur internet, les connexions sécurisées seront redirigées vers le port 443 du NAS. Web Station utilise le port 80. On va donc rediriger les connexions externes non sécurisées vers le port 80 du NAS. En résumé, sur le routeur, il faut rediriger les ports externes 80 et 443 vers les ports internes 80 et 443 du NAS. Après cette étape, les connexions utilisant les ports 80 et 443 seront acheminées de la box au NAS. IV. Configuration du pare-feu du NAS Pour que les connexions ne soient pas rejetées par le NAS, il faut modifier son pare-feu. Plutôt que d'ouvrir complètement les ports 80 et 443 : - on ouvre les ports 80 et 443 pour le trafic en provenance de France, pour limiter les risques d'attaque. - on ouvre également le port 80 pour le trafic venant des 2 IP que Let's Encrypt utilise pour le renouvellement du certificat (64.78.149.164 et 66.133.109.36, cf ici). Correction de la modération : ces IP ne sont plus valides. Pour la création ou le renouvellement de vos certificats, vous pouvez suivre les explications données plus loin, ou vous référer aux différents tutos qui traitent de cette question, ou bien encore utiliser le certificat fourni par Synology pour votre nom de domaine personnalisé (xxxx.synology.me) Ces règles sont à entrer dans le pare-feu du NAS (panneau de configuration/Connectivité/Sécurité/onglet "Pare-feu", puis "Modifier les règles"). NB : Les IP utilisées par Let's Encrypt peuvent changerLes IP ci-dessus ne sont plus valides. Il est donc conseillé d'ouvrir complètement le port 80 (au moins pour le trafic en provenance des Etats-Unis) avant la demande initiale de certificat ou en cas de problème de renouvellement de celui-ci. Après cette étape, les connexions pourront parvenir jusqu'au Reverse proxy du NAS (et jusqu'à WebStation). V. Configuration du portail des applications de DSM Il faut d'abord définir les ports HTTP qui seront utilisés par les applications auxquelles on veut accéder depuis l'extérieur. Pour ça, aller dans le panneau de configuration/Applications/Portail des applications/onglet "Application". NB : Il n'est pas nécessaire de définir un port HTTPS pour les applications vu que la connexion est déjà en HTTPS jusqu'au reverse proxy. En effet, il est inutile et contre-productif de doubler les chiffrements. Après cette étape, si on tape IP_locale_du_NAS:45000, on ouvre directement Audio Station. Il faut ensuite définir le reverse proxy à proprement parler, à savoir faire correspondre les différents sous-domaines avec les différentes applications. Ça se passe sur la même page, dans l'onglet "Proxy inversé". Pour chaque application, il faut renseigner : - la source (nom du sous-domaine, protocole (HTTPS) et port (443)) - la destination (nom d'hôte (localhost quand l'appli est sur le NAS, IP s'il s'agit d'un autre élément du réseau), protocole (HTTP) et port (défini à l'étape précédente)). NB : On utilise "localhost" pour désigner le NAS, car si celui-ci change d'IP, on n'aura pas besoin de reparamétrer le reverse proxy. Il faut activer le HTTP/2. Par contre, je déconseille le HSTS (c'est le navigateur qui enregistre cette information et il ne laissera plus passer autrement qu'en HTTPS, même si ce dernier est coupé). Après cette étape, quand on tape https://music.ndd.fr, on est bien redirigé vers audio station, mais avec un avertissement de sécurité du navigateur comme quoi la connexion n'est pas sûre. VI. Obtention du certificat SSL pour le domaine et ses sous-domaines Il ne faut jamais utiliser de certificat auto-signé (comme celui installé par défaut dans la plupart des équipements), tout comme accepter des exceptions de sécurité (peut provoquer des interceptions de données même sur des sites protégés par de vrais certificats). Le mieux et le plus simple est de se tourner vers une autorité de certification comme Let's Encrypt, bien intégrée chez Synology. Dans le panneau de configuration de DSM, partie "Connectivité", section "Sécurité", onglet "Certificat", cliquer sur le bouton "Ajouter". A la 2e étape, choisir de se procurer un certificat auprès de Let's Encrypt. A la 3e étape, remplir le NDD et l'adresse mail. Dans le champ "Autre nom de l'objet", mettre le nom de tous les sous-domaines, séparés par des points-virgules. Enfin, cliquer sur "Appliquer". Après cette étape, le reverse proxy fonctionne sans avertissement de sécurité. Cependant, quand on tape music.ndd.fr dans un navigateur, celui-ci ne nous redirige pas automatiquement vers https://music.ndd.fr. A la place, il nous renvoie vers ndd.fr:port_DSM_non_sécurisé (même si la connexion n'aboutit pas). Le registrar ne peut pas mettre en place de redirection car seul le nom de domaine est loué chez lui, aucun site n'est hébergé. L'option de redirection présente dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM n'est pas envisageable car elle casse le mécanisme du reverse proxy. Pour éviter ça, on va créer un site web. Ça nous permettra la création d'un fichier .htaccess, qui redirigera automatiquement les requêtes en HTTPS. VII. Auto-hébergement d'un site web et mise en place des redirections Il faut installer Web Station. Une fois que c'est fait, ouvrir l'application. Dans la partie "Statut", il faut installer les 2 versions du serveur HTTP Apache et les 2 versions de PHP. Pour ça, cliquer sur les icônes de raccourci présentes dans la colonne "Gestion". Une fois que c'est fait, on passe à la partie "Paramètres généraux". On sélectionne les versions les plus récentes d'Apache et de PHP, puis on coche la case "Activer un site web personnel" (ce n'est possible que si on a installé les 2 versions d'Apache et de PHP à l'étape précédente). On n'a pas besoin de changer les paramètres PHP ou de créer un Virtual Host (à moins d'avoir plusieurs sites web à héberger sur le même NAS). Avec l'installation de Web Station, un dossier Web a été créé à la racine du volume. Le fichier index.html est la page d'accueil du site hébergé sur le NAS. On peut en profiter pour modifier ce fichier afin que notre page d'accueil présente plusieurs liens permettant de se connecter aux différents services présents sur le NAS. Pour mettre en place la redirection automatique, il faut créer un fichier .htaccess. Pour ça, il faut créer un fichier texte dans le dossier Web. A l'intérieur de ce fichier, on écrit le code suivant : RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} On enregistre sous ".htaccess" (donc sans nom mais juste avec l'extension htaccess). Il faut ensuite redemander un certificat à Let's Encrypt, en ajoutant www.ndd.fr dans le champ 'Autre nom de l'objet" (en plus des noms de tous les sous-domaines). Après cette étape, quand on tape music.ndd.fr dans un navigateur, celui-ci nous redirige automatiquement vers https://music.ndd.fr. NB : Il faut préciser le port 443 dans le formulaire de connexion des applications mobiles, sans quoi elles n'arrivent pas à se connecter (donc music.ndd.fr:443 et non music.ndd.fr pour se connecter à DS Audio). Voir un retour intéressant ici, concernant le reverse proxy et la certification par Let's Encrypt. Si quand on tape ndd.fr on est redirigé vers l'interface de connexion à DSM (ce que je ne veux pas), il faut vérifier que la case "Activer un domaine personnalisé" dans le panneau de configuration/Connectivité/Réseau/Paramètres de DSM est décochée (ou bien qu'on a mis un autre nom de domaine que ndd.fr dans ce champ, cf tuto DNS Server). Par contre, pour se connecter à l'interface de gestion du NAS, il faudra désormais taper l'IP locale du NAS + le port DSM non sécurisé dans la barre d'adresse du navigateur (à moins d'avoir mis en place une zone DNS locale, avec une adresse comme nas.super_nom.lan qui pointe sur le NAS). J'espère que ce tuto vous sera utile. Je suis preneur de tout retour, remarque ou suggestion !

le 20 février 20188 a
1895 réponses
14

Bonjour, les paquets WordPress disponibles avec nos NAS Synoogy (DSM 6) permettent de simplifier la mise en place d'un site web sur la base de ce CMS. Les procédures associées automatisent les différents liens techniques entre les briques logicielles requises. Cependant, les dépendances associés (version PHP, serveur apache) peuvent en dérouter certains, soucieux de : disposer d'une version PHP à jour éviter une couche logicielle supplémentaire pour le serveur web sachant que nos NAS fonctionnent nativement sur serveur web NGINX. Ce TUTO est fait pour : permettre une installation manuelle de WordPress sur la base du serveur natif installé sur nos NAS (NGINX) sans recourir (autant que possible) à d'autres paquets tels que PhPMyAdmin pour les éléments requis en lien avec la base de données MariaDB 10 PRÉ-REQUIS Quelques connaissances techniques générales sur le CMS wordpress (composants techniques, installation et fonctionnement général) quelques notions Linux (en shell) pour passer des commandes en accès SSH quelques notions SQL pour créer les éléments requis (user privilèges et base de données) pour l'utilisation du CMS WordPress disposer d'un utilisateur associé au groupe administrator pour passer les commandes citées et bien sur.. d'un NAS Synology sous DSM 6 et > (version utilisée pour la création du tuto - DSM 6.2.2-24922 Update 4) de notions avancées dans le paramètrage et l'administration de son NAS (sécurité et certificat) Par ailleurs, il est entendu que : un NDD (en propriété directe - chez un registar comme OVH ou autre - ou via un fournisseur gratuit comme Synology -NDD.synology.me par exemple) est créé les ports idoines pour un accès web de l'extérieur sont routés vers le NAS (à minima 443 et 80)* service WebStation installé, dossier web présent, site web accessible - ie ce qui est disponible sous ce dossier est visible en tant que pages html de l'extérieur ou à minima via un simple navigateur internet - (*) Si l'on souhaite accéder au site WordPress depuis l'extérieur. Cf d'autres tutos sur l'accès externe et la sécurité. Structure , modalités et "AVERTISSEMENTS" Afin d'éviter un long et très (trop) détaillé sujet, j'ai volontairement limité les actions, inclus des étapes de contrôle - ie si l'étape -1 n'est pas OK.. inutile de poursuivre... - et des images écrans, afin de rendre je l'espère, plus accessible l'ensemble pour le plus grand nombre, mais: l'ensemble des actions demeurent sous la responsabilité de celui qui les réalise. une telle installation même si elle n'enfreint pas les licences logicielles de nos NAS Synology ni des composants tiers utilisés, sort du cadre d'assistance potentielle dispensée par Synology. en clair en cas de problème y compris sur un autre sujet avec votre NAS, ils peuvent vous demander de revenir en arrière sur cette installation - jamais eu le cas de figure mais ils ont le droit - une mise à jour DSM peut changer certains éléments techniques paramétrés ainsi et "casser" l'installation - là encore, situation pas rencontrée suite à différentes MAJ réalisées.. Mais ça peut arriver 0- PAQUETS A INSTALLER WebStation est installé (sans paramètrage particulier) et à la saisie du NDD de votre NAS (pas de proxy ou dans ce cas il faut un NDD ou sous domaine pour votre site web) vous devez arriver à cette page (ou à minima http://ip_du_NAS) Récupérer la dernière version de WordPress depuis le site https://fr.wordpress.org/download/ déposer ce paquet dans le dossier web du NAS via FileStation. Décompresser l'archive - on doit avoir un dossier wordpress à la racine du dossier web. (A noter si plusieurs sites indépendants souhaités, on indice le dossier ou on le renomme) MariaDB 10 paramètré comme suit Avec un mot de passe définit pour root (l'admin de la base de données globale) PHP dernière version si pas déjà présent Optionnel mais pratique : l'éditeur de texte. Par défaut on suppose que les paquets sont installés sur le Volume1 du NAS. (à adapter par la suite si différent) Sur sa machine (PC sous Windows ou macOS ou Linux) Terminal pour accéder en mode SSH au NAS ou via un logiciel comme Putty pour Windows. Pour un accès SSH : Admin du NAS Panneau de configuration Terminal SNMP on coche l'accès qui va bien et les paramètres par défaut comme suit (sinon on adapte..) optionnel : un requeteur SQL si vous souhaitez effectuer des requêtes distantes (en réseau local) sur votre Base De données, par exemple HeidiSQL pour Windows ou Sequel Pro pour macOS 1 - CREER BASE DE DONNEES ET USER Dans cette étape, via l'accès SSH linux au NAS on entre dans l’interpréteur SQL de MariaDB pour créer la base de données pour WordPress et l'utilisateur administrateur pour cette base. Les étapes sont des commandes à saisir (les exemples ci-dessous peuvent être copiés mais doivent selon les cas adaptées) Attention la saisie du mot de passe n'est pas affichée : surveillez votre saisie. Accès SSH au NAS (via Terminal ou Putty selon la plateforme utilisée) passage en mode root sudo -i Appel de l'interpréteur Mysql de MariaDB /usr/local/mariadb10/bin/mysql -uroot -p Le mot de passe demandé ici est celui de root de MariaDB définit sur l'admin du NAS en amont. Création de la base de données pour WordPress : CREATE DATABASE BDmonsite; Création de l'utilisateur Admin de cette base : CREATE USER 'BDmonsite_admin'@'localhost' IDENTIFIED BY 'MAJmin&123'; BDmonsite_admin est le nom de cet utilisateur autorisé en local (localhost) ie depuis le NAS lui même avec MAJmin&123 comme mot de passe - Il faut respecter les exigences de mot de passe MariaDB 8 caractères Maj Min chiffres et symbole. On donne les droits d'administration à cet utilisateur sur la base concernée : GRANT ALL PRIVILEGES ON BDmonsite.* TO 'BDmonsite_admin'@'localhost'; Maintenant, pour que les nouveaux droits attribués soient pris en compte, il est nécessaire de lancer la requête FLUSH. FLUSH PRIVILEGES; [ Optionnel ] Vérifier la prise en compte des paramètres passés : SHOW DATABASES; SELECT User, Host FROM mysql.user; [optionnel +] créer un super utilisateur pour une utilisation sur réseau local via un requeteur SQL CREATE USER 'supermoi'@'192.168.1.%' IDENTIFIED BY 'MajMin#&987aliasroot'; Utilisateur 'supermoi' avec mot de passe 'MAjMin#&987aliasroot' autorisé depuis le réseau local. (A adapter selon le masque réseau chez vous - peut être limité à une IP ou ouvert au grand vent par % seul) Lui donner les droits complets GRANT ALL PRIVILEGES ON *.* TO 'supermoi'@'192.168.1.%'; On confirme FLUSH PRIVILEGES; On quitte MySql de MariaDB exit 2 - Créer l'hôte virtuel dans WebStation Admin du NAS, WebStation Vérification paramètrages : PHP dernière version et serveur web NGINX Adaptation du paramètrage PHP, on modifie le profile par défaut On s'assure que le cache PHP est activé ainsi que les plugins requis. (merci @Mic13710) ) Puis, on adapte le profil PHP pour certains items Sauf cas particulier pour un thème avancé ou si plusieurs sites WordPress, on peut dans ce cas, pour chaque hôte, spécifier le profile PHP utilisé. Il faut préciser le port et le chemin de la pile TCP utilisée par PHP pour MariaDB. Paramètres PHP Modifier le profil par défaut Onglet coeur filtrer sur mysqli saisir les valeurs (selon paramètrage MariaDB sur NAS) mysqli.default_port –> 3307 mysqli.default_socket –> /run/mysqld/mysqld10.sock Création de l'hôte virtuel pour le site utilisant WordPress monsite.fr représente le NDD ou sous domaine pour accéder au site wordpress. Pour le serveur c'est NGINX et pour PHP le profile par défaut paramètré. Pour l'accès en SSL : - HSTS pour la couche SSL (suppose un certificat associé) Optionnel : - HTTP/2 pour limiter l'usage de la bande passante (- vaste débat, longtemps décrié et sujet à des failles de sécurité aujourd'hui corrigées -) A Vérifier : En théorie DSM vous informe que pour gérer cet hôte virtuel le groupe http doit passer en écriture sur le dossier web. Si ce n'est le cas vérifier ce point dans l'administration du NAS. Requis si vous souhaitez pourvoir faire une MAJ de votre CMS et de ses plugins automatiquement (en cas contraire il faut mettre en place un lien ftp) 3 - Mise en conformité du certificat SSL avec le NDD utilisé pour le service web. Lors de la création de l’hôte virtuel, le certificat par défaut du NAS est associé. Si le NDD du site est différent du NDD du NAS il faut associer le certificat SSL en conséquence. (suppose qu'il est créé...) Admin du NAS panneau configuration sécurité onglet certificat Configurer associer site avec son certificat i.e : mon nas est mondomaine.com, mon site web siteweb.mondomaine.com. Mon certificat mondomaine.com est associé à siteweb.mondomaine.com. Dans la sécurité j'associe le bon certificat avec le bon domaine. Le siteweb n'apparait ici que si l'hôte virtuel est créé en amont. 4 - Adaptation spécifique pour WorpRess et serveur NGINX Afin d'éviter la mauvaise getion des erreurs 404 sur WordPress et autoriser le changement des permaliens, il faut ajouter manuellement un fichier de configuration NGINX dans un dossier créé par WebStation. a) Création du fichier a-1)) Copier le texte suivant : (ou récupérer le ici) location /{ try_files $uri $uri/ /index.php?$args; } a-2) Connexion au NAS, Editeur de texte, Fichier Nouveau fichier enregistrer format text codage UTF8 sous le nomdans le dossier web du NAS user.conf.wordpress-permalink b) Identification du dossier réceptacle de ce fichier selon les paramètres de WebStation accès SSH au NAS passage en mode root (sudo -i) on localise les dernieres lignes du fichier de configuration concerné : ATTENTION : depuis la version DSM7 le chemin pour localiser le fichier server.webstation-vhost.conf est : /etc/nginx/sites-enabled/. ATTENTION : depuis la version DSM7.2 dans ce dossier on trouve de configuration de webstation comme par exemple : webservice_portal_2000bf3a-bb82-4d3e-9b59-ab7f2258747d webservice_portal_3c616e71-dc68-457e-8d42-ed8428a5c2ba chacun représentant les services ajoutés. Il convient de lire le contenu de ces fichiers pour localiser le dossier vers lequel on trouvera le fichier de configuration indiquant le dossier où le fichier permalink est requis. More webservice_portal_3c616e71-dc68-457e-8d42-ed8428a5c2ba aficche toutes les informaitons le début permet de vérifier qu'on est sur le bon nom de domaine : ligne server_name : machintruc.com la dernières lignes le dossier dans lequel il faut ensuite se rendre include conf.d/.service.6bdb4391-b794-4c12-a94a-e9dd73c13169.383d4d42-325d-4b78-92e3-6ec9a3120b2f.conf*; ici le fichier est caché (débutant par un point) - .service.6bdb4391-b794-4c12-a94a-e9dd73c13169.383d4d42-325d-4b78-92e3-6ec9a3120b2f.conf*; AVANT DSM 7 tail /etc/nginx/app.d/server.webstation-vhost.conf Dans cet exemple le chemin est : /usr/local/etc/nginx/conf.d/3c616e71-dc68-457e-8d42-ed8428a5c2ba. en lien avec le NDD.COM correspondant au site web créé dans WebStation. A noter : si plusieurs sites Virtuels faire la commande MORE ou CAT et localiser selon le NDD concerné par cet hôte virtuel. c) copie du fichier issu du dossier web vers ce dossier (pour éviter des erreurs on le fait en 2 temps pour s'assurer d'être à destination en 1er lieu) Pour DSM avant 7.2 se déplacer dans ce dossier cd /usr/local/etc/nginx/conf.d/3c616e71-dc68-457e-8d42-ed8428a5c2ba copier le fichier issu du dossier web dans ce dossier cp /volume1/web/user.conf.wordpress-permalink user.conf.wordpress-permalink Bien respecter la syntaxe, partant du postulat que le dossier web est sur le volume1 [optionnel] Vérifier la présence du fichier ls On redémarre le serveur NGINX pour la prise en compte de cet ajout nginx -s reload DEPUIS DSM 7.2 se rendre dans le dossier /etc/nginx/conf.d faire un ls -a (pour affichier les dossier/fichiers cachés) MORE .service.6bdb4391-b794-4c12-a94a-e9dd73c13169.383d4d42-325d-4b78-92e3-6ec9a3120b2f.conf affiche le contenu du fichier de configuration (localisé précédement) et en dernière ligne le dossier où l'on va copier notre fichier pour les permaliens exemple : include /usr/local/etc/nginx/conf.d/383d4d42-325d-4b78-92e3-6ec9a3120b2f/user.conf*; ouf il est enfin localisé ! on peut le créer mkdir /usr/local/etc/nginx/conf.d/383d4d42-325d-4b78-92e3-6ec9a3120b2f se rendre dans ce dossier pour y copie rle fichier permalink cd /usr/local/etc/nginx/conf.d/383d4d42-325d-4b78-92e3-6ec9a3120b2f cp /volume1/web/user.conf.wordpress-permalink user.conf.wordpress-permalink On redémarre le serveur NGINX pour la prise en compte de cet ajout nginx -s reload Vous pouvez supprimer le fichier user.conf.wordpress-permalink situé en dossier web. Vous n'êtes ammenés à refaire cette manipulation que dans le cas où vous crééer un nouvel hôte virtuel dans WebStation - pour le CMS WordPress- (sinon mettez le de côté mais hors le dossier Web) 5 - Appropriation du dossier wordpress de Web par le groupe http Le groupe http est le groupe d'autorité du NAS pour le serveur web NGINX (avec droits d'écriture sur le dossier web dans l'admin du NAS). Afin que les mises à jours WordPress puissent se faire, on confirme l'appropriation du dossier concerné par ce groupe (possible via FileStation dans les propriétés du dossier) Toujours en accès SSH root, saisir les commandes suivantes : Déplacement dans le dossier web cd /volume1/web Appropriation des droits sur le dossier et ses sous-dossiers et contenu par groupe et user http. chown -R http:http wordpress Fin de l'accès SSH On peut quitter le mode SSH (exit 2 fois, - 1x pour la sortie du mode root, 1 x pour la sortie de l'utilisateur connecté) Dans l'admin du NAS on désactive l'accès SSH (Admin du NAS, Panneau de configuration, Telnet SMNP on décoche l'accès SSH) 6 - Installation de WordPress Via un navigateur web, saisir l'adresse du NDD utilisé pour ce site web, on bascule en installation de WordPress. Il faut définir le nom de la base, l'utilisateur administrateur de cette base le mot de passe associé Autant d'informations connues en amont. [ ici BDmonsite, BDmonsite_admin et son mot de passe MAJmin&123 ] 7- Vérifications Au delà du fonctionnement nominal d'accès au site wordpress ainsi créé, il faut s'assurer que : Mise à jour possible Dans WordPress, administration on fait une réinstallation de WordPress PAR Wordpress Modification des permaliens opérationnel Après avoir ajouté un article on vérifie qu'on y accède Puis dans l'admin de WordPress on change le règlage des permaliens et on vérifie qu'on accède toujours à l'article selon la nouvelle dénomination.

le 18 mars 20206 a
125 réponses

PHP 8.4 : installé et paramétré sur Synology Web Station PHP 8.2 : obligé de le garder pour Synology Calendar PHP 8.1 : désinstallé sans problème Par contre, par défaut les FPM des PHP sont différents (là ça me dépasse, je laisse comme ça 😅). Et oui, reverse proxy toujours OK de mon côté 😅 (je suis sur un DS418). Dans Web Station j'ai tout basculé sur le PHP 8.4.

le 3 avrille 3 avril
1895 réponses

Question, chez moi j'ai un Non de Service web bizarre Du type : Toto_/volumeX/web_xxxxxxx Ca va pas pose un souci ? sachant qu'il est déjà notifier en rouge avec comme recommandation comme quoi le nom ne peut pas commencer par un tiret ou un caractère de soulignement

le 8 avrille 8 avril
1895 réponses

Bonjour, EDIT 20/06/2021 §4 : Complément à la commande de création du certificat suite aux récentes évolutions du Shell script ACME. §6 : Ajout lié au renouvellement. Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu. EDIT 10/01/2021 § 5.1 : Ajout d’une astuce évitant un problème de renouvellement lié au cookie DID de la double authentification. EDIT 21/08/2020 § 6 : Évolution du script Python pour être aussi compatible de la dernière et actuelle version du langage Python : version 3.x.x § 10 : Mise à jour du texte d’aide associé à l’option « -h ». Suppression des fichiers de trace « cleanlog » et « cleanlogerr » qui n’apportaient rien de plus à la trace existante. Remaniement du fichier de trace pour que soit généré un nouveau fichier à chaque exécution du script. On dispose ainsi d’un historique « tournant » basé sur 9 fichiers : « acme_renew_python.log.1 » à « acme_renew_python.log.9 ». Le fichier à l’indice « 1 » étant toujours le dernier donc le plus récent. Nouvelle version v1.44 du script Python (à remplacer simplement dans le répertoire « /volume1/Scripts »). Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu. EDIT 11/08/2020 § 10 : Ajout d’une trace complète et systématique du processus de renouvellement. § 10 : Ajout de l’option « -f » au script Python de renouvellement. La partie configuration du renouvellement automatique du certificat au §6 a été revue grâce à l’aide de @bruno78 que je remercie vivement ici, pour prendre en compte une anomalie liée au Shell script « acme.sh » et à l’environnement particulier du NAS Synology. Cette anomalie ainsi que sa résolution, est décrite au § 10 ci-dessous. EDIT 01/06/2020 § 2 : Utilisation du "vrai" root pour la connexion SSH au lieu du "sudo -i" § 3.1 : Utilisation de l'Id principal de connexion OVH § 5.2.1 : Réaffectations de services à faire suite à la création du certificat en mode Ajout. Objectif de ce tutoriel : Créer un certificat « Wilcard » Let’s Encrypt (LE) afin : d’une part, de prendre en compte tous les domaines de second niveau de votre domaine personnel, et d’autre part, de s’affranchir de la limite fatidique de 256 caractères imposée par Synology pour les SAN (Subject Alternative Name – Autre nom de l’objet) lors de la création des certificats dans DSM. Pour mémoire, la méthode de création du certificat « wilcard » LE décrite dans le Tutoriel « Certificat TLS/SSL - Let's Encrypt "Wildcard" » de @unPixel utilisait le service ‘SSL For Free’. Malheureusement, ce service n’étant plus gratuit depuis le 18 mai 2020, il convenait alors pour moi de m’orienter sur un autre moyen pour obtenir un certificat « wilcard » LE et gratuit de surcroît. Nota : ‘SSL For Free’ fournit toujours gratuitement son service mais uniquement pour un seul nom de domaine du type « ndd.tld » (NomDeDomaine.Top-LevelDomain). En fouillant un peu la toile, j’ai fini par trouver cet autre moyen. Il est basé sur l’utilisation du client ACME via le Shell script « acme.sh » disponible sur GitHub. Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ... Sachez que c'est un mixte de différents tutoriels trouvés sur la toile, car aucun pris individuellement ne donnait complètement satisfaction vis-à-vis du but à atteindre et il fallait souvent s’adapter et/ou corriger en fonction de leurs contextes parfois légèrement différents. Je ne m’en cache pas, je n’ai pas réinventé la roue, vous retrouverez ici certaines explications directement extraites et traduites de ces tutoriels. Selon le cas, le lien vers l’original sera donné. Mais avant toutes choses, il convient pour mémoire, de faire un petit rappel contextuel. Depuis que Synology a introduit LE dans la gestion des certificats associés à ses NAS et Routeurs, beaucoup d'entre nous bénéficient du SSL gratuit et c’est très bien. D'un autre côté, beaucoup d'entre nous ne veulent pas exposer les ports 80 et 443 à Internet, y compris l'ouverture de ces ports sur le routeur. Malheureusement, l'actuelle implémentation Synology de LE ne prend en charge que la méthode de validation dite WEB, basée sur le protocole « HTTP-01 » qui nécessite d'exposer notamment le port 80 à Internet. Une alternative à cette non exposition est de passer par l’utilisation de la méthode de validation dite par DNS basée sur le protocole « DNS-01 ». Ce protocole présente l’avantage de ne pas avoir besoin d’ouvrir de ports lors de la création du certificat LE mais surtout lors de son renouvellement et là c’est le « plus » indéniable du point de vue sécurité qu’apporte cette méthode. Mais pour utiliser cette méthode de validation par DNS, il est obligatoire d’avoir la main sur la zone DNS du domaine concerné. En effet, LE vérifie la présence d’un enregistrement de type « TXT » sous la forme de « _acme‑challenge.votre-domaine.tld » contenant la valeur d’autorisation. Cet enregistrement permet de prouver que la personne qui demande le certificat, contrôle également la zone DNS du domaine en question. Il convient aussi de noter que le protocole « DNS-01 » est utilisé pleinement par les fonctions d’API (Application Programming Interface) développées par nos fournisseurs de domaines tels que OVH et que l’on va utiliser ici. Pour l’exemple, la méthode présentée ici, utilise les API de mon fournisseur OVH. Mais vous pouvez très bien utiliser les API d’un autre fournisseur car ACME prend en charge de nombreux autres services DNS. Il faudra alors adapter la méthode en fonction de ces autres fournisseurs. Rien de bien compliqué en soit, les paramètres diffèrent quelque peu mais le principe de mise en œuvre reste le même. Par ailleurs, l’utilisation du Shell script ‘acme.sh’ est rendu possible par le fait que nous pouvons accéder au NAS via une connexion SSH pour le configurer pour renouveler les certificats au lieu d'utiliser le tableau de bord WEB. Maintenant, cerise sur le gâteau si je puis dire, depuis peu Synology a introduit dans DSM le code nécessaire pour qu’il ne soit plus nécessaire d'exécuter le Shell script ‘acme.sh’ sur votre NAS pour renouveler le certificat. Le Shell script ‘acme.sh’ devra simplement être exécuté sur quelque chose (votre PC/Mac ou autre) qui a accès à l'interface d'administration de DSM. Du coup, les méthodes de déploiement du certificat généré sont considérablement simplifiées et c’est qui va être exploité dans la présente méthode. Voilà pour le discours préliminaire, on passe aux choses sérieuses … 1 Pré-requis · Disposer d’un nom de domaine personnel chez OVH. · Attribuer l’@IP externe de votre Box/Routeur à votre nom de domaine personnel. Pour cela, se rendre sur l'espace client d'OVH. Une fois connecté : Si vous avez une @IP fixe : aller dans l'onglet : « Web / Domaines / votre-domaine.tld / Zone DNS » vous devez avoir un enregistrement de type « A » dans le quel votre « votre-domaine.tld » pointe vers cette @IP fixe. Si vous avez une @IP dynamique : aller dans l'onglet : « Web / Domaines / votre-domaine.tld / DynHost » vous devez avoir une ligne avec « votre-domaine.tld » qui a pour cible votre @IP du moment (i.e. l’@IP externe de votre Box/Routeur). Ce même DynHost doit être également défini sur le NAS (« Panneau de configuration / Accès externe / DDNS » où le nom d’hôte est : « votre-domaine.tld ». 2 Installation du Shell script ‘acme.sh’ L’installation du Shell script ‘acme.sh’ doit s’effectuer dans un répertoire qui n’est pas modifié/réinitialisé lors des mises à jour de DSM. Pour ce faire, on va donc créer un répertoire spécifique d’installation « Certs/Acme_install » sous « /volume1 » et surtout pas sous le répertoire « /root » qui lui est régulièrement « nettoyé » par le système. Ce répertoire « /root » est également utilisé par défaut par ACME. Ceci expliquant cela. · Sous Windows ouvrir une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP » · Sous Mac ouvrir une session SSH en lançant le « Terminal » puis tapez : ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalié sudo -i (pour passer en « root » - c'est la procédure normale). · EDIT : Il s'avère que passer sous « root » via un « sudo -i» sur PC comme sur Mac, génère une erreur dans l'exécution de la commande « ./acme.sh». Aussi, je vous invite à suivre le Tuto sur les "Accès SSH et ROOT via DSM6" de @unPixel et ainsi de configurer un accès par le "vrai" « root ». Cela marche tout de suite bien mieux ... Nota 1 : Pour ma part sous Windows, je préfère l’utilisation de « WinSCP » à « PuTTY », tout simplement à cause de son interface graphique qui est très agréable de mon point de vue et aussi parce que l’on peut accessoirement directement sélectionner le texte affiché dans la Console pour le Copier/Coller ailleurs dans une autre application. C’est tout bête mais bien pratique au demeurant. Certes « PuTTY » le permet aussi mais je le trouve beaucoup moins souple de ce point de vue, et ce n’est que mon avis ... Nota 2 : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes. Je préfère prévenir même si c’est évident pour certains initiés … · Tapez successivement les commandes suivantes : On crée le répertoire d’installation d’ACME : « /volume1/Certs/Acme_install » et on s’y place : $ cd /volume1 $ mkdir -p Certs/Acme_install $ cd Certs/Acme_install On télécharge ACME chez GitHub $ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz On décompresse le fichier téléchargé et on se place dans le répertoire qui a été automatiquement créé lors de la décompression : $ tar xvf master.tar.gz $ cd acme.sh-master On lance l’installation d’ACME (pensez avant à remplacer dans la commande : « email@gmail.com » par votre @Mail personnelle) $ ACME_HOME="/usr/local/share/acme.sh" $ CERT_HOME="/volume1/Certs" « CERT_HOME » est le répertoire où seront générés les fichiers du certificat. Vous pouvez l’adapter à besoins. $ ./acme.sh --install --nocron --home "$ACME_HOME" --cert-home "$CERT_HOME" --accountemail "email@gmail.com" --nocron : spécifie de ne pas installer par défaut le « cron job ». Vous comprendrez de vous-même pourquoi plus loin. --home : désigne le répertoire « customisé » d’installation du Shell script ‘acme.sh’. C’est un répertoire dit « invariant ». C’est-à-dire qu’il n’est pas modifié par les mises à jour de DSM. Sinon par défaut, le script aurait été installé dans « ~/.acme.sh » où « ~ » correspond au répertoire ‘home’ de l’utilisateur « root » en l’occurrence : « /root ». Pour mémoire le répertoire « /root » est lui, dit « variant », donc sujet à modifications par les mises à jour de DSM. --cert-home : désigne le répertoire où seront générés les fichiers du certificat « wilcard » LE. Cette disposition permet de les sécuriser d’une part et d’autre part permet de les rendre accessibles facilement sans avoir à replonger dans les acarnes de DSM pour les retrouver en cas de besoin autre. Nota :Pour votre information, ce répertoire n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ». Durant la courte installation, vous aurez certainement un message du style : It is recommended to install socat first. We use socat for standalone server if you use standalone mode. If you don't use standalone mode, just ignore this warning. Il faut savoir que ‘Acme.sh’ recommande l'installation du paquet « socat » pour gérer les certificats en mode standalone, mais comme nous n'allons pas utiliser ce mode, vous pouvez largement ignorer ce message. Vous trouverez donc, le dossier d'installation d’ACME dans le répertoire : « /usr/local/share/acme.sh ». Maintenant, il faut régénérer le fichier « .profile » de l'utilisateur courant (« root ») pour pouvoir utiliser immédiatement les commandes Shell. Pour cela, tapez simplement : $ source ~/.profile · Vérifier si besoin les droits d'exécution du fichier « acme.sh » : $ cd $ACME_HOME $ ls -al Normalement c’est bon mais si besoin, tapez : $ chmod a+x acme.sh · On active la mise à jour automatique du client (c’est préférable mais ce n’est pas une obligation) : $ ./acme.sh --upgrade --auto-upgrade Nota 1 : si vous souhaitez désactiver la mise à jour automatique d’ACME, tapez : $ ./acme.sh --upgrade --auto-upgrade 0 Comme vous pouvez aussi commenter manuellement la ligne : AUTO_UPGRADE="1" dans le fichier « /usr/local/share/acme.sh/account.conf » par l’ajout du caractère « # » en tout début de ligne. Nota 2 : Si vous êtes curieux et que vous souhaitez voir toutes les commandes disponibles pour ACME, tapez : $ ./acme.sh --help NE PAS quitter la session SSH 3 Configuration DNS 3.1 Création des clés Pour générer un certificat « wilcard » et pouvoir le renouveler automatiquement, on va donc utiliser l’API d’OVH. Pour ce faire, on va créer une application dans l’API qui va nous permettre de générer trois clés nommées respectivement : « application key », « application secret » et « consumer key ». Il est aussi une bonne pratique de sécurité que de limiter ce qu'une clé API donnée peut faire, dans le cas où elle serait perdue, volée ou que quelque chose de mal se produirait et ce, pour en limiter les dommages potentiels. Cela tombe bien, les clés API OVH peuvent être limitées à une zone de domaine spécifique à l'aide d'un mécanisme de modèle simple. On va donc en profiter pour restreindre une clé API OVH à la gestion de « votre-domaine.tld », en utilisant les paramètres suivants : GET=/domain/zone/votre-domaine.tld/* &POST=/domain/zone/votre-domaine.tld/* &PUT=/domain/zone/votre-domaine.tld/* &GET=/domain/zone/votre-domaine.tld &DELETE=/domain/zone/votre-domaine.tld/record/* Il est clair que cela peut facilement être personnalisé pour prendre en charge un ou plusieurs domaines si le besoin en est. Je vous renvoie à la documentation en ligne d’OVH pour plus de détails. · On se rend donc sur l’API d’OVH en saisissant l’URL suivante dans un navigateur WEB : https://api.ovh.com/createToken/?GET=/domain/zone/votre-domaine.tld/*&POST=/domain/zone/votre-domaine.tld/*&PUT=/domain/zone/votre-domaine.tld/*&GET=/domain/zone/votre-domaine.tld&DELETE=/domain/zone/votre-domaine.tld/record/* Nota : Dans le cas où vous ne souhaiteriez pas restreindre la gestion de la clé API OVH à votre domaine, il suffit simplement d’utiliser les paramètres suivants : ?GET=/domain/zone/* &POST=/domain/zone/* &PUT=/domain/zone/* &DELETE=/domain/zone/*/record/* o L’URL à utiliser pour aller sur l’API d’OVH, est alors : https://api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/* · Donc avec le premier cas, on arrive sur l’écran suivant : Nota : Dans le second cas l’écran est très similaire, je vous laisse vous adapter. · On saisit les informations : o Account ID : votre identifiant principal de connexion chez OVH Nota : Si vous utilisez votre @Mail vous aurez un message d’erreur lors de la création des clés. o Password : votre mot de passe de connexion chez OVH. o Script name : Ce que vous voulez (par ex : « Synology_acme_sh ») mais avec que des caractères, pas d’espaces ni de points et pas de caractères spéciaux sinon cela bloque. o Script description : Ce que vous voulez (par ex : « Certificat wilcard LE – ACME ». o Validity : Dans le popup sélectionnez l’item « Unlimited ». · On clique en fin sur le bouton « Create keys ». · On obtient l’écran suivant, où il convient immédiatement de copier les clés et de les sauvegarder dans un fichier « .txt » : 3.2 Retour dans la session SSH · Taper successivement les commandes suivantes : $ export OVH_END_POINT=ovh-eu $ export OVH_AK="votre application key" $ export OVH_AS="votre application secret" $ export OVH_CK="votre consumer key" 4 Création du certificat Avant de créer effectivement le certificat il convient de préciser un point sur la méthode de chiffrement associée à la génération du certificat LE. Sans aucun paramètre spécifique, ACME utilise une clé de chiffrement de type RSA fixée à 2048 bits par défaut. Dans notre cas, on va directement forcer cette clé RSA à 4096 bits pour renforcer le niveau de sécurité, ce qui se fait par l’emploi du paramètre « -- keylength 4096 » dans la commande de création du certificat. Maintenant pour ceux qui le souhaitent, on peut aussi passer en mode « paranoïaque » et poussez plus loin les choses en adoptant un chiffrement basé sur une clé ECDSA qui elle s’appuie sur des courbes elliptiques. Malgré une faible longueur, ces clés sont très robustes et peut-être bien plus sécures que les clés RSA et sachant aussi que ces dernières sont déjà bien suffisantes pour nos besoins courants. Pour comparaison, une clé ECDSA 256 bits est équivalente à une clé RSA 3072 bits, et une clé ECDSA 384 bits est équivalente à une clé RSA 7680 bits ! À noter que LE reconnait les courbes elliptiques P-256 et P-384 mais le P-521 n'est pas encore reconnu. Donc dans ce dernier cas de figure, le paramètre à employer serait par exemple : « -- keylength ec-394 ». A vous de voir … Bon, il est maintenant vraiment temps de créer le certificat « wilcard » LE pour « votre-domaine.tld » : · Tapez successivement les commandes suivantes : $ cd $ACME_HOME $ export CERT_DOMAIN="votre-domaine.tld" $ export CERT_WDOMAIN="*.votre-domaine.tld" $ export CERT_DNS="dns_ovh" $ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt Edit du 20/06/2021 : Suite aux récentes évolutions du Shell script ACME la commande de création du certificat doit être complétée par deux options. En effet, dorénavant lors de la création d'un nouveau certificat, par défaut c'est un certificat ZeroSSL qui est créé par ACME. Donc dans notre cas, comme l'on veux générer un certificat LesEncrypt, on doit ajouter les options suivantes à la commande de création pour forcer la génération du certificat LE : --set-default-ca --server letsencryp ainsi le shell script ACME prendra en compte ce choix qu'il retiendra d'ailleurs par la suite lors du renouvellement du certificat. Le processus de création du certificat se déroule et affiche un message du type : /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" [Sun May 24 22:42:07 CEST 2020] Create account key ok. [Sun May 24 22:42:07 CEST 2020] Registering account [Sun May 24 22:42:08 CEST 2020] Registered [Sun May 24 22:42:08 CEST 2020] ACCOUNT_THUMBPRINT='l7IOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfro' [Sun May 24 22:42:08 CEST 2020] Creating domain key [Sun May 24 22:42:13 CEST 2020] The domain key is here: /volume1/Certs/votre-domaine.tld/ votre-domaine.tld.key [Sun May 24 22:42:13 CEST 2020] Multi domain='DNS:votre-domaine.tld,DNS:*.votre-domaine.tld' [Sun May 24 22:42:13 CEST 2020] Getting domain auth token for each domain [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='votre-domaine.tld' [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='*.votre-domaine.tld' [Sun May 24 22:42:15 CEST 2020] Adding txt value: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:42:15 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:42:15 CEST 2020] Checking authentication [Sun May 24 22:42:16 CEST 2020] Consumer key is ok. [Sun May 24 22:42:16 CEST 2020] Adding record [Sun May 24 22:42:17 CEST 2020] Added, sleep 10 seconds. [Sun May 24 22:42:27 CEST 2020] The txt record is added: Success. [Sun May 24 22:42:27 CEST 2020] Adding txt value: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:42:27 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:42:27 CEST 2020] Checking authentication [Sun May 24 22:42:27 CEST 2020] Consumer key is ok. [Sun May 24 22:42:27 CEST 2020] Adding record [Sun May 24 22:42:28 CEST 2020] Added, sleep 10 seconds. [Sun May 24 22:42:38 CEST 2020] The txt record is added: Success. [Sun May 24 22:42:38 CEST 2020] Let's check each dns records now. Sleep 20 seconds first. [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld [Sun May 24 22:42:58 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success. [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld [Sun May 24 22:42:59 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success. [Sun May 24 22:42:59 CEST 2020] All success, let's return [Sun May 24 22:42:59 CEST 2020] Verifying: votre-domaine.tld [Sun May 24 22:43:02 CEST 2020] Success [Sun May 24 22:43:02 CEST 2020] Verifying: *.votre-domaine.tld [Sun May 24 22:43:06 CEST 2020] Success [Sun May 24 22:43:06 CEST 2020] Removing DNS records. [Sun May 24 22:43:06 CEST 2020] Removing txt: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:43:06 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:43:06 CEST 2020] Checking authentication [Sun May 24 22:43:06 CEST 2020] Consumer key is ok. [Sun May 24 22:43:09 CEST 2020] Removed: Success [Sun May 24 22:43:09 CEST 2020] Removing txt: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:43:09 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:43:09 CEST 2020] Checking authentication [Sun May 24 22:43:09 CEST 2020] Consumer key is ok. [Sun May 24 22:43:13 CEST 2020] Removed: Success [Sun May 24 22:43:13 CEST 2020] Verify finished, start to sign. [Sun May 24 22:43:13 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxx/xxxxxxxxxxxxxx [Sun May 24 22:43:14 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5c1f [Sun May 24 22:43:15 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- [Sun May 24 22:43:15 CEST 2020] Your cert is in /volume1/Certs/votre-domaine.tld/votre-domaine.tld.cer [Sun May 24 22:43:15 CEST 2020] Your cert key is in /volume1/Certs/ votre-domaine.tld/votre-domaine.tld.key [Sun May 24 22:43:15 CEST 2020] The intermediate CA cert is in /volume1/Certs/votre-domaine.tld/ca.cer [Sun May 24 22:43:15 CEST 2020] And the full chain certs is there: /volume1/Certs/votre-domaine.tld/fullchain.cer Voilà déjà une bonne chose de faite … NE PAS quitter la session SSH 5 Déploiement du certificat Comme expliqué en préambule, Synology nous a facilité la vie pour le déploiement des fichiers du(des) certificat(s) généré(s). Cela se passe par l’emploi du « Synology DSM deployhook ». 5.1 Cas de la double authentification Si vous n’utilisez pas la double authentification pour vous connecter à votre NAS, passez directement au §5.2 ci-dessous. Mais avant de réaliser le déploiement effectif du certificat, il y a encore un point préciser car il y a un paramètre supplémentaire à prendre en compte dans le cas où, comme moi vous utilisez la double authentification pour vous connecter à votre NAS. En effet, si on ne renseigne pas ce paramètre, le processus de double authentification viendrait bloquer le déploiement du certificat tel qu’il sera décrit ci-après. Ce serait dommage convenez-en. Donc, habituellement lorsqu’on se connecte au NAS après avoir saisi son id/pseudo et son mot de passe, la double authentification réclame la saisie d’un code à six chiffres que l’on obtient à partir d’une application tierce installée idéalement sur un smartphone/iPhone. Pour n’en citer que quelques-unes, il y a : « FreeOTP Authenticator », « Google Authenticator », « Microsoft Authenticator », etc … (le choix est grand ! - pour la mise en place de la double authentification sur le NAS, reportez-vous à l’excellent Tutoriel de @Fenrir sur la sécurisation des accès au NAS). Bref, on récupère et on saisit donc ce code à six chiffres et on coche la case « Faire confiance à ce périphérique ». Cette dernière action a pour effet caché de créer un « cookie » dans votre navigateur qui lui, évite par la suite que ce code à six chiffres, ne vous soit systématiquement demandé à chaque connexion. Ce « cookie » stocke en interne un code nommé « DID » dont il nous faut récupérer la valeur pour alimenter le paramètre suscité. Pour récupérer la valeur de ce code « DID », normalement un simple clic gauche sur le cadenas situé à gauche de la barre d’URL du navigateur, suivi de la sélection de l’item « cookies » permet d’afficher ce code « DID ». Sauf que cela ne marche pas avec le navigateur FireFox. Pour contourner le problème, j’ai installé l’excellent module complémentaire « Cookie Quick Manager » dans FireFox. Ensuite on procède ainsi : · Se placer sur la page de connexion ou si déjà connecté, sur la page du navigateur affichant le bureau DSM de votre NAS. · Dans le popup de « Cookie Quick Manager », clic gauche et sélectionner l’item « Rechercher les cookies pour : URL de la page suscitée ». Cela peut-être selon : « https://nom-du-nas.ndd.tld » ou http://@IP_du_NAS:5000 ou encore « https://@IP_du_NAS:5001 ». · Une nouvelle page s’ouvre dans le navigateur, vous montrant tous le détail du cookie associé à la page du NAS. · Dans la partie droite de cette page, on trouve la valeur du fameux code « DID ». · Sélectionnez et Copiez cette valeur et refermez la page du cookie. · Revenez sur la session SSH et tapez la commande suivante en y collant la valeur du « DID » : $ export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx Edit du 10/01/2021 Suite au retour de plusieurs utilisateurs dont le renouvellement du certificat avait échoué avec un message du style : « Tue Dec 15 15:58:28 CET 2020] Unable to authenticate to localhost:5000 using http. [Tue Dec 15 15:58:28 CET 2020] Check your username and password. » voici la « parade ». En fait, ce message survient parce que le cookie DID est périmé. Il s’avère qu’il n’a en fait qu’une durée de vie d’un mois et qu’il change donc tous les mois. Aussi, toute l’astuce va être d’aller éditer le cookie et de modifier sa date de péremption pour la repousser aux « calandres grecques ». Donc pour cela, comme expliqué ci-avant, vous éditez le cookie DID et vous modifiez le champ « expire » en indiquant une date en 2050 par exemple. Cela devrait suffire 😀. Dans le cas, où le cookie DID aurait changé, il vous faut alors aller modifier, dans une session SSH sous l’utilisateur « root » avec PuTTY ou WinSCP sur Windows ou dans un Terminal sur Mac, le fichier « /volume1/Certs/votre-domaine.tld/votre-domaine.tld.conf » pour mettre en accord la valeur de votre nouveau cookie DID avec le contenu de la variable « SAVED_SYNO_DID » sauvegardée par le système dans ce fichier. Ajout du 2021-02-15 : Il faut aussi mettre en accord la variable « SAVED_DID » qui se trouve elle, dans le fichier « /usr/local/share/acme.sh/account.conf ». Toujours pareil, attention lors du copier/coller de la valeur à ne pas prendre de caractères parasites ! N’oubliez pas aussi d’enregistrer le fichier à l’issue de vos modifications. Ainsi, plus de soucis de renouvellement à ce niveau … 5.2 Réalisation du déploiement du certificat Nota préliminaire : Tout ce qui suit présume que vous n’avez pas quitté la présente session SSH. Sinon, il faut réexporter toutes les variables définies précédemment. Sans quoi rien ne fonctionnera correctement ! Ce serait dommage, non ? Maintenant, deux cas de figure se présentent selon que l’on procède à un déploiement du nouveau certificat : · avec un mode « Annule et remplace » du certificat existant marqué « par défaut », · ou que l’on se contente d’ajouter simplement le nouveau certificat à la liste existante de vos certificats. Vous avez le choix, c’est vous qui décidez … 5.2.1 Mode « annule et remplace » du certificat par défaut Rappel : Ici on va ECRASER le certificat marqué par défaut dans le tableau de bord de DSM. Il n’existera plus !!! Vous êtes prévenus … · Dans la session SSH tapez successivement les commandes suivantes : o Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ». $ pwd o Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes : # export SYNO_Scheme="http" Par défaut : « http » mais on peut fixer à « https » # export SYNO_Hostname="localhost" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Port="5000" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS. o On poursuit les définitions de variables d’environnement : Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse. $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir remplacer le certificat par défaut, il est nécessaire de spécifier une chaîne vide pour ce paramètre. Ne me demandez pas pourquoi ! (si un « initié » sait, je corrigerai en conséquence avec l’explication du pourquoi). $ export SYNO_Certificate="" · Et on déploie enfin le certificat … $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm 5.2.2 Mode « ajout » du nouveau certificat Ici, on va simplement ajouter le nouveau certificat à la liste des certificats éventuellement déjà présents sur le NAS. Le processus est sensiblement le même que celui décrit au §5.2.1 ci-dessus. · Dans la session SSH tapez successivement les commandes suivantes : o Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ». $ pwd o Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes : Par défaut : « http » mais on peut fixer à « https » # export SYNO_Scheme="http" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Hostname="localhost" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS (dans ce dernier, il faut ajouter l'option "--insecure" à la commande de déploiement donnée plus loin). # export SYNO_Port="5000" o On poursuit les définitions de variables d’environnement : Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse. $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir ajouter le nouveau certificat, il est nécessaire de spécifier une chaîne non vide pour ce paramètre. Là, cela paraît évident … (Quoi que …) Vous nommez votre certificat comme bon vous semble. Pour ma part je lui donne le nom qui précise mon domaine « ACME_Wilcard_LE_*.ndd.tld » pour plus de clarté. Encore une fois, c’est vous qui voyez … $ export SYNO_Certificate="Nom_du_certificat" o Une dernière variable d’environnement : Par défaut : ce paramètre est sur « off » et n’est pas enregistré mais on peut le fixer à « 1 » pour indiquer au système de créer le certificat s’il n’existe pas déjà. $ export SYNO_Create=1 · Et on déploie enfin le certificat … $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm Dans cette commande, pour le cas où vous le souhaiteriez, on peut préciser un domaine de second niveau. La commande est alors : $ ./acme.sh --deploy -d "secondNiv.$CERT_DOMAIN" --deploy-hook synology_dsm Nota : On peut remarquer dans le message ci-dessus la ligne : « http services were NOT restarded », ne sachant pas ce qu’il faut en faire, je l’ai provisoirement ignorée. Je n’ai d’ailleurs pas constaté par la suite de disfonctionnements qui lui soient liés. Cela dit, je compte sur les « initiés » pour me dire s’il y a une quelconque action à exécuter vis-à-vis de ce message. D’avance merci, je mettrai à jour la présente procédure en conséquence. Toujours est-il, le nouveau certificat est maintenant visible dans « Panneau de configuration / Sécurité /Certificat » de DSM : Ici par défaut on constate que : · d’une part le nouveau certificat a été automatiquement marqué pour une utilisation « par défaut », · • et d’autre part là, deux cas de figures peuvent se présenter : Soit vous êtes dans le cas d’une toute première création du certificat i.e. aucun autre certificat pour « votre-domaine.tld » n’existait auparavant, alors il est obligatoire de réaliser une affectation manuelle du certificat aux services qui vont l’utiliser pour une bonne prise en compte de celui-ci. Pour cela : Sélectionnez le certificat. Cliquez sur le bouton « Configurer » et affectez le certificat aux services de votre choix en le sélectionnant dans le popup en regard du service concerné. Soit vous êtes dans le cas d’une nouvelle création du certificat avec déjà un certificat pour « votre-domaine.tld » existant auparavant, alors avec cette création, le constat est qu’il n’a pas repris les assignations aux services qui existaient pour le certificat précédemment marqué par défaut. Il vous faut alors reprendre ces assignations manuellement. Toujours pareil, vous adaptez à votre besoin … Nota : Dans ce dernier cas, sachez que ce comportement est normal puisque l’on crée le certificat. Un dernier constat : on ne le voit pas sur la copie d’écran, mais bien évidemment, le certificat précédemment marqué pour une utilisation par défaut, n’a pas disparu. Il est bien toujours présent dans la liste des certificats. Il n’est tout simplement plus marqué pour une utilisation par défaut. Rien n’a été perdu, c’est ce qui importe ! NE PAS quitter la session SSH 6 Configurer le renouvellement du certificat Maintenant que le certificat « wilcard » LE a été créé et déployé sur le NAS, il faut assurer son renouvellement à l’échéance fatidique de 3 mois. En fait, cette échéance est variable dans le sens où selon la date de génération du certificat il peut se passer entre 89, 90, 91 et 92 jours. Mais en pratique lors de son exécution, le script « acme.sh » contrôle par défaut si la date courante est supérieure de plus de 60 jours par rapport à la date de création du certificat avant de lancer ou non le renouvellement effectif de celui-ci. Par sécurité, on ne va pas « s’embêter », on va programmer tout simplement cette opération de contrôle du besoin de renouvellement, avec une exécution hebdomadaire à un horaire de faible charge du NAS (par exemple tous les Lundi et donc a priori la nuit soit à 00h00). Libre à vous de modifier cette périodicité selon vos propres besoins. C’est vous qui voyez … Mais avant toute choses, on va installer un petit programme/script écrit en langage Python (Encore MERCI à @bruno78 qui l’a développé) destiné à compléter l’action normale du script « acme.sh » en réalisant un certain nombre d’autres opérations spécifiques et rendues nécessaires par l’environnement du NAS Synology (pour les plus curieux, ces actions sont explicitées en détail au § 10 ci-dessous). Rassurez-vous, vous n’avez pas besoin de connaître le langage Python. Celui-ci est nativement géré par le NAS Synology au travers du package « Python module ». Vérifiez juste que ce package est bien installé sur votre NAS et auquel cas installez le via le centre de paquets. EDIT 21/08/2020 Le script Python est maintenant compatible de la dernière et actuelle version 3.x.x du langage Python. Si vous envisagez d’utiliser Python3 il vous faut alors installer le package « Python3 » disponible dans la rubrique « Outils de développement » dans le centre de paquets de DSM. Donc, le package « Python module » ou le package « Python3 » étant installé : Créez un répertoire spécifique pour accueillir ce script Python : On crée le répertoire : « /volume1/Scripts » et on s’y place : Nota 1 : Ce chemin peut être tout autre selon vos besoins, mais veillez à rester cohérent dans son utilisation par la suite. Nota 2 : Ce répertoire, tout comme le répertoire « Volume1/Certs » créé précédemment, n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ». $ cd /volume1 $ mkdir -p Scripts $ cd Scripts Téléchargez sur votre PC/Mac le fichier du script Python : acme_renew.py Copiez/Collez ce fichier sur le NAS dans le répertoire « /volume1/Scripts ». (via WinSCP c’est on ne peut plus simple !). Le script Python étant en place, on va programmer effectivement l’exécution périodique de ce script. Nota :En préalable et pour ceux qui seraient tentés de le faire, il faut également savoir qu’Il n'est pas conseillé de configurer directement un « cron job » personnalisé car le conseiller de sécurité DSM va rapidement vous rappeler à l’ordre et vous dira que vous avez un avertissement critique concernant un ou des cron job(s) inconnu(s). Donc pour ce faire, on va configurer une tâche dans le planificateur de tâches de DSM. · Dans « Panneau de configuration / Planificateur de tâches », cliquer sur le bouton « Créer » et sélectionner dans le popup : « Tâche planifiée / Script défini par l’utilisateur » · Dans la fenêtre « Créer une tâche » onglet « Général » nommez la tâche à exécuter périodiquement. Par exemple : « RenewCertif_W_LE ». L’utilisateur doit être « root » et la case « Activé » est cochée. · Dans l’onglet « Paramètres de la tâche » : o Pour la partie « Paramètres généraux » : si vous voulez recevoir par eMail les détails d’exécution de la tâche : cochez la case correspondante et saisissez votre @Mail. Vous pouvez aussi décider de ne recevoir ces eMails uniquement si l’exécution de la tâche se termine de façon anormale. Dans ce cas cochez la case correspondante. o Pour la partie « Exécuter la commande » : saisir la commande suivante : python /volume1/Scripts/acme_renew.py -l votre-domaine.tld Ou si vous souhaitez utiliser la version sous « Python3 » : python3 /volume1/Scripts/acme_renew.py -l votre-domaine.tld Dans cette commande : - Le chemin d’accès au script « acme_renew.py » (ici « /volume1/Scripts/ ») devra être modifié selon que vous en aurez défini un autre ci-avant. - Le paramètre « -l » est quant à lui optionnel. Libre à vous de l’indiquer ou pas. Néanmois je ne peux que vous conseiller de le mentionner pour le cas où … On n’est jamais trop prudent. Si vous l’indiquez explicitement, sachez qu’à chaque renouvellement, un fichier de « log » nommé « acmelog » sera automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew/ » lui-même créé automatiquement par le script Python. Donc si un quelconque problème survenait, vous disposerez alors d’une trace complète de toutes les opérations réalisées lors du processus de renouvellement du certificat« wilcard » LE. Si tout est OK, vous aurez tout de même une trace mais forcément « light ». - Le paramètre « votre-domaine.tld » est quant à lui OBLIGATOIRE et est bien évidemment à remplacer par l’intitulé de votre propre domaine pour lequel le certificat doit être renouvelé. · Dans l’onglet « Programmer » : o Sélectionner « Exécuter les jours suivants » o Dans le popup, cochez la case « Lundi ». o Dans la zone « Temps » : laisser les valeurs par défaut. · Valider l’ensemble de votre paramétrage en cliquant sur le bouton « OK ». EDIT du 20/06/2021 : Suite aux récentes évolutions du Shel script ACME (voir plus haut pour la commande de création du certificat) il n'y a normalement rien à faire si vous disposer déjà d'un certificat LE. Le Shell script ACME de lui même s'adapte et assure le rouvellement de votre certificat comme avant. Toutefois, afin de s'assurer et forcer ce renouvellement avec LetEncrypt, il convient d'ajouter (sous SSH à la fin du fichier) la ligne suivante dans votre fichier "account.conf" (/usr/local/share/acme.sh/account.conf) : DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' 7 En cas de problème suite à une mise à jour de DSM En cas de problème suite à une mise à jour de DSM, on peut réparer l’environnement ACME en exécutant les commandes suivantes dans une session SSH sous l’utilisateur « root » : $ cd /usr/local/share/acme.sh $ ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh Vous pouvez aussi ajouter la ligne suivante dans le fichier « /root/.profile » et régénérer le « .profile » en tapant : . "/usr/local/share/acme.sh/acme.sh.env" $ source /root/.profile 8 Arrêter le renouvellement du certificat Pour arrêter le renouvellement d’un certificat, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes pour supprimer le certificat de la liste de renouvellement : $ cd /usr/local/share/acme.sh $ ./acme.sh --remove -d votre-domaine.tld Les fichiers « .cert » et « .key » de votre certificat ne sont pas supprimés du disque. Vous pouvez supprimer le répertoire correspondant (par exemple : « /volume1/Certs/votre-domaine.tld ») par vous-même. 9 Un dernier truc utile Vous pouvez éventuellement avoir besoin de convertir votre certificat en un fichier « .p12 » ou « .pfx » exploitable sous Android. C’est utile par exemple, pour un client VPN installé sur le smartphone. Dans ce cas, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes : $ ACME_HOME="/usr/local/share/acme.sh" $ CERT_HOME="/volume1/Certs" $ cd $ACME_HOME $ ./acme.sh --toPkcs -d votre-domaine.tld Enter Export Password: Verifying - Enter Export Password: [Mon May 25 20:00:28 CEST 2020] Success, Pfx is exported to: /volume1/Certs/votre-domaine.tld/votre-domaine.tld.pfx « Password » est le mot de passe utilisé pour ouvrir la session SSH. 10 Évolution du processus de renouvellement du certificat EDIT du 11/08/2020 et du 21/08/2020 Afin d’améliorer la recherche de la (les) cause(s) d’un éventuel dysfonctionnement dans le processus de renouvellement du certificat, la trace complète de toutes les opérations effectuées lors du déroulement de ce processus a été remaniée de façon à fournir un historique « tournant ». Ces informations sont inscrites dans un fichier nommé « acme_renew_python.log.x » qui est automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew ». Cette trace est systématiquement générée que vous utilisiez ou non l’option « -l » pour obtenir un « log » du processus. Au total, vous disposerez de neuf (9) fichiers de trace sachant que le fichier ayant l’indice « 1 » sera toujours celui correspondant à la dernière exécution du script, donc le plus récent. Si pour une quelconque raison vous aviez besoin de renouveler votre certificat LE avant sa date normale de renouvellement, une option dédiée à cet effet à été ajoutée au script Python (v1.40). Cette option « -f » ou « --force » doit toutefois être utilisée avec parcimonie. En effet, LetsEncript limite le nombre de modifications d’un certificat d’un même domaine à cinq (5) par semaines calendaires. Au-delà de ces cinq (5) modifications dans une même semaine, vous serez bloqués et ne pourrez pas renouveler votre certificat durant une semaine à compter de la dernière modification tentée. Vous êtes donc prévenus ... EDIT du 25/07/2020 Suite aux retours de plusieurs utilisateurs « initiés », il a été fait le constat que le processus de renouvellement du certificat tel qu’il existait, n’était pas pleinement satisfaisant. En effet, même si en apparence le certificat semblait renouvelé dans le « Panneau de configuration / Sécurité / Certificat » avec une nouvelle date d’expiration affichée en vert et qu’il était bien marqué « par défaut », en fait il ne l’était pas complétement. À l’usage il générait encore des messages liés à une connexion non sécurisée avec une erreur du type « SLL_ERROR_BAD_CERT_DOMAIN ». La raison en était que les fichiers « .pem » du nouveau certificat n’avaient en fait, pas été recopiés partout où ils auraient dû l’être et du coup les navigateurs Web utilisaient toujours les anciens fichiers. Pour les plus sceptiques vis-à-vis de cette apparence trompeuse et pour bien se rendre compte que c’était toujours l’ancien certificat qui était pris en compte par les navigateurs Web, il suffit effectuer les manipulations suivantes : Effacer le cache du navigateur Web. Recharger le site web consulté où l’erreur SSL était apparue. Examiner le certificat utilisé par le navigateur dans ce cas. On constate que c’est toujours l’ancien certificat à la vue de sa date d’expiration. On obtient aussi la preuve que le processus de renouvellement pour le cas particulier de l’environnement du NAS Synology n’était pas complet, en examinant via une connexion SSH sous « root », les fichiers « .pem » contenus dans le répertoire « /usr/local/etc/certificate/WebStation/vhost_xxxxxx ». Ces fichiers correspondaient exactement à l’ancien certificat. Par ailleurs, après sa création et/ou son renouvellement, il avait été constaté que le nouveau certificat n’était pas non plus, appliqué et/ou réappliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Il fallait alors reprendre manuellement via le menu « Configurer », toutes les affectations de ce nouveau certificat aux différents services qui l’utilisaient. Opération laborieuse s’il en était … Nota : Je vous rappelle si besoin en est, qu’après toute création du certificat (qu’il en existe déjà un ou non pour « votre-domaine.tld »), cette opération d’affectation du certificat aux services est obligatoire pour la bonne prise en compte de celui-ci. Vous en conviendrez donc, du point de vue automatisation ce n’était pas top ! 🤔 Ces différents problèmes nous ont donc conduits @bruno78 et moi-même à plancher sur une automatisation COMPLETE de la procédure de renouvellement du certificat et il faut bien le dire ici, sans les talents de développeur de @bruno78, nous n’aurions pas aujourd’hui une procédure pleinement fonctionnelle et efficiente. Donc, @bruno78 a développé un script en langage Python nommé « acme_renew.py » qui réalise maintenant correctement tout le « boulot » si je puis dire. À noter que ce script dispose également de certaines fonctionnalités disponibles uniquement dans le cadre une utilisation manuelle en mode SSH sous « root » que je vais vous détailler plus loin. Pour d’ores et déjà satisfaire la curiosité des utilisateurs « initiés », de façon succincte, ce script Python réalise les opérations suivantes : Lecture des fichiers « INFO » et « DEFAULT » (« /usr/syno/etc/certificate/_archive ») Vérification de l’atteinte ou non de la date de renouvellement (minimum T0+60 jours, valeur par défaut inscrite dans le code du Shell script « acme.sh »). Sauvegarde du répertoire « /usr/syno/etc/certificate/_archive » y compris des fichiers « INFO » et « DEFAULT » Récupération des services du certificat originel par défaut selon qu’il a été généré avec une clé de chiffrement de type RSA ou ECDSA. Renouvellement du certificat : On reprend ici la commande originelle de renouvellement du script « acme.sh » à laquelle on a ajouté des paramètres spécifiques (« /usr/local/share/acme.sh/acme.sh --cron –force –debug --log --home /usr/local/share/acme.sh/ ») : « --force » pour le forcer à renouveler le certificat (la simple option « –renew » n’est pas suffisante car elle génère un message d’erreur qui stipule de surcroît d’utiliser l’option « --force », donc on applique cette option directement). « --debug » pour avoir un maximum de messages de traçage des opérations réalisées. « --log » pour récupérer les messages générés dans un fichier « Log » de trace. Lecture des nouveaux fichiers « INFO » et « DEFAULT » générés suite au renouvellement. Mise à jour du fichier « INFO » en inscrivant les services sur le nouveau certificat « par défaut » Renommage de la description de l'ancien certificat en "xxx_old". Distribution les nouveaux fichiers du certificat dans les répertoires système du NAS « /usr/syno/etc/certificate » et « /usr/local/etc/certificate ». Recherche et constitution de la liste des packages et services qui utilisent le certificat. Redémarrage global de ces packages et services en incluant leurs dépendances. Donc comme évoqué précédemment, le script Python « acme_renew.py » peut être utilisé selon deux modes de fonctionnement : En mode dit « Standard ou automatique » : c’est celui qui est typiquement utilisé pour la commande de renouvellement intégrée à la tâche périodique que vous avez définie dans DSM au § 6 ci-dessus et dans lequel la description des paramètres que le script accepte, est précisée. Veuillez-vous y reporter. En mode dit « Manuel » : ce mode correspond à une utilisation directe en lignes de commandes dans une connexion au NAS via une session SSH sous l’utilisateur « root ». Donc, ouvrez une connexion SSH sous « root » et tapez les commandes suivantes : $ cd /volume1/Scripts $ python acme_renew.py -h Avec ce paramètre « -h » vous obtenez une aide sur tous les paramètres utilisables avec le script Python « acme_renew.py » : Les informations fournies par cette option « -h » se suffisent à elles-mêmes. Elles ne seront donc pas décrites/détaillées plus avant. Nota : Dans cette aide le paramètre « ndd.tld » correspond bien évidemment à « l’intitulé » de votre domaine soit « votre-domaine.tld ». Toutefois, dans le cas particulier d’une utilisation avec le paramètre « -c » il convient de préciser ceci : En aucun cas vous ne devez utiliser la commande « python acme_renew.py -c votre-domaine.tld » ou « python3 acme_renew.py -c votre-domaine.tld » dans une fenêtre de console sous WinSCP ! La raison en est, que la console de WinSCP ne supporte pas l’exécution de commandes dites « interactives ». Si d’aventure vous faisiez cette erreur, sachez que vous allez entrer dans une boucle sans fin et que le seul moyen d’en sortir sera de « tuer » le process WinSCP dans le gestionnaire de tâches de Windows. Maintenant vous êtes prévenus ! Par contre, il n’y a aucun souci pour exécuter cette commande interactive dans une fenêtre « Terminal » de PuTTY sur PC (même si celle-ci est lancée à partir de WinSCP) ou d’une fenêtre « Terminal » sur Mac. Voilà c’est fini, profitez bien de votre certificat « wilcard » Let’sEncrypt !!! GRATUIT !!! et ne nécessitant plus d’ouvrir les ports 80 et/ou 443 sur votre NAS pour son renouvellement. À l’usage, on en oublierait presque la chose … Le fichier ".pdf" de cette procédure : Création_Certif_Wilcard_LE_avec_ACME_20210215.pdf Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Merci à @maxou56 pour ses compléments d’informations liées au monde Mac. Cordialement Oracle7😉

@firlin Les versions de PHP pour le DS1821 sont apparemment 8.1 à 8.4 indiquées sur le site de synology. Tu peux installer plusieurs versions de PHP et voir dans Web Station si tu peux les affecter. Edit : sauf pour DSM7.1 auquel cas c'est PHP 8.0

le 3 avrille 3 avril
1895 réponses

Bonjour à tous, Depuis quelques temps, je constate un défaut très handicapant avec l'interface web de Synology Photos. Lors de la suppression d'une ou plusieurs photos, j'ai bien l'indication du traitement en cours mais ça ne va pas plus loin. Ca dure tant que je ne réactualise pas la page. Si ce n'est pas trop un souci tant qu'il n'y a que quelques photos sur la page, c'est difficilement acceptable lorsqu'il y en a des centaines dans un dossier car chaque actualisation revient à la première photo du dossier. Il faut alors tout faire défiler pour revenir à la dernière photo traitée. Très pénible. Ce n'est pas sur un seul PC mais sur tous mes PC que ce problème existe. Je suis sous Firefox et les PC sous windows 10 et 11. Suis-je le seul dans ce cas ?

le 3 avrille 3 avril
1 réponse

Attention, les NAS dont les versions de DSM sont inférieures à 6.2.3 (votre cas) ne sont pas détectés par les dernières versions de Synology Assistant. Pour ces NAS, il faut utiliser la version 7.0-50029 ou inférieure. A télécharger ici : https://archive.synology.com/download/Utility/Assistant Votre problème peut être situé au niveau du NAS ou au niveau des disques. Pour le NAS, faites un test de la carte mère : https://kb.synology.com/fr-fr/DSM/tutorial/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly Afin de vérifier s'il s'agit d'un problème de disque, je vous propose de retirer les disques actuels, de monter un disque neuf ou usagé qui fonctionne peu importe et de tenter de faire une nouvelle installation à partir de Synology Assistant. Si c'est ok, c'est que le problème vient d'un des disques, ou des deux.

le 11 septembre 2025le 11 sept.
5 réponses

Bonjour, Suite a des soucis, il y a deux jours, de connexion aux volumes de sauvegarde crées sur ce NAS DS211j, j'ai voulu en vérifier les paramètres sous DSM 6.2.4 MAIS plus moyen de lancer ledit DSM. En fait, ni Synology Assistant ni la recherche à l'adresse web idoine ne le détectent. Après un reset "sans perte de données" (1 bip et 3 bips), et donc clignotant orange du témoin Statut, pas mieux, pas moyen de le faire voir par les outils Synology. Le NAS est bien vu sur le réseau avec son adresse IP - fixe ou dynamique -, mais considéré comme injoignable. Qu'en penser, que tenter encore avant de le considérer comme perdu ? Merci de votre aide, --Michel--

le 10 septembre 2025le 10 sept.
5 réponses

Merci pour ces nouvelles suggestions - belle solidarité sur le forum. 🙂 Avant de lire votre message ce matin, j’avais installé un disque connu comme défectueux à la place des deux disques d'origine. Du coup, hasard ou conséquence, j'ai pu retrouver mon NAS en DHCP, mais toujours pas vu par mon Synology Assistant (SA; 7.0.5 50070). J'ai donc téléchargé la version plus ancienne que vous indiquez, et après deux sollicitations de celle-ci, un miracle s'est accompli, j'ai revu mon NAS (j'ai pu le revoir aussi avec ma version précitée). Du coup, j'ai pu lancer la réinstallation de DSM - qui n'a pas abouti, je m'en doutais vu le disque notoirement défectueux. Les deux disques d’origine ont été remis en place, DSM réinstallé cette fois et hop, je me plonge dans les délices du paramétrage - mais c'est une ure histoires. Un nouveau NAS sauvé - et un utilisateur soulagé - grâce au forum. --Michel--

le 11 septembre 2025le 11 sept.
5 réponses

Merci beaucoup pour cette suggestion ,qui m'a insufflé un bon vent d'optimisme. J'ignorais qu'il y avait une pile sur mon Syno (même si à la réflexion j'aurais pu m'en douter), et donc encore plus que sa déficience pouvait bloquer le NAS. Remplacement effectué dans la foulée, la pile d'origine en était à 2,7 V contre 3 V nominal et 3,2 V pour la remplaçant neuve. Hélas, trois fois hélas, ceci n'a toujours résolu mon problème, mon 211j "reseté"demeurant invisible sous Synology Assistant. Mais j'ai quand même regagné un peu d'espoir, et je me console en pensant à ceux qui ont malheureusement changé leur NAS pour une histoire - ignorée - de pile --Michel--

le 10 septembre 2025le 10 sept.
5 réponses

Update : je l'ai éteint quelques minutes, j'ai retiré 3 disques pour n'en laisser qu'un seul. Entre temps je me suis branché en ethernet et déconnecté le wifi de mon Mac. Je l'ai redémarré et il a finit par être de nouveau détecté par Synology Assistant, et j'ai pu finir la configuration et enfin me connecter dessus via la console web. Évidemment le système est en alerte car il n'y a qu'un disque. Je remarque que le CPU est à bloc par contre.. Je fais la maj DSM et je le redémarre, on verra bien si il repart ou non.

le 10 marsle 10 mars
6 réponses

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

le 11 septembre 2025le 11 sept.
5 réponses

Si la pile de la carte-mère (CR2032) est d'origine, il faudra certainement la changer. Lorsque cette pile devient faible, le NAS perd l'heure au redémarrage, ce qui peut le bloquer.

le 10 septembre 2025le 10 sept.
5 réponses

Bonjour tout le monde, Le problème : je n'accède plus à mon site internet hébergé sur mon NAS via le nom de domaine https://mondomaine/monsiteweb/home.php mais il fonctionne bien en local via http://moniplocale/monsiteweb/home.php Page synology : Désolé, la page que vous recherchez est introuvable : Résumé: Il y a quelques jours j'ai du refaire les données pour accéder a mon site web via mon NAS (/web/monsiteinternet/touslesfichiersphp) j'ai du réinstaller les logiciels comme MyPHPMyadmin, MariaDB, MySQL, Web Station, Apache, PHP etc. Jai refais la config web station, enfin de ce qu'en avais en souvenir... en extensions cochées : gd, curl, mysqli, openssl, pdomysql, Mon certificat lets encrypt est bien valide sur mon domaine principal. je ne sais plus si sur web station j'avais créé ou non un virtual host en plus de "serveur par defaut" mais si j'essai d'en créer un il me dit que le domaine existe déjà (via le serveur par défaut qui est mon domaine principal) je précise que tout fonctionnait bien sans avoir eu a créer de sous domaine ou de faire des ports alternatifs au 80/443 je ne sais plus si c'est utile mais coté routeur jai les règles porte 80 et 443 établies pour le NAS je suis preneur de toute idées :) Merci par avance et bonne journée

le 7 novembre 2025le 7 nov.
4 réponses

Bonjour à tous, J'ai besoin de votre aide svp : je viens de ressortir mon vieux DS411j du placard en vue de le remettre en route. J'ai installé 4 disques de 4To. Au premier démarrage, tous les voyants étaient au vert sauf celui de "Status" qui clignotait en orange. J'ai installé Synology Assistant sur mon Mac mais il ne le détectait pas. J'ai effectué le reset au bip et il a finit par remonter dans l'application. J'ai pu alors lancer l’installation en téléchargeant le DSM compatible mais j'ai eu un message d'erreur dans la dernière phase (celle du redémarrage et inscription des informations). Il est resté bloqué en phase où seul le LAN est en vert, et le bouton d'allumage principal clignote en bleu (status et disques sont éteints). Je l'ai redémarré plusieurs fois, mais rien. Le LAN est en vert, et le bouton d'allumage principal clignote en bleu (status et disques sont éteints). J'ai tenté à nouveau le reset mais pas de bip. J'ai retiré la pile et mis une neuve, mais toujours rien. Quelqu'un aurait une idée de ce que je dois faire ? je suis bloqué là.. Merci par avance pour votre aide !!

le 10 marsle 10 mars
6 réponses

Préambule au préambule : Aout 2025, à savoir avant d'acheter un NAS SYNOLOGY Attention la série 2025 , dont le DS925+, n'accepte que des disques durs de marque SYNOLOGY, de la mémoire SYNOLOGY et des SSD SYNOLOGY SYNOLOGY précise "Synology ne fournira pas d'assistance technique si votre périphérique ne figure pas dans la liste de compatibilité des produits Synology". Pour les modèles antérieurs Synology publie une liste de disques durs compatibles : Seagate, Toshiba, Western Digital. DSM 7.3 est disponible : Synology fait (enfin) marche arrière sur les disques durs tiers ! Préambule : Utilisateur de PHOTO STATION depuis de nombreuses années, j'ai constaté et regretté sa disparition avec l'arrivée de DSM 7. Actuellement j'ai installé mon 'ancien' PHOTO STATION sur un DSM Virtuel en version 6.2 pour assurer la continuité de mes partages. Néanmoins force est de constater que malgré de très nombreuse demandes de ses clients SYNOLOGY persiste à ne pas vouloir réimplanter PHOTO STATION dans DSM7, et le développement de SYNOLOGY PHOTO va certainement se poursuivre avec d'autres objectifs, qui sont en résumé de cloner GOOGLE PHOTO. A noter les publicités insistantes pour SYNOLOGY PHOTOS sur les liens de partage de documents ... C'est pourquoi j'ai testé pas mal de solutions alternatives de partage de photos sur internet ( PhotoPrism, Libre Photo, Lychee, Photoview etc ..) et finalement après avoir pas mal galéré pour l'installer, j'ai trouvé les fonctionnalités de Piwigo très intéressantes, proches de celles de PHOTO STATION, voire mieux puisque l'on peut enfin avoir des Albums et des sous-albums imbriqués, sans aucune limite. D'où ce tuto pour installer Piwigo en tant que site web sur un NAS Synology pour ceux qui ont l'envie de voir par eux mêmes ce qu'il en est. ( Il existe aussi une version Docker que je n'ai jamais réussi à faire fonctionner pleinement ) Après plus de deux ans d'utilisation, 100 000 photos et 1 300 albums, une fluidité sans égal par rapport à Photo Station , il n'y a pas photo 😉 [TUTO] INSTALLER PIWIGO SUR UN NAS SYNOLOGY – DSM7 Installation de Piwigo sur un NAS Synology pour gérer la publication des photos et vidéos situées dans un ou plusieurs répertoires partagés. Les photos sont intégrées à piwigo par la méthode de synchronisation, on n’utilise pas la méthode ajouter des photos pour ne pas créer des doublons. On peut probablement utiliser ‘photos’ mais il y a peut-être des effets de bord si on utilise simultanément Synology Photos. Le gros plus de Piwigo est de permettre d’afficher des albums physiques ou virtuels, imbriqués de manière illimitée. 1 Installation des paquets Installer les paquets suivants : Web Station Apache HHTP 2.4 PHP8.2 MariaDB 10 et phpMyAdmin 2 Paramétrage des paquets 2.1 Créer avec File Station un répertoire sous web, pour l'exemple 'photo_charles' sous web 2.2 Web Station ( mis à jour avec DSM 7 ) 1 - Dans 'paramètre du langage de script ' onglet 'PHP' créer un profil personnalisé onglet : 'Paramètres' Nom : 'Piwigo 8.2', Description ; 'Piwigo PHP 8.2' ; version 'PHP 8.2' cocher 'Activer le cache PHP' onglet : 'Extensions' cocher 'exif' 'gd' 'imagick' 'mysqli' 'zip' 'zlib' 2 - Dans 'Service Web' Créer un service web , choisir 'un site web en langage de script natif' Service : 'PHP 8.2' , dans la liste déroulante choisir le profil créé précédemment 'Piwigo 8.2' Nom : 'photo_charles' Profil : choisir dans la liste le profil php 'Piwigo 8.2' Description : 'Photo Charles' Racine du document : sélectionner ..web/photo_charles Serveur principal HTTP sélectionner 'Apache HTTP Server 2.4' ( ça fonctionne aussi avec Nginx ) 3 - Dans 'Portail Web' Créer un portail , choisir 'Portail de service Web' Service, choisir celui créé précédemment 'photo_charles' Type de portail 'Basé sur le nom' Nom d'hôte : 'photo_charles' cocher : port 80/443 Les autorisations d'accès aux répertoires données Webstation sont insuffisants, pour pouvoir installer Piwigo, il faut d’abord donner des droits d’accès aux dossiers : - En lecture pour le groupe http sur les répertoires photos/vidéos que l'on souhaite associer à Piwigo - En lecture et écriture pour le groupe http sur les répertoires : ./photo_charles/_data ./photo_charles/galleries ./photo_charles/plugins ./photo_charles/themes ./photo_charles/local 2.3 MariaDB Créer un mot de passe fort, le login étant root 2.4 phpMyAdmin Ouvrir avec root et le mot de passe précédent Créer un nouvel utilisateur, 'charles_admin' avec un mot de passe fort Cocher ‘privilèges globaux tout cocher’ Créer une base de données, nom : 'photo_charles' (L’installateur piwigo créera les tables ultérieurement) 3 Installation de piwigo Sur le site de Piwigo https://fr.piwigo.org/obtenir-piwigo Télécharger le fichier 'piwigo-16.2.0.zip', dézipper le fichier zip dans le répertoire ./web/photo_charles ( mise à jour décembre 2025 ) L’adresse du NAS étant 192.168.1.20 saisir dans le navigateur http://192.168.1.20/photo_charles ou cliquer sur le raccourci dans Web Station. On arrive sur la page Piwigo installation Compléter les champs comme indiqué Cliquer sur ‘Démarrer l’installation’ On arrive sur cet écran : Ne cliquer pas sur 'je veux ajouter des photos' !!! Mais sur ‘je me débrouillerai par moi-même’ L’objectif étant d’accéder aux photos situées dans le NAS sans créer de doublon. Dans la page qui s'affiche, sélectionner 'Admin' Qui va vous donner accès au menus de gestion de l'application Aller dans Plugins et activer 'LocalFiles Editor' et 'Admin Tools' 4 Paramétrage de piwigo Aller dans le plugin : LocalFiles Editor > configuration Ce plugin permet de compléter le fichier de configuration de Piwigo d’une manière simple. Ajouter les lignes suivantes dans 'configuration locale ': $conf['picture_ext'] = array('jpg','JPG',’jpeg’,’png’); // pour limiter les extensions à prendre en compte $conf['sync_exclude_folders'] = array('@eaDir'); // pour exclure des répertoires Les répertoires ‘@eaDir’ sont des répertoires cachés propres à Synology. On peut ajouter d’autres répertoires à exclure dans cette liste, par exemple si on a utilisé Picasa au préalable il faut rajouter ‘.Originals’ et ‘.picasaoriginals’, ou encore ‘raw’ si les raw sont stockés dans des répertoires ‘raw’ de l’arborescence. le plugin ‘Admin Tools’ ajoute des raccourcis utiles pour administrer le site. 5 Vérification de la configuration Menu Administration > Outils > Maintenance : Environnement On peut vérifier que PHP et MySQL, ainsi que la bibliothèque graphique ImageMagick sont correctement installés. 6 Synchronisation avec le ou les répertoires contenant les photos Normalement on devrait pouvoir utiliser le ’Gestionnaire des sites’ pour créer des liens sur les répertoires du nas où se trouvent les photos. Mais en pratique cette méthode occasionne de nombreux dysfonctionnements. Pour éviter ces dysfonctionnements il suffit de créer des liens symboliques sur le NAS, et on obtient ainsi un fonctionnement correct de la synchronisation de Piwigo. Avertissement : Maintenant on va entrer dans les entrailles du NAS, il faut être prudent car on peut gravement endommager le NAS en faisant une fausse manipulation. Cette solution nécessite de se connecter au NAS en SSH Il faut au préalable autoriser l’accès au NAS en SSH, dans le panneau de configuration : ‘Terminal & SNMP’ > Terminal : cocher ‘activer le service SSH, par sécurité modifier le port SSH par défaut. On peut accéder au NAS en SSH avec le logiciel Putty ( https://www.putty.org ) On arrive sur cette fenêtre Saisir votre login et mot de passe : Login as: ADMIN ADMIN@192.168.1.20's password: Synology strongly advises you not to run commands as the root user, who has the highest privileges on the system. Doing so may cause major damages to the system. Please note that if you choose to proceed, all consequences are at your own risk. Could not chdir to home directory /var/services/homes/ADMIN: No such file or directory ADMIN@Mon_NAS:/$ Ensuite on passe en mode sudo (super utilisateur) ADMIN@Mon_NAS:/$ sudo -i Password: root@Mon_NAS:~# Se positionner dans le répertoire ‘galleries’ de piwigo : roo@Mon_NAS:~# cd /volume1/web/photo_charles/galleries Pour faire un lien symbolique ‘nom_du_lien’ sur un répertoire ‘repertoire_cible’ la syntaxe est : cible nom du lien ln -s repertoire_cible’ ‘nom_du lien’ root@Robert:/volume1/web/photo_charles/galleries# ln -s /volume1/photo_test lien_photo_test On peut créer plusieurs liens symboliques. Quand on fait un dir dans le répertoire ‘galleries’ les liens symboliques s’affichent en cyan, sous la forme : ‘nom_du_lien’ -> ‘repertoire_cible’ Pour supprimer un lien symbolique la syntaxe est : unlink nom_du lien Pour avoir la liste de tous les liens symboliques se placer à la racine et saisir : find . -type 1 Quand tous les liens sont créés, quitter Putty. Revenir dans l’application Piwigo, et lancer Administration > Outils > Synchroniser : synchronisation (./galleries) 7 La syntaxe des noms des répertoires et des fichiers Le manuel de Piwigo préconise de n’utiliser ni espace, ni caractères accentués dans les noms des répertoires et des fichiers. On peut passer outre à ces recommandations en ajoutant avec le plugin LocalFiles Editor : // permet les caractères accentués et l'espace ( juste avant le \ ) dans les noms de fichiers // pour l'apostrophe ça ne marche pas $conf['sync_chars_regex'] = '/^[a-zA-Z0-9éè~àâ%&êñ!ûëçïÁÂÀÃ´`‘’()-_. \']+$/'; (Merci à k5 de piwigo.org pour l’info) Ceci autorise dans les noms de répertoires et des fichiers photo les caractères accentués et les espaces. J’utilise cette fonctionnalité, et à ce jour avec 90000 photos et 1200 albums ça marche, à l’exception de l’apostrophe que j’ai dû supprimer de quelques noms de répertoire. Si les albums créés dans piwigo ne sont pas ceux attendus on peut toujours supprimer le lien symbolique, les répertoires et les photos originales ne sont pas affectés, et on peut faire de nouveaux essais, jusqu'à la présentation attendue. 8 Le classement des photos, la structure des répertoires et les albums Lorsque l’on active la synchronisation de ‘galleries’, Piwigo va parcourir les liens symboliques créés dans ‘galleries’ et pour chaque répertoire il va créer (ou mettre à jour) automatiquement un album et créer des miniatures pour chaque photo. C’est donc la manière dont on a classé les photos qui va conditionner la création des albums. Personnellement mes photos sont classées par date, en deux catégories (photos numériques et scans) selon le schéma suivant : NAS | |__ Mes Photos | |__ photo | | |__ 2000-2009 | | |__ 2000 | | … | | |__ 2009 | | … | | |__ 2010-2019 | | … | | |__ 2020-2025 | | | |__ scan | |__ 1920-1949 | |__ 1950-1979 | |__ 1980-1989 | |__ 1990-1999 | |__ Mes Vidéos | |__ web |__ photo_charles C’est la manière dont sont définis les liens symboliques qui va déterminer l’arborescence des albums de base dans piwigo Exemple 1 Lien_photo -> /volume1/Mes Photos/photo Va créer 3 albums de niveau 1 ( 2000-2009, 2010-2019, 2020-2025 ) Lien_scan -> /volume1/Mes Photos/scan Va créer 4 albums de niveau 1 ( 1920-1949, 1950-1979, 1980-1989, 1990-1999 ) Au final ces 2 liens vont créer 7 albums de niveau 1, et des albums pour tous les sous-répertoires selon l'arborescence. Exemple 2 Lien_photo -> /volume1/Mes Photos Va créer 2 albums de niveau 1 ( photo, scan ) et tous les albums correspondants aux sous-répertoires. Exclusion des répertoires à ne pas intégrer à piwigo On peut exclure des répertoires, mettant la ligne suivante dans le plugin LocalFiles Editor : $conf['sync_exclude_folders'] = array('@eaDir',’raw’,’edition’); On va ainsi exclure les répertoires ‘raw’ et ‘edition’ ; à compléter avec tout autre répertoire que l’on ne souhaite pas voir comme album. Pour lancer une synchronisation : Administration > Outils > Synchroniser : synchronisation ./galleries Smart Albums - albums automatiques Les liens entre les photos sur le NAS et piwigo étant définis, on peut ensuite réaliser des albums personnalisés selon les thèmes voulus (voyages, famille, portrait etc … ) avec le plugin ‘SmartAlbums’ en utilisant les ‘tags’ des photos. (merci à mistic100 pour ce plugin !! ) A noter : pour que l’album apparaisse la première fois, il est impératif de définir une photo comme ‘représentante’ pour l’album. Pour la gestion des ‘tags’ j’utilise le logiciel open source DIGIKAM ( https://www.digikam.org ) qui permet de gérer les tags de manière hiérarchique, et surtout d’écrire les métadonnées dans les photos. Aussi si on change de logiciel de présentation, ou bien en cas de problème avec la base de données de piwigo , les tags sont toujours là !! On peut gérer la hiérarchie des tags comme on le souhaite, avec la possibilité de sélectionner ou non chaque niveau. Album voyage Pays 1 Pays1 ville 1 Pays1 ville 2 Pays 2 Faune Oiseau Mésange Mésange charbonnière Mésange bleue Chardonneret Mammifère Chamois On peut aussi renommer, supprimer ou fusionner les tags très facilement. DIGIKAM intègre également un module de reconnaissance faciale. DIGIKAM intègre aussi un éditeur photo très sommaire pour les jpg Pour l’édition des raw j’utilise le logiciel open source DARKTABLE ( https://www.darktable.org/install/ ) Album classique Outre les 'Smart Albums' l'interface de piwigo permet de créer sa propre architecture d'album, et d'y associer des photos qui seront sélectionnées dans les albums de base. 9 Inclure des vidéos mp4 dans les galeries de photos Piwigo ne lit pas nativement les vidéos, il faut installer le plugin ‘VideoJS’ Créer un lien symbolique entre les vidéos du nas et pwigo. Lien_video -> /volume1/Mes Vidéos Activer le plugin VideoJS, dans la configuration du plugin choisir lecteur : Native Browser Lancer une synchronisation : Administration > Outils > Synchroniser : synchronisation ./galleries Les vidéos vont être reconnues comme des photos, et un album 'Mes Vidéos' va être créé. Ensuite on peut associer les vidéos aux albums souhaités de la manière suivante. Lancer la commande : Administration > Photos > Gestion par lot : All videos > sélectionner une ou plusieurs vidéos > Action : Associer à l'album : choisir un album > Appliquer l'action La ou les vidéos choisies vont apparaitre dans l'album sélectionné. Elle seront représentées par une icône de pellicule de cinéma. L'icône représentant la pellicule se nomme mp4.png et se trouve dans ./piwigo/plugins/piwigo-videojs/mimetypes, on peut la remplacer par ce que l'on veut. Si l’on souhaite afficher une image de la vidéo en lieu et place de l’icône, il faut en extraire une image (avec l’appareil photo dans vlc par exemple), il faut donner à ce fichier jpg ou png le même nom que la vidéo, et placer ce fichier dans un répertoire nommé ‘pwg_representative’ qui sera positionné sous le répertoire contenant la vidéo. Un clic sur l'icône et c'est partie pour la séance de cinéma ... (testé sur Firefox, Edge, Chrome et Opéra) 10 Groupe, Utilisateurs et Permissions Avant de publier votre site, créer des groupes avec des utilisateurs pour définir qui verra quoi. A noter que le webmaster, le 1er utilisateur créé ne voit pas les albums privés. Pour qu’il puisse les voir pensez à créer un groupe qui voit tout et mettez le dedans !! En ce qui me concerne les albums issus des liens symboliques sont privés à usage de l’administrateur, et les albums créés avec ‘SmartAlbums’ sont soit Publics, soit Privés selon les cas. 11 Documentation - Personnalisation de l’interface La documentation complète de piwigo se trouve là : https://doc-fr.piwigo.org/ On peut personnaliser l'application avec de nombreux plugins : https://fr.piwigo.org/ext/ Un grand merci à ceux qui développent et maintiennent Piwigo !!! DARKTABLE + DIGIKAM + PIWIGO = le trio gagnant !!! _______________________________________________________________________________________ PS : n’hésitez pas à commenter, et à critiquer ce tuto, je le mettrai à jour si besoin. Première version 14/01/2023, V2 - Mise à jour 02/02/2023, V3 – Mise à jour 06/02/2023 V4 – Mise à jour 17/03/2023, V5 – Mise à jour 16/04/2023, V6 - Mise à jour 22/12/2024 ( suppression du § Gestionnaire de sites ) V7 - Mise à jour 21/02/2024 ( DSM7 , Piwigo 15.3 ) V8 - Mise à jour 02/01/2026 (DSM7.3 12/2025 recul sur la politique restrictive des disques, http lecture et http lecture + écriture ( à la place de SYSTEM )

le 16 avril 20233 a
26 réponses
1

Bonjour, J'ai un site Wordpress / Woocommerce / Thème Flatsome sur mon NAS, en passant par les paquets syno. Cela fait un bout de temps que wordpress me "presse" pour changer de version PHP, actuellement en 7.4 Sauf que ça fait plusieurs années que j'essaie sans succès. - Je crée un nouveau profil PHP dans le Webstation (paramètre du langage de script), en ajoutant la totalité des extensions. Je garde les options par défaut pour le reste. - Je sélectionne ce profil pour mon site dans "service web" Ensuite je teste mon site et il fonctionne en apparence, à l'exception près que l'on ne peut ajouter aucun article dans le panier, ni accéder à une commande : une page grise apparaît lorsqu'on veut accéder au panier par exemple. Bref, ça semble être un souci avec woocommerce ? Voici mon log d'erreur : [25-Jul-2025 13:36:16 UTC] PHP Fatal error: Uncaught TypeError: ftp_rename(): Argument #1 ($ftp) must be of type FTP\Connection, null given in /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php:379 Stack trace: #0 /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php(379): ftp_rename(NULL, '/var/services/t...', '/volume1/web/at...') #1 /volume1/web/mon-site/wp-content/themes/flatsome/inc/admin/kirki/modules/webfonts/class-kirki-fonts-downloader.php(115): WP_Filesystem_FTPext->move('/var/services/t...', '/volume1/web/at...', true) #2 /volume1/web/mon-site/wp-content/themes/flatsome/inc/admin/kirki/modules/webfonts/class-kirki-fonts-downloader.php(42): Kirki_Fonts_Downloader->get_local_files_from_css('/* cyrillic */\n...') #3 /volume1/web/mon-site/wp-content/themes/flatsome/inc/admin/kirki/modules/webfonts/class-kirki-fonts-downloader.php(30): Kirki_Fonts_Downloader->get_local_font_styles('/* cyrillic */\n...') #4 /volume1/web/mon-site/wp-content/themes/flatsome/inc/admin/kirki/modules/webfonts/class-kirki-modules-webfonts-embed.php(155): Kirki_Fonts_Downloader->get_styles('https://fonts.g...') #5 /volume1/web/mon-site/wp-includes/class-wp-hook.php(324): Kirki_Modules_Webfonts_Embed->the_css('') #6 /volume1/web/mon-site/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array) #7 /volume1/web/mon-site/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #8 /volume1/web/mon-site/wp-content/themes/flatsome/inc/admin/kirki/modules/css/class-kirki-modules-css.php(205): do_action('kirki_dynamic_c...') #9 /volume1/web/mon-site/wp-content/themes/flatsome/inc/admin/kirki/modules/css/class-kirki-modules-css.php(122): Kirki_Modules_CSS->print_styles() #10 /volume1/web/mon-site/wp-includes/class-wp-hook.php(324): Kirki_Modules_CSS->print_styles_inline('') #11 /volume1/web/mon-site/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array) #12 /volume1/web/mon-site/wp-includes/plugin.php(517): WP_Hook->do_action(Array) #13 /volume1/web/mon-site/wp-includes/general-template.php(3192): do_action('wp_head') #14 /volume1/web/mon-site/wp-content/themes/flatsome/header.php(17): wp_head() #15 /volume1/web/mon-site/wp-includes/template.php(810): require_once('/volume1/web/at...') #16 /volume1/web/mon-site/wp-includes/template.php(745): load_template('/volume1/web/at...', true, Array) #17 /volume1/web/mon-site/wp-includes/general-template.php(48): locate_template(Array, true, true, Array) #18 /volume1/web/mon-site/wp-content/themes/flatsome/page.php(17): get_header() #19 /volume1/web/mon-site/wp-includes/template-loader.php(106): include('/volume1/web/at...') #20 /volume1/web/mon-site/wp-blog-header.php(19): require_once('/volume1/web/at...') #21 /volume1/web/mon-site/index.php(17): require('/volume1/web/at...') #22 {main} thrown in /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php on line 379 [25-Jul-2025 13:36:16 UTC] PHP Fatal error: Uncaught TypeError: ftp_nlist(): Argument #1 ($ftp) must be of type FTP\Connection, null given in /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php:438 Stack trace: #0 /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php(438): ftp_nlist(NULL, '/volume1/web/at...') #1 /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php(456): WP_Filesystem_FTPext->exists('/volume1/web/at...') #2 /volume1/web/mon-site/wp-content/plugins/woocommerce/src/Internal/Admin/Logging/FileV2/File.php(254): WP_Filesystem_FTPext->is_file('/volume1/web/at...') #3 /volume1/web/mon-site/wp-content/plugins/woocommerce/src/Internal/Admin/Logging/FileV2/File.php(437): Automattic\WooCommerce\Internal\Admin\Logging\FileV2\File->is_writable() #4 /volume1/web/mon-site/wp-content/plugins/woocommerce/src/Internal/Admin/Logging/FileV2/FileController.php(135): Automattic\WooCommerce\Internal\Admin\Logging\FileV2\File->write('2025-07-25T13:3...') #5 /volume1/web/mon-site/wp-content/plugins/woocommerce/src/Internal/Admin/Logging/LogHandlerFileV2.php(60): Automattic\WooCommerce\Internal\Admin\Logging\FileV2\FileController->write_to_file('fatal-errors', '2025-07-25T13:3...', 1753450576) #6 /volume1/web/mon-site/wp-content/plugins/woocommerce/includes/class-wc-logger.php(189): Automattic\WooCommerce\Internal\Admin\Logging\LogHandlerFileV2->handle(1753450576, 'critical', 'Uncaught TypeEr...', Array) #7 /volume1/web/mon-site/wp-content/plugins/woocommerce/includes/class-wc-logger.php(236): WC_Logger->log('critical', 'Uncaught TypeEr...', Array) #8 /volume1/web/mon-site/wp-content/plugins/woocommerce/includes/class-woocommerce.php(413): WC_Logger->critical('Uncaught TypeEr...', Array) #9 [internal function]: WooCommerce->log_errors() #10 {main} thrown in /volume1/web/mon-site/wp-admin/includes/class-wp-filesystem-ftpext.php on line 438 J'ai essayé avec PHP 8.0 8.1 et 8.2 et ce sont les mêmes symptômes. Dès que je repasse à la version 7.4, le site refonctionne parfaitement. Versions installées : wordpress 6.8.2 woocommerce 9.7.0 flatsome 3.19.15 (thème) Une idée du problème ?

le 25 juillet 2025le 25 juil.
3 réponses

Problème résolu (par un autre moyen que je vais décrire, on sait jamais si ca peut aider pour plus tard). j'ai finalement créer un domaine sur duckdns.org. monsite.duckdns.org. Sécurité puis certificat et Ajout certificat lets encrypt sur ce domaine. Sur web station j'ai pu créer l'hôte virtuel sur ce nom d'hôte toujours en associant le dossier racine de mon site dessus. merci d'avoir pris le temps de m'aider :)

le 9 novembre 2025le 9 nov.
4 réponses

Bonjour Dans ta configuration il te manque au moins un enregistrement dans WebStation => Portail Web => Portail définis par l'utilisateur (nom d'hote)

le 7 novembre 2025le 7 nov.
4 réponses

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

le 10 novembre 2025le 10 nov.
4 réponses

C'est ce qu'il me semblait aussi mais lorsque j'essai de créer un autre profil virtual host et qu'en nom d'hôte j'entre mon domaine, il me dit que le domaine est déjà utilisé (par le serveur default) surement : sur internet ils disent de passer par un sous domaine etc mais jusqu'à présent je n'avais pas eu besoin de le faire donc ya forcément quelque chose qui a changé par rapport a la config d'il y a quelques jours. Et quand j'essai d'en créer un via les ports et non le nom d'hôte il me dit que les ports sont déjà utilisés (par le serveur par defaut du coup). et via DSM on ne peut pas toucher a la config de serveur par défaut.

le 7 novembre 2025le 7 nov.
4 réponses

Rechercher par étiquettes

Rechercher par auteur

Type du contenu

Forums

Calendriers

Blogs

Rechercher les résultats dans…

Rechercher les résultats qui contiennent…

Date de création

Début

Fin

Dernière mise à jour

Début

Fin

Filtrer par nombre de…

Nombre minimal de commentaires

Nombre minimal de réponses

Nombre minimal d’avis

Nombre minimal de vues

Inscription

Début

Fin

Groupe

AIM

MSN

Website URL

ICQ

Yahoo

Jabber

Skype

Pays / Ville

Intérêts

Mon NAS

Information importante

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)