Arch Linux User Repository

The tmpfile has an issue:

Detected unsafe path transition /etc/coolwsd (owned by cool) → /etc/coolwsd/coolwsd.xml (owned by root) during canonicalization of /etc/coolwsd/coolwsd.xml.

@electricprism: Thank you for notifying me. Collabora made a major upgrade in their packaging, with:

• a global change (user name, program name…) from lool to cool;
• a change in versioning, with new versions being apparently based on the 2-digit year.

I hope it is fixed now.

Unknown dependency: loolwsd
error: failed to download sources for 'collabora-online-server-nodocker-6.4.11-1 (collabora-online-server-nodocker_en)':
error: packages failed to build: collabora-online-server-nodocker-6.4.11-1 (collabora-online-server-nodocker_en)

@kesherAUR: Indeed, they do. You should:

• either edit PKGBUILD (top of the file) to set your wanted language,
• or build everything, but install only the packages that you want.

Here is an example modification: https://yalis.fr/git/yves/home-server/src/branch/master/roles/nextcloud_back/tasks/main.yml#L32

en-gb and en seem to conflict with each other - en contains en_GB directories as well.

@andrej: the nginx and apache configs you mention are just tls-reverse-proxy examples and should work outside of docker as well. collabora-office can establish encrypted connection by itself if configured correctly and supplied with certs, so it depends on your setup if you need use these examples.

nexcloud-systemd-timers just runs the cron jobs required by nextcloud and has nothing to do with collabora-office.

The package does not require nextcloud because it just supplies the online document editing functionality independently from nextcloud and can be used with other cloud file storage systems as well.

For differences between collabora and libreoffice consulting the search engine of your choice should answer the question.

Is there an ArchWiki page for this? I could only find this short chapter on the Nextcloud page, which is not very informative. For example, can the Apache and Nginx configuration from the Docker chapter be applied also in the non-Docker case? Which of the other tips and instructions apply? (Should one install nextcloud-systemd-timers etc.?)

The package dependencies are also a bit of a mystery. For example, why doesn’t this depend on nextcloud from community? That looks concerning, because it’s unclear to what extent it can share an existing nextcloud configuration without too much duplication + hassle.

On the same topic: How is this package related to libreoffice-online? IIUC, libreoffice-online (in its vanilla form) is just a server serving a HTML5 office suite without any cloud access / online editing, which can store files on the end users’ local disks. Does CODE / Collabora reuse / depend on LOOL or not? Or does it contain a modified version of it?

Can the CODE functionality be configured (perhaps in a somewhat more modular way) using a combination of nextcloud and libreoffice-online?

Hi, I've got trouble with capabilities on loolforkit and loolmount.

Here what I do to manually fix the permission issues:

setcap cap_chown,cap_fowner,cap_sys_chroot,cap_mknod=ep /usr/bin/loolforkit
setcap cap_sys_admin=ep /usr/bin/loolmount

this even works in a systemd-nspawn system.

I see some permission already there for loolforkit. it seems to needed chown also. And loolmount need admin for mount/umount.

@theYinYeti, you should be able to strip all the makedependencies that are already in base-devel and base, as those can be assumed as installed for all packages.

Specifically, that means you can drop bzip2, coreutils, gawk, grep, gzip, sed, systemd, tar, util-linux, xz (see base). libcap and curl are also transitively included via iputils and libelf.

The only thing that is left then is fontconfig.

To be clear, I am only referring to the makedeps array, not any content within e.g. _upstream_equiv, I have no clue about that :D

@electricprism: I admit this package is somewhat unusual. It is however not too far from the Linux/Unix standard because /opt is a standard location for software that is not installed from official packages. I can’t change that: it is not built from source, but instead build from a .DEB packaging targeted at Debian.

As for TLS, since it is a complicated subject (even when using the ACME protocol), I think it is best to leave TLS termination to Nginx or HAProxy. Users still can setup TLS by themselves, though; I just won’t.

Last but not least, thank you for notifying me of the missing systemd dependency! That’s the problem with this package: I always have to catch-up with what is going on upstream…