Showing posts with label Oracle ias10g. Show all posts
Showing posts with label Oracle ias10g. Show all posts

Thursday, 23 October 2008

Oracle IAS 10g 10.1.3.x Mapping j2ee security roles to OID groups

Today I feel like I have touched down the deepest bottom of applied j2ee. I have spend two hours trying to figure out why mapping of j2ee application roles -- defined in `/META-INF/jazn-data.xml -- to Internet directory groups did not work and all it required was just to restart the OC4J instance. And although I knew the peeps in a Jeep joke, it took me two hours to finally get out and back in again, i.e. do the restart and get over with it.

To be honest, I have always wanted to do that simply by matching j2ee roles and OID groups and then use something as simple as my UserInfo bean to determine allowed user actions. The truth of the matter is that until today I always gave it up after running into the 403 Forbidden reply from Apache popping out after accessing the application..

Anyway, enough with grumbling, my advice to anyone interested in performing the same is: Just when you think you 've finished changing the applications security provider, setting up mappings and deploying the application do a final restart to the instance.

Friday, 29 February 2008

Deploying Oracle ADF: What did I learn about caching

Our company's production application server is located at a site different than the one we do our development. Whenever we deployed a new application users were always complaining about long response times, but we usually blamed that on the network. When we moved away from jsps and started working with JSF pages things really got out of hand.

Response times took as much as 10 seconds when application pages where accessed via WAN, rising the user complaint level to maximum levels.

Additionally the network link appeared to be utilized below 80% and then application server response times as shown at OC4J administration website where much below 0.045 sec.

First thing we tried was to use Oracle's ADF Cache library as explained in Chapter 23 of the ADF Programmers guide for Forms/4GL Developers, without any success. To be precise the library was indeed incorporated into the application but the server response time was still as long as 9 or 10 seconds.

It was then when we asked for help from Oracle Support. So thanks to Kavintha we learned the following :

  • First thing we learned was that the problem was indeed related to caching. Every JSF page created using Oracle ADF utilizes a Javascript file named Common10_1_3_3_0.js with a file size of 120 KB. This is an external script referenced at every page. The problem was that this script was never cached so users had to download it every time causing the delays mentioned above. If this file -- and all related page images -- are cached, then the usual size of an ADF/JSF generated HTML code ranges between 1 and 2 KBytes.
    Enabling full caching options on the Oracle Apache Server can be done by uncommenting the # CacheNegotiatedDocs line of the httpd.conf file located in $ORACLE_HOME/Apache/Apache/conf.
  • Next thing was that if an application is protected by Single-Sign-On then in that case, no matter whether CacheNegotiatedDocs is commented out or not, Apache will always send no-cache headers practically undoing whatever the Apache configuration or the ADF Faces Cache library do.
    The way to allow caching for SSO protected applications is to modify mod_osso.conf located in $ORACLE_HOME/Apache/Apache/conf so the entry for each application looks like this :
            <Location /ProductionDelays>
                    OssoSendCacheHeaders off 
                    require valid-user
                    AuthType Basic
            </Location>
    
    More information about how to to disable the caching headers sent by SSO is available on Metalink note 226119.1. Also you may have a look at a one of my previous postings regarding using SSO which is available through here
  • Last thing we learned about this caching business was that when a JSF application is accessed via SSL, then again caching issues still apply. Firefox will disable caching by default whenever the user loads an https:// URL. IE on the other hand does cache SSL pages by default but this setting can change by a policy set by your system administrator. I realize that in this case Firefox uses the safest approach but unfortunately this will produce very poor results if ADF/JSF pages are to be accessed.
    Enabling disk caching of SSL pages in Firefox can be done by changing the value of the browser.cache.disk_cache_ssl parameter available from the about:config URL.
    IE on the other hand has an option called Do not save encrypted pages to disk available in the Security section of the Advanced internet properties tab. If you want IE to cache content from SSL pages this option must be unchecked.

Wednesday, 23 January 2008

Oracle IAS 10g 10.1.3.1 Installation on Enterprise Linux 5

Yesterday I completed my first installation of Oracle SOA Suite 10.1.3.1 on Oracle Enterprise Linux 5. In order to complete the installation I followed Metalink Note:465159.1, which explains the exact procedure.

Now the only tip I can give you, is to make sure that the /etc/hosts file contains a line that resolves the locally or DNS assigned computer name and domain to the machines network IP address.

My up until now experience has been with SuSE systems only, so on my machine the /etc/hosts/ file always contains a line like

10.5.1.8 lxbakalidis.shelman.int lxbakalidis

An OEL installation hosts file only contains

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain   localhost       lxBakalidis
::1     localhost6.localdomain6 localhost6

... but this is not enough. The installation completed successfully only after I added the line that resolved the external IP to my computer name. So the final etc/hosts file looked something like this :

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain   localhost       lxBakalidis
::1     localhost6.localdomain6 localhost6
10.5.1.8 lxbakalidis.shelman.int lxbakalidis

The symptoms before that were: First OUI was taking a very long time to do the file copy operation and next when at some point installation would complete, then two out of three configuration assistants would fail.

Friday, 8 June 2007

Setting up a Virtual Host in Oracle IAS 10.1.3.1

Sooner or later it would have to come to this. We decided we wanted to setup our application server so that we would end up with two virtual hosts

  • One providing a set of j2ee applications that will be accessible via port 80. This will be used by intra net users
  • Another virtual host, providing an application named MyApp deployed into an OC4J Instance called OC4J_MYAPP that will be accessible via a different DNS name and used by internet users. The actual application will be accessed via SSL provided by a firewall / SSL Converter hosted on a different machine.

The first thing that needed to be done was to enable Apache to run as root and change the listening port to 80. See previous post Oracle IAS 10g 10.1.3.x Enable Apache to run as root and set the default HTTP port to 80 (non SSL)

The next thing was to set up the virtual host. environment. This includes creating a location for the static documents and he log files. In our case I created a websites directory and added a virtual-host-name directory with two subdirs named htdocs and logs.

You then have to go through the patching part and there is no way you can know this unless somebody from Oracle Support tells you. (Thanks Dan!) Out of the box 10.1.3.1 Oracle IAS needs two patches to be applied one 5555875 is the one that will allow your virtual host to be able to mount OC4J exported applications and the second one 5669155 will be the one that will patch the opatch utility so it will install the first one. Both patchsets are available from Oracle metalink.

After you have successfully applied patch numbers 5669155 and 5555875 in sequence, you will have to modify the the httpd.conf file located in $ORACLE_HOME/Apache/Apache/conf/httpd.conf and add a VirtualHost entry to specify the details of your virtual host. My file looks more or less like this

# Defualt virtual host
NameVirtualHost *

# here is where you must enable acess to EM website and other applications 
# so they may be available from the default host
<VirtualHost *>

    Oc4jMountCopy on
    Oc4jMount /em home
    Oc4jMount /em/* home
</VirtualHost>

# Virtual host for example.com

Oc4jRoutingMode Static

<VirtualHost *>
#    Unique location where a unique index.html file exists:
     DocumentRoot /home/oracle/websites/www.example.com/htdocs

#    Name used for this VirtualHost:
     ServerName www.example.com

#    For this purpose, we may need also access on port 80:
     Port 80

     ServerAdmin        me@example.com

#    Must appear in one line
     CustomLog "|/home/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache
                 /bin/rotatelogs /home/oracle/websites/www.example.com/logs/access_log                     
                 43200" common

    Oc4jMountCopy off
    Oc4jMount /MyApp OC4J_MYAPP
    Oc4jMount /MyApp/* OC4J_MYAPP
</VirtualHost>

More or less that does it.

The details can be found in the Apache documentation for virtual hosts, from where the basic idea is summarized as follows:

When a request arrives, the server will first check if it is using an IP address that matches the NameVirtualHost. If it is, then it will look at each section with a matching IP address and try to find one where the ServerName or ServerAlias matches the requested hostname. If it finds one, then it uses the configuration for that server. If no matching virtual host is found, then the first listed virtual host that matches the IP address will be used.

As a consequence, the first listed virtual host is the default virtual host. The DocumentRoot from the main server will never be used when an IP address matches the NameVirtualHost directive. If you would like to have a special configuration for requests that do not match any particular virtual host, simply put that configuration in a &th;VirtualHost> container and list it first in the configuration file.

So to finish it, Just restart the HTTP_Server ...

opmnctl restartproc process-type=HTTP_Server

and it works.

Just one final touch. Since the virtual server will be the home for a single j2ee application, it might be convinient that the static index.html page of the new virtual host directly sends visitors to the j2ee application URL. This is as easy as adding

<meta http-equiv="refresh" content="0; url=/MyApp">

And think that now we are ready.

Friday, 25 May 2007

Adding users in the jazn-data.xml file of a deployed aplication in OC4J

Poor man's authentication in applications deployed on an OC4J instance of an Oracle 10.1.3.x application server often comes down to using basic HTTP authentication and storing user names and passwords in the jazn-data.xml file located in the src/META-INF folder of your ViewController (or UserInterface) project. The technique is documented in Chapter 10 of the Oracle Application Development Framework: Tutorial 10g Release 3 (10.1.3).

A question that I had to answer the first time i started using this was how to change a user's password. I posted this to the JDeveloper forum and Frank Nimphius explained that it is as easy as entering the text in clear text preceded by an ! and then restarting the OC4J instance. The passowrd gets automatically hashed.

The other thing I found out is that, when the application gets redeployed then the jazn-data.xml file does not get copied to the application server so you are left with the initial users created during the initial deployment.

The actual file is stored in $ORACLE_HOME/j2ee/OC4J_NAME//application-deployments/myApp where OC4J_NAME is the name of the oc4j instance and MyApp is the name of the j2ee application.

The best way for me to handle this is to edit and test it on local PC, then copy it to the application server and restart OC4J. So for my EOrders application deployed in the OC4J_SAP instance the story goes like this :

oracle@lachesis:~/product/10.1.3.1/OracleAS_1/j2ee/OC4J_SAP/application-deployments/EOrders> scp thanassis@lxBakalidis:/home/thanassis/jdevhome/mywork/EOrders/View
Controller/src/META-INF/jazn-data.xml .
Password:
jazn-data.xml                                                                100% 2419     2.4KB/s   00:00
oracle@lachesis:~/product/10.1.3.1/OracleAS_1/j2ee/OC4J_SAP/application-deployments/EOrders> vi jazn-data.xml
oracle@lachesis:~/product/10.1.3.1/OracleAS_1/j2ee/OC4J_SAP/application-deployments/EOrders> opmnctl startproc  process-type=OC4J_SAP
opmnctl: starting opmn managed processes...
oracle@lachesis:~/product/10.1.3.1/OracleAS_1/j2ee/OC4J_SAP/application-deployments/EOrders>

Wednesday, 23 May 2007

Oracle IAS 10g 10.1.3.x Enabling and using SSO Authentication

Reading again from the manual, enabling Single-Sign-On for deployed applications on a new 10.1.3.x application server midtier is a three step process For this example my new instance uses the DNS name lachesis.shelman.int and the HTTP server listens at port 80, while my 10.1.2 infrastructure host is named eudoxia:
  1. Create the SSO configuration file on the host running infrastructure services in my case this is a 10.1.2 Oracle IAS infrastructure.
    oracle@eudoxia:~/sso_reg> $ORACLE_HOME/sso/bin/ssoreg.sh 
               -oracle_home_path $ORACLE_HOME 
               -config_mod_osso TRUE 
               -site_name lachesis.shelman.int 
               -remote_midtier 
               -config_file lachesis_osso.conf 
               -mod_osso_url http://lachesis.shelman.int
    CLASSPATH=/home/oracle/OraHome_1/jlib/repository.jar:/home/oracle/OraHome_1/sso/lib/ossoca.jar:/home/oracle/OraHome_1/sso/lib/ossoreg.jar:/home/oracle/OraHome_1/lib/xmlparserv2.jar:/home/oracle/OraHome_1/jdbc/lib/classes12.jar:/home/oracle/OraHome_1/jdbc/lib/nls_charset12.jar:/home/oracle/OraHome_1/jlib/jndi.jar:/home/oracle/OraHome_1/jlib/ojmisc.jar:/home/oracle/OraHome_1/j2ee/home/jazn.jar:/home/oracle/OraHome_1/j2ee/home/jaas.jar:/home/oracle/OraHome_1/jdk/lib/rt.jar:/home/oracle/OraHome_1/jdk/lib/i18n.jar:.:/home/oracle/OraHome_1/sysman/webapps/emd/WEB-INF/lib/emd.jar:/home/oracle/OraHome_1/dcm/lib/dcm.jar:/home/oracle/OraHome_1/sysman/j2ee/lib/portalSMI.jar:/home/oracle/OraHome_1/jlib/emConfigInstall.jar:/home/oracle/OraHome_1/lib/dms.jar:/home/oracle/OraHome_1/opmn/lib/ons.jar:/home/oracle/OraHome_1/j2ee/home/oc4j.jar
    Parameters passed to SSO registration tool :
    param0:-oracle_home_path param1:/home/oracle/OraHome_1 param2:-oracle_home_path param3:/home/oracle/OraHome_1 param4:-config_mod_osso param5:TRUE param6:-site_name param7:lachesis.shelman.int param8:-remote_midtier param9:-config_file param10:lachesis_osso.conf param11:-mod_oso_url param12:http://lachesis.shelman.int
    -DinstallType=
    -DoldOracleHome=
    -DoldOHSUser=root
    Wed May 23 15:07:20 EEST 2007  Invalid argument -mod_oso_url
    Wed May 23 15:07:20 EEST 2007  Missing value for parameter: http://lachesis.shelman.int
    oracle@eudoxia:~/sso_reg> $ORACLE_HOME/sso/bin/ssoreg.sh -oracle_home_path $ORACLE_HOME -config_mod_osso TRUE -site_name lachesis.shelman.int -remote_midtier -config_file lachesis_osso.conf -mod_osso_url http://lachesis.shelman.int
    CLASSPATH=/home/oracle/OraHome_1/jlib/repository.jar:/home/oracle/OraHome_1/sso/lib/ossoca.jar:/home/oracle/OraHome_1/sso/lib/ossoreg.jar:/home/oracle/OraHome_1/lib/xmlparserv2.jar:/home/oracle/OraHome_1/jdbc/lib/classes12.jar:/home/oracle/OraHome_1/jdbc/lib/nls_charset12.jar:/home/oracle/OraHome_1/jlib/jndi.jar:/home/oracle/OraHome_1/jlib/ojmisc.jar:/home/oracle/OraHome_1/j2ee/home/jazn.jar:/home/oracle/OraHome_1/j2ee/home/jaas.jar:/home/oracle/OraHome_1/jdk/lib/rt.jar:/home/oracle/OraHome_1/jdk/lib/i18n.jar:.:/home/oracle/OraHome_1/sysman/webapps/emd/WEB-INF/lib/emd.jar:/home/oracle/OraHome_1/dcm/lib/dcm.jar:/home/oracle/OraHome_1/sysman/j2ee/lib/portalSMI.jar:/home/oracle/OraHome_1/jlib/emConfigInstall.jar:/home/oracle/OraHome_1/lib/dms.jar:/home/oracle/OraHome_1/opmn/lib/ons.jar:/home/oracle/OraHome_1/j2ee/home/oc4j.jar
    Parameters passed to SSO registration tool :
    param0:-oracle_home_path param1:/home/oracle/OraHome_1 param2:-oracle_home_path param3:/home/oracle/OraHome_1 param4:-config_mod_osso param5:TRUE param6:-site_name param7:lachesis.shelman.int param8:-remote_midtier param9:-config_file param10:lachesis_osso.conf param11:-mod_osso_url param12:http://lachesis.shelman.int
    -DinstallType=
    -DoldOracleHome=
    -DoldOHSUser=root
    Check /home/oracle/OraHome_1/sso/log/ssoreg.log for details of this registration
    SSO registration tool finished successfully.
    oracle@eudoxia:~/sso_reg>
    
  2. Now we have the file named lachesis_osso.conf that we need to copy to the actual host running the 10.1.3.x instance.
    oracle@eudoxia:~/sso_reg> scp lachesis_osso.conf oracle@lachesis:/home/oracle
    Password:
    lachesis_osso.conf                                                         100%  417     0.4KB/s   00:00
    oracle@eudoxia:~/sso_reg>
    
  3. Back in the middle tier host, we only need to run file osso1013 located in the $ORACLE_HOME/Apache/Apache/bin directory, passing it the new file as an argument.
    racle@lachesis:~> $ORACLE_HOME/Apache/Apache/bin/osso1013 lachesis_osso.conf
    
    /home/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/conf/httpd.conf successfully updated.
    /home/oracle/product/10.1.3.1/OracleAS_1/Apache/Apache/conf/mod_osso.conf successfully updated.
    
    oracle@lachesis:~>
    

Now when we want to SSO protect any deployed application we usually edit the file mod_sso.conf located in $ORACLE_HOME/Apache/Apache/conf. Let's suppose now that an already installed application uses a web content root like /MyApp. In this case users would invoke it via a URL like http://my_host:my_post/myApp.
Protecting this application with SSO requires that you enter the following in the mod_osso.file.
<Location /MyApp>
    require valid-user
    AuthType Basic
</Location>
As always bouncing the instance is the last step.

Oracle IAS 10g 10.1.3.x Enable Apache to run as root and set the default HTTP port to 80 (non SSL)

This is relatively easy and comes straight out of the Oracle Application Server Administrator's Guide. In order to set the HTTP listen port to value less than 1024 we need to set the Apache to run as root.
[oracle@barbara ~]$ su
Password: 

[root@barbara bin]#  cd $ORACLE_HOME/Apache/Apache/bin
[root@barbara bin]# chown root .apachectl 
[root@barbara bin]# chmod 6750 .apachectl
Logout from the root shell
[oracle@barbara ~]$ vi $ORACLE_HOME/Apache/Apache/conf/httpd.conf
locate the first listen directive. You should see a fragment like :
#
# Port: The port to which the standalone server listens. For
# ports < 1024, you will need httpd to be run as root initially.
#
# This port is used when starting without SSL
Port 7777
Listen 7777
Change both values to 80, save the file and restart the middle tier instance.
[oracle@barbara ~]$ opmnctl stopall
[oracle@barbara ~]$ opmnctl startall
opmnctl: starting opmn and all managed processes...
[oracle@barbara ~]$ 
The new Application server home page can then be accessed simply be typing http://myservername on your browser's address bar

Tuesday, 22 May 2007

Oracle IAS 10g 10.1.3.1

I have just finished installing a development Oracle IAS 10g version 10.1.3.1 and from what I 've seen new instances are created with support for ADF already enabled. So instead of tampering with the XML files consider the upgrade to 10.1.3.x.

Making a new OC4J Instance ADF aware in Oracle IAS 10.1.3

... or simply copy shared library definitions from one OC4J instance to an other

When you create a new OC4J instance on an Oracle Application server 10g 10.1.3 using the createinstance utility, then the new instance does not have the ADF libraries installed and therefore you cannot deploy any ADF based applications that you usually create using JDeveloper.

To resolve this issue -- thanks to Oracle support -- you have to manually add references for the adf.*libraries to the new instance's server.xml file and add references to the bc4j application to both the server.xml and the default-web-site.xml. The correct configuration is only available in the default home instance created during installation, so we are going to copy the setup from there.

The detailed list of steps required are the following. let's suppose that the new oc4j instance name is OC4J_NEW.

  1. Shutdown the server.
  2. Open $ORACLE_HOME/j2ee/home/config/server.xml using any windowed text editor.
  3. Open $ORACLE_HOME/j2ee/OC4J_NEW/config/server.xml using any windowed text editor.
  4. Copy the two shared-library tags with name="adf.oracle.domain" and name="adf.generic.domain" found in the home/config/server.xml and paste them into the OC4J_NEW/config/server.xml after the last of the shared library tags already in the file. (The same technique can be used for practically copying any server library definitions from one instance to an other).
  5. Close the home/config/server.xml file.
  6. Move towards the end of the OC4J_NEW server.xml and locate a line like:
  7. <application name="ascontrol" path="../../home/applications/ascontrol.ear" parent="system" start="false"/> 
    
  8. insert a blank line after it and add the following :
  9. <application name="bc4j" path="../../../BC4J/redist/bc4j.ear" start="true"/>
    
  10. Close and save the OC4J_NEW server.xml file.
  11. Open the OC4J_NEW/config/default-web-site.xml file. Add a line like :
    <web-app application="bc4j" name="webapp" startup="true" root="/webapp"/> 
    
    right after the <default-web-app> tag located in the top. Close and save the file and restart the instance.In case of any typing errors, the instance log provides very detailed error messages -- at least it did so for me.

Thursday, 8 March 2007

Installation of SAP JCo on an Oracle IAS 10.1.3.x on Linux

1) Unpack sapjco to /opt/SAP/SAPJCo.

2) Create the following symbolic links in $ORACLE_HOME/lib

oracle@barbara:~> ln -sf /opt/SAP/SAPJCo/librfccm.so $ORACLE_HOME/lib/librfccm.so
oracle@barbara:~> ln -sf /opt/SAP/SAPJCo/libsapjcorfc.so $ORACLE_HOME/lib/libsapjcorfc.so
3) Create an additional OC4J instance to host SAP enabled Java apps.
oracle@barbara:~> createinstance -instanceName OC4J_SAP
Creating OC4J instance "OC4J_SAP"...
Set OC4J administrator's password for "OC4J_SAP" (password text will not be displayed as it is entered)
Enter password:
Confirm password:
The password for OC4J administrator "oc4jadmin" has been set.
New OC4J instance "OC4J_SAP" has been created.
oracle@lachesis:~>

4) Navigate to the instance home page. Start the new instance and then click on the administration tab and select the Shared libraries.

5) Click on the Create button at the bottom of the page.

5.1) On the Create shared library attributes page enter SAPJCo for the library name and the corresponding SAPJCo version (eg 2.1.6) for the version. Click next

5.2) The following page is entitled “Create Shared Library: Add Archives”. Click on the Add button and insert the /opt/SAP/SAPJCo/sapjco.jar file. Click next

5.3) The final step is the page entitled “Create Shared Library: Import Shared Libraries”. You do not need any adjustments here. Just click finish.

... and that does it.

Friday, 2 February 2007

Starting and stopping a version 10g (10.1.2 & 10.1.3) Oracle Application server

Starting up an infrastructure

I have always wanted to put that down since I keep opening my note book each time I haven't done something like that for quite some time. so here it goes 1) Start the listener
% lsnrctl start
2) Start the Infrastructure database using sqlplus
% sqlplus / as sysdba
startup open;
quit 
3) Start the Oracle processes
 %> opmnctl startall
4) Start the enterprise manager console. (this consumes a lot of memory and system recourses, so it is better to avoid it unless you have to)
% emctl start iasconsole 

Starting up an OC4J Server

In this case just leave out steps 1) and 2) and use a command line like :
% opmnctl startall
% emctl start iasconsole
Note: When starting up a version 10.1.3 server then the emctl command does not need to be used at all. The management website is now a true J2EE application deployed by default and is always accessible is http://myhost:myport/em