Difference between revisions of "App Center/Dev/Integration with UCS"

From Univention Wiki

Jump to: navigation, search
Line 12: Line 12:
= The configuration database =
= The configuration database =
The Univention Config Registry (UCR) holds system wide information that can be accessed by scripts and used to write configuration files. See the [https://docs.software-univention.de/developer-reference.html#chap:ucr Developer Reference] for more details.
App may ship a .univention-config-registry-Variables file that contains a superset of what can be specified in UCS.
Description[de]=Alles in Log-Dateien schreiben
Description[en]=Write everything in log files
Description[en]=Access control
Labels[de]="Alle lesen, eigene schreiben" "Alle lesen, alle schreiben"
Labels[en]="Read all, write own" "Read all, write all"
Values=owner_write authenticated
The following attributes may be set: TBD
Inside the container, you may use ucr get variable to get the value. Variables that were set during installation are accessible as environment variables, too ([myapp/variable] becomes MYAPP_VARIABLE). Note that these were set during container creation. The environment variables will not change, even after the user changes the UCR variable.
;''Note'': For the full functionality of UCR (e.g., UCR templates), you would need a UCS based image. If the App Center detects UCR is present (which ucr), it will use it to set the variables (docker exec $appcontainer ucr set variable1=value1 variable2=value2). If this program is not found, the variables still get written in /etc/univention/base.conf. You may parse this file if UCR is not available. The format is rather simple: Each line contains variable: value.
= Domain-Join and Unjoin =
= Domain-Join and Unjoin =

Revision as of 11:22, 11 October 2016

Univention Corporate Server (UCS) is not just an enterprise Linux distribution. With its focus on identity and infrastructure management it has a lot of information saved about the IT infrastructure environment, the user accounts and the groups and the system configuration, to name a few.

The most obvious integration makes use of the numerous user accounts stored in the UCS directory service. Apps using this information avoid double effort in user administration. They may technically make just a simple LDAP bind for user authentication. Or if the app needs certain user attributes in its own persistence layer (e.g. the database) they may be synchronized via the Listener-/Notifier mechanism. Furthermore, existing data can be extended with app specific attributes, e.g., shall a user be allowed to use the app or what role shall the user occupy for the app. The UCS management system can be extended by attributes and the information is usually stored in the directory service. It is even possible that certain values or their change may trigger certain actions. A third integration possibility is to hook up the app in existing solution stacks of UCS, for example the mail stack or the web server. The app will among others benefit from a working configuration and a higher communication security because of already present security certificates.

Those are just a few examples to outline the possibilities for the integration. There are many more. The guiding question for the integration should be: What information about the infrastructure, the configuration and identities does UCS offer that the app will benefit from and saves efforts for the administrator?

The following sections give an impression of several integration scenarios. Further information can be found in the UCS Developer Reference.

Read information from the directory service


The configuration database

Domain-Join and Unjoin


Extend the UCS management system


Further integration scenarios


Firewall settings


Serving a web application


Setting links to the web interface in /ucs-overview


Personal tools