Deprecated. This material represents early efforts and may be of interest to historians. It doe not describe current VIVO efforts.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »

This document applies to VIVO release 1.6. For documents that apply to other releases, please consult the Documentation Archive page.

Introduction

This document is a summary of the VIVO installation process. For information about this release, consult the VIVO 1.6 Release Announcement. Links to this and other documentation can be found on the support page at VIVOweb.org.

These instructions assume that you are performing a clean install, including emptying an existing database, emptying the VIVO home directory, and removing a previous installation from the Tomcat webapps directory. VIVO may not work as expected if you install over an an earlier version. If you are upgrading an existing service, please consult the Upgrade Instructions for VIVO release 1.6.

The section entitled A simple installation describes a standard, simple installation for those who want to get VIVO up and running. The second called Installation options section describes several choices; some are intended for a full-scale production installation of VIVO, and some are intended for a person who is developing VIVO on their own machine.

Where is VIVO on your computer?

Before beginning the installation, let's look at the four locations on your computer that will hold VIVO.

The VIVO distribution directory

This is created when you unpack the VIVO distribution file (see Download the VIVO source code, below). This is where you will create your build.properties file (see Specify build properties, below), and where you will make any modifications to the VIVO theme or code. You can create this wherever you choose.

VIVO inside Tomcat

When you run the build script to compile and deploy VIVO (see Compile and deploy, below), the files will be deployed to a directory inside Tomcat. This is the actual executing code for VIVO, but you won’t need to look at it or change it. If you need to change VIVO, make the changes in the distribution directory, and run the build script again. Tell the build script where to find Tomcat by setting tomcat.home in the build.properties file (see Specify build properties, below).

The VIVO home directory

This directory contains the runtime configuration properties for VIVO. VIVO will also use this area to store some of its data. Uploaded image files are stored here, and the Solr search index is stored here also. This is also a place for the files or RDF data that will initialize the VIVO knowledge base. You can create this wherever you choose. Tell VIVO where to find the home directory by setting vitro.home in the build.properties file (see Specify build properties, below). You must create this directory before starting VIVO. You must create the runtime.properties file in this directory (see Specify runtime properties, below), and you must ensure that Tomcat has permission to read and write to this directory when it runs.

The VIVO knowledge base

By default, nearly all of the data that you enter into VIVO will be stored in MySQL. The actual location of this data depends on what system you have, and on how you install MySQL (see Install required software, below). but you won’t need to know the location. You will access the data through VIVO, or occasionally through the MySQL client application.

Depending on your Installation options, these directories may have different locations, or may be specified in different ways. They may even exist on different computers. Regardless of the options, these four locations are important for any installation of VIVO.

First the installation, then what?

When you have VIVO up and running, please read the Site Administrator's Guide.

Installation options

TBD

Using an external authentication system

VIVO can be configured to work with an external authentication system like Shibboleth or CUWebAuth.

VIVO must be accessible only through an Apache HTTP server. The Apache server will be configured to invoke the external authentication system. When the user completes the authentication, the Apache server will pass a network ID to VIVO, to identify the user.

If VIVO has an account for that user, the user will be logged in with the privileges of that account. In the absence of an account, VIVO will try to find a page associated with the user. If such a page is found, the user can log in to edit his own profile information.

Configuring the Apache server

Your institution will provide you with instructions for setting up the external authentication system. The Apache server must be configured to secure a page in VIVO. When a user reaches this secured page, the Apache server will invoke the external authentication system.

For VIVO, this secured page is named: /loginExternalAuthReturn

When your instructions call for the location of the secured page, this is the value you should use.

Configuring VIVO

To enable external authentication, VIVO requires two values in the runtime.properties file.

Property name
externalAuth.netIdHeaderName
Description

 

The name of the HTTP header that will hold the external user's network ID.

When a user completes the authentication process, the Apache server will put the user's network ID into one of the headers of the HTTP request. The instructions from your institution should tell you which header is used for this purpose.

 

Default valueNONE
Example value
remote_userID
Property name
selfEditing.idMatchingProperty
Description
Associating a User with a profile page.

VIVO will try to associate the user with a profile page, so the user may edit his own profile data. VIVO will search the data model for a person with a property that matches the User’s network ID (the value of the property must be either a String literal or an untyped literal). You need to tell VIVO what property should be used for matching.

This property is also mentioned in the insructions for A simple installation, because it can also be useful for sites that do not use external authentication.

Default valueNONE
Example valuehttp://vivo.mydomain.edu/ns#networkId

 

Finally, you will need to provide text for the Login button.

  • To start the authentication process, the user will click on a button in the VIVO login form. You need to tell VIVO what text should appear in that button.

    In your theme, add a line to the all.properties file, like this one:

    external_login_text = [the text for your login button]
    For example:
    external_login_text = Log in using BearCat Shibboleth
    The VIVO login form will display a button labelled "Log in using BearCat Shibboleth".

    If your site supports additional languages, add lines to the corresponding files. For example, all_es.properties might contain this line:

    external_login_text = Entrar usando Shibboleth GatoOso

Developers' installation: obtaining VIVO source code from Git

TBD

Customizing VIVO with a "3-tier" build

TBD

Using a database other than MySQL

TBD

Optional external triple store

VIVO can configured to use a different triple store for the bulk of its semantic data, so long as this triple store supports Web-based use of the SPARQL language to query and modify its data. If you elect to use a separate triple store, note that VIVO's MySQL database is still required for basic configuration and user account data. In order to connect VIVO to an external triple store, you will need to know two URIs: the store's endpoint URI for issuing SPARQL queries that read data, and its URI for issuing SPARQL UPDATE commands. These URIs are typically kept separate in order to make it easier to secure the triple store against unauthorized edits. With Sesame, for example, the update URI is usually the query endpoint URI with "/statements" appended. You will need to know these two URIs later when you specify runtime properties.

Specify the maximum number of active connections in the database connection pool to support the anticipated number of concurrent page requests. It is not necessary to adjust this value when using the RDB configuration.
VitroConnection.DataSource.pool.maxActive40
Specify the maximum number of database connections that will be allowed to remain idle in the connection pool. Default is 25% of the maximum number of active connections.
VitroConnection.DataSource.pool.maxIdle10
Change the dbtype setting to use a database other than MySQL. Otherwise, leave this value unchanged. Possible values are DB2, derby, HSQLDB, H2, MySQL, Oracle, PostgreSQL, and SQLServer. Refer to http://openjena.org/wiki/SDB/Databases_Supported for additional information.
VitroConnection.DataSource.dbtypeMySQL
Specify a driver class name to use a database other than MySQL. Otherwise, leave this value unchanged. This JAR file for this driver must be added to the the webapp/lib directory within the vitro.core.dir specified above.
VitroConnection.DataSource.drivercom.mysql.jdbc.Driver
Change the validation query used to test database connections only if necessary to use a database other than MySQL. Otherwise, leave this value unchanged.
VitroConnection.DataSource.validationQuerySELECT 1
Set the endpointURI only if you wish to store semantic data in an external triple store instead of MySQL. Enter the URI of the triple store's SPARQL endpoint for querying data.
VitroConnection.DataSource.endpointURI
Set the updateEndpointURI only if you wish to store semantic data in an external triple store instead of MySQL. Enter the URI at which the triple store responds to SPARQL UPDATE requests. This setting is only necessary if the triple store does not support updates via its main URI. If the endpointURI above is not set, this setting has no effect.
VitroConnection.DataSource.updateEndpointURI

Adding OpenSocial gadgets to VIVO

TBD
These values are used when deploying VIVO as an OpenSocial container and integrating with OpenSocial gadgets (see Step 13, below). If you are creating a VIVO installation that does not use OpenSocial gadgets, these values are omitted.
OpenSocial.shindigURL
OpenSocial.tokenService
OpenSocial.tokenKeyFile
OpenSocial.sandbox
 

VIVO now supports an extension of the OpenSocial API, known as Open Research Networking Gadgets, or ORNG (pronounced "ORNG") (see http://www.opengadgets.org/index.html).

Configuring VIVO to support ORNG requires several steps, including additions to the VIVO properties, modifications to Tomcat, creating a security key for safe network operations, and running a build script.

For instructions, consult the file setting_up_orng.html in this directory.

VIVO in a language other than English

TBD
Languages (in addition to American English) that will be built into your VIVO site. The languages must be found in the languages directory of the VIVO distribution. See the VIVO Wiki for more information.
languages.addToBuildes_MX
Show only the most appropriate data values based on the Accept-Language header supplied by the browser. Default is false if not set.
RDFService.languageFilterfalse
Force VIVO to use a specific language or Locale instead of those specified by the browser. This affects RDF data retrieved from the model, if RDFService.languageFilter is true. This also affects the text of pages that have been modified to support multiple languages.
languages.forceLocaleen_US
A list of supported languages or Locales that the user may choose to use instead of the one specified by the browser. Selection images must be available in the i18n/images directory of the theme. This affects RDF data retrieved from the model, if RDFService.languageFilter is true. This also affects the text of pages that have been modified to support multiple languages.
languages.selectableLocalesen, es, fr_FR

 

Other installation options

TBD

 

 

  • No labels