I’ve been using an iPhone sinceFebruary and over that time I have used a bunch of websites running on Oracle. Such as Grid Control, custom applications deployed on Weblogic and Oracle Application Server, etc all which work fine. I wasn’t asked to test our applications but happened to be in situations where my iPhone was quickly available.
I was kind of surprised when I was told one of our applications didn’t work properly on the iPhone or iPad. When a user tried to access the site a Safari error would pop up:
“Safari can’t open the page <website> because Safari can’t establish a secure connection to the server <website>”
We also verified the problem existed on the desktop with Safari 5.
A quick search on Google turns out a ton of hits, none of them solved the problem but provided us with some ideas to try out. We contracted our SSL certificate provider and they sent us another chain certificate and a different root certificate which they said would resolve any issues we were having Apple products.
We loaded them into Oracle Wallet manager but unfortunately that didn’t work either. Back to square one.
A coworker enabled tracing in Webcache and noticed the following in the logfile:
[17/Jun/2010:10:48:46 -0400] [warning 11904] [ecid: 104838150494,0] SSL handshake fails NZE-29048
Since it was an obvious error on the client side I was surprised to see this as a warning. It just goes to show that if your trying to troubleshoot a problem, always enable tracing.
This error led me to Metalink note:
Internet Explorer Fails To Connect To Web Cache Via SSL If SSLV2.0 Is Unchecked - NZE-29048 [ID 342626.1]
By default Webcache sets SSL_ENABLED to SSLV3_V2H which only supports SSL V2.0 and SSLV3.0 not TLSv1. In the Metalink note they did an Ethereal Sniff and found that IE tries to use TLSv1 but since by default its not supported, it can’t connect. I also found a post in the Safari forum of Apple Discussions which basically talks about the same problem.
In our staging environment I tried the fix, changing SSLENABLED in $ORACLE_HOME/webcache/webcache.xml from SSLV3_V2H to SSL, restarted Webcache and success!
What made this problem slightly more confusing to troubleshoot was that we have another environment with the same version of Webcache. We could access that application from our iPhone/iPad successfully. The only difference is in that case SSL isn’t handled by Webcache but by an SSL accelerator.
Tuesday
Why are R12 patches so large?
While performing patch analysis for some one-off patches I noticed there was quite a size difference between codelines. (ie. R12.AP.A vs R12.AP.B) For example, take a look at payables patch 8733916. The version compatible with AP.A is 35.4MB while the AP.B version is only 9MB.
A coworker forwarded me a note from Metalink which describes the issue:
Release 12: Why are One-Off Patches so Large? [ID 841218.1]
The note has an interesting chart which shows how many files are applied from a patch based on the codelevel. Basically a one-off patch contains all the files necessary to fix the problem on a base R12 release. So to summarize the note, the more upto date you keep your EBS environment, the less work adpatch has to do in order to apply patches.
Background Info: Adpatch performs a number of tasks when applying a patch. One of them is to compare versions of files supplied by the patch to those in your EBS environment. Only newer files will be copied.
In my case, with patch 8733916, its basically the same situation. R12.0 was released I believe back in Jan 2007, while R12.1 was released in May 2009. So if a bug affects both versions, its not surprising that the patch would be smaller for R12.1 since its more upto date. Now, I would assume this is highly dependant on the bug but I haven’t seen a patch for R12.1 that is larger than R12.0.
A coworker forwarded me a note from Metalink which describes the issue:
Release 12: Why are One-Off Patches so Large? [ID 841218.1]
The note has an interesting chart which shows how many files are applied from a patch based on the codelevel. Basically a one-off patch contains all the files necessary to fix the problem on a base R12 release. So to summarize the note, the more upto date you keep your EBS environment, the less work adpatch has to do in order to apply patches.
Background Info: Adpatch performs a number of tasks when applying a patch. One of them is to compare versions of files supplied by the patch to those in your EBS environment. Only newer files will be copied.
In my case, with patch 8733916, its basically the same situation. R12.0 was released I believe back in Jan 2007, while R12.1 was released in May 2009. So if a bug affects both versions, its not surprising that the patch would be smaller for R12.1 since its more upto date. Now, I would assume this is highly dependant on the bug but I haven’t seen a patch for R12.1 that is larger than R12.0.
Wednesday
Fusion Middleware and 11g DB Password Expiry
As a few DBA’s have noticed, the 11g database has password expiry enabled. This is not entirely a bad thing, I am in favor of this move. However, if your not aware of this change then it can cause you some problems with your Fusion Middleware (FMW) 11g environment.
Developers contacted me with
ORA-28001: the password has expired.
Originally I didn’t even think of the repository accounts being an issue. I assumed it was a password policy in Oracle Internet Directory (OID) or WebLogic accounts they created for deploying applications. After those were verified, then the only thing left was the database.
A quick look at dba_users showed a couple of accounts already expired or in grace status:
USERNAME ACCOUNT_STATUS LOCK_DATE EXPIRY_DA
------------------------------ -------------------------------- --------- ---------
DCM EXPIRED 12-MAY-10
ORASSO_PS EXPIRED 10-MAY-10
DEV_PORTAL EXPIRED 10-MAY-10
ODSSM EXPIRED 10-MAY-10
ORASSO EXPIRED(GRACE) 20-MAY-10
You can view the password policy of the database default profile by looking at dba_profiles:
SQL> select * from dba_profiles;
PROFILE RESOURCE_NAME RESOURCE LIMIT
------------------------------ -------------------------------- -------- ---------------------
DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10
DEFAULT PASSWORD_LIFE_TIME PASSWORD 180
DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED
DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED
DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL
DEFAULT PASSWORD_LOCK_TIME PASSWORD 1
DEFAULT PASSWORD_GRACE_TIME PASSWORD 7
I personally do not like to have password expiry setup for database level application accounts. In most cases the passwords for these accounts can’t be changed without downtime, so its best to have a policy were once a quarter (or whatever your corporate standards are) to manually change these passwords.
Since individual end users do not have their own database level accounts I modified the default profile. If this is not the case for your server, you may want to create a new profile for application users so that you can have separate password policies.
The command to alter the default profile is:
SQL> alter profile default limit PASSWORD_LIFE_TIME unlimited FAILED_LOGIN_ATTEMPTS unlimited;
The next task was to re-enable expired accounts. To do this the password for these accounts need to be changed manually and I would recommend reusing the same password. One thing I need to do is investigate password changes for FMW accounts and see if there are any dependencies. NOTE: If PASSWORD_REUSE_MAX is not set to UNLIMITED you may not be able to reuse the previous password.
Remember back to the Fusion Middleware installation, you were prompted to create passwords for a number of repository accounts. If any of these accounts have expired either issue the
alter user <username> identified by <password>;
or login as each user and you’ll be prompted for a new password. As noted above, use the previous password.
You may notice or find out the hard way, that you don’t have the passwords for some of these accounts. If you take a look at the DBA_USERS query above you’ll notice the ORASSO, ORASSO_PS, and DCM users. When these accounts are created they are assigned random passwords. Use ldapsearch, changing the OrclResourceName parameter for each account you need to find the password for:
[oracle@myserver ~]$ ldapsearch -b "orclReferenceName=<SID>.world,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext" -D cn=orcladmin -h <OID Server> -p 3060 -q OrclResourceName=ORASSO
Please enter bind password:
OrclResourceName=ORASSO,orclReferenceName=MYDB.world,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext
orclflexattribute1=true
orclresourcename=ORASSO
objectclass=orclResourceDescriptor
objectclass=top
orclpasswordattribute=AECR63ZP
The current password is identified by orclpasswordattribute. Now you can reset the password for these accounts as you did with the others above.
Developers contacted me with
ORA-28001: the password has expired.
Originally I didn’t even think of the repository accounts being an issue. I assumed it was a password policy in Oracle Internet Directory (OID) or WebLogic accounts they created for deploying applications. After those were verified, then the only thing left was the database.
A quick look at dba_users showed a couple of accounts already expired or in grace status:
USERNAME ACCOUNT_STATUS LOCK_DATE EXPIRY_DA
------------------------------ -------------------------------- --------- ---------
DCM EXPIRED 12-MAY-10
ORASSO_PS EXPIRED 10-MAY-10
DEV_PORTAL EXPIRED 10-MAY-10
ODSSM EXPIRED 10-MAY-10
ORASSO EXPIRED(GRACE) 20-MAY-10
You can view the password policy of the database default profile by looking at dba_profiles:
SQL> select * from dba_profiles;
PROFILE RESOURCE_NAME RESOURCE LIMIT
------------------------------ -------------------------------- -------- ---------------------
DEFAULT FAILED_LOGIN_ATTEMPTS PASSWORD 10
DEFAULT PASSWORD_LIFE_TIME PASSWORD 180
DEFAULT PASSWORD_REUSE_TIME PASSWORD UNLIMITED
DEFAULT PASSWORD_REUSE_MAX PASSWORD UNLIMITED
DEFAULT PASSWORD_VERIFY_FUNCTION PASSWORD NULL
DEFAULT PASSWORD_LOCK_TIME PASSWORD 1
DEFAULT PASSWORD_GRACE_TIME PASSWORD 7
I personally do not like to have password expiry setup for database level application accounts. In most cases the passwords for these accounts can’t be changed without downtime, so its best to have a policy were once a quarter (or whatever your corporate standards are) to manually change these passwords.
Since individual end users do not have their own database level accounts I modified the default profile. If this is not the case for your server, you may want to create a new profile for application users so that you can have separate password policies.
The command to alter the default profile is:
SQL> alter profile default limit PASSWORD_LIFE_TIME unlimited FAILED_LOGIN_ATTEMPTS unlimited;
The next task was to re-enable expired accounts. To do this the password for these accounts need to be changed manually and I would recommend reusing the same password. One thing I need to do is investigate password changes for FMW accounts and see if there are any dependencies. NOTE: If PASSWORD_REUSE_MAX is not set to UNLIMITED you may not be able to reuse the previous password.
Remember back to the Fusion Middleware installation, you were prompted to create passwords for a number of repository accounts. If any of these accounts have expired either issue the
alter user <username> identified by <password>;
or login as each user and you’ll be prompted for a new password. As noted above, use the previous password.
You may notice or find out the hard way, that you don’t have the passwords for some of these accounts. If you take a look at the DBA_USERS query above you’ll notice the ORASSO, ORASSO_PS, and DCM users. When these accounts are created they are assigned random passwords. Use ldapsearch, changing the OrclResourceName parameter for each account you need to find the password for:
[oracle@myserver ~]$ ldapsearch -b "orclReferenceName=<SID>.world,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext" -D cn=orcladmin -h <OID Server> -p 3060 -q OrclResourceName=ORASSO
Please enter bind password:
OrclResourceName=ORASSO,orclReferenceName=MYDB.world,cn=IAS Infrastructure Databases,cn=IAS,cn=Products,cn=OracleContext
orclflexattribute1=true
orclresourcename=ORASSO
objectclass=orclResourceDescriptor
objectclass=top
orclpasswordattribute=AECR63ZP
The current password is identified by orclpasswordattribute. Now you can reset the password for these accounts as you did with the others above.
Tuesday
OID 11g: Viewing and Setting the Password Policy via ODSM and the Command Line
We are about to go live with our new 11g Fusion Middleware environment and wanted to setup the password policy for user accounts before they logged in for the first time.
I logged in to Oracle Directory Services Manager, which by default resides at http://server:7005/odsm. The first screen is informational and shows you some relevant version numbers and some statistics.
To change password policy options click on the Security tab followed by clicking on Password Policy.
Next you need to determine the correct policy to modify. The easiest way is to probably look at the Distinguished Name which has the proper domain component values. (ie. dc=youserver, dc=com)
There are a number of options you can set for your password policy and the values you choose will be dependent on your corporate standards. To get help for any particular option click on it and a context sensitive dialog box will appear with more information.
Once you have made all your changed click on the apply button. This is where I ran into trouble and was presented with the following error:
I searched google, Metalink but didn’t find any solutions so I decided to try the command line method.
Login to the server which hosts your Identity Management Domain and initialize your environment. Properly set, ldapsearch and ldapmodify should be in your path.
To view the password policy use ldapsearch utility:
To modify the password policy use ldapmodify and pass it a file containing the options you’d like to change:
In the PolicyMod.txt document below I am modifying the minimum length of a password and the number of failures before their account is locked:
So now you are familiar with two methods to changing password policy settings.
I logged in to Oracle Directory Services Manager, which by default resides at http://server:7005/odsm. The first screen is informational and shows you some relevant version numbers and some statistics.
To change password policy options click on the Security tab followed by clicking on Password Policy.
Next you need to determine the correct policy to modify. The easiest way is to probably look at the Distinguished Name which has the proper domain component values. (ie. dc=youserver, dc=com)
There are a number of options you can set for your password policy and the values you choose will be dependent on your corporate standards. To get help for any particular option click on it and a context sensitive dialog box will appear with more information.
Once you have made all your changed click on the apply button. This is where I ran into trouble and was presented with the following error:
I searched google, Metalink but didn’t find any solutions so I decided to try the command line method.
Login to the server which hosts your Identity Management Domain and initialize your environment. Properly set, ldapsearch and ldapmodify should be in your path.
To view the password policy use ldapsearch utility:
ldapsearch -D "cn=orcladmin" -w <orcladmin_pass> -h <OID_Host> -p 3060 -b "cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=mydomain,dc=com" -s sub "(objectclass=*)" "*" cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=mydomain,dc=com orclpwdminalphachars=0 pwdfailurecountinterval=300 orclpwdmaxrptchars=0 pwdlockoutduration=86400 objectclass=top objectclass=pwdpolicy pwdmaxfailure=5 orclpwdminuppercase=0 orclpwdencryptionenable=0 pwdminlength=8 orclpwdalphanumeric=1 cn=default pwdlockout=1 pwdchecksyntax=1
orclpwdpolicyenable=1 pwdgraceloginlimit=5
pwdexpirewarning=604800 pwdmaxage=10368000 orclpwdminspecialchars=0 orclpwdminlowercase=0
To modify the password policy use ldapmodify and pass it a file containing the options you’d like to change:
ldapmodify -p 3060 -D cn=orcladmin -w password < PolicyMod.txt
In the PolicyMod.txt document below I am modifying the minimum length of a password and the number of failures before their account is locked:
dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=myserver,dc=com changetype: modify replace: pwdminlength pwdminlength: 8 dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=myserver,dc=com changetype: modify replace: pwdmaxfailure pwdmaxfailure: 5
So now you are familiar with two methods to changing password policy settings.
Refreshing VS Cloning an e-Business Suite Environment
Just a quick note on refreshing vs cloning, what each of them means and when you should perform them.
What is Refreshing?
A refresh is where the data in the target environment has been synchronized with a copy of production. This is done by taking a copy of the production database and restoring it to the target environment.
What is Cloning?
Cloning means that an identical copy of production has been taken and restore to the target environment. This is done by taking both a copy of the production database as well as all of the application files.
When should you Clone or Refresh?
There are a couple of scenarios when cloning should be performed:
1. Building a new environment.
2. Patches or other configuration changes have been made to the target environment so that they are now out of sync.
3. Beginning of development cycles. Before major development efforts take place, its wise to re-clone dev, test environments so that your 100% positive that the environments are in sync.
There is only one scenario in which you should refresh an environment:
1. Your 100% confident that the environments are in sync and need an updated copy of the production data in order to reproduce issues.
Technically, if proper change control processes are being followed, test and production environments should be identical. So in the case of test, you should be able to get away with performing refreshes. However, to ease concerns and for comfort levels, test environments are usually re-cloned at the beginning of new development cycles as well.
If I have missed any scenarios, feel free to comment.
Related Articles:
R12 Cloning with RMAN
What is Refreshing?
A refresh is where the data in the target environment has been synchronized with a copy of production. This is done by taking a copy of the production database and restoring it to the target environment.
What is Cloning?
Cloning means that an identical copy of production has been taken and restore to the target environment. This is done by taking both a copy of the production database as well as all of the application files.
When should you Clone or Refresh?
There are a couple of scenarios when cloning should be performed:
1. Building a new environment.
2. Patches or other configuration changes have been made to the target environment so that they are now out of sync.
3. Beginning of development cycles. Before major development efforts take place, its wise to re-clone dev, test environments so that your 100% positive that the environments are in sync.
There is only one scenario in which you should refresh an environment:
1. Your 100% confident that the environments are in sync and need an updated copy of the production data in order to reproduce issues.
Technically, if proper change control processes are being followed, test and production environments should be identical. So in the case of test, you should be able to get away with performing refreshes. However, to ease concerns and for comfort levels, test environments are usually re-cloned at the beginning of new development cycles as well.
If I have missed any scenarios, feel free to comment.
Related Articles:
R12 Cloning with RMAN
Subscribe to:
Posts (Atom)