oracle7

@Hamtary Bonjour, Donc en principe dans ta zone DNS chez OVH tu a un enregistrement MX qui pointe vers ton domaine tel que par ex : tondomaine.tld. 3600 MX 10 tondomaine.tld. Essaies d'ajouter ces enregistrements : tondomaine.tld. 86400 MX 30 mx0.mail.ovh.net. tondomaine.tld. 86400 MX 50 mx1.mail.ovh.net. tondomaine.tld. 86400 MX 75 mx2.mail.ovh.net. tondomaine.tld. 86400 MX 99 mx3.mail.ovh.net. Il te faut aussi à minima une boite mail coté OVH avec une adresse (xxxxxxxx@tondomaine.tld) identique à une de celles que tu utilises coté MailPlus sur le NAS. Ainsi si ton serveur mail sur le NAS tombe, il ne répondra donc plus et les mails à destination de xxxxxxxx@tondomaine.tld, seront redirigés (en fait resteront) sur sur ta boite mail chez OVH. C'est le principe que j'utilise dans mon TUTO. Mais attention, ceci n'est valable que pour une seule @Mail (celle que tu as gratuitement pour tout compte ouvert chez OVH) à moins que tu en ais achetées plusieurs chez OVH. Cordialement oracle7😉

@erzane Bonjour, Dans une fenêtre de CMD Windows en mode administrateur, essaies ceci : net use X: \\@IPduNAS\Gab /delete /user:usernameDSM password Cordialement oracle7😉

@limannzerga Bonjour, Comme le dis justement @EVOTk comme les serveurs de Let's Encrypt sont aux USA, tu bloques implicitement toute possibilité de renouvellement de ton certificat d'une part et d'autres part tu t'interdit l'accès à aussi bons nombres de sites français mais hébergés à l'étranger. Mais là si c'est ton choix ... Par ailleurs, désolé mais tu sembles mélanger les notions : ton certificat LE tant qu'il sera valide fonctionnera toujours pour les domaines pour le quel il a été défini. En l'occurence, comme tu as une erreur pour le domaine "test.ndd.tld" c'est que ton certificat n'est manifestement défini pour ce domaine précis. Cordialement oracle7😉

@Antonio21 Bonjour, Non tu ne les effaces pas, ils doivent être autorisés/ouvert dans le pare-feu du NAS. Par contre ils ne doivent pas être transférés dans la box vers le NAS. C'est tout. Dans ton pare-feu la première ligne qui refuse tout pour les pays "exotique", est inutile, Tu la supprimes. C'est la dernière ligne qui fait la même chose. Pour bien comprendre le principe du pare-feu : Les règles sont interprétées du haut vers le bas Tant qu'une règle d'autorisation n'est pas satisfaite, il passe à suivante vers le bas sinon il s'arrête là et ne contrôle pas les règles suivantes qui deviennent de fait inopérantes. Au final tout ce qui n'est pas autorisé/ouvert explicitement par une règle, est irrémédiablement refusé/bloqué par la dernière ligne/règle "refuser tout". Donc c'est elle qui te protège de tout le reste. Il ne faut pas cocher la case "Rediriger automatiquement les connexions HTTP vers HTTPS pour le bureau DSM". Cette redirection HTTP vers HTTPS est à faire via un fichier .htaccess après installation du package WebStation. Si tu la laisses cochée ET que tu utilises le reverse proxy, ce dernier ne fonctionnera pas correctement. Voir le TUTO : Reverse Proxy c'est expliqué en détail. Cordialement oracle7😉

@Stixen92 Bonjour, Il n'y a pas que cela dans les logs. Pour moi le problème est ailleurs même si le message parle du package socat. De plus, comme dit dans le TUTO lors de l'installation de acme.sh, on utilise pas le "mode standalone" donc le package socat n'est pas à installer ni à utiliser. Attention aux nombre de tentatives de renouvellement du certificat --> maxi 5 par semaine. Après tu seras bloqué pour une semaine calendaire à compter de la dernière tentative. Cordialement oracle7😉

@Supermatos.com Bonjour, Vis à vis de l'assistant de sécurité, manifestement tu n'as pas lu ni suivi le TUTO Sécuriser les accès à son NAS, sinon tu aurais vu qu'il y a 3 règles de ce conseiller sécurité dont il ne faut pas tenir compte (ne pas activer), et notamment celle à propos des ports standards du NAS 5000 et 5001. Moralité, on ne change pas les ports standards du NAS et surtout sans en connaitre toutes les conséquences et subtilités associées. Pour ce qui est des applications, on ne change leurs ports qu'au niveau que tu indiques : "DSM - Panneau de configuration - Portail desApplications - Application" ou via l'utilisation du reverse proxy. Cordialement oracle7😉

@limannzerga Bonjour, Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Par soucis de sécurité et confidentialité, il est préférable pour toi de masquer ton domaine et de le remplacer par une valeur générique "ndd.tld" dans les échanges que tu as. Sinon je t'invites aussi à regarder et suivre ces deux TUTOs pour bien démarrer. TUTO : Débuter avec un NAS Synology TUTO : Sécuriser les accès à son NAS Les ports 80 et 433 sont-ils bien ouverts/autorisés dans le pare-feu du NAS ? Cordialement oracle7😉

@YAQ Bonjour, Content pour toi que tu ais trouvé ici la solution à ton problème mais sans faire le rabat joie, comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Cordialement oracle7😉

@Stixen92 Bonjour, Que disent les logs "acmelog" et "acme_renew_python.log.1" situés dans "/volume1/Certs/Acme_renew/" ? C'est la première chose à examiner lorsque tu as un dysfonctionnement du processus. Assures-toi que tes mots de passe (à tous les niveaux) ne comportent pas de caractères "exotiques" spéciaux (que des lettres majuscules, minuscules et des chiffres !). C'est souvent cela qui crée les blocages. Cordialement oracle7😉

@Pascalou59 Bonjour, Pour supprimer toutes les clés définies, tu fais : un " cd /root/.ssh " puis un " rm -i ./authorised_keys " qui te demandera confirmation avant la suppression effective. Pas la peine de supprimer le répertoire " .ssh ". Accessoirement, si j'étais toi je me documenterais a minima sur les commandes de base du shell bash. Il y a plein de TUTOs disponibles sur la toile. Car certaines comme par ex la commande " rm " peuvent s'avérer très dangereuses pour ton système, surtout lorsque utilisées sous "root", si elles sont mal exploitées. Mais c'est pour toi et ce n'est que mon avis ... Cordialement oracle7😉

@Antonio21 Bonjour, Plusieurs causes possibles, entre autres : si tu exposes à internet dans ton routeur tes ports 5000 et/ou 5001 (bien voir que ce sont des cibles de choix et privilégiées des malveillants pour atteindre les données des NAS Synology). si tu as activer le port SSH 22 qui est aussi très prisés, surtout par les chinois entre autres. Moralité, le système de blocage du NAS fonctionne bien c'est rassurant mais vérifies quand même les règles que tu as mises dans ton pare-feu (voir TUTO : Sécuriser les accès à son NAS) ainsi que les ports que tu NAT dans ta box. Cordialement oracle7😉

@Pascalou59 Bonjour, Par extension à ma mise en garde au §2 du TUTO, concernant l'usage du "vrai" root et du problème de la commande "sudo -i", je t'invites à recréer une session SSH WinSCP et/ou PuTTY pour l'utilisateur 'root' avec son mdp propre (surtout SANS caractères "exotiques" spéciaux !!!) et NE PAS utiliser de connexion SSH autre, même à partir d'un utilisateur de type "Administrateur". Il te faudra peut-être pour cela regénérer un couple de clés Privé./Publique pour "root" (voir le TUTO Accés SSH et root via DSM6). Maintenant, il est quand même étonnant que tu ne puisses pas déposer un fichier depuis Windows dans un dossier partagé du NAS. Tu as peut-être un problème réseau, aussi tout bêtement, reboot le PC et le NAS ... PS : Précédemment, quand je disais d'utiliser un dossier partagé du NAS tel que "mondossierpartagé", il faut que ce dossier partagé (au sens Synology) soit déjà existant donc avoir été créé via DSM dans "Panneau de configuration / Dossiers partagés" avec aucune restriction dessus en termes de droits. Il ne faut surtout pas que "mondossiermartagé" soit créé directement via WINSCP par ex. Ensuite tu appliques l'astuce que je t'ai donnée précédemment et la commande "cp" sous Terminal PuTTY ou WinSCP. Là cela devrait le faire 🤔 Cordialement oracle7😉

@Stixen92 Bonjour, Je vais être abrupte et j'en suis désolé, mais il te faut faire avec cette syntaxe c'est comme cela et pas autrement, faute en est aux développeurs du script acme.sh. Seuls eux pourraient t'expliquer ce qui te paraît être une incohérence. Ce que je peux t'en dire : c'est que les variables sont nommées "OVH_AK" , "OVH_AS" et "OVH_CK" pour leur usage dans le script, les deux premières sont ensuite sauvegardées sous le nom "SAVED_OVH_AK" et "SAVED_OVH_AS" dans le fichier account.conf. La variable "OVH_CK" est quant à elle normalement sauvegardée sous le même nom. Si la variable "OVH_CK" n'apparaît pas, tu la rajoutes comme je te l'ai expliqué précédemment. C'est vrai, sans que je ne sache vraiment l'expliquer, cette variable semble parfois disparaître du fichier account.conf. C'est un phénomène aléatoire bizarre, qui apparaît a priori après un renouvellement. Comme acme.sh se réinstalle tout seul systèmatiquement lorsque l'on exécute le script (pour un renouvellement par ex), peut-être qu'il réécrit complètement le fichier account.conf à cette occasion mais en le faisant malheureusement incomplètement, d'où la disparition de la variable OVK_CK. Ce n'est qu'une intuition, mais je peux me tromper ... Par ailleurs, dans la procédure, on exporte les trois variables sous leur nom "simple" pour communiquer leurs valeurs respectives au script acme.sh, c'est en quelque sorte une forme de passage de paramètres externes au script pour son fonctionnement. Donc, ne le prends pas mal, mais ne cherches pas "midi à quatorze heures", tout ceci est de la syntaxe pure, admets le simplement. Je crains que tu ne te tortures l'esprit pour rien car c'est un simplement un fait de programmation, pas propre à mon sens, je te l'accorde bien volontiers. Pour ton point2 : As-tu au moins installé le package Python3 et ses éventuelles dépendances sur le NAS ? As-tu aussi vérifié si ton NAS était compatible pour accueillir Python3 --> voir ici. Ceci est lié au script acme.sh qui met du temps pour réaliser certaines opération et à des temporisations dans les communications entre acme.sh et les serveurs d'OVH, sans parler que parfois si tu observes bien les logs, tu verras que ces serveurs OVH ne répondent pas dans les temps ce qui force acme.sh a réitérer plusieurs fois ses demandes/requêtes. J'ai constaté personnellement plusieurs fois jusqu"à plus d'une minute d'attente. Du coup la console WinSCP prend cela pour de l'inactivité (i.e. comme un programme planté) et cherche à se déconnecter. Pour éviter cela il faut éditer les paramètres de ta session SSH sous WinSCP. Tu vas dans "Session / SItes /Gestionnaire de Site" là tu sélectionnes ta session SSH via son nom de site et tu cliques sur "Editer" puis sur "Avancé ...". Tu sélectionnes la rubrique "Connexion" dans la liste à gauche et tu fixes le "time out de connexion" à 120 secondes : Cordialement oracle7😉 @bruno78 Bonjour, Pas de soucis, je reste à ta disposition pour cela. Cordialement oracle7😉

@Stixen92 Bonjour, Désolé je me suis mal exprimé en parlant de la date d'expiration, le DID comporte en fait une durée de validité fixée par la date d'expiration par rapport à sa date de création. Du coup, quand la date courante est supérieure à Date création + durée de validité alors le DID n'est plus valide. Quand tu changes manuellement la date d'expiration du DID dans FF pour la repousser aux calandres grecques, il te faut ensuite aller recopier dans le fichier account.conf la nouvelle valeur du DID dans la variable SAVED_DID. Il en est aussi de même après une mise à jour de FF car le DID est réinitialisé, il faut donc remodifier sa date d'expiration. Seulement à partir de là le NAS saura ... C'est chi... mais on n'a pas le choix que de subir cet état de fait. Tu m'as lu ma précédente réponse en "diagonale" ! Je n'ai jamais parlé de variable SAVED_OVH_CK mais de variable OVH_CK. Et pour cause, exporter une variable (par ex export OVH_CK="XXXX") n'est valable que durant la session SSH courante durant laquelle la variable reste en mémoire pour d'autres utilisations. La variable exportée n'est pas détruite à la fin du script qui l'utilise puisqu'elle n'a pas été définie dans ce script, ainsi si tu relances le script, la variable (et donc la valeur qu'elle stocke) est toujours disponible. Par contre elle est bien détruite à la fin de la session SSH. Il n'y a donc rien de bizarre. Ce que tu as constaté, est simplement normal. Par ailleurs, saches qu'en aucun cas cet export n'écrit dans un quelconque fichier et donc pas dans account.conf. Seul le script acme.sh le fait. NON, cette variable ne sert que pour et lors de la création du certificat. Le fichier account.conf sert lui, aux renouvellements du certificat. Cordialement oracle7😉

@Didus69 Bonjour, Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Je ne te comprends pas, tu fais pour le QNAP de la même manière que tu as fais pour tes 2 NAS Synology, tu ajoutes l'@IP du QNAP à la liste. Comme la liste peut contenir 5 @IP de machines tu peux même y ajouter aussi l'ASUSTOR. Non ? Par exemple : Cordialement oracle7😉

@Stixen92 Bonjour, Je ne crois pas, avec @bruno78 on connait le problème, de mémoire cela viendrait a priori du script mais sous toutes réserves. Bruno78 devait regarder cela, je ne sais où il en est sur ce point qui est finalement est plus déroutant qu'il n'est bloquant en pratique. Pour les codes d'erreur [Wed Jan 27 17:15:03 CET 2021] _error_level='2' c'est, si je ne m'abuse, une information de acme.sh qui dit avoir utiliser le niveau d'erreur 2 pour ses logs. Elle est stockée dans le DID. Bonne remarque, Non ce n'est pas normal elle devrait y figurer. Edites le fichier account.conf et ajoute à la fin une ligne tel que : OVH_CK= 'xxxxxxxxxxxxxxxxxx valeurcléConsumerKeyxxxxxxxxxxxxxxxxxxxx' N'oublies pas d'enregistrer. Cordialement oracle7😉 @Pascalou59 Bonjour, L'astuce est de copier via WIN/Mac le fichier acme_renew.py dans un dossier partagé du NAS (par exemple : "mondossierpartagé"). Ensuite soit directement sous WINSCP tu transferts par glisser/déposer ou C/C le fichier depuis "/volume1/mondossierpartagé" vers "/volume1/Scripts". Ou bien soit sous root avec sous PuTTY/Terminal_Mac tu tapes : " cp -p /volume1/mondossierpartagé/acme_renew.py /volume1/Scripts " Cordialement oracle7😉

@Pascalou59 Bonjour, Tu es bien sous "root" (le vrai !) quand tu fais cela ? Les droits chez moi sont : Cordialement oracle7😉

@Pascalou59 Bonjour, Bien c'est super ! 🤗👍 il faut maintenant passer au déploiement et mettre en place le renouvellement auto ... Cordialement oracle7😉

@Pascalou59 Bonjour, Effectivement, mais ce truc qui coince comme tu le dis, relève le plus souvent d'une erreur d'attention bénigne et ce malgré les mises en gardes que je fais dans le TUTO. Je constate à la vue des retours que la lecture est parfois faite un peu en "diagonale" car on croit savoir et on va du coup plus vite que la musique ou encore on ne percute pas sur la mise en garde. Rassures-toi tu n'es pas le premier et ne sera pas le dernier ...🤪 Toi c'était les caractères spéciaux, d'autres ce sera autre chose ... Cordialement oracle7

@Pascalou59 Bonjour, Je comprends donc après ton "Edit 2" que tout est bon maintenant. Codialement oracle7😉

@Pascalou59 Bonjour, Je t'ai répondu par rapport à cette page que tu indiquais. Les liens que je t'ai donné précédemment font référence à cette rubrique : Donc quand tu cliques sur le lien en question, il te faut ensuite user de l'ascenseur de la page pour atteindre la rubrique "/me". Tu me suis ? Cordialement oracle7😉

@laurentHCM Bonjour, A mon humble avis, je prendrais un routeur (par exemple placé en DMZ derrière la LIvebox) sur le quel j'installerai le serveur VPN si pas déjà résident de base. Cela aurait aussi l'avantage indéniable de pouvoir te passer de la Livebox en tant que routeur s'entend et ainsi pouvoir via le nouveau routeur fixer notamment tes propres serveurs DNS plutôt que d'être contraint d'utiliser les serveurs DNS reputés "menteurs" d'Orange que tu ne peux pas modifier/remplacer dans la Livebox. De plus, en reportant tout de travail de DHCP, de sécurisation du(des) réseau(x) local(aux) sur le routeur qui sera bien plus performant que la Livebox sur ces domaines, tu y gagneras largement en fiabilité globale. Maintenant ce que j'en dis ... A toi de voir ... Cordialement oracle7😉

@MarcelPahud Bienvenue à toi sur ce forum, tu verras c'est une mine d'informations. 😀 Cordialement oracle7😉

@MarcelPahud Bonjour, Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... As-tu lus et appliqués les TUTO suivants : TUTO : Débuter avec un NAS Synology TUTO : Sécuriser les accès à son NAS Dans le cas contraire, avant toutes choses, je t'invite à les suivre. On verra après, si tu veux bien, le problème de ta connexion externe. Je te fournirai alors une procédure à suivre. Reviens lorsque ton NAS sera sécurisé à minima, ce sera tout de suite plus facile sinon on risque de chercher après des dysfonctionnements alors que certaines choses n'auront pas été configurées préalablement correctement. Tu me suis ? Cordialement oracle😉

@.Shad. Bonjour, Tu as bien fait de préciser pour VPN Plus Server de SRM, on fait trop vite le raccourci avec VPN Server de DSM qui tellement proche mais avec moins de fonctions ! Merci. Cordialement oracle7😉