Herbs Posté(e) le 2 novembre 2018 Partager Posté(e) le 2 novembre 2018 Bonsoir messieurs, Je viens de passer "un peu" de temps à lire ce topic, et à mettre en place les solutions proposées par InfoYann et PPJP. Tout semble OK chez moi, alors un grand merci à tous les contributeurs et en particulier aux 2 cités plus haut 😉 !!!! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 2 novembre 2018 Auteur Partager Posté(e) le 2 novembre 2018 De rien 😉 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
TabasKo Posté(e) le 4 novembre 2018 Partager Posté(e) le 4 novembre 2018 (Salut les gars) Purée ! moi qui voulais mettre en place en quelques heures mon certificat SSL ... je suis à deux doigts de lâcher l'affaire ! Comme j'ai un tas de NDD chez OVH, j'ai décidé d'en prendre 1 et de configurer un sous domaine (du genre nas.1ndd.com). Jusque là, ok. Par contre pour se procurer un certificat, c'est tout de suite plus opaque pour moi. J'ai l'impression que l'autorité qui délivre le certificat doit (et c'est normal) s'assurer que je suis le propriétaire du domaine/sous-domaine indiqué. Dès lors, je vois pas comment rendre possible cette opération sans avoir un serveur http ouvert sur le port 80 du NAS (chose que je ne souhaite pas faire). C'est d'ailleurs explicitement demandé sur le NAS : J'imagine qu'ouvrir le port 80 sur ma box en port-fowarding sur le NAS ne servirai à rien (puisqu'il n'y a à ma connaissance aucun service sur le port du nas) Et si j'ouvre le port 80 sur la box, le message d'erreur devient Un gros truc m'échappe ? ps: je voudrai pas polluer vos échanges si c'est préférable que j'ouvre un nouveau thread dites le moi. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
TabasKo Posté(e) le 6 novembre 2018 Partager Posté(e) le 6 novembre 2018 Le 03/10/2018 à 12:41, PiwiLAbruti a dit : Il vaut mieux limiter la surface d'exposition en utilisant uniquement les adresses nécessaires plutôt qu'un pays entier : outbound1.letsencrypt.org 66.133.109.36 outbound2.letsencrypt.org 64.78.149.164 Le port 80 suffit n'est ce pas ? le 443 n'est pas utile. C'est bien en TCP seulement qu'on l'autorise ? https://snag.gy/vpW5lu.jpg 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 6 novembre 2018 Auteur Partager Posté(e) le 6 novembre 2018 Oui, TCP et port 80 uniquement pour ces deux IP. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 18 décembre 2018 Auteur Partager Posté(e) le 18 décembre 2018 (modifié) @PPJP, Hello PPJP, Je te tiens au courant puisque ça fait pas mal de temps que l'eau à coulé sous les ponts. Le script fonctionne parfaitement pour la génération du script comme la dernière fois. Le seul soucis qui persiste, c'est le redémarrage de certains paquets qui ne se fait pas. Ils sont arrêtés dans le centre de paquets donc je suppose que le script arrive à leurs donner l'ordre de se relancer mais eux ne doivent pas y arriver. J'ai fait un petit coup de : synoservicecfg --list Certains paquets n'apparaissent pas comme Office qui est concerné par les paquets qui ne redémarrent pas. Ces prochains jours, je vais essayer de voir les logs sur le serveur pour chercher le pourquoi ça pêche dans le redémarrage de certains services. Merci à toi en tout cas pour toute l'aide apportée avec ton script 😉 EDIT : J'ai été lire le log "synoservice.log" et voilà le résultat : Modifié le 18 décembre 2018 par Zeus 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 30 décembre 2018 Partager Posté(e) le 30 décembre 2018 Bonjour à tous, Beaucoup d'infos dans ce sujet, j'ai essayé de trouver une réponse quant à un renouvellement automatique, je n'ai rien vu de clair. Mon certificat SSL for free va-t-il se renouveler automatiquement (à la manière d'un certificat créé via DSM) à l'expiration des trois mois ou dois-je refaire la manipulation initiale ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Thierry94 Posté(e) le 30 décembre 2018 Partager Posté(e) le 30 décembre 2018 Bonjour, Le certificat se renouvellera automatiquement au bout des 3 mois. Pour cela il suffit que le port 80 en TCP soit ouvert sur votre NAS, et votre routeur pendant la période de renouvellement. Pour plus de sécurité il est possible de limiter l'ouverture du port 80 aux 2 adresses IP utilisées par Let's Encrypt. Mais si vous ne voulez pas attendre le renouvellement automatique vous pouvez le déclencher manuellement directement sur DSM (ouvrir préalablement le port 80 !) 1 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 30 décembre 2018 Auteur Partager Posté(e) le 30 décembre 2018 (modifié) Il y a 8 heures, shadowking a dit : Bonjour à tous, Beaucoup d'infos dans ce sujet, j'ai essayé de trouver une réponse quant à un renouvellement automatique, je n'ai rien vu de clair. Mon certificat SSL for free va-t-il se renouveler automatiquement (à la manière d'un certificat créé via DSM) à l'expiration des trois mois ou dois-je refaire la manipulation initiale ? Ça dépend, tu as créé comment ton certificat SSL ?! Création via DSM directement - renouvellement automatique tous les trois mois en ouvrant le port 80 sur les USA ou mieux sur les deux IP de Let's Encrypt. Création via mon tutoriel, il faut que tu refasses ton certificat tous les trois mois et que tu l'importes en remplaçant l'ancien. Si tu t'es inscrit sur le site, tu seras prévenu par mail qu'il faut que tu renouvelles. Si création via acme en ayant suivi la discussion "très" longue, tu n'as rien à faire, ça renouvelle tout seul un certificat wildcard. Modifié le 30 décembre 2018 par Zeus 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 30 décembre 2018 Partager Posté(e) le 30 décembre 2018 Je parlais de la méthode du tutoriel oui, j'ai d'autres certificats non wildcard créés via DSM pour d'autres applications. J'ai bien reçu un mail mais je voulais être certain que c'était la marche à suivre. Du coup je testerai sûrement à l'avenir la troisième méthode, quand j'aurai pris le temps de tout lire. Merci ! 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 30 décembre 2018 Auteur Partager Posté(e) le 30 décembre 2018 Pas encore définitif la troisième méthode parce que je rencontre encore un petit soucis sur le redémarrage auto de certains paquets... Donc pour la partie tuto, c'est bien à toi de faire la demande de renouvellement depuis le site indiqué. Synology n'a pas encore intégré la possibilité de faire un certificat wildcard donc il n'y a pas le choix. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 10 février 2019 Auteur Partager Posté(e) le 10 février 2019 (modifié) Bon, j'ai essayé de me pencher un peu plus sur ces soucis de paquets qui ne redémarre pas et autant dire que pour le moment, le soucis ne me parle pas. Voici la liste exacte des paquets qui ne se relance pas à la demande : Moments Office phpMyAdmin Apache 2.2 Apache 2.4 J'ai donc tenté de lancer au départ Apache 2.2 via la commande : /usr/syno/sbin/synoservicecfg --restart pkgctl-Apache2.2 La commande est bien passée mais rien n'a été fait. C'est normal puisque après réflexion, j'ai demandé le redémarrage d'un paquet non lancé. Je suppose donc que le système hôte n'a pu trouver l'ID du processus en question. Je suis donc passé par la commande : /usr/syno/sbin/synoservicecfg --start pkgctl-Apache2.2 Et là, j'ai vu un changement. Dans le centre de paquets, le démarrage s'est bien initialisé et était passer au statut "Démarrage en cours" sauf qu'il n'a jamais réussi à démarrer et il est resté dans cet état. J'ai donc décidé de tenter le redémarrage du NAS pour voir si les services allaient se relancer via DSM. Je ne voulais pas les lancer manuellement depuis le centre de paquets car lors de mes précédents soucis du même ordre, je savais que ça fonctionnait. Après redémarrage via la commande reboot en SSH, je suis allé dans le centre de paquets et les paquets cités plus haut n'étaient toujours pas démarrés. Logique me direz-vous puisqu'ils étaient déjà arrêtés avant le reboot. DSM en a donc certainement conclu qu'il ne fallait pas les redémarrer puisqu'il prend en compte l'état on/off des paquets avant une extinction. J'ai donc lancé manuellement depuis le centre de paquets ces paquets et je suis aller voir au niveau des logs SSH et en particulier le fichier synoservice.log En voici le résultat suite au lancement manuel des dits paquets via le centre de paquets. https://framabin.org/p/?14d2eaf1f5e55544#KhZAWFZhA4YI+d+rPoaH6WJS4y9AGV1FbZuTjc5HjIU= J'ai quand même cherché aussi au moment ou j'avais lancé le script pour voir ce qu'il s'était passé au niveau du redémarrage des paquets et voilà le résultat : https://framabin.org/p/?98e0e9edee1d9262#Xq2sVwrDmBegoCJ0zkqvQxWlN1FyMKhEwMARfsMpyJg= Bref, je patauge et je ne comprend pas pourquoi ils ne peuvent pas se relancer lorsqu'on leur demande... Modifié le 13 février 2019 par Zeus 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Jojo (BE) Posté(e) le 10 février 2019 Partager Posté(e) le 10 février 2019 parce qu'ils sont têtus comme des bourriques 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 10 février 2019 Auteur Partager Posté(e) le 10 février 2019 Au jour d'aujourd'hui, je ne recommande pas encore de passer par la méthode à laquelle je passe n'ayant pas encore résolu ce soucis alors si vous voulez un certificat wildcard, passez par un tiers recommandé par Let's Encrypt comme SSLFORFREE. C'est d'ailleurs pour ça qu'en dehors du premier post parlant de SSLFORFREE, tout le reste n'est que brouillon et test. Sans compter qu'on est limité dans les tests de génération de certificat et que ces derniers se renouvelle tous les trois mois d'eux même. Donc assez chiant pour faire des tests sur de courtes périodes. En passant par un service tiers qui utilise l'API de Let's Encrypt comme le faire SSLFORFREE, ça se génère en deux minutes et on importe le nouveau certificat dans DSM sans soucis en quelques instants aussi. Et là, pas de soucis de redémarrage de paquets... 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Mic13710 Posté(e) le 10 février 2019 Partager Posté(e) le 10 février 2019 As-tu essayé le redémarrage proposé par Neilpang pour l'acme.sh ? https://github.com/Neilpang/acme.sh/wiki/Synology-NAS-Guide PACKAGECERTROOTDIR="/usr/local/etc/certificate" FULLCERTDIR="$CERTROOTDIR/$CERTDIR" # reload /usr/syno/sbin/synoservicectl --reload nginx # update and restart all installed packages PEMFILES=$(find $PACKAGECERTROOTDIR -name cert.pem) if [ ! -z "$PEMFILES" ]; then for DIR in $PEMFILES; do #active directory has it's own certificate so we do not update that package if [[ $DIR != *"/ActiveDirectoryServer/"* ]]; then rsync -avh "$FULLCERTDIR/" "$(dirname $DIR)/" /usr/syno/bin/synopkg restart $(echo $DIR | awk -F/ '{print $6}') fi done fi 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Einsteinium Posté(e) le 10 février 2019 Partager Posté(e) le 10 février 2019 Bientôt 1 an... qu’attend synology pour l’implementation ? 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 10 février 2019 Auteur Partager Posté(e) le 10 février 2019 @Mic13710 Oui j'ai essayé mais je pense avoir fait une erreur dans la modification du script car j'ai reçu un message d'erreur par mail sans précision de ce dernier. Et comme j'y connais pas grand chose en bash, je n'arrive pas à me décoincer du soucis. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PPJP Posté(e) le 11 février 2019 Partager Posté(e) le 11 février 2019 @Zeus Bonsoir, Désolé car j'ai loupé le message ou tu me citais. Je ne suis pas très régulier sur ce forum et ai la mauvaise habitude de ne pas m'identifier car je n'ai pas à y écrire. Concernant le script, les redémarrages demandés de paquets semblent se faire correctement. Le redémarrage des paquets arrêtés ne doivent pas avoir été demandés. Il est difficile de savoir quels sont les paquets arrêtés lors de la mise à jour du certificat. Chez moi tous les paquets sont OK dont phpMyAdmin. Pour test, je viens d'installer Apache 2.2, Apache 2.4 et Moments. Résultat: Les 2 Apaches OK,(sans demande de redémarrage par le script) et Moments arrêté. Donc pas cohérent avec ce qui est constaté chez toi. Je crains que l'on soit devant un problème de dépendance. @Mic13710 Le redémarrage proposé par Neilpang ne relancera les mêmes paquets que le script actuel. @Zeus A toute fin utile je joins une nouvelle version du script qui ne fait pas appel au CRON. C'est une modif que j'avais faite après constat d'un risque de rater un renouvellement. Le Nas était en arrêt pour dépoussiérage périodique (heureusement il était également lancé au boot). Si l'on rate un créneau le suivant arrive après péremption du certificat. Il est lancé journellement par une tache planifiée par: Pour un renouvellement à 85 jours bash /pathduscript/majcertificat.sh > /pathduscript/majcertificat.log 2>&1 Pour un renouvellement à X jours (X de 0 à 90) bash /pathduscript/majcertificat.sh X > /pathduscript/majcertificat.log 2>&1 Si utilisation de pas oublier de supprimer a ligne de crontab correpondant à l'ancienne vesion Le script oublié!!! majcertificat.sh 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 11 février 2019 Auteur Partager Posté(e) le 11 février 2019 (modifié) Merci pour ton retour, je vais jeter un œil à ton script. Citation Il est difficile de savoir quels sont les paquets arrêtés lors de la mise à jour du certificat. Pas forcément, suffit d'aller voir dans les logs ssh et on voit normalement ce qui a été fait par le système. Non ? Citation Il est difficile de savoir quels sont les paquets arrêtés lors de la mise à jour du certificat. Chez moi tous les paquets sont OK dont phpMyAdmin. Pour test, je viens d'installer Apache 2.2, Apache 2.4 et Moments. Résultat: Les 2 Apaches OK,(sans demande de redémarrage par le script) et Moments arrêté. Donc pas cohérent avec ce qui est constaté chez toi. Je crains que l'on soit devant un problème de dépendance. Merci pour les tests effectués de ton côté. C'est vrai que c'est assez chiant ce phénomène. Surtout pour Apache qui me bloque la connexion sur mon virtual host par exemple. Et bien entendu phpMyAdmin qui me bloque aussi au niveau des sites. Il faut vraiment que je réfléchisse à comment je peux arranger ce foutu soucis de redémarrage sur certains paquets. Je pense que ce que je vais faire, c'est tout reprendre à 0. Passer par SSLFORFREE pour obtenir un certificat et l'injecter dans DSM. Surveiller les logs afin de voir les actions du système surtout sur la partie redémarrage de paquets Refaire un certificat via acme sur mon NAS en essayant de régler le soucis. EDIT : Après un test rapide en réimportant l'ancien certificat d'origine Synology, supprimant le certificat Wildcard et le mettant par défaut sur tous mes services, voici le résultat dans les logs : On peut voir qu'il ne redémarre aucun paquet à proprement parler en ce qu'il concerne les paquets qui posent soucis. Je me demande si il ne faudrait pas dire au script de simplement redémarrer nginx et avahi et pourquoi pas nmbd. Après tout, c'est pas ces trois services qui gèrent tous les protocoles réseau sur le serveur ? https://framabin.org/p/?2f5a4923d0dbc8cf#phSR6VJQlI5j5y1Jz2/3z/EipEo1rAxqIO+9FE1eB4s= Modifié le 13 février 2019 par Zeus 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PPJP Posté(e) le 12 février 2019 Partager Posté(e) le 12 février 2019 (modifié) Je viens de regarder le fichier synoservice.log et je n'ai pas tout compris. On voit que Moments est arrêté (2 fois), et n'est jamais redémarré. Le script ne demande ni l’arrêt ni le redémarrage de ce paquet! J'ai rajouter en fin de script une commande de restart de Moments. Cela fonctionne.C'est sale mais c'est une piste de recherche. Donc pour moi Déjà installé phpMyAdmin: a toujours été OK Installé pour test Apache 2.2 a toujours été OK Apache 2.4 a toujours été OK Moments redémarre avec l'ajout de commande en fin de script Pour info la partie de synoservice.log correspondante https://framabin.org/p/?bebd694c53abf131#L+ZTx9qp//6sm6cB7h1fV+Ybf9ZLpinV7jBcrsTLzho= PS: je viens de découvrir la modif de ton post Je vais regarder, dans les prochaines soirées, ce que l'on peut obtenir de cette nouvelle piste qui semble intéressante. Modifié le 14 février 2019 par PPJP 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 12 février 2019 Auteur Partager Posté(e) le 12 février 2019 J'essaie d'apprendre pour scripté en bash mais pas facile parce que les 3/4 des sites proposent des scripts et n'expliquent pas les bases pour un débutant. Sinon, j'ai modifier le script pour tenter le redémarrage uniquement de nginx, avahi et nmbd. Tiens moi au courant de ton test, je pense que ça pourrait suffire mais je n'en suis pas sûr. Tu pourrais stp me donner un exemple dans ton script pour ajouter par exemple la commande pour Moments. #Redémarrage des packages echo -e "\nRedémarrage des packages" t0=$SECONDS echo "Redémarrage de nginx" /usr/syno/sbin/synoservicectl --reload nginx echo "Temps de redémarrage : $(($SECONDS - $t0))s" IFS=$'\n' for package in $(sort -u <<<"${paquets[*]}");do echo "Redémarrage de $package" t0=$SECONDS /usr/syno/bin/synopkg restart $package echo "Temps de redémarrage : $(($SECONDS - $t0))s" done unset IFS echo "Redémarrage de nginx" /usr/syno/sbin/synoservicectl --reload nginx echo "Temps de redémarrage : $(($SECONDS - $t0))s" 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PPJP Posté(e) le 12 février 2019 Partager Posté(e) le 12 février 2019 Bonsoir, Je suis comme toi, je ne programme pas en Bash, que je le trouve imbuvable! Ci-jointe une nouvelle version qui doit relancer Moments (elle fonctionne chez moi). Tiens moi au courant du résultat. (paquets non relancés) Je te joindrai dans qq temps une version pour relancer les Apache, mais je ne pourrai pas la tester car je n'ai jamais eu d’arrêts de ces paquets majcertificat.sh 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Einsteinium Posté(e) le 12 février 2019 Partager Posté(e) le 12 février 2019 Les gas c’est invivable vos log ici... je vous recommande l’utilisation de https://pastebin.com/ 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
unPixel Posté(e) le 13 février 2019 Auteur Partager Posté(e) le 13 février 2019 Ok pour Pastebin 😉 @PPJP Je viens d'essayer ton script et malheureusement le renouvellement se fait pas car il détecte qu'il est trop récent: Demarrage du script (v02.00): Wed Feb 13 15:13:05 CET 2019 Age du certificat : 1 jour(s) 1550067185 1549927802 Ecart : 139383s Renouvellement du certificat non nécessaire 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
PPJP Posté(e) le 13 février 2019 Partager Posté(e) le 13 février 2019 Bonsoir, Je fais court pour ne pas m'attirer les foudres d'un modo (grand adepte des fessées!) Le 11/02/2019 à 02:46, PPJP a dit : Pour un renouvellement à 85 jours bash /pathduscript/majcertificat.sh > /pathduscript/majcertificat.log 2>&1 Pour un renouvellement à X jours (X de 0 à 90) bash /pathduscript/majcertificat.sh X > /pathduscript/majcertificat.log 2>&1 Lance avec le paramètre à 0 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.