So last night as I was testing new hypervisors out to possibly replace Proxmox, and I got a bit sidetracked. During my adventures in la-la land, I happened to come across files that hadn’t been updating via my Rsync scripts. I double checked the crontab’s, manually ran the scripts, but nothing was throwing any red flags. I investigated all my machines and found they all, while executing other tasks via cron, were refusing to actually run the Rsync jobs. Cron was kicking off the tasks but was stopping dead there.
As it was getting late I ran the most critical ones manually, and decided to leave further investigation until today.
Starting from square one I made the Rsync jobs output to a log file so I could see any errors, set the timing to 1 minute so I can watch it run immediately, and set out on some Google adventures while I troubleshot what may be going wrong.
The most recent VM’s I’ve created I have been setting up Rsync jobs on them from the start, and one glaring option has been blocking each one right away…
This was being defined in /etc/sudoers, and commenting it out and restarting sshd resolved the issues for these newer VM’s. However, it looks like on machines where it had been working fine…sometimes for months…one of the recent updates decided to inject that line into my sudoers file on the 2nd of December. I was able to track this down via /var/log/secure:
Dec 2 08:00:02 kansai sudo: chris : sorry, you must have a tty to run sudo ; TTY=unknown ; PWD=/home/chris ; USER=root ; COMMAND=/usr/bin/rsync -av --delete-after --ignore-errors --progress...
This is default behaviour on all CentOS 6.3 machines.
After doing this on all previously existing VM’s, and my physical machines, all is well in The Zen Garden once more!