Problème crontab / script

Support Debian
#1

Bonjour à tous,

Ca fait un moment que je cherche, sans résultat, voici mon problème.

Je dois copier des données d’un serveur A vers un serveur B, dont les clés rsa ont été installées entre eux, donc pas de demande de mot de passe ou de confirmation de quoique ce soit.
Je fais mon script, je le lance, ca marche, je suis content, je le mets dans la crontab.
Le lendemain, je me rends compte qu’il n’a pas fonctionné.
Je réduis mon script à une simple création basique distante de fichier. (ssh A ‘touch fichier’) ou (scp fichier A:fichier)
Je creuse du côté des variables d’environnement de la crontab, je mets en place des logs pour voir où ca plante.

Le script se lance, mais :
Que ce soit en SCP, SSH, RSYNC, impossible de copier les données de A vers B, ni de B vers A, si le script est lancé par la crontab.

Du coup, je teste mon script avec un autre serveur C.
Et là mon script fonctionne de A vers C et de B vers C, manuellement ou par la crontab.
Mais ne marche pas de C vers A, ni de C vers B, uniquement par la crontab.

Je ne comprends pas.

Si quelqu’un a un début de piste… merci !

#2

Je suppose que tu as vérifié toute histoire de port et d’IP.
Pas de problème de parefeu non plus ?
On pourrait connaitre les lignes que tu emploies pour toutes tes commandes ?

À mon avis, ça ressemble à une histoire de clefs.
Pourrais-tu faire une expérience avec seulement un MDP au lieu des jeux de clefs ?

#3

C’est exactement ce qu’il m’est arrivé il y a quelques jours. Lorsque tu testes ton script, tu le lances avec ton utilisateur standard. Si tu configures la crontab d’un autre utilisateur, attention à copier les clefs chez lui aussi.

#4

Un point à prendre en compte lors de la création de tâches cron est que le fichier ~/.profile de l’utilisateur ne sera pas chargé. Les exécutables sous ~/bin/ doivent donc être donnés avec leur chemin complet, ce chemin ne faisant pas partie de $PATH au moment de l’exécution de la tâche.

#5

Merci pour toutes vos réponses.

Oui, j’ai bien vérifié port/ip/firewall, ce qui bloquerait l’exécution manuelle également.
Si je supprime les clés, le script ne fonctionnera pas par la crontab, car il attendra le mot de passe.

Je n’ai pas précisé, je travaille en root et la crontab utilisée est bien celle de l’utilisateur root.

J’utilise bien les chemins complets pour appeler les commandes.
Le script fonctionne d’ailleurs vers un serveur C

#6

Alors, ce n’est pas possible de supprimer aussi le MDP, juste le temps de l’essai ?

EDIT :
(bis) On pourrait connaitre les lignes que tu emploies pour toutes tes commandes ?

#7

Non, je ne désactive pas le mot de passe root, même quelques secondes.
C’est un serveur en prod, avec une ip publique.
Mais si ca venait de l’authentification, je suppose que j’aurais également le souci lorsque je lance le script manuellement, non ?

Le code initial était le suivant :

[code]#!/bin/bash
date=date +\%d\%m\%y
dump_home="/DATAS3/plesks/“
dir_date=”${dump_home}${date}“
remote_server=“nom_du_serveur"
remote_dump_home=”/datas1/dumps/plesks/$date”

if ! [ -d $dir_date ] ; then
mkdir -p $dir_date
fi

rsync -au $remote_server:$remote_dump_home $dump_home[/code]

Mais j’ai testé avec un simple scp et un simple ssh, sans succès.

#8

Est-ce que root est encore root ?

Etre ou ne pas être root, voilà la question !

Le glouton systemd est-il à l’œuvre ?

#9

Oui, effectivement, un des serveurs est en Debian Jessie.

C’est à dire root est encore root ?

#10

Salut,

Aucun log, aucun retour console, aucun test. Bref, rien de concret sur quoi s’appuyer.

#11

Rien, j’ai essayé un script tout simple :

[code]#!/bin/bash

echo avant
ssh -vvv $serveur_distant 'touch $file’
echo apres[/code]

Si je l’appelle directement, jai bien mes “echo” et tout le log d’ssh où je vois mon échange de clés etc.
Et si je l’appelle avec la crontab ; dans mon log, j’ai mes echo et rien entre 2, comme s’il ne voyait pas la commande ssh du tout.

jcsm33 a l’air de mettre le doigt sur quelque chose… j’attends sa réponse

#12

$ cp <options> là-bas $ mv <options> là-bas $ scp <options> là-bas $ ssh <options> là-bas $ rsync <options> là-bas $ ping <options> là-bas $ tail -f /var/log/...
[mono]$ etc …[/mono]

#13

Où veux tu en venir ?
Tu veux que je lance ces commandes et donner le résultat ?

cp et mv, à ma connaissance ne se font qu’en local. Et lancé par ssh, ca me fonctionne pas.
scp, ssh et rsync ne donne rien, comme je l’ai expliqué ci-dessus, sans rien afficher dans les logs.
Je ping très bien la vm, puisque quand je lance le script manuellement, il fonctionne parfaitement.
Dans les logs, je vois que ma tâche CRON se lance, c’est tout, sans erreur.

J’ai fait plus de tests.
Ca ne fonctionne pas du serveur Debian7 vers le Debian8
Ca fonctionne du Debian8 vers le Debian7, sauf avec rsync, puisque rsync est en fait lancé à distance sur la source, ce qui équivaut à le lancer depuis le Debian7.
Je ne sais pas si je me fais comprendre.

#14

Je passe mon chemin, bon courage …

#15

merci quand même :wink:

#16

Dis-moi si je me trompe, mais les échanges se font parfaitement dans tous les sens quand tu les fais directement.
Si c’est bien ça, inutile de chercher ailleurs que du côté de crontab.

#17

Dans l’entrée de la crontab, as-tu bien indiqué le chemin complet du script (là aussi il ne connait pas le PATH) ?

Si tu rediriges la sortie de ton cron vers un fichier, as-tu un message d’erreur dans ce fichier après son exécution ?

0 0 * * * /chemin/vers/ton/script >/chemin/vers/fichier.log 2>&1
#18

Yop

+1 Kna je mettrais même bash en debug…

T’être un problème de path éventuellement, au début de ton script je mettrais bien un printenv > /my/dir/export.log

#19

Merci à tous pour vos réponses.

J’ai supprimé les /root/.ssh/known_hosts correspondants aux serveurs, recréé les clés RSA entre les serveurs et ça marche.
C’est bien que ca marche mais je ne comprends toujours pas pourquoi ca ne marchait pas.

En tout cas, ca fait plaisir d’avoir des gens réactifs, encore merci :astonished:)

#20

Il aurait ptet suffit de supprimer les known_hosts sans toucher aux clefs.