oracle7

@Jeoffrey Stinson-Cooper Bonjour, Si tu as branché ton PC sur l'onduleur, alors Oui il faut l'installer pour piloter ce PC. C'est très simple et efficace. Cordialement oracle7😏

@lowfab Bonjour, @GrOoT64 t'as fourni la solution dans le post sur le Reverse Proxy, du coup je n'ai rien de plus à te dire ... Cordialement oracle7😏

@bruno78 De ce que j'en comprends (sous toutes réserves !) : il mémorise les packages à "true" et récupère le "subscriber" selon le retour du script "star-stop-status" qui doit correspondre à "start". C'est peut-être là que sont gérées les dépendances ? mais pas sûr du tout ???? Ensuite il relance les packages ainsi mémorisés. Pas facile tout çà 😪 Cordialement oracle7😉

@bruno78 Bonsoir, Sans le faire spécialement tourner, regardes le code, tu verras qu'il y a 2 fonctions dédiées : lister_packages_actifs_et_services() et redemarrage_des_packages_actifs(). Elles doivent peu-être déjà faire ce que à quoi tu réfléchis. Non ? Cordialement oracle7😉

@lowfab Peux-tu STP préciser : xx.xx.xx.xx est une @IP locale à ton LAN ou une @IP Internet ? Cordialement oracle7😉

@bruno78 Waouh ! Il faut vraiment que @PPJP passe par ici, lui seul, à mon avis, saura répondre à ta question sur les dépendances. Mais, je me demande si lui ne fait pas déjà toute cette manipulation dans son script quand il liste tous les packages actifs et services puis qu'il redémarre les packages actifs ? Cordialement oracle7😉

@Thierry94 Bonjour, Pour ton information, à suivre vos échanges avec @alan.dub, j'ai essayé de créer un alias sur mon unique utilisateur de MailPlusServer comme indiqué par ce dernier. Çà marche en réception depuis une @MAIL gmail. (mais toujours pas depuis orange !) Par contre, impossible de saisir "alias@ndd.tld" comme émetteur dans MailPlus pour envoyer un MAIL alors que "userstandard@ndd.tld" marche sans problème. Tu n'es pas seul à avoir ce soucis d'alias ... Cordialement oracle7😉

@jpfangin Ton fichier de configuration est correct et la connexion s'établit. Du coup je ne vois pas quoi faire de plus pour t'aider. Désolé. Maintenant le message en question n'est qu'un warning et pas une erreur ! Donc c'est pas grave. Cordialement oracle7😉

@jpfangin Bonjour, Dans ton fichier de configuration ".ovpn", vérifies que tu as bien une ligne (en principe la 2ème) avec l'instruction : "tls-client". Sinon, ajoutes là. Cordialement oracle7😉

@lowfab Sur le NAS, avais-tu auparavant déjà enregistré un DDNS avec "zoneip.fr" avec comme fournisseur OVH ? Si OUI, alors tu ne pourras pas enregistrer un autre DDNS avec OVH comme fournisseur. Synology refuse cela, c'est un et un seul. Il te faut alors allez sur ton compte Synology et désactiver/supprimer le DDNS enrgistré. Si non, c'est bien "zoneip.fr" que tu saisis ? et pas ".zoneip.fr" ? il ne faut pas de "point" devant le domaine pour la saisie sur le NAS ! Cordialement oracle7😉

@lowfab Bonjour, Dans la zone DynHost chez OVH, tu ne doit avoir qu'une seule ligne avec ".zoneip.fr" qui a pour cible "ton@IP" (@IP externe du moment, pour ta Box/Routeur). Cordialement oracle7😉

@LeMorse Bonjour, C'est un DS918+ spécial que tu as ! 🤪 Sinon, sur https://community.jeedom.com tu n'as pas eu de réponse à ta question ? Je serais curieux de la réponse car j'hésite encore entre installer Jeedom comme toi sur le NAS (mais docker m'effraie un peu) et installer Jeedom sur un RPI4 maintenant qu'il sait booter en USB sur un SSD. Cordialement oracle7😉

@lowfab Bonjour, Oui, tu crées dans la zone DNS un enregistrement "wilcard" de type CNAME : "*.zoneip.fr" qui pointe vers "zoneip.fr" Attention, il te faudra alors modifier (voire recréer) ton certificat pour prendre en compte cela ! Cordialement oracle7😉

@Jeff777 OUI (j'avais oublié cela !), donc j'en conclue que le résultat du test "zonemaster.net" est normal quelque part ? Je donc clore le sujet. Pour le lien, effectivement c'est du "hard" ... 😛 En tous cas MERCI à toi de ton aide. Cordialement oracle7😉

@jpfangin Bonjour, Parce qu'il semblerai que la résolution DNS pose parfois des problèmes de fiabilité. Mais rassures-toi tu peux mettre ton domaine à la place de l'@IP dans le champ remote. Je fonctionne comme cela et je n'ai jamais de problèmes de connexion. Sous WIN as-tu bien installé le client OpenVPN et surtout recopié au bon endroit le fichier de configuration ".ovpn" ? (voir onglet Configuration/Avancés dans l'interface GUI) Vérifie aussi si ton fichier de configuration ".ovpn" sur WIN, comporte bien deux fois des lignes : "----------BEGIN CERTIFICATE--------------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ----------END CERTIFICATE-----------". Normalement en exportant la configuration VPN depuis ton NAS, le certificat est inclus dans le fichier de configuration ".ovpn". C'est précisé dans le Tuto pour les version récentes du paquet OpenVPN. Cordialement oracle7😉

@Jeff777 Merci de t'intéresser à mon cas. Je n'ai et n'ai jamais vu aucun enregistrement DS dans ma zone DNS chez OVH et je n'avais rien remarqué de tel auparavant. J'ai plutôt l'impression, à la vue des messages d'erreurs/warning, que OVH lors de la création du domaine, ne transmets pas partout l'info concernant le domaine et en particulier à la racine DNS nic.fr. D'où ces messages. Mais ce n'est qu'une impression ... Tu as sûrement raison car je n'ai rien modifié de mon coté. Le problème reste tout de même de comment interpréter ces résultats ? et quoi en faire ? Cordialement oracle7😉

Bonjour, Je vois que ma question ne déchaîne pas les foules ... 🤔 Cordialement oracle7😉

@bruno78 Bonjour, Intuitivement, j'aurais essayé de relancer tout simplement le processus SMB ... Cordialement oracle7😉

@yogib33r Je ne sais pas comment tu cherches, il y a pourtant plusieurs possibilités, mais bon ... Regardes ici par exemple. Lis bien au moins une fois l'ensemble du Tuto avant toutes choses. Ne te lances surtout pas "bille en tête" sans en avoir bien compris ce qui ce passe quand tu génère un certificat. il te faut juste être attentif et bien noter tout ce que tu fais. enfin ce n'est qu'un conseil... Cordialement oracle7😉

@PPJP Bonjour, Tout simplement parce que le dossier où acme met les fichiers du certificat ne porte pas le même nom selon que c’est une clé RSA ou EDSA. OK, il me semblait que le dossier (avec son chemin) où sont générés les fichiers du certificat, était défini avant la première commande de création du certificat, au moyen de l'export de la variable d'environnement 'CERT_HOME' et qu'il était automatiquement nommé avec l'intitulé du domaine concerné par le certificat. Mais effectivement en regardant de plus près le code d'acme.sh, dans le cas d'une clé ECDSA, le suffixe "_ecc" est rajouté au nom définit initialement. Maintenant je comprends mieux ... OK, pas de soucis pour revoir à la baisse les ambitions : on s'en tiendra alors à OVH tout cours pour ne pas introduire une quelconque confusion au près des utilisateurs. Et pas de paramètre supplémentaire liée à la clé de chiffrement. L'utilisateur fera son choix dès le départ. S'il veux en changer ensuite, pas la peine de compliquer le processus du Tuto pour cela, je maintiens qu'il n'aura qu'à relancer le processus avec son nouveau paramétrage. Le seul paramètre sera donc celui que tu as introduit : nombre de jours pour le cycle de renouvellement. On reste dans la simplicité ... Je ne comprends pas non plus pourquoi il y aurait cette nécessité, ces clés d'API une fois générées, sont copiées dans des variables d'environnement qui sont utilisées ensuite par acme.sh pour la création du certificat. OK certes, mais elles ressemblent étonnamment aux clés API que l'on insère manuellement dans des enregistrements TXT lorsqu'on déroule le processus acme.sh dans sa version "simple"/"basique". Voilà le pourquoi de mon interprétation de cette sauvegarde dans le fichier 'account.conf' et de leur utilité présumée. D'autant plus qu'elles portent le même nom au préfixe 'SAVED_' près et que le code d'acme.sh semble les utiliser, mais je peux me tromper... Cordialement oracle7😉

@Andrea J'utilise quand nécessaire une connexion VPN avec un fournisseur tiers vers l'extérieur depuis mon PC sur le LAN. Et quand je suis à l'extérieur, j'utilise soit une connexion OpenVPN soit une connexion VPN SSL avec le serveur VPN installé sur mon routeur, pour accéder à tout mon LAN en toute sécurité. Tout cela est on ne peut plus simple à mettre en œuvre et parfaitement sécurisé. Je ne me prends pas la tête avec des configurations que je qualifierai d'exotiques et souvent bancales ... Cordialement oracle7😉

@bruno78 Arrêtes moi si je dis encore une bêtise, mais n'existerait-il pas deux types de packages ? Ceux qui sont actifs en permanence parce qu'ils écoutent par ex un ou des ports comme Webdav et auquel cas il faille les redémarrer, et ceux qui ne sont actifs que lorsqu'on s'en sert, par ex AudioStation et auquel cas ils n'auraient pas besoin d'être redémarrés systématiquement. J'essaie comme toi de comprendre le mécanisme, d'où ces suppositions ... Cordialement oracle7😉

@PPJP Bonjour, OK mais c'est très étonnant cela, es-tu certain qu'il n'y a pas autre chose qui fait planté le script ? En toute logique, j'ai du mal à comprendre en quoi un paramétrage de longueur de clé de chiffrement peut impacter ainsi le fonctionnement d'un script. J'ai bon, Oui/Non ? Pourquoi, envisager des conversions de clés (RSA vers EDSA, EDSA vers RSA) ? Cela ne me parait pas utile à moins que tu n'ai une bonne raison en magasin. Pour mémoire le choix de la clé de chiffrement est fixée initialement lors de la constitution de la commande de création du certificat. L'utilisateur devrait à mon sens, recréer un certificat s'il souhaite changer la longueur de la clé de chiffrement lorsque la date d'expiration du certificat est atteinte. Par ailleurs, je aperçois qu'à l'usage, tel que le script est actuellement, il faille allez modifier manuellement le script pour l'adapter au contexte propre de l'utilisateur. Dans mon idée initiale, l'objectif était de faire le plus simple possible pour que le processus soit réalisable par le plus grand nombre. Aussi, je pense qu'il serait bien que le script ne soit pas modifiable pour éviter ainsi tous problèmes avec des utilisateurs non avertis. En conséquence, il serait nécessaire donc pour cela, qu'il accepte des paramètres supplémentaires qui seraient eux, définis lors de la constitution de la commande à insérer dans le planificateur de tâches et uniquement à ce moment là, et qui permettraient de prendre en compte notamment : le domaine de l'utilisateur : "ndd.tld" Le type de clé de de chiffrement (i.e. la valeur du paramètre "-- keylenght") : 2048 (défaut), 4096, ec-256, ec-394) le nombre de jour pour le renouvellement : mais cela tu l'as déjà pris en compte. Bien évidemment, avec un contrôle de la présence ou non de ces paramètres qui rejette l'exécution du script si ces derniers sont incorrects et/ou absents, selon. Désolé de "rallonger la sauce", mais cela me paraît important d'ajouter ces éléments. Enfin, si tu le veux bien 😏 C'est normal car tu n'as pas déroulé le processus de création de la même façon. Avec le Tuto, ces clés sont "exportées" une première fois pour la création du certificat. ACME.sh les inscrit alors temporairement chez OVH pour l'authentification du domaine puis les supprime de chez OVH (voir le log de création que j'ai fourni dans le Tuto). Donc ensuite, pour le renouvellement, ACME.sh a besoin de les retrouver quelque part puisque il n'y a plus d'enregistrement correspondant chez OVH (dans la zone DNS du domaine), d'où leur sauvegarde dans le fichier "account.conf". Cette façon de procéder, me paraît très sécurisante, pas de clés personnelles chez un tiers ! Comme demandé, je te joins donc le fichier "account.conf" : account.conf expurgé des informations personnelles. Une dernière question : peut-on purement et simplement remplacer dans le gestionnaire de tâches, l'actuelle commande de renouvellement (celle du Tuto) qui est active dans le gestionnaire de tâches, par celle que tu proposes avec l'usage du script ? N'y-a-t-il pas une manipulation autre à effectuer vis à vis du "cron" pour prendre en compte ce changement ? J'avoue ne pas trop maîtriser ce point. Encore MERCI à toi de bien vouloir nous aider pour finaliser de processus d'automatisation complet. @bruno78 @PPJP m'arrêtera si je dis une bêtise ..., mais n'est-ce pas tout simplement, parce que justement ces services ne sont pas des packages qu'ils n'ont pas besoin d'être redémarrés ? Cordialement oracle7😉

@Andrea Bonjour, Je connaissais cet article, mais pour ton info ce paramétrage est déjà en place chez moi mais cela ne marche pas. Comme toi, connexion externe vers le LAN impossible si une connexion VPN vers l'extérieur est active par ailleurs. J'ai donc choisi ... Car toutes les autres solutions proposées ici ou là, si bonnes soient-elles, sont à mon sens beaucoup trop compliquées à mettre en œuvre. Mais ce n'est que mon avis. Cordialement oracle7😉

@Andrea Bonjour, Je voudrais pas passer pour un rabat joie mais je crains qu'il ne te faille te faire une raison. Ce que tu souhaites faire "en même temps" c'est à dire, si j'ai bien compris : A) accéder de l'extérieur vers ton LAN et tous ses périphériques ET B) Activer une connexion VPN depuis ton NAS vers l'extérieur pour DL en BT, n'est pas possible. @Juan luis te l'a déjà expliqué précédemment et il a tout a fait raison, à partir du moment où ta connexion VPN vers l'extérieur est établie, tu as implicitement rendu ton LAN et donc ton NAS, étanche à toute connexion extérieure vers ton LAN. Sauf à te connecter via l'@IP de ton VPN (en Chine, ou Russie par ex). Mais tu ouvres en grand les portes de ton LAN à ces serveurs tiers. Question sécurité on fait mieux ... Désolé mais il te faut donc choisir : ou tu DL en BT, ou tu accèdes à ton NAS pour tout autre usage mais pas les deux en même temps ! Une dernière solution positive, tu investis dans un routeur avec fonction double WAN (Synology fait cela très bien) et tu prends un second FAI différent de l'actuel Orange et là tu auras deux connexion indépendantes et dédiées chacune à chacun de tes souhaits. OK, cela a un coût non négligeable, mais à toi de voir si le jeu de tes désidératas en vaut la chandelle, c'est toi qui vois ... Cordialement oracle7😉