Release 3.0.9
Part Number A90096-01
 Library |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Portal Configuration Guide Release 3.0.9 Part Number A90096-01 |
|
After installing Oracle Portal with the Oracle9i Application Server installation, several scripts are made available for post-installation configuration. For example, you may want to customize the configuration and install additional components, such as a standalone Login Server, additional Oracle Portal nodes, or load additional language translations into Oracle Portal.
Specific topics covered include:
For purposes of configuring Oracle Portal, the following scripts are useful, and are described in this appendix:
| Script | Description |
|---|---|
|
|
This script allows you to perform a manual installation of Oracle Portal. If you already have a Login Server installed, install a single portal node without having to install another Login Server. See Section B.2, "Manually Installing Oracle Portal with the winstall Script". |
|
|
This script allows you to perform a manual installation of a standalone Login Server, without a corresponding Oracle Portal installation. See Section B.3, "Manually Installing a Login Server with the linstall Script". |
|
|
This script is responsible for setting up the configuration information associated with a newly-installed Oracle Portal node with a Login Server. Run this script on a newly-installed host in which the Login Server and Oracle Portal are on the same database instance and are being setup for the first time. See Section B.4, "Configuring a New Oracle Portal Instance and Login Server with the ssodatan Script". |
|
|
This script is responsible for setting up the configuration information associated with an Oracle Portal node with a Login Server. This script is also used to add configuration entries to support server aliases or virtual host names. A different partner configuration entry is required for each alias to be used. This script must also be used in any instance when the Oracle Portal node is on a separate database instance from the Login Server. Section B.5, "Updating an Existing Portal Instance with the ssodatax Script". |
You can perform a manual installation of Oracle Portal by running the winstall script or you can create a Login Server for the Oracle Portal by invoking this script.
To manually install Oracle Portal with the winstall script, complete the following:
Follow these steps to manually install Oracle Portal:
lsnrctl start listener
Ensure that your ORCL <ORACLE_HOME>/bin is set in the PATH variable before any other ORACLE_HOME. Otherwise, you may encounter LoadJava or JDBC type errors.
<ORACLE_HOME>/bin/loadjava works correctly. Type loadjava -help to test it and display the help usage messages.
Otherwise, change the directory to the following to run the following onetime script:
<ORACLE_HOME>/portal30/admin/plsql
In a command box, run the onetime script file to install the necessary Oracle Portal packages as follows:
onetime [-p sys_password] [-l logfile] [-c connect_string]
onetime -p change_on_install -l onetime.log -c orcl
winstall, from the following location to install the Oracle Portal product.
<ORACLE_HOME>/portal30/admin/plsql
Run the Oracle Portal installation script parameters as follows:
winstall <-s portal_schema> <-p sys_password> <-u default_tablespace> <-t temporary_tablespace> <-d document_tablespace> <-l logging_tablespace> <-w workflow_schema> <-o sso_schema> <-i pstore_password> <-r random_seed> <-c connect_string>
winstall list_tablespaces [sys_password] [connect_string]
winstall uninstall sys_password portal_schema [sso_schema][connect_string]
winstall -s portal30 -p change_on_install -u users -t temp -d users -l users -o portal30_sso -i portal30_sso_ps -r 12345 -c orcl > winstall.log
The parameter descriptions are provided in the winstall file which opens with any text editor. All arguments are validated before the installation starts.
By default, five schemas are created: portal30, portal30_sso, portal30_sso_public, portal30_public, portal30_demo. The default base schema name and password is portal30 which you can change at installation time. For more information, see Section 2.1, "Oracle Portal Default Schemas".
Install an Oracle Portal node without an associated Login Server by invoking winstall with the following usage:
winstall -s newportalnode -nosso
In the preceding example, executing this command installs an Oracle Portal node in a schema named newportalnode without loading an associated Login Server schema. Usage of this command is useful for installing nodes for a distributed Oracle Portal installation as discussed in Chapter 4, "Distributed Oracle Portal Installations".
You should check the installation session log that describes the actions performed and the components created upon installation. GREP the log file for "ORA-", "PLS-", and "ERROR:" that may have occurred during installation. The log file is located in:
<ORACLE_HOME>/assistants/opca/install.log
Proceed with the next step only if you successfully ran the winstall script and Oracle Portal was installed properly.
If you install an Oracle Portal node with the winstall script, you need to run the ssodatan script afterwards to establish the linkage between the Portal node and the Login Server.
However, if the installation of the Oracle Portal node does not include the Login Server, or you are linking to an existing Login Server, then run the ssodatax script to perform the linkage. See Section B.5, "Updating an Existing Portal Instance with the ssodatax Script".
In a command box, run the ssodatan script from this location:
<ORACLE_HOME>/portal30/admin/plsql
This script configures your Single Sign-On (SSO) login via the Login Server, which is installed as part of Oracle Portal.
For example, if your settings are as follows:
DAD = simpledad ;(from <ORACLE_HOME>/Apache/modplsql/cfg/wdbsvr.app ) SSO DAD = ssodad ;(from <ORACLE_HOME>/Apache/modplsql/cfg/wdbsvr.app ) Portal schema = portal30 Host name = myhost IAS/Apache port = 7777 TNS Alias = ORCL
You would run the ssodatan script as follows in one continuous line. If you use port 80, then omit the colon ':' and the port number altogether:
Also, the hostname must match the ServerName parameter in your <ORACLE_HOME>/Apache/Apache/conf/httpd.conf file.
./ssodatan -w http://hostname:7777/pls/simpledad/ -l http://hostname:7777/pls/ssodad/ -s portal30 -o portal30_sso -c orcl > ssodatan.log
This script completes in a few seconds. Verify that there were no "ORA-" or "PLS-" type errors in your ssodatan.log file. If there were such errors, make sure you correct these before re-running the ssodatan script.
<ORACLE_HOME>/Apache/modplsql/cfg directory.
wdbsvr.app.
wdbsvr.app file by removing all existing entries, and then adding these initial settings (using the example values):
; [WVGATEWAY] defaultDAD = simpledad administrators = all adminPath = /admin_/ admindad = ;upload_as_long_raw = ;upload_as_blob = ;debugModules = ; [DAD_simpledad] connect_string = orcl password = portal30 username = portal30 default_page = portal30.home document_table = portal30.wwdoc_document document_path = docs document_proc = portal30.wwdoc_process.process_download upload_as_long_raw = upload_as_blob = * reuse = Yes connmax = 10 enablesso = Yes pathalias = url pathaliasproc = portal30.wwpth_api_alias.process_download ;name_prefix = ;always_describe = ;after_proc = ;before_proc = ; [DAD_%sso_DAD%] connect_string = orcl password = portal30_sso username = portal30_sso default_page = portal30_sso.wwsso_home.home document_table = portal30_sso.wwdoc_document document_path = docs document_proc = portal30_sso.wwdoc_process.process_download upload_as_long_raw = upload_as_blob = * reuse = Yes connmax = 10 enablesso = Yes pathalias = url pathaliasproc = portal30_sso.wwpth_api_alias.process_download ;name_prefix = ;always_describe = ;after_proc = ;before_proc = ; [DAD_sample] connect_string = sample-tcp password = sample username = sample default_page = sample.home document_table = sample.wwdoc_document document_path = docs document_proc = sample.wwdoc_process.process_download upload_as_long_raw = upload_as_blob = * reuse = Yes connmax = 10 enablesso = Yes pathalias = url pathaliasproc = sample.wwpth_api_alias.process_download ;name_prefix = ;always_describe = ;after_proc = ;before_proc = ;
Stop and restart the Oracle HTTP Server powered by Apache with the following commands:
With Secure Sockets Layer, the start command is:
The Oracle Portal Online Help Content Area contains conceptual, getting started, step-by-step, and troubleshooting Help topics. If you manually install Oracle Portal, choose to install the Oracle Portal online help.
In the <ORACLE_HOME>/portal30/admin/plsql/wwu directory, run the following script (in one continuous line):
./contimp.csh -s portal30 -p portal30 -o portal_help -m reuse -u database_user -d ../../../doc/site/hlp30ca.dmp -c orcl
This process takes about three minutes to complete. Ignore the following messages after the script is run:
security.dmp: No such file or directory pobpage.dmp: No such file or directory Unable to set user acl for:
To install an instance of the Login Server which resides in a database instance without an associated Oracle Portal, execute the linstall script.
This script installs the Login Server schema and also automatically sets the configuration information that registers the Login Server application as a Partner Application to the Login Server itself.
linstall <-o sso_schema> <-i pstore_password> <-s login_server_url> <-r random_ seed> <-p sys_password> <-u default_tablespace> <-t temporary_tablespace> <-d document_tablespace> <-l logging_tablespace> <-c connect_string>
linstall -o portal30_sso -i portal30_sso_ps -s http://server.oracle.com:3000/pls/portal30_sso/ -r 12345 -p change_on_install -u users -t temp -d users -l users -c orcl
The ssodatan script sets up a fresh Oracle Portal and a new Login Server. Running this script completely removes any pre-existing configuration information in the Login Server configuration and replaces it with the information specified in the most recent invocation of this script.
Alternatively, if you are associating a Portal node with an existing Login Server that contains configuration information you want to retain, do not use this script. Instead, invoke the ssodatax script which is described in the next section, Section B.5, "Updating an Existing Portal Instance with the ssodatax Script".
The ssodatan script can only be used on an Oracle Portal and Login Server which reside on the same database instance. If you are setting up a configuration with separate database instances for the Portal and the Login Server, then use a combination of the linstall and ssodatax script to set this up.
In the case of the single instance, where you want to associate a fresh association of Oracle Portal with Login Server, invoke the ssodatan script as follows:
ssodatan <-w portal_url> <-l login_server_url> <-s portal_schema> <-p portal_ password> <-o sso_schema> <-d sso_password> <-e pstore_schema> <-c portal_ connect_string>
ssodatan -loginserver <-l login_server_url> <-o sso_schema> <-d sso_password> <-c portal_connect_string>
ssodatan -w http://webdbsvr.us.oracle.com:3000/pls/portal/ -l http://webdbsvr.us.oracle.com:3000/pls/portal_sso/ -s portal30 -p portal30 -o portal30_sso -d portal30_sso -e portal30_sso_ps -c orcl
ssodatan -w http://webdbsvr.us.oracle.com:3000/pls/portal/ -l http://webdbsvr.us.oracle.com:3000/pls/portal_sso/ -s portal30
ssodatan -loginserver -l http://webdbsvr.us.oracle.com:3000/pls/portal_sso/ -o portal30_sso -d portal30_sso -c orcl
Table B-3 lists the ssodatan script parameters.
The ssodatax script updates the Partner Application's enabler configuration table, WWSSO_PAPP_CONFIGURATION_INFO$. However, before running this script, first update the Login Server's Partner Application configuration table to create the entries on the Login Server side in the following way:
The new Partner Application appears in the Edit/Delete Partner Application list on the Partner Application page. After adding a Partner Application entry on the Login Server, the Login Server generates a site id, site token, and encryption key for the new Partner Application. These are used as input when invoking the ssodatax script.
In the case where you want to add or update entries in the enabler configuration table, invoke the ssodatax script as follows:
ssodatax <-i portal_site_id> <-t portal_site_token> <-k encryption_key> <-w portal_url> <-l login_server_url> <-s portal_schema> <-p portal_password> <-v cookie_version> <-o sso_schema> <-e pstore_schema> <-r pstore_password> <-b pstore_dblink> <-c connect_string> <-n ps_connect_string>
ssodatax <-s portal_schema> <-p portal_password> <-remove portal_host> <-b pstore_dblink> <-c connect_string>
ssodatax -i 1234 -t A1B2C3 -k X9Y8Z7 -w http://webdbsvr.us.oracle.com:3000/pls/portal30/ -l http://webdbsvr.us.oracle.com:3000/pls/portal30_sso/ -s portal30 -p portal30 -v v1.1 -o portal30_sso -e portal30_sso_ps -r portal30_sso_ps -b portal30_dblink -c orcl -n orcl01
ssodatax -i 1234 -t A1B2C3 -k X9Y8Z7 -w http://webdbsvr.us.oracle.com:3000/pls/portal30/ -l http://webdbsvr.us.oracle.com:3000/pls/portal30_sso/ -s portal30
ssodatax -s portal30 -remove webdbsvr.us.oracle.com:3000 -b portal30_dblink
Table B-4 lists the ssodatax script parameters.
The ssodatax script removes entries from the enabler table with the -remove option. When you use this option, the following parameters are applicable:
-s portal_schema
-p portal_password
- remove portal_host
The portal_host is the value of the lsnr_token to remove from the enabler table.
-c connect_string
If you have any problems starting Oracle Portal, see Chapter 8, "Troubleshooting" or run the diagnostics tool.
See also:
In cases where you want to install a distributed Oracle Portal environment, and you need to have more than one distinctly named middle-tier server, you need to define the scope of the Oracle Portal session cookie to be sent to all the middle-tier servers involved in the architecture. By default, the session cookie is scoped to the host from which it was generated which is typically the root path.
For example, if the cookie was generated from www.oracle.com, then the cookie domain is www.oracle.com. However, let's say that another server, portal.oracle.com is also a middle-tier server that needs to get access to that session cookie, then the cookie domain would need to be widened so that the portal.oracle.com server can also see the cookie.
Follow these steps to modify the scope of the portal session cookie:
<ORACLE_HOME>/portal30/admin/plsql/wwc
sqlplus nodea/nodea
SQL> @ctxckupd Oracle Portal Current Settings for Portal Session Cookie: Cookie Domain : Only send cookie back to originating host:port Enter the domain for the session cookie: .oracle.com Settings changed to Cookie Domain : .oracle.com SQL>
This allows you to set the cookie domain for the session cookie. In the example above, the cookie domain is set to .oracle.com.
Oracle Portal and the Login Server perform session management similar to other web-based applications. Sessions are tracked using cookies. Session information is stored in a table in the Portal and Login Server schema. When a user logs out, the session information is marked inactive. A DBMS job subsequently cleans up the inactive rows.
The session table accumulates a number of rows that are flagged as active. When a user shuts down the browser instead of logging out, the row is "active", even though it is not actually in use. The cleanup job cleans up the active rows that are older than a specified duration.
When Oracle Portal is installed, a DBMS job is installed to perform session cleanup of the session table, WWCTX_SSO_SESSION$. The cleanup job is set to run every 24 hours. The first scheduled cleanup occurs 24 hours after the installation of the job.
When the job runs, it deletes all inactive sessions, and all sessions marked active (WWCTX_SSO_SESSION$.ACTIVE = 1), that are older than 7 days (WWCTX_SSO_SESSION$.SESSION_START_TIME < sysdate - 7).
These default settings can be modified by running some job management scripts in the Portal schema to manage Portal sessions, or in the Login Server schema to manage Login Server sessions. They utilize the same session management infrastructure.
Follow these steps to obtain the current cleanup job information:
<ORACLE_HOME>/portal30/admin/plsql/wwc
sqlplus portal30/portal30
SQL> @ctxjget The session cleanup job is job ID 7381 dbms_job.isubmit(job=>7381,what=>'begin execute immediate''begin wwctx_sso.cleanup_sessions(p_hours_old => 168); end;''; exception when others then null; end;',next_date=>to_date('2001-04-17:14:07:20', 'YYYY-MM-DD:HH24:MI:SS'),interval=>'SYSDATE + 24/24',no_parse=>TRUE); PL/SQL procedure successfully completed.
The command results in the display of the currently installed job information, as returned by the DBMS_JOB package. It indicates which procedure is executed, what parameters are passed to it, and when the next invocation is to occur. This particular example indicates that the job is to cleanup active sessions which are a week old (168 hours). It also indicates that the next scheduled job execution is on 4/17/2001 at 5:14 pm, and the job should run every 24 hours thereafter.
If the job execution needs to be modified, either to adjust the age of sessions that should be deleted, or to increase or decrease the frequency of cleanup, you can run the ctxjsub.sql script to submit modified execution parameters.
Follow these steps to submit modified job execution parameters:
<ORACLE_HOME>/portal30/admin/plsql/wwc
sqlplus portal30/portal30
@ctxjsub <hours_old> <start_time> <time_format> <interval_hours>
Table B-5 lists the ctxjsub parameters.
For example:
SQL> @ctxjsub 200 '04/17/2001 10:00' 'MM/DD/YYYY HH24:MI' 12 Created path for job id. DBMS_JOB id = 7381 Cleanup job updated. Job ID = 7381 PL/SQL procedure successfully completed.
The cleanup job submission script can be run any number of times to modify the execution parameters. Each invocation updates the job information associated with the job ID for the cleanup job. This job ID is maintained in the preference store so that the job information is updated instead of submitting multiple jobs.
You can also specify a start_time of 'START', in which case, the time_format parameter is ignored, but you still need to pass it a value (such as 'NOW'). The result is to run the job <interval_hours> hours from now:
SQL> @ctxjsub 168 START NOW 24
This submits the job as it does in the installation.
If you want the cleanup job to execute immediately, then obtain the job ID by calling ctxjget.sql. Once you know the job ID, you can execute the job by issuing the following command in the product schema:
SQL> exec dbms_job.run(7381);
In the preceding example, 7381 is the job ID returned by the call to ctxjget.sql. When you execute a job in this manner, the next automated invocation of the job occurs at interval_hours after this manual invocation. To run the job on the original schedule, you need to resubmit the start_time desired using ctxjsub.sql.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|