Dtrace Notes - Quick Refernce

These are notes from the Dtrace Guide. they are not intended to be a replacement of the Dtrace Guide, but rather are based on the content of the guide and listed here just as quick reference.




Probes are specified as:
provider:module:function:name

Predicates provide flow control. Predicate expressions go in between pair of "/" after the probe name. It is evaluated before executing the statement clause following the firing of the probe. The statement clause is executed only if the predicate expression evaluates to "true"/non-zero.

Example : -

#pragma D option flowindent
syscall:::entry,
syscall:::return
/pid == $1/
/* or alternately use /execname == "my_program_name"/ */
{
}


Predefined DTrace Variable Names:
==========================
errno - current errno value for syscalls
execname
pid
tid
probeprov
probemod
probefunc
probename


Arrays
=====
D "associative arrays" can be indexed by a list of one or more values of any types.


External Symbols
============
Since DTrace instrumentation executes inside the Solaris kernel, so in addition to being able to access special DTrace variables and probe arguments, kernel data structures, symbols and types can also be accessed. D uses the backquote character (`) as a special scoping operator for accessing symbols that are defined in the OS and not in the D program.


- Types and Operators are same as C


- Conditional Expressions:
D does not provide if-then-else constructs. However, it does provide simple conditional expressions using the ? and : operators. As with any other D operator multiple ?: operators can be used in a single expression e.g.

- Variables:

Scalar Variables:
Scalar variables are created automatically the first time value to previously undefined identifier in a D program. They are global by default. Unlike ANSI-C declarations, D variable declarations may not assign initial values. You must use a BEGIN probe clause to assign any initial values. All global variable storage is filled with zeroes by DTrace before you first reference the variable.


Thread-Local Variables:
Thread-local variables are useful in situations where you want to enable a probe and mark every thread that fires the probe with some tag or other data. Thread-local variables are referenced by applying the -> operator to the special identifier "self":
syscall::read:entry
{
self->read = 1;
}

Clause-Local Variables:
Clause-local variables are similar to automatic variables in a C, C++, or Java language. These variables can be referenced and assigned by applying the -> operator to the special identifier
"this". Clause-local variables are the only D variables that are not initially filled with zeroes. Note that if your program contains multiple clauses for a single probe, any clause-local variables.



DTrace Built-in Variables:

Type and Name Description
int64_t arg0, ..., arg9 The first ten input arguments to a probe
represented as raw 64-bit integers. If fewer
than ten arguments are passed to the current
probe, the remaining variables return zero.

args[] The typed arguments to the current probe, if
any. The args[] array is accessed using an
integer index, but each element is defined to
be the type corresponding to the given probe
argument.

uintptr_t caller The program counter location of the current
thread just before entering the current probe.

chipid_t chip The CPU chip identifier for the current
physical chip. See Chapter 26 for more
information.

processorid_t cpu The CPU identifier for the current CPU.

cpuinfo_t *curcpu The CPU information for the current CPU.

lwpsinfo_t *curlwpsinfo The lightweight process (LWP) state of the
LWP associated with the current thread. This
structure is described in further detail in
theproc(4) man page.

psinfo_t *curpsinfo The process state of the process associated
with the current thread. This structure is
described in further detail in the proc(4) man
page.

kthread_t *curthread The address of the operating system kernel’s
internal data structure for the current thread,
the kthread_t. The kthread_t is defined in
. Refer to Solaris Internals
for more information on this variable and
other operating system data structures.

string cwd The name of the current working directory of
the process associated with the current thread.

uint_t epid The enabled probe ID (EPID) for the current
probe. This integer uniquely identifies a
particular probe that is enabled with a specific
predicate and set of actions.

int errno The error value returned by the last system
call executed by this thread.

string execname The name that was passed to exec(2) to
execute the current process.

gid_t gid The real group ID of the current process.

uint_t id The probe ID for the current probe. This ID is
the system-wide unique identifier for the
probe as published by DTrace and listed in the
output of dtrace -l.

uint_t ipl The interrupt priority level (IPL) on the
current CPU at probe firing time. Refer to
Solaris Internals for more information on
interrupt levels and interrupt handling in the
Solaris operating system kernel.

lgrp_id_t lgrp The latency group ID for the latency group of
which the current CPU is a member.

pid_t pid The process ID of the current process.

pid_t ppid The parent process ID of the current process.

string probefunc The function name portion of the current
probe’s description.

string probemod The module name portion of the current
probe’s description.

string probename The name portion of the current probe’s
description.

string probeprov The provider name portion of the current
probe’s description.

psetid_t pset The processor set ID for the processor set
containing the current CPU.

string root The name of the root directory of the process
associated with the current thread.

uint_t stackdepth The current thread’s stack frame depth at
probe firing time.

id_t tid The thread ID of the current thread. For
threads associated with user processes, this
value is equal to the result of a call to
pthread_self(3C).

uint64_t timestamp The current value of a nanosecond timestamp
counter. This counter increments from an
arbitrary point in the past and should only be
used for relative computations.

uid_t uid The real user ID of the current process.

uint64_t uregs[] The current thread’s saved user-mode register
values at probe firing time.

uint64_t vtimestamp The current value of a nanosecond timestamp
counter that is virtualized to the amount of
time that the current thread has been running
on a CPU, minus the time spent in DTrace
predicates and actions. This counter
increments from an arbitrary point in the past
and should only be used for relative time
computations.

uint64_t walltimestamp The current number of nanoseconds since
00:00 Universal Coordinated Time, January 1,
1970.


External Variables:
D uses the backquote character (‘) as a special scoping operator for accessing
variables that are defined in the operating system.

Because the Solaris kernel supports dynamically loaded
modules with separate symbol namespaces, the same variable name might be used
more than once in the active operating system kernel. You can resolve these name
conflicts by specifying the name of the kernel module whose variable should be
accessed prior to the backquote in the symbol name. For example, each loadable
kernel module typically provides a _fini(9E) function, so to refer to the address of
the _fini function provided by a kernel module named foo, you would write:
foo‘_fini


Probe Name Pattern Matching Characters:

Symbol Description

* Matches any string, including the null string.

? Matches any single character.

[ ... ] Matches any one of the enclosed characters.
A pair of characters separated by - matches
any character between the pair, inclusive. If
the first character after the [ is !, any
character not enclosed in the set is matched.

\ Interpret the next character as itself,
without any special meaning.


Use of the C Preprocessor :

You can use the C preprocessor in conjunction with your D
programs by specifying the dtrace -C option. This option causes dtrace to first
execute the cpp(1) preprocessor on your program source file and then pass the results
to the D compiler.



Pointers and Address Spaces:

DTrace executes your D programs within the address space of the operating system kernel itself.

For example, if you use the syscall provider to instrument entry to a system call
that takes a pointer to an integer or array of integers as an argument (for example,
pipe(2)), it would not be valid to dereference that pointer or array using the * or []
operators because the address in question is an address in the address space of the
user process that performed the system call.

To access user process memory from a DTrace probe, you must apply one of the
copyin(), copyinstr(), or copyinto() functions described in Chapter 10 to the
user address space pointer.


Aggregations
=========

The syntax for an aggregation is:
@name[ keys ] = aggfunc ( args );

The dtrace command prints aggregation results by default when the process
terminates, either as the result of an explicit END action or when the user presses
Control-C.


DTrace aggregating functions are:

Function Name Arguments Result

count none The number of times called.
sum scalar expression The total value of the specified expressions.
avg scalar expression The arithmetic average of the specified expressions.
min scalar expression The smallest value among the specified expressions.
max scalar expression The largest value among the specified expressions.
lquantize scalar expression, A linear frequency distribution, sized by the specified
lower bound, range, of the values of the specified expressions.
upper bound, step Increments the value in the highest bucket that is less
value than the specified expression.

quantize scalar expression A power-of-two frequency distribution of the values of
the specified expressions. Increments the value in the
highest power-of-two bucket that is less than the
specified expression.

The example below averages the wall clock time spent
in the "write" system call by various processes/executables:

syscall::write:entry
{
self->ts = timestamp;
}
syscall::write:return
/self->ts/
{
@time[execname] = avg(timestamp - self->ts);
self->ts = 0;
}


Printing Aggregations:
By default, multiple aggregations are displayed in the order they are introduced in the
D program. You can override this behavior using the printa() function to print the
aggregations.

Data Normalization:
The parameters to normalize() are an aggregation and a normalization
factor. The output of the aggregation shows each value divided by the normalization
factor. denormalize() takes only an aggregation.
Adding the denormalize action can be used to get both raw system call
counts and per-second rates:
#pragma D option quiet
BEGIN
{
start = timestamp;
}
syscall:::entry
{
@func[execname] = count();
}
END
{
this->seconds = (timestamp - start) / 1000000000;
printf("Ran for %d seconds.\n", this->seconds);
printf("Per-second rate:\n");
normalize(@func, this->seconds);
printa(@func);
printf("\nRaw counts:\n");
denormalize(@func);
printa(@func);
}


Clearing Aggregations:
The clear() function takes an aggregation as its only
parameter. The clear() function clears only the aggregation’s
values; the aggregation’s keys are retained.

Truncating aggregations:
When looking at aggregation results, you often care only about the top several results. The parameters to trunc() are an aggregation and an optional truncation value.
Without the truncation value, trunc() discards both aggregation values and
aggregation keys for the entire aggregation. When a truncation value n is present,
trunc() discards aggregation values and keys except for those values and keys
associated with the highest n values. That is, trunc(@foo, 10) truncates the
aggregation named foo after the top ten values, where trunc(@foo) discards the
entire aggregation. The entire aggregation is also discarded if 0 is specified as the
truncation value.
To see the bottom n values instead of the top n, specify a negative truncation value to
trunc(). For example, trunc(@foo, -10) truncates the aggregation named foo
after the bottom ten values.



Actions And Subroutines:
==================

Default Action:
If a clause is left empty, the default action is taken. The default action is to trace the enabled probe identifier (EPID) to the principal buffer.


Data Recording Actions:

void trace(expression)
- traces the result to the directed buffer.

void tracemem(address, size_t nbytes)
- copies the memory from the address specified by addr into the directed buffer for the length specified by nbytes.


void printf(string format, ...)
- traces D expressions


void printa(aggregation)
void printa(string format, aggregation)
-


void stack(int nframes)
void stack(void)
- The stack() action records a kernel stack trace to the directed buffer. The kernel
stack will be nframes in depth. If nframes is not provided, the number of stack frames
recorded is the number specified by the stackframes option.
- The stack() action is a little different from other actions in that it may also be used
as the key to an aggregation. e.g.
# dtrace -n kmem_alloc:entry’{@[stack()] = count()}’


void ustack(int nframes, int strsize)
void ustack(int nframes)
void ustack(void)
- The ustack() action records a user stack trace to the directed buffer. While ustack() is
able to determine the address of the calling frames when the probe fires, the stack
frames will not be translated into symbols until the ustack() action is processed at
user-level by the DTrace consumer. If strsize is specified and non-zero, ustack() will
allocate the specified amount of string space, and use it to perform address-to-symbol
translation directly from the kernel. This direct user symbol translation is currently
available only for Java virtual machines, version 1.5 and higher. Java
address-to-symbol translation annotates user stacks that contain Java frames with the
Java class and method name.


void jstack(int nframes, int strsize)
void jstack(int nframes)
void jstack(void)
- jstack() is an alias for ustack() that uses the jstackframes option for the
number of stack frames the value specified by , and for the string space size the value
specified by the jstackstrsize option.



Destructive Actions:
When using dtrace(1M), you can enable destructive actions using the -w option.

void stop(void)
- The stop() action forces the process that fires the enabled probe to stop when it next
leaves the kernel, as if stopped by a proc(4) action. The prun(1) utility may be used
to resume a process that has been stopped by the stop() action.


void raise(int signal)
- The raise() action sends the specified signal to the currently running process.

void copyout(void *buf, uintptr_t addr, size_t nbytes)
- The copyout() action copies nbytes from the buffer specified by buf to the address
specified by addr in the address space of the process associated with the current
thread. If the user-space address does not correspond to a valid, faulted-in page in the
current address space, an error will be generated.

void copyoutstr(string str, uintptr_t addr, size_t maxlen)
- The copyoutstr() action copies the string specified by str to the address specified
by addr in the address space of the process associated with the current thread.

void system(string program, ...)
- The system() action causes the program specified by program to be executed as if it
were given to the shell as input. The program string may contain any of the
printf()/printa() format conversions.


#pragma D option destructive
#pragma D option quiet
proc:::signal-send
/args[2] == SIGINT/
{
printf("SIGINT sent to %s by ", args[1]->pr_fname);
system("getent passwd %d | cut -d: -f5", uid);
}
Running the above script results in output similar to the following example:
# ./whosend.d
SIGINT sent to MozillaFirebird- by Bryan Cantrill
SIGINT sent to run-mozilla.sh by Bryan Cantrill
^C
SIGINT sent to dtrace by Bryan Cantrill
The execution of the specified command does not occur in the context of the firing
probe ? it occurs when the buffer containing the details of the system() action are
processed at user-level.



Kernel Destructive Actions:

void breakpoint(void)
- The breakpoint() action induces a kernel breakpoint, causing the system to stop
and transfer control to the kernel debugger.
- A mistake with the breakpoint() action may cause it to be called far more often
than intended. This behavior might in turn prevent you from even terminating the
DTrace consumer that is triggering the breakpoint actions. In this situation, set the
kernel integer variable dtrace_destructive_disallow to 1.

If using the OpenBoot PROM on a SPARC system,
use w!:
ok 1 dtrace_destructive_disallow w!
ok
Confirm that the variable has been set using w?:
ok dtrace_destructive_disallow w?
1
ok


If using kmdb(1) on x86 or SPARC systems, use the 4–byte write modifier (W) with the
/ formatting dcmd:
kmdb[0]: dtrace_destructive_disallow/W 1
dtrace_destructive_disallow: 0x0 = 0x1
kmdb[0]:
Continue using :c:
kadb[0]: :c



void panic(void)
- The panic() action causes a kernel panic when triggered.


void chill(int nanoseconds)
- The chill() action causes DTrace to spin for the specified number of nanoseconds.
chill() is primarily useful for exploring problems that might be timing related.



Subroutines:

Subroutines differ from actions because they generally only affect internal DTrace
state. Therefore, there are no destructive subroutines, and subroutines never trace data
into buffers.


void *alloca(size_t size)
- alloca() allocates size bytes out of scratch space, and returns a 8–byte aligned pointer
to the allocated memory. Scratch space is only valid for the duration of a clause and
will be deallocated when the clause completes.


string basename(char *str)
- This subroutine creates a string that consists of a copy of the specified string, but without any prefix that ends in /. The returned string is allocated out of scratch memory, and is therefore valid only for the duration of the clause.


void bcopy(void *src, void *dest, size_t size)
- bcopy() copies size bytes from the memory pointed to by src to the memory pointed
to by dest. All of the source memory must lie outside of scratch memory and all of the
destination memory must lie within it.


void *copyin(uintptr_t addr, size_t size)
- copyin() copies the specified size in bytes from the specified user address into a
DTrace scratch buffer, and returns the address of this buffer. The user address is
interpreted as an address in the space of the process associated with the current
thread.


string copyinstr(uintptr_t addr)
- copyinstr() copies a null-terminated C string from the specified user address into a
DTrace scratch buffer, and returns the address of this buffer.


void copyinto(uintptr_t addr, size_t size, void *dest)
- copyinto()copies the specified size in bytes from the specified user address into the
DTrace scratch buffer specified by dest.


string strjoin(char *str1, char *str2)
- strjoin() creates a string that consists of str1 concatenated with str2. The returned
string is allocated out of scratch memory

size_t strlen(string str)
- strlen() returns the length of the specified string in bytes, excluding the
terminating null byte.


{See more kernel related sub-routines in d-trace guide}





Buffers and Buffering
================

ring Policy:
The DTrace ring buffer policy helps you trace the events leading up to a failure. If
reproducing the failure takes hours or days, you might wish to keep only the most
recent data. Once a principal buffer has filled, tracing wraps around to the first entry,
thereby overwriting older tracing data. You establish the ring buffer by setting the
bufpolicy option to the string ring:
# dtrace -s foo.d -x bufpolicy=ring

When used to create a ring buffer, dtrace(1M) will not display any output until the
process is terminated. At that time, the ring buffer is consumed and processed.
dtrace processes each ring buffer in CPU order. Within a CPU’s buffer, trace records
will be displayed in order from oldest to youngest. No ordering exists between records
from different CPUs. If such an ordering is required, you should trace the timestamp
variable as part of your tracing request.
The following example demonstrates the use of a #pragma option directive to
enable ring buffering:
#pragma D option bufpolicy=ring
#pragma D option bufsize=16k
syscall:::entry
/execname == $$1/
{
trace(timestamp);
}
syscall::rexit:entry
{
exit(0);
}




Speculative Tracing
==============

Speculative tracing provides the ability to tentatively trace data and then later decide whether to commit the data to a tracing buffer or discard it.

Function Name Args Description
============= ==== ===========
speculation None Returns an identifier for a new speculative buffer
speculate ID Denotes that the remainder of the clause should be traced to the
speculative buffer specified by ID
commit ID Commits the speculative buffer associated with ID
discard ID Discards the speculative buffer associated with ID


The number of speculative buffers defaults to one, but may be optionally tuned higher.
See “Speculation Options and Tuning” on page 170 for more information.

To use a speculation, an identifier returned from speculation() must be passed to
the speculate() function in a clause before any data-recording actions. All
subsequent data-recording actions in a clause containing a speculate() will be
speculatively traced. Clauses may contain speculative tracing or non-speculative tracing requests, but not both.

Aggregating actions, destructive actions, and the exit action may never be
speculative.

Typically, you assign the result of speculation() to a thread-local variable and then
use that variable as a subsequent predicate to other probes as well as an argument to
speculate().

You commit speculations using the commit() function. When a speculative buffer is
committed, its data is copied into the principal buffer. If there is more data in the
specified speculative buffer than there is available space in the principal buffer, no data
is copied and the drop count for the buffer is incremented. If the buffer has been
speculatively traced to on more than one CPU, the speculative data on the committing
CPU is copied immediately, while speculative data on other CPUs is copied some time
after the commit().

A clause containing a commit() cannot contain a data recording action, but a clause may contain multiple commit() calls to commit disjoint buffers.

You discard speculations using the discard() function. When a speculative buffer is
discarded, its contents are thrown away


Example below shows the entire code path under the open(2) system call only when the
open() fails:

specopen.d: Code Flow for Failed open(2)
#!/usr/sbin/dtrace -Fs
syscall::open:entry,
syscall::open64:entry
{
/*
* The call to speculation() creates a new speculation. If this fails,
* dtrace(1M) will generate an error message indicating the reason for
* the failed speculation(), but subsequent speculative tracing will be
* silently discarded.
*/
self->spec = speculation();
speculate(self->spec);
/*
* Because this printf() follows the speculate(), it is being
* speculatively traced; it will only appear in the data buffer if the
* speculation is subsequently commited.
*/
printf("%s", stringof(copyinstr(arg0)));
}
fbt:::
/self->spec/
{
/*
* A speculate() with no other actions speculates the default action:
* tracing the EPID.
*/
speculate(self->spec);
}
syscall::open:return,
syscall::open64:return
/self->spec/
{
/*
* To balance the output with the -F option, we want to be sure that
* every entry has a matching return. Because we speculated the
* open entry above, we want to also speculate the open return.
* This is also a convenient time to trace the errno value.
*/
speculate(self->spec);
trace(errno);
}
syscall::open:return,
syscall::open64:return
/self->spec && errno != 0/
{
/*
* If errno is non-zero, we want to commit the speculation.
*/
commit(self->spec);
self->spec = 0;
}
syscall::open:return,
syscall::open64:return
/self->spec && errno == 0/
{
/*
* If errno is not set, we discard the speculation.
*/
discard(self->spec);
self->spec = 0;
}



Scripting
======
An interpreter file begins with a line of the form:
#! pathname [arg]

i.e.
#!/usr/sbin/dtrace -s

Macro Variables:

Name Description Reference
$[0-9]+ macro arguments
$egid effective group-ID getegid(2)
$euid effective user-ID geteuid(2)
$gid real group-ID getgid(2)
$pid process ID getpid(2)
$pgid process group ID getpgid(2)
$ppid parent process ID getppid(2)
$projid project ID getprojid(2)
$sid session ID getsid(2)
$target target process ID
$taskid task ID gettaskid(2)
$uid real user-ID getuid(2)


Using $target:
syscall:::entry
/pid == $target/
{
@[probefunc] = count();
}
To determine the number of system calls executed by the date(1) command, execute the following command:
# dtrace -s syscall.d -c date

posted by Amandeep 1/18/2010 10:38:00 PM | PERMALINK

How to Install Cisco vpnClient on Debian

As the heading suggests this blog explains the how to install Cisco VPN client from source (rather than package) on Debian. It is assumed that you already have the cisco-vpnclient source. If so, just follow the steps below :

1. 'vpnclient' requires kernel-sources. To install the correct kernel sources first identify the kernel you are running :



aman@asingh:~$ uname -r
2.6.26-2-686
aman@asingh:~$


2. I had to find kernel-sources by running "apt-cache search linux-source*" :


asingh:/usr/src# apt-cache search linux-source*
linux-patch-debian-2.6.26 - Debian patches to version 2.6.26 of the Linux kernel
linux-source-2.6.26 - Linux kernel source for version 2.6.26 with Debian patches
linux-tree-2.6.26 - Linux kernel source tree for building Debian kernel images


Next install the sources using apt-get :


asingh:/usr/src# apt-get install linux-source-2.6.26
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
make
Suggested packages:
libncurses-dev ncurses-dev kernel-package libqt3-mt-dev make-doc
The following NEW packages will be installed:
linux-source-2.6.26 make
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
......


3. Now cd into the vpnclient and run ./vpn_install. Keep hitting "enter" to keep the default values :


asingh:/opt/vpnclient# ./vpn_install
Cisco Systems VPN Client Version 4.8.02 (0030) Linux Installer
Copyright (C) 1998-2006 Cisco Systems, Inc. All Rights Reserved.

By installing this product you agree that you have read the
license.txt file (The VPN Client license) and will comply with
its terms.


Directory where binaries will be installed [/usr/local/bin]

Automatically start the VPN service at boot time [yes]

In order to build the VPN kernel module, you must have the
kernel headers for the version of the kernel you are running.

For RedHat 6.x users these files are installed in /usr/src/linux by default
For RedHat 7.x users these files are installed in /usr/src/linux-2.4 by default
For Suse 7.3 users these files are installed in /usr/src/linux-2.4.10.SuSE by default

Directory containing linux kernel source code []

* Binaries will be installed in "/usr/local/bin".
* Modules will be installed in "/lib/modules/2.6.26-2-686/CiscoVPN".
* The VPN service will be started AUTOMATICALLY at boot time.
* Kernel source from "" will be used to build the module.

Is the above correct [y]

Shutting down /opt/cisco-vpnclient/bin/vpnclient: Done
Stopped: /etc/init.d/vpnclient_init (VPN init script)
Making module
./driver_build.sh
Cisco Systems VPN Client Version BUILDVER_STRING
Copyright (C) 1998-2001 Cisco Systems, Inc. All Rights Reserved.

usage:
./driver_build.sh 'kernel_src_dir'

'kernel_src_dir' is the directory containing the linux kernel sour
ce

Copying module to directory "/lib/modules/2.6.26-2-686/CiscoVPN".
Already have group 'bin'

Creating start/stop script "/etc/init.d/vpnclient_init".
/etc/init.d/vpnclient_init
Enabling start/stop script for run level 3,4 and 5.

Installing license.txt (VPN Client license) in "/opt/cisco-vpnclient/":
/opt/cisco-vpnclient/license.txt

Installing bundled user profiles in "/etc/opt/cisco-vpnclient/Profiles/":
* Replaced Profiles: sample

Copying binaries to directory "/opt/cisco-vpnclient/bin".
Adding symlinks to "/usr/local/bin".
/opt/cisco-vpnclient/bin/vpnclient
/opt/cisco-vpnclient/bin/cisco_cert_mgr
/opt/cisco-vpnclient/bin/ipseclog
Copying setuid binaries to directory "/opt/cisco-vpnclient/bin".
/opt/cisco-vpnclient/bin/cvpnd
Copying libraries to directory "/opt/cisco-vpnclient/lib".
/opt/cisco-vpnclient/lib/libvpnapi.so
Copying header files to directory "/opt/cisco-vpnclient/include".
/opt/cisco-vpnclient/include/vpnapi.h

Setting permissions.
/opt/cisco-vpnclient/bin/cvpnd (setuid root)
/opt/cisco-vpnclient (group bin readable)
/etc/opt/cisco-vpnclient (permissions not changed)
* You may wish to change these permissions to restrict access to root.
* You must run "/etc/init.d/vpnclient_init start" before using the client.
* This script will be run AUTOMATICALLY every time you reboot your computer.
asingh:/opt/vpnclient#


4. Copy any .pcf that may have come with the vpnclient to /etc/CiscoSystemsVPNClient/Profiles

5. For this one time start vpnclient, as follows:


asingh:/opt/vpnclient#/etc/init.d/vpnclient_init start


This will happen automatically at system start-up in the future.

6. Connect to VPN as follows:

asingh:/opt/vpnclient#vpnclient connect profile

Substitute profile with the your preferred profile defined via profile.pcf file in /etc/CiscoSystemsVPNClient/Profiles

That's it!

posted by Amandeep 6/18/2009 11:29:00 PM | PERMALINK

How to Find Large Files and Directories in the Solaris OS

Check out this blog for the tip:
http://wikis.sun.com/display/BigAdmin/Finding+Large+Files+and+Directories+in+the+Solaris+OS

posted by Amandeep 3/23/2009 05:25:00 PM | PERMALINK

Enabling Apache Tomcat on Solaris 10

Apache Tomcat is already installed with Solaris 10. Following steps can be used to enable the Tomcat server (assuming C-shell):

1. setenv CATALINA_BASE /var/apache/tomcat
2. setenv JAVA_HOME /usr/java
3. cd /var/apache/tomcat/conf
4. cp server.xml-example server.xml
5. cd /usr/apache/tomcat
6. ./bin/startup.sh

Apache tomcat should now be running at port 8080 and can be tested by entering http://localhost:8080/ in the browser.

posted by Amandeep 1/08/2009 09:33:00 PM | PERMALINK

Korn Shell Scripting Tutorial

Just noting the link to a concise ksh tutorial that I came across. A more complete list of shell scripting notes is available here. Some additional notes :


Including other scripts: For better code/script organization if one wants to include a one script (say, include_script.ksh) in another script (say, main_script.ksh) following line in "main_script.ksh" will achieve it: . full_path/include_script.ksh Note the ".", without this "include_script.ksh" will get executed in a separte shell and its variable will not be visible in "main_script.ksh".

Variables Significant to ksh and sh: There is a good list here

Redirecting: All Unix process have 3 file descriptors by default 1 (stdout), 2 (stderr) and 3 (stdin). Following example shows how to redirect both stdout and stderr to same file:

ls -l > my_file 2>&1

(For more details see file duping section here)

posted by Amandeep 12/12/2008 11:14:00 PM | PERMALINK

As the title suggests, this is an addendum to the last entry which covered setting tip line between Sun Sparc system and another system running Solaris. When keyboard and monitor are not connected to the Sun Sparc system automatically directs the console to the serial port. Once the Sun Sparc and the PC were connected via a null modem cable, I was able to access the console easily using putty.

One issue is that the the serial port sends break signal to the Sun sparc system whenever the PC is powered off. This causes the Sparc system to drop to "ok" prompt. To prevent this from happening, I uncommented the following following line in /etc/defaults/kbd file on the Sun Sparc system, and rebooted it :

KEYBOARD_ABORT=alternate

This changes the break sequence to ~^b, thus providing the ability to drop the system to "ok" prompt when needed, while avoiding any confusion due to bogus break signals.

posted by Amandeep 12/12/2008 12:39:00 AM | PERMALINK

Connecting SPARC system through tip line

I have an old Ultra60 box, running Solaris 10. I wanted to free up the monitor space but my other monitor is already connected to two systems via a kvm. While the SParc box is pretty stable and i could always rlogin into it, I wanted a way to be able to see the console - just in case. So I decided to use tip line.

To connect a tip line, I bought a null modem cable from local fry's store and connected it between the Ultra60 and the PC. The PC is now running OpenSolaris 2008.5. In the /etc/remote file I added an entry :

jalandhar:\
:dv=/dev/term/a:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:

And entered the following in the terminal:

%tip jalandhar


Voila following messages appeared when I turned Ultra60 on :

Sun Ultra 60 UPA/PCI (2 X UltraSPARC-II 360MHz), No Keyboard
OpenBoot 3.23, 2048 MB memory installed, Serial #12111824.

SunOS Release 5.10 Version Generic 64-bit
Copyright 1983-2005 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Cisco Unity IPSec Module 4.0 Load OK
Hostname: jalandhar
checking ufs filesystems
/dev/rdsk/c0t1d0s7: is logging.
jalandhar console login:

*****************************************************************************
*
* Starting Desktop Login on display :0...
*
* Wait for the Desktop Login screen before logging in.
*
*****************************************************************************
jalandhar console login:


For more information see: http://docs.sun.com/source/806-1377-10/tipapp.html

posted by Amandeep 6/11/2008 09:15:00 PM | PERMALINK