Mise a jour en 3.7 et mes mots de passe ne fonctionnent plus

m_t · May 3, 2020, 9:25pm

Mon serveur YunoHost

Matériel: Kimsuffi OVH
Version de YunoHost: 3.6.? mis a jour vers 3.7.1
J’ai accès à mon serveur : En SSH sur une session active qui risque de se couper
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer:
Je suis censé pouvoir me connecter a mon compte admin avec une clé ssh.

Description du problème

Apres la mise a jour des autres paquets “non spéciaux”, j’ai attendu plus d’une dizaine de minutes que la mise a jour de yunohost vers la 3.7.1 se fasse.
Apres avoir rafraichi la page, mon mot de pass d’amin ne marche plus sur la web interface.
Mon compte utilisateur habituelle ne fonctionne plus non plus.

Ma session SSH est encore active. Mais le sudo et le compte utilisateur semble foireux:

admin@nsXXXXXX:~$ sudo ls
sudo: unknown uid 1007: who are you?
admin@nsXXXXXX:~$ whoami
whoami: cannot find name for user ID 1007
admin@nsXXXXXX:~$ su root
su: Cannot determine your user name.

En tentant d’ouvrir une nouvelle session, la connexion automatique avec ma clé ssh est refusée:

Using username "admin".
Debian GNU/Linux 9
admin@domain.tld's password:
Access denied

Noté que d’habitude je n’ai pas a entrer de mot de passe, la clé ssh étant suffisante.

Est-ce que quelqu’un a une idée du problrme, et comment le résoudre ?

Aleks · May 3, 2020, 9:29pm

Salut,

ça ressemble furieusement à une situation où LDAP (service slapd) est dans les choux …

Il faut que tu connectes en root … Si tu es déjà connecté en admin, tu peux faire su puis le mot de passe root sera demandé (normalement il s’agit du même que le mot de passe admin)

Ensuite tu peux tenter de faire systemctl status slapd pour investiguer, et aussi un yunohost tools regen-conf slapd

m_t · May 3, 2020, 9:31pm

Salut, malheureusement su ne fonctionne pas :

admin@nsXXXXXX:/etc$ su root
su: Cannot determine your user name.

Quand je regarde le contenu de /etc/passwd, je ne vois pas de trace du compte admin. J’imagine que c’est un soucis ?

Voici le resultat de systemctl depuis ma session:

systemctl status slapd
slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Suun 2020-05-03 23:02:57 CEST; 28min ago

Et en tentant le restart:

systemctl restart slapd
Failed to restart slapd.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files

Aleks · May 3, 2020, 9:52pm

C’est normal car admin est une utilisateur ldap, pas géré comme un user unix classique…

systemctl restart slapd
Failed to restart slapd.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files

Est-ce que tu fais ça en root du coup ?

Est-ce que tu peux essayer juste su ? (J’y crois pas trop mais bon)

Bon du coup il faut trouver un moyen de se connecter en root pour de vrai … mais ca ne peux se faire que sur le réseau local … Bref c’est un peu bizarre mais on faire ip a pour trouver l’adresse IPv6 locale (en fe80::....) de ton serveur.

Puis depuis ton shell en admin, fait un ssh -6 root@fe80::....%eth0 (en supposant que ton interface reseau est eth0)

m_t · May 3, 2020, 9:57pm

Merci beaucoup de m’assister !

Je n’arrive pas a passer en root vis le su malheureusement.

su
su: Cannot determine your user name.

En tentant le ssh vers l’ipv6 local (ma connexion est bien eth0) :

ssh -6 root@fe80::xxxxxxxxxxxxx/64%eth0
No user exists for uid 1007

L’erreur est la meme faisant un simple ssh.

Aleks · May 3, 2020, 9:59pm

Gnarf … Est-ce que si tu fais login il accepte de lancer la commande ?

Sinon il va falloir lancer une console depuis l’interface OVH je pense…

m_t · May 3, 2020, 10:01pm

Login ne veut pas se lancer sans root visiblement.
Je crois pouvoir redémarrer mon serveur en mode rescue, ce qui devrait me donner acces au systeme de fichier.
Je devrais aussi pouvoir changer mon mdp root a ce moment la (cf ce tuto).

Mais je ne sais pas si changer le MDP root est la bonne chose a faire pour le coup. Qu’en penses tu?

Merci!

Aleks · May 3, 2020, 10:03pm

Le soucis n’est pas vraiment au niveau du mot de passe root, le soucis est juste de pouvoir ouvrir un shell en root pour réparer slapd … Naivement peut-être qu’un simple reboot pourrait resoudre le soucis, mais aussi peut faire crasher plus de choses loules …

A mon avis pas besoin de lancer un mode rescue, une simple console “en browser” (comme si tu avait branché un écran…) devrait te permettre de te logger en root, mais je ne sais pas ce que fourni OVH exactement.

m_t · May 3, 2020, 10:07pm

Pour les kimsufi il n’y a pas grand choses niveaux outils il me semble.

Lorsque je tente une connexion ssh simple depuis cmder, et que j’utilises mon mon de passe admin, je prends ceci:

ssh root@xxxxxxxx
Debian GNU/Linux 9
root@xxxxxxxx's password:
Permission denied, please try again.

Est-ce que c’est moi qui deboite, ou le mot de passe root n’est pas le meme que le mdp d’admin ?

Aleks · May 3, 2020, 10:33pm

Le login root en ssh est desactivé par defaut sauf sur le reseau local

m_t · May 4, 2020, 6:59am

Ah logique.

Bon, la session n’a pas tenu pendant la nuit, je vais donc tenter:

Un reboot normal, en croisant les doigts
Si ça ne marche pas, un reboot en mode rescue qui devrait me donner acces aux fichiers de mon hdd, ou je pourrais authoriser la connexion root a distance.

Une fois avec un acces root, je commencerai a regarder du coté de slapd.

m_t · May 4, 2020, 9:47am

Le reboot normal ne suffit pas, mais au moins il ne semble pas casser plus de choses que ca (mes sites webs accessibles sans identification YNH marchent encore).

Je suis en train de tenter le mode “rescue”.
Cela semble bien fonctionner, je peux monter la bonne partition de mon disque dur, et je tente donc de permettre la connexion root via ssh avec un mot de passe.
Pour l’instant, je me contente de changer la valeur de PermitRootLogin en haut du ficher /etc/ssh/sshd_config par un yes.
Ca ne semble pas fonctionner, mais c’est peut-etre le mdp root que j’avais gardé en stock qui est invalide.

Y a-t-il autre chose de plus spécifique a Yunohost que je dervais changer pour permettre une connexion root avec mdp en ssh ?

Merci !

Aleks · May 4, 2020, 9:57am

Nope … juste changer cette valeur à yes comme tu as du le faire devrait suffir …

Si tu as perdu le mot de passe root alors on peut aussi bricoler /etc/shadow mais bon

m_t · May 4, 2020, 10:30am

Ok,

J’ai rajouté mon IP dans la whitelist de fail2ban histoire d’etre sur que le probleme ne vient pas de la.
J’ai forcé un reset de mon password root, en utilisant mon ancien mot de passe root. Bon, ca c’était juste pour etre sur que mon pass était bon.

Un nouveau reboot et j’ai maintnant un acces root qui fonctionne, mais slpad est toujours down.
Le résultat de systemctl status slapd est:

● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2020-05-04 12:20:30 CEST; 2min 7s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 923 ExecStart=/etc/init.d/slapd start (code=exited, status=1/FAILURE)

May 04 12:20:30 domain.xxxxxxxxxx.eu slapd[1044]: main: TLS init def ctx failed: -1
May 04 12:20:30 domain.xxxxxxxxxx.eu slapd[1044]: DIGEST-MD5 common mech free
May 04 12:20:30 domain.xxxxxxxxxx.eu slapd[1044]: DIGEST-MD5 common mech free
May 04 12:20:30 domain.xxxxxxxxxx.eu slapd[1044]: slapd stopped.
May 04 12:20:30 domain.xxxxxxxxxx.eu slapd[1044]: connections_destroy: nothing to destroy.
May 04 12:20:30 domain.xxxxxxxxxx.eu slapd[923]: Starting OpenLDAP: slapd failed!
May 04 12:20:30 domain.xxxxxxxxxx.eu systemd[1]: slapd.service: Control process exited, code=exited status=1
May 04 12:20:30 domain.xxxxxxxxxx.eu systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Di
May 04 12:20:30 domain.xxxxxxxxxx.eu systemd[1]: slapd.service: Unit entered failed state.
May 04 12:20:30 domain.xxxxxxxxxx.eu systemd[1]: slapd.service: Failed with result 'exit-code'.

J’ai vérifier l’état des updates en faisant un apt-get update puis apt-get upgrade et il ne me trouve rien de nouveau.
Voici le résultat de yunohost -v

yunohost:
  repo: stable
  version: 3.7.1.3
yunohost-admin:
  repo: stable
  version: 3.7.1.1
moulinette:
  repo: stable
  version: 3.7.1.1
ssowat:
  repo: stable
  version: 3.7.1.1

Voila, donc maintenant il faut que je trouve le moyen de restaurer slapd!

Edit:

Un peu plus d’info, j’ai deux services qui semblent touchés:

systemctl --state=failed
  UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
● console-setup.service loaded failed failed Set console font and keymap
● slapd.service         loaded failed failed LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)

Je n’ai jamais vu passer console-setup jusqu’ici, donc ca ne m’éclaire pas trop encore.

Aleks · May 4, 2020, 11:04am

Tu peux faire un : yunohost tools regen-conf slapd

m_t · May 4, 2020, 11:52am

En effet je remontais dans les messages et j’ai revu cette commande dont tu avais parlé.
Elle s’effectue sans erreur ni message de succes, mais slapd refuse toujours de démarrer ensuite.
Le message d’erreur de la commande status est la meme que ci dessus.

Aleks · May 4, 2020, 12:26pm

Mokay … bon de ce que je vois à priori c’est un soucis avec les permissions des certificats auquel slapd à besoin d’accéder …

Est-ce que tu peux tenter un

sudo -u openldap ls -l /etc/yunohost/certs/yunohost.org/{crt,key}.pem

Si ca ne marche pas, il faut faire les commandes successives pour trouver ce qui bloque :

sudo -u openldap ls -ld /etc/yunohost/certs/yunohost.org/
sudo -u openldap ls -ld /etc/yunohost/certs/
sudo -u openldap ls -ld /etc/yunohost/

m_t · May 4, 2020, 3:34pm

Merci encore pour l’aide. On avance !

Alors, le dossier yunohost.org ne contient qu’un fichier ca.pem, pas de trace de cert ou key.

root@xxxxxx:~# ls -lah /etc/yunohost/certs/yunohost.org/
total 12K
drwxr-x---  2 root ssl-cert 4.0K Jun 25  2017 .
drwxr-xr-x 39 root root     4.0K Apr 22 06:25 ..
-rw-r-xr--  1 root ssl-cert 1.2K Nov  6  2016 ca.pem

Les commandes suivantes donnent ça :

root@xxxxxx:~# sudo -u openldap ls -ld /etc/yunohost/certs/yunohost.org/
sudo: ldap_sasl_bind_s(): Can't contact LDAP server
drwxr-x--- 2 root ssl-cert 4096 Jun 25  2017 /etc/yunohost/certs/yunohost.org/
root@xxxxxx:~# sudo -u openldap ls -ld /etc/yunohost/certs/
sudo: ldap_sasl_bind_s(): Can't contact LDAP server
drwxr-xr-x 39 root root 4096 Apr 22 06:25 /etc/yunohost/certs/
root@xxxxxx:~# sudo -u openldap ls -ld /etc/yunohost/
sudo: ldap_sasl_bind_s(): Can't contact LDAP server
drwxr-xr-x 5 root root 4096 May  3 23:02 /etc/yunohost/

Et maintenant qu’on parle de ce dossier… Ça me ramène au sujet que j’avais posté il y a bientôt trois ans.
À l’époque, j’avais du faire la migration entre les certifs letencrypt gérés manuellement vers ceux gérés par Yunohost. En ayant la main lourde, j’avais supprimé les certifs stockés dans le dossier /etc/yunohost/certs/yunohost.org/.
Au final, ça n’avait pas pose de problème jusqu’ici semble-t-il.

Il me semble qu’à l’époque, je ne savais pas comment faire pour générer a nouveau un certif pour yunohost.org, puisque je ne le gère pas.

Edit: au passage, je voulais tester les commandes de yunohost domain puisque c’était ce que tu me conseillais dans le sujet linké au dessus.
Mais sans le serveur lapd moulinette se bloque:

yunohost domain cert-status
Error: Unable to reach LDAP server
Exception AttributeError: "'Authenticator' object has no attribute 'con'" in <bound method Authenticator.__del__ of <moulinette.authenticators.ldap.Authenticator object at 0x7879083b48d0>> ignored

Aleks · May 4, 2020, 6:36pm

Ceci devrait regenerer ton crt et key.pem :

bash /usr/share/yunohost/hooks/conf_regen/02-ssl init

Puis ensuite refaire le regen-conf slapd d’avant (et/ou ptete just restart de slapd suffit)

m_t · May 4, 2020, 7:09pm

Bonne nouvelle : ca remarche
Moyenne nouvelle : j’ai encore des questions

Voici ce que j’ai fait:
La régénération des cert a semble-t-il bien fonctionné. J’ai maintenant un cert.pem et key.pem de présent.

Slapd ne voulait pas redémarrer de suite, donc j’ai fait une regen-conf.
Toujours pas de message, mais les permissions sur les fichiers de cert sont passées de -rw-r----- à -rw-r-x---.
Pour autant, slapd me donne toujours le meme message d’erreur au démarrage.

En voyant ca, je réalise que le ca.pem est toujours le vieux fichiers. Je déplace donc tout les .pem dans un dossier de backup, je régenere le certificat, puis je relance la config de slapd.
Cette fois-ci, slapd redémarre comme il faut !

Je peux maintenant me connecter comme avant avec mon compte admin en ssh et via le web, utiliser mon compte utilisateur, etc.

Ce qui me permet enfin de vérifier les logs de la mise a jours vers la 3.7 d’hier.
Soucis : une des migration a échoué.

yesterday Run migrations
yesterday Regenerate system configurations ‘all’
yesterday Upgrade system packages

Voici les détails du log des migrations :

2020-05-03 23:02:52,242: DEBUG - Making sure we have the right permissions needed ...
2020-05-03 23:02:52,244: DEBUG - + usermod -aG ssl-cert openldap
2020-05-03 23:02:52,346: DEBUG - + chown root:openldap /etc/ldap/slapd.conf
2020-05-03 23:02:52,347: DEBUG - + chown -R openldap:openldap /etc/ldap/schema/
2020-05-03 23:02:52,349: DEBUG - + chown -R openldap:openldap /etc/ldap/slapd.d/
2020-05-03 23:02:52,351: DEBUG - + chown -R root:ssl-cert /etc/yunohost/certs/yunohost.org/
2020-05-03 23:02:52,353: DEBUG - + chmod o-rwx /etc/yunohost/certs/yunohost.org/
2020-05-03 23:02:52,355: DEBUG - + chmod -R g+rx /etc/yunohost/certs/yunohost.org/
2020-05-03 23:02:52,357: DEBUG - + '[' -z '' ']'
2020-05-03 23:02:52,358: DEBUG - + exit 0
2020-05-03 23:02:52,410: DEBUG - To view the log of the operation 'Regenerate system configurations 'slapd'', use the command 'yunohost log display 20200503-210251-regen_conf-slapd'
2020-05-03 23:02:52,420: INFO - Updating LDAP database…
2020-05-03 23:02:56,946: WARNING - Could not migrate… trying to roll back the system.
2020-05-03 23:02:57,702: INFO - System rolled back.
2020-05-03 23:02:57,704: ERROR - Migration 0011_setup_group_permission did not complete, aborting. Error: Unable to reach LDAP server

Cette migration est encore “pending” dans la section Tools > Migrations.

Avant de me lancer, je voulais juste confirmer avec toi que tout semblait bon pour pouvoir reprendre le processus de mise a jour.

Merci beaucoup !