Aller au contenu

Transferts De Fichiers Entre Deux Syno


Messages recommandés

  • Réponses 67
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

J'aimerais bien que tu lises, que tu appliques et donne le résultat des indications qu'on te donne. Tu as en plus les réponses et tu reposes les mêmes questions, plus des nouvelles.

Pour la crontab : sur un unix normal, chaque utilisateur à la sienne. Sur le syno, je ne crois pas que ce soit le cas. Mais rien n'empêche de mettre les commandes de tous les utilisateurs dans la crontab système (/etc/crontab). Ça fonctionne très bien comme ça. La seule différence, c'est que la crontab ne peut être modifiée que par l'admin alors que les crontab utilisateur, sur un système linux normal, peuvent l'être par leur propriétaire.

Pour ton problème :

donne le contenu de ton script /var/services/homes/noisy/bin/Transfic.sh

(dernière chance)

Entre temps je suis allé sur ce site :

http://blog.spikesou...com/crontab.htm

Résultats :

1) Environnement crontab =

SH_CLIENT=192.168.1.6 49603 22

USER=root

MAIL=/var/mail/root

OLDPWD=/

HOME=/root

SSH_TTY=/dev/ttyp0

PAGER=more

LOGNAME=root

TERM=xterm

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/syno/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin

SHELL=/bin/sh

PWD=/root

SSH_CONNECTION=192.168.1.6 49603 192.168.1.11 22

TZ=CET-1CEST,M3.5.0,M10.5.0/3

PGDATA=/volume1/@database/pgsql

Je suis étonné des redondances dans PATH, est-ce normal ?

2) Environnement user :

SSH_CLIENT=192.168.1.6 50750 22

USER=noisy

MAIL=/var/mail/noisy

HOME=/root

SSH_TTY=/dev/ttyp1

PAGER=more

LOGNAME=noisy

TERM=xterm

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/syno/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin

SHELL=/bin/ash

PWD=/volume1/homes/noisy

SSH_CONNECTION=192.168.1.6 50750 192.168.1.11 22

PGDATA=/volume1/@database/pgsql

#!/bin/ash

# ============================================

#

DATEDeb=$(date +%d-%m-%Y" "%Hh%M)

echo $DATEDeb > /volume1/Transfic/Transfic.log

# Transfert du repertoire

/usr/syno/bin/rsync -avz /volume1/Transfic/ noisy@IPdistant:/volume1/jp/Transfic

# tests codes retour

status=$?

if [ $status -ne 0 ]

then echo 'code retour = ' $status >>/volume1/Transfic/Transfic.log

else echo 'Transferts reussis' >>/volume1/Transfic/Transfic.log

fi

# ecriture du fichier log

DATEFin=$(date +%d-%m-%Y" "%Hh%M)

echo $DATEFin >>/volume1/Transfic/Transfic.log

Note : le user noisy est le même sur les deux synos ...

Quelles sont les variables à faire évoluer au sein du fichier crontab ?

Que vois-tu comme modifs dans le script ?

J'ai peut-être commis une erreur ou oublié quelque chose ... (je débute sur syno et linux ...)

On pourrait peut-être poser le pb aux ingénieurs Synology car sur le forum je n'ai pas vu quelqu'un utiliser crontab avec un user hors root ???

S'il y a des restrictions sur le sujet par rapport à un linux normal ils devraient recadrer le sujet en fonction du besoin non ?

Cordialement

JP

Lien vers le commentaire
Partager sur d’autres sites

OK pour l'environnement et le script.

Ça devrait fonctionner. J'ai déjà fait un test sur le syno d'une commande lancée en tant qu'utilisateur dans la crontab, et ça fonctionne (ils'agissait d'une commande nail).

A mon humble avis oui car lorsque je passe par crontab le script se déroule car il génère le log mais avec un code retour à 255 derrière l'appel à rsync au lieu d'un contenu complet des transferts.

Le seul truc que je vois c'est l'absence de variable sur le pays (voir mon exemple dans un post précédent).

Désolé pas trouvé ...

Tu es sûr que la clé publique a bien été copiée sur le serveur distant ?

Pour moi oui à partir du moment où le script fonctionne hors crontab cad lancement du script en manuel les fichiers se transmettent sans demande de mot de passe et je suis bien sous ssh port 22 syno distant (rsync 873 n'y est pas ouvert)...

- Donne le résultat de la commande lancée à la main.

14-09-2009 00h42

sending incremental file list

./

Transfic.log

sent 1554 bytes received 47 bytes 457.43 bytes/sec

total size is 26363290 speedup is 16466.76

transferts reussis

14-09-2009 00h43

- Essaie de lancer directement le rsync dans la crontab

#minute hour mday month wday who command

7 1 * * * noisy /usr/syno/bin/rsync -avz /volume1/Transfic/noisy@IPadresse:/volume1/jp/Transfic >/volume1/Transfic/Transfic.log

Sans effet, sauf génération de log à vide .

- redirige la sortie d'erreur sur la sortie standard et envoie dans le log (après ta commande rsync dans le script tu mets 2>&1 >>tonfichierlog

J'ai fait celà un dans le script lancé par crontab:

/usr/syno/bin/rsync -avz /volume1/Transfic/noisy@IPadresse:/volume1/jp/Transfic 2>&1 >>/volume1/Transfic/Transfic.log

Résultat :

14-09-2009 01h32

code retour = 255

14-09-2009 01h32

Les heures de début et de fin sont dans le log mais rsync génère le code 255 ....

Autre test :

J'ai modifié le script pour faire une synchro entre deux sous répertoire de Transfic sur mon syno, celà fonctionne ....

mais qu'en penser ce n'est surement pas significatif.

Je t'avais fait part de mon étonnement sur le nombre de chemins redondants dans l'environnement de crontab : est-ce normal ?

JP

Lien vers le commentaire
Partager sur d’autres sites

A mon humble avis oui car lorsque je passe par crontab le script se déroule car il génère le log mais avec un code retour à 255 derrière l'appel à rsync au lieu d'un contenu complet des transferts.

Désolé pas trouvé ...

- soit définir un environnement dans le fichier crontab (exemple sur une machine linux normale)


SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=""

HOME=/

HOSTNAME=MonServeurÀMoi

LANG=fr_FR

Pour moi oui à partir du moment où le script fonctionne hors crontab cad lancement du script en manuel les fichiers se transmettent sans demande de mot de passe et je suis bien sous ssh port 22 syno distant (rsync 873 n'y est pas ouvert)...

OK

#minute hour mday month wday who command

7 1 * * * noisy /usr/syno/bin/rsync -avz /volume1/Transfic/noisy@IPadresse:/volume1/jp/Transfic >/volume1/Transfic/Transfic.log

Sans effet, sauf génération de log à vide .

tu es bien sûr que le compte noisy a les droits de lecture locale et d'écriture distante ? (je penche pour un problème de droits sur le répertoire source)

as-tu fait un test direct (pas dans crontab) avec l'utilisateur noisy ?

Autre test :

J'ai modifié le script pour faire une synchro entre deux sous répertoire de Transfic sur mon syno, celà fonctionne ....

mais qu'en penser ce n'est surement pas significatif.

si (pb de droits).

Donne un ls -la /volume1/Transfic/

Je t'avais fait part de mon étonnement sur le nombre de chemins redondants dans l'environnement de crontab : est-ce normal ?

non, mais pas génant

Lien vers le commentaire
Partager sur d’autres sites

- soit définir un environnement dans le fichier crontab (exemple sur une machine linux normale)

Si je mets ne serait-ce qu'un SHELL=/bin/sh devant la ligne de commande ou les titres de colonnes plus rien ne se passe !

#minute hour mday month wday who command

SHELL=/bin/sh

42 1 * * * noisy sh /var/services/homes/noisy/bin /Transfic.sh>/volume1/Transfic/cron.log

que je le mette en première ou deuxième ligne idem .

Mais ce que je fais n'est peut-être pas correct ...

UNIX standard celà marcherait ?

as-tu fait un test direct (pas dans crontab) avec l'utilisateur noisy ?

/usr/syno/bin/rsync -avz /volume1/Transfic/noisy@IPadresse:/volume1/jp/Transfic > /volume1/Transfic.log

Pas de problème, fait à partir de user noisy c'est tout bon.

Donne un ls -la /volume1/Transfic/

Monserveuramoi> ls -la /volume1/Transfic

drwxrwxrwx 5 noisy users 4096 Sep 14 23:12 .

drwxrwxrwx 17 root root 4096 Sep 14 23:24 ..

drwxrwxrwx 8 noisy users 4096 Sep 3 09:44 @eaDir

-rwxrwxrwx 1 noisy users 697999 Sep 2 18:38 Fiche produit PEEKBOX 300.jpg

-rw-rw-rw- 1 noisy users 980672 Sep 1 00:08 IM000631.JPG

-rwxrwxrwx 1 noisy users 300631 Sep 2 18:45 LePoint260309 Peekton Peekbox300.pdf

-rwxrwxrwx 1 noisy users 18262950 Sep 2 18:37 Manuel PEEKBOX 300.pdf

-rwxrwxrwx 1 noisy users 844702 Sep 2 18:39 Note technique complémentaire PEEKBOX 300.pdf

-rwxrwxrwx 1 noisy users 2485506 Sep 2 18:46 Tele Satellite HS Peekbox 300 010709.pdf

- .....

Par contre en appel sh par crontab et user noisy sans autre paramétrage et en ajoutant un log indépendant pour crontab j'ai le contenu suivant :

Permission denied, please try again.

Permission denied, please try again.

Permission denied (publickey,password,keyboard-interactive).

rsync: connection unexpectedly closed (0 bytes received so far) [sender]

rsync error: unexplained error (code 255) at io.c(633) [sender=3.0.4]

Ce log est dans le même répertoire que l'autre ...

Ca va peut-être commencer à s'éclaircir ...

Dur dur quand même ..

JP

Lien vers le commentaire
Partager sur d’autres sites

Si je mets ne serait-ce qu'un SHELL=/bin/sh devant la ligne de commande ou les titres de colonnes plus rien ne se passe !

#minute hour mday month wday who command

SHELL=/bin/sh

42 1 * * * noisy sh /var/services/homes/noisy/bin /Transfic.sh>/volume1/Transfic/cron.log

que je le mette en premi

Lien vers le commentaire
Partager sur d’autres sites

  • 4 semaines après...

Pilotage des échanges par le seul syno local :

- Création de deux sous-répertoires /Emis et /Recus dans le répertoire /Transfic tant sur le syno local que sur le syno distant

Dans le même script :

- première étape : envoyer les fichiers du répertoire /Emis du syno local vers le répertoire /Recus du syno distant

- deuxième étape : récupérer les fichiers du répertoire /Emis du syno distant vers le répertoire /Recus du syno local

Ajout du paramètre --remove-sent-files a chaque ligne de commande rsync pour purger les fichiers après transmission.

Chacun s'occupant de vider son répertoire /Recus après utilisation.

Il reste néanmoins que les sous-répertoires éventuellement créés sous /Emis, bien qu'étant vides de fichiers subsistent.... à vide !

JP

--force : force deletion of directories even if not empty

Lien vers le commentaire
Partager sur d’autres sites

--force : force deletion of directories even if not empty

J'ai essayé ce paramètre sans succès.

Auparavant, compte-tenu que les fichiers échangés sont rangés en sous répertoires, j'ai mis dans les options :

/usr/syno/bin/rsync -avrz --remove-sent-files ......

-r pour récupérer les sous-répertoires avec leurs fichiers

--remove-sent-files pour effecer les fichiers émis

Ceci fonctionne bien.

Devant l'insuccès de --force je suis allé sur le site :

http://samba.anu.edu...sync/rsync.html

J'ai trouvé ce texte :

--force This option tells rsync to delete a non-empty directory when it is to be replaced by a non-directory. This is only relevant if deletions are not active (see --delete for details).

Note for older rsync versions: --force used to still be required when using --delete-after, and it used to be non-functional unless the --recursive option was also enabled.

Il y aurait donc des évolutions ..

J'ai essayé en supprimant -r sans effet !

Mon DS109J a la version :

rsync version 3.0.4 protocol version 30

Je ne traduis pas de cette notice comment effacer les répertoires vides après émission (peut-être mon niveau d'anglais ..),

me suis-je fourvoyé quelque part ?

JP

Lien vers le commentaire
Partager sur d’autres sites

  • 3 semaines après...

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.


×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.