Start to Finish Nextcloud+Collabora Step-by-Step Guide

📑 How to
1

I’ve written this guide to aid those that may be in the same scenario as I:

  1. You wish to implement your own cloud based solution, accessible via any computer/device, from any machine with an internet connection.
  2. You can’t or don’t have an external IP address that it static, but rather is assigned dynamically.
  3. Both Nextcloud services and Collabora services housed on single server.

This guide outlines the installation technique I used in order to create a functioning system that met the above scenario. I did have to purchase a domain name, and DNS services. I suppose you could use any Domain registar you wished, but I used DYN.com since they are also tied to the managed DNS service I used. Total cost for both services was approximately $100/year.

WHAT THIS GUIDE ASSUMES: You are familiar with IP and DNS schemas, gateways and subnet masks, and how to obtain this info from your computer. This guide also assumes that you already know how to setup a static IP address, DNS, gateway, how to change the host and domain name if your Ubuntu 16.04 installation.

Uses:
Ubuntu 16.04 (Can be either physical or virtual machine, I used a VM)
Nextcloud 11.02
Collabora CODE 2.0
DYNect managed DNS services (maps dynamic IP to domain name)
DYN DNS update client (Updates the DNS records when your dynamic IP changes)
Custom Domain name (Easier to get SSL working without cert generation errors due to too many certs being requested.)

Section #1 Network Schema
First we need to setup our private domain. I used the domain name registar DYN.com to register my domain name, but you should be able to use which ever registar you wish, but we later will need to use another service offered by DYN, called DYNect Managed DNS service. Depending on the registar, that price can vary. Once you have found a suitable domain name and registered it. We need to change our private network to reflect that of the public network (Internet). You will need to log into your router and change the domain name of your private network to the domain name that you registered. EXAMPLE: If you registered (mycloudnetwork.com) you will change the domain name setting in the router to (mycloudnetwork.com). This should not be confused with the host name also referred to as the machine name. So if your router’s host name is “router” the full internal domain name would become (router.mycloudnetwork.com). This is to setup an internal DNS schema that mirrors the internet’s so that you can use the exact same URL addresses to access your data whether you at home or half way around the world. We also need to enable port forwarding within the router. We need to forward all traffic on ports 80 and 443 on the WAN interface to the internal IP address.

Next your going to determine which private network your internal network is currently using. Your going to record the following items:

IP network address schema: EXAMPLE=192.168.1.0
Subnet mask: EXAMPLE=255.255.255.0 or /24
Gateway: Example 192.168.1.1
DNS Server: EXAMPLE=192.168.1.1

Next we are going to choose our static IP address for our Ubuntu server within the previously determined IP address schema. For this guide we will use the static IP address of 192.168.1.2 to assign to our Ubuntu server. We also need to decide on a hostname for the Ubuntu server. Something such as “cloud”. So for this example we will be using the following settings:

Static IP address: 192.168.1.2
DNS Server: 192.168.1.1
Gateway: 192.168.1.1
Hostname: cloud
Domain: mycloudnetwork.com

Next we need to go back to the router’s configuration interface and assign a manual DNS (A-record) entry for our host named “cloud” to resolve to 192.168.1.2. This will cause your router to resolve the address “cloud.mycloudnetwork.com” to resolve to 192.168.1.2 rather than query an external DNS server for the address. Failure to get this step right will result in the above mentioned address to be resolved to an external address outside of your internal network, and cause and error later on in the setup. (Explanation: You cannot access your server which resides in the same internal network “LAN” by using the external WAN address, you will get a ERROR 404 or something similar).
Using your everyday computer, at the command prompt or terminal, verify that the domain is being correctly resolved by issuing the “nslookup cloud.mycloudnetwork.com” command. Make sure that the DNS server issuing the response is 192.168.1.1 and replies with the host resolving to 192.168.1.2.
Now we need to return to the router config interface, we need to enable port forwarding within the router. We need to forward all traffic on ports 80 and 443 on the WAN interface to the internal IP address of the Ubuntu server (192.168.1.2)

Section #2 Server install and config

Next we install the Ubuntu 16.04 Operating system on our desired platform (physical or VM) when prompted make sure to use the settings we chose and recorded earlier. Or if you’ve already installed the O.S. changed these settings to reflect these settings we recorded/chose eariler.
Note: If using the Ubuntu GUI interface, I’ve ran into problems getting the network manager to correctly change the DNS server from “8.8.8.8 (which is the default)” to the internal LAN DNS server address. This was resolved by manually editing file named “head” and entering “nameserver 192.168.1.1” removing any other entry, and deleting any entry in the file named “base”. Both files are located in “/etc/resolvconf/resolv.conf.d/” directory. And then rebooting.
IP address: 192.168.1.2
Subnet mask: 255.255.255.0
Gateway: 192.168.1.1
hostname: cloud
domain: mycloudnetowrk.com

Section #3 setting up DYNect Managed DNS services.

This is the other product in which we have to purchase. I am sure that there are other services out there that offer this type of service, but this is what worked for me. The reason we are purchasing a domain name and DYNect Managed DNS services is that I found that it makes the SSL cert generation steps that will need to be completed later on to actually succeed, and not return with an error that too many certs have been issued for the parent domain name. such as (mooo.com, etc.). It aslo provides a more customized and polished feel to your installation. The service I chose was the basic $7/mo package. This allows us to use our custom registered domain name just like you would with services such as DYN, no-ip, freedns.afraid. The link to the service is (http://dyn.com/managed-dns/) . (I am no way affiliated with this service) Once you have registered and activated your service you need to create a new “Zone”. You will use the domain name “mycloudnetwork.com” and provide your contact details. Upon submitting, you will be given a list of several nameserver URL’s. Record these exactly as the appear for later use.

Once the zone has been published and provisioned, you will be able to “manage” your new zone. Once you’re inside the management of your new zone, along the top you’ll click on a tab named “Quick Tasks” and select “Create Dynamic DNS”. In the form that loads you will enter the hostname of our server, “cloud”, Enter the WAN address we previously recorded, then select “create new update user” fillout the username and password fields and click “Create DDNS Host”. (NOTE: the username will have alpha-numeric characters pre-pended to the username which will be displayed upon creation). Write this username and the password you chose down for later use.

We then are going to create another “Quick Dynamic DNS” entry. But this one is going to be later used for our Collabora server. For this guide we will use the hostname “office”, and follow all the same steps, but instead of creating another update user, we will select an already previously create user we made during the last entry. In the end we should end up with both hosts (cloud.mycloudnetwork.com and office.mycloudnetwork.com) resolving to our external WAN IP address.

Now we need to log back into the registar you chose to register your domain name with back in section #1. Within the setting you should be able to find where you can manually manage your DNS servers. This is where you will enter the list of domain name servers given to you by DYNect when you created your zone. This instructs the registar to use DYN’s nameservers to resolve your domain name.

Now you have a choice here. We are gonna need to download and run the update client on a machine within the internal network. This generally is a computer that is going to be on all the time. This can be your everyday computer or you can use the updater on the Ubuntu Server. You can download the appropriate client at: http://dyn.com/update-client-faqs/ . once you’ve installed the updater client your going to use the username and password that you created when you made the “Create Dynamic DNS” entry. You then will need to select the two hosts you created from the list that will load in the updater (Windows Version updater) and select IPv4 enable. This will continue to run on the machine in which it was installed. Anytime that the WAN IP address is updated by your ISP, the corresponding IP address change will then be forwarded to DYNect and automagically change the address listed within the service. Just make sure that this updater is constantly running. Cause if your IP address changes while this machine is off or the updater isn’t running, access to your server will not be possible from outside your internal network until WAN IP address is updated within DYNect.

Section #4 Installing Nextcloud 11.02
This part is best done physical at the server (or within hypervisor) rather than remotely such as SSH for simplicity sake.

Log into the server and start a terminal. Run this command.

wget https://github.com/nextcloud/vm/blob/master/nextcloud_install_production.sh

nano nextcloud_install_production.sh

Here we are gonna goto line 160 and look for the following two lines:

echo "nameserver 8.8.8.8" > /etc/resolvconf/resolv.conf.d/base
echo "nameserver 8.8.4.4" >> /etc/resolvconf/resolv.conf.d/base

We need to place a “#” at the beginning of each line, so they look like this.

#echo "nameserver 8.8.8.8" > /etc/resolvconf/resolv.conf.d/base
#echo "nameserver 8.8.4.4" >> /etc/resolvconf/resolv.conf.d/base

Now we press ctrl + x then y and press enter to save the changes and exit.

We done this because the changes we made earlier to the nameserver to make it 192.168.1.1 would have been overwritten again with 8.8.8.8 and the ‘#’ tells the script we are about to run to skip these lines.

Now run
sudo bash nextcloud_install_production.sh

This will download, install and setup nextcloud, depending on your internet connection this can take about 30 minutes. In the meantime you will be asked several questions regarding your installation. When prompted, remember to enter your nextcloud URL as ‘cloud.mycloudnetwork.com’ but use your host name and domain name. Since we are using a unique domain name you should be able to successfully complete the SSL generation part of the script. Although the script may complain during the first attempt, but should complete during the second attempt. Above all, be patient. Don’t restart the computer or do anything, until the script has completed and dropped you back to the prompt.

At this point you should have a functioning nextcloud server accessible at ‘https://cloud.mycloudnetwork.com’ on both the internal LAN and across the internet.

Section #5 installation and setup of Collabora

At the terminal type these commands:
sudo apt update

sudo apt install docker.io

sudo systemctl enable docker

sudo docker pull collabora/code (depending on your internet conenction this may take awhile.)

In the following command be sure to change the domain to yours. (NOTE: The periods must be escaped with a double “” like in the example.)

sudo docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=cloud\\.mycloudnetwork\\.com' --restart always --cap-add MKNOD collabora/code

sudo nano /etc/apache2/sites-available/office.mycloudnetwork.com.conf (Change the domain name)

Paste the following into the file: (be sure to change the domain name to yours)

<VirtualHost *:80>
ServerName office.mycloudnetwork.com
</VirtualHost>`

Now we press ctrl + x then y and press enter to save the changes and exit.

Enable the virtual host we just created:
sudo a2ensite office.mycloudnetwork.com.conf (Change the domain name)

Restart Server’s web service

sudo systemctl restart apache2

Now lets create our Collabora Server SSL cert, Run these commands: (NOTE: on the second command be sure to use you contact email and domain name)

sudo apt install letsencrypt python-certbot-apache

sudo letsencrypt --apache --agree-tos --email your-email-address -d office.mycloudnetwork.com

Now we need to ensure that HTTP reverse proxy is set up:

sudo a2enmod proxy proxy_wstunnel proxy_http ssl

Now we need to alter the Apache config file for the SSL secured virtual host that will serve Collabora

sudo nano /etc/apache2/sites-enabled/office.mycloudnetwork.com-le-ssl.conf

Look for the following two lines in this file:

Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>`

Between these two lines copy and paste the following lines of code:

 # Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://127.0.0.1:9980/loleaflet

# WOPI discovery URL
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery

# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon

# Admin Console websocket
ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws

# Download as, Fullscreen presentation and Image upload operations
ProxyPass /lool https://127.0.0.1:9980/lool
ProxyPassReverse /lool https://127.0.0.1:9980/lool

Now we need to save and exit:
press ctrl + x then y and press enter to save the changes and exit.

Restart apache again:
sudo systemctl restart apache2

FINAL STEP: Enabling Collabora in Nextcloud:

Now we need to log into the nextcloud server at ‘https://cloud.mycloudnetwork.com’ and in the top left had corner of the interface, you see ‘Admin’. Click this and a sub menu will appear. Click the ‘+’ sign to add APPS. Located and enable Corrabora.

Now in the top right hand corner click on the menu there and select “admin”. Once the page loads in the menu along the left hand side of the screen select “Additional Settings” and then “Corrabora Online”. In the text box labeled “Corrabora Online Server” enter your Corrabora server URL https://office.mycloudnetwork.com and click apply.

From here you should now be able to use Corrabora Online to edit files stored on the Nextcloud server, or under Files, you can select the “+” to create doc, spreadsheets, or presentations from within your LAN or over the internet.

5 Likes
2

This is better than the official video. It has the location for the files that need changing.

1 Like
3

If you have this bug in a newer Nextcloud version ( at least v19, maybe in earlier versions too ) where the connection between the collabora container and nextcloud always disconnects after reloading the settings page, then
change this:

<VirtualHost *:80>
ServerName office.mycloudnetwork.com
</VirtualHost>`

to this:

<VirtualHost *:80>
ServerName office.mycloudnetwork.com
Redirect permanent / https://office.mycloudnetwork.com/
</VirtualHost>`

in /etc/apache2/sites-available/office.mycloudnetwork.com.conf and the error will probably be fixed. It seems like nextcloud only checks the https vhost on the first time when you save your settings and after that it uses http to verify if the collabora server is still alive.

Since the collabora server only gets data from requests on the :443 vhost through the given reverse proxy configuration, nextcloud fails to verify that the server is still alive if there is no redirect for http to https.

Maybe this helps someone who followed the guide and still didn´t manage to get it running