Posts Tagged Weblogic
Provide access to #WebLogic DMS Spy Servlet for readonly users
Posted by Torsten Kleiber in Configuration, Installation on August 30, 2017
For security reasons and to prevent the configuration drift it is recommendable to use read only for analyzing problems.
For read only access of configuration and logs WebLogic provides out of the box the group Monitors. Unfortunately you cannot access DMS Spy Servlet with this group, which is useful for analyse runtime values of the server. Only users which belongs to the Administrators group and therefore have full access can access DMS Spy Servlet and this is not configurable in WebLogic by default.
Here you can see how to add groups on linux to the DMS Spy Servlet deployment:
pushd $ORACLE_HOME/oracle_common/modules/oracle.dms cp dms.war dms.war.`date +%y.%m.%d.%H:%M` unzip dms.war WEB-INF/weblogic.xml sed -i '/Monitors/d' WEB-INF/weblogic.xml sed -i '/^ <principal-name>Administrators<\/principal-name>$/a\ <principal-name>Monitors<\/principal-name>' WEB-INF/weblogic.xml zip dms.war WEB-INF/weblogic.xml rm -r WEB-INF popd
Following is the responsible snippet in weblogic.xml before:
<security-role-assignment> <role-name>Admin</role-name> <principal-name>Administrators</principal-name> </security-role-assignment>
and after modification:
<security-role-assignment> <role-name>Admin</role-name> <principal-name>Administrators</principal-name> <principal-name>Monitors</principal-name> </security-role-assignment>
After this modification you have to restart the WebLogic Server.
That’s it!
Set all WebLogic log levels to “Inherit” via WLST
Posted by Torsten Kleiber in Configuration, Installation, Performance on August 22, 2016
Logging is a very useful feature of WebLogic.
Unfortunately the log levels, which are set after a clean install of WebLogic or some of the Fusion Middleware product creates a lot of noise and therefore it costs I/O performance.
Additional after analyzing an issue with logging often resetting the log level is forgotten.
Here you get a script to reset the log levels at regular intervals or after a trace session.
#!/usr/bin/python execfile('get_environment.py') connect(wlUser, wlPassword, wlAdminUrl) edit() loggers = listLoggers(target=managedServer, runtime=0) for key, value in loggers.items(): if key <> "" and key <> "ADF_PERFORMANCE_MONITOR_DATABASE" and value <> "": print "set " + key + " from " + value + " to <Inherited>" setLogLevel(target=managedServer, runtime=0, logger=key, level="") loggers = listLoggers(target=managedServer, runtime=0) exit()
In line 2 a script is called to initialize your environment variables wlUser, wlPassword, wlAdminUrl and managedServer.
In line 5 you get the list of loggers.
In line 6..9 you iterate over this list.
In line 7 you can add your own restrictions. Here are already filtered all inherited loggers and one special tool logger for performance monitoring of ADF applications.
In line 10 the loggers are shown again for the result, you can remove this.
Now call this script via
$ORACLE_HOME/oracle_common/common/bin/wlst.sh config_loglevel.py
In the output you see similar output:
------------------------------------------------------------------------+----------------- Logger | Level ------------------------------------------------------------------------+----------------- ... oracle.ods.virtualization.accesslog | ERROR:1 ... set oracle.ods.virtualization.accesslog from ERROR:1 to <Inherited> ------------------------------------------------------------------------+----------------- Logger | Level ------------------------------------------------------------------------+----------------- ... oracle.ods.virtualization.accesslog | <Inherited> ...
This version of the script change only the persistent logger levels (runtime=0), because we don’t want influence running trace sessions. But as our servers are dayly started, all runtime log levels are resetted at this point to the persistent one’s.
That’s it.
References:
Fasten your Oracle Forms and Reports 11g Server start on Unix derivates
Posted by Torsten Kleiber in Configuration on December 21, 2012
Do you see a slow start of your weblogic managed server for forms & reports on unix derivate? We have this problem on Suse SLES 11 and forms and reports 11.1.2.
In November I attended the annual DOAG (German Oracle User Group) conference in Nuremberg. There I’ve heare an interesting presentation from Jan-Peter Timmermann about “Performance with Forms 11gR2 Weblogic 10.3.x”.
One snippet of the presentation was an bug in the jdk which slows down the start of managed weblogic servers. It has to do with the random number generator during loading the OPSS Policy Provider for security. This issue is discussed in detail in this blog: http://www.itonguard.com/20090313/weblogic-starts-slow/.
These are the relevant log files before as an example for forms:
####<21.12.2012 07:38 Uhr MEZ> <Info> <WebLogicServer> <localhost> <> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1356071911941> <BEA-000000> <WebLogic Server "WLS_FORMS" version: WebLogic Server 10.3.5.0 Fri Apr 1 20:20:06 PDT 2011 1398638 Copyright (c) 1995, 2009, Oracle and/or its affiliates. All rights reserved.> ####<21.12.2012 07:38 Uhr MEZ> <Info> <IIOP> <localhost> <WLS_FORMS> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1356071912371> <BEA-002014> <IIOP subsystem enabled.> ####<21.12.2012 07:40 Uhr MEZ> <Info> <Security> <localhost> <WLS_FORMS> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1356072024665> <BEA-090894> <Successfully loaded the OPSS Policy Provider using oracle.security.jps.internal.policystore.JavaPolicyProvider.> ####<21.12.2012 07:41 Uhr MEZ> <Notice> <WebLogicServer> <localhost> <WLS_FORMS> <main> <<WLS Kernel>> <> <> <1356072069175> <BEA-000360> <Server started in RUNNING mode>
You see, that initializing the OPSS Policy Provider, which seems to use the random number generator, needs 2 minutes.
Now we will make a simple change in the Oracle Middleware JDK Runtime file (we have here SUN JDK 1.6.0_26 64bit)
<JDK Home>/jre/lib/security/java.security
Comment the original line as followed, an add a the marked new line:
#securerandom.source=file:/dev/urandom securerandom.source=file:/dev/./urandom
Now see the results for forms:
####<21.12.2012 07:57 Uhr MEZ> <Info> <WebLogicServer> <sdu10037> <> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1356073038615> <BEA-000000> <WebLogic Server "WLS_FORMS" version: WebLogic Server 10.3.5.0 Fri Apr 1 20:20:06 PDT 2011 1398638 Copyright (c) 1995, 2009, Oracle and/or its affiliates. All rights reserved.> ####<21.12.2012 07:57 Uhr MEZ> <Info> <IIOP> <localhost> <WLS_FORMS> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1356073039121> <BEA-002014> <IIOP subsystem enabled.> ####<21.12.2012 07:57 Uhr MEZ> <Info> <Security> <localhost> <WLS_FORMS> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1356073042034> <BEA-090894> <Successfully loaded the OPSS Policy Provider using oracle.security.jps.internal.policystore.JavaPolicyProvider.> ####<21.12.2012 07:58 Uhr MEZ> <Notice> <WebLogicServer> <localhost> <WLS_FORMS> <main> <<WLS Kernel>> <> <> <1356073086151> <BEA-000360> <Server started in RUNNING mode>
You see the loading of OPSS Policy Provider takes now no relevant time and the startup time in our case decrease from 3 to 1 minute. We see same improvement for the reports managed server.
Remember, your mileage may vary if
- Your are not on a affected unix derivate.
- You use not an jdk with this bug. Unfortunatly in the blog is not described the bug number.