CoolRaoul

Ca semble bloquer au niveau du profile du compte root... N'aurait-il pas été modifié précédemment? (mais je pense que tu nous l'aurais dit) Pour comprendre ce qu'il se passe, dis-nous d'abord ce que donne un simple: sudo sh et, si ce dernier fonctionne, serait intéressant d'avoir la trace de: sudo sh -lx

J'en un peu creusé le truc entre temps, pas sur que ce soit aussi trivial. Me suis aperçu que la conf Nginx native Syno est un peu alambiquée, en particulier avec des fichiers de conf générés à la volée au démarrage. Ca pourrait peut être marcher en mettant le .conf dédié Domoticz dans le dossier "sites-enabled" mais toute mauvaise manip (erreur de syntaxe) risque de faire perdre l'accès http à DSM (ports 5000/5001). Mieux vaut sans doute opter pour l'approche que je décrit dans mon tuto de reverse proxy via Nginx, plus sure (car il s'agit d'une instance Nginx entièrement indépendante de l'instance système)

Pour utiliser un seul certificat SSL.

Précision ajoutée après que j'ai fais la remarque. Et c'est pas optionnel mais inutile vu que ce sont *déja* les options par défaut. Suffit d'essayer (la preuve est que le tuto ne demande pas de redémarrer le démon sshd alors que c'est nécessaire pour que les modifications du fichier de config soient prises en compte) C'est parce que tu utilises "sudo -l -U root" (j'avais pas fait gaffe initialement d'ailleurs) qui se contente de *lister* les droits sudo de l'utilisateur root mais ne provoque pas d'élévation de privilege. La bonne commande est "sudo -i -u root" (u minuscule et "i" et non pas "l") ou, plus simplement, "sudo -i" puisque le compte "root" est le défaut. Ref: http://linux.die.net/man/8/sudo -l[l] [command] If no command is specified, the -l (list) option will list the allowed (and forbidden) commands for the invoking user (or the user specified by the -U option) on the current host. Et bien, je demande à voir. En tout cas voici ce que donne pour pour moi: en sftp on peut se connecter en admin (ou tout autre compte) mais pas en root. Pourtant les connexions ssh sont possibles sur le compte root comme on peut le constater par la première commande (connexion par clé publique active par agent ici): [root@fserv_~]$ ssh root@localhost pwd /root [root@fserv_~]$ sftp root@localhost Connection closed [root@fserv_~]$ sftp admin@localhost Connected to localhost. sftp> quit Par contre en "SCP", ca fonctionne pour root a partir du moment ou ssh fonctionne: [root@fserv_~]$ touch /tmp/toto [root@fserv_~]$ scp root@localhost:/tmp/toto /dev/null toto 100% 0 0.0KB/s 0.0KB/s 00:00 Ma remarque sur le refus de clé (contrairement au reste de mon post) concernait le refus de clé constaté par @hacr, c'est donc *sa* config qui est en cause, pas la tienne (et le port 22, tant qu'on est en réseau local c'est pas très important: j'utilise bien le port 22 et je ne me crois pas fou. Par contre j'ai une redirection sur mon routeur qui utilise un numéro plus exotique et à ca j'ajoute des restrictions d'IP dans le firewall) Je me suis sans doute mal fait comprendre sur ce point: je ne disais pas que le mot '"pageant" était absent du tuto, mais que sa configuration n'était pas abordée alors que l'indication explicite de cocher cette option n'avait de sens que *si* il était actif. Si il ne l'est pas, bien évidement que l'option soit cochée ou pas ne change rien mais alors inutile de le spécifier dans le tuto. Comme déjà mentionné un peu plus haut ma remarque ("pas possible de se connecter root") ne portait que sur *SFTP* (bien lire la phrase en entier), clé publique ou pas ne change rien. Et pour être un peu plus constructif, voici comment utiliser pageant et ne plus avoir à saisir la passphrase de sa clé privée à chaque connexion Sous Windows, récupérer le chemin de son fichier de clé privé (celui créé au point #3 du tuto, disons "C:\Users\Dudule\local.ppk") Ajouter un raccourci vers pageant (pageant.exe, livré avec Putty) dans le dossier démarrage %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup dans les paramètres du raccourci, ajouter le chemin du fichier clé dans le champ "cible" La passphrase de la clé privée ne sera demandé *qu'une seule fois* à l'ouverture de la session Windows. Ensuite, pour peu qu'on ait bien activé l'option "allow the connection agent" dans putty *et* dans Winscp, les connexions SSH se feront sans avoir à saisir la passphrase à nouveau. C'est bien confortable.

Finalement trouvé la solution (pas sur que ce soit la plus élégante mais mes compétences Nginx ont leur limite: location /dsm { server_name_in_redirect off; port_in_redirect off; rewrite ^/dsm$ /dsm/ redirect; rewrite ^/dsm(.*) $1 break; proxy_pass http://localhost:5000; include proxy_defaults.conf; proxy_buffering off; } Ce sont les 3 clauses "server_name_in_redirect off", "port_in_redirect off" et "rewrite ^/dsm$ /dsm/ redirect" qui font le job Si ça peut servir à d'autre.. **EDIT** Par contre ça ne fonctionne toujours pas avec un navigateur sur mobile, faut forcer le mode "desktop". Et là je reste sec.

C'est possible, en utilisant "OpenVPN for Android" par exemple (ce n'est pas le seul client OpenVPN Android mais c'est celui que j'utilise)

Ok c'est plus clair comme ça. Et sinon, ça marche maintenant le script de démarrage au boot?

Tu m'en diras tant! (pas compris grand chose mais c'est sans importance ) Je reste juste étonné du chemin du binaire python ("/volume1/homes/admin/dev/web_server/env/bin/python") je suis surpris python de Synocommunity soit installé avec ce chemin

Tant que le script n'aura pas rendu la main le démarrage du NAS sera toujours considéré comme "en cours" Il faut donc qu'il soit lancé en background. Pour cela, à la fin de la la ligne: /volume1/homes/admin/dev/web_server/env/bin/python /volume1/homes/admin/dev/web_server/surv_station_server.py >> /volume1/homes/admin/dev/web_server/log.txt tu dois ajouter : </dev/null 2>&1 & Au passage, ca serait plus lisible écrit ainsi: cd /volume1/homes/admin/dev/web_server ./env/bin/python surv_station_server.py >>log.txt 2>&1 </dev/null & Question subsidiaire: pourquoi n'utilises-tu pas le python 2.7 pré-installé (/usr/bin/python) "officiel" ou éventuellement le paquet python 3

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)