home | sitemap | abstract | introduction | chaos | thinking | checklist | migrating | recovery
pushpull | cost | career | workshop | isconf | list_and_community | papers | references

Gold Server

Prerequisites: Version Control

We use CVS to manage only one machine in each distinct infrastructure -- the "gold server". Changes to any other machine in the infrastructure propagate out from the gold server. This allows us to make our changes reproducible, recoverable, traceable, and able to be ported and integrated into our other infrastructures. The results are rewarding: We are able to make a true migration from "systems administrators" to "infrastructure engineers". We have learned to abhor fixing the same thing twice, and get to spend our time working out fun, complex puzzles of infrastructure design (and then going home earlier).

We can't stress enough the fact that our gold server is passive . Understanding this concept is key to understanding our model. The gold server serves files via NFS, SUP [sup] , and CVS [cvs] , and that's all . Client machines were responsible for periodically contacting the gold server to obtain updates. Neither the gold server nor any other mechanism ever "pushes" changes to clients asynchronously. See Push vs. Pull .

The gold server is an interesting machine; it usually was not part of the infrastructure, was usually the only one-off in the whole infrastructure, was not mission-critical in the sense that work stops if it went down, but nevertheless the entire infrastructure grows from and is maintained by that one machine. It was the network install server, the patch server, the management and monitoring server, and was often the most protected machine from a security standpoint.

We have developed a rule that works very well in practice and saves us a lot of heartache: "Never log into a machine to change anything on it. Always make the change on the gold server and let the change propagate out."

We manage the gold server by maintaining it as an ordinary CVS sandbox, and then use SUP to replicate changes to client disks. It might make more sense today to use CVSup [polstra] . (See File Replication Servers .)

We use one gold server for an entire infrastructure; this means binaries have to be built on other platforms and transferred to the gold server's NFS or replication server trees. Other infrastructures we've seen use a different gold server for every hardware/OS combination.

Checklist

Version Control


Gold Server
Host Install Tools
Ad Hoc Change Tools
Directory Servers
Authentication Servers
Time Synchronization
Network File Servers
File Replication Servers
Client File Access
Client O/S Update
Client Configuration Management
Client Application Management
Mail
Printing
Monitoring
Google
Search WWW Search www.infrastructures.org
Unix System Administration
[ Join Now | Ring Hub | Random | << Prev | Next >> ]
© Copyright 1994-2007 Steve Traugott, Joel Huddleston, Joyce Cao Traugott
In partnership with TerraLuna, LLC and CD International