App Center/Dev/Integration with UCS
From Univention Wiki
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.
- 1 Read information from the directory service
- 2 The configuration database
- 3 Domain-Join and Unjoin
- 4 Extend the UCS management system
- 5 Using PostgreSQL or MySQL
- 6 Further integration scenarios
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.
[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.
- 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
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:
- One of "mysql" or "postgres". If set, the database is installed and set up on the Host before installing the actual App.
- Name of the database within the DBMS. Defaults to the App ID.
- Name of the database user within the DBMS with full access to the DatabaseName (and only to that!). Default to the App ID.
- 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.
- 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.
- Same as DockerEnvDatabaseHost, but contains the port of the DBMS on the Host. Defaults to DB_PORT.
- Same as DockerEnvDatabaseHost, but contains the DatabaseName. Defaults to DB_NAME.
- Same as DockerEnvDatabaseHost, but contains the DatabaseUser. Defaults to DB_USER.
- Same as DockerEnvDatabaseHost, but contains the password to the database. Defaults to DB_PASSWORD.
- 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.
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:firstname.lastname@example.org:5432.
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.
- 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
Serving a web application