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

From Univention Wiki

Jump to: navigation, search
Line 54: Line 54:
 
= Using PostgreSQL or MySQL =
 
= Using PostgreSQL or MySQL =
  
The App Center provides an integration into the Database Management Systems (DBMS) PostgreSQL and MySQL. This is useful particularly 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).
+
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:
 
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:

Revision as of 15:00, 21 September 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

TBD

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.

Example:

[myapp/verbose]
Description[de]=Alles in Log-Dateien schreiben
Description[en]=Write everything in log files
Type=bool
Advanced=yes
Categories=apps

[myapp/rights/type]
Description[de]=Rechtevergabe
Description[en]=Access control
Type=list
Labels[de]="Alle lesen, eigene schreiben" "Alle lesen, alle schreiben"
Labels[en]="Read all, write own" "Read all, write all"
Values=owner_write authenticated
Default=owner_write
Categories=apps

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

TBD

Extend the UCS management system

TBD

Using PostgreSQL or MySQL

The App Center provides an integration into the Database Management Systems (DBMS) PostgreSQL and MySQL. This is particularly useful for Docker Apps. This is why the following text assumes a Docker App. 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 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: DockerEnvDatabaseHost=MYAPP_HOST will start with a Container with MYAPP_HOST=master.mydomain.intranet 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

ID=myapp
Database=postgres

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.

Alternatively,

ID=myapp
Database=mysql
DatabasePasswordFile=/opt/myapp/conf/database.secret
DockerEnvDatabaseHost=MYAPP_MYSQL_HOST
DockerEnvDatabasePort=MYAPP_MYSQL_PORT
DockerEnvDatabaseName=MYAPP_MYSQL_NAME
DockerEnvDatabaseUser=MYAPP_MYSQL_USER

installs MySQL, creates the database and the user and then sets

MYAPP_MYSQL_HOST=master.mydomain.intranet
MYAPP_MYSQL_PORT=3306
MYAPP_MYSQL_NAME=myapp
MYAPP_MYSQL_USER=myapp
DB_PASSWORD=1234567890

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 DockerEnvDatabasePassword as well.

Important
For the App Appliance to work, it is necessary for Docker Apps to reconfigure their database connection in the 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

TBD

Firewall settings

TBD

Serving a web application

TBD

Setting links to the web interface in /ucs-overview

TBD

Personal tools