oracle7

@xmaret Bonjour, "Panneau de configuration / Options régionnales / Service NTP" Cordialement oracle7😉

@McBernic Bonjour, Cordialement oracle7😉

@PiwiLAbruti Bonjour, Je parles du script Windows "vpn-route.ps1" mais ta réponse intéressera sûrement aussi les utilisateurs Mac pour leur cas ... Cordialement oracle7😉

@xmaret Bonjour, L'application de double authentification Google marche très bien, j'utilise cette méthode depuis bien longtemps sans aucun problème en local comme depuis l'extérieur. Le soucis vient très souvent d'un problème d'horloge avec le NAS et l'application. Sur le NAS il faut que tu actives le service NTP afin d'avoir toujours le bon horaire. Le TUTO sur la sécurisation des accès décrit très bien comment configurer l'application elle même. C'est pas plus compliqué. Cordialement oracle7😉

@PiwiLAbruti Bonjour, Je rejoins l'interrogation de @tempinou à propos du script de routage que tu as écrit et cité dans ce post (page 1 du TUTO) : Malheureusement pour les non initiés, dont je fait partie, tu ne dis pas où doit être placé ce script pour qu'il se déclenche sur l'évènement de connexion au VPN. C'est peut-être évident mais j'ai beau éplucher le TUTO je n'ai rien trouvé en ce sens. Merci de tes savantes lumières 😀 Cordialement oracle7😉

@Jeff777 Bonjour, Effectivement tu as raison c'est une solution palliative, mais je préfère ne pas trop en parlé car comme tu le dis toi même et à juste titre : "ça nécessite de remettre les fichiers dans l'état initial pour le test suivant". Du coup selon le niveau de l'utilisateur (qui est difficile à appréhender tu en conviendras aussi aisément), ce sont des manipulations loin d'être anodines et qui peuvent être sources de beaucoup d'erreurs. Voilà c'est tout ... Cordialement oracle7😉

@sbre 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. Cela dit rassures-toi il n'est pas trop tard pour bien faire ... Surtout après 13 posts ... J'ai un problème similaire. Pour l'instant je n'ai trouvé que cet embryon de solution mais sans garantie : Ajouter dans la section "environment:" du fichier "docker-compose.yml" l'option : "- DOCKER_MODS=linuxserver/calibre-web:calibre". Et j'ai trouvé aussi qu'il faudrait faire ceci (valable avec l'image technosoft2000/calibre-web mais je ne sais pas si c'est aussi applicable à l'image linuxserver/Calibre-web que j'envisage d'utiliser) : Cordialement oracle7😉

@.Shad. @quart-temps Bonjour, Encore des questions "existentielles" pour ma bonne compréhension : Je n'ai pas trouvé dans la doc docker-compose l'option "APPNAME" alors qu'elle fait partie des variables d'environnement dans les copies d'écran ci-avant. Est-elle renseignée par le système après création du conteneur ? Quelle est son utilité ? Il n'y a rien concernant l'usage d'un réseau par le conteneur. Est-ce normal ? Si Oui ou Non, pourquoi ? Le réseau "bridge" est utilisé par défaut et on a pas besoin de le préciser ? Enfin vis à vis de l'usage : comment cela se passe dans le cas où l'on souhaite lire un livre avec une tablette ou une liseuse depuis l'extérieur ? Il suffit simplement depuis ce périphérique de se connecter (avec VPN pour pas) à par ex : "liseuse.ndd.tld" sachant qu'une redirection est en place dans le proxy inversé du NAS telle que "htpps://liseuse.ndd.tld:443" vers "http://localhost:8083" ? Merci de vos réponses. Cordialement oracle7😉

@hieronimus Bonjour, Lors de tes tests, attention de ne pas dépasser la limitation de Let'sEncrypt fixée à 5 essais par semaine ! Après tu serais bloqué pour une semaine à compter de la dernière tentative. Cordialement oracle7😉

@hieronimus, @bruno78 Pour mémoire, dans ton message initial tu ne parlais que de "ndd.tld" erroné. Donc sans plus d'informations, mon analyse et ma réponse se sont limitées à l'examen du "ndd.tld". Bien : maintenant, indirectement tu viens de mettre le doigt sur un point qui nous avait échappé car non envisagé. C'est très bien et je t'en remercie car on va pouvoir corriger et prendre en compte ce cas de figure. J'en conclue aussi, qu'il nous faut modifier le message d'erreur pour être plus précis suite au contrôle qui est effectué pour prendre en compte aussi dans le message un défaut sur "Le_Alt". Accessoirement je m'étonne à propos du contenu de "Le_Alt". A mon humble avis il n'est pas nécessaire de préciser les wilcards suivants : "*.abap.ndd.tld,*.java.ndd.tld,*.wso2.ndd.tld" dans le champ "Autres noms de l'objet" (SAN). Je me permet de te rappeler que les noms de domaines répondent à une structure hiérarchique dont le sommet est le "tld". En conséquence, ton ajout est inutile car ces domaines de 4ème et 3ème niveau ("*.abap.ndd.tld,*.java.ndd.tld,*.wso2.ndd.tld") sont couverts par "*.ndd.tld". Indirectement, c'est peut-être aussi pour cela que implicitement cet aspect (ton ajout) n'a pas été envisagé car 'est une règle évidente. Cordialement oracle7😉

@hieronimus Bonjour, Le script vérifie que le nom de domaine figurant dans la commande de renouvellement est conforme à celui qui a été enregistré dans le fichier ndd.tld.conf. Donc si tu as ce message, c'est que tu l'as certainement mal saisi dans la commande de renouvellement (python /volume1/Scripts/acme_renew.py -l votre-domaine.tld) . Vérifies cela. OU Si tu as exécuté le script python en mode manuel (avec l'option -f) dans une session SSH avec PuTTY pour forcer le renouvellement, c'est que tu as aussi mal saisi la commande. Puisque tu dis avoir sauvegardé tes manipulations sous PuTTY, examines les attentivement à ce niveau. Je ne peux te dire mieux sans les voir. Si tu veux, envoies moi en MP pour analyse, tes fichiers logs acmelog et acme_renew.log.1 mais avant, caches, en fait remplaces ton domaine par "ndd.tld" et masques tes éventuels identifiant/MdP ainsi que les valeurs des clés OVH. Pour ton info il n'existe pas de variable SAVED_OVH_CK. Seulement OVH_CK. Cordialement oracle7😉

@.Shad. Bonjour, Comme je ne suis pas convaincu de leur utilité (la doc Github ou dockerhub ne disant rien à leur propos, même dans leurs exemples de configuration), je vais faire abstraction de ces variables et verrais bien ce qui ce passe. Il sera toujours temps de les rajouter si besoin en est vraiment. Merci tout de même de ta réponse. Cordialement oracle7😉

@McBernic Bonjour, Si cela marche via le wifi, c'est que manifestement tu passes directement par ton réseau local. Si en 4G, donc depuis l'extérieur, cela ne marche pas c'est que tu es mal configuré soit sur la box et/ou soit sur le NAS. Sur la livebox, les ports 80 et 443 doivent être transférés via le NAT/PAT (menu Réseau) vers ton NAS (ne pas les ouvrir dans le pare-feu de la Livebox). Sur le NAS, les ports 80 et 443 doivent être autorisés/ouverts dans le pare-feu du NAS. Utiliser QuickConnect n'est en aucun cas une bonne idée ni même une bonne solution même si cela marche en apparence. D'une part ce type de liaison est réputée ne pas être stable et d'autre part TOUT ton traffic passe par les serveurs de Synology. En termes de confidentialité on fait mieux... Il est nettement préférable que tu configures dans DSM un DDNS avec un domaine en synology.me (par ex : NomDuNAS.synology.me), à défaut d'avoir ton propre domaine et que tu utilises ce "NomDuNAS.synology.me" pour réaliser tes connexions avec les applications DSxxxx depuis l'extérieur sans oublier de suffixer avec le port 443 l'URL de connexion (ie : NomDuNAS.synology.me:443). Cela marchera sûrement mieux. Maintenant c'est toi qui voit ... Cordialement oracle7😉

@.Shad. Bonjour, OK merci pour cette explication très détaillée. Je comprends mieux maintenant ta démarche et d'où l'inscription en dur des variables SYNO_x dans le script. Cette explication qui ne manquera pas d'intéresser @bruno78 dans ses travaux actuels. Cordialement oracle7😉

@.Shad. Bonjour, OK je l'avais compris mais ma question portait sur l'utilité de ces variables ? Cordialement oracle7😉

@quart-temps Bonjour, Merci de ta réponse rapide. Donc un seul utilisateur type Liseuse puis c'est à gérer avec le backend admin. Je suppose que le backend admin de calibre-wed est accessible via un menu de l'application une fois connecté à celle-ci, non ? Pour les variables, je pose la question car je viens justement d'éplucher la doc sur github mais sans succès, peut-être que j'ai mal cherché aussi ... Cordialement oracle7😉

@McBernic Bonjour, Tu ne dois activer le service uPNP sur la livebox UNIQUEMENT si tu as un décodeur TV orange qui lui est connecté car c'est obligatoire pour son bon fonctionnement. Si tu n'utilises pas de décodeur TV d'orange alors comme te la dit @maxou56 précédemment tu crées un trou béant dans la sécurité de ton réseau local qui deviens accessible de l'extérieur. Donc à désactiver dans ce cas précis. A coté de cela, si ce n'est déjà fait je t'invite fortement à lire et appliquer le TUTO sur la sécurisation des accès au NAS. Cordialement oracle7😉

@quart-temps Bonjour, Dans ce TUTO tu parles d'UN utilisateur "Liseuse" dont tu récupères les PUID et GUID. Mais lorsque l'on dispose de plusieurs utilisateurs potentiels, à part leur donner les droits qui vont bien sur les répertoires partagé docker et Bd_Calibre, comment fait-on pour les PUID et GUID de chacun ? Il faut aussi les mettre en variables de la section "environment:" ? C'est pas clair pou moi ... Pour comprendre, quelle est l'utilité de définir respectivement les variables PATH, HOME et TERM ? Cordialement oracle7😉

@Dut Surleweb Bonjour, Là je crois que tu vas trop vite en besogne si je puis dire. Je te rappelle que après toutes modifications dans la zone DNS d'un domaine, il faut en général attendre 24h pour quelles soient effectives. C'est à dire qu'elles aient été prises en compte par tous les serveurs DNS du monde. Tu peux suivre ce déploiement en interrogeant régulièrement avec ton nom de domaine le site https://www.whatsmydns.net . Donc soit patient et attends pour relancer la demande de certificat. De plus, Let'sEncrypt limite à 5 par semaine ce nombre de demandes (honorées ou pas). Donc si tu dépasses 5, alors tu seras bloqué et tu devras attendre une semaine complète à compter de la dernière demande pour pouvoir en relancer une. C'est comme cela que cela marche ! Cordialement oracle7😉

@.Shad. Bonjour, Là tu m'étonnes fortement car j'ai du mal à comprendre pourquoi tu dois te passer de ces variables, vu que acme.sh en a besoin pour faire le déploiement et que tu l'utilises en ligne 175. Il est quand même plus sûr à mon sens de les récupérer selon le certificat dans le fichier ndd.tld.conf que de les coder en dur dans ton script aux lignes 168 à 174. Peut-être que cela pour t'aider. C'est assez clair il me semble même si cette commande getops est à la fois compliquée et puissante. Sinon, pourquoi ne pas utiliser tout simplement la notation "$n" avec n=0 pour la commande et n=1 à X paramètres passés pour récupérer les valeurs de ces paramètres et ensuite gérer cela avec un "case" ou une boucle "for i in "$@" "? Cordialement oracle7😉

@seb46 Bonjour, Puisque tu as toujours le message "All TAP-Windows adapters on this system are currently in use.", peux-tu STP faire une copie d'écran des tes connexions réseaux Cordialement oracle7😉

@.Shad. Bonjour, Comme à ton habitude, encore un excellent TUTO. Bravo ! 😀 Juste quelques remarques et suggestions : Dans le script, sauf erreur de ma part, j'aurais codé aux lignes 257 et suivantes : echo -e "### STEP 5 ###\n" certificate_deployment_1 #certificate_deployment_2 #certificate_deployment_3 ... #certificate_deployment_N saved_syno_values_removing pour ne pas répéter à chaque fois la ligne "saved_syno_values_removing" à moins qu'elle soit obligatoire après chaque déploiement, dans ce cas oublies la remarque. A ce niveau, il te manque la variable "SYNO_DID" qui doit être renseignée avec la valeur du cookies DID lorsque l'utilisateur à mis en place la double authentification sinon cela bloquera le renouvellement du certificat. Si pas de double authentification en place alors SYNO_DID est "vide" (ou absente mais il vaut mieux qu'elle soit présente et "vide"). Maintenant pour éviter que l'utilisateur n'ai à venir modifier directement le script et donc par inadvertance faire des bêtises, je crois qu'il serait plus judicieux de passer en paramètres au script certaines variables d'environnement sachant que quelque unes peuvent être relues (puisque sauvegardées par acme.sh) directement depuis les fichiers "/usr/local/share/acme.sh/account.conf" et "/volume1/Certs/ndd.tld/ndd.tld.conf". Dernier détail : dans le script pour la fonction "zone_backup()" tu utilises des commandes "cp", il serait judicieux de leur rajouter le paramètre "-p" afin de conserver les attributs d'origine du fichier copié (propriétaire et droits). Cordialement oracle7😉

@Dut Surleweb Bonjour, J'ai été voir la doc de ton fournisseur de domaine (soit dit en passant, c'est loin d'être facile pour s'y retrouver, mais là n'est pas le problème) et je pense et maintiens que ta zone DNS est mal renseignée. Relis attentivement la doc pour t'en convaincre. Cette mauvaise définition explique que Let'sEncrypt ne trouve pas le sous-domaine nas.trucmuche.org lors de sa vérification et donc qu'il ne crée pas le certificat en conséquences. D'ailleurs, cela doit être pareil pour les autre sous-domaines bla.trucmuche.org, bli.trucmuche.org que tu cites plus haut. De fait, en regardant ta copie d'écran de cette zone DNS, je ne vois pas de définition explicite du sous-domaine nas.trucmuche.org pointant vers ton domaine trucmuche.org. Si effectivement xxx.yyy.zzz.155 est ton @IP externe (celle de ta Box) alors pour moi tu devrais avoir a minima ces deux lignes dans ta zone DNS chez Scaleway : A trucmuche.org. 14400 xxx.yyy.zzz.155 CNAME nas.trucmuche.org. 14400 trucmuche.org. La ligne existante A nas 14400 xxx.yyy.zzz.155 n'est pas correcte sur tous les points aussi bien en syntaxe qu'en valeurs des champs ! et de fait à la vue de la doc Scaleway je ne comprends pas comment tu dis pouvoir atteindre ton nas en tapant nas.trucmuche.org:5001. Ce n'est pas clair du tout ! A mon humble avis, la balle est dans ton camp pour remettre en forme correctement ta zone DNS (relis attentivement la doc pour cela) car dans l'état cela ne peut marcher correctement. C'est juste mon avis. Mais c'est toi qui voit ... Cordialement oracle7😉

@kroumi Bonjour, Oh des "rats bleus" on en voit toujours ...😜 Si tu te souviens de la lettre que tu avais attribuée à ton lecteur récalcitrant, as-tu essayé aussi avec la commande "net use X: /delete" avec X = la lettre ? Sinon on va essayer si tu veux bien, autre chose (toujours dans regedit donc ATTENTION) : Sur le bureau WIN, tu tapes WIN + R puis "regedit"(sans les guillemets !) Dans l'éditeur de registre tu vas dans l'arborescence suivante : "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU" Là dans la partie droite de l'éditeur, tu sélectionnes la clé correspondante au lecteur, tu retiens la lettre qui lui est associée (le nom de la clé) et tu supprimes la clé. Ensuite tu 2xCliques sur la clé nommée "MRUList". Dans la fenêtre qui s'est ouverte dans le champ "Données de la valeur", tu supprimes le caractère correspondant à la lettre du lecteur notée précédemment. Tu cliques sur OK pour valider. Fermer l'éditeur regedit reboot PC Si là, cela ne le fait pas alors désolé je ne sais pas ... Cordialement oracle7😉

@Dut Surleweb Bonjour, Là tu me déconcertes un peu (beaucoup) avec ces deux @IP. Habituellement l'@IP externe est attribuée par le fournisseur d'accès Internet (FAI) et correspond à l'@IP de la Box/modem qui nous relie à l'Internet. Ensuite lorsque l'on est "propriétaire" d'un nom de domaine comme toi pour trucmuche.org, chez le fournisseur de domaine dans la zone DNS du dit domaine on a un enregistrement "A" qui fait pointer le domaine en question vers l'@IP externe (celle de la Box) et des enregistrements CNAME pour chaque sous-domaine géré pointant eux vers le domaine. Ni plus ni moins. Je ne parles pas ici des enregistrements supplémentaires liés aux boites mails hébergés chez le fournisseur de domaine, c'est un autre débat ... Donc pour clarifier les choses dans le contexte ci-avant (je le répète, j'essaie de comprendre ton architecture exacte) : l'@IP en .53, est-elle celle de ta box ou bien est-ce l'@IP en .155 celle de ta box ? Par ailleurs, tu dis que "l'@IP en .155 est ton IP fixe à ton domicile" dans ce cas est-ce l'@IP locale fixe (dans ton réseau local en 192.168.x.x par ex) de ton NAS que tu as définie par un bail DHCP statique dans ta Box ? OUI/ NON ? Je joue sur les mots mais il convient ici d'appeler correctement un chat, un chat c'est important pour la compréhension, tu en conviendras aisément. Maintenant, où cela ne va pas c'est : Si en tapant nas.trucmuche.org tu atteints cette page Web, c'est justement que tu n'as pas atteint la bonne page (celle de login au NAS) et il te renvoie automatiquement vers cette page du serveur Web. Tu me suis ? Dans l'attente de tes réponses. Cordialement oracle7😉