CoolRaoul

Autre probable avantages du Syno: Le silence La moindre consommation électrique Les fonctionnalités du système et leur intégration. Par exemple l'ajout, ou la modification d'un fichier, quel que soit le protocole réseau utilisé (SMB/CIFS, NFS, FTP, filestation etc ...) , entraînera immédiatement la mise à jour correspondante de la base d'index. Pas sur que tu obtiennes l'équivalent avec des packages linux de type FreeNas ou autres.

Tu devrait peut-être ouvrir un nouveau sujet pour ta question pour augmenter sa visibilité, ici il est question de streaming, pas d'enregistrement.

Si ça saccade c'est alors que tu aura un problème au niveau réseau (câbles, switches). Le travail du NAS dans ce type d'utilisation se résume à transférer les données sur le réseau et, même avec des sources HD le débit requis est largement en dessous de ce que n'importe quel modèle de la gamme est capable. Comme le NAS ne fera pas de transcodage video (aucun modèle DS213 le fait (*)), juste éventuellemet du transcodage audio (mais peu de chance que cela soit necessaire, ton téléviseur a de bonne chance de décoder les formats les plus courant en interne) son processeur ne sera tres peu sollicité. (*)

Mon grain de sel: Modifier le shell par défaut du compte root est, AMHA, une *tres* mauvaise idée . J'avais d'ailleurs déja posté un message sur ce sujet avec une methode alternative bien moins risquée: (à lire en remplacant "bash" par "zsh")

La visibilité des partages n'est pas liée aux droits de l'utilisateur authentifié. Ce n'est pas la faute de Synology mais une caractéristique du protocole SMB/CIFS. On peut rendre un partage invisible mais c'est tout ou rien: ça le sera pour tous les utilisateurs (mais cela n’empêchera pas ceux autorisés de s'y connecter si ils en ont le droit, bien entendu)

/var/log/synolog/synoconn.log contient les logs DSM. Une version "épurée" et moins détaillée Je cherche à retrouver les logs ssh "brutes" au format natif syslog comme avant.

Oui, et alors? Je veux parler de ce type de logs: Aug 27 19:44:02 sshd[13112]: SSH: Server;Ltype: Version;Remote: N.P.Q.R-50510;Protocol: 2.0;Client: PuTTY_Releas e_0.63 Aug 27 19:44:02 sshd[13112]: WARNING: /etc/ssh/moduli does not exist, using fixed modulus Aug 27 19:44:02 sshd[13112]: Accepted publickey for root from N.P.Q.R port 50510 ssh2 Aug 27 19:44:02 sshd[13112]: pam_unix(sshd:session): session opened for user root by (uid=0) Aug 27 19:44:57 sshd[13221]: SSH: Server;Ltype: Version;Remote: N.P.Q.R-50524;Protocol: 2.0;Client: PuTTY_Releas e_0.63 Aug 27 19:44:57 sshd[13221]: WARNING: /etc/ssh/moduli does not exist, using fixed modulus Aug 27 19:44:57 sshd[13221]: Accepted publickey for root from N.P.Q.R port 50524 ssh2 Aug 27 19:44:57 sshd[13221]: pam_unix(sshd:session): session opened for user root by (uid=0)

Je viens de m'apercevoir que je n'ai perdu les logs ssh dans /var/log/messages Est-ce que d'autres ont remarqué aussi? Et si oui, qui aurait trouvé comment rétablir ça?

je n'en ai pas testé d'autre que celui que j'utilise, un PCTV 73e, qui marche tres bien avec VideoStation J'utilise TS Doctor. Il est payant mais je ne regrette pas du tout mon investissement. Je n'ai pas d'iphone mais la version Androïd de DS Video, permet tout ça, j'imagine que la version IOS est similaire. A partir d'un PC suffit d'un simple navgateur pour se connecter à l'interface de VideoStation

J'ai un DS213j et je n'ai pas de probleme pour enregistrer les video, même en HD Et même je n'avais aucun probleme non plus avec mon DS210j précédent (je n'avais pas testé la HD sur celui-la par contre) Si le stick sait lire les chaines HD c'est oui Oui, avec le paquet video station Sous réserve d'avoir installé les bon codecs oui Le container est en .ts. Pour les formats j'ai analysé avec mediainfo deux enregistrements, un HD et un SD Le détail est ici: https://app.box.com/s/331gyxlg4snv0qthv9fd Oui pour la box, pour le WD je suppose aussi que c'est oui mais mieux attendre un propriétaire de cet appareil pour confirmation. Le seul problème que je rencontre est que les flux videotext (ceux qui contiennent les sous titres) ne sont pas enregistrés. Je ne suis pas parvenu a savoir si c'est un probleme de videostation ou de mon stick. J'ai posté à ce sujet dans le forum () mais le sujet n'a pas déchaîné l'enthousiasme des foules. A ce propos je découvre dans le résultat de mediainfo que les pistes de sous-titres sont bien présentes mais au format "DVB Subtitle" et pas videotext Va falloir creuser ça.

On peut rajouter pour la lecture de fichiers media (audio et video) toutes les applications compatible DLNA, comme par exemple et de façon non exaustive: BubbleUPNP, Archos Video Player, souvent aussi les lecteurs intégrés dans les surcouches constructeurs, et il doit y en avoir d'autre. Attention: DLNA est limité au réseau local (wifi donc).

Sur des postes windows me semble avoir constaté que "ping" n'utilisait pas la même résolution que d'autres commandes et que parfois ça ne marchait pas, à moins d'ajouter un "." final au nom de domaine. Vérifier (avec et sans le point): ping <host>.<domaine> ping <host>.<domaine>. nslookup <host>.<domaine> nslookup <host>.<domaine>. A priori, ajouter le "." final systématiquement semble être une solution, mais j'ai jamais eu le temps de bien cerner le truc et toutes les implications.

Ce que l'on met dans la config DHCP est celle qui est fournie au clients DHCP pour auto-configurer le serveur DNS qu'ils vont utiliser. Je suppose que tu parle de la liste d'ip entourée ci dessous: Pour que les clients DHCP se configurent pour utiliser le Syno comme relai DNS, il faut mettre l'IP du SYNO dans "DNS principal". On peux mettre un serveur de backup en secondaire (celui de son FAI) qui sera utilisé si le Syno est inaccessible provisoirement. De façon générale si on veut qu'un poste client utilise le service dnsmasq comme relai/cache DNS c'est sur le client qu'il faut configurer l'ip du Syno comme adresse de serveur DNS, ( à faire manuellement si on ne s'appuie pas sur l'auto configuration DHCP) et c'est sur le poste client qu'il faut faire les tests (ping ou autre). Le Syno, lui, continue à se référer au DNS externe.

Il y a déjà un fil sur le même sujet:

Pour comparer les caractéristiques de ces 3 modèles: http://www.synology.com/products/compare_spec.php?lang=fre&compare_list%5B%5D=DS213%2B&compare_list%5B%5D=DS213&compare_list%5B%5D=DS213j#compare_show_top

Tu veux dire qu’après la manip le process "synorcd" est *toujours* actif? J'ai du mal a comprendre comment c'est possible. Essaie de rebooter le NAS alors.

Voici l'étape que tu as loupée (il est vrai qu'on a oublié de l'indiquer explicitement): après avoir édité le fichier S96synorcd.sh faut arréter puis relancer le paquet Audiostation. Éventuellement en ligne de commande comme cela: /var/packages/AudioStation/target/scripts/S96synorcd.sh stop /var/packages/AudioStation/target/scripts/S96synorcd.sh start

En fait je n'ai pas plus d'info sur le fonctionnement de cette commande que l'aide en ligne que j'ai copié Faut expérimenter (me demande bien ce que font les arguments "--get" par exemple) Que le premier qui trouve de la doc la dessus poste ici, ça serait sympa.

Bien entendu, on ne propose pas de *tout* synchroniser. Quel que soit l'outil de synchro utilisé on peut choisir de ne synchroniser que certains dossiers bien identifiés.

Juste un truc: si l'idée est d'avoir une synchro de certains dossiers entre les deux NAS, peut être que la fonctionnalité "syncho de dossier partagé" de DSM est à envisager aussi. Je n'ai pas pratiqué le bidule, juste regardé l'aide en ligne. Cependant, au delà de 2 NAS à synchroniser j'ai l'impression que c'est moins trivial Voici ce que dit l'aide: "Synchro du dossier partagé est un service réseau qui permet aux utilisateurs de synchroniser des dossiers partagés entre DiskStations. À partir de DSM 4.1, Synchro du dossier partagé fournit la fonctionnalité Synchro du dossier partagé à source multiple, qui permet à plusieurs clients de synchroniser leurs dossiers partagés vers un DiskStation." A tester.

Étrange alors qu'apache n'ait pas redémarré lors du premier reboot après la mise à jour. Bon, le principal étant que maintenant ça marche.

Vérifie que le service web est bien activé alors, sinon au prochain reboot tu risque d'avoir le même gag:

En complément, sous DSM, les commandes à utiliser pour cela sont respectivement "synouser -add" et "synogroup -add" (dans /usr/syno/sbin/, à mettre dans le PATH sinon donner le chemin complet): fserv> synouser Copyright (c) 2003-2012 Synology Inc. All rights reserved. Usage: synouser (Version 3776) --help --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})} --enum {local|domain|ldap|all|domain_used} --enumpre {local|domain|all|domain_used} prefix Caseless{0|1} --enumsub {local|domain|all|domain_used} substr Caseless{0|1} --get username --getuid UID --add [username pwd "full name" expired{0|1} mail privilege] --modify username "full name" expired{0|1} mail --rename old_username new_username --setpw username newpasswd --del username1 username2 ... --login username pwd --dbopen2 username --filesetpw filename --create_homes {domain|ldap} fserv> synogroup Copyright (c) 2003-2012 Synology Inc. All rights reserved. Usage: synogroup (Version 3776) --help --rebuild {all|(domain Force{0|1})|(ldap Force{0|1})} --enum [{local|domain|ldap|all}] --enumpre {local|domain|all} prefix Caseless{0|1} --enumsub {local|domain|all} substr Caseless{0|1} --get groupname --getgid GID --descget groupname --descset groupname ["New Descritions"] --add groupname username1 username2 ... --rename old_groupname new_groupname --member groupname username1 username2 ... --del groupname1 groupname2 ... --dbopen2 groupname

La mise a jour DSM entraine un *reboot* du NAS. Donc je ne vois pas comment il a été possible que apache ne se relance pas!

Oui, enfin de la à parler de "trou béant" . D'autant plus que si les postes clients ne sont pas des antiquités, ce sont les methodes d'authentification les plus solides qui vont être négociées entres eux et le serveur samba de DSM. Ensuite, tous les protocoles de ce genre (voir NFS par exemple) ont des vulnérabilités qui sont corrigées en général assez rapidement Si il ne fallait utiliser que ceux n'ayant jamais eu de faille ne resterait plus que la remise via support externe de la main à la main. Par contre, je reconnais bien volontiers que CIFS n'est pas forcément le plus adapté aux acces de type WAN (NFS pas trop non plus d'ailleurs). Webdav me semble plus approprié et serait d'ailleurs possible en compilant et installant le module "davs" (ça a été abordé dans le forum) permettant faire un montage distant, mais AMHA ça reste de l'ordre du bricolage (d'autant plus que les informations d'authentifications sont fournies lors du mount et donc sont commune à tous les utilisateurs) Maintenant la question est, est-il vraiment utile que les Synos se voient entre eux? Si chaque poste client a directement accès aux différents NAS (en utilisant webdav pour les serveur distants) qu'apporte de plus l'acces inter NAS via filestation?