Technology Unleashed: January 2015

Wednesday, January 28, 2015

zfs command

Suppose if you have 500GB in a pool which has 5 mounts . 1. /u01a 100 (fixed quota) 2. /u01b 100 (fixed quota) 3. /u01c 75 (not fixed quota) 4. /u01d 75 (not fixed quota) The requirement is to increase the /u01b from 100gb to 200gb Step 1: First see whether this /u01a is fixed quota zfs get quota pool/u01a which will show the whether this mount is having fixed quota or not Step 2 : 2.a To increase more space ,first decrease 50gb from /u01a and 50gb from /u01c..so that you will have 100gb more .. to decrease space ..give the follwing zfs set quota=50gb pool/u01a (this will decrease 50gb from /u01a ) zfs set quota=50gb pool/u01c (this will decrease 50gb from /u01c ) 2.b now enter the below command zfs set quota=100gb pool/u01b ( this will increase 100gb to /u01b) Some more commands zfs list df -h /u01* /backup/ zfs get quota /backup/ zfs get quota pool/u01a zfs get volsize pool/u01a df -h zfs set quota=50gb pool/u01a

Mangaing Oracle Tablespace

select name from v$tablespace; select name from v$datafile; create tablespace mytbs datafile 'd:\oracle\mytbs01.dbf' size 100m; select ts#,name from v$tablespace; select ts#,name from v$datafile; alter tablespace mytbs add datafile 'd:\oracle\mytbs02.dbf' size 100m alter tablespace mytbs drop datafile 'd:\oradata\mytbs02.df'; desc dba_tabplespaces; select tablespace_name,status from dba_tablespaces; alter database datafile 'd:\oradata\mytbs01.dbf' resize 10m; desc v$datafile; select name,bytes/1024/1024 from v$datafile; alter tablespace mytbs read only; alter tablespace mytbs read write; alter tablespace mytbs force logging; alter tablespace mytbs nologging; alter tablespace mytbs rename to yourtbs; select name from v$tablespace; alter tablespace yourtbs rename to mytbs; drop tablespace mytbs including contents and datafiles;

Monday, January 26, 2015

Enabling SSL in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1)

Enabling SSL in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1) To BottomTo Bottom In This Document Section 1: Introduction Section 2: Concepts and Terminology Section 3: Application Tier Setup Section 4: Database Tier Setup Section 5: Advanced SSL Setup Section 6: Encrypting Database Network Traffic Using ANO/ASO (Optional) Appendix A - Using Network Traffic Encryption Appendix B - Disabling SSL Appendix C - Known Issues This document details the steps for enabling SSL in Oracle E-Business Suite Release 12.2. The most current version of this document can be obtained in My Oracle Support Knowledge 1367293.1. Refer to My Oracle Support Knowledge 376700.1 for the setup steps for enabling SSL in Oracle E-Business Suite Release 12.0 and 12.1. There is a change log at the end of this document. Section 1: Introduction Oracle E-Business Suite Release 12.2 uses the Oracle Fusion Middleware infrastructure to secure communication between components using SSL. Oracle Fusion Middleware supports SSL version 3, TLS version 1 and JKS-based keystores for components running under Java and Oracle Wallets for other components, such as the Oracle HTTP Server. Oracle HTTP Server (Web Tier) is the Web Server component for Oracle Fusion Middleware and enables strong cryptography using mod_ossl and mod_wl_ohs modules. Web Tier certificates can still be managed by the Oracle Wallet Manager (OWM), which is accessible via the OWM graphical user interface, ORAPKI command line interface (CLI) or Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control). Note: Use of the Forms Server Listener with ConnectMode=https is not supported. ConnectMode=https only works with JInitiator, which includes the Oracle SSL libraries. Oracle E-Business Suite Release 12 uses the Sun Java Plugin. If you need to use HTTPS for the Forms communication layer you must use the servlet architecture. Oracle Fusion Middleware Oracle WebLogic Server allows additional Java Keystores to be created to protect the communication to and from Oracle WebLogic Servers (Application tier). These Java Keystores can be created with Java Keytool Utility or Fusion Middleware Control. This document provides information specific to securing Oracle E-Business Suite Release 12.2 components. Section 2: Concepts and Terminology Transport Layer Security (TLS) & Secure Sockets Layer (SSL) TLS and its predecessor SSL secures communication by providing message encryption, integrity and authentication. This document uses the term SSL where either SSL or TLS may be appropriate because SSL is the most widely recognized term. Certificate Authority (CA) A Certificate Authority is a trusted third party responsible for issuing, revoking, and renewing digital certificates. All digital certificates are signed with the Certificate Authority's private key to ensure authenticity. The Certificate Authority's Public Key is widely distributed. Secure Socket Layer Offloading and Load Balancers Secure Socket Layer (SSL) Offloading can be used to remove the processing burden of encrypting/decrypting traffic from a Web Server. An SSL offloader that acts as an SSL terminator is responsible for converting HTTPS SSL requests to non-SSL HTTP requests, directing the request to the Web Server which is running in non-SSL mode. Any response back to the desktop is encrypted and returned to the client. Encryption/decryption of data can also be speeded up by using dedicated devices designed to perform SSL acceleration. These types of offloading and acceleration activities tend to be performed at the Load Balancer Layer but can also be standalone devices. If you’re planning on only using an SSL terminator (for example f5 BIG-IP achieves this through a Client SSL Profile) then only Steps 10 to 13 of Section 3: Application Tier Setup and Section 4: Database Tier Setup should be configured, additional sections are optional. Securing communication from an SSL Load Balancer to an SSL enabled Oracle E-Business Suite Release 12.2 instance is also becoming more common (for example f5 BIG-IP LTM achieves this through a Server SSL Profile). For this type of configuration additional steps will need to be taken to ensure the chain of trust is established between both sides. Note: Depending on the Load Balancer, the SSL Server configuration can be setup to presents its certificate to Oracle E-Business Suite Release 12.2 which in turn will verify it if the ‘SSLVerifyClient require’ directive is set for the Web Tier. For this setup you may need to import the Load Balancer certificate(s) into the Oracle Wallet as well as the JDK keystores (at the application tier and the database layer) to establish the chain of trust. In turn, if the Load Balancer is configured to verify the Oracle E-Business Suite Release 12.2 Server Certificate then the Oracle E-Business Suite Release 12.2 certificate(s) will need to be added to the Load Balancer trust point, refer to the Load Balancer documentation on how to do this. If you plan to use "cookie based session persistence" at the HTTP Load Balancer level, and you plan to enable SSL for HTTP traffic at all application tier Web Nodes, you have to use an SSL Offloader as the Web Entry Point Host. This is because HTTP Load Balancers cannot intercept the SSL encrypted communication between the Client Browser and the application tier Web Server to insert or delete cookies to maintain session persistence. It is advantageous to use SSL Offloader because it requires less maintenance as none of the application tier Web Nodes have to be configured for SSL anymore. Keystores and Wallets Oracle Fusion Middleware uses JKS keystore (the default JDK implementation of Java keystores used by Oracle WebLogic Server) to store keys and certificates. Other components (such as Oracle HTTP Server) continue to use the Oracle wallet as their storage mechanism. Wildcard Certificates Wildcard Certificates secure a website URL first level sub-domain that the certificate was issued to. Oracle WebLogic Server uses a Hostname Verifier to ensure the server being connected to via SSL is genuine for the request being made. The standard implementation of a hostname verifier in Oracle WebLogic for SSL requires an explicit Common Name (CN) match. Oracle E-Business Suite Release 12.2 deployment of Oracle WebLogic Server includes an enhancement to allow both Wildcard and Subject Alternative Name (SAN) support. This will allow Oracle WebLogic Server to communicate with external websites that use Wildcard certificates (for example My Oracle Support). Section 3: Application Tier Setup The {s_web_ssl_directory} location is still used by some Oracle E-Business Suite Release 12.2 components (for example XML Gateway Transportation Agent OXTA), and during the Oracle Fusion Middleware cloning process. Refer to the Application Context file for the exact location of the {s_web_ssl_directory} variable. The process outlined in this section creates the wallet in this location, and it is then copied to the new Web Tier location. Note: Oracle E-Business Suite Release 12.2 is preconfigured with default self-signed certificates during the install. Using these or any other demo or self-signed certificates is not covered in this documentation. For simplicity any existing keystores are not used, and if your configuration included additional certificates that your deployment is dependent on for integration, you will have to take additional steps to ensure they are added afterwards (those steps are not covered in this document but would either consist of using the current keystore or re-importing them into a new keystore). The main steps for setting up SSL on the Application Tier are: Set Your Environment Create a Wallet Create a Certificate Request Submit the Certificate Request to a Certificate Authority Import your Server Certificate Modify the Oracle HTTP Server Wallet Modify the OPMN Wallet Fusion Middleware Control Console Update the JDK Cacerts File Update the Context File and Config Files Run AutoConfig Customizations Restart the Application Tier Services Synchronization between Run and Patch File System Note: Oracle Discoverer users who enable SSL for the Oracle E-Business Suite must also enable SSL for Discoverer, and should refer to Oracle Business Intelligence Discoverer. Step 1- Set Your Environment During the Oracle E-Business Suite Release 12.2 Installation, Rapid Install lays down two copies of the Oracle E-Business Suite File System. After the installation one of the File Systems will be labeled as the Run File System and the second one the Patch File System. As part of applying online patches to the system the Patch File System will be promoted to be the new Run File System and the old Run File System becomes the Patch File System for the next online patching cycle. Apply the latest AD and TXK Delta Release Update Packs. Refer to Note 1617461.1 for the latest information on known issues. Note: The steps detailed in this section must be executed on the (running) Run File System in order to ensure that during the next online patching the SSL setup is then propagated to the Patch File System. Log on to the Oracle E-Business Suite Release 12.2 application tier as the OS user who owns the installation files. The file system with the Application Context file variable {s_file_edition_type} set to 'run' denotes the Run File System. Source your application tier environment file (.env), located in the APPL_TOP directory on the Run File System. Do not source the APPS.env file, otherwise the 10.1.2 environment variables will be picked up, and Oracle Wallet Manager 11g will fail to start. After sourcing the environment file $FILE_EDITION environment variable should be 'run'. Set the PATH environment variable to include the Fusion Middleware location. For example: export PATH=$FMW_HOME/webtier/bin:$FMW_HOME/oracle_common/bin:$PATH Set the DISPLAY environment variable. For example: export DISPLAY= :0.0 Note: When working with wallets and certificates, you must use the Oracle Fusion Middleware 11g executables. These instructions involve the use of the Oracle Wallet Manager Graphical User Interface. Oracle Wallet Manager Command Line Interface ORAPKI or Fusion Middleware Control can also be used to manage various aspects of keystores. These tools are detailed in the Fusion Middleware Documentation Library and not covered in this document. Step 2 - Create a wallet Navigate to the {s_web_ssl_directory}/Apache directory, if it does not exist, create it. Move any existing wallet files to a backup directory in case you wish to use them again in the future. Open the Wallet manager as a background process: owm & For Windows: The Oracle Wallet Manager can be launched from the run file system as follows: Start -> Run -> Input \webtier\bin\launch.exe "\webtier\bin" owm.cl and click OK. On the Oracle Wallet Manager Menu navigate to Wallet -> New. Answer No to: “Your default wallet directory doesn't exist. Do you wish to create it now?” The new wallet screen will now prompt you to enter a password for your wallet. Be sure to make the password something you will remember. You will need to use the password whenever you open the wallet with Oracle Wallet Manager, or perform operations on the wallet using the Command Line Interface. With auto login enabled processes submitted by the OS user who created the wallet, there is no need to supply the password to access the wallet. Click YES when prompted: “A new empty wallet has been created. Do you wish to create a certificate request at this time?” Step 3 - Create a Certificate Request After clicking "Yes" in step 2, the Create Certificate Request Screen will appear, enter the appropriate values, for example: Common Name: Name of your server, including the domain Organizational Unit: (optional) Unit within your organization Organization: Name of your organization Locality/City: Locality or city State/Province: is the full name of your State or Province - do not abbreviate Select your Country from the drop down list, and for the Key Size, select 2048 as a minimum. Click OK. Note: SHA1 Hash Algorithm Migration for SSL Certificates issued with a SHA1 based signature hash algorithm as an industry standard are being phased out. Many sites are transitioning to SHA2 or higher ahead of industry plans for deprecation of SHA1. The time frame for moving to SHA2 may vary depending on the certificate authority used. This change also impacts intermediate certificates which must also be SHA2 in order to chain back to the end-entity SHA2 certificate issued. Root certificates are not impacted. Depending on your certificate provider, they may not accept MD5 based certificate requests (CSR) generated by Oracle Wallet Manager (OWM). For example, VeriSign will now only accept SHA1 2048 bit based CSRs or higher. Due to a current limitation in both OWM and orapki, they are incapable of generating anything other than MD5 based CSRs. OWM can accept SHA2 or above trusted certificates and server certificates, it just cannot generate them. In these cases, the workaround is to make use of openssl to generate the CSR. An example of this process is provided here: 1) Generate your CSR using the OWM as this will also create the key pair, and save the wallet. 2) Use openssl to take the existing wallet and save it as a new PEM format file: openssl pkcs12 -in ewallet.p12 -nodes -out nonoracle_wallet.pem 3) Use openssl to generate the request specifying SHA2: openssl req -new -key nonoracle_wallet.pem -sha256 -out certrequest.csr At this point openssl will prompt you for the request attributes. Be sure to enter the same data you entered when creating the CSR in OWM. Do not specify a 'challenge password' as this has been deemed to be insecure by most certifying authorities. 4) Send this CSR to your Certifying Authority. 5) Upon receiving your newly issued certificate, you can import this into your wallet using OWM continuing with Step 5 below. Reference the following notes for more information: Note 1448161.1 How To Produce CSR With A SHA-1 Or Better Signature Algorithm Note 1275428.1 Support Status for SHA2 in Oracle Application Server (10.1.2.X.X/10.1.3.X.X) and Fusion Middleware 11g (11.1.1.X) Note 1939223.1 Is it Possible to Generate SHA2 Certificate Signing Requests with Oracle Wallet Manager or ORAPKI in FMW11g Step 4 - Submit the Certificate Request to a Certificate Authority Export the Certificate Request: Click on Certificate [Requested] to Highlight it From the menu click Operations -> Export Certificate Request Save the file as server.csr (example filename) From the menu click Wallet and then click Save On the Select Directory screen change the Directory to your fully qualified wallet directory and click OK From the menu click Wallet and check the Auto Login box Exit Wallet Manager The wallet directory will contain the following files: cwallet.sso ewallet.p12 server.csr The server.csr should now be submitted to your Certificate Authority to request a Server Certificate. Step 5 - Import your Server Certificate to the wallet After you receive your Server Certificate from your Certificate Authority, you will need to import it into your wallet. Copy the certificate to a file server.crt (example filename) in the wallet directory on your server by one of the following methods: Use ftp (in binary mode) to copy the certificate Copy and paste the certificate contents into server.crt (example filename) Steps to import server.crt into your wallet: Open the Wallet Manager as a background process: owm & For Windows: The Oracle Wallet Manager can be launched from the run file system as follows: Start -> Run -> Input \webtier\bin\launch.exe "\webtier\bin" owm.cl and click OK. From the menu click Wallet then Open Answer Yes when prompted: Your default wallet directory does not exist. Do you want to continue? On the Select Directory screen change the Directory to your fully qualified wallet directory {s_web_ssl_directory}/Apache and click OK. Enter your wallet password and click OK On the Oracle Wallet Manager Menu navigate to Operations - Import User Certificate. Server Certificates are a type of user certificate. Since the Certificate Authority issued a certificate for the server, placing its distinguished name (DN) in the Subject field, the server is the certificate owner, and thus the "user" for this user certificate. Click OK Double Click on server.crt to import it. Save the wallet: On the Oracle Wallet Manager Menu click Wallet Verify the Auto Login box is checked Click Save Note: If all trusted certificates that make up the chain of Server Certificate are not present in the wallet, adding the certificate will fail. When the wallet was created only the certificates for the most common CA’s were included automatically. Contact your Certificate Authority if you need to add their certificate, and save the provided file (for example as ca.crt) in the wallet directory. If your Certificate Authority provided an intermediate certificate (to complete the chain) then save the provided file (for example as intca.crt), this will need to be imported into Oracle Wallet Manager prior to importing the Server Certificate (server.crt if you used the example name). If you need to import the CA Certificate you'll also need to add the contents of Server Certificate (ca.crt) file to b64InternetCertificate.txt file located in the 10.1.2 ORACLE_HOME/sysman/config directory: $ cat ca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt If you were also provided an Intermediate Certificate (intca.crt) then you will also need to add that to the b64InternetCertificate.txt: $ cat intca.crt >> <10.1.2 ORACLE_HOME>/sysman/config/b64InternetCertificate.txt Step 6 - Modify the Oracle HTTP Server wallet The default location for the Oracle HTTP Server configuration is in a location specific to the Oracle Fusion Middleware Web Tier. The {s_web_ssl_directory}/Apache is still used by some Oracle E-Business Suite Release 12.2 components, but is not used by the Oracle HTTP Server. Use the following instructions to copy the {s_web_ssl_directory}/Apache wallet to {s_ohs_instance_loc}/config/OHS/{s_ohs_component}/keystores/default directory location: Navigate to the {s_ohs_instance_loc}/config/OHS/{s_ohs_component}/keystores/default directory location. Refer to the Application Context file for the exact location of the ohs_instance_loc variable (details the ohs instance location) and the ohs_component variables (name of a specific ohs component for example OHS). Move the existing wallet files to a backup directory in case you wish to use them again in the future. Copy the cwallet.sso from {s_web_ssl_directory}/Apache into the current directory. Step 7 - Modify the OPMN wallet The default location for the OPMN wallet is in the {s_ohs_instance_loc}/config/OPMN/opmn/wallet directory. Refer to the Application Context file for the exact location of the {ohs_instance_loc} variable (gives details of the OHS instance location). Now that the Web Tier wallet has been created, you will need to use these same certificates for OPMN. Use the following steps to backup and copy the wallets: Navigate to the {s_ohs_instance_loc}/config/OPMN/opmn/wallet directory. Move the existing wallet files to a backup directory in case you wish to use them again in the future. Copy the cwallet.sso files from the {s_ohs_instance_loc}/config/OHS/{s_ohs_component}/keystores/default directory to the current directory. Step 8 - Fusion Middleware Control Console Fusion Middleware Control Console utilizes the functionality of OPMN to manage your Oracle Fusion Middleware Enterprise. Using a Web browser, Fusion Middleware Control Console provides a graphical interface that enables management of all system components in your network and enterprise. Changes made in the previous steps to the OPMN wallet also need to be made to the wallet used by Fusion Middleware Control MBeans, which rely on successful SSL communication to manage the OPMN based components. Use the following steps to backup and copy the wallets. If the Fusion Middleware Control wallets contain additional certificates that are not stored in the Web Tier OPMN wallet, you may want to export them and then re-import them after the following steps have been completed: Move the existing wallet files to a backup directory in case you wish to use them again in the future. Refer to the Application Context file for the variables for your instance: $EBS_DOMAIN_HOME/opmn/{s_ohs_instance}/{s_ohs_component}/wallet $EBS_DOMAIN_HOME/opmn/{s_ohs_instance}/wallet $FMW_HOME/webtier/instances/{s_ohs_instance}/config/OHS/{s_ohs_component}/proxy-wallet Copy the cwallet.sso file from {s_ohs_instance_loc}/config/OPMN/opmn/wallet directory to all three locations previously mentioned. Step 9 - Update the JDK Cacerts File Oracle Fusion Middleware components (including Oracle WebLogic Server, Oracle Web Services) requires the Certificate of the Certificate Authority who issued your Server Certificate (ca.crt from the previous step) to be present in the JDK cacerts file. In addition, some features of Oracle BI Publisher require the Server Certificate (server.crt from previous step) to be present. Follow the steps below for all Application Tier Nodes: Navigate to the {s_fmw_jdktop}/jre/lib/security directory. Refer to the Application Context file for the exact location of the {s_fmw_jdktop} variable. Backup the existing cacerts file. Copy your ca.crt and server.crt files to this directory, and issue the following command to insure that cacerts has write permissions: $ chmod u+w cacerts Add your Oracle HTTP Server ca.crt and server.crt to cacerts: $ keytool -import -alias OHSRootCA -file ca.crt -trustcacerts -v -keystore cacerts $ keytool -import -alias OHSServer -file server.crt -trustcacerts -v -keystore cacerts If you were also provided an Intermediate Certificate (intca.crt) then you will also need to add that to the cacerts before adding the server.crt: $ keytool -import -alias OHSRootCA -file ca.crt -trustcacerts -v -keystore cacerts $ keytool -import -alias OHSIntCA -file intca.crt -trustcacerts -v -keystore cacerts $ keytool -import -alias OHSServer -file server.crt -trustcacerts -v -keystore cacerts When prompted enter the keystore password (the default password is "changeit"). Note: For Oracle E-Business Suite Release 12.2 installations that use 64-bit JDK for Oracle Fusion Middleware the steps in this section need to be repeated for the 32-bit JDK keystore location that is still used by some products. If the Application Context file {s_fmw_java_use_64} variable is set to 'true' then repeat the steps for the 32-bit cacerts in $OA_JRE_TOP/lib/security. Some UNIX platforms such as Oracle Solaris have a single JDK location {s_fmw_jdktop}/jre/lib/security so this additional step is not required. Step 10 - Update the Context File and Config Files In Oracle E-Business Suite Release 12.2 some configuration files are no longer maintained by AutoConfig (including httpd.conf and ssl.conf). Oracle Enterprise Manager 11g Fusion Middleware Control should be used to maintain these configuration files as well as making additional changes to Context File variables. When choosing the SSL port, special consideration should be given if a privileged port is being considered (for example 443 on UNIX). A number of additional steps will be required throughout Online Patching, refer to the Section on Privileged Port. Privileged Port (Optional) On a UNIX system the TCP/IP port numbers below 1024 are special in that only processes with root privileges are allowed to listen on those ports. Refer to Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server for additional information on Starting Oracle HTTP Server on a Privileged Port. In Oracle E-Business Suite Release 12.2 additional consideration needs to be given when using a Privileged Port. The following needs to be executed on both the Run and Patch File Systems as the root user. After executing the commands restart HTTP services (by running $ADMIN_SCRIPTS_HOME/adapcctl.sh) on the Run File System. chown root $FMW_HOME/webtier/ohs/bin/.apachectl chmod 6750 $FMW_HOME/webtier/ohs/bin/.apachectl The following additional steps need to be taken during Online Patching when using a privileged port: Before running the prepare phase or the fs_clone phase, you must perform these steps: Ensure that the following commands have been executed as the root user on both the run file system and the patch file system: chown root $FMW_HOME/webtier/ohs/bin/.apachectl chmod 6750 $FMW_HOME/webtier/ohs/bin/.apachectl After running the prepare phase or the fs_clone phase, you must perform these steps: Execute the following commands as the root user on the patch file system: chown root $FMW_HOME/webtier/ohs/bin/.apachectl chmod 6750 $FMW_HOME/webtier/ohs/bin/.apachectl On completion of Online Patching Cutover Phase (adop phase=cutover), Oracle Fusion Middleware Control Console may error when accessing configuration files on the new Run File System. In the event you experience Failed to invoke operation load on MBeanthe opmnctl updatecomponentregistration command should be run. Example command usage: -proxyPort should be set to the Listen directive shown in $FMW_HOME/webtier/instances/{s_ohs_instance}/config/OHS/{s_ohs_component}/admin.conf -oracleInstance should be set to the $FMW_HOME/webtier/instances/{s_ohs_instance} context variable value -componentName should be set to the {s_ohs_component} context variable value $FMW_HOME/webtier/opmn/bin/opmnctl updatecomponentregistration -componentType OHS -proxyPort 10001 -oracleInstance /u01/Z122VIS/fs1/FMW_Home/webtier/instances/EBS_web_Z122VIS_OHS1 -componentName EBS_web_Z122VIS Command requires login to weblogic admin server (<>): Username: weblogic Password: Updating component registration on admin server. Command succeeded. Note: Refer to Oracle E-Business Suite Technology Stack Release Notes for Release 12.2 Document 1376618.1 for additional information. Standard SSL Setup Use Oracle Fusion Middleware Control to make some additional configuration file changes: Login to Oracle Fusion Middleware Control Console (for example http://.:/em) Select Web Tier Target under EBS Domain Select Administration > Advanced Configuration Select ssl.conf file for edit Update the Listen and the VirtualHost _default_: directives to SSL port, for example Listen 4443 Click Apply The following command should be run (on all application tier nodes) to propogate the changes made via Oracle Fusion Middleware Control Console to the context file variables: perl $AD_TOP/bin/adSyncContext.pl contextfile=$CONTEXT_FILE Enter the APPS user password: Enter the WebLogic AdminServer password: For Windows: perl %AD_TOP%\bin\adSyncContext.pl contextfile=%CONTEXT_FILE% Review the adSyncContext.log for the changes that have been picked up and made to the Context File. Note: When setting up SSL for the first time the default protocol will be set to 'http' and only the port related context variables will be updated by running adSyncContext.pl, additional url based context variables {s_login_page} {s_external_url} will need to be updated using Oracle Applications Manager (OAM). On an instance where the protocol is already set to 'https' then these context variables will be updated as long as the matches the existing value defined for s_active_webport, otherwise it is assumed that the login related urls have been customized and should not be automatically changed. Use the Oracle E-Business Suite 12.2 - OAM Context Editor to change the SSL related variables shown in this table: SSL Related Variables in the Context File Variable Non-SSL Value SSL Value s_url_protocol http https s_local_url_protocol http https s_webentryurlprotocol http https s_active_webport same as s_webport Verify the port, correct if required. s_webssl_port not applicable Verify the port, correct if required. s_https_listen_parameter not applicable Verify the port, correct if required. s_login_page url constructed with http protocol and s_webport Verify the protocol and port, correct if required. s_external_url url constructed with http protocol and s_webport Verify the protocol and port, correct if required. SSL Offloader Setup Use Oracle Fusion Middleware Control to make some additional configuration file changes: Login to Oracle Fusion Middleware Control Console (for example http://.:/em) Select Web Tier Target under EBS Domain Select Administration > Advanced Configuration Select ssl.conf file for edit Update the ServerName directive to the SSL Offloader . Click Apply Select httpd.conf file for edit Update the ServerName directives to the SSL Offloader . Click Apply Use the Oracle E-Business Suite 12.2 - Oracle Applications Manager (OAM) Context Editor to change the SSL related variables shown in this table: Changes when using an SSL Offloader Variable Non-SSL Value SSL Value s_url_protocol http http s_local_url_protocol http http s_webentryurlprotocol http https s_active_webport same as s_webport SSL Offloader external port s_webentryhost same as s_webhost SSL Offloader hostname s_webentrydomain same as s_domainname SSL Offloader domain name s_enable_sslterminator # Remove the '#' to use ssl_terminator.conf s_login_page url constructed with http protocol and s_webport Construct url with https protocol, s_webentryhost, s_webentrydomain, s_active_webport s_external_url url constructed with http protocol and s_webport Construct url with https protocol, s_webentryhost, s_webentrydomain, s_active_webport Step 11 - Run AutoConfig Run AutoConfig using the adautocfg.sh script in the application tier $ADMIN_SCRIPTS_HOME directory. Step 12 - Customizations (optional) In Oracle E-Business Suite Release 12.2, a Non-SSL port is kept open for those products that need to access some of their pages via the HTTP, and for the Oracle E-Business Suite Help System. If you wish to disable the HTTP port and force all users to access your pages via HTTPS, you can add a redirect rule to the {s_ohs_instance_loc}/config/OHS/{s_ohs_component}/custom.conf file: RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://:/$1 [R,L] Any updates you make to the custom.conf file will be preserved when AutoConfig is run. Step 13 - Restart the Application Tier Services Use the adstpall.sh/adstrtal.sh script in the $ADMIN_SCRIPTS_HOME directory to stop and restart all services. Note: The basic configuration can now be tested on the current Run File System. Please refer to Section 4 if you wish to test Oracle products that rely on Database Tier Setup being completed. Step 14 - Synchronization between Run and Patch File Systems The following steps need to be performed in order to synchronize the SSL setup between the two file systems: Edit $APPL_TOP_NE/ad/custom/adop_sync.drv Assuming the rsync command is available on UNIX the following directives must be copied and pasted between the and section after the existing <#Copy Ends> Example commands: #SSL SECTION - START # Required for SSL setup migration from RUN to PATCH file-system. # Please alter the commands in the event that rsync is not available or the platform does not support the example syntax. #10.1.2 b64InternetCertificate.txt rsync -zr %s_current_base%/EBSapps/10.1.2/sysman/config/b64InternetCertificate.txt %s_other_base%/EBSapps/10.1.2/sysman/config/b64InternetCertificate.txt #Oracle HTTP Server Wallet - cwallet.sso rsync -zr %s_current_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/keystores/default/cwallet.sso %s_other_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/keystores/default/cwallet.sso #OPMN Wallet - cwallet.sso rsync -zr %s_current_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OPMN/opmn/wallet/cwallet.sso %s_other_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OPMN/opmn/wallet/cwallet.sso #Fusion Middleware Control Wallets - cwallet.sso rsync -zr %s_current_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso %s_other_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/%s_ohs_component%/wallet/cwallet.sso rsync -zr %s_current_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/wallet/cwallet.sso %s_other_base%/FMW_Home/user_projects/domains/EBS_domain_%s_dbSid%/opmn/%s_ohs_instance%/wallet/cwallet.sso rsync -zr %s_current_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/proxy-wallet/cwallet.sso %s_other_base%/FMW_Home/webtier/instances/%s_ohs_instance%/config/OHS/%s_ohs_component%/proxy-wallet/cwallet.sso For Windows: #SSL SECTION - START # Required for SSL setup migration from RUN to PATCH file-system. # Please alter the commands in the event that rsync is not available or the platform does not support the example syntax. #10.1.2 b64InternetCertificate.txt xcopy /ieqy %s_current_base%\EBSapps\10.1.2\sysman\config\b64InternetCertificate.txt %s_other_base%\EBSapps\10.1.2\sysman\config\b64InternetCertificate.txt #Oracle HTTP Server Wallet - cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs_component%\keystores\default\cwallet.sso %s_other_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs_component%\keystores\default\cwallet.sso #OPMN Wallet - cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OPMN\opmn\wallet\cwallet.sso %s_other_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OPMN\opmn\wallet\cwallet.sso #Fusion Middleware Control Wallets - cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\%s_ohs_component%\wallet\cwallet.sso %s_other_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\%s_ohs_component%\wallet\cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\wallet\cwallet.sso %s_other_base%\FMW_Home\user_projects\domains\EBS_domain_%s_dbSid%\opmn\%s_ohs_instance%\wallet\cwallet.sso xcopy /ieqy %s_current_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs _component%\proxy-wallet\cwallet.sso %s_other_base%\FMW_Home\webtier\instances\%s_ohs_instance%\config\OHS\%s_ohs_component%\proxy-wallet\cwallet.sso Refer to the Application Context file variable {s_fmw_jdktop} to determine the JDK version currently being used, then add either the JDK 6/JRockit or JDK 7 copy directive. JDK 6/JRockit Example command: #JDK keystore rsync -zr --include=jdk* --include=jdk*/jre --include=jdk*/jre/lib --include=jdk*/jre/lib/security --include=jrockit* --include=jrockit*/jre --include=jrockit*/jre/lib --include=jrockit*/jre/lib/security --include=cacerts --exclude=* %s_current_base%/FMW_Home/ %s_other_base%/FMW_Home/ #SSL SECTION - END The JDK on AIX and HP is in $COMMON_TOP/util, the following modified JDK keystore command should be used instead of the example previously shown: #JDK keystore rsync -zr --include=jdk* --include=jdk*/jre --include=jdk*/jre/lib --include=jdk*/jre/lib/security --include=cacerts --exclude=* %s_current_base%/EBSapps/comn/util/ %s_other_base%/EBSapps/comn/util/ #SSL SECTION - END JDK 7 Example command for UNIX: #JDK keystore rsync -zr --include=jdk* --include=jdk*/jre --include=jdk*/jre/lib --include=jdk*/jre/lib/security --include=cacerts --exclude=* %s_current_base%/EBSapps/comn/util/ %s_other_base%/EBSapps/comn/util/ #SSL SECTION - END For JDK 7 on Windows: #JDK keystore for /f %%A in ('dir /b %s_current_base%\EBSapps\comn\util\jdk*') do (xcopy /ieqy %s_current_base%\EBSapps\comn\util\%%A\jre\lib\security\cacerts %s_other_base%\EBSapps\comn\util\%%A\jre\lib\security\cacerts) #SSL SECTION - END Refer to My Oracle Support Knowledge Document 1530033.1 for additional information on JDK 7. Note: The changes are propagated to the Patch File System during the prepare phase (adop phase=prepare) of online patching and take affect after a successful cutover (adop phase=cutover). The SSL setup can then be verified as the Patch File System has now been promoted to be the new Run File System. Section 4: Database Tier Setup Oracle products such as Oracle Configurator, Order Management, iStore, Order Capture, Quoting, iPayment, iStore, and Pricing access data over the Internet in HTTP or HTTPS connection mode. The implementation of SSL for the Oracle Database (which acts as a client sending requests to the Web Server) makes use of Oracle Wallet Manager for setting up an Oracle wallet. Note: This is a mandatory requirement for Oracle iStore storefront pages when the Web Tier is also SSL enabled. When a Load Balancer is being used its certificate(s) will need to be imported into the Database Wallet if a trust point does not already exist, the same goes for when communicating with any external HTTPS Web Server. To enable SSL on the Database Tier you need to only create a wallet, you do not need a separate Server Certificate for this wallet. If you were required to import a Server Certificate (for example ca.crt) and (Intermediate Certificate, for example intca.crt if it exists) into the Application Tier wallet you will need to do it for this wallet also. If communication is required to an external application that is also SSL enabled then you may need to import that applications certificate (to establish the chain of trust). After setting your environment for the database tier, navigate to the $ORACLE_HOME/appsutil directory. Create a new wallet directory named: wallet Navigate to the newly created wallet directory. Open the Wallet Manager as a background process: owm & For Windows: The Oracle Wallet Manager can be launched as follows: Start Menu -> All Programs -> Oracle_%SID%_db112_RDBMS -> Integrated Management Tools -> Wallet Manager On the Oracle Wallet Manager Menu navigate to Wallet -> New. Answer NO to: “Your default wallet directory doesn't exist. Do you wish to create it now?” The new wallet screen will now prompt you to enter a password for your wallet. Click NO when prompted: “A new empty wallet has been created. Do you wish to create a certificate request at this time?” If you need to import ca.crt: On the Oracle Wallet Manager menu navigate to Operations -> Import Trusted Certificate. Click OK. Double click on ca.crt to import it. Save the wallet: On the Oracle Wallet Manager Menu click Wallet. Verify the Auto Login box is checked. Click Save. To test that the wallet is properly set up and accessible, login to SQL>select utl_http.request('

', '', 'file:', null) from dual; where: '

Enabling SSL in Oracle E-Business Suite Release 12 [ID 376700.1]).

https://blogs.oracle.com/stevenChan/entry/ssl_advanced_configuration_wizard_ebs12 Configuring SSL with a Configuration Wizard in EBS R12 By Prasad Akkiraju on Aug 21, 2009 E-Business Suite R12.1.1 provides Advanced Configuration wizards that make it easier to deploy features such as SSL and load-balancing. Apps administrators can use these wizards to make configuration changes online through Oracle Applications Manager (OAM) and then run AutoConfig on the applications tier to make the changes effective. SSL (Secure Sockets Layer) is one of the most commonly used configurations in EBS. I'll walk through the SSL Advanced Configuration Wizard in this article. Accessing the Advanced Configuration Wizards Launch the Oracle Applications Manager Site Map using the System Administrator responsibility, then select the AutoConfig link from the Administration tab. Wizards_Welcome.png Click on Launch Wizards. It brings up the launch pad for five wizards: Forms Socket Mode SSL SSL Accelerator HTTP Load Balancing OC4J Load Balancing Wizards_Home.png Start the SSL Configuration Wizard The OAM General Collection Service must be activated before running any configuration wizards. From the Administration tab of the Site Map, click on the 'Generic Services' link under the Application Services. Select 'OAM Generic Collect Services' and start it for the target instance. OAM submits a concurrent request for the same. Click on Verify to see if the service starts up fine. Once the service starts, you are ready to use the wizard. From the Configuration Wizards launch pad, click on the 'Enable' button for SSL. Select Nodes to be SSL-Enabled Select the nodes on which you would like to enable SSL and click 'Next.' SSL1.PNG 2. Set Context variables for SSL Notice the tip at the bottom of the Parameters screen: you should make sure that your digital certificates are properly imported into the Wallet of your EBS instance. For details about importing SSL certificates, see: Enabling SSL in Oracle Applications Release 12 (Note 376700.1) SSLParam.png The wizard sets the following context variables to 'https': URL protocol Local URL protocol It also sets values for the 'Web SSL directory' and the 'Active HTTP SSL port.' The subsequent screen gives the current and new values for these variables. 3. Validation The wizard validates all settings when you click 'Next' after the user comparison of context values screen. It checks that the Wallet and the required directory structures exist. SSLValidation.png Make sure that the Status is 'Success.' Check the log file in the 'View' link for any errors. 4. Confirmation Page Clicking 'Next' will take you to the Confirmation Page in the train cart. Click on the link below to check the confirmation page. View image 5. Submit the changes and run AutoConfig Clicking the 'Submit' button on the Confirmation page displays the next action to be taken. You can review the context file on the applications tier for the changes that have been made. The next step is to run AutoConfig to propagate the changes. You need to restart all application services to make the changes effective. Once the service have been restarted, the EBS instance is ready to be used in SSL mode. References Enabling SSL in Oracle Applications Release 12 (Note 376700.1) Using Load-Balancers with Oracle E-Business Suite Release 12 (Note 380489.1) Using AutoConfig to Manage System Configurations in Oracle E-Business Suite Release 12 (Note 387859.1) Related Articles 15 New Technology Stack Enhancements in EBS 12.1.1 Power Tools: Running AutoConfig in Parallel in EBS 12 Optimizing R12 Performance via OC4J Load-Balancing In-Depth: Load-Balancing E-Business Suite Environments Category: Oracle Tags: 12 akkiraju apps autoconfig ebs prasad primer security tier

Sunday, January 25, 2015

Adding Persistent route in Solaris 11

route -p add 192.168.160.0 172.30.14.1 In the above example 192.168.160.0 is the destination gateway IP and 172.30.14.1 source gateway IP -p is used to avoid restart of the server. It will change the value with out restarting the server . Here we are trying to add persistent route to access an IP in the gateway 192.168.160.0 and our source or server IP (172.30.14.91)is in the gateway 172.30.14.1 route -p delete 10.14.1.204 172.30.15.1 -netmask 255.255.255.0 Other usefull command are given below # netstat -nr Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ---------- --------- default 172.30.14.1 UG 3 12623 10.10.71.68 172.30.14.1 UGH 2 8 127.0.0.1 127.0.0.1 UH 2 27918 lo0 169.254.182.0 169.254.182.77 U 2 5087 net2 172.30.14.0 172.30.14.91 U 6 20 net1 172.30.15.0 172.30.14.1 UGH 1 0 172.30.16.0 172.30.16.121 U 10 3492312 net0 192.168.160.0 172.30.14.1 UG 2 2911 Routing Table: IPv6 Destination/Mask Gateway Flags Ref Use If --------------------------- --------------------------- ----- --- ------- ----- ========================================================================== # route -p show persistent: route add default 172.30.14.1 persistent: route add 10.10.71.68 172.30.14.1 persistent: route add 172.30.15.0 172.30.14.1 persistent: route add 192.168.160.0 172.30.14.1 ========================================================== # traceroute 10.14.1.204 traceroute: Warning: Multiple interfaces found; using 172.30.14.91 @ net1 traceroute to 10.14.1.204 (10.14.1.204), 30 hops max, 40 byte packets 1 172.30.14.1 (172.30.14.1) 0.519 ms !X * 0.598 ms !X ====================================================================

Tuesday, January 20, 2015

New Security Vulnerability Named POODLE (Padding Oracle on Downgraded Legacy Encryption)

What is the Poodle vulnerability ? The "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. Please note that we are talking about the old SSL 3.0, not TLS 1.0 or later. The TLS versions are not affected http://www.wired.com/2014/10/poodle-explained/ On a day when system administrators were already taxed addressing several security updates released by Microsoft, Oracle, and Adobe, there is now word of a new security hole discovered in a basic protocol used for encrypting web traffic. Its name is POODLE, which stands for Padding Oracle on Downgraded Legacy Encryption, and it was discovered by three Google security researchers—Bodo Moller, Thai Duong, and Krzysztof Kotowicz. They published a paper (.pdf) about it today. POODLE affects SSLv3 or version 3 of the Secure Sockets Layer protocol, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. It’s not as serious as the recent Heartbleed and Shellshock vulnerabilities, but POODLE could allow an attacker to hijack and decrypt the session cookie that identifies you to a service like Twitter or Google, and then take over your accounts without needing your password. To exploit the vulnerability, you must be running javascript, and the attacker has to be on the same network as you—for example, on the same Starbucks Wi-Fi network you’re using. This makes it less severe than an attack that can be conducted remotely against any computer on the Internet. The attack works only on traffic sessions using SSLv3. Although this is an old protocol that has been replaced in many client and server configurations with TLS (Transport Layer Security), many browser clients and web servers that use TLS for connections still support SSLv3. Some products and browsers, like Internet Explorer 6 for Windows XP, only use SSLv3. There are also clients that support SSLv3 as an alternative to use whenever a TLS connection to a web server fails. An attacker could exploit this compatibility to downgrade a connection to SSLv3 and then conduct the POODLE attack to hijack your session. Google’s security team has recommended that systems administrators simply turn off support for SSLv3 to avoid the problem. But this will mean that some users trying to connect securely to a web server using SSLv3 will have trouble connecting if they’re using a client that only supports this protocol. “This attack is really against clients—you have to worry about it if you’re in a place like Starbucks,” says Rob Graham, CEO of Erratasec. “If you’re at home there’s probably no one man-in-the-middling you except the NSA. So as a home user, you don’t need to panic. As a server [administrator], you probably don’t need to panic if your customers are coming in over home connections. Only if they’re coming in over [something like] a Starbucks Wi-Fi.” Heartbleed and Shellshock were vulnerabilities that allowed an attacker to hack a server. POODLE instead targets the clients. “The fear of rushing to go fix this is very low because of that,” Graham says. “People with servers can’t get hacked, and people with [vulnerable] clients also can’t get hacked unless they’re on an open Wi-Fi.”

Sunday, January 18, 2015

Major Changes in R12 ?

http://appsdba.info/docs/oracle_apps/R12/Changes_in_R12.pdf mod_plsql : Mod_plsql is an Apache web server extension that can be used to develop web application pages using Server PL/SQL. Unlike Oracle E-Business Suite Release 11i, Release 12 does not include mod_plsql as part of its technology stack. Modplsql component of Apache is removed in R12 .We will have to see the alternate for custom developed programs which will be using this. If we have developed mod_plsql extensions to Oracle E-Business Suite Release 11i, and are considering upgrading to Release 12, we will have to take some action to preserve that functionality. mod_plsql is replaced by Oracle Application Framework in R12. The reasong for replacing the mod_plsql with Oracle Application Framework in R12 is that , mod_plsql does not provide solutions for a number of important problems that must be solved in a robust and secure web application. The following components/modules are removed from Release 12 1. mod_plsql 2. Oracle Reports Server 3. Oracle Graphics Integration with Oracle Forms 4. Oracle Applications Framework pages in the AK Repository (AK mode) JServ : OC4J replaces the Jserv component which is there in the current release 11i of Oracle Applications. Also as a result the mod_jserv component would be replaced by the mod_oc4j component in release 12 of Oracle Applications. The mod_oc4j is used to communicate between different OC4J instances. The default installation Release 12 of Oracle Applications creates 3 OC4J instances – Oacore: This runs the OA Framework -based applications. – Forms: This runs the Forms-based applications. – OAFM: This is responsible for running the web services. The Jserv groups which are there current in Oracle Applications Release 11i are also planned be replaced by OC4J instances. As mentioned earlier the OC4J properties are controlled using the XML files and OC4J.properties file. These files are managed by the standard Oracle Applications Autoconfig. The Java code deployment in Oracle E-Business suite for OC4J is done at the time of install using rapid install and maintained by ad tools like adadmin and adpatch. New custom code deployment can be done by using the Application Server Control user interface. The OC4J implementation In Oracle Applications Release 12 includes the following directory structure. – applications: Contains applications deployed – applications-deployment: Contains configuration settings for the applications deployed – config: Contains common configuration setting for the OC4J instance. Please Note : there are no jserv.properties or jserv.conf or zone.properties in R12 (new techstack), Jserv is replaced by Oacore. So following are the major changes made in R12 - Jserv component is removed and it is replaced in R12 by OC4J(oacore) Source –http://appsdba.info 3 - mod_plsql is replaced by Oracle Application Framework - The reports server has been removed in R12 and it runs as a spawned process called rwrun which is spawned by conc manager. We can check the metalink note 726711.1 to know more about this.

Wednesday, January 14, 2015

Windows Native Authentication

How Windows Native Authentication Works The following steps, illustrated in Figure 8-1, describe what happens when a user tries to access a single-sign-on-protected application: 1. The user logs in to a Kerberos realm, or domain, on a Windows 2000 computer. 2. The user attempts to access a single-sign-on partner application using Internet Explorer. 3. The application redirects the user to the single sign-on server for authentication. As part of this redirection, the following occurs: a. The browser obtains a Kerberos session ticket from the Key Distribution Center (KDC). b. The single sign-on server verifies the Kerberos session ticket and returns the user to the requested URL. 4. The application provides content to the user. Configuring Windows Native Authentication for Oracle Application Server 10g (9.0.4) on Unix/Linux (Doc ID 264666.1) Configuring eBusiness Suite with Windows Native Authentication (WNA) (Doc ID 744118.1)

Oracle 11g AWR Report

http://www.oracle-class.com/?p=2409 1- AWR Concept: In this post, I am going to show you how to generate AWR reports for Real Application Clusters (RAC) environment. AWR was first introduced in 10g version of Oracle as a repository of all important statistics for an Oracle database. At a regular intervals, Oracle makes a snapshots of those vital statistics and stores them in SYSAUX tablespace. In 11g version, These snapshots are retained for 8 days. It is the MMON background process who is responsible of AWR collection. AWR scripts allow you to generate the reports in HTML or TEXT formats. These reports allow you to analyze the workload of the database at a given intervals. Oracle extends the AWR tool for RAC databases by adding the possibility to generate snapshots reports against the whole cluster database, some database instances of the cluster database, a specific database instance of the cluster database, statistics for a specific select query. In the following sections, I am going to show you how to generate AWR reports for each case. 2- Generate AWR reports for the current Instance: Run the awrrpt script from $ORACLE_HOME/rdbms/admin/ as a sys user. The script will ask you for the output format of the report (HTML or TEXT), the the number of days (n) will result in the most recent (n) days of snapshots being listed (If you hit enter, you will get all the available snapshots listed), begin and end snapshot interval Ids …

How to find applied patches for R12 EBS Oracle Applications

How to find applied patches for R12 EBS Oracle Applications One key task for Oracle Application EBS Database Administrators is to perform patching on regular basis for maintenance pack upgrades and bug fixes. However, with busy work schedules, keeping track of applied patches can be a challenge. Oracle R12 Applications uses the following tables under the APPS schema to track the status for bug fixes and patches with adpatch: ad_applied_patches ad_bugs SQL> desc ad_applied_patches Name Null? Type ----------------------------------------- -------- ---------------------------- APPLIED_PATCH_ID NOT NULL NUMBER RAPID_INSTALLED_FLAG VARCHAR2(1) PATCH_NAME NOT NULL VARCHAR2(120) PATCH_TYPE NOT NULL VARCHAR2(30) MAINT_PACK_LEVEL VARCHAR2(30) SOURCE_CODE NOT NULL VARCHAR2(3) CREATION_DATE NOT NULL DATE CREATED_BY NOT NULL NUMBER LAST_UPDATE_DATE NOT NULL DATE LAST_UPDATED_BY NOT NULL NUMBER IMPORTED_FLAG VARCHAR2(1) IMPORTED_FROM_DB VARCHAR2(30) IMPORTED_ID NUMBER MERGE_DATE DATE DATA_MODEL_DONE_FLAG VARCHAR2(1) A useful query to track status of applied patches for the E-Business Suite with Oracle EBS is the following: SQL> select applied_patch_id, last_update_date from ad_applied_patches order by last_update_date; APPLIED_PATCH_ID LAST_UPDATE_DAT ---------------- --------------- 41444 03-NOV-09 41445 03-NOV-09 42444 09-NOV-09 42445 09-NOV-09 43444 18-NOV-09 44444 24-NOV-09 45444 30-NOV-09 45445 30-NOV-09 45446 30-NOV-09 45447 30-NOV-09 45448 03-DEC-09 APPLIED_PATCH_ID LAST_UPDATE_DAT ---------------- --------------- 45449 03-DEC-09 45450 03-DEC-09 45451 03-DEC-09

Tuesday, January 13, 2015

Oracle E Business Suite 12.2 ADOP Patching Cycle

Before adop fs1 is run file system fs2 is patch file system You are going to apply a patch As we know there are 5 cycles in ADOP Patching Cycle 1. Prpare 2. Apply 3. Finalize 4. Cutover 5. Cleanup 1. So as the first step when you run adop with phase=prepare adop phase=prepare Enter the APPS password: apps (default password) Enter the SYSTEM password: MANAGER ( defualt password ) Enter the WLSADMIN password:welcome123 (default password) A copy of fs1 will be made in fs2 that will be called as patch file system 2. In the 2nd phase you will apply the patch with the patch number 3. In the 3rd pahse you will run the Finalize ,you go and compile the invalid objects and generate all the dervived objects 4. In the cutover phase you brings down the production system ,and you will swap the patch file system to the run file system ...(the first 3 phase should be complete before runnig the cutover phase ) The patch edition will become your new runedition file system and the patch edition of db to be your new run edition db file system and then you start the application on the patch copy which is obviously the new run ediditon file system 5. In cleanup phase ,it will remove all the obselet objects from the run file edition and send the data to reocver phase . At the end of the adop lifecycle, you will have a copy of old the run file system which will become the nex patch file system as far as application tier is concerned where as the old run system in database wil be descarded Summary of Fundamental Patching Operations Patching is performed in several phases, which are specified on the adop command line as follows: adop phase= Prepare phase - Used to start a new online patching cycle: $ adop phase=prepare Apply phase - Used to apply a patch to the patch edition of a system: $ adop phase=apply patches=123456 workers=8 Finalize phase - Used to perform the final patching operations that can be executed while the application is still online: $ adop phase=finalize Cutover phase - Used to perform the transition to the patched environment: $ adop phase=cutover Cleanup phase - Used to remove old objects that are no longer needed: $ adop phase=cleanup Abort phase - Used only if the online patching cycle needs to be terminated before completion: $ adop phase=abort Important: The abort phase can only be run after the prepare phase and before completion of the cutover phase. After the cutover phase completes, it is no longer possible to abort the online patching cycle. The adop phases are described in more detail in The Online Patching Cycle section of the Patching Procedures chapter. Patch Log Files It is advisable to review the relevant log files after any patching operation. The adop log files are located on the non-editioned file system (fs_ne), under: $NE_BASE/EBSapps/log/adop//__//log For example, if s_ne_base was /u01/R122_EBS/fs_ne, the session ID was 15, and the was patch01_testsys, the path to the adop log files from 9th July 2014 would resemble this: /u01/R122_EBS/fs_ne/EBSapps/log/adop/15/apply_20140709_112226/patch01_testsys/log The adop Interface adop is run from the command line. It prompts for required passwords, but expects all other input parameters to be specified on the command line or in an input file. Running adop The following is a summary of the steps you use to run adop. For a complete procedural description of all the steps, see Creating Customized Instructions for Patching Using PAA. Step 1: Set the environment You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities. Your Oracle E-Business Suite installation includes a shell script in the root installation directory that helps you easily set the run edition or patch edition environment. For example: $ . /EBSapps.env run Step 2: Unzip the patch Download and unzip the patch into the patch top directory, which is identified by the $PATCH_TOP environment variable. Step 3: Review the information in the readme file In the directory where you unzipped the patch, you will find a README.txt file and a README.html file. Review either readme file for information about the patch and for instructions on using Oracle Patch Application Assistant (PAA) to generate customized instructions for your system. Step 4: Run Oracle Patch Application Assistant Run PAA (admsi.pl) to generate customized instructions for your system. Follow the steps in the customized instructions to start the patching process. Step 5: Run adop The customized instructions generated by PAA describe how to run adop using the adop command. Note: You can add arguments on the command line to refine the way adop runs. See adop Modes and Command Line Arguments. A simple example of the commands to execute a complete online patching cycle for patch 123456 is as follows: $ . /EBSapps.env run $ adop phase=prepare $ adop phase=apply patches=123456 $ adop phase=finalize $ adop phase=cutover $ . /EBSapps.env run $ adop phase=cleanup Monitoring Status You can obtain a brief report for the current patching session by running the command: $ adop -status This will display information that includes phases completed and the time taken. In the example below, the current patching session ID is 5: Current Patching Session ID: 5 Node Name Node Type Phase Status Started Finished Elapsed --------------- --------------- ----------- --------------- ------------------------------ ------------------------------ ------------ patchtest1 master PREPARE COMPLETED 06-MAY-13 11:31:38 -07:00 07-MAY-13 12:27:51 -07:00 0:56:13 APPLY COMPLETED 07-MAY-13 04:19:17 -07:00 07-MAY-13 04:43:12 -07:00 0:23:55 CUTOVER COMPLETED 07-MAY-13 05:54:03 -07:00 07-MAY-13 05:57:57 -07:00 0:03:54 CLEANUP COMPLETED 07-MAY-13 09:14:33 -07:00 07-MAY-13 09:22:46 -07:00 0:08:13 The output is also recorded in a log file, called /u01/R122_EBS/fs_ne/EBSapps/log/status__/adzdshowstatus.out. For example, /u01/R122_EBS/fs_ne/EBSapps/log/status_20130507_111647/adzdshowstatus.out. Two additional options with this command are as follows. If you want information about a particular session, specify the relevant session ID: $ adop -status If you want additional details of operations performed: $ adop -status -detail This option will give a summary of last ten adop session IDs, and full details of the file system and database changes introduced by a patch. It also shows the log file location of the current patching cycle. Aborting an Online Patching Cycle. If a patching cycle is failing and the issue cannot be resolved quickly, it is possible to abort the patching cycle and return to normal runtime operation. The patch edition will be dropped. You can abandon a patching cycle (without applying any patches) by running the command: $ adop phase=abort Important: The abort command is only available until successful completion of the cutover phase. After cutover completes, the system is running on the new edition and abort is no longer available for that patching cycle. Warning: Aborting a patching cycle will drop the patch edition, but you must then run the cleanup and fs_clone phases before starting a new patching cycle. The cleanup must be a full cleanup ($ adop phase=cleanup cleanup_mode=full). For example: $ adop phase=prepare $ adop phase=apply patches=123456 [Patch application encounters problems and you want to abort] $ adop phase=abort $ adop phase=cleanup cleanup_mode=full $ adop phase=fs_clone

adcgnjar utility in EBS 12.2

Use the adcgnjar utility for any custom Java or BC4J code for Oracle Application Framework, Oracle CRM Technology Foundation (JTT), Oracle Web Applications Desktop Integrator (BNE), custom servlets, or other custom Java code. This utility generates and signs a file named customall.jar file containing the custom Java and BC4J code and extensions. The customall.jar file is included in the ebsProductManifest.xml so that the customall.jar will be in the CLASSPATH through the ebs-product shared library. The adcgnjar utility does not require any parameters on the command line. When prompted, enter the user name and password of the APPS user. The utility performs the following steps: 1. Creates a temporary custom.zip file that contains all the directories under $JAVA_TOP except the oracle, META-INF, and policies directories. 2. Generates and signs the customall.jar file with the contents of the custom.zip file. 3. Deletes the temporary custom.zip file. MOS Note 1609939.1

Wednesday, January 7, 2015

How To Configure JDeveloper 11g to Invoke Secure Web Services? (Doc ID 1277326.1)

How To Configure JDeveloper 11g to Invoke Secure Web Services? (Doc ID 1277326.1) APPLIES TO: Web Services - Version 11.1.1.0.0 and later Oracle Weblogic Server - Version 11.1.1.1.0 and later Oracle JDeveloper - Version 11.1.1.0.0 and later Information in this document applies to any platform. GOAL How to configure JDeveloper11g to add an existing certificate/keystore to invoke a secure Web Service? SOLUTION Import the certificates, then specify the certificates/keys path in the Run Directory of the project by applying the following steps: Copy your certificate ( eg. certificate.cer ) to JDeveloper's internal JRE directory, for example: C:\Jdeveloper11.1.1.3.0\Oracle\Middleware\jdk160_18\jre\lib\security Import the certificate using the following command: keytool -v -import -file certificate.cer -keystore cacerts Invoke the project properties dialog of your Web Service (Client) project: Select Run/Debug/Profile. Click the button Edit. In the field Run Directory, specify the certificates, keys directory with the following path: C:\Jdeveloper11.1.1.3.0\Oracle\Middleware\jdk160_18\jre\lib\security Restart JDeveloper, and then invoke the secure Web Service.

How To Call a SSL Secured Web Service from JDeveloper 430414.1

How To Call a SSL Secured Web Service from JDeveloper 10.1.3.x ? (Doc ID 430414.1) To BottomTo Bottom In this Document Goal Fix APPLIES TO: Web Services - Version 10.1.3.0.0 to 10.1.3.4.0 Oracle JDeveloper - Version 10.1.3 to 10.1.3.5.0 Information in this document applies to any platform. ***Checked for relevance on 26-Jan-2010*** ***Checked for relevance on 12-Oct-2012*** GOAL How to call a Web Service that is secured by SSL, and that uses certificates. You have the certificate stored in a keystore and have generated a Web Service Proxy using the wizard in JDeveloper. FIX 1. Start a new JDeveloper project and create the Web Service Proxy. 2. Right-click the project node in Application Navigator and select Project Properties ... 3. Select Run/Debug 4. Click New to create a new Run Configuration 5. Enter a name and click Ok 6. Select the new Run Configuration and Click Edit 7. On the Launch Settings page, enter the following in the java options text box -Djavax.net.ssl.trustStore="" -Djavax.net.ssl.trustStorePassword="" -Djavax.net.ssl.keyStore="" -Djavax.net.ssl.keyStorePassword="" Ensure that the Web Service provider's certificate is added in your truststore as a trusted certificate. 8. Click Ok 9. Click Ok to use the new configuration. 10. Run the application and test. NOTE: Even though it is not the purpose of this document, if an explanation is necessary on how to use the JDeveloper wizard to create a Web Service proxy, the Oracle SOA Suite Developer's Guide 10g provides a good explanation at the following URL: http://docs.oracle.com/cd/B31017_01/core.1013/b28764/web_services003.htm#CHDBABBJ For assistance with the creation and manipulation of keystores using keytool, the Java 6 SE documentation provides some guidance at the following URL: http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

Configuring Jdeveloper 11g to work with SSL

Configuring Jdeveloper 11g to work with SSL Configuring Jdeveloper 11g to work with SSL Many times we come across situations where we need to create connection to SSL enabled weblogic server and deploy the code. Here I would like to show steps I have followed to setup Jdev for SSL. Get the server certificate preferably in '.cer' extension.If you have certificate installed in your browser then you can simply export it(Tools->Internet Options->Content then certificates) Copy certificate into any local folder, assume that D:\certificates Open DOS prompt and import certificate into Jdev certificate trust store DOS:\>keytool -import -alias democert -file D:\Certificates\ -keystore D:\Oracle\Middleware\wlserver_10.3\server\lib\DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase Parameters explanation democert is some alias name I have given to my certificate DemoTrustKeyStorePassPhrase is default key store password D:\Oracle\Middleware\wlserver_10.3 is my Integrated WLS home that comes with Jdev DemoTrust.jks is default certificate store comes with WLS(Weblogic server) List certificate in store Open DOS and run below command D:\Oracle\Middleware\jdk160_29\bin>keytool -list -keystore D:\Oracle\Middleware\ wlserver_10.3\ server\lib\DemoTrust.jks Cross check output returned by above command has your certificate If it doesn't list your certificate then import was not successful and you need to make sure import happens successfully We need to import same certificate in below keystore also JDK_HOME\bin>keytool -import -alias -file < certificate file path > -trustcacerts -keystore JDK_HOME\jre\lib\security\cacerts Default pwd will be changeit Restart Jdev and try to create connection to Jdev Note: When you create WLS connection in Jdev please choose 'Always use SSL' and enter SSL Port If you still see issues with creating connection then please follow steps mentioned at Oracle support document-ID 1338707.1 Document says- We need to clean profile and preferences then re create connection again by the following steps: Close Jdeveloper Navigate to following path-C:\Documents and Settings\\Application Data\JDeveloper\system11.1.1. x.x.x.x.x Note : Here x.x.x.x.x is some numbers If you dont find above path then try to search for folder with name starting with 'system11.1.1' Rename this directory to any other name Restart Jdeveloper Try to create connection Now we will have a jdev thats totally clean with preferences set to default values http://soacrux.blogspot.com/2012/09/configuring-jdeveloper-11g-to-work-with.html

Sunday, January 4, 2015

2014: A Year in Review for Oracle E-Business Suite

https://blogs.oracle.com/stevenChan/entry/op_faq2 2014: A Year in Review for Oracle E-Business Suite By Steven Chan (Oracle Development) on Dec 31, 2014 Happy New Year. 2014 was another big year for the Oracle E-Business Suite. Did you miss any of the most-important articles of the year? Upgrading to EBS 12.2 • Three Essential Reference Tools for E-Business Suite Upgrades • Preparing Your Customizations for EBS 12.2 • Top 9 Frequently-Asked Questions About Online Patching • Top Three EBS 12.2 Online Patching Resources • Three Options For Getting to Oracle E-Business Suite Release 12.2 • New 12.2 EBS Technology Stack Documentation Roadmap Available Updates to EBS 12.2 • Oracle E-Business Suite 12.2.4 Now Available • New User Interface Features in Release 12.2.4 • EBS 12.2.4 OA Extensions for Jdeveloper 10g Now Available • E-Business Suite 12.2.4 VM Virtual Appliances Now Available • New Rapid Install StartCD 12.2.0.49 for EBS 12.2 Now Available • November 2014 Updates to AD and TXK for EBS 12.2 • Updated Whitepaper: Using Application Express with EBS 12.2 • Integrating Custom and Third-Party Products With EBS 12.2 Updates to EBS 12.1 • Second Recommended Patch Collection for EBS 12.1.3 Now Available • First Recommended Patch Collection for EBS 12.1.3 Now Available • New OA Framework 12.1 Release Update Pack 4 Now Available • New Patch Wizard for EBS 12.1 Now Available Java • Java Auto-Update Upgrades JRE 7 to 8 in January 2015 • Java (JDK) 7 Certified with E-Business Suite 12.2 Servers • Java JRE 8 Certified with Oracle E-Business Suite • JRE Support Ends Earlier than JDK Support Important Technology Stack Updates • Mobile Apps for Oracle E-Business Suite • Microsoft Office 2013 Certified with E-Business Suite 12.1.3 • Microsoft Office 2013 Certified with E-Business Suite 11i • Microsoft Office 2013 Certified with E-Business Suite 12.0.6 • Microsoft Office 2013 Certified with E-Business Suite 12.2 • Updated: Using Third-Party Identity Managers with E-Business Suite Release 12 • Oracle Functional Testing Suite Advanced Pack for EBS 12.2.4 Now Available • Oracle EBS Adapter for Oracle SOA Suite 12c Now Available • Application Management Pack 12.1.0.2 Certified with EM 12cR4 • E-Business Suite Plug-in 12.1.0.3 for Enterprise Manager 12c Now Available • New Solaris SPARC OS Requirements for EBS R12 • Google Chrome 35 Certified with Oracle E-Business Suite 12.1 & 12.2 • Internet Explorer 11 Certified with E-Business Suite 12.1 • Database 12.1.0.1 Certified with EBS 12.2 • Database 12.1.0.2 Certified with E-Business Suite 12.1 • Oracle Database 11.2.0.4 Certified with E-Business Suite 12.2 Virtualization • Oracle VM Virtual Appliances Available for E-Business Suite Release 12.2.3 • Oracle VM Templates For EBS 12.2.3 For Exalogic • Oracle VM Virtual Appliances for E-Business Suite 12.1.3 Now Available • EBS VMs: Appliances, Templates, and Assemblies Explained • E-Business Suite 12.2.4 VM Virtual Appliances Now Available Maintaining and Extending EBS • Understanding and Managing Licensing Options in Oracle E-Business Suite • Creating a Maintenance Strategy for Oracle E-Business Suite • Oracle Functional Testing Suite Advanced Pack for Oracle EBS Now Available • Testing Your EBS Environment After Database Upgrades • Which JDeveloper Version Works With Your EBS Release? • A Primer on Oracle E-Business Suite REST Services Support Policies • After Windows XP and Office 2003: E-Business Suite Implications • JRE Support Ends Earlier than JDK Support • Support Implications for Your EBS Customizations

Technology Unleashed