Network & Academic Computing Services
Some of these improvements are critical to a high-functionality, well-secured environment. However, these critical improvements alone are simply too much to do by hand, on all of our machines. Of course, the "nice, but not critical" changes are forgotten with manual procedures - given that our time is more than consumed by the critical improvements.
autoinstall is essentially a system for installing machines, with very nearly all of the improvements we know how to make ("critical" as well as "nice"), conditionalized so that people who don't want some of those improvements, aren't forced to have them on their machines.
Full utilization of autoinstall entails full reinstalls, as well as invocations of run-after (see also Components of Autoinstall). The former is used to load an initial configuration with the customizations developed at the time of the install, while the later is used to bring a machine up-to-date on customizations (with the notable exception of most vendor patches, which are done by full reinstalls, but aren't done by run-after). Many machines are not autoinstalled, so run-after is not particularly applicable for them.
For these reasons, srsh comes in. srsh is for making small changes, on a large number of hosts, in a small amount of time, with a high degree of consistency. That is, autoinstall is used to load the best-we-know-how, at install time, and srsh is used to shore up a large number of machines on their immediate needs, as those needs become apparent - for example, as security holes are revealed on the internet, and become commonly exploited. Good applications of srsh include applying those patches not handled by run-after.
In terms of security, at a given instant, srsh is usually more important than autoinstall. However, in terms of future security, in terms of making sure that security fixes do not start slipping through the cracks, autoinstall is the more significant facility. srsh is inherently better geared toward quick implementation of stop-gap measures, while autoinstall is more of a view toward the future. As such, autoinstall and srsh are quite complementary.
stamp is used to generate descriptions of, and make comparisions between, machine configurations. Because a great deal of the work carried out during upgrades, is trying to determine what modifications have been made to a machine, stamp simplifies upgrades considerably - allowing more frequent reinstalls (via autoinstall).
srsh and stamp do not particularly relate to each other at this time, although at some point in the future, stamps may be collected via srsh, for safe-keeping on a centralized host.
Network & Academic Computing Services >
Support >
SysAdmin
Updated: October 2, 2003
![]()
Departamental Computing Support
How autoinstall, srsh and stamp are used together
As our body of administrative knowledge grows, there is an ever-increasing number of improvements to machine configurations, we would like to make - and in many instances, should be making. Needless to say, if we learn much at all about what we are doing, and work with anything but a very small number of machines, we learn about far more improvements than we have time to take care of, manually.