Total Pageviews

Wednesday, October 19, 2016

to check last login in oracle query



select username, max(logoff_time) from dba_audit_trail group by username;

Monday, October 17, 2016

OIF adding data store information


OIF Identity Console
OIF Server
Administration
Data Stores

add

data store configuration

Webgate, setting logfile lcoation for troublehsooting




Steps to change Webgate Default Log file path
By default the in 10g webgate the log file(oblog.log) will be present in the <Webgate Installation directory>\access\oblix\logs directory.  This post explains the steps to change webgate default log file path in windows environment.  The steps explained here for oracle access manager 10g webgate.
  • Create a folder where you want to store the log files
Eg: D:\WebgateLogs
  • Navigate to <Webgate Installation directory>\access\oblix\
  • Take the back up of oblog_config_wg.xml
  • Open oblog_config_wg.xml
  • Search for LogTrace2Sys in this file.
  • For the FILE_NAME parameter for LogTrace2Sys , set the value to the new syslog.log Path . Also change the value for LOG_WRITER to FileLogWriter . Now the system logs will be redirected to the syslog file.
<ValNameList
xmlns=”http://www.oblix.com”
ListName=”LogTrace2Sys”>
<NameValPair
ParamName=”LOG_LEVEL”
Value=”LOGLEVEL_TRACE”>
</NameValPair>
<NameValPair
ParamName=”LOG_WRITER”
Value=”FileLogWriter“>
</NameValPair>
<NameValPair
ParamName=”FILE_NAME”
Value=”D:\WebgateLogs \syslog.log“>
<NameValPair
ParamName=”BUFFER_SIZE”
Value=”131072″></NameValPair>
<NameValPair
ParamName=”MAX_ROTATION_SIZE”
Value=”52428800″></NameValPair>
<NameValPair
ParamName=”MAX_ROTATION_TIME”
Value=”86400″></NameValPair>
<NameValPair
ParamName=”LOG_STATUS”
Value=”On”></NameValPair>
</ValNameList>
</ValNameList>
  • Search for LogAll2File
  • For the FILE_NAME parameter for LogAll2File, set the value to the new oblog.log Path
<!– Write all logs to the Oracle log file. –>
<ValNameList
xmlns=”http://www.oblix.com”
ListName=”LogAll2File”>
<NameValPair
ParamName=”LOG_LEVEL”
Value=”LOGLEVEL_ALL”>
</NameValPair>
<NameValPair
ParamName=”LOG_WRITER”
Value=”FileLogWriter”>
</NameValPair>
<NameValPair
ParamName=”FILE_NAME”
Value=” D:\WebgateLogs \oblog.log “></NameValPair>
<NameValPair
ParamName=”BUFFER_SIZE”
Value=”131072″></NameValPair>
<NameValPair
ParamName=”MAX_ROTATION_SIZE”
Value=”52428800″></NameValPair>
<NameValPair
ParamName=”MAX_ROTATION_TIME”
Value=”86400″></NameValPair>
<NameValPair
ParamName=”LOG_STATUS”
Value=”On”></NameValPair>
</ValNameList>
  •  Save the file
  • Give required write permission to WebgateLogs folder to the Administrator and other users.
  • Restart the web server.
  • Access the some protected urls and make sure that the Webgate logs are redirected to the new file.

webgate log file location



you can find webgate log configuration information at oblog_config_wg.xml



The oblog_config_wg.xml file is updated when you edit to configure Webgate logging. For example, by setting a new log threshold level, changing a log file name, or filtering logs related to some modules and so on.
Log configuration, oblog_config_wg.xml, files reside in the following locations depending upon your Webgate version:
10g Webgates: Webgate_install_dir\oblix\config
11g Webgates: Webgate/Oracle_Home under webgate/ohs/config and Instance_Home/webgate/config (the later to be used when configuring logging).
The same oblog_config_wg.xml file is copied to the Webgate instance directory when the Webgate instance is created. In Instance_Home, this file is located at webgate/config.
Note:
Do not change the path to this file. If you install more than one instance, a log configuration file is installed for each instance. When configuring logging, use oblog_config_wg.xml under Instance_Home should be updated.
After installation, oblog_config_wg.xml and oblog_config_wg_original.xml both contain comments to help guide your editing.
Table 23-2 lists the names of the log configuration files. Do not change the names.

Table 23-2 Log Configuration File Names for Components
ComponentLog Configuration FIle Name
Webgateoblog_config_wg.xml
Access Manager SDK (custom Access Client)oblog_config.xml


How to update the JDK: update the references to the JDK location in $DOMAIN_HOME/bin/setDomainEnv.sh



How to update the JDK:
update the references to the JDK location in $DOMAIN_HOME/bin/setDomainEnv.sh


when weblogic starts it reads configuration information from

•    $MW_HOME/wlserver_10.3/common/bin/commEnv.sh

ohs version information

./httpd -version
Server version: Oracle-HTTP-Server/2.2.15 (Unix)
Server built:   Apr  2 2011 23:51:27
Server label:   APACHE_11.1.1.5.0_LINUX.X64_110325.2001

if above command does not provide Server label than try below file, it had components version information including jdk oam 

find file comps.xml

it should be under /inventory/ContentsXML/


Programatically obtain the variables using the fcgi-bin executable:
http://servername:port/fcgi-bin/echo
http://servername:port/cgi-bin/printenv


If ServerTokens is not set to Prod in httpd.conf, you can also see the version on a page not found page, when requesting an invalid file:
http://servername:port/thispageisnotfound


ls -d $ORACLE_HOME/inventory/Components*/*/* | grep "apache.apache"
  

jvm crash file

hs_err_pidXXXX.log

tar command giving blocksize =2


if you get bow error. please check the size of your file. it might not downloaded correctly and it only have few bites in it




















solaris version information

solaris version information

cat /etc/release

or

uname -r

or

uname -a
 

ohs restart error .apachectl


/ohs/bin/.apachectl: Permission denied


check the permission of user who is running the command.   file .apachectl priviliges should be like

chown root .apachectl
chmod 6750 .apachectl


if after these permission you are still getting above error than change permission to
chmod 7770 .apachect

it should resolve the issue.

if you want to debug the issues further do the following

1. Take a backup/copy of the directory <instace_home>\diagnostics\logs\OHS\ohs1\
2. Delete all the log files under <instace_home>\diagnostics\logs\OHS\ohs1\
3. Take a backup and delete State directory

The "states" directory is located in $ORACLE_INSTANCE/config/OPMN/opmn

4. Take a backup and delete all the log files under ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/*

5.
a) Backup and edit ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
b) Change the following lines

<debug comp="" rotation-size="1500000"/>

to

<debug comp="internal;ons;pm" rotation-size="1500000"/>


6. Please start opmn from instance_home and collect the logs.


oam 11gr2 making resouce url case insensitive



Additional Setting Required for Case Insensitive Policy Resource Matching

A setting must be added to oam-config.xml and configured in order to workaround an iussue with the "Case Insensitive Policy Resource Matching" option. The additional setting that must be added under PolicyService -> OAMPolicyProvider -> properties is:

<Setting Name="USE_CASE_INSENSITIVE_RESOURCE_MATCH
  "Type="xsd:boolean">true</Setting>


starting single opm component



opmnctl startproc ias-component=ohs1
 
 
checking ohs version
 
OHS 10g then we would need see ias_properties file for confirmation 



if getting library path error
 LD_LIBRARY_PATH
 

OIM 11.1.2.2.0 deploying and undeploying Schedule taks



Steps to undeploy old schedule task at OIM and redeploy new Schedule task


steps to Undeploy the previous schedule task
a.      Login to OIM SysAdmin console
Delete the Schedule Task - IDM Reconcile LDAP User Info to OIM
b.      Unregister the previous Schedule Task Plugin
ant –f pluginregis.xml unregister
Enter the classname -   idm.schedulejobs.ReconcileLDAPUserToOIM
steps to Deploy the Schedule Task
a.      Import the OID LDAP SSL certificate from the libovd keystore (adapters.jks) into the OIM JDK Keystore and OIM WLS Trust Keystore
b.      Copy the zip file to the OIM server
c.      Register the Schedule Task Plugin
ant –f pluginregis.xml register
Register the plugin zip – ReconcileLDAPUserToOIM.zip
d.      Import the ReconcileLDAPUserToOIM.xml using the OIM Deployment Manager
e.      Modify the Schedule Job parameters for LDAP IT Resource and LDAP Server URL to point to OID.
f.       Run the Purge Cache utility
Purgecache.sh All
b.      Restart the OIM Servers
a.      Do a test run of the schedule job by setting the value of Last Run Timestamp to 20150311100000z and remove the value after it is successfully complete
Test the out of the box schedule job to check for any infrastructure dependencies

command to see what is running on the port netstat command

netstat -nap | grep 5557

Execing EMAgent process is taking longer than expected 120 secs solution


Launching the JVM with following options: -Xmx207M -XX:MaxPermSize=96M

Execing EMAgent process is taking longer than expected 120 secs

EMAgent will be restarted because of an Out of Memory Exception

 [34626:GC.Executor.27 (oracle_oam_cluster:/MAS_OAMDomain-MAS/OAMDomain-MAS/OAMDomain:oracle_oam_cluster_config_files) (oracle_oam_cluster:/MAS_OAMDomain-MAS/OAMDomain-MAS/OAMDomain:oracle_oam_cluster_config_files:oracle_oam_cluster_config_files)] ERROR - oracle_oam_cluster:/MAS_OAMDomain-MAS/OAMDomain-MAS/OAMDomain:oracle_oam_cluster_config_files:oracle_oam_cluster_config_files 
java.lang.OutOfMemoryError: Java heap space 
at java.util.Arrays.copyOf(Arrays.java:2882) 


 Stop agent 

$/AGENT_INST/bin/emctl stop agent 

If agent does not shutdown gracefully then kill all agent background processes by first grepping for agent perl and java processes only 

$ps -ef | grep java | grep '<agent_home >' 
$ps -ef | grep perl 
$kill -9 <Process id> 

2. Take backup and edit /AGENT_INST/sysman/config/emd.properties file 

Note : Tune -Xmx and -XX:MaxPermSize parameters , in the below example heap value is increased to 512M from 128M . 
default 

agentJavaDefines=-Xmx130M -XX:MaxPermSize=96M 

new 

agentJavaDefines=-Xmx512M -XX:MaxPermSize=128M 

3. Restart agent 

$/AGENT_INST/bin/emctl start agent 

grep command to search at multipile files




grep 12-01T21  OPtime=[1-9][1-9][0-9][0-9][0-9]+
kill -9 'awk -F' ' '
oidldap019(5-9)*.log

TLS1.0 issue with andriod devices



Andriod devices support TLSv.1.1 and 1.2 any lower version are not compatible with Android devices. Apple support backward compatibility TLSv1.0 but they will remove this compatibility very soon.

if you are running OHS version lower version than 11.1.1.9, it will not support with Andriod devices connectivity.

in order for Andriod version to work with OHS, OHS version should be higher than 11.1.1.9


TLSv1.1 and 1.2 are supported by OHS starting with 11.1.1.9


soa jndi error




<Error> <oracle.sdp.messaging.util> <SDP-25717> <Error occurred in looking up Queue in JNDI, skipping: OraSDPM/Queues/OraSDPMDriverDefSndQ1. >
 <Error> <oracle.sdp.messaging.util> <SDP-25700> <An unexpected exception was caught.
javax.naming.NameNotFoundException: Unable to resolve 'OraSDPM.Queues.OraSDPMDriverDefSndQ1'. Resolved 'OraSDPM.Queues'; remaining name 'OraSDPMDriverDefSndQ1'


The reason for the change is that jndi seem to be attached to a distributed queue on servers 1 and 2 but not on server3.

<distributed-queue name="dist_OraSDPM/Queues/OraSDPMDriverDefSndQ1_auto"> 
<jndi-name>OraSDPM/Queues/OraSDPMDriverDefSndQ1</jndi-name> 

name="OraSDPM/Queues/OraSDPMDriverDefSndQ1_auto_3"></distributed-queue-member> 

</distributed-queue> 




OIM 11gR2Ps2 enabling/Restricts backurl parameter for EIDM url's



Step-by-Step Instructions:
Disabling whitelist validation and collecting values for the whitelist
1.Create and configure OIM system-property XL.AllowedBackURLsMode=Disable (see Mode above).

  An administrator can do this manually using OIM console.

 Some customers may choose to script this as a post-installation step in the installation-process.
2.Check the logs for warnings emitted by "OIMRedirectValidatorFilter::validateURL".
3.Collect from the input urls shown in those warnings in the logs the set of distinct host-and-port combinations that OIM should allow (as targets for redirection).
4.Create and Add to OIM system-property XL.AllowedBackURLs (see Whitelist above) each combination of host and port that OIM should allow.
  Once committed, the change to XL.AllowedBackURLs should take effect immediately. Once a URI has been added to that whitelist, OIM should consider to be valid any value of 'backURL' or          'endURL' that specifies the host from that URI. OIM should no longer log a warning for any value of 'backURL' or 'endURL' that specifies the host from any URI in the whitelist.
5.Once the administrator is confident that all necessary values have been added to the whitelist, an administrator should enable whitelist-validation (see next section below).

Enabling whitelist validation
1.Configure OIM system-property XL.AllowedBackURLsMode=Enforce (see Mode above).
1.An administrator can do this manually using OIM console. Please refer http://docs.oracle.com/cd/E23943_01/doc.1111/e14308/system_props.htm#BABCBCEB
2.Check the logs for severe errors emitted by "OIMRedirectValidatorFilter::validateURL".
3.Collect from the input urls shown in those errors in the logs the set of distinct host-and-port combinations that OIM should allow (as targets for redirection).
4.Add to OIM system-property XL.AllowedBackURLs (see Whitelist above) each combination of host and port that OIM should allow.
  Edit OIM system-property XL.AllowedBackURLs and add for each combination of host and port a URI that specifies the host and port. (OIM does not use the port-number currently, but may do so          in the future.)
  Once committed, the change to XL.AllowedBackURLs should take effect immediately. Once a URI has been added to that whitelist, OIM should consider to be valid any value of 'backURL' or              'endURL' that specifies the host from that URI. OIM should redirect successfully to any value of 'backURL' or 'endURL' that specifies the host from any URI in the whitelist.


webgate log location


go to oblog_config_wg.xml

webgate/config/oblog_config_wg.xml

modify

LOGLEVEL_DEBUG1

 

steps to upgrade JKD version at weblogic





Below is an outline of the steps that can be followed to upgrade the JDK and the Weblogic servers within a WebLogic domain.
1.      On the admin and any remote managed servers, install the new JDK (1.6.0_29+) in a directory that does not have the JDK version number in its name (e.g. /opt/oracle/jdk)
a.      Update existing JAVA_HOME definition. If it does not exist, create it.
b.      Copy cacerts from the old JDK to the new one (under jdk/jre/lib/security)
c.      (Optional) Apply JCE

2.      Stop managed and admin servers in the domain

3.      On the admin and any remote managed servers, back up the MW_HOME directories

4.      Copy the following files from the Admin Server to any remote managed servers
·        <domain_name>/config/config.xml
·        <domain_name>/security/SerializedSystemIni.dat

5.      (JDK 1.7 only) Copy the following files from $MW_HOME/modules to $JDK_ROOT/jre/lib/endorsed
·        javax.annotation_1.0.0.0_1-0.jar
·        javax.xml.bind_2.1.1.jar
·        javax.xml.ws_2.1.1.jar

6.      On the admin and any remote managed servers, update the following scripts with $JAVA_HOME or the new JDK location (from step 1 above)
·        $MW_HOME/user_projects/domains/domain/bin/setDomainEnv.sh
·        $MW_HOME/utils/bsu/bsu.sh
·        $MW_HOME/utils/quickstart/quickstart.sh
·        $MW_HOME/utils/uninstall/uninstall.sh
·        $MW_HOME/wlserver_10.3/common/bin/commEnv.sh
·        $MW_HOME/wlserver_10.3/server/bin/setWLSEnv.sh
·        $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

7.      On the admin and any remote managed servers, update the following files with the new JDK location (from step 1 above)
·        $MW_HOME/user_projects/domains/domain/init-info/domain-info.xml
·        $MW_HOME/user_projects/domains/domain/init-info/startscript.xml
·        $MW_HOME/user_projects/domains/domain/init-info/tokenValue.properties
·        $MW_HOME/user_projects/domains/domain/servers/<server>/data/nodemanager/startup.properties
·        $MW_HOME/wlserver_10.3/.product.properties
·        $MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.properties

8.      On the admin and any remote managed servers below version 10.3.6.0, upgrade WebLogic to 10.3.6.0
a.      java -Xms1024 -jar wls1036_upgrade_generic.jar

9.      On the admin and any remote managed servers, upgrade WebLogic to 10.3.6.0.160719 (PATCH_ID - UIAL)
a.      unzip p23094342_1036_Generic.zip to {MW_HOME}/utils/bsu/cache_dir or any local directory (Note: You must make sure that the target directory for unzip has required write and executable permissions for "user" with which the component being patched is installed.)
b.      Navigate to the {MW_HOME}/utils/bsu directory
c.      Execute bsu.sh -install -patch_download_dir={MW_HOME}/utils/bsu/cache_dir -patchlist= UIAL -prod_dir={MW_HOME}/{WL_HOME} -log=weblogic_upgrade.log

10.   Compare backed up and current MW_HOME directories

11.   Start admin and managed servers. Review the startup logs to ensure that the new JDK is being used

12.   Uninstall old JDK or rename its root directory

13.   Restart admin and managed servers and ensure that they start correctly and are not trying to use the old JDK

14.   Test the system