Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Portal
11g Release 1 (11.1.1)

Part Number E10239-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

F Setting Up and Maintaining a Virtual Private Portal

This appendix walks you through the steps for setting up and maintaining a virtual private portal (VPP). It works through a case study to demonstrate the various tasks involved in setting up and maintaining a virtual private portal (hosted portal).

The following topics are covered in this appendix:

F.1 Overview of Hosting

Before reviewing the tasks, let us look at why hosting features are beneficial and what some of the known limitations are.

F.1.1 Why Use Hosting?

Consider an Application Service Provider (ASP), Acme, that wants to provide portal services for its customers. Acme wants to give its customers the flexibility to build and customize cost-effective and secure portals. They want customers to create and manage their own users, information, and portal pages securely.

Dedicated portal or database instances for each customer would provide the security they require. Traditionally, implementing fully isolated portal environments for multiple organizations within a company required a dedicated database instance for each organization. This proved expensive in terms of hardware and manpower resources, especially when the number of organizations was large. Manpower and hardware costs fast increased as their customer base grew. A single shared instance is obviously more manageable, but will not provide the level of isolation required to host multiple organizations securely.

A single instance is cheaper and easier to manage, but a traditional portal solution requires complex security rules to be written into the application. What Acme needs is the best of both worlds. VPP provides a platform for ASPs a more manageable way for large Enterprise IT departments to host departmental intranet or extranet portal sites. Oracle Portal introduces a more cost-effective and manageable solution for hosting multiple organizations and provides the benefits of a shared instance model with complete security. When using VPP you are required to add subscribers. A Subscriber is a company that signs up with an ASP (Application Service Provider) and receives a stripe on a hosted Oracle Portal.

F.1.2 Known Limitations

Although a shared instance model has many benefits, there are several things to consider before implementing a VPP environment.

Hosted technology will completely isolate each subscriber or identity realm. The VPP will prompt each user to enter their company ID and name, or set a particular context before portal retrieves any content. The scope of the content and data is limited to the subscriber's context. The portal is secured at the subscriber level and does not allow sharing of any data between one subscriber and another. Sharing of data is not allowed for security reasons. For example, VPP should not be used if Company A and Company B need to share documents.

Making repetitive changes to all subscribers is also more complex. From an administrative perspective, user interface manipulation of the portal must be done for each subscriber.

Example F-1 Scenario 1 - Administering Many Subscribers

Company A, Company B, and Company C have identical portal pages 1, 2, and 3. When an administrator logs in to Company A to change the layout of page 1, it only affects that particular subscriber. To change page 1 on Company B, the administrator for Company B would need to perform the same changes using the portal user interface. Logging in to each subscriber is easy, as long as the number of subscribers is small. When administering lots of subscribers, the best way to manage many portal sites is to update the pages by using portal APIs, or through an automated testing tool to make the changes on each site. This makes managing a large number of subscribers very complex.

Example F-2 Scenario 2 - Upgrading

Another area of consideration is upgrading. When performing portal repository upgrades, every subscriber's data must be upgraded. If Acme hosts 1000 subscribers, the portal repository upgrade must go through every subscriber's data before successful completion.

Assume that an average single repository upgrade takes 10 minutes. As it is not possible to split the upgrade process on a single instance, VPP portal repository upgrade will loop through all existing subscribers. So in this example, it would take 10 minutes for a single upgrade multiplied by the number of subscribers: 10 times 1000 will be 10000 minutes. This has huge downtime implications.

Therefore, small manageable deployments of VPP with about 50 subscribers for each instance is recommended. In cases where you must exceed the recommended maximum number, consider deploying multiple VPP instances. To choose a reasonable set of downtime windows to apply changes and upgrades, it is also recommended that you segment on a time zone basis. You can configure multiple portal repositories that could be upgraded individually. So, you can upgrade 50 subscribers on an instance without affecting all the 1000 subscribers at the same time.

Note:

For clarity, the terms Subscribers and Identity Realm are used interchangeably in this document.

F.2 Overview of Steps to Perform for Virtual Private Portals

The following subsections outline the tasks involved in setting up and managing your hosted installation.

F.2.1 Enabling Hosting

  • Enable hosting on Oracle Portal and the OracleAS Single Sign-On (SSO) server.

  • Create a basic structure on Oracle Internet Directory for ASP user/group support.

F.2.2 Setting Up Users and Groups

  • Set up the virtual private portal with a support and administration infrastructure and users. The ASP uses these to administer the virtual private portal on behalf of their customers.

F.2.3 Adding Subscribers

  • Create a new subscriber stripe in the Oracle Portal and SSO schemas. This step includes copying objects like page groups, pages, portlet and providers information so that the default environment and pages can be pre-defined.

  • Create a new Oracle Internet Directory subscriber tree, and establish required portal entries in Oracle Internet Directory (for example, seeded groups, users, and privileges).

  • Copy ASP groups/users for the new subscriber in Oracle Internet Directory (for example, creating mirror entries, assigning privileges, and so on).

F.2.4 Removing Subscribers

  • Remove a subscriber's data in Oracle Portal and SSO schema.

  • Delete the whole subscriber sub tree in Oracle Internet Directory.

F.2.5 Advanced Features

  • WebDAV enables you to use a URL address as a transparent read and write medium where content can be checked out, edited, and checked in.

  • Secure Enterprise Search provides uniform search-and-locate capabilities over multiple repositories, such as Oracle Databases, IMAP servers, Web pages, disk files, and portal page groups.

F.2.6 Pre-Installation Checklist

Before running the scripts to enable virtual private portals, first gather the information to run them. Table F-1 lists and describes the parameters.

Table F-1 Parameters

Parameters Description

-pc

Database connect string for portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-ps

Oracle Portal schema name. By default, it is portal.

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-ss

SSO schema name. By default, it is the orasso.

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=orcladmin. This DN must have Oracle Internet Directory administrative privilege, for example, privilege to create new subscribers.


F.2.7 Using Oracle Directory Manager

To begin the process, use the Oracle Directory Manager (ODM). The ODM is a GUI tool to help you administer Oracle Internet Directory. To obtain the passwords for portal and orasso users:

  1. Launch the Oracle Directory Manager.

    • In the first field, provide the Oracle Internet Directory bind DN (parameter -d). By default, it is cn=orcladmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

    • In the second field, provide the password for Oracle Internet Directory bind DN (parameter -w). By default, it is welcome1.

    • In the third field, select your Oracle Internet Directory instance. If you have not defined your Oracle Internet Directory instance, click the icon to right of the field and give the server host name (parameter -h) and port number (parameter -p) that Oracle Internet Directory is running on. By default, the port is 389 or 4032.

  2. Once you have logged into Oracle Internet Directory, navigate through the menu tree. Entry Management > cn=OracleContext > cn=Products > cn=IAS.

    Cn=IAS Infrastructure Databases > orclReferenceName=name of Oracle Internet Directory database.

  3. Continue to navigate the tree.

  4. Click the orasso user name.

  5. In the right pane, find the section called orclpasswordattribute. This is the password for the orasso user (parameter –sw).

  6. Click the portal user name.

  7. In the right pane, there is a section called orclpasswordattribute. This is the password for the portal user (parameter –pw).

F.3 Enabling Hosting on an Out-of-the-Box Portal

To begin an out-of-the-box Oracle Portal installation, enable hosting on the portal. A C-shell script is provided, that:

To illustrate how the script works, here is what the Oracle Internet Directory tree looks like before running the script:

Figure F-1 Oracle Internet Directory Tree Before Running the Script

Description of Figure F-1 follows
Description of "Figure F-1 Oracle Internet Directory Tree Before Running the Script"

To run the script, type the following at the UNIX command line:

cd ORACLE_HOME/portal/admin/plsql/wwhost
./enblhstg.csh -pc portaldb.acme.com:1521:portaldb -ps portal -sc portaldb.acme.com:1521:portaldb -ss orasso -h oid.acme.com -p 389 -d "cn=orcladmin"

Stop and start the Single Sign-On middle tier.

Refer to Section F.8, "Parameters for the Scripts" for a detailed explanation of parameters.

After running the script, the Oracle Internet Directory tree looks like Figure F-2:

Figure F-2 Oracle Internet Directory Tree After Running the Script

Description of Figure F-2 follows
Description of "Figure F-2 Oracle Internet Directory Tree After Running the Script"

Now the portal instance is hosting enabled. If you go to the portal login screen, you see three input fields (Username, Password, and Company). To login as the default subscriber, you can type acme in the Company field, or leave it blank.

The default subscriber is reserved for the ASP for administrative purposes. For each of its customers, a new subscriber must be created before people can login and use it.

F.4 ASP Users And Groups

Because Acme is the ASP it needs to have a support and administration infrastructure that administers the virtual private portal on behalf of the customers. The virtual private portal provides support for ASP users and groups such that administration of multiple subscriber portals is simple.

These ASP users and groups can have different levels of administrative access into the virtual private portals of the subscribers (customers) of Acme. ASP users can be split into groups according to the privileges they need. For example, Alice needs privileges to manage user accounts; Bob and Joe need privileges to manage page contents. These privilege groups are ASP groups.

These ASP users and groups allow an ASP user to log in to multiple subscribers using a single set of credentials (user name and password), and have the same set of pre-defined privileges in all subscribers. This is achieved by creating mirror entries of ASP users and groups across all subscribers. The user and group entries can then be kept in sync through pre-supplied scripts (see ASP Sync Script section). Note: The synchronization (script or automatic) only synchronizes the users and groups, not the portal privileges.

The following sections show how to set up the virtual private portal with ASP user/group support for Acme, and some other tasks you may want to perform:

F.4.1 Setting Up ASP Users and Groups

The master entry for ASP Users and groups resides under the default subscriber. Because these users and groups will have additional access (not all users in the default subscriber can log in to all subscribers) you must set up ASP users/groups explicitly.

When you enabled hosting on your portal, the script creates a group called ASP under the default subscriber's Oracle Internet Directory sub-tree, which is a placeholder for ASP user/group support. You need this to set up ASP users/groups. From now on, this placeholder group will be referred to as the ASP group. Let's look at some examples where Acme could use ASP users and groups:

  • Alice needs to manage user accounts for all subscribers.

  • Bob and Joe need to manage pages for all subscribers.

  • Tom needs to log in to all subscribers but only have normal authenticated user privileges.

To accomplish this, do the following:

  • Create users asp_alice, asp_bob, asp_joe and asp_tom in default subscriber.

  • Create group asp_UserAdm in default subscriber and assign it privileges to manage user accounts; and also create group asp_PageAdm in default subscriber and assign it privileges to manage pages.

  • Add asp_alice as member of asp_UserAdm group.

  • Add asp_bob and asp_joe as members of asp_PageAdm group.

  • Add asp_UserAdm and asp_PageAdm as members of the ASP group.

  • Add user asp_tom as member of the ASP group.

Now you have set up ASP users and groups. The Oracle Internet Directory tree looks like Figure F-3:

Figure F-3 Oracle Internet Directory Tree with Users and Groups

Description of Figure F-3 follows
Description of "Figure F-3 Oracle Internet Directory Tree with Users and Groups"

More precisely, ASP users/groups are defined as follows:

  • ASP groups are either the ASP group itself or its direct group members.

  • ASP users that are a direct user member of any ASP group.

Figure F-4 Membership Structure of Acme Users and Groups

Description of Figure F-4 follows
Description of "Figure F-4 Membership Structure of Acme Users and Groups"

By default, the portal bootstrap users are members of the ASP group, which means that they are by default ASP users. For more information on portal bootstrap users portal, portal_admin, and FMWADMIN, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

When you add a new subscriber, the portal Add Subscriber script automatically creates mirror entries for those ASP users/groups in the new subscriber. Then those users can login and have the corresponding privileges.

F.4.2 Restrictions

There are some restrictions on ASP users/groups set up:

  • ASP users and groups can be no more than two levels deep. That is, groups that are not direct members of the ASP group or users that are not direct members of any ASP groups are ignored during mirror entry creation.

  • Oracle Internet Directory mandates that user names must be unique (case insensitive) within each subscriber, including those of ASP users. For example, you cannot have two users in subscriber CompanyA called Bob or bob. Because ASP users have mirror entries in every subscriber, use special names for ASP users to prevent user name collisions. This is reflected throughout this document with names such as asp_bob, asp_joe, and the like.

  • For similar reasons, use special names for ASP groups, for example, asp_PageAdmin, asp_UserAdmin, and the like. Because hosting scripts handle ASP groups dynamically, do not make a portal seeded group into an ASP group. If you need an ASP group with similar privileges, create a new group and make it a member of the seeded group.

  • Manage nondefault subscribers' ASP users and groups only with hosting scripts. Do not manually modify those users, or groups, or both.

  • The ASP group is only a placeholder for all ASP users and groups, and is not designed for privilege purposes. Do not assign privileges to the ASP group. Those privileges are not propagated to other subscribers.

F.5 Adding Subscribers

Acme has now set up its ASP users and groups and has enabled the portal for hosting. The next step is to add the customers as subscribers of the virtual private portal. For each of Acme's customers (CompanyA, CompanyB), you will create a new subscriber in the portal. A C-shell script is provided, that:

To add subscriber CompanyA, enter the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name CompanyA -id 1001 -type all -pc
 portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
 portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso –a
 portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d "cn=orcladmin" -rc "cn=OracleContext" -sd acme -tp ORACLE_INSTANCE/ldap/schema/oid/

Refer to Section F.8, "Parameters for the Scripts" for an explanation of parameters.

Check the output, and contact Oracle technical support if there is any error. After running the script, subscriber CompanyA exists in both Oracle Portal and Oracle Internet Directory. The Oracle Internet Directory tree looks like Figure F-5:

Figure F-5 CompanyA in Both Portal and Oracle Internet Directory

Description of Figure F-5 follows
Description of "Figure F-5 CompanyA in Both Portal and Oracle Internet Directory"

Run the same script to create subscriber CompanyB.

Now you have set up a virtual private portal with two subscribers. To try the ASP users, log in to CompanyA as user asp_alice using the same password as when you created it in default subscriber. Alice should have privileges to do user management tasks.

F.6 Advanced Operations on a Virtual Private Portal

Specific topics covered in this section include:

F.6.1 Managing ASP Users and Groups

After you have set up all the subscribers, there could be several types of changes to the ASP users/groups structure. For example:

  • Bob changed his password in default subscriber, and you must synchronize the new password in all other subscribers.

  • Joe left Acme and should no longer be able to login as an ASP user.

  • The service contract changed and the ASP is no longer responsible for user account problems. So, the asp_UserAdm group is no longer needed.

  • When ASP users/groups are changed in the default subscriber, you must use a provided script to synchronize the changes in all other subscribers.

The synchronization script has three options:

F.6.1.1 Password Sync

If you use password sync, the script updates passwords for all the ASP user's mirror entries using the password in the default subscriber.

For the first example in the preceding text, you can synchronize Bob's new password using the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode pwd -u asp_bob

Alternatively, if you have enabled the Directory Integration Platform, it synchronizes ASP user password changes automatically so that you do not need to run this script.

F.6.1.2 Delta (Structure Changes) Sync

If you use delta sync, the script searches for users/groups that have been changed in the default subscriber and applies the changes to all other subscribers.

For departing employees or service contract changes, you can synchronize the new ASP structure using the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode dif

Delta sync assumes consistency and integrity of old ASP structures. That is, if the old ASP structure in each subscriber is consistent and correct, then delta sync does the job correctly. Otherwise, you could use the Complete Sync option, which is slower than the delta sync.

F.6.1.3 Complete Sync

The script takes the ASP structure of default subscriber and overwrites the structures of all other subscribers. If delta sync failed to synchronize the ASP structure, consider using this option.

For departing employees or service contract changes, you can synchronize the new ASP structure using the following commands at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost

>./syncasp.csh -pc portaldb.acme.com:1521:portaldb -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -mode all

Complete sync is slower than delta sync, so use only when necessary.

F.6.2 Removing Subscribers

If a subscriber in a portal is no longer needed, or errors occurred during the subscriber creation, you can permanently remove a subscriber using a provided script. The script does the following:

  • Removes the subscriber's data in Oracle Portal and SSO schema.

  • Deletes the whole subscriber sub tree in Oracle Internet Directory.

For example, to remove a subscriber called nowhere, type the following command at the UNIX command line. However, once you remove a subscriber, there is no way to restore it except from any backups taken of the Oracle Database on which the virtual private portal instance has been installed.

> cd ORACLE_INSTANCE/portal/admin/plsql/wwhost

>./rmsub.csh -name nowhere -pc portaldb.acme.com:1521:portaldb -pp change_on_
install -ps portal -sc portaldb.acme.com:1521:portaldb -sp change_on_install -ss
 orasso –a portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d
 "cn=orcladmin" -cs 1000

See Section F.8, "Parameters for the Scripts" for more information about the parameters.

F.6.3 Using WebDAV in the Virtual Private Portal

WebDAV is a protocol that supports distributed authoring and versioning. With WebDAV the Internet becomes a transparent read and write medium where content can be checked out, edited, and checked in to a URL address. For details about how WebDAV works with Oracle Portal and how to set up WebDAV, see the Oracle Fusion Middleware User's Guide for Oracle Portal.

Setting up WebDAV in a virtual private portal is the same as setting up WebDAV in an out-of-the-box portal.

Connecting to WebDAV in a virtual private portal is similar to that in an out-of-the-box portal. The only difference is that, when connecting to WebDAV in a virtual private portal, you use:

"<username>@<subscriber_name>" as the username, instead of just ...
"<username>" as required in an out-of-the-box portal.

For example, to connect to WebDAV using user Joe in subscriber CompanyA, use joe@CompanyA as the user name and Joe's password as the password.

When different subscribers use the same URL for WebDAV connection, the client side operating system may cache the connection. For example, if you connected to WebDAV using user portal_admin@acme on a Windows 2000 PC, you may not be able to connect to WebDAV in subscriber CompanyA as user joe@CompanyA because of the operating system cache. For details about how to clear an operating system cache and stored user name and password, see your operating system documents.

F.6.4 Setting Up Directory Integration Platform for the Virtual Private Portal

The Directory Integration Platform is a comprehensive framework that performs synchronization between various directories and directory-enabled applications. One of the services it provides is Provisioning Integration, which can send notifications about directory events to Directory Enabled Applications.

In an out-of-the-box Oracle Portal installation, the Directory Integration Platform is enabled. If you have disabled Directory Integration Platform for a virtual private portal, do the following to re-enable Directory Integration Platform:

  1. Run the provided script that enables Directory Integration Platform on existing subscribers.

    For example, for UNIX:

    enbldip.csh -pc portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -h oid.acme.com -p 389 -d "cn=orcladmin" -enable
    
  2. Uncomment the calls to oidprovtool in the addsub.csh and rmsub.csh, so that those two scripts take care of Directory Integration Platform profile entries when you add/remove subscribers.

    To do this:

    1. Open the two files in your editor.

    2. Search for lines with the oidprovtool string.

    3. Uncomment those lines.

Also, you can do the following to disable Directory Integration Platform on all subscribers in your portal:

  1. Run the provided script in at the UNIX command line as follows:

    enbldip.csh -pc portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -h oid.acme.com -p 389 -d "cn=fmwadmin" -disable
    
  2. Comment out the calls to oidprovtool in addsub.csh and rmsub.csh, so that those two scripts ignore Directory Integration Platform profile entries when you add or remove subscribers.

    To do this:

    1. Open the two files in your editor.

    2. Search for lines with oidprovtool.

    3. Comment these lines out.

F.6.5 Partially Prepare (Pre-Cook) Subscribers

Creating a new subscriber by running the addsub.csh script can take a few minutes based on how the computer where Oracle Portal, Oracle Internet Directory, and OracleAS Single Sign-On are installed is configured. Along with the data operations that occur when a new subscriber is created, most ASPs have some administrative provisioning and subscriber-specific customizations that they perform when a subscriber is created.

To expedite subscriber registration, the virtual private portal allows ASPs to partially prepare the subscribers. This is done so that when an ASP is registered, the subscriber need only perform post registration customizations and directly assign a virtual private portal stripe to that subscriber. The virtual private portal provides a database-only mode in the addsub.csh script where the data copying is performed on the portal and SSO databases. When the ASP is ready to assign a stripe to a subscriber, it can complete the subscriber creation by running the addsub.csh script using the LDAP mode.

To partially prepare a subscriber in portal and SSO databases, use the -type parameter in addsub.csh. For example, type the following at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name TEMP_COMPANY -id 1003 -type db -pc
 portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
 portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso -h
 oid.acme.com -p 389 -d "cn=orcladmin" -rc "cn=OracleContext" -sd acme

You can use a temporary name for company name, like (TEMP_COMPANY) as used in the preceding example. Later, when a customer (example, CompanyC) comes, you can run the following command at the UNIX command line:

> cd ORACLE_HOME/portal/admin/plsql/wwhost
>./addsub.csh -name CompanyC -id 1003 -type ldap -pc
 portaldb.acme.com:1521:portaldb -pp change_on_install -ps portal -sc
 portaldb.acme.com:1521:portaldb -sp change_on_install -ss orasso -a
 portal.portaldb.portaldb.acme.com -h oid.acme.com -p 389 -d "cn=orcladmin" 
 -rc "cn=OracleContext" -sd acme -tp ORACLE_INSTANCE/ldap/schema/oid/

You must use the same subscriber ID when you partially prepare the subscriber, and give the real name of your customer (CompanyC). The new name will replace the old name (TEMP_COMPANY in the preceding example). The script will create an Oracle Internet Directory subscriber tree for CompanyC and synchronize the Oracle Internet Directory settings to portal schema, which takes less time than creating the subscriber from scratch.

You do have to partially prepare (using -type db option) the subscriber before you can use run addsub.csh with -type ldap option.

Oracle Portal Middle-Tier Installation on the Virtual Private Portal

Follow the steps in Chapter 3, "Pre-Installation and Post-Installation Tasks" to run the Oracle Portal middle-tier installation.

The Oracle Portal middle-tier installation can be run against a virtual private portal.

F.7 Restrictions

The following subsections provide summaries of the restrictions on the different virtual private portal scripts and operations:

F.7.1 Scripts

The virtual private portal configuration and provisioning scripts currently only run on a UNIX C-shell environment.

F.7.2 ASP Users/Groups Support

  • The top level ASP group must not have any Oracle Internet Directory privileges assigned to it. Privileges are not copies or synchronized across subscribers. Privileges of the sub-groups of the ASP group are synchronized and copied.

  • Any modifications to the ASP user and group structure in Oracle Internet Directory that are performed on any other subscriber other than the default subscriber are not preserved when the subscriber synchronization scripts are run.

  • Portal seeded groups should not be designated as ASP groups.

F.7.3 Add Subscriber

Names of new subscribers must be unique within Oracle Internet Directory.

F.7.4 Remove Subscriber

This script cannot be used to remove the default subscriber. To do that, use the Portal Dependency Settings Tool, ptlconfig.

F.7.5 Upgrade

When performing an upgrade from Oracle Portal release 9.0.2.x to 9.0.4.x, the Oracle Text indexes need to be re-created. See Section 10.3.4.1, "Creating All Oracle Text Indexes Using ctxcrind.sql" for information on running the ctxcrind.sql script to re-create all the Oracle Text indexes.

F.8 Parameters for the Scripts

Table F-2 through Table F-6 list and describe all the parameters for the scripts provided for administering a virtual private portal. These scripts can be found in the ORACLE_HOME/portal/admin/plsql/wwhost directory.

Note:

To produce a list of the parameters for any of the scripts, run the script in your UNIX shell without any parameters. If you want the output of the scripts to be saved to a log file, type |& tee <log_filename> at the end of the command, replacing <log_filename> with the name of your log file.

Table F-2 enblhstg.csh

Parameter Description

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-ps

Oracle Portal schema name. By default, it is portal.

-pw

Oracle Portal schema password (no default).

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-ss

SSO schema name. By default, it is the orasso

-sw

SSO schema password (no default).

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN should have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).


Table F-3 addsub.csh

Parameter Description

-name

Oracle Internet Directory nickname of the new subscriber. This is a mandatory parameter. This name must not have been used by any other subscriber

-id

Internal ID for the new subscriber, which is used within Oracle Portal and OracleAS Single Sign-On. This is a mandatory parameter. It should not have been used by any other subscriber in Oracle Portal or OracleAS Single Sign-On schema.

-type

Valid values are:

  • db – only copy seed data in Oracle Portal and OracleAS Single Sign-On schemas.

  • ldap – create Oracle Internet Directory entries for Oracle Portal and OracleAS Single Sign-On. You can run the script only using -type ldap option after you add temporary subscriber using -type db option.

  • all – default value, do both db and ldap types jobs.

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-pp

SYS user password of portal instance. By default, change_on_install.

-ps

Oracle Portal schema name. By default, portal.

-pw

Oracle Portal schema password (no default).

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-sp

SYS user password of SSO instance.

-ss

SSO schema name. By default, it is orasso.

-sw

SSO schema password. By default is the value of -ss parameter.

-a

Portal Application name. By default, it is <portal_schema>.<sid>.<dbhost>

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-rc

Oracle Internet Directory root context DN. By default, it is cn=OracleContext

-sd

Oracle Internet Directory nickname of the template subscriber. By default, it is the nickname of the portal default subscriber.

-tp

File system path of template files for Oracle Internet Directory subscriber creation. By default, it is ORACLE_INSTANCE/ldap/schema/oid/.


Table F-4 rmsub.csh

Parameter Description

-name

Oracle Internet Directory nickname of an existing nondefault subscriber to be removed. This is a mandatory parameter. Default subscriber cannot be removed using this script, use the ptlconfig tool instead.

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-pp

SYS user password of portal instance (no default).

-ps

Oracle Portal schema name. By default, it is portal.

-sc

Database connect string for SSO schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. By default, it is the value of -pc parameter.

-sp

SYS user password of OracleAS Single Sign-On instance. By default, if OracleAS Single Sign-On and Oracle Portal are on different database instances, it is change_on_install; if OracleAS Single Sign-On and Oracle Portal use the same database instance, it is the value of -pp parameter.

-ss

SSO schema name. By default, it is orasso.

-a

Portal Application name. By default, it is <portal_schema>.<sid>.<dbhost>.

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-cs

Commit size, specifying the number of rows that can be deleted before a mandatory database commit. By default, it is 1000.


Table F-5 syncasp.csh

Parameter Description

-mode

This is a mandatory parameter. Valid values are:

  • pwd – Synchronize password for one ASP user.

  • dif – Synchronize ASP structure changes since last synchronization.

  • all – Do a complete synchronization of ASP structure.

-pc

Database connect string for Oracle Portal schema, in format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-ps

Oracle Portal schema name. By default, portal.

-pw

Oracle Portal schema password (no deafault).

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-u

This parameter is used with the password sync mode (pwd) to specify the user name whose password must be synchronized.

-l

Log file name.


Table F-6 embldip.csh

Parameter Description

-pc

Database connect string for Oracle Portal schema, in the format of <host>:<port>:<sid>, where <host> is a fully qualified domain name. This is a mandatory parameter.

-pp

SYS user password of portal instance (no default).

-ps

Oracle Portal schema name. By default, it is portal.

-h

Oracle Internet Directory server host name. This is a mandatory parameter.

-p

Oracle Internet Directory server port number. By default, it is 389.

-d

Oracle Internet Directory bind DN. By default, it is cn=fmwadmin. This DN must have Oracle Internet Directory admin privilege, for example, privilege to create new subscribers.

-w

Password for Oracle Internet Directory bind DN (no default).

-enable

Enables Directory Integration Platform on all subscribers in portal. This parameter precedes the -disable parameter.

-disable

Disables Directory Integration Platform on all subscribers in portal.