Certification Objective 10.02Working with Network Services

Certification Objective 10.02—Working with Network Services

Exam Objective 1.2: Explain the client-server model and enable/disable server processes.

Networks are formed to share and use resources, and this is accomplished through services. The machine that offers a service is called a server, and the machine that uses the service is called a client.

Client/Server Model of Networking

Most of the network services are offered in a client/server environment. A client refers to a host that makes requests to another host on the network called a server. The client machine has a client program running on it to make these requests. Examples of clients are web browsers, such as Netscape Navigator and Internet Explorer, an email client, or an FTP client. A server is a machine that has resources to serve, such as files or web pages. A server program running on the machine accepts the incoming requests. It may ask other programs running on the machine to prepare the response and then will send the response back to the client.

Most networks (along with the Internet itself) are server centric. That means there are multiple clients per server. All the resources are on the server machines and the client machines make requests to the server machines. For example, think of a file server on a network, or a web server on the Internet. Because the resources are centered on the servers, security is also server centric.

There is another client/server environment in which the resources are not centered only on servers. Each machine has the resources to share. In other words, each machine is both a client and a server. Such a network is called peer to peer, because the resources are distributed over all the participating machines, and so is the security. Therefore the task of implementing security in peer-to-peer networks becomes very challenging.

As a system administrator, you will be managing network services on your Solaris system.

Working with Solaris Network Services

Solaris 10 offers a service-based startup facility named Service Management Facility (SMF), which provides an infrastructure that augments the traditional UNIX startup scripts, init run levels, and configuration files. SMF removes the rc startup script conventions in Solaris and creates a more Windows-like framework for services. Furthermore, SMF allows multiple services to start up concurrently, thereby dramatically reducing the boot time of a Solaris 10 server.

Still, during the system boot time, the inetd daemon is responsible for starting standard Internet services such as applications running on top of TCP, UDP, or SCTP, including RFC services. After the boot, you can manage services (modify the existing services or add new services) by using SMF commands.

In the SMF framework, multiple versions of the same service can run on a single Solaris system, each version with its own configuration. A specific configuration of a service is called an instance. For example, a web server offers web service, and a specific web server daemon configured to listen on port 80 is a web service instance. A service has a systemwide configuration, but each instance of the service may have its own configuration, which would override the service configuration when there is a conflict. This offers increased flexibility by allowing each instance to choose its own requirements.

Each service instance is named with a Fault Management Resource Identifier (FMRI)—a fancy term, indeed, for a combination, of the service name and the instance name. For example, the FMRI for the rlogin service is network/login:rlogin, where network/login identifies the service and rlogin identifies the service instance.

You can use the inetadm command to manage inetd-controlled SMF services. The inetadm command has the following syntax:

    inetadm [<option>] [<FMRI>] 

The command without any option and without any argument will display the following information about each service that is currently controlled by inetd:

• FMRI of the service

• The run state of the service

• Whether the service is enabled or disabled

The following options specified by <option> are available:

• -e. Enable the service instance specified by <FMRI>.

• -d. Disable the service instance specified by the <FMRI>.

• -l. List the properties of the service instance specified by the <FMRI>.

SMF offers the svcadm command, which can be used to enable and disable the network services. The command has the following syntax:

    svcadm<option> <FMRI> 

You can specify the values for the <option>:

• disable. To disable the service.

• enable. To enable the service.

• refresh. To upgrade the running configuration with the values from the current configuration.

• restart. To restart the service.

Note that the service status change is recorded in the service configuration repository, which will persist across reboots. For example, if you have disabled a service and you reboot the machine, the only way to get the service running again is to enable it.

Now that you know how to enable and disable network services, here are some practical scenarios and their solutions.

SCENARIO & SOLUTION
Which command would you issue to enable the rlogin service whose PMRI name is network/login/rlogin?	svcadm enable network/login:rlogin
Now, how will you disable this service?	svcadm disable network/login:rlogin

Table 10-6 presents some common services that have been converted to use SMF in Solaris 10. The table includes the following information for each service: the daemon name (service name), the FMRI, the run script used to start the service, and whether the service is started by inetd.

Table 10-6: Incomplete list of services converted to use SMF

Service Name	FMRI	Run Script	Inetd Service?
automount	svc:/system/filesystem/autofs:default	autofs	No
coreadm	svc:/system/coreadm:default	coreadm	No
cron	svc:/system/cron:default	cron	No
dumpadm	svc:/system/dumpadm:default	savecore	No
in.dhcpd	svc:/network/dhcp-server:default	dhcp	No
in.ftpd	svc:/network/ftp:default	None	Yes
in.named	svc:/network/dns/server:default	inetsvc	No
in.telnetd	svc:/network/telnet:default	None	Yes
inetd	svc:/network/inetd:default	inetsvc	No
ldap_cachemgr	svc:/network/ldap/client:default	ldap.client	No
nfsd	svc:/network/nfs/server:default	nfs.server	No
None	svc:/network/physical:default	network	No
nscd	svc:/system/name-service-cache:default	nscd	No
sendmail	svc:/network/smtp:sendmail	sendmail	No
sshd	svc:/network/ssh:default	sshd	No
syslogd	svc:/system/system-log:default	syslog	No
ypbind	svc:/network/nis/client:default	rpc	No
yp serv	svc:/network/nis/server:default	rpc	No

The three most important takeaways from this chapter are as follows:

• The TCP/IP protocol suite makes the Internet appear to be a single network, even though it is actually a collection of networks.

• A computer connects to a network through its network interface, which is assigned a hardware address and an IP address.

• The resources on the networks (or Internet) are shared through services. A client machine makes a request for a service, and a server machine serves the request.