Wednesday, January 18, 2012

Dtrace -powerful tracing and analysis tool

DTrace Introduction

DTrace is Solaris 10's new Dynamic Tracing facility. It allows us to peer into the innards of running processes and customize our view to exclude extraneous information and close in on the source of a problem.
DTrace also has capabilities that allow us to examine a crash dump or trace the boot process.
A number of freely available scripts have been made available as the DTrace Toolkit. The toolkit provides both programming examples and also extremely useful tools for different types of system monitoring.
The DTrace facility provides data to a number of consumers, including commands such as dtrace and lockstat, as well as programs calling libraries that access DTrace through the dtrace kernel driver.

Probes

DTrace is built on a foundation of objects called probes. Probes are event handlers that fire when their particular event occurs. DTrace can bind a particular action to the probe to make use of the information.
Probes report on a variety of information about their event. For example, a probe for a kernel function may report on arguments, global variables, timestamps, stack traces, currently running processes or the thread that called the function.
Kernel modules that enable probes are packaged into sets known as providers. In a DTrace context, a module is a kernel module (for kernel probes) or a library name (for applications). A function in DTrace refers to the function associated with a probe, if it belongs to a program location.
Probes may be uniquely addressed by a combination of the provider, module, function and name. These are frequently organized into a 4-tuple when invoked by the dtrace command.
Alternatively, each probe has a unique integer identifier, which can vary depending on Solaris patch level.
These numbers, as well as the provider, module, function and name, can be listed out through the dtrace -l command. The list will vary from system to system, depending on what is installed. Probes can be listed by function, module or name by specifying it with the -f, -m or -n options, respectively.
Running a dtrace without a -l, but with a -f, -m or -n option, enables all matching probes. All the probes in a provider can be enabled by using the -P option. An individual probe can be enabled by using its 4-tuple with the -n option.
(Note: Do not enable more probes than necessary. If too many probes are enabled, it may adversely impact performance. This is particularly true of sched probes.)
Some probes do not list a module or function. These are called "unanchored" probes. Their 4-tuple just omits the nonexistent information.

Providers

Providers are kernel modules that create related groups of probes. The most commonly referenced providers are:
  • fbt: (Function Boundary Tracing) Implements probes at the entry and return points of almost all kernel functions.
  • io: Implements probes for I/O-related events.
  • pid: Implements probes for user-level processes at entry, return and instruction.
  • proc: Implements probes for process creation and life-cycle events.
  • profile: Implements timer-driven probes.
  • sched: Implements probes for scheduling-related events.
  • sdt: (Statistically Defined Tracing) Implements programmer-defined probes at arbitrary locations and names within code. Obviously, the programmer should define names whose meaning is intuitively clear.
  • syscall: Implements entry and return probes for all system calls.
  • sysinfo: Probes for updates to the sys kstat.
  • vminfo: Probes for updates to the vm kstat.

Command Components

The dtrace command has several components:
  • A 4-tuple identifier:provider:module :function:name
    Leaving any of these blank is equivalent to using a wildcard match. (If left blank, the left-most members of the 4-tuple are optional.)
  • A predicate determines whether the action should be taken. They are enclosed in slashes: /predicate/. The predicate is a C-style relational expression which must evaluate to an integer or pointer. If omitted, the action is executed when the probe fires. Some predicate examples are:
    • executable name matches csh:/execname == "csh"/
    • process ID does not match 1234:/pid != 1234/
    • arg0 is 1 and arg1 is not 0:/arg0 == 1 && arg1 !=0/
  • An action (in the D scripting language) to be taken when the probe fires and the predicate is satisfied. Typically, this is listed in curly brackets: {}
Several command examples are provided at the bottom of the page.

D Scripting Language

In order to deal with operations that can become confusing on a single command line, a D script can be saved to a file and run as desired. A D script will have one or more probe clauses, which consist of one or more probe-descriptions, along with the associated predicates and actions:
#!/usr/sbin/dtrace -sprobe-description[, probe-description...]/predicate/
{
action; [action; ...]}
The probe-description section consists of one or more 4-tuple identifiers. If the predicate line is not present, it is the same as a predicate that is always true. The action(s) specified are to be run if the probe fires and the predicate is true.
Each recording action dumps data to a trace buffer. By default, this is the principal buffer.
Several programming examples are provided at the bottom of the page.

D Variables

D specifies both associative arrays and scalar variables. Storage for these variables is not pre-allocated. It is allocated when a non-zero value is assigned and deallocated when a zero value is assigned.
D defines several built-in variables, which are frequently used in creating predicates and actions. The most commonly used built-in variables for D are the following:
  • args[]: The args[] array contains the arguments, specified from 0 to the number of arguments less one. These can also be specified by argn, where this is the n+1th argument.
  • curpsinfo: psinfo structure of current process.
  • curthread: pointer to the current thread's kthread_t
  • execname: Current executable name
  • pid: Current process ID
  • ppid: Parent process ID
  • probefunc: function name of the current probe
  • probemod: module name of the current probe
  • probename: name of the current probe
  • timestamp: Time since boot in ns
Listing Probes
You can list all DTrace probes by passing the
-l option to the dtrace command:#

To count all the probes that are available on your system, you can type the following command:

#
dtrace -l | wc -l
dtrace -l

Sunday, January 8, 2012

Solaris 11 IPS configuration

Oracle Solaris 11 has been released and coming up as the first cloud OS, Oracle Solaris 11 coming with more features and enhancements. One of it is IPS (Image Packing Systems) this the new way you manage the software patches and packages, IPS make you easy to manage package and patches.




Why you configure Local IPS?

1. Performance (more speed from local network)

2. Security (you don’t want your client to connect to internet)

3. Replication (You want manage the repository, and to make your installation today is exactly the same for the installation next Year)



Prerequisite :

1. Install Oracle Solaris 11

2. 2 DVD ISO repository : https://edelivery.oracle.com



you need to unzip the iso, below the tow iso repository look like :





view source

print?

1 rachmat@solaris:~$ ls -l *iso

2 -rw-r--r-- 1 rachmat staff 3537872896 Nov 13 06:53 V28915-01.iso

3 -rw-r--r-- 1 rachmat staff 3403360256 Nov 13 14:52 V28916-01.iso



3. Create Zpool for IPS Repository (it’s optional, but I create Zpool specially for holding the repository)


01 root@solaris:~# format

02 Searching for disks...done

03

04 AVAILABLE DISK SELECTIONS:

05 0. c3t0d0

06 /pci@0,0/pci8086,2829@d/disk@0,0

07 1. c3t2d0

08 /pci@0,0/pci8086,2829@d/disk@2,0

09 Specify disk (enter its number): ^D

10

11 root@solaris:~# zpool create ipspool c3t2d0

12 root@solaris:~# zfs create ipspool/ips

13

14 -optional :

15 root@solaris:~# zfs set atime=off ipspool/ips

16 root@solaris:~# zfs set compression=on ipspool/ips



set a time to off for better performance, it’s optional.



4. Mount the first repository iso and rsync it, after finished umount it :




1 root@solaris:~# lofiadm -a /export/home/rachmat/V28915-01.iso /dev/lofi/1

2 root@solaris:~# mount -F hsfs /dev/lofi/1 /mnt

3 root@solaris:~# ls /mnt/

4 COPYRIGHT NOTICES README repo

5

6 root@solaris:~# rsync -aP /mnt/repo /ipspool/ips

7 root@solaris:~# umount /mnt

8 root@solaris:~# lofiadm -d /dev/lofi/1



5. Mount the second repository iso and rsync it, after finished umount it :



1 root@solaris:~# lofiadm -a /export/home/rachmat/V28916-01.iso /dev/lofi/1

2 root@solaris:~# mount -F hsfs /dev/lofi/1 /mnt

3 root@solaris:~# ls /mnt/

4 COPYRIGHT NOTICES README repo

5

6 root@solaris:~# rsync -aP /mnt/repo /ipspool/ips

7 root@solaris:~# umount /mnt

8 root@solaris:~# lofiadm -d /dev/lofi/1



6. set the repository to your repository folder, in this case /ipspool/ips/repo



1 root@solaris:~# svccfg -s application/pkg/server setprop pkg/inst_root=/ipspool/ips/repo



7. Set the readonly to true :



1 root@solaris:~# svccfg -s application/pkg/server setprop pkg/readonly=true



8. Enable and refresh pkg serer :




1 root@solaris:~# svcadm refresh application/pkg/server

2 root@solaris:~# svcadm enable application/pkg/server



9. setting up the client, to use only this repository




1 root@solaris:~# pkg set-publisher -G '*' -g solaris



Where the origin is your repository server domain / ip address



view source

print?

1 root@solaris:~# pkg set-publisher -G '*' -g http://10.0.7.1 solaris



10. Verify and testing :



01 root@solaris:~# pkg publisher

02 PUBLISHER TYPE STATUS URI

03 solaris origin online http://10.0.7.1/

04

05 root@solaris:~# pkg install nmap

06 Packages to install: 2

07 Create boot environment: No

08 Create backup boot environment: No

09 Services to change: 1

10

11 DOWNLOAD PKGS FILES XFER (MB)

12 Completed 2/2 454/454 3.1/3.1

13

14 PHASE ACTIONS

15 Install Phase 538/538

16

17 PHASE ITEMS

18 Package State Update Phase 2/2

19 Image State Update Phase 2/2



Note : See the README file of repository for the complete options.