CoolRaoul

En ligne de commande il y a 7zip (commande: "7z", disponible sous DSM6) Détail de la syntaxe ici: https://sevenzip.osdn.jp/chm/cmdline/commands/extract.htm **EDIT** Encore plus simple (comment ai-je pu oublier ?): dans FileStation, menu contextuel sur le fichier .iso et choisir "monter le lecteur virtuel"

je ne connais pas l'appli IOS, mais dans le cas de la version Android, je viens de tester un port alternatif, configuré dans le portail des application et ça semble fonctionner. Suffit d'ajouter ":<numéro-de-port>" dans le champ "adresse" de la fenêtre de connexion: Bien entendu ce port doit avoir été redirigé dans le routeur ou la box. Là je n'ai fait mes tests qu'en local mais un tcpdump me confirme que le traffic passe bien par ce port.

Parmi les protocoles proposés par filestation dans "outil"→"connexion à distance" il n'y a pas "FTPES", uniquement "FTP" (ref) Donc ça ne peut pas marcher.

Dans le cas de file station (puisque c'est de cela qu'il s'agit) ca doit pouvoir se faire sans même avoir à mettre en oeuvre un reverse proxy. Dans le panneau de configuration -> "Portail des applications", onglet "application", il est possible de définir des alias pour certaines services, parmi lesquels filestation. Et, contrairement à ce qu'il se passait en DSM5, me semble bien qu'il il ne s'agisse plus de redirection, on accède directement au service par le port 80 (ou 443 en https). A tester.

D'apres le screenshot c'est Cloud Station Backup que tu as installé alors que c'est Cloud Station Drive qu'il te faut

Je te conseiller de jeter un oeuil à KeeWeb Si on en croit son README, un simple serveur web (et donc celui DSM) devrait pouvoir marcher (pas testé par contre) "Everything you need to host this app on your server is any static file server. The app is a single HTML file + cache manifest (optionally; for offline access). " Par contre (si j'ai bien compris son mécanisme) il ne semble pas capable de lire un fichier kdbx stocké sur le serveur. Cependant il dispose de plusieurs autres méthodes d'acces dont webdav: La aussi si j'ai bien compris, tout se passe dans le navigateur, enfin à toi de tester si tu te sens.

D'apres ce que je lis du produit, ce dernier supporte SFTP mais pas SCP, ce qui explique cela: sous DSM, SFTP ne donne acces qu'aux dossiers partagés, pas à la racine.

bienvenue au club !

Pour compléter ce qui a été dit ci-dessus, dans le cas ou on utilise apache, le bon endroit pour mettre ses configs perso pour le serveur web est "/usr/local/etc/httpd/sites-enabled", dans lequel on déposera un ou plusieurs fichiers ".conf" (contenants des directives globales mais plutôt des blocs <Directory /var/service/web/<chemin>.. > .. </Directory>) Attention a bien vérifier la syntaxe en redémarrant apache ("synoservicecfg --restart pkgctl-WebStation" en line de commande par exemple) Cela dit, personnellement, j'utilise très ponctuellement des .htacess pour des besoins spécifique et c'est bien pratique (pas besoin de redémarrer apache )

J'avais le même probleme. Résolu en appliquant la modif de "ipsec.conf" indiquée dans ce post: https://forum.synology.com/enu/viewtopic.php?f=173&t=116297&start=15#p430936

Bizarre, n'a pas disparu chez moi. Es-tu bien sur d'avoir constaté cela juste apres la migration DSM6 ? N'aurait-il pas été supprimé suite à autre chose ? En tout état de cause, te reste à le recréer ainsi que son contenu. Sinon tu as également l'option d'utiliser la nouvelle possibilité, apparue avec DSM6, du gestionnaire de tâches d'appliquer l'attribut "au démarrage" pour les tâches utilisateur.

Je ne parviens pas à m'expliquer un lien de cause à effet entre le changement de shell et le blocage ou pas de la commande "ps". (en fait je ne comprend même pas ce que Synology cherche à faire avec ce "ps | grep $$ | grep tty" dont le "grep tty" n'a a priori aucune raison de matcher quoi que ce soit. En outre, en DSM6 ash, sh et bash sont symlinkés: [admin@fserv_~]$ ls -l /bin/*sh lrwxrwxrwx 1 root root 4 Mar 26 17:08 /bin/ash -> bash -rwxr-xr-x 1 root root 1236860 Mar 6 20:52 /bin/bash lrwxrwxrwx 1 root root 4 Mar 26 17:08 /bin/sh -> bash -rwxr-xr-x 1 root root 674268 Mar 23 05:48 /bin/ssh D'autant plus que chez moi j'ai bien "ash" et ne constate aucun problème: [admin@fserv_~]$ grep "root:" /etc/passwd root:x:0:0:root:/root:/bin/ash Vraiment perplexe je suis

Je ne parviens pas à lire le résultat "ps -ef" mais si tu n'a pas le prompt, c'est en effet bien la que ca bloque. Et dans le profile c'est le ps de la ligne: isTTY=$(ps | grep $$ | grep tty) Qui à le même effet. Ce n'est absolument pas normal, surtout sur un NAS qui vient juste d'être réinstallé. J'ai bien peur qu'il ne te reste plus qu'a ouvrir un ticket au support en leur expliquant bien le symptôme (blocage commande "ps")

Tiens, je ne retrouve plus mon message??? Bien entendu j'avais testé avant de proposer cette solution. Ma configuration WebStation est basée sur Apache. Bien vérifier les droits du fichier .htaccess (à poser dans /var/services/web/) et les logs en cas d'erreur 4XX (dans /var/log/httpd) Chez moi j'ai ceci (l'important c'est le "read" pour le groupe http) [root@fserv_web]$ ls -l /var/services/web/.htaccess -rw-r----- 1 root http 950 May 22 08:33 /var/services/web/.htaccess

essayer "ps -ef" (sans sudo) et, si ca coince aussi, donner le résultat de "sudo which ps" C"était "cat /root/.profile" (l'espace en trop involontaire est du au clavier Android de ma tablette, pas fait gaffe) Mais de toutes façons, si le "ps" précédent coince aussi, c'est inutile. Commencer par rebooter le Syno, et si ca persiste je vais m'avouer vaincu, faudra sans doute ouvrir un nouveau ticket au support.

Maintenant nous faudrait le résultat des commandes: "sudo ps" et "sudo cat /root/. profile"

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