Deprecated. This material represents early efforts and may be of interest to historians. It doe not describe current VIVO efforts.
Deprecated. This material represents early efforts and may be of interest to historians. It doe not describe current VIVO efforts.
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.
Before beginning the installation, let's look at the four locations on your computer that will hold VIVO.
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.
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).
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.
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.
When you have VIVO up and running, please read the Site Administrator's Guide.
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.
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.
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 value | NONE |
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 value | NONE |
Example value | http://vivo.mydomain.edu/ns#networkId |
Finally, you will need to provide text for the Login 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 ShibbolethThe 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
TBD
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.maxActive | 40 |
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.maxIdle | 10 |
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.dbtype | MySQL |
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.driver | com.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.validationQuery | SELECT 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 |
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.
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.addToBuild | es_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.languageFilter | false |
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.forceLocale | en_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.selectableLocales | en, es, fr_FR |