Configuring

Now that is installed, it’s a good moment to look into its run-time configuration options. All configuration can be done through a configuration file, for which an example is available at .

Essential options

Configuring the Database

The d͡jehuty program stores its state in a SPARQL 1.1 compliant RDF store. Configuring the connection details is done in the r͡df-store node.

Audit trails and database reconstruction

The d͡jehuty program can keep an audit log of all database modifications made by itself from which a database state can be reconstructed. Whether d͡jehuty keeps such an audit log can be configured with the following option:

Reconstructing the database from the query audit log

Each query that modifies the database state while the query audit logs are enabled can be extracted from the query audit log using the -͡-extract-transactions-from-log command-line option. A timestamp to specify the starting point to extract from can be specified as an argument. The following example displays its use:

djehuty web --config-file=config.xml --extract-transactions-from-log="YYYY-MM-DD HH:MM:SS"

This will create a file for each query in the folder specified in the t͡ransactions-directory attribute.

To replay the extracted transactions, use the a͡pply-transactions command-line option:

djehuty web --config-file=config.xml --apply-transactions

When a query cannot be executed, the command stops, allowing to fix or remove the query to-be-replayed. Invoking the -͡-apply-transactions command a second time will continue replaying where the previous run stopped.

Configuring storage

Storage locations can be configured with the s͡torage node. When configuring multiple locations, d͡jehuty attempts to find a file by looking at the first configured location, and in case it cannot find the file there, it will look at the second configured location, and so on, until it has tried each storage location.

This allows for moving files between storage systems transparently without requiring specific interactions with d͡jehuty other than having the files made available as a POSIX filesystem.

One use-case that suits this mechanism is letting uploads write to fast online storage and later move the uploaded files to a slower but less costly storage.

Configuring an identity provider

Ideally, d͡jehuty makes use of an external identity provider. d͡jehuty can use SAML2.0, ORCID, or an internal identity provider (for testing and development purposes only).

This section will outline the configuration options for each identity provision mechanism.

SAML2.0

For SAML 2.0, the configuration can be placed in the s͡aml section under a͡uthentication. That looks as following:

<authentication>
  <saml version="2.0">
    <!-- Configuration goes here. -->
  </saml>
</authentication>

The options outlined in the remainder of this section should be placed where the example shows .

The a͡ttributes configuration

To create account and author records and to authenticate a user, d͡jehuty stores information provided by the identity provider. Each identity provider may provide this information using different attributes. Therefore, the translation from attributes used by d͡jehuty and attributes given by the identity provider can be configured. The following attributes must be configured.

As an example, the attributes configuration for SURFConext looks like this:

<attributes>
  <first-name>urn:mace:dir:attribute-def:givenName</first-name>
  <last-name>urn:mace:dir:attribute-def:sn</last-name>
  <common-name>urn:mace:dir:attribute-def:cn</common-name>
  <email>urn:mace:dir:attribute-def:mail</email>
</attributes>

And for SURF Research Access Management (SRAM), the attributes configuration looks like this:

<attributes>
  <first-name>urn:oid:2.5.4.42</first-name>
  <last-name>urn:oid:2.5.4.4</last-name>
  <common-name>urn:oid:2.5.4.3</common-name>
  <email>urn:oid:0.9.2342.19200300.100.1.3</email>
  <groups>urn:oid:1.3.6.1.4.1.5923.1.1.1.7</groups>
  <group-prefix>urn:mace:surf.nl:sram:group:[organisation]:[service]</group-prefix>
</attributes>

The s͡ram configuration

When using SURF Research Access Management (SRAM), d͡jehuty can persuade SRAM to send an invitation to anyone inside or outside the institution to join the SRAM collaboration that provides access to the d͡jehuty instance. To do so, the following attributes must be configured.

The s͡ervice-provider configuration

ORCID

ORCID.org plays a key role in making researchers findable. Its identity provider service can be used by d͡jehuty in two ways:

1. As primary identity provider to log in and deposit data;

2. As additional identity provider to couple an author record to its ORCID record.

When another identity provider is configured in addition to ORCID, that identity provider will be used as primary and ORCID will only be used to couple author records to the author’s ORCID record.

To configure ORCID, the configuration can be placed in the o͡rcid section under a͡uthentication. That looks as following:

<authentication>
  <orcid>
    <!-- Configuration goes here. -->
  </orcid>
</authentication>

Then the following parameters can be configured:

Configuring an e-mail server

On various occassions, d͡jehuty will attempt to send an e-mail to either an author, a reviewer or an administrator. To be able to do so, an e-mail server must be configured from which the instance may send e-mails.

The configuration is done under the e͡mail node, and the following items can be configured:

Configuring DOI registration

When publishing a dataset or collection, d͡jehuty can register a persistent identifier with DataCite. To enable this feature, configure it under the d͡atacite node. The following parameters can be configured:

Configuring Handle registration

Each uploaded file can be assigned a persistent identifier using the Handle system. To enable this feature, configure it under the h͡andle node. The following parameters can be configured:

Configuring IIIF support

When publishing images, d͡jehuty can enable the IIIF Image API for the images. It uses l͡ibvips and p͡yvips under the hood to perform image manipulation. The following parameters can be configured:

Customizing looks

With the following options, the instance can be branded as necessary.

Customizing colors

The following options can be configured in the c͡olors section.

Configuring privileged users

By default an authenticated user may deposit data. But users can have additional roles; for example: a dataset reviewer, a technical administrator or a quota reviewer.

Such additional roles are configured in terms of privileges. The following privileges can be configured in the p͡rivileges section:

To enable a privilege for an account, set the value of the desired privilege to 1͡. Privileges are disabled by default, except for m͡ay-receive-email-notifications which defaults to 1͡.

<privileges>
    <account email="you@example.com" orcid="0000-0000-0000-0001">
      <may-administer>1</may-administer>
      <may-run-sparql-queries>1</may-run-sparql-queries>
      <may-impersonate>1</may-impersonate>
      <may-review>0</may-review>
      <may-review-quotas>0</may-review-quotas>
      <may-review-integrity>0</may-review-integrity>
      <may-process-feedback>0</may-process-feedback>
      <may-receive-email-notifications>1</may-receive-email-notifications>
    </account>
  </privileges>