Dans chaque application que l'on a installé, apparait en surbrillance (voir l'image ci-dessous) un icône qui permet à tout moment de revenir sur la partie sso / tuiles listant toutes les applications auxquelles un utilisateur a accès.

On peut vouloir masquer cette icône. (Ca a été le cas pour moi, pour une instance Nextcloud que j'utilise en démonstration, installé sur une base Yunohost pour plus de facilité).

Pour masquer cette icône, il faut donc aller dans les fichiers de configuration nginx lié à l'application et commenter la ligne :

On relance Nginx pour prendre en compte cette modification :

Et on rafraichit la page dans son navigateur, l'icône est masqué / n'apparait plus.

Régulièrement lors du lancement des mises à jour via l'interface web de Yunohost, dans la partie administration, dans les logs qui apparaissent en haut de l'écran, je voyais apparaître les lignes suivantes :
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. The stty program didn't work. at /usr/share/perl5/NeedRestart/UI.pm line 50.

Dans le fichier /var/log/yunohost/yunohost-api.log, je retrouve le même type d'informations :
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. The stty program didn't work. at /usr/share/perl5/NeedRestart/UI.pm line 50.

J'ai creusé un peu et j'ai trouvé que c'était lié à
un bug de l'outil NeedRestart.

L'utilitaire needrestart permet de vérifier si les services utilisent bien les dernières bibliothèques ou librairies suite à une mise à jour de sécurité. Tout comme checkrestart, il vérifie tous les processus et liste ceux qui ont besoin d'être redémarrés. Alors pourquoi needrestart à la place de checkrestart ? Tout simplement, needrestart soutient les nouvelles technologies comme LXC et Docker. Source : MemoLinux - needrestart : vérification des services à redémarrer suite à des mises à jour de sécurité

En effet, j'ai bien installé cet outil dans le cadre de l'administration de ma machine (au delà des outils graphiques fournis par défaut dans la partie web l'administration de Yunohost).

Dans ce même descriptif de bug, https://github.com/liske/needrestart/issues/86, on retouve un lien vers des patchs et une solution corrective.

La soluion est donc de modifier unfichier en commentant deux appels / fonctions.

J'ai appliqué ça. Me reste à investiguer un peu plus pour savoir si le patch est appliqué dans Debian 9, si oui pourquoi il n'a pas été mis avec une mise à jour du logiciel NeedRestart...

A voir également

La série d'articles Yunohost et plusieurs instances de Nextcloud :
Yunohost et plusieurs instances de Nextcloud (1/N)
Yunohost et plusieurs instances de Nextcloud (2/N).
Yunohost et plusieurs instances de Nextcloud (3/N).

Introduction

Par soucis de facilité, j'ai installé Nextcloud, Collabora et Onlyoffice via les paquets sur Yunohost. Les 3 applications sont sur des sous-domaines dédiés.

Une cohabitation Nextcloud, Collabora, Onlyoffice, c'est possible ?

Dans les instances Nextcloud, j'ai ajouté les 2 applications Collabora et Onlyoffice. J'ai configuré ces dernières avec l'adresse des sous-domaines respectifs.

Pour Onlyoffice, j'ai en plus choisi les formats par défauts qui devaient être ouverts pour cette application, soit les formats MS-Office (.docx, .xlsx, .pptx) :

Et la cohabitation se fait sans soucis.

Quand je veux créer un nouveau document, j'ai le menu complet suivant :
Document : Nouveau document avec une extension .docx, s'ouvre ensuite dans Onlyoffice
Feuille de calcul : Nouveau document avec une extension .xlsx, s'ouvre ensuite dans Onlyoffice
Présentation : Nouveau document avec une extension .pttx, s'ouvre ensuite dans Onlyoffice
Nouveau Document : Nouveau document avec une extension .odt, s'ouvre ensuite dans Collabora
Nouvelle feuille de calcul : Nouveau document avec une extension .odc, s'ouvre ensuite dans Collabora
Nouvelle présentation : Nouveau document avec une extension .odp, s'ouvre ensuite dans Collabora

Et idem,
si je clique sur un document existant au format MS-Office (.docx, .xlsx, .pptx), c'est Onlyoffice qui s'ouvre.
si je clique sur un document existant au format OpenDocument (.odt, .odc., .odp), c'est Collabora qui s'ouvre.

Ainsi, je peux travailler avec l'outil le plus adéquate selon le format de fichier, je peux aussi faire des démonstrations (j'ai fait les mêmes branchement sur une instance Nextcloud uniquement liée à la démonstration)...

Reste à voir la charge d'avoir plusieurs utilisateurs avec toutes ces instances, Onlyoffice, Collabora en parallèle sur une même machine. Ce sera un sujet de billet de retour d'expérience.

Collabora ?

Dans le monde de la bureautique en ligne avec Nextcloud, il y a deux écoles : Collabora et Onlyoffice. Il faudra que je fasse un billet dédié sur le sujet.

J'ai donc voulu installer Collabora sur mon instance Yunohost sur laquelle j'ai un Nextcloud.

La galère

J'ai passé pas mal de temps à regarder dans les forums, à tester, à installer et désinstaller l'application packagée, à essayer en faisant à la main en installant Collabora avec Docker, avec les paquets sans succès.

Jusqu'à trouver la manipulation suivante qui marche :

La solution

On crée un sous-domaine, par exemple collabora.mondomaine.fr, dans l'enregistrement DNS.

Dans l'interface d'administration de Yunohost, on ajoute ce domaine dans Yunohost, on mets des certificats SSL via Let's Encrypt, toujours via l'interface d'administration.

Issu du forum de Yunohost, il faut utiliser la branche testing de l'application en passant des paramètres particuliers. Je fais donc ça en ligne de commande (via SSH) :

Et j'associe l'application au sous-domaine, à la racine de celui-ci (soit collabora.mondomaine.fr) quand on me le demande (on a l'équivalent en ligne de commande d'une installation classique d'une application pour Yunohost).

Ensuite, on ajoute l'application Collabora dans Nextcloud via un compte administrateur.

Et dans la configuration de l'application, il faut mettre https://collabora.mondomaine.fr SANS LE PORT (ne pas mettre de port comme dans l'exemple donné par défaut dans le champ de saisie qui indique https://collabora_serveur:8090).

Conclusion

Collabora est disponible est accessible pour les 3 instances Nextcloud qui tournent sur le même serveur, il suffit de mettre le même paramétrage indiqué ci-dessus.

Reste à faire : tester la charge avec plusieurs utilisateurs.

Explication technique

Il faudra creuser / regarder le script d'installation en détail du paquet Yunohost, mais voici quelques explications techniques :
* Nextcloud et Collabora sur le même serveur.
* Nextcloud est installé en tant qu'application packagée Yunohost,
* Collabora est installé en tant qu'application packagée Yunohost non stabilisée / beta, les scripts sont alors installé Collabora via les paquets Debian officiel.

Cette application écoute sur le port 8090 et c'est Nginx qui fait la redirection / qui sert de proxy.

Je mets aussi des paramètres particuliers que l'on trouve dans le fichier /etc/loolwsd/loolwsd.xml. Ces paramètres sont bien renseignés dans le cas d'une installation de Collabora via le paquet Yunohost, mais pour ceux qui feraient des installations manuelles, cela peut toujours servir comme informations.


* ssl > enable > false
* ssl > termination > true
* storage > wopi > Ajout d'un élément sous la forme moncloud\.chezmoi\.fr
* storage > ssl reste inchangé