2

I am currently cleaning up a mess left by someone else on a CentOS 6 server. There is an application that is required to be backed up to a github account every 6 hours. There is a script that takes care of preparing the data and it takes care of the git add and git commit.

The git push is taken care of by an "expect" script. This was done so that the passphrase can be passed to the git push when the ssh asks for it. The user does not want to use an empty passphrase.

The script runs fine when run from the command line in a bash shell by the root user. I can see the files transferred to github.

When the script runs under a crontab created by root the script appears to run but the git push does not take place. If I manually run a git push, after the script has failed, I notice that the push that should have happened happens along with the manual one I have called from the command line. It appears that the push that should have happened in the script has been cached and not pushed to github.

Can anyone suggest what I am missing here? Is it possible to get a git push to work within a script like this?

Regards

Richard

Richard Luckhurst
  • 101
  • 2
  • 11
  • when you do the command manually do you run it as root? not sudo? – Lynch May 16 '13 at 03:38
  • 1
    The usual reason why a command fails under cron is that it depends on environment variables that are set in your .profile, since it's not run by cron jobs. – Barmar May 16 '13 at 03:38
  • When I run the command manually I run it as root – Richard Luckhurst May 16 '13 at 04:41
  • I agree that the environment variables can be a reason that a command fails when run from a cronjob. In a standard CentOS installation there don't seem to be many environment variables set for a root login. All commands in the scripts I am having trouble with are called with their absolute paths and do not depend on the PATH variable. – Richard Luckhurst May 16 '13 at 04:43

1 Answers1

1

The issue should be in the passphrase being not correctly passed by the ssh-agent to ssh when the git push tries to run.

As illustrated by the follow-up blog post, you cannot simply call ssh-agent -s in your cron, or it would simply create another instance, with no key in it.

To fix it, I needed to find a way to keep from starting another ssh-agent process, and instead gain access to the one seahorse starts every time I log in.
I made a change to my crontab that would search for the existing ssh-agent process ID and authentication socket and import them into the cron environment. This is kind of a hack but it actually works (not like last time).
Just add the following to your script before trying to connect to your SSH server (or do what I did and put them right into the cron job, separated by semicolons):

export SSH_AGENT_PID=`ps -a | grep ssh-agent | grep -o -e [0-9][0-9][0-9][0-9]`
export SSH_AUTH_SOCK=`find /tmp/ -path '*keyring-*' -name '*ssh*' -print 2>/dev/null`

To clarify:

Just add the following to your script

That means the above two lines are part of a script declared as a cron job and called by said cron job.

put them right into the cron job, separated by semicolons

If the script is small enough, you can get rid of the script entirely and make your cron job a sequence of commands: see "Run two commands with a crontab".

crontab -l | { cmd1; cmd2 ; cmd3; } | crontab -

That syntax is but one of the way you can add programmatically a command to a cron job.

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Can't this be improved by putting up an `rc`-script which would run something like `openvt -c 8 /bin/sh -c 'umask 077; ssh-agent -s >/root/agent.env && source /root/agent.env && ssh-add /path/to/the/key'` at startup, and the cron job script would then just `source /root/agent.env` before attempting to connect the server? – kostix Jun 17 '13 at 16:09
  • @kostix that sounds like a good improvement. Did you test it? – VonC Jun 17 '13 at 16:12
  • No, I myself would use a well-protected *decrypted* key. But if the OP wants/needs entering a password, a dedicated on-boot setup seems to be a good thing to me. BTW my comment wasn't a claim to improve your answer but rather it tried to possibly give some new ideas to the OP. – kostix Jun 17 '13 at 16:20
  • @kostix I understand. Let's see what the OP thinks about this. – VonC Jun 17 '13 at 16:23
  • answer is insufficient and doesn't explain HOW to "put them right into the cron job", separated by semicolons. Where? Right where? Right into the same command on one line? Right into the beginning of the cronjob? There's no way for us to understand what "right there" means – codyc4321 Oct 14 '16 at 23:39
  • yes that works. python scripts need the env variable as part of the line calling the script, if you call a bash script you can throw the env var right in it seems – codyc4321 Oct 15 '16 at 15:34