Mic13710

Bonjour sv59510, soyez le bienvenu dans la communauté.

Et puis on perd la possibilité de passer en btrfs, ce qui du même coup limite les possibilités du 220+

oui, mais il faudra confirmer tous les mois.

Alors il faudra expliquer à ceux qui ne l'utilisent pas, et j'en suis, pourquoi ça fonctionne très bien sans. Pour moi, sans vouloir dénigrer le travail qui a été fait et que je respecte, ce script n'a (plus) aucun intérêt. Edit : Mais si tu es réellement convaincu qu'il y a un problème, plutôt que de pallier des dysfonctionnements à coup de script, il me semble plus productif d'alerter les contributeurs de github pour qu'ils apportent une solution qui profite à tous. C'est ici que ça se passe pour synology_dsm.sh : https://github.com/acmesh-official/acme.sh/issues/2727

IP fixe chez Bouygues ? Pourquoi pas. Si c'est le cas, vous n'avez pas besoin de DDNS.

Comme dirait fort justement Fenrir, un sous-domaine n'existe pas. mondomaine.tld est un domaine, tout comme toto.mondomaine.tld est un autre domaine, certes rattaché au premier, mais c'est un domaine. Et donc oui, vous pouvez très bien utiliser toto.mondomaine.tld pour atteindre votre NAS et obtenir le certificat correspondant à partir du moment ou vous en êtes le propriétaire. Avant cela, il faudrait savoir si votre ip publique est fixe ou dynamique. Si elle est dynamique, il faudra effectivement activer un service DDNS et dans ce cas, il faut vérifier si O2switch offre ce service. Sinon, comme l'a dit @PiwiLAbruti, il faudra passer par un service externe.

cloudfare est pris en exemple par l'auteur. Ce n'est pas à suivre aveuglément. Puisque vous avez suivi ce tuto, vous avez déjà toutes les clés OVH pour passer directement à l'installation. Pour lancer la configuration DNS, il faut simplement utiliser les mêmes clés et les exporter : export OVH_AK='Application Key' export OVH_AS='Application Secret' export OVH_CK='Consumer Key' @oracle7 Tu as tout à fait raison. Ce n'est pas DSM mais bien acme.sh qui lance le déploiement en appelant un autre script : /usr/local/share/acme.sh/deploy/synology_dsm.sh. Ce dernier a été mis à jour plusieurs fois en 2020, la dernière date du 10 décembre, ce qui explique probablement que le déploiement s'effectue maintenant normalement et sans l'aide d'un script supplémentaire.

Avec plus de 51000 heures, ça fait presque 6 ans de fonctionnement 24/7.

Généralement, un test smart bloqué à 90% = disque HS.

Bonjour Arno22, soyez le bienvenu dans la communauté

Justement, le tuto sur github dont j'ai parlé plus haut que j'utilise sur tous les NAS non compatibles Docker. Et si vous le comparez au tuto d' @Einsteinium, vous verrez qu'il est très similaire. Il y fait d'ailleurs référence à la fin de son tuto. Que ce soit avec Docker ou pas, la méthode est la même : on passe par le deploy_hook. La seule différence c'est qu'avec Docker, le certificat est créé dans une instance Docker alors que sans, il est créé dans DSM. Les deux utilisent le même script acme.sh. Docker n'est absolument pas une nécessité puisqu'on fait au final la même chose que ce soit avec ou sans. C'est juste une autre manière d'obtenir le certificat qui est fondamentalement la même dans les deux cas avec des commandes quasi identiques. Le déploiement est ensuite strictement le même puisqu'il s'agit de déployer le certificat dans les dossiers appropriés en utilisant le deploy_hook de DSM. Je ne l'avez pas relevé. acme.sh ne fait pas de déploiement. Il se contente d'obtenir le certificat. C'est le deploy_hook de DSM qui fait ensuite le déploiement.

Toujours ce problème de certificat sur le VPN. Pour ne pas y être confronté, il faut utiliser pour le seul serveur VPN un certificat spécifique d'une durée de validité éloignée. Soit on lui affecte le certificat par défaut de DSM synology.com, soit un certificat auto-signé. Ainsi le certificat n'est pas affecté par les renouvellements Let's Encrypt, et surtout on ne perd pas la connexion à distance qui peut devenir un vrai cauchemar à rétablir.

Absolument pas. Je n'ai rien eu à faire pour rétablir les affectations. Et je n'ai pas qu'un seul domaine, ce qui pourrait simplifier les choses. Comme je l'ai écrit, je n'ai fait que le déploiement et basta. tous les ".pem" sont en place, les infos renvoyées par Firefox sur les certificats sont conformes aux dernières mises à jour, les affectations n'ont pas bougé. Alors, je veux bien creuser un peu plus mais en l'état je ne vois rien qui cloche. Je ne dis pas que ton script ne sert à rien, je dis qu'il ne sert plus à grand chose, ou pour être plus précis, qu'il ne m'est d'aucune utilité. As-tu au moins essayé de ne faire que le déploiement ? Parce que faire tourner un script qui est sensé corriger des erreurs qui n'existent plus ne prouve pas qu'il sert à quelque chose. Juste qu'il s'évertue à recopier des fichiers qui n'ont pas besoin de l'être. Je ne vois pas l'intérêt d'un déclenchement avant les 60 jours, mais s'il faut le faire, un simple --force dans le script permet de renouveler le certificat. Aisément contournable en créant un user admin spécifique uniquement pour ça que tu appelles par exemple ACME avec des droits très limités et sans double authentification.

@Diabolomagic, oui, le 216 comporte 2 licences comme pratiquement tous les NAS Synology. Seuls les premiers modèles (serie 01 à 08, et peut-être 09) n'avaient qu'une seule licence. Les NVR en ont 4.

@oracle7 Salut, Je viens vers toi à propos de ce tuto car je me demande quelle en est encore la pertinence. Je viens d'avoir 3 renouvellements automatiques avec deploy_hook sur 3 NAS, 2 avec la méthode Neilpang sur github dont la tienne est dérivée, et l'autre via Docker à partir de la toute première version du tuto d' @Einsteinium qui est en fait une réplique du même tuto de github. J'ai aussi eu fin décembre un renouvellement auto via Docker sur un autre NAS et son prochain renouvellement est prévu pour le 27. Tous se sont déroulés sans utilisation d'un script supplémentaire (celui de ton tuto) pour pallier un supposé dysfonctionnement et tous les certificats ont été correctement reportés dans les différentes applications concernées que ce soit dans /usr/syno/etc/certificate » ou « /usr/local/etc/certificate Aussi, je me pose la question de l'utilité de ton script avec les dernières versions de DSM. Je me trompe peut-être, mais à mon avis le deploy_hook a été corrigé, ce qui de facto ne nécessiterait plus de rajouter ton script. J'ai plusieurs renouvellements planifiés dans les prochains jours. Je te ferai un retour, mais je suis persuadé qu'ils se dérouleront sans encombre.

@CyberFr Attention tout n'est pas sauvegardé par Hyperbackup et il faudra malgré tout mettre les mains dans le cambouis pour rétablir toutes les fonctions. Par exemple, les certificats ne sont pas sauvegardés, le reverse proxy non plus, et si je ne fais pas erreur, les tâches planifiées non plus, tout comme un certain nombre de paquets comme par exemple Docker et ses containers sur certains modèles de NAS. Disons que l'essentiel est préservé et permet de repartir sur de bonnes bases sans avoir à tout reconstruire.

Pour pouvoir restaurer un NAS, il faut d'abord installer DSM puis les paquets, y compris Hyperbackup et Hyperbackup Vault bien sûr, et on les lance. Dans Hyperbackup, on se reconnecte à des tâches existantes pointant vers les sauvegardes. Il suffit de lancer les restaurations et c'est reparti.

Et encore moins en présentation. J'ai rarement vu plus court. Sans en faire un roman, on aurait aimé en savoir un peu plus sur vous, votre environnement informatique, votre modèle de NAS, etc... Sinon, ça n'a pas de sens. Bienvenue dans la communauté.

Vous avez donné la réponse. Si vos identifiants ont changé, il faut bien évidemment les mettre à jour dans toutes les connexions au NAS, Drive y compris.

Bof, à quoi bon créer plusieurs fois des ouvertures de ports, c'est le routeur derrière qui filtre. Une DMZ sur une IP dédiée à un routeur ne pose pas de problème en terme de sécurité. Ca revient à faire du bridge, tout simplement.

Ah l'interface chaise/clavier, c'est bien souvent là que se situe la source du problème, et plus l'interface prend de l'âge, plus les problèmes s'accentuent 😉

D'autant qu'il est impossible de faire fonctionner les deux sur un même NAS car ils utilisent les mêmes ressources. C'est soit l'un, soit l'autre.

Pas compris. Pour que les dossiers partagés puissent être intégrés dans CS, il faut d'abord les inclure dans le périmètre CS. Avec un compte admin, vous allez dans la console d'administration de Cloud Station serveur, Dossiers de l'équipe et vous activez les dossiers partagés à inclure. Ensuite, sur chaque client pour lequel le compte utilisateur est déjà dans Cloud Station, vous créez une nouvelle connexion qui pointe vers le dossier partagé. Vous le faite pour chaque dossier auquel l'utilisateur a accès.

Peut-être. Je n'utilise pas le VPN à partir d'un smartphone. Seulement à partir de mon PC sous Win10. OpenVPN est très bien et je l'utilise beaucoup pour la maintenance à distance du parc de NAS dont je m'occupe, mais on doit systématiquement renseigner les identifiants de connexion alors qu'on peut les enregistrer dans les paramètres pour une connexion en L2TP ce qui au final ne demande qu'un clic se souris pour se connecter. Perso, je n'ai que mon PC portable que j'utilise avec L2TP lorsque j'ai besoin d'intervenir sur DSM à distance. J'utilise aussi L2TP pour les connexions et sauvegardes inter NAS car là aussi, il n'est point besoin de passer par un fichier de configuration, la liaison se faisant en direct. Mis à part l'accès à DSM ou la synchro entre 2 NAS, je n'utilise pas le VPN, les accès classiques aux comptes utilisateurs étant suffisamment sécurisés pour pouvoir prendre un risque raisonnable.

Non. sur chacune des règles, il ne faut autoriser que la France. Mais attention, si vous avez un certificat LE à renouveler, il faut aussi autoriser les US sur le 80 et/ou le 443 au moins le temps du renouvellement.