Copyright (c) 2001 Anthony Tonns Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".GNU Free Documentation License
If you don't care how the JumpStart server was created, etc. and just want to use it, follow these quick steps
NOTE: You must have the serial console on the machine to make this work
How To Use The JumpStart Server: When assigning a 'hostname' to a machine, DO NOT, I repeat DO NOT use the name of the network that it's on as part of the hostname (ie: hostname.bup or hostname.filer). You MUST use just the plain 'hostname' |
|
At the Office (512 7th)jump1.ivillage.com |
At Exodusjump0.bup.ivillage.com |
[where 'hostname' is the name of the new machine,
and 'jump1.jump' is the correct interface on the jumpstart server]
|
[where 'hostname' is the name of the new machine,
and 'jump0.bup' is the correct interface on the jumpstart server]
|
Creating a JumpStart server is basically a Catch-22. You need to install a system to install systems >8). As part of this process, every time I've built a custom JumpStart server, I've done it at LEAST twice. The first server is basically an out-of-the-box install with a few tweaks to get me going. The second server is built from the JumpStart template, and is totally up-to-spec. However, we'll just jump right in here, and you can figure it out how you want to deal with it yourself...
/jump/os - where Solaris 7 livesI strongly recommend that you also create /jump/etc/RCS and /jump/etc/scripts/RCS so that you can use revision control as you modify your custom JumpStart configs.
/jump/etc - your main JumpStart config directory
/jump/etc/scripts - custom JumpStart scripts
/jump/patch - location of the Recommended patch cluster
/jump/cfg - location of the sysidcfg files
/jump/pkg - place for packages to be installed (both SunFreeware and local)
/jump/local - place for files needed by customization scripts (not packages)
/jump/var - the area to screw around with, compile sources, etc. etc.
cd /cdrom/sol_7*sparc_sun_srvr/Solaris_2.7/ToolsNOTE: This will take _some_ time, as the CD is big (and slow)
./setup_install_server /jump/os
Also, make sure to mkdir /tftpboottftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
cd /jump/os/Solaris_2.7/Misc/jumpstart_sample
tar cf - . | ( cd /jump/etc; tar xf - )
mv /etc/rc2.d/s71rpc /etc/rc2.d/S71rpc
mv /etc/rc2.d/s73nfs.client /etc/rc2.d/S73nfs.client
mv /etc/rc3.d/s15nfs.server /etc/rc3.d/S15nfs.server
share -F nfs -o ro,anon=0 -d "jumpstart" /jumpAt this point you can "start" the RPC, nfs.client and nfs.server scripts.
Now you have an elementary JumpStart server, that can install Solaris 7 over the network. If this is all that you wanted, you can follow Sun's documentation on How to Set Up Systems to be Installed Over the Network With add_install_client. Pay closed attention to step 2, where the hostname, IP address and ethernet address need to be added to /etc/hosts and /etc/ethers before running add_install_client.
When installing OpenSSH, the process that generates it's host keys depends on a good source of random numbers. When installing OpenSSH from a system already built, the pre-package psuedo-random number generator that comes with OpenSSH is sufficient. However, when installing the custom iVillage OpenSSH package prior to the first boot, there is clearly not enough psuedo-random data. Thus, we will not use the pseduo-random number generator, but use the SUNWski package available from Sun (shipped with Sun Web Server). To do this, we must first install it on the install boot system, then edit the startup scripts so it starts cryptorand, the random number generator. To install the package:
pkgadd -d SUNWski.pkg -R /jump/os/Solaris_2.7/Tools/Boot SUNWski
Now edit the /jump/os/Solaris_2.7/Tools/Boot/sbin/sysconfig script (you might want to back it up first as sysconfig.orig) changing at the VERY end of the script:
exec /sbin/suninstallto:
mkdir -p /var/etc /etc/init.d/cryptorand start exec /sbin/suninstall
These files enable the automation of the install process. However, it leaves you with a clean, vanilla and extremely vulnerable Solaris install. For the most part, these are three aspect of the JumpStart will not need changing. However, for those who like to meddle with things (like myself) you might want to know a little more about them in case you do want to change them.
The JumpStart process begins with the /jump/etc/rules file. Each rule in the rule file "distinguishes a group of systems based on one or more system attributes, and it links each group to a profile, which is a text file that defines how the Solaris software will be installed on each system in the group" (from the Solaris Advanced Installation Guide). First, you need to comment out all the sample rules in the rules file. This can be done in vi with ":%s/^/#/g".
Then, for the iVillage setup, add these generic rules to the end of the rules file:
#
# generic rules
#
karch sun4u && disksize c0t0d0 3500-4500 \
ivil_begin ivil_4gb ivil_finish
karch sun4u && disksize c0t0d0 8100-9900 \
ivil_begin ivil_9gb ivil_finish
karch sun4u && disksize c0t0d0 17100-18900 \
ivil_begin ivil_18gb ivil_finish
Basically, the distingushing attributes we use are kernel architecture and size of the boot disk.
Combined with the profile, the sysidcfg file is really what "automates" the install portion of the JumpStart server. It allows you to preconfigure the most basic system information without user interaction. Here is a sample sysidcfg file:
terminal=vt100
system_locale=C
timezone=US/Eastern
name_service=NONE
timeserver=localhost
network_interface=PRIMARY {netmask=255.255.255.0}
root_password=XxXxXxXxXxXxX
For the most part, this will never change. The only item that has a chance of changing is the network_interface parameter. The "PRIMARY" interface will usually default to hme0. Thus, you might want to make this qfe0, or whatever is appropriate. Note that the name_service is set explicitly to "NONE". Solaris trys to do wacky things if you attempt to use thier DNS setup. This will be tuned later in the scripts section. If you want to customize the sysidcfg file further, you can look at the documentation.
All the profiles that are used are very similar. You can take a look at the 4GB, 9GB or 18GB profiles, and see that they are vary by parition size. They each configured so when you 'JumpStart' a machine, it will:
Also note that a small 10MB partition 7 is named /mirror, so that the disk can be later mirrored with SDS. It's unlikely you'll need to create a custom profile.
As you can see from the rules file above, all profiles use the same begin and end scripts. This is where most of the work is done. For the most part, the ivil_begin does nothing. It's just there so it can be used in the future. However, the ivil_finish is the meat-n-potatoes of the custom JumpStart. Specifically, it does:
All of these scripts depend upon the NFS mount. While the ivil_finish does double-check to make sure that the /tmp/jump/etc directory is there, it it worth noting that without the NFS mount, none of the customizations will work. Thus, if the JumpStart server ever changes, subnets, networks, etc. the ivil_finish script will need to be edited so that the network information about the NFS server is updated.
Basically, patch_finish is a modification of the patch script included with the Solaris OS that installs patches that were available when the CD for the OS was masters. For our usage, the variable SOL_PATCHDIR will be pointint to the directory /tmp/jump/patch/recommended/7_Recommended. More information can be obtained from the comments in the beginning of the script itself:
#!/sbin/sh # # iVillage modified patch_finish # ATonns Thu Aug 30 12:49:37 EDT 2001 # # Modifications are as follows: # # 1) SOL_PATCHDIR has been changed to reflect the location of the # NFS mounted patch directory # 2) The order which patches are installed is no longer determined by: # patches=`\ls -rt .` # instead it is done by: # patches=`cat $SOL_PATCHDIR/patch_order` # # You can diff the patch_finish.orig with the copy from the Solaris CD # (/cdrom/sol_7_1199_sparc_sun_srvr/s0/Solaris_2.7/Tools/Boot/usr/sbin/install.d/install_config/patch_finish) # to check to see if there has been any additional updates
This is a big pkgadd for-loop based upon the packages in /jump/pkg. The file /jump/pkg/pkg_order determines what order the packages in the directory are installed, as to prevent dependency problems. Thus, to add more package-based software to your JumpStart server, just pkgtrans the package into a directory package, move it to /jump/pkg and add it's package name to the pkg_order file.
This is the most complex of all the JumpStart scripts. There are several dozen customizations that are performed, all using the most basic of UNIX tools that are part of the installation OS boot. As of now (2001/10/22) here are the customizations that are performed:
Yeah, you know me.
To enable you to update the OpenBoot PROM (OBP) quickly and over the network, you need the latest OBP patches. The patch-id's as of 2001/10/22 are [Sunsolve login required]:
Uncompress and untar them in /jump/var/OBP and then:
cp 104169-08/flash-update-Ultra2-latest /jump/os/Solaris_2.7/Tools/Boot/u2flash cp 104881-07/flash-update-Ultra1-latest /jump/os/Solaris_2.7/Tools/Boot/u1flash
Now you just need to "boot net /u2flash" or "boot net /u1flash" once add_install_client has been run to update the OBP.
Assuming you've downloaded the latest 7_Recommended.zip into /tmp, this can be done in five (or six) simple steps:
cd /jump/patch
mv recommended recommended.old
mkdir recommended
cd recommended
unzip -q /tmp/7_Recommended.zip
cd..; rm -rf recommended.old
pkgtrans filename.pkg . allEach package will be in it's own directory.