osuosl-cookbooks / proj-seagl

Apache License 2.0
0 stars 0 forks source link

Google Docs-style realtime editing in Nextcloud #11

Open strugee opened 1 year ago

strugee commented 1 year ago

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.

lufthans commented 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.

https://github.com/nextcloud/richdocuments

ramereth commented 1 year ago

@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?

strugee commented 1 year ago

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?)

meonkeys commented 8 months ago

👋 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).

meonkeys commented 8 months ago

@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:

  1. install the Nextcloud Office app at /settings/apps in your Nextcloud server
  2. select "Use your own server" radio button
  3. I'm not sure if that "Allow list for WOPI requests" matters... I'll need to look that up. Leave as-is and see if it works.

That'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.

strugee commented 7 months ago

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.