CoolRaoul

presence Voir le fichier Script Perl (package Perl Synology requis) de détection de présence. Tient à jour un fichier TSV des connexions/déconnexions (date/heure, nom, on|off) de différents équipements IP. Le format du fichier trace est adapté pour être facilement incorporé dans un tableur. Configuration: Créer un fichier de lignes de la forme <IP><espace><nom> (type "/etc/hosts"). Chemin par défaut, si non spécifié: "/etc/presence.conf" Les espaces pour "<nom>" sont supportés mais pas recommandés. Lancement: <chemin>/presence -d <parametres> Paramétres: -v: augmente la verbosité -d: se détache pour tourner en mode "démon" (pour tester en mode "normal", lancer avec "-v" et sans "-d") -w <n>: timeout des pings en secondes (défaut: -w 2) -c <n> : nombre de pings (défaut: -c 2) -i : intervalle en secondes entre les pings par appareil (défaut: -i 60) -D <répertoire> : chemin du répertoire contenant les fichiers d'état des équipements (défaut: "/var/run/presence.d") -H <chemin et nom fichier trace> : nom du fichier trace au format TSV. Défaut: "/site/var/log/presence-%Y-%m.tsv" (supporte les macros telles que documentées ici: posix strftime). Ce fichier n'est pas maintenu ouvert en permanence mais uniquement une fois par cycle (paramètre "-i") -C <chemin fichier conf> : chemin fichier de configuration au format /etc/hosts, défaut : "/site/etc/presence.conf" Compléments: URL pour acces direct au script: http://pastebin.com/VhTMvm6a Ne pas hésiter à me contacter pour toute suggestion d'améliorations, demande d'infos complémentaires ou ou signaler un dysfonctionnement. Contributeur CoolRaoul Soumis 22/01/2016 Catégorie Créations de nos membres

Ma confusion venait du fait que mon NAS n'étant pas assez puissant pour faire du transcodage, je n'ai pas les options de correspondantes dans le serveur multimedia pas plus que dans DSVideo: Mais même avec cette config, les videos avec piste son AC3 sont bien lue par MX player, pour peu d'avoir installé le codec complémentaire **EDIT** Ca fonctionne également avec Archos Video Player complété par "All codecs for Archos Video" (beaucoup moins bien qu'avec MX faut reconnaître)

DSVideo ne lit pas lui même les videos, il s'appuie sur un lecteur tiers que tu choisis au moment de la lecture avec un menu ("ouvrir avec") Si tu n'a plus ce menu de choix c'est que tu y as sélectionné "toujours" à un moment ou autre. Tout ça pour dire que le probleme n'est ni côté NAS ni côté DSVideo. Essaie d'installer un autre lecteur video sur le smartphone (MXplayer ou VLC par exemple)

Pas uniquement, ça peut également être scp, sftp, rsync, ou également une sauvegarde via rsync de nas à nas (comme je l'ai évoqué plus haut) **EDIT** Et même un dossier distant sftp déclaré dans filestation (mais je ne sais pas si ça se connecte au démarrage)

Sous réserve de la disponibilité de l'adaptateur. Cela dit il n'y a aucune raison que ça ne fasse pas l'affaire en WIFI qui est son mode de fonctionnement natif. Tu confond avec la Chromecast originale (et sa nouvelle version 2015) qui est orienté video. La Chromecast Audio est un autre modèle, exclusivement dédié à l'audio. Et d'ailleurs, cette dernière dispose uniquement de sorties audio : (Nb seul le cable analogique est fourni, le cable optique doit être acheté séparément) Tout à fait. Il faut également savoir que le mode de fonctionnement fait que la Chromecast, même piloté par DSAudio (ou Google music) va streamer directement de façon autonome à partir du NAS via le réseau. Une fois la liste de lecture activée, plus besoin de laisser tourner DSAudio sur le téléphone. (et même si tu as plusieurs Chromecast dans différentes pieces, chacune peut streamer un flux différent simultanément) Vu la différence de coût ridicule (un simple cable) autant connecter la Chromecast sur une entrée optique numérique de l'ampli. Mais je n'ai aucune idée si la différence de rendu sera perceptible. Tu trouvera les différentes connectiques possible ici ("Câbles et branchements compatibles")

Pas uniquement, la présence d'un port optique toslink montre que les deux usages sont prévus. Consultes les tests du produit pour voir les usages possibles. C'est exact elle fonctionne en wifi. Ca ne fait pas l'affaire? (pour juste de l'audio, même en HD 24 bits, pas besoin d'une bande passante extraordinaire) Par contre un adaptateur ethernet est prévu : http://www.frandroid.com/marques/google/294545_google-va-bientot-vendre-adaptateur-ethernet-chromecast Je ne sais pas ou on en est de sa commercialisation.

Et pourquoi pas une Chromecast Audio connectée sur une entrée ligne ou optique de l'ampli? Semblerait que ça fonctionne avec DS Audio: http://forum.synology.com/enu/viewtopic.php?f=216&t=105339#p400694

Probablement pas exhaustif: /usr/syno/etc/rc.d/* /usr/local/etc/rc.d/* /var/packages/*/scripts/start-stop-status

Déjà, puisque ton script ne fait pas d'erreur (vu que son .log est vide) on peut déduire que le blocage est causé par quelque chose qui est déclenché *plus tard* dans la phase de démarrage. Donc à priori ne s'agit pas d'un script système. Assure-toi également, d'apres le timestamp du blocage, que c'est bien lié au démarrage et pas quelque chose de récurrent (en cron ou gestionnaire de taches par exemple: n'aurais-tu pas mis en place des sauvegardes automatiques croisées de NAS à NAS en rsync dont l'authentification ne marcherait plus?) A part ça, et surtout à distance, je n'ai pas d'autre idée.

Si le serveur bloquait effectivement ces commandes ssh-là, elles échoueraient et des erreurs émises par ces dernières s'afficheraient dans le .log. Le blocage doit être provoqué par autre chose. Sur le serveur cible, dans panneau de configuration -> "sécurité" -> "blocage auto" -> "autoriser/bloquer la liste" -> "liste des blocages" tu peux voir l'heure ou le blocage est intervenu. Vérifie que si ca coincide ou pas avec l'heure de démarrage du NAS source. Essaie aussi quand même d'ajouter la commande "set -x" juste apres la ligne "exec ..." dans S99remets.sh. Ca ajoutera au log une trace d'éxécution commande par commande qui pourrait t'aider à comprendre ce qui ce passe.

Si L'IP est bloquée c'est que le script a provoqué des erreurs d'authentification sur la cible. Suffit de corriger ces erreurs et plus de blocage. Hypothèse (à vérifier): quand il est lancé au démarrage ton script ne "voit" pas la clé privé. Modifie-le en ajoutant une log (en ajoutant pres du début "exec >/tmp/monscript.log 2>&1"), reboote le NAS et jette un oeil au contenu du fichier log.

Et même sans ça, tu peux maintenant supprimer la redirection du port 4200 dans le routeur, devenue inutile.

Si tu peux te connecter ainsi (direct sur le port 7200) *de l'extérieur* c'est qu'efffectivement tu as loupé ma preco précédente ou je disais de laisser shellinabox écouter uniquement sur "localhost". Ça se fait par modification de sa ligne de commande (j'ai pas la syntaxe en tête là, suis à l'extérieur sur mon téléphone)

Ben, le premier script kiddie qui fait un scan de port sur ton IP publique va voir le port 4200 ouvert, si il tente une connexion au petit bonheur la chance, va tomber sur le prompt "Username:" et ça va lui donner l'envie de chercher à entrer (remarque en SSL tu ne serais pas plus protégé). Et comme le login shellinabox n'est pas pris en compte par le blocage auto il va pouvoir essayer tant qu'il veux et aussi longtemps qu'il veux. Avec un reverse proxy, faut déjà connaitre l'url de sous-domaine pour arriver à la connexion (sans oublier la possibilité de filtrage amont que j'ai évoqué).

Ca risque de devenir un peu complexe, jette un oeuil à mon tuto sur la conf reverse proxy par Nginx et a toi de voir si tu te sens de faire la manip. Y a aussi la possibilité d'utiliser le package Haproxy (y a un tuto pour ça aussi). A toi de voir.

Pas la peine, le but était de voir si un flux passait ou pas Tu peux lancer maintenant un demon sshd en premier plan sur un port dédié (faut qu'il soit ouvert dans le bon sens entre les deux sites) pour avoir des diags directement à l'écran. Comme cela: /usr/syno/sbin/sshd -p 9999 -d et coté client , tu te connectes en ajoutant "-p 9999" à ta ligne de commande ssh. A noter que lancé comme cela le sshd ne vas traiter qu'une seule session et mourir ensuite. (choisir ce qui t'arrange pour le numéro de port à la place de 9999)

Le numéro du port importe peu, de toutes façons on peut choisir ce qu'on veut en ligne de commande. Si tu fait allusion au mode "en clair" (pas de https) suffit, comme j'ai dit, de le laisser écouter exclusivement sur localhost et y accéder via un reverse proxy qui s'occupera du SSL (c'est ma configuration perso, j'utilise nginx pour ça). Possible d'ajouter des règles de filtrage supplémentaire dans la conf proxy (via proxy_pass, allow et deny) pour serrer les boulons.

Essayer d'ajouter "--disable-ssl" en argument de la commande "configure" Compiler sans SSL et le mettre en écoute sur localhost et laisser un reverse proxy s'occuper du https

Tous les syno ont un firewall intégré, j'imagine que tu veux plutot dire que tu ne l'as pas activé alors. Ouvre une fenêtre shell sur le nas principal (de site A) dans celle-ci exécuter:: /usr/sbin/tcpdump host <ip_de_nas_maison> and port 22 tenter une connexion à partir de "Nas Maison", flux orange si on ne voit rien passer dans la fenêtre dans laquelle tourne le tcpdump c'est que ça bloque quelque part au niveau réseau, y a pas à tortiller. Et alors on saura que la cause n'est pas pas due à un problème de clés SSH. PS: as tu tenté une connexion sans clé, par mot de passe?

Alors la je ne comprend plus.. Firewall qui bloque?

Faudrait faire le "grep ..." apres avoir retenté une connexion

Ah oui, j'oubliais, par défaut la config syslog-ng DSM filtre les logs sshd (pfff.. j'te jure ...) Faut appliquer mon correctif donné ici; http://forum.synology.com/enu/viewtopic.php?f=39&t=74141#p284002 et redémarrer la partie ssh serveur.

essayer "grep sshd /var/log/messages | tail "

En mode verbose >= 3 c'est une erreur normale, CF ici, le commentaire de "Kenster" daté Jul 20 '14 at 19:38: "FWIW, the "unknown key type '-----BEGIN'" message and the ones following it aren't error messages. ssh is just checking to see if the key file is in a particular format, and it's being verbose because you asked it to be verbose. " Faudrait plutot regarder les logs coté serveur. (vérifier les droits de ~/.ssh du compte cible par exemple)

Pour ajouter mon grain de sel, je serai très circonspect sur l'opportunité d'utiliser Optware, projet en quasi hibernation quasiment depuis 3 ans, et encéphalogramme plat depuis bientôt deux (Ref: "Optware is DEAD as of MAY 2014") A la limite (mais ça reste sans garantie ni support de ma part) autant partir sur le projet alternatif basé sur Entware qu'un quidam à eu le courage de prendre en main (voir fil du forum anglophone ici) Reste qu'on n'a pas beaucoup plus de garantie sur la pérennité du bidule