CoolRaoul

Pour ne pas poster dans cette section uniquement pour râler, je saisis l'occasion de dire que je me félicite de l'arrivée de l'édition en format source des messages (exit le bbcode, dommage, mais le html c'est déjà ça) Merci aussi pour le choix des languages des blocs code: Bon, c'est pas encore tout à fait ca, je constate que la colorisation est passée à la trappe: #!/bin/sh # Copyright (c) 2000-2010 Synology Inc. All rights reserved. # Configure routing # defaultrouter=$1 # Wait for a while until the network is ready sleep 10 if [ -d "/initrd" ]; then # If it's in junior mode /usr/syno/sbin/synonetdtool --refresh-gateway all fi case ${defaultrouter} in [Nn][Oo] | '') ;; *) echo "Add default router ${defaultrouter}" /bin/ip route add default via ${defaultrouter} ;; esac exit 0 mais on reste sur la bonne voie pour aboutir un jour à un forum qui retrouve toutes les fonction qu'il permettait auparavant.

Si vous avez utilisé un compte Gmail pour l'abonnement au forum, les notifs risquent de se voir classifiées en spam: Pensez à mettre une règle de type "whitelist"

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

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:

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)

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