Wednesday, January 27, 2010

HP-UX: Create a new software depot for patches

Taken from http://www.unixguide.net/hp/patch_depot.shtml

Creating a separate software depot for your patches is useful,
when space is tight and patches have dependencies.

Assuming you have two patches PHNE_20000 and PHNE_20001.

unshare all two patches by typing the following commands.

sh PHNE_20000
sh PHNE_20001

Next, we have to create a new software depot on the directory /newdir/depot

mkdir /newdir/depot
swpackage -s PHNE_20000.depot -d /newdir/depot

Register your new depot on the sd-ux.

swreg -l depot /newdir/depot

Copy the next patch to the newly created software depot.

swcopy -s `pwd`/PHNE_20001.depot PHNE_20001 @ /newdir/depot

You are now ready to install your patches

swinstall -s /newdir/depot

Wednesday, January 13, 2010

How to add temporary directory based swap space in HPUX

The examples enable paging to the file system containing the /paging directory. The maximum number of file system blocks available to the paging system is set to 5000, the number of file system blocks reserved for file system use only is set to 10000, and the priority is set to 2. The number of file system blocks initially taken by the paging system defaults to 0 in the first example, and is set to 0 in the second example. On a file system with the default 8kB block size, these examples allocate approximately 40MB of file system paging.

# /usr/sbin/swapon -l 5000 -r 10000 -p 2 /paging

Tuesday, February 3, 2009

lquerypr - low level tool to break scsi disk reservation

lquerypr -Vh /dev/vpath13 -- list
lquerypr -Vph /dev/vpath13 -- to reset


1. To test the persistent reservation status on the device:

lquerypr -h /dev/vpath30

This will try to read the persisten reservation on the device without displaying.
If there is a persistent reservation, shell return code will be 0 if device
reserved by the current host, or 1 if device reserved by the other hosts.

2. To test and display the persistent reservation on the device:

lquerypr -vh /dev/vpath30

Same as above. In addtion, it displays the persistent reservation key.

3. To release the persistent reservation if the device is reserved by the current host:

lquerypr -rh /dev/vpath30

Release the persistent reservation if device is reserved by the current host.
Return code should be 0 if the command succeeds or if device is not reserved.
If the command fails, return code is 2.

4. To remove the persistent reservation and clear all reservation key registration:

lquerypr -ch /dev/vpath30

Removes the persistent reservation and clears all reservation key registration.
Return code is 0 if the command succeeds or 2 if the command fails.

5. To remove the persistent reservation if the device is reserved by the other host

lquerypr -ph /dev/vpath30


Removes the persistent reservation by preempting the persistent reservation
reserved by the other hosts . Return code is 0 if the command succeeds or if the
device is not reserved;.or it returns 2 if the command fails.

Note: If the command issued without options of -p, -r or -c, the command
will return 0 if there is no persistent reservation key on the device, or the
device is reserved by the current host; it returns 1 if the persistent reservation
key is different from the host reservation key; it returns 2 if the command fails,
or it returns 3 if device is already opened.

If the command issued with one of the options of -p, -r or -c, it returns
0 if the command succeeds; it returns 2 if the command fails, or it returns 3
if device is alreayd opened.


**Thanks to Suhaila for contribution.

Thursday, September 4, 2008

SAN event data gathering tips

Taken from : http://www.redbooks.ibm.com/abstracts/tips0553.html

The purpose of this TIP is to outline all the basic information that needs to be collected to assist in resolving SAN related problems. You might find it daunting to have to go through several steps to gather all the data requested, but the most common cause of delays in problem resolution is a lack of data. Therefore, you should never assume that the root cause of any problem is in the most obvious place. By gathering logs from all parts of the SAN, you give yourself the greatest chance of getting a fast and effective resolution to the problem.

The second most common cause of delays in problem resolution is providing data that has been collected some hours or even days after the problem occurred. Often in this case, there is no longer evidence of the original problem. Timely and complete data collection will aid in problems being resolved quickly. Collection of timely and detailed information for hosts are outlined in the following sections.

The collection of log information is critical to understanding the cause of an event in a SAN environment, and to aid support in analyzing the collected logs. It is also useful to provide the time offsets of individual equipment. As some hardware may never have had its real-time clock set to the local time, it can become very difficult to match events from one piece of equipment to the other. Another important piece of information to aid in timely error analysis is a physical diagram of the SAN topology. This diagram should be kept up to date, and include all hosts, switches, directors, and storage devices within the SAN. This document can save countless hours of reconstructing the original picture by piecing together log information.

AIX

Time difference
Use the date command to display the system date and time.

Log collection
Collect both errpt and errpt -a (each piped to a file).

Hardware configuration collection
Take a snap (the errpt is found in a snap, but it is good to have a separate copy).
The preferred snap for IBM TotalStorage DS Family problems is:

snap -gfiLc where:

g - Gathers the output of the lslpp -hBc command, which collects the exact operating system environment
f - Gathers file system information
i - Gathers installation debug vital product data (VPD) information
L - Gathers LVM information
c - Creates a compressed pax image (snap.pax.Z file)


Multi-pathing data collection
SDD (all versions of AIX)
Issue the following commands and capture the output. This data is not found in a snap. Preferably provide the output of these commands during the failure.

datapath query adapter
datapath query device
lsvpcfg


MPIO (available on AIX 5.2 and above)
Issue the following commands and capture the output. This data is not included in a snap.

pcmpath query adapter
pcmpath query device
pcmpath query essmap


HP-UX

Time difference
Use the date command to get the system date and time.

Log collection
Collect the contents of the /var/adm/syslog/syslog.log file.

Hardware configuration collection
Provide the following server details for each server involved with the SAN:

Manufacturer
Machine Type/Model Number
Feature details, for example, number of CPUs, amount of memory


HBA details
For SAN problems we always need the following details about the FC HBAs:

Hardware manufacturer, brand and model
BIOS (firmware) level - BIOS settings if QLogic
Driver level


Software configuration collection
Capture the output of the uname -a command

Multi-pathing data collection
SDD
Issue the following commands and capture the output. Preferably provide the output of these commands during the failure.

datapath query adapter
datapath query device


Linux

Time difference
Use the date command to get the system date and time.

Log collection
Capture the contents of /var/log/messages
Capture the output of the dmesg command

Hardware configuration collection
For IBM xSeries hardware, the best way to collect configuration data is by using the e-gatherer tool. Make sure you also supply the HBA details. You can download e-gatherer from:




Software configuration collection
Capture the output of the command: uname -a

If you are running Redhat, install and run sysreport and send the output.

Multi-pathing Data Collection
SDD
Issue the following commands and capture the output. Preferably provide the output of these commands during the failure.

datapath query adapter
datapath query device


Microsoft Windows

Time difference
Display the system date and time using the clock in the bottom right hand corner, or by issuing the time and date commands at a command prompt.

Log collection
Always save the system logs and the application logs as soon as possible after the event.
Do not export and provide the logs in EVT format, it is not helpful.
To find the system logs, either right click My computer then Manage or click:

Start -> Programs -> Administrative Tools -> Computer Management
When this opens, go to:
System Tools -> Event Viewer -> System
And then:
Action -> Save Log file as changing the save as type to CSV
Repeat for Application logs.


Hardware configuration collection
For IBM xSeries hardware, the best way to collect configuration data is by using the e-gatherer tool. Make sure you also supply the HBA details. You can download e-gatherer from:




Software configuration data collection
If you cannot take the e-gatherer data provide:

Operating System
Service Pack Level


Multi-pathing data collection

SDD
If you are running SDD, issue the following commands and capture the output.

datapath query adapter
datapath query device


Novell Netware

Time difference
Display the system date and time.

Log collection
CONLOG.EXE is a utility which writes all system console messages to a .LOG file.
More details can be found at url:




Hardware configuration collection
There is no e-gatherer for Netware.

Software configuration data collection
Provide:

Operating System Level
State whether this is a clustered system


Multi-pathing data collection

SDD
If you are running SDD, issue the following commands and capture the output.

datapath query adapter
datapath query device


SUN Solaris

Time difference
Use the date command to get the system date and time.

Log collection
Save the /var/adm/messages file. Previous days messages are normally available as /var/adm/messagesx where x is the number of days since the logs rolled.

Hardware configuration collection
There is no e-gatherer or snap command to collect these details, so a good description of the hardware including the following is required:

Software configuration data collection
Provide :

Operating System details.
A copy of your sd.conf file
Output from iostat -El


Depending on the HBA there will be a /kernel/drv/*.conf where the * could be QLogic or JNI.

Multi-pathing data collection

SDD
Issue the following commands and capture the output.

datapath query adapter
datapath query device


Veritas Volume Manager DMP
Provide the output from the following commands:

ls -lL /dev/rdsk/*
ls -la /dev/vx/dmp/*
format


**Contributed by shah_mr

Sunday, June 15, 2008

Migrate filesystem on any UNIX platform

# cd /"source directory/filesystem"
# tar cfp - ./* |(cd /"target directory/FS"; tar xvfp -)

Thursday, May 15, 2008

Command to perform immediate ufsdump

E.g.:
ufsdump 0f - / | gzip -f -1 - > root.dump.gz

Tuesday, March 11, 2008

synclvodm - synchronising your logical volume manager in IBM AIX


Description

If you have problems with LVM because it is out of sync with the ODM in IBM AIX, you may see the following errors:

0516-306 getlvodm: Unable to find hd7copie in the Device
Configuration Database.
0516-912 rmlv: Unable to remove logical volume hd7copie.

To correct this, you must sync the ODM:

Before correction:

# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
...
hd7copie ??? 8 8 1 closed/syncd N/A

Run the sync command:

# synclvodm -v rootvg
synclvodm: Physical volume data updated.
synclvodm: Logical volume hd5 updated.
synclvodm: Logical volume hd6 updated.
synclvodm: Logical volume hd8 updated.
synclvodm: Logical volume hd4 updated.
synclvodm: Logical volume hd2 updated.
synclvodm: Logical volume hd9var updated.
synclvodm: Logical volume hd3 updated.
synclvodm: Logical volume hd1 updated.
synclvodm: Logical volume hd7 updated.
synclvodm: Logical volume hd7copie updated.
synclvodm: Logical volume rootvglv01 updated.

After the sync command completes:

# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
...
hd7copie dump 8 8 1 open/syncd N/A
Example

synclvodm -v vg_name

Friday, January 18, 2008

Tuesday, December 4, 2007

Howto switch on/off SMT features in LPAR

# smtctl -m 'on'

# smtctl -m 'off'

or via smitty -> under performance --> SMT

Wednesday, November 7, 2007

Alternative command for TOP in Solaris

There are fews command that to monitor overall performance.

1) sar 2 10
2) prstat

Sunday, October 28, 2007

Monday, October 22, 2007

How to "config manager" in Sun

# cfgadm -c

# devfsadm

# devfsadm -c disk

Monday, October 8, 2007

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

Sunday, October 7, 2007

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.

Wednesday, August 29, 2007

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

Tuesday, August 28, 2007

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)

NFS advanced mount options

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).

Tuesday, August 14, 2007

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

Friday, July 27, 2007

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.

Saturday, March 24, 2007

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