This chapter describes managing server and client support on a network, and it provides overview information about each system configuration (referred to as a system type) supported in the Solaris environment. This chapter also includes guidelines for selecting the appropriate system type to meet your needs.
This is a list of the overview information in this chapter.
For step-by-step instructions about how to add and maintain server and client support, see Chapter 4, Managing Server and Client Support (Tasks).
For overview information on setting up a name service policy, see the Solstice AdminSuite 2.3 Administration Guide.
Use this reference to find step-by-step instructions for setting up server and client services.
Systems on the network can usually be described as one of the following:
Server - A system that provides services to other systems in its network. There are file servers, boot servers, database servers, license servers, print servers, installation servers, and even servers for particular applications. This chapter uses the term server to mean a system that provides file systems and installation software 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, and they have to rely on remote file systems from a server to function. Diskless, AutoClientTM and JavaStationTM systems are examples of this type of client.
Other clients may use remote services (such as installation software) from a server, but they don't rely on a server to function. A standalone system, which has its own hard disk containing the root (/), /usr, and /export/home file systems and swap space, is a good example of this type of client.
Providing support for a system means providing software and services to help another system function. Support can include:
Making a system known to the network (i.e., host name and ethernet address information)
Providing installation services to remotely boot and install a system
Providing operating system (OS) services to a system with limited or no disk space
System types are basically defined by how they access the root (/) and /usr file systems, including the swap area. For example, standalone and server systems mount these file systems from a local disk, while other clients mount the file systems remotely, relying on servers to provide these services. Table 3-1 lists these and other differences for each system type.
Table 3-1 System Type Overview
System Type |
Local File Systems |
Local Swap? |
Remote File Systems |
Network Use |
Relative Performance |
---|---|---|---|---|---|
Server |
root (/) /usr /home /opt /export/home /export/root |
Yes |
- none - |
high |
high |
Standalone System |
root (/) /usr /export/home |
Yes |
- none - |
low |
high |
Diskless Client |
- none - |
No |
root (/) swap /usr /home |
high |
low |
JavaStation |
- none - |
No |
/home |
low |
high |
AutoClient System |
cached root (/) cached /usr |
Yes |
/var |
low |
high |
A server system has the following file systems:
The root (/) and /usr file systems, plus swap space
The /export, /export/swap, 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:
Operating system (OS) services for diskless, JavaStation, or AutoClient systems that are running a different release or are a different platform than the server
Solaris CD image and boot software for networked systems to perform remote installations
JumpStartTM directory for networked systems to perform custom JumpStart installations
A networked standalone system can share information with other systems in the network, but it could continue to function if detached from the network.
A standalone system can function autonomously because it has its own hard disk containing the root (/), /usr, and /export/home file systems and swap space. The standalone system thus has local access to operating system software, executables, virtual memory space, and user-created files.
A standalone system requires sufficient disk space to hold the four necessary file systems.
A non-networked standalone system is a standalone system with all the characteristics listed above 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 area. 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 operating system 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.
The JavaStationTM is a client designed for zero administration. This client optimizes JavaTM; the JavaStation client takes full advantage of the network to deliver everything from Java applications and services to complete, integrated system and network management. The JavaStation has no local administration; booting, administration, and data storage are handled by servers.
An AutoClient system is nearly identical to a diskless client in terms of installation and administration. It has the following characteristics:
Requires a minimum of a 100-Mbyte local disk for swapping and for caching its individual root (/) file system and the /usr file system from a server
Can be set up so that it can continue to access its cache when the server is unavailable
Relies on a server to access other file systems and software applications
Contains no permanent data, making it a field replaceable unit (FRU)
You must obtain a license for each AutoClient system you want to add to your network. See the Solstice AdminSuite 2.3 Installation and Release Notes for licensing information.
Determining which system types are appropriate for your environment can be done by comparing each 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/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 from a centralized server, quickly and easily 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 Usage
How much disk space is required to effectively deploy this configuration?
Table 3-2 describes how each system type scores in terms of each of these categories. A ranking of 1 is most efficient; a ranking of 4 is least efficient.
Table 3-2 Comparison of System Types
System Type |
Centralized Administration |
Performance |
Disk Usage |
---|---|---|---|
Standalone System |
4 |
1 |
4 |
Diskless Client |
1 |
4 |
1 |
AutoClient System |
1 |
2 |
2 |
JavaStation Client |
1 |
1 |
1 |
In previous Solaris releases, you may have used Administration Tool to manage server and client support. Starting with the Solaris 2.5 release and compatible versions, you must use the Solstice Host Manager tool, which offers ease of use and provides support for the following name services:
NIS+ tables
NIS maps
Local /etc files
Host Manager is a graphical user interface that enables you to add and maintain server and client support on a network. With a name service like NIS+, you can manage system information in a centralized manner so that important system information, such as host names, does not have to be duplicated on every system in the network.
Host Manager enables you to:
Add and modify support
Update system types
Convert system types
Add and remove OS services
Set up remote installation services
Queue tasks
Host Manager enables you to add and modify support for the following Solaris system types:
Solaris AutoClient systems
Solaris diskless clients
Solaris standalone systems
Solaris OS servers
JavaStations (modify support only)
Table 3-3 describes the server-client configurations that are supported by the Solstice AdminSuite 2.3 release of Host Manager.
Table 3-3 Supported Server-Client Configurations
The SunOS 4.1 release and compatible versions are only supported on SPARC systems with the Sun4, Sun4c, and Sun4m platform groups.
Host Manager initially marks the system types of previously added systems as generic. However, you can choose Update System Types from the File menu to probe previously added systems and attempt to automatically determine their system types. If Host Manager cannot determine the system type (for example, the system is not running the Solaris software) the systems will stay marked as generic.
Previously added systems running Solaris 2.5 release or compatible versions must also have the Solstice AdminSuite software installed for Host Manager to automatically update their system type.
The system type information is stored in the bootparams file in the local /etc files or a name service database. Host Manager will either modify an existing bootparams entry or add a new one such as the following for a Solaris standalone system named mars:
mars boottype=:st
Host Manager enables you to convert one system type to another. Table 3-4 shows what conversions you can make.
Table 3-4 System Type Conversions
You Can Convert A ... |
To A ... |
Standalone System |
AutoClient System or OS Server |
Dataless System |
AutoClient System or OS Server |
AutoClient System |
Standalone System |
Generic System |
Standalone System, or AutoClient System, or OS Server |
You can add Solaris 7 or compatible OS services during the standalone system to OS server conversion.
A Solaris OS server is a server that provides operating system (OS) services to support client systems. By using Host Manager, you can add support for an OS server or convert a standalone system to an OS server.
For each platform group and 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 Sun4m systems running the Solaris 7 release, you must add Sun4m/Solaris 7 OS services to the OS server. You would also still need to add OS services to support SPARC Sun4c systems or x86 systems running the Solaris 7 release, because they are different platform groups.
You must have access to the appropriate Solaris CD image to add OS services.
Although Host Manager enables you to add support for diskless clients running the SunOS 4.0 and compatible releases, you cannot add SunOS 4.0 and compatible OS services using Host Manager. You must use the install4x commands to add OS services to an OS server, and then use Host Manager to add support for the SunOS 4.0 and compatible client.
When adding OS services to an OS server, you may see error messages saying that you have inconsistent versions of the OS running on the server and the OS that you are trying to add. This 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 may have a server that is running the Solaris 7 release or compatible versions; you may also have additional OS services loaded on this server, including the Solaris 2.6 SPARC Sun4m OS services that have been patched. If you try to add the Solaris 2.6 SPARC Sun4c 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. |
OS services can be removed from an OS server using Host Manager. For instance, if you no longer want to support SPARC Sun4m systems running the Solaris 7 or compatible versions, you can remove these OS services from the server using Host Manager.
Host Manager enables you to set up systems to provide Solaris installation services for other systems on the network. You can set up the following types of installation services on a system:
An install server - A system on the network that provides a Solaris CD image (either from a CD-ROM drive or the copy on the hard disk) for other systems to install from.
A boot server - A system that provides boot information to other systems on the network. The boot server and the install server are usually the same system.
A profile server - A system that contains Jumpstart files for systems to perform a custom JumpStart installation.
A boot server and install server are typically the same system. However, if the system to be installed is on a different subnet than the install server, a boot server is required on that subnet.
Host Manager enables you to queue tasks such as converting system types and adding OS services. Since these tasks may require several minutes to process, Host Manager enables you to set up tasks to be performed without requiring you to wait for each task to be completed. After setting up the tasks, choose Save Changes from the File menu. Host Manager's progress is displayed in the message bar located at the bottom of the window as each task is processed.
When adding a Solstice AutoClient or Solaris diskless client using Host Manager, you can now set the root password using the GUI just as you do when setting the group or user password.
When you add a Solstice AutoClient using Host Manager, you have the option to enable scripts to run on the server before or after you add the AutoClient to the server, or run on the client before or after the cache is configured on the AutoClient.
These scripts are those that you have created to customize the addition or deletion of AutoClient systems; these scripts need to be located in the /opt/SUNWadmd/Scripts directory in order for the AdminSuite software to read them.
Host Manager enables you to add a multihomed host alias for servers with multiple network interfaces. For instance, if a server has more than one IP address because it is on multiple networks, it is considered a multihomed host. With Host Manager, you can specify more than one IP address for a host to make it a multihomed host.
Table 3-5shows the limitations of Host Manager and their suggested workarounds.
Table 3-5 Host Manager Limitations and Workarounds
Limitation |
Workaround |
---|---|
Host Manager cannot automatically recognize all previously added system types. |
Use the Update System Type option from the File menu the first time you use Host Manager. This option will probe systems on the network and attempt to identify their system types. |
Host Manager can't add SunOS 4.1 or compatible services to an OS server. |
Mount a SunOS 4.1 or compatible CD image and add OS services by using the install4x command. |
Host Manager can't provide remote installation services for systems running the SunOS 4.1 release or compatible versions. |
Install systems running the SunOS 4.1 or compatible versions from the local CD-ROM drive. |
Host Manager does not enable you to install patches on existing clients and servers. (However, if you have used the admclientpatch command to set up a patch spool directory, Host Manager will reference this spool directory and add appropriate patches for all new hosts.) |
Use the admclientpatch command to set up a patch spool directory and to update existing servers and clients with the latest patches. |
When running host manager as superuser, you will see slightly different behavior. The following list describes the limitations of running host manager as superuser.
When Host Manager is started as superuser, you will see a dialog box describing the constraints that you will encounter.
The name service selection dialog is forced to the local host and the text field is not editable.
When adding a host, the file server is forced to the local host and can not be edited.
When Remote Install is enabled in the Add, Modify, or Convert windows, the boot server is forced to the local host and can not be edited; also, the Install Server is forced to the local host and can not be edited.