Controlling the Install Footprint

Solaris 10 introduced two technologies that, both individually and in concert, change the way we think about installing the OS.

Zones provide very lightweight virtualization. Especially sparse-root zones, which share most of the system files (binaries such as /usr) but have their own copy of configuration files and data (/etc and /var).

SMF, the Service Management Facility, replaces the old rc system and inetd, and allows you to configure exactly what services and daemons are running on a system.

The point about SMF is that historically, the only real way to guarantee that something was disabled was to not install it at all. With SMF, it is feasible to install something and rely on SMF to make sure it won't be active. So while minimization can be done the old way, you can use SMF to minimize what's running on a much larger install.

Then think about zones, and especially sparse-root zones. Because /usr is shared, you have to install everything that's going to be used throughout all the zones. So if you need a zone that runs tomcat, you have to install tomcat globally and it's there in all the zones. (Unless you install a private copy outside the OS in the zone that needs it.) And this is where SMF comes in - you can have all the applications everywhere, but only enable them in the zones that need them.

And it's not just the applications you have now that you need to worry about - to allow for future zones, you really need to make sure that you've installed everything that you might need in the future.

And if you wish to migrate zones between machines, then you have to install everything that might be needed by any zone on your network.

The old days of "install what you need, and no more" on each system don't apply. Consolidation using zones tends to drive you towards fat installs, using SMF to manage what's active in each zone.

That's fine - up to a point. And that point is where each zone gets overloaded with the services that it might run. One part of this is manifest import, which can be the dominant factor in sparse-root zone installation times. (Thankfully work to speed this up has recently been done!)

And as time goes on, the number of services is steadily proliferating. My desktop has over 200 lines of output from svcs. I know it doesn't do 200 different things.

So I have recently been looking again at my install profiles, to see what level of additional tweaking can be done. And the emphasis here is not just on minimizing what software is installed, but minimizing what services are installed, to reduce the cost of manifest import and reduce the available number of services that have to be managed.

On my (largely untweaked) desktop, there are currently 158 SMF manifests. Broken down into packages by number, that is:

   1 SUNWaccr
   1 SUNWadmr
   1 SUNWapmsc
   1 SUNWatfsr
   1 SUNWbindr
   1 SUNWbrgr
   1 SUNWcfplr
   1 SUNWcsd
   1 SUNWdhcsr
   1 SUNWfontconfig-root
   1 SUNWftpr
   1 SUNWgnome-display-mgr-root
   1 SUNWgssc
   1 SUNWinstall-patch-utils-root
   1 SUNWipmir
   1 SUNWipplr
   1 SUNWiscsir
   1 SUNWiscsitgtr
   1 SUNWjwnsr
   1 SUNWkdcr
   1 SUNWmconr
   1 SUNWntpr
   1 SUNWocfr
   1 SUNWos86r
   1 SUNWpcr
   1 SUNWpiclr
   1 SUNWpmr
   1 SUNWppror
   1 SUNWrcapr
   1 SUNWslpr
   1 SUNWsndmr
   1 SUNWsshdr
   1 SUNWstosreg
   1 SUNWstsfr
   1 SUNWtnamr
   1 SUNWtnetr
   1 SUNWtsr
   1 SUNWwbcor
   1 SUNWxwssu
   2 SUNWbsr
   2 SUNWnfssr
   2 SUNWpoolr
   2 SUNWpsr
   2 SUNWsacom
   2 SUNWservicetagr
   2 SUNWsmmgr
   2 SUNWvbox
   2 SUNWvolr
   2 SUNWzoner
   3 SUNWckr
   3 SUNWkrbr
   3 SUNWnisr
   3 SUNWtsg
   4 SUNWsmbar
   4 SUNWxwplr
   4 SUNWypr
   5 SUNWcnsr
   5 SUNWnfscr
   6 SUNWmdr
  10 SUNWrcmdr
  49 SUNWcsr

Now I can't uninstall SUNWcsr, but there are a lot of packages there that my servers aren't going to need. So I end up removing all the WBEM, smc, service tags, telnetd, tnamd, samba, core network services, and the rcmds help a bit too.