Kevin Amorin
kevin@amorin.org
July 12, 2000
Updated: September 1, 2001
Note:
Kevin is currently searching for a full time Sr. Unix Systems position in the Boston area, his resume can be viewed at http://www.amorin.org/professional/resume.php. He thanks you for your interest in this article and can be contacted at kevin@amorin.org with any questions or comments
This is
an introduction to custom automated installation in a Solaris environment. It is
an overview of the necessary systems, services, and configurations needed for
easy client integration into existing corporate environments. General pre and post install modifications
will also be discussed.
The Jumpstart feature is an automatic installation process available in the Solaris operating environment. It allows system administrators to categorize machines on their network and automatically install systems based on the category to which a system belongs.
· Simplifies installations
· Speed - Faster then CD-ROM installation
· Allows unattended installation
· Replication - same systems across the enterprise
All Solaris base installations require some basic
configuration. With Jumpstart, Sun has
enabled the system administrator to avoid repetitive tasks associated with
bringing a sun system online.
· A boot server on the same ethernet segment
· An install server with the Solaris OS
· A Jumpstart configuration server that defines rules and
profiles.
Needed Services |
Use |
NFS (mountd nfsd) |
Sharing Solaris OS Image Files |
Rarp |
IP address discovery |
Bootp |
Host and location of shared file systems |
Rpld |
Serves X86 initial boot net kernel |
Tftp |
Serves Solaris initial boot net kernel |
IMAGE
1.
Client sends a RARP for its IP address
2.
The Boot Server responds via RARPD (in.rarpd) with the IP address in /etc/ethers or
the ethers
NIS/NIS+ map depending on the ethers setting in /etc/nsswitch.conf
3.
The client sends a tftp request for a
bootimage
4.
The server starts in.tftp from inetd and sends
the small net kernel image
5.
The client then sends out a bootp request
6.
The server responds with the clients entry
from /etc/bootparams
7.
The client NFS mount it’s root partition from
the install server
8.
The client then mounts the configuration
server (/jumpstart) and runs “sysidtool”.
9.
It then mounts the install image and runs
Suninstall to begin the install process.
The boot server is composed of rarpd (in.rarpd), bootp (in.bootparamd), and tftp (in.tftpd) servers for solaris systems and rplboot for x86 architecture. The Boot server must be on the client’s local network due to the fact that rarp packets will not be forwarded across a router.
Server Files:
/etc/ethers Contains entry for install
clients ethernet address
8:0:20:ab:cd:ef client_name |
/etc/bootparams Contains NFS share parameters for installation & configuration
client_name root=boot_svr:/export/install/Solaris_2.6/Tools/Boot \ install=boot_svr:/export/install boottype=:in \ sysid_config=boot_svr:/jumpstart \ install_config=boot_svr:/jumpstart rootopts=:rsize=32768 |
/tftpboot Houses the small net kernel used for bootstrapping
C0A8000B C0A8000B.SUN4U inetboot.SUN4U.Solaris_8-1 rm.192.168.0.11 tftpboot |
/rpldboot Used in x86 installs (tftp equivalent)
192.168.0.12.glue.com 192.168.0.12.hw.com 192.168.0.12.inetboot gluecode.com inetboot.I86PC.Solaris_2.7-1 rm.192.168.0.12 smc.com |
One thing to always take into account when designing a jumpstart network is the boot server needs to be on the local net.
The install server supplies the client with the Solaris OS. It is an NFS share with the Solaris install image. Any OS able to export NFS shares is able to serve as a Jumpstart Install Server.
The configuration Sever is comprised of the rules file, profiles, and sysidcfg. It allows the administrator to have available different custom jumpstart configurations based on rule sets. This is very helpful when different groups within an organization require different system configurations.
Below are examples of a profile. Profiles contain filesystem layout and package information.
Example:
# profile keywords profile values # ----------------- ----------------- # This profile keyword is required in every profile install_type initial_install system_type standalone partitioning default filesys any 60 swap filesys s_ref:/usr/share/man - /usr/share/man ro filesys s_ref:/usr/openwin/share/man - /usr/openwin/share/man ro,quota cluster SUNWCprog package SUNWman delete package SUNWolman delete package SUNWxwman delete package SUNWoldem add package SUNWxwdem add package SUNWoldim add
package SUNWxwdim
add |
Example:
profile keywords |
# profile values |
install_type system_type partitioning cluster cluster package filesys filesys |
initial_install standalone default SUNWCuser SUNWCxgl delete SUNWaudmo add any 40 swap any 50 /opt |
A derived profile is a profile that is dynamically created by a begin script during a custom JumpStart installation. Derived profiles are needed when you cannot set up the rules file to match specific systems to a profile (when you need more flexibility than the rules file can provide).
Set the profile field to an equal sign (=) instead of a profile.
Note:
If a begin script is used to create a derived profile,
make sure there are no errors in it. A derived profile is not verified by the check
script because it is not created until the execution of the begin script.
Example:
#!/bin/sh echo "install_type initial_install" > ${SI_PROFILE} echo "system_type standalone" >> ${SI_PROFILE} echo "partitioning default" >> ${SI_PROFILE} echo "cluster SUNWCprog" >> ${SI_PROFILE} echo "package SUNWman delete" >> ${SI_PROFILE} echo "package SUNWolman delete" >> ${SI_PROFILE} echo "package SUNWxwman delete" >> ${SI_PROFILE} |
Verify Profile
After you create a profile, use the pfinstall command to test
the profile before you actually use it to install or
upgrade a system. Testing a profile is especially useful when you are creating
upgrade profiles that reallocate disk space.
Profiles should only be tested on systems with the same architecture
(i386 or sparc) as the Jumpstart clients to ensure accurate results.
# prtvtoc /dev/rdsk/device_name > disk_config # /usr/sbin/install.d/pfinstall disk_configuration [-c path] profile |
The rules file is a text file used to create the rules.ok file. The rules file is a look-up table consisting of one or more rules that define matches between system attributes and profiles. For example, the rule
karch sun4c - basic_prof –
matches a system with a sun4c platform name to the basic_prof profile, which the Solaris installation program would use to install the system.
Figure 3 - How a Custom Jumpstart Installation Works
During a custom Jumpstart installation, the Solaris installation program attempts to match the rules in the rules.ok file in order: first rule through the last rule. A rule match occurs when the system being installed matches any of the values in the rule (as defined in Appendix A). As soon as a system matches a rule, the Solaris installation program stops reading the rules.ok file and begins to install the system as defined by the matched rule's profile. This allows a fine grain control over different configuration clusters (Figure 3).
#### [!]keyword value [&& [!]keyword value] ... begin profile finish # # any - - any_machine - ^ ^ ^ ^ ^ | | | | | | | | | -------------- Finish script | | | --------------- Profile | | -------------- Begin script | ----------- Rule Value (specific system attribute) ----- Rule keyword (general system attributes)
|
Example:
# The following rule matches one system: hostname host1 - host1_class set_root_pw # The following rule matches all x86: arch i386 x86-begin x86-class - # The following rule matches any system: any - - any_machine - karch i86pc - basic_prof - |
Validating the rules file
Before the profile server is able to function the jumpstart share must have a rules.ok file. The check script validates the rules file and creates the rules.ok file.
Usage: check
[-r <rules
filename>] [-p <Solaris 2.x CD image path>] |
When you boot Solaris, a set of programs called sysidtool configures your system, prompting for information needed such as the client’s host name and IP address, the local date and time, the time zone and the netmask. NIS or NIS+ can provide this information, otherwise you have to enter it manually before JumpStart can install the OS and packages. It is also possible to create a sysidcfg file, which must be on either local media or a nfs exported filesystem.
The sysidcfg file is a file where, starting with Solaris 2.6, all the configuration information required during an OS installation can be specified. A change needed to be made to the sysidcfg provided as part of the Jumpstart package in order for the process to work on your local network.
Default values needed
· date & time
· time zone
· site netmask
· language options
Sysidcfg Example:
System_locale=en_US name_service=NONE network_interface=primary {protocol_ipv6=no netmask=255.255.255.0} security_policy=NONE root_password=XXXXXXXXX system_locale=C timezone=US/Eastern timeserver=localhost terminal=sun-cmd |
Note: To use "name_service=NONE" with Solaris 2.6 you will need to load patch 106193-03 or greater. Also to use network_interface=primary on Solaris 2.6, you need patch 106193-0 or greater. Solaris 7 and Solaris 8 do not need any patches
Note: Solaris 8 will prompt for two new options, ipv6, and kerberos. To avoid user interaction you must include answers to these options in the sysidcfg file.
security_policy=NONE (disable kerberos) network_interface=le0{netmask=255.255.255.0
protocol_ipv6=no} |
Pre Solaris 2.6 did not support sysifcfg option. NIS/NIS+ can be used to supply system information
NIS/NIS+ name service
•/etc/hosts
•/etc/timezone
•/etc/netmasks
•/etc/locale
Profile floppy disks cannot be created on a platform with a different architecture than the Jumpstart client. This is due to big/little endian differences that affect the creation of the ufs filesytem. The jumpstart profile diskette may be PCFS or UFS.
Figure 2 - How a Custom JumpStart Installation Works:
Non-Networked Example
The installation utility will look to the floppy drive for all configuration information.
Directory
listing
drwxr-xr-x 4 root other 512 Jan 16 12:58 . drwxr-xr-x 47 root root 1024 Jan 16 13:10 .. -rw-r--r-- 1 root other 182 Jan 16 08:22 any_machine -rwxr-xr-x 1 root other 30029 Jan 15 13:34 check -rw-r--r-- 1 root other 4742 Jan 15 13:34 rules -rw-r--r-- 1 root other 54 Jan 16 08:22 rules.ok -rw-r--r-- 1 root other 188 Jan 15 13:36 sysidcfg |
The x86 Solaris installation cannot be totally automated. The default for installation media is local CD-ROM, you must choose network install at the intro screen.
X86 Solaris install will prompt during the install for openwindows parameters. To be able to automate these values you must pass them to the client through rplboot system.
#kdmconfig -c -s
Take the additions to the /etc/bootparms file and append them to your bootparms entry on the boot server
These values can also be found in
/etc/openwin/server/etc/owconfig
/etc/defaultkb
- /etc/defaultrouter
- /etc/resolv.conf
A begin/finish script is a user-defined Bourne shell script, specified within the rules file, which performs tasks after the Solaris software is installed on the system.
variables |
|
Variable |
Description |
ROOT |
The rootdisk's mountpoint
(/a). |
TOOLSDIR |
Directory where our tools
are found. The mountpoint for: /export/jumpstart/Tools |
BACKUPDIR |
Directory to store all
files and other information that need to be backed up for the particular
machine. |
ROOTDEV |
The root disk device
specified as an argument to migrate.begin. |
PKGDIR |
Where packages are
installed on the server (migrate.end only). |
JUMPSTARTDIR |
The JumpStart directory
on the server. |
Begin/Finish details
· The Solaris installation program mounts the system's file systems onto /a. The file systems remain mounted on /a until the system reboots. Therefore, you can use the finish script to add, change, or remove files from the newly installed file system hierarchy by modifying the file systems respective to /a.
· Output from the finish script goes to /var/sadm/finish.log.
· Finish scripts should be owned by root and have permissions equal to 644.
Server
1. Create install server(s).
2. Create a profile server
3. Create profiles
4. Create begin and finish scripts
5. Create and check rules file
Client
6. Add Client(s)
7. Boot Client(s)
Server
Setup
1. The first step copies the Solaris CD to the disk. You will need around 450Mb of free space in this directory.
# cd /cdrom/cdrom0/s0/Solaris_2.6/Tools
# ./setup_install_server /export/Solaris_2.6
Verifying target directory...
Calculating the required disk space for the Solaris_2.6 product
Copying the CD image to disk...
Install Server setup complete
#
Note: for Solaris 8 if you would like to include CD 2 (Supplemental), insert CD 2 and run
# cd /cdrom/cdrom0/s0/Solaris_8/Tools
#./add_to_install_server /export/Solaris_2.6
2. Creating a Profile server
#cp -r /cdrom/cdrom0/s2/Solaris_2.6/Misc/jumpstart_sample/* /jumpstart
#share -F nfs -o ro,anon=0 /jumpstart
#shareall
3. Create profiles (Reference Profiles)
Copy profile into /jumpstart directory
4. Create begin and finish scripts (Reference begin/finish scripts)
Copy scripts into /jumpstart directory
5. Create and check rules file (Reference Rules)
#cd /jumpstart
#./check
# cd
/jumpstart
# ./check
Validating rules...
Validating profile any_machine...
The
custom JumpStart configuration is ok.
# cat rules.ok
any - - any_machine -
6. Adding the Install Client
#vi /etc/hosts
127.0.0.1 localhost
127.0.0.2 129.151.29.1 boot_svr loghost
127.0.0.3 129.151.29.10 client_name
#./add_install_client –e <CLIENT_ETHERNET_ADDRESS> -s <INSTALL_SERVER>:<OS_IMAGE_DIRECTORY -c <CONFIG_SERVER>:<CONFIGURATION_DIRECTORY> -p <CONFIG_SERVER>:<PATH_TO_SYSIDCFG_FILE> -n [SERVER]:name_service[netmask] (The brackets "[]" are needed!!!) CLIENT_NAME ARCHITECTURE |
Add the client information to the server
# cd /jumpstart/Solaris_2.6/Tools
# ./add_install_client \
-e 8:0:20:7a:22:7e \
-t /jumpstart/Solaris_2.6/Tools/Boot \
-p server.rainmonkey.org:/jumpstart \
-c server.rainmonkey.org:/jumpstart \
-s server.rainmonkey.org:/export/Solaris_2.6 \
client.rainmonkey.org \
sun4u
Note: There must be an entry in the /etc/hosts for client.rainmonkey.org and server.rainmonkey.org
Client
Booting the Jumpstart Client
At the OpenBoot prompt enter
Upgrade:
#
reboot "net -
install"
ok> boot net -
install
Resetting ...
SPARCstation 20 MP (2 X SuperSPARC-II), No Keyboard
ROM Rev. 2.25, 64 MB memory installed, Serial #8004222.
Ethernet address 8:0:20:7a:22:7e, Host ID: 727a227e.
Initializing Memory |
Boot device: /iommu/sbus/ledma@f,400010/le@f,c00000 File and args: -
hostname: client.rainmonkey.org
domainname: rainmonkey.org
root server: server
root directory: /solaris_2.6/export/exec/kvm/sparc.sun
|
Copyright (c) 1983-1994, Sun Microsystems, Inc.
|
/
-
The system is coming up. Please wait.
Note: New machines will net boot at power on
The USparc II 450Mhz systems will not show the correct arch under sysidtool
http://www.freeware4sun.com/patches/README/106154-01.README
Q1: How do I configure my Boot server if it is a NIS client and I wish to
use sysidcfg file for my Jumpstart setup?
A1: To achieve that, we need to change /etc/nsswitch.conf to ensure that the
Server searches for local files first before using NIS. i.e. change hosts, ethers and
bootparams: in the nsswitch.conf file to:
hosts: files nis
ethers: files nis
bootparams: files nis
After which, we need to add to the /etc/hosts file the IP address and
hostname of the new client to be installed. We do not need to create or amend the
/etc/ethers and /etc/bootparams files. These files will be altered accordingly after we
execute the "add_install_client" command.
Q2: Can I have all Configuration, Install and Boot server functions on a
Single host?
A2: Yes.
Q3: After I have setup my Configuration/Install/Boot servers, I ran "boot net
- install" on the client and it gave me:
No bootparam (whoami) server responding; still trying...
RPC: Timed out.
A3: The ethernet address of the client is not set correctly on the Boot
server. Check that the /etc/ethers file on the Boot server has the correct ethernet
address of the client. If NIS is used for Jumpstart setup, make sure that the NIS
master server executes "make" to rebuild the network NIS maps, after the /etc/ethers
file is updated.
Q4: After I have setup my Configuration/Install/Boot servers, I ran "boot net
- install" on the client and it gave me:
root directory: /cdrom/sol_7_sparc/s0/Solaris_2.7/Tools/Boot
panic - boot: Could not mount filesystem.
A4: The filesystem with the installation directory on the Install server is
not shared. Also, make sure that, on the Configuration server, the directory with
all the rules, classes and sysidcfg files are shared.
Q5: Half way through, during the installation of the client, it stopped and
Asked for user input in one of its sysidtool or installtool dialog boxes.
A5: It means that the class or sysidcfg file has not been set up correctly.
Make sure that all the essential entries are included. Commonly omitted entries are:
"system_locale" and "timezone" for the sysidcfg file; and "locale" for the
class file.
Snoop Output
1 0.00000
OLD-BROADCAST -> (broadcast) RARP C
Who is 0:a0:24:d2:f6:34 ?
2
3.00626 pikachu ->
togepi RARP R 0:a0:24:d2:f6:34 is
192.168.0.12, togepi
3
0.00078 togepi ->
BROADCAST BPARAM C WHOAMI?
192.168.0.12
4
0.00862 pikachu ->
togepi BPARAM R WHOAMI? togepi in
5
0.00054 togepi ->
(broadcast) ARP C Who is 192.168.0.1,
192.168.0.1 ?
6
0.00006 192.168.0.1 ->
togepi ARP R 192.168.0.1,
192.168.0.1 is 0:90:27:d0:fd:27
7
0.00037 togepi ->
pikachu BPARAM C GETFILE root
8
0.00163 pikachu ->
togepi BPARAM R GETFILE
File=/export/install/2.6/x86/Solaris_2.6/Tools/Boot
9
0.00073 togepi ->
pikachu PORTMAP C GETPORT
prog=100005 (MOUNT) vers=1 proto=UDP
10
0.00122 pikachu ->
togepi PORTMAP R GETPORT
port=32774
11
0.00075 togepi ->
pikachu MOUNT1 C Mount
/export/install/2.6/x86/Solaris_2.6/Tools/Boot
12
0.00281 pikachu ->
togepi MOUNT1 R Mount OK FH=CE64
13
0.01728 togepi ->
pikachu NFS C LOOKUP2 FH=CE64 etc
14
0.00099 pikachu ->
togepi NFS R LOOKUP2 OK FH=8298
15
0.00066 togepi ->
pikachu NFS C LOOKUP2 FH=8298
bootrc
16
0.00040 pikachu ->
togepi NFS R LOOKUP2 OK FH=6C1F
17
0.00068 togepi ->
pikachu NFS C GETATTR2 FH=6C1F
18
0.00038 pikachu ->
togepi NFS R GETATTR2 OK
19
0.00075 togepi ->
pikachu NFS C GETATTR2 FH=6C1F
20
0.00034 pikachu ->
togepi NFS R GETATTR2 OK
21
0.00086 togepi ->
pikachu NFS C READ2 FH=6C1F at 0
for 1344
http://www.sun.com/blueprints/0300/sysidcfg.pdf
http://www.sun.com/software/solutions/blueprints/1099/jumpstart.pdf
http://xi.nu/~jheiss/js/lisa99/paper.html
http://www.octaldream.com/scottm/talks/jsintro/img3.htm
Kasper, Paul Anthony and Alan L. McClellan. Automating Solaris Installations. Prentice Hall, April 1995. ISBN: 013312505X.
http://docs.sun.com/ab2/coll.214.4/SPARCINSTALL/
http://wwwwswest.sun.com/smcc/solaris-migration/cookbook/jump1.html
http://www.sun.com/blueprints/0300/sysidcfg.pdf
http://sunsolve.sun.com/private-cgi/retrieve.pl?doc=faqs%2F3172
http://sunsolve.sun.com/private-cgi/retrieve.pl?doc=infodoc%2F16484&zone_32=jumpstart
Kevin Amorin graduated from Worcester Polytechnic Institute (http://www.wpi.edu/) with a BS in Computer Science. He can be reached at kevin@amorin.org. He is involved in most any random sport in his hometown of Attleboro, MA and can be found lounging about with Mr. David Laporte (dlaporte@harvard.edu) a close friend.
8/21/01 - Updated - Thanks to Dan Harris (Dan.D.Harris@smsc.com) for his review and revisions.
Table 18 –
Syntax Elements of a Rule |
|
Element |
Description |
! |
Is a symbol used before a keyword to indicate negation. |
Rule_keyword |
Is a predefined lexical unit or word that describes a general system attribute, such as host name (hostname) or memory size (memsize). It is used with the rule value to match a system with the same attribute to a profile. See Table 19 for the list of rule keywords. |
Rule_value |
Is a value that provides the specific system attribute for the corresponding rule keyword. Rule values are described in Table 19 . |
&& |
Is a symbol you must use to join rule keyword and rule value pairs together in the same rule (a logical AND). During a custom JumpStart installation, a system must match every pair in the rule before the rule matches. |
begin |
Is the name of an optional Bourne shell script that can be executed before the installation begins. If no begin script exists, you must enter a minus sign (-) in this field. All begin scripts must be located in the JumpStart directory. Information about how to create begin scripts is presented in Creating Begin Scripts . |
profile |
Is the name of a text file that defines how the Solaris software is to be installed on the system when a system matches the rule. The information in a profile consists of profile keywords and their corresponding profile values. All profiles must be located in the JumpStart directory. Note - Optional ways to use the profile
field are described in Using
a Site-Specific Installation Program and Creating
Derived Profiles With a Begin Script . |
finish |
Is the name of an optional Bourne shell script that can be executed after the installation completes. If no finish script exists, you must enter a minus sign (-) in this field. All finish scripts must be located in the JumpStart directory. Information about how to create finish scripts is presented in Creating Finish Scripts . |
Table 4-2 Profile
Keyword and Profile Value Descriptions (1 of 10) |
|
Profile Keyword |
Profile Values
and Description |
|
|
client_arch |
karch_value client_arch defines that the server will support a different platform group than it uses. If you do not specify client_arch, any diskless client must have the same platform group as the server. You must specify client_arch once for each platform group. Valid values for karch_value are sun4d, sun4c, sun4m, or i86pc. (See Appendix C, "Platform Names and Groups" for a detailed list of the platform names of various systems.) Restriction: client_arch can be used only when system_type is specified as server. |
Client_root |
root_size client_root defines the amount of root space (root_size in Mbytes) to allocate for each client. If you do not specify client_root in a server's profile, the installation software will automatically allocate 15 Mbytes of root space per client. The size of the client root area is used in combination with the num_clients keyword to determine how much space to reserve for the /export/root file system. Restriction: client_root can be used only when system_type is specified as server. |
Client_swap |
swap_size client_swap defines the amount of swap space (swap_size in Mbytes) to allocate for each diskless client. If you do not specify client_swap, 24 Mbytes of swap space is allocated. Example: client_swap 32 This example sets each diskless client with a swap space of 32 Mbytes. Restriction: client_swap can be used only when system_type is specified as server. |
|
Table 4-2 Profile
Keyword and Profile Value Descriptions (2 of 10) |
||
Profile Keyword |
Profile Values and Description |
|
cluster |
group_name
(use for software groups) cluster
designates what software group to add to the system. The cluster names for
the software groups are found in Appendix C. |
|
:Table
4-2 Profile Keyword and Profile Value Descriptions (3 of 10) |
||
Profile
Keyword |
Profile
Values and Description |
|
|
|
|
dontuse |
disk_name dontuse designates a disk that the Solaris installation program should not use when partitioning default is specified. You can specify dontuse once for each disk, and disk_name must be specified in the form cxtydz or cydz, for example, c0t0d0. By default, the Solaris installation program uses all the operational disks on the system. Restriction: You cannot specify the dontuse keyword and the usedisk keyword in the same profile. |
|
fdisk |
disk_name type size fdisk defines how the fdisk partitions are set up on an x86 system (only required for x86 systems), and you can specify fdisk more than once. This is what happens by default with fdisk partitions on x86 systems: · All fdisk partitions on the disk are preserved unless you specifically delete them with the fdisk keyword (if size is delete or 0). Also, all existing fdisk partitions are deleted when size is all. · A Solaris fdisk partition that contains a root file system is always designated as the active partition on the disk (an x86 system boots from the active partition by default). · If no fdisk keyword is specified in a profile, the following fdisk keyword is specified during the installation: fdisk all solaris maxfree · fdisk entries are processed in the order they appear in the profile. disk_name - Choose where the fdisk partition will be created or deleted: · cxtydz or cydz - A specific disk, for example, c0t3d0. · rootdisk - The disk where the root file system is placed during an installation, which is determined by the Solaris installation program (described on page 87). · all - All the selected disks. type - Choose what type of fdisk partition will be created or deleted on the specified disk: · solaris - A Solaris fdisk partition (SUNIXOS fdisk type). · dosprimary - An alias for primary DOS fdisk partitions (not for extended or data DOS fdisk partitions). When deleting fdisk partitions (size is delete), dosprimary is an alias for the DOSHUGE, DOSOS12, and DOSOS16 fdisk types (they are all deleted). When creating an fdisk partition, dosprimary is an alias for the DOSHUGE fdisk partition (a DOSHUGE fdisk partition is created). |
|
.
Profile keywords that can be used for upgrading |
||
Table 4-2 Profile
Keyword and Profile Value Descriptions (4 of 10) |
|||
Profile Keyword |
Profile Values and Description |
||
Table 4-2 Profile
Keyword and Profile Value Descriptions (5 of 10) |
|||
Profile Keyword |
Profile Values
and Description |
||
|
|
||
filesys
(use for mounting remote file systems) |
server:path server_address mount_pt_name [mount_options] This instance of filesys sets up the installed system to automatically mount remote file systems when it boots. You can specify filesys more than once. For Dataless Clients: Profiles for dataless clients (when system_type dataless is specified) must include a remote filesys entry for both the /usr file system. The following line is an example of the filesys entries that must be used in a profile to install the Solaris software on a dataless client: filesys sherlock:/export/exec/Solaris_2.4_sparc.all/usr - /usr server: - The name of the server where the remote file system resides (followed by a colon). path - The remote file system's mount point name, for example, /usr or /export/home. server_address - The IP address of the server specified in server:path. If you don't have a name service running on the network, this value can be used to populate the /etc/hosts file with the server's host name and IP address. If you don't want to specify the server's IP address (if you have a name service running on the network), you must specify a minus sign (-). mount_pt_name - The name of the mount point that the remote file system will be mounted on. mount_options - One or more mount options (-o option of the command) that are added to the /etc/vfstab entry for the specified mount_pt_name. Note: If you need to specify more than one mount option, the mount options must be separated by commas and no spaces. For example: ro, quota |
||
. Profile keywords that can be used for upgrading |
|||
Table 4-2 Profile
Keyword and Profile Value Descriptions (6 of 10) |
|
Profile Keyword |
Profile Values
and Description |
|
|
filesys
(use for creating local file systems) |
slice size [file_system] [optional_parameters] This instance of filesys creates local file systems during the installation. You can specify filesys more than once. slice - Choose one of the following: · any - The Solaris installation program places the file system on any disk. Restriction: any cannot be specified when size IS existing, all, free, start:size, or ignore. · cwtxdysz or cxdysz - The disk slice where the Solaris installation program places the file system, for example, c0t0d0s0. · rootdisk.sn - The logical name of the disk where the installation program places the root file system. The sn suffix indicates a specific slice on the disk. size - Choose one of the following: · num - The size of the file system is set to num (in Mbytes). · existing - The current size of the existing file system is used. Note: When using this value, you can change the name of an existing slice by specifying file_system as a different mount_pt_name. · auto - The size the file system is automatically determined depending on the selected software. · all - The specified slice uses the entire disk for the file system. When you specify this value, no other file systems can reside on the specified disk. · free - The remaining unused space on the disk is used for the file system. Restriction: If free is used as the value to filesys, it must by the last filesys entry in a profile. · start:size - The file system is explicitly partitioned: start is the cylinder where the slice begins; size is the number of cylinders for the slice. |
. Profile keywords that can be used for upgrading |
Table 4-2 Profile
Keyword and Profile Value Descriptions (7 of 10) |
|
Profile Keyword |
Profile Values
and Description |
|
|
filesys
(use for creating local file systems) continued |
slice size [file_system] [optional_parameters] file_system - You can use this optional value when slice is specified as any or cwtxdysz. If file_system is not specified, unnamed is set by default, but then you can't specify the optional_parameters value. Choose one of the following: · mount_pt_name - The file system's mount point name, for example, /var. · swap - The specified slice is used as swap. · overlap - The specified slice is defined as a representation of a disk region (VTOC value is V_BACKUP). By default, slice 2 is an overlap slice that is a representation of the whole disk. Restriction: overlap can be specified only when size is existing, all, or start:size. · unnamed - The specified slice is defined as a raw slice, so slice will not have a mount point name. If file_system is not specified, unnamed is set by default. · ignore - The specified slice is not used or recognized by the Solaris installation program. This could be used to ignore a file system on a disk during an installation, so the Solaris installation program can create a new file system on the same disk with the same name. optional_parameters - Choose one of the following: · preserve - The file system on the specified slice is preserved. Restriction: preserve can be specified only when size is existing and slice is cwtxdysz. · mount_options - One or more mount options (-o option of the mount(1M) command) that are added to the /etc/vfstab entry for the specified mount_pt_name. Note: If you need to specify more than one mount option, the mount options must be separated by commas and no spaces. For example: ro, quota |
. install_type |
initial_install | upgrade install_type defines whether to perform the initial installation option or upgrade option on the system. Restriction: install_type must be the first profile keyword in every profile. |
. Profile keywords that can be used for upgrading |
Table 4-2 Profile
Keyword and Profile Value Descriptions (8 of 10) |
|
Profile Keyword |
Profile Values and Description |
.
Language |
locale_name |
||
Chinese |
zh |
||
French |
fr |
||
German |
de |
||
Italian |
it |
||
Japanese |
ja |
||
Korean |
ko |
||
Latin American |
es |
||
Swedish |
sv |
||
Taiwanese |
zh_TW |
||
Table 4-2 Profile
Keyword and Profile Value Descriptions (9 of 10) |
|||
Profile Keyword |
Profile Values
and Description |
||
|
|
||
. package |
package_name [add | delete] package designates whether a package should be added to or deleted from the software group that will be installed on the system. add or delete indicates whether the package should be added or deleted. If you do not specify add | delete, add is set by default. package_name must be in the form SUNWname. Use the pkginfo -l command or Admintool (select Software from the Browse menu) on an installed system to view detailed information about packages and their names. For Upgrade: · All packages already on the system are automatically upgraded. · If you specify package_name add, and package_name is not installed on the system, the package is installed. · If you specify package_name delete, and package_name is installed on the system, the package is deleted before the upgrade begins. · If you specify package_name delete, and package_name is not installed on the system, the package is prevented from being installed if it is part of a cluster that is designated to be installed. |
||
. Profile keywords that can be used for upgrading |
|||
Table 4-2 Profile
Keyword and Profile Value Descriptions (10 of 10) |
|
Profile Keyword |
Profile Values
and Description |
|
|
partitioning |
default | existing | explicit partitioning defines how the disks are divided into slices for file systems during the installation. If you do not specify partitioning, default is set. default - The Solaris installation program selects the disks and creates the file systems on which to install the specified software, except for any file systems specified by the filesys keyword. rootdisk is selected first; additional disks are used if the specified software does not fit on rootdisk. existing - The Solaris installation program uses the existing file systems on the system's disks. All file systems except /, /usr, /usr/openwin, /opt, and /var are preserved. The installation program uses the last mount point field from the file system superblock to determine which file system mount point the slice represents. Restriction: When specifying the filesys profile keyword with partitioning existing, size must be existing. explicit - The Solaris installation program uses the disks and creates the file systems specified by the filesys keywords. If you specify only the root (/) file system with the filesys keyword, all the Solaris software will be installed in the root file system. Restriction: When you use the explicit profile value, you must use the filesys profile keyword to specify which disks to use and what file systems to create. |
system_type |
standalone | dataless | server system_type defines the type of system being installed. If you do not specify system_type in a profile, standalone is set by default. |
Usedisk |
disk_name usedisk designates a disk that the Solaris installation program will use when partitioning default is specified. You can specify usedisk once for each disk, and disk_name must be specified in the form cxtydz or cydz, for example, c0t0d0. If you specify the usedisk profile keyword in a profile, the Solaris installation program will only use the disks that you specify with the usedisk profile keyword. Restriction: You cannot specify the usedisk keyword and the dontuse keyword in the same profile. |
. Profile keywords that can be used for upgrading |
The following is the list of sun clusters available
Software Group |
group_name |
Core |
SUNWCreq |
End User System Support |
SUNWCuser |
Developer System Support |
SUNWCprog |
Entire Distribution |
SUNWCall |
Entire Distribution Plus OEM Support |
SUNWCXall |