unPixel

Syncthing est géré par le reverse proxy car il s'installe comme un paquet normal et non un paquet dans le dossier web comme Wordpress par exemple. Finalement, c'était un bug de Syncthing et après une réinstallation, il a bien été prit en compte dans son adresse reverse proxy. Sinon, pour une url type https://domaine.tld/xxx, il faut passer par le virtual host de wbestation mais tu le sais déjà.

Google a son système qui est différent des standards... Pourquoi ne pas créer un compte exclusivement pour calendar pour ces personnes ?!

Tu étais root quand tu as fait ces commandes ssh ?

De rien et bonne utilisation ;) Tu as une section routeur sur le forum au cas ou tu aurais besoin d'aide :)

https://ndd.tld/photo fonctionne bien lui Mais par exemple, je viens d'installer Syncthing et lui n'est pas prit en compte dans le certificat avec l'adresse https://ndd.tld:portdesyncthing

Voilà ce que j'ai dans le mien donc si j'ai bien le wildcard : root@NDD:~/.acme.sh/ndd.fr# vi ndd.fr.conf Le_Domain='ndd.fr' Le_Alt='*.ndd.fr' Le_Webroot='dns_ovh' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='4096' Par contre, je viens de me rendre compte d'un petit truc. Mes liens en https://ndd.fr/quelquechose ne sont pas prit en compte par le certificat...

Le soucis c'est que si je lui indique pas le bon dossier, ne va-t-il pas aller au mauvais endroit pour chercher l'information car dans le dossier .acme.sh, je n'ai pas que ndd.fr J'ai aussi *.ndd.fr qui lui est vide (mais créé quand même par acme.sh), dossier ca, fichier account.conf et fichier http.header

Bah elle est modulable en désactivant le 2,4 GHz ou le 5 GHz selon tes choix. Après dans les routeurs récents, ça m'étonnerait que tu en trouves qui ne propose pas du wifi AC qui est la norme en ce moment. Un peu comme si tu voulais te limiter à la 2G alors qu'on est à la 4G...

Moi je sais pas, je me suis jamais préoccupé des boutons sur le routeur

http://www.fredzone.org/plainte-ftc-d-link-332#utm_source=feed&utm_medium=feed&utm_campaign=feed Tu as ta réponse avec preuve en plus

Avant de chercher à mettre des restart dnas le script, je vais attendre de voir dans trois mois si vraiment la renouvellement se fait automatiquement et si au cas ou tous les paquets se relancent. Ensuite, on avisera :)

Je viens de tester la tâche et voici le résultat : Cher utilisateur, Le planificateur de tâches à terminé une tâche planifiée. Tâche : MAJ Certificat SSL Heure de début : Thu, 05 Apr 2018 20:22:31 GMT Heure d’arrêt : Thu, 05 Apr 2018 20:28:55 GMT État actuel : 0 Sortie standard/erreur : sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 nginx reloaded. sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package MailPlus-Server restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package MailPlus-Server restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package WebDAVServer restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package CloudStation restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package WebStation restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package WebStation restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package LogCenter restart successfully sending incremental file list ./ .fullchain.pem.swp cert.pem chain.pem fullchain.pem privkey.pem sent 28.27K bytes received 110 bytes 56.75K bytes/sec total size is 27.92K speedup is 0.98 package CardDAVServer restart successfully Sincères salutations, Synology DiskStation Soucis rencontré, j'ai un 502 sur MailPlus. Après vérification, il était arrêté dans le centre de paquets... Je l'ai donc relancé manuellement. Après d'autres vérifications, il s'avère que phpMyAdmin, Apache 2.2 et apache 2.4 étaient aussi arrêté dans le centre de paquets...

C'est simple, mon acme est dans le dossier root et là ou il envoie le certificat c'est root/.acme.sh/ndd.tld Donc ma commande devrait être : 0 10 2 * * root root/.acme.sh/****.fr --cron --home root/.acme.sh/

Bon alors je vais tenter avec ma ligne de code. Je teste le script en lançant la tâche pour voir si ça fonctionne ?

Euhhh non. Je te confirme bien que j'ai pas acme.sh à l'endroit que tu indiques :

@Mic13710 : Ok merci pour les précisions. Voici alors ce qui serait possible si je comprend bien. Tu valides les manips stp ? 1. On tape vim /etc/crontab 2. On ajoute la ligne 0 10 2 * * root root/.acme.sh/ndd.tld --cron --home root/.acme.sh/ 3. On enregistre et on quitte avec la commande : :wq 4. Dans le planificateur de tâches, on ajoute une tâche en tant que root qui se lancera tous les 2 de chaque mois avec comme code : En changeant bien entendu le nom du dossier comme précisé dans le code. # Note: The $CERT_FOLDER must be hardcoded here since the running environment is unknown. Don't blindly copy&paste # change this sample directory name "AsDFgH" to the name of your Let's Encrypt cert directory CERTDIR="AsDFgH" # do not change anything beyond this line! CERTROOTDIR="/usr/syno/etc/certificate" PACKAGECERTROOTDIR="/usr/local/etc/certificate" FULLCERTDIR="$CERTROOTDIR/_archive/$CERTDIR" # find all subdirectories containing cert.pem files PEMFILES=$(find $CERTROOTDIR -name cert.pem) if [ ! -z "$PEMFILES" ]; then for DIR in $PEMFILES; do # replace all certificates, but not the ones in the _archive folder if [[ $DIR != *"/_archive/"* ]]; then rsync -avh "$FULLCERTDIR/" "$(dirname $DIR)/" fi done fi # 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 rsync -avh "$FULLCERTDIR/" "$(dirname $DIR)/" /usr/syno/bin/synopkg restart $(echo $DIR | awk -F/ '{print $6}') done fi En faite, j'ai surtout un doute sur la ligne "0 10 2 * * root /usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/" car chez moi elle ne correspond pas. Quand acme.sh me créer un certificat SSL, il le met dans "root/.acme.sh/****.fr". Donc je suppose que ma ligne devrait être : 0 10 2 * * root root/.acme.sh/****.fr --cron --home root/.acme.sh/ Je me trompe ?

Attention par contre, en DLNA, il n'y a pas de droits et donc tous les dossiers perso sont visibles de tous sur le réseau. Donc si tu utilises des dossiers persos dans le dossier "photo", je te recommande d'interdire le NAS en DLNA au sein de ton réseau :)

Par exemple pour la famille j'ai ce genre d'arborescence. photo > Famille > x photo > Famille > x perso photo > Famille > y photo > Famille > y perso photo > Famille > z photo > Famille > z perso Et personne ne voit les dossiers perso à par le propriétaire. Les droits sont gérés depuis Photo Station normalement. Envoyé de mon iPhone en utilisant Tapatalk

Bizarre car je viens de vérifier et moi je n'ai pas accès via File Station aux sous dossiers persos de mes utilisateurs qui sont dans un dossier rassemblant tous les dossiers persos justement.

La nuit porte conseille... Alors voilà l'idée qu'il m'est venue. Maintenant que je sais que ma ligne de code renouvelle le certificat sans rien toucher du côté OVH, me suffirait-il pas de créer un script auto de MAJ de ce dernier via le planificateur de tâches ?! En gros je pense à un truc dans ce genre : ./acme.sh --issue -d ******.fr -d *.*****.fr --dns dns_ovh --keylength 4096 --force Copie automatique des trois fichiers en remplaçant les précédents redémarrage service http Est-ce que ça pourrait fonctionner ?! Si oui, dans ce cas, on a trouvé la possibilité d'automatiser tout ça et de ne plus s'en préoccuper...

Si tu as trouvé la solution alors tant mieux ;)

Bon et bien là, je sèche. J'ai cette impression d'oublier quelque chose mais je ne vois pas quoi...

Ok alors éventuellement, tu vas en tant qu'admin dans le dossier HomeS puis tu fais un clic droit sur le dossier Home de l'utilisateur en question puis "Propriétés". Tu regardes que c'est bien le bon propriétaire qui est inscrit sinon tu le changes en n'oubliant pas de cocher "Appliquer à ce dossier, ces sous dossiers et ces fichiers" avant de faire OK. Cet utilisateur devrait retrouver son dossier home.

Voilà ma config mais par contre, tu ne mets pas écriture/lecture aux utilisateurs sur le dossier homeS sinon ils verront les dossiers et données des autres utilisateurs !

Après, si tu ne veux pas qu'ils voient le dossier HomeS, tu peux aller dans les paramètres du dossier partagé et cliquer sur "Cacher ce dossier partagé dans mes emplacements réseaux". Par contre, ça ne le cachera pas au niveau de File Station mais ils ne devraient pas le voir normalement.