[09:25:51]
<nojhan> I can't find a config for Nextcloud's `richdocuments wopi_allowlist` that works (So far I tried `127.0.0.1,localhost,::1,<ext_IP>`). I added what I can think of in `/etc/coolwsd/coolwsd.xml` as well (the same, with \\. since it's regexps), but to no avail. What can I look at that would tell me what address(es) to set up?
[10:50:15]
<otm33> Can you share your xml (only wopi hosts section, hiding sensitive data)?
[13:30:50]
<jtm02> Hi! I installed Yunohost recently and I have trouble opening ports on IPv6 (unreachable in HTTP from outside, it says), while IPv4 is working. I use the french Orange Livebox 5. (so I speak french too). Also, 4443 and 10000 ports seems not being reachable from outside although I think I did set them properly on NAT/PAT rules. Could anyone help me? :-)
[13:32:29]
<artlog> with orange i had to activate firewall and create a rule with the specific device, ther is a bug where the device might not be displayed later while the ipv6 rule still applies to one specific device.
[13:33:41]
<artlog> i requested documentation about ipv6 firewall in this box and got ... not the expected answer, they wanted to dela directly with me to have my box setup, what i want is to understand what it is supposed to do
[13:35:06]
<artlog> well it is a sosh one, but very same for orange https://communaute.sosh.fr/t5/Ma-ligne-Internet-Livebox-email/Obtenir-une-Documentation-d%C3%A9taill%C3%A9e-de-la-configuration-du/td-p/2770396
[13:36:47]
<artlog> jtm02: en ipv6 il n'y a pas besoin de NAT/PAT . Le yunhost reçoit une adresse ipv6 qui est routable sur le net.
[13:37:38]
<artlog> La seule chose qui stoppe les paquets entrant en ipv6 c'est le parefeu de la box.
[13:38:05]
<artlog> ah et 'chez moi ça march'
[13:40:01]
<artlog> les règles qui spéficient un périphérique particulier doivent vouloir dire : pour l'adresse ipv6 destination affectée au périphérique.
[13:40:11]
<nojhan> <wopi desc="Allow/deny wopi storage." allow="true">
<host desc="Regex pattern of hostname to allow or deny." allow="true">nextcloud\.domain\.tld</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">collabora\.domain\.tld</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">domain\.tld</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">::1</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">127\.0\.0\.1</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="true">192\.168\.[0-9]{1,3}\.[0-9]{1,3}</host>
<host desc="Regex pattern of hostname to allow or deny." allow="false">192\.168\.1\.1</host>
<max_file_size desc="Maximum document size in bytes to load. 0 for unlimited." type="uint">0</max_file_size>
<locking desc="Locking settings">
<refresh desc="How frequently we should re-acquire a lock with the storage server, in seconds (default 15 mins) or 0 for no refresh" type="int" default="900">900</refresh>
</locking>
</wopi>
[13:40:44]
<nojhan> This was for otm33
[13:42:57]
<artlog> Le concept du forum où on répond à ta question en privé : c'est pas un forum.
[13:44:11]
<artlog> ce genre de communauté sosh fait penser à une secte où l'on attends la réponse du gourou...
[13:45:27]
<artlog> désolé, je m'égare , stay focus don't show feelings ...
[13:49:09]
<jtm02> No problémo ahah. Merci beaucoup pour l'astuce du pare-feu, j'ai essayé avec le port 443 et ça marche
[13:49:12]
<jtm02> https://aria.im/_bifrost/v1/media/download/ASHYbM2CY6RybP_oYhCE3t-Qn7QkzlhqZJ5RGJVsQH8xu-zpsikGPYz9Vl3x6zZweLYOEenErk77rhs6gATAw5lCecI8Os4AAG1hdHJpeC5vcmcvemJwWU91VWZzVFZPR0lPR3FUbkhtcVV1
[14:22:05]
<jtm02> It's me again! Everything is fine now with most ports. Yet, I am still getting errors for 4443 and 10000 ports :
> [ERROR] Le port 4443 n'est pas accessible depuis l'extérieur.
> - Rendre ce port accessible est nécessaire pour les fonctionnalités de type [?] (service jitsi-videobridge)
> - Pour résoudre ce problème, vous devez probablement configurer la redirection de port sur votre routeur Internet comme décrit dans https://doc.yunohost.org/providers/isp_box_config
>
> [ERROR] Le port 10000 n'est pas accessible depuis l'extérieur.
> - Rendre ce port accessible est nécessaire pour les fonctionnalités de type [?] (service jitsi-videobridge)
> - Pour résoudre ce problème, vous devez probablement configurer la redirection de port sur votre routeur Internet comme décrit dans https://doc.yunohost.org/providers/isp_box_config
In my Livebox settings I have opened 10000 UDP and 4443 TCP, both on the Firewall and Network's NAT/PAT sections. Any clues ? I'm kind of a newbie in networking stuffs
[14:27:26]
<jtm02> I installed Yunohost on an old laptop and have not did any major changes by the way. I use the french Livebox 5
[14:33:06]
<jtm02> (les hyperliens vers la doc ne sont plus bons d'ailleurs)
[14:51:30]
<otm33> Active le pare-feu personnalisé puis crée une règle ipv6 pour la machine concernée ( ipv6 + Port)
[14:55:08]
<artlog> 1) is port listeing localy on yunhost ? something like ss -ntlp | grep 4443 and ss -nulp | grep 10000
[14:55:21]
<otm33> Essaie ceci: dans la liste des hôtes, mets simplement le domaine nextcloud (avec https et sans les backslashes) -seul le premier domaine est pris en compte- Redémarre ensuite le service coolwsd.
[14:55:59]
<artlog> 2) is local yunhost firewalling autorising it ?
[14:56:11]
<artlog> 3. no fail2ban ? ;-)
[14:56:17]
<artlog> 4. is the box open ...
[14:56:46]
<artlog> you can check if it works from within you home lan network
[15:02:12]
<jtm02> Here is the output
```
# ss -ntlp | grep 4443
(nada)
# ss -nulp | grep 10000
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=143))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=142))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=141))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=140))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=139))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=138))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=137))
UNCONN 0 0 [::ffff:192.168.1.26]:10000 *:* users:(("java",pid=78850,fd=136))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=135))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=134))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=133))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=132))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=131))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=130))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=129))
UNCONN 0 0 [2a01:cb0c:b3a:e00:6e88:14ff:fe3c:4960]:10000 [::]:* users:(("java",pid=78850,fd=128))
```
[15:09:07]
<jtm02> https://aria.im/_bifrost/v1/media/download/ARNav0Q4IP8JDhatX125b6dEG1bZDjdF4KHPlvQXPOaDWOXwHUZsrykoem6uvFx-WbydXDwR4pdsoya2dKLYt0JCecJAzWbAAG1hdHJpeC5vcmcvaGJ1RGtIeVNORE5LcWd5eGpSRVZicmJH
[15:09:31]
<jtm02> Should I authorize UPnP too?
[15:11:59]
<jtm02> I don't know much about fail2ban, maybe this would help :
```
# tail /var/log/fail2ban.log
2026-02-02 15:57:55,331 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XXX - 2026-02-02 15:57:55
2026-02-02 15:57:58,225 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XXX - 2026-02-02 15:57:58
2026-02-02 15:58:00,930 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XXX - 2026-02-02 15:58:00
2026-02-02 15:59:00,603 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XX - 2026-02-02 15:59:00
2026-02-02 15:59:00,648 fail2ban.filter [92464]: INFO [pam-generic] Found XX.XXX.XX.XX - 2026-02-02 15:59:00
2026-02-02 15:59:03,351 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XX - 2026-02-02 15:59:02
2026-02-02 16:01:15,198 fail2ban.filter [92464]: INFO [postfix] Found XX.XXX.XXX.XXX - 2026-02-02 16:01:14
2026-02-02 16:01:17,055 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XX - 2026-02-02 16:01:17
2026-02-02 16:01:17,106 fail2ban.filter [92464]: INFO [pam-generic] Found XX.XXX.XX.XX - 2026-02-02 16:01:17
2026-02-02 16:01:19,811 fail2ban.filter [92464]: INFO [sshd] Found XX.XXX.XX.XX - 2026-02-02 16:01:19
```
[15:13:24]
<jtm02> I tested connecting 3 devices on a same jitsi call and it seems to work though. Maybe it's ok ignoring it?
[15:32:03]
<otm33> Je ne pense pas que les ports ouverts en UDP ''répondent'' à ce genre de test.
[16:49:48]
<nojhan> Nope, toujours l'erreur WOPI dans Nextcloud Office.
[16:52:51]
<nojhan> C'est quoi le principe général de la config des deux cotés ? Coolwsd doit accepter les requêtes depuis le domaine NextcloudOffice, et NextcloudOffice doit avoir le domaine de Coolwsd dans sa liste ? Comment je peux savoir qui essaye quoi comme addresse ?
[17:04:35]
<nojhan> OK, j'ai lu https://help.nextcloud.com/t/collabora-integration-guide/151879 et j'ai compris le principe. J'ai suivi la checklist proposée et ça passe, mais j'ai toujours l'erreur WOPI.
[17:04:55]
<otm33> Oui. Dans l'interface nextcloud, onglet netxcliud office, il doit y avoir l'adresse des deux.
[17:05:54]
<otm33> Une adresse associée pour l'erreur wopi ?
[17:07:40]
<nojhan> J'ai mis `collabora.domain.tld,cloud.domain.tld` dans la "Allow list for WOPI request", et il n'y a plus que `https://cloud.comain.tld` dans le coolwsd.xml.
[17:10:24]
<otm33> Ainsi : `<host desc="Regex pattern of hostname to allow or deny." allow="true">https://cloud.domain.tld</host>` ?
[17:11:49]
<nojhan> Oui, très exactement: `<host desc="Regex pattern of hostname to allow or deny." allow="true">https://cloud.domain.tld</host>` (copié/collé)
[17:12:50]
<nojhan> `cloud` étant le sous-domaine où Nextcloud tourne sur YunoHost, et `collabora` celui avec coolwsd.
[17:23:34]
<otm33> Je pense que tu peux vider la case "Allow list for WOPI req". Le reste m'a l'air correct mais il peut y avoir des données en cache.
[17:26:58]
<nojhan> J'ai vidé la case (du coup j'ai le warning de NCO) et essayé avec un autre navigateur, mais j'ai toujours l'erreur.
[17:27:41]
<nojhan> J'ai écumé les forums, mais je suis à court d'idée ☹️
[17:28:33]
<otm33> Lance la commande `journalctl -u coolwsd` et vois si tu y trouves `storage.wopi.host:`
[17:29:44]
<nojhan> J'ai bien `Feb 02 17:52:55 cloud.domain.tld coolwsd[11715]: storage.wopi.host: https://cloud.domain.tld
[17:39:23]
<otm33> Là, franchement... J'ai juste un doute sur https://
[17:40:44]
<nojhan> Ça ne change rien avec ou sans, de toute façon ☹️
[17:41:29]
<nojhan> Bon, je vais poster une question. C'est quel forum le mieux, par contre ? Nextcloud, YunoHost ou Collabora ? 🙂
[18:13:37]
<miro5001> Allow list devrait être 127.0.0.1
[18:22:33]
<Marcus Lee> Hello, I would like to report something concerning.
Today I saw that my CPU usage was abnormally high, so I have went to check running processes to see what happened. I then saw an "xmrig" process (I suspect is a Monero cryptominer) owned by Umami user which was heavily using my CPU. I happened to have a Yunohost Umami package installed too, which prompted me to check the Yunohost package for Umami on GitHub
[18:23:16]
<Marcus Lee> https://aria.im/_bifrost/v1/media/download/AdETzm8Xp5Ak1m9eJgwOySb6ZAr1sk9CV6OKPIBmOvhabJ5BB99jCnUXqTur4SlGxLZjLJqW41So9z7jYJTvX-5CecJL6XHwAG1hdHJpeC5vcmcvbEFkdGtPU2h5Z3FIY0FMRUJ5TGN6SVlG
[18:23:45]
<trendless> related to this? https://github.com/YunoHost-Apps/umami_ynh/issues/110
[18:24:50]
<Marcus Lee> It could be, can someone with more knowledge help out?
[18:25:21]
<Marcus Lee> I don't know if I can identify suspicious code myself
[18:26:35]
<Marcus Lee> English is not my native language so I apologise if I say something wrong
[18:33:54]
<Marcus Lee> https://aria.im/_bifrost/v1/media/download/AYeJRliZ4MLPaAVMM4efy_gjspTGnJUwL5zs8olVEIUKzQOqbO__xQpRbs0-gLzcqudrhK6OSfqz7Wj4FhCto9NCecJMhULQAG1hdHJpeC5vcmcvZUFDTGNGWld6T3h2TWhZeHJmVWFjVWhN
[18:33:55]
<trendless> Those look like normal commits to me.
[18:34:01]
<Marcus Lee> This was what I saw in my process lists
[18:34:36]
<Marcus Lee> I see, I don't have a lot of experience with git commits
[18:34:53]
<trendless> yeah, that's a common way the out-of-date version of umami you were running is exploited.
[18:35:28]
<trendless> do you have any backups of umami from before it was hacked?
[18:35:34]
<Marcus Lee> I think I have
[18:35:53]
<trendless> if so, the easiest thing would be to remove umami and restore from a clean backup. Then immediately upgrade to the latest version
[18:35:59]
<otm33> trendless: Related to this ? https://forum.yunohost.org/t/after-rallly-update-to-version-4-5-6-a-miner-is-on-my-system-version-4-5-13-fixed-many-security-issues/41051
[18:36:40]
<trendless> yeah, seems like the same nextjs/react exploit: https://security.berkeley.edu/news/critical-vulnerabilities-react-and-nextjs
[18:36:45]
<Marcus Lee> I think I'll just do a clean install of Umami, the data that I have collected is not important
[18:36:58]
<trendless> even better
[18:37:23]
<trendless> you'll still wanna keep an eye on the system to make sure xmrig doesn't persist
[18:38:23]
<Marcus Lee> I see
[18:38:30]
<Marcus Lee> Thank you for your advice
[18:39:01]
<trendless> Very welcome
[18:39:11]
<Marcus Lee> I'll try to remove Umami first
[18:47:33]
<nojhan> J'ai essayé 127..., ::1, IP locale, IP externe, etc. Rien ne résout l'erreur. Je crois que c'est autre chose. Un port qu'il faut ouvrir ?
[18:58:02]
<otm33> Juste une question (sans lien avec ton pb), est-ce que tu arrives à te connecter à la page admin de collabora ? Avec la dernière version, mes identifiants sont rejetés...
[18:58:48]
<otm33> chemin `/browser/dist/admin/admin.html`
[18:59:34]
<nojhan> Oui.
[19:00:03]
<otm33> Tu es sur la dernière version (25.04.8.2~ynh4) ?
[19:00:41]
<nojhan> Oui, 25.04.8.2
[19:00:51]
<nojhan> J'ai mis à jour genre hier.
[19:01:11]
<nojhan> Par contre le compte c'est `admin`, pas le compte yunohost.
[19:01:22]
<nojhan> Avec un MdP ad-hoc.
[19:04:49]
<otm33> Oui, et le mot de passe est dans le xml... C'est que je viens de mettre à jour et cela a cessé de fonctionner alors que je me connectais encore avec l'ancienne version il y a qqs minutes... Bon, bref, as-tu essayé de lancer une mise à jour forcée pour remettre les fichiers de conf d'équerre ? Il faut notamment regarder dans ` /etc/yunohost/apps/collabora/settings.yml` si le `nextcloud_domain` est correct.
Pour lancer l'upgrade sans backup et forcée : `yunohost app upgrade collabora -b --force`
[19:05:28]
<nojhan> Allez, je teste 🙂
[19:05:47]
<otm33> Au pire, ça ne marchera pas ;)
[19:06:16]
<nojhan> Au pire faudra juste reformater.
[19:07:14]
<nojhan> Par contre j'ai trouvé des dépendances manquantes sur une autre appli, où-est ce qu'on peut faire des PR ?
[19:07:53]
<otm33> Sur le github de l'app en question.
[19:10:17]
<otm33> rollback à une version antérieure et je retrouve l'interface admin de collabora...
[19:15:17]
<otm33> Juste une question: tu n'aurais pas laissé la version CODE intégrée de Collabora installée ?
[19:17:50]
<@err404:matrix.numericore.com> j'ai jamais réussi à installer colabora, par contre onlyoffice s'installe assez facilement
[19:18:39]
<otm33> C'est une solution...
[19:20:55]
<nojhan> Pas plus de succès avec l'upgrade forcée 😕
[19:28:40]
<otm33> Et plus de "CODE intégré" installé ?
[19:29:55]
<nojhan> Celui dans Nextcloud ? Non, je l'ai viré depuis longtemps.
[19:37:42]
<rodinux> Hello, pour collabora il faut utiliser la dernière version svp, les versions antérieurs sont des fausses indications, en fait c'est toujours la dernière version du dépôt collaboraonline qui va être installé quoiqu'il arrive. Dans la dernière release, j'ai du ajouté le dépôt contrib non-free de bookworm pour installer ttf-mscorefonts-installer, dépendance nécessaire, donc le toute dernière release corrige cela
[19:39:46]
<rodinux> Pour le mot de passe de l'admin collabora évité des caractères spéciaux
[19:41:30]
<rodinux> sinon pour Nextcloud Ofiice pour l'URL je met `https://collabora.domain.tld`
[19:42:00]
<rodinux> pour le Allow list wopi request `127.0.0.1 ::/1`
[19:42:36]
<rodinux> Attention, avant on mettait des virgules, mais maintenant il ne faut plus en mettre, je pense avoir compris cela
[19:43:33]
<rodinux> et si besoin redamarrer le service coolwsd `yunohost tools restart coolwsd`
[19:46:33]
<Paprika> Recently started getting these warnings when updating apps or packages:
```
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://dl.yarnpkg.com/debian stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 62D54FD4003F6525
W: Failed to fetch https://dl.yarnpkg.com/debian/dists/stable/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 62D54FD4003F6525
W: Some index files failed to download. They have been ignored, or old ones used instead.
```
Anyone else? Haven't looked into it too deep, but seems out of the blue. Should I consider this harmless or look into a fix.
[19:47:53]
<rodinux> yes, you could do this command manually on ssh
```
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/yarn.gpg > /dev/null`
[19:48:39]
<Paprika> Thanks, I had a similar situation with another repo, but thought maybe this was caused by some other mighty force that I should be looking into.
[19:49:49]
<rodinux> The repository have rotate the key authentification...
[19:50:44]
<orhtej2> > <@botagiuks:tiesiog.lt> Thanks, I had a similar situation with another repo, but thought maybe this was caused by some other mighty force that I should be looking into.
Cf https://github.com/yarnpkg/yarn/issues/9218
[19:51:26]
<orhtej2> tldr they rotated the key (twice) because of reasons
[19:52:30]
<rodinux> alice => bob => null => bob => alice ???
[19:54:58]
<Paprika> Well good to know, if I hadn't been fixing other issues I had this probably would've been an easy find haha
[19:56:19]
<otm33> Le lien entre les deux doit dépendre d'un autre paramètre : cela fait plus d'une heure que je mets n'importe quoi comme wopi host et cela continue de fonctionner, cache nettoyé, changement de navigateur, redémarrages...
[19:56:22]
<rodinux> Tu as des logs ?
[19:56:56]
<nojhan> Je ne sais pas lesquels regarder.
[19:57:15]
<rodinux> ceux de coolwsd ?
[20:03:55]
<rodinux> Par contre dans le fichier `/etc/coolwsd/coolwsd.xml`, j'ai `<host desc="Regex pattern of hostname to allow or deny." allow="true">nextcloud.domain.tld</host>`
[20:04:08]
<rodinux> sans https...
[20:05:23]
<nojhan> Je viens de tester d'installer une instance from scratch sur un autre domaine, et j'ai le même problème.
[20:12:22]
<rodinux> si je fais un `journalctl -u coolwsd | grep wopi.host`
```
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host: nectcloud.domain.tld
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host[1]: 10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host[2]: 172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host[3]: 172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host[4]: 172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host[5]: 192\.168\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 linux07.fr coolwsd[1082308]: storage.wopi.host[6]: 192\.168\.1\.1
```
[20:14:22]
<rodinux> si je fais un `journalctl -u coolwsd | grep wopi.host`
```
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host: nectcloud.domain.tld
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host[1]: 10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host[2]: 172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host[3]: 172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host[4]: 172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host[5]: 192\.168\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 01:34:15 domain.tld coolwsd[1082308]: storage.wopi.host[6]: 192\.168\.1\.1
```
[20:17:00]
<nojhan> Pareil:
```
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host: cloud.domain.tld
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host[1]: 10\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host[2]: 172\.1[6789]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host[3]: 172\.2[0-9]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host[4]: 172\.3[01]\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host[5]: 192\.168\.[0-9]{1,3}\.[0-9]{1,3}
Feb 02 20:49:33 cloud.antigene.org coolwsd[68762]: storage.wopi.host[6]: 192\.168\.1\.1
```
[20:19:02]
<rodinux> est-ce que tu as mis dans Allow wopi request `127.0.0.1 ::1`
[20:19:13]
<rodinux> et sauvegarder
[20:20:12]
<rodinux> wait, pas les même domaines ?
[20:24:11]
<rodinux> dans ton log c'est bizarre de ne pas voir un résultat comme `domain.tld coolwsd[68762]: storage.wopi.host: nextcloud.domain.tld `
[20:26:44]
<rodinux> est-ce que tu as dans `/etc/hosts` une ligne
`127.0.0.1 domain.tld domain` ??
[20:33:56]
<rodinux> Ce serait bien de comprendre, il y a quelques jours j'ai installé en tous cas cette upgrade sur 3 serveurs yunohost...
[20:34:07]
<rodinux> Par contre, parfois je dois m'y prendre deux ou trois fois au tout début où j'ouvre un fichier
[21:41:36]
<rodinux> c'est un nextcloud privé du coup ?
[21:48:47]
<rodinux> Je vais tester en local si le fait que le nextcloud n'est pas public est le soucis...
[21:51:36]
<otm33> Je me disais qu'il avait oublié d'anonymiser dans la partie gauche... tu ne crois pas que c'est plutôt ça ?
[21:53:32]
<rodinux> En tous les cas dans mes tests si le nextcloud est privé, pas public (avec les permissions visitors) en effet ça bug
[22:11:11]
<otm33> dsl, j'avais lu de travers... Je viens de suivre le lien cloud.antigene.org... Donc c'était juste ça. Ca a du bon parfois, les erreurs d'anonymisation.
[22:11:58]
<rodinux> oui, pour ce cas là en tous les cas... mais en effet il faudrait peut-être effacer ??? son commentaire ??
[22:12:50]
<otm33> dsl, j'avais lu de travers... Je viens de suivre le lien xxxxxxxxx.xxxxx ... Donc c'était juste ça. Ca a du bon parfois, les erreurs d'anonymisation.
[22:15:33]
<rodinux> En tous las cas ça me permet de savoir que en effet, le nextcloud doit être public pour communiquer avec le collabora... c'est bête, il y a peut-être une config à trouver
[22:47:21]
<otm33> J'aimerais mieux comprendre la communication entre nextcloud et collabora. J'ai purgé le xml de toutes les regex pour les ip, je n'ai laissé qu'un hôte wopi aberrant (ce n'est même pas un nom de domaine), j'ai vidé le cache du navigateur, de `cool/cache` et Collabora fonctionne toujours...
[22:48:26]
<Chatpitaine Caverne> Télépathie ?
[22:48:55]
<rodinux> et redémarrer coolwsd ?
[22:49:06]
<otm33> Le rêve de tout admin réseau...
[22:49:34]
<otm33> Ah mais je l'ai redémarré 20 fois... (restart, stop, start...)
[22:51:07]
<rodinux> Du moment qu'il écoute le localhost en local pas de soucis, j'imagine que c'est depuis l'extérieur qu'il peut y avoir besoin des regex...
[22:55:56]
<rodinux> Je pense qu'il a peut-être un truc pour pouvoir l'utiliser avec un nectloud privé... Ajouter dans le config.php de nextcloud
```
'trusted_domains' =>
array (
0 => '127.0..0.1',
1 => 'cloud.mondomaine.local',
1 => 'collabora.mondomaine.local',
)
```
et le sous‑domaine collabora.mondomaine.local doit être résolu en interne (ex. via le fichier /etc/hosts ou le DNS interne).... pas sûr mais c'est peut-être une piste...
[22:58:03]
<rodinux> Il doit être possible aussi que collabora n'écoute que loopback et en IPv4
```
<net desc="Network settings">
<!-- On systems where localhost resolves to IPv6 [::1] address first, when net.proto is all and net.listen is loopback, coolwsd unexpectedly listens on [::1] only.
You need to change net.proto to IPv4, if you want to use 127.0.0.1. -->
<proto type="string" default="all" desc="Protocol to use IPv4, IPv6 or all for both">IPv4</proto>
<listen type="string" default="any" desc="Listen address that coolwsd binds to. Can be 'any' or 'loopback'.">loopback</listen>
[23:03:34]
<rodinux> en mettant l'IP de mon serveur local dans allow request wopi, ce n'est plus une erreur de wopi mais `Hôte WOPI non autorisé. Veuillez essayer de nouveau plus tard et en faire part à votre administrateur si le problème persiste. L'erreur d’autorisation était : 'self-signed certificate in certificate chain'.` là je pense que c'est parce que sur ce serveur je n'ai que des auto-certifs...
[23:05:43]
<rodinux> C'est pas vraiment pratique de garder le nextcloud privé je trouve...
[23:05:45]
<otm33> et en cochant "na pas vérifier le certificat" dans nextcloud office
[23:07:45]
<rodinux> hummm non plus `Failed to connect to the remote server: cURL error 60: SSL certificate problem: self-signed certificate in certificate chain (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://collabora.yunohost.packaging/hosting/discovery`
[23:12:36]
<otm33> Même de l'extérieur je parviens à éditer...???