UnixPedia : HPUX / LINUX / SOLARIS: October 2013

Friday, October 18, 2013

ORACLE : WHAT IS OEM (ORACLE ENTERPRISE MANAGER (OEM))

ORACLE ENTERPRISE MANAGER (OEM)

GUI to administer, monitor and tune multiple databases. It consists of a centralized console,

intelligent agents and a package of standard application that provide database administrators

functionality they need to manage database.

 

OEM Console

An application that permits a database administrator to manage several databases from one

machine. It provides a global view of the system and consists of a menu, a launch pallette, a

navigator which provides hierarchical view of Oracle services on the network, a map which

permits Oracle services to be grouped based on spatial relationships, functions or both, a job

that permits remote execution of tasks related to databases, listeners and an event system that

monitors and reports on system status. The OEM common services are Repository, Service

Directory and Security.

Intelligent Agent

A process that runs on remote nodes in the network. It executes jobs and events sent by the

console and communicates results back to console using Net8.

OEM Repository

A set of database tables that holds information used by OEM.

OEM DATABASE ADMINISTRATION TOOLS

Instance Manager

Schema Manager

Security Manager

Storage Manager

SQL Worksheet

Backup Manager

Data Manager

OEM PERFORMANCE PACK

Performance Manager

Top Session Monitor

Lock Manager

Advance Events

Tablespace Manager

Trace

Expert

Wednesday, October 16, 2013

HPUX: Change Login UMASK on Trusted Systems from Default 077 with General Release Patches for HP-UX 11.23 and HP-UX 11.31

HP-UX 11i Security - Ability to Change Login UMASK on Trusted Systems from Default 077 with General Release Patches for HP-UX 11.23 and HP-UX 11.31
Issue
A default login umask can be configured via the UMASK attribute described in security(4) . Currently, for a login into a Trusted System, the pam_unix(5) PAM module does not allow the default umask to be less restrictive than 077 . This restriction is not normally an issue for an interactive login session (such as telnet or rlogin), because the umask can be reset later (for example in the /etc/profile file).
However, this restriction can be an issue in other situations, for example, remsh a command/script, ssh a command/script, rcp , scp , ftp , or sftp .
The restrictive umask prevents these commands from creating files with access permissions less restrictive than 0700 .
Example :
The remote execution to a Trusted System shows default restricted umask 077 :

      user1@barbados# ssh nut umask
      Password: 
      077
      user1@barbados# remsh nut umask
      077
Solution
HP-UX engineering has delivered General Release (GR) patches with the option to be able to change the default login umask setting on a Trusted System. Along with required patch or patches, the existence of a trigger file in the /etc/default directory called BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS is required. If this file exists, then pam_unix does not impose any additional trusted_system restrictions on the umask . This allows Services to use a less restrictive default umask value, as configured in the /etc/default/security file.
However, Services, such as telnet or rlogin, will continue to use the restrictive umask of 077 as the default.
The following are GR patches available for enabling this option:

    HP-UX 11.31 Patch PHCO_39232, libpam_hpsec.
    HP-UX 11.23 Patches PHCO_39230, libpam_unix AND PHCO_39231, libpam_hpsec.
    HP-UX 11.11 no Patch available, option not be available with this release.
After installing the appropriate patch or patches, follow the patch instructions (detailed in the Patch Descriptions) as follows:
Manually create the required trigger file in /etc/default as follows:

   /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS    
   rw-rw-rw- 1  root bin  Feb 13 10:41 BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
Modify the umask setting in file /etc/default/security to the desired setting.
Example :
#UMASK 022
to
UMASK 022
Example :
The remote command execution to a Trusted System now uses the desired umask setting (022 ) defined in the /etc/default/security _file:

    user1@barbados# ssh nut umask
    Password: 
    022
    user1@barbados# remsh nut umask
    022

=======================================
Issue : when user was copying files using “scp” without –p option from source server to target server, he’s getting the permission issue on copied files on target server.
He’s getting 600 permissions
ssh hcsftpsm@Jupitor.jnj.com umask is showing 077

Target server OS : 11.31

Sol : -
Verify the patches mentioned in the above document is installed or not on target server as below : -

#-> swlist -l patch |grep -i PHCO_40072
  PHCO_40072.CORE-64SLIB           1.0               OS-Core.CORE-64SLIB    applied

#-> swlist -a supersedes -l fileset | grep -E 'PHCO_39232|PHCO_40072'
# PHCO_40072
  PHCO_40072.CORE-64SLIB                                PHCO_36743.CORE-64SLIB,fr=* PHCO_38601.CORE-64SLIB,fr=* PHCO_38824.CORE-64SLIB,fr=* PHCO_39232.CORE-64SLIB,fr=*
  PHCO_40072.CORE-ENG-A-MAN                             PHCO_36743.CORE-ENG-A-MAN,fr=* PHCO_38601.CORE-ENG-A-MAN,fr=* PHCO_38824.CORE-ENG-A-MAN,fr=* PHCO_39232.CORE-ENG-A-MAN,fr=*
  PHCO_40072.CORE-SHLIBS                                PHCO_36743.CORE-SHLIBS,fr=* PHCO_38601.CORE-SHLIBS,fr=* PHCO_38824.CORE-SHLIBS,fr=* PHCO_39232.CORE-SHLIBS,fr=*
  PHCO_40072.CORE2-64SLIB                               PHCO_36743.CORE2-64SLIB,fr=* PHCO_38601.CORE2-64SLIB,fr=* PHCO_38824.CORE2-64SLIB,fr=* PHCO_39232.CORE2-64SLIB,fr=*
  PHCO_40072.CORE2-SHLIBS                               PHCO_36743.CORE2-SHLIBS,fr=* PHCO_38601.CORE2-SHLIBS,fr=* PHCO_38824.CORE2-SHLIBS,fr=* PHCO_39232.CORE2-SHLIBS,fr=*
[root@Jupitor:/etc/opt/ssh]#
#-> swlist -l patch |grep -i PHCO_41282
[root@Jupitor:/etc/opt/ssh]#
#-> swlist -a supersedes -l fileset | grep -E 'PHCO_41282'
  PHCO_41859.RBAC-CONF                                  PHCO_36479.RBAC-CONF,fr=* PHCO_37832.RBAC-CONF,fr=* PHCO_38583.RBAC-CONF,fr=* PHCO_40131.RBAC-CONF,fr=* PHCO_40362.RBAC-CONF,fr=* PHCO_41282.RBAC-CONF,fr=*
  PHCO_41859.RBAC-ENG-A-MAN                             PHCO_36479.RBAC-ENG-A-MAN,fr=* PHCO_37832.RBAC-ENG-A-MAN,fr=* PHCO_38583.RBAC-ENG-A-MAN,fr=* PHCO_40131.RBAC-ENG-A-MAN,fr=* PHCO_40362.RBAC-ENG-A-MAN,fr=* PHCO_41282.RBAC-ENG-A-MAN,fr=*
  PHCO_41859.RBAC-RUN                                   PHCO_36479.RBAC-RUN,fr=* PHCO_37832.RBAC-RUN,fr=* PHCO_38583.RBAC-RUN,fr=* PHCO_40131.RBAC-RUN,fr=* PHCO_40362.RBAC-RUN,fr=* PHCO_41282.RBAC-RUN,fr=*
[root@Jupitor:/etc/opt/ssh]#
Required patched installed on the server, now proceed with below steps :-
[root@Jupitor:/.root]#
#-> ll /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
/etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS not found
[root@Jupitor:/.root]#
#-> touch /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
[root@Jupitor:/.root]#
#-> chmod 666 /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
[root@Jupitor:/.root]#
#-> chown root:bin /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
[root@Jupitor:/.root]#
#-> ll /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
-rw-rw-rw-   1 root       bin              0 Sep 17 18:08 /etc/default/BYPASS_TRUSTED_SYSTEM_UMASK_RESTRICTIONS
[root@Jupitor:/.root]#
#-> cat /etc/default/security |grep -i umask
# Default umask value upon login. Note: This
# attribute controls umask(2) of all sessions
# UMASK=0022
UMASK=022
[root@Jupitor:/.root]#

Verify/copy the files now, issue resolved.
You will get 644 permissions for the copied files.
ssh hcsftpsm@Jupitor.jnj.com umask is showing 022

HPUX : VGIMPORT: LVM GROUP FILE HAS THE WRONG MAJOR NUMBER; IT IS NOT AN LVM DEVICE

While giving   the major number to a vg , due typo instead 64 , 4 has been supplied to the vg
#-> vgimport -vsN -m ethp_vg.mapfile /dev/ethp_vg
Beginning the import process on Volume Group "/dev/ethp_vg".
vgimport: LVM group file has the wrong major number; it is not an LVM device.
#-> ll /dev/*/group
crw-r--r--   1 root       sys         64 0x060000 Oct 16 08:51 /dev/crdp_vg/group
crw-r-----   1 root       sys         64 0x030000 Jun 12  2012 /dev/dpyp_vg/group
crw-r-----   1 root       sys         64 0x020000 Jun 12  2012 /dev/eesp_vg/group
crw-r--r--   1 root       sys          4 0x0a0000 Oct 16 08:53 /dev/ethp_vg/group
crw-r-----   1 root       sys         64 0x010000 Jun 12  2012 /dev/latp_vg/group
crw-r-----   1 root       sys         64 0x090000 Feb 13  2013 /dev/lfsp_vg/group
crw-r-----   1 root       sys         64 0x040000 Jun 13  2012 /dev/ncsp_vg/group
crw-r-----   1 root       sys         64 0x000000 Feb  8  2012 /dev/vg00/group
crw-r-----   1 root       sys         64 0x050000 Jun 19  2012 /dev/vg_lock/group
crw-r-----   1 root       sys         64 0x080000 Aug  8  2012 /dev/vg_openv/group
crw-r-----   1 root       sys         64 0x0b0000 Sep 22 13:14 /dev/vg_oraback/group
crw-r-----   1 root       sys         64 0x070000 Aug  7  2012 /dev/vg_tdmf/group
Solution
Remove the group file and re-create the file.
#-> rm /dev/ethp_vg/group
#-> mknod /dev/ethp_vg/group c 64 0x0a0000

Thursday, October 10, 2013

HPUX : HOW TO TURN ON NETWORK TRACE ON/OFF THE SERVER

   Turn on nettl trace to find any network issues during the recovery hang.

 
On the ignite server:
 
(To start the trace)
# nettl -tn pduin pduout -tracemax 99999 -n 10 -e ns_ls_ip -f /tmp/raw
 
(To stop the trace)
# nettl -tf -e all

Friday, October 4, 2013

HPUX :WHAT HAPPENS WHEN A NODE TIMES OUT

WHAT HAPPENS WHEN A NODE TIMES OUT

Each node sends a heartbeat message to all other nodes at an interval equal to one-fourth of the
value of the configured MEMBER_TIMEOUT or 1 second, whichever is less.

When a node detects that another node has failed (that is, no heartbeat message has arrived
within MEMBER_TIMEOUT microseconds), the following sequence of events occurs:

1. The node contacts the other nodes and tries to re-form the cluster without the failed node.
2. If the remaining nodes are a majority or can obtain the cluster lock, they form a new cluster
without the failed node.
3. If the remaining nodes are not a majority or cannot get the cluster lock, they halt (system reset).

HEALTHY NODE STATUS:




INCASE  OF FAILURE :





EXAMPLE
SITUATION.
Assume a two-node cluster, with Package1 running on JUPITOR and Package2 running
on EARTH. Volume group vg01 is exclusively activated on JUPITOR; volume group vg02is
exclusively activated on EARTH. Package IP addresses are assigned to JUPITOR and EARTH
respectively.

FAILURE.
Only one LAN has been configured for both heartbeat and data traffic. During the course
of operations, heavy application traffic monopolizes the bandwidth of the network, preventing
heartbeat packets from getting through.

Since JUPITOR does not receive heartbeat messages from EARTH, JUPITOR attempts to reform
as a one-node cluster. Likewise, since EARTH does not receive heartbeat messages from
JUPITOR, EARTH also attempts to reform as a one-node cluster.

ELECTION PROCESS:
During the election protocol,each node votes for itself, giving both nodes 50 percent of the vote.
Because both nodes have 50 percent of the vote, both nodes now vie for the cluster lock.
Only one node will get the lock.

OUTCOME.
Assume JUPITOR gets the cluster lock. JUPITOR reforms as a one-node cluster. After
re-formation, JUPITOR will make sure all applications configured to run on an existing cluster
node are running. When JUPITOR discovers Package2 is not running in the cluster it will try to
start Package2 if Package2 is configured to run on JUPITOR.
EARTH recognizes that it has failed to get the cluster lock and so cannot re-form the cluster. To
release all resources related to Package2 (such as exclusive access to volume group vg02 and

the Package2 IP address) as quickly as possible, EARTH halts (system reset).

Thursday, October 3, 2013

HPUX : PVDISPLAY: COULDN'T QUERY THE LIST OF PHYSICAL VOLUMES



One of the four path of a device file is showing could not able to query.

#-> pvdisplay /dev/dsk/c110t5d0
pvdisplay: Warning: couldn't query physical volume "/dev/dsk/c110t5d0":
The specified path does not correspond to physical volume attached to
this volume group
pvdisplay: Couldn't query the list of physical volumes.
pvdisplay: Couldn't retrieve the names of the physical volumes
belonging to volume group "/dev/vg0011a".
pvdisplay: Cannot display physical volume "/dev/dsk/c110t5d0".

--- Physical volumes ---
PV Name                     /dev/dsk/c106t5d0
PV Name                     /dev/dsk/c104t5d0   Alternate Link
PV Name                     /dev/dsk/c107t5d0   Alternate Link
VG Name                     /dev/vg0011a
PV Status                   available
Allocatable                 yes
VGDA                        2
Cur LV                      1
PE Size (Mbytes)            32
Total PE                    2169
Free PE                     149
Allocated PE                2020
Stale PE                    0
IO Timeout                  default
Autoswitch                  On
Proactive Polling           On


#-> strings /etc/lvmtab |grep -i /dev/dsk/c110t5d0
/dev/dsk/c110t5d0

Recommedation: To resolve the issue
#-> vgchange -a e /dev/vg0011a
Volume group "/dev/vg0011a" has been successfully changed.
It will re-query the path.

#->  pvdisplay -v /dev/dsk/c106t5d0 |more
--- Physical volumes ---
PV Name                     /dev/dsk/c106t5d0
PV Name                     /dev/dsk/c110t5d0   Alternate Link
PV Name                     /dev/dsk/c104t5d0   Alternate Link
PV Name                     /dev/dsk/c107t5d0   Alternate Link
VG Name                     /dev/vg0011a
PV Status                   available