CoolRaoul

Avec la double redirection ("> bidule" suivi de "2>&1") le fichier log contiendra l'intégralité des messages émis par ton script si c'est bien de ça qu'il s'agit.

Suffira d'ajouter la ligne "export ..." *dans* le script qui invoque mkvmerge

Sous unix il y a toujours *deux* sorties pour chaque process: la sortie standard (descripteur 1) et la sortie d'erreur (descripteur 2) la simple redirection (">" ou "1>") ne redirige que la première.

Tant qu'a faire, ajoute aussi la sortie d'erreur a ton log, ca sera mieux: remplacer 1>> log.txt par >>log.txt 2>&1 **edit** Autre chose, faudrait spécifier le chemin *complet* du fichier log, et le mieux est de faire ça *dans* le script en y ajoutant la ligne: exec >> /tmp/ftp_mirror.log 2>&1

Ca dépend ou se trouve la commande "lftp" sur ton NAS (ce n'est pas une commande standard DSM) Si c'est un package optware il y a de forte chances que ceci fonctionne: PATH=/opt/bin:/bin:/usr/bin

Il manque la ligne "PATH=" **edit** En cron, le shell n'exécute pas les profiles, se retrouve avec le PATH par défaut, et il ne peut pas deviner ou se trouve le binaire "lftp"

Tu as oublié de déclarer le PATH dans ton script

En ce qui concerne le reverse proxy, le témoignage d'un collègue ayant appliqué l'update indique n'avoir rien constaté d'anormal de son coté. Je pense que je vais bientôt me lancer aussi alors.

Certains packages ipkg (non encore installés) mettent certains de leur binaires dans "/opt/sbin" tu peux l'ajouter au PATH (ça ne mange pas de pain) mais inutile de créér le dossier, il le sera lorsque necessaire

Est-ce que ça fait pareil après avoir tapé: export LANG=C (inspiré de http://forum.synology.com/enu/viewtopic.php?f=40&t=36845&start=15)

Pour exécuter le bootstrap faut être loggé "root", pas "admin" (même mot de passe)

Dans le script, ajouter la ligne: exec > /tmp/mount_local.log 2>&1juste apres la ligne "#!". Redémarrer et aller voir dans le contenu du .log généré ce qui a coincé. Il est important que le nom du script se termine par ".sh" aussi (en tout cas c'est ce qui est indiqué par le README situé dans mon "/usr/local/etc/rc.d" (doit dater d'une ancienne version de DSM sans doute)

Pas exactement; il est juste mentionné l'erreur: Configuring optware-bootstrap.ipk...mount: mounting /volume1/@optware on /opt failed: No such file or directory je pense qu'un simple "mkdir /opt" préalable devrait résoudre le probleme

Ca ne serait pas "/volume1/startup" plutôt? J'utilise une autre approche désormais pour les scripts de démarrage (et d’arrêt d'ailleurs), dans "/usr/local/etc/rc.d". CF ici:

Question pertinente. J'avais testé haproxy il y a pas mal de temps et il répondait aussi à mon besoin, mais un jour il est parti en vrille (fuite mémoire probablement) et m'a planté mon NAS: plus aucun accès à distance et je n'étais pas chez moi pour réparer bien entendu. J'imagine que le produit s'est fiabilisé depuis mais cet incident m'a un peu fait perdre confiance (un peu ennuyeux dans le cas d'un outil utilisé dans le cader d'acces distant qui doit être d'une robustesse à toute épreuve). Inversement, le reverse proxy qui n'utilise que des composants natifs de DSM ne m'a jamais fait défaut. Lors d'une mise a jour DSM, pour retrouver ma conf reverse proxy je n'ai qu'une ligne à ajouter dans http-user.conf, c'est pas bien compliqué.

Juste.. Pour l'instant j'ai trouvé un unique retour (négatif). Un seul positif suffirait à me rassurer. Pas possible que *tous* les utilisateurs de reverse proxy choisissent de temporiser quand même!

Note: tu n'as pas précisé la version de DSM. Mais voici celui correspondant à la plus récente: https://app.box.com/s/3j1kzbjfz0zkcu8206ax (DS213j) Sinon, tous les fichiers originaux sont dans le ".pat" du firmware, téléchargeable sur le site syno, et ce dernier peut s'ouvrir avec 7Zip:

Raison de plus (en attendant d'avoir mis un place une solution 100% Syno en suivant les conseils de Bud) d'éviter cette double copie aller/retour. Dans le cas où les fichiers restent sur le NAS le temps de mux va être probablement du même ordre que celui d'une copie et par suite la durée totale de l'opération divisée par deux. Par contre ça justifie ton souhait de chercher un moyen de traiter les fichiers directement via des commandes sous DSM mais ce n'était pas ce point que je commentais. **edit** Je réalise à la réflexion que l'opération de mux à distance implique un flux réseau double (puisque il y a lectures *et* écritures ) ce qui relativise ma remarque. Le temps total de la manip, avec ou sans copie doit être similaire (faire les copies reste cependant probablement inutile mais sans gain de temps) Bon, cela dit fin de ma digression: vu l'architecture utilisée il va de soit qu'une solution 100% sur le NAS reste l'idéal dans le cas présent.

De mon coté je dois avouer ne pas même comprendre ta description du problème! Que constates-tu *exactement* et qu'appelles-tu "les permissions pour le compte Admin"?

A quoi peuvent bien servir ces copies? Il n'est pas nécessaire de déplacer les fichiers à traiter: mkvmerge windows n'a aucun problème pour traiter directement les fichiers situés dans des dossiers partagés du NAS.

De mon coté je temporise, au moins le temps d'avoir le cœur net au sujet des problèmes signalé sur le reverse proxy.

oui oui oui

Apache

J'imagine qu'il s'agit du du service telnet est activé lors d'une mise a jour du NAS (pour débugger une update qui coince) En effet, Il n'y à rien en écoute du port telnet (23) sur mon NAS: fserv> netstat -nptl | grep :23 <rien ici> Pour comparaison, la meme commande sur le port 22 (ssh) : fserv> netstat -nptl | grep :22 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 27200/sshd tcp 0 0 ::%22:22 :::* LISTEN 27200/sshd Mais de toutes les façons, tant qu'on n'a pas fait de redirection dans le routeur vers le port 23 du NAS, telnet ne serait accessible que de l'intérieur (réseau local)

Beaucoup (sinon tous) ne la voient pas (encore): dans ce cas on peut faire la mise à jour en téléchargement directement le ".pat" pour son NAS à partir du site de téléchargement