Improvements for Nethserver-Collabora

check in the messages log transaction when you need to start your action

except for the above, think i’v got the objectives. Running some tests and - out of time here.

Feel free to commend/review/scrutinize the changes I made:

2 Likes

I tested on a running server and a fresh install on a VM but no success this time.
I got an unauthorized wopi host error on the running server and on the VM the connection to the wopi host could not be established…

When the loolwsd virtualhost prop is unset, the Nextcloud app is not configured and collabora.server-domain is not set as wopi_url.

I think something like this would be needed (or maybe use a variable wopiurl when calling occ to have less code) :

#Configure Nethserver-Nextcloud

if [[ -x "/usr/local/sbin/occ" ]]; then

  /usr/local/sbin/occ app:install richdocuments

  if [[ -n `config getprop loolwsd VirtualHost` ]]; then

    /usr/local/sbin/occ config:app:set richdocuments wopi_url --value=https://`config getprop loolwsd VirtualHost`

  else

    /usr/local/sbin/occ config:app:set richdocuments wopi_url --value=https://collabora.`config get DomainName`

  fi

fi

/usr/local/sbin/occ app:enable richdocuments

After that change it’s configured but still not working, so maybe some new/changed loolwsd settings like localhost or IPV4 are a problem.

The cert check seems not working, it’s always set to disable cert verification.

I’m going to do some more tests tomorrow…thanks for your work!

1 Like

hmm, works here :thinking:

Did you clone my git-repo and locally build nethserver-collabora on the tlc_wip branch to include the commits made so-far?
(NOTE: I tend to --force push on wip-branches to keep it tidy in the end)

As said before have an dns entry in the lan-dnsserver for collabora.server-domain
If curl can not resolve collabora.server-domain it will not exit 60 on an un-trusted cert here:

1 Like

Have one strange quirk:
Always need to refresh my (firefox) browser to open a new document :confounded:

No, I didn’t checkout the tlc_wip branch. :sleepy:
Tests will follow…

EDIT:

When using the correct branch it’s working like a charm. :clap:

Just for info: I needed to browse to collabora.server-domain first and allow the self signed cert in Firefox else Collabora shows an error where it’s not possible to allow the cert.

Same here with Firefox and Chrome.

There’s an open issue:

Great feedback again :+1:

Same here, guess this needs to be documented (same behavior with M$-Edge).

1 Like

Good idea, just to avoid support questions.
Onlyoffice has the same browser issue when using self signed certs.

In the end of the day a lot of the possible hickups can be avoided if (default) setup on installation can run on the default virtualhost (ie server FQDN) instead of a virtual host.

  • No worries about dns settings
  • If the certificate is invalid the user might have made a exception for this…
  • Would use the (valid) let’s encrypt cert of the server if requested by the user…

Risk is nethserver-collabora breaks the default virtualhost. Would be a bit more comfortable if loolwsd had it’s own location like /loolwsd (Server-FQDN/loolwsd) and we (Reverse)ProxyPass from there.

2 Likes

My knowledge of the Apache web-server (or web-servers in general to be precise) falls to short to accomplish this.

If someone can make it work, post your configs. :orange_heart:
And I’ll try to make a template for it. :grinning:

2 Likes

@syntaxerrormmm found a bug :+1:

It is addressed in my tcl-wip branch and to make our live easy opened a PR to invoke the (nethbot) auto-build.

(ATM: nethserver-collabora-0.1.2-1.9.pr7.gfb51eaf.ns7.noarch.rpm)

1 Like

what is the state of collabora and php73, I saw it is not released ?

If you mean using the same rh-php7x nethserver-nextcloud depends on;
It is fixed and released using the wrapper provided by nethserver-nextcloud.

what rpm number, I installed yesterday and I use the older php version I bet…

fixed yes but released sure ?

my rpm version are

[root@ns1 ~]# rpm -qa | grep collabora
collaboraoffice6.2-ure-6.2.10.3-3.x86_64
collaboraoffice6.2-6.2.10.3-3.x86_64
collaboraofficebasis6.2-draw-6.2.10.3-3.x86_64
collaboraofficebasis6.2-writer-6.2.10.3-3.x86_64
collaboraofficebasis6.2-core-6.2.10.3-3.x86_64
collaboraofficebasis6.2-images-6.2.10.3-3.x86_64
collaboraofficebasis6.2-impress-6.2.10.3-3.x86_64
collaboraofficebasis6.2-ooolinguistic-6.2.10.3-3.x86_64
collaboraofficebasis6.2-calc-6.2.10.3-3.x86_64
collaboraofficebasis6.2-graphicfilter-6.2.10.3-3.x86_64
collaboraofficebasis6.2-ooofonts-6.2.10.3-3.x86_64
nethserver-collabora-0.1.2-1.ns7.noarch
collaboraofficebasis6.2-extension-pdf-import-6.2.10.3-3.x86_64
collaboraofficebasis6.2-en-US-6.2.10.3-3.x86_64

Yes this includes the fix for rh-php7x

1 Like

Note : you still need to set it up as described in README.rst
EDIT: above applies to version nethserver-collabora-0.1.2-1.ns7.noarch not the wip-package

To get rid of most additional steps to configure nethserver-collabora and make it more stable at updates is what this "TLC"efffort is about. :grinning:

1 Like

Well, tried the first round yesterday, but found out that probably the droplet I created was too small in RAM. Will retry in some hours :slight_smile:

1 Like

same for me, someone has a clue ?

As @mrmarkuz mentioned above it seems to be a upstream bug in the richdocuments netxtcloud app

2 Likes

In the CODE repo there’s only version 6.0 and 6.4. I’d like to get some dictionaries for our version 6.2. I don’t understand because 6.2 should be LTS from what I saw here.

Install code repo:

sudo yum-config-manager --add-repo https://www.collaboraoffice.com/repos/CollaboraOnline/CODE-centos7

EDIT:

Version 6.4 working here with dictionaries.

Collabora is named like collaboraofficebasis6.4* whereas the dictionaries are named like

yum install collaboraoffice6.4-dict-en collaboraoffice6.4-dict-de collaboraoffice6.4-dict-es

2 Likes