Continuing this discussion here in this wiki-fied post…
(recap) The objective are :
Improve stability on updates in non interactive shells.
If the NS instance you install nethserver-collabora on has nethserver-nextcloud installed and is the DNS-server: it should work out-off the box on virtual/wopi host collabora.server-domain except for the certificate issue
If a loolwsd VirtualHost prop is set it respects this.
Redirect http > https on virtualhost except for acme http-01 challenge
If the virtual/wopi host does not have a valid cert and nethserver-nextcloud is installed on the same instance try to Disable certificate verification
Enable certificate verification on certifate-save event if the cert is valid.
Update documentation in README/documentation/wiki :
Reflect the changes made about what the package does.
Provide documentation to include exception in web-browser if cert is invalid.
Provide documentation to set AllowWopiHost if Nextcloud runs on an other instance.
Update CODE-brand, loolwsd, collaboraoffice6.x
For the time being enabled issues in my fork to get a bit organized before opening an issue in Nethserver/dev.
(moderator(s) feel free to merge 7 to 14 into this post )
action takes a number to start before or after the template, and before or after the service start in your createlinks
basically you launch the action
0 < action number < 10 before template expand
10 < action number < 90 after the template expand but before the service start
90 < action number < 100 after the service has been restarted.
in your case create an action with the 21 number
this will start you action after the nethserver-collabora-conf
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!
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:
No, I didn’t checkout the tlc_wip branch.
Tests will follow…
EDIT:
When using the correct branch it’s working like a charm.
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.
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.