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
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s