Question cron will not run working Bash script

[iainh]

I have a small bash script that uses curl to post the Plesk Apache logs to a logging service and then moves the files to an 'uploaded' directory (so as to not reload them on a second run).

The scripts works fine from an ssh CLI, but fails under cron and so I'm clearly missing a permission for the cron task or similar.

The actual script reads:

for FILE in access_*log.processed.*.gz
do echo "Processing $FILE"
curl -v -X POST -T $FILE -H 'Content-Encoding: gzip' https://[URL_removed]
mv $FILE uploaded/$FILE
done

This works without issue from an SSH shell, but cron reports:

Task "/var/www/vhosts/vhost_name/logs/loadAccessLogs.sh" completed with error in 0 seconds, output:

curl: Can't open 'access_*log.processed.*.gz'!
curl: try 'curl --help' or 'curl --manual' for more information
mv: cannot stat ‘access_*log.processed.*.gz’: No such file or directory

So both curl and mv seem to be complaining. Do I need to provde a path varialbe or set absolute paths to the commands?

 

[iainh]

So starting to answer my own question, it look slike the cron task is run in a chrooted environment based on the system user of the subscription and so I need to work out file paths (Scheduling Tasks)

Note: In Plesk for Linux all "Run a command" scheduled tasks by default are run in a chrooted environment. The home directory of a subscription's system user is treated as the file system root for that subscription, and no executable files outside the chroot jail can be run. If you are encountering "file not found" errors during the execution of your scheduled tasks, try using paths relative to the system user's home directory, and not absolute ones. If you need the ability to run executable files located outside the chroot jail, contact your hosting provider.​

So now to work out where the cron task home is...

 

[iainh]

Well, using a simpler version of the script on the realisation that I don't need to loop for each log on the basis the cron job will run each night, plus the realisation that yesterdays's log will always be *.processed.1.gz and so I need to timestamp the files when moving to the uploaded directory (unless I permit overwriting each day), I have now got to:

# Load the http access log
curl -v -X POST -T /logs/access_log.processed.1.gz -H 'Content-Encoding: gzip' https://URL

# And load the https access log
curl -v -X POST -T /logs/access_ssl_log.processed.1.gz -H 'Content-Encoding: gzip' https://URL

# And now move both to the 'uploaded' directory
mv /logs/access_log.processed.1.gz /logs/uploaded/$(date -d "today" +"%Y-%m-%d-%H-%M").http_access_log.gz
mv /logs/access_ssl_log.processed.1.gz /logs/uploaded/$(date -d "today" +"%Y-%m-%d-%H-%M")https_access_log.gz

I now have the issues of the chrooted environment and:

1. curl can't negotate a TLS session: "curl: (77) Problem with the SSL CA cert (path? access rights?)"
   
2. The date function can no longer be found ("/logs/cronLoadAccessLogsToSumo.sh: line 12: date: command not found") and pointing to it's location is clearly falling foul of the chroot environment
   bash-4.2$ /usr/bin/date -d "today" +"%Y-%m-%d-%H-%M"
   bash: /usr/bin/date: No such file or directory
   
3. The subscription system user account doesn't seem to have permission to move the log files
   mv: cannot move '/logs/access_ssl_log.processed.1.gz' to '/logs/uploaded/https_access_log.gz': Permission denied
   although does seem to have read access:
   -rw-r--r--. 3 root root 188 May 30 02:39 access_log.processed.1.gz
   -rw-r--r--. 3 root root 156 May 30 02:39 access_ssl_log.processed.1.gz

 

[iainh]

So I found a Plesk article; "How to extend chrooted environment with additional commands" (How to extend chrooted environment with additional commands) which seemed promising, however, the provided <recreate_chroot_env> script doesn't work on my CentOs 7 system:

[root@at chroot]# ./recreate_chroot_env.sh /usr/bin/date
 Trying to install chrooted environment... *****  problem report *****
./recreate_chroot_env.sh: line 61: : No such file or directory
cleanup chrooted environments on existing domains
./recreate_chroot_env.sh: line 64: : No such file or directory

./recreate_chroot_env.sh: line 67: : No such file or directory
mknod: ‘/var/www/vhosts/chroot/dev/null’: File exists
mknod: ‘/var/www/vhosts/chroot/dev/tty’: File exists
/var/www/vhosts/chroot/bin /var/www/vhosts/chroot
/var/www/vhosts/chroot
*****  problem report *****
./recreate_chroot_env.sh: line 61: : No such file or directory
distribute chrooted environments on existing domains
./recreate_chroot_env.sh: line 64: : No such file or directory

./recreate_chroot_env.sh: line 67: : No such file or directory
done

However, I have copied over the <date> function to the directory and so that should hopefully cure the 'bash: /usr/bin/date: No such file or directory' error.

My real issue is curl and it's error:

curl: (77) Problem with the SSL CA cert (path? access rights?)​

This seems to be a permissions issue in getting access to /etc/ssl/certs

The root certs are 'read all':

lrwxrwxrwx. 1 root root 49 Sep 14 21:22 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx. 1 root root 55 Sep 14 21:22 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt​

but cannot be read from the chrooted environment, hence I presume this "curl: (77) Problem with the SSL CA cert (path? access rights?)".

So do I need to do a mount --bind to try and enable curl to find the root certs, and if so, where is curl going to go looking? Do I need ot use:

mount -bind /etc/ssl/certs /var/www/vhosts/[vhost_name]/etc/ssl/certs​

so that curl will still find the certs on the same path relative to its home?

I'm just keen not to go breaking anythng and so some clear; 'Do it like this' instructions woudl be great

Many thanks

 

[adiamantakidis]

Same problem with a Schedule Task cron style:

curl: (77) Problem with the SSL CA cert (path? access rights?)

Tried every suggested solution, not working. Any help?