Merge pull request #111 from Lebernd/patch-1
set cronjob to run every 5 min
|3 weeks ago|
|i18n||2 months ago|
|resources||1 month ago|
|.gitignore||3 years ago|
|Dockerfile||1 month ago|
|Makefile||2 months ago|
|README.md||10 months ago|
|env||1 year ago|
|inst||1 month ago|
|nextcloud.schema||3 years ago|
|preinst||1 month ago|
|restore_data_after_setup||1 year ago|
|restore_data_before_setup||1 year ago|
|setup||4 weeks ago|
|store_data||1 year ago|
|uinst||1 year ago|
|update_app_version||2 years ago|
This is the Nextcloud app for Univention Corporate Server (UCS). This installs, configures and integrates Nextcloud into UCS.
It is a docker based app, not relying on the UCS image.
Totally replaces the container. Data and Config are kept, upgrade routine kick off automatically.
Removes container, all system integrations (except Schema), keeps data
The Dockerfile install the base system (based on Ubuntu 16.04) and copies the Nextcloud files into place. Also file permissions are set accordingly.
Furthermore unattended upgrades are enabled and the web server configured.
The entrypoint is a scrip that starts cron and eventually runs the web server in foreground.
When the UCS admin clicks on install Nextcloud following happens.
The docker container will be created. If one is present, it will be replaced.
The hostname (retrieved from ucr) is saved within the permanent app config dir so setup within the Nextcloud container can do install and most basic configuration.
If a config.php exists, it will be copied from the permanent app folder to the usual destination within Nextcloud.
occ is made executable.
Checks are done whether Nextcloud is installed and being upgraded.
In any case, a Nextcloud upgrade routine is attempted (it does not do anything if not necessary).
The current config.php is copied to the permanent app config folder.
Just on UCS Api call / bash method invocation
They also can be used for pre-configuration, however there are no dedicated GUI ways for this.
It is checked whether
univention-ldap-overlay-memberof is installed to figure out one configuration flag for the Nextcloud LDAP backend.
With another single UCS bash method invocation.
Settings for enabling users and groups as well as setting user quota are registered.
Nextcloud's LDAP backend is configured.
all users and groups are whitelisted that are of objectclass
nextcloudGroup and where
nextcloudEnabled is set to
The login attribute defaults to
The user search attributes default to
uid;givenName;sn;employeeNumber;mailPrimaryAddress and the group search attributes to
The search base for users defaults to
cn=users,LDAP_BASE and for groups to
cn=groups,LDAP_BASE. This means only users or groups underneath those default subtrees are considered. The search base can be changed before the installation by executing
ucr set nextcloud/ldap/baseUsers="your-ldap-subtree" and
ucr set nextcloud/ldap/baseGroups="your-ldap-subtree" on the UCS host or after the installation in the Nextcloud settings via Admin -> LDAP / AD integration -> Advanced -> Directory Settings.
Unless on update or empty
$nextcloud_ucs_modifyUsersFilter all Users resulting by this filter¹ are modified.
nextcloudEnabled is set to
$nextcloud_ucs_userEnabled (defaults to 1) and
nextcloudQuota is set to
$nextcloud_ucs_userQuota(default to empty, i.e. unlimited).
(&(|(&(objectClass=posixAccount) (objectClass=shadowAccount)) (objectClass=univentionMail) (objectClass=sambaSamAccount) (objectClass=simpleSecurityObject) (&(objectClass=person) (objectClass=organizationalPerson) (objectClass=inetOrgPerson))) (!(uidNumber=0)) (!(|(uid=*$) (uid=nextcloud-systemuser) (uid=join-backup) (uid=join-slave))) (!(objectClass=nextcloudUser)))
This works by adding this user to the local Nextcloud group “admin” and empowers him to administer Nextcloud.
(This user can give admin rights by adding other Users within the Nextcloud user management to the “admin” group.)
The uninstall script makes sure that UCS is left clean from any Nextcloud tracks. A subsequent install will have a fresh and empty instance.
The Nextcloud service is removed from the localhost (UCS bash method invocation).
Following steps are only done, when
The Nextcloud PostgreSQL database and user are removed unconditionally, because the database resides on the docker host. The app folder /var/lib/univention-appcenter/apps/nextcloud/ is being deleted. To avoid this a manual backup has been done before (we can automatize it, but whereto?).
On upgrade the Nextcloud docker container is removed and all not-permanent data vanished. Before this, the Nextcloud config is copied to the permanent app config directory.
Subsequently the installation process kicks in. Therefore, all the upgrade switches in that logic :)
If the Dockerfile changes, you first need to build the image. If not continue with tagging and pushing to docker. Background: the app version on UCS as well as the docker tag should be the same (not a technical necessity, but best practice).
To build the container (from within the dir where the Dockerfile is located, replace $name accordingly):
$ sudo docker build -t $name .
To tag, figure out the docker image id via
sudo docker images, eventually:
sudo docker tag $imageID $repo/$name:$version
and push it
sudo docker push $repo/$name:$version
In the Univention Provider Portal, open the Hamburger menu of the app and click “New app version”. Pick the source and the target version and hit “Create”. In the app settings go to the “Docker” section and adjust the Docker image (update the tag).
Click the “save” icon and and the app is available in the test app center.
First, having an account and access to the UCS App Provider portal.
$ make add-version app_ver='11.0.3-0’ app_newver='11.0.3-90’
$ make push-files
uploads all files, except
i18n/*/Short Description.html and
i18n/*/Long Description.html, Screenshots and Videos. These text can only be edited manually in the app provider portal. Also logos are not being uploaded.
Uploads go against the current Nextcloud app version as configured in the Makefile.
to create a local build use
$ make docker
in order to trigger a build on the docker hub tag it like
$ git tag “13.0.3-0”
Tag the latest commit with the package name, e.g.
13.0.3-0 and push the tags. An automated build is configured at the docker hub.
$ make push-files
Afterwards, there are still two things that need to be done in the Provider Portal: