Introduction to the TeamDrive Web Portal

TeamDrive Web Portal Overview

The TeamDrive Web Portal consists of a number of components.

Firstly, the TeamDrive Web browser interface (ie. the TeamDrive Client interface that runs in a browser) is served by Apache.

The TeamDrive Web Portal Administration Console and the Web Portal authentication API is served dynamically by the Yvva Apache module mod_yvva.

A list of Docker containers and other administrative information is stored in a Management MySQL Database called webportal. This database must be accessible by all components of the Web Portal.

In addition, a Docker-based environment runs the TeamDrive Agents which serve the TeamDrive browser interface. A TeamDrive Agent is a faceless TeamDrive Client which provides a HTTP-based Rest API for the purpose of accessing a TeamDrive user account.

Depending on the scale of an installation, all components: Apache, MySQL and Docker may run on one machine or on separate machines. Docker itself may run on a cluster of machine, however setting up such a configuration is not part of this documentation.

../_images/WebPortal-Overview.png

An overview of the Web Portal with connections to other TeamDrive components

In the illustration above, you see the Web Portal, which runs as an Apache module, and how it is connected to other components in the system.

Details of which systems settings affect which connections are indicated in the diagram, for example the connection to the Docker Host is established using the DockerHost system setting. Also illustrated is the optional use of an external Authentication Service (See Configuring Active Directory / LDAP Authentication Services for details).

TeamDrive Hosting Basics

Note

The system variables mentioned in this section are set using the Administration Console explained in Web Portal Settings.

A TeamDrive Web Portal requires a unique domain name. The domain name is basically the URL for the TeamDrive users that access the Web Portal. This domain name is stored in the WebPortalDomain system setting.

The same domain name is also used to access the Administration Console by adding /admin/ to the base URL:

https://webportal.yourdomain.com/admin/

Once the TeamDrive Web interface has been served, further calls from the browser will be redirected to the appropriate TeamDrive Agent running in a Docker container. In order to do this, an Apache rewrite rule is installed which allows Apache to act as a reverse proxy, forwarding calls to the TeamDrive Agent.

Docker Configuration

As mentioned above, the Docker system is responsible for running multiple TeamDrive Agent instances in containers. A container with a agent is created for each user session.

The users data is not stored in the container itself. Instead, the container mounts a directory in the host machines file system.

The root mount point for all containers is \teamdrive\ by default. This path is stored in the ContainerRoot system setting. The username of the user is added to this path to produce the mount point for each individual container. For example the user for user “td_user_1” is \teamdrive\td_user_1.

Under this directory, the TeamDrive agent stores the “meta data” (file names and directory structure) of the Spaces that have been entered, as well as a disk cache for any files in transit.

Docker itself also needs additional storage (stored on the overlay2 device mentioned later in this documentation) to run the cloned container for each user. This storage will be cleand up by the background task described in the next section.

Note

The Space data stored by the TeamDrive Agents is stored in unencrypted form. For this reason, security of the Docker host system is extremely important.

Background Tasks Performed by td-webportal

The td-webportal process is a service that executes background tasks scheduled by the Web Portal.

It uses the Yvva daemon yvvad to run the following background tasks at a definable regular interval:

  • Remove Idle Containers:

    The purpose of this task is to remove containers that are no longer being used.

    When a user session times out, the container running the associated TeamDrive Agent exits (stops executing). When this happens the container is not removed. It remains in the system and is simpley restarted when the user logs in again.

    This task removes containers that are unused for a certain amount of time (indicated by the RemoveIdleContainerTime). This period should be longer than the regular user session timeout.

    Containers that are removed are automatically recreated by the Web Portal when the user logs in again. The only difference is that login process takes a little bit longer because the container must be created and then started, instead of just being restarted if the container already exists.

  • Delete Container Storage:

    This task removes container data if a container is unused for a certain period of time (as specified by the ContainerStorageTimeout setting. The container data is the data stored under the ContainerRoot directory for a particular container, for example: the directory \teamdrive\td_user_1 for the user “td_user_1”.

    The purpose of the task is to free up unused disk space.

    If a user logs in again after the container data has been deleted the user will find that all of his Spaces have been set to “Inactive”. This means that he has to enter a Space again in order to access the data. Since this could inconvenient and time consuming the ContainerStorageTimeout should be set to a fairly large period, for example 1 month.

  • Remove Old Images:

    The purpose of this task is to remove containers so that the TeamDrive Agent version used by the Web Portal can be upgraded.

    The TeamDrive Agent running in a container is never updated “in place”. Instead, the Web Portal waits for a container to be removed, and then the new TeamDrive Agent version is used when a new container is created.

    This task specifically removes containers that are running an old TeamDrive Agent image. The current (and new) TeamDrive Agent image to be used is specified using the ContainerImage setting.

    There are a number of settings which control the behaviour of this task: RemoveOldImages, OldImageTimeout and OldImageRemovalTime.

    RemoveOldImages must be to True to enable this task. OldImageTimeout is the time, in seconds, that a container with an old image must be idle before it is removed. Zero means the container is removed, even if it is running. OldImageRemovalTime is used to specify when containers with old images should be removed. You can set it to “now”, to remove the containers immediately, if set to “never”, then containers are only removed if the OldImageTimeout is exceeded. This setting value can also be set to a time (e.g. 03:00, format: hh:mm), or a date (format YYYY-MM-DD hh:mm).