Metronome : pas les droits pour lire les certificats

Support
,
1

Salut,
J’ai une erreur sur métronome, qui est arrivée je pense après une mise à jour. J’ai mis du temps à m’en rendre compte, c’est juste certains contacts n’étaient plus jamais connectés. En gros je peux communiquer avec les adresse jabber, mais pas les auto-hébergés.
Dans /etc/metronome/metronome.log j’ai ça :

Nov 21 16:07:03 certmanager error SSL/TLS: Failed to load '/etc/yunohost/certs/domain.tld/key.pem': Check that the permissions allow Metronome to read this file. (for domain.tld)

J’avais touché au fichier de conf de métronome pour essayer d’activer certaines XEP, mais je ne pense pas que ça soit lié vu que ça a plutôt l’air d’être un problème de droits. Les droits sur les certificats sont :

-rw-r----- 1 root ssl-cert 3,7K nov.  10 06:38 crt.pem
-rw-r----- 1 root ssl-cert 2,5K nov.  10 06:37 key.pem

Et metronome fait bien partie du groupe ssl-cert :

getent group ssl-cert
ssl-cert:x:114:metronome,postgres

Résultat des investigations sur le chat :

  • Metronome a accès au dossier /etc/yunohost/certs, mais pas à /etc/yunohost/certs/domain.tld
  • /etc/yunohost/certs/domain.tld -> /etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt

Si quelqu’un a une idée…

Je suis sur yunohost 3.2.2 sur un PC en 64 bits.

2

Le probleme se trouve donc probablement dans les permissions de /etc/yunohost/certs/domain.tld

Que donne ls -ld /etc/yunohost/certs/domain.tld ? (pas juste les proprietaires, mais les permissions au début de la sortie)

3

Ça donne ça :

lrwxrwxrwx 1 root root 64 nov. 10 06:38 /etc/yunohost/certs/domain.tld -> /etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt

4

Et ls -ld /etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt ?

5

drw-r-xr-x 2 root root 4096 nov. 10 06:38 /etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt

6

Mais du coup sudo -u metronome ls -ld /etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt ne fonctionne pas ?

7

Non :

root@serveur:/etc/yunohost/certs# sudo -u metronome ls -ld /etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt
ls: impossible d'accéder à '/etc/yunohost/certs//domain.tld-history/20181110.063804-letsencrypt': Permission non accordée
8

Et pour ma culture, il correspond à quoi le double slash ?

9

À rien du tout :wink: C’est comme un slash normal, c’est juste que la facon dont est construite ce chemin lorsque le lien est défini, il a un double slash (genre il concatene un morceau qui commence avec un / avec un autre morceau qui commence par /, bref~).

Bon mais du coup est-ce que ça ça marche :

sudo -u metronome ls -ld /etc/yunohost/certs/
sudo -u metronome ls -ld /etc/yunohost/
10

Oui :

root@serveur:/etc/yunohost/certs/domain.tld-history# sudo -u metronome ls -ld /etc/yunohost/certs/
drwxr-xr-x 34 root root 4096 nov.  16 06:39 /etc/yunohost/certs/
root@serveur:/etc/yunohost/certs/domain.tld-history# sudo -u metronome ls -ld /etc/yunohost/
drwxr-xr-x 5 root root 4096 sept. 30 00:01 /etc/yunohost/

C’est vraiment l’accès au dernier dossier qui n’est pas accordé :

root@serveur:~# sudo -u metronome ls -ld /etc/yunohost/certs/domain.tld-history/
drwx------ 13 root root 4096 nov.  10 06:38 /etc/yunohost/certs/domain.tld-history/
root@serveur:~# sudo -u metronome ls -ld /etc/yunohost/certs/domain.tld-history/20181110.063804-letsencrypt/
ls: impossible d'accéder à '/etc/yunohost/certs/domain.tld-history/20181110.063804-letsencrypt/': Permission non accordée
11

Ah voilà.

Donc t’es censé avoir drwxr-xr-x pour le dossier -history … pas sur de comprendre pourquoi ce n’est pas le cas chez toi …

Mais du coup la commande suivante devrait régler le probleme :

chmod 755 /etc/yunohost/certs/domain.tld-history/
12

Effectivement c’est bizarre :

root@serveur:/etc/yunohost/certs/domain.tld-history# ls -lh
total 44K
drwx------ 2 root root 4,0K mars  23  2017 20170209.120031-letsencrypt
drwxr-xr-x 2 root root 4,0K mars  23  2017 20170323.012015-selfsigned
drw-r-xr-x 2 root root 4,0K mars  23  2017 20170323.012031-letsencrypt
drw-r-xr-x 2 root root 4,0K juin   5  2017 20170605.062802-letsencrypt
drw-r-xr-x 2 root root 4,0K août  19  2017 20170819.062725-letsencrypt
drw-r-xr-x 2 root root 4,0K nov.   1  2017 20171101.063243-letsencrypt
drw-r-xr-x 2 root root 4,0K janv. 17  2018 20180117.082829-letsencrypt
drw-r-xr-x 2 root root 4,0K avril  1  2018 20180401.064128-letsencrypt
drw-r-xr-x 2 root root 4,0K juin  14 06:44 20180614.064410-letsencrypt
drw-r-xr-x 2 root root 4,0K août  28 09:10 20180828.091000-letsencrypt
drw-r-xr-x 2 root root 4,0K nov.  10 06:38 20181110.063804-letsencrypt

J’ai fait ta commande pour les domaines qui posaient problème, et c’est bon, je n’ai plus d’erreur sur les certificats au démarrage de métronome. Par contre je n’arrive toujours pas à contacter 2 serveurs de copains autohébergés :

Nov 21 21:28:53 general info    Hello and welcome to Metronome version 3.11.1
Nov 21 21:28:53 general info    Metronome is using the epoll backend for connection handling
Nov 21 21:28:53 portmanager     info    Activated service 'console'
Nov 21 21:28:53 portmanager     info    Activated service 'c2s'
Nov 21 21:28:53 portmanager     info    Activated service 'c2s_secure'
Nov 21 21:28:53 portmanager     info    Activated service 's2s'
Nov 21 21:28:53 portmanager     info    Activated service 's2s_secure'
Nov 21 21:28:53 portmanager     info    Activated service 'http'
Nov 21 21:28:53 portmanager     info    Activated service 'https'
Nov 21 21:28:53 mod_posix       info    Successfully daemonized to PID 29270
Nov 21 21:29:05 c2s562173640920 info    Client connected
Nov 21 21:29:05 c2s562173640920 info    Authenticated as justine@mondomain.tld
Nov 21 21:29:05 c2s562173640920 warn    Attempted to resume unexistent session with id a92d4c9a-70a1-46f7-8c2c-43965852a2b1
Nov 21 21:29:05 s2sout56217302e080      info    Beginning new connection attempt to copain1.tld ([89.234.141.17]:5269)
Nov 21 21:29:05 s2sout5621736ccb40      info    Beginning new connection attempt to jabber.fr ([62.210.214.37]:5269)
Nov 21 21:29:05 s2sout5621738d1000      info    Beginning new connection attempt to copain2.tld ([109.190.184.96]:5269)
Nov 21 21:29:05 s2sout5621738d1000      info    sent dialback key on outgoing s2s stream
Nov 21 21:29:05 s2sout5621736ccb40      info    outgoing s2s connection mondomain.tld->jabber.fr complete
Nov 21 21:29:05 s2sout56217302e080      info    sent dialback key on outgoing s2s stream
Nov 21 21:29:06 s2sin5621737aa060       info    incoming s2s connection jabber.fr->mondomain.tld complete
Nov 21 21:29:07 c2s562173861910 info    Client connected
Nov 21 21:29:07 c2s562173861910 info    Authenticated as tom@mondomain.tld
Nov 21 21:29:26 s2sin5621731cef00       info    incoming s2s connection copain1.tld->mondomain.tld complete
Nov 21 21:29:26 s2sin5621731cef00       info    incoming s2s stream copain1.tld->mondomain.tld closed: stream closed
Nov 21 21:30:35 s2sout56217302e080      info    outgoing s2s stream mondomain.tld->copain1.tld closed: connection-timeout
Nov 21 21:30:35 s2sout56217302e080      info    sending error replies for 4 queued stanzas because of failed outgoing connection to copain1.tld
Nov 21 21:30:35 s2sout5621738d1000      info    outgoing s2s stream mondomain.tld->copain2.tld closed: connection-timeout
Nov 21 21:30:35 s2sout5621738d1000      info    sending error replies for 2 queued stanzas because of failed outgoing connection to copain2.tld

Je ne sais pas si le problème vient de chez moi ou de chez eux. Pour info, j’ai modifié la conf de métronome pour accepter les connexions sans certificats (si j’ai bien compris ce que j’ai fait) :

c2s_require_encryption = false
s2s_require_encryption = false

car un des copains en question n’a pas de certificat pour le moment (c’est juste pour tester).