here’s a first module draft (not for production!) of the Collabora CODE Office suite built from the howto. Installation instructions are in the wiki
Features:
app widget for collabora admin
autoconfig of nextcloud richdocuments app
custom domain
works with fresh Nextcloud 14
Open/Todos:
CODE uses the loolconfig tool to configure loolwsd via /etc/loolwsd/loolwsd.xml. I didn’t template it because templating makes loolconfig useless. In /etc/e-smith/events/actions/nethserver-collabora-conf I do most of the config part with loolconfig. What do you think, loolconfig or template?
collabora uses an external repository. It installs many packages. Do you see a possibility to make one package out of it to avoid the external repo?
Now the loolwsd servce runs https which is not necessary as it’s reverse proxied but it didn’t work for me without HTTPS. I’d like to go HTTP to avoid certificate creation.
Now a static admin is used but it seems possible to use PAM auth, don’t know if it’s necessary for the admin page…
Maybe we can add some defaults:
Please check the code and share your thoughts. Comments are always welcome!
Usually we do what upstream wants and follow the docs. But the package maintainer can evaluate if it’s wise to follow another approach. If the XML is not too complex, expanding it with a template could be acceptable. Take care of &
In ns6 I used a “mixed” approach with SOGo, when they dropped the .conf file and pushed the config command named “defaults”. I defined an action that pipes the templates output to default
I think docker is the way to go if direct installation does not work at all.
I am working on integrating koha that needs lots of perl modules and additional packages not provided by centos. So I am going to try the docker way with Koha.
Leaving the UX “everything is a file” philosophy is a inseverable trend and some of us (me among them) regret this. Some applications store their settings in a database and it is understandable as configurations get more complex. IMHO Unless the features of a configuration file are well documented and an application comes with a configuration tool: use it.
You know my view on this So looked in to it a bit. Basically it installs the Collabra LTS (base) components of LibreOffice. Hence the big amount of packages. As an purist i would be interested if we can succeed in rebuilding it or if it can run stable on the Libreoffice base from centos repo’s. I doubt the latter and suggest to valuate / take this on in the future to be sure we do not encounter regressions on behalf of this principle.
Note: Collabra is one of the main contributors of Libreoffice and their source code is a branch of theLibreoffice git repository. Github mirror:
Why not use a copy of the default server certificate?
IMHO A local administrator account is inevitable if a application / module should work with a remote account provider. You can not be sure the Nethserver default admin user is present.
Moreover for applications which bind to the LDAP directly and this bind setting can be configured in an admin page of the application it’s dangerous to rely on the LDAP for a administration account.
If a user edits this settings and loses connection with LDAP/AD the application is a dead fish in the water: it’s impassible to correct your mistake!
This being said, i like the idea to standardize it as much as possible and admin / Nethesis,1234 comes in to mind. (unfortunately it is impossible with nethserver-gitea )
Agree, it could always be templated later on if we accept loosing the config tool.
Me too. I really have to get into (re)packaging because nearly any of my modules uses an external repo or some install script. In the end packaging is most work but the most professional way as we decide version and updates.
Thanx, that would be possible. I just had to copy the cert and change permissions (SECURITY!) but I’d like to get rid of the cert at all and use localhost http.
That’s right. The question was more if PAM auth is necessary in general as it’s just an admin overview page. I fully agree, default app admin is enough for now.
That’s a great idea as I may just put the pw hash in the config file and I am done with admin user setup. It may be changed by loolwsd or Nethgui (vision) later.
I would not drop the https route. Especially when the service is an internet facing service, IMO https should be mandatory. We already have a great LE procedure implemented. Why not use it?
You’re absolutely right but in this case I am talking about the internal https connection. You still connect via HTTPS (letsencrypt) but are reverse proxied to the localhost https service which is not necessary IMHO.
It took a while before I had it running due to self-signed (CA) certificates, run a private PKI in the test environment. And will do a new fresh install after including my CA in nextcloud.
Hi did the fresh install: nextcloud 13, ldap accounts provider.
Until now I can not login to the admin page.
Also after changing the password with loolconfig set-admin-password.
The storage.wopi.host (what ever that may be ) defaults to example.com.
To make it work for me on the default vHost changed this to FQDN of the server
ie machine.example.com
(config setprop loolwsd Domain machine.example.com)
Maybe an option / opening to do this, found this in loolwsd.xml (included the line numbers)
57 <ssl desc="SSL settings">
58 <enable default="true" type="bool">true</enable>
59 <termination default="true" desc="Connection via proxy where loolwsd acts as working via https, but actually uses http." type="bool">false</termination>
60 <cert_file_path desc="Path to the cert file" relative="false">/etc/loolwsd/fullchain.pem</cert_file_path>
61 <key_file_path desc="Path to the key file" relative="false">/etc/loolwsd/privatekey.pem</key_file_path>
62 <ca_file_path desc="Path to the ca file" relative="false"/>
63 <cipher_list default="ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH" desc="List of OpenSSL ciphers to accept"/>
64 <hpkp desc="Enable HTTP Public key pinning" enable="false" report_only="false">
65 <max_age desc="HPKP's max-age directive - time in seconds browser should remember the pins" enable="true">1000</max_age>
66 <report_uri desc="HPKP's report-uri directive - pin validation failure are reported at this URL" enable="false"/>
67 <pins desc="Base64 encoded SPKI fingerprints of keys to be pinned">
68 <pin/>
69 </pins>
70 </hpkp>
71 </ssl>
look like it is quite difficult to set a default password and could not find a place in the admin ui to change it.
Hence the suggestion to use PAM afterall, this let me login in with domain admins with LDAP:
loolwsd.xml
<admin_console desc="Web admin console settings.">
<enable default="true" desc="Enable the admin console functionality" type="bool">true</enable>
<enable_pam default="false" desc="Enable admin user authentication with PAM" type="bool">true</enable_pam>
<username desc="The username of the admin console. Ignored if PAM is enabled.">admin</username>
<password desc="The password of the admin console. Deprecated on most platforms. Instead, use PAM or loolconfig to set up a secure password."/>
</admin_console>
/etc/pam.d/loolwsd
auth [success=1 default=ignore] pam_succeed_if.so user in [admin]
auth [success=ok default=die] pam_succeed_if.so user ingroup [domain admins]
auth include password-auth
account include password-auth
session include password-auth
Credits for the PAM configuration belong to @stephdl :
OMG, putty nano copy paste error…will be fixed soon.
loolconfig set admin_console.secure_password pbkdf2.sha512.10000.84de78d224a447158478da8b9717c3b66ac842e7217ac6b79bf864cf2cbc2d0be5b76818dd397502286295f8d31742564e0b31efac46fb6dffb6bd10ac9aacd1861af5c3311c749bc046608ee47d86f2978eedf78819bbde26e620d886eed4192234517ff1585c93dc6fde0166ba714268c89f7c41eefd77ada783ad86266dd7.1e2ecb9a387f3f5d48d167cde908f72f115c131307e556eb9c30227ffdfcf4843e3cea4fa80c4bfb830c2c1ab64c920a1902785e06c02f9365778cfd863a6fc0736db0b708a11231e2ecd47a5210b55bef7f7b0ce2f84c820b144313567845a5fa4e5b18c10d021dac5d99fb6e44876f6d39763b341a2b1533355c2485f6e248
EDIT: fixed
EDIT2:
Thanks, I added the service restart in form of signal-event nethserver-collabora-update to the wiki entry.