FireFox Sync Server

Thursday, November 30. 2017

After years of Chromium as my default browser I've moved to give FF a new go after the release of v57 aka Quantum. Mozilla is still more trustworthy than Google and hey, I prefered Netscape over Mosaic once. Part of the shift was trying out FireFox sync. Since I have not much trust in the cloud unless it is my own server this meant installing Firefox Syncserver on my debian server.

I more or less followed the howto from sathya.de/blog/how-tos/setup-your-own-firefox-1-5-sync-server-on-debian-with-apache2-and-mysql/ , there are links to the mozilla docu included on his site. The basic steps are easy to take, with dns.he.net and letsencrypt with dehydrated setup of a new subdomain with a valid SSL-certificate has gone down to a matter of minutes.

Git clone the server, create a db and db-user, config the virtualhost in the web servers configuration, edit the default syncserver.ini, restart the webserver and then tell the clients in about:config which syncserver to use. Pretty basic, but it still has some potential for confusion and took me two runs to get it running.

the supplied syncserver.ini has an entry   public_url = http://localhost:5000/   which appears to suggest that ports should be defined in the server config, client config. But this is not so, in a production environment with https and a web server non ports are given.

I saw 404 errors in the error_log which stemmed from an error with the client config, I had erased the token/ - ppart of the uri. And I experienced a multitude of 500 server errors with traces in the error_log pointing at a line between Public_url = ... and allow_new_users = ...
The first complained the given secret exceeded the maximum length, while it had been created like the comments advise. Later I saw errors from parsing the sqluri. Many visual checks did not find a problem.

What helped me was a set of voodoo measures including: manually retyping the sqluri line  and  inserting a 'dummy = stupid' line supposed to catch any non-visible carried syntactical elements. Other possible sources of problems here include permissions issues and missing execution flag on the wsgi file.

And then, suddenly, it worked.

 

Geschrieben von daniel Abgelegt in WebServer.
Comments (0) Trackbacks (0)

Install and config of Collabora with nextcloud on debian with apache2 without Docker.

Thursday, November 16. 2017

Debian 9.2

Apache/2.4.25 (Debian)
Nextcloud 12.0.3
 
https://github.com/husisusi/officeonlin-install.sh/blob/master/README.md
https://github.com/husisusi/officeonlin-install.sh/issues/135
 
mkdir a folder for the script, clone or download the .zip
open officeonline-install.cfg with an editor and adapt the POCO parameters like ExaconAT shared it in the issue 135 (link above)
 
let the script run (started it w/o any parameters). It took about 80 min on my box.
I had to restart the script once because it complained over an inconsistency in /etc/group which needed to be fixed first. After restart the script managed to resume where it had stopped before.
 
created a subdomain for the lool (LibreOffice OnLine) to run in in DNS, a valid certificate for https, a virtual host config to tell apache how to proxy. Check that Apache has the required modules enabled:
proxy_wstunnel proxy proxy_http ssl
 
For the latter I used the example Nextcloud recommends in https://nextcloud.com/collaboraonline/ and this was a source of problems later. It took me hours of try and error & recherche to learn that all the ProxyPassReverse lines need to have a trailing slash at the end of the right hand argument. The relevant bit of the config I use is:
 
# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode

# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off

# keep the host
ProxyPreserveHost On

# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass           /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse    /loleaflet https://127.0.0.1:9980/loleaflet/

# WOPI discovery URL
ProxyPass           /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse    /hosting/discovery https://127.0.0.1:9980/hosting/discovery/

# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon

# Admin Console websocket
ProxyPass   /lool/adminws wss://127.0.0.1:9980/lool/adminws

# Download as, Fullscreen presentation and Image upload operations
ProxyPass           /lool https://127.0.0.1:9980/lool
ProxyPassReverse    /lool https://127.0.0.1:9980/lool/
 
The script creates a self signed certificate for lool in /etc/loolwsd
This is not helpful when things do not work at once because chrome and firefox are so very strict against self signed certs and any direct tests of the lool subdomain and the virtual host there are hindered. I got around this by changing the path to the certificate (cert, ca-chain privkey) to point at my valid cert by edit in /opt/online/loolwsd.xml. An increased log level here and file enable="true" are other useful settings here. 
 
Things look fine when https://lool.domain.tld:9980 results in an empty page with ok and https://lool.domain.tld:9980/hosting/discovery returns an xml of wopi discovery. If the latter gives a 500 then the proxy config may be the reason.
 
In nextcloud admin Collabora Online the entry is https://lool.domain.tld:9980 - during my recherche I found several discussions with recommendations to not include the port, but this only adds another error.
 
Sources of error messages included nextcloud admin logging (connection refused as long as the proxying doesnt work), /var/log/loolwsd.log (needs log level increased and file enabled) and of course the messages of systemctl status  loolwsd and systemctl status apache2
 
 
 
Geschrieben von daniel
Comments (0) Trackbacks (0)
(Page 1 of 1, totaling 2 entries)