Howto switch on/off SMT features in LPAR

# smtctl -m 'on'

# smtctl -m 'off'

or via smitty -> under performance --> SMT

Alternative command for TOP in Solaris

There are fews command that to monitor overall performance.

1) sar 2 10
2) prstat

How to read vgda on the specific disk

# lqueryvg -Atp hdisk1

How to "config manager" in Sun

# cfgadm -c

# devfsadm

# devfsadm -c disk

dlnkmgr - Hitachi SAN HDLM software Description

Available command parameters:

# dlnkmgr help
dlnkmgr { clear | help | offline | online | set | view }

The view option allows you to see system and drive information

# dlnkmgr view -help
dlnkmgr view -sys [ -sfunc | -msrv | -adrv | -pdrv ] [-t]
dlnkmgr view -path [ -c | -hdev HostDeviceName ] [-t]
dlnkmgr view -path -item [pn] [dn] [lu] [cp] [type] [ic] [ie] [dnu] [hd]
[ -hdev HostDeviceName ] [-t]
dlnkmgr view -drv [-t]

The clear option allows you to clear the errors counters

# dlnkmgr clear -help
dlnkmgr clear -pdst [-s]

The offline option allows you to disactivate a dlmfdrv

# dlnkmgr offline -help
Format
dlnkmgr offline [-path] -pathid AutoPATH_ID [-s]

Valid value
AutoPATH_ID {000000 - 999999}(Decimal)


The online option allows you to activate a dlmfdrv

# dlnkmgr online -help
Format
dlnkmgr online [-path] [-pathid AutoPATH_ID] [-s]

Valid value
AutoPATH_ID {000000 - 999999}(Decimal)

The set option allows you to set various dlm values

# dlnkmgr set -help
Format
dlnkmgr set { -lb { on | off }
| -ellv LogLevel
| -elfs LogSize
| -systflv TraceLevel
| -pchk { on [ -intvl Interval-Time ] | off }
| -afb { on [ -intvl Interval-Time ] | off }
| -rsv on ReserveLevel }
[-s]

Valid value
LogLevel { 0 | 1 | 2 | 3 } (Default Value 3)
LogSize { 100 - 9900 }(KB) (Default Value 1000)
TraceLevel { 0 | 1 | 2 | 3 | 4 } (Default Value 0)
Interval-Time { 1 - 1440 }(Minute) (Default Value 30)
(pchk)
Interval-Time { 1 - 1440 }(Minute) (Default Value 1)
(afb)
ReserveLevel on { 0 | 2 } (Default Value "on 0")

Command to view path information

# dlnkmgr view -path
Paths:000002 OnlinePaths:000002
PathStatus IO-Count IO-Errors
Online 49960 0

PathID PathName DskName iLU ChaPort Status Type IO-Count
IO-Errors DNum HDevName
000000 08.14.0000000000075000.0000 HITACHI .OPEN-V .43194 0085 1G Online Own
25152 0 0 dlmfdrv2
000001 08.3D.0000000000085000.0000 HITACHI .OPEN-V .43194 0085 2G Online Own
24808 0 0 dlmfdrv3
KAPL01001-I The HDLM command completed normally. Operation name = view

alternate disk operation in AIX

alt_disk_install AIX 4.3.2 or later:

" Determine Volume Group Boot Disk:"
alt_disk_install -q disk

"Put-to-sleep Volume Group:"
alt_disk_install -S

"Rename Alternate Disk Volume Group:"
alt_disk_install -v new_volume_group_name disk

"Wake-up Volume Group:"
alt_disk_install -W disk

"Clean Up Alternate Disk Volume Group:"
alt_disk_install -X [ volume_group]

Examples

1. To clone the running 4.2.0 rootvg to hdisk3, then apply updates from
/updates to bring the cloned rootvg to a 4.2.1 level:

alt_disk_install -C -F 4.2.1.0_AIX_ML -l /updates hdisk3

The bootlist would then be set to boot from hdisk3 at the next reboot.
2. To install a 4.3 mksysb image on hdisk3, then run a customized script
(/home/myscript) to copy some user files over to the alternate rootvg file
systems before reboot:

alt_disk_install -d /mksysb_images/4.3_mksysb -s /home/myscript hdisk3

3. To remove the original rootvg ODM database entry, after booting from the
new alternate disk:

alt_disk_install -X old_rootvg

The lspv listing for the original rootvg will be changed to "None".
Therefore, a new volume group could be created on those disks.
4. To determine the boot disk for a volume group with multiple physical
volume:

alt_disk_install -q hdisk0

Illustrated Example

# lspv

hdisk0 00006091aef8b687 old_rootvg

hdisk1 00076443210a72ea rootvg

hdisk2 0000875f48998649 old_rootvg

# alt_disk_install -q hdisk0

hdisk2

In this case, the boot disk for "old_rootvg" is actually hdisk2. Therefore,
you could reset your bootlist to hdisk2 and reboot to the original rootvg
volume group.
5. To modify an alt_disk_install volume group name:

alt_disk_install -v alt_disk_432 hdisk2

Illustrated Example

# lspv

hdisk0 00006091aef8b687 rootvg

hdisk1 00000103000d1a78 rootvg

hdisk2 000040445043d9f3 altinst_rootvg

hdisk3 00076443210a72ea altinst_rootvg

hdisk4 0000875f48998649 None

hdisk5 000005317c58000e None

# alt_disk_install -v alt_disk_432 hdisk2

#lspv

hdisk0 00006091aef8b687 rootvg

hdisk1 00000103000d1a78 rootvg

hdisk2 000040445043d9f3 alt_disk_432

hdisk3 00076443210a72ea alt_disk_432

hdisk4 0000875f48998649 None

hdisk5 000005317c58000e None

6. To "wake_up" an original rootvg, after booting from the new alternate disk:

alt_disk_install -W hdisk0

Illustrated Example

# lspv

hdisk0 000040445043d9f3 old_rootvg

hdisk1 00076443210a72ea rootvg

# alt_disk_install -W hdisk0

# lspv

hdisk0 000040445043d9f3 altinst_rootvg

hdisk1 00076443210a72ea rootvg

At this point, the "altinst_rootvg" volume group is varied-on and the
/alt_inst file systems will be mounted.
7. To "put-to-sleep" a volume group that had experienced a "wake-up":

alt_disk_install -S

Illustrated Example

# lspv

hdisk0 000040445043d9f3 altinst_rootvg

hdisk1 00076443210a72ea rootvg

# alt_disk_install -S

# lspv

hdisk0 000040445043d9f3 altinst_rootvg

hdisk1 00076443210a72ea rootvg

The "altinst_rootvg" is no longer varied-on and the /alt_inst file systems
are no longer mounted. If it's necessary for the "altinst_rootvg" volume
group name to be changed back to "old_rootvg", this can be done with the
"-v" flag.

Soft Partitioning

Taken from http://sysunconfig.net/unixtips/soft-partitions.html

Solstice DiskSuite / Solaris Volume Manager

Soft Partitioning

---

A Primer for Understanding Soft Partitioning,
a new feature in Solstice DiskSuite (Solaris Volume Manager)

---

The intent of this document is to describe Soft Partitioning within Solstice DiskSuite (soon-to-be-renamed Solaris Volume Manager), and offer a short primer/tutorial on how to create, use, and delete them.

Until now, Solaris, without any volume management software, has only ever allowed a fixed number of partitions on a physical disk (seven (7) on SPARC platforms). With the increase in capacity of disks, this limitation has become a severe restriction.

SDS/SVM uses these slices for its metadevices (sub-mirrors, trans, stripes, and RAID5) and hence is faced with the same limitation, whereas Veritas Volume Manager (VxVM) allows for the logical partitioning of disks into a virtually unlimited number of subdisks.

Soft Partitioning allows for a disk to be subdivided into many partitions which are controlled and maintained by software, thereby removing the limitation of the number of partitions on a disk. A soft partition is made up of one or more "extents". An extent describes the parts of the physical disk that make up the soft partition. While the maximum number of extents per soft partition is 2147483647, the majority of soft partitions will use only one (1) extent.

---

What is new?

Soft Partitioning was not in the original Solstice DiskSuite 4.2.1 Release, which coincided with the release of Solaris 8. However, the soft partitioning functionality was released in patch 108693-06 for SDS 4.2.1.

When Solaris 9 gets released, the "Solstice DiskSuite" name will change to "Solaris Volume Manager" ("SVM") and it will be bundled in with Solaris 9. Soft Partitioning will, of course, be part of the base functionality of that release.

Soft Partitions are implemented by new kernel driver: md_sp.

   # modinfo | grep md_sp
 228 78328000 4743 - 1 md_sp (Meta disk soft partition module)

There are new options to the metainit command:

   metainit softpart -p [-e] component size
 metainit softpart -p component -o offset -b size 

The metattach command has been modified to allow for growing of soft partitions:

   metattach softpart size 

There is a new command... metarecover:

   metarecover [-n] [-v] component -p [-d|-m] 

NOTE: the -p option means that the command refers to soft partitions.

---

Creating Soft Partitions

There are three methods to create a soft partition using the metainit command:

1. Specifying an unused disk and size (with the -e option). For example:

   # metainit d0 -p -e c1t0d0 200m

   The -e option requires that the name of the disk supplied be in the form c#t#d#.

   The last parameter (200m) specifies the initial size of the soft partition. The sizes can be specified in blocks, kilobytes, megabytes, gigabytes, and terabytes.

   The -e option causes the disk to be repartitioned such that slice 7 has enough space to hold a replica (although no replica is actually created on this disk) and slice 0 contains the rest of the space. Slice 2 is removed from the disk. The soft partition that is being created is put into slice 0. Further soft partitions can be created on slice 0 by the next method of creating a soft partition.

   After this command is run, the layout of the disk would like similar to this example:

   Part Tag Flag Cylinders Size Blocks 0 unassigned wm 5 - 2035 999.63MB (2031/0/0) 2047248 1 unassigned wm 0 0 (0/0/0) 0 2 unassigned wm 0 0 (0/0/0) 0 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wu 0 - 4 2.46MB (5/0/0) 5040

   This command (with the -e) can only be run on an empty disk (one that is not used in any other metadevice). If another metadevice or replica already exists on this disk, one of the following messages will be printed, and no soft partition will be created.

      metainit: hostname: c#t#d#s0: has appeared more than once in the specification of d#
   

   or

      metainit: hostname: c#t#d#s#: has a metadevice database replica
   

2. Specifying an existing slice name and size (without the -e option). This will be the most common method of creation. For example:

   # metainit d1 -p c1t0d0s0 1g

   This will create a soft partition on the specified slice. No repartitioning of the disk is done. Provided there is space on the slice, additional soft partitions could be created as required. The device name must include the slice number (c#t#d#s#).

   If another soft partition already exists in this slice, this one will be created immediately after the existing one. Therefore, no overlap of soft partitions can occur by accident.

3. Specifying an existing slice and absolute offset and size values. For example:

   # metainit d2 -p c1t0d0s0 -o 2048 -b 1024

   The -o parameter signifies the offset into the slice, and the -b parameter is the size for the soft partition. All numbers are in blocks (a block is 512 bytes). The metainit command ensures that extents and soft partitions do not overlap. For example, the following is an attempt to create overlapping soft partitions.

   # metainit d1 -p c1t0d0s0 -o 1 -b 2024 d1: Soft Partition is setup # metainit d2 -p c1t0d0s0 -o 2000 -b 2024 metainit: hostname: d2: overlapping extents specified

   An offset of 0 is not valid, as the first block on a slice containing a soft partition contains the initial extent header. Each extent header consumes 1 block of disk and each soft partition will have an extent header placed at the end of each extent. Extent headers are explained in more detail in the next section.

   NOTE: This method is not documented in the man page for metainit and is not recommended for manual use. It is here because a subsequent metastat -p command will output information in this format.

---

Extent Headers

Whenever a soft partiton is created in a disk slice, an "extent header" is written to disk. Internally to Sun, these are sometimes referred to as "watermarks".

An extent header is a consistency record and contains such information as the metadevice (soft partition) name, it's status, it's size, and a checksum. Each extent header 1 block (512 bytes) in size.

The following diagram shows an example 100MB slice (c1t0d0s0) and the extent headers (watermarks) that have been created on it. The command to make the soft partition shown was

# metainit d1 -p c1t0d0s0 20m

->>

There is always an extent header on the first and last blocks in the slice. Note that the 80MB of space left over from the creation of the soft partition can be used to make one or more additional soft partitions. Each additional soft partition will create an additional extent header to be created as well.

---

Mirroring Soft Partitions

Once you have created soft partitions, what can you do with them? Well, one thing to do is to create mirrors out of them. Unfortunately, even though a soft partition is a metadevice, they cannot serve directly as a submirror. For example:

# metainit d10 -p c1t11d0s4 100m d10: Soft Partition is setup # metainit d20 -m d10 metainit: hostname: d10: invalid unit

Instead, you must first take the soft partition and create a simple concat/stripe out of it. For example:

# metainit d10 -p c1t0d0s0 100m d10: Soft Partition is setup # metainit d20 1 1 d10 d20: Concat/Stripe is setup # metainit d30 -m d20 d30: Mirror is setup # metainit d11 -p c2t0d0s0 100m d11: Soft Partition is setup # metainit d21 1 1 d11 d21: Concat/Stripe is setup # metattach d30 d21 d30: submirror d21 is attached

Once done, the resulting metastat output of the mirror will look like this:

# metastat d30 d30: Mirror Submirror 0: d20 State: Okay Submirror 1: d21 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 204624 blocks d20: Submirror of d30 State: Okay Size: 204624 blocks Stripe 0: Device Start Block Dbase State Hot Spare d10 0 No Okay d10: Soft Partition Component: c1t0d0s0 State: Okay Size: 204800 blocks Extent Start Block Block count 0 1 204800 d21: Submirror of d30 State: Okay Size: 204624 blocks Stripe 0: Device Start Block Dbase State Hot Spare d11 0 No Okay d11: Soft Partition Component: c2t0d0s0 State: Okay Size: 204800 blocks Extent Start Block Block count 0 1 204800

---

Combining Soft Partitions Together into a RAID5 Device

RAID5 devices can be made up of soft partitions directly. This example shows 4 soft partitions (from 4 separate slices) striped together to make a RAID5 device:

# metainit d1 -p c1t0d0s0 10m d1: Soft Partition is setup # metainit d2 -p c2t0d0s0 10m d2: Soft Partition is setup # metainit d3 -p c3t0d0s0 10m d3: Soft Partition is setup # metainit d4 -p c4t0d0s0 10m d4: Soft Partition is setup # metainit d10 -r d1 d2 d3 d4 d10: RAID is setup

Once done, the resulting metastat output of the RAID5 device will look like this:

# metastat d10 d10: RAID State: Okay Interlace: 32 blocks Size: 59472 blocks Original device: Size: 60384 blocks Device Start Block Dbase State Hot Spare d1 330 No Okay d2 330 No Okay d3 330 No Okay d4 330 No Okay d1: Soft Partition Component: c1t0d2s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480 d2: Soft Partition Component: c1t0d4s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480 d3: Soft Partition Component: c1t1d1s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480 d4: Soft Partition Component: c1t1d3s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 1 20480

---

Using Soft Partitions for MetaTrans (UFS Logging) Devices

MetaTrans devices (UFS logging) can be built on top of soft partitions. Soft partitions can be used for the master device, the logging device, or both. In the following example, soft partitions are used for both the master and the logging device:

# metainit d1 -p c1t0d0s0 500m d1: Soft Partition is setup # metainit d2 -p c2t0d0s0 50m d2: Soft Partition is setup # metainit d10 -t d1 d2 d1: Trans is setup

Once done, the resulting metastat output of the metatrans device will look like this:

# metastat d10 d10: Trans State: Okay Size: 1024000 blocks Master Device: d1 Logging Device: d2 d1: Soft Partition Component: c1t1d3s0 State: Okay Size: 1024000 blocks Extent Start Block Block count 0 1 1024000 d2: Logging device for d10 State: Okay Size: 102142 blocks d2: Soft Partition Component: c1t1d1s0 State: Okay Size: 102400 blocks Extent Start Block Block count 0 1 102400

---

Layering

Most of the time, soft partitions are made on a disk slice. However, there are certain situations where it can be beneficial to make a soft partition on top of an existing metadevice. This is referred to as layering.

For example, say you have a 90GB RAID5 device made up of 6 18GB disks. You can then take that 90GB device and "split it up" into many soft partitions. These many soft partitions then can be accessed as separate simple metadevices, although the data in them is protected by the RAID5 parity in the underlying device.

Soft partitions can be layered only on top of concat/stripes, mirrors, and RAID5 devices. Soft partitions cannot be layered on top of a metatrans device or directly on top of another soft partition.

Here is an example of layering soft partitions on top of an existing RAID5 metadevice. First, we create the RAID5 device, then soft partition that device into 3 100MB partitions (obviously, we could create more than just 3 soft partitions).

# metainit d0 -r c1t0d2s0 c1t0d4s0 c1t1d1s0 c1t1d3s0 d0: RAID is setup # metainit d1 -p d0 100m d1: Soft Partition is setup # metainit d2 -p d0 100m d2: Soft Partition is setup # metainit d3 -p d0 100m d3: Soft Partition is setup

Each of the resulting soft partitions (d1, d2, and d3) can be accessed individually (i.e., newfs and mount).

Soft partitions can be built on top of an existing mirror device as well, just like we did above on the RAID5 device. In the following example, the mirror device (d0) is "carved up" into 3 smaller soft partitions.

# metainit d10 1 1 c1t0d2s0 d10: Concat/Stripe is setup # metainit d20 1 1 c2t0d0s0 d20: Concat/Stripe is setup # metainit d0 -m d10 d20 d0: Mirror is setup # metainit d1 -p d0 100m d1: Soft Partition is setup # metainit d2 -p d0 100m d2: Soft Partition is setup # metainit d3 -p d0 100m d3: Soft Partition is setup

Soft partitions are not allowed to be parented by other soft partitions directly. For example:

# metainit d1 -p c1t0d0s0 100m d1: Soft Partition is setup # metainit d2 -p d1 10m metainit: hostname: d1: invalid unit

Soft partitions also cannot be built on top of trans (UFS logging) devices. For example:

# metainit d1 -t d10 d20 d1: Trans is setup # metainit d2 -p d1 100m metainit: hostname: d1: invalid unit

---

Growing Soft Partitions

A soft partition can be grown by the use of the metattach command. There is no mechanism to shrink a soft partition.

# metattach d0 10m d0: Soft Partition has been grown

When additional space is added to an existing soft partition, the additional space is taken from any available space on the same device and might not be contiguous with the existing soft partition. Growing soft partitions must be done with free space in the same device as the current soft partition.

The following example shows how growing a soft partition will increase the size of the current extent:

# metainit d1 -p c1t0d2s0 100m d1: Soft Partition is setup # metastat d1 d1: Soft Partition Component: c1t0d2s0 State: Okay Size: 204800 blocks Extent Start Block Block count 0 1 204800 # metattach d1 50m d1: Soft Partition has been grown # metastat d1 d1: Soft Partition Component: c1t0d2s0 State: Okay Size: 307200 blocks Extent Start Block Block count 0 1 307200

Note how after the metattach is run, there is still only one extent, but the (block count) has grown from 204800 (100MB) to 307200 (150MB).

In the following example, the extent cannot be grown, as it was above, because another soft partition is "in the way". Therefore, a second extent is created in the same slice.

# metainit d1 -p c1t0d2s0 100m d1: Soft Partition is setup # metainit d2 -p c1t0d2s0 10m d2: Soft Partition is setup # metastat d1: Soft Partition Component: c1t0d2s0 State: Okay Size: 204800 blocks Extent Start Block Block count 0 1 204800 d2: Soft Partition Component: c1t0d2s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 204802 20480 # metattach d1 50m d1: Soft Partition has been grown # metastat d1: Soft Partition Component: c1t0d2s0 State: Okay Size: 307200 blocks Extent Start Block Block count 0 1 204800 1 225283 102400 d2: Soft Partition Component: c1t0d2s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 204802 20480

Note how d1 now has two non-contiguous extents that together make up the 307200 (150MB) blocks.

NOTE: Growing the metadevice does not modify the data or the filesystem inside the metadevice. If the metadevice contains a filesystem, you must use the appropriate command(s) to grow that filesystem after the metadevice has been grown.

---

Deleting Soft Partitions

This is achieved by using the metaclear command in the normal way:

# metaclear d0 d0: Soft Partition is cleared

If other metadevices are using the soft partition, the metaclear will error with:

   metaclear: hostname: d0: metadevice in use

---

Using Soft Partitions with Disksets

There are no differences with soft partitioning in a diskset, other than having to specify the -s option on the commandline to specify the diskset name.

The only potential problem occurs when dealing with did disk devices that are in a SunCluster configuration. Unfortunately, the naming convention of the did devices is similar to that of SDS/SVM in that the disks are referred to as d#. This means that SDS/SVM could confuse a did disk with a metadevice when creating a soft partition.

The simple workaround to this problem is to use the full path to the did device on the metainint commandline in order to prevent any confusion.

For example, the following command to create a 1GB soft partition on /dev/did/rdsk/d7s0 would be invalid:

# metainit -s set2 d0 -p d7s0 1g

Instead, the correct command to run would be:

# metainit -s set2 d0 -p /dev/did/rdsk/d7s0 1g

---

How to list the soft partitions in a given slice

The metarecover command, with the -n and -v options, will display information about the soft partitons existing in a given slice.

The metarecover command actually scans the given slice for extent headers and prints the information that it finds about those headers.

In each slice/device, there are also 2 additional extent headers; one which preceeds the free space in the slice, and the one on the last block of the slice. These are printed as well. This is an easy way to determine how much free space is available in a slice for additional soft partitions.

# metarecover -v -n /dev/rdsk/c1t0d0s0 -p Verifying on-disk structures on c1t0d0s0. The following extent headers were found on c1t0d0s0. Name Seq# Type Offset Length d0 0 ALLOC 0 20481 d1 0 ALLOC 20481 40961 NONE 0 END 17674901 1 NONE 0 FREE 61442 17613459 Found 2 soft partition(s) on c1t0d0s0.

In the above example, there were 2 soft partitions (d0 and d1) found on c1t0d0s0, as well as 17613458 blocks (approx 8.4GB) of unallocated free space.

IMPORTANT NOTE: The information printed by this command is relative to the extent header, not the soft partition itself. Therefore, the 'offset' is the starting location of the extent header, not the extent itself. Also, the 'length' given is the length of the extent plus the header. Therefore, in the example above, there are only 17613458 free blocks, not 17613459 blocks.

Because soft partitions can be layered above metadevices like mirrors or RAID5 devices (see layering, above), this command can also be run on them to determine the locations and sizes of the extent headers. In the example below, d0 is a RAID5 metadevice which has 4 soft partitions in it. There is no free space left in this device.

# metarecover -v -n d0 -p Verifying on-disk structures on d0. The following extent headers were found on d0. Name Seq# Type Offset Length d1 0 ALLOC 0 204801 d2 0 ALLOC 204801 204801 d3 0 ALLOC 409602 204801 d99 0 ALLOC 614403 7573580 NONE 0 END 8187983 1 Found 4 soft partition(s) on d0.

---

Fragmentation

Fragmentation of free space will occur on a slice when there has been activity in creating, deleting, and possibly growing soft partitions. At this time, there is no method to defragment a disk.

For example, the following sequence of commands can result in some amount of fragmentation. First, create 2 10MB soft partitions on a slice.

# metainit d1 -p c1t0d0s0 10m d1: Soft Partition is setup # metainit d2 -p c1t0d0s0 10m d2: Soft Partition is setup

Then, remove the first 10MB soft partition and then create a 20MB soft partition.

# metaclear d1 d1: Soft Partition is cleared # metainit d3 -p c1t0d0s0 20m d3: Soft Partition is setup

When the d3 metadevice was created, the 10MB of free space at the beginning of the slice is not used, because there is a contiguous 20MB space available further out that can be used instead. Therefore, the 10MB of free space is skipped over in favor of the first 20MB of contiguous space. The metarecover command will show the fragmentation (multiple free spaces):

# metarecover -v -n c1t0d0s0 -p Verifying on-disk structures on c1t0d0s0. The following extent headers were found on c1t0d0s0. Name Seq# Type Offset Length d2 0 ALLOC 20481 20481 d3 0 ALLOC 40962 40961 NONE 0 END 2047247 1 NONE 0 FREE 81923 1965324 NONE 0 FREE 0 20481 Found 2 soft partition(s) on c1t0d0s0.

---

Recovering Soft Partitions

The 'metarecover' command is run when something has gone wrong. It should not be run except to recover from a catastrophic problem. There are two main functions that this command does. It can

1. scan through the given slice and recreate the soft partitions that it finds there. this is good when moving a disk with soft partitions to a new machine. The option to use on the metarecover command is -d.
2. reads through the current replica and creates the soft partitions on the given slice. This is good to run after a disk fails and gets replaced with a new one. The option to use on the metarecover command is -m.

Recreating Information in the Replica from the Extent Headers

Here is a very simple example showing a disk which had soft partitions created on it (in slice 0) on another host, which is being moved to a new machine. We wish to extract the soft partitions on this new machine. Currently, there are no metadevices created.

# metastat

This command scans the given slice (in this case, "c0t0d0s0") and, for each soft partition it finds in that slice, it puts an entry into the current replica. The data on the disk is not modified, and nothing on the slice specified is modified. All that happens is that the extent headers are read and information is written to the replica.

# metarecover c0t0d0s0 -p -d The following soft partitions were found and will be added to your metadevice configuration. Name Size No. of Extents d1 61440 1 d2 20480 1 WARNING: You are about to add one or more soft partition metadevices to your metadevice configuration. If there appears to be an error in the soft partition(s) displayed above, do NOT proceed with this recovery operation. Are you sure you want to do this (yes/no)? yes c0t0d0s0: Soft Partitions recovered from device.

Now, we can see the soft partition metadevices have been created for us:

# metastat d1: Soft Partition Component: c0t0d0s0 State: Okay Size: 61440 blocks Extent Start Block Block count 0 120836 61440 d2: Soft Partition Component: c0t0d0s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 20482 20480

Recreating Soft Partitions from Information in the Replica

This example essentially does the opposite of example 1. In this case, the actual extent headers on the disk have been lost, either because something wrote over them, or because the disk hosting the soft partitions had to be replaced with new disk drive. Although the replica shows the soft partitions to be "Okay":

# metastat d1: Soft Partition Component: c0t0d0s0 State: Okay Size: 61440 blocks Extent Start Block Block count 0 120836 61440 d2: Soft Partition Component: c0t0d0s0 State: Okay Size: 20480 blocks Extent Start Block Block count 0 20482 20480

there are no extent headers on the disk, so I/O to the disk will error out.

# dd if=/dev/zero of=/dev/md/rdsk/d2 dd: /dev/md/rdsk/d2: open: I/O error

To check the disk to see if any extent headers exist on the disk, you can run the command

# metarecover -n c0t0d0s0 -p found incorrect magic number 0, expected 20000127. No extent headers found on c0t0d0s0. c0t0d0s0: On-disk structures invalid or no soft partitions found. metarecover: hostname: d0: bad magic number in extent header

The above command confirms that there are no extent headers on the disk. To have the extent headers written out to the disk, according to the information currently in the replica, run the command

# metarecover c0t0d0s0 -p -m c0t0d0s0: Soft Partition metadb configuration is valid WARNING: You are about to overwrite portions of c0t0d0s0 with soft partition metadata. The extent headers will be written to match the existing metadb configuration. If the device was not previously setup with this configuration, data loss may result. Are you sure you want to do this (yes/no)? yes c0t0d0s0: Soft Partitions recovered from metadb

Now, the extent headers have been written to the disk, so I/O will work correctly now. Running the verify command again, we see

   # metarecover -n c0t0d0s0 -p
 c0t0d0s0: Soft Partition metadb configuration is valid
 c0t0d0s0: Soft Partition metadb matches extent header configuration

luxadm command for Solaris FC disks

Taken from http://www.tek-tips.com/viewthread.cfm?qid=1183310&page=9

FCAL Disks
luxadm probe (discovers fcal)
luxadm display Enclosure (displays information on fcal box)
luxadm reserve /dev/rdsk/c#t#d#s# (reserves device so it can’t be accessed)
luxadm -e offline /dev/rdsk/c#t#d#s# (takes a device offline)
luxadm -e bus_quiesce /dev/rdsk/c#t#d#s# (quiesce the bus)
luxadm -e bus_unquiesce /dev/rdsk/c#t#d#s# (unquiesce the bus)
luxadm -e online /dev/rdsk/c#t#d#s# (bring the disk device back online)
luxadm release /dev/rdsk/c#t#d#s# (unreserved the device for use)
luxadm remove_device BAD,f2 (removes a device from slot f2 on enclosure BAD)
luxadm insert_device BAD,f2 (hot plug a new device to slot f2 on enclosure BAD)

SSAADM (for old ssa drawers)
ssaadm display c# (displays ssa on controller)
ssaadm display /dev/rdsk/c#t#d#s# (display drive information)
ssaadm start /dev/rdsk/c#t#d#s# (spin up a specific drive)
ssaadm stop /dev/rdsk/c#t#d#s# (spin down a specific drive)
ssaadm start –t 3 c# (spin up all drives in tray 3 on controller )
ssaadm stop –t 3 c# (spin down all drives in tray 3 on controller)
ssaadm start c# (spin up all drives in array)
ssaadm stop c# (stop all drives in array)

Taken from http://uw714doc.sco.com/en/FS_manager/nfsD.nfsopt.html
Many thanks to Suhaila

NFS advanced mount options

The Filesystem Manager supports the following mount options for NFS filesystems:

Mount in background

specifies that the NFS mount should be retried in the background if the server's mount daemon (mountd) does not respond.

Yes

This is recommended for automatic mounts done during system startup. The default is to mount in the foreground.

No

This is recommended if you wish to see whether the mount was successful.

Type of Mount

specifies how the client acts if the server does not respond to its NFS request.

Hard

retries indefinitely. The client will continue to attempt the NFS file operation indefinitely if the operation fails. Hard mounts should be used when the server and the link to the server are known to be reliable. Hard mounts with the interruptible option enabled is the recommended method of mounting remote filesystems. The default is hard mount.

Soft

retries NFS file operation n times as set by the number of retries before reporting error option; returns error if no server response in n tries. Soft mounts are recommended for filesystems whose servers are considered unreliable, or if the link is slow. Unlike spongy mounts, soft mounts may time out during read and write operations.

Spongy

sets soft semantics for stat, lookup, fsstat, readlink, and readdir NFS operations and hard semantics for all other NFS operations on the filesystem. Spongy mounts are preferable to soft mounts because spongy mounts will not time out during read and write operations. They are recommended for slow, long-distance, or unreliable links, and for unreliable servers.

Allow Keyboard Interrupts

allows keyboard interrupts on hard mounts.

Yes

allows the user to kill a process that is hung while waiting for a response on a hard-mounted filesystem. This option is useful if the server or the connection to the server is known to be slow or unreliable. It is recommended to always have the intr option on. A keyboard interrupt is configured by entering stty intr key where key is the keyboard key you wish to use to issue an interrupt.

No

specifies that the user cannot terminate an NFS operation from the keyboard. This should only be used if the server and link to the server are known to be reliable. Non-interruptible is the default.

Cache attributes

Yes

caches the file attributes. This eliminates redundant requests to the server for file information/attributes. This option is the default.

No

does not cache attributes. Use this option when close synchronization with the server is required. Note that using this option will drastically impair performance on the filesystem being mounted.

Read/Write Buffer Size (bytes)

specifies client read and write buffer sizes in bytes (the default size is 8192 bytes). This should be lowered if you have a slow Ethernet card.

Timeout period for each operation

sets the initial NFS timeout for each RPC operation to n seconds. The default is 300 seconds.

Number of retries before reporting error

specifies (for soft mounts only) the number of NFS retransmissions the client will make before reporting an error. The default is 5.

Alternate IP Port Number

set the server IP port number (the default port number is 2049).

Split DNS

Taken from http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#id2549203

Setting up different views, or visibility, of the DNS space to internal and external resolvers is usually referred to as a Split DNS setup. There are several reasons an organization would want to set up its DNS this way.

One common reason for setting up a DNS system this way is to hide "internal" DNS information from "external" clients on the Internet. There is some debate as to whether or not this is actually useful. Internal DNS information leaks out in many ways (via email headers, for example) and most savvy "attackers" can find the information they need using other means.

Another common reason for setting up a Split DNS system is to allow internal networks that are behind filters or in RFC 1918 space (reserved IP space, as documented in RFC 1918) to resolve DNS on the Internet. Split DNS can also be used to allow mail from outside back in to the internal network.

Here is an example of a split DNS setup:

Let's say a company named Example, Inc. (example.com) has several corporate sites that have an internal network with reserved Internet Protocol (IP) space and an external demilitarized zone (DMZ), or "outside" section of a network, that is available to the public.

Example, Inc. wants its internal clients to be able to resolve external hostnames and to exchange mail with people on the outside. The company also wants its internal resolvers to have access to certain internal-only zones that are not available at all outside of the internal network.

In order to accomplish this, the company will set up two sets of name servers. One set will be on the inside network (in the reserved IP space) and the other set will be on bastion hosts, which are "proxy" hosts that can talk to both sides of its network, in the DMZ.

The internal servers will be configured to forward all queries, except queries for site1.internal, site2.internal, site1.example.com, and site2.example.com, to the servers in the DMZ. These internal servers will have complete sets of information for site1.example.com, site2.example.com, site1.internal, and site2.internal.

To protect the site1.internal and site2.internal domains, the internal name servers must be configured to disallow all queries to these domains from any external hosts, including the bastion hosts.

The external servers, which are on the bastion hosts, will be configured to serve the "public" version of the site1 and site2.example.com zones. This could include things such as the host records for public servers (www.example.com and ftp.example.com), and mail exchange (MX) records (a.mx.example.com and b.mx.example.com).

In addition, the public site1 and site2.example.com zones should have special MX records that contain wildcard (`*') records pointing to the bastion hosts. This is needed because external mail servers do not have any other way of looking up how to deliver mail to those internal hosts. With the wildcard records, the mail will be delivered to the bastion host, which can then forward it on to internal hosts.

Here's an example of a wildcard MX record:

*   IN MX 10 external1.example.com.

Now that they accept mail on behalf of anything in the internal network, the bastion hosts will need to know how to deliver mail to internal hosts. In order for this to work properly, the resolvers on the bastion hosts will need to be configured to point to the internal name servers for DNS resolution.

Queries for internal hostnames will be answered by the internal servers, and queries for external hostnames will be forwarded back out to the DNS servers on the bastion hosts.

In order for all this to work properly, internal clients will need to be configured to query only the internal name servers for DNS queries. This could also be enforced via selective filtering on the network.

If everything has been set properly, Example, Inc.'s internal clients will now be able to:

• Look up any hostnames in the site1 and site2.example.com zones.
• Look up any hostnames in the site1.internal and site2.internal domains.
• Look up any hostnames on the Internet.
• Exchange mail with internal AND external people.

Hosts on the Internet will be able to:

• Look up any hostnames in the site1 and site2.example.com zones.
• Exchange mail with anyone in the site1 and site2.example.com zones.

Here is an example configuration for the setup we just described above. Note that this is only configuration information; for information on how to configure your zone files, see the section called “Sample Configurations”

Internal DNS server config:

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {
   ...
   ...
   forward only;
   forwarders {                                // forward to external servers
       bastion-ips-go-here;
   };
   allow-transfer { none; };                   // sample allow-transfer (no one)
   allow-query { internals; externals; };      // restrict query access
   allow-recursion { internals; };             // restrict recursion
   ...
   ...
};

zone "site1.example.com" {                      // sample master zone
 type master;
 file "m/site1.example.com";
 forwarders { };                               // do normal iterative
                                               // resolution (do not forward)
 allow-query { internals; externals; };
 allow-transfer { internals; };
};

zone "site2.example.com" {                      // sample slave zone
 type slave;
 file "s/site2.example.com";
 masters { 172.16.72.3; };
 forwarders { };
 allow-query { internals; externals; };
 allow-transfer { internals; };
};

zone "site1.internal" {
 type master;
 file "m/site1.internal";
 forwarders { };
 allow-query { internals; };
 allow-transfer { internals; }
};

zone "site2.internal" {
 type slave;
 file "s/site2.internal";
 masters { 172.16.72.3; };
 forwarders { };
 allow-query { internals };
 allow-transfer { internals; }
};

External (bastion host) DNS server config:

acl internals { 172.16.72.0/24; 192.168.1.0/24; };

acl externals { bastion-ips-go-here; };

options {
 ...
 ...
 allow-transfer { none; };                     // sample allow-transfer (no one)
 allow-query { internals; externals; };        // restrict query access
 allow-recursion { internals; externals; };    // restrict recursion
 ...
 ...
};

zone "site1.example.com" {                      // sample slave zone
 type master;
 file "m/site1.foo.com";
 allow-query { any; };
 allow-transfer { internals; externals; };
};

zone "site2.example.com" {
 type slave;
 file "s/site2.foo.com";
 masters { another_bastion_host_maybe; };
 allow-query { any; };
 allow-transfer { internals; externals; }
};

In the resolv.conf (or equivalent) on the bastion host(s):

search ...
nameserver 172.16.72.2
nameserver 172.16.72.3
nameserver 172.16.72.4

Host-based authentication using OpenSSH

Taken from http://cert.uni-stuttgart.de/doc/openssh/host-based.php

Using host-based authentication, any user on a trusted host can log into another host on which this feature is enabled. This authentication is useful in an environment with a trusted host and several untrusted systems. Passwords no longer have to be transferred to the untrusted systems.

Requirements

It is recommended that you use at least OpenSSH 3.4p1 on both clients and servers.

Scenario

We have got two hosts, trusted.example.com and untrusted.example.com. We want to perform host-based authentication from trusted.example.com to untrusted.example.com, i.e. user on trusted.example.com shall be able to login on untrusted.example.com without supplying a password.

We assume that all SSH configuration files are stored in /etc/ssh.

Configuration on the client

On trusted.example.com, the following changes are required:

1. The ssh binary (usually stored in /usr/bin/ssh or /usr/local/bin/ssh) has to be maded set-uid root:

   # chown root /usr/bin/ssh
   # chmod u+s /usr/bin/ssh
   # ls -l /usr/bin/ssh
   -rwsr-xr-x    1 root     root       230216 Jul 31 08:49 /usr/bin/ssh
   #
   

2. Host keys for protocol version 2 are required. The files are called /etc/ssh/ssh_host_dsa_key and /etc/ssh/ssh_host_rsa_key (and the .pub variants). You can create these files using ssh-keygen.
3. Host-based authentication has to be enabled in the client. Add the following section to /etc/ssh/ssh_config:

   Host *
      HostbasedAuthentication yes 

Configuration of the server

On untrusted.example.com, these changes are needed:

1. Of course, host-based authentication has to be enabled in the server, by changing the /etc/ssh/sshd_config file and inserting the following line (or replacing an uncommented HostbasedAuthentication directive):

   HostbasedAuthentication yes 

2. The public part of the the host keys of trusted.example.com have to be added to the /etc/ssh/ssh_known_hosts file. In contrast to the authorized_keys file you might know from user-oriented public-key authentication, this file is stored in the known hosts file format, i.e. you have to prefix each line with the host name and its IP adress (separated by a comma).

   For example, if the RSA public host key on trusted.example.com looks like this:

   ssh-rsa AA lots of characters MM= root@trusted.example.com
   

   You have to add the following line to /etc/ssh/ssh_known_hosts on untrusted.example.com:

   trusted.example.com,192.0.2.1 ssh-rsa AA lots of characters MM= root@trusted.example.com
   

   A similar line should be added for the DSA host key.

3. Using the line above, untrusted.example.com can authenticate requests from trusted.example.com. It is still necessary to instruct the SSH server on untrusted.example.com to authorize host-based authentication requests coming from trusted.example.com. For this, you need to create a file /etc/ssh/shosts.equiv with the following line in it:

   +trusted.example.com 

After these changes, you should be able to use host-based authentication on trusted.example.com/CODE>.

Security considerations

• If trusted.example.com is compromised, untrusted.example.com. As a consequence, you should never enable host-based authentication unless trusted.example.com is already a trusted system (i.e. on which you completely depend), and a compromise of untrusted.example.com is a minor annoyance compared to a break-in on this trusted host.
• The SSH client on trusted.example.com is now set-uid root. (See the remarks under the previous point.)
• An additional authentication method is enabled in the client on trusted.example.com. This exposes more OpenSSH client code to attacks from malicious SSH servers.
• Similarly, on the server untrusted.example.com, more code is exposed to attacks, too.

View vpath's ESS attributes

Use command lsvpcfg to find the vpath serial number.
example:
# lsvp
# lsvpcfg vpathX
example output:
servername:/ $ lsvpcfg vpath1
vpath1 (Avail pv myvg) 00126549 = hdisk4 (Avail ) hdisk10 (Avail )

The serial number of the vpath equals the Shark LUN ID

How to add filebase swapspace on Linux

a) Login as the root user

b) Type following command to create 512MB swap file (1024 * 512MB = 524288 block size):
# dd if=/dev/zero of=/swapfile1 bs=1024 count=524288

c) Set up a Linux swap area:
# mkswap /swapfile1

d) Activate /swapfile1 swap space immediately:
# swapon /swapfile1

e) To activate /swapfile1 after Linux system reboot, add entry to /etc/fstab file. Open this file using text editor such as vi:
# vi /etc/fstab
Append following line:
/swapfile1 swap swap defaults 0 0

So next time Linux comes up after reboot, it enables the new swap file for you automatically.

g) How do I verify swap is activated or not?
Simply use free command:
$ free -m
$ swapon -s

Switch the primary group with secondary group temporarily

This command is used to switch / swap between primary group and secondary group in a session.

$ id
uid=33119(kasim) gid=33119(users) group=3333(sysadm)
$ newgrp sysadm
$ id
uid=33119(kasim) gid=3333(sysadm) group=33119(users)

Admin tools for cluster manipulation

A tool to manage and configure cluster overall:
# smitty hacmp

A tool to manage RG(s) and cluster generally:
# smitty cl_admin

A tool to start cluster:
# smitty clstart

A tool to stop cluster gracefully, fail over or force:
# smitty clstop

A command to check the cluster services:
# lssrc -g cluster

Set user ID, set group ID, sticky bit

Source taken from: http://wiki.e107.org/?title=Unix_Permissions

In addition to the basic UNIX permissions, there are also three bits of information defined for files in UNIX:

• SUID or setuid: change user ID on execution. If setuid bit is set, when the file will be executed by a user, the process will have the same rights as the owner of the file being executed.
• SGID or setgid: change group ID on execution. Same as above, but inherits rights of the group of the owner of the file. For directories it also may mean that when a new file is created in the directory it
• Sticky bit. It was used to trigger process to "stick" in memory after it is finished, now this usage is obsolete. Currently its use is system dependant and it is mostly used to suppress deletion of the files that belong to other users in the folder where you have "write" access to.

Numeric representation

Octal digit Binary value Meaning

• 0 000 setuid, setgid, sticky bits are cleared
• 1 001 sticky bit is set
• 2 010 setgid bit is set
• 3 011 setgid and sticky bits are set
• 4 100 setuid bit is set
• 5 101 setuid and sticky bits are set
• 6 110 setuid and setgid bits are set
• 7 111 setuid, setgid, sticky bits are set

Textual representation

SUID

• If set, then replaces "x" in the owner permissions to "s", if owner has execute permissions, or to "S" otherwise. Examples:
• -rws------ both owner execute and SUID are set
• -r-S------ SUID is set, but owner execute is not set

SGID

• If set, then replaces "x" in the group permissions to "s", if group has execute permissions, or to "S" otherwise. Examples:
• -rwxrws--- both group execute and SGID are set
• -rwxr-S--- SGID is set, but group execute is not set

Sticky

• If set, then replaces "x" in the others permissions to "t", if others have execute permissions, or to "T" otherwise. Examples:
• -rwxrwxrwt both others execute and sticky bit are set
• -rwxrwxr-T sticky bit is set, but others execute is not set

What are the SUID, SGID and the Sticky Bits?

Source taken from http://www.codecoffee.com/tipsforlinux/articles/028.html

Linux has some special attributes associated with all files. Often in X Windows when you check the properties of any file (by right clicking on it and viewing its properties) you would get to see 3 special attributes besides the common read/write/execute rights for the owner/group/others. The 3 extra attributes are known as SUID, SGID and Sticky Bits

Sticky Bit

Lets start with Sticky bit first. Since this is the most simplest to explain. Setting the sticky bit tells Unix that once the concerned application is executed, it should remain in memory. Remember that Unix is a multi-user OS and was mainly designed so that multiple users can work simultaneously. Thus the logic used is that a program that exists in memory requires lesser time to start when a new user requests for the same program. Thus when one user has just used a program and then a new user wants to use the same program, the second user doesn't have to face a time delay for the program to initialize itself. It would be readily available to him. The concept of the sticky bit was a very useful one, long back when fast disk access and other memory access technologies weren't around. But in today's age the concept of sticky bit is obsolete, since modern day technology is advanced enough to reduce the time delay while loading applications into the memory. Thus currently the sticky bit is of very little significance. Sticky bit is only associated with executables.

SUID (Set User ID) Bit

Sometime you may faced an error while trying to run any application stating that the application must be 'SUID root' . You might have been confused that time, but now once you read this article you would no longer find it confusing.

SUID stands for Set User ID. This means that if the SUID bit is set for any application then your user ID would be set as that of the owner of application/file rather than the current user, while running that application. That means in case I have an application whose owner is ' root ' and it has its SUID bit set, then when I run this application as a normal user, that application would still run as root. Since the SUID bit tells Linux that the the User ID root is set for this application and whenever this application executes it must execute as if root was executing it (since root owns this file).

In case you have really understood the above you may be wondering - isnt this a major security risk? If users are able to run applications as root, then it must be definitely posing as a threat to the security of the system. Actually the SUID is used to increase the security in a way. Let me explain this with my own example I use on my machine.


One way I use SUID on my machine

I have a few files that I modify through Linux and then before I shutdown Linux I have to transfer them to my Windows partition for further use there. As a normal user I do not have write access to the Windows partitions that I have mounted. So I have to be the superuser to be able to write to that partition. I have created a simple shell script that copies my files to the Windows partitions. This script was created by root user and the SUID bit was set. Access rights to this script have been given to all users. Now whenever I want to copy my files I simply run this script. Even though I have logged in as a normal user, the SUID bit which is set causes this script to execute as if the root was executing it and it allows me to write to the Windows partitions.

Had the SUID bit not been set, I would have to type ' su ' at the prompt and get temporary superuser access to get write access to the Windows partitions. Hope you got the point..

You may be thinking that since these applications would run as root they can do harmful things and destroy the system. The concept behind SUID bit is that you as the superuser would be able to allow certain applications / scripts to be run by the users as if they were the superuser for the time being. What these application / scripts do when they execute should be completely known to you. Even though the users would be allowed to execute these programs as root they would be able to do ONLY THOSE things that these programs were designed to do. So in case a script was designed to copy 5 files from one place to another. Then the user who would run that script would be able to ONLY copy those 5 files from one place to another. He would not be able to modify that script in any way since he would not have write access to the script. He would only be having execute rights for that script. Hence its an excellent idea to allow users to do some important backup using a script that does only that and by setting the SUID bit for that script. This way the users don't have to know the superuser password but can still use some facilities that are only available to the superuser

Important : Think twice before setting the SUID bit for scripts (owned by root) that take arguments at the command line. Since you never know what parameters a malicious user may pass to your script. Since the script would run as root it could do great damage if misused.


SGID (Set Group ID) bit

Just like SUID, setting the SGID bit for a file sets your group ID to the file's group while the file is executing. IT is really useful in case you have a real multi-user setup where users access each others files. As a single homeuser I haven't really found a lot of use for SGID. But the basic concept is the same as the SUID, the files whose SGID bit are set would be used as if they belong to that group rather than to that user alone.

Note : Making SUID and SGID programs completely safe is very difficult (or maybe impossible) thus in case you are a system administrator it is best to consult some professionals before giving access rights to root owned applications by setting the SUID bit. As a home user (where you are both the normal user and the superuser) the SUID bit helps you do a lot of things easily without having to log in as the superuser every now and then.

HACMP health-check command

To check RG availability on HACMP server, execute the command as below:

# /usr/es/sbin/cluster/utilities/clRGinfo

To check setting of the HACMP cluster:

# /usr/es/sbin/cluster/utilities/cltopinfo

To check the current status of the cluster:

# /usr/es/sbin/cluster/utilities/clstat

How to collect system info for IBM to investigate (snap command)

Below is the general step how to collect system info for IBM to investigate:

1. run snap -r (answer yes if asked).
2. run snap -ac (additional option '-e' to collect HAMCP cluster information)
3. rename the file in step 2. under /tmp/ibmsupt directory to the name that has been specified by IBM themselves. xxxxxxxx.snap.pax.Z
4. upload the renamed file (step 3) to our FTP server:

ftp server: ftp.XxxXxxx.ibm.com
login: anonymous
passwd:
upload dir: /toibm/aix

Hitachi Dynamic Link Manager on AIX manipulation command

Today's work lead me to find and learn new command for managing and verifying Hitachi Disks Array on AIX machine:

Source taken from http://www.coolcommands.com/index.php?option=com_cccat&task=display&id=47

hdlm - Hitachi SAN disk correspondance Description

Correspondance for physical disks for a Hitachi SAN:

4 hdisk = 4 dlmfdrv = 1 physical disk

HDLM commands:

Command to discover all dlmfdrv:

# dlmcfgmgr

Command to verify the disks on a HITACHI SAN:

- the system:

# dlnkmgr view -sys

- the drivers

# dlnkmgr view -drv

- the paths

# dlnkmgr view -path

Changing the Auto Failback feature

# dlnkmgr set -afb on
dlnkmgr set -afb on
Execute command? [y/n] : y
KAPL01001-I The HDLM command completed normally. Opestartration name = set

Changing the Path Health Checking feature

# dlnkmgr set -pchk on
dlnkmgr set -pchk on
Execute command? [y/n] : y
KAPL01001-I The HDLM command completed normally. Operation name = set

To bring LUN online in the system

# dlnkmgr online -path -pathid 000001

SSH Secure Shell: Protocol error: packet too long

Source taken from http://www.jp.ssh.com/support/faq/secureshell/qa_1_920.html

Unix and Windows: I receive error messages like this when trying to connect to a secure shell server: Server responded "Protocol error: packet too long: -130315592" (number reported will vary). Other similar error messages may also appear. How do I fix this?


The most likely cause of this error message is that you are attempting to connect to an older version secure shell server. Try changing the encryption algorithm to a different algorithm - for example, Blowfish.

Windows Client

Go to Edit -> Settings ... -> Profile Settings -> Connection , change the algorithm, click on OK. Then choose File -> Save Settings and they try again to establish a connection. If that does not resolve the problem, try changing the MAC Algorithm:

http://www.ssh.com/products/ssh/winhelp30/Connection.html

Unix Client

If you have root privileges, edit the /etc/ssh2/ssh2_config to change the encryption algorithm.

If you do not have root privileges, you can set the algorithm in your own user-specific configuration file, located by default in $HOME/.ssh2/ssh2_config . If you do not already have a user-specific configuration file, simply copy the file /etc/ssh2/ssh2_config to $HOME/.ssh2/ssh2_config .

You can also specify a different cipher or MAC at the command line using the ssh2 options -c and/or -m. See man ssh2 and man ssh2_config for more information.

Moving Data Between Volume Group (VG - HPUX)

# cd /
# cd /; fbackup -f - -i . | (cd /; frecover -f - -r)

How to check SSA card serial number

View SSA Serial No.:

# ssa_ela -h 3
ssa3 SRN 42521

Howto recovery from an unknow Root password

TITLE : Howto recovery from an unknow Root password
OS LEVEL : AIX 4.x and above

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

1. Boot the machine into 'service' mode from the installation media. Ensure
the CD/tape is in the appropriate drive, turn the keyswitch to 'service'
mode and boot the machine.
2. At the first screen, "Please Define the System Console", type a 1 and
press enter.
3. At the next screen, type 1 and press enter to have English during install.
4. At the next screen, "Welcome to Base Operating System Installation and
Maintenance", select 3 - Start Maintenance Mode for System Recovery.
5. At the "Maintenance" screen, select 1 - Access a Root Volume Group.
6. At the "Warning" screen, press 0 to continue.
7. At the screen, "Access a Root Volume Group", select the number for the
Root Volume Group to display the LV information and press enter.
8. At the "Volume Group Information" screen, select 2 -Access this Volume
Group and start a shell before mounting filesystems.
9. At the root prompt, type 'exit' to continue the process of accessing the
root volume group.
10. At the next prompt, set the TERM variable, using:

TERM=vt100 export TERM (where vt100 is the emulation used)

11. At the next prompt, change the root password, using:

passwd

You will then be prompted for a new root password. You will be asked
to enter it a 2nd time to confirm.

12. Shutdown and reboot the system in normal mode. Turn the keyswitch to
'normal' mode and type:

shutdown -Fr

Solaris login check

To check the status of the UNIX account.

# /usr/bin/logins -aoxl username

Checking disk mapping in Linux system

Below is the command to check the correct PV to scsi mapping in the Linux system:

# scsiinfo -a /dev/sda1

Checking Solaris hardware component

I've learned the command to check and verify Solaris's hardware component including ram, processor details, system model and architecture, network and etc. The command is the following below:

# /usr/platform/`uname -m`/sbin/prtdiag

Using public keys for SSH authentication

Source taken from http://www.putty.nl/0.58/htmldoc/Chapter8.html#pubkey

Public key authentication - an introduction

Public key authentication is an alternative means of identifying yourself to a login server, instead of typing a password. It is more secure and more flexible, but more difficult to set up.

In conventional password authentication, you prove you are who you claim to be by proving that you know the correct password. The only way to prove you know the password is to tell the server what you think the password is. This means that if the server has been hacked, or spoofed (see section 2.2), an attacker can learn your password.

Public key authentication solves this problem. You generate a key pair, consisting of a public key (which everybody is allowed to know) and a private key (which you keep secret and do not give to anybody). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine.

So you generate a key pair on your own computer, and you copy the public key to the server. Then, when the server asks you to prove who you are, PuTTY can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in. Now if the server is hacked or spoofed, the attacker does not gain your private key or password; they only gain one signature. And signatures cannot be re-used, so they have gained nothing.

There is a problem with this: if your private key is stored unprotected on your own computer, then anybody who gains access to that will be able to generate signatures as if they were you. So they will be able to log in to your server under your account. For this reason, your private key is usually encrypted when it is stored on your local machine, using a passphrase of your choice. In order to generate a signature, PuTTY must decrypt the key, so you have to type your passphrase.

This can make public-key authentication less convenient than password authentication: every time you log in to the server, instead of typing a short password, you have to type a longer passphrase. One solution to this is to use an authentication agent, a separate program which holds decrypted private keys and generates signatures on request. PuTTY's authentication agent is called Pageant. When you begin a Windows session, you start Pageant and load your private key into it (typing your passphrase once). For the rest of your session, you can start PuTTY any number of times and Pageant will automatically generate signatures without you having to do anything. When you close your Windows session, Pageant shuts down, without ever having stored your decrypted private key on disk. Many people feel this is a good compromise between security and convenience. See chapter 9 for further details.

There is more than one public-key algorithm available. The most common is RSA, but others exist, notably DSA (otherwise known as DSS), the USA's federal Digital Signature Standard. The key types supported by PuTTY are described in section 8.2.2.

For Unix, what are ssh-agent and ssh-add, and how do I use them?

Source taken from http://kb.iu.edu/data/aeww.html

In Unix, ssh-agent is a background program that handles passwords for SSH private keys. The ssh-add command prompts the user for a private key password and adds it to the list maintained by ssh-agent. Once you add a password to ssh-agent, you will not be prompted for it when using SSH or scp to connect to hosts with your public key.

To use ssh-agent and ssh-add, follow the steps below:

1. At the Unix prompt, enter: eval `ssh-agent` Note: Make sure you use the backquote ( ` ), located under the tilde ( ~ ), rather than the single quote ( ' ).
   
   
2. Enter the command: ssh-add
3. Enter your private key password.
   
   
4. When you log out, enter the command: kill $SSH_AGENT_PID To run this command automatically when you log out, place it in your .logout file (if you are using csh or tcsh) or your .bash_logout file (if you are using bash).

Note: The versions of these programs for SSH2, ssh-agent2 and ssh-add2, are the same as outlined above. To use them, follow the instructions above, replacing all occurrences of ssh-agent with ssh-agent2 , and ssh-add with ssh-add2 . The SSH2 versions will only work if both your computer and the remote host are running SSH2.