Versions Compared

Old Version 3

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Former user

Saved on

Key

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

To run WSO2 products, you start the product server at the command line. You can then run the Management Console application to configure and manage the product. This page describes how to run the product in the following sections:

Table of Contents
maxLevel3
minLevel3

...

  1. Open a command prompt:
    • On Windows, choose Start -> Run, type cmd at the prompt, and press Enter.
    • On Linux/Solaris, establish a SSH connection to the server or log in to the text Linux console.

  2. Execute one of the following commands, where <PRODUCT_HOME> is the directory where you installed the product distribution:

    • On Windows: <PRODUCT_HOME>/bin/wso2server.bat --run

    • On Linux/Solaris: sh <PRODUCT_HOME>/bin/wso2server.sh

    Info
    titleStarting the server as a Worker Node:

    If you want to provide access to the production environment without allowing any user group (including admin) to log in to the management console, you must start the product as a worker node. You can enable the worker node for your product in two ways:

    1. Use the -DworkerNode startup command when you start the product as shown below:

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

    2.You can set permanently set the -DworkerNode system property to 'true' in your product startup script. When you execute the product startup script, the worker profile will be started automatically.

    Code Block
    '-DworkerNode=false'

    Note that this profile only consists of the back-end features of the Application Server and does not include stubs or any UI features. However, in WSO2 AS, if you require any stubs to be activated in addition to the back-end features when you run the worker profile, you can manually add the relevant JARs to the web application's lib folder before starting the server. For information about other profiles available for AS, see Running the Product on a Preferred Profile.

    If you want to check any additional options available to be used with the startup commands, type -help after the command, such as: sh <PRODUCT_HOME>/bin/wso2server.sh -help.

...

At the sign-in screen, sign in to the Management Console using admin as both the username and password. You can then use the Management Console to manage the product. The tabs and menu items in the navigation pane on the left may vary depending on the features you have installed. For example, following is the Management Console for WSO2 Storage Server:

To view information about a particular page, click the Help link in the top right corner of that page , or click the Docs link to open this documentation for full information on managing the product.

Info

When the Management Console Sign-in page appears, the web browser will typically display an "insecure connection" message, which requires your confirmation before you can continue.

The Management Console is based on HTTPS protocol, which is a combination of HTTP and SSL protocols. This protocol is generally used to encrypt the traffic from the client to server for security reasons. The certificate it works with is used for encryption only, and does not prove the server identity, so when you try to access the Management Console, a warning of untrusted connection is usually displayed. To continue working with this certificate, some steps should be taken to "accept" the certificate before access to the site is permitted. If you are using the Mozilla Firefox browser, this usually occurs only on the first access to the server, after which the certificate is stored in the browser database and marked as trusted. With other browsers, the insecure connection warning might be displayed every time you access the server.

This scenario is suitable for testing purposes, or for running the program on the company's internal networks. If you want to make the Management Console available to external users, your organization should obtain a certificate signed by a well-known certificate authority, which verifies that the server actually has the name it is accessed by and that this server belongs to the given organization.

If you leave the Management Console unattended, the session will time out. The default timeout value is 15 minutes, but you can change this in the <PRODUCT_HOME>/repository/conf/tomcat/carbon/WEB-INF/web.xml file as follows:

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.

 

Stop the Server
Anchor
stop
stop

...