Erreur 504 via yunohost/sso portalapi (debian Bookworm)

Support
, ,
1

What type of hardware are you using: Internet Cube with VPN
What YunoHost version are you running: 12.0.6
How are you able to access your server: SSH

Describe your issue

Je viens de procéder à une installation de yunohost avec la toute nouvelle version. J’ai un utilisateur (administrateur) et seulement une application qui est le client VPN (puisqu’il s’agit d’une carte ARM hébergé dernière mon FAI)
Le service yunohost-portal-api n’arrive pas à se lancer. Le statut sur le webadmin est le suivant : auto-restart depuis moins d’une minute. Pourtant en ssh j’ai ce retour quand je tente de le relancer :
root@yunohost~# yunohost service restart yunohost-portal-api
Success! Service ‘yunohost-portal-api’ restarted
Résultat lorsque je tente de me connecter via /yunohost/sso et non yunohost/admin, j’obtiens une erreur 502 avec le message suivant : [GET] “https://xxxx.noho.st/yunohost/portalapi/public”: 502
Je pense donc que c’est lié au service qui ne se démarre pas mais je n’ai aucune idée du pourquoi et comment le corriger. Avez-vous déjà recontré ce problème ?

Share relevant logs or error messages

https://paste.yunohost.org/ijapixequy

2

Que raconte ls -l /var/log/yunohost-portalapi.log ?

3

Merci pour ton retour si rapide.
J’obtiens ceci :

root@yunohost:~# ls -l /var/log/yunohost-portalapi.log
ls: cannot access '/var/log/yunohost-portalapi.log': No such file or directory

Ça n’a pas l’air très rassurant. Un problème de permissions sur un dossier ? Mais pourquoi je suis le seul dans ce cas ?

4

Oui c’est une bonne question, normalement ce fichier est initialisé à l’install initiale du paquet debian, et encore après pendant la regenconf de la postinstall, je ne comprends pas comment il peut ne pas exister, mais je vois aussi que tu indiques “internet cube” alors je m’interroge sur quel process d’install (et image de départ?) tu as utilisé exactement …

Mais du coup on peut tenter de remettre les choses à plat avec yunohost tools regen-conf yunohost

5

J’ai suivi la doc d’installation qui se trouve ici : Install YunoHost | Yunohost Documentation
Mais justement je me suis demandé si la doc était bien à jour au vu de la récente migration debian et yunohost 12.

6

Après avoir regénéré la conf yunohost, j’ai bien la mire de connexion (sans 502 cette fois) mais une fois mes identifiants rentrés je tombe sur cette nouvelle erreur 504 :

[POST] “https://xxxx.noho.st/yunohost/portalapi/login”: 504

Pour info, voici désormais le retour des permissions sur var/log/yunohost-portalapi.log

root@yunohost:~# ls -l /var/log/yunohost-portalapi.log
-rw------- 1 ynh-portal root 1810 Nov  4 19:29 /var/log/yunohost-portalapi.log

Au niveau du service yunohost-portal-api, celui-ci tourne désormais correctement depuis quelques minutes :

En cours d’exécution depuis 4 minutes

7

Bonjour,
J’ai procédé ce soir à une réinstallation entière de ma carte ARM pour m’assurer qu’il ne s’agissait pas d’une erreur d’installation de Debian. Je n’ai cette fois ci pas eu l’erreur 502 en tentant d’accéder à la mire de connexion. Néanmoins après connexion je tombe toujours sur celle-ci…

[POST] “https://xxxx.noho.st/yunohost/portalapi/login”: 504

Auriez-vous une piste de la raison de cette erreur ?

8

Je refais un point ce jour sur le soucis rencontré.

L’erreur 504 est toujours présente à la connexion via yunohost/sso. Cependant j’ai tenté d’installer Nextcloud pour m’y connecter directement depuis la mire de l’app sans passer par la connexion Yunohost et de cette façon j’arrive à m’y connecter directement. Le problème se situe donc vraisemblablement au niveau de l’authentification Yunohost SSO.

NB : je rencontre la même erreur qu’il s’agisse d’un utilisateur (sans droit particulier) ou d’un administrateur

9

C’est difficile à debugger dans la mesure où ça marche pour pleins d’autres monde et on ne sais pas comment reproduire le problème … mais tu n’es aussi pas un cas isolé

Naivement je zieuterais à sudo tail /var/log/yunohost-portalapi.log -n 100 pour voir si il y a des infos évidentes, ou bien sudo journalctl -u yunohost-portal-api -n 100 --no-pager --no-hostname

10

Merci pour ton retour. En effet je ne suis pas un cas isolé, j’ai profité d’un post qui a obtenu plus de réponses pour y lister les différentes remontées qui pour moi sont identiques.

Pour une connexion qui me retourne 504 voici les logs stockés dans var/log/yunohost-portalapi.log :

2024-11-07 18:49:15,997 DEBUG geventwebsocket.handler.run_application - Initializing WebSocket
2024-11-07 18:49:15,998 DEBUG geventwebsocket.handler.upgrade_websocket - Validating WebSocket request
2024-11-07 18:49:16,004 DEBUG moulinette.actionsmap.process - loading python module yunohost.portal took 0.000s
2024-11-07 18:49:16,005 DEBUG moulinette.actionsmap.process - processing action ‘yunohost.portal.public’
2024-11-07 18:49:16,008 DEBUG moulinette.actionsmap.process - action executed in 0.002s
2024-11-07 18:49:16,017 INFO geventwebsocket.handler.log_request - 127.0.0.1 - - [2024-11-07 18:49:16] “GET /public HTTP/1.1” 200 378 0.019441
2024-11-07 18:49:22,793 DEBUG geventwebsocket.handler.run_application - Initializing WebSocket
2024-11-07 18:49:22,794 DEBUG geventwebsocket.handler.upgrade_websocket - Validating WebSocket request
2024-11-07 18:49:22,795 DEBUG geventwebsocket.handler.upgrade_websocket - Can only upgrade connection if using GET method.

Le retour de requête GET 200 m’intrigue un peu…

Du côté du journalctl de yunohost-portal-api, je n’ai rien de nouveau depuis le redémarrage effectué le 5 novembre :

nov. 05 20:12:05 systemd[1]: Started yunohost-portal-api.service - YunoHost Portal API.

11

Okay alors regardons ce que renvoie sudo grep -nr "location /yunohost.*api/ \|proxy_pass" /etc/nginx/conf.d

et sudo netstat -tulpn | grep 678

12

je ne sais pas dans quelle mesure je troll le fil mais vu que j’ai le même problème que celui de Valen je me permets d’envoyer les réponses des commandes que tu viens d’envoyer.

-peut être que je devrais me contenter de regarder-

root@pigeonsrapides:~# grep -nr "location /yunohost.*api/ \|proxy_pass" /etc/nginx/conf.d
/etc/nginx/conf.d/yunohost_api.conf.inc:1:location /yunohost/api/ {
/etc/nginx/conf.d/yunohost_api.conf.inc:3:    proxy_pass http://127.0.0.1:6787/;
/etc/nginx/conf.d/yunohost_api.conf.inc:22:location /yunohost/portalapi/ {
/etc/nginx/conf.d/yunohost_api.conf.inc:25:    proxy_pass http://127.0.0.1:6788/;
root@pigeonsrapides:~# netstat -tulpn | grep 678
tcp        0      0 127.0.0.1:6788          0.0.0.0:*               LISTEN      694/python3         
tcp        0      0 127.0.0.1:6787          0.0.0.0:*               LISTEN      691/python3         
root@pigeonsrapides:~#
13

Ok alors continuons de creuser … si tu fait curl -v http://127.0.0.1:6788/public, est-ce que tu vois bien un truc qui ressemble à :

*   Trying 127.0.0.1:6788...
* Connected to 127.0.0.1 (127.0.0.1) port 6788 (#0)
> GET /public HTTP/1.1
> Host: 127.0.0.1:6788
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 195
< Date: Thu, 07 Nov 2024 18:31:36 GMT
< 
* Connection #0 to host 127.0.0.1 left intact
{"public": false, "portal_logo": "", "portal_theme": "system", "portal_tile_theme": "simple", "portal_title": "YunoHost", "show_other_domains_apps": false, "domain": "127.0.0.1:6788", "apps": {}}
14

donne la réponse :

root@pigeonsrapides:~# curl -v http://127.0.0.1:6788/
*   Trying 127.0.0.1:6788...
* Connected to 127.0.0.1 (127.0.0.1) port 6788 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:6788
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 405 Method Not Allowed
< Allow: OPTIONS
< Content-Length: 733
< Content-Type: text/html; charset=UTF-8
< Date: Thu, 07 Nov 2024 18:33:24 GMT
< 

    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html>
        <head>
            <title>Error: 405 Method Not Allowed</title>
            <style type="text/css">
              html {background-color: #eee; font-family: sans;}
              body {background-color: #fff; border: 1px solid #ddd;
                    padding: 15px; margin: 15px;}
              pre {background-color: #eee; border: 1px solid #ddd; padding: 5px;}
            </style>
        </head>
        <body>
            <h1>Error: 405 Method Not Allowed</h1>
            <p>Sorry, the requested URL <tt>&#039;http://127.0.0.1:6788/&#039;</tt>
               caused an error:</p>
            <pre>Method not allowed.</pre>
        </body>
    </html>
* Connection #0 to host 127.0.0.1 left intact
root@pigeonsrapides:~#
15

avec “/public” a la fin de l’url

16 
root@pigeonsrapides:~# curl -v http://127.0.0.1:6788/public
*   Trying 127.0.0.1:6788...
* Connected to 127.0.0.1 (127.0.0.1) port 6788 (#0)
> GET /public HTTP/1.1
> Host: 127.0.0.1:6788
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 195
< Date: Thu, 07 Nov 2024 18:36:48 GMT
< 
* Connection #0 to host 127.0.0.1 left intact
{"public": false, "portal_logo": "", "portal_theme": "system", "portal_tile_theme": "simple", "portal_title": "YunoHost", "show_other_domains_apps": false, "domain": "127.0.0.1:6788", "apps": {}}root@pigeonsrapides:~#

Ca ressemble à ce que tu ecrivais

17

Voilà les retours de mon côté concernant les deux commandes que tu m’as indiqué :

root@yunohost:~# sudo grep -nr “location /yunohost.*api/ |proxy_pass” /etc/nginx/conf.d
/etc/nginx/conf.d/yunohost_api.conf.inc:1:location /yunohost/api/ {
/etc/nginx/conf.d/yunohost_api.conf.inc:3: proxy_pass http://127.0.0.1:6787/;
/etc/nginx/conf.d/yunohost_api.conf.inc:22:location /yunohost/portalapi/ {
/etc/nginx/conf.d/yunohost_api.conf.inc:25: proxy_pass http://127.0.0.1:6788/;
root@yunohost:~# sudo netstat -tulpn | grep 678
sudo: netstat : commande introuvable

Faut-il que j’installe netstat ou ce n’est pas nécessaire ?

18

Concernant le curl, j’ai exactement le même retour que toi

19

Mokaayyy alors ben testons la route de login :

curl -v -X POST http://127.0.0.1:6788/login -d "credentials=foo:bar"

(essayons avec des faux identifiants pour le moment)

Est-ce que ça renvoie bien “Invalid password” à la fin ?

20

J’ai bien une erreur 401 mais pas d’“Invalid password” en vue. Voici le retour exact :

Trying 127.0.0.1:6788…
Connected to 127.0.0.1 (127.0.0.1) port 6788 (#0)
POST /login HTTP/1.1
Host: 127.0.0.1:6788
User-Agent: curl/7.88.1
Accept: /
Content-Length: 19
Content-Type: application/x-www-form-urlencoded

HTTP/1.1 401 Unauthorized
Content-Length: 16
Content-Type: text/html; charset=UTF-8
Date: Thu, 07 Nov 2024 18:50:35 GMT

Connection #0 to host 127.0.0.1 left intact