related posts:
https://forums.oracle.com/thread/1087777
http://www.iamidm.com/2013/04/weblogic-error-ldap-bootstrap.html
We ran into this crazy issue today.
Problem Summary
---------------------------------------------------
Oracle 11g IDM WLS_ods1 server could not be started up JPS-01050
Problem Description
---------------------------------------------------
We installed 11G IDM with the OID only. After the installation, both Admin Server and WLS_ODS1 server are up and running.
We
then reconfigured the node manager, IDM Admin Server and WLS_ODS1
server to use the Custom Certificates. Then we restarted node Manager,
and we restarted Admin Server using startWeblogic.cmd under
e:\oracle\idm\user_project\domains\idmdomain
Admin Server is up,
but wls_ods1 is down. From Admin Server Console, I can see that the node
manager is reachable. Restart WLS_ODS1 from the Admin Server Console,
failed. WLS_ODS1.log is giving the following info:
JPS-01050:Opening of wallet credential store failed. PKI-02002: Unable to open the wallet. Check password.
I then tried to start WLS_ODS1 from
e:\oracle\idm\user_project\domains\idmdomain using startWeblogicManagedServer.cmd, WLS_ODS1 is started successfully.
When I tried to start Admin Server from the node manager via wlst, I got the same errors.
It appears that we have a problem to start servers from the node manager.
--------------------------------------------
Solution:
We have tried everything.
We used the ideas suggested in the above posts, such as:
(1)"using orapki you should be able to see the contents of the wallet without a password. try using this:
ORACLE_WM_HOME/oracle_common/bin/orapki wallet display -wallet ORACLE_WM_HOME/user_projects/domains/idmdomain/config/fmwconfig "
It worked. the content seemed fine.
(2) we also recreated the wallet using the following:
Oracle wallet, if it still asking password when you have cwallet.sso file, it means it corrupted.
Just generate it again:
orapki wallet create -wallet wallet path on fmwconfig -auto_login_only
That should create a new cwallet.sso.
(3)We have changed permission to e:\tmp folder and other temp folder and etc.
None of the above worked!
(4)
At the end, we decided to use FileMon to find out exactly which wallet it was trying to open. From the FileMon output, we can see that the wallet was found and used. but we found the system is looking for folder "c:\Temp; c:\TMP" and was not able to open it.
The cause: Oracle WLS node manager or WLS server is looking for directory defined by environment variable TEMP and TMP to locate the folder where it can write temporary files into, and could not find it.
Oracle gave extremely misleading error messages!
Once we cleaned up environment varilable TEMP and TMP to include only 1 folder. The problem went away. We can start the Admin Server from the node manager via wlst.cmd. and we can also start wls_ods1 from the admin console, which uses node manager to start the managed server.
Wednesday, June 26, 2013
Tuesday, June 25, 2013
Deinstall Portal 11g and IDM 11g
In previous posts, I have discussed about how to deinstall Portal 11g and IDM 11g when the admin server is running.
In this post, I am going to discuss the case when the admin server is messed up and can not be started. So, how do we deinstall Portal and IDM in this case?
We have performed the following in this case:
(1) deinstall oracle_home by running the following in a command prompt with administrative privilege:
Setup.exe -deinstall
Note that Setup.exe can be found under Oracle/home/oui/bin and oracle/oracle_instance/oui/bin. Use the one under Oracle/home/oui
(2) Stop all related windows services.
(3) manually remove all folders under oracle/idm and oracle/portal.
If you run into errors complaining about "file being used by another program", restart your server. Then try again. You should be able to clean up everything.
(4) delete all related windows services by running the following in a command prompt with administrative privilege:
sc delete "windows service name"
(5) remove related items in windows "Start" menu.
(6) remove related item under system Path in the system environment variable
(7) run "regedit" to remove all related Oracle registries.
(8) We then reversed our database to the date before our last IDM and Portal installation.
After the above clean-up, we are able to successfully reinstall IDM 11g and Portal 11g.
In this post, I am going to discuss the case when the admin server is messed up and can not be started. So, how do we deinstall Portal and IDM in this case?
We have performed the following in this case:
(1) deinstall oracle_home by running the following in a command prompt with administrative privilege:
Setup.exe -deinstall
Note that Setup.exe can be found under Oracle/home/oui/bin and oracle/oracle_instance/oui/bin. Use the one under Oracle/home/oui
(2) Stop all related windows services.
(3) manually remove all folders under oracle/idm and oracle/portal.
If you run into errors complaining about "file being used by another program", restart your server. Then try again. You should be able to clean up everything.
(4) delete all related windows services by running the following in a command prompt with administrative privilege:
sc delete "windows service name"
(5) remove related items in windows "Start" menu.
(6) remove related item under system Path in the system environment variable
(7) run "regedit" to remove all related Oracle registries.
(8) We then reversed our database to the date before our last IDM and Portal installation.
After the above clean-up, we are able to successfully reinstall IDM 11g and Portal 11g.
Thursday, June 6, 2013
Oracle HTTP Server: nzos_Handshake returned 29039, too restrictive SSLCipherSuite
The following are copied from Johnathon's post:
http://www.trumbleshoot.com/home/announcements/nzlibraryerrorsinoraclehttpserver
I ran into the same problem when working with OHS 11.1.1.6. This post helped resolving it. Many thanks to Johnathon for that!
http://www.trumbleshoot.com/home/announcements/nzlibraryerrorsinoraclehttpserver
I ran into the same problem when working with OHS 11.1.1.6. This post helped resolving it. Many thanks to Johnathon for that!
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
ohs1.log
[OHS] [NOTIFICATION:16] [OHS-9999] [core.c] [host_id: trumble-web] [host_addr: x.x.x.x] [pid: 1760] [tid: 47526511683200] [user: root] [VirtualHost: main] Oracle-Application-Server-11g/11.1.1.6.0 Oracle-HTTP-Server (Unix) mod_ssl/11.0.0.0.0 OtherSSL/0.0.0 mod_plsql/11.1.1.0.0 mod_onsint/2.0 configured -- resuming normal operations
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] nzos handshake error, nzos_Handshake returned 29039(server HOSTNAME:9999, client 127.0.0.1)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1132067136] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1121577280] [user: root] [VirtualHost: HOSTNAME:9999] NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]
[OHS] [ERROR:32] [] [core.c] [host_id: HOSTNAME] [host_addr: x.x.x.x] [pid: 1896] [tid: 1132067136] [user: root] [VirtualHost: HOSTNAME:9999] unusably short session_id provided (0 bytes)
This infuriating message repeats over and over, and the OHS instance continuously cycles itself. I tried adjusting the cipher suites on all of my virtual hosts (thanks for the awesome hint), but naturally that didn't make any difference. Firewalls were also set up correctly, and I even reverted back to the default SSL wallet.
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
httpd.conf
{..snippet..}
Listen 127.0.0.1:7890
{..snippet..}
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
One of the most frustratingly simple problems I've run into in quite a while popped up in my OHS logs a long time ago, and then again recently in a new implementation. Here is what I was seeing:
What's this then? Bug 12696971 apparently covers this problem. I initially ignored this note (and similar ones) because I hadn't disabled my non-SSL port, but was still getting these errors. Yet, simply adding a (random) non-SSL listen port in httpd.conf allows OPMN to establish a connection.
The line can go anywhere, really. And the port can be any unused port as long as the IP is the loopback address for your machine. That's all there is to it!
On a side note, I don't really see this as being a security issue, as is mentioned in the note. Support says to use port 80, but that's not even necessary. The port is only exposed locally to the web server, and can be totally random. If you're worried about what someone might be able to access over an unencrypted channel, consider the fact that they'd have to have already gained access to the server itself. Just saying.
|
Reconfigure Portal 11g
How to recover from Portal 11g Configuration Failure?
If portal 11g configuration fails in the middle due to network flow problems, such as: the needed port is not open, how do we recover from there?
Answer: Deinstall Portal Instance. And then reconfigure portal.
The last post described the steps to deinstall Portal Instance. This post describes how to reconfigure Poratl 11g.
- Use windows explorer to find out where config.batis located. Most likely it is located under a directory like the following:
-
- Open up a command line prompt with "run as administrator", and execute the following:
1. cd oracle\poratl\portal_home\oui\bin
2. config.bat
In "Install Type", select "Extend Weblogic Domain"
3. On the next screen you will need to enter the following information:
If portal 11g configuration fails in the middle due to network flow problems, such as: the needed port is not open, how do we recover from there?
Answer: Deinstall Portal Instance. And then reconfigure portal.
The last post described the steps to deinstall Portal Instance. This post describes how to reconfigure Poratl 11g.
- Use windows explorer to find out where config.batis located. Most likely it is located under a directory like the following:
-
- Open up a command line prompt with "run as administrator", and execute the following:
1. cd oracle\poratl\portal_home\oui\bin
2. config.bat
In "Install Type", select "Extend Weblogic Domain"
3. On the next screen you will need to enter the following information:
a. Domain Host Name:
b. Domain Port No: (i.e. 7001)
c. User name: (i.e. weblogic)
d. Password: <password for weblogic admin user)
4.
b. Domain Port No: (i.e. 7001)
c. User name: (i.e. weblogic)
d. Password: <password for weblogic admin user)
Deinstall Portal 11g or Portal Instance
How to recover from Portal 11g Configuration Failure?
If portal 11g configuration fails in the middle due to network flow problems, such as: the needed port is not open, how do we recover from there?
Answer: Deinstall Portal Instance. And then reconfigure portal.
Below describes the steps to deinstall Portal Instance. Next post will describe how to reconfigure Poratl 11g.
- Use windows explorer to find out where setup.exe is located. Most likely it is located under a directory like the following:
oracle\poratl\portal_home\oui\bin
- Open up a command line prompt with "run as administrator", and execute the following:
1. cd oracle\poratl\portal_home\oui\bin
2. setup.exe -deinstall
In "Deinstall Type", select "Deinstall ASInstance managed by Weblogic Domain"
3. On the next screen you will need to enter the following information:
Note: Make sure the WebLogic admin server is running.
- In most cases, there is no need to deinstall Oracle_Home if you are trying to recover from a configuration failure. But in the case that you do need to deinstall Oracle_Home, reran "setup.exe -deinstall" and setlect type "Deinstall Oracle Home".
Use the following link as a reference:
http://www.idmworks.com/blog/entry/uninstalling-oracle-fusion-middleware-products
If portal 11g configuration fails in the middle due to network flow problems, such as: the needed port is not open, how do we recover from there?
Answer: Deinstall Portal Instance. And then reconfigure portal.
Below describes the steps to deinstall Portal Instance. Next post will describe how to reconfigure Poratl 11g.
- Use windows explorer to find out where setup.exe is located. Most likely it is located under a directory like the following:
oracle\poratl\portal_home\oui\bin
- Open up a command line prompt with "run as administrator", and execute the following:
1. cd oracle\poratl\portal_home\oui\bin
2. setup.exe -deinstall
In "Deinstall Type", select "Deinstall ASInstance managed by Weblogic Domain"
3. On the next screen you will need to enter the following information:
a. Domain Host Name:
b. Domain Port No: (i.e. 7001)
c. User name: (i.e. weblogic)
d. Password: <password for weblogic admin user)
b. Domain Port No: (i.e. 7001)
c. User name: (i.e. weblogic)
d. Password: <password for weblogic admin user)
Note: Make sure the WebLogic admin server is running.
- In most cases, there is no need to deinstall Oracle_Home if you are trying to recover from a configuration failure. But in the case that you do need to deinstall Oracle_Home, reran "setup.exe -deinstall" and setlect type "Deinstall Oracle Home".
Use the following link as a reference:
http://www.idmworks.com/blog/entry/uninstalling-oracle-fusion-middleware-products
Wednesday, June 5, 2013
EM Console shows OID being down
The content of post is from the following:
http://coreidng.blogspot.ca/2011/05/em-console-11g-shows-oid-is-down.html
It is explained so well. This is no need for me to write about it again.
The EM console also displays the following error while trying to access the OID instance under Farm_IDMDomain -> Identity and Access -> oid1 or while trying to create a wallet for SSL
http://coreidng.blogspot.ca/2011/05/em-console-11g-shows-oid-is-down.html
It is explained so well. This is no need for me to write about it again.
EM Console 11g shows OID is down
The Enterprise Manager Fusion Middleware Control 11g shows OID is down even though opmnctl shows OID is up.
Error:
Information Configuration settings are unavailable because /Farm_IDMDomain/OID_Inst/oid1 is down.
There could be 2 reasons for this.
Reason1:
The WebLogic user password used by EM Console to monitor OID is not correct.
Solution:
- Go to the Farm drop down menu on the top of EM Console -> Agent Monitored Targets -> Configure . Verify if the Weblogic Monitoring User Name is correct and Change the WebLogic Monitoring Password to the correct password. Click Ok.
- Check the OID status now.
Reason2:
The IP address/hostname given in the Middleware Administration Server Service URL is wrong.
The following is an example of the Middleware Administration Server Service URL
service:jmx:t3://your_ip_address:7002/jndi/weblogic.management.mbeanservers.domainruntime
Solution:
- Go to the Farm drop down menu on the top of EM Console -> Agent Monitored Targets -> Configure .
- Try using hostname instead of IP address. Click OK and verify the status of OID from EM console.
Mod_wl_ohs HTTPS Becomes HTTP, how to fix this?
I was creating a management proxy for my weblogic admin server. Mod_wl_ohs is used. mod_ossl is used. I am using Oracle HTTP Server 11g (version 10.3.6)
During debugging, I found that my https requests often becomes http requests. And that is the reason why my weblogic admin console page does not come up.
Searched internet. There had been no post related to this.
Search through oracle's support site, finally found that it was caused by an Oracle bug. Below is extracted from Oracle notes on this.
During debugging, I found that my https requests often becomes http requests. And that is the reason why my weblogic admin console page does not come up.
Searched internet. There had been no post related to this.
Search through oracle's support site, finally found that it was caused by an Oracle bug. Below is extracted from Oracle notes on this.
Configuring Mod_wl_ohs to use SSL between Oracle HTTP Server and Weblogic Server in FMW 11g (11.1.1.X):
5. On FMW 11.1.1.4 or higher, there is an extra step required to prevent redirects going to http. This problem is documented in Note 1300169.1 HTTPS Request Returns HTTP When Using Redirects Through Mod_wl_ohs.
To prevent this problem:
To prevent this problem:
- Access the WebLogic Server console
- Click on ‘Environment’- > 'Servers' -> '<SSL_Managed_Server>' -> 'General' -> 'Advanced'
- Check the 'WebLogic Plug-In Enabled' box.
- Click 'Save'
- Restart the Admin Server or Managed Server depending on which server you are SSL into.
This has been an undocumented change and thus an internal documentation bug filed for a future release.
Bug 11824138 HTTPS REQUEST RETURNS HTTP WHEN USING REDIRECTS THROUGH MOD_WL_OHS
Also if you are planning on accessing /b2bconsole then you need also set 'WebLogic Plug-In Enabled' at the Domain level as well, otherwise you will hit the problem in Note 1335638.1 Accessing /b2bconsole Redirects To HTTP After Configuring Mod_wl_ohs To Use SSL Between Oracle HTTP Server And Weblogic Server
Bug 11824138 HTTPS REQUEST RETURNS HTTP WHEN USING REDIRECTS THROUGH MOD_WL_OHS
Also if you are planning on accessing /b2bconsole then you need also set 'WebLogic Plug-In Enabled' at the Domain level as well, otherwise you will hit the problem in Note 1335638.1 Accessing /b2bconsole Redirects To HTTP After Configuring Mod_wl_ohs To Use SSL Between Oracle HTTP Server And Weblogic Server
- Access the WebLogic Server console
- Click on 'SOA_Domain' -> 'Web Applications'
- Check the 'WebLogic Plug-In Enabled' box.
- Click 'Save'
- Restart the soa_server1 Managed Server.
6. Test you can access the application via https:
https://host.domain:port/contextroot
For example: https://ohs.uk.oracle.com:4448/helloWorld
https://host.domain:port/contextroot
For example: https://ohs.uk.oracle.com:4448/helloWorld
Subscribe to:
Posts (Atom)