Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.
Nextcloud and Collabora Integration

Nextcloud and Collabora Integration

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
Basil Hendroff submitted a new resource:

Nextcloud and Collabora Integration - A collection of notes on how to integrate Collabora with Nextcloud.

This is a collection of notes on how to get Collabora Online Development Edition (CODE) working in Nextcloud. To realise this, a number of building blocks need to be put together.

Outline of the Steps
  1. Install Nextcloud
  2. Set up Nextcloud behind a reverse proxy
  3. Install Ubuntu with Docker in a FreeNAS VM
  4. Install Collabora using Docker
  5. Set up the Collabora server behind the reverse proxy
  6. Enable and configure the Collabora Online connector in Nextcloud
...
Read more about this resource...
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
Office Suite Free Edition
Licensing
Mobile Editing
Collabora Online Development Edition (CODE)
Up to 10 documents. Up to 20 connections​
Yes​
OnlyOffice Community Edition
Up to 20 documents. Up to 20 connections​
No. Viewers only.​

Putting aside technology and feature comparisons, considering the free editions from a licensing perspective only, moving forward, Collabora will be the preferred choice if mobile editing is important. On the other hand, if supporting a larger user base is more important, OnlyOffice will be the preferred choice.

There is nothing to stop both office suites being enabled. However, this is probably not a good idea in a group setting as cross-suite collaboration is likely to have unpredictable and damaging consequences.
 
Last edited:

adrianwi

Neophyte Sage
Joined
Oct 15, 2013
Messages
1,091
I played around with both for a few months (running Onlyoffice Document Server on a ubuntu 18.4 VM and CODE in a Docker container on a different ubuntu VM) and overall felt that Onlyoffice is the better solution.

It looked at one point that Nextcloud was going down the Collabora route, but with 18 they appear to have selected Onlyoffice as the preferred integration. It is much more compatible with Office 365 and from my experience a more reliable solution. It's a little slower than CODE at opening documents, but I still choose Onlyoffice every time. I don't even run CODE anymore.

Having posted that, and then read the other post, I'm a little concerned that this might not be a viable open source solution for much longer :-( I've not upgraded my Onlyoffice Document Server so can still edit documents on mobile, and probably won't be updating it for the foreseeable future.
 
Last edited:

KevDog

Senior Member
Joined
Nov 26, 2016
Messages
378
Hi @Basil Hendroff. I think you may have referenced some of my posts from the Nextcloud Forums. I believe I made those a few years ago and for all intensive purposes that setup method works, but it's not very robust. I've since moved on to using docker-compose files which are a lot better and easier to work with. Containers will automatically be pulled with the latest updates and started on system startup. It's a heck of a lot easier to save configurations with the compose file rather than as a command line argument. In addition -- the part of your guide which you referenced about needing to log into the container to edit the loolwsd.xml file --- you definitely don't need to do that when working with a docker-compose file. Just a heads up. If you need some more information, I'd be happy to supply you with some, since overall I think it would make your guide a heck of a lot better.

In terms of OO vs Collabora, OO has client/server processing whereas with Collabora its strictly server side. For me at least Collabora is a heck of a lot slower and clunkier to use whereas OO seems just a lot more zippy. I have both Collabora and OO running side by side with docker images, and its relatively easy to switch back and forth between the two. I'm not sure if you had a bunch of users using the system if you'd want to do this, however since my user base is small, it works quite well. OO is definitely a lot less picky to install via a docker-compose file, and frankly it's just a lot less work to maintain.

In terms of the lack of mobile editing, I'll just post a link about it -- and that's all I'm going to say. The user can glean any information they want.

Thanks for the caddy section -- Honestly I've never seen someone do a writeup with caddy as a reverse proxy, so it was nice to see. I'm still using nginx as this is what most of the resources were using when I researched the topic.
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
I've since moved on to using docker-compose files which are a lot better and easier to work with. Containers will automatically be pulled with the latest updates and started on system startup. It's a heck of a lot easier to save configurations with the compose file rather than as a command line argument. In addition -- the part of your guide which you referenced about needing to log into the container to edit the loolwsd.xml file --- you definitely don't need to do that when working with a docker-compose file. Just a heads up. If you need some more information, I'd be happy to supply you with some, since overall I think it would make your guide a heck of a lot better.
That section of the guide where I had to work around a buggy command line did bother me a little. I also wondered how I was going to suggest keeping the versions of OO and Collabora up to date. As well as that, I did wonder about the benefits of docker-compose files and you've just spelled it all out in a nutshell. Based on what you've suggested, I think Step 4 of each of the guides could do with the improvement. You're on the way to addressing all these issues for me, so yes please, 'Bring it on!'. Thank you for the offer of assistance. I'll be happy to update the guides for the benefit of other forum members.

It's clear from recent Nextcloud posts, there's lots of interest in the Nextcloud office suites, but considerable difficulty getting them set up. Much of this, I feel, is due to not fully appreciating the structures needed to support the suites.

Thanks for the caddy section -- Honestly I've never seen someone do a writeup with caddy as a reverse proxy, so it was nice to see. I'm still using nginx as this is what most of the resources were using when I researched the topic.
All credit goes to @danb35 and his Reverse Proxy using Caddy (with optional automatic TLS) resource. If it wasn't for this resource, I reckon I'd still be trying to get my head around NginX or Apache. Caddy V2 is about to be released. I understand the longer-term benefit will be simplified code blocks, but, I don't believe there's backward compatibility with Caddy V1 code blocks. FWIW, V1 is perfectly adequate for my needs. For instance, this thread suggests some members are grappling putting TrueCommand behind an NginX reverse proxy. It literally took five minutes for a noob like me to get TC working behind a Caddy reverse proxy (refer here).
 
Last edited:

NasKar

Neophyte Sage
Joined
Jan 8, 2016
Messages
594
@Basil Hendroff
Steps 1-3 work fine with TLS with HTTP validation for the caddy reverse proxy.
I'm up to step 4 of your Collabora guide. You need to add sudo to the command so it's sudo docker pull collabora/code
I'm stuck at verifying the install
sudo docker logs CODE last line is kit-00032-00030 2020-04-22 21:30:20.135708 [ kit_spare_001 ] INF Kit initialization complete: setting log-level to [warning] as configured.| kit/Kit.cpp:2676 and curl -k http://10.1.1.21:9980 gives the error curl: (7) Failed to connect to 10.1.1.21 port 9980: Connection timed out
 

KevDog

Senior Member
Joined
Nov 26, 2016
Messages
378
@Basil Hendroff
I have a question for you -- I'm using nginx for my reverse proxy rather than caddy (although I don't actually have a preference). What I can't get however is how to reverse proxy collabora/code when the reverse proxy is on a different machine than collabora. I can setup a reverse proxy if nginx is on the same machine as collabora but I can't take the same configuration and apply it to reverse proxy on another machine. Where you able to figure this out?
 

Patrick M. Hausen

Neophyte Sage
Joined
Nov 25, 2013
Messages
1,480
Shouldn't the discussion of Collabora and reverse proxies better be taken to a Collabora forum/community platform?
 

KevDog

Senior Member
Joined
Nov 26, 2016
Messages
378
@Patrick M. Hausen -- yes technically you are probably correct, but there is a big but.... I've posted on the Nextcloud forum help forums (there isn't a specific Collabora forum that I'm aware of). Unfortunately the skillset on the Nextcloud forum isn't all that great. I'm looking for any or as much help as I can find. Usually the knowledge base in FreeNAS is a lot more extensive and usually I've found people here have set up something similar in the past.
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
You need to add sudo to the command so it's sudo docker pull collabora/code
Fixed. Thanks!

I'm stuck at verifying the install
sudo docker logs CODE last line is kit-00032-00030 2020-04-22 21:30:20.135708 [ kit_spare_001 ] INF Kit initialization complete: setting log-level to [warning] as configured.| kit/Kit.cpp:2676 and curl -k http://10.1.1.21:9980 gives the error curl: (7) Failed to connect to 10.1.1.21 port 9980: Connection timed out
Make sure you refer to the IP of your Ubuntu server in the curl command e.g.

screenshot.284.png
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
I'm using nginx for my reverse proxy rather than caddy (although I don't actually have a preference). What I can't get however is how to reverse proxy collabora/code when the reverse proxy is on a different machine than collabora. I can setup a reverse proxy if nginx is on the same machine as collabora but I can't take the same configuration and apply it to reverse proxy on another machine. Where you able to figure this out?
Just to be very clear, I have no experience with Apache or NginX. I am, however, comfortable using @danb35's Caddy resource.

The problem you're describing was a non-event for me under Caddy. Set up was trivial. To test this out, I built an instance of Collabora in a Ubuntu VM on a FreeNAS server different to the server that Caddy and my production version of Collabora and Nextcloud are installed on. In steps 5 and 6 of this resource, I pointed to the remote Collabora instance in Caddy. I didn't appear to have any issues invoking that Collabora instance within the production version of Nextcloud. In the code block below, codetest.mydomain.com and IP 10.1.147 refer to Collabora in a Ubuntu VM on a remote FreeNAS server.

Code:
# Collabora on different server to Caddy
codetest.mydomain.com {
  tls {
    dns cloudflare
  }
  gzip

    # Static html, js, images, etc. served from loolwsd
    # Loleaflet is the client part of LibreOffice Online
    proxy /loleaflet http://10.1.1.47:9980 {
        insecure_skip_verify
        transparent
    }

    # WOPI discovery URL
    proxy /hosting/discovery http://10.1.1.47:9980 {
        insecure_skip_verify
        transparent
    }

    # Main websocket
    proxy /lool http://10.1.1.47:9980 {
        insecure_skip_verify
        transparent
        websocket
    }

#    # Admin console websocket
#    proxy /lool/adminws http://10.1.1.47:9980 {
#       insecure_skip_verify
#       transparent
#       websocket
#    }

    # Show capabilities as json
    proxy /hosting/capabilities http://10.1.1.47:9980 {
        insecure_skip_verify
        transparent
    }

    # Download as, fullscreen presentation and image upload operations
    proxy /lool http://10.1.1.47:9980 {
        insecure_skip_verify
        transparent
    }
}


screenshot.286.png


The test version vs my production version of Collabora.

screenshot.70.jpg
screenshot.71.jpg
 
Last edited:

NasKar

Neophyte Sage
Joined
Jan 8, 2016
Messages
594
trying to get one of these working
Got to step 5
Collabora listening port returns OK
after adding the recommended info the Caddyfile the caddy log shows.
Code:
Apr 23 22:48:13 caddy caddy[43695]: 2020/04/23 22:48:13 [INFO] Caddy version: v1.0.4
Apr 23 22:48:13 caddy caddy[43695]: 2020/04/23 22:48:13 [INFO][cache:0xc0000c67d0] Started certificate maintenance routine
Apr 23 22:48:13 caddy caddy[43695]: Activating privacy features... 2020/04/23 22:48:13 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/direct>
Apr 23 22:48:14 caddy caddy[43695]: 2020/04/23 22:48:14 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.>
Apr 23 22:48:15 caddy caddy[43695]: 2020/04/23 22:48:15 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.>
Apr 23 22:48:16 caddy caddy[43695]: 2020/04/23 22:48:16 get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on 192.168.5.1:53: s>
Apr 23 22:48:21 caddy caddy[43717]: 2020/04/23 22:48:21 [INFO] Caddy version: v1.0.4
Apr 23 22:48:21 caddy caddy[43717]: 2020/04/23 22:48:21 [INFO][cache:0xc0000e07d0] Started certificate maintenance routine
Apr 23 22:48:21 caddy caddy[43717]: Activating privacy features... 2020/04/23 22:48:21 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/direct>
Apr 23 22:48:22 caddy caddy[43717]: 2020/04/23 22:48:22 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.>
Apr 23 22:48:23 caddy caddy[43717]: 2020/04/23 22:48:23 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.>
Apr 23 22:48:24 caddy caddy[43717]: 2020/04/23 22:48:24 get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on 192.168.5.1:53: s>
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
So if you take out the Caddy code block for Collabora, and restart Caddy, do you still get the error?
 

KevDog

Senior Member
Joined
Nov 26, 2016
Messages
378
@Basil Hendroff Nice work on the proxy. What were the parameters you used for the docker collabora?
 

KevDog

Senior Member
Joined
Nov 26, 2016
Messages
378
Ok Basil, Here are a few things you can try to use docker-compose which is a heck of a lot easier.

Since you are using ubuntu you need to install docker-compose
Code:
apt install docker-compose


You then want to make a directory where you are going to keep your compose files.
I usually put mine in /etc/docker/compose/<project or site>
Code:
mkdir -p /etc/docker/compose/<project or site name>
cd /etc/docker/compose/<project or site name>


Your compose file in this directory needs to specifically be called docker-compose.yml. If you don't know about working with yml files, spacing is very important. If you need to indent its 2 spaces. I'd recommend not using tabs to not screw things up. Make sure the columns line up. I've wasted a lot of time with malformed yml files because of spacing issues, so word of caution.

So I'll post my docker-compose.yml version for collabora here. I'm using this page as a reference on how to construct this file: https://www.collaboraoffice.com/code/docker/

Code:
---
version: '3.3'

networks:
  net:
   driver: bridge

services:

  collabora:
    restart: always
    image: collabora/code:latest
    container_name: collabora
    networks:
      - net
    ports:
#      - 127.0.0.1:9980:9980
      - 9980:9980
    cap_add:
      - MKNOD
    environment:
      - username=<admin user name>
      - password=<admin password>
      - domain=nextcloud\.domain\.com
#      - cert_domain=office.domain.com
      - DONT_GEN_SSL_CERT="True"
      - server_name=reverse_proxy.domain.com
      - extra_params=--o:ssl.enable=false --o:ssl.termination=true
#      - extra_params="--o:ssl.enable=true"
#      - extra_params="--o:ssl.enable=false"
#    volumes:
#      - /etc/letsencrypt/privkey.pem:/etc/loolwsd/key.pem
#      - /etc/letsencrypt/cert.pem:/etc/loolwsd/cert.pem
#      - /etc/letsencrypt/chain.pem:/etc/loolwsd/ca-chain.cert.pem


Ok so lets kind of step through this file briefly. The # lines are comments, feel free to exclude. I like to play with various options during testing so its easier for me to be able to flip these options on and off as needbe

version # needs to be in relation to your installed docker version. A page of the available version numbers is here: https://docs.docker.com/compose/compose-file/compose-versioning/. Version numbers are backwards compatible.

Docker networking. Docker creates a private internal docker network using a network bridge. Containers declared within the docker-compose file can speak to each other using docker's internal network. The internal DNS server for the docker network is at address 127.0.0.11. When containers need to perform DNS lookups they first check docker's internal DNS, then the docker host's /etc/hosts file, and then ask the network router. DNS Host over rides may be done at the /etc/hosts or router level. Docker containers are known on the network by their container_name variable.
networks:
net:
driver: bridge
This defines an internal network using a network bridge. A routed network could also be used however a bridged network is fairly easy to work with in most cases.

restart: always -- means the container will be restarted when the host is rebooted or restarted. The container will not automatically restart after the docker image is stopped manually, but would restart if stopped after a host reboot. We'll discuss starting and stopping containers below

image: collabora/code:latest - this tells docker what image to pull from dockerhub. https://hub.docker.com/r/collabora/code/tags

container_name - defines the name for the container. This will be used for stop/restart operations and will also by the host name for the container.

networks:
- net
This line tells the container what network bridge to utilize.

ports:
Ports or expose can be used. Ports 9980:9980 -- The first 9980 is docker's host port, and the second 9980 refers to the container' port. 9980:9980 maps the docker host's port 9980 to the docker container's port 9980. The docker container will listen for all incoming connections on port 9980 when defined in this way 9980:9980. If you only want to listen for incoming connection from a specific address you could use 127.0.0.1:9980:9980 which means the docker container will only bind port 9980 to listen for incoming connections from the local host. 127.0.0.1:9980:9980 is usually used if a revere proxy is run directly on the docker host. Expose is another variant of ports but not valid in this instance. expose 9980 would the container is exposing it's 9980 port only to listen to incoming connections from the docker network. Use of expose is valuable when you only want intra-container communication. If using a firewall on the docker host -- please be sure to open port 9980 (see ufw or iptables).

cap_add:
- MKNOD
This "adds capabilities" to the container to be able to make special files using mknod - https://docs.docker.com/engine/reference/run/

Environmental Variables are the variables as best defined in https://www.collaboraoffice.com/code/docker/. These options will mirror what is usually used on the command line.

volumes -
Briefly volumes are a way to map a host or directory of the docker host directly to a host or directory within the docker container. If you wanted to generate Let's Encrypt SSL certs for the container itself, you could map the relevant key, cert, and chain files here if needed. Another example of using volumes would be if you wanted to keep a working copy of the /etc/loolwsd/loolwsd.xml directly on the host and make modifications directly to the configuration file. You could make changes to the file and then map it as a volume for the container to use -- effectively it would overwrite the default loolwsd.xml file within the container. I'd recommend trying to make changes via setting environmental variables prior to editing the loolwsd.xml file directly. Syntax can be tricky with the xml file and prone to errors. I've found very little need (if at all) to directly modify this file is using docker-compose.

Once you have configured and started your compose file:
1. Make sure you are within the docker-compose.yml directory (/etc/docker/compose/<project or site name>
2. Start the docker network with containers: docker-compose up -d --build --remove-orphans
3. You can check the state of the containers with: docker ps
4. You can check the logs of an individual container with: docker logs <container_name>
5. To stop all running containers: docker-compose down -v


Optional Step

By default docker-compose will not pull updated containers from dockerhub. (If building and using docker images created from a DOCKERFILE totally ignore this section or modify the information to your needs). If you want to automatically pull the latest containers, there are a number of methods.

Probably the most comprehensive method is actually using a docker project itself known as ouroboros: https://hub.docker.com/r/pyouroboros/ouroboros.

Watchtower https://github.com/containrrr/watchtower is another alternative. This is the "old tried and true" method for keeping containers updated automatically. I thought the project died however looking at their github there have been many recent commits.

Another simple and cheap method is the use of systemd timers and service files. Based on some examples I've found on the internet, I've constructed the following 3 files: docker-compose-reload@.service, docker-compose-reload@.timer, docker-compose@.service. In a nutshell, these files will use a systemd timer method (analogous to cron tasks), where at a specified interval, systemd will "refresh" the containers by stopping the running containers, pulling new images if necessary from dockerhub, and then restarting the container. (You don't get all the nifty feedback, graphs, and emails however that pyourobors would offer -- if you need such things!!).

Here are the files:
docker-compose-reload@.timer
Code:
[Unit]
Description=Refresh images and update containers
Requires=docker-compose@%i.service
After=docker-compose@%i.service

[Timer]
OnCalendar=daily

[Install]
WantedBy=timers.target


docker-compose-reload@.service
[Unit]
Description=Refresh images and update containers

[Service]
Type=oneshot

ExecStart=/usr/bin/systemctl reload-or-restart docker-compose@%i.service

docker-compose@.service
[Unit]
Description=Docker Compose %i container starter
After=docker.service network-online.target
Requires=docker.service network-online.target

[Service]
WorkingDirectory=/etc/docker/compose/%i
Type=oneshot
RemainAfterExit=yes

ExecStartPre=/usr/bin/docker system prune
ExecStartPre=/usr/bin/docker-compose down -v
ExecStartPre=/usr/bin/docker-compose rm -fsv
ExecStartPre=/usr/bin/docker-compose pull --quiet
#ExecStartPre=/usr/bin/docker-compose build --compress
ExecStart=/usr/bin/docker-compose up -d

ExecStop=/usr/bin/docker-compose down -v
ExecStopPost=/usr/bin/docker-compose rm -fv

ExecReload=/usr/bin/docker-compose pull --quiet
ExecReload=/usr/bin/docker-compose up -d

[Install]
WantedBy=multi-user.target


Be sure to modify the docker-compose-reload@.timer file and change the OnCalendar option to fit your needs. This option works similar to cron settings: https://wiki.archlinux.org/index.php/Systemd/Timers

To use these files it would be similar to any systemd file (For these files to work - they assume a directory structure of /etc/docker/compose/<project or site name>. This assumption can be changed by modifying the docker-compose@.service file - See Working Directory):

systemd enable docker-compose-reload@<project or site name>.service
systemd enable docker-compose-reload@<project or site name>.timer
systemd enable docker-compose@<project or site name>.service
systemd start docker-compose-reload@<project or site name>.timer
systemd start docker-compose@<project or site name>.service

That's it. Hopefully that helps.
 
Last edited:

NasKar

Neophyte Sage
Joined
Jan 8, 2016
Messages
594
So if you take out the Caddy code block for Collabora, and restart Caddy, do you still get the error?
If I take out the Collabora block the error goes away and the reverse proxy works. Here is my Caddyfile.

Code:
mydomain.cf {
root /usr/local/www/html/
}
cloud.mydomain.cf {

  gzip
  proxy / http://192.168.5.81 {
    transparent
  }
}
#office.mydomain.cf {

#  gzip
#  proxy / http://192.168.5.88 {
#    transparent
#  }

code.mydomain.cf {
    # Static html, js, images, etc. served from loolwsd
    # Loleaflet is the client part of LibreOffice Online
    proxy /loleaflet https://192.168.5.88:9980 {
        insecure_skip_verify
        transparent
    }

    # WOPI discovery URL
    proxy /hosting/discovery https://192.168.5.88:9980 {
        insecure_skip_verify
        transparent
    }

    # Main websocket
    proxy /lool https://192.168.5.88:9980 {
        insecure_skip_verify
        transparent
        websocket
    }

    ## Admin console websocket
    #proxy /lool/adminws https://192.168.5.88:9980 {
    #   insecure_skip_verify
    #   transparent
    #   websocket
    #}

    # Show capabilities as json
    proxy /hosting/capabilities https://192.168.5.88:9980 {
        insecure_skip_verify
        transparent
    }

    # Download as, fullscreen presentation and image upload operations
    proxy /lool https://192.168.5.88:9980 {
        insecure_skip_verify
        transparent
    }
}
 

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
@NasKar Certification services are off in the Collabora Docker container. In the Caddy Collabora code block, change https references to http and see if that makes a difference.
 
Last edited:

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
What were the parameters you used for the docker collabora?
Code:
sudo docker run -t -d -p 9980:9980 \
--name=CODE \
-e 'domain=cloud\.mydomain\.com' \
-e 'server_name=codetest\.mydomain\.com' \
-e "username=admin" -e "password=secret" \
-e "extra_params=--o:ssl.enable=false --o:ssl.termination=true" \
--restart always --cap-add MKNOD collabora/code

I've been avidly following your discussion in the Nextcloud forum thread Is there a guide how to setup Collabora/Code docker if the reverse proxy is on a different machine?
 
Last edited:

Basil Hendroff

Neophyte Sage
Joined
Jan 4, 2014
Messages
1,049
Basil Hendroff updated Nextcloud and Collabora Integration with a new update entry:

Minor update

Just some minor tidying up, removal of superfluous commands and updates to 'humanise' this resource a little more and to match it more closely to the Nextcloud and OnlyOffice Integration resource.

Update instructions are provided below for those who have used the original version of this resource. While this step is entirely optional, future releases of this resource will use Docker Compose...
Read the rest of this update entry...
 

NasKar

Neophyte Sage
Joined
Jan 8, 2016
Messages
594
@Basil Hendroff decided I wanted to be able to use the editor on my IOS device. Tried it again from scratch and it worked. Not sure what the difference in my Caddyfile was that prevented it from working but here is the working version.
Code:
mydomain.cf {
root /usr/local/www/html/
}
cloud.mydomain.cf {

  gzip
  proxy / http://192.168.5.81 {
    transparent
  }
}

collabora.mydomain.cf {
  # Static html, js, images, etc. served from loolwsd
  # Loleaflet is the client part of LibreOffice Online
  proxy /loleaflet http://192.168.5.89:9980 {
    insecure_skip_verify
    transparent
  }

  # WOPI discovery URL
  proxy /hosting/discovery http://192.168.5.89:9980 {
    insecure_skip_verify
    transparent
  }

  # Main websocket
  proxy /lool http://192.168.5.89:9980 {
    insecure_skip_verify
    transparent
    websocket
  }

  ## Admin console websocket
  #proxy /lool/adminws http://192.168.5.89:9980 {
  #  insecure_skip_verify
  #  transparent
  #  websocket
  #}

  # Show capabilities as json
    proxy /hosting/capabilities http://192.168.5.89:9980 {
    insecure_skip_verify
    transparent
  }
  # Download as, fullscreen presentation and image upload operations
  proxy /lool http://192.168.5.89:9980 {
    insecure_skip_verify
    transparent
  }
}

Thanks for your help.
 
Top