Newb Cron Question

The services are different in Debian, but the command is the same, and
the required file is the same. (Qubes cleverness)
Did you restart the qube after issuing the command?

1 Like

There is also a discussion on the mailinglist. I though I’d link it here (read-only):

Nice, cron works now after a reboot.
However, the Filecopy dialog still pops up, after changing the /etc/qubes-rpc/policy/qubes.FileCopy, since the source VM doesn’t know which VM it’s being sent to, for security reasons.

Edit: Command seems to be qrexec-client-vm cloud qubes.FileCopy file.txt

But I still get permission denied. I tried both qubes.FileCopy and qubes.Filecopy files.

OP here.

I’m getting a little lost in the other (very welcome!) issues raised in the thread.

My current state of play is:

  • Crond has been enabled in qvm service crond status confirms that crond is up when the AppVM is running
  • there is an entry in the rc.local to replace /etc/crontab with /rw/home/user/path/to/new/crontab
  • the script which is invoked in the crontab, runs fine when run manually and doesn’t require sudo

Tl;dr - Crond is running (in a Fedora based AppVM), the script backup.sh runs fine when invoked, crontab is rewritten upon boot to

* * * * * user /rw/home/user/path/to/./backup.sh

I’ve tried it with ‘user’ and without ‘user’, no difference. Cron doesn’t seem to have logs so can’t find whether the issue is with the crontab edit, some permissions thing or something more fundamental.

Any help?

If you have an entry:
qube $default allow,target=qube2

Then the pop up wont appear, and files will be automatically copied to
qube2.

I’m not quite following you - I’m not copying files between AppVMs, I’m rsyncing between an AppVm and a remote server.

One reason why I hate forums like this - they make it incredibly
difficult to follow lines of discussion within a single thread.
My remark was directed toward @9009 who complained that the FileCopy
dialog opened.

My bad!

Not your fault - blame the forum format.

qvm-copy-to-vm was the command I was seeking, which works, although it is deprecated.

A basic syntax like destvm targetvm allow works. Although I’m unsure if it’s qubes.FileCopy or qubes.Filecopy, I’ve seen mentions of both in the docs.

It looks like cron(ie) does not get installed by default in Fedora 32. qvm-service [appvm] crond only determines if the service is “enabled” from a Qubes OS perspective. The issue here is that the packages for cron aren’t even installed - perhaps this is a Fedora 32 template bug? My Debian 10 template already had cron installed by default.

In your Fedora 32 template, execute:

sudo dnf install cronie

Shut down the template and your AppVM.

Ensure you have the crond service enabled by Qubes; in dom0:

qvm-service [appvm] crond on

Now, cron will be enabled in the appvm. To verify, boot the appvm, and check:

systemctl status crond

Result should have Active: active (running) (on Debian, change crond to cron).

This the baseline - making sure cron(d) is running before changing anything. If the above doesn’t check out, you have to resolve that first.

At this point now you can make your changes.

When you enable crond from Qubes OS (with qvm-service), Qubes redirects the crontabs that would normally be stored on the root file system to be to be stored persistently within the AppVM under /rw/bind-dirs/var/spool/cron. The system-wide root crontab at /etc/crontab is not affected.

To stay in the “Qubes OS” lane as well as being a little more declarative, I would suggest to leave /etc/crontab alone and place your cron entries in the crontab for the user user.

In your appvm, have these files:

  • ~user/backup/backup.sh: Performs the backup commands

  • ~user/backup/crontab: Contains crontab entry to exec backup.sh:

    *  *  *  *  *  ~user/backup/backup.sh
    

Assuming you have no other crontab things to add for this AppVM, set the crontab for the user:

$ crontab ~user/backup/crontab

Logs? Check journalctl -u crond in Fedora or journalctl -u cron in Debian. This will tell you when crond is triggered.

If your backup.sh script generates output, check user’s mail with the mail command. Or, make sure backup.sh redirects output within the script itself to a file…or change the crontab…etc.

OP has already stated that they have confirmed that crond is up when the
appVM is running - “crond status confirms that crond is up when the AppVM
is running” - so much of your explanation is not particularly helpful.

@JustAnotherQubesUser - Is there a chance that you can post the contents
of the backup.sh file, anonymised if possible?

I wasn’t aware of the ‘cron’ folder in /rw/bind-dirs/var/spool/

However, the directory is empty.

I’ve run the crontab command you suggest, but not seeing any change…

Will post the script shortly.

The folder is empty because you edited /etc/crontab directly instead of using
crontab -e which is the better method.

If you don’t want to post your script, here’s one you can try:

#!/bin/bash
/usr/bin/date >> /home/user/log

Save that as /home/user/test.sh owned by root
chmod +x test.sh

Entry in /etc/crontab:

          • user /home/user/test.sh

systecmctl reload crond
You should see the log file incrementing every minute.
Report back

Here is the script:

#!/bin/bash

LOG_FILE=/rw/home/user/Cron/backup.log
exec > >(tee ${LOG_FILE}) 2>&1

if ping -c 1 IP ADDRESS >> /dev/null
then
echo $(date -u) "Backup Script has run"
rsync -azP /path/to/file user@ipaddress:/path/to/file/
else
echo $(date -u) "Remote host not found"
exit
fi
exit

Here is my modified crontab file

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
* * * * * /rw/home/user/Cron/./backup.sh

OK, we might be making progress.

When I am in the AppVm, and run crontab -e, I am seeing the modified file above.

However, when I check the status of crond via sudo service crond status I see the following:

Redirecting to /bin/systemctl status crond.service
● crond.service - Command Scheduler
     Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
    Drop-In: /usr/lib/systemd/system/crond.service.d
             └─30_qubes.conf
     Active: active (running) since Mon 2020-12-21 14:41:40 GMT; 8min ago
   Main PID: 667 (crond)
      Tasks: 1 (limit: 4840)
     Memory: 1.5M
        CPU: 168ms
     CGroup: /system.slice/crond.service
             └─667 /usr/sbin/crond -n

Dec 21 14:41:40 phd crond[667]: (CRON) STARTUP (1.5.5)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (Syslog will be used instead of sendmail.)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 24% if used.)
Dec 21 14:41:40 phd crond[667]: (root) BAD FILE MODE (/etc/crontab)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (running with inotify support)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Dec 21 14:41:40 phd systemd[1]: Stopping Command Scheduler...
Dec 21 14:41:40 phd systemd[1]: crond.service: Succeeded.
Dec 21 14:41:40 phd systemd[1]: Stopped Command Scheduler.
Dec 21 14:41:40 phd systemd[1]: Started Command Scheduler.

The bit that is interesting is:
Dec 21 14:41:40 phd crond[667]: (root) BAD FILE MODE (/etc/crontab)

Thoughts?

/etc/crontab is owned by root:root and have permissions 644:
-rw-r--r-- 1 root:root <sixe> <date> /etc/crontab

The file you are linking in place should have same permissions.
(If you are doing this I would copy /etc/crontab to /rw, and then in
/rw/config/rc.local:

rm /etc/crontab
ls -s /rw/crontab /etc/crontab
systemctl restart crond

But, of course, I wouldn’t be doing this at all - that’s what native
Qubes use of bind-dirs and qvm-service crond is for.

Thanks - can you run through that last bit again?

I will remove the rc.local script I have in place, and reboot the AppVM so cron will be back ‘factory’ settings.

Let me know what specifically I should do then.

See my explanation here - Newb Cron Question - #31 by icequbes1

And as unman indicated, I missed the part when it was mentioned crond was running - I assumed you meant qvm-service appvm crond says “on” (though “enabled” is a better description)…so skip the first half.

But the rest explains qvm-service, bind-dirs, and how to edit the crontab - you can do it interactively with crontab -e or crontab [filename] if you have a file with the cron jobs specified in them already.