CoolRaoul

Ok, a suivre donc

Bon je reprend posément: lors de ton 1er message tu nous disais "Ce script fonctionne en ssh" Tu l'avais lancé de quelle façon quand il a fonctionné à ce moment-là?. (ou bien doit-on conclure qui'il n'a *jamais* marché?)

Ceci est une réponse à quelle question? **EDIT** « La réponse est oui. Mais quelle était la question ? » (Woody Allen)

Et quelle syntaxe utilises-tu quand ca fonctionne alors (comme indiqué dans ton 1er message)?

Nous voila peu avancés alors Dernier essai et apres je sèche (faudra attendre qu'un spécialiste python passe par ici) En ligne de commande, en lançant le script de cette façon: env - /volume1/Scripts/Wol2PC.py est-ce que ça fonctionne aussi?

Décidément que de problemes avec ces dvico! Si un jour je change ma passerelle multimedia je saurai ce qu'il ne faut pas acheter

La ça ressemble à un bug par contre

Solution:

Le scripts lancé par le gestionnaires de taches (en en détaché en général comme au boot par exemple) n'ont pas le meme environnement que les shells interactifs. Ils n'exécutent ni "/etc/profile" ni "~/.profile" *toujours* mettre la ligne "PATH=" correcte dans un script qui utilise des commandes situées ailleurs que dans les chemins standard ("/bin" et "/usr/bin")

Autre piste pour comprendre, ajoute dans le planificateur de taches, dans le champ de formulaire titré "exécuter la commande",au dessus de ta commande de script une ligne ce ce type: exec >/tmp/monscript.log 2>&1 Ce qui va donner ceci: Tu forces l'exécution du script via le planificateur (bouton "exécuter") et le contenu de "/tmp/monscript.log" devrait te permettre de comprendre la cause de l'erreur

Ben, la syntaxe n'est pas bonne: (le message d'erreur aurait du te mettre sur la voie)Comme tu aurais du le constater sur l'exemple du site Syno, Il ne faut pas de "/" apres "::" Si tu veux apprendre de tes erreurs, quand ça ne marche pas, comme ici, faut essayer de comprendre pourquoi en analysant le message que produit la commande et ensuite de corriger.Essayer au petit bonheur la chance d'ajouter un "/" par ici ou un "" par la est en général moins efficace.

Et le message d'erreur était ? (mais si tu n'a plus besoin d'aide tu peux le dire, je ne me vexerai pas )

C'est bien ce qui me semblait: tu n'as apparemment jamais utilisé la syntaxe préconisée par Synology (avec le double ":" suivi du nom de module). Pourquoi?

Si tu veux qu'on t'aide, faut donner systématiquement les commandes essayées *et* le message d'erreur constaté (sauf dans les cas ou le message d'erreur te permet de comprendre par toi même quelle est l'erreur) En tout cas si la doc en ligne Syno dit qu'il faut spécifier explicitement le module NetBackup dans la commande rsync, tous tes tests faits avec des commandes qui ne le spécifient pas était inutiles AMHA.

dans le planificateur, le champ de formulaire "script défini par l'utilisateur" est multiligne. Suffit donc de remplacer /volume1/Scripts/Wol2PC.py par (une commande par ligne): exec >/tmp/wol.log 2>&1 /volume1/Scripts/Wol2PC.py ce qui permettra de voir dans "/tmp/wol.log" ce qui coince

Je me suis permis de citer ce lien car on peut y lire: Et d'apres ce que j'ai vu dans les messages précédent, ne me semble pas que cette syntaxe-là ait été testée (root@<IP>::NetBackup/<chemin>/)

Comment migrer entre DiskStations Synology

Je pense que cette faq pourrait être utile pour la bonne syntaxe à utiliser pour la commande "rsync": Pourquoi ne puis-je pas effectuer de sauvegarde depuis un serveur compatible rsync vers un produit Synology ?

L'installation d'optware ne modifie que peu de choses sur la partition système (L'essentiel est dans le répertoire /volume1/@optware, préservé lors de la mise a jour): /etc/profile: préservé lors de la mise a jour (modification du PATH pour le compte root) /root/.profile: écrasé lors de la mise a jour (suffit de le sauvegarder) /etc/rc.local: "mount" de /opt -> /volume1/@optware et startup optware. (je crois qu'il est aussi préservé) Dans tous les cas, les manips a faire pour tout remettre d'équerre sont expliquées ici.

Faut comprendre Synology, installer des outils clients sur un NAS (dont la fonction est plutot de serveur) n'est pas une priorité. Pour un backup distant, tu devrais etudier l'option rsync (c'est natif sous DSM)

Le bootstrap semble avoir détecté une installation précédente d'optware ("optware" que d'aucuns persistent à appeler "ipkg", un peu comme si pour RedHat ou Fedora on utilisait le nom de "rpm") Pas besoin de rebooter, suffit de faire un "umount /opt" (ne pas s'inquiéter si erreur) puis les 2 commandes "rm" indiquées (pas d'inquiétude non plus, ça ne supprime qu'optware) et recommencer

Tu aurais pu remarquer que j'avais évoqué cette option : J'ai préféré aller à plus simple dans un premier temps. En outre, je pense qu'il pourrait se rendre compte rapidement à l'usage qu'il n'a pas besoin de synchro en fait et pourrait se satisfaire d'un seul dossier photo sur le NAS monté en NFS. Ainsi le montage serait déjà opérationnel

D'apres ce que j'ai vu on est *obligé* de faire comme ça. Comment t'y es-tu pris de ton coté pour que les deux comptes aient accès à l'application?

Pour cela faudrait que mod_auth_pam soit intégré a l'apache de DSM Ce n'est pas le cas et comme ce bidule n'est plus maintenu, il y a peu d'espoir Voir ici: http://pam.sourceforge.net/mod_auth_pam/index.html

(Ca ne va pas t'aider, je sais) J'ai voulu reproduire ta config sur un XP virtualisé et, à cette occasion, me suis aperçu que: Sous Windows, Il n'était pas possible d'installer CloudStation globalement: une instance par compte (faut l'installer sur chaque compte) Pas possible de choisir le dossier d'installation (forcé à %USERPROFILE%Local SettingsApplication DataCloudStation) pas possible de l'installer sur un compte non administrateur Ca fait beaucoup de contraintes Déçu je suis...