Page History
...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
General Configuration
In the following sections you will learn about the different configuration files that you will need to edit so that you may make your DSpace installation work.
...
To get started, simply create your own [dspace-source]/dspace/config/local.cfg based on the example, e.g.
| Code Block | ||
|---|---|---|
| ||
cd [dspace-source]/dspace/config/ cp local.cfg.EXAMPLE local.cfg |
...
DSpace will look up a javax.mail.Session object in JNDI and, if found, will use that to send email. Otherwise it will create a Session using some of the properties detailed below.
Property: |
|
Example Value: |
|
Informational Note: | The address on which your outgoing SMTP email server can be reached. |
Property: |
|
Example Value: |
|
Informational Note: | SMTP mail server authentication username, if required. This property is optional. |
Property: |
|
Example Value: |
|
Informational Note: | SMTP mail server authentication password, if required. This property is optional |
. | |||
Property: |
| ||
Example Value: |
| ||
Informational Note: | The port on which your SMTP mail server can be reached. By default, port 25 is used, port 587 is commonly used for TLS connections. Change this setting if your SMTP mailserver is running on another port. This property is optional. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | The "From" address for email. Change the 'myu.edu' to the site's host name. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | When a user clicks on the feedback link/feature, the information will be sent to the email address of choice. This configuration is currently limited to only one recipient. Since DSpace 4.0, this is also the email address displayed on the contacts page. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | Email address of the general site administrator (Webmaster) | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | Enter the recipient for server errors and alerts. This property is optional. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | Enter the recipient that will be notified when a new user registers on DSpace. This property is optional. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | Set the default mail character set. This may be over-ridden by providing a line inside the email template 'charset: <encoding>', otherwise this default is used. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | A comma separated list of hostnames that are allowed to refer browsers to email forms. Default behavior is to accept referrals only from dspace.hostname. This property is optional. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | If you need to pass extra settings to the Java mail library. Comma separated, equals sign between the key and the value. This property is optional. | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | An option is added to disable the mailserver. By default, this property is set to ' | ||
Property: |
| ||
| Example Value: |
| ||
Informational Note: | Specifies the name of a javax.mail.Session object stored in JNDI under | ||
Property: |
| ||
Example Value: |
| ||
Informational Note: | If no other language is explicitly stated in the input-forms.xml, the default language will be attributed to the metadata values. |
Wording of E-mail Messages
...
- A line beginning with "#" is a comment and will not be included in the message.
- A line beginning with "Subject: " will set the
Subject:header of the message and will not be included in the body. - A line beginning with "Charset: " will set the character set in which the subject and single message bodypart are assumed to be encoded, will be used as the value of the
charsetparameter of theContent-Encodingheader for the message, and will not be included in the body. If the message has multiple bodyparts (i.e. attachments are included) then all are assumed to be encoded in US-ASCII and the "Charset: " line has no effect on them (but still affects the subject). A number enclosed in braces, such as
{2}, anywhere in a non-comment line, will be replaced with the corresponding parameter which was supplied to the message when the message formatter was called. Parameter numbers are 0-based. Refer to the comments in the template or to the code which uses it for the meaning of each parameter.
File Storage
| Info |
|---|
Beginning with DSpace 6, your file storage location (aka bitstore) is now defined in the |
Using an external mail server
If you want to use an external mail server setting the value of mail.server to the domain name is enough if authentication is not required. Most external SMTP mail servers will however require authentication for obvious reasons. To enable TLS encryption you will typically have to set the mail.server.port to the secure default 587 and for the mail.server.username and mail.server.password to be set. In addition you will need to enable TLS by setting the following extra properties:
| Code Block |
|---|
mail.extraproperties = mail.smtp.auth=true, \
mail.smtp.starttls.enable=true |
Note that as of January 2020 Microsoft has started to remove support for Transport Layer Security (TLS) versions 1.0 and 1.1 in Office 365 and Office 365 GCC (see more information here). This necessitates using TLS 1.2 then. Some users have reported being able to use the following configuration successfully (see discussion):
| Code Block |
|---|
mail.extraproperties = mail.smtp.socketFactory.port=587, \
mail.smtp.starttls.enable=true, \
mail.smtp.starttls.required=true, \
mail.smtp.ssl.protocols=TLSv1.2
|
File Storage
| Info |
|---|
Beginning with DSpace 6, your file storage location (aka bitstore) is now defined in the |
DSpace supports multiple options for storing your repository bitstreams (uploaded files). The DSpace supports multiple options for storing your repository bitstreams (uploaded files). The files are not stored in the database, instead they are provided via a configured "assetstore" or "bitstore".
...
| Code Block | ||
|---|---|---|
| ||
<bean class="org.dspace.app.itemmarking.ItemMarkingInfo" id="type1MarkingInfo">
<property name="classInfo" value="glyphicon glyphicon-picture"/>
<property name="tooltip" value="itemlist.mark.type1MarkingInfo"/>
</bean>
<bean class="org.dspace.app.itemmarking.ItemMarkingInfo" id="type2MarkingInfo">
<property name="imageName" value="image/type2.png-picture"/>
<property name="tooltip" value="itemlist.mark.type2MarkingInfotype1MarkingInfo"/>
</bean> |
Tooltip property contains the localized key to display.
Keep in mind that the Strategy that you may write can have its own logic on how to create the ItemMarkingInfo per item. The only requirement of the feature is to add in the Spring configuration file the initial beans one for each mark you have declared in the dspace.cfg file.
Styling:
The title for the column of each mark is titled based on the localized key “itemlist.mark_[value]”, so you just need to add the specific keys in the messages.propertied files.
Moreover, the following CSS styles are applied to the various aspects of the mark:
- mark_[value]_th: a style applied to the column header
- mark_[value]_tr: a style applied to the each row
Add these classes to the css file and apply any style you like (like centering the text or the image)
Recognizing Web Spiders (Bots, Crawlers, etc.)
DSpace can often recognize that a given access request comes from a web spider that is indexing your repository. These accesses can be flagged for separate treatment (perhaps exclusion) in usage statistics. This requires patterns to match against incoming requests. These patterns exist in files that you will find in config/spiders.
In the spiders directory itself, you will find a number of files provided by iplists.com. These files contain network address patterns which have been discovered to identify a number of known indexing services and other spiders. You can add your own files here if you wish to exclude more addresses that you know of. You will need to include your files' names in the list configured in config/modules/solr-statistics.cfg. The iplists.com-*.txt files can be updated using a tool provided by DSpace. See SOLR Statistics for details.
In the spiders directory you will also find two subdirectories. agents contains files filled with regular expressions, one per line. An incoming request's User-Agent header is tested with each expression found in any of these files until an expression matches. If there is a match, the request is marked as being from a spider, otherwise not. domains similarly contains files filled with regular expressions which are used to test the domain name from which the request comes. You may add your own files of regular expressions to either directory if you wish to test requests with patterns of your own devising.
webui.itemdisplay.label.restricted.bitstreams
Many configuration names/keys have changed!
If you are upgrading from an earlier version of DSpace, you will need to be aware that many configuration names/keys have changed. Because Apache Commons Configuration allows for auto-overriding of configurations, all configuration names/keys in different *.cfg files MUST be uniquely named (otherwise accidental, unintended overriding may occur).
In order to compensate for this, all modules/*.cfg files had their configurations renamed to be prepended with the module name. As a basic example, all the configuration settings within the modules/oai.cfg configuration now start with "oai.".
Additionally, while the local.cfg may look similar to the old build.properties, many of its configurations have slightly different names. So, simply copying your build.properties into a local.cfg will NOT work.
This means that DSpace 5.x (or below) configurations are NOT compatible with the Enhanced Configuration Scheme. While you obviously can use your old configurations as a reference, you will need to start with fresh copy of all configuration files, and reapply any necessary configuration changes (this has always been the recommended procedure). However, as you'll see in the next section, you'll likely want to do that anyways in order to take full advantage of the new local.cfg file.
<bean class="org.dspace.app.itemmarking.ItemMarkingInfo" id="type2MarkingInfo">
<property name="imageName" value="image/type2.png"/>
<property name="tooltip" value="itemlist.mark.type2MarkingInfo"/>
</bean> |
Tooltip property contains the localized key to display.
Keep in mind that the Strategy that you may write can have its own logic on how to create the ItemMarkingInfo per item. The only requirement of the feature is to add in the Spring configuration file the initial beans one for each mark you have declared in the dspace.cfg file.
Styling:
The title for the column of each mark is titled based on the localized key “itemlist.mark_[value]”, so you just need to add the specific keys in the messages.propertied files.
Moreover, the following CSS styles are applied to the various aspects of the mark:
- mark_[value]_th: a style applied to the column header
- mark_[value]_tr: a style applied to the each row
Add these classes to the css file and apply any style you like (like centering the text or the image)
Recognizing Web Spiders (Bots, Crawlers, etc.)
DSpace can often recognize that a given access request comes from a web spider that is indexing your repository. These accesses can be flagged for separate treatment (perhaps exclusion) in usage statistics. This requires patterns to match against incoming requests. These patterns exist in files that you will find in config/spiders.
In the spiders directory itself, you will find a number of files provided by iplists.com. These files contain network address patterns which have been discovered to identify a number of known indexing services and other spiders. You can add your own files here if you wish to exclude more addresses that you know of. You will need to include your files' names in the list configured in config/modules/solr-statistics.cfg. The iplists.com-*.txt files can be updated using a tool provided by DSpace. See SOLR Statistics for details.
In the spiders directory you will also find two subdirectories. agents contains files filled with regular expressions, one per line. An incoming request's User-Agent header is tested with each expression found in any of these files until an expression matches. If there is a match, the request is marked as being from a spider, otherwise not. domains similarly contains files filled with regular expressions which are used to test the domain name from which the request comes. You may add your own files of regular expressions to either directory if you wish to test requests with patterns of your own devising.[dspace]/config/config-definition.xml
Command-line Access to Configuration Properties
...
Overview
Content Tools