Python UCS@school Kelvin REST API Client

Python 3.7+ GNU AGPL V3 license Code style: black Security: bandit Code coverage Documentation Status gh Code Linting gh Integration tests

Python library to interact with the UCS@school Kelvin REST API.


  • Asynchronous

  • Automatic handling of HTTP(S) sessions

  • Type annotations

  • ~95% test coverage (unittests + integration tests)

  • Python 3.7, 3.8, 3.9, 3.10


A list of UCS@school Kelvin REST API server versions which introduce breaking changes can be found in the UCS@school Kelvin REST API Documentation.


The Session context manager opens and closes a HTTP session:

>>> import asyncio
>>> from ucsschool.kelvin.client import Session, User, UserResource
>>> async def get_user(username: str) -> User:
...     async with Session(
...         "USERNAME",
...         "PASSWORD",
...         "master.ucs.local",
...         verify="ucs-root-ca.crt"
...     ) as session:
...         return await UserResource(session=session).get(name=username)
>>> obj ="demo_student"))
>>> print(obj)
User('name'='test_user', dn='uid=test_user,cn=schueler,cn=users,ou=DEMOSCHOOL,dc=example,dc=com')
>>> print(obj.firstname, obj.lastname)
Test User

There are more examples in the docs usage section.

For HTTPS to work, the SSL CA of the target system (UCS Master) must either be publicly signed, installed on the client system or available as file (as in the example above). If the SSL CA certificate is not available verify=False. Obviously that is not safe! The CA of any UCS server can always be downloaded from http://FQDN.OF.UCS/ucs-root-ca.crt.


Install UCS@school Kelvin REST API Client via pip from PyPI:

$ pip install kelvin-rest-api-client


Development internal tests

The Kelvin-client-daily-job, an integration test for the Kelvin client, is run and daily with the newest UCS. The job takes around 10 minutes to run and can be configured to run with a feature branch and a Kelvin Rest Api version of your choice. This is the recommended way to run the full integration test suite.

Local Tests

There are some isolated unittests, but most tests run against a real UCS@school Kelvin REST API. A UCS 4.4 Docker container has been prepared for this (additionally to the Kelvin API Docker container). The Makefile automates downloading and starting the Docker containers (3.2 GB GB) and running the tests. It is also possible to use an existing UCS DC Master with UCS@school and the Kelvin API installed.

Install the dependencies for testing in your python virtual environment:

$ pip install -r requirements_test.txt

The tests expect the existence of two schools (OUs) on the target system (the Kelvin API does not support creation of schools yet). The schools are DEMOSCHOOL and DEMOSCHOOL2. The first one usually already exists, but trying to create it again is safe. To create the schools run on the UCS DC Master:

$ /usr/share/ucs-school-import/scripts/create_ou DEMOSCHOOL
$ /usr/share/ucs-school-import/scripts/create_ou DEMOSCHOOL2

Furthermore an email domain must exist:

$ udm mail/domain create \
    --ignore_exists \
    --position "cn=domain,cn=mail,$(ucr get ldap/base)" \
    --set name="$(ucr get domainname)"

Since version 1.5.0 the Kelvin REST API supports UDM properties in all resources. A configuration is required for the tests for this feature:

$ cat > /etc/ucsschool/kelvin/mapped_udm_properties.json <<__EOF__
    "user": ["title"],
    "school_class": ["mailAddress"],
    "school": ["description"]

The provided UCS Docker containers already contain both OUs. They can be started using the Makefile:

$ make start-docker-containers

Downloading Docker image '..-ucsschool-udm-rest-api-only:stable-4.4-8'...
Downloading Docker image '../ucsschool-kelvin-rest-api:1.5.5'...
Starting UCS docker container...
Waiting for UCS docker container to start...
Waiting for IP address of UCS container...
Waiting for UDM REST API...........
Creating Kelvin REST API container...
Configuring Kelvin REST API container...
Rebuilding the OpenAPI client library in the Kelvin API Container...
Starting Kelvin REST API server...
Waiting for Kelvin docker container to start...
Waiting for IP address of Kelvin container...
Waiting for Kelvin API...
Fixing log file permissions...
Setting up reverse proxy...
==> UDM REST API log file: /tmp/udm-rest-api-log/directory-manager-rest.log
==> Kelvin API configs: /tmp/kelvin-api/configs/
==> Kelvin API hooks: /tmp/kelvin-api/kelvin-hooks/
==> Kelvin API log file: /tmp/kelvin-api/log/http.log
==> Kelvin API:
==> Kelvin API:

The Docker containers can be stopped and removed by running:

$ make stop-and-remove-docker-containers

The Docker images will not be removed, only the running containers.

Run tests with current Python interpreter:

$ make test

Using tox the tests can be executed with all supported Python versions:

$ make test-all

To use an existing UCS server for the tests, copy the file tests/test_server_example.yaml to tests/test_server.yaml and adapt the settings before starting the tests:

$ cp tests/test_server_example.yaml tests/test_server.yaml
$ $EDITOR tests/test_server.yaml
# check settings with a single test:
$ python -m pytest tests/
# if OK, run all tests:
$ make test


Standard logging is used for tracking the libraries activity. To capture the log messages for this project, subscribe to a logger named ucsschool.kelvin.client. Attention: Passwords and session tokens will be logged at log level DEBUG!

The UCS@school Kelvin REST API on the UCS server logs into the file /var/log/univention/ucsschool-kelvin-rest-api/http.log. The UDM REST API on the UCS server logs into the file /var/log/univention/directory-manager-rest.log.


- [ ] Check and update contents of [HISTORY.rst](./HISTORY.rst>)
- [ ] Check and update contents of [VERSION.txt](./VERSION.txt>)
- [ ] Kelvin client [Jenkins test](>) OK
- [ ] Tag commit in gitlab
- [ ] Run `make dist`
- [ ] Run `make docs`
- [ ] Run `make release-test` and verify the installation
- [ ] Run `make release` and verify the installation
- [ ] Verify packages on
- [ ] Release mail & chat announcement

Repo permissions

  • Github: @dansan and @JuergenBS

  • Gitlab: @JuergenBS

  • PyPI: @dansan and @SamuelYaron

  • RTD: @dansan and @SamuelYaron