unixpowered.com » solaris utilities http://www.unixpowered.com/blog Wed, 21 Jul 2010 13:42:57 +0000 http://wordpress.org/?v=abc en hourly 1 Installing and patching Data Protector client on standalone Solaris machine http://www.unixpowered.com/blog/2010/05/07/installing-and-patching-data-protector-client-on-standalone-solaris-machine/ http://www.unixpowered.com/blog/2010/05/07/installing-and-patching-data-protector-client-on-standalone-solaris-machine/#comments Fri, 07 May 2010 16:24:39 +0000 somedude http://www.unixpowered.com/blog/?p=473 I needed to install HP Data Protector 5.5 client on an old machine running Solaris 2.6. I also needed to apply some Data Protector patches to that machine. The problem was I had no Data Protector Install Server for Data Protector version 5.5.

Normally, Data Protector clients are installed from Data Protector Install Server. When you need to deploy patches, first you patch the Install Server and then you push out patches to you Data Protector clients.

Installing the client itself on standalone machine is not a big deal. All you need is an appropriate Data Protector software depot and off you go. The problem was installing patches without the Install Server.

Here is the process I took installing and patching this machine:

B6960-15041_DP55_HPUX_PA_IS_CD.tar – HPUX Install Server – contains Solaris 2.6 client
DPSOL_00168.zip – Patch
DPSOL_00180.zip – Patch

First, I decompressed Data Protector software depot that contains Solaris 2.6 client and installed Disk Agent on the machine:

root@client # tar xf B6960-15041_DP55_HPUX_PA_IS_CD.tar
root@client # cd LOCAL_INSTALL
root@client # ./omnisetup.sh -install da

After that was done, it was time to patch Data Protector installation. First, I decompressed the patch archive. Then I located and decompressed the proper packet.Z file for Solaris 2.6:

root@client # unzip DPSOL_00168.zip
root@client # cd OB2-SOLUX/root/opt/omni/databases/vendor/da/sun/sparc/solaris-26/A.05.50/
root@client # uncompress packet.Z

Finally I installed the packet, which is really Solaris package:

root@client # pkgadd -d ./packet all

The whole patch process has to be repeated for all patches you are trying to install. Note, that when you unzip the patch, you kind of have to know what you are looking for, so you need to pay attention to the PATH to packet.Z file; i.e. in the above case I was installing Data Agent patch on a Sun box, running Solaris 2.6 and Data Protector version 5.5.

]]> http://www.unixpowered.com/blog/2010/05/07/installing-and-patching-data-protector-client-on-standalone-solaris-machine/feed/ 0 Trussing processes on Sun Cluster? http://www.unixpowered.com/blog/2010/04/02/trussing-processes-on-sun-cluster/ http://www.unixpowered.com/blog/2010/04/02/trussing-processes-on-sun-cluster/#comments Fri, 02 Apr 2010 15:41:02 +0000 somedude http://www.unixpowered.com/blog/?p=461 One of the apps running on Sun Cluster was randomly crashing. So, I decided to take a look what was happening. Yeah, there is DTrace in Solaris 10. Since I am pretty comfortable with truss I decided to give that a shot first:

root@node1 # truss -p 27462
truss: process is traced: 27462
root@node1 #

That’s it. No truss output, nothing. That was weird. truss will not work if there is a debugger attached to the process to be traced, which was not the case. So, I figured it might have something to do with the fact that the process is handled by the cluster software.

Finaly, NOTES section of pmfadm manpage gave me the answer:

To avoid collisions with other controlling processes. truss(1) does not allow tracing a process that it detects as being controlled by another process by way of the /proc interface. Since rpc.pmfd(1M) uses the /proc interface to monitor processes and their descendents, those processes that are submitted to rpc.pmfd by way of pmfadm cannot be traced or debugged.

So, Dtrace it was. Thankfully, Brendan Gregg already did the hard work for me, by creating DTrace version of truss. The more you know…

]]> http://www.unixpowered.com/blog/2010/04/02/trussing-processes-on-sun-cluster/feed/ 0 Quick and dirty SVM cheatsheet http://www.unixpowered.com/blog/2009/12/03/quick-and-dirty-svm-cheatsheet/ http://www.unixpowered.com/blog/2009/12/03/quick-and-dirty-svm-cheatsheet/#comments Thu, 03 Dec 2009 12:50:43 +0000 somedude http://www.unixpowered.com/blog/?p=372 This list focuses mostly on mirror operations. I use Solaris Volume Manager quite a bit when mirroring internal drives. There are tons of additional features and commands, if you use SVM for  things other than mirroring. In that case you might want to look at check out Solaris Volume Manager Administration Guide.

Create database replicas:
metadb -f -a -c [number_of_replicas] [device]
metadb -f -a -c 3 c0t0d0s7

Delete all database replicas from device:
metadb -d [device]
metadb -d c0t0d0s7

Display status of database replicas:
metadb -i
metadb -i

Display metadevice status:
metastat
metastat

Create simple concat/stripe metadevice:
metainit -f [concat_metadevice] 1 1 [device]
metainit -f d21 1 1 c0t0d0s1

Create a mirror with one submirror:
metainit [mirror_metadevice] -m [submirror_metadevice]
metainit d20 -m d21

Attach a submirror to one sided mirror:
metattach [mirror_metadevice] [submirror_metadevice]
metattach d20 d22

Detach a submirror from a mirror:
metadetach [mirror_metadevice] [submirror_metadevice]
metadetach d20 d22

Clear a metadevice:
metaclear [metadevice]
metaclear d22

Offline a submirror:
metaoffline [mirror_metadevice] [submirror_metadevice]
metaoffline d20 d22

Online a submirror:
metaonline [mirror_metadevice] [submirror_metadevice]
metaonline d20 d22

Enable a failed component:
metareplace -e [metadevice] [device]
metareplace -e d21 c0t0d0s1

Rename a metadevice:
metarename [old_metadevice] [new_metadevice]
metarename d20 d30

Switch metadevice names:
metarename [metadevice_1] [metadevice_2]
metarename -x d20 d30

Configure system for root metadevice:
metaroot [metadevice]
metaroot d10

]]> http://www.unixpowered.com/blog/2009/12/03/quick-and-dirty-svm-cheatsheet/feed/ 0 Corrupt superblock, now what? http://www.unixpowered.com/blog/2009/09/17/corrupt-superblock-now-what/ http://www.unixpowered.com/blog/2009/09/17/corrupt-superblock-now-what/#comments Thu, 17 Sep 2009 19:41:54 +0000 somedude http://wayciak.wordpress.com/?p=283 This is an oldie, but a goodie. For some reason I was asked about it 3 times in a span of a week. Suppose your system was not shut down cleanly and it refuses to come up. During bootup fsck refuses to run, complaining about corrupt superblock. So, what do you do? First, get the alternate superblock locations and then run fsck using one of the alternate superblocks.

To get alternate superblock locations do:

newfs -Nv /dev/rdsk/c0t0d0s3

This will not actually format the slice. It will only print what it would do, if it was actually formating the slice. Basically, it is newfs dry run. It will also give you locations of alternate superblocks on the slice. I guess it should be mentioned that if you used non-default values while formating the slice originally, and you did not make a note of those values, this might not give you valid superblock numbers.

After you have your alternate superblock numbers you can use them to help out fsck (in this case superblock I am using is in block 8192):

fsck -y -F ufs -o b=8192 /dev/rdsk/c0t0d0s3

It might not hurt to run the above with -n option instead of -y to make sure it produces the results you are looking for.

Hopefully, the filesystem is not hosed so badly that it can not be repaired. This was more of an issue when Solaris did not have ufs logging. Nevertheless, it does not hurt to know this for one of those emergencies.

]]> http://www.unixpowered.com/blog/2009/09/17/corrupt-superblock-now-what/feed/ 0 Getting handle on log files http://www.unixpowered.com/blog/2009/04/13/getting-handle-on-log-files/ http://www.unixpowered.com/blog/2009/04/13/getting-handle-on-log-files/#comments Mon, 13 Apr 2009 17:44:02 +0000 somedude http://wayciak.wordpress.com/?p=186 Starting with Solaris 9 there is a very handy tool called logadm that makes management of any log files a breeze. Syslog and messages files, among others, are managed by logadm which is called from root’s crontab.
Logadm reads /etc/logadm.conf file to figure out what it needs to do. By default there are following entries in logadm.conf:

/var/log/syslog -C 8 -P 'Wed Apr 8 02:10:22 2009' -a 'kill -HUP `cat /var/run/syslog.pid`'
/var/adm/messages -C 4 -P 'Fri Apr 10 02:10:15 2009' -a 'kill -HUP `cat /var/run/syslog.pid`'
/var/cron/log -c -s 512k -t /var/cron/olog
/var/lp/logs/lpsched -C 2 -N -t '$file.$N'
/var/fm/fmd/errlog -M '/usr/sbin/fmadm -q rotate errlog && mv /var/fm/fmd/errlog.0- $nfile' -N -s 2m
smf_logs -C 8 -s 1m /var/svc/log/*.log
/var/adm/pacct -C 0 -N -a '/usr/lib/acct/accton pacct' -g adm -m 664 -o adm -p never
/var/log/pool/poold -N -a 'pkill -HUP poold; true' -s 512k

Logadm provides -w switch which will write an entry into logadm.conf file that reflects current command line arguments. Of course logadm.conf can be edited using text editor, if that is the preferred method. If that’s the case, -V option can validate syntax of logadm.conf for you. Another handy option is -n which will cause logadm to do a dry run without actually performing the log rotation.

Other useful switches are:

  • -b and -a which allow specification of pre and post rotation commands to execute
  • -e sends error messages to a specific address instead of sending it to the owner of the crontab
  • -r removes entry from logadm.conf for a specific log file
  • -o sets different owner for the new log file from the original
  • -g sets different group for the new log file from the original
  • -m sets different permissions for the new log file from the original

For the whole story on logadm check out logadm man page.

]]> http://www.unixpowered.com/blog/2009/04/13/getting-handle-on-log-files/feed/ 0 Solaris Link Aggregation http://www.unixpowered.com/blog/2009/03/22/solaris-link-aggregation/ http://www.unixpowered.com/blog/2009/03/22/solaris-link-aggregation/#comments Sun, 22 Mar 2009 11:19:44 +0000 somedude http://wayciak.wordpress.com/?p=116 Link aggregation takes a bunch of network interfaces and creates a big pipe out of them.

Aggregation also provides redundancy. If all interfaces but one go down, the server will remain connected to the network.

Before starting make sure that:

  • interfaces to be aggregated are of the following type: xge, e1000g, and bge
  • interfaces to be aggregated are not plumbed
  • they run in full duplex mode at the same speeds
  • eeprom’s local-mac-address? variable is set to true

The following will create aggr1 interface with bge1 as one of its members:

bash-3.00# dladm create-aggr -d bge1 1

Next plumb the aggregate interface, configure an IP address on it and bring it up:

bash-3.00# ifconfig aggr1 plumb 192.168.1.5 netmask 255.255.255.0 up

At this point you can list aggregations:

bash-3.00# dladm show-aggr
key: 1 (0x0001) policy: L4      address: 0:3:ba:56:7f:ba (auto)
           device       address                 speed           duplex  link    state
           bge1         0:3:ba:56:7f:ba   0     Mbps    unknown down    standby

Now add bge0 as a second member of aggr1 aggregation interface and list aggregate interfaces:

bash-3.00# dladm add-aggr -d bge0 1
bash-3.00# dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:3:ba:56:7f:ba (auto)
           device       address                 speed           duplex  link    state
           bge1         0:3:ba:56:7f:ba   0     Mbps    unknown down    standby
           bge0         0:3:ba:56:7f:b9   1000  Mbps    full    up      attached

To keep the configuration persistent across reboots, create /etc/hostname.aggr1 with appropriate content and remove any hostname.* files pertaining to the interfaces that are now members of aggr1.

To have link aggregation working properly you need to have the switch to which server is connected to properly configured with LACP.

Another thing to consider is load balancing policy for outgoing traffic. You can load balance on layers 2,3 and 4. Load balancing policy can be changed using dladm command. Here is a quick example that will modify load balancing policy to combination of L3 and L4:

bash-3.00# dladm modify-aggr -P L3,L4 1
bash-3.00# dladm show-aggr -L
key: 1 (0x0001) policy: L3,L4 address: 0:3:ba:56:7f:ba (auto)
                LACP mode: off  LACP timer: short
    device    activity timeout aggregatable sync  coll dist defaulted expired
    bge1      passive  short   yes          no    no   no   no        no
    bge0      passive  short   yes          no    no   no   no        no

And finally, command that will allow you to see utilisation of individual links within aggregation. Note the %ipkts column, I did not have LACP turned on on the switch at that time:

bash-3.00# dladm show-aggr -s
key: 1  ipackets  rbytes      opackets   obytes          %ipkts %opkts
           Total        2723785   2287233197  1481682   710633551
           bge1 618712    115674760   870443    636559150       22.7    58.7
           bge0 2105073   2171558437  611239    74074401        77.3    41.3

More info on link aggregation is here.

]]> http://www.unixpowered.com/blog/2009/03/22/solaris-link-aggregation/feed/ 0 Basic IPMP http://www.unixpowered.com/blog/2009/01/26/basic-ipmp/ http://www.unixpowered.com/blog/2009/01/26/basic-ipmp/#comments Mon, 26 Jan 2009 18:52:16 +0000 somedude http://wayciak.wordpress.com/?p=111 Finally, I got tired of remembering which network interfaces is configured on my Netra test box. So I do not have to remember which interface to plug cable into I configured IPMP on the box. IPMP provides link redundancy among multiple network interfaces in multipathing group. IPMP is not meant to be full fledged load balancing solution, though it will spread outgoing traffic across the interfaces.

I have put my two hme interfaces into a multipathing group. The group has a failover IP address assigned to it. Initially this address will be assigned to hme0. If hme0 fails, the address will automatically move to the other interface in the failover group.

First I edited /etc/hostname.hme0:

unreal-hme0 netmask + broadcast + deprecated -failover group unrealgrp1 up addif unreal netmask + broadcast + failover up

This configures physical hme0 with IP address of 192.168.11.6, which will not fail over and puts hme0 in unrealgrp1 multipathing group. It will additionally configure a virtual IP address of 192.168.11.5 which will failover when hme0 link goes down. Deprecated means the IP address 192.168.11.5 will not be used as source address for any outgoing packets.

Then I edited /etc/hostname.hme1:

unreal-hme1 netmask + broadcast + deprecated -failover group unrealgrp1 up

Similarly, hme1 will be configured with IP address of 192.168.11.7 and as a member of unrealgrp1 multipathing group. Again, 192.168.11.7 is marked as deprecated so it will not be used for outgoing packets. Finally I made sure my hosts file is correct:

bash-3.00# cat /etc/hosts
127.0.0.1 localhost
192.168.11.5 unreal loghost
192.168.11.6 unreal-hme0
192.168.11.7 unreal-hme1

And here is the result:

bash-3.00# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
hme0: flags=9040843 mtu 1500 index 2
inet 192.168.11.6 netmask ffffff00 broadcast 192.168.11.255
groupname unrealgrp1
ether 8:0:20:d9:ac:c
hme0:1: flags=1000843 mtu 1500 index 2
inet 192.168.11.5 netmask ffffff00 broadcast 192.168.11.255
hme1: flags=19040803 mtu 1500 index 3
inet 192.168.11.7 netmask ffffff00 broadcast 192.168.11.255
groupname unrealgrp1
ether 8:0:20:d9:ac:d

Essentially IP address 192.168.11.5 “floats” among interfaces. If I were to unplug hme0, 192.168.11.5 would fail over to hme1. Failure is detected on link loss. There are some tunable parameters in /etc/default/mpathd.

This is all I needed. Of course, there is much more to IPMP: you can setup test system, that your system will test for reachability, detection of interfaces missing on boot, etc. Sun has much more info on it here.

]]> http://www.unixpowered.com/blog/2009/01/26/basic-ipmp/feed/ 0 Quick and dirty ZFS cheatsheet http://www.unixpowered.com/blog/2008/12/20/quick-and-dirty-zfs-cheatsheet/ http://www.unixpowered.com/blog/2008/12/20/quick-and-dirty-zfs-cheatsheet/#comments Sat, 20 Dec 2008 15:53:38 +0000 somedude http://wayciak.wordpress.com/?p=104 Create simple striped pool:
zpool create [pool_name] [device] [device] ...
zpool create datapool c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0

Create mirrored pool:
zpool create [pool_name] mirror [device] [device] ...
zpool create datapool mirror c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0

Create Raid-Z pool:
zpool create [pool_name] raidz [device] [device] [device] ...
zpool create datapool raidz c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0 c5t439257C4000019250000900000540000d0

Transform simple pool to a mirror:
zpool create [pool_name] [device]
zpool attach [pool_name] [existing_device] [new_device]
zpool create datapool c5t433127A900011C370000C00003210000d0
zpool attach datapool c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0

Expand simple pool:
zpool create [pool_name] [device]
zpool add [pool_name] [new_device]
zpool create datapool c5t433127A900011C370000C00003210000d0
zpool add datapool c5t433127B4001031250000900000540000d0

Expand mirrored pool by attaching additional mirror:
zpool add [pool_name] mirror [new_device] [new_device]
zpool add datapool mirror c5t433127A900011C370000C00003460000d0 c5t433127B400011C370000C00003410000d0

Replace device in a pool:
zpool replace [pool_name] [old_device] [new_device]
zpool replace datapool c5t433127A900011C370000C00003410000d0 c5t433127B4001031250000900000540000d0

Destroy pool:
zpool destroy [pool_name]
zpool destroy datapool

Set pool mountpoint:
zfs set mountpoint=/path [pool_name]
zfs set mountpoint=/export/zfs datapool

Display configured pools:
zpool list
zpool list

Display pool status info:
zpool status [-v] [pool_name]
zpool status -v datapool

Display pool I/O statistics:
zpool iostat [pool_name]
zpool iostat datapool

Display pool command history:
zpool history [pool_name]
zpool history datapool

Export a pool:
zpool export [pool_name]
zpool export datapool

Import a pool:
zpool import [pool_name]
zpool import datapool

Create a filesystem:
zfs create [pool_name]/[fs_name]
zfs create datapool/filesystem

Destroy a filesystem:
zfs destroy [pool_name]/[fs_name]
zfs destroy datapool/filesystem

Rename a filesystem:
zfs rename [pool_name]/[fs_name] [pool_name]/[fs_name]
zfs rename datapool/filesystem datapool/newfilesystem

Move a filesystem:
zfs rename [pool_name]/[fs_name] [pool_name]/[fs_name]/[fs_name]
zfs rename datapool/filesystem datapool/users/filesystem

Display properties of a filesystem:
zfs get all [pool_name]/[fs_name]
zfs get all datapool/filesystem

Make a snapshot:
zfs snapshot [pool_name]/[fs_name]@[time]
zfs snapshot datapool/filesystem@friday

Roll back filesystem to its snapshot:
zfs rollback [pool_name]/[fs_name]@[time]
zfs rollback datapool/filesystem@friday

Clone a filesystem:
zfs snapshot [pool_name]/[fs_name]@[time]
zfs clone [pool_name]/[fs_name]@[time] [pool_name]/[fs_name]
zfs snapshot datapool/filesystem@today
zfs clone datapool/filesystem@today datapool/filesystemclone

Backup filesystem to a file:
zfs send [pool_name]/[fs_name] > /path/to/file
zfs send datapool/filesystem@friday > /tmp/filesystem.bkp

Restore filesystem from a file:
zfs receive [pool_name]/[fs_name] < /path/to/file
zfs receive datapool/restoredfilesystem < /tmp/filesystem.bkp

Create ZFS volume:
zfs create -V [size] [pool_name]/[vol_name]
zfs create -V 100mb datapool/zvolume
newfs /dev/zvol/dsk/datapool/zvolume

]]> http://www.unixpowered.com/blog/2008/12/20/quick-and-dirty-zfs-cheatsheet/feed/ 0 Gathering fibre channel info using fcinfo http://www.unixpowered.com/blog/2008/08/19/gathering-fibre-channel-info-using-fcinfo/ http://www.unixpowered.com/blog/2008/08/19/gathering-fibre-channel-info-using-fcinfo/#comments Tue, 19 Aug 2008 19:47:25 +0000 somedude http://wayciak.wordpress.com/?p=41 I came across fcinfo command reading some man page. So, I decided to see what kind of useful fibre channel information it could give me. It turns out fcinfo knows quite a bit.

We can list all local fibre channel ports:

bash-3.00# fcinfo hba-port
HBA Port WWN: 21000003ba16dbd2
OS Device Name: /dev/cfg/c1
Manufacturer: QLogic Corp.
Model: 2200
Firmware Version: 2.1.144
FCode/BIOS Version: ISP2200 FC-AL Host Adapter Driver: 1.12 01/01/16
Type: L-port
State: online
Supported Speeds: 1Gb
Current Speed: 1Gb
Node WWN: 20000003ba16dbd2
HBA Port WWN: 2100001b320e3853
OS Device Name: /dev/cfg/c3
Manufacturer: QLogic Corp.
Model: QLA2462
Firmware Version: 4.0.27
FCode/BIOS Version: QLA2462 Host Adapter Driver(SPARC): 1.24 11/15/06
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 2Gb
Node WWN: 2000001b320e3853
HBA Port WWN: 2101001b322e3853
OS Device Name: /dev/cfg/c4
Manufacturer: QLogic Corp.
Model: QLA2462
Firmware Version: 4.0.27
FCode/BIOS Version: QLA2462 Host Adapter Driver(SPARC): 1.24 11/15/06
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 2Gb
Node WWN: 2001001b322e3853

We can take a look what remote ports are seen by particular local fibre channel port, in this case 2100001b320e3853:

bash-3.00# fcinfo remote-port -p 2100001b320e3853
Remote Port WWN: 100000e00216aef3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e01124b88f
Remote Port WWN: 50001fe15003b384
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e0020744f3
Remote Port WWN: 50001fe150216de9
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Remote Port WWN: 100000e00228f492
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e00208f492
Remote Port WWN: 50001fe15076b59b
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Remote Port WWN: 50001fe150216ded
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53

Here, we get link statistics for remote fibre channel device whose WWN is 100000e0020744f3:

bash-3.00# fcinfo remote-port -l -p 2100001b320e3853 100000e0020744f3
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: unknown
Node WWN: 100000e0020744f3
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0

We can also get link statistics and SCSI target information for all remote fibre channel devices see on local port whose WWN is 2100001b320e3853:

bash-3.00# fcinfo remote-port -sl -p 2100001b320e3853
Remote Port WWN: 100000e00216aef3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e01124b88f
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: MSL6000 Series
OS Device Name: /devices/pci@8,600000/SUNW,qlc@1/fp@0,0/sgen@w100000e00216aef3,0
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/2n
Remote Port WWN: 50001fe15003b384
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B4001031250000900000540000d0s2
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e0020744f3
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: MSL6000 Series
OS Device Name: /devices/pci@8,600000/SUNW,qlc@1/fp@0,0/sgen@w100000e0022744f3,0
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/1n
LUN: 2
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/0n
Remote Port WWN: 50001fe150216de9
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B400011C370000C00003210000d0s2
Remote Port WWN: 100000e00228f492
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e00208f492
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/4n
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/3n
Remote Port WWN: 50001fe15076b59b
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B4001031250000900000540000d0s2
Remote Port WWN: 50001fe150216ded
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B400011C370000C00003210000d0s2

This command is quite handy when troubleshooting fibre channel. Very cool…

]]> http://www.unixpowered.com/blog/2008/08/19/gathering-fibre-channel-info-using-fcinfo/feed/ 0 Managing core files http://www.unixpowered.com/blog/2008/07/22/managing-core-files/ http://www.unixpowered.com/blog/2008/07/22/managing-core-files/#comments Tue, 22 Jul 2008 19:45:59 +0000 somedude http://wayciak.wordpress.com/?p=22 If you have grown tired of having core files laying around all over the place you can manage them using coreadm command. You can set up system to save core files to a specific location.

First, here are the default core settings on a Solaris box:

bash-3.00# coreadm
global core file pattern:
global core file content: default
init core file pattern: core
init core file content: default
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled

Now, let’s configure the system to save init core files in /var/crash/cores in format EUID.execName.core:

bash-3.00# coreadm -i /var/crash/cores/%u.%f.core
bash-3.00# coreadm
global core file pattern:
global core file content: default
init core file pattern: /var/crash/cores/%u.%f.core
init core file content: default
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled

To test our setup, we can use gcore command.

bash-3.00# gcore -p 741
gcore: /var/crash/cores/0.bash.core dumped
bash-3.00# ls /var/crash/cores
0.bash.core hsperfdata_noaccess hsperfdata_root
bash-3.00#

Above, we generated core file for bash process with PID 741 run under effective UID 0. This should make the system tidier as far as core files are concerned.

]]> http://www.unixpowered.com/blog/2008/07/22/managing-core-files/feed/ 0