CoolRaoul

Pour ce que tu veux faire, me semble qu'il vaut mieux d'utiliser la fonction "partage de liens de fichiers" de filestation, appliqué à un dossier. Ca aura pour effet de générer un lien qui donne acces uniquement à ce dossier, en lecture seule, soit de façon anonyme soit avec authentification Dans filestation sélectionner le dossier, puis "partager les liens de fichier"

Comme quoi il n'y a pas de règle. Je tenais à donner un exemple que NAS-Forum n'est pas le seul dans ce cas et la réponse ne peut pas être simplement de se dire "pas de chance, pourquoi sommes-nous les seuls à être attaqués?". Il existe des méthodes a la fois préventives et réactives comme cela à été abordé dans ce fil, il est impératif d'en mettre en oeuvre au plus vite. (pour ma part le captcha à chaque post ca me gonflerait grave, mais si on ne peux faire mieux faudra vivre avec) Je ne pense pas. je dirai plutôt que déléguer, même partiellement, c'est aussi accorder sa confiance et ca c'est jamais facile de but en blanc.

Tu n'avais parlé que de fichiers pas de dossiers. La solution est celle-ci: find /volume1/commun/incoming -maxdepth 1 ! -name 'nepassauvergarder' | xargs --no-run-if-empty mv -t /volume1/commun/archive Note: on peut ajouter en argument de "find" d'autres "! -name <fichier ou dossier à exclure>" et pour ces derniers utiliser des jokers ("*", "*", etc ...) avec un "find | xargs" en entrée on inverse le sens du "mv": "mv -t <destination> <fichier_ou_dossier> ... Ca c'est simple: mv --backup=numbered /volume1/commun/incoming/* /volume1/commun/archive-$(date %F)/ (Il existe d'autre formats possible pour la date) Références doc de "find": http://linux.die.net/man/1/find doc de "date": http://linux.die.net/man/1/date doc de "xargs": http://linux.die.net/man/1/xargs Nb: si tu as d'autres questions sur les commandes en ligne je t'engage à poursuivre dans une des section "Newbie du monde Linux" ou"Terminal Telnet et SSH"

En fait c'est simplement plus visible du fait que le nettoyage n'est pas fait assez vite. Je suis responsable de section sur un autre forum francophone (FrAndroid pour ne pas le nommer) est là-bas aussi il arrive fréquemment de subir ce des flots de spams exactement du même type et tout autant volumineux. La différence est que, grâce justement à l'existence d'une équipe modération suffisamment importante, le flot est très rapidement endigué et la plupart des visiteurs n'ont pas le temps de s'en apercevoir.

suffit de faire une tache quotidienne programmée via le planificateur de taches intégré à DSM avec la commande suivante: mv --backup=numbered <chemin dossier_source>/* <chemin dossier_destination> ("--backup" sert à ne pas écraser les fichiers du même nom comme demandé) Exemple: mv --backup=numbered /volume1/commun/incoming/* /volume1/commun/archive/ Documentation commande "mv" ici: https://www.gnu.org/software/coreutils/manual/html_node/mv-invocation.html

C'est pas en insultant les gens que tu feras avancer le dossier Résumons: le besoin est simplement que le Mac accede à internet en ethernet plutôt qu'en WIFI. La solution qu'on propose est quasiment la norme en terme de bonnes pratiques: (internet) | | [ BOX/routeur ] | | | | | +--- <autres équipements, en direct ou via un switch> [NAS] [PC/Mac] L'investissement se résume à l'achat d'un malheureux cable ethernet (qu'on doit trouver pour à peu prix le prix de deux paquets de café moulu). Pourquoi chercher à tout prix une solution alternative plus complexe ? La méthode que tu cherches consisterait à configurer le NAS en mode "routeur". Via une recherche rapide suis tombé sur ce fil daté de plus de deux ans sur le sujet qui décrit une méthode pour éventuellement y parvenir: https://forum.synology.com/enu/viewtopic.php?t=70083 Mais d'une part je ne suis pas sur que ca fonctionne à l'identique sur la dernière version de DSM, de l'autre c'est bien entendu non supporté et probablement mis en oeuvre quasiment par personne. Par suite, en cas de problème de fonctionnement, faut pas compter trouver facilement de l'aide ni de la part de Synology, ni des utilisateurs (qui ne sauront pas reproduire ton setup pour pouvoir analyser)

Ah tiens, j'ignorais ça: j'étais persuadé que le serveur multimedia qui assure la fonction DLNA savait tirer partie du décodage à la volée des modèles "play" lui aussi.

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.

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.

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.

bienvenue au club !

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")

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)

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.

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.