On Wed, Dec 20, 2006 at 08:53:41AM -0600, Will Maier wrote: > On Wed, Dec 20, 2006 at 02:31:09PM +0000, Brian Candler wrote: > > That makes a lot of sense. But enforcing that policy might be > > difficult. This is important if you're relying on your gold server > > for disaster recovery purposes - if the target machines had some > > change made which nobody remembers and weren't reflected in the > > gold server, then any freshly-built machines will be > > non-functional. > > This is a cultural problem, but there's an adequate technical > solution: aggressively sync the client machines. Admins quickly > learn to make changes in the central when their changes get blown > away every hour.
That makes sense too. However if the file is a daemon config, say, then the central system reverting the change might not be noticed until some far time in the future when the daemon is restarted. So a super-smart config management system would know that daemon D depends on files F1..F3, and if the start time of D is earlier than the modification time of any of F1..F3 then it could report this. (Problem: there's no standard way to get the "last HUP time" of a daemon) The other thing which concerns me is that it's not easy to protect against the installation of new software packages, or Perl CPAN modules, or ad-hoc scripts, unless you 'rsync --delete' big chunks of the filesystem... Thanks, Brian.
