Improvements for Nethserver-Collabora

Feature
21

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
22

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
23

same for me, someone has a clue ?

24

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

2 Likes
25

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

image
image1895×1024 87.6 KB

image
image1899×576 63.6 KB

2 Likes
26

Did not take a possible LTS version in to consideration, i’ll gues it for collabora-subscribtion users (or build it yourself).
Did two brief update tests from 6.0 > 6.2 > 6.4 and one 6.0 > 6.4, it did not break but did only basic functional tests.
If this makes it to release i’d propose to include CODE/collabora office 6.4 in the nethforge repo.

1 Like
27

Fully agree :+1:

3 Likes
28

IMHO it is ready to go through the development/audit cycle

@giacomo do you prefer I open an issue in Nethserver/dev for this (or not),
asking because it is a nethforge module.

2 Likes
29

I’d say yes, it will help you tracking the progress. I we will add the forge tag to the issue :slight_smile:

2 Likes
30

Does this apply to all services in the (update) event ?:

event_services($event, qw(
               httpd reload
               loolwsd restart
));

Goal is to set/check the WopiUrl after httpd reload

EDIT Sorry RTFM:
https://docs.nethserver.org/projects/nethserver-devel/en/latest/events.html#order-of-implicit-actions

1 Like
31

this is the goal indeed action 91 will be triggered after the services restart

1 Like
32

Updated another server, worked without issues. :clap:

2 Likes
33

With the last commit nethserver-collabora works like intended;

The default wopiUrl (collabora.server_domain) created on installation needs to be resolvable. :thinking:

Included it in the /etc/hosts template, can not think of a cleaner method.

1 Like
34

I updated a Nethserver at work with Collabora 6.4 because there were problems with formattings and it worked and solved the format issues in first tests.

1 Like
35

Can some of you review the changes made in the PR on github?

To make a bit of a quiz: found one bogus IF statement myself…

cc/ @Amygos

Like to have “special permission” from @giacomo or @davidep on the Add default collabora WopiUrl to server-hostnames part…

2 Likes
36

You now have write access to repo so you can merge and request for review.
I will take a look to it, but it will require a little time.

In the meanwhile, @stephdl could you please take a look?

1 Like
37

Take your time :grinning:
As long as needed, I’m not in a hurry.

Pinged here because could not add reviewers and need some auditing going on in time. :yum:

1 Like
38

Will do it asap, currently in holidays but interested mainly because I installed it recently.

Either next week or sooner if possible.

3 Likes
39

I tested on a VM and found an issue. If the cert is LE but does not contain “collabora.domain.local” the cert check is not working correctly.

We catch only error 60

[root@testserver ~]# curl https://collabora.domain.local; echo $?
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.

but if you get an LE cert without adding collabora.server-domain to it you get another error 51:

[root@testserver ~]# curl https://collabora.domain.local; echo $?
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

Here’s something that works:

answer=$?

    if [[ $answer -eq 60 || $answer -eq 51 ]]; then
        /usr/local/sbin/occ config:app:set richdocuments disable_certificate_verification --value=yes
        echo "bad cert $answer"
    else        
        /usr/local/sbin/occ config:app:set richdocuments disable_certificate_verification --value=''
        echo "good cert $answer"
    fi

    /usr/local/sbin/occ richdocuments:activate-config

Maybe it’s better to do it other way round like asking if the cert is ok by checking if $? = 0 and for the rest we disable cert verification?

1 Like
40

Thanks!

Thought about that, did not want to disable the certificate-check if the host cannot be resolved.
This can be a external host (other server) and than the certicicate-update event (on that other serever) cannot correct this.
But think your suggestion is more fail-save… hence better.

1 Like