hello…
Je suis un peu dépité.
Le soucis est de retour.
Je suis certain d’avoir testé et que ça fonctionnait Vendredi soir.
Mais aujourd’hui de nouveau, impossible d’écrire dans un récit…
C’est vraiment handicapant… surtout que nous utilisons DoDoc pour documenter l’utilisation des machines pour le public et tout ce que nous faisons pour nous en interne… les feuilles de brouillon s’accumulent à force.
Est-ce que qqun a une idée de ce qu’il se passe ou un solution pour que je revienne à une version antérieure qui fonctionne svp ?
Merci.
Alors… j’ai trouvé le soucis.
Quand je passe en LAN ça marche.
Si je passe par internet cela ne marche pas.
Il doit y avoir des communications utilisées par le protocole wss qui sont bloquées.
Est-ce qu’il faut que j’ouvre un/des port(s) spécifiques ?
Est-ce que mon fichier de config nginx doit contenir qqch de spécial ? Car j’utilise ce même server pour divers services, j’ai donc un fichier de config nginx par service.
Visiblement les wss n’arrivent pas à se connecter au server. Etant donné que j’utilise un proxy inversé pour distribué les services, quel est le port utilisé par les WSS ? le 443 ? car les autres ne sont pas redirigés mais bloqués.
Mon fichier settings.json
je l’ai surtout utilisé pour le certificat… certificat qui marche pas d’ailleurs mais c’est un autre sujet ;p
À priori y a rien à faire. Et j’ai rien changé depuis 2 semaines à ce niveau donc si ça marche plus, ça vient d’ailleurs je pense. Le règlages des clés .pem ici n’est pas utilisé si tu fait un proxy inversé avec nginx, il vaut mieux placer le certificat au niveau nginx, avec certbot (voir tuto forum) ou à la main.
En tout cas ton fichier settings.json ne devrait pas poser de soucis.
Peux-tu re-pull depuis dodoc2-next-node ? j’ai mis à jour en début d’après midi, et tout fonctionne bien sur test10.
Je vais tester ça ce soir, là mon collègue utilise DoDoc pour mettre ses notes papier en ligne.
Je pense que depuis le début, le soucis venait de là : en local ça fonctionne mais pas via le net…
très étrange.
Pour les certificats, CertBot n’arrive pas à créer les certificats automatiquement. Je ne comprends pas pourquoi d’ailleurs… je m’y pencherai plus tard.
J’ai donc fait des certificats avec notre NAS pour voir mais ça ne fonctionne pas non plus. Bref.
qqch fait que les websockets ne parviennent pas à se connecter au server…
Etrange.
Peut-être un soucis HTTP/HTTPS ?
L’éditeur de texte se connecte en WSS (les websockets sécurisés) si tu donne accès en HTTPS, sinon websocket simple.
Tu peux ajouter un règlage
"protocol": "http",
Dans settings.json puis redémarrer le server pour tester en HTTP ?
Alors, le proxy inversé laisse entrer le 443 et le 80, mais le 80 est redirigé vers la page par défaut de nginx… donc le navigateur n’aura pas de retour du server
et le 443 sur avec en requete https://dodoc.varennes-ecocentre.fr est redirigé vers le 8080
Seule le 443 marche vraiment normalement.
je ne suis plus sur un NAS.
je suis sur un server Bare Metal en local.
Ubuntu Server 22.04.4 LTS
Sans Docker, sans rien.
Vraiment le plus basique possible.
Simplement, il héberge DoDoc et d’autres services en local comme un gestionnaire de mot de passe etc.
Comme ces services ont besoin d’internet, ils sont plusieurs à utiliser nginx.
Pour l’accès depuis l’extérieur, nous utilisons un reverse proxy qui redirige en fonction de l’url de requête.
Et une requête en 443 vers l’url https://dodoc.varennes-ecocentre.fr renvoie vers le port 8080 du serveur, qui correspond à DoDoc.
Sur le 443 j’ai un autre service déjà.
Ma seule piste c’est le certificat SSL pour le HTTPS qui n’est pas en place, mais je n’ai pas l’explication pour laquelle ça ferait ça. Tu crois que tu peux tester ça ? Je ne me souviens plus pourquoi tu ne pouvais pas l’installer.
Il est hébergé chez OVH pour un site internet et un serveur mail.
J’utilise des sous domaines pour mes autres services, par exemple dodoc.varennes-ecocentre.fr
Sauf que ces derniers sont hébergés en local.
Au niveau du DNS, on a donc un NDD hébergé chez OVH avec une ip chez OVH et des sous-domaines hébergés en local avec une ip publique de box FAI.
Le soucis, c’est que let’s encrypt, si j’ai bien compris, il vérifie à la fois le domaine et le sous domaine… sauf que ça ne pointe pas au même endroit donc il dit qu’il ne peut pas valider le sous-domaine.
Ai-je été clair ?
J’ai tenté de mettre protocol http dans le settings.
Mais cela fait tout planté… je n’ai plus ni projets, ni espaces, ni … plus rien à part la description en page d’accueil.
Donc j’ai laissé tombé cette idée ;p
Y a-t-il moyen d’utiliser ws en lieu et place de wss ?
peut-être que cela résoudrait le soucis du SSL ?
Ce qui est étonnant c’est qu’avant la MàJ… aucun soucis pour éditer malgré un SSL incorrect…
Ça m’a l’air tout bon, pas de soucis à ce niveau là.
Impossible de passer en ws si tu utilises le https, c’est forcément une connexion sécurisée (le navigateur l’oblige).
Je pense que ça vaudrait le coup de revenir à un commit précédent effectivement, tu perds pas énormément de choses pour le moment et on retentera quand ça sera stabilisé. Ce commit peut-être ?
.
Visiblement, il a bien pris les changement en compte (100% resolving deltas toussa toussa).
Mais impossible de compiler tout ça… il me manque un fichier electron (enfin je suppose, car le fichier qu’il essaie d’executer « electron-builder install-app-deps » n’existe pas dans mon dossier dodoc).
Si je ne dis pas de bêtise, electron c’est pour la version non node, nan ?
malheureusement cela ne change rien. Toujours ce soucis de websocket… j’avoue que j’y comprends plus rien…
Pourquoi cela a fonctionné mais plus maintenant ??
c’est incompréhensible…
Est-ce que ça vient de la manière dont j’ai transférer le DoDoc du NAS vers le serveur ?
J’ai simplement copié le dossier avec tous les fichiers des projets et des utilisateurs.
Mais est-ce qu’en faisant cela j’ai écrasé un fichier de config des ws ?
Mais alors pourquoi ça fonctionne en local mais pas via internet ?
Une chose à tenter : une clean-install dans un autre dossier en suivant le tuto du forum (git clone …, git checkout dodoc2-next-node, etc.), puis définir dans un nouveau fichier settings.json les paramètres pour faire cohabiter les deux instances, par exemple :
Puis lancer avec npm run debug, et voir si en accédant au site https://IP:PORT/ et en contournant l’avertissement de sécurité, tu rencontres le même soucis.
Tu vois ce que je veux dire ?
