5 comments

[ 2.6 ms ] story [ 27.9 ms ] thread
What a horrible idea.
Why, in particular, do you think so?

On a one off basis, it sounds like a good idea.

I do think in the long run you're better off to use a build process/documentation to allow rebuilding of hosts. This is especially true if you're running 100's of instances.

Exactly what you're saying.

If you need to maintain multiple hosts then use proper tooling, be it puppet, chef, FAI, git, virtualization, or even a homegrown set of bootstrap scripts.

Rsync'ing random stuff from one host to another will hardly end well, except for truly one-off stuff that gets closely reviewed during the process.

File location and contents vary wildly, even between slightly different [package] versions of the same distribution. Trying to automate that stuff without even looking at what the package manager of the respective hosts has to say is a recipe for disaster.

Sure, your script may work today right after you tested it with two near identical RedHat hosts. I promise it will fail badly when you try to run it again 6 months from now. Or rather, it will probably run nearly fine, but bury some interesting surprises for you to find out about later...

Elaborate? We have used it in production to move servers from Slicehost to Rackspace Cloud Files and it worked flawlessly.
Reading about efforts like this makes me glad we write a half-page spec file and build an RPM for each service we've created. We're finally free of servers whose configuration is a hand-crafted artwork needing this sort of attention. We just "yum install" on a fresh machine (or a xen instance in dev or qa), smoke test, and call it a day.