Boot Server Guide

This information pertains to Solaris 9.

In order to install any system over the network without installation media, it is required that the client have a boot server available to it somewhere on the local subnet. The information provided in these pages will explain how to install and configure a Boot Server on your subnet so that you can use any of the Solaris network installation tools.

Using IT&S's Boot Server
If you do not have root access to another Sun system on your network, you can arrange to use IS&T's boot server by bringing your CPU to our office (we will supply a monitor and keyboard). In addition, if this is your first Sun equipment purchase, we will do the installation for you at no cost. Additional installs or reinstalls are done at our normal time and materials rate. You should contact the Systems Support Manager to coordinate either of these. All requirements for DNS registration and other information needed to install your system will be discussed with your at this time.

Setting Up Your Own Bootserver
Given the length of this document, it has become necessary to break it into sections. It is possible to read straight through this document, but this Table of Contents may be useful to those who need only review certain sections of it.

Installing A Boot Server

Running a Boot Server with a Name Service

Running a Boot Server without a Name Service

Configuring a Boot Server

Installing A Boot Server
In order to use IS&T's Install Server you must have access to a boot server on the local subnet. The boot server requires approximately 250MB of disk space.

Installing the Boot Server image
Before you can install a Boot Server, you must get access to IS&T's Install Server, which you will use to make your own Boot Server. You should contact the IS&T Systems Support Manager or your departmental Support Contact to obtain access to the server for your intended Boot Server. Once your request has been processed, you will be able to NFS mount IS&T's installation area from your Boot Server.

After obtaining access to our server, you should do the following as root to install your local Boot Server:

1. mount -F nfs -o ro jumpstart:/export/Sun/licensed/sun4_59/ /mnt
   cd /mnt/Solaris_9/Tools
   ./setup_install_server -b /usr/local/bootserver/sun4_59/
   umount /mnt
2. The /usr/local/bootserver/sun4_59 directory should be empty prior to running this command, or not exist. You will need to have 250MB free in /usr/local/ to install the server. The installation may take some time to complete.
3. Note that you can choose to install the server anywhere that you have sufficient free space. /usr/local/bootserver is the IS&T promoted standard installation point. If you choose to install boot server files elsewhere, you might want to make a link from /usr/local/bootserver to your chosen installation point. Remember to make adjustments to paths, etc. whenever you choose a non-standard location.
   

   Setting up services on the Boot Server
   After you have the boot server installed you, will need to make sure the following services are enabled in /etc/inet/inetd.conf:

• time, which is required by the client to set an initial time of day.
• tftp, which is required for booting.
  
  In addition, you should create the tftpboot area, as specified in the inetd.conf, and make a symlink from /tftpboot to point to it. Then, you should edit the file /etc/dfs/dfstab to share your boot server directory with your install clients. The file should contain a line like:
  
  share -F nfs -o ro=<install_client>,anon=0 /usr/local/bootserver
  
  where <install_client> is the name of the install client, or a colon separated list of install clients. For security and to maintain licensing, you should NOT export the directory to the world as this is a security risk and violates our license agreements.
  
  You should then start up some other NFS related services by running the startup script (as root):
  
  /etc/rc3.d/S15nfs.server start
  
  You should now decide if you will use a nameserver or flat files to control the host configuration and read the appropriate sections.

Running a Boot Server with NIS
If you wish to run NIS on your Boot Server, or already are, you will need to make some modifications to the NIS setup to accommodate the needs of a network installation. Alternatively, you can make a hybrid server that uses NIS for some configuration and not for others, but this document will not address that method. For new boot servers, setting up NIS only makes the Boot Server more difficult to manage and adds security exposures. It is recommended that you do not use NIS to provide configuration to your clients unless you are already running NIS for some other purpose.

Setting up a Name Service

NIS+
The Office of Information Technology has insufficient experience with NIS+ to recommend its use or troubleshoot its configuration. We do fully support NIS and recommend that departments that need a network information service make use of NIS (formerly yp). If you would like to use an NIS+ server, you should consult Sun's documentation on the proper way to set up and configure NIS+ for use with a boot server.

NIS (aka YP)
Attempting to explain how one would set up NIS on a host is beyond the scope of this document. If you are unfamiliar with the ritual involved in setting up NIS on a system, you are best advised to consult Sun's NIS Documentation before attempting to do so.

Configuring NIS to support a Boot Server
In order for a Network Installation of Solaris to be non-interactive you need to extend your name service beyond its default settings. The default NIS setup lacks timezone, netmask, and locale maps that are required, and you must specify your "timehost" in /etc/hosts.

1. Creating the files from which the maps will be generated
   
   /etc/netmasks
   
   You should make sure that the file /etc/netmasks exists and that it minimally contains the following three entries:
   
   128.197.0.0 255.255.255.0
   168.122.0.0 255.255.255.0
   155.41.0.0 255.255.255.0
   
   These entries define the Class B subnets that make up the BU domains and their associated netmasks. In truth, you only need the one entry that is relevant for the subnet the boot server is on, but it doesn't hurt to have all three and it might help you someday.
   
   /etc/timezone
   
   This file may not exist by default. You should create it, and it should be of the form:
   
   <timezone> <name service domain>
   
   A host in the name service domain chocolate in the Eastern Time Zone of the US would have the following entry:
   
   US/Eastern chocolate
   
   Note that this is the NIS domain name, not the DNS domain name (bu.edu).
   
   /etc/locale
   
   This file may not exist by default. You should create it, and it should be of the form:
   
   <locale> <name service domain>
   
   A host in the name service domain chocolate and using the 7 bit English Locale would have the following entry:
   C chocolate
   
   A host in the name service domain chocolate and using the 8 bit English Locale would have the following entry:
   en_US chocolate
   
   Note that this is the NIS domain name, not the DNS domain name (bu.edu).
   
2. Modifying the Makefile for NIS
   
   The Makefile for the NIS maps located in /var/yp/ will not make the locale map that is required for jumpstart. You must add the following to have NIS build this map.
   
   locale.time: $(DIR)/locale
   -@if [ -f $(DIR)/locale ]; then \
   sed -e "/^#/d" -e s/#.*$$// $(DIR)/locale \
   | awk '{for (i = 2; i<=NF; i++) print $$i, $$0}' \
   | $(MAKEDBM) - $(YPDBDIR)/$(DOM)/locale.byname; \
   touch locale.time; \
   echo "updated locale"; \
   if [ ! $(NOPUSH) ]; then \
   $(YPPUSH) locale.byname; \
   echo "pushed locale"; \
   else \
   : ; \
   fi \
   else \
   echo "couldn't find $(DIR)/locale"; \
   fi
   
   You should then find the "all" instruction in the Makefile (the line that starts with "all: "). You should add the word "locale" to the line (without the quotes).
   
   On the next line, add the following:
   locale: locale.time
   
   The all line instructs the NIS server on what to build when someone runs 'make' in /var/yp/. The locale entry that you added tells it to build the locale map. The single line you added, "locale: locale.time" says to follow the locale.time make instruction to build the locale map. The large section of text you added tells NIS how to build the map (what it should look like).
   
3. Adding the nicknames
   
   In order for NIS to find all of the maps, you must supply "nicknames" for the maps to the NIS server. The nicknames as defined in /var/yp/nicknames.
   
   You should add the following nicknames to your nicknames file:
   timezone timezone.byname
   netmasks netmasks.byaddr
   locale locale.byname
   
   Amongst other things, this will allow you to run command like "ypcat timezone" to verify the the timezone map is correct.
   
4. Adding a timehost
   
   In order for a network install process to not ask you what time it is you must specify where the install client is to get the current time. You can provide this service from your boot server by making sure that the "time" service is uncommented in the /etc/inet/inetd.conf file. A quick test is to telnet to port 37 on your host. If you get some garbage back, then you are running the time service. If you get "Connection Refused", you aren't.
   
   On a host that is running the time service:
   % telnet localhost 37
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   ·Éf±Connection closed by foreign host.
   
   On a host that is not:
   % telnet localhost 37
   Trying 127.0.0.1...
   telnet: Unable to connect to remote host: Connection refused
   
   If you are not running a time server, you can either modify the /etc/inet/inetd.conf file to use the time service and restart inetd, or you can just use the campus time server, BU.EDU. In either case, you should add the word "timehost" after the host entry in /etc/hosts.
   
   The proper entry for BU.EDU in your /etc/hosts file would be:
   128.197.27.7 bu.edu timehost
   
   Again, if you are providing the time service on your Boot Server, or any other Sun host on your network, you can simply add "timehost" after that host's name in the /etc/hosts file.
   
5. Rebuilding the NIS maps
   
   All of these maps must exist in the NIS database before a client can be made to install in a non-interactive fashion. After the first four steps are complete, you can change directory (cd) to /var/yp and run /usr/ccs/bin/make, which will produce the NIS maps. You will have to run this command again after configuring the client, as the configuration process will update the bootparams and ethers files.
   

Setting up the sysidcfg file
If you are planning to customize the configuration of your host, or wish to do an installation without having NIS or NIS+ running on your Boot Server, you should create a configuration directory for your Boot Server. A sample sysidcfg file is provided with the Solaris 9 boot server when you install it.

The file is located in:
/usr/local/bootserver/sun4_59/Solaris_9/Tools/Boot/config/
or /usr/local/bootserver/sun4_59/Solaris_9/config/

You will note that the sysidcfg file is actually a symlink to sysidcfg.default.hme0. There is also a sysidcfg.default.ge0, sysidcfg.default.eri0 and sysidcfg.default.le0 file present. You will need to select the appropriate file and symlink to it according to the type of network interface present on your system. Most UltraSparc Systems have a 100Mb/s interface, which uses the hme driver and sysidcfg file. Older systems will need the sysidcfg.default.le0 file instead. Sun Blades have a RIO interface that requires the sysidcfg.default.eri0 file. Systems that utilize the Gigabyte interface requires the sysidcfg.default.ge0 file. Note that you will need to create files of your own if you intend to have the system use an interface other than its primary interface to boot.

The actual path to the sysidcfg file is set in the bootparams file, so it can be anywhere with the bootserver tree, but IS&T promotes keeping this kind of configuration in one place. The sysidcfg file allows you to specify a number of configuration variables that previously required the use of NIS or NIS+ to avoid interactive installation. To do this, you must set a number of variables within the file.

The following is an example of a valid sysidcfg file. With the exception of root_password and terminal, removing any line from this file will cause an interactive installation. If you are using a serial line console and you remove the terminal keyword, the installation will also become interactive. If you are using a graphics card and monitor, you can safely remove the terminal directive.

Keywords in the sysidcfg file
(The following content is adapted from the Solaris 9 Installation Guide.)

• name_service
  • The name_service keyword is used to specify what type of name_service the install client is to use during the installation and following the installation. The valid types are NIS, NIS+, DNS, and NONE.
  • Additional information is required if you select NIS or NIS+ by using the keywords domain_name and name_server inside curly brackets. In addition, the name_server may be followed by parenthesis including the IP address of the name server.
    • name_service=NIS {domain_name=example name_server=names(128.197.0.1)} would instruct the client to bind to domain "example" using nameserver "names" located at IP address 128.197.0.1.
  • Additional information is required if you select DNS bu using the keywords domain_name, name_server, and search inside curly brackets. A maximum of six search domains can be provided.
    • name_service=DNS {domain_name=bu.edu name_server=128.197.27.7 search=bu.edu} would instruct the client to use the DNS server on 128.197.27.7 to lookup names, searching the bu.edu domain for unqualified names.
• network_interface
  • This enables you to set several features about the hosts network interface. The keyword can have values of NONE, PRIMARY, or a valid value. You can use the value to switch between a 10Mb ethernet and 100Mb ethernet, for example, by specifying that the host should use network_interface=hme0 rather than le0.
  • Several sub keywords allow you to specify the hostname, IP address and netmask. These are set using the keywords hostname, ip_address, and netmask respectively.
  • This enables you to set the netmask of specific interfaces. A usage example is:
    • network_interface=le0 {netmask=255.255.255.0}
  • Starting in Solaris 8 you also need ipv6=no to avoid questions on boot up. This is the correct answer for all BU Campus systems. BU does not have any IPv6 deployment in place.
  • Starting in Solaris 9 you also need default_route=NONE to avoid questions on boot up. This is the correct answer for all BU Campus systems. The default route is set via the MASTERFINISH script. >
    

• Root Password
  • If you specify an encrypted root password in the sysidcfg file then this password will be set for root by the security module in the finish script, overriding the default jumpstart password mentioned in the overlay module. An example of use (don't use this one!) is:
    • root_password=m4QPOWNY
• Locale
  • You may select any locale you like, but most people will select either the traditional 7-bit English locale (C) or the newer 8-bit English Locale (en_US).
    • To set the 7bit locale:
      • system_locale=C
    • To set the 8bit locale:
      • system_locale=en_US
        
        
• Terminal Type
  • This allows you to set the type of console that is attached to the install client. If the host can detect a graphics card with attached monitor, Jumpstart will use this monitor and ignore the Terminal Type declared here. However, this directive is important if you use a client that is using its serial port for the console. The correct terminal type (as specified in /usr/share/lib/terminfo) must be specified here for proper screen mapping.
    
    
• Timezone
  • This enables to you to properly set the timezone of a system. Usage:
    • timezone=US/Eastern
  • The correct assignment is the full pathname to the timezone relative to /usr/share/lib/zoneinfo. It is unlikely you will need anything other than the Eastern Time Zone, so further explanation is not given here. Consult the Solaris 9 Installation Guide if you have questions.
    
    
• Timeserver
  • This points the client to a machine from which it can obtain the current time.Usage:
    • timeserver=128.197.27.7
  • 128.197.27.7 is BU.EDU, which always runs a time service. You may want to send the clients to a host on your local subnet, such as the bootserver to ensure that the machine is up when you are performing your install. The "time" service in must be enabled in the /etc/inetd.conf file on the timeserver.
    
    
• Security Policy
  • Despite an ominous name, this really refers to Kerberos integration. Set this to NONE and let jumpstart take care of it for you.

For a full list of commands and how to set them, see pages 50 through 53 of the Solaris 9 Installation Guide.

The timezone, netmask and locale can be specified via your NIS server as well, if you have one. Some of these settings can also be put in the bootparams map. To use these alternate methods, consult the Solaris 9 Installation Guide. For those who are already using jumpstart and NIS for their installations and need to know how to set up a Locale Map, see pages 54 through 56 of the guide.

Configuring A Boot Server
In order to install Solaris on your client, you must configure the Boot Server with enough information to boot your client across the network. Generically, this includes providing the Boot Server with:

• The Ethernet Address of the Client.
• The hostname and IP address to be used.
• Where the install and configuration host for the client is.
• A tftp image suitable for booting your client.
  • For this you will need the architecture type (sun4m, sun4u, etc.) of your client and the hexadecimal form of your IP address. For example, the IP address of IT.BU.EDU is 128.197.20.40. The hexadecimal conversion of each piece of the quad is 80, C5, 14, 28 respectively.
  The hexadecimal form that I need for the tftp area is the concatenation of all these strings in order: 80C51428.

The boot server must also export the boot server area to your install client.

add_install_client
To make your life easier, Sun has provided the add_install_client command that will configure all of this information for you. The add_client_command requires a number of arguments:

• i for the IP address of the host to install (obtained from the BU Hostmaster)
• e for the ethernet address of the host to be installed (obtained from startup banner)
• s for Install Server (jumpstart.bu.edu)
• c for Configuration Server (jumpstart.bu.edu for Jumpstart installs, not needed for WebStart installs)
• p for sysidcfg file location

To install QAYIN.BU.EDU, which has IP address 128.197.20.26, is a Sparc 5 (which is of architecture type sun4m), with ethernet address 8:0:20:22:8D:88 using IS&T's install and config server and with DATA.BU.EDU as the boot server, you would use the following command:

<bootserver_root>/Solaris_9/Tools/add_install_client -i 128.197.20.26 -e 8:0:20:22:8D:88 -s jumpstart:/export/Sun/licensed/sun4_59/ -c jumpstart:/export/Sun/licensed/sun4_59/jumpstart/ -p data:/usr/local/bootserver/sun4_59/Solaris_9/config/ qayin sun4m


The last argument to the command is the platform_group, otherwise known as the architecture type. A list of hardware types and their associated platform_groups can be found in the Solaris 9 Sun Hardware Platform Guide, pages 2 through 4.


This somewhat long command (that's all one line) would do everything necessary to configure the bootserver to properly boot the client. I would then have to add a sysidcfg file to the /usr/local/bootserver/sun4_59/Solaris_9/config/ directory, and if I wanted to, a qayin.cfg file (to control the jumpstart customization) and a subnet.sh and/or qayin.sh file.

Remember to start the rpc.bootparamd daemon manually if you do not reboot your machine the first time you run the add_install_client command.

Manually Configuring the Boot Server
If you prefer to do things manually, you would need to:

• Add the hostname/IP pair to /etc/hosts
• Add the ethernet/hostname pair to /etc/ethers. Remember that the hostname should appear the same way (qualified or unqualified) here as it does in /etc/hosts. To enter the ethernet address, drop leading zeroes and put letters in lowercase.
• Add an entry to the /etc/bootparams that looks similar to the following:
  

  dummy root=jumpstart:/export/Sun/licensed/sun4_59/Solaris_9/Tools/Boot \

  install=jumpstart:/export/Sun/licensed/sun4_59/ boottype=:in \

  install_config=jumpstart:/export/Sun/licensed/sun4_59/jumpstart/ \

  rootopts=:rsize=32768 \

  sysid_config=bootserver:/export/Sun/licensed/sun4_59/Solaris_9/config/

• Add a link in the tftpboot area from the hexadecimal form of the the hosts IP address to inetboot.SUN4U.Solaris_9-1, and a second link from the hexadecimal form of the hosts IP address with .<ARCH> appended to it, where <ARCH> is the architecture type in all caps (such as SUN4U) to the same file.
• Verify the partition containing the boot server image is exported to the client.
• If your Boot Server is running NIS, it may also be necessary to rebuild your NIS maps.

In general, it is easier to use the add_install_client command until you become familiar with the jumpstart layout.

Once you are done with the add_install_client or other configuration you should be sure that your NIS maps are up to date, if applicable, and that the sysidcfg file referenced in the bootparams entry, if any, exists and contains the correct information.

Also, remember to start the rpc.bootparamd daemon manually if your machine hasn't been rebooted since you added the first client to /etc/bootparams.

Hint for obtaining the hexadecimal form of your IP address
Unless you are particularly skilled in base 16 to base 10 conversions, obtaining the hexadecimal form of a decimal number may be a bit daunting. The following example shows how to use the "bc" program (available on most machines) to calculate the address. The user would type everything in bold, the system replies are in italics.

% bc
obase=16
128
80
197
C5
20
14
40
28