Overview of Linux

Before we jump into the actual activities of the example migration, let's review some information about the Linux operating system and how it compares to the Solaris Operating System (Solaris OS).

Linux has grown from its early beginning as Linus Torvald's attempt to create a freely available operating system running on 80386 hardware to its use today as a general-purpose environment that rivals commercial UNIX implementations. Along the way, Linux has taken cues from many commercial UNIX implementations and has constructed application program interfaces (APIs) and a kernel along similar lines. In addition, Linux has gained application support from the open source community, with alternatives for many of the commercial packages available. Because of these facts, migrating from Linux to Solaris is a relatively painless affair in most environments.

In this example, we focus on the migration from a particular Linux distribution, Red Hat Linux. Red Hat Linux is the best-selling Linux distribution today, capturing over 50 percent of the server market. Other major Linux distributions include SuSE, Debian, and Mandrake. These distributions differ not in core functionality or kernel code, but in marketing focus and utilities. For example, each of the distributions listed above has different installation method and software packaging utilities. While we specifically talk about Red Hat Linux's features and utilities, we also point out features that might be different from some of the other major Linux distributions.

Differences Between the Linux and Solaris Environments

While many people think of Solaris and Linux as being two separate environments, they have many external similarities. However, because Solaris has been in constant development over the past 20 years , it has obtained a level of maturity that is not present in today's implementations of Linux. This directly translates into some additional features in the enterprise space that Linux lacks. Most Linux developers, administrators, and architects will feel right at home with the Solaris environment, especially when they see the additional features it offers.

In the following sections, we compare some key differences between Linux (focusing on Red Hat) and Solaris. We compare these two environments in the following areas:

• Booting process

• Software packaging and installation

• Kernel configuration

• APIs

• Device configuration

• Administration and monitoring

• Networking

• Storage

• Security

This is not an exhaustive list, but it focuses on differences that will affect your migration to the Solaris OS.

Booting Process

The local disk boot process for Red Hat Linux varies depending on the boot loader you decide to use: Linux Loader (LILO) or Grand Unified Boot (GRUB) loader. GRUB is the newer of the two boot loaders and has some advantages over LILO, especially the ability to read EXT2 and EXT3 file systems. GRUB is the default boot loader, but many people still use LILO because of their familiarity with it. GRUB uses the following booting sequence:

1. The BIOS self-tests the system and launches the first-stage boot loader by reading the master boot record (MBR) of the hard drive.

2. The first-stage boot loader loads into memory and launches the second-stage boot loader. On some non-x86 architectures, there can be an intervening step here that displays the GRUB menu and environment. This allows you to check system parameters as well as pass some variables onto the kernel before booting.

3. The second-stage boot loader loads the kernel into memory and mounts the root partition.

4. The kernel transfers control of the boot process to the /sbin/init program.

5. The /sbin/init program loads all services and user -space tools, and mounts all partitions listed in /etc/fstab . The /sbin/init process starts the run control ( rc ) scripts, which execute a series of other scripts. These scripts (stored in /etc/init.d/ ) check and mount file systems, start various processes, and perform system maintenance tasks .

Solaris on SPARC boots in a similar way, with different programs. For example, Solaris uses a program called monitor to do its boot loading. Solaris/SPARC's boot process is as follows :

1. The PROM displays system identification and then runs self-test diagnostics to verify the system's hardware and memory.

2. The PROM loads the primary boot program, bootblk , whose purpose is to load the secondary boot program (located in the ufs file system) from the default boot device.

3. The bootblk program finds and executes the secondary boot program, ufsboot , and loads it into memory.

4. The ufsboot program loads the kernel.

5. The kernel initializes itself and begins loading modules, using ufsboot to read the files. When the kernel has loaded enough modules to mount the root ( / ) file system, the kernel unmaps the ufsboot program and continues, using its own resources.

6. The kernel creates a user process and starts the /sbin/init process, which starts other processes by reading the /etc/inittab file.

7. The /sbin/init process starts the run control ( rc ) scripts, which execute a series of other scripts. These scripts ( /sbin/rc* ) check and mount file systems, start various processes, and perform system maintenance tasks.

Both systems use a process of symbolic linking scripts to control the order of startup and shutdown of processes. However, Red Hat Linux's use of the chkconfig command to automate this control is not implemented on Solaris.

Software Packaging and Installation

Both Solaris and Red Hat Linux provide facilities for the management of software installation and packaging. Red Hat Linux's software installation facilities, called RPM for the RPM Package Manager, enable the easy installation and packaging of both binary and source software. Red Hat Linux also manages patches through this facility. This RPM technology separates Red Hat Linux from most other Linux distributions. For example, Debian Linux uses the Debian package management system to install, upgrade, remove, and verify software. While the specific commands are different, the Debian package management system supports many of the same concepts and features as RPM. Red Hat Linux provides both command-line interface (CLI) and graphical user interface (GUI) tools to manipulate RPMs.

Solaris uses a standard package management system, commonly referred to as pkgadd (after the software installation command). With the pkgadd family of commands you can manipulate packages, collections of files, and directories in a defined format, according to the System V Interface Definition. Beginning in the Solaris 8 Operating Environment (Solaris OE), Sun started to augment these commands with new GUI tools and a more powerful registry. The following table compares the Red Hat Linux and Solaris packaging commands:

Table 9-1. Red Hat Linux and Solaris Packaging Commands

	Red Hat Linux	Solaris
Install package	#rpm -i <package file>	#pkgadd <package file>
Remove package	#rpm -e <package file>	#pkgrm <package file>
Upgrade package	#rpm -U <package file>	#pkgadd <package file>
List package	#rpm -qa	#pkginfo <package file>
Verify package	#rpm -V <package file>	#pkgchk <package file>
GUI	# gnorpm	#prodreg

Creating Solaris packages or converting RPMs is beyond the scope of this book. However, these procedures require largely the same components : software, directory structures, control files, and preinstall and postinstall scripts. For more information on creating Solaris packages, consult your Solaris documentation or visit http://docs.sun.com/.

In addition to the manual software installation utilities, the Solaris OS also includes automated installation facilities through the JumpStart technology framework. JumpStart, similar to Red Hat's Kickstart for installation, can be used to automatically install or upgrade servers. For more information on using the JumpStart technology, consult JumpStart Technology: Effective Use in the Solaris Operating Environment .

Solaris patches are handled separately from software packages, with more powerful commands specifically suited for patches. More notably, these commands allow for the "backing out" of patches. They include the CLI patchadd / patchrm commands as well as a GUI and web tool called PatchPro (available at http://www.sun.com/PatchPro). There are also advanced facilities for upgrading or patching the operating system while it is running so that the patch becomes effective on the next reboot. This feature is called Live Upgrade and can significantly reduce planned downtime.

Just as open source and shareware Linux RPMs are available on Web sites such as http://www. rpmfind .org, you can find Solaris open source packages at the http://www.sunfreeware.com/ Web site. These packages are maintained by third parties but are compiled and packaged in the Solaris pkgadd format.

Kernel Configuration

Kernel configuration under Linux can be a complicated task for the uninitiated. Most major kernel variables require the administrator to change kernel variables, recompile the kernel from its source, reconfigure the boot loader to point to the new kernel, and reboot the server. Luckily, this is only necessary when moving to different kernels such as symmetrical multiprocessing (SMP) or big memory (for 686 systems with over 4 gigabytes of RAM). Most lesser kernel changes can be handled through loadable modules, the proc file system, or the /etc/sysctl.conf file.

Solaris takes a different approach for configuring kernels than Red Hat Linux does. Only one Solaris kernel has been compiled and optimized for each different hardware platform (depending on the system architecture). Any kernel configuration is taken care of through the /etc/system file or the proc file system. The /etc/system file acts much like Red Hat Linux's /etc/sysctl.conf file, in which kernel parameters are set in a "variable = value" format. However, the variables and values used for the Solaris OS are quite different, even for similar variables such as shared memory. Never use the Red Hat Linux kernel variable values on a Solaris system. One exception to the /etc/system convention are TCP/IP parameters, which are usually set with the ndd (1) utility.

Application Programming Interfaces

Because Solaris and Linux are both POSIX-compliant operating systems, they share many of the same APIs. However, Solaris APIs differ from Linux APIs in two key areas: threading and 64-bit support. Luckily, both of these APIs are enhancements, so the initial porting activities from Linux should not be affected.

The Solaris OS implements two threading models: Solaris threads and POSIX threads. Threading allows a single process to take advantage of multiple processors by spawning threads. The Solaris POSIX threads APIs follow the standard implementation and are compatible with the Linux implementation. Solaris proprietary threads predate the POSIX threading standard, but provide higher threading performance on the Solaris OS. Linux-threaded programs can be ported to the Solaris OS by means of POSIX threading APIs, with conversion to Solaris threading if greater performance is necessary.

Solaris 64-bit support is also an enhancement to UNIX that is not currently available on Red Hat Linux. The 64-bit support enables access to larger files, physical memory, and process space than is currently available on 32-bit processors or operating systems. Linux programs will need to be converted for 64-bit support on the Solaris OS. Solaris 64-bit support and porting are described in more detail in Chapter 10.

Below the API level, source code for the Solaris OS and Linux might differ because of their hardware platforms. Linux typically runs on x86 processors, while the Solaris OS can run on either x86 or SPARC processors. SPARC processors are "big endian" processors, whereas x86 CPUs are "little endian." Be sure to review your source code for this change, because it can introduce errors that are difficult to troubleshoot.

Device Configuration

Both the Solaris and Linux operating systems manage their devices through symbolic links in the device tree. Linux manages this device tree through the /etc/sysconf/hwconf file that is either manually edited or discovered during the booting process. The Solaris OS handles it in a similar way, but with different commands.

In addition, the Solaris OS can configure hardware in the operating kernel, through a process called dynamic reconfiguration (DR). This feature, offered on supported Sun hardware, allows operators to add or remove processors, memory, storage, or peripheral cards to or from the OS without rebooting.

The following table highlights the differences in functionality between Red Hat Linux and the Solaris OS.

Table 9-2. Solaris OS Device Management

Functionality	Solaris
Reconfigure hardware during reboot	# devfs # reboot -r -or- # boot -r (at boot prom)
Reconfigure device links	# devlinks
Reconfigure disk drives	# drvconfig

Administration and Monitoring

Linux administration tools are specific to each vendor, with the exception of the linuxconf utility. The management functions for the Solaris OS are concentrated in two applications: Sun Management Console (SMC) and Sun Management Center (SunMC). SMC provides server administration functionality, and SunMC remotely monitors groups of servers. Like linuxconf , SMC allows for the remote GUI administration of servers.

Networking

Networking implementations on the Linux and Solaris operating systems are remarkably similar. Both operating systems use the same basic commands and files for configuring interfaces, default routes, static routes, name servers, and name services ( /etc/nsswitch.conf ). In addition, Solaris boasts some unique redundancy and management networking features. One of these features is IP multipathing, which allows multiple IP interfaces on a single network. The Solaris OS supports this by load balancing among the interfaces. IP quality of service (IPQoS) to prioritize IP traffic by application according to service levels is also supported by the Solaris OS.

Storage

The Solaris OS uses the UNIX file system (UFS) as its default file system. Like EXT3, Red Hat Linux's default file system, UFS is a popular and robust block-based file system that supports journalling for faster recovery times. However, unlike EXT3, UFS supports larger file systems and maximum file sizes. UFS is also tightly integrated with Sun Volume Manager (SVM), which allows GUI creation and manipulation of redundant array of independent disk (RAID) volumes .

UFS is just one of the file systems supported on the Solaris OS. Common file systems such as PCFS (MS-DOS, or VFAT on Linux), HSFS (iso9960 on Linux), and NFS are also supported on the Solaris OS. Commercially available file systems, including Sun's QFS, and SAM-FS or VERITAS's VxFS (and the complementary VERITAS Volume Manager [VxVM]), are also quite commonly used on the Solaris OS.

Security

The Solaris and Linux operating systems differ significantly in the security tools they support. Linux uses iptables as its default firewalling tool; the Solaris OS uses SunScreen software, which provides advanced firewall features such as stealth mode, whereby the server operates without any visible IP address. The software also offers more conventional stateful firewall features like network address translation (NAT), ordered firewall rules, and a GUI management application. SunScreen is bundled with the Solaris 8 Operating Environment and above.

Sun also provides a toolkit called JumpStart Architecture and Security Scripts (JASS) to minimize, harden, and secure the Solaris OS. JASS automates and standardizes the process of securing installations of the Solaris OS by leveraging JumpStart software to run scripts on groups of servers. It is an invaluable aid in securing and maintaining security on Sun servers. More information and documentation about JASS is available at the Sun BluePrints OnLine Web site at http://www.sun.com/solutions/blueprints/online.html.

In addition to the security tools we've already mentioned, Sun also offers a high-security version of the Solaris OS called Trusted Solaris. Trusted Solaris implements much more robust auditing, privacy, and user controls than do traditional UNIX operating systems. For example, through more robust user control facilities, Trusted Solaris implements role-based access control to provide greater granularity than the single root user account.