Pas d'accès à yunohost depuis la dernière migration erreur 504

What type of hardware are you using: Old laptop or computer
What YunoHost version are you running: 12.0.6
How are you able to access your server: The webadmin
SSH
Direct access via physical keyboard/screen
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: no

Describe your issue

Bonjour,
Vieux Laptop HP qui fonctionne avec yunohost 12.0.6
Roundcube / Custom webapp / Dollibarr / piwigo / Concrete5 / redirect
J’ai accès à mon serveur En SSH | Par la webadmin | En direct avec un clavier/écran |
Je n’ai pas effectué de modifications particulières.

Mon problème est que le bouton “connexion” pour accéder aux apps n’a aucun effet.
J’ai bien accès la page d’administration mais pas à yunohost.

Merci du temps que vous prendrez pour m’aider.

Share relevant logs or error messages

https://paste.yunohost.org/raw/adumakifal
https://paste.yunohost.org/raw/ewahacubuv
https://paste.yunohost.org/raw/ecewozurab

Salut,

J’ai pas vu d’erreur en regardant vite fait tes logs.

Dans une fenêtre en navigation privé ca fonctionnerait pas par hasard ?

Bonjour,
Non ça ne marche pas en navigation privée non plus.
Sur mon téléphone j’ai un “ancien” onglet ouvert avec le bouton connexion bleu ciel qui me permet d’acceder à mes mails.
En revanche dès que j’essaye avec la “nouvelle présentation” avec le bouton connexion bleu foncé ça ne fait rien.
Comme si le bouton ne fonctionnait pas.

Alors,
pas certain que ça soit ton problème mais j’ai rencontré ça chez mes utilisateurices récemment (après passage en Yunohost 12) :

  • la page de login Yunohost n’affiche aucun message d’erreur, et pas même de réaction réellement visible lors d’un clic sur le bouton “connexion” si le login ou pass est erronné.
  • mon utilisateur qui rencontrait ça se loggait avec son pseudo@NDduYunohost.TLD et ne voyait pas d’erreur, quand il a essayé avec juste pseudo, et le même pass, c’est passé.

j’ai testé des couples login/pass erronés sur mon instance, et en effet, pas de réaction visible lorsque le login ou le pass sont erronés.

d’ailleurs cela génère une entrée de type :

2024-11-06 16:34:29,442 DEBUG    geventwebsocket.handler.run_application - Initializing WebSocket
2024-11-06 16:34:29,442 DEBUG    geventwebsocket.handler.upgrade_websocket - Validating WebSocket request
2024-11-06 16:34:29,442 DEBUG    geventwebsocket.handler.upgrade_websocket - Can only upgrade connection if using GET method.
2024-11-06 16:34:29,445 INFO     geventwebsocket.handler.log_request - 127.0.0.1 - - [2024-11-06 16:34:29] "POST /login HTTP/1.1" 401 142 0.003114

dans mon /var/log/yunohost-portalapi.log
lorsque la connexion échoue (par login incorrect, dans cet exemple)

J’ai donc changé le mot de passe de mon profil user par l’intermédiaire de la webadmin et réessayé.
J’ai maintenant une erreur 504.
Je suis allé dans le forum et j’ai cliqué sur “redémarrer yunohost API”.
La réponse que j’ai eu est :
Erreur “502”.
Action : “Put” /yunohost/api/services/yunohost-api/restart
“L’API Yunohost ne répond pas. Peut être que “yunohost-api” est en panne ou a été redémarré.”

Je partage ici le log donné :
https://paste.yunohost.org/ubonujunem

Tout ce que j’ai fait est par l’interface graphique.

P.S. Je ne connais pas l’informatique mais j’ai vaguement souvenir d’avoir eu un jour à retrograder de PHP 8.0 à 7.0.
Peut être une piste cohérente avec le log envoyé ?

Edit 18h42 sur la “vieille page avec le bouton bleu ciel” sur mon téléphone je peux acceder à mes mails en utilisant le nouveau mot de passe user.
Est-ce que je peux en déduire que ce n’est pas un problème de login/password ?

Edit 18H51 voici le message de l’erreur 504 qui arrive plus de deux minutes après avoir essayé de me logger :
[POST] “https://pigeonsrapides.fr/yunohost/portalapi/login”: 504

la commande “systemctl restart yunohost-api” en ssh ne donne pas de message d’erreur

Edit 19h07 j’ai fait ça et ça n’a rien amélioré :
root@pigeonsrapides:~# yunohost tools regen-conf yunohost
Attention : Le fichier de configuration ‘/etc/systemd/system/ntp.service.d/ynh-override.conf’ a été modifié manuellement et ne sera pas mis à jour
yunohost:
applied:
pending:
/etc/systemd/system/ntp.service.d/ynh-override.conf:
status: modified

Edit 19H22 j’ai tapé “apt update && apt full-upgrade”
qui m’a proposé de taper “apt autoremove” pour
php8.2 php8.2-curl php8.2-fpm php8.2-mysql phpmyadmin-ynh-deps
ce que j’ai fait et ça n’a rien amélioré

Pardon, si le mot de passe est bon, est-ce le login ?

Aviez-vous tenté la solution de @fabulousfabs ? En l’occurence, vous connecter avec le pseudo simple, sans nom de domaine ?

Oui j’ai essayé les deux méthodes.
Avec le nom de domaine ça ne donne rien.
Sans le nom de domaine j’arrive à me connecter sur la vieille version d’avant la mise à jour qui a le bouton connexion bleu ciel.

Je ne vois rien non plus dans les logs (le premier étant trèèèès long, je n’ai pas regardé le début).

J’aime beaucoup le nom de domaine, en passant.

Je remarque c’est un serveur pour une entreprise. Je suis désolé et espère que cela ne nuira pas au travail quotidien en attendant que de meilleures réponses n’interviennent.

pour reprendre le problème de manière intelligible :

  1. J’arrive à me logger à l’adresse :
    https: //pigeonsrapides.fr/webmail

  2. impossible de me logger par
    https://pigeonsrapides.fr/yunohost/sso/login
    qui me donne une erreur 504

  3. L’adresse
    https://pigeonsrapides.fr/dolibarr/ me renvoie automatiquement à yunohost/sso/login où il est impossible de se logger.

  4. un redémarrage de l’api me donne l’image suivante

Hum, je ne pense pas que ce soit une bonne idée… Il ne faut surtout pas supprimer ces paquets php ! C’est le php8.2 est le php de la version bookworm les réinstaller semble une bonne idée

apt install php8.2 php8.2-curl php8.2-fpm php8.2-mysql

Pour phpmyadmin-ynh-deps ce devait être des dépendances de phpmyadmin… Au pire tu pourras le désinstaller et réinstaller…

Il vaut mieux ne pas utiliser de commandes apt, toujours préférer les commandes yunohost

yunohost tools update
yunohost tools upgrade system

Que donne ensuite cette commande

yunohost tools regen-conf -n -d

Bonjour Rodinux,
Merci pour ton temps.

J’ai réinstallé les paquets
php8.2 php8.2-curl php8.2-fpm php8.2-mysql

La commande

yunohost tools regen-conf -n -d

donne ce résultat :

Attention : Le fichier de configuration '/etc/systemd/system/ntp.service.d/ynh-override.conf' a été modifié manuellement et ne sera pas mis à jour
Attention : Le fichier de configuration '/etc/ldap/slapd.ldif' a été modifié manuellement et ne sera pas mis à jour
Attention : Le fichier de configuration '/etc/apt/sources.list.d/extra_php_version.list' a été modifié manuellement et ne sera pas mis à jour
Succès ! La configuration aurait dû être mise à jour pour la catégorie 'dnsmasq'
apt: 
  applied: 
  pending: 
    /etc/apt/sources.list.d/extra_php_version.list: 
      diff: @@ -1 +1 @@
-deb https://packages.sury.org/php/ bookworm main
+deb [signed-by=/etc/apt/trusted.gpg.d/extra_php_version.gpg] https://packages.sury.org/php/ bookworm main
      status: modified
dnsmasq: 
  applied: 
    /etc/resolv.dnsmasq.conf: 
      diff: @@ -1,20 +1,20 @@
+nameserver 89.233.43.71
+nameserver 2001:67c:28a4::
 nameserver 2001:1608:10:25::1c04:b12f
+nameserver 2001:910:800::40
+nameserver 2001:1608:10:25::9249:d69b
+nameserver 80.67.169.12
+nameserver 185.233.100.100
+nameserver 89.234.141.66
+nameserver 2a0c:e300::100
+nameserver 84.200.69.80
+nameserver 194.150.168.168
+nameserver 2a0c:e300::101
+nameserver 2a00:5881:8100:1000::3
+nameserver 91.239.100.100
+nameserver 195.160.173.53
+nameserver 80.67.169.40
+nameserver 2a01:3a0:53:53::
+nameserver 185.233.100.101
 nameserver 84.200.70.40
-nameserver 195.160.173.53
-nameserver 2001:67c:28a4::
-nameserver 2001:910:800::40
-nameserver 80.67.169.12
-nameserver 2a00:5881:8100:1000::3
-nameserver 89.234.141.66
-nameserver 80.67.169.40
-nameserver 2a0c:e300::100
-nameserver 194.150.168.168
-nameserver 91.239.100.100
-nameserver 84.200.69.80
-nameserver 2001:1608:10:25::9249:d69b
-nameserver 2a0c:e300::101
-nameserver 185.233.100.101
-nameserver 185.233.100.100
 nameserver 2001:910:800::12
-nameserver 89.233.43.71
-nameserver 2a01:3a0:53:53::
      status: updated
  pending: 
slapd: 
  applied: 
  pending: 
    /etc/ldap/slapd.ldif: 
      diff: @@ -1,235 +0,0 @@
-# OpenLDAP server configuration for Yunohost
-# ------------------------------------------
-#
-# Because of the Yunohost's regen-conf mechanism, it is NOT POSSIBLE to
-# edit the config database using an LDAP request.
-#
-# If you wish to edit the config database, you should edit THIS file
-# and update the config database based on this file.
-#
-# Config database customization:
-# 1. Edit this file as you want.
-# 2. Apply your modifications. For this just run this following command in a shell:
-#    $ /usr/share/yunohost/hooks/conf_regen/06-slapd apply_config
-#
-# Note that if you customize this file, YunoHost's regen-conf will NOT
-# overwrite this file. But that also means that you should be careful about
-# upgrades, because they may ship important/necessary changes to this
-# configuration that you will have to propagate yourself.
-
-#
-# Main configuration
-#
-dn: cn=config
-objectClass: olcGlobal
-cn: config
-olcConfigFile: /etc/ldap/slapd.conf
-olcConfigDir: /etc/ldap/slapd.d/
-# List of arguments that were passed to the server
-olcArgsFile: /var/run/slapd/slapd.args
-#
-olcAttributeOptions: lang-
-olcAuthzPolicy: none
-olcConcurrency: 0
-olcConnMaxPending: 100
-olcConnMaxPendingAuth: 1000
-olcIdleTimeout: 0
-olcIndexSubstrIfMaxLen: 4
-olcIndexSubstrIfMinLen: 2
-olcIndexSubstrAnyLen: 4
-olcIndexSubstrAnyStep: 2
-olcIndexIntLen: 4
-olcListenerThreads: 1
-olcLocalSSF: 71
-# Read slapd.conf(5) for possible values
-olcLogLevel: None
-# Where the pid file is put. The init.d script
-# will not stop the server if you change this.
-olcPidFile: /var/run/slapd/slapd.pid
-olcReverseLookup: FALSE
-olcThreads: 16
-# TLS Support
-olcTLSCertificateFile: /etc/yunohost/certs/yunohost.org/crt.pem
-olcTLSCertificateKeyFile: /etc/yunohost/certs/yunohost.org/key.pem
-olcTLSVerifyClient: never
-olcTLSProtocolMin: 0.0
-# The tool-threads parameter sets the actual amount of cpu's that is used
-# for indexing.
-olcToolThreads: 1
-structuralObjectClass: olcGlobal
-
-#
-# Schema and objectClass definitions
-#
-dn: cn=schema,cn=config
-objectClass: olcSchemaConfig
-cn: schema
-
-include: file:///etc/ldap/schema/core.ldif
-include: file:///etc/ldap/schema/cosine.ldif
-include: file:///etc/ldap/schema/nis.ldif
-include: file:///etc/ldap/schema/inetorgperson.ldif
-include: file:///etc/ldap/schema/mailserver.ldif
-include: file:///etc/ldap/schema/sudo.ldif
-include: file:///etc/ldap/schema/permission.ldif
-
-#
-# Module management
-#
-dn: cn=module{0},cn=config
-objectClass: olcModuleList
-cn: module{0}
-# Where the dynamically loaded modules are stored
-olcModulePath: /usr/lib/ldap
-olcModuleLoad: {0}back_mdb
-olcModuleLoad: {1}memberof
-structuralObjectClass: olcModuleList
-
-#
-# Frontend database
-#
-dn: olcDatabase={-1}frontend,cn=config
-objectClass: olcDatabaseConfig
-objectClass: olcFrontendConfig
-olcDatabase: {-1}frontend
-olcAddContentAcl: FALSE
-olcLastMod: TRUE
-olcSchemaDN: cn=Subschema
-# Hashes to be used in generation of user passwords
-olcPasswordHash: {SSHA}
-structuralObjectClass: olcDatabaseConfig
-
-#
-# Config database Configuration (#0)
-#
-dn: olcDatabase={0}config,cn=config
-objectClass: olcDatabaseConfig
-olcDatabase: {0}config
-# Give access to root user.
-# This give the possiblity to the admin to customize the LDAP configuration
-olcAccess: {0}to *  by * none
-olcAddContentAcl: TRUE
-olcLastMod: TRUE
-olcRootDN: cn=config
-structuralObjectClass: olcDatabaseConfig
-
-#
-# Main database Configuration (#1)
-#
-dn: olcDatabase={1}mdb,cn=config
-objectClass: olcDatabaseConfig
-objectClass: olcMdbConfig
-olcDatabase: {1}mdb
-# The base of your directory in database #1
-olcSuffix: dc=yunohost,dc=org
-#
-# The userPassword by default can be changed
-# by the entry owning it if they are authenticated.
-# Others should not be able to see it, except the
-# admin entry below
-# These access lines apply to database #1 only
-olcAccess: {0}to attrs=userPassword,shadowLastChange
-    by dn.base="cn=admin,dc=yunohost,dc=org" write
-    by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
-    by anonymous auth
-    by self write
-    by * none
-#
-# Personnal information can be changed by the entry
-# owning it if they are authenticated.
-# Others should be able to see it.
-olcAccess: {1}to attrs=cn,gecos,givenName,mail,maildrop,displayName,sn
-    by dn.base="cn=admin,dc=yunohost,dc=org" write
-    by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
-    by self write
-    by * read
-#
-# Ensure read access to the base for things like
-# supportedSASLMechanisms.  Without this you may
-# have problems with SASL not knowing what
-# mechanisms are available and the like.
-# Note that this is covered by the 'access to *'
-# ACL below too but if you change that as people
-# are wont to do you'll still need this if you
-# want SASL (and possible other things) to work
-# happily.
-olcAccess: {2}to dn.base=""
-    by * read
-#
-# The admin dn has full write access, everyone else
-# can read everything.
-olcAccess: {3}to *
-    by dn.base="cn=admin,dc=yunohost,dc=org" write
-    by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
-    by group/groupOfNames/member.exact="cn=admin,ou=groups,dc=yunohost,dc=org" write
-    by * read
-#
-olcAddContentAcl: FALSE
-# Save the time that the entry gets modified, for database #1
-olcLastMod: TRUE
-# Where the database file are physically stored for database #1
-olcDbDirectory: /var/lib/ldap
-# Checkpoint the BerkeleyDB database periodically in case of system
-# failure and to speed slapd shutdown.
-olcDbCheckpoint: 512 30
-olcDbNoSync: FALSE
-# Indexing options for database #1
-olcDbIndex: objectClass eq
-olcDbIndex: entryUUID eq
-olcDbIndex: entryCSN eq
-olcDbIndex: cn eq
-olcDbIndex: uid eq,sub
-olcDbIndex: uidNumber eq
-olcDbIndex: gidNumber eq
-olcDbIndex: sudoUser eq,sub
-olcDbIndex: member eq
-olcDbIndex: mail eq
-olcDbIndex: memberUid eq
-olcDbIndex: uniqueMember eq
-olcDbIndex: virtualdomain eq
-olcDbIndex: permission eq
-olcDbMaxSize: 10485760
-structuralObjectClass: olcMdbConfig
-
-#
-# Configure Memberof Overlay (used for Yunohost permission)
-#
-
-# Link user <-> group
-dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
-objectClass: olcOverlayConfig
-objectClass: olcMemberOf
-olcOverlay: {0}memberof
-olcMemberOfDangling: error
-olcMemberOfDanglingError: constraintViolation
-olcMemberOfRefInt: TRUE
-olcMemberOfGroupOC: groupOfNamesYnh
-olcMemberOfMemberAD: member
-olcMemberOfMemberOfAD: memberOf
-structuralObjectClass: olcMemberOf
-
-# Link permission <-> groupes
-dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config
-objectClass: olcOverlayConfig
-objectClass: olcMemberOf
-olcOverlay: {1}memberof
-olcMemberOfDangling: error
-olcMemberOfDanglingError: constraintViolation
-olcMemberOfRefInt: TRUE
-olcMemberOfGroupOC: permissionYnh
-olcMemberOfMemberAD: groupPermission
-olcMemberOfMemberOfAD: permission
-structuralObjectClass: olcMemberOf
-
-# Link permission <-> user
-dn: olcOverlay={2}memberof,olcDatabase={1}mdb,cn=config
-objectClass: olcOverlayConfig
-objectClass: olcMemberOf
-olcOverlay: {2}memberof
-olcMemberOfDangling: error
-olcMemberOfDanglingError: constraintViolation
-olcMemberOfRefInt: TRUE
-olcMemberOfGroupOC: permissionYnh
-olcMemberOfMemberAD: inheritPermission
-olcMemberOfMemberOfAD: permission
-structuralObjectClass: olcMemberOf
      status: modified
yunohost: 
  applied: 
  pending: 
    /etc/systemd/system/ntp.service.d/ynh-override.conf: 
      diff: @@ -1,3 +0,0 @@
-[Unit]
-ConditionCapability=CAP_SYS_TIME
-ConditionVirtualization=!container
      status: modified
root@pigeonsrapides:~# ```

Ici on voit une grosse modif pour slapd, donc pour se connecter au LDAP, je tenterais cela pour remettre d’aplomb les fichiers /etc/ldap/slapd.ldif, /etc/systemd/system/ntp.service.d/ynh-override.conf, /etc/apt/sources.list.d/extra_php_version.list et le dnsmasq

yunohost tools regen-conf --force

Je viens de taper cette commande

qui me donne

root@pigeonsrapides:~# yunohost tools regen-conf --force
Succès ! La configuration a été mise à jour pour 'yunohost'
Succès ! La configuration a été mise à jour pour 'slapd'
Succès ! La configuration a été mise à jour pour 'apt'
Succès ! La configuration a été mise à jour pour 'dnsmasq'
apt: 
  applied: 
    /etc/apt/sources.list.d/extra_php_version.list: 
      status: force-updated
  pending: 
dnsmasq: 
  applied: 
    /etc/resolv.dnsmasq.conf: 
      status: updated
  pending: 
slapd: 
  applied: 
    /etc/ldap/slapd.ldif: 
      status: force-removed
  pending: 
yunohost: 
  applied: 
    /etc/systemd/system/ntp.service.d/ynh-override.conf: 
      status: force-removed
  pending: 
root@pigeonsrapides:~# 
Broadcast message from root@pigeonsrapides.fr (Thu 2024-11-07 15:17:57 CET):

The system will reboot now!

Connection to 192.168.1.49 closed by remote host.
Connection to 192.168.1.49 closed.
philippe@debianPhil:~$ 

maintenant le résultat de

yunohost tools regen-conf -n -d

est beaucoup plus court

root@pigeonsrapides:~# yunohost tools regen-conf -n -d
Succès ! La configuration aurait dû être mise à jour pour la catégorie 'dnsmasq'
dnsmasq: 
  applied: 
    /etc/resolv.dnsmasq.conf: 
      diff: @@ -1,20 +1,20 @@
+nameserver 194.150.168.168
 nameserver 2001:1608:10:25::1c04:b12f
-nameserver 2001:67c:28a4::
+nameserver 84.200.69.80
+nameserver 2001:910:800::40
+nameserver 80.67.169.40
 nameserver 2001:910:800::12
 nameserver 2001:1608:10:25::9249:d69b
-nameserver 2a00:5881:8100:1000::3
 nameserver 80.67.169.12
-nameserver 84.200.70.40
-nameserver 195.160.173.53
-nameserver 194.150.168.168
-nameserver 84.200.69.80
-nameserver 2a01:3a0:53:53::
-nameserver 2001:910:800::40
-nameserver 91.239.100.100
+nameserver 185.233.100.101
 nameserver 185.233.100.100
 nameserver 2a0c:e300::100
+nameserver 195.160.173.53
 nameserver 89.233.43.71
+nameserver 89.234.141.66
+nameserver 84.200.70.40
+nameserver 2a00:5881:8100:1000::3
+nameserver 2001:67c:28a4::
+nameserver 2a01:3a0:53:53::
+nameserver 91.239.100.100
 nameserver 2a0c:e300::101
-nameserver 89.234.141.66
-nameserver 185.233.100.101
-nameserver 80.67.169.40
      status: updated
  pending: 
root@pigeonsrapides:~# 

Après un redémarrage j’ai encore le problême et aussi en ne redémarrant que l’API toujours l’erreur 502.

Est-ce que tu arrives à te connecter au portail ?

Nop,
Pas de réaction jusqu’à “l’erreur 504”

EDIT 15h36
le diagnostic dit

Il y a eu récemment un grand nombre d'échecs d'authentification. Assurez-vous que Fail2Ban est en cours d'exécution et est correctement configuré, ou utilisez un port personnalisé pour SSH comme expliqué dans https://yunohost.org/security.

est-ce utile de tripoter “fail2Ban” ?

Edit 15h39 aparemment non je viens d’arreter fail2ban et essayer de me logger j’ai toujours cette “erreur 504”

On dirait que ce n’est pas le bon identifiant ou mot de passe ??
Est-ce que ça ne vaudrait pas le coup d’essayer de changer le mote de passe en ligne de commande ??

yunohost user update mon_identifiant  -p 'mon_super_mot_de_passe'  

faut-il passer cette commande en root ou en simple admin ?

là en root pour changer le mot de passe de l’utilisateur…

Question: tu pouvais accéder à la webadmin ? Tu peux y accéder de nouveau ?

Je viens de changer le mot de passe en root.

Oui Je peux acceder à la webadmin. Je rechange mon mot de passe par là aussi ?