7. Limitations#

To use the OX Connector reliably, read the following limitations. Each section identifies the deployments it applies to.

7.1. OX Connector integration with the OX App Suite app#

Deployment — Nubus for UCS

This section applies to the Nubus for UCS deployment.

Added in version 2.1.2.

Starting with version 2.1.2 of the OX Connector app, you can use the OX Connector with the OX App Suite app from Univention App Center. The OX Connector handles provisioning, while OX App Suite provides groupware.

For OX App Suite administrator credentials on separate UCS systems, see OX App Suite administrator.

7.2. How OX Connector handles faulty items#

Deployment — All: Nubus for UCS and Nubus for Kubernetes

This section applies to both deployments.

The OX Connector stores provisioning tasks in its database. It uses OX_CONNECTOR_STOP_ON_ERROR to select how it handles ordinary errors during provisioning.

In the Nubus for UCS deployment, the value defaults to true.

In the Nubus for Kubernetes deployment, the value defaults to false.

7.2.1. OX Connector continues after faulty items#

If OX_CONNECTOR_STOP_ON_ERROR is false and the OX Connector can’t process a faulty queue item, it moves the task to the error list and continues with the remaining queue items. The connector logs the problem.

The OX Connector app provides a command-line interface (CLI) to manage the error list. For more information, see Log files and Manage provisioning tasks.

Regardless of the setting, the OX Connector handles HTTP, connection, timeout, and OX context errors differently. It retains the task in the task list, increments its error count, and retries the task after a delay.

When you set OX_CONNECTOR_STOP_ON_ERROR to false, you must monitor the list of errors manually and decide whether to delete or retry a task. Meanwhile, the OX Connector continues to process data it receives from the Provisioning Service.

In the Nubus for Kubernetes deployment, the OX Connector moves tasks that fail with an ordinary error to the error list by default. The OX Connector then continues with the following tasks.

Network errors and errors while processing OX context objects remain in the task list. The consumer retries these tasks while outstanding tasks remain.

7.2.2. OX Connector stops at faulty items#

If OX_CONNECTOR_STOP_ON_ERROR is true and the OX Connector can’t process a faulty queue item, it retains the task in the task list. The connector logs the problematic task in the OX Connector Provisioning Consumer log file. For more information, see Log files.

The Provisioning Service continues to add items to the queue.

After an administrator removes the faulty queue item, the OX Connector Provisioning Consumer resumes processing the queue. It also processes items that the Provisioning Service adds.

As administrator, you need to resolve that conflict manually when it happens, see Resolve blocked provisioning. After the conflict resolution, the connector continues to process the provisioning queue.

In the Nubus for Kubernetes deployment, when you set OX_CONNECTOR_STOP_ON_ERROR to true, the OX Connector retains a task that fails with an ordinary error in the task list.

7.3. No validation of access profile rights#

Deployment — All: Nubus for UCS and Nubus for Kubernetes

This section applies to both deployments.

When an access profile changes, the OX Connector doesn’t check its rights against OX App Suite. It writes the recognized rights to the module-access definition file and applies them to users during provisioning. If a user references an unknown access profile, the connector leaves the user’s existing module-access rights unchanged.

For more information, see OX App Suite Permission Level.