On Thu, 10 Jan 2019 at 13:17, Jamon Camisso via talk <talk@gtalug.org> wrote:
On 1/9/19 12:46 PM, Jason Shaw via talk wrote:
darryl, you should be able to look at yum or apt/dpk histories to see if/when cron was updated and possibly gleam some information about who/what did it.
for debian and ubuntu :
https://serverfault.com/questions/175504/how-do-i-get-the-history-of-apt-get... <snip
Certainly sounds like something automatically updated the cron package to me. Good luck in the forensics.
Sounds bad on all counts. I'm not aware of any bugs in 16.04 that would wipe out any crontabs on auto-updates or manual updates. If you're the lucky person to discover one, it will definitely require an SRU update to the cron package itself.
Does anything show up related to cron in /var/log/apt/*.log as Jason pointed out?
What about in syslog and auth.log? Anything there that would show something like 'crontab -r' being invoked?
Lastly, are you using any config management tool like puppet, chef, salt, ansible, juju, etc.? My immediate reaction upon reading this is to cast aspersions at config management - think sorcerer's apprentice and all that.
Just because you can't control the brooms doesn't mean we can't control the brooms! ... Oh, wait, yeah. They do some pretty wonky things occasionally. I'm forced to acknowledge that you should probably check the brooms if you use them ... If that's the case though, their traces would still normally show up in the logs previously mentioned. They would with Ansible anyway. [for those not following this overstretched metaphor, "brooms" == "config management tools"] -- Giles https://www.gilesorr.com/ gilesorr@gmail.com