Tech fails in action – Rsync misuse

Take a scenario of having to synchronise several webservers with identical content, rsync would seem a reasonable choice.It just comes down to how you implement it.

What you don’t do is run rsync pull via cron, with two similar jobs, both writing to the same log file (overwring the same log file whilst dutifully sending stderr there as well), running under a normal user whilst trying to use the root only -o option.

Other things you don’t do is to modify a production web server and the let the replicas PULL the configuration to them using the aforementioned rsync/crontab. This needs a Picard facepalm!

“Well it used to work before!”, was that before you weren’t allowed to run it as root maybe? Guess the answer. You ran it as ROOT??!!! So any compromise would have been replicated as root and you’d have no log files to trace what might have been.

“So what’s the solution?” Well getting a proper deployment system in place that pushes out configurations from a seperate deployment server.

To spell it out:

  • Legacy use of root needs to be weeded out and exterminated
  • Configuration servers should ALLWAYS exist outside of end user access
  • Always PUSH configuration from the configuration server
  • All logs go to Syslog, never ever write your own
  • Any requirements to vary the deployment from this get rejected