This approach could be a useful addition to the arsenal of today’s spam-fighting techniques, observers argue, in that, unlike other typical spam fighting approaches, the content of the email does not have to be scanned.

The work “advanced both the science of spam fighting and … worked through all the engineering challenges of getting these techniques built into the most popular open-source spam filter,” said Massachusetts Institute of Technology computer science research affiliate Steve Bauer, who was not involved with the work. “So this is both a clever bit of research and genuinely practical contribution to the persistent problem of fighting spam.”

In the paper that accompanied the presentation, the researchers showed that spam email blasts have certain characteristics at the networking transport layer. Signal analysis of factors such as timing, packet reordering, congestion and flow control can reveal the work of a spam-spewing botnet. “A lot of spam comes from spambots, which are sending as fast as they can and congesting their local uplink,” Beverly said. “So you can detect them by looking really hard at the TCP stream.”

Thus far, earlier techniques developed for analyzing spam at the network transport layer have been offline, which is to say, the email traffic is analyzed as a batch, and the results can be used later. The naval researchers have developed an architecture for analyzing network traffic as it comes over the wire.

For the implementation, they used the the SpamAssassin email filter. SpamAssassin has a plug-in architecture for incorporate new filtering techniques. “We have a daemon that captures all the packets and looks timing and other congestion characteristics of the traffic stream,” Beverly said. The plug-in can learn to identify and detect spam without human intervention. In tests, SpamFlow was able to correctly identify spam over 95 percent of the time, after a reception of 1,000 emails.

The ability to detect a spam message without actually examining the contents of the message would be handy in a number of situations, noted Bruce Davie, a Cisco fellow and visiting lecturer at MIT. Davie is familiar with though not involved in the work. An Internet service provider could apply the detection algorithm without violating users’ privacy. It can be used to detect messages that are encrypted, such as those traveling over an encrypted link. It can also be used to detect other forms of malicious traffic, such as port scans from botnet hosts.

“Overall, I see it as a generally useful tool in the fight against malicious traffic,” Davie said. “You can combine it with traditional anti-spam techniques to improve accuracy.”

Currently, the team is beta testing the software at a number of locations. They plan to release it as open-source software afterward.

The U.S. National Science Foundation funded part of this work, under the Software Development for Cyberinfrastructure (SDCI) program.

Source: ITWorld

The only option is to create an opensolaris live usb. There are couple of ways you can install make ubs live stick but the procedure here i am going to explain is simple and its work with windows. There are other methods like ./usbcopy from opensolaris it self.

There  is a windows tool that will allow Windows users to put a copy of OpenSolaris media on a usb stick. Download it from

http://devzone.sites.pid0.org/OpenSolaris/opensolaris-liveusb-creator

Download the open solaris image from here

http://genunix.org/distributions/indiana/osol-0906-111-x86.usb

Run the usb creator and select the image and thats it, you have a working live bootable usb stick. You can install opensolaris without a CD.

drwxrwxrwt 5 root sys 458 Oct 21 17:04 /public

Sticky bit cab be set by chmod command. You need to assign the octal value 1 as the first number in a series of four octal values.

# chmod 1777 public

Solaris supports both types VTOC disk label and the EFI disk label. Solaris 10 (and later versions of Solaris 9) provides support for disks that are larger than 1 TB on systems that run a 64-bit Solaris kernel. The EFI label provides support for physical disks and virtual disk volumes. The UFS file system is compatible with the EFI disk label, and you can create a UFS file system greater than 1 terabyte.

The traditional VTOC label is still available for disks less than 1 terabyte in size. You can use the format-e command to label a disk less than 1TB with an EFI label.

The advantages of the EFI disk label over the VTOC disk label are as follows:

• Provides support for disks greater than 1 TB in size.
• Provides usable slices 06, where slice 2 is just another slice.
• Slices cannot overlap with the primary or backup label, nor with any other partitions. The size of the EFI label is usually 34 sectors, so partitions start at sector 34. This feature means that no partition can start at sector zero.
• Sizes are reported in blocks. No cylinder, head, or sector information is stored in the EFI label.
• Information that was stored in the alternate cylinders area, the last two cylinders of the disk, is now stored in slice 8.
• If you use the format utility to change partition sizes, the unassigned partition tag is assigned to partitions with sizes equal to zero. By default, the format utility assigns the usr partition tag to any partition with a size greater than zero. You can use the partition change menu to reassign partition tags after the partitions are changed.
• Solaris ZFS  uses EFI labels by default.

But there some restrictions with EFI disk labels and those are:

• You cannot boot from a disk with an EFI disk label.
• The EFI disk label is not supported on IDE disks.
• The EFI specification prohibits overlapping slices. The entire disk is represented by c#t#d#.
• The SCSI driver, ssd or sd, currently supports only up to 2 terabytes. If you need greater disk capacity than 2 terabytes, use a disk and storage management product such as Solaris Volume Manager to create a larger device.
• Layered software products intended for systems with EFI-labeled disks might be incapable of accessing a disk without an EFI disk label.
• You cannot use the fdisk command on a disk with an EFI label that is greater than 1 terabyte in size.
• A disk with an EFI label is not recognized on systems running previous Solaris releases.
• You cannot use the Solaris Management Console’s Disk Manager tool to manage disks with EFI labels. Use the format utility to partition disks with EFI labels. Then, you can use the Solaris Management Console’s Enhanced Storage Tool to manage volumes and disk sets with EFI-labeled disks.
• The EFI disk label provides information about disk or partition sizes in sectors and blocks, but not in cylinders and heads.
• The following format options are either not supported or are not applicable on disks with EFI labels:
  • The save option is not supported because disks with EFI labels do not need an entry in the format.dat file.
  • The backup option is not applicable because the disk driver finds the primary label and writes it back to the disk.

  If you have volume manger VxVM EFI disks wont work under Solaris 9. But Solaris 10 supports. Its in fact VxVM is not supporting as you could label, create ufs filesystems on these disks and so on. But when you do vxdisksetup you will get errors.

Ref : Sun Docs, Veritas Docs

# ifconfig <interface> <ip_address> <netmasks> <broadcast address>

You can figure out the interface name by using ifconfig command. Now to change the IP under solaris 9 and older version, just open /etc/hosts file and add or edit the entry for the IP address and the hostname. You need to reboot the server so that the changes will take place.

In Solaris 10 there is one more file you need to edit which is /etc/inet/ipnodes (ipnodes file is for IPv6, without adding an entry to the file, the IP address (IPv4) will not active but SUN has fixed this issue).  Next restart the network services and the changes will take place

#svcadm restart newtork/physical

No reboot, no downtime. Cool !

1.  Production and test interfaces in the same IP subnet
1.1  With defaultrouter
1.2  Without defaultrouter
1.3  With dedicated hosts acting as test targets with “host-routes”
1.4  Configuration example for 1.1, 1.2 and 1.3

2.  Production and test interfaces in different IP subnets but the same
physical network
2.1  With defaultrouter in production subnet and test subnet
2.2  With defaultrouter in production subnet but without defaultrouter in test subnet
2.3  With dedicated hosts acting as test targets with “host-routes”
2.4  Configuration example for 2.1, 2.2 and 2.3
2.5  Configuration example for 2.2 if you use IPMP on the test subnet

A.  Start script for adding static “host routes” permanently
/etc/init.d/ipmp.targets

B.  Summary

Note: This document does not cover the basic knowledge of IP Multipathing. If you would need it, please check it in Sun Microsystems Documentation

All IPMP patches mentioned below should be installed.

Sparc     Intel     Comments
OS
Release

7 or earlier     N/S     N/S       IPMP was introduced with Solaris[TM] 8 Update 2
for Solaris 8 FCS the Patch ID: 108528,
116965 (109898), 109900 are required

8         108528   108529   Kernel Patch (in.mpathd, ip, icmp, ifconfig)
116965   116966   ip/arp Patch
109900     109901      Startup Patch (/etc/init.d/network and /sbin/ifparse)
109902   109903   Offlining capability (Update 3
110378   110396   Mipagent patch needed for offlining capability
116991   116992   RCM Daemon

9         112233   112234   Kernel Patch (ip)
114344   119435   in.mpathd, arp, ifconfig (see SunAlert 57435)(1)
112912    N/P     libinetcfg.so
112854    N/P     icmp
113073   114733   ipmp header files

10         118833   118855   Kernel Patch (in.mpathd, ip, icmp, ifconfig)

Key
—–
N/S – Product not supported on this OS
N/P – No patch applicable for this OS

Legend:
——-
IPMP    system with IPMP group
T<n>    target host <n>
p       network/host part of IP address of interface in production subnet
t       network/host part of IP address of interface in test subnet
—     data link subnet (i.e broadcast domain) with one IP subnet
===     data link subnet (i.e broadcast domain) with two (or more) IP
subnets

Good to know:
————-
The operation of IP Multipathing (in.mpathd) depends on the routing
configuration. Therefore in.mpathd always refers to the routing-table
(IRE-cache) to distinguish which test partner(s) are going to be used.
Test partners are required for deciding if the interface is working properly.

in.mpathd by default chooses the defaultrouter as single test-target
for probing. If no defaultrouter exists for the test-interface ip address,
arbitrary hosts on the link are detected by sending out “all hosts”
multicast packets (224.0.0.1) on the wire to detect its test-partners.
An “all routers” multicasts (224.0.0.2) will never be sent! The first five
hosts that are responding to the echo packets are chosen as targets
for probing. In such a non-defaultrouter environment, the in.mpathd
always tries to find five probe targets via an “all hosts” multicast.

The in.mpathd detects failures and repairs by sending out ‘icmp-echo’
probes (like pinging) from all interfaces that are part of the IPMP group.
If there are no replies to five consecutive probes, the interface is
considered to have failed and performs a failover of the network access
to another interface in the IPMP group. The probing rate depends on the
failure detection time which is defined in /etc/default/mpathd. By default,
failure detection time is 10 seconds. Thus the five probes will be sent
within the failure detection time.

1.  Production and test interfaces in the same IP subnet
======================================================

1.1 With defaultrouter
———————-

+————-+
|defaultrouter|
+——o——+
| p=t:172.20.20.1
|
|
———-+-+————————+————————-
| |                                  p=t:172.20.20/24
p:172.20.20.10  | |
t:172.20.20.210 | | t:172.20.20.220
+—o-o—+
|   IPMP  |
+———+

IPMP only use the defaultrouter as probe target. Each test interface of the
IPMP group send ICMP requests only to the defaultrouter. To get the
configuration, IPMP looks to the routing table and is independent from
/etc/defaultrouter file. NO “all hosts” multicast (224.0.0.1) will be sent.

Advantages:
- Easiest configuration for IPMP.

Disadvantages:
- When the defaultrouter is down IPMP failover does not work anymore.
The in.mpathd does NOT send out multicasts to get other probe
targets, therefore all interfaces in the IPMP group get the state
“failed”. You can ignore this bug/feature when you have a
defaultrouter which is 100% online! Please look to RFE 4431511 and
4489960 for further information.
- If you have a lot of IPMP groups, the defaultrouter has to reply to
a lot of ICMP requests. Take care of defaultrouter. Do not overload
the defaultrouter.
- The defaultrouter has to reliably answer ICMP echo requests. (e.g.
firewalls sometimes do not)

1.2 Without defaultrouter
————————-

+———+           +———+
|    T1   |   ……  |    T5   |
+—-o—-+           +—-o—-+
| p=t:172.20.20.110   | p=t:172.20.20.150
|                     |
|                     |
———–+-+————–+———————+——-
| |                            p=t:172.20.20/24
p:172.20.20.10  | |
t:172.20.20.210 | | t:172.20.20.220

+—o-o—+
|   IPMP  |
+———+

IPMP dynamically determines five arbitrary hosts on the link via “all
hosts” multicast address (224.0.0.1). At the least, you need one probe
target that IPMP will work. Beware that one probe target is not reliable
enough. If there are less than five targets available the in.mpathd sent
out the “all hosts” multicasts to get a complete list of five probe targets.

Advantages:
- easiest configuration for IPMP in a subnet without a defaultrouter.
- is very reliable due to the five targets.

Disadvantages:
- a subnet without an defaultrouter is very rare.

1.3 With dedicated hosts acting as test targets with “host-routes”
—————————————————————-

+————-+  +———+           +———+
|defaultrouter|  |    T1   |   ……  |    T5   |
+——o——+  +—-o—-+           +—-o—-+
!              | p=t:172.20.20.110   | p=t:172.20.20.150
!              |                     |
!              |                     |
————+-+—————+———————+——-
| |                              p=t:172.20.20/24
p:172.20.20.10  | |
t:172.20.20.210 | | t:172.20.20.220
+—o-o—+
|   IPMP  |
+———+

Some “host routes” will be defined with a startscript in
/etc/rc2.d/S70staticroutes.  (The script is attached to this document.)
When IPMP refer to the routing table it will choose the first five defined
“host routes” as probe targets. This is due to the fact that normally the
“host routes” are before the defaultrouter in the routing table. If you
have less than five “host routes” also the defaultrouter (when available)
will be used as probe target as well.

Example:
a) Configuration with host1, host2 … hostN (with N=5 or N>5),
defaultrouter :
==> The first five hosts (host1 … host5) will be defined as target.

b) Configuration with less than 5 hosts : for instance, host1, host2,
defaultrouter :
==> The three systems (host1, host2, defaultrouter) will be defined as
target.

Also in this case the in.mpathd tries to get five probe targets all
the time from the routing table. Remember in this configuration the
in.mpathd does NOT send “all hosts” multicasts!

Advantages:
- The defaultrouter is not important for the IPMP configuration because
if the defaultrouter is not available you have still some “host routes”
for probing.
- IPMP is always high available due to independency to the defaultrouter

Disadvantages:
- More administrative work to do.
- Due to static configuration you should check that some of the probe
targets   are always available.

1.4 Configuration examples for 1.1, 1.2 and 1.3
————————————————-

/etc/hosts
———-
127.0.0.1        localhost
172.20.20.10     host10       loghost
172.20.20.210    host10-test-qfe0
172.20.20.220    host10-test-qfe4

/etc/hostname.q fe0
——————
host10 netmask + broadcast + group ipmp0 up \
addif host10-test-qfe0 deprecated -failover netmask + broadcast + up

/etc/hostname.qfe4
——————
host10-test-qfe4 deprecated -failover netmask + broadcast + group ipmp0 up

ifconfig output:
—————-
qfe0: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 172.20.20.10 netmask ffffff00 broadcast 172.20.20.255
groupname ipmp0
ether 8:0:20:e8:88:dc
qfe0:1:
flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 3
inet 172.20.20.210 netmask ffffff00 broadcast 172.20.20.255
qfe4:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 4
inet 172.20.20.220 netmask ffffff00 broadcast 172.20.20.255
groupname ipmp0
ether 8:0:20:e8:89:34

Note: The example describe the setup of an active-active IPMP configuration
which is best practices. But you can also configure an active-standby
configuration. You simple have to add the “standby” flag to the
/etc/hostname.qfe4 file. More Details available in Technical Instruction < Solution: 217158 >.

2.  Production and test interfaces in different IP subnets
==========================================================

If you have not enough additional ip-addresses on hand for setting up
IPMP, you can configure the ipmp-test-interfaces in a different
ip-network than your production network (e.g. 192.168., 10. ..). But you
must make sure that there are enough test-partners (also in the new
test-network) who are responding to the ipmp-test-interfaces. You may
also configure a defaultrouter in the new test-network in case you have
an existing 100.1% reliable test-partner which should act as a single
test-partner. In such a configuration in.mpathd will only use its
test-subnet IP addresses as source address for outgoing probe packets.

Note: The in.mpathd only looks to the test subnet. Therefore if you
have no IP addresses available in the test subnet the IPMP
group will fail although if the production subnet is available.

2.1 With defaultrouter in production subnet and test subnet
———————————————————–

+————-+
|defaultrouter|
+——o——+
| p: 172.20.20.1
| t: 192.168.1.1
|
|           t: 192.168.1/24
===========+=+========================+==========================
| |                                    p: 172.20.20/24
p: 172.20.20.10  | |
t: 192.168.1.210 | | t: 192.168.1.220
+—o-o—+
|   IPMP  |
+———+

IPMP only use the defaultrouter as probe target. Each test interface of the
IPMP group send ICMP requests only to the defaultrouter. To get the
configuration IPMP looks to the routing table and is independent from
/etc/defaultrouter file. NO “all hosts” multicast (224.0.0.1) will be sent.

Advantages:
- Test interfaces don’t need IP addresses of the production subnet

Disadvantages:
- The interface of the defaultrouter has to reside in both the
production AND test subnet.
- Exceptional configuration of defaultrouter.
- All which are mentioned in section 1.1

2.2 With defaultrouter in production subnet net but without defaultrouter
in test subnet
—————————————————————————————-

+————-+      +———+       +———+
|defaultrouter|      |    T1   |  …  |    T5   |
+——o——+      +—-o—-+       +—-o—-+
| p:172.20.20.1    | p:172.20.20.110 | p:172.20.20.150
|                  | t:192.168.1.110 | t:192.168.1.150
|                  |                 |
|                  |                 |       t:192.168.1/24
============+=+=+==============+=================+=====================
| |                                        p:172.20.20/24
p:172.20.20.10   | |
t:192.168.1.210  | | t:192.168.1.220
+—o-o—+
|   IPMP  |
+———+

IPMP dynamically determines five arbitrary hosts in the test subnet via
“all hosts” multicast  address (224.0.0.1). At least you need one probe
target that IPMP will work. Beware that one probe target is not reliable
enough. If there are less than five targets available the in.mpathd sent
out the “all hosts” multicasts to get a complete list of five probe
targets.

Advantages:
- easiest configuration for IPMP if you have too less IP addresses
available in the production subnet.
- is very reliable due to the five targets.

Disadvantages:
- the probe targets must be available before you can setup the
IPMP host.
- more administrative work because you have to setup the probe
targets as an additional interface in the test subnet.
Recommendation: Setup an additional logical network interface on target host.
(e.g. add a new interface to /etc/hostname.qfe0 with the ‘addif’ option)
If your test partners are on systems which run also IPMP you must add an
logical network interface NOT flagged deprecated and NOT flagged nofailover.
An address associated with this interface will then be used as source address
by responding properly to “all hosts” multicast packets which are used for
the automatic IPMP test partner detection.
Beware that Solaris 8 does NOT require the additional logical network
interface in the test subnet on the target host. So, in case of an upgrade
from Solaris 8 to Solaris[TM] 9 or higher you have to change your configuration.
Please refer to 2.5 for a detailed example.

2.3 with dedicated hosts acting as test targets with “host-routes”
—————————————————————–

+————-+       +———+        +———+
|defaultrouter|       |    T1   |  ….  |    T5   |
+——o——+       +—-o—-+        +—-o—-+
!                   | p:172.20.20.110 | p:172.20.20.150
!                   | t:192.168.1.110 | t:192.168.1.150
!                   |                 |
!                   |                 |       t:192.168.1/24
=============+=+===============+=================+=====================
| |                                         p:172.20.20/24
p:172.20.20.10  | |
t:192.168.1.210 | | t:192.168.1.220
+—o-o—+
|   IPMP  |
+———+

Some “host routes” will be defined in the test subnet with a startscript in
/etc/rc2.d/S70ipmp.targets (The script is attached to this document.). When
IPMP refer to the routing table it will choose the first five defined “host
routes” as probe targets in the test subnet. This is due to the fact that
normally the “host routes” are before the defaultrouter in the routing
table. If you have less than five “host routes” also the defaultrouter
(when available in the test subnet) will be used as probe target as well.

Example:
- please look to the example of section 1.3

Advantages:
- test interfaces don’t need IP addresses of the production subnet
- all which are mentioned in section 1.3

Disadvantages:
- all which are mentioned in section 1.3
- all which are mentioned in section 2.2

2.4 Configuration examples for 2.1, 2.2 and 2.3
————————————————

/etc/hosts
———-
127.0.0.1        localhost
172.20.20.10     host10       loghost
192.168.1.210    host10-test-qfe0
192.168.1.220    host10-test-qfe4

/etc/hostname.qfe0
——————
host10 netmask + broadcast + group ipmp0 up \
addif host10-test-qfe0 deprecated -failover netmask + broadcast + up

/etc/hostname.qfe4
——————
host10-test-qfe4 deprecated -failover netmask + broadcast + group ipmp0 up

ifconfig output:
—————-
qfe0: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
inet 172.20.20.10 netmask ffffff00 broadcast 172.20.20.255
groupname ipmp0
ether 8:0:20:e8:88:dc
qfe0:1:
flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 3
inet 192.168.1.210 netmask ffffff00 broadcast 192.168.1.255
qfe4:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 4
inet 192.168.1.220 netmask ffffff00 broadcast 192.168.1.255
groupname ipmp0
ether 8:0:20:e8:89:34

Note: The example describe the setup of an active-active IPMP configuration
which is best practices. But you can also configure an active-standby
configuration. You simple have to add the “standby” flag to the
/etc/hostname.qfe4 file. More Details available in Technical Instruction < Solution: 217158 >.

2.5  Configuration example for 2.2 if you use IPMP on the test subnet
———————————————————————
/etc/hosts
———-
127.0.0.1        localhost
# IPMP active IP address:
172.20.20.10     host10       loghost
# IPMP test interface
192.168.1.210    host10-test-ce0
# additional active interface in the ‘test subnet’
# to be able to respond to probe packets from other
# IPMP setups (See 2.2). Will also failover.
192.168.1.211    host10-prod-ce0
# IPMP test interface
192.168.1.220    host10-test-ce1

/etc/hostname.ce0
—————–
172.20.20.10 netmask + broadcast + group ipmp0 up \
addif 192.168.1.211 netmask + broadcast + up \
addif 192.168.1.210 netmask + broadcast + deprecated -failover up

/etc/hostname.ce1
—————–
192.168.1.220 netmask + broadcast + group ipmp0 deprecated -failover up

ifconfig output:
—————-
ce0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 172.20.20.10 netmask ffffff00 broadcast 172.20.20.255
groupname ipmp0
ether 8:0:20:e2:da:d5
ce0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.1.211 netmask ffffff00 broadcast 192.168.1.255
ce0:2: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 192.168.1.210 netmask ffffff00 broadcast 192.168.1.255
ce1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 3
inet 192.168.1.220 netmask ffffff00 broadcast 192.168.1.255
groupname ipmp0
ether 8:0:20:e2:da:d6

A.
———– Begin of start script /etc/init.d/ipmp.targets ————–

#!/sbin/sh
# /etc/rc2.d/S70ipmp.targets /etc/init.d/ipmp.targets
# Copyright (c) 2005 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident  “@(#)ipmp.targets      1.0.0
#
# Edit the following IPMP test  TARGETS to suit your needs.
# To install:
# 1) cp ipmp.targets /etc/init.d
# 2) perform edits on the scri pt as required (e.g: add TARGETS)
# 3) chmod 744 /etc/init.d/ipmp.targets
# 4) chown root:sys /etc/init.d/ipmp.targets
# 5) ln /etc/init.d/ipmp.targets /etc/rc2.d/S70ipmp.targets
#
TARGETS=”192.168.85.117 192.168.85.127 192.168.85.137″

case “$1″ in
‘start’)
/usr/bin/echo “Adding static routes for use as IPMP targets”
for target in $TARGETS; do
/usr/sbin/route add -host $target $target
done
;;
‘stop’)
/usr/bin/echo “Removing static routes for use as IPMP targets”
for target in $TARGETS; do
/usr/sbin/route delete -host $target $target
done
;;
esac
———– End of start script /etc/init.d/ipmp.targets ————–

	$ uname -a
	SunOS mysunserver 5.10 Generic_125100-06 sun4v sparc SUNW,Sun-Fire-T1000 Solaris
	$

	Solaris 10 uses the SunOS 5.10 kernel, Solaris 9 uses the SunOS 5.9 kernel...

	$ cat /etc/release 
	                       Solaris 10 11/06 s10s_u3wos_10 SPARC
	           Copyright 2006 Sun Microsystems, Inc.  All Rights Reserved.
	                        Use is subject to license terms.
	                           Assembled 14 November 2006
	$ 
And to check the Solaris build

        $ showrev
	Hostname: mysunserver
	Hostid: 848233a4
	Release: 5.10
	Kernel architecture: sun4v
	Application architecture: sparc
	Hardware provider: Sun_Microsystems
	Domain:
	Kernel version: SunOS 5.10 Generic_125100-06
	$ 

	Kernel architectures:
		sun4c (MicroSPARC)
		sun4d
		sun4m (SuperSparc)
		sun4u (UltraSPARC) (~1995)
		sun4v (USIIIi) (~2002)
	(Solaris 10 only support sun4u and later)

First, we should learn about some tools to help us monitor system performance. SAR (the system activity reporter) is the time-honored (and very cryptic) standard UNIX performance monitoring tool. How do we use SAR to see what the Sun server has been doing?

SAR collects data on the state of the system using a program called “sadc” (the system activity data collector), which is usually launched from two standardized shell scripts (called sa1 and sa2) that can be launched from “cron” as frequently as you want to collect performance data by adding a few lines to your crontab with:

	mysunserver# crontab -e

Now add these lines..

	# Starting at 8am collect system activity records
	# every 20 minutes for 12 hours
	# 20 minutes = 1200 seconds
	# 12 hours with 3 samples each hour = 36 loops
	0 8 * * 1-5 /usr/lib/sa/sa1 1200 36

	# After the 12 hour period,
	# collect a system activity report
	30 20 * * 1-5 /usr/lib/sa/sa2 -A

After a full day of systems monitoring, we can use “sar” to extract the collected data:

	root@mysunserver:~$ sar

	SunOS mysunserver 5.10 Generic_125100-06 sun4v    07/25/2007

	23:00:01    %usr    %sys    %wio   %idle
	23:20:00       0       0       0     100
	23:40:00       0       0       0     100
	00:00:00       0       0       0     100
	00:20:00       0       0       0     100
	00:40:02       0       1       0      99
	01:00:01       0       2       0      98
	01:20:05       0       2       0      98
	   .
	   .
	   .

In the default SAR display, we see, at every sample interval, how the computer was spending it’s time.

Each of the four columns shows how the CPU’s time was being divided:

• %usr: running UNIX processes (“user time”)
• %sys: processing kernel system calls on behalf of processes (“system time”)
• %wio: sitting around waiting to read/write data (to disks or network devices), as demanded by processes (“waiting for I/O”)
• %idle: just plain doing nothing as there were no processes that demanded the CPU’s time (“idle”).

NOTE: These statistics are not quite the same as the system “load average”, which, precisely defined, is the AVERAGE number of PROCESSES that are in the process table which are WAITING for the CPU to be able to service them. In theoretical terms, the “load average” resembles a percentage of processor utilization that can exceed 100% when the system is overutilized (load avg. > 1.00) or fall below 100% when the CPU is not fully utilized (load avg. < 1.00). Theoretically, a system that sustained a load average utilization of 0.50 would operate with the same apparent performance if the CPU ran at half the clock-speed.

If may be best to think of load average as CPU demand, and to think of the SAR statistics as actual CPU utilization.

If SAR reports the CPU is more than 10% idle, then your system is probably not being held back by a slow processor or slow storage devices. The culprit may just be inefficiently-written software, which fails to optimize for the particular platform which it runs on.

Time spent by the system waiting for I/O (%wio) is one of the most important to attack. This “wasted” time is sometimes called a “wait state”. As those I/O processes are necessary, it is only “wasteful” because the CPU just sits around doing nothing until the disk has had a chance to fetch the requested data, or upload the data, or do whatever other I/O activity which was requested by the UNIX process.