CoolRaoul

"login incorrect" signifie que le mot de passe n'est pas le bon. Re-actives le compte admin "officiel" dans l'interface DSM et affecte lui un mot de passe. Tu pourra alors de connecter "root" en ssh en utilisant le mot de passe que tu as choisi ci dessus. ***EDIT*** Le mot de passe "root" est automatiquement synchronisé avec celui du compte "admin", mais bien entendu pas celui de adminXXX, quelle que soit la valeur de XXX.

Tu a essayé de te connecter sur le compte "admin" Par défaut, sous DSM < 6, seul le comte root peut se connecter (et ca explique ton pb en ssh) (PS: désolé pour les lignes vides en extra dans les citations, c'est un nouveau gag de l'éditeur de message du forum ...)

Ah c'est malin! Tout le monde connait ton mot de passe maintenant

Je ne pense pas: quand on se retrouve avec son IP blacklistée par l'autoblock me semble bien qu'on n'a plus de connexion du tout (ca sort en timeout) et pas de message explicite comme ici ("Permission denied, please try again") et bien entendu pas possible de se connecter sur l'interface WEB non plus (NB: "Le mot de passe est bon puisque j'arrive à me connecté au Web Admin.")

Dans cette situation j’essaierai de me connecter en telnet pour aller voir ce que racontent les logs.

Panneau de configuration DSM -> "Indexation Multimedia" -> "Créer" Nom: "Video" Dossier: cliquer sur bouton "sélectionner" pour naviguer au dossier racine des videos (à priori "vidéo") Type de fichier: cocher uniquement "Video" Si le dossier est *déjà* déclaré comme dossier indexé, faire "modifier" et s'assurer que dans "Type de ficher" video est bien coché.

J'ai probablement mal expliqué à quoi je pense en parlant de "copie de sauvegarde" Prenons l'exemple d'un tutorial tel que celui-ci: Reverse Proxy Avec Nginx Avant d'arriver à sa version définitive, je l'ai modifié à plusieurs reprise (CF "historique des versions" à la fin). A chaque fois que j'entreprenais une modif, je commençais par faire un copier/coller du texte "brut" (et c'est à cela que je faisais allusion en parlant de sauvegarde), pour pouvoir instantanément revenir en arrière au cas ou j'aurais fait une fausse manip avec l'éditeur "rich text", ce dont on n'est jamais à l'abro. D'ailleurs j'espère ne pas avoir à y faire une nouvelle modif car il contient entre autre un bloc "code" (et d'ailleurs je vous engage à aller voir à quoi ressemble désormais ce post sous Tapatalk, c'est devenu absolument illisible et donc inexploitable que j'ai honte que mon pseudo y soit associé. Extrait: Autre exemple, lors de la réponse à un post avec plusieurs citations imbriquées, le mode "texte brut" est d'un maniement autrement pus rapide et efficace pour éditer, splitter en deux, une citation (en pratique pour ce dernier cas, je n'ai toujours pas trouvé comment le faire sans coup férir dans le nouvelle interface). J'avais même des macros clavier pour ça qui me faisaient gagner un temps fou. Naïvement je pensais qu'avec une évolution d'un outil (comme IPB ici) on était en droit à s'attendre essentiellement à des améliorations. Jusqu'ici je ne rencontre essentiellement que des régressions voire des fonctionnalités apparemment carrément supprimées. En conclusion: doit-on il faire définitivement une croix sur l'édition en texte brut et au choix "shell" dans les blocs "code"? Si la réponse est positive faudra plus compter sur moi à l'avenir pour pondre des tutos dans le style de celui que j'ai cité en référence (et j'en suis vraiment désolé).

Je commencerai par un petit "up" sur un problème toujours présent: choix des languages dans le menu d'insertion de code presque trois mois s'étant écoulés depuis son signalement (fin octobre dernier). Au cette occasion je profite pour rappeler qu'on a toujours pas retrouvé l'édition en texte brut (avec bbcode), ce qui rend impossible la copie de sauvegarde "propre" d'un post (indispensable pour un tutoriel un peu long et au formattage un minimum chiadé). Egalement, le probleme d'édition des messages sous Tapatalk est toujours là (html au lieu de bbcode, ajout intempestif de paragraphes supplémentaires (balises "p") à chaque édition d'un post. (apparemment sans impact sur le format cependant) . Enfin, il y a aussi le style "liste a puces" qui passe bien en mode Web et qu'on retrouve sous forme de hiéroglyphes sous Tapatalk:

Soyons indulgent: il s'agit juste d'un de ses principaux critères de choix du NAS, pas la chose la plus importante dans l'absolu . Et pour répondre à la question, dans la mesure ou le domaine QuickConnect.to n'est pas bloqué par le firewall, l'option quickconnect pourrait répondre au besoin sans la moindre complexité technique (utilise les ports http standard). Sans oublier quand même, que ce soit ou boulot ou ailleurs, qu'il sera toujours possible (sous réserve de couverture réseau bien entendu) d'accéder également à son NAS via son téléphone mobile

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)