Finding superblocks and fsck in RHEL

"If it looks like there is an issue with the filesystem's superblock. By running the command below we can check for the location of where backup superblocks will be:

mkfs.ext3 -n /dev/mapper/vg01-lvol5

The mkfs command may cause you some worry, but I'd like to stress the importance of -n option. This causes it to not actually perform any changes. Here is an excerpt from the mkfs.ext3 man page:

 -n     Causes mke2fs to not actually create a filesystem,  but  display

              what it would do if it were to create a filesystem.  This can be

              used to determine the location of the backup superblocks  for  a

              particular  filesystem,  so  long  as the mke2fs parameters that

              were passed when the filesystem was originally created are  used

              again.  (With the -n option added, of course!)

After this we can look for the lines simlar to:

Superblock backups stored on blocks:

    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Take the first value, i.e. 32768 and try using the commands I previously pasted with the -b option.

Once again confirm that the operation to be performed looks sane, keeping in mind to replace 32768 with your actual value:

fsck -b 32768 -fN /dev/mapper/vg01-lvol5

Then if it looks good try with:

fsck -b 32768 -fy /dev/mapper/vg01-lvol5

If you find the first backup superblock does not work try again with the next available one, i.e. 98304.

Again please make sure to have the filesystem unmounted."

HP-UX : How to find out reboot is required for depot installation

If you have a depot, run this command against it.

swlist -l fileset -a is_reboot -s depot_name

this will tell you if the swinstall will reboot

HP UX : Creating a trusted host environment using SSH

The trusted host environment as an alternative to setting up public-private SSH key pairs.

For automation or in a scripted environment in which these types of calls are necessary, the trusted host network,

though still bearing some security risks, has advantages over the public-private key pair scenario.

A trusted host network or trusted host authentication relies primarily on preconfigured files that list a combination of users and hosts that are allowed access.

There are two types of trusted-host authentication. The older (such as for OpenSSH and SSH1) and weaker uses the clear-text protocol commands (rsh, rcp, and rlogin);

checks the two files; and sets one keyword in the sshd_config file:

/etc/hosts.equiv

~/.rhosts

SSH Protocol 2 does not support this method. Instead, for a more secure trusted host network,

make the following changes in the /etc/ssh/sshd_config file (which accepts host names or IP Addresses),

and configure the shosts.equiv and/or the .shosts files:

/etc/shosts.equiv

~/.shosts

To enable a trusted-host environment in the /etc/ssh/sshd_config file for SSH Protocol 2, use:

PermitEmptyPasswords yes

AllowSHosts remoteclient.com

DenySHosts

For example, if you were on the server example.com and had configured your /etc/shosts.equiv file as follows:

+remoteclient.com fsmythe

+secureserver.net sallyh

+192.168.100.12 fsmythe

-hackers.org james

you would allow user fsmythe trusted host authentication from the remote sources remoteclient.com, 192.168.100.12, and secureserver.net and user sallyh access from secureserver.net,

denying access from user james at the remote source hackers.org. The trusted-host authentication and public-private SSH key pair authentication methods are similar and to a greater end achieve the same results.

How do I move a Volume Group from one system to another?

We recently moved a server from one location to other but SAN as replicated one, not the original LUNs which were in use. Below are the steps followed.

1. Make sure to stop all the access to device coming from the old storage. You may need to unmount the devices if in use. Verify with the lsof command that no device is being used.

2. Poweroff the server. (step 1 can be skipped)

3. Detach the old storage.

4. Reboot the server and verify that it is booting correctly and no traces of old storage are present.

5. Poweroff the server. Move to another location. I assume here that the same multipathing software is being used, in our case it is EMC powerpath.

6. connect the server to new storage [Replicated disks] and boot the server.

7. All the LUNs should come up with the multipathing software. Any VGs should get activated.

You may also be interested in reading the following article (Commands in detail)

 https://access.redhat.com/knowledge/solutions/4123   How do I move a Volume Group from one system to another?

SPARC Super Cluster

http://www.oracle.com/technetwork/server-storage/hardware-solutions/ebusiness-on-sparc-supercluster-1851212.pdf  

Linux : VG details

Strings /etc/lvmtab will not have all info in Linux like HP-UX. 

for VG in `strings /etc/lvmtab`

do

echo "  ------------------------"

echo " /  ${VG}"

LINES=`vgdisplay -v ${VG} 2>/dev/null | grep -e "PV Name" | wc -l | awk '{print $1}'`

vgdisplay -v ${VG} 2>/dev/null | grep -e "PV Name" | \

awk '{if($5 != "\*") print $1, $2, $3, $4 ; else print $0}' 2>/dev/null | \

awk -v LT=${LINES} 'BEGIN {i=1} {if(i == LT) print " \\   " $NF ; else print "|    " $NF ; ++i}'

echo "  ------------------------"

done

identify the linux virtualization

#dmesg | grep -i virtual
#dmidecode | egrep -i 'manufacturer|product'
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Manufacturer: Intel Corporation
Product Name: 440BX Desktop Reference Platform
Manufacturer: No Enclosure
Manufacturer: GenuineIntel
Manufacturer: GenuineIntel
Manufacturer: 000000000000
Manufacturer: 000000000000
Manufacturer: Not Specified
Manufacturer: Not Specified
Manufacturer: Not Specified
Manufacturer: Not Specified
Manufacturer Name: Intel
#cat /proc/ide/hd*/model
VMware Virtual IDE CDROM Drive
#

NIS yppoll

# yppoll -h hostname -d domainname passwd.byname