LinuxQuestions.org - Calling Crontab over non interactive ssh session

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - Calling Crontab over non interactive ssh session (https://www.linuxquestions.org/questions/linux-general-1/calling-crontab-over-non-interactive-ssh-session-885245/)

Calling Crontab over non interactive ssh session

Ok, is there any obvious reason like security permissions why the following script would fail when executed over ssh with a supplied command

File updatecron.sh

Code:

#!/bin/bash

crontab -l > crontab.bak

cp crontab.bak crontab

echo " 30 2 * * * /usr/local/bin/targetprogram 2>&1" >> crontab

crontab crontab

This simple would be called using

Code:

ssh user@host updatecron.sh

The file was put in place prior to the attempt to run it remotly. Essentially I had over 100 servers where I needed to make a crontab update, using a usr who doesn't have admin access. Now the script works in an interactive ssh session just fine, but when ran as stated above in a non interactive mode it produced crontab.bak dorrectly and modified the new crontab file correctly, but the entry in cron was empty. This leads me to believe the line "crontab crontab" failed due to some permission or enviroment issue I am unaware of.

If you have any feedback I would greatly appriciate it and if you have a better idea on how to automate commands like this when pushing to multiple servers I'm all ears.

name the file 'newcrontab' instead of crontab

anything in /var/log/messages or /var/log/cron ?

I'll test renaming the script in a few minutes and get back to you.

As for as the log request. For some reason the team in charge of the RH images puts var/log as 600 root root making my ability to look at the logs a very leangthy process. I'll work on that because it isn't something I thought about last night when I ran in to the trouble.

I would assume that the PATH is different whether you get an interactive or batch session. Can you please check whether it’s in your PATH also when invoked remotely:

Code:

$ ssh user@host which updatecron.sh

Maybe ~/.bashrc and/or ~/.bash_profile needs to be adjusted.

NB: You can also avoid your own temporary file:

Code:

#!/bin/sh



if [ "$PARAMETER" ]; then

    echo "$PARAMETER" >> $1

else

    export EDITOR=$0

    export PARAMETER="$1"

    crontab -e

fi

and on the local machine then:

Code:

$ ssh user@host /home/user/updatecron.sh '" 30 2 * * * /usr/local/bin/targetprogram 2>&1"'

$1 during the second invocation is the name of the temporary file crontab -e normally feeds to the editor. Instead of the echo used here, you can also make more complex changes using sed or awk.

You were right. It was a path issue. The file provided need to be explicitly stated. I actually went ahead and used your version for future udpates because it makes it easier. I appriciate the help.

As a second note. I would have never thought about a recursive call to the same script. I like the technique and will need to find more ways to use it in the future.

Great that it works now.