This documentation is for WSO2 Identity Server 5.1.0 . View documentation for the latest release.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
titleBefore you begin
  • The Management Console uses the default HTTP-NIO transport, which is configured in the catalina-server.xml file in the <IS_HOME>/repository/conf/tomcat directory. This transport must be properly configured in this file for the Management Console to be accessible.
  • The config-validation.xml file in the <PRODUCT_HOME>/repository/conf/etc directory contains a list of recommended system parameters, which are validated against your system when the server starts. See Configuring config-validation.xml for details on modifying these parameters before starting the server.

Starting the server
Anchor
start
start

Follow the relevant instructions based on the operating system you use. 

On Windows/Linux/Mac OS 

To start the server, you run the script wso2server.bat (on Windows) or wso2server.sh (on Linux/SolarisMac OS) from the bin folder. Alternatively, you can install and run the server as a Windows service.

Info

To start and stop the server in the background mode of Linux, run wso2server.sh start and wso2server.sh stop commands. 

  1. Open a command prompt:
    • On Windows, choose Start -> Run, type cmd at the prompt, and press Enter.
    • On Linux/SolarisMac OS, establish a SSH connection to the server or log in to the text Linux console.
  2. Execute one of the following commands, where <IS_HOME> is the directory where you installed the product distribution:
    • On Windows: <IS_HOME>/bin/wso2server.bat --run
    • On Linux/SolarisMac OSsh <IS_HOME>/bin/wso2server.sh

      Info

      If you want to provide access to the production environment without allowing any user group (including admin) to log into the management console, execute one of the following commands.

      • On Windows: <PRODUCT_HOME>\bin\wso2server.bat --run -DworkerNode
      • On Linux/Mac OS: sh <PRODUCT_HOME>/bin/wso2server.sh -DworkerNode

      For additional options you can use with these startup commands, type -help after the command, such as: sh <PRODUCT_HOME>/bin/wso2server.sh -help 

The operation log appears. When the product server is running, the log displays the message "WSO2 Carbon started in 'n' seconds."

On Solaris 

To start the server, run <PRODUCT_HOME>/bin/wso2server.sh (on Solaris) from the Command Prompt as described below. 

Anchor
instructions
instructions

Note

Following instructions are tested for an Oracle Solaris 10 8/11 x86 environment.

  1. Click Launch -> Run Applications, type dtterm at the Prompt, and then press Enter, to open a Command Prompt.
  2. Execute the following command: <PRODUCT_HOME>/bin/bash wso2server.sh.
  3. The operation log appears in the command window. When the product server has successfully started, the log displays the message "WSO2 Carbon started in 'n' seconds".

 

Info

If you are starting the product in service/nohup mode in Solaris, do the following:

  1. Update the <PRODUCT_HOME>/bin/wso2server.sh file as follows:
    1. Search for the following occurrences: nohup sh "$CARBON_HOME"/bin/wso2server.sh $args > /dev/null 2>&1 &

    2. Replace those occurrences with the following:  nohup bash "$CARBON_HOME"/bin/wso2server.sh $args > /dev/null 2>&1 &

      Tip

      The only change is replacing sh with bash. This is required only for Solaris.

  2. Update your PATH variable to have /usr/xpg4/bin/sh as the first element. This is because /usr/xpg4/bin/sh contains an sh shell that is newer than the default sh shell. You can set this variable as a system property in the wso2server.sh script or you can run the following command on a terminal:

    Code Block
    export PATH=/usr/xpg4/bin/sh:$PATH
  3. Start the product by following the above instructions.


Running the management console
Anchor
run
run

Once the server has started, you can run the Management Console by opening a Web browser and typing in the management console's URL. The URL is displayed towards the end of the server start script's console and log. For example:

...

You can use this URL to access the Management Console on this computer from any other computer connected to the Internet or LAN. When accessing the Management Console from the same server where it's installed, you can type "localhost" instead of the IP address: https://localhost:9443/carbon

Tip

Tip: The Management Console URL depends on can be changed by modifying the value of the MgtHostName in the <PRODUCT_HOME>/repository/conf/carbon.xml file.

Code Block
languagexml
<MgtHostName>localhost</MgtHostName>

...

Code Block
languagehtml/xml
<session-config>
   <session-timeout>15</session-timeout>
</session-config>
Info
titleRestricting Access to the Management Console and Web Applications:

You can restrict access to the management console of your product by binding the management console with selected IP addresses. Note that you can either restrict access to the management console only, or you can restrict access to all web applications in your server as explained below.

  • To control access only to the management console, add the IP addresses to the <PRODUCT_HOME>/repository/conf/tomcat/carbon/META-INF/context.xml file as follows:

    Code Block
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="<IP-address-01>|<IP-address-02>|<IP-address-03>"/>

    The RemoteAddrValve Tomcat valve defined in this file will only apply to the Carbon management console, and thereby all outside requests to the management console will be blocked. 

  • To control access to all web applications deployed in your server, add the IP addresses to the <PRODUCT_HOME>/repository/conf/context.xml file as follows:

    Code Block
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="<IP-address-01>|<IP-address-02>|<IP-address-03>"/>

    The RemoteAddrValve Tomcat valve defined in this file will apply to each web application hosted on the Carbon server. Therefore, all outside requests to any web application will be blocked.

  • You can also restrict access to particular servlets in a web application by adding a Remote Address Filter to the web.xml file (stored in the <PRODUCT_HOME>/repository/conf/tomcat/ directory), and by mapping that filter to the servlet url. In the Remote Address Filter that you add, you can specify the IP addresses that should be allowed to access the servlet.


    The following example from a web.xml file illustrates how access to the management page (/carbon/admin/login.jsp) is granted only to one IP address:
    Code Block
    <filter>
        <filter-name>Remote Address Filter</filter-name>
        <filter-class>org.apache.catalina.filters.RemoteAddrFilter</filter-class>
            <init-param>
                <param-name>allow</param-name>
                <param-value>127.0.01</param-value>
            </init-param>
    </filter>
    
    <filter-mapping>
        <filter-name>Remote Address Filter</filter-name>
        <url-pattern>/carbon/admin/login.jsp</url-pattern>
    </filter-mapping>
Note: Any configurations (including valves) defined in the <PRODUCT_HOME>/repository/conf/tomcat/catalina-server.xml file applies to all web applications and is globally available across server, regardless of host or cluster. See the official Tomcat documentation for more information about using remote host filters.

Stopping the server
Anchor
stop
stop

...