Retool Your Linux Skills For Commercial UNIX
Retool Your Linux Skills For Commercial UNIX
30 Mar 2006
Examine how to best migrate your Linux® skills to take advantage of AIX® and
Solaris. Linux is all the rage, but what if you have experience in Linux and need to
apply it to a commercial UNIX® environment? UNIX and Linux are similar, and many
of the same principles exist; there is a shell, root is still all powerful, and many of the
tools and applications are the same. But how do you cope with understanding the
nuances and differences?
There are, however, minor differences, and it is understanding those differences that
help you migrate your skills and abilities from Linux into a commercial UNIX
environment. In this tutorial, you are going to look at the basics and history of Linux
and UNIX to understand where the similarities lie, and then you'll take a closer look
at specific commands, functionality, and the abilities that are different between the
Linux operating system and the commercial UNIX variants. This tutorial includes
tips, alternative tools, and utilities that you can use to provide similar, or identical,
functionality to the Linux commands.
Prerequisites
While no specific tools are needed to follow along with this tutorial, some familiarity
with Linux and UNIX is recommended.
UNIX roots
Defining the UNIX operating system and what makes UNIX unique compared to
other systems is difficult without going into more detail than is available here, but
let's start by picking out some key elements of the UNIX environment:
Beyond these core elements, however, are the further subtleties of the UNIX
environment. For example, the notion of a "superuser" (root) that is capable of doing
anything on the system, regardless of the rights or security of that resource, is very
much a UNIX notion. The use of "swap space" that enables pages of memory (and
entire applications) to be written to disk to gain the best performance of active
memory is also a key element of the UNIX environment.
Linux is based on these same principles but, unlike UNIX variants, which are driven
by one vendor (IBM, Sun, Hewlett Packard), the components that make up the Linux
operating system are owned and developed by multiple parties, and that means
options are often provided that support the options from more than one "source"
environment. From a Linux administrator perspective, there are no problems, but
when migrating to UNIX, the difference between options, tools, and functionality can
take some getting used to.
With Linux, various distributions package these elements differently and provide
different tools and systems for managing, installing, and organizing these
components, but the basic environment and toolset tend to remain constant.
Within the Linux distribution, it is the combination of these free tools and
components that make up the operating system. Within UNIX, by comparison, the
common tools and environmental components are entirely developed and sourced
by the UNIX vendor. For example, Sun's Solaris includes Sun developed tools, such
as ls and awk, that fit in with the rest of the Solaris operating environment. Sun has
also bundled free software tools, but these are extensions (such as emacs or KDE)
as opposed to core operating system elements, such as the default shell or standard
While many of these items and components are considered as free software today
and part of the Linux stable, they started out as extensions or alternatives to
commercial UNIX operating environments many years before Linux was introduced.
Tools that are taken for granted today, such as gcc, gawk, Perl, emacs, and even
versions of vi all started out as UNIX-based tools and utilities.
For the Linux administrator who wants to migrate his or her skills and experience
into the UNIX space, the combination of familiar principles (processes, user, group,
other security) and tools (shells, awk, ps, and so forth) means that the migration will
be far simpler than that experienced when moving from Linux to Microsoft®
Windows®.
The most complex element of the transition process for most Linux administrators is
the difference and what some will see as the restrictions implied in a UNIX operating
system sourced from a single vendor.
Those impressions are not entirely unfounded, but their existence is neither a
problem nor hard to appreciate. The tools and facilities available to a Linux
administrator are typically based on the amalgamation and combination of
functionality that users and developers have experienced across a range of
operating systems, including all the different UNIX environments.
Rather than standardizing on a single option or function, these tools instead provide
access to all of the different combinations. Most Linux-based ps tools, for example,
support both the -e (System V Release 4) and -A (BSD) arguments for obtaining a
list of all running processes. A commercial UNIX ps tool supports only the option
appropriate to their heritage.
Within UNIX, the same tools, options, and functionality is often provided across
different versions of the operating system. This is especially true for operating
systems that have been developed to support specific ranges of hardware, for
example, Sun's own SPARC-based servers or AIX range from IBM.
All users are identified, at least by default, through the /etc/passwd file. Common
within Linux is the storage of passwords in /etc/shadow, which is restricted to
superuser access only. Although most modern UNIX variants share the same model,
some older variants still store the password information within /etc/passwd.
Solaris stores passwords in /etc/shadow. AIX stores the secure password data in
/etc/security/passwd. Older editions of HP-UX store the information within a special
root specific authorization directory (/tcb/files/auth/r/root). Newer HP-UX revisions
(HP-UX IIi Version 1.6 or later) store the file in /etc/shadow, but it is an optional
change.
The useradd tool in Linux provides the facility to add users to the system, and this
same tool is available within Solaris, with some minor changes to some of the
command line items. AIX has a similar tool, mkuser, for adding users to the system.
Processes
The basic principles behind processes within Linux and UNIX are identical. All
processes have an owner (user ID) group ID, a unique process ID, and parent
process ID. Processes also all have a priority and this can be modified by using the
nice tool to adjust the priority of the process.
Signals are the main method of controlling processes and there are no differences
between the core signals for communicating different operations, such as SIGKILL,
SIGQUIT, or SIGHUP, as these signals are defined as part of the POSIX standard to
which most Linux and UNIX operating systems are made. These signals are listed in
the Table 2 below.
On Linux and UNIX, the kill tool can be used to send a signal to a running process
on any UNIX or Linux operating system. For changing priority, the renice tool is
available on some, but not all UNIX variants. Those UNIX variants based on BSD
UNIX should include the renice tool as standard. SVR4 variants (including Solaris)
might optionally include the tool. For example, Solaris includes a suite of BSD-based
tools (from the original Sun operating system platform, which was based on the BSD
code) within the /usr/ucb directory.
One major difference between Linux and UNIX variants is that the thread model
within Linux treats all processes and threads as individual entries in the process
table, particularly when the list of running processes is displayed using the ps tool.
Within UNIX, however, threads treated as integral components of the process are
not specifically, or individually, listed.
Shells
The basic interface to the UNIX operating system is the shell, and this is no different
from the shell interface that is available within Linux. However, there are differences
in the list of available shells and their functionality compared to the common
solutions available within Linux.
Within Linux, the range of shells provided is based on the range of free or open
source software (FOSS) solutions available. For example, bash or zsh are common
Linux alternatives for the original Bourne and Korn shell (ksh), both standardized
shells within the UNIX environment.
At the core, these shells work identically: prompt, interface, and common principles,
such as pipes and redirection, remain the same. More complex elements, such as
the advanced internal variable types supported by the bash and zsh shells or the
advanced file completion tools, are not always available in the UNIX shells.
If you are familiar with bash or zsh, then ksh is the closest equivalent, providing file
completion, command-line editing or scrollback, and job control features. To enable
bash or zsh style environment within ksh, you should start ksh with the following
command:
$ ksh -o emacs -o markdirs -o viraw
The above enables emacs-style editing (^p^n goes back or forward through
previous commands, ^a goes to beginning of line, and so forth), markdirs adds a /
to a completed directory, and viraw should enable tab-style auto-completion. On
some UNIX ksh implementations, auto-completion with the TAB key is not available,
and you will need to use ESC-ESC (press the escape key twice) to complete the
command or pathname.
Beyond the basic shell environment, there are other differences. For example,
commonly available tools, such as gawk, sed, and others, will be based around the
original applications (awk). These applications have changed little over the years,
although they remain staple components of the environment, scripts, and utilities
that have been in use for many years.
There is, however, no reason why you cannot install the free software alternatives,
although you should be aware that these alternatives might not always be available.
You should be prepared to work within the restrictions of the original shell and
environment in the event of an operating system failure, the initial stages of setup, or
if the company policy prevents use of non-approved software.
Also, be very careful when migrating scripts and tools from an existing Linux
platform. Not only will the shell script tool that is available be different, but the tools
and commands on which it relies might be different.
Network environment
Networking within UNIX is based on the same IP (TCP/IP and UDP/IP) standards on
which Linux and most other operating systems use.
The major difference is in the configuration of this information. The exact method
within Linux depends entirely on the distribution, but it is not uncommon to find a
configuration file such as this one, from /etc/conf.d/net on a Gentoo Linux machine
that defines the network configuration for each network device:
config_eth0=( "192.168.0.22 netmask 255.255.255.0" )
routes_eth0=( "default gw 192.168.0.1" )
config_eth1=( "192.168.0.23 netmask 255.255.255.0" )
Within the UNIX variants, the configuration of the network is not normally quite so
clear. Solaris, for example, uses the names of files in /etc to specify the name, which
is in turn referenced to the corresponding static name reference in /etc/hosts. For
example, to configure the network interface /dev/bge0 (in Solaris, network devices
are named according to the network driver used to support them), you would create
a file /etc/hostname.bge0 with the name of the host: ultra3, while /etc/hosts would
contain the IP address: 192.168.0.99 localhost ultra3.
If the machine is part of a wider network, you also need to configure the
/etc/netmasks file with a suitable netmask for the network:
192.168.0.0 255.255.255.0
and populate the /etc/defaultrouter file with the IP address of the router to use for the
network.
Although these are not parameters that change regularly, altering the information
can be problematic. For installation, the system will ask for the configuration and ID
information. For reconfiguration, you can zero the current configuration data, reboot,
and then repeat the configuration process.
Within AIX, the System Manager tool and the command line smitty tool are available
for basic configuration options. The HP-UX tool sam is able to configure most
aspects of the systems, although you can manually configure the network
configuration using the /etc/rc.config.d/netconf file.
The Bourne Again Shell (bash), for example, was an open source shell that brought
the power and flexibility of the original Korn and C shells into a shell that behaved
much more like the original (and simpler to use) Bourne shell.
In general, it is possible to configure, compile, and install a free software tool onto
your UNIX system.
The scripts in the /etc/init.d directory (or similar) are executed to start different
processes, background daemons, and services. These include NFS, Web servers,
database servers, and other components.
There is normally a separate directory, for example, /etc/init.d/rc3.d (the directory for
run level 3), that contains symbolic links to the scripts in /etc/init.d/. Each script has a
numeric prefix that controls the order in which the scripts are executed. When the
machine is started in run level 3, the scripts in /etc/init.d/rc3.d are executed, in order,
to start up the machine.
The run levels supported by Linux can be different to those in UNIX. Generally, run
level S/s/1 is always used for single-user (no network or background services)
mode. Run level 2 is the default multi-user mode, and run level 3 might be a
multi-user, networked, or file-sharing (for example, NFS, Samba) mode.
UNIX startup
Solaris, HP-UX, and AIX are slightly different in their startup operation. The init
daemon and the significance of the inittab are no different, but the significance of
different run levels might be different. For example, some Linux platforms use run
level 5 for multi-user Linux with a GUI login, while Solaris defines run level 5 as a
synonym for shutdown and power off (if possible) mode, as opposed to powering
down and returning the BOOTPROM prompt (supported on SPARC hosts).
AIX follows the Linux model, using /etc/init.d to hold scripts for starting background
services and daemons. HP-UX uses a slightly different model. There are separate
scripts for different run levels, but these are stored in /sbin/init.d and /sbin/rcX.d. In
other respects, the HP-UX model follows Linux.
Solaris, up until Solaris 9, closely resembled the Linux model, using individual scripts
and directories to hold the configuration of background daemons and services that
need to be started at boot time. The minor difference is that while all scripts have a
numerical prefix for adjusting the order of execution during startup, they also have a
prefix letter, S for startup and K for kill. The S-prefix scripts are executed during boot
time, or when changing from one run level to another. The K-prefix scripts are used
to shutdown services when the machine is configured for shutdown, reboot, or is
changing run levels.
Solaris 10 has changed the startup model completely and now uses the Service
Manager Framework (SMF) to control the execution of daemons and other scripts
and background tasks. SMF has benefits over the script based model in that it
monitors daemons to ensure they are re-spawned in the event of failure, and also
takes into account the dependencies of daemons and service availability. For
example, Solaris will not start NFS if networking has not been initiated.
For example, the Linux shutdown command brings the system down in a safe way,
and you can either poweroff: $ shutdown -h now or reboot the machine with this
command: $ shutdown -r now.
Note that with shutdown, you must specify when the shutdown should occur.
Neither option is suitable for changing the init state of a Linux machine to single-user
mode, for this, you must use init or telinit: $ init S.
Like Linux, AIX supports single-user shutdowns with init or telinit: $ init S.
HP-UX administrators must specify the time when the shutdown or reboot should
occur, and the desired state (reboot or halt). Hence, you can shutdown with: $
shutdown -h now or through telinit: $ telinit 0.
Reboot with the reboot command: $ shutdown -r now. Both the above will
prompt for confirmation, which you can skip using the -y option. With no options,
apart from the time specification, the shutdown switches the machine into
single-user mode: $ shutdown now or through telinit: $ telinit S.
Therefore, to shutdown (and switch off) the machine, you should use: $ shutdown
-i 0 now, or you can use init or telinit to change to run level 5, which shuts down
the machine (and if possible, powers the machine off): $ init 5.
To switch to single-user mode, you must explicitly state the init state to either
shutdown or init:
$ init s
$ shutdown -i S
Within Linux, all file systems (including those relating to non-physical storage, such
as /proc) are specified within the /etc/fstab file. Solaris uses the /etc/vfstab file, AIX
uses /etc/filesystems, and HP-UX uses /etc/fstab. All three use a different format.
You should use caution to ensure that you follow the guidelines always included in
the file comments.
NFS file shares are also handled differently across the different systems. Within
Linux, AIX, and HP-UX, you place the directory to be shared in /etc/exports. Within
Solaris, directories are exported by placing the corresponding share command you
would use to export the directory into the /etc/dfs/dfstab file. For example, within
Linux, you can export file systems by placing these two lines into /etc/exports:
/export/home *(sync)
/export/data *(sync)
Within Solaris, you would place the following two lines into /etc/dfs/dfstab:
share -F nfs -o rw /export/home
share -F nfs -o rw /export/data
The share command in Solaris is more less identical to the exportfs command in
Linux/AIX/HP-UX.
Swap configuration
Within Linux, swap space is configured automatically during boot using the entries
within the /etc/fstab. You can arbitrarily add swap space to a running Linux system
using the swapon command.
Solaris uses the swap command to add, list, and report on swap space information.
Default swap devices are listed in the /etc/vfstab file along with other file systems.
The swap command can be used both to interrogate the current swap information
and to add temporary swap space.
AIX uses the /etc/swapspaces file to hold a list of the available devices to be used
for swap space. These are configured automatically during boot. To add temporary
swap space, you can use the swapon command.
HP-UX provides an interface for configuring swap space through the swapon
command, but the list of the default swap space is configured in the /etc/fstab file.
Kernel configuration
Rebuilding the Linux kernel is a standard task that is used both to configure the
available modules and extensions and to control kernel configurable parameters,
such as the maximum number of open files or maximum number of processes. Linux
kernels also support loadable extension modules that extend the functionality of the
kernel or provide the interface to underlying hardware.
Within UNIX, however, the source for the kernel is not available, and so other
solutions are available for tuning kernel options and setting parameters. All the UNIX
kernels do, however, provide loadable module support.
You can obtain a list of the configurable parameters within AIX using the chdev
command. The same tool can also be used to adjust the parameters (if supported)
according to your needs.
HP-UX provides a kernel that can be rebuilt according to your new parameters and
configuration. The configuration information is contained in the /stand/system file,
although you should use one of the kernel configuration tools, such as kconfig,
which controls the kernel configuration, or kctune, which alters the tunable
parameters for a kernel. You can then rebuild the kernel using the mk_kernel
command based on those configured elements.
Within Solaris, all kernel parameters are controlled through the /etc/system file. To
alter the configuration of the kernel, tune the available parameters and then reboot
the system.
Within Solaris, for example, the default configuration restricts root logins to the
console of the host only -- this includes Telnet, ssh, and other remote access
mechanisms. To gain superuser privileges, you must log in as a standard user and
use su to obtain the privileges necessary for administration.
Most UNIX variants do not support the sudo tool for providing one-time authorization
and execution of a particular command, but it is possible to use one of the free
software alternatives.
Also, be aware that the wheel group used in Linux to determine whether a user can
use su to change to the root user is not valid within UNIX variants. HP-UX, for
example, provides special privileges for members of the adm group, and most UNIX
variants provide special privileges for different areas of the system (printing, disk
management, and so forth) to specific groups or users.
For getting basic information about the operating system, hardware, and other
details, there are a variety of methods and tools available. For example, Solaris
provides a lot of configuration information through the prtconf command, while AIX
provides a list of configured devices with the lscfg tool. Within HP-UX, studying the
contents of /var/adm/syslog/syslog.log provides you with a lot of information.
Across both Linux and UNIX, the dmesg command provides information about the
system determined or configured by the kernel during the boot process.
Devices in Linux and UNIX are referenced through the /dev directory or file system,
but the contents of the directory are not consistent, either across operating system
or platform. In Linux, for example, disk devices are referenced according to their
type and a unique, increasing number according the interface and device number.
Thus, the first available SCSI disk is /dev/sda, and the first partition is /dev/sda1.
AIX uses a similar system to Linux, referencing disks according to their existence
and availability in the system.
Within Solaris, disk devices are referenced directly according to their controller,
target, logical disk, and partition number. Therefore, the SCSI disk with SCSI ID 3 on
the first controller is available as /dev/dsk/c0t3d0. The first partition on that disk
would be /dev/dsk/c0t3d0s0. Similarly, with network devices, the exact name of the
device in the device directory can be different. Within Solaris, network devices are
named according to the driver -- you might find /dev/hme0 or /dev/qfe0 and others.
HP-UX, AIX, and Linux use a simple numbering system with a prefix. For example,
the first Ethernet interface on AIX is en0, HP-UX lan0, and Linux eth0.
As a general rule, it is best to check the device reference according to where the
devices are used (for example, disk devices in /etc/fstab or similar), referencing back
to the information usually contained in the output from dmesg to determine the right
device. In most cases, the structure of /dev is human-readable.
Within most UNIX variants, there is a specific tool available that configures the disk
system for the platform specific to the UNIX variant in use, and you must then create
a new file system on each partition that you have created to provide an area for
storage. The available file system types differ from platform to platform.
Solaris for SPARC uses the format tool to configuration partitions. Within Solaris
x86, you must use the fdisk tool to configure a PC partition on the disk before
using format to configure Solaris-specific partitions that will be used for individual
file systems.
Within AIX, you use the smitty tool to add a physical disk to the volume groups
used with the volume management tools. The primary file system type within AIX is
the JFS file system (Journaling) and the Enhanced JFS (JFS2).
Solaris supports the original ufs file system and has recently introduced ZFS
(Zettabyte file system). ZFS incorporates logical and physical volume management
and a flexible approach for the configuration of partitions, along with better reliability
through the support for journaling.
HP-UX also supports the original ufs file system, but also supports the vxfs
journaling system if you want slightly higher resilience.
Although Linux supports most file system options, this is largely because it was
designed to work within the confines of many operating systems and environments
and has had to support these different options to provide interoperability.
In reality, most Linux environments use the ext2 or ext3 file system, which provides
similar functionality to the ufs and JFS, respectively (although ufs does not support
journaling). The ReiserFS in Linux is another journaling system that provides for
much higher performance when opening or creating a larger number of files, but it is
similar to the journaling file systems in UNIX.
Table 7 lists the files ystems supported by the different operating systems.
ext3 Y Y N N N
ReiserFS Y Y N N N
XFS Y Y N N N
ZFS Y N Y N N
Where Linux and UNIX differ is in the finer points and aspects of the systems and, if
you can understand the core of these differences, migrating your skills and
experience becomes easy.
Resources
Learn
• For examining licensing, usability issues, and how best to install and integrate
free software into your commercial UNIX operating system, see: Use free
software within commercial UNIX (developerWorks, February 2006).
• The UNIX Guide provides a handy table for comparing some of the key
similarities and differences between different UNIX variants and Linux.
• The Comparison of Solaris, Linux and FreeBSD kernels is a useful reference for
some of the internal differences of these operating systems.
• Porting enterprise applications from UNIX to Linux is guide for porting from
UNIX to Linux, but provides a lot of useful information about porting and
differences in general.
• Guide to porting from Solaris to Linux on x86 provides Solaris specific
information for porting applications ().
• The Technical guide for porting applications from Solaris to Linux gives more
detailed technical information about the Solaris operating system.
• Although the z/OS UNIX System Services Porting Guide is targeted at the
zSeries® platform and z/OS® UNIX platform, there is a lot of good general and
practical advice that can be used for all UNIX porting projects.
• The IBM AIX Porting Redbook contains AIX specific porting information and
technical details.
• Want more? The developerWorks eServer™ zone hosts hundreds of
informative articles and introductory, intermediate, and advanced tutorials on
the eServer brand.
• The IBM developerWorks team hosts hundreds of technical briefings around the
world which you can attend at no charge.
Discuss
• Participate in the eServer forums.
• developerWorks blogs: Get involved in the developerWorks community.