In this chapter, you will
Understand the role of the kernel, shell and file system
Review commonly used Solaris shells
Investigate the distinction between a multiuser system and a multitasking system
Explore the role of clients and servers
Define hosts, hostnames, networks, and IP addresses
Explore the range of SPARC and Intel hardware supported by Solaris
Understanding what makes Solaris different from other operating systems is critical to appreciating why it is the environment of choice for high-availability client/server environments. In this chapter, we review the terms used to describe Solaris systems and major components, as well as networking terminology associated with Solaris networks. Understanding these terms will ensure that you understand some of the concepts discussed in later chapters. Much Solaris terminology is particular to the context of Solaris systems, and some generic terms may have one meaning in Solaris but another meaning for other operating systems. For example, while the term host may be used generically to identify any system attached to a network, it may be used in Solaris, to refer to multihomed hosts.
The Kernel
Operating systems are the building blocks of computer systems, and they provide the interface between user applications and computer hardware. Solaris is a multiuser, multitasking operating system developed and sold by Sun Microsystems (http://www.sun.com/), and it is one implementation of the UNIX operating system that draws on both the System V (AT&T) and Berkeley (BSD) systems. Solaris has evolved from little more than a research project to become the dominant UNIX operating system in the international marketplace.
Solaris 9 is the latest in a long line of operating environment releases that are based around the SunOS operating system, which is currently in version 5.9. Solaris is commonly found in large corporations and educational institutions that require concurrent, multiuser access on individual hosts and between hosts connected via the Internet.
Many desktop computer users have never heard of the word Sun in the context of computing, nor are they usually familiar with the term Solaris as an operating environment. However, almost every time that an Internet user sends an e-mail message or opens a file from a networked server running Sun’s Network File System (NFS) product, Solaris is transparently supporting the Internet applications that allow these things to happen. In the enterprise computing industry, Sun is synonymous with highly available, highly reliable performance hardware, while Solaris is often the operating environment of choice to support database servers and application servers. Sun’s hardware solutions are based around the SPARC and UltraSPARC integrated circuit technologies, which can currently support more than 64 processors in a single server system, such as the E10000 StarFire configuration.
UNIX is hard to define because different vendors have historically introduced different features to arrive at the entities that most users would think of as UNIX. However, it is easy enough to list the fundamental characteristics that are common to all UNIX and UNIX-like systems:
They have a kernel, written in the C programming language, which mainly manages input/output processing rather than being a complete operating system. The kernel has ultimate responsibility for allocating system resources to complete various tasks.
They have a hierarchical file system, which begins with a root directory and from which the branches of all other directories (and file systems) are mounted.
System hardware devices are represented logically on the file system as special files (such as /dev/pty, for pseudoterminals).
They are process-based, with all services and user shells being represented bya single identifying number (the process ID, or PID).
They share a set of command-line utilities that can be used for text and numeric processing of various kinds, such as troff, col, cat, head, tbl, and so on.
User processes can be spawned from a shell, such as the Bourne shell, which interactively executes application programs.
Multiple processes can be executed concurrently by a single user and sent into the background by using the & operator.
Multiple users can execute commands concurrently by logging in from pseudoterminals.
Note that a graphical user interface (GUI) is not necessarily a defining feature of UNIX, unlike other desktop operating systems, which place much stock in “look and feel.” Although CDE remains the default desktop for Solaris 9, Sun plans to integrate the GNOME window manager (http://www.gnome.org/) into future maintenance releases. GNOME is currently the leading desktop of Linux users. Integrating GNOME into Solaris 9 will lead to greater interoperability between Solaris and Linux systems, particularly in terms of GUI application development. It will also make porting GUI applications between Solaris and Intel easier, because Linux back-end applications have been able to be executed on Solaris Intel for some time by using lxrun.
The reasons for this distinction are largely historical and related to the UNIX design philosophy. For operating systems that are not layered, changing the window manager or even the look and feel involves rewriting significant portions of back-end code. In the Solaris environment, where the interface and display technologies are appropriately abstracted from the underlying kernel, moving from CDE to GNOME involves simply changing the command to initialize the X11 display manager; the kernel remains unmodified. The layering of the various components of a UNIX system is shown in Figure 2-1.
Figure 2-1: Components of a UNIX system
Broadly speaking, a UNIX system is layered according to applications that are invoked through user shells, which are managed by a kernel—which in turn uses file systems to create a persistence storage mechanism. Because the kernel provides the interface between shells and the file system, (and by extension, between applications and the file system), it is considered the central part of UNIX technology.
Solaris kernels can trace their origins to both the System V and BSD variants of UNIX, while Microsoft NT was based on the Virtual Memory System (VMS) kernel originally developed for the high-end VAX systems. Most kernels during the 1960s were written using assembly language or machine (binary) code, so the development of a high-level language for writing kernels (the C language) was one of the founding ideas of UNIX. This level of abstraction from hardware meant that kernels could be ported to other hardware platforms without having to be completely rewritten. The tradition of writing kernels in C continues today, with the Linux kernel (for example) being written in C. Obviously, a kernel alone is not a complete operating environment, so many additional applications (such as the visual editor, vi) were later added to what UNIX users would recognize as the suite of standard UNIX tools.
All UNIX systems have a kernel, which is the central logical processor that provides an interface between the system hardware, the system services, and the user shells that directly enable applications. For example, support for network interfaces is provided in the form of a kernel module and a device file that logically represents the physical device. Services are defined in the services database, and network daemons provide the final layer for supporting applications that use the network to transmit data. Since UNIX kernels are typically written in the C programming language, many systems-level applications and daemons are also written in C.
Of course, UNIX systems share some common characteristics with other operating systems, including the use of a hierarchical file system in which special files called directories are used to arrange related files logically. But UNIX has some distinctive features as well: explicit permissions to read, execute, and modify files on the UNIX file system can be granted to specific users or groups of users, making it easy to share work and collaborate with other users on the system.
Because UNIX was created by active developers, rather than by operating system gurus, the focus was on creating an operating system that suited a programmer’s needs. A Bell System Technical Journal article in 1978 lists the following key guiding principles of UNIX development:
Create small, self-contained programs that perform a single task. When a new task needs to be solved, either create a new program that performs it or combine tools from the toolset that already exists to arrive at a solution. This is a similar orientation to the current trend toward encapsulation and independent component building (such as Enterprise JavaBeans), where complicated systems are built from smaller interacting but logically independent modules.
Programs should accept data from standard input and write to standard output; thus, programs can be “chained” to process each other’s output sequentially. Interactive input should be avoided in favor of command-line options that specify a program’s actions to be performed. Presentation should be separated from what a program is trying to achieve. These ideas are consistent with the concept of piping, which is still fundamental to the operation of user shells. For example, the output of the ls command to list all files in a directory can be "piped" using the "|" symbol to a program such as grep, to perform pattern matching. The number of pipes on a single command-line instruction is not limited.
Creating a new operating system or program should be undertaken on a scale of weeks, not years—the creative spirit that leads to cohesive design and implementation should be exploited. If software doesn’t work, don’t be afraid to build something better. This process of iterative revisions of programs has resurfaced in recent years with the rise of object-oriented development.
Make best use of all the tools available, rather than asking for more help. The motivation behind UNIX is to construct an operating system that supports the kinds of toolsets that are required for successful development.
This is not intended to be an exhaustive list of the kernel-oriented characteristics that define UNIX; however, these features are central to understanding the importance that UNIX developers often ascribe to the operating system. It is designed to be a programmer-friendly system.
The Shell
A key Solaris concept is the functional separation between the user interface and the operating system. This distinction means that a user can access a Solaris system by using either a terminal-based character user interface (CUI) or a high-resolution graphical user interface (GUI) without modifying the underlying operating system.
With so much attention paid to GUI, why are CUI environments still important to Solaris? Are they just a historical hangover that Windows has managed to overcome? Or are they simply the tools of choice for long-haired network administrators who have never used a mouse? In fact, mastering the Solaris command line is one of the effective tools available under any UNIX environment, and the good news is it’s not that difficult to learn. Using the command line (or shell) has several advantages over GUI environments.
The shell is essential for programming repetitive tasks that can be performed laboriously through a GUI. For example, searching a file system for all document files that have changed each day and making a copy of all these files (with the extension .doc) to a backup directory (with the extension .bak) takes time.
The shell can be used to search for, modify, edit, and replace Solaris configuration files, which are typically storied in text format. This is much like the approach taken with Windows .ini configuration files, which were text-based. However, after Windows 95, Windows versions store configuration information in the Registry in a binary format, making it impossible to edit manually. All Solaris configuration files, including the startup scripts, are text-based.
The shell has a number of built-in commands that typically mirror those provided in the C programming language. This means that it is possible to write small programs as shell statements that are executed as sequential steps, without having to use a compiler (just like MS-DOS batch files are interpreted without requiring a compiler).
The shell can be used to launch applications that use a CUI, which is especially useful for logging onto a remote system and enabling access to the commands an administrator can use on the console, a valuable point in this era of global information systems. While Windows applications like Symantec’s pcAnywhere can be used for remote access to the Windows Desktop, they don’t easily support multiuser access (or multiuser access where one user requires a CUI and another a GUI).
The shell can be used to execute commands for which no equivalent GUI application exists. Although many operations could conceivably be performed using a GUI, it is usually easier to write a shell script than create a completely new GUI application.
Many applications in Solaris, Linux, and Windows are now available through a GUI interface. If you feel more comfortable using GUI interfaces, there is little reason to stop using them as long as you can find the tools to perform all of the tasks you need to undertake regularly, such as monitoring resource usage, setting process alarms and diagnostics, and/or remote access. However, if you want to make the most of Solaris and competently administer the system, you will need to become familiar with the shell and command-line utilities.
In keeping with the philosophy that different administrators have different needs and styles, Solaris makes several different shells available:
Bourne shell (sh) The original UNIX shell used to write all system scripts by convention.
Korn shell (ksh) Provides enhanced input/output features, including the print and read commands.
C shell (csh) Offers a command syntax similar to the C programming language.
The Cornell shell (tcsh) Includes improved terminal handling compared to the original C shell.
Bourne Again shell (bash) An open source, much improved version of the Bourne shell.
Exercise 2-1 Find out if these shells are installed on your system, and what others might be supported. Precompiled binary shells can be downloaded from www.sunfreeware.com
The File System
UNIX also features a hierarchical file system that makes it easy for you to separate related files logically into directories, which are themselves special files. While MS-DOS and similar operating systems feature a hierarchical file system with simple file access permissions (such as read only), UNIX has a complete user-based file access permission system. Like process management, each file on the system is “owned” by a specific user, and by default only that user can perform operations on that file. Privileged users can perform all operations on all files on the file system. Interestingly, a special file permission allows unprivileged users to execute certain commands and applications with superuser privileges (such as setuid).
The following file system types are supported by the kernel:
cachefs The CacheFS cached file system
hsfs The High Sierra file system
nfs The Network File System (NFS)
pcfs The MS-DOS file system
tmpfs A file system that uses memory
ufs The standard UNIX File System (UFS)
The default local file system type is contained in the /etc/default/fs file, while the default remote file system type is contained in the /etc/default/fstypes file.
Multiuser vs. Multitasking
Operating systems like MS-DOS are single-user, single-task systems; they are designed to be used by a single user who wishes to execute a single program from the shell. However, with advances in CPU technology, even the humble MS-DOS shell was expanded to allow multitasking, where more than one application can execute concurrently. This approach was extended with Microsoft Windows, which allows several applications to be executed concurrently in a GUI environment. In addition, Microsoft Windows has support for multiple users, although it is generally possible for only a single user to initiate a console session, limiting its concurrency—unless some third-party product is installed (such as Symantec’s pcAnywhere, or Terminal Server with Windows 2000/XP).
UNIX provides the best of both worlds, because it is designed from the ground up to permit multiple users to initiate multiple shells, which in turn can execute multiple applications. In addition, Solaris supports lightweight processes such as threads, which allow the traditional concept of multitasking to be generalized to execute multiple threads within a single process. Solaris also supports symmetric multiprocessing, meaning that the physical execution of processes, threads, and user applications may occur on one of many different supported processors.
Client/Server Networks
While PC operating systems were designed in response to the waning of client/server systems, Solaris and other UNIX systems are firmly designed as client/server systems. While a PC is designed to run many high-powered applications using the local CPU, a client/server network is designed around the concept of multiple thin clients that access data and execute applications on a fat centralized server, or on a number of servers that are dedicated to one particular purpose. For example, a typical Solaris network might consist of hundreds of Sun Ray thin client systems, which are supported on the front line by several E450 departmental servers, as well as a set of rack-mounted 420R systems that run database, web server, and development systems.
The client/server topology is also reflected in the structure of UNIX services: client applications running on client systems are designed to connect through to server applications running on server systems. Sun was instrumental in initiating key distributed computing technologies, such as the Remote Procedure Call (RPC) technology used in the Network File System (NFS) protocol. In addition, the Remote Method Invocation (RMI) technology developed as part of the Java networking and distributed computing APIs allows objects to be passed around the network as seamlessly as RPC.
Basic Networking Terminology
A Solaris network consists of a number of different hosts that are interconnected using a switch or a hub. Solaris networks connect to one another via routers, which can be dedicated hardware systems, or Solaris systems, which have more than one network interface. Each host on a Solaris network is identified by a unique hostname; these hostnames often reflect the function of the host in question. For example, a set of four FTP servers may have the hostnames ftp1, ftp2, ftp3, and ftp4.
Every host and network that is connected to the Internet uses the Internet Protocol (IP) to support higher-level protocols such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Every interface of every host on the Internet has a unique IP address that is based on the network IP address block assigned to the local network. Networks are addressable by using an appropriate netmask that corresponds to a class A (255.0.0.0), class B (255.255.0.0), or class C (255.255.255.0) network.
Solaris supports multiple Ethernet interfaces that can be installed on a single machine. These are usually designated as /etc/hostname.hmen, where n is the interface number and hme is the interface type. Interface files contain a single unqualified domain name or IP address, with the primary network interface being designated with an interface number of zero. Thus, the primary interface of a machine called ftp would be defined by the file /etc/hostname.hme0, which might contain the unqualified domain name “ftp”, or the IP address 203.17.64.28. A secondary network interface, connected to a different subnet, might be defined in the file /etc/hostname.hme1. In this case, the file might contain the unqualified domain name “mail”, or the IP address 10.17.65.28.
The decision to use unqualified domain names or IP addresses rests largely with the naming service used by the system, which is defined by the file /etc/nsswitch.conf. If this file does not allow hostname resolution from the /etc/hosts because the Domain Name System (DNS) is used exclusively, using unqualified domain names in /etc/hostname.* files can lead to a failure of local hostname resolution. However, because IP addresses can change from time to time (particularly if Dynamic Host Configuration Protocol, or DHCP, is used), some administrators may need to use unqualified domain names.
Enabling multiple interfaces is commonly used in organizations that have a provision for a failure of the primary network interface or to enable load balancing of server requests across multiple subnets (for example, for an intranet web server processing HTTP requests). A system with a second network interface can act either as a router or as a multihomed host. Hostnames and IP addresses are locally administered through a naming service, which is usually DNS for companies connected to the Internet, and the Network Information Service (NIS/NIS+) for companies with large internal networks that require administrative functions beyond what DNS provides, including centralized authentication.
It is also worth mentioning at this point that it is possible for you to assign different IP addresses to the same network interface; this configuration can be useful for hosting “virtual” interfaces that require their own IP address, rather than relying on application-level support for multihoming (for example, when using the Apache web server). You simply create a new /etc/hostname.hmeX:Y file for each IP address required, where X represents the physical device interface and Y represents the virtual interface number.
The subnet mask used by each of these interfaces must also be defined in /etc/ netmasks. This is particularly important if the interfaces lie on different subnets, or if they serve different network classes. In addition, it might also be appropriate to assign a fully qualified domain name to each of the interfaces, although this will depend on the purpose to which each interface is assigned.
System Configuration
Solaris provides a simple way to view all the hardware devices on your system. This information can be used to configure your system. For example, by identifying the disk devices on your system, you can correctly select targets for formatting.
The prtconf command is used for displaying system information:
prtconf
System Configuration: Sun Microsystems sun4u
Memory size: 128 Megabytes
This section shows the hardware architecture (sun4u, which means that this is a Sun 4 system with an UltraSPARC CPU) and that it has 128MB of RAM.
The following section identifies the terminal emulator, keyboard, and UFS. These devices are necessary to boot a Solaris system.
System Peripherals (Software Nodes):
SUNW,Ultra-5_10
packages (driver not attached)
terminal-emulator (driver not attached)
disk-label (driver not attached)
SUNW,builtin-drivers (driver not attached)
sun-keyboard (driver not attached)
ufs-file-system (driver not attached)
The next section shows the OpenBoot PROM (programmable read-only memory), physical memory, and virtual memory monitor devices:
chosen (driver not attached)
openprom (driver not attached)
client-services (driver not attached)
options, instance #0
aliases (driver not attached)
memory (driver not attached)
virtual-memory (driver not attached)
The final section displays devices attached to the first PCI local bus. This includes an Integrated Device Electronics (IDE) hard disk, IDE hard drive, and network interface:
pci, instance #0
pci, instance #0
ebus, instance #0
auxio (driver not attached)
power, instance #0
SUNW,pll (driver not attached)
se, instance #0
su, instance #0
su, instance #1
ecpp (driver not attached)
fdthree, instance #0
eeprom (driver not attached)
flashprom (driver not attached)
SUNW,CS4231 (driver not attached)
network, instance #0
SUNW,m64B (driver not attached)
ide, instance #0
disk (driver not attached)
cdrom (driver not attached)
dad, instance #0
sd, instance #30
Note Obviously, the specific devices installed on each system vary, and so will the configuration displayed when using prtconf.
Processes
Processes lie at the heart of all modern multiuser operating systems. By dividing system tasks into small, discrete elements that are uniquely identified by a process identifier (PID), Solaris is able to manage all the applications that may be concurrently executed by many different users. In addition, individual users may execute more than one application at any time. Each Solaris process is associated with a UID and a GID, just like a standard file. This means that only users may send signals to their own processes (except for the superuser, who may send signals to any process on the system). Signals are typically used to restart or terminate processes. The multiuser, multitasking process model in Solaris ensures that system resources can be shared equally among all competing processes or allocated preferentially to the most important applications. For example, a firewall application would probably take precedence over all other system processes. Individual users and the superuser may allocate a priority level to active processes in real time.
Solaris provides a number of command-line tools that can be used to manage processes. In addition, APIs are provided for C programmers to allow them to operate directly on processes—spawning, managing, and killing as necessary. Solaris also provides lightweight processes (LWPs) that don’t require as much overhead to operate as “normal” processes.
Naming Services
Every computer connected to the Internet must have an IP address, which identifies it uniquely within the network. For example, 192.18.97.241 is the IP address of the web server at Sun. IP addresses are difficult for humans to remember, and they don’t adequately describe the network on which a host resides. Thus, by examining the fully qualified domain name (FQDN) of 192.18.97.241—www.sun.com—it’s immediately obvious that the host, www, lies within the sun.com domain. The mapping between human-friendly domain names and machine-friendly IP addresses is performed by a distributed naming service known as the Domain Name Service (DNS). DNS is the standard protocol used by UNIX systems (and other operating systems) for mapping IP addresses to hostnames, and vice versa.
Although Solaris provides complete support for DNS, it uses its own domain management and naming system, known as the Network Information Service (NIS). NIS is not only responsible for host naming and management, but it is a comprehensive resource management solution that can be used to structure and administer groups of local and remote users.
NIS uses a series of maps to create namespace structures. Sometimes administrators ask why this extra effort is required to manage hosts and naming, because DNS already provides this for Internet hosts by converting computer-friendly IP addresses to human-friendly “names.” However, NIS does not just provide naming services; a NIS server also acts as a central repository of all information about users, hosts, Ethernet addresses, mail aliases, and supported Remote Procedure Call (RPC) services within a network. This information is physically stored in a set of maps that are intended to replace the network configuration files usually stored in a server’s /etc directory, ensuring that configuration data within the local area network (LAN) is always synchronized. Many large organizations use NIS alongside DNS to manage both their Internet and LAN spaces effectively. Linux also supports NIS.
In the past, Sun introduced an enhanced version of NIS known as NIS+. Instead of a simple mapping system, it uses a complex series of tables to store configuration information and hierarchical naming data for all networks within an organization. Individual namespaces may contain up to 10,000 hosts, with individual NIS+ servers working together to support a completely distributed service. NIS+ also includes greater capabilities in the area of authentication, security (using DES encryption), and resource access control.
Recently, Solaris has begun a transition to Lightweight Directory Access Protocol (LDAP) directory services as an alternative source of authoritative information for naming, identification, and authentication. LDAP is based on the original Directory Access Protocol (DAP), which provided X.500-type services for centralized directory lookups. Like NIS and NIS+, LDAP performs lookups, given a token, and returns a result. However, the query is much more generalized than what can be returned from NIS or NIS+: text, sounds, and graphics can all be associated with an entry in the directory.
LDAP does not provide any kind of programmatic query language, like SQL, to query the directory, so its use is still limited. However, because it works directly over TCP/IP, and it can support directory services for clients on different operating systems, LDAP is often viewed as the future central naming and directory service for Solaris.
Server-Side Java
Java is a new programming language that is often used to create platform-independent GUIs that a user can interact with in complex and sophisticated ways. However, Java applets—the bits of code that are transmitted over the Internet and executed on the user’s machine—are only one side of the whole Java story. This section will focus on the server side of Java.
Java applications that execute on the server are called servlets, and they have their own standard API specification that has now been widely implemented in web server extension products known as servlet runners (such as Apache’s Tomcat server). Servlets are useful in developing web-enabled, Solaris-based enterprise applications.
Increasingly, applications in the enterprise are being implemented using web interfaces, partly in response to the persistent heterogeneity of computing platforms within organizations that span cities, states, and even nations. Accepting platform diversity does not mean losing control of standards, however. Sun Microsystems has pioneered a platform-independent programming language in which applications run on top of a logical Java Virtual Machine (JVM) that presents a consistent API for developers. Most major hardware platforms and operating systems now have virtual machines implemented, including (obviously) Solaris. In fact, the Solaris JVM produced by Sun has been highly optimized in its production release series. JVMs have also been integrated into popular web browsers, so that Java programs can be downloaded from a server and executed within these browsers. (HTML has an
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment