Wednesday, September 30, 2009

Enabling Scan to Linux FTP

Purpose
This document provides a procedure to configure scanning to Linux via FTP. Your
Xerox multifunction device must have the Network Scanning software option enabled to
follow this procedure.
Procedure
To configure scanning to Linux via FTP, follow the steps below. The sections that
follow explain these steps in detail.
1. Create a new user account.
2. Create a scanning repository.
3. Assign permissions to selected accounts.
4. Test the FTP connection.
5. Configure the Xerox device.
6. Scan a test page.
Create a New User Account
When a document is scanned, the Xerox device uses a user account on the scan
server to log into the Linux scan repository. After a successful logon, it files the jobs in
the appropriate folder on the scan server. Follow these steps to create the user
account for the Xerox device.
1. Obtain root access to the Linux server you use as the repository. Either:
• Log in to the server with root access.
• Type su and enter the root password.
2. At the Linux prompt, type useradd .
3. Type passwd .
4. Enter a password and verify it when prompted. The password must have at least
six characters.
Xerox Multifunction Devices
Customer Tips
… for the user
dc00cc0107
June 10, 2003
This document applies
to these Xerox
products:
X WC Color 40/32
X WC Pro 90/75/65
X WC Pro 55/45/35
WC Basic 55/45/35
X DC 555/545/535
X DC 490/480/470/460
X DC 440/432/425/420
X DC 340/332
X DC 265/255/240
X DC 230/220
DCCS 50
dc00cc0107
Page 2 Customer Service
Create a Scanning Repository
1. Once again, either:
• Log in to the server with root access.
• Type su and enter the root password.
2. Type cd / to return to the root directory.
3. Type cd home/.
4. To create a new directory to which scanned documents are added, type
mkdir .
5. Type ifconfig and make a note of the IP address.
Assign Permissions to Selected Account(s)
The steps in this section give the user created in “Create a New User Account” full
ownership (read and write access) of the directory created in “Create a Scanning
Repository.”
1. Log in as root.
2. To return to the root directory, type cd /. Type cd home/ to get to
the Xerox device’s home directory.
3. To view the owner and privileges for the scan repository in the user’s home
directory, type ls –l.
4. Type chown to assign ownership of the scan
directory to the user account you specify.
5. Type ls -l to redisplay the owner and privileges for each directory and file in the
root directory. Verify the user account you specified is now the owner of the scan
directory. The result of such a session is shown in the example below.
[anurkhet@chapeau anurkhet]$ ls -l
total 1673
-rw-rw-r-- 1 anurkhet anurkhet 477 Feb 16 11:41 Xrootenv.0
-rwxrwxr-x 1 anurkhet anurkhet 15931 Feb 4 18:07 ato
-rw-r--r-- 1 anurkhet anurkhet 43222 Feb 16 11:47 chewy.1
-rw-r--r-- 1 anurkhet anurkhet 517458 Feb 16 11:47 chewy:2.1
-rw-r--r-- 1 anurkhet anurkhet 569 Feb 16 11:47 chewy:2.1.rcv
-rw-r--r-- 1 anurkhet anurkhet 589 Feb 16 11:47 chewy:2.rcv
-rw-rw-r-- 1 anurkhet anurkhet 280 Feb 4 18:06 demo.cpp
-rw-rw-r-- 1 anurkhet anurkhet 1182 Feb 4 18:24 employee.cpp
-rw-r--r-- 1 anurkhet anurkhet 94818 Feb 17 10:52 log.txt
-rw-r--r-- 1 anurkhet anurkhet 3854 Dec 10 15:21 ps_lakes
drwxrwxr-x 2 anurkhet anurkhet 1024 Feb 22 09:57 scan
-rw-rw-r-- 1 anurkhet anurkhet 1239 Dec 9 18:21 test_printcap
-rw-rw-r-- 1 anurkhet anurkhet 0 Feb 22 09:59 typescript
-rwxrwxr-x 1 anurkhet anurkhet 4589 Feb 4 18:24 wage
[anurkhet@chapeau anurkhet]$
The user account, scan directory, and access privileges are now configured at the
Linux scan repository.
Testing the FTP Connection
To test the FTP connection, perform the following steps at a workstation or server other
than the Linux server on which the scan repository resides.
1. From a command line, type ftp .
2. Login with the username and password created in “Create a New User Account.”
3. To list the contents of the FTP root directory, type dir.
dc00cc0107
Customer Service Page 3
4. To verify you have write access, type put . Your workstation sends
the specified file to the Linux scan repository.
5. To list the contents of the directory, type dir. The file you specified in step 4 is
displayed.
6. To disconnect and exit the FTP program, type quit.
Configure the Xerox Device Using CentreWare Internet Services
Follow the steps in this section to configure the Xerox device to use the new scanning
repository created on the Linux FTP server.
1. Open your Web browser and enter the IP address of the Xerox device in the
address bar.
2. Select the [Properties] link/tab.
• WC Color 32/40, WC Pro 65/75/90, WC Pro 35/45/55, and DC 555/545/535 –
Expand Services, Network Scanning, and select File Repository Setup.
Select [Add] or [Edit] to configure the Default File Destination.
• DC 490/480/470/460 and DC 265/255/240 – Expand Services, Distribution
Templates, and select Repository Setup.
• DC 440/432/425/420, DC 340/332, and DC 230/220 – Expand Services,
Stored Templates, and select Repository Setup
3. Enter the following information:
• Protocol – TCP/IP
• IP address of the Linux FTP server
• A folder name in the Document Path field (leave this field blank if you’re
scanning to the root directory).
• The login name and password you created in "Create a New User Account."
4. Select [Apply]. Enter the Xerox device’s admin user ID and password.
Create a Scan Template Using CentreWare Internet Services
Access the Xerox device’s Web user interface. For the WC Pro devices, select the
Scan link/tab. For all DC devices, select the Services link/tab.
• WC Color 32/40, WC Pro 65/75/90, and WC Pro 35/45/55 – Select [New Template],
give your template a name, and select [Add].
• DC 555/545/535 – Select Scan: Distribution Templates, select [New Template],
enter your template a name, and select [Add].
• DC 490/480/470/460, DC 265/255/240 – Select Distribution Templates, select
[New], enter your template a name, and select [Apply].
• DC 440/432/425/420, DC 340/332, DC 230/220 – Select Stored Templates, select
[New], enter your template a name, select the File check box, and select [Apply].
Your Linux FTP server is now configured as a scan repository, and has a scan
template that points to the repository folder. Go to the Xerox device, update the
template list and scan a job.
NOTE: If you wish to use CentreWare Network Scanning Services to set up a scan
server on your Linux FTP server, use your documentation about CentreWare Network
Scanning Services installation for the instructions.
dc00cc0107
Page 4 Customer Service
Additional Information
Xerox Customer Service welcomes feedback on all documentation - send feedback via
e-mail to: USA.DSSC.Doc.Feedback@mc.usa.xerox.com.
Other Tips about Xerox multifunction devices are available at the following URL:
http://www.xerox.com/DocumentCentreFamily/Tips.
XEROX ®, The Document Company ®, the digital X ®, and all Xerox product names are trademarks of
XEROX CORPORATION. Other trademarks belong to their respective owners.
Copyright © XEROX CORPORATION 2003. All Rights Reserved.

Linux Kernel development Ian McDonald

University of Waikato
ian.mcdonald@jandi.co.nz
Abstract. This paper focuses on the process of development for the
Linux kernel. This topic is approached both from a technical viewpoint
and also the interactions with the open source community. The aim of
the paper is for readers not to have the same diculties the author
experienced!
Keywords: Operating Systems
1 Introduction
This paper discusses the social aspects of kernel development, followed by tips
for building a kernel. The paper then focusses on releasing code and lastly, but
not least important, testing and debugging.
The paper highlights some of the lessons learned by the author and the
methodology used in developing within the kernel.
2 Building a kernel
2.1 Maintaining a source code tree
Keeping in synchronisation with the Linux kernel source code tree takes a nontrivial
amount of time. It is necessary to keep synchronised if it is intended to
have the code merged into the tree or released as an ongoing codebase.
The Linux source code is maintained in a git [1] tree. Git is a new source
code management tool created by Linus Torvalds. Git stores every change as a
patch addressed by a SHA1 hash. Developers can make copies of git trees and
because each patch is unique it is relatively simple for developers to synchronise
their code base with other developers.
For developing in the kernel it is recommended to make a copy of Linus
Torvalds’ source code tree by issuing a statement similar to:
git-clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
~/linuxsrc/linus
and then using git-pull to keep the git tree up to date. If the maintainer for
the area that is being developed keeps a separate git tree, as most do, then you
will need to create a copy of it by issuing a statement similar to:
git-clone --reference ~/linuxsrc/linus \
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git \
~/linuxsrc/davem
When the above syntax is used it uses the local copy where possible making
synchronisation quicker and uses a fraction of the bandwidth.
It is often useful to use a patch management tool on top of git such as stgit
[2] or quilt [3]. These tools allow a series of patches to be maintained as a “stack”
of patches which can be applied against di erent or updated trees.
Often a maintainer will “rebase” their tree which means they delete their
original tree, make a fresh clone of Linus’ tree and then they will reapply any
outstanding patches to that tree. If a maintainer rebases their tree then it is
usually not possible to update it using the git-pull or stg pull command.
Presuming the use of stgit, issue the command stg export to export the patches
(this should also be done before any pull in case of a problem), save the files that
are under patches-branch in a temporary directory, clone the git tree again to
the latest tree and then import the patches into the new tree by stg import.
2.2 Use of distcc
To speed up compilation if multiple machines are available then distcc [4] can be
used which is a distributed C compiler, and then specifying to make how many
parallel threads to run using the -j parameter. For kernel development there
are a couple of caveats to be aware of. The same version of the C compiler gcc
must be installed on the machines that are being used as a compile pool. It is
also important to specify only one target on the command line or else the kernel
will continue to rebuild from scratch each time the make command is issued.
For example to build a kernel and prepare for it to be installed the following
commands could be issued:
make -j6 CC=distcc all
make modules_install INSTALL_MOD_PATH=~/tmp
2.3 Other resources
For an introduction to Linux development there are excellent resources available
such as [5] and [6]. The use of simple tools should also not be underestimated
such as the use of grep -n -r phrase to find a symbol in the kernel. The author
also maintains a Wiki page at http://wlug.org.nz/KernelDevelopment which
contains other tips.
3 Releasing code
An often cited mantra in the open source community is “release early and release
often” [7]. This concept is useful even prior to code release.
It can productive to talk about what you are planning to implement. This
can be useful as other people can inform you if they are working on similar
code as is often the case. It also gives people an opportunity to give feedback on
whether the ideas are good or need refining.
Once the ideas have been crystallised it is often useful to release a code as a
request for comment (RFC) if the code is not ready to be merged. This, again,
allows discussion of the ideas being implemented.
The code will probably go through many, many iterations so if the code
is rejected then it is important to work on the areas highlighted rather than
becoming disheartened.
When developing code for the kernel it needs to be submitted to the maintainer
of the subsystem. The MAINTAINERS file in the top level directory of the
Linux source code tree contains the list of the maintainers. A posting to the
linux-kernel list or other kernel mailing lists will usually produce a response on
how the code is maintained if it is not clear.
Any code released should always be against the latest tree of the maintainer.
One of the biggest reasons that code isn’t accepted is that the maintainer cannot
use it as it applies against an older version of Linux.
When code is submitted it must be able to be applied without problems by
the maintainer. Prior to submitting test each patch with:
git-apply --check --whitespace=error < mypatch.diff
It is also required to choose a mail client to send the patch which does not
alter whitespace such as spaces being substituted for tabs, breaking lines up or
sending as HTML. The author uses KMail as he has found this is one of the few
that will meet these criteria.
The code and patches should also fit into the existing kernel code style. The
Documentation directory of the Linux source code contains many useful guides
to assist with this.
It is recommended for a developer to submit kernel changes in multiple small
patches rather than one large patch. This is that so the change can be reviewed
in a series of steps which are simpler to read and find bugs in. If multiple patches
are provided then part of the change can be accepted, rather than all rejected if
one large patch is used.
4 Testing and debugging
It is important that code is well tested before it is released.
There are a number of virtualisation tools available to assist with testing
software such as qemu [8], UML [9], VMWare [10] and Xen [11]. These tools can
make testing easier if computers with sucient processing power are used. Any
software developed should also be tested on computers natively as well as this
can uncover separate bugs.
There are debugging tools available that can be used on the kernel such as
gdb. The simplest debugging tool to use for timing dependent code is the printk
statement in the code which acts like a printf statement, except the output goes
to the kernel logging daemon. If it is desired to find which patch caused a bug
then git-bisect can be used to “divide and conquer” the code base.
In the kernel there is also a mechanism for tracing code execution and capturing
data called kprobes which allows hooks to be added into any function entry
or exit dynamically without any changes being made to the original function. In
our research we have taken an implementation of this for monitoring TCP and
implemented it for DCCP.
With testing it is often necessary to transfer newly built kernels to multiple
machines. This can be automated through a script such as:
#! /bin/bash
# syntax m machine_name directory version
H=$HOME
SRC=$H/linuxsrc/$2
VER=$3
rm $H/tmp/lib/modules/$VER/build
rm $H/tmp/lib/modules/$VER/source
rsync $SRC/System.map root@$1:/boot/System.map-$VER
rsync $SRC/arch/i386/boot/bzImage root@$1:/boot/vmlinuz-$VER
rsync -av $H/tmp/lib/modules/$VER root@$1:/lib/modules
5 Conclusion
Development in the Linux kernel is more than simply editing code and typing
make all. It is the hope of the authour that this paper helps more people develop
in the Linux kernel by taking into account other considerations and applying
these.
References
1. Web: git. http://git.or.cz/ (Accessed 2006)
2. Web: Stacked git. http://www.procode.org/stgit/ (Accessed 2006)
3. Web: Quilt patch management tools. http://savannah.nongnu.org/projects/quilt/
(Accessed 2006)
4. Pool, M., et al.: Distcc: a fast, free distributed c/c++ compiler, 2002–. URL
http://distcc. samba. org
5. Love, R.: Linux Kernel Development. Second edn. Novell Press (2005)
6. Web: Lxr. http://lxr.linux.no/ (Accessed 2006)
7. Raymond, E.: Cathedral & the Bazaar: Musings on Linux and Open Source by an
Accidental Revolutionary. (2001)
8. QEMU, C.: Emulator. URL: http://fabrice. bellard. free. fr/qemu
9. Dike, J.: A user-mode port of the Linux kernel. Proceedings of the Annual Linux
Showcase. Atlanta, GA, Oct (2000)
10. VMware, I.: The VMWare software package. See http://www. vmware. com
11. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer,
R., Pratt, I., Warfield, A.: Xen and the art of virtualization. Proceedings of the
nineteenth ACM symposium on Operating systems principles (2003) 164–177

Overview of Linux-Kernel Reference Counting

Paul E. McKenney
Linux Technology Center
IBM Beaverton
paulmck@us.ibm.com
Document number: N2167=07-0027
Date: 2007-01-12
Project: Programming Language C++, Evolution
Working Group
Reply-to: paulmck@linux.vnet.ibm.com
Revision: Draft 1
Abstract
This document describes several reference-counting
disciplines used in the Linux kernel, and con-
cludes by summarizing the memory-barrier, atomic-
instruction, and compiler-control required by each.
This material is adapted from a tutorial document,
so the alert reader may notice a few departures from
the typical standards-document style.
These disciplines show ample precedent for spec-
ifying that a given variable should have atomic re-
sponse to normal loads and stores, and for the ability
to separately specify atomic operations, memory bar-
riers, and disabling of compiler optimizations in uses
of variables.
1 Introduction
Reference counting tracks the number of references to
a given object in order to prevent that object from
being prematurely freed. Although this is a concep-
tually simple technique, there are a great many vari-
ants adapted to di erent situations. This is analo-
gous to similar situations in construction, for exam-
Release Synchronization
Acquisition Reference
Synchronization Locking Counting RCU
Locking - CAM CA
Reference A AM A
Counting
RCU CA MCA CA
Table 1: Reference Counting and Synchronization
Mechanisms
ple, a hinge is simply a hinge, but there is an aston-
ishing variety of hinges for di erent purposes. Insist-
ing that programmers use a single style of reference
counting is as nonsensical as insisting that all doors
and cabinets use a single style of hinge – after all, a
hinge designed for a bank vault might be inappropri-
ate for a kitchen cabinet.1 The examples herein are
taken from the Linux 2.6.19 kernel, with primitives
described in Section 3.
A key reason for the variety of reference-counting
techniques is the wide variety of mechanisms used
to protect objects from concurrent access. Further-
more, the same object might be protected by dif-
ferent mechanisms at di erent times, which further
increases the required number of styles of reference
counting. In the Linux kernel, the main categories of
synchronization mechanisms are (1) locking, includ-
ing semaphores and mutexes, (2) reference counts,
1My wife concurs, with the possible exception of kitchen
cabinets filled with trues. Your mileage with your own spouse
may vary.
1
and (3) RCU. Table 1 divides reference-counting
mechanisms into the following broad categories:
1. Simple counting with neither atomic opera-
tions, memory barriers, nor alignment con-
straints (“-”).
2. Atomic counting without memory barriers
(“A”).
3. Atomic counting, with memory barriers required
only on release (“AM”).
4. Atomic counting with a check combined with the
atomic acquisition operation, and with memory
barriers required only on release (“CAM”).
5. Atomic counting with a check combined with the
atomic acquisition operation (“CA”).
6. Atomic counting with a check combined with the
atomic acquisition operation, and with memory
barriers also required on acquisition (“MCA”).
However, because all Linux-kernel atomic operations
that return a value are defined to contain mem-
ory barriers, all release operations contain memory
barriers, and all checked acquisition operations also
contain memory barriers. Therefore, cases “CA”
and “MCA” are equivalent to “CAM”. Therefore,
there are sections below for only the first four cases:
“-”, “A”, “AM”, and “CAM”. The Linux primitives
that support reference counting are presented in Sec-
tion 3. Later sections cite optimizations that can
improve performance if reference acquisition and re-
lease is very frequent, and the reference count need
be checked for zero only very rarely.
2 Implementation of
Reference-Counting Categories
Simple counting protected by locking (“-”) is de-
scribed in Section 2.1, atomic counting with no mem-
ory barriers (“A”) is described in Section 2.2 atomic
counting with acquisition memory barrier (“AM”) is
described in Section 2.3, and atomic counting with
check and release memory barrier (“CAM”) is de-
scribed in Section 2.4.
2.1 Simple Counting
Simple counting, with neither atomic operations nor
memory barriers, can be used when the reference-
counter acquisition and release are both protected
by the same lock. In this case, it should be clear
that the reference count itself may be manipulated
non-atomically, because the lock provides any neces-
sary exclusion, memory barriers, atomic instructions,
and disabling of compiler optimizations. This is the
method of choice when the lock is required to protect
other operations in addition to the reference count,
but where a reference to the object must be held after
the lock is released. Figure 1 shows a simple API that
might be used to implement simple non-atomic ref-
erence counting – although simple reference counting
is almost always open-coded instead.
1 struct sref {
2 int refcount;
3 };
4
5 void sref_init(struct sref *sref)
6 {
7 sref->refcount = 1;
8 }
9
10 void sref_get(struct sref *sref)
11 {
12 sref->refcount++;
13 }
14
15 int sref_put(struct sref *sref,
16 void (*release)(struct sref *sref))
17 {
18 WARN_ON(release == NULL);
19 WARN_ON(release == (void (*)(struct sref *))kfree);
20
21 if (--sref->refcount == 0) {
22 release(sref);
23 return 1;
24 }
25 return 0;
26 }
Figure 1: Simple Reference-Count API
2
2.2 Atomic Counting
Simple atomic counting may be used in cases where
any CPU acquiring a reference must already hold a
reference. This style is used when a single CPU cre-
ates an object for its own private use, but must allow
other CPU, tasks, timer handlers, or I/O completion
handlers that it later spawns to also access this ob-
ject. Any CPU that hands the object o must first
acquire a new reference on behalf of the recipient ob-
ject. In the Linux kernel, the kref primitives are
used to implement this style of reference counting, as
shown in Figure 2.
Atomic counting is required because locking is not
used to protect all reference-count operations, which
means that it is possible for two di erent CPUs to
concurrently manipulate the reference count. If nor-
mal increment and decrement were used, a pair of
CPUs might both fetch the reference count concur-
rently, perhaps both obtaining the value “3”. If both
of them increment their value, they will both ob-
tain “4”, and both will store this value back into the
counter. Since the new value of the counter should
instead be “5”, one of the two increments has been
lost. Therefore, atomic operations must be used both
for counter increments and for counter decrements.
If releases are guarded by locking or RCU, mem-
ory barriers are not required, but for di erent rea-
sons. In the case of locking, the locks provide any
needed memory barriers (and disabling of compiler
optimizations), and the locks also prevent a pair of re-
leases from running concurrently. In the case of RCU,
cleanup must be deferred until all currently executing
RCU read-side critical sections have completed, and
any needed memory barriers or disabling of compiler
optimizations will be provided by the RCU infras-
tructure. Therefore, if two CPUs release the final
two references concurrently, the actual cleanup will
be deferred until both CPUs exit their RCU read-
side critical sections.
Quick Quiz 1: Why isn’t it necessary to guard
against cases where one CPU acquires a reference just
after another CPU releases the last reference?
The kref structure itself, consisting of a single
atomic data item, is shown in lines 1-3 of Fig-
ure 2. The kref_init() function on lines 5-8 ini-
1 struct kref {
2 atomic_t refcount;
3 };
4
5 void kref_init(struct kref *kref)
6 {
7 atomic_set(&kref->refcount,1);
8 }
9
10 void kref_get(struct kref *kref)
11 {
12 WARN_ON(!atomic_read(&kref->refcount));
13 atomic_inc(&kref->refcount);
14 }
15
16 int kref_put(struct kref *kref,
17 void (*release)(struct kref *kref))
18 {
19 WARN_ON(release == NULL);
20 WARN_ON(release == (void (*)(struct kref *))kfree);
21
22 if ((atomic_read(&kref->refcount) == 1) ||
23 (atomic_dec_and_test(&kref->refcount))) {
24 release(kref);
25 return 1;
26 }
27 return 0;
28 }
Figure 2: Linux Kernel kref API
tializes the counter to the value “1”. Note that the
atomic_set() primitive is a simple assignment, the
name stems from the data type of atomic_t rather
than from the operation. The kref_init() function
must be invoked during object creation, before the
object has been made available to any other CPU.
The kref_get() function on lines 10-14 uncon-
ditionally atomically increments the counter. The
atomic_inc() primitive does not necessarily explic-
itly disable compiler optimizations on all platforms,
but the fact that the kref primitives are in a separate
module and that the Linux kernel build process does
no cross-module optimizations has the same e ect.
The kref_put() function on lines 16-28 checks for
the counter having the value “1” on line 22 (in which
case no concurrent kref_get() is permitted), or if
atomically decrementing the counter results in zero
on line 23. In either of these two cases, kref_put()
invokes the specified release function and returns
“1”, telling the caller that cleanup was performed.
Otherwise, kref_put() returns “0”.
Quick Quiz 2: If the check on line 22 of Figure 2
fails, how could the check on line 23 possibly succeed?
3
Quick Quiz 3: How can it possibly be safe to non-
atomically check for equality with “1” on line 22 of
Figure 2?
2.3 Atomic Counting With Release
Memory Barrier
This style of reference is used in the Linux kernel’s
networking layer to track the destination caches that
are used in packet routing. The actual implementa-
tion is quite a bit more involved; this section focuses
on the aspects of struct dst_entry reference-count
handling that matches this use case, shown in Fig-
ure 3.
1 static inline
2 struct dst_entry * dst_clone(struct dst_entry * dst)
3 {
4 if (dst)
5 atomic_inc(&dst->__refcnt);
6 return dst;
7 }
8
9 static inline
10 void dst_release(struct dst_entry * dst)
11 {
12 if (dst) {
13 WARN_ON(atomic_read(&dst->__refcnt) < 1);
14 smp_mb__before_atomic_dec();
15 atomic_dec(&dst->__refcnt);
16 }
17 }
Figure 3: Linux Kernel dst clone API
The dst_clone() primitive may be used if the
caller already has a reference to the specified dst_
entry, in which case it obtains another reference that
may be handed o to some other entity within the
kernel. Because a reference is already held by the
caller, dst_clone() need not execute any memory
barriers. The act of handing the dst_entry to some
other entity might or might not require a memory
barrier, but if such a memory barrier is required, it
will be embedded in the mechanism used to hand the
dst_entry o .
The dst_release() primitive may be invoked
from any environment, and the caller might well ref-
erence elements of the dst_entry structure imme-
diately prior to the call to dst_release(). The
dst_release() primitive therefore contains a mem-
ory barrier on line 14 preventing both the compiler
and the CPU from misordering accesses.
Please note that the programmer making use of
dst_clone() and dst_release() need not be aware
of the memory barriers, only of the rules for using
these two primitives.
2.4 Atomic CountingWith Check and
Release Memory Barrier
The fact that reference-count acquisition can run con-
currently with reference-count release adds further
complications. Suppose that a reference-count re-
lease finds that the new value of the reference count
is zero, signalling that it is now safe to clean up the
reference-counted object. We clearly cannot allow a
reference-count acquisition to start after such clean-
up has commenced, so the acquisition must include
a check for a zero reference count. This check must
be part of the atomic increment operation, as shown
below.
Quick Quiz 4: Why can’t the check for a zero ref-
erence count be made in a simple “if” statement with
an atomic increment in its “then” clause?
The Linux kernel’s fget() and fput() primitives
use this style of reference counting. Simplified ver-
sions of these functions are shown in Figure 4.
Line 4 of fget() fetches the a pointer to the
current process’s file-descriptor table, which might
well be shared with other processes. Line 6 invokes
rcu_read_lock(), which enters an RCU read-side
critical section. The callback function from any sub-
sequent call_rcu() primitive will be deferred until a
matching rcu_read_unlock() is reached (line 10 or
14 in this example). Line 7 looks up the file structure
corresponding to the file descriptor specified by the
fd argument, as will be described later. If there is an
open file corresponding to the specified file descriptor,
then line 9 attempts to atomically acquire a reference
count. If it fails to do so, lines 10-11 exit the RCU
read-side critical section and report failure. Other-
wise, if the attempt is successful, lines 14-15 exit the
read-side critical section and return a pointer to the
file structure.
4
1 struct file *fget(unsigned int fd)
2 {
3 struct file *file;
4 struct files_struct *files = current->files;
5
6 rcu_read_lock();
7 file = fcheck_files(files, fd);
8 if (file) {
9 if (!atomic_inc_not_zero(&file->f_count)) {
10 rcu_read_unlock();
11 return NULL;
12 }
13 }
14 rcu_read_unlock();
15 return file;
16 }
17
18 struct file *
19 fcheck_files(struct files_struct *files, unsigned int fd)
20 {
21 struct file * file = NULL;
22 struct fdtable *fdt = rcu_dereference((files)->fdt);
23
24 if (fd < fdt->max_fds)
25 file = rcu_dereference(fdt->fd[fd]);
26 return file;
27 }
28
29 void fput(struct file *file)
30 {
31 if (atomic_dec_and_test(&file->f_count))
32 call_rcu(&file->f_u.fu_rcuhead, file_free_rcu);
33 }
34
35 static void file_free_rcu(struct rcu_head *head)
36 {
37 struct file *f;
38
39 f = container_of(head, struct file, f_u.fu_rcuhead);
40 kmem_cache_free(filp_cachep, f);
41 }
Figure 4: Linux Kernel fget/fput API
The fcheck_files() primitive is a helper function
for fget(). It uses the rcu_dereference() prim-
itive to safely fetch an RCU-protected pointer for
later dereferencing (this emits a memory barrier on
CPUs such as DEC Alpha in which data dependen-
cies do not enforce memory ordering). Line 22 uses
rcu_dereference() to fetch a pointer to this task’s
current file-descriptor table, and line 24 checks to see
if the specified file descriptor is in range. If so, line 25
fetches the pointer to the file structure, again using
the rcu_dereference() primitive. Line 26 then re-
turns a pointer to the file structure or NULL in case
of failure.
The fput() primitive releases a reference to a file
structure. Line 31 atomically decrements the refer-
ence count, and, if the result was zero, line 32 in-
vokes the call_rcu() primitives in order to free up
the file structure (via the file_free_rcu() function
specified in call_rcu()’s second argument), but only
after all currently-executing RCU read-side critical
sections complete. The time period required for all
currently-executing RCU read-side critical sections to
complete is termed a “grace period”. Note that the
atomic_dec_and_test() primitive contains a mem-
ory barrier. This memory barrier is not necessary in
this example, since the structure cannot be destroyed
until the RCU read-side critical section completes,
but in Linux, all atomic operations that return a re-
sult must by definition contain memory barriers.
Once the grace period completes, the file_free_
rcu() function obtains a pointer to the file structure
on line 39, and frees it on line 40.
This approach is also used by Linux’s virtual-
memory system, see get_page_unless_zero() and
put_page_testzero() for page structures as well
as try_to_unuse() and mmput() for memory-map
structures.
3 Linux Primitives Supporting
Reference Counting
The Linux-kernel primitives used in the above exam-
ples are summarized in the following list. The RCU
primitives may be unfamiliar to some readers, so a
5
brief overview with citations is included in Section 5.
• atomic t Type definition for 32-bit quantity to
be manipulated atomically.
• void atomic dec(atomic t *var); Atomi-
cally decrements the referenced variable without
necessarily issuing a memory barrier or disabling
compiler optimizations.
• int atomic dec and test(atomic t
*var); Atomically decrements the refer-
enced variable, returning TRUE if the result
is zero. Issues a memory barrier and disables
compiler optimizations that might otherwise
move memory references across this primitive.
• void atomic inc(atomic t *var); Atomi-
cally increments the referenced variable without
necessarily issuing a memory barrier or disabling
compiler optimizations.
• int atomic inc not zero(atomic t
*var); Atomically increments the refer-
enced variable, but only if the value is non-zero,
and returning TRUE if the increment occurred.
Issues a memory barrier and disables com-
piler optimizations that might otherwise move
memory references across this primitive.
• int atomic read(atomic t *var); Returns
the integer value of the referenced variable. This
is not an atomic operation, and it neither issues
memory barriers nor disables compiler optimiza-
tions.
• void atomic set(atomic t *var, int
val); Sets the value of the referenced
atomic variable to “val”. This is not an atomic
operation, and it neither issues memory barriers
nor disables compiler optimizations.
• void call rcu(struct rcu head
*head, void (*func)(struct rcu head
*head)); Invokes func(head) some time after
all currently executing RCU read-side critical
sections complete, however, the call_rcu()
primitive returns immediately. Note that head
is normally a field within an RCU-protected
data structure, and that func is normally
a function that frees up this data structure.
The time interval between the invocation of
call_rcu() and the invocation of func is
termed a “grace period”. Any interval of time
containing a grace period is itself a grace period.
• type *container of(p, type, f); Given a
pointer “p” to a field “f” within a structure of the
specified type, return a pointer to the structure.
• void rcu read lock(void); Marks the begin-
ning of an RCU read-side critical section.
• void rcu read unlock(void); Marks the end
of an RCU read-side critical section. RCU read-
side critical sections may be nested.
• void smp mb before atomic dec(void); Is-
sues a memory barrier and disables code-motion
compiler optimizations only if the platform’s
atomic_dec() primitive does not already do so.
• struct rcu head A data structure used by the
RCU infrastructure to track objects awaiting a
grace period. This is normally included as a field
within an RCU-protected data structure.
4 Counter Optimizations
In some cases where increments and decrements are
common, but checks for zero are rare, it makes sense
to maintain per-CPU or per-task counter. See the
paper on sleepable read-copy update (SRCU) for an
example of this technique [7]. This approach elim-
inates the need for atomic instructions or memory
barriers on the increment and decrement primitives,
but still requires that code-motion compiler optimiza-
tions be disabled. In addition, the primitives such
as synchronize_srcu() that check for the aggre-
gate reference count reaching zero can be quite slow.
This underscores the fact that these techniques are
designed for situations where the references are fre-
quently acquired and released, but where it is rarely
necessary to check for a zero reference count.
6
5 Background on RCU
Read-copy update (RCU) is a synchronization API
that is sometimes used in place of reader-writer locks.
RCU’s read-side primitives o er extremely low over-
head and deterministic execution time, in fact, non-
realtime server-class implementations of RCU imple-
ment the rcu_read_lock() and rcu_read_unlock()
primitives as empty C-preprocessor macros, so that
neither the compiler nor the CPU see any RCU read-
side overhead whatsoever.2 These properties imply
that RCU updaters cannot block RCU readers, which
means that RCU updaters can be expensive, as they
must leave old versions of the data structure in place
to accommodate pre-existing readers. Furthermore,
these old versions must be reclaimed after all pre-
existing readers complete. The Linux kernel o ers a
number of RCU implementations, the first such im-
plementation being called “Classic RCU”.
A full description of RCU is beyond the scope
of this document, however, McKenney’s disserta-
tion [3] contains an extensive RCU bibliography as
well as detailed descriptions of early Linux imple-
mentation and corresponding APIs, along with early
Linux RCU usage and corresponding performance
results. The Wikipedia RCU page [8] provides a
short overview of RCU’s operation, also present-
ing “toy” implementations of RCU infrastructure.
Numerous publications compare RCU performance
to a number of alternative synchronization mecha-
nisms within the Linux kernel [1, 4, 9], and Hart
et al. [2] compare various locking and non-blocking-
synchronization schemes to an RCU-infrastructure
implementation similar to Linux’s “Classic RCU”.
Of course, the ultimate description of RCU in Linux
is the source code [10], which makes significant use
of the RCU API [5]. McKenney maintains a list of
cscope databases listing RCU API usage on a per-
Linux-version basis [6].
2The DEC Alpha CPU being the one exception proving this
rule.
6 Operations Required for Reference
Counting
Properties of atomic variables and operations on
those variables may be categorized as follows:
1. Atomic response to normal loads and stores.
2. Atomic operations.
3. Memory barriers.
4. Disabling of compiler optimizations that move
memory references.
Table 2 shows which of the reference-counting
methods described in this paper require which of the
above properties. This table shows that while mem-
ory barriers can imply disabling of compiler code-
motion optimizations without penalty, tying atomic
operations to memory barriers may penalize the sim-
ple atomic-counting reference-counting scheme de-
scribed in Section 2.2.
Even more severe penalties are imposed on
SRCU [7] if optimization disabling is not provided
independently, for example, as provided by the gcc
compiler’s “memory” attribute on __asm__ direc-
tives. In some cases, the C-language “volatile” key-
word can be used, however, the semantics of this key-
word are ill-defined. In particular, for some architec-
tures, some compilers will emit expensive memory-
barrier instructions that are not needed for SRCU.
Finally, SRCU requires that normal loads and
stores to its per-CPU counter variables be atomic, in
other words, loads must see either the initial value or
the complete result of one preceding store. This abil-
ity is provided natively for properly aligned C/C++
integers and pointers on all mainstream CPUs, and
should be exposed in any C/C++ specification that
touches on multithreaded behavior.
In summary, there is ample precedent for specify-
ing that a given variable should have atomic response
to normal loads and stores, and for the ability to
separately specify atomic operations, memory barri-
ers, and disabling of compiler optimizations in uses
of variables.
7
Implementation Type
Property - A AM CAM SRCU
Atomic Response to Y
Normal Loads/Stores
Atomic Operations Y Y Y
Memory Barriers Y Y
Disable Compiler Y Y Y
Optimizations
Table 2: Reference Counting and Required Opera-
tions
7 Answers to Quick Quizzes
Quick Quiz 1: Why isn’t it necessary to guard
against cases where one CPU acquires a reference
just after another CPU releases the last reference?
Answer: Because a CPU must already hold a ref-
erence in order to legally acquire another reference.
Therefore, if one CPU releases the last reference,
there cannot possibly be any CPU that is permitted
to acquire a new reference. This same fact allows
the non-atomic check in line 22 of Figure 2.
Quick Quiz 2: If the check on line 22 of Fig-
ure 2 fails, how could the check on line 23 possibly
succeed?
Answer: Suppose that kref put() is protected
by RCU, so that two CPUs might be executing
line 22 concurrently. Both might see the value “2”,
causing both to then execute line 23. One of the two
instances of atomic dec and test() will decrement
the value to zero and thus return 1.
Quick Quiz 3: How can it possibly be safe to
non-atomically check for equality with “1” on line 22
of Figure 2?
Answer: Remember that it is not legal to call
either kref get() or kref put() unless you
hold a reference. If the reference count is equal
to “1”, then there can’t possibly be another CPU
authorized to change the value of the reference count.
Quick Quiz 4: Why can’t the check for a
zero reference count be made in a simple “if”
statement with an atomic increment in its “then”
clause?
Answer: Suppose that the “if” condition com-
pleted, finding the reference counter value equal
to one. Suppose that a release operation executes,
decrementing the reference counter to zero and
therefore starting cleanup operations. But now the
“then” clause can increment the counter back to a
value of one, allowing the object to be used after it
has been cleaned up.
Acknowledgements
I owe thanks to Michael Wong for his careful review
of this paper, and am indebted to Daniel Frye for his
support of this e ort.
References
[1] Arcangeli, A., Cao, M., McKenney, P. E.,
and Sarma, D. Using read-copy update tech-
niques for System V IPC in the Linux 2.5 ker-
nel. In Proceedings of the 2003 USENIX Annual
Technical Conference (FREENIX Track) (June
2003), USENIX Association, pp. 297–310.
[2] Hart, T. E., McKenney, P. E., and
Brown, A. D. Making lockless synchroniza-
tion fast: Performance implications of memory
reclamation. In 20th IEEE International Parallel
and Distributed Processing Symposium (Rhodes,
Greece, April 2006).
[3] McKenney, P. E. Exploiting Deferred
Destruction: An Analysis of Read-Copy-
Update Techniques in Operating System
Kernels. PhD thesis, OGI School of Sci-
ence and Engineering at Oregon Health
and Sciences University, 2004. Available:
http://www.rdrop.com/users/paulmck/RCU/
RCUdissertation.2004.07.14e1.pdf [Viewed
October 15, 2004].
[4] McKenney, P. E. RCU vs. lock-
ing performance on di erent CPUs. In
linux.conf.au (Adelaide, Australia, January
2004). Available: http://www.linux.
8
org.au/conf/2004/abstracts.html#90
http://www.rdrop.com/users/paulmck/
RCU/lockperf.2004.01.17a.pdf [Viewed June
23, 2004].
[5] McKenney, P. E. RCU Linux usage. Avail-
able: http://www.rdrop.com/users/paulmck/
RCU/linuxusage.html [Viewed January 14,
2007], October 2006.
[6] McKenney, P. E. Read-copy update
(RCU) usage in Linux kernel. Available:
http://www.rdrop.com/users/paulmck/
RCU/linuxusage/rculocktab.html [Viewed
January 14, 2007], October 2006.
[7] McKenney, P. E. Sleepable RCU. Available:
http://lwn.net/Articles/202847/ Revised:
http://www.rdrop.com/users/paulmck/RCU/
srcu.2007.01.14a.pdf [Viewed August 21,
2006], October 2006.
[8] McKenney, P. E., Purcell, C., Algae,
Schumin, B., Cornelius, G., Qwertyus,
Conway, N., Sbw, Blainster, Rufus, C.,
Zoicon5, Anome, and Eisen, H. Read-copy
update. Available: http://en.wikipedia.org/
wiki/Read-copy-update [Viewed August 21,
2006], July 2006.
[9] Morris, J. Recent developments in
SELinux kernel performance. Available:
http://www.livejournal.com/users/james_
morris/2153.html [Viewed December 10,
2004], December 2004.
[10] Torvalds, L. Linux 2.6. Available: ftp://
kernel.org/pub/linux/kernel/v2.6 [Viewed
June 23, 2004], August 2003.
9

Linux Bangalore/2003

December 2nd, 3rd and 4th, 2003
National Science Seminar Complex
(J.N.Tata Auditorium)
Indian Institute of Science
Bangalore
http://linux-bangalore.org/2003
1/6
About Linux Bangalore
Linux Bangalore is India's premier annual Open Source event, and is the only one that is
driven by the Open Source community itself.
Held annually at Bangalore, India, in the month of December, Linux Bangalore offers
event participants a means of acquainting themselves with both the concepts of Open
Source, as well as the very latest in Open Source technologies and applications.
This year, the event will be held on December 2nd, 3rd and 4th, at the prestigious National
Science Seminar Complex (J.N.Tata Auditorium), Indian Institute of Science, Bangalore.
The event caters to both developers as well as users of Open Source products and
technologies, from entry to advanced levels, and features speakers from academia,
research as well as industry, and addresses audiences ranging from students,
professionals, corporates and government officials.
LB/2003 will feature talks, discussions and demonstrations by national and international
speakers that cover a diverse spectrum of Linux and OpenSource related technologies
ranging from Kernel-programming and Embedded systems to Desktop Environments,
Localisation Databases and Web Applications to Gaming and Multimedia, to community
and User Group Development. ( Please visit our website for a detailed talk-list ).
This year, Linux Bangalore/2003 also features the Open Source Expo, which, for the first
time, offers developers and vendors of Open Source technologies a platform to showcase
their technologies, products and services. The expo also helps the delegates to have a first
hand view into the latest in OpenSource technologies.
Linux Bangalore/2003 is sponsored by Hewlett Packard (HP) [Platinum Sponsor],
Novell [Gold Sponsor] and Exocore Consulting [Silver Sponsor]
LB/2003 has been endorsed by MAIT and the IPv6 Forum India.
2/6
What will happen there
Programs
Linux Bangalore/2003 will take place from December 2 to December 4, 2003, at the
J.N.Tata Auditorium at IISc in Bangalore, India.
The three days will offer around 90+ technical sessions and invited talks, divided in five
parallel tracks.
The talks will focus on Linux Kernel and systems software, as well as more generic Open
Source Software, the underlying software technologies, and the free software and Open
Source philosophy. Presentations should take about 45 minutes each (including
discussions, when applicable).
Linux Bangalore/2003 conference will feature talks about current and future Linux
technologies including software development and more generally about Open Source
projects.
The main areas of focus are: ( http://linux-bangalore.org/2003 for latest updates )
• Embedded and Real-Time Systems and Devices
• System Development
• Web Development & Application Development
• Localisation and Internationalisation
• Desktop Computing and Applications
• Open Source in Multimedia
• Database Applications: RDBMS, ODBMS, ERP systems
• Network and System Security
• Grid and Cluster Computing
• E-governance Solutions & Open Source in Education
• Banking and Financial Applications
• Business impact and solutions
• Open Source in Defence and Space Applications
• Internet Service Provider Services
• Legal Issues: Privacy, Licensing and Copyrights
Topics of specific interests can be discussed during informal gatherings called Birds-ofa-
Feather (BoF) sessions. BoFs may be scheduled at the conference or in advance by
mailing the program committee.
3/6
The Technology Showcase
The technology showcase will consist of an exposition of Linux technologies and
products from the local industry. Various product lines and services that use/run on Linux
and OSS will be displayed.
Cultural Events
Linux Bangalore/2003 is all about having fun and understanding technology is fun
enough. Along with technology, the Linux Bangalore/2003 team has arranged for
entertainment on three days of the conference. All three days of the event will end with a
cultural program.
The programs arranged are mentioned below:
• Day 1 (Dec 2nd) : A private screening of the movie “Revolution OS”
• Day 2 (Dec 3rd) : Fusion music by the group “Laya-Tarang” *
• Day 3 (Dec 4th) : Performance by the rock band “Phenom”
All delegates to Linux Bangalore/2003 are invited to attend the cultural programs.
Note : There will NOT be any extra cost for attending the cultural events.
Speaker Profiles at LB/2003
The profiles of some of the speakers at LB/2003 is given below.
• Harald Welte - One of the five netfilter/iptables core team members, and the current
Linux 2.4.x firewalling maintainer. Also contributed to 'User Mode Linux' and the
international (crypto) kernel patch.
• Bdale Garbe - Bdale is a former Debian Project Leader, and as HP Linux CTO helps
to ensure Linux will work well on future HP systems. His background includes many
years of both UNIX internals and embedded systems work. He helped jump-start ports
of Debian GNU/Linux to 5 architectures other than i386.
• Jeremy Zawodny – A Technical Yahoo! at Yahoo Inc. A MySQL expert and
advocate and also the author and maintainer of the DBIx:DWIW Perl module.
• Miguel De Icaza - Co-Founder of Ximian. Also a lead developer on various GNOME
related projects such as Evolution, Mono and Gnumeric.
• Nat Friedman - Co-Founder and Vice-President of Product Development at Ximian
(which was recently acquired by Novell Inc ).
• Rasmus Lerdorf - Inventor of PHP and is also the author of the “PHP Pocket
Reference”.
4/6
• Atul Chitnis - A partner in Exocore Consulting, operating as a senior technology
consultant specialising in Corporate computing strategies, internetworking and data
communication. Atul is passionate about open source and is a key contributor to its
propagation in India.
• Gurunandan R. Bhat - Former Head, Department of Computer Science and
Technology, Goa University, Dr Bhat undertakes Linux training for educational
institutions. Also authored books and writes for technology magazines.
• Kishore Bhargava - A Linux advocate with lots of experience in implementation,
consulting and public seminars. Also a writer with some of the Tech publications.
• Naba Kumar - The founder, maintainer and lead developer of “Anjuta” - the versatile
Integrated Development Environment for C,C++ on GNU/Linux.
• Sirtaj Singh Kang - A KDE developer and the representative for KDE in Australia.
Sirtaj is a professional programmer and has a keen interest in the management and
operation of free software projects.
• Tarique Sani - Dr Tarique Sani is the CTO of SANIsoft. He has co-authored
"Professional PHP4" (WROX PRESS) and has been associated with several Open
Source PHP related projects.
• Gopi Garge - Gopi is a Senior Consultant at Exocore Consulting (P) Limited and a
Network Services Consultant to the ERNET, IISc. Core areas of expertise include
Enterprise Internetworking, Messaging Systems, Linux based enterprise solutions and
Systems Integration and Performance Tuning.
• Sudhakar Chandrasekhar (thaths) – slacker-at-large, geek volunteer, recently
returned from a year teaching in Kenya.
Please visit : http://linux-bangalore.org/2003 for the detailed list of talks
Note : The final schedule for the talks will be put up, one week before the conference.
5/6
How to Register for LB/2003
You can register as a delegate for Linux Bangalore/2003, by visiting :
http://linux-bangalore.org/2003/
The exact URL for registration is :
http://linux-bangalore.org/2003/register/delegates/
Registration Charges
1. A gate fee of Rs. 300/- per head will be charged for people who pre-register online
and bring their correct registration code (i.e. the printout of the registration
card that you get to see when you register on-line).
2. A gate fee of Rs. 500/- per head will be charged for people who have not preregistered
on-line or who do not have a valid registration code with them.
Group Registrations
You can do group registrations for delegates from your organization. The steps involved
are -
• Delegates have to register online at http://linux-bangalore.org/2003 and obtain their
“Delegate Code”.
• Mail their delegate-codes along with the participant names to jessie@exocore.com.
• You can make a single cheque/DD favouring the “Bangalore Linux Users Group”
and send it to
Jessica Prabhakar
Email : jessie@exocore.com
Ph: +91-80-3440397/ +91-9845089200
Fax: +91-80-3341137
Have Fun at Linux Bangalore/2003 !!
The Linux Bangalore/2003 team.
http://linux-bangalore.org/2003
6/6

Linux to Solaris Administrators Guide



The aim of the Linux to Solaris Administrator Guide is to give Linux adminis-
trators the information and guidance they'll need to make a successful transition
to using Solaris 10.
The Linux to Solaris Administrators Guide is not intended for a rst time
system administrator. The guide assumes a certain amount of background ad-
ministering a Linux system.
The major topics in this guide include:
Chapter Description
Overview Overview of Solaris and Linux di erences.
Solaris Features
not Available in Linux
An overview of some of the new features in So-
laris 10 that either don't exist, or are still in the
development phase, on Linux.
Command Di erences Information on command di erences between
Linux and Solaris.
Installation Information on installation and its comparison to
Linux.
Software Management Information on software management di erences
in Solaris as compared to Linux.
System Management Information on system management di erences in
Solaris as compared to Linux.
Device Management Information on device management di erences in
Solaris as compared to Linux.
Security and Hardening Information on security and system hardening dif-
ferences in Solaris as compared to Linux.
Monitoring Performance Information on system monitoring and perfor-
mance in Solaris as compared to Linux.
Backup and Restore An overview and comparison of backup and re-
store procedures between Solaris and Linux.
Troubleshooting Information on troubleshooting common Solaris
issues and errors.
After reviewing the material in this book you should have enough exposure
to be able to install and maintain a Solaris machine.
ix
Chapter 1
Overview of Linux and
Solaris Di erences
While similar in many respects there are still quite a few di erences between
a Linux and Solaris machine including commands, le systems and heritage.
These di erences can be as simple as a renamed con guration le to the more
complicated alternate meanings for command line arguments.
This chapter presents an overview of some of the di erences between Linux
and Solaris.
Topics Covered
Architectural Similarities and Di erences
File System Organization
Locations of Common used Commands
Location of Con guration Files
Location of Log Files
Script Migration
1
Linux to Solaris Administrators Guide
Architectural Similarities and Di erences
While similar in many respects there are fundamental di erences between the
Solaris and Linux operating environments.
Throughout the development of Solaris the focus has been on compatibility.
Compatibility with previous releases (binaries compiled on Solaris 8 will run on
Solaris 10) and compatibility with de jure standards such as POSIX. Linux has
had the freedom to establish new de facto standards (such as extended command
line syntax, with a strong consistency among commands). However, judicious
use of the included GNU utilities, the proper command line settings, downloads
of additional utilities, and some acquired knowledge such as this guide and sites
such as the Rosetta Stone1 will mitigate most di erences.
Many of the system similarities can be attributed to the implementation
of di erent system standards. These standards make it a lot easier to move
applications between Operating Systems. Solaris conforms to the POSIX, SVID
and XPG standards.
Although many commands may have the same name, the implementation
and command line options may have changed. The man pages should be con-
sulted to verify the functionality of commands.
The rst di erence you'll probably notice is the default shell. The default
Linux shell is Bash. Linux distributions typically symlink /bin/sh to /bin/bash.
In Solaris, on the other hand, /bin/sh remains the Bourne shell; this is done
to preserve absolute compatibility with existing shell scripts. Bash is upwards
compatible from the Bourne shell, but includes many additional extensions;
Bash is available on Solaris as /bin/bash. You may want to make a root account
with /bin/bash as its shell.
Depending on the kernel con guration a Linux kernel will be either dynam-
ically linked or monolithic. The Solaris kernel is always dynamically linked.
The standard Solaris le system format is UFS; the extra-cost le systems
VxFS and QFS are often used as well. Beginning with Solaris 10 6/06 Solaris
ZFS is also available. Linux will typically use one of ext3, reiser, JFS or XFS.
File System Organization
There are many similarities between Linux and Solaris le system hierarchies.
That being said, there are slight variations in the usage of some directories.
Table 1.1 lists the common le system directories.
Of these directories only one directory has di erences worth noting, /proc.
On Linux, /proc contains information on the current system con guration and
1http://bhami.com/rosetta.html
c
2006-2007 Treklogic Advanced Solutions Page 2
Linux to Solaris Administrators Guide
Table 1.1: Common le system directories
/ /sbin /bin
/lib /usr /etc
/var /opt /proc
process along with les you can alter to update kernel variables and process
information. On Solaris the /proc directory only contains process information.
You won't use /proc to update kernel tunables or retrieve system information.
Solaris adds the /platform directory which contains platform speci c infor-
mation and applications. There is no equivalent to /platform on Linux.
For a full description of the le system organization on Solaris please refer
to the lesystem(5) manpage.
Locations of Common Commands
One of the more frustrating aspects of changing operating environments is de-
termining the location of commonly used commands. There is a common set of
command directories between Linux and Solaris which are listed in Table 1.2.
Table 1.2: Common command directories
/bin /usr/bin
/sbin /usr/sbin
In order to maintain compatibility with System V, BSD and GNU software
Solaris also includes several extra command directories. These extra directories
can be seen in Table 1.3.
Table 1.3: Extra Solaris command directories
/usr/openwin/bin /usr/dt/bin /usr/sfw/bin
/opt/sfw/bin /usr/xpg4/bin /usr/ccs/bin
/usr/ucb
/usr/bin contains the standard System V implementation of certain applica-
tions. /usr/ucb contains implementations that are compatible with legacy BSD
versions. Some commands exist in both /usr/bin and /usr/ucb with di ering
c
2006-2007 Treklogic Advanced Solutions Page 3
Linux to Solaris Administrators Guide
implementations. You'll need to determine which version meets your require-
ments when doing script migrations and setup your PATH as required. Table
1.4 lists some /usr/ucb commands which may di er from the implementation
of the same command in /usr/bin.
Table 1.4: Solaris commands in /usr/ucb
basename df du echo expr fastboot
fasthalt le from groups install ld
lint ln lpc lpq lpr lprm
lptest ls mkstr printenv ps rusage
sed shutdown stty sum test touch
tr tset users vipw whereis whoami
Along with the System V and BSD versions there are two directories that
contain free software. These are the /usr/sfw/bin and /opt/sfw/bin directo-
ries. /usr/sfw/bin will contain any freeware installed o the Install media while
/opt/sfw/bin contains software installed o of the Companion CD.
The free software versions are the same implementations as found on a Linux
machine. These GNU commands on Solaris are typically pre xed with a g. (e.g.
tar vs gtar).
As Solaris matures, some software that used to be shipped with the Com-
panion CD slowly makes its way into the Solaris install media. You may notice
that on a given release of Solaris a command in /opt/sfw/bin may migrate to
/usr/sfw/bin.
Note that software delivered in /usr/sfw is fully supported by Sun through
Sun's standard support channels. Software delivered in /opt/sfw is community
supported. These are simply packaged by Sun for convenience. If support issues
arise regarding software in /opt/sfw, the usual open source support channels
must be used.
Location of Con guration Files
Networking
Table 1.5 lists the Linux and equivalent Solaris networking con guration les.
File System
Table 1.6 lists the Linux and equivalent Solaris le system con guration les.
c
2006-2007 Treklogic Advanced Solutions Page 4
Linux to Solaris Administrators Guide
Table 1.5: Linux and Solaris networking con guration les
Linux Solaris
/etc/ntp.conf /etc/inet/ntp.conf
/etc/inetd.conf /etc/inet/inetd.conf
/etc/syscon g/network-scripts/ifcfg-finterfaceg /etc/inet/netmasks
/etc/networks /etc/inet/networks
Table 1.6: Linux and Solaris le system con guration les
Linux Solaris
/etc/fstab /etc/vfstab
/etc/exports /etc/dfs/dfstab (format is di erent)
/etc/auto.master /etc/auto master
/etc/auto.home /etc/auto home
Mail
Table 1.7 lists the Linux and equivalent Solaris mail con guration les.
Table 1.7: Linux and Solaris mail con guration les
Linux Solaris
/etc/aliases /etc/mail/aliases
/etc/mail.rc /etc/mail/Mail.rc
/etc/mail/mailx.rc
Sendmail con guration on Linux is typically stored in the /etc/mail direc-
tory. On versions of Solaris up to Solaris 9 this con guration was stored in
/usr/lib/mail. With Solaris 10 the /usr/lib/mail directory is a symlink to the
/etc/mail directory.
Location of Log Files
There is one main log le directory used on a Linux system, /var/log. This is
where the log les for the various system daemons are stored.
Solaris uses a slightly di erent setup for its log directories. /var/log stores
the syslog and authlog les and /var/adm stores the messages log le, /var/log/messages.
This is the le that contains the logs for everything. (By default, this is con g-
urable in the syslog.conf le.)
c
2006-2007 Treklogic Advanced Solutions Page 5
Linux to Solaris Administrators Guide
Script Migration
There are a few pieces of information that need to be gathered when porting
shell scripts from Linux to Solaris.
First, make sure that any le system paths used by the scripts are valid on
Solaris 10. As mentioned in Section 1 some of the commands maybe in di erent
locations, or have di erent implementations. If there are GNU versions of the
commands available, via the Software Companion CD, alter the path to utilize
this version. (Check both /usr/sfw/bin and /opt/sfw/bin to see if the GNU
version exists).
Once you've got all the command paths veri ed, check that the command
line arguments are still correct on Solaris. As discussed in Chapter 3, Linux
commands that utilize the long option names ({option-name) may be candidates
for modi cation. The Solaris equivalents of those commands most likely don't
understand the long options, unless you're using the GNU versions.
If you are taking any command output and parsing it to extract speci c
information you may need to re-write the parsing routines to match the output
of the program on Solaris.
c
2006-2007 Treklogic Advanced Solutions Page 6
Chapter 2
Solaris Features not in
Linux
With the release of Solaris 10, and the subsequent updates, there are several
features available that provide a unique value proposition for the utilization
of Solaris 10: features ranging from virtualization, to application tracing and
service management. These tools make it easier to harness the full potential of
your hardware and to track down any latent performance issues.
This chapter will provide a brief overview of four key features now available
in Solaris 10: service management with the Solaris Service Manager (SMF),
Virtualization using Zones, dynamic tracing using DTrace, self healing and the
Solaris ZFS.
While all of these features are very powerful tools provided with Solaris
10, only SMF is required learning when transitioning to Solaris 10. All other
features, Zones, DTrace and ZFS included, can be set aside and incorporated
at your own pace.
Topics Covered
SMF
Zones
DTrace
ZFS
Predictive Self Healing
7
Linux to Solaris Administrators Guide
SMF
The Service Management Facility (SMF) is the new system to manage services
in Solaris 10. SMF takes over the role that was previously delegated to scripts
in the /etc/rc*.d directories, although those scripts will continue to run.
Your rst encounters with a Solaris 10 machine may leave you wondering
how to manage any running services. The /etc/rc*.d/ directories are relatively
empty compared to Linux. The reason for this is SMF. The majority of the
system services available under Solaris 10 are controlled by SMF. In order to
control these services you'll need to get familiar with a couple of SMF commands:
svcs(1) and svcadm(1M). These two commands will allow you to start, stop,
diagnose and control the services previously controlled through /etc/rc*.d.
Enabling and disabling of services is done with the svcadm command. As
can be seen in Figure 2.1 we use the enable and disable subcommands to modify
the service state.
Figure 2.1: Modifying service states
# svcadm enable network/http:apache2
# svcadm disable network/http:apache2
SMF service states are persistent. If you enable or disable a service and
reboot your machine the service will be restored to the state last speci ed.
There are several other subcommands to svcadm that will be bene cial to
know when working with a Solaris 10 machine. See svcadm(1M) for the full list
of subcommands.
Information on the services running, or available, on the system can be
obtained using the svcs command. Figure 2.2 shows some possible output from
svcs -a.
There are a few things to note in Figure 2.2.
First notice how the services are named. Each service has a unique FMRI
(fault management resource identi er) that identi es the service. Some of the
services have an instance name on the end (the :default of svc:/network/ssh:default).
There can be multiple instances of a single service executing on the system at
one time.
Second, notice the svc:/milestone/multi-user-server:default FMRI. SMF uses
a system of milestones instead of run levels to specify the system state. We can
see that I currently have milestone/multi-user-server enabled. More informa-
tion on Solaris 10 milestones can be found in the System Management chapter.
The nal thing to note is the STATE column. This column is telling us the
current state of each service. The legacy run state is for services that are still
c
2006-2007 Treklogic Advanced Solutions Page 8
Linux to Solaris Administrators Guide
Figure 2.2: System services
# svcs -a
STATE STIME FMRI
legacy_run 15:33:43 lrc:/etc/rc3_d/S84appserv
legacy_run 15:33:44 lrc:/etc/rc3_d/S90samba
...
disabled 15:33:33 svc:/network/shell:kshell
disabled 15:33:33 svc:/network/talk:default
...
online 15:33:44 svc:/milestone/multi-user-server:default
online 15:33:47 svc:/system/zones:default
...
offline 15:33:17 svc:/network/ssh:default
offline 15:33:18 svc:/application/print/ipp-listener:default
executing from the old /etc/rc*.d scripts. The disabled state speci es all of the
services that have been disabled on the system. The online state lists all of the
services that are currently enabled on the system. Lastly, oine lists all of the
services that were unable to start, or had a service fault, and have been taken
oine by SMF.
Typically any oine services will need to be investigated to determine the
reason for their o -lining. The svcs -x command can be used to gather informa-
tion on the o -lined processes. Figure 2.3 shows that the svc:/network/physical:default
service is disabled. Adding the -v
ag we can see that this is causing the
svc:/network/ssh:default service to be o -lined.
The svcs -x output also gives pointers on where you can go for information
on the current issue. These can be pointers to websites, log les or man pages.
These are typically very handy resources in diagnosing and correcting the issue
at hand.
Along with svcs and svcadm there are several other commands that are used
to interact with SMF. These commands are listed in Table 2.1.
Table 2.1: SMF Commands
Command Description
svccfg Con gure services.
inetadm Administer inetd services.
inetconv Convert inetd services to SMF.
The inetd services have been converted to run under SMF. Inetd still func-
tions as it did previously, launching the required service as a request comes in,
c
2006-2007 Treklogic Advanced Solutions Page 9
Linux to Solaris Administrators Guide
Figure 2.3: SMF state explanations
# svcs -x
svc:/network/physical:default (physical network interfaces)
State: disabled since Thu Sep 28 15:33:17 2006
Reason: Disabled by an administrator.
See: http://sun.com/msg/SMF-8000-05
See: ifconfig(1M)
Impact: 5 dependent services are not running. (Use -v for list.)
# svcs -xv
svc:/network/physical:default (physical network interfaces)
State: disabled since Thu Sep 28 15:33:17 2006
Reason: Disabled by an administrator.
See: http://sun.com/msg/SMF-8000-05
See: man -M /usr/share/man -s 1M ifconfig
Impact: 5 dependent services are not running:
svc:/milestone/network:default
svc:/network/nfs/nlockmgr:default
svc:/network/nfs/client:default
svc:/network/nfs/status:default
svc:/network/ssh:default
c
2006-2007 Treklogic Advanced Solutions Page 10
Linux to Solaris Administrators Guide
it's just controlled through the uni ed SMF interface.
When a service is de ned in SMF you can also de ne any dependencies of
that service. For example, PostgreSQL depends on a local le system. With that
knowledge, SMF knows that if the user disables the le system that PostgreSQL
depends on it also needs to disable PostgreSQL.
This dependency information is also used by SMF to execute as much of
the boot processes in parallel as possible. SMF can take any services which
don't depend on each other and start them at the same time. This can result
in quicker boot times as compared to the linear processing of the /etc/rc*.d
scripts.
There are three main types of services provided by SMF.Transient, Wait and
Contract services. Transient services are often con guration services requiring
no long-running process. Wait services run for the lifetime of the child process
and are restarted when the process exits. Contract services are the standard
system daemons and require processes which run forever once started. The
death of all processes in a contract service is considered a service error which
will cause the service to restart.
More information on SMF can be found in the Solaris Service Management
Facility - Quickstart Guide 1 and the applicable sections of the Solaris Admin-
istration Guide: Basic Administration2.
Zones
Virtualization is quickly becoming a hot topic in system administration. The
ability to run multiple instances of an operating system on a single machine
allows us to increase the overall usefulness of that machine. We're able to take
some of the idle CPU time, free memory and unused disk and run two, three or
four parts of our network architecture.
Sun has taken this technology in hand with Solaris 10 and presents the
concept of Zones. (You may also see references to Solaris Containers, which are
Zones coupled with Resource Management.)
If you've heard of chroot jails, originating from FreeBSD, you'll understand
the basic concept of Zones. When utilizing Zones there is one instance of the
Solaris kernel. Even though there is only one kernel, all of the zones, except in
one special case, are segregated and isolated from each other. (The special case
being the global zone which can see everything.)
Each zone on the system can have its own IP address, resource controls, root
and user accounts, running services and installed software. The only way for
two zones to communicate is using the TCP/IP networking capabilities.
1http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html
2http://docs.sun.com/app/docs/doc/817-1985
c
2006-2007 Treklogic Advanced Solutions Page 11
Linux to Solaris Administrators Guide
There has been a lot of work to make the creation and interaction with zones
as simple as possible. There are two main commands to remember, zonecfg and
zoneadm. With these two tools you'll be able to create, install, boot, halt,
uninstall and delete your zones.
zonecfg and zoneadm provide a simple, yet powerful, interface to work with
Zones. We can get a list of the current Zones using the list subcommand to
zoneadm. An example of this can be seen in Figure 2.4. There are a couple of
things to note. First, there is always a global zone. The global zone is the main
machine and can see everything that happens in all other zones. You'll also
notice there is no ID assigned to the test zone. The Zone IDs are only assigned
after a Zone has been booted. These IDs can change depending on the order of
zone startup. All of the zone work we do will use the zone name which must be
unique.
Figure 2.4: Listing zones
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- test configured /zones/test
There are two types of zones, whole and sparse root Zones: the di erence
between the two being the amount of data that is copied into the zone le
system. With a whole root zone all of the needed data is copied from the global
zone. With a sparse root zone the /usr, /sbin, /platform and /lib directories are
read-only loopback links to the global zone. Using a sparse root zone provides a
lot of disk savings over a whole root zone but with the drawback that you can't
install anything into the loopbacked le systems from within the local Zone.
The rst step in creating a zone is to create its con guration. This is done
with the zonecfg command. By supplying a non-existent zone name to zonecfg
we are prompted to create the new zone. The only required step when setting
up a zone is to set the zonepath attribute. A network interface is also setup in
Figure 2.5 using the net command.
Once the zone is created zoneadm list shows the zone to be in the con gured
state. The next step, as seen in Figure 2.6, is to install the zone.
Once the zone is installed you use zoneadm boot to boot the zone. There
is an autoboot parameter that can be set in the zone con guration to have the
zone autoboot on system startup. The initial boot may take a bit of time as
the SMF repository is con gured. After the initial boot you'll need to log into
the console using zlogin -C test zone and complete the nal con guration.
More information on zones can be found in the Solaris Administrators Guide:
Solaris Containers, Resource Management and Solaris Zones3 and the man
3http://docs.sun.com/doc/817-1592
c
2006-2007 Treklogic Advanced Solutions Page 12
Linux to Solaris Administrators Guide
Figure 2.5: Zone creation
# zonecfg -z test_zone
test_zone: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:test_zone> create
zonecfg:test_zone> set zonepath=/zones/test_zone
zonecfg:test_zone> add net
zonecfg:test_zone:net> set physical=bge0
zonecfg:test_zone:net> set address=192.168.1.44
zonecfg:test_zone:net> end
zonecfg:test_zone> info
zonepath: /zones
autoboot: false
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 192.168.1.44
physical: bge0
zonecfg:test_zone> verify
zonecfg:test_zone> commit
zonecfg:test_zone> exit
# zoneadm list -cv
ID NAME STATUS PATH
0 global running /
- test_zone configured /zones/test_zone
c
2006-2007 Treklogic Advanced Solutions Page 13
Linux to Solaris Administrators Guide
Figure 2.6: Zone installation
# zoneadm -z test_zone install
Preparing to install zone .
Creating list of files to copy from the global zone.
Copying <2379> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1157> packages on the zone.
Initialized <1157> packages on zone.
Zone is initialized.
The file
contains a log of the zone installation.
pages for zoneadm, zonecfg and zlogin.
DTrace
DTrace is the dynamic tracing tool built into Solaris 10. DTrace provides a tool
for both developers and system administrators to analyze their running system
and the applications executing on it. Because of its design, minimal impact
and safety as a requirement, DTrace can be safely used on a production system.
There is no need to reboot the system, restart the application or add any kind
of instrumentation.
The impact of enabling DTrace is typically minimal, unless you enable large
numbers of probes, and even then DTrace is designed to automatically halt
any of its scripts that cause excessive performance degradation. DTrace is also
designed with a dead-man in place. DTrace will kill itself if it sees performance
issues arising due to its usage.
DTrace is designed around the concept of providers and probes. A provider
is a high level grouping of probes. There is a default set of providers delivered
with Solaris 10 including networking, function boundary tracing, application
tracking and IO providers. There are also providers available for Java, Ruby,
PHP and other languages. It's also possible, although not required, to write
a provider for your application. Probes are the speci c access points in the
application, library or kernel that you can watch and gather data.
When writing a DTrace script you'll be using the dtrace application. As
a simple starting point, Figure 2.7 is an example of using dtrace to get a list
of all available probes and a count of the number of probes on the system. A
typical machine can have upwards of 44000 probes available without looking at
application probes. Since none of these probes are enabled they don't utilize any
c
2006-2007 Treklogic Advanced Solutions Page 14
Linux to Solaris Administrators Guide
CPU resources. As probes are enabled they are dynamically inserted into the
executing code allowing DTrace to have zero performance impact when disabled.
Figure 2.7: Listing DTrace probes
# dtrace -l
ID PROVIDER MODULE FUNCTION NAME
1 dtrace BEGIN
2 dtrace END
3 dtrace ERROR
4 syscall nosys entry
5 syscall nosys return
6 syscall rexit entry
7 syscall rexit return
8 syscall forkall entry
9 syscall forkall return
10 syscall read entry
11 syscall read return
12 syscall write entry
13 syscall write return
...
# dtrace -l | wc -l
44102
A DTrace script is made up of probes, predicates and actions. A probe is
the part of the system you wish to observe, (e.g. syscall::read:entry). Probes
are made up of four parts: provider:module:function:name. Predicates act like
"if" conditions. Actions are what we wish to do if the probe is red and the
predicate evaluates to true.
Figure 2.8 gives an example of counting the number of syscalls the executing
application is making. While this may seem a bit confusing at rst glance it
isn't too complicated. We use the -n
ag to dtrace to signal that we are going to
specify a probe name to trace. The probe we're interested in is syscall:::entry.
syscall:::entry will match all of the probes named "entry" in the syscall provider.
As you can see, if you leave part of the probe 4-tuple blank it will act as a wild-
card and match everything. You can also specify the "*" as a wild-card. (e.g.
open* will match open and open64). When the probe is red we store a count
into an associative array, @count, with the executable name, execname, as the
array key.
The count() function is part of what is called an aggregate. You can think
of aggregates like hash tables. There is a set of aggregate functions including
count(), quantize() and lquantize(). Aggregates make it easy to pull a lot of
data together without needing to store all data in memory.
c
2006-2007 Treklogic Advanced Solutions Page 15
Linux to Solaris Administrators Guide
Figure 2.8: Counting syscalls per application
# dtrace -n 'syscall:::entry {@counts[execname] = count()}'
dtrace: description 'syscall:::entry ' matched 233 probes
^C
utmpd 2
snmpdx 2
snmpd 2
tsasim_exec 3
webservd 3182
appservd 4041
dataserver 20187
More information on DTrace can be found in the Solaris 10 Dynamic Tracing
Guide4 and the man page for dtrace.
ZFS
As of Solaris 10 6/06, ZFS is available to the public. ZFS provides another
option when selecting a le system to use with your Solaris machine along side
other available le systems such as: UFS, VxFS and QFS.
ZFS has been designed from the ground up to be simple, secure, provide
end-to-end data integrity and amazing scalability. Among its many features,
because of the disk write semantics the on-disk data is always consistent, even
over power failure. No need to ever run fsck. The on-disk data is endian agnostic,
take the disk out of an x86 machine and install it in a SPARC machine and it
will just work. More information on the features of ZFS can be seen in ZFS |
the last word in le systems5.
When working with ZFS you'll run into the terms pools and le systems. A
pool is a collection of disks that determine the amount of storage space available.
You can dynamically add and remove disks from pools. The disks in a pool can
be con gured in a mirrored or raid-z array.
Lets look at a couple of simple examples of creating pools and le systems.
Figure 2.9 shows the simplest form of pool creation using a single disk.
Next, Figure 2.10 shows an example of creating a pool using a two disk
mirror.
4http://docs.sun.com/doc/817-6223
5http://www.sun.com/2004-0914/feature/
c
2006-2007 Treklogic Advanced Solutions Page 16
Linux to Solaris Administrators Guide
Figure 2.9: Creating a ZFS pool
# zpool create tank c1t0d0
Figure 2.10: Creating a mirrored pool
# zpool create tank mirror c1t0d0 c1t1d0
Once the pool is created we can start creating le systems. File systems
are created on top of storage pools. File systems provide a point to apply
con guration parameters for di erent pieces of the storage pool. What does
that mean? Well, you could have one le system with compression enabled,
and one with it disabled. One could be NFS shared, one not. These attributes
are also inherited as le systems are added. These properties can be things
like the mount point, is the le system NFS shared, do we use compression,
among others. Some properties are also inherited down the le system hierarchy.
Setting compression on tank/home means that compression will also be enabled
on tank/home/dan. Figure 2.11 shows the creation of a le system hierarchy
and setting some properties.
Figure 2.11: Creating ZFS le systems and setting attributes
# zfs create tank/home
# zfs set mountpoint=/export/home tank/home
# zfs set sharenfs=on tank/home
# zfs set compression=on tank/home
# zfs create tank/home/dan
Because of the le system inheritance tank/home/dan will automatically be
NFS shared and mounted to /export/home/dan.
ZFS has built-in support for generating snapshots. A snapshot is a read-only
copy of le system or volume. Creation of snapshots is almost instantaneous
and since they use a copy-on-write model they'll initially consume no space in
the storage pool. Figure 2.12 shows some of the snapshot commands.
Figure 2.12 is doing three things. First, we're creating a snapshot named
friday of the tank/home/dan directory. Second, we can access the snapshot
by changing into the .zfs/snapshot directory at the root of the le system.
In this case, as we set the mount point to be /export/home/ we are looking
at /export/home/dan/.zfs/snapshot. We can then access the friday directory
c
2006-2007 Treklogic Advanced Solutions Page 17
Linux to Solaris Administrators Guide
Figure 2.12: ZFS snapshots
# zfs snapshot tank/home/dan@friday
# ls /export/home/dan/.zfs/snapshot
friday
# zfs rollback tank/home/dan@friday
to retrieve les saved in the snapshot. Finally, we can rollback to a previous
snapshot using the zfs rollback command.
More information on the administration of ZFS can be found in the Solaris
ZFS Administration Guide6 along with the zfs(1m) and zpool(1m) man pages.
Predictive Self Healing
Tracking down the cause of, and solution too, any issues that arise on a server
can be a time consuming, and error prone, task. In order to simplify the task of
diagnosing and correcting these hardware and software faults Solaris 10 includes
a set of technologies referred too as Predictive Self Healing.
Predictive Self Healing is a new capability of Solaris 10 to isolate, diagnose
and recover from hardware and software faults. There are two main components
to Predictive Self Healing; the Solaris Fault Manager Software and the Solaris
Service Manager (SMF).
The Solaris Fault Manager Software is responsible for receiving all of the
error reports in the system and taking the appropriate action. This maybe
disabling a piece of errant software or an over-heating CPU.
The fault manager is made of a collection of diagnostic engines which are
responsible for this diagnosis.
More information on the Predictive Self Healing capabilities of Solaris 10
can be found in http://www.sun.com/software/solaris/availability.jsp.
6http://www.opensolaris.org/os/community/zfs/docs/zfsadmin.pdf
c
2006-2007 Treklogic Advanced Solutions Page 18
Chapter 3
Command Di erences
Most Linux commands take two types of options, short form (-v) and long form
({version). Solaris commands, unless they're the GNU version, typically don't
implement the log forms. If a script is migrated from Linux to Solaris and
makes use of the long option format it will, most likely, require modi cation to
use either the GNU versions or to convert the options to their short form.
The Rosetta Stone website1 is a good resource for nding the equivalent
Solaris and Linux commands.
With the non-GNU implementation of commands there can be slight varia-
tions in the meaning and usage of options when compared to the Linux equiva-
lent. Some of these command di erences are listed below.
awk
Linux ships with GNU awk. Solaris ships with several versions of awk as listed
in Table 3.1. The default version is referred to as System V awk. GNU awk has
several extensions which aren't available with System V awk.
basename
The basic functionality of basename is the same between Linux and Solaris.
There are two basename implementations on Solaris. Of these two, /usr/ucb/bin/basename
is the same as the Linux version. /usr/bin/basename is enhanced such that you
can match a sux using a pattern as de ned in expr(1).
1http://bhami.com/rosetta.html
19
Linux to Solaris Administrators Guide
Table 3.1: Solaris awk variations
/usr/bin/awk Standard System V awk
/usr/bin/nawk New awk. Has a number of features and extensions
over /usr/bin/awk
/usr/xpg4/bin/awk XPG4 compliant awk. XPG4 awk can be used
when porting awk scripts from Linux.
/opt/sfw/bin/gawk GNU awk. The awk distribution found on the
companion CD. gawk provides the highest degree
of compatibility with Linux awk. The Solaris 10
Companion CD ships with GNU awk version 3.0.6.
cat
The cat command, while similar, has a few variations between Linux and Solaris.
These di erences can be seen in Table 3.2.
Table 3.2: Linux vs Solaris cat arguments
Linux Solaris
-a, {show-all -vet
{number-nonblank -b
-e -ve
-E, {show-ends -ve
-s, {squeeze-blank -
-t -vt
-T, {show-tabs -vt
-u (ignored) -u (forces non bu ered output.)
{show-nonprinting -v
{help -
{version -
chown
Solaris ships with two versions of chown, /usr/bin/chown and /usr/ucb/chown.
The /usr/ucb/chown implementation only supports two options: -f and -R.
/usr/bin/chown, in addition to those supported by /usr/ucb/chown, supports
-h, -H, -L and -P. The implementations of the -f and -R
ags for both commands
are compatible with the Linux chown.
The -h option of /usr/bin/chown is compatible with the -h, or {no-dereference
option to chown on Linux. If a Linux script contains {no-dereference convert it
c
2006-2007 Treklogic Advanced Solutions Page 20
Linux to Solaris Administrators Guide
to -h when porting to Solaris.
The de nition of the additional
ags, -H, -L and -P can be seen in Table 3.3.
Table 3.3: Additional Solaris /usr/bin/chown arguments
-H If the le is a symbolic link referencing a directory,
the ownership of the directory and all les in the
le hierarchy below it are changed. If a symbolic
link is encountered, the owner of the target le is
changed, but no recursion takes place.
-L Same as -H but also a ects les. Any symbolic link
to a directory will be referenced and the directory
traversed.
-P If the le speci ed on the command line or en-
countered during the traversal of a le hierarchy
is a symbolic link this option changes the owner
of the symbolic link. This option does not follow
the symbolic link to any other part of the le hi-
erarchy. -P is similar to {no-dereference.
The implementation of chown on Linux also accepts several additional ar-
guments. These arguments can be seen in Table 3.4.
Table 3.4: Additional Linux chown arguments
-c or {changes Like verbose, but only reports when a change is
made.
{dereference A ects the referent of each symbolic link. This is
the default behaviour in Solaris. If a script uses
this option remove it when porting to Solaris.
{from= Only change the owner and/or group of each le if
its current owner and/or group match those speci-
ed. While there is no equivalent for this option in
Solaris, you can use nd with the -owner and/or
-group options and pass the results to chown.
df
Solaris supports several implementations of df. The simplest is /usr/ucb/df
which supports an additional -v option over /usr/ucb/df. The -v option is the
same as -k except that the sizes are displayed in multiples of the smallest block
size supported by each speci ed le system.
c
2006-2007 Treklogic Advanced Solutions Page 21
Linux to Solaris Administrators Guide
/usr/xpg4/bin/df supports an additional -P
ag which has the same meaning
as -k except the sizes are listed in 512-byte units.
du
There are several di erences between the Linux du command and the Solaris
variant. A summary of these di erences is given in Table 3.5. Several du options
available on Linux have no Solaris equivalents. These can be seen in Table 3.6.
Table 3.5: Linux and Solaris du comparison
Linux Solaris /usr/bin Solaris xpg4 Solaris /usr/ucb
-a, {all -a -a a
{block-size=SIZE - - -
-b, {bytes - - -
-c, {total - - -
-D, {dereference-args -L -L -L
-h, {human-readable -h -h -h
-H, {si - - -
-k, {kilobytes -k -k -k
-l, {count-links - - -
-L, {dereference -L -L -L
-m, {megabytes - - -
-S, {separate-dirs -o - -
-s, {summmarize -s -s -s
-x, {one- le-system -d -x -d
-X FILE, {exclude-from=FILE - - -
{exclude=PAT - - -
{max-depth=N - - -
{help - - -
{version - - -
The meaning of the -H option di ers between Linux and Solaris. On Linux,
-H and -si mean the same thing, use powers of 1000 not 1024. The Solaris
meaning for the -H
ag is similar to that of the -L
ag on Linux.
ps
The /usr/ucb/ps executable is BSD compatible and takes the same command
line arguments as the Linux version of ps. The output on Solaris may di er
from the output on Linux.
c
2006-2007 Treklogic Advanced Solutions Page 22
Linux to Solaris Administrators Guide
Table 3.6: Linux du options without Solaris equivalents
-b print size in bytes
{block-size=SIZE
-c produce a grand total
-l count links
-L dereference all symbolic links
-m megabytes
{exclude=PAT
{max-depth=N
{help
{version
setfacl
The /usr/bin/setfacl command is used for managing le Access Control Lists
(ACL). Although they perform the same function in Linux and Solaris, the
syntax and options are di erent.
The syntax for the Solaris implementation can be seen in Figure 3.1.
Figure 3.1: Solaris setfacl Syntax
setfacl [-r] -s acl_entries file
setfacl [-r] -md acl_entries file
setfacl [-r] -f acl_file file
The -s option sets a le's ACL. All old ACL entries are removed and replaced
with the newly speci ed ACL.
The -m option adds one or more new ACL entries to the le, and/or modi es
one or more existing ACL entries on the le. It can also be used to replace an
existing ACL entry.
The -d option deletes one or more ACL entries from the le.
The -r option recalculates the ACL mask entry.
The format for an ACL entry is similar to the format in Linux. Linux sup-
ports the Solaris ACL entry format, while some Linux formats are not supported
by Solaris. The ACL formats seen in Figure 3.2 are supported by Solaris.
Linux accepts an additional colon (:) after the "other" and "mask" keywords,
while Solaris does not.
The perms are composed of the symbols "rwx" or a number (the same per-
mission numbers used with the chmod command). For example "r-x" is used
c
2006-2007 Treklogic Advanced Solutions Page 23
Linux to Solaris Administrators Guide
Figure 3.2: Solaris ACL formats
[d[efault]:][u[ser]]:uid:perms
[d[efault]:][g[roup]]:gid:perms
[d[efault]:]o[ther]:perms
[d[efault]:]m[ask]:perms
to signify read and execute permissions. Linux support "rx" as an equivalent,
while Solaris treats this as an error.
Solaris setfacl supports the -f option which is absent in the Linux version
of setfacl. This option allows you to use another le's ACL as a reference for
setting a le's ACL.
The setfacl options listed in Table 3.7 are supported in Linux but have no
equivalent in Solaris.
Table 3.7: Linux setfacl options not available in Solaris
-b, {remove-all removes all ACL entries
-k, {remove-default removes the default ACL
-n, {no-mask Do not recalculate the e ective rights mask. This is equiv-
alent to the Solaris setfacl without the -r option. The ab-
sence of this option is equivalent to specifying the -r option
in Solaris.
{mask Recalculate the e ective rights mask. Equivalent to the -r
option in Solaris
-d, {default All operations apply to the Default ACL
{restore= le Restore permission backup created by "getfacl -R" or sim-
ilar
{test test mode
-R, {recursive Apply operations to all les and directories recursively
-L, {logical Logical walk, follow symbolic links
-P, {physical Physical walk, skip all symbolic links
{version Print the version of setfacl and exit
{help Print help explaining command line options
{ End of command line options
- If the le name parameter is a single dash, read a list of
les from standard input
c
2006-2007 Treklogic Advanced Solutions Page 24
Linux to Solaris Administrators Guide
getfacl
The /usr/bin/getfacl command is used to display the Access Control Lists(ACL)
of les. Although they perform the same function and have similar output
formats in Linux and Solaris, they di er in the options they accept.
None of the long form options are supported under Solaris. In addition to
that, the following short form options are also not supported: -R, -L, -P, and -.
These options do not have any equivalents in Solaris.
tar
The implementation of tar included in Linux is GNU tar. Solaris uses System
V tar. These two implementations have many di erences. It is best to consult
their respective man pages rather than providing a lengthy discussion of these
di erences in this guide.
Notably missing in Solaris are the compression options (-Z, -z, -j). Solaris
tar does not support the use of an external compression programs.
Solaris does include an implementation of GNU tar in /usr/sfw/bin/gtar.
GNU tar is installed via the SUNWgtar package.
When porting Linux scripts that use tar to Solaris, you can either re-write
the tar command to use the equivalent Solaris tar options and use pipes to the
compression and decompression programs. Alternatively, if the target Solaris
system has the SUNWgtar package installed, the script can be modi ed to use
gtar instead of tar.
useradd
The useradd command in Linux is very similar to the same command on Solaris.
For the most part they operate identically and take most of the same options
which mean the same things. The Solaris version takes additional options to
support RBAC (see Hardening Tools for more information). One signi cant
di erence is the meaning of the -p option. In Linux, this is used to specify
a password for the account on the command line; an unsafe practise that the
Linux version supports. In Solaris the -p option is used to specify the project
name to which all processes started by the user being created will belong.
Table 3.8 details the option di erences between Solaris and Linux.
For more information on the Solaris useradd, consult the useradd(1M) man-
page.
c
2006-2007 Treklogic Advanced Solutions Page 25
Linux to Solaris Administrators Guide
Table 3.8: Linux and Solaris useradd di erences
Linux Solaris Meaning
-e expire date -e expire date User account expiration date.
Format of expire date di ers
between Linux and Solaris.
-f inactive -f inactive On Linux this is the number of days
after password expiry until the the
account is permanently disabled. In
Solaris this is the maximum number
of days allowed between uses of a
login ID before considering it invalid.
-M The users home directory will not be
created.
-m Users home directory will be
created if it doesn't already exist.
-n Create a group having the same name
as the user. In Solaris, use a
separate call to groupadd
-o -o Allow the user to be created with
non-unique user id.
-p passwd Specify the encrypted password as
returned by crypt(3).
-p pro le Specify a project to which the user belongs.
-r Create a system account (a user with a
UID lower than the value of UID MIN
de ned in /etc/login.defs). This is
a RedHat speci c option.
-K key=value Set a key=value pair to add to the
users attributes.
-A authorization Authorizations to add to the user.
-P pro le[,pro les...] Pro les to add to the user.
-D -e default expire date -D -e default expire date Set the default expiry date for
accounts created. Format of
default expire date di ers
between Linux and Solaris.
c
2006-2007 Treklogic Advanced Solutions Page 26
Linux to Solaris Administrators Guide
groupadd
The groupadd command in Linux is very similar to the same command on So-
laris. For the most part they operate identically and take most of the same
options with the same meanings. Table 3.9 describes the di erences between
the implementations.
Table 3.9: Linux and Solaris groupadd di erences
Linux Solaris Meaning
-r Instructs groupadd to add a system account.
-f Force option. This is a RedHat speci c option.
For more information on the Solaris groupadd, consult the groupadd(1M)
manpage.
c
2006-2007 Treklogic Advanced Solutions Page 27
Linux to Solaris Administrators Guide
c
2006-2007 Treklogic Advanced Solutions Page 28
Chapter 4
Installation
This chapter will talk about three installation mechanisms, CD/DVD installa-
tion, network installation and
ash archives. We will also look at a mechanism
to upgrade an existing machine, live upgrade.
After reading this chapter you should be able to install Solaris onto an
existing machine.
Topics Covered
CD/DVD Media Installation
Network Installation
Flash Archives Live Upgrade
29
Linux to Solaris Administrators Guide
CD/DVD Media Installation
The most typical installation method for both Linux and Solaris is using the
provided, or downloaded1, installation media.
Installation of Linux typically involves the following steps:
 Boot from CD.
 Partition hard drives.
 Select desired software packages.
 Enter system con guration parameters.
A Solaris install will follow a similar pattern:
 Boot from CD/DVD.
 Enter system con guration parameters.
 Select desired software packages.
 Partition the hard drives.
There is nothing overly complex involved in a media based installation. Once
the required information is entered the system will be rebooted.
Network Installation
Unlike a media installation, the steps for a network installation di er between
Linux and Solaris. On Linux you would boot o a CD/DVD and then choose
the install media for your packages to be the URL of the host server. The install
program downloads the packages and installs them to the local system.
Solaris uses a technology called Jumpstart. You'll need a Jumpstart server
with a DHCP service running. The Jumpstart server will contain a copy of the
installation media (CD or DVD) on an NFS exported le system.
You'll need to know the MAC address of the host to be installed in order to
con gure the Jumpstart server. Our example will use 00:0c:29:d5:c1:90.
First, we con gure the Jumpstart server. This involves mounting the Solaris
install media and executing the setup install server finstall directoryg script.
The install directory parameter is the directory to copy the install image to on
1Solaris 10 is available at: http://www.sun.com/software/solaris/get.jsp
c
2006-2007 Treklogic Advanced Solutions Page 30
Linux to Solaris Administrators Guide
Figure 4.1: DHCP con guration
 Default settings for everything except as below.
 Text le as the data store.
 /var/dhcp as location for data store.
 Do not manage host records.
 Do not provide DNS domain nor name server information.
 Network used is 172.16.129.0, netmask 255.255.255.0.
 Network type is LAN and routing is using Router discovery protocol.
 Do not provide NIS information.
 Do not provide NIS+ information.
 Starting address for DHCP clients is 172.16.129.100 { with 10 addresses
the Jumpstart server. setup install server is available in the Solaris 10/Tools
directory of the install media. If you're using CDs you'll be prompted to enter
the additional CDs as required.
With the Jumpstart server installed we need to con gure the DHCP server.
This is done by executing /usr/sadm/admin/bin/dhcpmgr as root. This will
prompt you to enter the con guration for your DHCP server. An example
DHCP con guration is provided in Figure 4
If you execute svcs -a jgrep dhcp you should see that dhcp-server is enabled.
The last action is to tell the Jumpstart server and DHCP server about the
client to be installed. This is done by issuing add install client -d -e 00:0c:29:d5:c1:90
i86pc (assuming you're installing an x86 machine). If NFS or TFTP are not
enabled then add install client will con gure them as needed. You can verify
these services are executing by using svcs -a jgrep nfs and inetadm jgrep tftp.
Follow the instructions provided by add install client to con gure the DHCP
server, add a macro 01000C29D5C190 and assign:
 Boot server IP (BootSrvA) : 172.16.129.10
 Boot le (BootFile) : 01000C29D5C190
Then, using dhcpmgr, assign this macro (01000C29D5C190) to the DHCP
address range. With that, everything is con gured.
c
2006-2007 Treklogic Advanced Solutions Page 31
Linux to Solaris Administrators Guide
Depending if you're booting a SPARC or x86 machine the boot actions are
slightly di erent. On SPARC systems, the install client is booted from the
network and retrieves its hostname using rarp. It then retrieves and executes
a boot le. The boot le obtains the boot parameters from bootparamd. On
x86 systems, the DHCP server will tell the x86 PXE client the bootservers IP
and the boot le information. The root le system for the install client will be
mounted from the NFS server. The kernel is then loaded from this mounted le
system. With the kernel loaded the installation parameters will be obtained.
More information on network installations of Solaris 10 can be found on
page 119 of in the Solaris 10 Installation Guide: Network-Based Installations2.
Information on customizing and automating Jumpstart can be found in Solaris
10 Installation Guide: Custom JumpStart and Advanced Installations3. Infor-
mation on booting and installing Solaris over the Internet (WANboot) can be
found in Solaris 10 Installation Guide: Network-Based Installations Part III 4.
Flash Archives
If you have several systems that are clones of each other, similar con guration
and application installs, you can use Flash Archives to make installation simpler.
A
ash archive is a le that contains all the les from a reference system. The
reference system will have been previously installed and con gured as required.
All machines installed from the
ash will be identical to the reference system,
a virtual clone of the master system.
More information on
ash archives can be found in Solaris 10 Installation
Guide: Solaris Flash Archives (Creation and Installation)5.
Live Upgrade
Live upgrade provides the ability to create alternate boot environments on a So-
laris host. You can then install updates into the alternate environment while the
current boot environment continues to execute. When the install is complete,
the system can be rebooted to the alternate boot environment.
Using live upgrade can reduce the downtime for installation and upgrade to
minutes. It also provides the ability to fall back to the previous boot environ-
ment in case of problems resulting from the upgrade.
More information on live upgrade can be found in Solaris 10 Installation
Guide: Solaris Live Upgrade and Upgrade Planning6.
2http://docs.sun.com/app.docs/doc/819-5776
3http://docs.sun.com/app/docs/doc/819-5778
4http://docs.sun.com/app/docs/doc/819-5776/6n7r9js52?a=view
5http://docs.sun.com/app/docs/doc/819-5779
6http://docs.sun.com/app/docs/doc/819-5777
c
2006-2007 Treklogic Advanced Solutions Page 32
Chapter 5
Software Management
Any operating environment will require applications to be installed, and patches
applied. This chapter takes a look at the mechanisms to install packages on
Linux and Solaris and touches on the issue of patching a machine.
Topics Covered
RPM Packages
Solaris Packaging
Patching
33
Linux to Solaris Administrators Guide
RPM packages
Package management in RedHat or SUSE Linux is handled by the rpm com-
mand. Package installation is facilitated using rpm -i and package removal with
rpm -e.
Solaris Packaging
Solaris uses System V packages. To install packages you'll use pkgadd. Removal
is handled by pkgrm. Solaris also provides support for the rpm command.
Patching
In Linux, the concept of patching doesn't exist as it does in Solaris. In Linux
you would upgrade the given RPM to the next revision. There is no built in
mechanism in Linux to rollback a patch after it has been applied.
In Solaris you can use the patchadd and patchrm commands to handle the
application and removal of patches. Patches are available on the SunSolve1
website. While some patches require a support contract, critical patches are
available for free. Each patch le contains all of the changes that must be
applied, or rolled back, as a bundle.
On a RedHat system you can use up2date to handle any package version
changes required to update to the latest revision of a package.
There are two separate commands available on Solaris to handle these up-
grades. updatemanager provides a GUI environment to manage the application
and rollback of patches, while the smpatch application provides a command line
interface to the same functionality.
1http://sunsolve.sun.com
c
2006-2007 Treklogic Advanced Solutions Page 34
Chapter 6
System Management
The management of a Solaris system is quite similar to that of a Linux system.
Often the commands used are the same, or, in the case of printing, the subsystem
is the same. This can aid in the move from Linux to Solaris as the experience
gained on Linux is directly applicable on Solaris.
This chapter will attempt to go through some of the aspects of system man-
agement and highlight some of the similarities and di erences between Linux
and Solaris.
Topics Covered
Booting, Shutdown and Run Levels
System Services
User/Group Management
Printer and Printing Management
File System Management
Disk and Volume Management
Network Management
Remote Management
Kernel Con guration
35
Linux to Solaris Administrators Guide
Booting, Shutdown and Run Levels
Up to Solaris 9 the boot procedures between Linux and Solaris were very similar.
Both systems provided the concept of run levels that were used to de ne what
services were started and stopped at each level. The init command was used to
switch between these run levels.
Table 6.1 lists the traditional run levels seen on a Linux system.
Table 6.1: Linux run levels
0 halt
1 single user
2-5 multi user
6 reboot
Solaris machines up to Solaris 9 used a set of run levels as shown in Table
6.2.
Table 6.2: Solaris run levels before Solaris 10
S, s or 1 single user state
0 halt
2 multi-user no network services
3 multi-user with network services
4 unused
5 power o
6 reboot
With Solaris 10, and the inclusion of SMF, the run levels have been replaced
by milestones. Table 6.3 lists the default set of milestones.
Table 6.3: Solaris 10 milestones
syscon g
devices
single-user Equivalent to run level 1.
network
name-services
multi-user Equivalent to run level 2 in previous Solaris versions.
multi-user-server Equivalent to run level 3 in previous Solaris versions.
Solaris 10 still provides a limited set of run levels as seen in Table 6.4. As in
c
2006-2007 Treklogic Advanced Solutions Page 36
Linux to Solaris Administrators Guide
previous versions of Solaris, and with Linux, you can use init to switch to any
one of these levels.
Table 6.4: Solaris 10 run levels
0 halt
1, s, or S single user
5 power o
6 reboot
Two other commands are available to manipulate the current system state
on Solaris, the reboot and halt commands. These commands will restart or halt
the system, respectively. It should be noted that when using these commands
the system will not go through the normal shutdown procedures. Services are
not stopped. Processes are simply killed, le systems unmounted and the system
rebooted or halted.
The recommended method to reboot or halt the system is to use init.
System Services
When using a Linux system, unless run from inittab with the respawn attribute,
system services will not be respawned if they're killed or terminate abnormally.
With Solaris 10, and the addition of SMF, it isn't possible to simply kill a
system service as it will be automatically restarted by SMF. You have to use
the svcadm commands to disable or enable the service.
Services that would be handled by xinetd on Linux are managed by SMF
in Solaris 10. When editing the services available through inetd you will edit
the /etc/inet/inetd.conf le. You must then execute inetconv to create the
corresponding service entries in SMF. All control of the inetd services will now
be done through inetadm or svcadm.
On a Linux system the typical places to con gure services are listed in Table
6.5.
Table 6.5: Linux services con guration locations
/etc/inittab To be controlled by init.
/etc/rc*.d Run level speci c scripts that start system services.
/etc/(x)inetd.conf Controlled by inetd.
On Solaris those locations are listed in Table 6.6.
c
2006-2007 Treklogic Advanced Solutions Page 37
Linux to Solaris Administrators Guide
Table 6.6: Solaris services con guration locations
/etc/inittab To be controlled by init. Not recommended in Solaris 10.
/etc/rc?.d, /etc/init.d Run level speci c scripts that start system services.
/etc/inetd.conf Controlled by inetd; in Solaris 10, use SMF and inetadm.
SMF Solaris 10 only.
User/Group Management
Solaris extends the useradd and groupadd commands as seen in Linux to pro-
vide extensions to manage RBAC-related properties. Other options may di er
between Linux and Solaris.
Along with useradd and groupadd Solaris also provides smuser and smgroup
to manage accounts and groups in a name server, such as NIS. These two com-
mands are part of the Solaris Management Console (SMC). smc is also available
as a graphical environment to manage users and groups.
Printing and Printer Management
Most Linux systems provide CUPS to handle their printing and printer man-
agement. Solaris 10 includes CUPS as well, making it compatible with Linux
systems.
Prior to Solaris 10, Solaris used System V printing. The System V printing
system provided the commands given in Table 6.7 to interact with the print
system.
Table 6.7: System V print commands
lpadmin Modify printing system parameters.
lpsched Start the print server (/usr/lib/lp/lpsched).
lpshut Stop the print server.
cancel Cancel print jobs.
lpmove Move print jobs to another printer.
lp Submit a print job.
lpstat Display the status of printers and/or print jobs.
Print system con guration was stored in /etc/printers.conf, printers NIS
map, the users $HOME/.printers, the $PRINTER and the $LPDEST environ-
ment variables.
c
2006-2007 Treklogic Advanced Solutions Page 38
Linux to Solaris Administrators Guide
A graphical interface for setting up printers in Solaris 10 is printmgr. This
is similar to the GNOME printer management command gnome-cups-manager
available on most Linux systems. The printmgr command resides in /usr/sadm/admin/bin/printmgr.
/usr/sbin/printmgr exists as a symbolic link to it.
File System Management
Solaris supports a wide variety of le system types to support most storage
media (CDs, DVDs, Hard Drives,
oppy disks,
ash based storage) and network
based le system protocols. Solaris also uses le systems to implement various
system interface features, and to export some kernel information as les visible
to the user (ie. /etc/mnttab). Table 6.8 shows the various le system types
supported under Solaris 10. In addition to the native supported le system,
third party software vendors also provide le systems; for example, Veritas
provides the vxfs le system.
Table 6.8: File System Types
autofs Automount File System.
cachefs Caching File System.
ctfs Contract File System.
devfs Devices File System.
fd File Descriptor File System.
hsfs High Sierra File System (CDs).
lofs Loopback Virtual File System.
mntfs Mount Table File System (/etc/mnnttab).
nfs Network File System.
objfs Kernel Object File System.
pcfs DOS formatted le system.
proc /proc File System.
qfs Distributed le system.
sam-fs Archive management and retrieval.
tmpfs Memory based le system (/tmp).
udfs Universal Disk Format File System (DVDs).
ufs Unix File System.
volfs Volume Management File System.
xmemfs Extended Memory File System.
In Solaris, le systems are mounted using the mount(1M) command. Linux
places the mount command in /bin. In Solaris this command is located in
/usr/sbin. The le system type is provided to the Linux mount command using
the -t vfstype option. The equivalent option for the Solaris mount command is
-F FSType.
c
2006-2007 Treklogic Advanced Solutions Page 39
Linux to Solaris Administrators Guide
Loopback Devices
Loopback devices provide a mechanism that allow mounting of disk images as
le systems. (They are also used in Solaris to handle the loopback le system
mounts in zones.)
When mounting a loopback device on Linux you would use a command
similar to mount -o loop /path/to/disk/image /mountpoint. This would mount
the image /path/to/disk/image to the directory /mountpoint.
On Solaris, instead of mounting the disk image directly you'll use lo adm
to create a loopback device that will then be mounted. Execute lo adm -a
/path/to/disk/image which will produce a /dev/lo /X device. This device is
then used to mount the le system, mount -F FSType /dev/lo /X /mountpoint.
You will need to provide the proper -F FSType option to the Solaris mount
command. The FSType provided should match the le system found in the
disk image. For example if the disk image is an ISO image of a CD, you would
use mount -F hsfs /dev/lo /X /mountpoint.
File System Quotas
There are three main commands to work with le system quotas on Solaris. Of
the three, only quot is unique to Solaris. quot will list the le system usage per
system user.
The other two commands, edquota and quota, while being named the same
as their Linux counterparts, have di ering options and behaviour.
Disk and Volume Management
Disk Management
There are two main commands used to work with disks on Solaris, fdisk and
format. The fdisk command (on x86 systems) is used to create a partition on
the disk. Solaris partitions have type 0x82, which is the same as the Linux
SWAP partition. This may cause issues when dual booting an x86 machine
with Solaris.
Solaris uses a single partition with type 0x82 then uses Sun disk labels within
the partition to split it further into slices. This slicing is done with the format
command.
As of Solaris 10 6/06 the partition type 0x82 is depreciated. A new type,
0xbf, is now used as the partition type for Solaris (this is the Solaris2 type).
Solaris will continue to recognize the older 0x82 (solaris) ID. Older non-Solaris
partitioning software may not yet recognize the 0xbf partition type.
c
2006-2007 Treklogic Advanced Solutions Page 40
Linux to Solaris Administrators Guide
format is used to slice up Solaris fdisk partitions (on x86 systems) or disks
(SPARC) into Solaris slices. format will present the user with a list of disks to
manage. All disks recognized by the system are listed. Once a disk is selected,
the part command can be used to partition it into slices.
Volume Management
Volume management on Linux is controlled using the vg* and lv* commands.
If you aren't using ZFS, then Solaris uses a set of metadevices for volume
management. These metadevices are maintained using the meta* commands
given in Table 6.9.
Table 6.9: Metadevice commands
metadb Creates and manages meta device databases.
metainit Initializes metadevices.
metattach Used to attach a metadevice to a mirror and to
attach space to a soft partition.
metadetach Used to detach a metadevice from a mirror.
metahs Used to manage hotspare pools.
metaoine Place submirrors oine.
metaonline Place submirrors online.
metaparam Modify parameters of metadevices.
metarecover Recover soft partition information.
metarename Renames a metadevice.
metareplace Enable or replace components of submirrors or
RAID5 metadevices.
metaset Con gure shared disksets.
metastat Display status of metadevice or hot spare pool.
metaclear Delete active metadevices and hot spare pools.
metadevadm Updates metadevice information.
metasync Performs metadevice resync during reboot.
Network Management
There are commands, as seen in Table 6.10, and les, as seen in Table 6.11,
which are involved in the con guration of networking on a Solaris host.
c
2006-2007 Treklogic Advanced Solutions Page 41
Linux to Solaris Administrators Guide
Table 6.10: Networking tools
ifcon g Con gure interfaces and devices.
route Con gure network routes.
netstat Display network con guration and connection sta-
tus.
ndd Get/set con guration parameters in select kernel
drivers.
Table 6.11: Networking con guration les
/etc/hostname.[interface name] Each network interface has a corresponding le
which indicates the hostname to use for assign-
ing IP addresses to the interface. Also used to
indicate that a network interface is to use DHCP.
/etc/nodename Hostname of the system.
/etc/hosts Static table of IP addresses.
/etc/defaultrouter IP address of the default router.
/etc/netmasks Table of default netmasks for various networks.
/etc/networks Table of networks and their names.
/etc/dhcp.[interface name] DHCP parameters for interface.
/etc/resolv.conf DNS client con guration.
/etc/nsswitch.conf Name service switch le. Used to select the source
for various network information parameters.
c
2006-2007 Treklogic Advanced Solutions Page 42
Linux to Solaris Administrators Guide
Remote Management
Solaris comes bundled with both telnet and ssh to handle remote system access.
These services can be enabled and disabled with SMF as needed.
In addition to the command line access you can also use the SMC GUI to
manage a remote Solaris host.
Kernel Con guration
Making kernel con guration changes di ers between Solaris and Linux. On a
Linux system you may need to modify the source, do runtime modi cations to
entries in /proc, use sysctl or load kernel modules. On Solaris you may need to
modify /etc/system, load kernel modules, run utilities such as ndd, use DTrace
or adb.
/etc/system is the kernel con guration le. This le is loaded at boot time
by the kernel and the kernel behaviour is in
uenced by the settings in this le.
You can in
uence general kernel behaviour, including paging, swapping, pro-
cess sizing, le system
ushing, kernel memory allocation, scheduling, TCP/IP
parameters, among others. You can also force certain kernel modules or device
drivers to be loaded at boot time. Parameters passed to device driver modules
can also be con gured by setting up values in /etc/system. Since this le is only
read once at boot time, changes do not take e ect until after a system reboots.
For more information on kernel tuning using /etc/system consult the sys-
tem(4) man page and the Solaris Tunable Parameters Reference Manual1.
Loading Kernel Modules
Kernel modules are binary les that contain kernel code. These usually imple-
ment some sort of device driver, le system, system call, or some other kernel
level functionality. These modules may be loaded and unloaded throughout the
lifetime of the OS. The kernels functionality can be modi ed by loading in a
module. For example a new le system can be supported by loading in a kernel
module that implements that le system. The command to load kernel modules
is modload. To remove a kernel module from the running kernel, the modun-
load command is used. The modinfo command allows the user to view what
modules are currently loaded on the system. These commands are the Solaris
counterparts to the modprobe, insmod, rmmod, and lsmod commands on Linux.
See modload(1M), modunload(1M), and modinfo(1M).
1http://docs.sun.com/app/docs/doc/819-2724
c
2006-2007 Treklogic Advanced Solutions Page 43
Linux to Solaris Administrators Guide
Kernel tuning Commands
There are some tuning parameters that can be modi ed using commands. For
example, ndd is a utility for modifying the behaviour of network interfaces.
With ndd you can change the con guration of your network interface (from half
duplex to full duplex, for example). You can also change the way the TCP/IP
stack in solaris behaves. Consult ndd(1M) for details.
In the previous section /etc/system was mentioned as a way to modify kernel
variables. However /etc/system modi cations required a system restart to take
e ect. adb and dtrace are utilities that can allow you to directly modify kernel
parameters while the system is running. Their e ects are immediate. These
should be used with care as errors could prove to be fatal to the running kernel.
More information on kernel tuning for Solaris can be found in the Solaris
Tunable Parameters Reference Manual2.
2http://docs.sun.com/app/docs/doc/817-0404
c
2006-2007 Treklogic Advanced Solutions Page 44
Chapter 7
Device Management
Adding and removing devices from machines has become commonplace with the
advent of USB drives, external hard drives, digital cameras and other portable
devices. This chapter takes a look at how Solaris handles these devices.
Topics Covered
Device Naming and Access
Adding/Removing Devices
Removable Media
Tape Drives
Terminals, Modems and Serial Ports
45
Linux to Solaris Administrators Guide
Device Naming and Access
On Linux the /dev directory stores all of the device les needed for the system.
There is also a selection of TTY devices named /dev/pty*. Each disk available
on the system will appear in /dev with a name of /dev/sd[a-z] for SCSI disks
and /dev/hd[a-z] for IDE disks. Partitions are indicated by /dev/sdaN where
N is the partition number. The /dev directory can be considered
at, with all
of the device nodes at the save level in the directory.
Although similar, the /dev directory on Solaris has some signi cant varia-
tions. /dev on Solaris does not contain any device les. Instead, all entries are
symlinks to the /devices directory. Solaris /dev is also set out in a hierarchy.
There are sub-directories for di erent types of devices: dsk, rdsk, pts, cua and
rmt.
Disk and TTY devices are also named slightly di erently. TTYs are named
using the form /dev/pts/*. Solaris uses controller, target, device, slice to address
partitions on a disk. (e.g./dev/dsk/cAtBdCsD where A is the controller number,
B is the SCSI target ID, C is the lun, and D is the slice number with 0 as the
rst slice.)
There are no devices on Solaris that point to the disks themselves. All
disk devices point to a slice of the disk. Slice 2, typically, is a special slice
that overlaps all other partitions starting from cylinder 0 and encompassing the
entire disk.
Adding/Removing Devices
Linux uses modload and modunload to add and remove devices. A static kernel
will require that the device driver has been compiled into the monolithic kernel
and initialized at boot.
On Solaris 8 and older systems you would use the adddrv command to add
and remove devices. With Solaris 9 and newer systems the devfsadm command
is used. devfsadm -C can be used to clean up stale /dev entries. The /devices
tree re
ects what the OpenBoot Prompt (OBP) saw at system boot time.
As with any Linux distrobution the latest Solaris release will have the most
comprehensive driver support available.
Removable Media
Removable devices in Solaris are controlled by the volume manager vold. vold
is started at boot using /etc/init.d/volmgt.
c
2006-2007 Treklogic Advanced Solutions Page 46
Linux to Solaris Administrators Guide
When
oppies are inserted they are automatically mounted to /
oppy and
create two devices: a block device, /vol/dev/diskette0, and a raw device, /vol/dev/rdiskette0.
CDs and DVDs work in a similar fashion to
oppies. They are automounted
to /cdrom and create device nodes in /vol/dev/dsk and /vol/dev/rdsk for block
and raw access respectively.
Tape Drives
SCSI tapes are represented by device les in /dev/rmt. The device les have
the form of /dev/rmt/N[lmhuc][b][n] so follows:
N The device number, 0 for rst tape on the system.
lmhuc Density (low, medium, high, ultra/compressed).
b BSD behavior (whether the fsb or fsf mt commands
point to the end of the previous le (fsb), or the
beginning of the current le (fsb), end of current le
(fsf), or beginning of next le (fsf)).
Terminals, Modems and Serial Ports
There are a couple of typical Linux tools for working with terminals and modems
connected to serial ports. They are minicom and seyon for working with ports
and setserial for working with serial ports.
The main Solaris tool is tip which is used to connect to serial ports. tip can
be con gured via /etc/remote and the $HOME/.tiprc le.
Serial port speed, parity and handshaking is performed via the eeprom com-
mand.
c
2006-2007 Treklogic Advanced Solutions Page 47
Linux to Solaris Administrators Guide
c
2006-2007 Treklogic Advanced Solutions Page 48
Chapter 8
Security and Hardening
Any system that is hooked up to a network needs to be secured. Security is
a multi-faceted task, from the initial hardening to auditing for patches and
vulnerabilities.
This chapter presents some of the options for hardening and auditing a
Solaris machine.
Topics Covered
Hardening Tools
Least Privileges
Auditing Tools
Securing and Removing Services
Kernel Tuning for Security
49
Linux to Solaris Administrators Guide
Hardening Tools
There are several di erent tools available for the hardening of a Solaris machine.
These facilities range from TCP Wrappers, included in Solaris 9 and 10 with the
SUNWtcpd package, to allow for the tight control of incoming TCP connections
to the RBAC and BART tools listed below.
Solaris Security Toolkit
The Solaris Security Toolkit (previously know as the Jumpstart Architecture
and Security Scripts, JASS), provides an automated, extensible and scalable
mechanism to maintain a secure Solaris system. The JASS scripts allow you to
audit and harden your Solaris installation.
More information on JASS can be found at: http://www.sun.com/software/security/jass/.
RBAC
The Role Based Access Control (RBAC) facility allows the system administrator
to assign roles and privileges to users on the system. This allows the admin to
provide access to facilities of the system that would traditionally require root
access.
More information on RBAC can be found in rbac(1) and in
http://www.sun.com/bigadmin/features/articles/least privilege.html.
BART
The Basic Auditing and Reporting Tool (BART) is designed to monitor your
le system and look for changes in le contents. BART does this by looking at
all of the les on the system and recording information about each one.
BART, although less robust, is similar to the commercially available Tripwire
application.
More information on BART can be found in bart(1M).
Least Privileges
There are typically a large number of processes executing on a UNIX box with
full root privileges as they need to access devices, modify other processes, work
with restricted les or access other root restricted resources.
c
2006-2007 Treklogic Advanced Solutions Page 50
Linux to Solaris Administrators Guide
Having all of these processes with root privileges around can pose a security
risk. If any of those applications is hacked the user could gain full root privileges
on the system.
This is where the Least Privileges capabilities of Solaris 10 come into play.
The least privileges feature allows you to remove any system privileges from an
application that are not required for its normal operation. There are around 50
privileges that can be set on a process.
More information on the least privileges capabilities of Solaris 10 and the
available privileges can be found in privileges(5) and
http://www.sun.com/bigadmin/features/articles/least privilege.html.
Auditing Tools
Many of the auditing tools available on Linux are also available on Solaris. This
includes tripwire1, used to monitor changes to important les. crack2 and John
the Ripper3 are also available to check for weak passwords..
Securing and Removing Services
The processes of hardening a Linux or Solaris 9 and prior machines is actually
quite similar. For any service you don't wish to start you just remove the
relevant les from /etc/rc*.d. For any inet les you'll need to remove them from
the inetd con guration. On Solaris this le would be stored at /etc/inetd.conf.
With Solaris 10, for any service to be disabled you will use the svcadm disable
fservice nameg and inetadm -d fservice nameg to set them as disabled in the
SMF repository. See Section 2 for more information on SMF.
Kernel Tuning for Security
Solaris provides two ways to guard against stack based bu er over
ows. The rst
is done globally by setting noexec user stack into /etc/system. All applications
that run will have the option set. If you don't wish to do this globally an
individual application can link with the /usr/lib/ld/map.noexstk map le.
More information on the noexec user stack /etc/system option can be found
in: Solaris Tunable Parameters Reference Manual 4.
1http://www.sun.com/software/security/tripwire/
2ftp://ftp.cert.dfn.de/pub/tools/password/Crack/
3http://www.openwall.com/john/
4http://docs.sun.com/app/docs/doc/817-0404/6mg74vs9h?a=view
c
2006-2007 Treklogic Advanced Solutions Page 51
Linux to Solaris Administrators Guide
c
2006-2007 Treklogic Advanced Solutions Page 52
Chapter 9
Monitoring and
Performance
It is often necessary to monitor your systems to determine the CPU, memory,
disk or network load. There are several tools available on Solaris to aid in this
monitoring and analysis. Along with the tools listed in this chapter there are
several resources for DTrace scripts available that can aid system monitoring
and performance tuning. The OpenSolaris DTrace community1 is a good source
for these scripts.
This chapter will look at a few of the available tools and their usage.
Topics Covered
Processors
Memory
Network
Disks, Volumes and File Systems
System and User Processes
Input/Output
1http://opensolaris.org/os/community/dtrace/scripts/
53
Linux to Solaris Administrators Guide
Processors
Information on the current processors in the system can be retrieved using the
psrinfo command. An example of the psrinfo output can be seen in Figure 9.1.
Figure 9.1: psrinfo and psrinfo -v
# psrinfo
0 on-line since 09/28/2006 19:49:33
# psrinfo -v
Status of virtual processor 0 as of: 09/29/2006 02:06:34
on-line since 09/28/2006 19:49:33.
The i386 processor operates at 1733 MHz,
and has an i387 compatible floating point processor.
The mpstat command can be used to gather per-processor statistics on the
system. The output data will contain one line per processor. Figure 9.2 shows
example output from mpstat.
Figure 9.2: mpstat 1 3 output
# mpstat 1 3
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 1305 3 0 394 294 403 38 0 0 0 1554 7 3 0 90
0 10 0 0 358 258 205 0 0 0 0 250 1 1 0 98
0 0 0 0 345 245 186 0 0 0 0 195 1 0 0 99
A eld of note in the mpstat output is xcal, if you have multiple CPUs.
This will be the number of inter-processor cross-calls. csw is the number of
context switches. syscl is the number of system calls that happened on the
processor. usr, sys and idl give the amount of user time, system time and idle
time respectively. The wt column is a legacy artifact and will always return 0
on Solaris 10.
The kstat command can also be used to gather information on the proces-
sors. By providing the -m cpu option to kstat you will retrieve all the CPU
information. Figure 9.3 shows an example of this usage.
Memory
The vmstat command can be used to display information on the system's virtual
memory subsystem. vmstat gives information on the current swap and memory,
c
2006-2007 Treklogic Advanced Solutions Page 54
Linux to Solaris Administrators Guide
Figure 9.3: kstat -m cpu output
# kstat -m cpu
module: cpu instance: 0
name: intrstat class: misc
crtime 6.573712134
level-1-count 1214737
level-1-time 3558707908
level-10-count 2364949
...
page faults, disk stats and fault information. Figure 9.4 shows example vmstat
output.
Figure 9.4: vmstat 2 5
# vmstat 2 5
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr cd f0 s0 -- in sy cs us sy id
0 0 0 1998572 1101884 8 29 14 0 1 0 35 8 0 0 0 397 865 412 5 1 94
0 0 0 1913292 1014728 0 22 6 0 0 0 0 0 0 0 0 364 204 207 1 0 99
0 0 0 1913292 1014728 0 0 0 0 0 0 0 0 0 0 0 356 162 184 1 0 99
kstat can be used to gather memory information. The memory module is
vmem. Figure 9.5 shows example output.
Figure 9.5: kstat -m vmem
# kstat -m vmem
module: vmem instance: 1
name: heap class: vmem
alloc 4632
contains 0
contains_search 0
crtime 0
Network
The netstat command can be used to gather network status information. netstat
can retrieve information on the active network sockets, various network data
c
2006-2007 Treklogic Advanced Solutions Page 55
Linux to Solaris Administrators Guide
structures, STREAMS memory statistics, interface states, routing tables and
DHCP information.
You can use kstat to query information on each network interface driver in
the system. In my case, I'm using the bge driver. Figure 9.6 is an example of
the output.
Figure 9.6: kstat -m bge
# kstat -m bge
module: bge instance: 0
name: bge0 class: net
brdcstrcv 16059
brdcstxmt 14
collisions 65
crtime 128.886063641
ierrors 0
ifspeed 100000000
ipackets 33976
Disks, Volumes and File Systems
The df command displays information on the size, used and available space of
the mounted le systems. Figure 9.7 shows example df output.
Figure 9.7: df -h
# df -h
Filesystem size used avail capacity Mounted on
/dev/dsk/c0d0s0 9.6G 3.1G 6.4G 33% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
The du command can be to summarize disk usage information. du will
output the size of each le and each directory as it walks the le system from
the given starting directory.
metastat can be used to display metadevice or hot spare pool information.
c
2006-2007 Treklogic Advanced Solutions Page 56
Linux to Solaris Administrators Guide
System and User Processes
System information can be gathered with the prstat command. prstat shows
process and thread information. prstat is similar to the top command. top
is also available for Solaris as part of the Companion CD. Figure 9.8 shows
example output from prstat.
Figure 9.8: prstat
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
533 dj2 36M 62M sleep 59 0 0:03:45 3.8% Xorg/1
627 dj2 62M 17M run 49 0 0:00:16 0.5% gnome-terminal/2
577 dj2 17M 11M sleep 59 0 0:00:41 0.3% enlightenment/1
873 dj2 3972K 2740K sleep 59 0 0:00:00 0.2% vim/1
Input/Output
The iostat command can be used to display information on the di erent IO
devices in the system. This can include hard drives, TTY devices, NFS mounts
and other devices. Example iostat output can be seen in 9.9.
Figure 9.9: iostat 2 5
# iostat 2 5
tty cmdk0 sd0 nfs1 nfs2 cpu
tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id
1 140 48 8 8 0 0 0 0 0 0 0 0 0 5 1 0 94
0 117 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 99
0 40 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 99
c
2006-2007 Treklogic Advanced Solutions Page 57
Linux to Solaris Administrators Guide
c
2006-2007 Treklogic Advanced Solutions Page 58
Chapter 10
Backup and Restore
Hard drives fail. People do silly things. Lightning strikes. These reasons and
many more just drive home the fact that everyone should be backing up their
data.
This chapter will give some information on di erent backup and restore
utilities in Solaris as compared to Linux.
Topics Covered
File System Backup and Restore
Compression Tools
File System Snapshots
59
Linux to Solaris Administrators Guide
File System Backup and Restore
When backing up and restoring le systems on Linux you'll typically use the
dump and restore commands.
Similarly, on Solaris you'll use the ufsdump and ufsrestore commands to
backup UFS le systems. For ZFS le systems see Section 10, File System
Snapshots.
There are many other backup tools that are used on Linux systems. Tar
and cpio are examples of these tools that some use. They are also available on
Solaris.
There are also a variety of open source backup tools, such as Amanda, that
are popular in Linux circles. Just like most open source tools, Amanda can also
be used in Solaris.
Sun also delivers The Sun StorageTek Enterprise Backup software and other
associated storage management tools. Sun also resells Legato Networker and
IBM Tivoli. There are many other third party backup software available on the
Solaris platform.
Compression Tools
The three most common compression tools bzip, gzip and zip are all available
on Solaris. You should con rm the options have not been changed.
File System Snapshots
Snapshots of the UFS le system can be taken using the fssnap utility. When
using ZFS snapshots can be taken using the zfs command. A command similar
to zfs snapshot tank/home@monday will produce a snapshot called monday.
You can then take this snapshot data and write it to tape using:
zfs send tank/home@monday > /dev/rmt/0
c
2006-2007 Treklogic Advanced Solutions Page 60
Chapter 11
Troubleshooting
If Murphy is to believed, something will always go wrong. This chapter is here
to help you out when that something happens. Following is a selection of issues
and guidance to aid you in solving some issues you may encounter.
Topics Covered
Installation
System Startup
Core Files
Kernel Crash Dumps
Logs
Permissions and File Access Problems
Missing Commands
Printing
File Systems
Root Password Recovery
Network
Diagnostic and Debugging Tools
61
Linux to Solaris Administrators Guide
Installation
Installing from a USB CDROM drive
Installing Solaris 10 onto an x86 system from a bootable USB CDROM doesn't
always complete successfully. Occasionally the system will lose track of the USB
CDROM being used to install. If this happens the following should help rectify
the problem.
1. During installation, select the Solaris Interactive Text (Console session)
install type. Continue until the install drops to a shell with the message:
ERROR: The disc you inserted is not a Solaris OS CD/DVD
2. Check, and remember, the list of available devices in /dev/dsk.
3. Unplug the USB CDROM and plug it back in after a few seconds.
4. Check for the newly recognized device (e.g. c1t0d0XXXX).
5. Mount the USB CDROM mount -F hsfs /dev/dsk/c1t0d0p0 /cdrom, re-
member it must be p0 (partition 0).
6. Run /sbin/install-solaris to continue.
System Startup
If you run into issues with system startup there are a few places you can look
for information. First, svcs -x will list any services that were not started, or
that were oined by the system. There will also be pointers to log les and
other information to aid in correcting issues.
The next place to look is the /var/adm/message le. This le contains all
the log messages for the system. Failing that, verify that any scripts being
executed from /etc/rc*.d complete without issue.
Cannot mount boot archive
If you receive a panic: cannot mount boot archive message while booting
then you've somehow lost your boot archive. This can happen if you install
multiple patches simultaneously that require rebuilding of the boot archive.
In order to correct this situation you'll need to boot the system into failsafe
mode. Failsafe mode will normally prompt you to update the boot archive. If
this is the case, reboot and you should be ne.
c
2006-2007 Treklogic Advanced Solutions Page 62
Linux to Solaris Administrators Guide
Otherwise, check if the original root partition is already mounted on /a,
if not, mount it to /a. (e.g. mount -F ufs /dev/dsk/c1d0s0 /a). Once the
partition is mounted issue /a/boot/solaris/bin/create ramdisk -R /a to rebuild
the boot archive.
Reboot and the issue should be corrected.
Core Files
Core les are created when a system exits abnormally. Cores can be quite useful
in determining the issue that caused the application to terminate. The coreadm
utility allows you to modify the location, name and contents of core dump les
produced on Solaris.
There are also several applications available to extract information from a
core le. Some of these applications are listed in Table 11.1.
Table 11.1: Core le utilities
p
ags Print tracing
ags.
pcred Print credentials.
pldd List dynamic libraries linked into the process.
pstack Print a hex and symbolic stack trace for each LWP
in the process.
Kernel Crash Dumps
If a kernel panic happens on a Linux machine an oops message will appear which
can be decoded to determine the cause of the issue. There are no actual crash
dump les produced by the Linux kernel.
If the Solaris kernel panics, a crash dump le will be written to /var/crash/hostname.
This crash dump le can be used in post-mortem analysis of why the system
crashed.
Logs
When trouble occurs it is often a good idea to take a look at the log les as the
rst step to diagnosing the issue. Depending on the desired information there
are a few di erent places to look. /var/adm/messages contains the main system
logs. /var/log/syslog contains Sendmail logs, among others. /var/cron/log will
c
2006-2007 Treklogic Advanced Solutions Page 63
Linux to Solaris Administrators Guide
contain information from the cron service. Finally, /var/lp/logs/lpsched will
contain the printer server logs.
There are also some application speci c log les, for example:
 /var/samba/log
 /var/apache/log
 /var/apache2/log
Missing Commands
Commands may exist in di erent directories, may need to be installed, or may
need to be ported if unavailable.
First, check the $PATH variable of your shell to verify all of the needed direc-
tories are present. The command could exist in one, or many, of the directories
listed in Tables 1.2 or 1.3.
If the command isn't installed you can attempt to install a freeware package
of the software. This could be retrieved from the Companion CD, sunfree-
ware.com, blastwave.org or installed from a source distribution.
If the tool doesn't exist on Solaris you may be required to port the original
tool or write your own variation.
Printing
File Systems
Root Password Recovery
If you've managed to forget the root password for your Solaris box, or inherited
a box without being told the password, it is possible to recover the box without
having to re-install.
Boot from the Solaris install CD, then when it starts exit out of the install
process. Mount the root disk to /a, modify /a/etc/passwd and /a/etc/shadow.
Reboot the system and the password should be changed.
Network
If you're having trouble with the network connections, Table 11.2 lists a few
commands that may be of service.
c
2006-2007 Treklogic Advanced Solutions Page 64
Linux to Solaris Administrators Guide
Table 11.2: Useful networking commands
traceroute To trace the route a packet takes to reach its des-
tination.
/usr/sbin/ping To test if remote hosts are reachable.
ifcon g To view network interface con guration.
netstat To show network status.
snoop Similar to tcpdump.
tcpdump Available on the companion CD.
Controlling NFS versions supported
In some circumstances, mounting a le system exported from a Linux system
to a Solaris 10 system, the following error message may be encountered:
$ mount linux-nfs-server:/export /mnt
nfs mount: mount: /mnt: Not owner
This occurs because the Solaris 10 NFS client uses the NFSv4 protocol to
mount the le system, and the Linux NFS client does not support NFSv4.
The solution to this problem is to change the default NFS client proto-
col that the Solaris system will use to the NFSv3 protocol. To do this, edit
/etc/default/nfs and add the line NFS CLIENT VERSMAX=3 to instruct So-
laris to use the NFSv3 protocol until the Linux nfs server software is upgraded
to support NFSv4.
If for some reason you want the Solaris nfs server not to support NFSv4, you
can do this by modifying /etc/default/nfs to indicate NFS SERVER VERSMAX=3
The Solaris system will now only support up to version 3 of the NFS protocol.
Diagnostic and Debugging Tools
DTrace is a powerful new tool available in Solaris 10 to make the process of
diagnosing system issues easier. DTrace can probe into all aspects of the system
including network, IO, function calls and when applications go on and o the
CPU. See Section 2 for more information.
Several repositories exist for DTrace scripts. The OpenSolaris DTrace com-
munity1 is a good starting point. The DTrace Toolkit is a collection of useful
scripts that maybe of aid in your troubleshooting.
1http://opensolaris.org/os/community/dtrace/
c
2006-2007 Treklogic Advanced Solutions Page 65
Linux to Solaris Administrators Guide
Two other tools that are available are truss which can trace system calls
made by applications and apptrace which is used to trace function calls made
by an application.
c
2006-2007 Treklogic Advanced Solutions Page 66
Appendix A
Packages
The following is a list of the software packages that are bundled with, or sup-
ported on, Solaris 10. Any package that is listed emphasized is fully supported
by Sun and Sun provides support the same as for Sun owned software. Oth-
erwise, Sun provides existing patches and escalates new bugs to the developer
community
Network Servers & Clients
Apache Apache2 bind
Mozilla ncftp ppp
Samba sendmail SER (SIP Proxy Server)
Tomcat wget wu-ftpd
xntpd Zebra
Commands
a2ps MySQL bzip2
patch footmatic print ppds texinfo
ghostscript traceroute ghostscript fonts
Webmin Gimp print drivers gzip
GNU patch utility GNU tar GNU grep
less ImageMagick texi2html
IPMItool mkisofs Open Printing API
rpm2cpio.pl System Management Agent
67
Linux to Solaris Administrators Guide
Libraries
Glib GTK+ JPEG
Libexpat Libusb Libxslt
PNG Tcl/Tk TIFF
XML2 XPM zlib
Compilers & Tools
Binutils gcc Bison
gm4 Flex gmake
Scripting Languages
Perl Python
Security Tools
Secure Shell tcp wrappers
Shells
bash tcsh zsh
Applications
Networking
cups-1.1.20 ethereal 0.10.5 fetchmail 6.2.5
hpijs 1.6 lynx-2.8.4 mutt-1.4.2.1
nmap 3.5 nmh-1.0.4 Open LDAP 2.2.17
Open SLP 1.0.11 pine-4.61 procmail-3.22
rsync 2.6.3pre1 slm-0.9.6.2 snort-2.0.0
tcpdump-3.8.3
Publishing
espgs-7.07.1 graphviz 1.10 gro -1.16.1
xpdf 3.0
c
2006-2007 Treklogic Advanced Solutions Page 68
Linux to Solaris Administrators Guide
Utilities
a o-2.4.6 amanda-2.4.4 cdrtools-2.01
cupsddk 1.0 di utils-2.8.1 enscript-1.6.1
expect 5.39 le-4.10 leutils-4.1
ndutils-4.1.20 Foomatic lters 3.0.2 Foomatic-ppds 3.0.1
gcal-3.01 gettext-0.10.35 gimp-print-4.2.6
gkrellm 2.1.19 gnuplot 3.7.3 ispell-3.2.06
lxrun 0.9.6.1 mpack-1.5 mpage-2.5.1
mpg123-0.59r mysql-jdbc-3.0.8 netpbm-10.3
plotutils-2.4.1 pnm2ppa-1.12 rpm-4.1
sane 1.0.12 screen 4.0.2 sgrep-1.92a
sh-utils-2.0a sharutils-4.2.1 sudo 1.6.8p5
TeTex 2.0.2 textutils-2.0 tnef 1.1.3
top-3.5.1 uudeview-0.5.20 vorbis-1.0
wine 20041104 xpp-1.1
Accessibility
brltty-3.3.1 emacspeak-18.0 emacspeak-ss-1.9.1
freetts-1.1.1 screenbrltty-4.02 unwindows-1.1.3
w3-4.0.47 yasr-0.6.4
Editors
blue sh 0.12 emacs 21.3 gawk-3.0.6
joe-3.1 sed-3.02 (GNU) vim-6.3
xemacs-21.4.15
Development
Tools
autoconf 2.59 automake 1.8.3 binutils-2.15
cvs 1.11.17 ddd 3.3.8 gdb 6.2.1
Languages
bison-1.35 gcc-2.95.3 gcc-3.4.2
libtool 1.5.2 m4-1.4 (GNU) MySQL python API 0.9.2
php-4.3.2 ruby-1.6.4 samp-1.0
tclX-8.2.0
c
2006-2007 Treklogic Advanced Solutions Page 69
Linux to Solaris Administrators Guide
Libraries
aalib-1.2 berkley-db 1.85 berkley-db 4.2.52NC
curl-7.10.3
tk-1.1.3 fnlib-0.5
GD Graphics library 2.0.15 guile-1.3.4 imlib-1.9.15
libexpt-1.95.7 libmpeg-1.3.1 libpcap-0.8.3
libsane 1.0.14 linungif-4.1.0 ncurses-5.2
Ogglib-1.0 Perl regex lib 4.5 qt-3.1.1
Desktop
Environment
kde-3.1.1a KOce-1.2.1 XFce-3.8.16
System
Daemons
imap2002d (UW) proftpd 1.2.10rc1 squid 2.5.STABLE7
X
Applications
afterstep-1.8.8 fvwm2-2.4.3 WindowMaker-0.80.2
Window Managers
global-4.8 readline-4.2 make-3.80 (GNU)
slang-1.4.0 SDL-1.2.5 Xaw3d-1.5
asclock-1.0 xcpustate-2.5 ethereal-0.9.11
xdelta 1.1.3 gimp-1.2.1 xmcd 3.2.1
rxvt-2.7.10 xmms 1.2.10 stardic-1.3.1
xterm-196 (XFree86) vnc-3.3.7
c
2006-2007 Treklogic Advanced Solutions Page 70
Appendix B
Quick Reference Guide
The information in this chapter can be used as a quick reference when moving
from Linux to Solaris. It will give information on the command changes and
application di erences.
Table B.1: Command Di erences
Linux Solaris
ps /usr/bin/ps requires command line argument
changes
/usr/ucb/ps has compatible command line argu-
ments but the output maybe di erent.
tcpdump use snoop
awk Use one of nawk, /usr/xpg4/bin/awk or gawk.
tar Use /usr jopt/sfw/bin/gtar
Table B.2: Con guration Files
Linux Solaris
/etc/fstab /etc/vfstab
/etc/exports /etc/dfs/dfstab
/etc/ntp.conf /etc/inet/ntp.conf
/etc/aliases /etc/mail/aliases
/etc/inetd.conf inetadm (solaris 10)
/etc/xinetd.conf inetadm (solaris 10)
Solaris 9 - convert to /etc/inetd.conf
/etc/printcap /etc/printers.conf
71
Linux to Solaris Administrators Guide
Table B.3: Kernel Drivers
Linux Solaris
/etc/modules* /etc/system
/kernel/drv/*.conf
Table B.4: Kernel Con guration
Linux Solaris
sysctl /etc/system
c
2006-2007 Treklogic Advanced Solutions Page 72
Index
/etc/system, 43
/opt/sfw/bin, 4
/platform, 3
/proc, 2, 3
/usr/bin, 3
/usr/sfw/bin, 4
/usr/ucb, 3
adb, 43, 44
adddrv, 46
apptrace, 66
awk, 19, 20
gawk, 20
GNU awk, 19
nawk, 20
System V awk, 19
XPG4 awk, 20
BART, 50
basename, 19
boot archive, 62
bzip, 60
cat, 20
chmod, 23
chown, 20
chroot jails, 11
coreadm, 63
CUPS, 38
devfsadm, 46
df, 21, 56
DTrace, 14, 43
dtrace, 14, 44
du, 22, 56
dump, 60
edquota, 40
eeprom, 47
ext3, 2
fdisk, 40
lesystem(5), 3
Flash Archives, 32
FMRI, 8
format, 40
fsck, 16
fssnap, 60
getfacl, 25
Global Zone, 11
GNU, 19
GNU tar, 25
groupadd, 27, 38
gzip, 60
halt, 37
inetadm, 9, 51
inetconv, 9
inetd, 9
init, 36, 37
insmod, 43
iostat, 57
JFS, 2
Jumpstart, 30
kstat, 54
Least Privileges, 50
legacy run, 8
Live Upgrade, 32
lo adm, 40
lsmod, 43
metastat, 56
73
Linux to Solaris Administrators Guide
minicom, 47
modinfo, 43
modload, 43, 46
modprobe, 43
modunload, 43, 46
mpstat, 54
ndd, 43, 44
netstat, 55
patchadd, 34
patchrm, 34
pkgadd, 34
pkgrm, 34
Predictive Self Healing, 18
prstat, 57
ps, 22
psrinfo, 54
quot, 40
quota, 40
RBAC, 50
reboot, 37
reiser, 2
Resource Management, 11
restore, 60
rmmod, 43
rpm, 34
Run Levels, 36
setfacl, 23
setserial, 47
seyon, 47
Shells
/bin/bash, 2
/bin/sh, 2
smc, 38
SMF, 8, 18
smgroup, 38
smpatch, 34
smuser, 38
Solaris Containers, 11
Solaris Security Toolkit, 50
ssh, 43
Standards
POSIX, 2
SVID, 2
XPG, 2
SunSolve, 34
svcadm, 8, 9, 51
svccfg, 9
svcs, 8, 9
sysctl, 43
tar, 25
telnet, 43
tip, 47
top, 57
truss, 66
UFS, 2
ufsdump, 60
ufsrestore, 60
up2date, 34
updatemanager, 34
useradd, 25, 38
Virtualization, 11
vmstat, 54
vold, 46
XFS, 2
ZFS, 2, 16, 41
zfs, 60
zip, 60
zoneadm, 12
zonecfg, 12
Zones, 11
Sparse, 12
Whole Root, 12
c
2006-2007 Treklogic Advanced Solutions Page 74