6 Extending the Domain for WebCenter Components

This chapter describes how to use the Configuration wizard to extend the domain that you created in Chapter 4, "Creating a Domain." It contains the following sections:

Section 6.1, "Installing Oracle Fusion Middleware Home"
Section 6.2, "Extending the Domain for WebCenter Components"
Section 6.3, "Restarting the Administration Server"
Section 6.4, "Disabling Host Name Verification for the WebCenter Managed Servers"
Section 6.5, "Starting Node Manager on SOAHOST1"
Section 6.6, "Propagating the Domain Changes to the Managed Server Domain Directory"
Section 6.7, "Propagating the Domain Configuration to SOAHOST2, WCHOST1, and WCHOST2 Using the unpack Utility"
Section 6.8, "Starting the Node Manager on WCHOST1 and WCHOST2"
Section 6.9, "Starting the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers on WCHOST1"
Section 6.10, "Validating the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers"
Section 6.11, "Starting the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers on WCHOST2"
Section 6.12, "Validating the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers"
Section 6.13, "Setting Up the Java Object Cache"
Section 6.14, "Converting Discussions Forum from Multicast to Unicast"
Section 6.15, "Configuring Clustering for Discussion Server"
Section 6.16, "Configuring WS-Security for Discussion Server"
Section 6.17, "Configuring Wiki Server"
Section 6.18, "Configuring Oracle HTTP Server for the WLS_Spacesn, WLS_Portletn, and WLS_Servicesn Managed Servers on WCHOST2"
Section 6.19, "Validating Access Through Oracle HTTP Server"
Section 6.20, "Validating Access Through the Load Balancer"
Section 6.21, "Backing Up the Installation"

6.1 Installing Oracle Fusion Middleware Home

You must install Oracle Fusion Middleware on WCHOST1 and WCHOST2. These nodes will run managed servers configured with WebCenter components.

Follow the steps in Section 4.1, "Installing Oracle Fusion Middleware Home". You must install both Oracle WebLogic Server and WebCenter.

6.2 Extending the Domain for WebCenter Components

In this step, you extend the domain created in Chapter 4, "Creating a Domain" to contain WebCenter components.

Note:

You must back up the current domain before extending the domain. You may use the backup to recover in case any errors were made in the domain extension. See Oracle Fusion Middleware Administrator's Guide.

Change directory to the location of the Configuration wizard. This is within the WebCenter home directory.
```
SOAHOST1> cd MW_HOME/wc/common/bin
```
Start the Configuration Wizard.
```
SOAHOST1> ./config.sh
```
Note:
If you run the Configuration Wizard from the same shell and environment that you used to create the domain, you must deselect the CONFIG_JVM_ARGS=-DTemplateCatalog.enable.selectable.all=true variable. Otherwise, the Configuration Wizard displays all of the available templates, which are not needed for extending the domain for WebCenter components.
In the Welcome screen, select Extend an existing WebLogic domain, and click Next.
In the WebLogic Domain Directory screen, Select the WebLogic domain directory (ORACLE_BASE/admin/<domain_name>/aserver/<domain_name>), and click Next.
In the Select Extension Source screen, do the following:
- Select Extend my domain automatically to support the following added products.
- Select the following products:
  - WebCenter Portlet Producers
  - WebCenter Discussion Server
  - Wiki and Blog Server
  - WebCenter Spaces
  The following products should already be selected, and grayed out. They were selected when you created in domain in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
  - Basic WebLogic Server Domain
  - JRF
  - WSM-PM
Click Next.
If you get a "Conflict Detected" message that Oracle JRF is already defined in the domain, select the Keep Existing Component option and click OK.
In the Configure JDBC Data Sources screen, do the following:
1. Ensure that the following data sources appear on the screen. The user names shown in Table 6-1 assume that wcedg was used as prefix for schema creation from RCU.
  
  Table 6-1 Values for Data Sources
  
  Data Source User Name
  
  mds-SpacesDS
  
  wcedg_mds
  
  WebCenterDS
  
  wcedg_webcenter
  
  PortletDS
  
  wcedg_portlet
  
  DiscussionDS
  
  wcedg_discussions
  
  OWCWikiDS
  
  wcedg_wiki
2. Select the check box next to all the component schemas.
3. Select Configure all datasources as RAC multi-datasources in the next panel.
4. Click Next.
Configure RAC Multi Data Sources screen
1. Enter values for the following fields, specifying the connect information for the RAC database that was seeded with RCU.
  - Driver: Select Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11.
  - Service Name: Enter the service name of the database, for example, wcedg.mycompany.com.
  - Username prefix: Enter the user name for each of the schemas by selecting each schema individually. The user names shown in Table 6-1 assume that wcedg was used as prefix for schema creation from RCU.
  - Password and Confirm Password: enter the password to use to access the schemas.
2. Click Add and enter the details for the first RAC instance.
3. Repeat for each RAC instance.
4. Click Next.
In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.

Click Next when all the connections are successful.
In the Advanced Configuration Screen, select the following:
- Managed Servers, Clusters and Machines
- Deployments and Services
Click Next.

Data Source	User Name
mds-SpacesDS	`wcedg_mds`
WebCenterDS	`wcedg_webcenter`
PortletDS	`wcedg_portlet`
DiscussionDS	`wcedg_discussions`
OWCWikiDS	`wcedg_wiki`

In the Configure Managed Servers screen, add the following managed servers:

Table 6-2 Managed Servers

Name	Server	Listen Port	SSL Listen Port	SSL Enabled
WLS_Spaces1	WCHOST1	9000	n/a	No
WLS_Spaces2	WCHOST2	9000	n/a	No
WLS_Portlet1	WCHOST1	9001	n/a	No
WLS_Portlet2	WCHOST2	9001	n/a	No
WLS_Services1	WCHOST1	9002	n/a	No
WLS_Services2	WCHOST2	9002	n/a	No

Note:

Providing the listen address is mandatory if the cluster mode is 'unicast'.

Click Next.

The Configure Clusters screen should already include the WSM_PM Cluster in the list. Add the following three new clusters:

Table 6-3 Clusters

Name	Cluster Messaging Mode	Multicast Address	Multicast Port	Cluster Address
Spaces_Cluster	unicast	n/a	n/a	Leave it empty.
Portlet_Cluster	unicast	n/a	n/a	Leave it empty.
Services_Cluster	unicast	n/a	n/a	Leave it empty.

Click Next.

In the Assign Servers to Clusters screen, assign servers to clusters as follows:
- Spaces_Cluster:
  - WLS_Spaces1
  - WLS_Spaces2
- Portlet_Cluster:
  - WLS_Portlet1
  - WLS_Portlet2
- Services_Cluster:
  - WLS_Services1
  - WLS_Services2
Click Next.

In the Configure Machines screen, click the Unix Machine tab. Make sure the following four entries exist:

Table 6-4 Machines

Name	Node Manager Listen Address
SOAHOST1	SOAHOST1VHN2 Note that SOAHOST1 should already be configured when you ran the Configuration wizard in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
SOAHOST2	SOAHOST2VHN1 Note that SOAHOST2 should already be configured when you ran the Configuration wizard in Section 4.4, "Running the Configuration Wizard on SOAHOST1 to Create a Domain."
WCHOST1	WCHOST1
WCHOST2	WCHOST2

Leave all other fields to their default values.

Click Next.

In the Assign Servers to Machines screen, assign servers to machines as follows:
- SOAHOST1:
  - AdminServer
  - WLS_WSM1
- SOAHOST2:
  - WLS_WSM2
- WCHOST1:
  - WLS_Spaces1
  - WLS_Portlet1
  - WLS_Services1
- WCHOST2:
  - WLS_Spaces2
  - WLS_Portlet2
  - WLS_Services2
Click Next.
In the Target Deployment to Clusters or Servers screen, click Next.
In the Review WebLogic Domain screen, click Next.
In the Extend WebLogic Domain screen, do not change the values that appear on the screen (since you are extending a domain). Click Extend.
In the Extending Domain screen, click Done.

6.3 Restarting the Administration Server

Restart the Administration Server so that the changes to the domain are picked up.

Stop the Administration Server.
```
SOAHOST1> ./stopWebLogic.sh
```
Start the Administration Server:
```
SOAHOST1> ./startWebLogic.sh
```

6.4 Disabling Host Name Verification for the WebCenter Managed Servers

Before you can start and verify the managed servers, you must disable host name verification. You can re-enable it after you set up SSL communication between the Administration Server and the Node Manager.

To disable host name verification, complete these steps:

Expand the Environment node in the Oracle WebLogic Server Administration Console.
Select Servers. The Summary of Servers page appears.
Select WLS_Spaces1 (represented as a hyperlink) from the Names column of the table. The Settings page appears.
Select the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Repeat these steps for the WLS_Spaces2, WLS_Portlet1, WLS_Portlet2, WLS_Services1, and WLS_Services2 managed servers.

6.5 Starting Node Manager on SOAHOST1

Make sure that Node Manager was started on SOAHOST1. If this is not the case, start Node Manager:

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> ./startNodeManager.sh

6.6 Propagating the Domain Changes to the Managed Server Domain Directory

As described in Section 2.3.2, "Directory Structure," we need to separate the Administration Server domain directory from the managed server directories. In this step, we propagate the changes from one to the other. To propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory, complete these steps:

Create a copy of the managed server domain directory and the managed server applications directory.

Move these directories using the following command (both commands :

mv ORACLE_BASE/admin/<domain_name>/mserver/apps ORACLE_BASE/admin/<domain_name>/mserver/appsbackup

mv ORACLE_BASE/admin/<domain_name>/mserver/<domain_name> ORACLE_BASE/admin/<domain_name>/mserver/>domain_name>backup

Run the pack command on SOAHOST1 to create a template pack using the following commands:

SOAHOST1> cd MW_HOME/wc/common/bin

SOAHOST1> ./pack.sh -managed=true -domain=ORACLE_BASE/admin/<domain_name>/aserver/<domain_name> -template=wcdomaintemplateExtWC.jar -template_name=wc_domain_templateExtWC

Run the unpack command on SOAHOST1 to unpack the propagated template to the domain directory of the managed server using the following command:

SOAHOST1> ./unpack.sh -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/ -template=wcdomaintemplateExtWC.jar -overwrite_domain=true -app_dir=ORACLE_BASE/admin/<domain_name>/mserver/apps

6.7 Propagating the Domain Configuration to SOAHOST2, WCHOST1, and WCHOST2 Using the unpack Utility

To propagate the domain configuration, complete these steps:

Run the following commands on SOAHOST1 to copy the template file created earlier to SOAHOST2, WCHOST1, and WCHOST:

SOAHOST1> scp wcdomaintemplate.jar
       oracle@SOAHOST2:MW_HOME/wc/common/bin

SOAHOST1> scp wcdomaintemplate.jar
       oracle@WCHOST1:MW_HOME/wc/common/bin

SOAHOST1> scp wcdomaintemplate.jar
       oracle@WCHOST2:MW_HOME/wc/common/bin

Run the unpack command on SOAHOST2, WCHOST1, and WCHOST2 to unpack the propagated template.

SOAHOST2> cd MW_HOME/wc/common/bin

SOAHOST2> ./unpack.sh
   -domain=ORACLE_BASE/admin/<domain_name>/mserver/<domain_name>/
   -app_dir=ORACLE_BASE/admin/<domain_dir>/mserver/apps

Repeat the above steps for WCHOST1 and WCHOST2.

6.8 Starting the Node Manager on WCHOST1 and WCHOST2

Set the JAVA_OPTIONS environment variable to define the StartScriptEnabled property before starting Node Manager. On WCHOST1 and WCHOST2, run the following command:
```
WCHOST1> export JAVA_OPTIONS=-DStartScriptEnabled=true
WCHOST2> export JAVA_OPTIONS=-DStartScriptEnabled=true
```

Start Node Manager:

WCHOST1> cd WL_HOME/server/bin
WCHOST1> ./startNodeManager.sh

WCHOST2> cd WL_HOME/server/bin
WCHOST2> ./startNodeManager.sh

After you have started Node Manager for the first time, you can edit the nodemanager.properties file to set the StartScriptEnabled property. The nodemanager.properties file does not exist until Node Manager is started for the first time.

To set the StartScriptEnabled property in the nodemanager.properties file:

Add the following line to the WL_HOME/common/nodemanager/nodemanager.properties file:
```
StartScriptEnabled=true
```

When this property is set in the nodemanager.properties file, you no longer need to define it in the JAVA_OPTIONS environment variable.

6.9 Starting the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers on WCHOST1

Follow these steps to start the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 managed servers:

Access the Administration Console at http://SOAHOST1VHN1:7001/console.
Click Servers.
Open the Control tab.
Select WLS_Spaces1, WLS_Portlet1, and WLS_Services1.
Click Start.

Note:

SOAHOST1VHN1 is the virtual hostname that maps to the virtual IP where the Administration Server is listening (in SOAHOST1).

6.10 Validating the WLS_Spaces1, WLS_Portlet1, and WLS_Services1 Managed Servers

Check that the managed servers are accessible by testing the following URLs:
- http://WCHOST1:9000/webcenter
- http://WCHOST1:9001/portalTools
- http://WCHOST1:9002/owc_wiki
- http://WCHOST1:9001/wsrp-info
- http://WCHOST1:9001/richtextportlet
- http://WCHOST1:9002/owc_discussions
Check that all deployments are active. In the Administration Console, select Deployments. If any failed, check the log files for any errors. The log files can be found at ORACLE_BASE/admin/<domain_name>/mserver/<domain_home/servers/[server_name]/logs.

6.11 Starting the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers on WCHOST2

Follow these steps to start the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 managed servers:

Access the Administration Console at http://SOAHOST1VHN1:7001/console.
Click Servers.
Open the Control tab.
Select WLS_Spaces2, WLS_Portlet2, and WLS_Services2.
Click Start.

6.12 Validating the WLS_Spaces2, WLS_Portlet2, and WLS_Services2 Managed Servers

Check that the managed servers are accessible by testing the following URLs:
- http://WCHOST2:9000/webcenter
- http://WCHOST2:9001/portalTools
- http://WCHOST2:9001/wsrp-tools
- http://WCHOST2:9002/owc_wiki
- http://WCHOST2:9002/owc_discussions
Check that all deployments are active. In the Administration Console, select Deployments. If any failed, check the log files for any errors. The log files can be found at ORACLE_BASE/admin/<domain_name>/mserver/<domain_home/servers/[server_name]/logs.

6.13 Setting Up the Java Object Cache

The Java Object Cache (JOC) should be configured among all the servers running WebCenter Spaces. This local cache is provided to increase the performance of Oracle WebCenter Spaces.

The Java Object Cache can be configured using the MW_HOME/oracle_common/bin/configure-joc.py script. This is a Python script which can be used to configure JOC in the managed servers. The script runs in WLST online mode and expects Administration Server to be up and running.

Note:

After configuring the Java Object Cache using the wlst commands or configure-joc.py script, all affected managed servers should be restarted for the configurations to take effect.

Usage

Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:
```
MW_HOME/wc/common/bin/wlst.sh
$ connect()
```
Enter the Oracle WebLogic Administration user name and password when prompted.
After connecting to the Administration Server using wlst, start the script using the execfile command, for example:
```
wls:/mydomain/serverConfig>execfile('FMW_HOME/oracle_common/bin/configure-joc.py')
```

Configure JOC for all the managed servers for a given cluster.

Enter 'y' when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the managed servers for the given cluster and configure the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:

Do you want to specify a cluster name (y/n) <y>
Enter Cluster Name : Spaces_Cluster
Enter Discover Port : 9988

Here is a walkthrough for using configure-joc.py for HA environments:

execfile('MW_HOME/oracle_common/bin/configure-joc.py')
.
Enter Hostnames (eg host1,host2) : SOAHOST1, SOAHOST2
.
Do you want to specify a cluster name (y/n) <y>y
.
Enter Cluster Name : Spaces_Cluster
.
Enter Discover Port : 9988
.
Enter Distribute Mode (true|false) <true> : true
.
Do you want to exclude any server(s) from JOC configuration (y/n) <n> n

The script can also be used to perform the following JOC configurations:

Configure JOC for all specified managed servers.

Enter 'n' when the script prompts whether you want to specify a cluster name, and also specify the managed server and discover port, when prompted. For example:
```
Do you want to specify a cluster name (y/n) <y>n
Enter Managed Server and Discover Port (eg WLS_Spaces1:9988, WLS_Spaces2:9988) : WLS_Spaces1:9988,WLS_Spaces2:9988
```
Exclude JOC configuration for some managed servers.

The script allows you to specify the list of managed servers for which the JOC configuration "DistributeMode" will be set to 'false'. Enter 'y' when the script prompts whether you want to exclude any servers from JOC configuration, and enter the managed server names to be excluded, when prompted. For example:
```
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y
Exclude Managed Server List (eg Server1,Server2) : WLS_Spaces1,WLS_Spaces3
```
Disable the distribution mode for all managed servers.

The script allows you to disable the distribution to all the managed servers for a specified cluster. Specify 'false' when the script prompts for the distribution mode. By default, the distribution mode is set to 'true'.

Verify JOC configuration using the CacheWatcher utility. See Oracle Fusion Middleware High Availability Guide.

You can configure the Java Object Cache (JOC) using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in the Oracle Fusion Middleware High Availability Guide.

6.14 Converting Discussions Forum from Multicast to Unicast

To convert Discussions Forum from multicast to unicast:

Step 1: Add the startup parameters

To add the relevant startup parameters:

In the Oracle WebLogic Server Administration Console, select Servers, WLS_Services1, Configuration, and then Server Start.

In the Arguments box, add the following:

-Dtangosol.coherence.wka1=WCHost1  -Dtangosol.coherence.wka2=WCHost2
-Dtangosol.coherence.localhost=WCHost1 -Dtangosol.coherence.wka1.port=8089
-Dtangosol.coherence.wka2.port=8089

Where WCHost1 is where WLS_Services1 is running.

Port 8089 is a port reserved for WebCenter Coherence communications.

Repeat steps 1 and 2 for WLS_Services2, swapping WCHost1 for WCHost2 and WCHost2 for WCHost1.
Restart the WLS_Services servers.

Step 2: Validate the changes

To validate the changes:

Log on to the Discussions Forum Administration panel.
Select Cache Settings in the left pane.
At the bottom of the screen, ensure that Clustering is set to enabled.
Repeat steps 1 through 3 for all members of the cluster.

As servers join the cluster they appear at the top of the screen.

6.15 Configuring Clustering for Discussion Server

If this is a Unicast cluster, first ensure that the steps in Section 6.14, "Converting Discussions Forum from Multicast to Unicast" are performed first.

Ensure that all members of the Discussion Server cluster can communicate with each other using the Discussion Server Administration Console:

Login to each member of the cluster at:

http://<host>:<port>/owc_discussions/admin
Go to Cache Settings.

Figure 6-1 Cache Settings Section

Description of "Figure 6-1 Cache Settings Section"
At the bottom of the page, in the Cache Features section, ensure that Clustering is set to Enabled.

The top of the page should now list all members of the cluster.
Again, towards the end of the page, under the Cache Tools section, do Cluster wide cache reset and the Cache warm up Task. Repeat the Cache warm up task on all members of the cluster.

Figure 6-2 Cache Tools Section

Description of "Figure 6-2 Cache Tools Section"

6.16 Configuring WS-Security for Discussion Server

This section describes the procedures for configuring WS-Security for the Discussion Server. These procedures are mandatory. The Client in the EDG case is WebCenter Spaces. The Server is the Discussion Server, which in this case is also on the same machine. For example, WCHOST1 and WCHOST2 function as both the client and the server machines.

6.16.1 Setting up the default Keystores

To set up the default keystores:

Note:

For a cluster setup, the default/demo keystores cannot be used. They are different for each instance. You MUST generate a new keystore.

Create/get a valid signed certificate and import it into a keystore that is accessible by the client library. For example, in development, you can create and self sign a certificate by using the keytool in the JDK.

keytool -genkey -alias <ALIAS> -keypass <KEY_PASSWORD> 
-keystore <KEY_STORE_FILE> -storepass <STORE_PASS> -dname <NAME> -keyalg RSA

For example:

keytool -genkey -alias jive -keypass jive_password -keystore 
client_certs.keystore -storepass clientKeyStorePassword -dname "cn=jive" -keyalg RSA

keytool -selfcert -alias <ALIAS> -keystore <KEY_STORE_FILE> 
-storepass <CLIENT_KEY_PASSWORD> -keypass <KEY_PASSWORD>

For example:

keytool -selfcert -alias jive -keystore client_certs.keystore -storepass
clientKeyStorePassword -keypass jive_password

The client_certs.keystore is generated from the this command, use this as the client certificate.

Export the public key from the certificate.

keytool -export -alias <ALIAS> -file <CLIENT_CERTS_FILE.TYPE> -keystore <KEY_STORE_FILE> -storepass <CLIENT_KEY_STORE_PASSWORD>

For example:

keytool -export -alias jive -file client_public_key.jks -keystore 
client_certs.keystore -storepass clientKeyStorePassword

On the server, import the public key into a Web app accessible keystore.

keytool -import -alias <ALIAS> -file <CLIENT_CERTS_FILE.TYPE> -keystore 
<SERVER_CERT_KEYSTORE_FILE> -storepass <SERVER_KEYSTORE_PASS>

For example:

keytool -import -alias jive -file client_public_key.jks 
-keystore server_public_certs.keystore -storepass serverKeyStorePassword

The server_public_certs.keystore file is generated from this command. Use this as the server certificate.

6.16.2 Distributing the Keystores

The client keystores generated in the previous section must be distributed onto all the machines with ws clients. In an EDG setup this includes all the machines with WebCenter Spaces. The keystores can be located anywhere, as long as the path to the keystores is the same on all the machines in the cluster. For EDG Oracle recommend /u01/app/oracle/keystores/.

The server keystores generated in the previous section must be distributed onto all the machines running Discussion Forum. The keystores can be located anywhere, but the path to the keystores must be the same on all the machines in the cluster.

The rest of this example assumes all of the keystores are located in /u01/app/oracle/keystores/.

6.16.3 Set up Jive Server Properties

To configure ws-security in Jive Server:

Go to DOMAIN_HOME/lib (on any machine in the cluster).

Create a keystore.properties file, insert the following values, and save the file.

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
 org.apache.ws.security.crypto.merlin.keystore.type=jks
 org.apache.ws.security.crypto.merlin.keystore.password=serverKeyStorePassword
 org.apache.ws.security.crypto.merlin.keystore.alias=jive
 org.apache.ws.security.crypto.merlin.file=/u01/app/oracle/keystores/server_public_certs.keystore

The alias and password are the ones used when generating the keystore described above. The file path is the full path to the server certificate generated.

Place the keystore file into a jar file.
```
jar cvf jive_crypto_props.jar keystore.properties
```
Note:
The jar size generated must be close to 616.
rm keystore.properties.
Distribute the jive_crypto_props.jar file to all machines in the cluster running Jive.
Access the Jive administration page:

http://host:port/owc_discussions/admin
Log in as admin user.
Click on the System Properties link, and add the following properties:
```
webservices.soap.custom.crypto.fileName=keystore.properties
```
Restart all the Jive Servers.

6.17 Configuring Wiki Server

As outlined in Section 2.3.2, "Recommended Locations for the Different Directories," the Administration Server domain directory and apps directory is on a shared disk. The apps directory also contains the deployment for Wiki Server. All Wiki Servers in the cluster are sharing this same apps directory. Therefore, for all Wiki servers in the cluster to run properly, the shared storage should be mounted on all nodes.

Set the non clustered mode setting in Wiki Administration, Settings, to false ("Use cached data") on both of the servers.

6.18 Configuring Oracle HTTP Server for the WLS_Spacesn, WLS_Portletn, and WLS_Servicesn Managed Servers on WCHOST2

To enable Oracle HTTP Server to route to the Spaces_Cluster, Portlet_Cluster, and Services_Cluster, which contain the WLS_Spacesn, WLS_Portletn, and WLS_Servicesn managed servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster.

Add the following lines to the OHS_HOME/instances/ohs_instance1/config/OHS/ ohs1/mod_wl_ohs.conf file:

# Spaces

<Location /webcenter>
    WebLogicCluster wchost1.com:9000,wchost2.com:9000
    SetHandler weblogic-handler
</Location>

<Location /webcenterhelp>
    WebLogicCluster wchost1.com:9000,wchost2.com:9000
    SetHandler weblogic-handler
</Location>

<Location /rss>
    WebLogicCluster wchost1.com:9000,wchost2.com:9000
    SetHandler weblogic-handler
</Location>

# Portlet

<Location /portalTools>
    WebLogicCluster wchost1.com:9001,wchost2.com:9001
    SetHandler weblogic-handler
</Location>

<Location /wsrp-tools>
    WebLogicCluster wchost1.com:9001,wchost2.com:9001
    SetHandler weblogic-handler
</Location>

# WSM

<Location /wsm-pm>
    WebLogicCluster soahost1.com:7010,soahost2.com:7010
    SetHandler weblogic-handler
</Location>

# Discussions and Wiki

<Location /owc_discussions>
    WebLogicCluster wchost1.com:9002,wchost2.com:9002
    SetHandler weblogic-handler
</Location>

<Location /owc_wiki>
    WebLogicCluster wchost1.com:9002,wchost2.com:9002
    SetHandler weblogic-handler
</Location>

Add the following lines to the httpd.conf file (located in the same directory as the mod_wl_ohs file):

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName https://wc.mycompany.com:443
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName admin.mycompany.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

NameVirtualHost *:7777
<VirtualHost *:7777>
    ServerName wcinternal.mycompany.com:80
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
</VirtualHost>

Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2:

WEBHOST1> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1
WEBHOST2> ORACLE_BASE/admin/<instance_name>/bin/opmnctl restartproc ias-component=ohs1

The servers specified in the WebLogicCluster parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that the listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.

Some example scenarios:

Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.
Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.

If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.

For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins With Oracle WebLogic Server guide.

6.19 Validating Access Through Oracle HTTP Server

Verify that you can access these URLs:

http://webhostN:7777/webcenter
http://webhostN:7777/webcenterhelp
http://webhostN:7777/rss
http://webhostN:7777/portalTools
http://webhostN:7777/wsrp-tools
http://webhostN:7777/owc_wiki
http://webhostN:7777/owc_discussions

where 'webhostN' specifies the name of each Oracle HTTP Server host (for example, WEBHOST1, WEBHOST2).

6.20 Validating Access Through the Load Balancer

Verify that you can access these URLs:

https://wc.mycompany.com/webcenter
https://wc.mycompany.com/webcenterhelp
https://wc.mycompany.com/rss
https://wc.mycompany.com/portalTools
https://wc.mycompany.com/wsrp-tools
http://wcinternal.mycompany.com/owc_wiki
http://wcinternal.mycompany.com/owc_discussions

6.21 Backing Up the Installation

After you have verified that the extended domain is working, back up the installation. This is a quick backup for the express purpose of immediate restore in case of problems in the further steps. The backup destination is the local disk. This backup can be discarded once the enterprise deployment setup is complete. At this point, the regular deployment-specific backup and recovery process can be initiated. The Oracle Fusion Middleware Administrator's Guide provides further details. For information on describing the Oracle HTTP Server data that must be backed up and restored, refer to the "Backup and Recovery Recommendations for Oracle HTTP Server" section in this guide. For information on how to recover components, see "Recovery of Components" and "Recovery After Loss of Component" sections in the guide. For recommendations specific to recovering from the loss of a host, see the "Recovering Oracle HTTP Server to a Different Host" in the guide. Also refer to the Oracle Database Backup and Recovery Guide for information on database backup.

To back up the installation a this point, complete these steps:

Back up the web tier:
1. Shut down the instance using opmnctl.
```
ORACLE_BASE/admin/<instance_name>/bin/opmnctl stopall
```
2. Back up the Middleware Home on the web tier using the following command (as root):
```
tar -cvpf BACKUP_LOCATION/web.tar $MW_HOME
```
3. Back up the Instance Home on the web tier using the following command (as root):
```
tar -cvpf BACKUP_LOCATION/web_instance.tar $ORACLE_INSTANCE
```
4. Start the instance using opmnctl:
```
ORACLE_BASE/admin/<instance_name>/bin/opmnctl startall
```
Back up the database. This is a full database backup (either hot or cold) using Oracle Recovery Manager (recommended) or OS tools such as tar for cold backups if possible.
Back up the AdminServer domain directory. Perform a backup to save your domain configuration. The configuration files all exist under the ORACLE_BASE/admin/<domain_name> directory.
```
SOAHOST1> tar -cvpf edgdomainback.tar ORACLE_BASE/admin/<domain_name>
```