|
» Forgot Password? About
» What is hipergate» Functional Modules » Benefits » Architecture Demo
» Screenshots» Demo Documentation
» Install» Manuals » API Reference » Case Studies Support
» Forums» Development Weblog » SourceForge Tracker » Commercial Support Downloads
» License» Downloads Partners
» Become a Partner» Find a Partner Private Area» Authors |
Installation ManualHow to upgrade from v1.1 to v2.0Step by Step Guide for Windows and Microsoft SQL Server 2000 by Malik Khan Introduction
You can get a more printer-friendly version of this page getting the HTML source. For the impatient...
Planning your installationIn order to get a working copy of hipergate you should install some JSP pages, put included .jar files in a proper location, customize the main configuration file (hipergate.cnf) and load the backend database. The most complex part in this installation process is related with the required third party libraries. You should pay special attention on this libraries and its version numbers. hipergate requires Java 1.4, a servlet/JSP engine (Tomcat, Sun Web Server, WebSphere, etc), and the following libraries:
You should plan the location of the following files prior to install:
/storage and /web directories can grow indefinitely with the use of hipergate. Main differences between /storage and /web are than /storage doesn't need to be available through HTTP, as /web require. Both are visible through HTTP in the default installation process. Required components
You can run hipergate with a non-priviledged user account. Contents of hipergate packageEach new release of hipergate is distributed in two diferent packages (also known as "flavours"): full and src.
hipergate releases are distributed in a ZIP compressed package with the following contents:
This diagram shows the contents of the web and storage direcotories:
web directory contents
storage directory contents
Install and configure a sample web sitePlacing your JSP files is the first task to be done in the installation process. A working servlet/JSP engine must be available, and you should take note of configuration parameters and URLs where you place JSP pages, as they are needed in step 3. Installing on Tomcat 4x/5xYou can install a copy of Apache Tomcat in /opt/tomcat/, and make it listen HTTP requests on port 8080 (default configuration). Check the following line in your $CATALINA_HOME/conf/server.xml file: <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" ... /> You can create a new <Context> for hipergate or use an existing one. For example, you can move the web from hipergate's ZIP package to $CATALINA_HOME/webapps/hipergate and create a new <Context> in server.xml as follows:
<Server port="8005" shutdown="SHUTDOWN" debug="0">
<Service name="Tomcat-Standalone">
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="100" debug="0" connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />
<Host name="localhost" debug="0" appBase="$CATALINA_HOME/webapps/hipergate"
unpackWARs="true" autoDeploy="true">
<Context path="" docBase="" debug="0"
reloadable="true" crossContext="true">
<Logger className="org.apache.catalina.logger.FileLogger"
prefix="hipergate_log." suffix=".txt" timestamp="true"/>
</Context>
</Host>
</Engine>
</Service>
</Server>
Unicode file encoding
hipergate JSP files use UFT-8 encoding. It is neccessary to instruct Tomcat to expect Unicode source files by setting the -Dfile.encoding=UTF-8 parameter on CATALINA_OPTS environment variable. If file.encoding parameter is not set you may encounter an error like org.apache.jasper.compiler.CompileException: /common/desktop.jsp Cannot read file: ze file upon application startup. Servletshipergate includes three servlets used to download files from the storage directory. directory. To retrieve file descriptors from the database you should configure the following parameters in web/WEB-INF/web.xml file. For each servlet (HttpBinaryServlet, HttpBLOBServlet and HttpQueryServlet) you should include the follogin parameters:
Database connection parameters for servlets from package com.knowgate.http (HttpBinaryServlet, HttpBLOBServlet and HttpQueryServlet) may be set at /WEB-INF/web.xml file or at /etc/hipergate.cnf. Information from web.xml will be prioritaire over hipergate.cnf so if both are different web.xmlwill be used. web.xml parameters may be left empty if only one instance of the application is running on the same server, but it is neccesary to fill them if several instances are running on the same server against different databases. If no connection parameters are found on web.xml the servlet will take those from hipergate.cnf, and not from other properties files such as real.cnf or portal.cnf. Last, check that http://hostname:8080/login.html works propertly. Installing librariesNext you should install hipergate and all required libraries in a directory where the servlet/JSP engine can find them. Usually, add them to CLASSPATH is not enought, as some servers use they own directory structure and class loaders to find JAR files. You can place all JAR files in WEBROOT/WEB-INF/lib ($CATALINA_HOME/webapps/hipergate/WEB-INF/lib), if you are using the same libraries in different contexts you should place them in a common place (like $CATALINA_HOME/shared/lib). Take special attention to JDBC database drivers. hipergate comes with postgreSQL (postgresql.jdbc3-YYYYMMDD.jar), drivers, but you can use any of supported database engines. Configuring hipergateAll parameters for hipergate are configured using two files: hipergate.cnf and appserver.cnf. Last one is only used when you setup hipergate in 3 tier mode. This files must reside in /etc directory, but hipergate will search for them in the directory specified in the KNOWGATE_PROFILES environment variable. You should pass this environment/shell variable to your servlet engine. hipergate.cnf file contains the following parameters (WARNING, $CATALINA_HOME variables are not valid in this file, they are only place here for explaination purpouses): # [Database] # Database Parameters driver=org.postgresql.Driver dburl=jdbc:postgresql://192.168.1.30:5432/test schema= dbuser=postgres dbpassword=postgres # [Files] # Where to store temporal files temp=/tmp # How hipergate reads and writes files and directories # File/Directory access mode (PUREJAVA=0, UNIX=1, WINDOWS = 2) javamode=0 # Root URL to hipergate webserver=http://hostname:8080 # optional Root to static images imageserver=http://hostname:8080/images # Protocol, hostname, username and password to access workareas and storage fileprotocol=file:// fileserver=localhost fileuser= filepassword= # Private storage directory storage=$CATALINA_HOME/webapps/storage # External shell commands to perform shelldir=/tmp # Public storage directory workareasput=$CATALINA_HOME/webapps/hipergate/workareas # Public storage URL workareasget=http://hostname:8080/workareas # Maximum file size (bytes) maxfileupload=10485760 # [Misc] # Validate XML documents? setXMLValidation=1 # Task scheduler maximum running threads maxschedulerthreads=1 # SMTP mail configuration mail.transport.protocol=smtp mail.host=localhost mail.user=
Create and load databasePre-requisitesThere are some initial requirement for each database in order to load hipergate:
Creating the database by loading binary dumpsInstead of ModelManager, you can also use the binary database dumps provided with the hipergate package inside the database/ directory.
Creating the database with ModelManager Java class SQL-DDL scriptsTo install the initial database using ModelManager Java class first check JDCB connectivity parameters in the hipergate.cnf file. Database chosen with the dburl parameter must be created prior to installation. Database creation process will use the DBURL, username and password parameters from hipergate.cnf file. Use the following command to load the default database objects (case sensitive): java com.knowgate.hipergate.datamodel.ModelManager /etc/hipergate.cnf create database
WARNING: all required libraries must be available on your CLASSPATH. #!/bin/sh cp=`ls -1 /opt/tomcat/webapps/hipergate/WEB-INF/lib/*.jar | tr '\n' ':'` java -cp "$cp" com.knowgate.hipergate.datamodel.ModelManager $@ You can save this script at /usr/local/bin/modelmanager.sh and run modelmanager.sh create database. Connection test and first loginOnce database is loaded, check the following URL: http://myserver/admin/test_connect.jsp. If everything is OK you'll see a screen with the JDBC connection URL. Login to hipergate with the following URL: http://myserver/login.html. When you load the database some example users are created. hipergate creates two default domains with 5 users that must be kept, althought it is recommended to change their default passwords.
Aditionaly, create database process generates three test domains with some users that can be used inmediately. Each domain (test, demo and real) can be used when testing some features of the application.
Configuring Security and WorkAreasFor creating new Domains, Users and WorkAreas read to the User Manual. Configuring Distributed cache for Web FarmsIntroductionThis configuration step is neccesary if and only if you have more than one web server running in parallel. When the application runs on several machines in parallel, it is neccesary to enable the Distributed Cache Coordinator. Each web server mantains a local cache of frecuently used information such as user passwords, lookups, menu options, etc. If more than one server provides service, it exists the possibility that one server updates information on the database that is localy cached on another server. This is why it is neccesary to install a Cache Coordinator. The coordinator itself does not store any actual information, but only acts as a ticket server for clients. It is not possible to pass information among client caches, if one of them modifies information on the database, that information become invalid on all othre nodes and has to be re-loaded from the database. The cache coordinator is divided in two parts: client and server. Client part is package com.knowgate.cache at hipergate.jar. This cliente is independent of the server side. Server Side may be either of one of two types: HTTP based or EJB based. An HTTP coordinator uses one Web Server for coordinating all the other ones. This is the simplest configuration. An EJB coordinator uses an application server (such as JBoss or WebLogic) as a ticket server for client web servers. Configuring coordinator over HTTPAny node of a web farm can act as coordinator of all the other ones. There may be only one coordinator, if this machine fails, all the other will stop working. For enabling an HTTP coordinator, open appserver.cnf on echa nodo and set properties: threetiers=enabled java.naming.provider.url=http://IP_ADDRESS:PORT/cache/server.jsp Configuring coordinator over an EJB containerInstalling the coordinator on an EJB container y more complex but it gives better performance, scalability and fault tolerance. Client Side (Web Servers)If you use JBoss 3.0, additional libraries must be installed on each web server:
Server Side (JBoss)Add the following to the standardjboss.xml file: <container-configuration> <container-name>Singleton Stateless SessionBean</container-name> <call-logging>false</call-logging> <container-invoker>org.jboss.proxy.ejb.ProxyFactory</container-invoker> <container-interceptors> <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor> <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor> <!-- BMT --> <interceptor transaction = "Bean"> org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor </interceptor> <interceptor transaction = "Bean"> org.jboss.ejb.plugins.TxInterceptorBMT </interceptor> <interceptor transaction = "Bean" metricsEnabled = "true"> org.jboss.ejb.plugins.MetricsInterceptor </interceptor> <interceptor> org.jboss.resource.connectionmanager.CachedConnectionInterceptor </interceptor> </container-interceptors> <client-interceptors> <home> <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor> <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> </home> <bean> <interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor> <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor> <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor> <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor> </bean> </client-interceptors> <instance-pool>org.jboss.ejb.plugins.StatelessSessionInstancePool</instance-pool> <instance-cache/> <persistence-manager/> <transaction-manager/> <container-pool-conf> <MaximumSize>1</MaximumSize> <MinimumSize>1</MinimumSize> <strictMaximumSize>true</strictMaximumSize> </container-pool-conf> </container-configuration> Start JBoss and deploy cachecoordinator-jboss30.jar. To do so:
Known IncompatibilitiesVersion 1.x
Version 2.x
Additional DownloadsUpgrading from v1.1 to v2.0For upgrading your hipergate installation from v1.1 to v2.0 follow these steps :
Copying DataIt is not possible to upgrade from v1.1 to v2.0 without doing a copy of the database since v1.1 works with ISO-8859-1 characters set and v2.0 works with Unicode.The upgrade process does not modify the previous version in any way, it copies all the data from the old version to the new one. PermissionsEnsure that the user of the new database have enought priviledges for enabling and disabling FOREIGN KEY CONSTRAINTS at the target datamodel.For PostgreSQL you will have to do ALTER USER hgdbuser CREATEUSER witch will make hgdbuser a superuser. Just doing GRANT ALL ON DATABASE hipergate2 TO hgdbuser or GRANT ALL ON pg_class TO hgdbuser is not enought. For Oracle do GRANT CREATE TABLE TO HIPERGATE. For SQL Server add your user to one of the fixed database roles db_owner or db_ddladmin. |
| Problems with this page?, email webmaster@hipergate.org |
| index.cgi | hipergate © 2003-2006 KnowGate. All rights reserved [Legal] [Contact] [Valid HTML 4.01] [Valid CSS!] | index.cgi |