Open strugee opened 1 year ago
We make heavy use of spreadsheets for Finance and Partnerships committees. They are currently on a private Nextcloud instance. Support for inline collaborative editing is required to move the spreadsheets over to SeaGL instance.
The other instance is using Nextcloud Office to connect to a Collabora Online instance.
@lufthans would you like this service to be running on the same server as NextCloud, or would you prefer it running on a separate VM? Also, it recommends we setup a separate domain for this (i.e. office.seagl.org
), would that work?
I'm happy to set up any DNS records you need. As for the VM question, I don't think it really matters - we just care about the end result. I leave it up to your judgement. (We can also just change it later - maybe we could start with it on the same VM to increase resource/process density and move it if we have perf problems?)
👋 Hey peeps! Salt mentioned SeaGL is still wanting to get free of the googs. I'm all about that (sorry, shameless self-promo there), so I'm here to help as long as I'm helpful.
First thing is to just sort out that--as far as I know--Nextcloud Office is just a re-branded CODE (Collabora Online Development Edition), so let's consider them synonyms. Onlyoffice also exists. It works differently: mostly c lient-side. I've heard it might be fine as well, but I won't discuss it here.
I've been running Nextcloud+CODE for several years now with a handful of users. I've found it stable and low-maintenance. I'm using their official image.
I run both Nextcloud and CODE on bare metal (in Docker containers, in one docker-compose.yml
), reverse-proxied behind Traefik. My server has plenty of CPU and RAM so I'm not exactly sure what resources a comparable CODE-only or Nextcloud+CODE VM would need, but I have a few numbers that may help. Watching docker stats
while using the Nextcloud+CODE web ui, my CODE container appears to use very little CPU. "Mem usage" says 718.2MiB. It feels fast and responsive. So maybe 1 core and 1GB RAM, just for CODE, then add on whatever the VM itself needs for its OS. The image size is about 1.5GB and docker system df --verbose
says the container is using about .5GB.
Config is fairly straightforward, I just followed the docs. My env vars are:
extra_params="--o:ssl.enable=false --o:ssl.termination=true --o:welcome.enable=false --o:home_mode.enable=true"
dictionaries: en
username: REDACTED
password: REDACTED
DONT_GEN_SSL_CERT: nonemptyvalue
home_mode
might be fine if we can live with 20 max connections and 10 max open docs. If not, we should probably request a license. Might even be free for nonprofits, I don't know. There's a corresponding config value in coolwsd.xml
and I'm not sure which one wins if they differ.
I believe coolwsd.xml
is the only necessary saved state.
I'm happy to share more and chat more (here, phone, email, Signal, Matrix, whatever).
@strugee - I still haven't had time to log on to the server you set up, sorry about that. I'll document a few things here anyway as a way to capture the knowledge and start to refresh my memory.
Relevant docs: https://sdk.collaboraonline.com/docs/installation/CODE_Docker_image.html
Here's what I think is the simplest most relevant docker-compose.yml
for the intended server:
version: '3.5'
services:
collabora:
image: collabora/code
restart: unless-stopped
tty: true
ports:
- '9980:9980'
environment:
extra_params: "--o:ssl.enable=false --o:ssl.termination=true --o:welcome.enable=false --o:home_mode.enable=true"
dictionaries: en
username: "$COLLABORA_USERNAME"
password: "$COLLABORA_PASSWORD"
DONT_GEN_SSL_CERT: nonemptyvalue
We'll need a .env
file too:
# I can't recall what these are used for... I think just some CODE admin ui
# that I've only had to glance at once every 24 months or so. I set a
# password just to lock it down, although disabling it somehow would be
# even better.
COLLABORA_USERNAME=admin
COLLABORA_PASSWORD="redacted_something_super_secure_i_guess?"
# only needed for the more detailed example below
COLLABORA_HOSTNAME=example.com
These files should be placed in a folder called nextcloud
... docker-compose will use that to name related Docker objects such as images and containers.
Here's my docker-compose.yml
for my live self-hosted Nextcloud Office (collabora CODE) instance. It assumes an extant /opt/collabora-coolwsd.xml
file, some Docker networks (I'll come back to that), traefik is the reverse proxy (and that traefik is handling SSL termination), and a sibling .env
file exists such as the one above.
version: '3.5'
services:
collabora:
image: collabora/code
restart: unless-stopped
labels:
- "traefik.enable=true"
- "traefik.http.routers.collabora.entrypoints=websecure"
- "traefik.http.routers.collabora.rule=Host(`$COLLABORA_HOSTNAME`)"
- "traefik.http.routers.collabora.tls.certresolver=myresolver"
networks:
- nextcloud
- traefik_default
cap_add:
- MKNOD
tty: true
environment:
extra_params: "--o:ssl.enable=false --o:ssl.termination=true --o:welcome.enable=false --o:home_mode.enable=true"
dictionaries: en
username: "$COLLABORA_USERNAME"
password: "$COLLABORA_PASSWORD"
DONT_GEN_SSL_CERT: nonemptyvalue
volumes:
- /opt/collabora-coolwsd.xml:/etc/coolwsd/coolwsd.xml
networks:
nextcloud:
name: nextcloud
traefik_default:
external: true
To use a different reverse proxy, just remove the whole labels
stanza and, I presume, expose port 9980 with a ports
stanza. I forget why I give the container MKNOD
privs, I can dig around for that if you like. You can also just try omitting it per my initial simple example up top. I also notice collabora is running as the root
user: this is less secure than an unprivileged user, and unnecessary. user: 'nobody:nobody'
would do the trick (assuming nobody
exists on the host and is unprivileged: otherwise use, e.g. user: '65534:65534'
-- again, assuming 65534:65534 is unprivileged). This container has user nobody
and group nobody
with UID and GID 65534
and 65534
, respectively. The container might also do its own privilege dropping: I notice when I run docker run --rm -it collabora/code bash
I become the unprivileged cool
user. Good for them.
I think you can skip overriding coolwsd.xml
, but I can't recall exactly right now.
Finally, the networks. Adding the traefik_default
network is how I allow traefik to talk directly to containers such as this one. If you use a different reverse proxy, just omit this as well as the networks
stanza in the collabora
service. I think the nextcloud
network is actually superfluous here, but I'm not certain.
Whew, you're still here. Ok, last stuff:
/settings/apps
in your Nextcloud serverThat's it, the rest should just work. /settings/apps
will show errors or a green checkmark. Creating and collaborative editing office docs should work as expected.
Update: we've deployed this ourselves, so this is no longer even remotely urgent - though of course we'd still love to drop our own setup in favor of a managed one.
See https://github.com/osuosl-cookbooks/proj-seagl/issues/1#issuecomment-1633110391 and https://github.com/osuosl-cookbooks/proj-seagl/issues/1#issuecomment-1635236296 for context.
We will likely begin using this immediately when it's available - spreadsheets would be particularly useful I think; shared text documents I think we can just use Nextcloud's Text app for. I haven't actually tried it on the SeaGL instance but even if it doesn't work, we can continue using our existing Etherpad too. That being said, we can definitely find workarounds in the meantime. So this is not in any way urgent IMO.