CoolRaoul

Serait peut-être plus clean de ne pas modifiers les fichiers gérés par DSM et d'ajouter un ou plusieurs fichiers .conf perso dans "/usr/local/etc/nginx/conf.d" (avec en prime plus un espoir qu'ils soient conservés lors des upgrades) Par exemple je verrai bien un "domoticz.conf" dans le style de celui que j'avais temporairement mis en place sur ma conf nginx sous dsm: Brut de fonderie, à affiner (directives "listen" à supprimer "location /" serait sans doute du genre "location ~ ^/domoticz", et auth à adapter): #+ # domoticz #- server { listen *:6080; listen *:6443 ssl; server_name ~^dz\..*$; add_header X-Frame-Options SAMEORIGIN; include ssl_defaults.conf; location / { proxy_pass http://localhost:8084/; include proxy_defaults.conf; auth_basic "Authentification"; auth_basic_user_file /site/etc/nginx/htpasswd; } } # Local Variables: # mode: nginx # End:

Je faisais référence à ceci: qui amène en pratique *directement* à l'étape 3 de EZ Internet et que je déconseille d'utiliser.

Ah là par contre désolé, non seulement je n'utilise pas Mail Station mais en outre ça touche des protocoles (DKIM, DMARC) que je n'ai jamais eu l'occasion de manipuler. Faut être un peu patient pour les réponses sur des sujets pointus comme celui-la. Toutefois j'ai comme l'impression que les deux problèmes que tu cites (DKIM/DMARC et reverse DNS) sont liés: il me semble comprendre (ref) que la cohérence du reverse DNS de l'IP source avec le nom de domaine email inclus dans la signature (champ "d") soit nécessaire pour que ça fonctionne. Dans ton cas, un reverse lookup de ton IP va répondre avec IP.rev.sfr.net ce qui ne "matche" pas. Et comme l'IP, même fixe, appartient à SFR, ca ne serait possible que si SFR te permettait de personnaliser ton reverse (comme chez Free par exemple) Mais je le répète je ne suis pas spécialiste de cette partie.

L'objet de mon post était essentiellement de corriger les inexactitudes du *tuto* (et c'est d'ailleurs surtout son contenu que j'ai cité), en particulier l'indication du choix de l'option "SFTP" dans le profil WinSCP au cas ou d'autres auraient voulu l'appliquer tel quel. Au passage j'en ai profité pour en souligner ce qui était inutile et faire quelques suggestions d'amélioration de "confort" (Pageant). Ca peut toujours faire gagner du temps à certains. J'entend bien que ça ne t'es sans doute pas utile personnellement mais ça peut servir à d'autres, et donc pourquoi s'en priver? (on est dans un forum public après tout) Au passage j'en ai profité pour donner ce que je pense être l'explication de l'anomalie signalée: "putty subit un refus de clé, mais winSCP fonctionne!". L'ayant qualifié d'"étonnant", ca donnait l'impression que que ça attendait une réponse. Au temps pour moi.

Pas besoin de "client" ftp, c'est intégré à filestation: Outils -> "connexion à distance" -> "configuration de la connexion" -> FTP Ensuite suffit de faire des copier/coller ou des drags & drop.

Je ne vois pas comment cela peut marcher: il n'est pas possible de se connecter "root" à DSM (et ça ne date pas de DSM6) en utilisant SFTP (SSH ou SCP ok par contre si on a bien enregistré la clé publique dans ~root/.ssh/authorized_keys) L'utilisation de cette option "allow the connection agent" présuppose qu'on utilise l'agent (pageant téléchargé avec putty) alors que le tuto n'en parle pas. De plus dans ce cas, il est inutile de spécifier de "private key file" dans Auth parameters. Inutile de préfixer ce "vi" (ainsi que les suivants) de "sudo" étant donné qu'on est *déjà* root (de part le "sudo -l -U root" précédent) C'est normal que ca ne fonctionne pas en SFTP : DSM ne supporte pas les connexions root dans ce mode. Si Putty échoue avec un refus de clé c'est que le chemin du fichier de clé privé spécifié dans sa propre configuration de session (Connexion -> SSH -> AUTH -> "authentication parameters") est erroné ou manquant. Mais je te conseille d'utiliser Pageant. Lancé au démarrage de ta session windows, on y charge la clé privée et ensuite plus besoin de retaper sa passphrase jusqu'au prochain login (s'assurer pour cela que dans putty Connexion -> SSH -> AUTH -> "authentication methods", "attempt authentication using pageant" est coché))

Les étapes 8 à 10 ci dessus sont inutiles: traditionnellement, les options en commentaire dans le sshd_config pré-installé n'ont d'autre rôle que de documenter les options par défaut. Les dé-commenter ne change donc rien

Si l’adresse ci dessus est bien un copier/coller et pas une IP au hasard donnée à titre d'exemple, c'est que contrairement à ce que tu penses, l’accès internet entrant à ton NAS est bien ouvert. 59.45.79.21 est une IP chinoise: https://www.abuseipdb.com/check/59.45.79.21 et tu n'es pas le premier auquel quelqu'un derrière cette adresse tente de s'attaquer: https://www.abuseipdb.com/report-history/59.45.79.21 Vérifie ici si le port 22 est ou pas fermé chez toi. Te restes à suivre les conseils de @Fenrir

Le reverse proxy Nginx est entièrement indépendant du type de serveur choisit dans DSM vu qu'il s'agit d'un front-end: il utilise notament son propre process et ses propres ports TCP.

Un autre utilisateur a le même problème. Voici le fil sur le forum US: https://forum.synology.com/enu/viewtopic.php?t=115878 Forcer php56 semble dans tous les cas un élément de la solution. Mais ce sont *toutes* les commandes qu'il va falloir préfixer par "php56" Par exemple php56 ./my_project/bin/console server:run bon chez moi ça bute alors sur: [ERROR] A process is already listening on http://127.0.0.1:8000. mais je pense qu'il doit être possible de choisir un autre port que le 8000 (connais pas Symfony)

Quickconnect n'utilise que des connexions TCP *sortantes*, et c'est justement le but de cette méthode, pas besoin de rediriger de ports dans le routeur, que ce soit en dur ou par UPNP. Par contre certaines Livebox (toutes?) implémentent un firewall dont un des mode est assez strict vu qu'il filtre également les flux *sortants*: http://assistance.orange.fr/livebox-modem/toutes-les-livebox-et-modems/installer-et-utiliser/piloter-et-parametrer-votre-materiel/le-parametrage-du-firewall-de-votre-livebox/livebox-2-parametrer-le-firewall_21365-21836 Je conseille d'aller vérifier si ce dernier ne serait pas en niveau de sécurité "élevé".

Ok, typique d'un script édité avec un éditeur Windows mal configuré pour une utilisation Unix. Utilise Notepad ++ avec les options suivantes: Et pour réparer ton fichier actuel, toujours avec Notepad++, dans le menu "édition": suivi de "enregistrer"

En effet, j'ai proposé le script en fonction de ton exemple ci dessous qui ne parlait que d'extension; Par contre, si tu veux pouvoir filtrer sur *l'ensemble* du nom du fichier, suffira de modifier la line suivante; findargs+=( "-name" "*.$ext" "-o" ) et la remplacer par findargs+=( "-name" "$ext" "-o" ) (faudrait aussi peut-être donner un autre nom à la variable "ext" maintenant qu'on l’interprète différemment mais c'est cosmétique) Optionnellement, tu peux aussi utiliser "-iname" au lieu de "-name" comme cela ça ignorera les différence majuscules/minuscules Ayant fait ça, suffira d'utiliser pour les paramètres 3 et suivants "*.mp3" au lieu de simplement "mp3" (mettre toujours les doubles quotes pour éviter les surprises), et, dans le cas ci dessus: "LeGrosBoeuf*.mp3" Encore heureux que ça ne fasse pas de message d'erreur! Je ne vais pas suggérer des commandes qui font des erreurs quand même! Par contre, une fois cela effectué, essayer de nouveau lancer le script dans le contexte ou ça plantait (à savoir: "quand je l’exécute avec putty ou avec le planificateur de tâche il ne marche pas (command not foud)").

Tous les paramètres à partir du 3ème et suivants sont la listes des extensions de fichiers à déplacer à partir du dossier nommé par le paramètre #1 vers le dossier nommé par le paramètre #2. Sur la ligne 18, tu as mis en paramètre #3 "LeGrosBoeuf" . Le script interprète ça comme le déplacement des fichiers nommés "<machin>.LeGrosBoeuf". Je ne pense pas que ce soit ce que tu cherches à faire. Il faut utiliser des *doubles* quotes (") pour que les variables soient interpolées à l'intérieur tout en conservant les espaces, autrement dit: moveto -c ${download} "/${podcast}/Apero du Captain/" ADC La première ligne de ton script doit être une ligne "shebang" pour indiquer le shell à utiliser, avec ce format: #! /bin/bash Il doit être exécutable aussi ("chmod +x /volume1/homes/Flavien/Script_Synology/moveto_script.sh") Essaie de vérifier ça déjà.

Il semble que depuis le passage du réseau TV Français en TNT HD, *aucun* dongle ne marche, le problème semble coté VideoStation. Certains ont déjà ouvert des tickets au support Syno, on attend leur retour. Il y a déjà un long fil sur le sujet:Tuner TNT Compatible passage TNT HD

Comme pour les liens de partage "simples": mettre le nom ou l'ip externe dans panneau de configuration -> "accès externe" -> "avancé" -> "nom d’hôte ou IP statique" (et meme sans ça, il suffit de faire la substitution dans le lien généré, ça devrait fonctionner)

je suppose que tu as lu le fil Let's Encrypt et DSM 6.0 : comment créer et installer un certificat sur votre NAS Synology et en particulier le post de @warkx: http://www.nas-forum.com/forum/topic/50375-lets-encrypt-et-dsm-60-comment-créer-et-installer-un-certificat-sur-votre-nas-synology/?do=findComment&comment=1319290327

Désolé, je n'ai pas d'autre piste pour le moment.

Dans ce cas la manip n'est bien entendu pas nécessaire. Juste s'assurer que ton serveur est bien accessible de l'extérieur avec ton nom de domaine perso.

Je ne comprend pas ce qui te poses problème: pour qu'un certificat SSL let's encrypt serve à quelque chose, faut que ton NAS soit accessible de l'extérieur en HTTP(S). Mais si tu ne sais pas comment faire, pour quelle raison as-tu besoin d'un certificat alors? **EDIT** Pour que la création de certificat fonctionne, faut que http://<nom_du_nas>.<ton_domaine>.ext aboutisse sur ton Synology.

Me semble me souvenir qu'il est nécessaire d'avoir redirigé les ports HTTP dans la box ou le routeur (443 et peut-être aussi 80) pour que ça fonctionne (uniquement le temps de l'opération,on peut refermer ensuite)

A ta place je ne me ferai pas d'illusion: vu l’extrême faiblesse de la base installée de cet OS, ca serait tres étonnant que Synology prenne la peine de faire travailler une équipe de dev sur un tel portage.

Dans FileStation, créer un dossier de réception (n'importe où, c'est sans importance) Ensuite, bouton droit -> "créer une demande de fichier" Renseigner les champs l'URL générée de partage est copiée dans le presse papier (sinon suffit de la récupérer dans le champ "lier") Communiquer cette URL à vos amis Il faudra vérifier que le port 5000 est correctement redirigé dans la box/le routeur (ou le 5001 pour une connexion sécurisée SSL, faudra aussi modifier le port dans l'url récupérée ci-dessus, mais ce n'est pas indispensable ici). Ou bien, si on ne veut pas avoir à s’embêter avec ça, configurer Quickconnect: panneau de configuration -> "quickconnect" -> avancés -> cocher "partage de fichiers"

S'agit d'un problème assez répandu constaté par ceux qui utilisent la fonction "configuration du routeur" (anciennement "EZ-Internet") ce qu'on a toujours ici dans le forum déconseillé. Il est bien plus fiable de faire les redirections de ports dans la box, d'autant plus avec une Freebox ou l'interface est assez bien conçue. D'autres témoignages récents: DSM 6 erreur "vérification de l'environnement reseau" autour d'EZ-Internet (invisible dans "paquets", fiabilité, éviter?) En résumé mon conseil est: dans "configuration du routeur", tout supprimer ce qui a été configuré redémarrer Freebox, NAS et PC configurer les redirections de ports en allant sur http://mafreebox.freebox.fr/ -> paramètres de la Freebox -> gestion des ports -> redirections de ports

Soyez indulgents: ne trouvez-vous pas quand même un peu WTF de lire dans le même message "erreur inconnue" pour en découvrir, juste en dessous, sa cause, en totale contradiction avec la qualification "inconnue".