6.2. Configuring and Loading the Primary Application Instance

Once the applications have been installed, they must be configured and loaded. First, set the CCM_HOME environment variable based on where your local configuration files should be stored. The default location is /usr/share/ccm. If you use the default location and are installing via RPMs, then the directory will have already been created. If using an alternate location make sure this directory has been created.

If running on an RPM-based system, make sure that you have started a new shell since installing the RPMs, as the scripts added to /etc/profile.d must be sourced in order to set up the deployment shell environment. Alternately you can source them from your existing session with:

. /etc/profile

On Windows, you must execute call CCM_ZIP_ROOT\etc\profile.d\ccm-init-profile.cmd in your command shell in order to set up your environment.

Finally, make sure that the following variables are properly set in your current environment:

Once CCM_HOME is set up, perform the following steps:

  1. If there are any changes necessary to legacy enterprise.init parameters for any applications, copy the file from the app-specific location (defined in the application configuration guide) into $CCM_HOME/conf, and then make any required changes. For example, in order to modify enterprise.init defaults for WAF, extract it with the following:

    pushd $CCM_HOME/conf 
    jar xvf /usr/share/java/ccm-core-version.jar com/arsdigita/core/enterprise.init
    popd
  2. ccm load --interactive pkg-key1 pkg-key2 ...

    The ccm tool is an interface for configuring the installation, with the load command loading the packages listed. Include all required application package keys in the ccm load statement. The package key is the name in the application RPM/ZIP without version information. For example, if the application package is ccm-cms-6.1.0-2.noarch.rpm, the package key will be ccm-cms. This step performs the following actions:

    • Loads the data model

    • Initializes the system (including running the legacy initializers).

    • Sets up both required and optional loader and configuration parameters.

    When inputting the JDBC URL, observe the following formats:

    # For PostgreSQL
    jdbc:postgresql://localhost/dbname?user=username&password=password
    
    # For Oracle8i and Oracle9i Databases
    waf.runtime.jdbc_url=jdbc:oracle:thin:username/password@servername:PORT:ORACLE_SID
    # or
    waf.runtime.jdbc_url=jdbc:oracle:oci8:username/password
    # or
    waf.runtime.jdbc_url=jdbc:oracle:oci8:username/password@tnsname
    # or
    waf.runtime.jdbc_url=jdbc:oracle:oci8:username/password@A SQL*Net name-value pair

    After running ccm load you may get a report of multiple APIs regarding security.jar. This normally occurs when you are using a 1.4.1 version JDK, and is not an error. You may ignore the report.

    NoteNote
     

    ccm has additional options and uses beyond what is documented here. Execute ccm --usage for more information.

  3. For tomcat, run the following using the port numbers for your application; the \ has been included for printing clarity:

    ccm hostinit --container=tomcat --parameter http-port=9090 \
    --parameter shutdown-port=9091

    For resin, run the following using the port numbers for your application:

    ccm hostinit --container=resin http-port=9090

    This step performs the following actions:

    • Generates the servlet container configuration file.

    • Copies the WAF JAR files to the shared library directory.

    • Merges the WAF web application files into the web application root directory.

    TipTip
     

    By default, ccm hostinit will not touch any existing files in the webapp directory. You can use the --clean option to have ccm hostinit delete the webapp directory before copying over the files.