How to use CRON as alternative to deferred actions?

Question

I'm trying to set up a CRON job to run maintenance actions in my contract on a regular basis. CRON will call a shell script containing cleos 'push action' commands. The problem is that 'push action' commands must be run with an account's permission, and a wallet must be unlocked to provide authentication of the specified account.

In theory I could unlock the wallet, tell keosd to set the the wallet timeout to seconds, but all of that won't help in the case of a system reboot. This technique doesn't sound very reliable or secure in any case.

Has anyone solved these problems? I'm trying to keep things simple for now and not use a third-party service such as croneos or LiquidApps scheduler.

Answer 1

I have had the same problem and there is a solution.

What you have to do is sign the transaction independently from pushing it. For this you have to either have the private key as a part of your script, or better still store it as an environmental variable so as to not risk having it appear in your repository by mistake.

Then in your script you will do the following steps:

1. Create the transaction
2. Sign and push the transaction to the chain

Create the transaction

To create the transaction, you type the normal cleos command into the script, followed by -x 600 -s -d -j > transaction.json, for example:

cleos push action mycontract myaction '[DATA HERE]' -p myaccount -x 600 -s -d -j > transaction.json

This will create a file called transaction.json that contains the action you want to run.

Sign and push the transaction

To sign and push the transaction to the chain, you type the following:

cleos sign transaction.json -k PRIVATE_KEY_HERE -p

This will then sign the transaction and push it to the chain.

A word of warning with keys

Obviously, storing your key in any unencrypted way on your server is a risk. This is just a basic example to show you roughly how you could do it. Its up to you to decide what risks are acceptable, and add appropriate measures to protect your key beyond this.

If you are using this cron job to run a non-critical task, I recommend you set up a new key and bind the appropriate action to that key, instead of using the active or owner key. This way, if your server is compromised and the key is stolen, they will only be able to call this single action.