SOLARIS LIVE PROCEDURES

TSM Backup Client Installation on X86/Sparc Solaris Servers

2012-11-12T22:10:00.004-08:00

Description: The Tivoli Storage Manager clients work in colligation with the Tivoli Storage Manager server. It helps you protect the information of your server. We also can maintain the backup version of our server files that we can restore if the original files are damaged or lost. We can also archive the files, and preserve them current state, and recall them when necessary.

Installation Process:

.1. Download the latest version of the TSM client software into our target server

EX: For x86 servers: tr-ibm-tsmclient-solaris.6.1.0.2.x86.1.0.0.zip

For Sparc servers: tr-ibm-tsmclient-solaris.6.1.0.2.Sparc.1.0.0.zip

#cd /tmp

#mkdir -p /tmp/tsm

#unzip tr-ibm-tsmclient-solaris.6.1.0.2.x86.1.0.0.zip -d tsm/

#cd tsm

#ls

dsm.opt install.ksh README_enu.htm TIVsmCba.pkg

dsm.sys install.ksh.17jan2011 removetsm.ksh tsmadmin

EXP-ICOS2863.txt NOTICES.TXT S95tsmsched upgrade.ksh

inclexcl.txt README_api_enu.htm TIVsmCapi.pkg version.txt

2. Copy the configuration files and script required location

#cp S95tsmsched /etc/rc3.d/

#cp inclexcl.txt /opt/tivoli/tsm/client/ba/bin

#cp dsm.opt /opt/tivoli/tsm/client/ba/bin

#cp dsm.sys /opt/tivoli/tsm/client/ba/bin

3. Stop the TSM client scheduler, and delete the old packages if we have any

#/etc/rc3.d/S95tsmsched stop

#ps -ef|grep dsmc

#pkgrm TIVsmCba.pkg

#pkgrm TIVsmCapi.pkg

4. Install latest TSM client packages, and change permission of the startup script

#pkgadd -d TIVsmCba.pkg

#pkgadd -d TIVsmCapi.pkg

#chmod -R 755 /etc/rc3.d/S95tsmsched stop

5. Give the the TSM server entries on dsm.sys and dsm.opt files

NOTE: check the communication between the server and client

#telnet <server name> <port number>

#vi /opt/tivoli/tsm/client/ba/bin/dsm.sys

SERVERNAME <tsm server name>

TCPServeraddress <tsm server name>

COMMmethod tcpip

tcpport <port number>

COMPression off

passwordaccess generate

TCPBUFFSIZE 32

TCPWINDOWSIZE 64

schedlogret 10

errorlogret 10

schedmode polling

txnbytelimit 2097152

commrestartduration 60

commrestartinterval 15

inclexcl /opt/tivoli/tsm/client/ba/bin/inclexcl.txt

errorlogname /opt/tivoli/tsm/client/ba/bin/dsmerror.log

#vi /opt/tivoli/tsm/client/ba/bin/dsm.opt

SErvername <tsm server name>

SUbdir Yes

dateformat 2

replace prompt

compressalways no

NOTE: check the inclexcl.txt file

5. Test the TSM client connectivity to the TSM server

#dsmc query session

6. Start the TSM client scheduler

#/etc/rc3.d/S95tsmsched start

#ps -ef|grep dsmc

root 20270 1 0 Nov 10 ? 0:27 ./dsmc schedule

7. check the client connectivity to the server

IBM Tivoli Storage Manager

Command Line Backup-Archive Client Interface

Client Version 6, Release 1, Level 0.2

Client date/time: 13-11-2012 05:57:15

Node Name: <TSM client server name>

Session established with server <TSM server name: Solaris SPARC

Server Version 5, Release 5, Level 4.2

Server date/time: 13-11-2012 05:57:15 Last access: 13-11-2012 00:24:53

TSM Server Connection Information

Server Name.............: <TSM server Name>

Server Type.............: Solaris SPARC

Archive Retain Protect..: "No"

Server Version..........: Ver. 5, Rel. 5, Lev. 4.2

Last Access Date........: 13-11-2012 00:24:53

Delete Backup Files.....: "No"

Delete Archive Files....: "Yes"

Node Name...............: <TSM client server name>

User Name...............: root

NOTE:Whenever we upgrade TSM client with the most recent one, just copy the latest software into the target location, stop the tsm scheduler before going to upgrade. Run the “upgrade.ksh” script once you change the permissions of the script.

#/etc/rc3.d/S95tsmsched stop

#chmod -R 755 /tmp/tsm/upgrade.ksh

#./upgrade.ksh

#/etc/rc3.d/S95tsmsched stop

New Volume Configuration To The Existing Veritas Cluster

2012-11-05T01:29:00.000-08:00

Reason for Change
Mysql database is generating more replication logs and elastic logs on hourly basis, and it causes the platform outages as it gets filled up volume. Hence finally we decided to dedicate the new volume to the DB cluster for these logs
Procedure
1.Two new LUNs need to be available on each host ( should be shared storage)
2.Once we add new LUNs to the server, need to label them, and should bring the LUNs under
   VERITAS control
   #cfgadm -al -o show_FCP_dev
    #export PATH=$PATH:/opt/VRTS/bin:/opt/VRTSvcs/bin:/etc/vx/bin
#vxdisk scandisks new
#vxdisk list
3.Initialize the each disk and create new disk group with new LUNs
   #vxdisksetup -i <new LUN>
#vxdisksetup -i <2nd new LUN>
#vxdisk list
#vxdg init new_bindg new_bindisk01=<new LUN>
#vxdg -g new_bindg adddisk new_bindisk02=<2nd new LUN>
4.Check whether the new disk group is working or not
   #vxdg deport new_bindg [needs to be done on A node]
    #vxdisk -o alldgs list
    #vxdg import new_bindg   [Needs to be done on B node]
    #vxvol -g new_bindg start new_binlogs [start the volume if we have any]
5.Create new striped volume using new LUNs
    #vxassit -g new_bindg make new_binlogs 398g layout=stripe ncol=2 stwidth=8k
       new_bindisk01 new_bindisk02
    #vxprint -hvpst
6.check the volume with temporary mount point
   #mkfs -F vxfs /dev/vx/rdsk/new_bindg/new_binlogs
#mkdir -p /binlogs [ do it on both the nodes]
#chown -R dba:other /binlogs [do it on both the nodes]
#mount -F vxfs /dev/vx/rdsk/new_bindg/new_binlogs /binlogs
#umount /binlogs
7. Freeze the cluster before going to add the volume
   #cp /etc/VRTSvcs/conf/config/main.cf /etc/VRTSvcs/conf/config/main.cf.bkp
    #cp /etc/VRTSvcs/conf/config/types.cf /etc/VRTSvcs/conf/config/types.cf.bkp
#haconf makerw [ Make the configuration as writable]
#hagrp -freeze newsDB -persistent
#hastatus -sum
8.Add disk group resource to the cluster
   #hares -add newsDBbin-dg DiskGroup newsDB

VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors [ignore notice]

   #hares -modify newsDBbin-dg DiskGroup new_bindg
   #hares -modify newsDBbin-dg Enabled 1
9.Add volume resource to the cluster
   #hares -add newsDBbin-vol Volume newsDB

VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors [ignore notice]

   #hares -modify newsDBbin-vol Volume new_binlogs
#hares -modify newsDBbin-vol DiskGroup new_bindg
#hares -modify newsDBbin-vol Enabled 1
10.Add mount resource to the cluster
   #hares -add newsDBbin-mnt Mount newsDB
          VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors [ignore notice]
#hares -modify newsDBbin-mnt MountPoint /binlogs
#hares -modify newsDBbin-mnt BlockDevice /dev/vx/rdsk/new_bindg/new_binlogs
#hares -modify newsDBbin-mnt FSType vxfs
#hares -modify newsDBbin-mnt MountOpt rw
#hares -modify newsDBbin-mnt FsckOpt %y
#hares -modify newsDBbin-mnt Enabled 1
11.Define the dependencies
#hares -link newsDB-app newsDBbin-mnt
#hares -link newsDBbin-mnt newsDB-mnt
#hares -link newsDBbin-mnt newsDBbin-vol
#hares -link newsDBbin-vol newsDBbin-dg
#hares -link newsDBbin-mnt newsDBlog-mnt
12. Go through the configuration
#more /etc/VRTSvcs/conf/config/main.cf

13.Unfreeze the cluster
     #hagrp -unfreeze newsDB -persistent
     #haconf -dump -makero [Make the configuration as readable]
     #hacf -verify /etc/VRTSvcs/conf/config/ [check the configuration]
     #hastop -all [ need stop the cluster for reconfiguration for the new resources]
     #hastart [ do it on A after that B node]
     #hastatus -sum

SOLARIS KERNEL PATCHING PROCEDURE

2012-10-17T00:40:00.002-07:00

We need to prepare patch document procedure with back-out plan, and needs to get the approval by change management. Once we get the approval, we can start our change in scheduled window
Download suitable our platform bundle patch(Recommended Solaris Cluster Patch) from https://support.oracle.com

#isainfo -b [ to check the bit version]

Take the necessary backups of the server.

#uname –a	# df –k	#metastat –p	#metadb –i	#netastat –nr
#ifconfig –a	#prtconf	#prtdiag –v	#metastat -ac	#metastat –t
#eeprom	#echo \| format	/etc/system	/etc/vfstab

NOTE: Better to run SUN Explorer before preceding this activity

NOTE: Take the outputs before detaching the mirror else you would have to take the backups separately for your detached disk

NOTE: Zones must be halted, while doing patch on active boot enviromnet

#zoneadm list –vc

NOTE: Before proceeding with patching, make sure our application & data base are down

Break the mirror, and it will isolate from root disk.

c1t0d0 —> Root disk

c1t1d0 —> Root-mirror disk

· First delete state database replicas from root-mirror disk

#metadb –i

a p luo 16 8192 /dev/dsk/c1t1d0s7

#metadb –d –f /dev/dsk/ c1t1d0s7

· Proceed with the mirror detach for your root-mirror disk

# metastat –p

d1 -m d20 d21 1

d20 1 1 c1t0d0s1

d21 1 1 c1t1d0s1

d0 -m d10 d11 1

d10 1 1 c1t0d0s0

d11 1 1 c1t1d0s0

#metadetach d1 d21

#metadetach d0 d11

#metaclear d21

#metaclear d11

#metastat –p

d1 -m d20

d20 1 1 c1t0d0s1

d0 -m d10

d10 1 1 c1t0d0s0

Mount detached root-mirror disk on mount point /mnt and edit /mnt/etc/vfstab & /mnt/etc/vfstab

#mount /dev/dsk/c1t1d0s0 /mnt

#vi /mnt/etc/vfstab [change md entries to native entries]

/dev/md/dsk/d1 à /dev/dsk/c1t1d0s1

/dev/md/dsk/d0 à /dev/dsk/c1t1d0s0

# grep -i md /mnt/etc/system

* Begin MDD root info (do not edit)

rootdev:/pseudo/md@0:0,0,blk [comment with *]

* End MDD root info (do not edit)

Unmount root-mirror disk and fsck

#umount /mnt

#fsck /dev/rdsk/c1t1d0s0

NOTE:

1.) Please keep in mind that all changes are applicable to root-mirror disk. Do not do any changes on other disk (i.e. root-disk).
2.) It is recommended to run fsck on root-mirror disk (slice 0, rootFS slice) so that it won’t give any errors while booting.
3.) Before proceeding with the patching make sure that /var FS have enough free space as all logs will be written there. else you will get errors while patching.

Now our root-disk is under SVM control and root-mirror disk is under native raw Solaris disk. By doing this step we are making sure that in case if anything goes against our action plan then we will be able to recover our server from other disk.
We have to test the booting of our server from both the disks to make sure that the server will come up with both of the disks without any issues.

#init 0

Ok>devalias root-mirror

/pci@1f,0/pci@1/scsi@8/disk@1,0:a

Ok>boot root-mirror

Once system come-up with root-mirror, needs do the post check like df –h, ifconfig etc

Now boot the server from root-disk as well

#init 0

Ok>devalias rootdisk

/pci@1f,0/pci@1/scsi@8/disk@0,0:a

Ok>boot rootdisk

Once system come-up with rootdisk, needs do the post check like df –h, ifconfig etc

Now we can go ahead with patching, but server should be single user mode

#cd /var/tmp

# digest -a md5 -v /var/tmp/10_x86_Recommended.zip [will check md5 value]

#unzip -q 10_Recommended.zip

NOTE: for unzipping of recommended patch, we need 5 GB of disk space

#grep PASSCODE 10_Recommended.README

*************** PASSCODE **************

PASSCODE: s10patchset

#shutdown -g0 -y –is

#who –r

. run-level S Oct 25 12:39 S 0 3

NOTE: For installation recommended patch, we need 3 GB of disk space

#./installpatchset --s10patchset

Setup ..........

Recommended OS Patchset Solaris 10 x86 (2011.09.14)

The patch set will complete installation in this session. No intermediate

reboots are required.

Application of patches started : 2011.09.16 20:24:45

Applying 120901-03 ( 1 of 302) ... skipped

Applying 121334-04 ( 2 of 302) ... skipped

Applying 119255-81 ( 3 of 302) ... skipped

. <similar output omitted>

Applying 147379-01 (300 of 302) ... success

Applying 147435-01 (301 of 302) ... success

Applying 147441-01 (302 of 302) ... success

NOTE: A symlink to 'installpatchset' is provided in place of the legacy 'installcluster' script for now

Once patching has done, needs to run reconfiguration reboot on server and check the kernel version

#touch /reconfigure

#reboot -- -r

#uname -a

SunOS Release 5.10 Version Generic_147441-01 32-bit

NOTE: Do not re-mirror the root-mirror disk immediately; wait for 5 to 7 days to notice any issues with the OS or application. If all is good then re-mirror the disks for redundancy.

NOTE: If patch fails, for roll-back you need to boot from the root-mirror disk and create all the SVM mirrors back on root-mirror disk from start and then re-mirror root-disk back with root-mirror disk.

SOFT & HARD LINKS

2012-10-16T22:18:00.000-07:00

Soft Link:

Symbolic link is a file that points to another file, and can create symbolic links for files, directories, and device files also

Syntax: ln -s <source_file> <target_file>

#ln –s /var/file1 link1

The size of the symbolic link always matches the number of characters in the path name it contains. EX: bin -> ./usr/bin [ size of bin directory is : 9]
Inode values are different but data block are same for soft link.
Across file system or network or another disk we can create the symbolic links
We can identify the soft link by using command ls –F which it displays the @ symbol at the end of the link

# ls -F

Desktop/ bin@ devices/ export/ lib/ net/ proc/ tmp/

Documents/ boot/ etc/ home/ lost+found/ opt/ sbin/ usr/

anonFTP/ dev/ evolution/ kernel/ mnt/ platform/ system/ var/

# ls -l bin

lrwxrwxrwx 1 root root 9 Sep 8 19:06 bin -> ./usr/bin

We can create the soft links for non existence source also#ln -s sur1 sub2 [here both files non existence files]

We can remove symbolic links by using rm command#rm link1

Hard Links:

We can create hard links for files only, and can’t create the hard links across the file system
Inode values are always same but data block are differect and will occupy the disk space
We can identify hard links by using link count more than 1

# ls -li /etc/rc2.d/K05appserv

5425 -rwxr--r-- 5 root sys 824 Aug 16 2006 /etc/rc2.d/K05appserv

#find / -mount –inum 5425 –exec ls –ltr {} \;

5425 1 -rwxr--r-- 5 root sys 824 Aug 16 2006 /etc/init.d/appserv

5425 1 -rwxr--r-- 5 root sys 824 Aug 16 2006 /etc/rc0.d/K05appserv

5425 1 -rwxr--r-- 5 root sys 824 Aug 16 2006 /etc/rc1.d/K05appserv

5425 1 -rwxr--r-- 5 root sys 824 Aug 16 2006 /etc/rc2.d/K05appserv

5425 1 -rwxr--r-- 5 root sys 824 Aug 16 2006 /etc/rc3.d/S84appserv

# find / -inum 5425

/etc/init.d/appserv

/etc/rc0.d/K05appserv

/etc/rc1.d/K05appserv

/etc/rc2.d/K05appserv

/etc/rc3.d/S84appserv

SVM ROOT MIRRORING

2012-10-16T03:23:00.000-07:00

c1t0d0 —> Root disk

c1t1d0 —> Root-mirror disk
Sub mirrors for Root disk —> d10, d20
Sub mirrors for Root-mirror disk —> d11, d21
Mirror name would be —> d0, d1 (root, swap)

1. Need to take the backup of required files

#cp /etc/system /etc/system.bkp

#cp /etc/vfstab /etc/vfstab.bkp

#df -h>df.bkp

#echo|format>format.bkp

2. We have to select the new disk as same geometry of root disk, and also need to label the new disk by using root disk

# fmthard -s /dev/null /dev/rdsk/c1t1d0s2 [empty labeling on new disk]

#prtvtoc /dev/rdsk/c1t0d0s2|fmthard -s - /dev/rdsk/c1t1d0s2 [labeling new disk]

3. Need to create 3 meta database replicas on each disk [should allocate 50MB for 7th slice on each disk, and no need run newfs]

# metadb -a -f -c 3 /dev/rdsk/c1t0d0s7

# metadb -a -f -c 3 /dev/rdsk/c1t1d0s7

#metadb [to check metadb values]

4. Create RAID-0 volumes on root disk for sub-mirrors

# metainit -f d10 1 1 c1t0d0s0 [for root]

# metainit -f d20 1 1 c1t0d0s1 [for swap]

5. Create second RAID-0 volumes on root-mirror disk for sub-mirrors

# metainit -f d11 1 1 c1t1d0s0

# metainit -f d21 1 1 c1t1d0s1

6. Create RAID-1 one-way mirror volumes using RAID-0 volumes on root disk

# metainit -f d0 -m d10

# metainit -f d1 -m d20

7. Execute “metaroot” command on root mirror volume, and it will update the /etc/system file & /etc/vfstab file

Note: Before executing “metaroot” just check system & vfstab for knowing difference after this

#metaroot d0

NOTE: Check /etc/vfstab & /etc/system files, and above command will update only for root file system with “md” entries for rest of other file systems(i.e., swap, usr, var etc..) we need to made it as manual “md” entries.

#cat /etc/vfstab

/dev/dsk/c1t0d0s1 - - swap - no -

/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no -

#vi /etc/vfstab [need to change with “md” entries for other FS]

/dev/md/dsk/d1 - - swap - no -

/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no -

8. For file system level alters, we must reboot the system[i.e. will effect in df –h with md entries]

#shutdown –y –g0 –i6

9. Once system came up, need to attach second submirrors to main mirror

#metattach d0 d11

#metattach d1 d21

Check the status of syncing

#metastat|grep –i sync

10. Install “bootblk” on root mirrored disk

#installboot /usr/platform/`uname –i`/lib/fs/ufs/bootblk /dev/rdsk/c1t1d0s0

#prtconf -pv | grep -i bootpath

bootpath: '/pci@1f,0/pci@1/scsi@8/disk@0,0:a'

NOTE: for x86 systems old versions [should be on s2 slice]

#installboot /usr/platform/i86pc/lib/fs/ufs/pboot \

/usr/platform/i86pc/lib/fs/ufs/bootblk /dev/rdsk/c1t1d0s2

------------------------------------------------------------------------------------------------------------------------

NOTE: From Solaris 10 x86 U1 version, the installboot command is obselete. So, use the installgrub command, to make the second disk bootable. It is better to run this command once, to make sure the secondary disk is bootable.

# installgrub -fm /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t1d0s0

11. Record second submirror name from event of failures

#eeprom boot-device

boot-device=rootdisk net

#ls -l /dev/dsk/c1t1d0s0

/pci@1f,0/pci@1/scsi@8/sd@1,0:a

Ok> [stop+A]

Ok> show-disks [select the root-mirror disk ]

Ok>nvalias root-mirror /pci@1f,0/pci@1/scsi@8/disk@1,0:a

NOTE: needs to boot with each drive for testing

Ok>setenv boot-device rootdisk root-mirror net

Ok>printenv boot-device

rootdisk root-mirror net

Ok>boot

NOTE: x86 systems

# eeprom bootpath

bootpath=/pci@0,0/pci15ad,1976@10/sd@0,0:a

# ls -l /dev/dsk/c1t1d0s0

lrwxrwxrwx 1 root root 46 Feb 7 16:48 /dev/dsk/c1t1d0s0 -> ../../devices/pci@0,0/pci15ad,1976@10/sd@1,0:a

# eeprom altbootpath=/pci@0,0/pci15ad,1976@10/sd@1,0:a

NOTE: Booting with 50% of available replicas is possible/optional with the /etc/system setting “set md:mirrored_root_flag=1” i.e to maintain quorum also add the mentioned line in /etc/system file.

UNMIRRORING PROCEDURE

1. Un-record second sub-mirror from “boot-device”

2. Need to detach root-mirror disk sub-mirrors from main mirror

#metadetach d0 d11 [for root]

#metadetach d1 d21 [for swap]

3. Execute metaroot on root file system block device

#metaroot /dev/dsk/c1t0d0s0

Check /etc/vfstab & /etc/system file, and above command will update for root FS

#grep c1t0d0s0 /etc/vfstab

/dev/dsk/c1t0d0s0 /dev/rdsk/c1t0d0s0 / ufs 1 no -

NOTE: For other File systems[swap,opt,usr], and we need to edit manually, and make it as native entries

NOTE: Here's the caveat(caution) for mirrored swap - you're probably using /dev/md/dsk/d1 for your dump device. Let's fix that now. First run

dumpadm | grep '/md/'

If that returns any output, then run this (using your single-disk slice for swap):

dumpadm -s /var/crash/`hostname` -d /dev/dsk/c1t0d0s1

4. Reboot the system

#shutdown –y –g0 –i6

5. Now, we can clear main mirror as well as sub-mirror under root disk

#metaclear –r d0

#metaclear –r d1

Root Password Recovery for any Solaris 10 (without CD/DVD).

2012-10-15T23:23:00.001-07:00

We can recover the root password for any solaris10 without any CD/DVD, for that first we need to bring the server at OK promt

#init 0

Boot the server into failsafe mode. In failsafe mode, server will boot with RAM disk without any CD/DVD

Ok>boot -F failsafe

#df -k

/ramdisk-root:a 201463 178943 2374 99% / > Server booted from RAM

Note: Sometimes (every time is X-86 servers) the Failsafe mode will ask you to mount the root disk before giving you the Shell prompt. Do not mount at that time, just say No everywhere and bring the failsafe mode at Shell Prompt and then do the mount and update archive manually.

In failsafe mode, we need to mount the server with root disk. Here my root disk c1t1d0s0

#mount /dev/dsk/c1t1d0s0 /a

#df -h|grep /a

/dev/dsk/c1t1d0s0 7.9G 7.1G 714M 92% /a

Copy the configuration to enable SVM module in failsafe mode, and un mount root FS

# cp /a/kernel/drv/md.conf /kernel/drv

#umount /a

Now we have to load the SVM module to enable it in failsafe mode:

#update_drv -f md

devfsadm: mkdir failed for /dev 0x1ed: Read-only file system ßYou will see this messages

Now you will be able to mount the md meta devices and will be able to make any changes

#mount /dev/md/dsk/d0 /a

Take a copy of /a/etc/passwd & /a/etc/shadow file

# cp -p /a/etc/passwd /a/etc/passwd-orig
# cp -p /a/etc/shadow /a/etc/shadow-orig

Need to remove encrypted passwd for root from /etc/shadow file

#grep root /a/etc/shadow
root:WP7grKsEFAgt.:15182::::::

#grep root /a/etc/shadow
root::15182::::::

Update the boot archive as below before proceeding with the reboot.

#bootadm update-archive -R /a

Creating boot_archive for /a
updating /a/platform/sun4u/boot_archive

Umount the meta device and Reboot your system, this time you are allowed to login into the server without password. Now first recommended thing would be to set you password for root.

#umount /a

#init 6

Note: The procedure for Solaris X-86 is also same, In X-86 select the Failsafe mode from GRUB Menu which is present in the GRUB menu bydefault. The GRUB is picking the entry from /boot/grub/menu.lst.

OpenBoot Parameters & commands

2012-10-15T23:16:00.000-07:00

GENERAL
Printenv	Display all environment variables and current values
setenv <variable>	Set variable to given value
set-default <variable>	Reset the value of variable to the factory default
set-defaults	Reset all variable values to the factory default
Go	To come out from OK> promt to # promt
Banner	Shows the system configuration
reset-all	Will save to new change & clear the buffer & reboot the system
show-devs	Show all the devices with physical path
show-nets	Show all the nic’s information
show-disks	Displays and allow a selection of device paths
Help	Shows the list of commands
power-off	Will switch off the system immediately
.version	Shows the open boot prom version
cd	Enter the device tree
.properties	Displays properties for the current node in the tree
dev devices	Sets node to device
device-end	Leaves from device tree
Devalias	Displays all defined aliases
devalias alias <device path>	Create an alias
nvalias alias <device path>	Store a devalias command in non-volatile memory
nvunalias alias <device path>	Removes stored devalias command
watch-net	Test the net device and monitors for bad packets
watch-clock	Test the real time clock chip
eject-floopy	Eject the floopy
.speed	Shows the CPU & PCI bus speed
Sync	Flushes the disk buffers to disk
show-post-results	Display post results
printenv auto-boot?	auto-boot?=false [answer]
setenv auto-boot? True	auto-boot?=true [answer]
printenv boot-device	boot-device=disk [answer]
Setenv boot-device disk net	boot-device=disk net [answer]
BOOT
auto-boot?=true	System directly reboot without stopping at OK>after power on
boot-command=boot	Command passed on to auto boot
Boot	Boot the system
boot –r or boot –rv	Will detect the new devices(reconfiguration reboot)
boot -s or boot –sv	Single user mode
boot –a	Interactive mode, user needs to put the input
boot net:rarp	Use rarp to find the boot server
boot net:dhcp	Use dhcp to find the boot server
boot cdrom -s	Single user mode by using cdrom
boot cdrom –F wanboot – install	Install client over the WAN
boot net:speed=100,duplex=full	Set network speed and duplex settings

NVRAM Variables:

Variable	Default	Description
auto-boot?	True	The system starts up automatically after power-on or reset if auto-boot? is true. If it is set to false, the system stops at the OpenBoot prompt (ok) after power-on or reset.
boot-command	Boot	The command that is executed if auto-boot? is true.
boot-device	disk or net	The device from which to start up.
boot-file	Empty string	Arguments passed to the started program.
diag-device	Net	The diagnostic startup source device.
diag-file	Empty string	Arguments passed to the startup program in diagnostic mode.
diag-switch?	False	Whether to run in diagnostic mode.
fcode-debug?	False	Whether name fields are included for plug-in device FCodes.
input-device	keyboard	A console input device (usually keyboard, ttya, or ttyb).
Nvramrc	Empty	The contents of NVRAMRC.
oem-banner	Empty string	A custom original equipment manufacturer (OEM) banner (enabled with oem-banner? true).
oem-banner?	False	If true, use custom OEM banner.
oem-logo	No default	A byte array custom OEM logo (enabled with oem-logo? true). Displayed in hexadecimal.
oem-logo?	False	If true, use custom OEM logo; otherwise, use the Sun logo.
output-device	Screen	A console output device (usually screen, ttya, or ttyb).
sbus-probe-list	0123	Which SBus slots to probe and in what order.
screen-#columns	80	The number of onscreen columns (characters/line).
screen-#rows	34	The number of onscreen rows (lines).
security-#badlogins	No default	The number of incorrect security password attempts.
security-mode	None	The firmware security level (options: none, command, or full).
security-password	No default	The firmware security password (which is never displayed).
use-nvramrc?	False	If true, execute commands in NVRAMRC during system startup.

Solaris Patching Procedure

2012-10-15T01:05:00.001-07:00

What is patch?

A patch fixes problems that prevent the proper execution of software. It is a collection of files and directories that replaces or updates existing files/binaries and directories.

Types of patches:

Standard Patches: Patches that fix problems with the Solaris OS and other SUN Hardware and Software products
Recommended Patches: Solaris OS patches that fix problems that might occur on a large percentage of systems. These include recommended security patches.
Firmware and PROM patches
Patch clusters: A groups of standard, recommended, security, or Y2K patches that have been bundled into a single archive for easy downloading and installation.

Ex: 105050-01

Patch number revision number

More patch definations:

Patches are categorized into the following types:

Critical: An E-Business Suite patch which is necessary for smooth functioning of the application. Critical patches should be installed immediately. Critical patches are always recommended.
General: A patch which is not in any other classification, typically these are one-off patches which solve a specific business issue for a customer.
Recommended: Any Critical, Security, Legislative and Recommended patches. It is highly recommended that users apply all recommended patches. .
Security: Patches that address security vulnerabilities in a product.
Legislative: These patches are necessary for accurate calculation of values which might have changed over time in the application (for example, tax tables for the new year, or withholding calculations for salaries).
Superseded: A patch that has been replaced by a more recent patch. The Superseded region lists the superseded patch and the replacement patch. You should use the replacement patch.
Note: You can search for a superseded patch if you know the bug number or patch ID. In addition, a product search will find a superseded patch.
Obsolete: A patch that has been retired. Use the patch listed under Replacement Options.
Note: You can search for an obsolete patch if you know the bug number or patch ID. Product searches do not find obsolete patches.

What is IDR (inter Diagnostic or relief)?

These are the customized patches provided by oracle (Formally Sun Microsystems), and also it is a temporary workaround solution for the issues but not a permanent fixes. These patches start with IDR.

Ex: IDR1153429-01

What is T-Patch?

T-patch is a Test Patch, and Oracle will provide T-patch when the organization having high priority issues with any specific bug and needs quick resolution.

General Procedure for Patching

We need to prepare patch document procedure with back-out plan, and needs to get the approval by change management. Once we get the approval, we can start our change in scheduled window
Before going to take the patch, first we need to take the backup of critical file systems like

/etc/system
/etc/vfstab
/etc/mnttab
df –h
echo|format
uptime

Check the existing patch version using

#showrev –p

#patchadd –p

#uname –a [if it is kernel patch]

Check /var/tmp directory space for our required patch

NOTE: In general we used to get patch problems by permissions issue. Hence we need to install the patches from /var/tmp [it contains 777 permission with stiky bit]. If in case of cluster patch we need more space to copy and run that patch. Here we can copy and run from any other directory, but make sure that directory permission should be 777

Download the patch from https://support.oracle.com by selecting HTML(New) option (or) supporthtml.oracle.com in “patches&update” tab by selecting “product, release,patchset” to our desktop and upload it into the /var/tmp directory.

NOTE: Before downloading our patch from MOS, we need to check our platform bit version by using
#isainfo -b

Before going to patch installation, we must read the “ReadMe.txt” file for more details
If system is in root mirroring, needs to detach one sub-mirror and then reboot the system into single user mode for patching

#shutdown –y –g0 –i1

Now we can patch the system by using patchadd command

#patchadd 119202-46

Once patch installation has completed, down the server into OBP prompt, and run reconfiguration reboot

#init 0

Ok>boot –r

Once system comes back to desired run-level, needs to compare all backed-up files with new files.
Check the “uptime” values, if it is more, then needs to check CPU utilization, if it is >60%

Put the server in observation for 3 days, if it’s not come down, needs to remove the patch by using

#patchrm 119202-46

Patch logs: /var/sadm/install_data/solaris_10_recommended_log

Patch errors:

0	No error
1	Usage error
2	Attempt to apply a patch that's already been applied
6	Patch is obsolete
8	Attempting to patch a package that is not installed

Failed Disk Replacement Under SVM

2012-10-15T00:48:00.001-07:00

1. Booting from the alternate root (/) submirror

Ok>boot disk2

2. Determining the erred state database replicas and volumes and take a copy of the all the metadevices related commands using metadb, metastat commands.

#metastat d54

d1: Mirror

Submirror 0: d4

State: Needs maintenance

Submirror 1: d14

State: Okay

Resync in progress: 15 % done

Pass: 1

Read option: roundrobin (default)

Write option: parallel (default)

Size: 2006130 blocks

# metastat -c

d54 m 5.0GB d4 d14

d4 s 5.0GB c0t0d0s4

d14 s 5.0GB c0t1d0s4

d53 m 8.0GB d3 d13

d3 s 8.0GB c0t0d0s3

d13 s 8.0GB c0t1d0s3

d56 m 24GB d6 d16

d6 s 24GB c0t0d0s6

d16 s 24GB c0t1d0s6

d55 m 5.0GB d5 d15

d5 s 5.0GB c0t0d0s5

d15 s 5.0GB c0t1d0s5

d51 m 8.0GB d1 d11

d1 s 8.0GB c0t0d0s1

d11 s 8.0GB c0t1d0s1

d50 m 8.0GB d0 d10

d0 s 8.0GB c0t0d0s0

d10 s 8.0GB c0t1d0s0

Needs maintenance: A problem has been detected. This requires that the system administrator tor replace the failed physical device. Volumes displaying Needs maintenance have incurred no data loss, although additional failures could risk data loss. Take action as quickly as possible.

3. Open up and incident record in Peregrine and also log a call with Vendor.

4. Dettach the bad hard drive using

#metadetach –f d54 d4

# metadetach –f d53 d3

# metadetach –f d56 d6

# metadetach –f d55 d5

# metadetach –f d51 d1

# metadetach –f d50 d0

5. Remove the usage from SVM control using [deletes a mirror, d11, with an sub mirror in an error state.

#metaclear –f d4

#metaclear –f d3

#metaclear –f d6

#metaclear –f d5

#metaclear –f d1

#metaclear –f d0

6. Check the status metadb status

#metadb –i

flags first blk block count

a w p luo 16 8192 /dev/dsk/c0t0d0s7

a w p luo 8208 8192 /dev/dsk/c0t0d0s7

a w p luo 16400 8192 /dev/dsk/c0t0d0s7

a m p luo 16 8192 /dev/dsk/c0t1d0s7

a p luo 8208 8192 /dev/dsk/c0t1d0s7

a p luo 16400 8192 /dev/dsk/c0t1d0s7

W - replica has device write errors

R - replica had device read errors

m- replica is master, this is replica selected as input

7. Remove metadata from the disk using

#metadb –f –d c0t0d0s7

8. copy partitions from the disk using [either we can copy from old or working disk] [OPTIONAL]

#prtvtoc /dev/rdsk/cxtxdxs2 >vtoc.file

9. Unconfigure the drive

#cfgadm –al

Ap_Id Type Receptacle Occupant Condition

c0 scsi-bus connected configured unknown

c0::dsk/c0t0d0 disk connected configured unknown

c0::dsk/c0t1d0 disk connected configured unknown

#cfgadm -c unconfigure c0::dsk/c0t0d0

The drive light turns blue

Pull the failed drive out

10. Halt the system, replace the disk. Use the format command or the fmthard command, to partition the disk as it was before the failure.

Without halting insert the new drive & configure the new disk

#cfgadm –c configure c0::dsk/c0t0d0

Now that the drive is configured and visible from within the format command, we can copy the partition table from the remaining mirror member

#prtvtoc /dev/rdsk/c0t1d0s2|fmthard –s - /dev/rdsk/ c0t0d0s2 (new disk)

11. Install bootblock on the new drive

#installboot /usr/platform/’uname –i’/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s2

12. Initialise the disk for SVM usage by using

#metainit -f d4 1 1 c0t0d0s4

#metainit -f d3 1 1 c0t0d0s3

#metainit -f d6 1 1 c0t0d0s6

#metainit -f d5 1 1 c0t0d0s5

#metainit -f d1 1 1 c0t0d0s1

#metainit -f d0 1 1 c0t0d0s0

13. Create metadb on new disk by using

Note: whenever we will use –a option, db info will automatically update in two files

a. /kernel/drv/md.conf

b. /etc/lvm/mddb.cf

We can define manually in the file /etc/lvm/md.tab file. See the instruction on that file

#metadb –a –c 3 c0t0d0s7

14. Re-enable the submirrors by using

#metattach d54 d4

#metattach d53 d3

#metattach d56 d6

#metattach d55 d5

#metattach d51 d1

#metattach d51 d0

15. After resync is done , boot the server from the repaired disk.

Check the sync status by using

#metastat d1

d54: Mirror

Submirror 0: d4

State: Resyncing

Resync in progress: 15 % done

Submirror 1: d14

State: Okey

Pass: 1

Read option: roundrobin (default)

Write option: parallel (default)

Size: 2006130 blocks

Stopping the VERITAS GUI process ID

2012-10-15T00:32:00.004-07:00

Reason:

We will be disabling the VERITAS.vxsvc process as it’s a VERITAS GUI process and consumes more CPU and Memory utilization of the server. However, we have not been using VERITAS GUI for cluster activities.

Process

1. Check the process ID using below command

#ps -ef|grep vxsvc

#/opt/VRTS/bin/vxsvcctrl status

Current state of server : RUNNING

2. Stop the running process

# /etc/init.d/isisd stop [or] # /opt/VRTSob/bin/vxsvc –k

3. Check the process status

#ps -ef|grep vxsvc [if still, process is present]

#kill -9 <pid> [kill the process]

#more /var/vx/isis/vxisis.lock [if it is showing any PID, kill again and delete the file]

#rm /var/vx/isis/vxisis.lock

4. Stop vxsvc from starting on bootup. The Veritas GUI Admin will run automatically on boot-up. To stop it from starting again on rebooting a server, remove the following start-up files

#mkdir -p /etc/rc0.d/GUI

#mv /etc/rc0.d/K50isisd /etc/rc0.d/GUI/K50isisd.28052011

#mkdir -p /etc/rc2.d/GUI

#mv /etc/rc2.d/S73isisd /etc/rc2.d/GUI/S73isisd.28052011

# mkdir -p /etc/rcS.d/GUI

#mv /etc/rcS.d/K50isisd /etc/rcS.d/GUI/K50isisd.28052011

5. Check the CPU usage status

#top

#ps -ef|grep vxsvc

#/opt/VRTS/bin/vxsvcctrl status

Different Ways to Check Memory Usage on Solaris Server

2012-10-10T03:18:00.002-07:00

Seat Arrangement

2012-10-10T00:52:00.001-07:00

Veritas Explorer Installation & Running Procedure

2011-07-28T04:50:00.000-07:00

VERITAS Explorer Installation:

VRTSspt is a group of support tools for troubleshooting a system and collecting information on its configuration. Note that this package is optional: the tools are not required for operation of any Veritas software. In general, these tools only gather configuration information; however, they may significantly impact system performance while doing so. They are designed to be used under the direction of a Veritas Technical Support Engineer only. Any other use of these tools is at your own risk.

To download VRTSspt , follow the below instructions:

1. Connect to the FTP site:

# ftp ftp.veritas.com
The below message appears with a prompt for a login name. Login as "symsupport" with password "iS*pp8rT1".

Connected to ftp.veritas.com
220-ftp
220-***********************************************************************
220- This system is for the use of authorized users only. Individuals
220- using this computer system without authority, or in excess of their
220- authority, are subject to having all of their activities on this
220- system monitored and recorded.
220- In the course of monitoring individuals improperly using this
220- system, or in the course of system maintenance, the activities of
220- authorized users also are monitored.
220- Anyone using this system expressly consents to such monitoring
220- and recording. Please be advised that unauthorized access to this
220- system is a violation of State and Federal law. If monitoring
220- reveals possible evidence of criminal activity, system personnel
220- may provide that evidence to law enforcement officials.
220-***********************************************************************
220
Name (ftp.veritas.com <ftp://ftp.veritas.com/>): symsupport
331 User symsupport okay, need password.
Password: iS*pp8rT1
230 Restricted user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

You are now logged into the ftp.veritas.com FTP server. This is a "blind site", which means it is no possible to list any of the files or directories. It is important that the below steps are followed exactly:

2. Change directories to /pub/support:

ftp> cd /pub/support

3. Set FTP mode to binary:

ftp> bin

4. Download the appropriate compressed tar file depending on the operating system in use:

IBM AIX: VRTSspt-aix.tar.gzHP-UX (11.23 and above): VRTSspt-hpux.tar.gzHP-UX (11.11 and below): VRTSspt-hpux.tar.ZLinux: VRTSspt-linux.tar.gzSun Solaris (SPARC): VRTSspt-sol.tar.gzSun Solaris (x64): VRTSspt-solx64.tar.gz

For example, to get the Solaris (SPARC) version:
ftp> get VRTSspt-sol.tar.gz

5. Close the FTP connection

ftp> bye

Uncompress, Un-tar the download and install the Support Tools:

1. Uncompress the tarball:

# gunzip VRTSspt-*.gz

2. Un-tar the downloaded file:

# tar xf VRTSspt-*.tar

3. Refer to the README file for installation instructions:

# more README.VRTSspt

metasave

- gathers metadata from a Veritas File System

vxbench

- generates various I/Os for benchmarking file system performance

VRTSexplorer

- gathers configuration information about the system and any installed Veritas products

FirstLook

- collects time correlated performance information using standard tools

To install the package, change directory to the location of the package on CD, and then use the command:

# pkgadd -d . VRTSspt

This installs VRTSspt in the /opt directory, taking up approximately 1 Mbyte of disk space. To remove the package, use:

# pkgrm VRTSspt

4. Once VRTSspt package have installed, you can see below information

# pwd

/opt/VRTSspt

# ls

FirstLook FS README.VRTSspt VRTSexplorer

Latest VERITAS Explorer Installation Procedure & Running Procedure:

VRTSexplorer , also known as Veritas Explorer, VxExplorer, vxexplorer, and vxexplore, is a tool provided by Symantec Corporation Technical Support that is executed on a host to gather some of the information that may be needed by a Support Engineer to troubleshoot an issue. The output of this utility is a compressed tar file that must be sent to Support. The information collected may not be sufficient to resolve the issue, but it is likely to give very relevant information about it. This utility will run on Solaris, Solaris x64, SUSE Linux, Red Hat Linux, AIX, and HP-UX.

Note: No user data is collected by the VRTSexplorer utility. Only the technical information about some server configuration and the installed Veritas products are collected. For the exact information that is collected by the VRTSexplorer utility, and other additional information refer to the README located in the VRTSexplorer directory after downloading and untarring.

The use of VRTSexplorer utility involves three different steps:

1.      Obtaining VRTSexplorer
2.      Executing the VRTSexplorer binary
3.      Sending the output to Symantec Technical Support

These steps are detailed below:

1. Obtaining the package that contains the VRTSexplorer utility:

Note: The VRTSexplorer utility is packaged with the Symantec Support Tools, VRTSspt, package which is included on the product CDs and available for download. If this package is installed on the host, this step can be skipped unless the latest VRTSexplorer utility is to be run, as the utility is located in the /opt/VRTSspt/VRTSexplorer directory. For more information about the Symantec Support Tools package and the tools that it contains (VRTSexplorer, FirstLook, metasave, vxbench, etc.), please refer to the Related Documents section below. Otherwise, the VRTSexplorer utility must be downloaded from the Symantec FTP site. The latest version will always be on the FTP site. The package can be downloaded and the binary executed from any directory. However, to remain consistent with installed applications, extract the package in the /opt directory.

To download the VRTSexplorer utility, follow the below instructions:

Connect to the FTP site:
# ftp ftp.veritas.com

The below message appears with a prompt for a login name. Log in as the user symsupport with password iS*pp8rT1
Connected to ftp.veritas.com
220-ftp
220-***********************************************************************
220- This system is for the use of authorized users only. Individuals
220- using this computer system without authority, or in excess of their
220- authority, are subject to having all of their activities on this
220- system monitored and recorded.
220- In the course of monitoring individuals improperly using this
220- system, or in the course of system maintenance, the activities of
220- authorized users also are monitored.
220- Anyone using this system expressly consents to such monitoring
220- and recording. Please be advised that unauthorized access to this
220- system is a violation of State and Federal law. If monitoring
220- reveals possible evidence of criminal activity, system personnel
220- may provide that evidence to law enforcement officials.
220-***********************************************************************
220
Name (ftp.veritas.com <ftp://ftp.veritas.com/>): symsupport
331 User symsupport okay, need password.
Password: iS*pp8rT1
230 Restricted user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

While logged into the FTP server as the user symsupport, it is not possible to list any files or directories. It is important that the below steps are followed exactly:

Change directories to /pub/support:
ftp> cd /pub/support

Set FTP mode to binary:
ftp> bin
Download the file that contains utility:
ftp> get vxexplore.tar.Z
Close the ftp connection: ftp> bye
Untar the download:

Untar the downloaded file (only if the VRTSexplorer utility has been downloaded and not installed with the VRTSspt package) : # zcat vxexplore.tar.Z | tar xvf -
The above command will create a VRTSexplorer directory containing everything that is needed. Change into this directory:
# cd VRTSexplorer

2. Execute the VRTSexplorer utility:

Some notes on the execution of VRTSexplorer:
·      To determine the version of VRTSexplorer that is on the host, along with other options, execute # ./VRTSexplorer -help:# ./VRTSexplorer -helpVRTSexplorer: version 5.5y
·      To run the VRTSexplorer utility for only one particular product, such as Veritas Volume Manager, execute:
# ./VRTSexplorer vxvm
·      To run the VRTSexplorer utility to exclude a particular product, such as Veritas NetBackup, execute:# ./VRTSexplorer -nbuRefer to the README file for additional options that are available with the VRTSexplorer utility.

The below messages will appear requesting input for the case number, destination directory (BE CAREFUL TO NOT USE SPACES OR OTHER SPECIAL CHARACTERS IN THE DIRECTORY YOU SPECIFY!), restart of vxconfigd (do not choose to do this if PowerPath is installed or if this is a node in a cluster), etc. The program will output several messages and finish by tarring and compressing the collected information. Please note that this operation can take some time to complete.

Below is partial example of what might be seen (the messages below are from VRTSexplorer version 5.5o and will be different from earlier versions of the utility) when executing the VRTSexplorer utility to gather information about a host, output is dependant on which product packages are installed:

# ./VRTSexplorer
VRTSexplorer: Initializing.
VRTSexplorer: Please enter case number, or just hit enter: 150-175-206VRTSexplorer: Please select a destination directory (default: /tmp): /tmpVRTSexplorer: Using /tmp as destination directory.
VRTSexplorer: Collecting system configuration information for SunOS system.
VRTSexplorer: Collecting VERITAS package version information.
VRTSexplorer: Collecting loadable module information.
VRTSexplorer: Collecting SLIM information.
VRTSexplorer: Collecting SLIM Agent installer logs.
VRTSexplorer: Collecting SLIM Server installer logs.
VRTSexplorer: Collecting Cross Product/Platform Installation (CPI) information.
VRTSexplorer: Collecting ISIS configuration information.
VRTSexplorer: Collecting VERITAS SANPoint Control Console configuration information.

##### All information and files will be placed under /tmp/VRTSexplorer_150-175-206_server1/spc
Logfile is /tmp/VRTSexplorer_150-175-206_server1/spc/LOG
##### Capturing SAL/VAIL/VEA information from host server1'
##### Saving VERITAS Package Information..........
##### Logging VEA Information #####
+Copying vxisis.log files.
+Copying /var/vx/isis vxsvc corefiles
+Copying /opt/VRTSob/bin vxsvc corefiles
##### Logging VRTSvail Information #####
Checksum /opt/VRTSvail/providers/vx*:...............
##### Saving Detailed information for all VERITAS packages..........................
##### Saving Host syslogs #####
+Copying syslog files.....
VRTSexplorer: Collecting SIG licensing information.
VRTSexplorer: Collecting VRW configuration information.
VRTSexplorer: Collecting VxFS configuration information.
VRTSexplorer: Determining current VxVM operating mode.
VRTSexplorer: Collecting VxVM configuration information.
VRTSexplorer: Collecting DMP configuration information.

NOTICE: This section will stop and restart the VxVM Configuration Daemon,
vxconfigd. This may cause your VxVA, VMSA and/or VEA session to exit.
This may also cause a momentary stoppage of any VxVM configuration
actions. This should not harm any data; however, it may cause some
configuration operations (e.g. moving subdisks, plex
resynchronization) to abort unexpectedly. Any VxVM configuration
changes should be completed before running this section.

If you are using EMC PowerPath devices with Veritas Volume Manager,
you must run the EMC command(s) 'powervxvm setup' (or 'safevxvm
setup') and/or 'powervxvm online' (or 'safevxvm online') if this
script terminates abnormally.

Restart VxVM Configuration Daemon? [y,n] (default: n) n
VRTSexplorer: Collecting VRAS configuration information.
VRTSexplorer: Collecting Web GUI Engine information.
VRTSexplorer: Collecting Cross Product/Platform Installation (CPI) information.
VRTSexplorer: Script finished.

VRTSexplorer: The cksum for the tarfile is:
2113302371 2569248 /tmp/VRTSexplorer_150-175-206_server1.tar.gz

VRTSexplorer: Please ftp /tmp/VRTSexplorer_150-175-206_server1.tar.gz
VRTSexplorer: to ftp.veritas.com:/incoming or work with your
VRTSexplorer: support representative for other upload options.
#

3. Send the file created above to Symantec Technical Support:

Example:

Change directory to the destination directory (default: /tmp):# cd /tmp

Connect to the FTP site:
# ftp ftp.veritas.com

The below message appears with a prompt for a login name. Log in as the user symsupport with password iS*pp8rT1
Connected to ftp.veritas.com
220-ftp
220-***********************************************************************
220- This system is for the use of authorized users only. Individuals
220- using this computer system without authority, or in excess of their
220- authority, are subject to having all of their activities on this
220- system monitored and recorded.
220- In the course of monitoring individuals improperly using this
220- system, or in the course of system maintenance, the activities of
220- authorized users also are monitored.
220- Anyone using this system expressly consents to such monitoring
220- and recording. Please be advised that unauthorized access to this
220- system is a violation of State and Federal law. If monitoring
220- reveals possible evidence of criminal activity, system personnel
220- may provide that evidence to law enforcement officials.
220-***********************************************************************
220
Name (ftp.veritas.com <ftp://ftp.veritas.com/>): symsupport331 User symsupport okay, need password.
Password: iS*pp8rT1
230 Restricted user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

While logged into the FTP server as the user symsupport, it is not possible to list any files or directories. It is important that the below steps are followed exactly:

Change into the /incoming directory:
ftp> cd /incoming
Set FTP mode to binary:
ftp> bin
Upload the file that was created above:
ftp> put VRTSexplorer_150-175-206_server1.tar.gz
Close the ftp connection: ftp> bye
If this is an existing case, call or email the Technical Support Engineer assigned to the case to let them know the VRTSexplorer data is available along with the name of the file that was uploaded. If a case has not been created for the issue, contact Technical Support via your local support hotline to create a new case, or create a new case on the Web via MySupport at https://mysupport.symantec.com/ and provide the name of the file that was uploaded along with a description of the issue.

Note: The SORT Data Collector VxExplorer will supersede Symantec's VRTSexplorer utility. For more information, see "How do I run a VxExplorer report?" in the SORT online help: https://sort.symantec.com/public/help/wwhelp/wwhimpl/js/html/wwhelp.htm

Notes on collecting I/O Fencing Driver (vxfen) information

Please note that by default, the script to collect vxfen related information (named as "vxfen") will try to collect information from all nodes in the cluster by using "rsh". If the remote nodes are not setup with rsh access permission, VRTSexplorer may hang in the execution of "rsh" command until network timeout. The may cause a delay of several minutes depending on the network setup.

If the remote systems in the cluster are not setup with rsh access permission, please add the following option to the vxfen command in the main program of the VRTSexplorer. The VRTSexplorer main program is named as "main.<ostype>". For example, on Solaris platform, the main program is called "main.SunOS".

# pwd
/opt/VRTSspt/VRTSexplorer
# ls -l main.SunOS vxfen
-r-xr--r-- 1 root other 13133 Jun 2 2006 main.SunOS <<< VRTSexplorer main program
-r-xr-xr-x 1 root other 8299 May 11 2006 vxfen <<< vxfen script to collect vxfen related information

Please modify the main.<ostype> script from

                VRTSvxfen*)
                        if doit vxfen
                        then
                                $PROGDIR/vxfen
                        fi;;
to

                VRTSvxfen*)
                        if doit vxfen
                        then
                                $PROGDIR/vxfen -local
                        fi;;

With the "-local" option, the vxfen script will not try to access the remote nodes in the cluster

How to force VRTSexplorer to continue to collect rest of the information if it hangs at a particular collection script

In some cases system malfunction may cause VRTSexplorer to hang in a particular information collection script.

For example, if "vxdctl enable" command hangs, it may cause VRTSexplorer to hang.

# /opt/VRTSspt/VRTSexplorer/VRTSexplorer
VRTSexplorer: Initializing.
VRTSexplorer: Please enter case number, or just hit enter: 999-999-999
VRTSexplorer: Please select a destination directory (default: /tmp):
VRTSexplorer: Using /tmp as destination directory.
VRTSexplorer: Collecting system configuration information for SunOS system.

.....

VRTSexplorer: Collecting VxFS configuration information.
VRTSexplorer: Determining current VxVM operating mode. <<< VRTSexplorer hangs in collection VxVM information

If this happens, please try to find out the command that causes VRTSexplorer to hang and kill that very last command executed by VRTSexplorer, so that VRTSexplorer will continue to collect the rest of the information. For example, in the following example, VRTSexplorer hangs at "vxdctl enable".

# ps -eaf | grep VRTSexplorer
root 10365 10343 0 21:47:03 pts/1 0:00 /bin/sh -- /opt/VRTSspt/VRTSexplorer/main.SunOS
root 10343 9800 0 21:46:59 pts/1 0:00 /bin/sh -- /opt/VRTSspt/VRTSexplorer/VRTSexplorer <<< VRTSexplorer command

On Solaris we can use ptree to print the processes spawned by the VRTSexplorer command.

# ptree 10343
        10343 /bin/sh -- /opt/VRTSspt/VRTSexplorer/VRTSexplorer
             10365 /bin/sh -- /opt/VRTSspt/VRTSexplorer/main.SunOS
                 14567 /bin/sh -- /opt/VRTSspt/VRTSexplorer/vxvm
                      14569 /usr/sbin/vxdctl mode              <<< if this command hangs

Please try to kill the very last command exectute by VRTSexplorer, so that it can continue to collect the rest of the information.

# kill -15 14569

The following are the "ps" command options to print the process tree on other platforms.

HP-UX:

Get the process session ID of the process and use option "-H" to print the process hierarchy.

# UNIX95=1 ps -eafj | grep VRTSexplorer

# UNIX95=1 ps -H -fj -s <session ID>

For example,

# UNIX95=1 ps -eafj | grep VRTSexplorer
UID PID PPID PGID SID C STIME TTY TIME CMD
root 13658 12296 13658 12295 0 03:06:30 pts/tb 00:00:00 /bin/sh -- /opt/VRTSspt/VRTSexplorer/VRTSexplorer

# UNIX95=1 ps -H -fj -s 12295
UID        PID PPID PGID   SID C    STIME TTY          TIME CMD
root     13658 12296 13658 12295 0 03:06:30 pts/tb   00:00:00     /bin/sh -- /opt/VRTSspt/VRTSexplorer/VRTSexplorer
root     14104 13658 14104 12295 0 03:07:34 pts/tb   00:00:00       /bin/sh -- /opt/VRTSspt/VRTSexplorer/main.HPUX
root     14105 14104 14104 12295 0 03:07:34 pts/tb   00:00:52         /bin/sh -- /opt/VRTSspt/VRTSexplorer/vxvm

AIX:

"ps" option -T will cause ps to print the process hierarchy.

# ps -fT 561322
     UID    PID   PPID   C    STIME    TTY TIME CMD
    root 561322 327830   0 10:46:33 pts/1 0:00 /bin/sh -- ./VRTSexplorer
    root 618510 561322   0 10:46:44 pts/1 0:00     \--/bin/sh -- /opt/VRTSspt/VRTSexplorer/./main.AIX
    root 520346 618510   0 10:49:49 pts/1 0:00         \--/bin/sh -- /opt/VRTSspt/VRTSexplorer/./vxvm

Linux:

Get the process session ID of the process and use option "--forest" to print the process hierarchy.

# ps -eafj | grep VRTSexplorer
root      5825 5823 5825 5825 0 03:16 pts/17   00:00:00 /bin/sh -- /opt/VRTSspt/VRTSexplorer/VRTSexplorer
root      5849 5825 5849 5825 0 03:17 pts/17   00:00:00 /bin/sh -- /opt/VRTSspt/VRTSexplorer/main.LINUX

# ps -fj -g 5828 --forest
UID        PID PPID PGID   SID C STIME TTY          TIME CMD
root      5825 5823 5825 5825 0 03:16 pts/17   00:00:00 /bin/sh -- /opt/VRTSspt/VRTSexplorer/VRTSexplorer
root      5849 5825 5849 5825 0 03:16 pts/17   00:00:00 \_ /bin/sh -- /opt/VRTSspt/VRTSexplorer/main.LINUX
root      5876 5849 5876 5825 0 03:17 pts/17   00:00:00      \_ /bin/sh -- /opt/VRTSspt/VRTSexplorer/vxvm