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

From Univention Wiki

Jump to: navigation, search
Line 51: Line 51:
= Using PostgreSQL or MySQL =
The App Center provides an integration into the Database Management Systems (DBMS) PostgreSQL and MySQL. This is particularly useful for [[App_Center/Dev/Docker_Apps|Docker Apps]]. This is why the following text assumes a Docker App. [[App_Center/Dev/Non-Docker_Apps|Non-Docker Apps]] may just install the DBMS via apt through a dpkg dependency (although, except for variables clearly related to Docker, everything works for Non-Docker Apps, too).
A Docker App does not have to install its own database in the container. Instead, it may connect to the database on the Docker Host. For that, the following variables in the [[App_Center/Dev/Meta_files#The ini file|ini file]] can be set:
;Database: One of "mysql" or "postgres". If set, the database is installed and set up on the Host before installing the actual App.
;DatabaseName: Name of the database within the DBMS. Defaults to the App ID.
;DatabaseUser: Name of the database user within the DBMS with full access to the '''DatabaseName''' (and only to that!). Default to the App ID.
;DatabasePasswordFile: Path to the password file both on the Host and in the Container. The file will contain the password without a newline character. The default will be ''/etc/[postgres|mysql]-$appid.secret''. The file will be readable only by ''root''.
;DockerEnvDatabaseHost: The Docker Container will be started with this variable's value as the environment variable containing the Host's name. Example: <tt>DockerEnvDatabaseHost=MYAPP_HOST</tt> will start with a Container with <tt>MYAPP_HOST=master.mydomain.intranet</tt> set in the environment. Defaults to DB_HOST.
;DockerEnvDatabasePort: Same as '''DockerEnvDatabaseHost''', but contains the port of the DBMS on the Host. Defaults to DB_PORT.
;DockerEnvDatabaseName: Same as '''DockerEnvDatabaseHost''', but contains the '''DatabaseName'''. Defaults to DB_NAME.
;DockerEnvDatabaseUser: Same as '''DockerEnvDatabaseHost''', but contains the '''DatabaseUser'''. Defaults to DB_USER.
;DockerEnvDatabasePassword: Same as '''DockerEnvDatabaseHost''', but contains the password to the database. Defaults to DB_PASSWORD.
;DockerEnvDatabasePasswordFile: Same as '''DockerEnvDatabaseHost''', but contains '''DatabasePasswordFile'''. If set, '''DockerEnvDatabasePassword''' is not used, i.e., the password will not show up in the environment. Instead, only the file contains information about the password.
=== Example ===
will install a PostgreSQL server on the Host, create a database user "myapp", create a database named "myapp" and make the user "myapp" its owner. The password is stored in /etc/postgres-myapp.secret.
In the Docker Container, one can configure the App to connect to: $DB_USER:$DB_PASSWORD@$DB_HOST:$DB_PORT, which is something like: myapp:1234567890@master.mydomain.intranet:5432.
installs MySQL, creates the database and the user and then sets
in the container.
Ideally, the password is already stored where the App expects it to be (otherwise setting DatabasePasswordFile does not make much sense). One could set <tt>DockerEnvDatabasePassword</tt> as well.
;''Important'': For the [[App_Center/Dev/App_Appliance|App Appliance]] to work, it is necessary for Docker Apps to reconfigure their database connection in the [[#Domain-Join_and_Unjoin|Join script]]. If the initial configuration is written in some "postinst routine" and left untouched, the connection will most likely fail as the hostname of the Docker Host will change.
= Further integration scenarios =
= Further integration scenarios =

Revision as of 10:37, 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

The Univention Config Registry (UCR) holds system wide information that can be accessed by scripts and used to write configuration files. See the 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.

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


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