Configuration

RDepot is configured through static YAML files.

Notation

This page occasionally uses period separators to denote the hierarchy of nested blocks for brevity. Additionally, the two styles of array syntax are used interchangeably.

Manager App

It is recommended to create a configuration file to override the default values of the RDepot manager application.

This files should be added to the same folder from where the manager app is run.

You can find up-to-date configuration examples on the Deployment page or in the integration tests of RDepot.

Repositories

As an alternative to configuring repositories through the interface you can specify them in the configuration. This is especially useful for scripted deployments.

repositories:
  - name: A
    publication-uri: http://mydomain.com/repo/A
    server-address: http://oa-rdepot-repo:8080/A
    # published: true is the default
  - name: B
    publication-uri: http://mydomain.com/repo/B
    server-address: http://oa-rdepot-repo:8080/B
    published: true
  - name: C
    publication-uri: http://mydomain.com/repo/C
    server-address: http://oa-rdepot-repo:8080/C
    published: false

For each repository the following fields should be specified:

name: repository name
publication-uri: the external uri of the repository
server-address: the internal address which the manager app uses to communicate with the repo server.

Optionally, configure whether the repository should by default be published or not:

published: true if the repository should be automatically published (default) or false if it shouldn’t be published at all

External repository mirrors

Configuring external repository mirrors is not available in the interface (yet) and only works in tandem with the declarative repository configuration. This is especially useful in the case where the RDepot application is hosted on the only host in the network with internet access, where regular client machines don’t have any external internet access but require external packages from i.e. CRAN or Bioconductor.

repositories:
  - name: mirror-multiple
    publication-uri: http://mydomain.com/repo/mirror-multiple
    server-address: http://oa-rdepot-repo:8080/mirror-multiple
    mirrors:
      - name: CRAN
        uri: https://cran.r-project.org
        sync-interval: * * 5 * * *
        type: tarball
        generate-manuals: true
        packages:
          - name: ggplot2
            version: 3.3.2
          - name: plotly
            generate-manuals: false
      - name: Bioconductor-3.12
        uri: https://bioconductor.org/packages/3.12/bioc
        sync-interval: * * 5 * * *
        type: tarball
        generate-manuals: false
        packages:
          - name: annotate
            version: 1.68.0
            generate-manuals: true
      - name: Bioconductor-release
        uri: https://bioconductor.org/packages/release/bioc
        sync-interval: * * 5 * * *
        type: tarball
        packages:
          - name: genefilter

One can configure multiple mirror configurations per repository. The uri parameter needs to be a valid URI where appending src/contrib/PACKAGES to the end of the URI leads to the PACKAGES file of the external repository. The sync-interval is an extended CRON-like expression, see the Spring documentation for more information on the syntax. Currently type is restricted to tarball. We might support source packages and other types in the future.

There are currently two types of package mirroring supported:

mirror a specific version of a package (only once)
mirror the latest version of a package (using the sync-interval)

Database

It is recommended to use a PostgreSQL-compatible database. Other SQL flavours may work but have not been tested.

You can configure access to your database in a db block:

db.driver : the database driver. Since the recommendation is to use postgres, this should be kept at org.postgresql.Driver
db.url : JDBC connection url
db.username: username/role to connect with
db.password: password to connect with

Authentication

The RDepot manager application supports multiple authentication backends. You can select the authentication method to use via the app.authentication field.

Simple Authentication

Users can be defined directly in the configuration file. To do so, select the simple authentication method. You can then define the users under app.simple:

app:
  simple:
    users:
      - login: einstein
        password: testpassword
      - login: tesla
        password: testpassword
      - login: galileo
        password: testpassword
      - login: newton
        password: testpassword
      - login: newbie
        password: testpassword
        name: New User

LDAP Authentication

The following properties can be set:

app.ldap.url: the LDAP connection string
app.ldap.basedn: base DN (distinguished name)
app.ldap.userou: user OU (organizational unit)
app.ldap.loginfield: field to use for login
app.ldap.namefield: field to use for name
app.ldap.emailfield: field to use for email
app.ldap.default.admins: array of default admins. For example: [ "admin" , "einstein", "newton" ]

OpenID Connect (OIDC)

OpenID Connect is a modern authentication protocol based on the OAuth2 standard. OIDC supports multiple authentication flows. The standard authentication flow applicable for web apps is three-legged (auth provider, client/application and user) and is based around tokens. This removes the need to store passwords and enables a single-sign-on experience.

To configure OIDC in the RDepot manager application, the following properties can be set:

app.authentication: should be set to openid
app.openid.auth-url: the endpoint that will be used by the manager application to initiate the authentication flow. This is where users will be redirected when visting the app without a (valid) token.
app.openid.token-url: the endpoint where tokens can be retrieved or exchanged. This is used during the authentication process.
app.openid.jwks-url: the endpoint where the provider’s public certificates can be found. This is used during the authentication process.
app.openid.baseUrl: the application’s base URL, i.e. the URL an user uses to access RDepot.
app.openid-logout-url: the URL to be used for logging out of the OpenID session (i.e. the end_session_endpoint). This property is optional, but when specified the app.openid.baseUrl must be specified as well. This URL will automatically be url-encoded, hence it may not contain any url-encoding sequences.
app.openid.client-id: unique ID generated by the provider for your client/application
app.openid.client-secret: a secret generated by the provider for your client/application
app.openid.default.admins: array of default admins. For example: [ "admin" , "einstein", "newton" ]

The client id and secret are sensitive and should be treated as such.

Keycloak

Keycloak is an open source identity and access management system supported by Red Hat. Using keycloak as an authentication backend to the RDepot manager enables advanced features such as User Federation, Identity Brokering and Social Login.

Keycloak supports both OIDC and SAML, but in the context of the RDepot manager, which relies on the client adapter for Spring, only OIDC can be used.

Keycloak authentication can be configured as follows:

app.authentication: should be set to keycloak
app.keycloak.realm: Keycloak allows to divide the identity space into distinct reams. You can use this property to select the appropriate one.
app.keycloak.auth-server-url: the endpoint that will be used by the manager application to initiate the authentication flow.
app.keycloak.baseUrl: the base url of RDepot manager, essentially the site url.
app.keycloak.resource: client/application id
app.keycloak.credentials-secret: client/application secret
app.keycloak.ssl-required: SSL/HTTPS mode. One of none, all or external (default). Read more here.
app.keycloak.principal-attribute: the identity-defining attribute to use in the manager application.
app.keycloak.default.admins: array of default admins. For example: [ "admin" , "einstein", "newton" ]

General information on how to configure Keycloak can be found here, but should look similar to the following:

define a new client and set the access type to confidential
obtain a summary of the settings to configure the RDepot manager from the Installation tab

Logging

By default, information about various application events will be logged into the standard output stream of the process.

You can also send the log output to a file via the logging.file setting:

logging:
  file:
    rdepot.log

You can change the log level by using the logging.level.<component> setting, where <component> can be either of:

root: this affects all components
any specific component: e.g. org.springframework.web.filter.CommonsRequestLoggingFilter

A full discussion of all components is out-of-scope for this document.

Storage

storage.implementation: Currently only a single storage implementation is supported: local.
localStorage.maxRequest: Maximum request size
requestTimeout: Timeout for requests

Sensitive Configuration

You can override sensitive configuration with environment variables.

E.g. api-token.secret can be overridden with API_TOKEN_SECRET.

Refer to the spring boot documentation on externalized configuration to learn more.