CoolRaoul

C'est le cas, j'ai eu l'occasion de le constater tout récemment: https://forum.synology.com/enu/viewtopic.php?f=145&t=120588&p=445644#p445644

En complément à @Fenrir, le principe est que les règles du firewall s'appliquent de haut en bas. Des que la condition d'une règle est vérifiée, l'action correspondante (autoriser ou refuser) est sélectionnée et les règles suivantes sont par conséquent ignorées. Si aucune condition s'applique, c'est l'action par défaut ("si aucune règle n'est remplie") qui est sélectionnée. En général je préconise de commencer par une règle "open bar" qui autorise le réseau local (192.168.XX.YY en général) pour ne pas se retrouver bloqué. Et ensuite c'est selon son usage.

Il n'y a aucune différence avec ce que tu t'apprétais à faire avec Optware (AKA "ipkg"), juste qu'en utilisant ce script au lieu de celui que ty t'apprétais à utiliser (sous réserve que j'ai bien compris la question initiale), tu n'auras pas besoin de Optware, rien à ajouter à DSM. En résumé tu dépose le script ou tu veux, ensuite le rendre exécutable (commande "chmod +x <chemin du script>"), modifier les variables initialies et ensuite pour l'exécuter, soit dans une fenêtre terminal (mieux vaut commencer ainsi d'ailleurs pour la mise au point), soit via le planificateur de taces (dans le panneau de configuration DSM). Tu peux utiliser le compte "admin" pour l'exécuter, pas besoin de "root" Tu trouvera plein d'exemples dans le forum.

Autre méthode: j'utilise un script maison pour faire un miroir local via ftp d'un site web situé chez un hébergeur externe. Il utilise exclusivement des commandes disponibles sous DMS6 (pas besoin d'optware donc). Me semble même que "lftp" était *déja* disponible en DSM5 dans le package Download Station (désormais c'est de base dans DSM). En outre, comme il fonctionne en mode miroir (commande lftp "mirror") c'est très efficace quant il y a peu de modifications. Voici: #!/bin/ash PATH=/bin:/usr/bin # remplacer les variables ci dessous host=ftp.monfournisseur.net password=XXXXXXX user=UUUUUUUUUU dest=/volume2/backups/websitemirror # destination du répertoire miroir sur le NAS mkdir -p $dest chmod go= $dest lftp <<EOF set ssl:verify-certificate no open $host -u "$user,$password" mirror -v . $dest/. EOF

J'avais lu lu ça mais je ne pense pas qu'on doive s'inquiéter (dans le cas de liens entre dossiers partagés en tout cas). Je viens à l'instant de faire un test avec un lien symbolique pointant vers un dossier situé dans un autre partage Dans ce dossier j'ai créé deux sous-dossiers, l'un avec des droits ACL "ouverts", et l'autre restreints. Un utilisateur non autorisé n'a non seulement pas acces au dossier restreint mais il ne le visualise même pas dans l'explorateur. Donc les droits affectés au dossier cible du lien sont bien pris en compte (et c'est heureux) **EDIT** Par contre il est important de garder à l'esprit que cette méthode utilisant les liens symboliques n'est apparement compatible uniquement avec les partages windows (CIFS), vu que ca se positionne dans les paramètres avancés de la section "partage de fiichiers Windows" de DSM. Ca reste invisible dans FileStation par exemple (faudrait éventuellement vérifier les autres modes d'acces).

Pour en revenir à la méthode s'appuyant sur des liens symboliques, je me demande si l'option ci-dessous (pas testée de mon coté) ne répondrait pas à la demande:

Faudrait commencer par ouvrir un fil dédié, parce qu'ici dans "Support des logiciels Synology -> Accès à vos données" je pas certain que ce soit le meilleur endroit Choisir par exemple: Divers -> Underground / Modifications ou Divers -> Newbie du monde Linux Ensuite faudra se poser la question du *pourquoi* installer Optware", projet à l'abandon depuis des années (voir ce que j'en pense ici)

Vu que ma demande de restauration (suite à mon post mentionné ci dessus) ne s'est pas concrétisée, à ta place je me garderai de trop d'optimisme.

Suite à une fausse manip, m'est arrivé la même chose sur un tuto, qui plus est très fourni de questions/réponses. Pas eu de retour sur une possible restauration: http://www.nas-forum.com/forum/topic/51395-jai-fais-une-cie/ J'en ai déduis que le forum ne dispose apparemment pas de sauvegardes. Faut donc faire très attention ! (extrême coup de pot j'avais précisément sauvegardé le contenu brut du post initial une semaine plus tot, par contre toutes les commentaires associés ont irrémédiablement disparu)

Un poil plus compliqué que la mienne, donnée juste avant! on dépose le script, correctement nommé et chmodé, directement dans le "/usr/local/etc/rc.d/" et roule ma poule. En plus je ne suis pas sur que cette méthode, qui ajoute un fichier dans "/etc/init" résiste au upgrades DSM (alors que le contenu de /usr/local est garanti conservé par Synology dans ces circonstances)

Les options "tache déclenchée sur événement (démarrer/éteindre) n'est apparue qu'avec DSM6 Pour les version précédentes faut mettre les mains dans le cambouis (plus exactement dans "/usr/local/etc/rc.d") et suivre ces instructions: If you would like to run an application when the system boots up, you have to write a startup script and put it in /usr/local/etc/rc.d/. Following are some rules for the startup script: 1. It must have the suffix “.sh”. For example, “myprog.sh”. 2. The permission must be 755. 3. It must have the options “start” and “stop”. When the system boots up, it will call “myprog.sh start”; when it shuts down, it will call “myprog.sh stop”. You can refer to the scripts in /usr/syno/etc/rc.d/. They are script for Synology default services.

Ah oui en effet, je n'étais pas allé assez loin. Ca risque d'être problématique alors. Mais pour quelle raison vouloir utiliser ce language sur un NAS? Un PC ne serait-il pas plus approprié? En effet, on peu lire sur la page Install OCaml que c'est supporté sur un grand nombre de plate-formes. Pourquoi choisir justement une parmi celles non validées? D'autant plus qu'en cas de dysfonctionnement ca pourrait s'avérer sportif de trouver quelqu'un utilisant la même plate-forme pour obtenir de l'aide.

Pas sur qu'Optware soit nécessaire d’après ce que je lis sur cette page: "How to install opam" Ca à eu l'air de marcher pour moi (suis pas allé plus loin que "opam --help" mais a priori ca semble bootstrappé) NB: non seulement le projet Optware est en hibernation, plus supporté depuis des lustres mais quand il est installé sur un Syno toute ouverture de ticket au support reste bloquée tant que c'est le cas. Mieux vaut éviter de l'utiliser quand c'est possible.

C'est vrai que les permissions ça peut rapidement devenir un peu "touchy" si on ne respecte pas quelques règles de base: quand on a à gérer un plusieurs utilisateurs partageant une typologie commune, *systématiquement* commencer par créer un groupe correspondant. Par exemple ici nommé "clients", à créer dans la section "groupes" du panneau de configuration DSM. Ca permettra de gérer des droits de façon globale là ou c'est approprié. ne *jamais* utiliser les permissions de type "refuser". En général il est toujours plus simple de n'autoriser que ceux qui sont habilités, les autres se voyant étant automatiquement refusé tout accès. Ici ça va donc donner: Création du groupe "clients", lui donner le droit FTP dans l'onglet "applications". Création du dossier partagé, nous l'appellerons "clients". Pour ses permissions, sélectionner le mode "groupe locaux", et positionner lecture/écriture pour le groupe "clients" (on va affiner ça ensuite dans FileStation) Création de comptes DSM : client1, client2, etc. chacun d'eux appartenant ua groupe "clients" et rien de plus au niveau des droits. Dans file station maintenant sélectionner le partage "clients" Propriétés -> permissions -> "clients" -> décocher tout sauf "Traverser les dossiers/Exécuter les fichiers" Y créer un sous dossier par client. Pour chacun d'entre eux: Propriétés options avancées -> "exclure les permissions héritées" "Créer" Champ "utilisateur ou groupe" -> <nom du compte client> Zone "permission" : tout cocher dans lire et écrire, rien ailleurs. Résultat de la manip (si je n'ai rien oublié): les clients pourront se connecter en ftp, verront le partage "clients" mais n'auront pas le droit d'en lister le contenu. Ils devront aller directement dans le dossier qui leur est attribué (commande ftp "cd clients/<nom_clients>", à configurer dans leur application ftp ou par un raccourci sur leur poste de travail) Dans ce dossier ils auront tous les droits, et rien en dehors (ca peut s'affiner ensuite si nécessaire) Ce qui empêche les clients de lister le contenu du dossier des autres clients est le fait d'avoir décoché le droit "lister les dossier" du dossier partagé "clients". Si on fait partie du groupe client on peut le traverser mais il faut savoir le nom du sous-dossier où on veut atterrir. Il n'est hélas pas possible, en ftp en tout cas, de rendre un dossier invisible à certains utilisateurs (l'option "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" ne s'applique pas en mode ftp hélas)

Même plus besoin de script, en parcourant le forum Syno US je viens de tomber sur ce post qui mentionne la commande "synonet", native à partir de DSM6. Usage: synonet --wake [MAC address] eth0

Plus simple, si on veut strictement répondre à la requête exprimée dans le titre du fil, il y a ça: OK, je sors, pas pu m’empêcher Mais avant de sortir: Tu ne dis pas de bêtise: ça consiste à utiliser une partie dédiée (LUNs SCSI) de l'espace de stockage NAS comme bibliothèque de contenu VmWare (disques virtuels, ISOs) mutualisée, pour les VM d'un ou de plusieurs serveurs VmWare. Autant dire qu'on parle là d'environnement "pro" et que la bande passante réseau a intérêt à assurer (LAN 10GB de bout en bout recommandé) et c'est pas par hasard que c'est réservé aux modèles Syno "High End"

Devrait marcher aussi bien que celui dont j'ai donné le lien Et tu peux faire abstraction de ton niveau en programation puisqu'il suffit de le recopier tel quel pour l'utiliser. Pas besoin de comprendre son fonctionnement.

Beaucoup plus simple à mon avis: Installer (si ce n'est déja fait) le package "perl" pour DSM. télécharger ce script: http://rom-o-matic.net/gpxe/gpxe-0.9.3/contrib/wakeonlan/wakeup.pl le déposer dans un répertoire de son choix du NAS programmer l'appel du script via le planificateur de tâches intégré à DSM avec la commande ci dessous: perl <chemin du script>/wakeup.pl <addresse mac de l'équipement à réveiller>

Encore une erreur de ma part, manque un "+" c'est $(date "+%F")

Ah oui, en effet, j'avais oublié: faut créer le répertoire au préalable, Suffit d'ajouter cette ligne au dessus de la commande "mv": mkdir -p /volume1/commun/archive/archive-$(date %F)/ Ou mieux, utiliser des variables, comme ceci: srcdir=/volume1/commun/incoming dstdir=/volume1/commun/archive/archive-$(date %F) mkdir -p $dstdir mv --backup=numbered $srcdir/* $dstdir/ Pas forcément une bonne idée, une erreur de frappe est vite arrivée avec des résultats potentiellement à problème Le gestionnaire de taches de DSM permet de choisir sous quel compte utilisateur effectuer la tache, mieux vaut utiliser cette option.

En effet, mais reconnaissons que ce problème était déjà implicitement présent dans la solution initiale C'est peut-être plutôt sur le contrôle du traffic qu'il faudra jouer plutôt (dans "panneau de conf" -> "réseau" ) Mais je dois avouer n'avoir pas encore expérimenté cette fonction.

Ah j'avoue ne pas avoir trop investigué les modes de restriction d’accès de VideoStation, faut expérimenter. En tout cas ne pas oublier que si le paquet "serveur multimedia" est actif ce dernier donne acces sur le réseau local à tous les fichiers videos situés dans des dossiers indexés (ce qui s'ajuste dans "panneau de configuration" -> "service d'indexation" -> "dossiers indexés"). En effet le protocole DLNA qui est utilisé dans ce cas n'implémente pas d'authentification.

Suffit de descendre d'un cran le contenu du partage documentaires dans un sous dossier et le tour est joué (peut-être pas très élégant en local, mais transparent pour les utilisateurs distants) Autre possibilité, déplacer ce dossier "Documentaires" comme sous dossier du partage "Video".

Réfection de la facade est (le coté ouest ayant été fait il y a quelques années de ça) Et je peux te dire que la douloureuse est salée pour les propriétaires

Peut être suffit-il dans le gestionnaire de stockage de supprimer les LUN SCSI pour pouvoir créer des volumes locaux En tout cas ca vaut le coup d'essayer **EDIT** J'ai voulu vérifier si il état possible de simuler ça sur la démo DSM en ligne mais je ne trouve aucune indication du compte et du mot de passe à utiliser!