This chapter describes the management of server and client support on a network. Overview information is provided about each system configuration (referred to as a system type) that is supported in the Oracle Solaris OS. This chapter also includes guidelines for selecting the appropriate system type to meet your needs.
You cannot use the smosservice and the smdiskless commands on systems that have an Oracle Solaris ZFS root file system installed. This is a known issue with all Solaris releases that support the installation of a ZFS root file system.
You can quickly provision systems that run a UFS root file system or a ZFS root file system by using the Solaris Flash installation feature. For more information, see Installing a ZFS Root File System (Oracle Solaris Flash Archive Installation) in Oracle Solaris ZFS Administration Guide.
The following is a list of the information that is in this chapter:
For step-by-step instructions about how to manage diskless client support, see Chapter 7, Managing Diskless Clients (Tasks).
This section describes new or changed diskless client features in this Solaris release. For a complete listing of new features and a description of Oracle Solaris releases, see Oracle Solaris 10 9/10 What’s New.
A new -p platform argument has been added to the bootadm command. This option enables you to specify the platform or machine hardware class of a client system in situations where the client platform differs from the server platform, for example when administering diskless clients.
For more information, see the bootadm(1M) man page.
The set_nfs4_domain script that was delivered in Oracle Solaris 10 is no longer used to set the NFSv4 domain. To set the NFSv4 domain, add the new nfs4_domain keyword to the diskless client's sysidcfg file. Note that if the nfs4_domain keyword exists in the sysidcfg file, the first boot of a diskless client sets the domain accordingly.
The following feature enhancements are part of the new diskless boot scheme:
The OS server is now capable of serving multiple Solaris releases simultaneously.
With the new diskless boot scheme, you can perform a pxegrub based network boot, where multiple releases are presented to a client from the GRUB menu.
Vendor-specific options are now specified in the boot archive.
In previous releases, client-specific boot properties, typically defined in the bootenv.rc file, were provided by using vendor-specific options for the DHCP setup. The total length of the information that was required frequently exceeded the limit in the DHCP specification.
With the new boot scheme, this information is now part of the boot archive. The PXE/DHCP server is only required to provide the server IP address, the boot file, pxegrub, and possibly a client-specific menu file, through Site Option 150.
The smdiskless command is used to set up diskless clients. Previously, the smdiskless command set up the root (/) and /usr file systems, then exported these file systems to the client through NFS. To boot the client, you would additionally need to configure the /tftpboot area manually. This manual step is no longer a requirement for setting up a diskless client. The smdiskless command now automatically invokes a script in the /usr/sadm/lib/wbem/config_tftp file, which prepares the /tftpboot area for a PXE boot.
After running the smdiskless command, the /tftpboot/01ethernet-address file is displayed as a link to pxegrub and the /tftpboot/menu.lst.01ethernet-address file, which contains the GRUB menu entry. The ethernet-address in this instance is 01, followed by the Ethernet address of the client network interface. When supplying the Ethernet address of the client network interface, use uppercase letters and do not include colons.
The boot archive of the diskless client is automatically updated during shutdown. If the client's boot archive is out of date when it is shut down, you might need to run the following command from the OS server to update the boot archive:
# bootadm update-archive -f -R /export/root/host-name |
where host-name is the host name of the client system.
For more information, see x86: How to Boot in Failsafe Mode to Forcibly Update a Corrupt Boot Archive and the bootadm(1M) man page.
This information applies to both SPARC and x86 based OS servers that are serving x86 based clients.
For more information on setting up and configuring DHCP, see Chapter 14, Configuring the DHCP Service (Tasks), in System Administration Guide: IP Services.
For more information on how to manage diskless clients in the GRUB boot environment, see Booting an x86 Based System by Using GRUB (Task Map).
Use this table to find step-by-step instructions for setting up server and client support.
Client-Server Services |
For More Information |
---|---|
Install or JumpStart clients |
Oracle Solaris 10 9/10 Installation Guide: Network-Based Installations |
Diskless client systems in the Solaris OS |
Diskless Client Management Overview and Chapter 7, Managing Diskless Clients (Tasks) |
Systems on the network can usually be described as one of the system types in this table.
System Type |
Description |
---|---|
Server |
A system that provides services to other systems in its network. There are file servers, boot servers, web servers, database servers, license servers, print servers, installation servers, appliance servers, and even servers for particular applications. This chapter uses the term server to mean a system that provides boot services and file systems for other systems on the network. |
Client |
A system that uses remote services from a server. Some clients have limited disk storage capacity, or perhaps none at all. Such clients must rely on remote file systems from a server to function. Diskless systems and appliance systems are examples of this type of client. Other clients might use remote services (such as installation software) from a server. However, they don't rely on a server to function. A stand-alone system is a good example of this type of client. A stand-alone system has its own hard disk that contains the root (/), /usr, and /export/home file systems and swap space. |
Appliance |
A network appliance such as the Sun Ray appliance provides access to applications and the Solaris OS. An appliance gives you centralized server administration, and no client administration or upgrades. Sun Ray appliances also provide hot desking. Hot desking enables you to instantly access your computing session from any appliance in the server group, exactly where you left off. For more information, see http://www.sun.com/software/index.jsp?cat=Desktop&. |
Support can include the following:
Making a system known to the network (host name and Ethernet address information)
Providing installation services to remotely boot and install a system
Providing Solaris OS services and application services to a system with limited disk space or no disk space
System types are sometimes defined by how they access the root (/) and /usr file systems, including the swap area. For example, stand-alone systems and server systems mount these file systems from a local disk. Other clients mount the file systems remotely, relying on servers to provide these services. This table lists some of the characteristics of each system type.
Table 6–1 Characteristics of System Types
System Type |
Local File Systems |
Local Swap Space? |
Remote File Systems |
Network Use |
Relative Performance |
---|---|---|---|---|---|
Server |
root (/) /usr /home /opt /export/home
|
Available |
Not available |
High |
High |
Stand-alone system |
root (/) /usr /export/home |
Available |
Not available |
Low |
High |
OS Server |
/export/root | ||||
Diskless client |
Not available |
Not available |
root (/) swap /usr /home |
High
High |
Low
Low |
Appliance |
Not available |
Not available |
Not available |
High |
High |
A server system contains the following file systems:
The root (/) and /usr file systems, plus swap space
The /export and /export/home file systems, which support client systems and provide home directories for users
The /opt directory or file system for storing application software
Servers can also contain the following software to support other systems:
Oracle Solaris OS services for diskless systems that are running a different release
OS client-server configurations, where only one system is running a Solaris release that implements either GRUB on the x86 platform or the new boot architecture on the SPARC platform, can result in major incompatibilities. It is therefore recommended that you install or upgrade diskless systems to the same release as the server OS before adding diskless client support.
Note that GRUB based booting was introduced on the x86 platform in the Solaris 10 1/06 release. The new SPARC boot architecture was introduced in the Solaris 10 10/08 release.
Clients that use a different platform than the server
Oracle Solaris CD or DVD image software and boot software for networked systems to perform remote installations
Oracle Solaris JumpStart directory for networked systems to perform custom JumpStart installations
A networked stand-alone system can share information with other systems in the network. However, it can continue to function if detached from the network.
A stand-alone system can function autonomously because it has its own hard disk that contains the root (/), /usr, and /export/home file systems and swap space. Thus, the stand-alone system has local access to OS software, executables, virtual memory space, and user-created files.
A stand-alone system requires sufficient disk space to hold its necessary file systems.
A non-networked stand-alone system is a stand-alone system with all the characteristics just listed, except it is not connected to a network.
A diskless client has no disk and depends on a server for all its software and storage needs. A diskless client remotely mounts its root (/), /usr, and /home file systems from a server.
A diskless client generates significant network traffic due to its continual need to procure OS software and virtual memory space from across the network. A diskless client cannot operate if it is detached from the network or if its server malfunctions.
For more overview information about diskless clients, see Diskless Client Management Overview.
An appliance, such as the Sun Ray appliance, is an X display device that requires no administration. There is no CPU, fan, disk, and very little memory. An appliance is connected to a Sun display monitor. However, the appliance user's desktop session is run on a server and displayed back to the user.
The X environment is set up automatically for the user and has the following characteristics:
Relies on a server to access other file systems and software applications
Provides centralized software administration and resource sharing
Contains no permanent data, making it a field-replaceable unit (FRU)
You can determine which system types are appropriate for your environment by comparing each system type based on the following characteristics:
Centralized administration:
Can the system be treated as a field-replaceable unit (FRU)?
This means that a broken system can be quickly replaced with a new system without any lengthy backup and restore operations and no loss of system data.
Does the system need to be backed up?
Large costs in terms of time and resources can be associated with backing up a large number of desktop systems.
Can the system's data be modified from a central server?
Can the system be installed quickly and easily from a centralized server without handling the client system's hardware?
Performance
Does this configuration perform well in desktop usage?
Does the addition of systems on a network affect the performance of other systems already on the network?
Disk space usage
How much disk space is required to effectively deploy this configuration?
This table describes how each system type scores in terms of each characteristic. A ranking of 1 is most efficient. A ranking of 4 is least efficient.
Table 6–2 Comparison of System Types
System Type |
Centralized Administration |
Performance |
Disk Space Usage |
---|---|---|---|
Stand-alone system |
4 |
1 |
4 |
Diskless client |
1 |
4 |
1 |
Appliance |
1 |
1 |
1 |
The following sections and Chapter 7, Managing Diskless Clients (Tasks) describe how to manage diskless client support in the Oracle Solaris OS.
A diskless client is a system that depends on an OS server for its operating system, software, and storage. A diskless client mounts its root (/), /usr, and other file systems from its OS server. A diskless client has its own CPU and physical memory and can process data locally. However, a diskless client cannot operate if it is detached from its network or if its OS server malfunctions. A diskless client generates significant network traffic because of its continual need to function across the network.
Starting with the Solaris 9 release, the diskless client commands, smosservice and smdiskless, enable you to manage OS services and diskless client support. In the Solaris 8 release, diskless clients were managed with the Solstice GUI management tools.
Attempts to add diskless client support using an OS client-server configuration where one system implements the new boot architecture, but the other system does not, can result in major incompatibilities. New boot (GRUB) was implemented on the x86 platform, starting with the Solaris 10 1/06 release and on the SPARC platform, starting with the Solaris 10 10/8 release. Note that adding diskless support on systems that are running a Solaris release that is more recent than that which is running on the OS server is also an unsupported configuration. To avoid potential problems, it is recommended that you install the latest Solaris release before adding diskless client support.
The Solaris releases and architecture types that are supported by the smosservice and smdiskless commands include the following:
SPARC based servers: Supported in the Solaris 8, Solaris 9, and Solaris 10 releases
SPARC based clients: Supported in the Solaris 8, Solaris 9, and Solaris 10 releases
x86 based servers: Supported in the Solaris 9, and Solaris 10 releases
x86 based clients: Supported in the Solaris 9, and Solaris 10 releases
The following table shows the x86 OS client-server configurations that are supported by the smosservice and smdiskless commands. This information applies to the Solaris 9 and the Oracle Solaris 10 FCS (3/05) release.
If you are running at least the Solaris 10 1/06 release, it is recommended that you install or upgrade to the same release before adding diskless client support.
Table 6–3 x86 OS Client-Server Support
Diskless Client OS | ||
Server OS |
Oracle Solaris 10 3/05 |
Solaris 9 |
Oracle Solaris 10 3/05 |
Supported |
Supported |
Solaris 9 |
Not supported |
Supported |
The following table shows the SPARC OS client-server configurations that are supported by the smosservice and smdiskless commands. This information applies to the Solaris 8 and Solaris 9 releases, and the Oracle Solaris OS, up through the 10 5/08 OS.
If you are running at least the Solaris 10 10/08 release, it is recommended that you install or upgrade to the same release before adding diskless client support.
Table 6–4 SPARC OS Client-Server Support
Diskless Client OS | |||
Server OS |
Oracle Solaris 10 3/05 through Solaris 10 5/08 |
Solaris 9 |
Solaris 8 |
Oracle Solaris 10 3/05 through Solaris 10 5/08 |
Supported |
Supported |
Supported |
Solaris 9 |
Not supported |
Supported |
Supported |
Solaris 8 |
Not supported |
Not supported |
Supported |
You can use the smosservice and smdiskless commands to add and maintain diskless client support on a network. By using a name service, you can manage system information in a centralized manner so that important system information, such as host names, do not have to be duplicated for every system on the network.
You can perform the following tasks with the smosservice and smdiskless commands:
Add and modify diskless client support
Add and remove OS services
Manage diskless client information in the LDAP, NIS, NIS+, or files name service environment
If you are performing a GRUB based boot on an x86 system, you need to manually set up the DHCP configuration. See x86: How to Prepare for Adding Diskless Clients in a GRUB Based Boot Environment for more information.
You can only use the diskless client commands to set up diskless client booting. You cannot use these commands to set up other services, such as remote installation or profile services. Set up remote installation services by including diskless client specifications in the sysidcfg file. For more information, see Oracle Solaris 10 9/10 Installation Guide: Custom JumpStart and Advanced Installations.
By writing your own shell scripts and using the commands shown in the following table, you can easily set up and manage your diskless client environment.
Table 6–5 Diskless Client Commands
Command |
Subcommand |
Task |
---|---|---|
/usr/sadm/bin/smosservice |
add |
Add OS services |
delete |
Delete OS services |
|
list |
List OS services |
|
patch |
Manage OS service patches |
|
/usr/sadm/bin/smdiskless |
add |
Add a diskless client to an OS server |
delete |
Delete a diskless client from an OS server |
|
list |
List the diskless clients on an OS server |
|
modify |
Modify the attributes of a diskless client |
You can obtain help on these commands in two ways:
Use the -h option when you type the command, subcommand, and required options, as shown in the following example.
% /usr/sadm/bin/smdiskless add -p my-password -u my-user-name -- -h |
View the smdiskless(1M) and smosservice(1M) man pages.
You can use the smosservice and smdiskless commands as superuser. If you are using role-based access control (RBAC), you can use either a subset of or all of the diskless client commands, according to the RBAC rights to which they are assigned. The following table lists the RBAC rights that are required to use the diskless client commands.
Table 6–6 Required RBAC Rights for Diskless Client Management
RBAC Right |
Command |
Task |
---|---|---|
Basic Solaris User, Network Management |
smosservice list |
List OS services
|
|
smosservice patch |
List OS service patches |
|
smdiskless list |
List diskless clients on an OS server |
Network Management |
smdiskless add |
Add diskless clients |
System Administrator |
All commands |
All tasks |
An Oracle Solaris OS server is a server that provides operating system (OS) services to support diskless client systems. You can add support for an OS server or convert a stand-alone system to an OS server by using the smosservice command.
For each platform group and Oracle Solaris release that you want to support, you must add the particular OS service to the OS server. For example, if you want to support SPARC sun-4u systems running Oracle Solaris , you must add sun-4u/Oracle Solaris 10 OS services to the OS server. For each diskless client that you support, you must add the OS service for that client to the OS server. For example, you would need to add OS services to support SPARC sun-4m systems or x86 based systems that run Oracle Solaris 10 or the Solaris 9 release, because they are different platform groups.
You must have access to the appropriate Oracle Solaris software CD, DVD, or disk image to add OS services.
When adding OS services to an OS server, you might see an error message stating that you have inconsistent versions of the OS running on the server and the OS that you are trying to add. This error message occurs when the installed version of the OS has packages that were previously patched, and the OS services being added do not have those packages patched, because the patches have been integrated into the packages.
For example, you might have a server that is running the current Solaris release or the Oracle Solaris OS. You might also have additional OS services loaded on this server, including the Solaris 9 SPARC sun-4m OS services that have been patched. If you try to add the Solaris 8 SPARC sun-4u OS services from a CD-ROM to this server, you could get the following error message:
Error: inconsistent revision, installed package appears to have been patched resulting in it being different than the package on your media. You will need to backout all patches that patch this package before retrying the add OS service option. |
Before you set up your diskless client environment, ensure that you have the required disk space available for each diskless client directory.
In previous Solaris releases, you were prompted about diskless client support during the installation process. Starting with the Solaris 9 release, you must manually allocate an /export file system either during installation or create it after installation. See the following table for specific disk space requirements.
Table 6–7 Disk Space Recommendations for Solaris OS Servers and Diskless Clients
Server OS/Architecture Type |
Directory |
Required Disk Space |
---|---|---|
Oracle Solaris 10 SPARC based OS server |
/export |
5 to 6.8 Gbytes |
Oracle Solaris 10 x86 based OS server |
/export |
5 to 6.8 Gbytes |
Oracle Solaris 10 SPARC based diskless client |
/export |
Reserve 200 to 300 Mbytes per diskless client. |
Oracle Solaris 10 x86 based diskless client |
/export |
Reserve 200 to 300 Mbytes per diskless client. |
Disk space recommendations can vary, depending on the Oracle Solaris release that is installed. For specific information about the disk space recommendations in the current Solaris release, see Disk Space Recommendations for Software Groups in Oracle Solaris 10 9/10 Installation Guide: Planning for Installation and Upgrade.