DB2 10.1 High Availability Active Passive on RHEL 5 Update 8 with Tivoli SA MP and RSCT (Reliable Scalable Cluster Technology) Done

Below are the screenshot of the status of DB2 10.1 High Availability Active Passive on RHEL 5 Update 8 with Tivoli SA MP and RSCT (Reliable Scalable Cluster Technology).

Below is the status of DB2 Level and Cluster Manager integration in Instance Configuration:

next screenshot, I will try to Switch Role of Active/Passive Nodes (Current Active Node is rhel58n2 and Passive Node is rhel58n1):

See the Request=Move(Online:O)

We will wait again for few more seconds until the Pending Online status become Online for resource IBM.Application:db2_db2ap_0-rs and IBM.Application:db2_db2ap_0-rs:rhel58n1

And now the final status of the DB2 is Online at rhel58n1, it means that the switchover processes is success.

Finally we will check on rhel58n1 (Node 01 - Active one) the status of current DB2 Database named HADB:

Great..


Note: 
There's a lot of tricky part for doing this correctly, if you do have some problem configuring DB2 HA Active Passive, or wants to just asking questions, I would be glad to help or answer, if I do have time.


- wdanyant -

Error “DB2JAVIT : RC = 9505” when starting IBM DB2 Control Center on Windows 7 Platform

After installing IBM DB2 on Windows Platform especially on Windows 7 or Windows Vista Platform, when trying to launch Control Center or some of the IBM DB2 tools, usually you will meet this error “DB2JAVIT : RC = 9505” or don't seem to do anything or not showing at all.

Here is what you need to do to fix this:

Right Click on the launch shortcut and select “Run as administrator”

And then you will successfully run the IBM DB2 Tools such as Control Center:

If on every reboot after installation you get a "SQL5005C System Error", then you should add your user account to the local DB2ADMNS or to the local DB2USERS group. These groups are created during the DB2 installation, but left empty.

- wdanyant -

Removing 90 days password expiration and loosen password restriction on Exadata Machine

After ResecureMachine Step in Exadata run, password now are required to be reset/changed and must be complex and this password will expired in 90 days.

To avoid having to reset the passwords and also to avoid the password expiration interval of 90 days, you must run the following command for each user on the system including root (i.e. root, celladmin, cellmonitor on cells and root, oracle on DB nodes): 

chage -d 14000 -E -1 -m 0 -M -1 <username>

To loosen the password restrictions and lessen complexity, login to each node as root and modify /etc/pam.d/system-auth by modifying the string "min=disabled,disabled,16,12,8" to be "min=1,1,1,1,1". After that, reset the root password to whatever value you'd like (suggestion: welcome1 :). 

- wdanyant -

How to change user to root when using oracle user on Exadata

How to change user to root when using oracle user on Exadata?
When trying to su to "root" user as "oracle", eventhough the password is correct, always showing incorrect password.

[oracle@server ~]$ su - root
Password:
su: incorrect password
[oracle@server ~]$

This is because of the "oracle" user is not a member of wheel group and this was done purposely by the Oracle Exadata Team.

If we want to do su to "root" user, just try solution below:

Add the oracle user to the wheel group.

usermod -G wheel oracle

- wdanyant -

How to change PAM settings that have tightened in Oracle Linux 5.7

How to change PAM settings that have tightened in Oracle Linux 5.7?


First deployment of Exadata 11.2.3.1.X and later, the Oracle Linux have been upgraded to version 5.7 which was having a little bit different locking mechanism or we can just say "the PAM settings tightened in OEL 5.7".


What does it means PAM settings tightened in OEL 5.7 ? 
When try to login (can be as root) with a wrong password, the user root account will be locked up until 10 minutes / 600 seconds before we can try to login again (Connection retries must wait 10 minutes / 600 seconds between retries can occur).


How do we change that PAM / security settings in OEL 5.7?

In modern Linux distributions, the default security mechanism governing SSH connections is the PAM service.
This service mainly uses one configuration file to drive the wait time and lockout value when too many incorrect connections are attempted: 
/etc/pam.d/sshd


Basically one line is used to define these timeouts/lockouts:
auth required pam_tally2.so deny=5 onerr=fail lock_time=600


The values to note are:
auth required pam_tally2.so deny=5 onerr=fail lock_time=600

The value set in the "deny" parameter governs how many attempts can be made to login using a user account before that account is locked. In this case it is set to 5 retries.
The value set in "lock_time" is the parameter which governs how long one must wait before attempting to log in again. This value appears to be set much higher than in the past- which is a result of "hardening" the SSH login process, and to discourage attempts to "guess" the password.

Both values can be altered. Setting them as follows causes the behavior noted:  
auth required pam_tally2.so deny=3 onerr=fail lock_time=10
In this case- you would only have 3 attempts to login using an account before that account is locked.
Also- the time you will be forced to wait before attempting another login is now reduced from 10 minutes (600 seconds) to 10 seconds.

After making changes to this file, the changes will only become effective when the following command is issued by the "root" user: 
# services sshd restart


- wdanyant -

How to unlock user account that has been locked up in Exadata

How to unlock user account that has been locked up in Exadata?


This is a major questions that Exadata customers has asked because of they have input the wrong character/password on the screen.
if the user locked is not root, e.g. celladmin, then login as root user and execute this command:

root@cel01# pam_tally2
Login           Failures Latest failure     From
celladmin           1    06/29/12 19:49:29  10.102.3.30


From above command you will see the failure login from which user
and the for the unlock or reset command : pam_tally2 -u <username> -r :

root@cel01# pam_tally2 -u celladmin -r
Login           Failures Latest failure     From
celladmin           1    06/29/12 19:49:29  10.102.3.30
root@cel01#


After executing above reset command, now the celladmin user can try to login again to the Exadata Cell Nodes.

Note:

pam_tally2 has the following options:

pam_tally2: [-f rooted-filename] [--file rooted-filename]
[-u username] [--user username]
 [-r] [--reset[=n]] [--quiet]

If you do not wish to have pam_tally2 enabled, please check the files in /etc/pam.d/ for entries that include "pam_tally2.so" and remove these entries

Example:

/etc/pam.d/sshd

auth       required     pam_tally2.so deny=5 onerr=fail

References:
Failed to Login Through SSH to Database Node (Doc ID 1329000.1)
Login not Possible Error: pam_tally2(sshd:auth): user oracle (1000) tally 48, deny 5 (Doc ID 1269133.1)


- wdanyant -