Cron et ssh
lonewolf
-
[Dal] Messages postés 6205 Date d'inscription Statut Contributeur Dernière intervention -
[Dal] Messages postés 6205 Date d'inscription Statut Contributeur Dernière intervention -
Bonjour,
J'ai un petit souci.
j'ai crée un script qui va vérifier a distance et par ssh si mon serveur samba est en fonctionnement.
Le script fonctionne, y a pas de souci
Par contre, dès que je le place dans le cron, cela ne fonctionne plus.
Je m'explique : j'ai une commande ssh et un || si cela ne fonctionne pas envoi moi un mail.
Lorsque j'execute le script, pas de souci, il m'envoi un mail que lorsque j'ai fait tomber le pc distant.
Mais par cron, il m'envoie toujours un mail car a priori, il ne prend pas en compte le ssh
Est ce qu'il y a une solution pour bypasser ce problème ??
Merci d'avance
Lonewolf
J'ai un petit souci.
j'ai crée un script qui va vérifier a distance et par ssh si mon serveur samba est en fonctionnement.
Le script fonctionne, y a pas de souci
Par contre, dès que je le place dans le cron, cela ne fonctionne plus.
Je m'explique : j'ai une commande ssh et un || si cela ne fonctionne pas envoi moi un mail.
Lorsque j'execute le script, pas de souci, il m'envoi un mail que lorsque j'ai fait tomber le pc distant.
Mais par cron, il m'envoie toujours un mail car a priori, il ne prend pas en compte le ssh
Est ce qu'il y a une solution pour bypasser ce problème ??
Merci d'avance
Lonewolf
A voir également:
- Cron et ssh
- Ssh download - Télécharger - Divers Web & Internet
- Z-cron - Télécharger - Optimisation
- Visual cron - Télécharger - Divers Utilitaires
- Cron sql - Forum Shell
- Cron toutes les minutes ✓ - Forum Redhat
4 réponses
Salut,
Les commandes de ton script doivent être accessibles dans l'environnement dans lequel s'exécute CRON, qui n'a surement pas la même variable de PATH.
Modifie ton script en lançant les commandes qu'il contient précédées de leurs chemins absolus et vois si cela améliore les choses.
Par exemple, sur une Debian le chemin absolu de "ssh" (et sur d'autres Linux en général) est "/usr/bin/ssh".
Pour vérifier le chemin d'une commande utilise la commande "which"
Fait cela pour toutes les commandes de ton script, y compris celles que tu mets dans la Crontab.
Dal
Les commandes de ton script doivent être accessibles dans l'environnement dans lequel s'exécute CRON, qui n'a surement pas la même variable de PATH.
Modifie ton script en lançant les commandes qu'il contient précédées de leurs chemins absolus et vois si cela améliore les choses.
Par exemple, sur une Debian le chemin absolu de "ssh" (et sur d'autres Linux en général) est "/usr/bin/ssh".
Pour vérifier le chemin d'une commande utilise la commande "which"
Fait cela pour toutes les commandes de ton script, y compris celles que tu mets dans la Crontab.
Dal
Bonjour et merci a toi,
Alors voila ce que j'ai fait :
J'ai modifié ma commande dans le cron en y mettant le chemin de la commande
j'ai modifié également mon script :
Mais ca coince. Ca ne fonctionne pas mais je n'ai pas de messages d'erreur dans mes logs.
Je suis donc un peu perdu
Merci de votre aide
lonewolf
Alors voila ce que j'ai fait :
J'ai modifié ma commande dans le cron en y mettant le chemin de la commande
*/5 * * * * /bin/sh /home/rsi/Desktop/script.sh
j'ai modifié également mon script :
#!/bin/bash
(/usr/bin/ssh root@CPD1 "service smb status>status.txt")||mail -s ErrorCpd1 toto@titi.fr << EOF
CPD1 Draf43 Tombé
EOF
/usr/bin/ssh root@CPD1 "scp status.txt root@linux:/home/rsi/Desktop/"
/usr/bin/ssh root@CPD1 "rm -f status.txt"
/usr/bin/ssh root@CPD1 "exit"
export foo=`cat /home/rsi/Desktop/status.txt|head -1|awk '{ print $NF }'`
if [ $foo = "arrêté" ]; then service smb start; fi
if [ $foo = "d'exécution..." ]; then service smb stop; fi
rm -f /home/rsi/Desktop/status.txt
*
Mais ca coince. Ca ne fonctionne pas mais je n'ai pas de messages d'erreur dans mes logs.
Je suis donc un peu perdu
Merci de votre aide
lonewolf
Bonjour,
Il faudrait vérifier si le cron arrive à prendre les clés ssh dans le bon répertoire. A priori cron force l'environnement $HOME, mais je ne suis pas sûr que ça suffise au plan des protections de fichier.
Je ferais des "ls -lu" avant et après l'exécution par cron, d'une part sur l'exécutable ssh (pour voir si ssh a été lancé), et d'autre part sur le répertoire $HOME/.ssh et les fichiers de clé (pour savoir s'ils ont été lus).
Manu
Il faudrait vérifier si le cron arrive à prendre les clés ssh dans le bon répertoire. A priori cron force l'environnement $HOME, mais je ne suis pas sûr que ça suffise au plan des protections de fichier.
Je ferais des "ls -lu" avant et après l'exécution par cron, d'une part sur l'exécutable ssh (pour voir si ssh a été lancé), et d'autre part sur le répertoire $HOME/.ssh et les fichiers de clé (pour savoir s'ils ont été lus).
Manu
Salut lonewolf,
1.
*/5 * * * * /bin/sh /home/rsi/Desktop/script.sh
"/bin/sh" me semble être inutile.. non ?
Pour rediriger stdout et stderr vers un endroit précis, tu peux faire cela :
*/5 * * * * /home/rsi/Desktop/script.sh > /home/lonewolf/testcrontab.txt 2>&1
j'ai modifié également mon script :
#!/bin/bash
(/usr/bin/ssh root@CPD1 "service smb status>status.txt")||mail -s ErrorCpd1 toto@titi.fr << EOF
Il manque le chemin absolu de "mail"
CPD1 Draf43 Tombé
EOF
/usr/bin/ssh root@CPD1 "scp status.txt root@linux:/home/rsi/Desktop/"
/usr/bin/ssh root@CPD1 "rm -f status.txt"
/usr/bin/ssh root@CPD1 "exit"
Le "exit" n'est pas utile car ssh fait déjà un "exit" à la fin de chaque ligne de commande.
export foo=`cat /home/rsi/Desktop/status.txt|head -1|awk '{ print $NF }'`
Mettre le chemin absolu des commandes ci-dessus est plus prudent.
if [ $foo = "arrêté" ]; then service smb start; fi
if [ $foo = "d'exécution..." ]; then service smb stop; fi
Je ne comprend pas cette partie. La commande "service" ne devrait-elle pas être exécutée sur la machine "CPD1" avec une commande ssh ? Si c'est vraiment un exécution locale, il est préférable de préfixer du chemin absolu.
rm -f /home/rsi/Desktop/status.txt
*
C'est pour quoi l'étoile ?
2.
Les commandes ssh ne fonctionneront que si "root" n'a pas de mot de passe sur "CPD1" (ce qui n'est pas recommandé), ou si tu as installé un couple de certificats sur "/root /.ssh" sur "CPD1" et dans le "$HOME/.ssh/" de l'utilisateur qui lance la tâche cron.
Fait les vérifications proposées par Manu si tu es dans ce 2ème cas.
Il faudra aussi, bien sûr, que la crontab que tu lances soit effectivement celle de l'utilisateur pouvant utiliser la paire de clés, et donc que tu aies mis ta ligne de crontab dans l'éditeur qui se lance après avoir saisi "crontab -e" en ligne de commande sous l'utilisateur concerné.
Dal
1.
*/5 * * * * /bin/sh /home/rsi/Desktop/script.sh
"/bin/sh" me semble être inutile.. non ?
Pour rediriger stdout et stderr vers un endroit précis, tu peux faire cela :
*/5 * * * * /home/rsi/Desktop/script.sh > /home/lonewolf/testcrontab.txt 2>&1
j'ai modifié également mon script :
#!/bin/bash
(/usr/bin/ssh root@CPD1 "service smb status>status.txt")||mail -s ErrorCpd1 toto@titi.fr << EOF
Il manque le chemin absolu de "mail"
CPD1 Draf43 Tombé
EOF
/usr/bin/ssh root@CPD1 "scp status.txt root@linux:/home/rsi/Desktop/"
/usr/bin/ssh root@CPD1 "rm -f status.txt"
/usr/bin/ssh root@CPD1 "exit"
Le "exit" n'est pas utile car ssh fait déjà un "exit" à la fin de chaque ligne de commande.
export foo=`cat /home/rsi/Desktop/status.txt|head -1|awk '{ print $NF }'`
Mettre le chemin absolu des commandes ci-dessus est plus prudent.
if [ $foo = "arrêté" ]; then service smb start; fi
if [ $foo = "d'exécution..." ]; then service smb stop; fi
Je ne comprend pas cette partie. La commande "service" ne devrait-elle pas être exécutée sur la machine "CPD1" avec une commande ssh ? Si c'est vraiment un exécution locale, il est préférable de préfixer du chemin absolu.
rm -f /home/rsi/Desktop/status.txt
*
C'est pour quoi l'étoile ?
2.
Les commandes ssh ne fonctionneront que si "root" n'a pas de mot de passe sur "CPD1" (ce qui n'est pas recommandé), ou si tu as installé un couple de certificats sur "/root /.ssh" sur "CPD1" et dans le "$HOME/.ssh/" de l'utilisateur qui lance la tâche cron.
Fait les vérifications proposées par Manu si tu es dans ce 2ème cas.
Il faudra aussi, bien sûr, que la crontab que tu lances soit effectivement celle de l'utilisateur pouvant utiliser la paire de clés, et donc que tu aies mis ta ligne de crontab dans l'éditeur qui se lance après avoir saisi "crontab -e" en ligne de commande sous l'utilisateur concerné.
Dal
