I've personally never tried it, just because of the number of gotchas. Of course, your risk evaluation is going to be different from mine, so you'll have to judge for yourself if the benefits outweigh the risks.
- Someone with access to the central server can modify any of the services set to call in, without needing explicit permission to any of the other systems.
- The client system needs to verify that the file is clean before installing, or it may break the service.
- How do you force a service to roll back if something goes wrong?
- (basic issues with verifying who gave you the file, etc, but those can be taken care of with PGP signing, and SSH known hosts)
- How much time slop do you have if you're doing pull, rather than push?
I'd rather push instead of pull -- although it might be tricker to have multiple machines all come up in a tight window of time, I'd rather have the responsiveness of knowing that I could connect to the server, and have the central server get an immediate report that something went wrong. I don't make changes often enough to make it so that the systems check in every 5 minutes or so, and I don't want to have to potentially wait an hour for the next system checkin.
Of course, my current systems aren't all that similar, so it's not worth my putting something together. If I were going to do it, though, I'd use Expect from the central server. Although this doesn't fix all of the risks that I mentioned, it makes it so I don't have to maintain this code as a service on each of the systems (as I wouldn't trust changes to this code being pulled), and I'd require some sort of a manual password entry to kick off the update. (I might store the passwords to the individual systems in a single encrypted file, if that was considered to be an acceptable risk)
| [reply] |
