If a USB device behaves erratically.
Use the cfgadm command to reset the device,
which logically removes and re-creates the device.

1. Become superuser.

2. Make sure that the device is not in use.

3. Reset the device.

For example:

# cfgadm -x usb_reset -y usb0/4.7

4. Verify that the device is connected.

For example:

# cfgadm usb0/4.7

Ap_Id                  Type         Receptacle   Occupant     Condition
usb0/4.7               usb-storage  connected    configured   ok

This document shows how you can set up a two node, high-availability HTTP cluster with heartbeat on linux. Both nodes use the Apache web server to serve the same content.

Pre-Configuration Requirements:

1. Assign hostname host01 to primary node with IP address 192.168.0.1 to eth0.
2. Assign hostname host02 to secondry node with IP address 192.168.0.2.

Note: on host01

# uname -n

host01

On host02

uname -n

host02

192.160.2.1 is the virtual IP address that will be used for our Apache webserver (i.e., Apache will listen on that address).

Configuration:

1. Download and install the heartbeat package. In our case we are using linux so we will install heartbeat with yum:

yum install heartbeat

or download these packages:

heartbeat-2.08
heartbeat-pils-2.08
heartbeat-stonith-2.08

2. Now we have to configure heartbeat on our two node cluster. We will deal with three files. These are:

authkeys
ha.cf
haresources

3. Now moving to our configuration. But there is one more thing to do, that is to copy these files to the /etc/ha.d directory. In our case we copy these files as given below:

cp /usr/share/doc/heartbeat-2.1.2/authkeys /etc/ha.d/
cp /usr/share/doc/heartbeat-2.1.2/ha.cf /etc/ha.d/
cp /usr/share/doc/heartbeat-2.1.2/haresources /etc/ha.d/

4. Now let’s start configuring heartbeat. First we will deal with the authkeys file, we will use authentication method 2 (sha1). For this we will make changes in the authkeys file as below.

vi /etc/ha.d/authkeys

Then add the following lines:

auth 2
2 sha1 test-ha

Change the permission of the authkeys file:

# chmod 600 /etc/ha.d/authkeys

5. Moving to our second file (ha.cf) which is the most important. So edit the ha.cf file with vi:

vi /etc/ha.d/ha.cf
Configuring Heartbeat High Availability Cluster On linux

Add the following lines in the ha.cf file:

logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
initdead 120
bcast eth0
udpport 694
auto_failback on
node host01
node host02

Note: host01 and host02 is the output generated by

# uname -n

6. The final piece of work in our configuration is to edit the haresources file. This file contains the information about resources which we want to highly enable. In our case we want the webserver (httpd) highly available:

# vi /etc/ha.d/haresources

Add the following line:

host01 192.160.2.1 httpd

7. Copy the /etc/ha.d/ directory from host01 to host02:

# scp -r /etc/ha.d/ root@host02:/etc/

8. As we want httpd highly enabled let’s start configuring httpd:

# vi /etc/httpd/conf/httpd.conf

Add this line in httpd.conf:

Listen 192.160.2.1:80

9. Copy the /etc/httpd/conf/httpd.conf file to host02:

# scp /etc/httpd/conf/httpd.conf root@host02:/etc/httpd/conf/

10. Create the file index.html on both nodes (host01 & host02):

On host01:

echo “host01 apache test server” > /var/www/html/index.html

On host02:

echo “host02 apache test server” > /var/www/html/index.html

11. Now start heartbeat on the primary host01 and secondary host02:

/etc/init.d/heartbeat start

12. Open web-browser and type in the URL:

http://192.160.2.1

It will show host01 apache test server.

13. Now stop the heartbeat daemon on host01:

# /etc/init.d/heartbeat stop

In your browser type in the URL http://192.160.2.1 and press enter.

It will show host02 apache test server.

14. We don’t need to create a virtual network interface and assign an IP address (192.160.2.1) to it. Heartbeat will create this and start the service (httpd) itself.

Don’t use the IP addresses 192.168.0.1 and 192.168.0.2 for services. These addresses are used by heartbeat for communication between host01 and host02. When any of them will be used for services/resources, it will disturb heartbeat and will not work. Be carefull!!!

This procedure lets you verify the baud rate and other serial port settings used by the Sun Fire V490 server to communicate with attached serial port devices.

You must be logged in to the Sun Fire V490 server, and the server must be running Solaris OS software.

Procedure:

1. Open a terminal tool window.

2. Type:

# eeprom ttya-mode

3. Look for the following output:

ttya-mode = 9600,8,n,1,-

This line indicates that the Sun Fire V490 server’s serial port is configured for:

* 9600 baud

* 8 bits

* No parity

* 1 stop bit

* No handshake protocol

Reference: http://docs.sun.com

Reference: http://docs.sun.com

The following procedure assumes you are connecting to the serial port (ttya) of the Sun Fire V490 system using a tip connection from serial port B (ttyb) of another Sun server, and that the other Sun server has its own local graphics terminal.

Procedure:

1. Decide whether you need to reset OpenBoot configuration variables on the Sun Fire V490 system.

Certain OpenBoot configuration variables control from where system console input is taken and to where its output is directed.

* If you are installing a new system – The default OpenBoot configuration variable settings will work properly. You do not need to reset the variables. Skip to Step 3.

* If you have previously altered OpenBoot configuration variable settings – For example, to use the system controller as the system console, you need to change the OpenBoot configuration variables back to their default values. Continue with the next step from the existing system console.

* If you are not sure whether OpenBoot configuration variable settings have been altered – Refer to “How to View and Set OpenBoot Configuration Variables” on page 178. Verify that the settings are as given in Reference for System Console OpenBoot Variable Settings. If not, reset them as described in the next step.

2. If necessary, reset OpenBoot configuration variables.

From the existing system console, type:

ok setenv diag-out-console false
ok setenv input-device ttya
ok setenv output-device ttya

Note – There are many other OpenBoot configuration variables, and although these do not affect which hardware device is used as the system console, some of them affect what diagnostic tests the system runs and what messages the system console displays. For details, refer to Controlling POST Diagnostics.

3. Connect the RJ-45 serial cable and adapter.

The cable and adapter connect the Sun server’s ttyb serial port to the Sun Fire V490 system’s built-in ttya serial port. Pinouts, part numbers, and other details about the serial cable and adapter are provided in the Sun Fire V490 Server Parts Installation and Removal Guide.

4. Ensure that the /etc/remote file on the Sun server contains an entry for hardwire.

Most releases of Solaris OS software shipped since 1992 contain an /etc/remote file with the appropriate hardwire entry. However, if the Sun server is running an older version of Solaris OS software, or if the /etc/remote file has been modified, you may need to edit it. Refer to How to Modify the /etc/remote File for details.

5. In a terminal tool window on the Sun server, type:

hostname% tip hardwire

The Sun server responds by displaying:

connected

The terminal tool is now a tip window directed to the Sun Fire V490 system via the Sun server’s ttyb port. This connection is established and maintained even if the Sun Fire V490 system is completely powered off or just starting up.

References: http://docs.sun.com

1. The multipath-tools package is not installed as part of a default installation of the operating system. The recommended multipath-tools rpm package is available from the Novell
website. The SLES 9 SP3 installation CD includes the multipath-tools package.

2. Verify that the required version of uDev has been installed for your environment. To query the uDev version, execute the command:

# rpm -q udev
If required, upgrade the uDev package and then execute the command to create a new device under the ‘/dev’ directory.

# udevstart
3. Novell recommends that ‘subfs’ auto-mount be disabled when using MPIO. This is achieved by editing the ‘/etc/sysconfig/hotplug’ and setting the value:

HOTPLUG_USE_SUBFS=no

Also, to prevent significant boot-up delays, edit /etc/sysconfig/boot and set the value:
DISABLE_BLKID=yes

4. Load the dm_multipath kernel module if it is not already loaded.

# modprobe dm_multipath
5. Replace the default /etc/multipath.conf with the following multipath.conf file recommended by EMC for attach to EMC storage.

Follow the instructions in the annotated multipath.conf file for masking internal scsi disks or disks that need to be excluded from multipath control.

## This is the /etc/multipath.conf file recommended for
## EMC storage devices.
##
## OS : SLES 9 SP3
## Arrays : CLARiiON and SYMMETRIX
##
## The blacklist is the enumeration of all devices that are to be
## excluded from multipath control
devnode_blacklist {
## Replace the wwid with the output of the command
## ‘scsi_id -g -u -s /block/[internal scsi disk name]’
## Enumerate the wwid for all internal scsi disks.
## Optionally, the wwid of VCM database may also be listed here.
wwid 20010b9fd080b7321
devnode “^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*”
devnode “^hd[a-z][[0-9]*]”
devnode “^cciss!c[0-9]d[0-9]*[p[0-9]*]”
}
devices {
## Device attributes for EMC SYMMETRIX
device {
vendor “EMC “
product “SYMMETRIX”
path_grouping_policy multibus
getuid_callout “/sbin/scsi_id -g -u -s /block/%n”
path_selector “round-robin 0”
features “0”
hardware_handler “0”
failback immediate
}
## Device attributes for EMC CLARiiON
device {
vendor “DGC”
product “*”
path_grouping_policy group_by_prio
getuid_callout “/sbin/scsi_id -g -u -s /block/%n”
prio_callout “/sbin/mpath_prio_emc /dev/%n”
hardware_handler “1 emc”
features “1 queue_if_no_path”
no_path_retry 300
path_checker emc_clariion
failback immediate
}
}

6. Perform a dry run and evaluate the setup by running the multipath command.

• With Symmetrix Logical Units, the output will look similar to:

# multipath –v2 -d
create: 360060480000190100501533030383842
[size=898 MB][features=”0″][hwhandler=”0″]
_ round-robin 0 [prio=4]
_ 2:0:2:105 sdaa 65:160 [ready]
_ 2:0:3:105 sdas 66:192 [ready]
_ 3:0:2:105 sdcj 69:112 [ready]
_ 3:0:3:105 sddb 70:144 [ready]
create: 360060480000190100501533030383843
[size=898 MB][features=”0″][hwhandler=”0″]
_ round-robin 0 [prio=4]
_ 2:0:2:106 sdab 65:176 [ready]
_ 2:0:3:106 sdat 66:208 [ready]
_ 3:0:2:106 sdck 69:128 [ready]
_ 3:0:3:106 sddc 70:160 [ready]
create: 360060480000190100501533030383844
[size=898 MB][features=”0″][hwhandler=”0″]
_ round-robin 0 [prio=4]
_ 2:0:2:107 sdac 65:192 [ready]
_ 2:0:3:107 sdau 66:224 [ready]
_ 3:0:2:107 sdcl 69:144 [ready]
_ 3:0:3:107 sddd 70:176 [ready]
create: 360060480000190100501533030383845
[size=898 MB][features=”0″][hwhandler=”0″]
_ round-robin 0 [prio=4]
_ 2:0:2:108 sdad 65:208 [ready]
_ 2:0:3:108 sdav 66:240 [ready]
_ 3:0:2:108 sdcm 69:160 [ready]
_ 3:0:3:108 sdde 70:192 [ready]

• With CLARiiON Logical Units, the output will look similar to:

# multipath –v2 –d
create: 360060160aa4018002ae6839182a8da11
[size=3 GB][features=”1 queue_if_no_path”][hwhandler=”1 emc”]
_ round-robin 0 [prio=2]
_ 3:0:0:6 sdbe 67:128 [ready]
_ 2:0:0:6 sdbk 67:128 [ready]
_ round-robin 0
_ 3:0:1:6 sdbr 68:80 [ready]
_ 2:0:1:6 sdi 8:128 [ready]
create: 360060160aa4018002ce6839182a8da11
[size=3 GB][features=”1 queue_if_no_path”][hwhandler=”1 emc”]
_ round-robin 0 [prio=2]
_ 3:0:0:7 sdbf 67:144 [ready]
_ 2:0:0:7 sdbl 67:128 [ready]
_ round-robin 0
_ 3:0:1:7 sdbs 68:96 [ready]
_ 2:0:1:7 sdj 8:144 [ready]
create: 360060160aa4018002de6839182a8da11
[size=3 GB][features=”1 queue_if_no_path”][hwhandler=”1 emc”]
_ round-robin 0 [prio=2]
_ 3:0:1:8 sdbt 68:112 [ready]
_ 2:0:1:8 sdk 8:160 [ready]
_ round-robin 0
_ 3:0:0:8 sdbg 67:160 [ready]
_ 2:0:0:8 sdbm 67:128 [ready]
create: 360060160aa4018002ee6839182a8da11
[size=3 GB][features=”1 queue_if_no_path”][hwhandler=”1 emc”]
_ round-robin 0 [prio=2]
_ 3:0:0:9 sdbh 67:176 [ready]
_ 2:0:0:9 sdbn 67:128 [ready]
_ round-robin 0
_ 3:0:1:9 sdbu 68:128 [ready]
_ 2:0:1:9 sdl 8:176 [ready]

7. If the listing is appropriate, commit the configuration as follows.

a. Start the required multipath processes.

# /etc/init.d/boot.multipath start
# /etc/init.d/multipathd start
b. Perform an ‘lsmod’ and verify that the processes are running.

• With Symmetrix attach the following modules should be listed:

# lsmod |grep dm
dm_round_robin 20480 1
dm_multipath 38544 2 dm_round_robin
dm_mod 77536 10 dm_multipath
• With CLARiiON attach the following modules will be listed:

# lsmod |grep dm
dm_emc 10880 1
dm_round_robin 7680 1
dm_multipath 25352 3 dm_emc,dm_round_robin
dm_mod 61312 1 dm_multipath

8. To get a listing of the current setup do:

# multipath -ll
9. Integrate the startup of the appropriate daemons in the boot sequence as follows:

# insserv boot.device-mapper multipathd boot.multipath
10. Device-mapper (dm) names and sd device names may not be persistent across reboots. There are two mechanisms to achieve persistence:

• Use of scsi_id based persistent names.

The scsi_id based persistent names are populated under the “/dev/disk/by-name” directory.

• Use of LVM-2 on top of device-mapper.

To enable LVM access to devices that are under multipath control, edit the /etc/lvm/lvm.conf and add “device-mapper” to the “types” extension. By default, device mapper uses the major number of 253.

types = [ "device-mapper", 253 ]

Configure logical volumes as necessary. LVM based entries in ‘/etc/fstab’ are supported. In the normal boot process, the device mapper and the multipath daemons start before LVM starts the discovery process.

You may optionally reboot the host to verify that the required processes automatically startup.

I/O Tuning Parameters:

1. numfsbufs (vmtune –b) specifies the number of file system buffer
   structures. This value is critical asVMM will put a process on the wait list
   if there are insufficient free buffer structures.

1. Run vmtune –a (pre 5.2) vmstat –v (5.2 & >) and monitor
   fsbufwaitcnt. This is incremented each time an I/O operation has to wait for
   file system buffer structures.
2. A general technique is to double the numfsbufs value (up to a maximum of
   512) until fsbufwaitcount no longer increases. This value, as it is dynamic,
   should be re-executed on boot prior to any mount all command.
3. hd_pbuf_cnt (vmtune –B) determines the number of pbufs assigned to LVM.
   pbufs are pinned memory buffers used to hold pending I/O requests.
4. Again, examine vmtune –a and review the psbufwaitcnt. If increasing,
   multiply the current hd_pbuf_cnt by 2 until psbufwaitcnt stops incrementing.
5. Because the hd_pbuf_cnt can only be reduced via a reboot (this is
   pinned memory) – be frugal when increasing this value.

I/O Tuning :

1. Over 35% I/O wait should be investigated.
2. Oracle databases like async I/O, DB2 & Sybase do not care (a good
   place to start would be AIO PARMS of
3. MINSERVERS = 80 MAXSERVERS = 200 MAXREQUESTS = 8192)
4. Recent technology disks will support higher ltg numbers
5. lvmstat (must be enabled prior to usage) provides detailed information for
   I/O contention
6. filemon is an excellent I/O tool (trace – ensure you turn it off)
7. numfsbufs and hd_pbuf_cnt adjusted to reduce wait counts in vmtune or
   vmstat -v

Hard Link:

Unix files consist of two parts: the data part and the filename part.
More than one filename can reference the same inode number; these files are called to be hard linked together.

Here two hard link files file-hard-a.txt and file-hard-b.txt reference same inode number.
Example:

[root@sunx4150 tmp]# touch file-hard-a.txt
[root@sunx4150 tmp]# ln file-hard-a.txt file-hard-b.txt
[root@sunx4150 tmp]# ls -ltri
34532 -rw-r--r-- 2 root root 0 Aug 20 10:09 file-hard-b.txt
34532 -rw-r--r-- 2 root root 0 Aug 20 10:09 file-hard-a.txt

Hard Link can not cross file system boundaries.

Soft Link:
There is a special file type whose data part carries a path to another file. Since it is a special file, the OS recognizes the data as a path, and redirects opens, reads, and writes so that, instead of accessing the data within the special file, they access the data in the file named by the data in the special file. This special file is called a soft link or a symbolic link.

Here you see that soft link file file-soft-b.txt reference file name file-soft-a.txt.

Example:

[root@sunx4150 tmp]# touch file-soft-a.txt
[root@sunx4150 tmp]# ln -s file-soft-a.txt file-soft-b.txt
[root@sunx4150 tmp]# ls -ltri
34532 -rw-r--r-- 1 root root 0 Aug 20 10:19 file-soft-a.txt
2344 lrwxrwxrwx 1 root root 15 Aug 20 10:19 file-soft-b.txt -> file-soft-a.txt


Soft link can be created across file system boundaries.

Add the following entry to data-sources.xml
<data-source
class=”com.evermind.sql.DriverManagerDataSource”
name=”jdbc/Oracle”
location=”jdbc/OracleCoreDS”
xa-location=”jdbc/xa/OracleXADS”
ejb-location=”jdbc/OracleDS”
connection-driver=”oracle.jdbc.driver.OracleDriver”
username=”scott”
password=”->PwdForScott”
url=”jdbc:oracle:thin:@incq245ac.idc.oracle.com:1521:V10UTF8″
inactivity-timeout=”30″/>

Then add the following entry to jazn-data.xml

<user>
<name>PwdForScott</name>
<display-name>PwdForScott</display-name>
<description>Scott’s
password</description>
<credentials>!tiger</credentials>
</user>

Restart the OC4J and checked the jazn-data.xml

You will the following With password Encrypted.

<user>
<name>PwdForScott</name>
<display-name>PwdForScott</display-name>
<guid>82D9DA218DD411DBBF9ADBCC94167DAD</guid>
<description>Scott’s
password</description>
<credentials>{903}Say314L4or3AWmsUFg/Glf2L/6GFrqqi</credentials>
</user>

Server Configuration for Solaris Jumpstart Software

Server: – Powercard
Path: – /data1/jumpstart
The Solaris 9 Operating System offers an automatic installation process, Solaris JumpStart software. The Solaris JumpStart procedure enables you to install the Solaris OS automatically and configure it differently, depending on the characteristics of client systems. These identifying characteristics are used to select the correct configuration for each client system.

The following tasks are required to configure a single JumpStart server to provide basic software installation services using the JumpStart procedures:

1. Spool the operating system image.
2. Edit the sysidcfg file.
3. Edit the profile and rules.
4. Run the check script.
5. Run the add_install_client script.
6. Boot the client.

Step #1
To spool the Solaris 9 boot and installation images to a local disk, complete the following steps:
Create a directory with at least 800 Mbytes of space available to hold the Solaris OS image. Usually the /data1/jumpstart/install directory is used.

# mkdir /data1/jumpstart/install
Insert the Solaris 9 Software 1 of 2 CD-ROM in the CD-ROM drive or the Solaris 9 DVD in the DVD drive.
Change the directory to the location of the setup_install_server script.

# cd /cdrom/cdrom0/s0/Solaris_9/Tools
Run the setup_install_server script to copy the Solaris 9 OS installation images to the local disk.

#./setup_install_server /data1/jumpstart/install
When the setup_install_server script finishes, change the directory to root (/), and eject the CD-ROM or DVD.

#cd /
#eject cdrom
If you use CD-ROM media, insert the Solaris 9 Software 2 of 2 CD-ROM in the CD-ROM drive.
Change the directory to the location of the add_to_install_server script.

# cd /cdrom/cdrom0/Solaris_9/Tools
Run the add_to_install_server script to copy the remainder of the installation image to the local disk.

#./add_to_install_server /data1/jumpstart/install
When add_to_install_server finishes, change the directory to root (/), and eject the CD-ROM.

# cd /
# eject cdrom

Step #2
The sysidcfg file keeps the various types of system information such as locale, time_zone, and so on, and supplies the information to the client at the booting time.
Create a directory to hold the sysidcfg file. Typically the /data1/jumpstart/config directory holds the sysidcfg file.

# mkdir /data1/jumpstart/config
Change the directory to /data1/jumpstart/config, and create a file called sysidcfg using a text editor.

# cd /data1/jumpstart/config
# vi sysidcfg
In the sysidcfg file, add the following lines. Substitute values that are appropriate for your systems, location, and network.

network_interface=primary {protocol_ipv6=no netmask=255.255.255.0}
security_policy=none
name_service=none
timezone=Asia/Calcutta
system_locale=en_US
Save the sysidcfg file, and exit your edit session.

Step #3
a. Rules
Create a directory to hold the rules file if this directory does not already exist. Usually, the /data1/jumpstart/config directory holds the rules file.
# mkdir /data1/jumpstart/config
Change the directory to /data1/jumpstart/config, and create a file called rules using a text editor.

# cd /data1/jumpstart/config
# vi rules
In the rules file, add the following line:

hostname client_name - profile1 -
For client_name, substitute the name of your JumpStart client. For example:

hostname sun1 - profile -
Save the rules file, and exit your edit session.

b. Profiles
Usually, the /data1/jumpstart/config directory holds the profile file.
Change the directory to /data1/jumpstart/config, and create a file called profile using a text editor.

# cd /data1/jumpstart/config

# vi profile1
Add the following lines to the profile1 file:

install_type initial_install
system_type server
partitioning explicit
filesys c0t0d0s0 14000 /
filesys c0t0d0s1 6144 swap
filesys c0t0d0s3 5000 /usr
filesys c0t0d0s4 10000 /var
filesys c0t0d0s5 15000 /opt
cluster SUNWCXall addSave the profile1 file, and exit your edit session.

Step #4
Before a JumpStart client can use a configuration provided by a JumpStart server, you must run the check script to produce a file called rules.ok. The check script validates the syntax of the rules file and the profile files. If the validation completes successfully, the check script creates the rules.ok file.
Change the directory to the location of the check script.

# cd /data1/jumpstart/install/Solaris_9/Misc/JumpStart_sample
Copy the check script to the /data1/jumpstart/config directory.

# cp check /data1/jumpstart/config
Change the directory to /data1/jumpstart/config, and run the check script.

# cd /data1/jumpstart/config
#./check
Validating rules…
Validating profile profile1…
The custom JumpStart configuration is ok.

Step #5. Add a host entry.
Edit the /etc/ethers file, and add an entry for the JumpStart client.

#vi /etc/ethers
0:3:ba:8a:c:ed qctapp1
Save and exit from the ethers file.
Edit the /etc/inet/hosts file, and add an entry for the JumpStart client.

#vi /etc/inet/hosts

10.0.50.76 qctapp1
Save and exit from the hosts file.

b. Add a client.
Change the directory to the location of the add_install_client script on the server.

# cd /data1/jumpstart/install/Solaris_9/Tools
Run the add_install_client script, and specify server and client information as follows. (Note: The following line of code should all be entered on one line.)

#./add_install_client -c server_name:/data1/jumpstart/config
-p server_name:/data1/jumpstart/config client_name platform_group
For example:

#./add-install-client -c powercard:/data1/jumpstart/config -p powercard:/data1/jumpstart/config sun1 sun4u
Edit the /etc/dfs/dfstab file to add the following line:

# vi /etc/dfs/dfstab

share -F nfs -o ro,anon=0 /data1/jumpstart/install
share -F nfs -o ro,anon=0 /data1/jumpstart/config
Save and exit from the dfstab file.
Run the shareall command to share the /data1/jumpstart/config and /data1/jumpstart/install directories.

#shareall
Verify that the /data1/jumpstart/config and /data1/jumpstart/install directories are currently shared.

#share

Step #6

Booting the JumpStart Client
After the JumpStart server has been configured to provide all of the required services, you can initiate the installation process on the JumpStart client. To boot the JumpStart client, perform the following steps:

a. Bring the JumpStart client to run state 0.

# init 0
b. Boot the client to initiate the software installation using the JumpStart procedure.

ok boot net - install