We are about to upgrade from sun4c_411 to sun4_413 (the planning meeting
is today), but have done a number of upgrades. The way we work it out
is that we have a file called /etc/package.sys on the local disk. It
looks something like:
%define sys sun4c_411
Then we have a file called /etc/package.proto which looks something like:
#[setup the machine for running depot]
%define usesdepot
#[setup to run depot on /usr/local]
%define localdepotdir
#[the machine has a medium size disk]
%define mediumdisk
#[include the files to run pc server]
%define doespcserver
# [set the afs cache file to 50megs]
%define specialcacheinfo 50000
#[set this up as a secure machine]
%define adminsecure
# [include the beta libraries]
%define beta
# [get /usr/local from the beta tree]
%define betalocal
#[get the standard set of config files from the department subdirectory]
%define deptadmin
#[the department subdirectory for config files is beta]
%define dept beta
#[add the .staff extention when getting config files from the dept area]
%define deptadminext staff
%include /afs/andrew.cmu.edu/wsadmin/public/src/public.proto
When the machine boots mpp is run with an additional set of variables
which are defined by the rc script. The /etc/package.proto file is then
expanded into a complete /etc/package.${SYS} file.
To change the system type all we do is change the variable definition in
/etc/package.sys. For mass migrations we have package update that file
on the next reboot and set the reboot flag.
We have found that the disks sometimes get full when doing upgrades or
special actions are sometimes needed to update things like boot blocks.
In these cases the at run time expansion of the package prototype files
helps out alot. The first time a machine runs mpp and package for a new
system type only variable of the new system type gets set (ie, the
variable sun4_413 is set), but the rc set a variable called
realsys_sun4c_411. That way the proto type file can expand diffrently.
For example, it can pull over just a new rc which will update the
superblock, then run mpp and package to pull over the new system type or
it can only pull over a small amount of the system till after the next
boot when it can remove the extra kernel which is hanging around and
free up space. There are sometimes up to 4 boots required to upgrade a
system type, but the whole process is automated.
I wrote up a description of how package here works and placed it on
grand.central.org a long time ago, but I can find it now. If you are
interested let me know and I will try to find it or reproduce it.
You can also look at /afs/andrew.cmu.edu/wsadmin/lib and see the actual
package files. The system specific ones are on the sys subdirectory.
You can follow the proto type file I listed above and see how a machine
gets it configuration.
Dan Longinver has a perl script which will create package files from a
system image perhaps he will post a pointer here.
-Wallace
