YunoHost 3.5 release / Sortie de YunoHost 3.5

Ça signifie que la syntaxe du fichier /etc/ssowat/conf.json.persistent n’est pas bonne …

1 Like

arf bon après quelques tests (je suis sur vps OVH)
le problème d installer une ouverture et fermeture des accolades pour installer d un thème dans le fichier “conf.json.persistent” n’est pas correct lorsque l on veut changer une redirection.

Blockquote Error while reading SSOwat persistent configuration: Expecting , delimiter: line 7 column 1 (char 104). Edit /etc/ssowat/conf.json.persistent file to fix the JSON syntax

j’ai simplement installer la ligne

“theme”: “XXX”

dans les accolades mais sans la virgule sic.

Je pense avoir bien faite la mise à jour mais je ne peux pas confirmer car j’ai maintenant un souci d’affichage de l’admin, qui n’est plus responsive :

Et j’ai cette erreur lors de la connexion qui m’indique justement qu’il ne trouve pas la version :

Error: 404 Not Found
Sorry, the requested URL ‘YunoHost Portal’ caused an error:
Not found: ‘/version’

Est-ce que forcer le rafraichissement du cache avec Ctrl+Shift+R (sous firefox) résoud le probleme ?

Bon, erreur de noob, c’est bon maintenant (j’avais “juste” redémarré YunoHost…) :sweat_smile:

Propulsé par YunoHost 3.5.2.2 (stable).

:blush:

Salut,

J’ai observé un comportement bizarre sur mon serveur kimsufi, hébergeant yunohost, depuis la semaine dernière.
Je n’arrive plus à faire des apt-get update/install rapide lorsque je suis en ipv6.
Lorsque mon serveur tente de se connecter aux miroirs debian d’ovh (Index of /debian/pool/main/), la connexion est super lente.
Lorsque je tente de télécharger un package par wget, pareille, la vitesse de connexion est abyssale.
En forçant un wget -4, je n’ai aucun problème.
Bien entendu, il y a encore deux semaines je n’avais pas ce problème.

J’ai ouvert un ticket avec OVH et leur techos sont en train de regarder ça.
Mais étant donné que le seul changement récent sur mon serveur c’est la mise à jour vers ynh 3.5, et que je vois ceci:

[enh] Add IPv6 resolvers from diyisp.org to resolv.dnsmasq.conf (#639)

Je me demande si ça peut avoir un rapport ou pas.
Avez vous un avis?
Merci !

Hmoui ca peut effectivement avoir un rapport … Il faudrait tester si c’est effectivement la resolution de domaine qui marche pas (et donc ca fini par fallback sur l’ipv4) ou alors vraiment tout l’ipv6 qui ne marche pas …

Est-ce que tu peux essayer de curl ou wget un site en ipv6 en passant directement par son IP ?

Salut, petite update sur ça.

J’ai supprimé toutes les IPv6 de mon /etc/resolv.dnsmasq.conf puis redémarré dnsmasq, et tout fonctionne comme il faut.
J’ai pingé toutes les IP en ipv6, et toutes répondent sauf 2002:d596:2a92:1:71:53::. Les perfs sont assez différentes (en 30/40ms pour les plus lentes et 5ms pour la meilleure).
En supprimant celle qui ne fonctionne pas, j’obtiens toujours le même résultat avec apt-get: super lent et ça finit par timeout.

En testant wget -6 www.google.com tout fonctionne bien.

Edit:
Ah nope, même après avoir redémarré dnsmasq, ou arrêté puis démarré, il tente quand même de passer par l’ipv6:

admin@xxxxxxx:/etc$ sudo apt-get update
Hit:1 http://security.debian.org stretch/updates InRelease
Hit:2 http://forge.yunohost.org/debian stretch InRelease
0% [Connecting to debian.mirrors.ovh.net (2001:41d0:202:100:213:32:5:7)]

Double edit: l’IP v6 du dns de https://blog.uncensoreddns.org/ a changé, donc diyisp.org n’est plus à jour.

Ok je pense que le problème vient d’OVH et pas de mon serveur/de mon install de yunohost.

Je peux faire du wget en ipv6 et ipv4 sur pleins d’url différentes, y compris sur des url OVH.
Mais, cela ne fonctionne pas sur leur miroir debian.

  • wget -4 http://debian.mirrors.ovh.net/robots.txt
    Auncun soucis
  • wget -6 http://debian.mirrors.ovh.net/robots.txt
    Ça pédale dans la choucroute.

En faisant un petit test sur https://ready.chair6.net/?url=debian.mirrors.ovh.net il me semble que ce serveur soit mal configuré.

Bon, au moins je sais d’où ça vient, et ça m’a permis de voir qu’une des ip dans le resolv.dnsmasq.conf est à changer.

Pour résoudre mon problème, si jamais d’autres l’ont aussi, deux solutions:

  • Utiliser l’option -o Acquire::ForceIPv4=true lors des appels à apt
    Mais ça veut dire qu’il faut le faire à chaque fois
  • Modifier la configuration d’apt pour forcer l’ipv4. Voir cette réponse sur stackexchange.

Edit: bon ben j’ai fait une pr pour mettre l’IP à jour tant qu’à faire : #727

1 Like

Release is available for docker, with delay :confused: ! Don’t hesitate to give me comebacks :slight_smile:

2 Likes