| iKnowBase Quickstart embedded web server | ||
|---|---|---|
| Previous | Next | |
| Apache Solr Search Server | Installing on Oracle WebLogic Server | |
NOTE: This chapter assumes the iKnowBase database repository has been created, as outlined in Quick Installation and upgrade overview .
The iKnowBase distribution contains an embedded web server usable for small to medium installations, with very small footprint and very easy installation.
Verify / review the recommended installation structure outlined in Quick Installation and upgrade overview .
If you’ve not already done so, set up the quickstart instance configuration file described in outlined in Quick Installation and upgrade overview .
For the examples further down we assume you’ve used the configuration file name
production.properties for a configuration named “production”.
With this configuration, you should be able to easily run and test the applications:
cd /opt/iknowbase/production
./quickstart.sh production.properties webServer
Start a web-browser, and navigate to http://YOUR_SERVER_NAME:8080/ressurs/iknowbase (to see documentation), http://YOUR_SERVER_NAME:8080/index.html (for the viewer application), or http://YOUR_SERVER_NAME:8080/ikbStudio (for the Development Studio). The first two should open immediately, while the second one will require login, which requires configuration as shown below.
Using the Quickstart embedded web server, application deployments is specified in the same property file as all other configuration.
The Quickstart program contains a default configuration that automatically deploys the applications: /ressurs, /. If this is what you want, you don’t have to make any changes or configure any deployments.
If you want to customize the deployment, start by specifying which applications to deploy. The names are only used internally to the property file, but pick names that are easy to understand:
# Web server configuration
web.apps=webRessurs,webIkbWebApp
NOTE that webIkbWebApp is by default deployed to context root / and MUST be listed as the last application in the web.apps property.
Next, add two entries for each application. First add an entry for the application path, which is where the application will be mounted. Next add an entry for the application WAR-file, which is where the application itself is located (can be a war file or a directory containing war contents / exploded war). These entries will be the name of the application, followed by “.path” and “.war” respectively:
# Web server configuration
web.apps=webRessurs,webIkbWebApp
# Web application definitions
webRessurs.path=/ressurs
webRessurs.war=iknowbase-resources-6.7.war
webIkbWebApp.path=/
webIkbWebApp.war=iknowbase-webapp-6.7.war
Often, you will want to add custom deployment, such as a your own resources (images, scripts, etc). This is done the exact same way, but note that the file-property is here used to point to a directory:
# Web server configuration
web.apps=webRessurs,webCustomResource,webIkbWebApp
# Web application definitions
webRessurs.path=/ressurs
webRessurs.war=iknowbase-resources-6.7.war
webIkbWebApp.path=/
webIkbWebApp.war=iknowbase-webapp-6.7.war
webCustomResource.path=/custom-resources
webCustomResource.war=/opt/iknowbase/production/custom-resources
As you can see in the examples, you can change the url mount point at will. Note that the Quickstart web server will visit the mount points in the order they appear in the
web.apps property, and that having the wrong order is important. Look at the partial example below:
web.apps=root,ressurs
root.path=/
ressurs.path=/ressurs
If a client asks for “/ressurs”, this will be captured by the application “root”, and served from there. Therefore, remember to set the longest paths to the beginning of the “web.apps” definition.
It will sometimes be required to have multiple applications deployed towards different hosts, for example to mount webdav at root of “webdav” and “webdav.example.com” and Viewer at the root of all other servers. This can be handled by defined virtual hosts for the required applications:
web.apps=webIkbWebApp,webIkbWebdav
webIkbWebApp.path=/
webIkbWebApp.war=iknowbase-viewer-webapp-6.7.war
webCustomResource.path=/custom-resources
webCustomResource.war=/opt/iknowbase/production/custom-resources
webCustomResource.vhosts=custom-resource.example.org, custom-resource
In the example below, when a client asks for “http://custom-resource/” or “http://custom-resource.example.org”, the request will be served by the webCustomResource application. Root requests to all other hosts (such as http://intranet.example.org or http://testserver.example.org) are handled by the iknowbase-webapp application, which has no particular host name affinity.
The recommended sequence for configuration is to first set up iKnowBase using the internal user directory, and verify sure that you have access to the iKnowBase web applications. After that, you can change to any supported authentication setting you want, but with the knowledge that iKnowBase does indeed work properly with a simple login service.
See iKnowBase Installation Guide > Web Application Security for additional explanations.
We strongly recommend using SSL (https) for all production sites.
If you terminate SSL in an external proxy, that proxy will typically use HTTP (an unsecured connection) to talk to the application server. Then, the application server will not be aware that the browser sees a secure connection, and will by default generate links to an unsecure site. To avoid this, note the following items:
If using Apache httpd for ssl-termination, the following configuration in httpd.conf should set the required header:
<Virtualhost ...>
...
RequestHeader set X-Forwarded-Proto "https"
...
</Virtualhost>
To configure the Quickstart application server, set the property
web.honorXForwardedHeaders in the property file:
...
web.honorXForwardedHeaders=true
...
The embedded web server can be configured to listen for HTTPS traffic with the following options:
...
web.ssl.port=8443
web.ssl.keyStorePath=quickstart.keystore
web.ssl.keyStorePassword=<KEYSTORE_PASSWORD>
web.ssl.certAlias=<Optional certificate alias>
...
The quickstart.keystore is a standard java keystore in JKS format generated by Java keytool.
The following example demonstrates generating the quickstart.keystore using preexisting private key, a server certificate and a CA chain file.
$ sudo openssl pkcs12 -inkey ./www_example_com.key -in ./www_example_com.crt -certfile ./ca_chain_file.crt -export -out ./www_example_com.pkcs12 -passout pass:<KEYSTORE_PASSWORD>
$ $JAVA_HOME/bin/keytool -keystore ./quickstart.keystore -storepass <KEYSTORE_PASSWORD> -importkeystore -srckeystore ./www_example_com.pkcs12 -srcstoretype PKCS12 -srcstorepass <KEYSTORE_PASSWORD>
By default, the quickstart server separates session between different domains, so that a user that opens both http://www.example.com and http://intranet.example.com will have to log on to each of these sites. Technically, this is done by using different “session cookie domains” for the session cookie for each of these hosts.
Sometimes, it is desirable to share the session information between sites. To do that, configure the session cookie domain to be used by the server. It is important that this domain is the parent domain of the various hosts used, for example, to share the login session between http://www.example.com and http://intranett.example.com you must specify “example.com”; to share the login session between http://www.iknowbase.com and http://customers.iknowbase.com you must specify “iknowbase.com”.
Note also that specifying a sesision cookie domain means that a single quickstart server can only serve sites belonging to that domain. If you specify a session cookie domain of iknowbase.com means that the same server may no longer serve content from example.com. If you need this scenario, for example to serve http://www.example.com, http://intranett.example.com and http://www.iknowbase.com from the same iKnowBase repository, use two quickstart servers (one for *.example.com and one for *.iknowbase.com) listening at different ports, and use a proxy server (such as Varnish or Apache Traffic Server) to direct requests appropriately.
...
web.sessionCookieDomain=example.com
...
During normal execution, the quickstart server needs a directory for storing working files. This directory will be used for e.g. unpacking the web application war files, where each deployed application will get its own subdirectory under the work directory (such as “work/webapps/webIkbWebApp”). The default work directory is “./work” under the current directory, but this can be overridden in the quickstart property file:
...
iknowbase.workDirectory=/vol/workfiles/iknowbase/prod-server
...
Note that it is not recommended to use the operating system temporary directory (/tmp) for this purpose. For example, Linux installations typically runs the program “tmpwatch” every day, cleaning up the /tmp directory.
The quickstart programs writes logfiles during execution, both for command line and web usage. By default, the logfile is written in a subdirectory “logs” under the work directory (i.e. “./work/logs”), but you can override this in the property file:
...
iknowbase.logDirectory=/var/log/iknowbase
...
Max form size that can be submitted in iKnowBase Quickstart is by default set to 200 000 bytes. This is inteded to help in denial of service attack scenarios where malicious clients send huge amount of data. This limitation does NOT affect file uploads using
multipart/form-data.
If you need to POST forms larger than 200 000 bytes override the max value per web application in quickstart property file:
...
[webAppName].formContentSize=200000
# webIkbWebApp.formContentSize=200000
...
When accessing a database through a firewall or on an unreliable network, use the Oracle Net connection descriptor syntax with ENABLE=BROKEN instead of the standard JDBC URL syntax as the database connection string.
Default JDBC URL:
jdbc:oracle:thin:@//localhost:1521/ORCL
Using Oracle Net connection descriptor syntax:
jdbc:oracle:thin:@(DESCRIPTION = (ENABLE = BROKEN)(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = ORCL)(FAILOVER_MODE =(TYPE = SESSION)(METHOD = BASIC))))
See Setting max form size.
| Previous | Top | Next |
| Apache Solr Search Server | Installing on Oracle WebLogic Server |