Retool your Linux skills for commercial UNIX

Skill Level: Intermediate

Martin Brown ([email protected])

Freelance Writer
Consultant

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?

Section 1. Before you start

This tutorial covers how to migrate your Linux® skills so that you can get the best
out of AIX® and Solaris. You'll look at key topics, such as tools and principles, and
at the main differences between the booting, run control, and administration of these
systems.

About this tutorial

The Linux operating system is based on the same principles as the UNIX operating
system, and many of the principles that are familiar to a Linux operator are also
familiar to a UNIX operator.

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.

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 1 of 19
developerWorks® ibm.com/developerWorks

Topics included in this tutorial cover:

• Basic environment and principles

• Booting and shutting down
• Security and authentication
• File system and device management

Prerequisites
While no specific tools are needed to follow along with this tutorial, some familiarity
with Linux and UNIX is recommended.

Section 2. Understanding the Linux and UNIX

relationship
Linux and UNIX are very similar, but the differences that exist come from the history
of the respective operating systems, how they were developed, and how they
evolved.

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:

• Kernel -- The core of the UNIX system provides the pre-emptive

multitasking capability and support for multiple users. The kernel provides
the core infrastructure for the other operating system elements.
• Security -- The security model of UNIX is well known and tested and
relies on support for individual users, with each user having membership
of one or more groups. When determining user access to a particular
resource, your rights can be determined and controlled based on whether
you are the user, a member of an appropriate group, or whether you fall
into the "everybody else" category (other).
• Processes -- All applications beyond the kernel are deemed to be
processes, and all processes have ownership rules, priorities, and rights
and restrictions.
• File system -- The UNIX file system relies on the same security elements

Retool your Linux skills for commercial UNIX

Page 2 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

as supported elsewhere in the UNIX operating system, but it is also

infinitely extendable through a model of mount points within the core
structure, instead of identifying different drives by name or letter.
• Interface -- The core of any UNIX system is the command line interface,
usually through some sort of shell application that provides the
combination of application or tool execution, file manipulation, and basic
programming facilities.
None of these elements should be any surprise to either UNIX or Linux users and
administrators and, even from this basic list, you can see the similarities between the
two environments.

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.

Linux is more than a kernel

Linux today is referred to as a combination of the Linux kernel, as originally
developed by Linus Torvalds, and a wide range of additional tools and utilities that
make up the Linux operating system. The kernel alone is not enough, it is the
addition of elements, such as the shells, familiar command line tools (from ls to ps),
and even more complex tools and languages like sed and awk. Linux is really the
combination of the Linux kernel and other tools and utilities that make up a Linux
distribution, such as Red Hat or Gentoo.

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

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 3 of 19
developerWorks® ibm.com/developerWorks

UNIX command line tools.

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®.

Migrating skills from Linux to UNIX

Migrating your skills and experience from Linux to UNIX is not as complex as you
might first expect. As the previous sections have shown, Linux is based on the same
fundamentals as the UNIX operating system, although it followed the commercial
UNIX and original UNIX operating system development by a number of decades.

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.

Effectively migrating your skills is therefore about understanding the available

options and tools, understanding how to migrate those tools and applications that
are vital to your job, and learning about the tools and environments unique to your
new operating system.

Retool your Linux skills for commercial UNIX

Page 4 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

Section 3. Similarities and familiar principles

Linux and UNIX are very similar, and many users would be surprised to see the
similarities.

Authentication and security

Both Linux and UNIX share the same basic security and authentication principles.
The basics of a unique user ID for each user and the membership of one or more
groups. The user ID and the membership of these groups is what provides (or
restricts) access to all other aspects of the system, from their ability to manage and
control processes to file system access.

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.

All variants, including Linux, support network-wide authentication through the

Network Information Service (NIS), the extended and improved variant (NIS+) and
the Lightweight Directory Access Protocol (LDAP).

A summary of the security information is shown in Table 1 below.

Table 1. Authentication and Security summary

Aspect Linux Solaris AIX HP-UX
User file /etc/passwd /etc/passwd /etc/passwd /etc/passwd
Password file /etc/shadow /etc/shadow /etc/security/passwd/tcb/files/auth/r/root
/etc/shadow
Group file /etc/group /etc/group /etc/group /etc/group
Add user useradd useradd mkuser useradd
Delete user userdel userdel rmuser userdel

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 5 of 19
developerWorks® ibm.com/developerWorks

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.

Table 2. Core (POSIX) signals

No Name Default action Description
1 SIGHUP Terminate process Terminal line hangup
2 SIGINT Terminate process Interrupt program
3 SIGQUIT Create core image Quit program
4 SIGILL Create core image Illegal instruction
5 SIGTRAP Create core image Trace trap
6 SIGABRT Create core image Abort program (formerly
SIGIOT)
7 SIGEMT Create core image Emulate instruction
executed
8 SIGFPE Create core image Floating-point exception
9 SIGKILL Terminate process Kill program
10 SIGBUS Create core image Bus error
11 SIGSEGV Create core image Segmentation violation
12 SIGSYS Create core image Non-existent system
call invoked
13 SIGPIPE Terminate process Write on a pipe with no
reader
14 SIGALRM Terminate process Real-time timer expired
15 SIGTERM Terminate process Software termination
signal
16 SIGURG Discard signal Urgent condition
present on socket
17 SIGSTOP Stop process Stop (cannot be caught
or ignored)
18 SIGTSTP Stop process Stop signal generated
from keyboard
19 SIGCONT Discard signal Continue after stop
20 SIGCHLD Discard signal Child status has
changed

Retool your Linux skills for commercial UNIX

Page 6 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

21 SIGTTIN Stop process Background read

attempted from control
terminal
22 SIGTTOU Stop process Background write
attempted to control
terminal

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,

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 7 of 19
developerWorks® ibm.com/developerWorks

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

Retool your Linux skills for commercial UNIX

Page 8 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

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.

Table 3 summarizes the main points and configuration files or locations.

Table 3. Network configuration and tools

Aspect Linux Solaris AIX HP-UX
Basic IP /etc/sysconfig/network-scripts
/etc/hostname.* lsattr -E -l inet0 /etc/rc.config.d/netconf
configuration (Red Hat) /etc/inet/* Smitty SAM
/etc/conf.d/net /etc/defaultroute
(Gentoo)
/etc/sysconfig/network/ifcfg-*
(SuSE)
Name service /etc/nsswitch.conf /etc/nsswitch.conf /etc/nsswitch.conf /etc/nsswitch.conf
switch
Obtain network ipconfig -a ipconfig -a lanscan ipconfig -a
interface list
Set network config ifconfig ifconfig ifconfig ifconfig

Free software configuration and installation

Many of the free software packages that make up the core elements of the Linux
operating system have their history and roots in the UNIX operating system, where
they were often developed as a free alternative or improved versions of the original
core tools.

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.

Section 4. Booting UNIX

UNIX and Linux booting are controlled through a combination of the run level and
the scripts that are executed within the different run levels. All run level information
(and scripts) is controlled by the same process (init) and file (/etc/inittab).

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 9 of 19
developerWorks® ibm.com/developerWorks

Linux startup scripts and daemons

The majority of Linux variants work on the SVR4 model. The init daemon is executed
during boot and the contents of /etc/inittab are examined and processed. There is a
default run level, which is used in combination with the /etc/inittab file to determine
the mode (single user, multi-user, network enabled, and so forth) and this is
combined with a suite of scripts appropriate to each run level.

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

Retool your Linux skills for commercial UNIX

Page 10 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

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.

Shutdown and reboot

The shutdown and reboot commands are consistent across all Linux and UNIX
variants, but their use, arguments, and effects can differ considerably.

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.

The latter option is equivalent to: $ reboot.

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.

Within AIX, you poweroff a machine using shutdown with no arguments: $

shutdown.

Reboot with either: $ shutdown -r or $ reboot.

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.

Finally, in Solaris, the shutdown process is controlled by the shutdown command,

and you must specify both the time to shutdown (as with HP-UX) and the init state to
shutdown to by specifying the run level with the -i command line option.

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 reboot, you can use any of these commands:

$ reboot
$ shutdown -r
$ init 6

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 11 of 19
developerWorks® ibm.com/developerWorks

To switch to single-user mode, you must explicitly state the init state to either
shutdown or init:
$ init s
$ shutdown -i S

A summary of these is shown in the Table 4 below.

Table 4. Reboot and poweroff commands

OS Reboot Single user Shutdown or power
off
Linux reboot init S shutdown -h now
shutdown -r now init l init 0
init 6
Solaris reboot init S init 5
shutdown -r now shutdown -i S init 0
init 6 shutdown -i 0
AIX reboot init S shutdown
shutdown -r
HP-UX shutdown -r now telnit S shutdown -h now
reboot telinit 0

File systems and sharing

File systems are mounted during the boot process, according to the configuration file
for the operating system. The name (and format) of this file differs within the UNIX
variants compared to the Linux standard.

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.

Retool your Linux skills for commercial UNIX

Page 12 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

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.

Table 5 provides a summary of the main issues for swap space.

Table 5. Swap space configuration and commands

Aspect Linux Solaris AIX HP-UX
Swap config /etc/fstab /etc/vfstab /etc/swapspaces /etc/fstab
Show swap free swap -l lsps -a swapon -s
Add temp swap swapon -a swap -a swapon -a swapon -a
Physical RAM free ptconf bootinfo -r Check
/var/adm/syslog/syslog.log

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,

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 13 of 19
developerWorks® ibm.com/developerWorks

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.

Table 6 illustrates a summary of the main points.

Table 6. Kernel configuration

Aspect Linux Solaris AIX HP-UX
List Kernel sysctl -a sysdef -i lsattr -E -l sys0 sysdef
parameters
Reconfigure kernel make Edit /etc/system chdev -1 sys0 kconfig
menuconfig Reboot kctune
Install kernel mk_kernel
Adjust boot Reboot
loader
Reboot
List modules lsmod modinfo genkex kmadmin -s
Load module insmod modload kmadmin -L
Unload module rmmod modunload kmadmin -U

Section 5. Basic administration tools and environments

The basic administration of your system is handled through the command line and
the root user. Some aspects of the administration, however, are different depending
on your target UNIX environment.

Superuser or root privileges

The idea of a superuser and root privileges originated in the UNIX operating system
and, along with other elements of the authentication and security system, is a key
part of the administration of a UNIX host. There are, however, some minor
differences with UNIX variants.

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.

Retool your Linux skills for commercial UNIX

Page 14 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

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.

System configuration and attributes

Most UNIX variants do not use the /proc file system. You should not use /proc as a
method for finding and locating information about the operating system or running
processes. A limited version /proc is available within Solaris, but detailed process
information should be extracted using the ptools suite of commands.

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.

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 15 of 19
developerWorks® ibm.com/developerWorks

Disk and file system management

The partition for disks within Linux is handled through the fdisk tool (on Intel, AMD,
and other x86 systems), or through a host- or platform-specific tool on other
platforms. This tool is consistent across disk devices, whether they are IDE-, SATA-,
or SCSI-based.

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.

Table 7. File systems supported by the different operating systems

File systems Journaling Linux Solaris AIX HP-UX
ufs N Partial Y N Y
Veritas (vxfs) Y Y Y N N
JFS Y Y N Y N
JFS2 Y Y N Y N
ext2 N Y N N N

Retool your Linux skills for commercial UNIX

Page 16 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

ext3 Y Y N N N
ReiserFS Y Y N N N
XFS Y Y N N N
ZFS Y N Y N N

Section 6. Summary and resources

Linux is based on many of the same principles as UNIX -- processes, user
authentication, authorization, and the tools and environment that manage and
administer the operating systems are, on the whole, identical. You can still use the
shell, same user or group security mechanism, and manage users and processes in
the same way.

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.

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 17 of 19
developerWorks® ibm.com/developerWorks

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.

About the author

Martin Brown
Martin Brown has been a professional writer for over eight years. He is the author of
numerous books and articles across a range of topics. His expertise spans myriad
development languages and platforms -- Perl, Python, Java, JavaScript, Basic,
Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS,
Mac OS/X and more -- as well as Web programming, systems management, and

Retool your Linux skills for commercial UNIX

Page 18 of 19 © Copyright IBM Corporation 1994, 2006. All rights reserved.
ibm.com/developerWorks developerWorks®

integration. Martin is a regular contributor to ServerWatch.com, LinuxToday.com, and

IBM developerWorks, and a regular blogger at Computerworld, The Apple Blog and
other sites, as well as a Subject Matter Expert (SME) for Microsoft. He can be
contacted through his Web site at http://www.mcslp.com.

Retool your Linux skills for commercial UNIX

© Copyright IBM Corporation 1994, 2006. All rights reserved. Page 19 of 19