CoolRaoul

En activant la fonction DHCP de DSM (qui s'appuie sur dnsmasq) tu bénéficie d'un serveur DNS "light" qui devrait suffire pour ce genre de besoin. Suffit d'ajouter des entrées hosts dans "/etc/hosts" du syno et elles seront résolues (sinon dnsmasq se reporte au serveur DNS par défaut pour les IP ou les hosts qu'il ne connait pas. Il gère un cache local également.

J'y ai pensé (et google drive aussi a des tarifs compétitifs) mais ce n'est pas demain la veille que ces services supporteront rsync et donc sauvegarde et restauration "native" de DSM.

Juste un bémol: dans un réseau perso, deux serveurs DHCP, pour peu qu'on veuille mettre en place de pré-allocation d'IP en fonction de la MAC, ça peut être ch** à gérer (faut dupliquer les confs, mais ça fonctionne). C'est surtout utile dans un réseau "pro" ou on souhaite assurer une redondance entre deux serveurs DHCP (bien que la aussi, une approche de type failover soit sans doute aussi efficace). Faut juste retenir c'est que ça fonctionne, le protocole est "étudié pour".

Pour de la sauvegarde il ne me semble pas important de bénéficier d'un gros débit . Par contre faudrait pouvoir garantir, à la demande et au coup par coup, une "fenetre" à haut débit pour une grosse restauration.

Oui, je le pense aussi: deux niveaux de tarifs en utilisant les quotas réseau Syno par utilisateur ça pourrait se justifier. Attention aussi bien étudier les tarifs de la concurrence pour rester compétitif.

Intéressant, mais ne faudait-il pas aussi moduler le tarif en fonction de la bande passante utilisée? Un gus qui te sauvegarde 1G par jour, même pour une volumétrie totale cible faible, n'aura pas le même impact que celui qui fait de la synchro avec peu de données modifiées ? Et je ne suis pas sur que les quotas réseau DSM soit une réponse à cette problématique. Mais je conviens que ca risque d'être pas évident à mesurer et par suite à facturer.

IOS ne sait pas lire nativement les MP3?

je vais répondre pour la partie Windows, je laisserai d'autre contributeurs se charger de la partie unix (tip: ssh -i <chemin clé privée> <user>@<host> shutdown, mais faut un peu enrober pour faire ça en toute sécurité) Donc voila: Coté Windows sur le serveur cible activer le service RemoteRegistry Les commandes (à exécuter dans une boite de commande en mode administrateur) sont: sc config RemoteRegistry start= auto sc start RemoteRegistry ensuite dans la branche de la base de registre: "HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" créer l'entrée "LocalAccountTokenFilterPolicy" (de type 32-bit DWORD) et lui donner la valeur "1" bien qu'on puisse utiser le compte windows "Administrateur" pour cela je préconise de créer un compte dédié (on l'apellera "shutdown"). Ce compte doit être membre d'un groupe disposant du privilege "Forcer l’arrêt à partir d’un système distant" ce qui par défaut n'est le cas que du groupe des administrateurs mais ça peut se modifier (sur les versions pro) si on le souhaite avec la console "Stratégie de sécurité locale" Coté NAS: Das un script, on va alors pouvoir arréter le serveur Windows à partir du NAS avec la commande: net rpc shutdown -I <ip du PC windows> -U shutdown%<mot_de_passe> La commande "rpc shutdown" accepte les switches suivants (extrait de la doc) **EDIT** Ah, j'oubliais: la commande "net" se trouve dans "/usr/syno/bin", s'assurer que ce répertoire est bien dans le PATH.

Sous android il y a BubbleUPNP (avec le serveur associé sous DSM) qui assure (entre autre choses) la même fonction. Attention cependant à la consommation mémoire, à mon avis excessive, du serveur (codé en Java, faut pas s'étonner ensuite ) Sur un Syno peu doté en mémoire, ça risque de pas trop le faire.

+1, a part pour des tests, accéder à son VPN à partir de son propre réseau, l’intérêt m'échappe.

Me semble qu'il aurait été plus simple d'utiliser la fonction DYNDNS intégré au syno que partir dans ces galères avec ces routeurs en cascade derrière la BOX (il est encore temps remarque mais faudra laisser tomber tes routeurs)

je ne pense pas qu'il y ait de différence fonctionnelle entre brancher la sortie HDMI du PI sur la TV et sur un ampli A/V C'est pas faux. Euh.. non, je ne comprend pas cette expression: "installation headless" en fait Pourquoi, tu as bien du son sur ta TV quand l'entrée HDMI connectée au PI est sélectionnée non? Sinon il reste l'option de garder le popcorn et l'utiliser juste comme passerelle multimedia ou acheter un WDTV qui pourra avoir un meilleur WAF que le PI.

Pas de sortie HDMI sur le PI?

Et utiliser le serveur DHCP du NAS ouvre la porte à des développement intéressants (quoiqu'un poil intrusifs ) Surveiller les messages "DHCPDISCOVER" dans /var/log/messages, pour peu que tu connaisses l'adresse MAC Wifi des téléphones respectifs de ta progéniture, va te permettre de générer un rapport des heures d'arrivées dans la maison de chacun.

Comme switch *et* point d'acces WIFI, (vu que la raison initiale de de la manip est: "la puissance du wifi pour tout ce qui est jeu en réseau produits mobiles, bien meilleur a ma box et plus stable") et cela revient à la configuration avec point d’accès que j'ai proposée (avec le switch en prime) Si le DHCP de la livebox n'était pas capricieux ça ne serait pas forcément rédhibitoire (cf mon message ci dessus). Sinon l'objectif demandé était d'utiliser le DHCP du NAS mais en effet on peut aussi utiliser celui du routeur. Attention dans les deux cas à bien spécifier l'ip de la box comme routeur par défaut et les IP des serveurs dns du FAI. Bien entendu: je proposais la solution point d’accès au cas ou le routeur n'avait pas *déjà* été acheté (d'ou l'emploi du conditionnel). Sinon n'importe qu'el routeur WIFI peut se configurer en mode point d'acces (et certains firmwares permettent même dans ce mode de récupérer le port WAN pour un faire un port LAN supplémentaire)

Ben oui: le message d'erreur laissait le doute entre un problème de permission et cette erreur de majuscule. Heureusement que Bud à le coup d'oeil!

"c'est le matin, il est encore tôt"

Sans doute l'est-il déjà (que donne "ls -l /volume1/partage/liste.sh" ?)

Oui et alors??? Ca n’empêche pas que le script *doit* être exécutable. Essaie de faire ce que j'ai dit au lieu de temporiser, tu verra bien. **EDIT** Y a un truc que je ne comprend pas: le script c'est "/Volume1/System/PhotoStation_DB_copy.sh" ou "/volume1/partage/liste.sh"? ***EDIT#2** Oups je croyais répondre au premier posteur

Commencer par: chmod +x /Volume1/System/PhotoStation_DB_copy.sh Et ça ira bien mieux

Dans ce cas je me serai contenté de désactiver le wifi de la box et connecter un point d'accés wifi séparé au réseau Beaucoup moins galère à configurer. (un truc dans le genre de: http://www.amazon.fr/TP-Link-TL-WA801ND-passive-antenne-d%C3%A9montable/dp/B004UBU8IE/ )

Pas d'accord sur le DHCP. Le protocole est conçu pour supporter plusieurs serveurs DHCP sur le LAN (détail). Le principe est que tous les serveurs répondent (DHCPOFFER) à la requête initiale effectuée en broadcast (DHCPDISCOVER), c'est ensuite le client qui va choisir *l'un d'entre eux* et lui demander (DHCPREQUEST, toujours en broadcast pour que les autres serveurs soient au courant) l'allocation d’adresse . Le serveur répond par une confirmation (DHCPACK) En outre, a partir du moment ou le réseau wifi et le réseau filaire partagent le même subnet (ce qui est le cas par défaut des box) n'importe quel serveur DHCP du réseau saura répondre aux requêtes de n'importe quel appareil, qu'il soit connecté en wifi ou en ethernet. Pas besoin de mettre une clé WIFI sur le NAS. Pour info c'est la configuration que j'utilise: serveur DHCP actif sur mon NAS, celui de la box désactivé (j'aurais pu le laisser actif mais ça aurait été moins pratique pour les allocation d’adresses prédéfinies) et WIFI sur la box.

Apparemment les problèmes avec les flux de radio en .m3u ce n'est pas nouveau: Mais suffit de télécharger le .m3U et récupérer l'url .mp3 à l'intérieur, après tout ce n'est pas la mer à boire.

Ca sauvegarde bien les ACL pourtant (en encore heureux!) qui ne sont pas supportées en FAT32 Je pense qu'il devrait également être possible de les stocker sous forme de métadonnées dans le sous dossier "@app@metadata" de la cible de sauvegarde.

Ce n'est pas à cela que je pensais, il n'est bien entendu pas question que la sauvegarde *suive* les liens symboliques (ce qui en effet peut avoir des effets de bords bien tordus) mais bien qu'elle les sauvegarde *en tant que tels*. Je considère qu'une restauration d'un dossier partagé devrait être capable de le reconstituer dans l'état initial. A partir du moment ou les liens sont officiellement supportés ça me semblerait la moindre des choses qu'on soit capable de sauvegarder et restaurer ces derniers. Dans l'état, on peut "modifier ses sauvegardes" tant qu'on veut, les liens sont purement et simplement ignorés.