Listen EACCES: permission denied

Nodes Duniter-v1
1

Bonjour,

J’ai quelques questions sur le fonctionnement de mon nœud Duniter.

Lorsque je démarre mon nœud, j’ai plusieurs fois l’erreur indiquée dans le titre :

error:  Error: listen EACCES: permission denied 2a01:e0a:55b:d8c1::1:3:443
    at Server.setupListenHandle [as _listen2] (net.js:1292:21)
    at listenInCluster (net.js:1357:12)
    at doListen (net.js:1496:7)
    at processTicksAndRejections (internal/process/task_queues.js:85:21)

Duniter tente de se connecter au port 443, alors que celui-ci n’est défini que comme remote port. Est-ce normal ? Y a-t-il quelque chose que j’ai oublié dans ma configuration ?

En parlant de configuration, j’ai bien vu la commande check-config, mais y a-t-il une commande qui permettrait de simplement afficher toute la configuration du nœud ? Ou est-ce que tout est dans le fichier config.json ?

Sinon, mon nœud s’est arrêté tout seul cette nuit. Rien d’inquiétant, cela arrive régulièrement sur un Raspberry Pi. Par contre, quand je l’ai redémarré, il semblait avoir perdu plusieurs options de sa configuration, et en tous cas, avait perdu les clés de mon compte, transformant mon nœud en nœud miroir. Avez-vous une idée de ce qui pourrait causer cela et comment s’en prémunir ?

Merci à tous !

2

Aucune idée je ne connais pas cette partie du code.

Il me faudrait l’avoir sous les yeux pour te le dire.

À ma connaissance non.

Oui tout est dedans. Sauf les valeurs par défaut jamais modifiées (et encore pas toutes).

Le fait que ton nœud soit devenu miroir n’ait pas nécessairement causé par une perte de conf où du trousseau, c’est même peu probable. Le plus probable c’est que tu ne sois plus membre du point de vue de la blockchain locale de ton nœud.

À tu vérifiés dans le fichier keyring.yml si ton trousseau avait changé ?

3

La voici:

{
 "currency": "g1",
 "endpoints": [],
 "rmEndpoints": [],
 "upInterval": 3600000,
 "c": 0.0488,
 "dt": 86400,
 "dtReeval": 15778800,
 "ud0": 1000,
 "stepMax": 5,
 "sigPeriod": 432000,
 "sigReplay": 5259600,
 "sigValidity": 63115200,
 "msValidity": 31557600,
 "sigQty": 5,
 "xpercent": 0.8,
 "percentRot": 0.67,
 "powDelay": 0,
 "avgGenTime": 300,
 "dtDiffEval": 12,
 "medianTimeBlocks": 24,
 "httplogs": false,
 "udid2": false,
 "timeout": 3000,
 "isolate": false,
 "forksize": 100,
 "switchOnHeadAdvance": 3,
 "nonWoTPeersLimit": 100,
 "msPeriod": 5259600,
 "storage": {
  "transactions": true,
  "wotwizard": false
 },
 "loglevel": "info",
 "cpu": 0.6,
 "nbCores": 4,
 "prefix": 1,
 "nobma": false,
 "bmaWithCrawler": false,
 "upnp": false,
 "dos": {
  "whitelist": [
   "127.0.0.1"
  ],
  "maxcount": 50,
  "burst": 20,
  "limit": 40,
  "maxexpiry": 10,
  "checkinterval": 1,
  "trustProxy": true,
  "includeUserAgent": true,
  "errormessage": "Error",
  "testmode": false,
  "silent": false,
  "silentStart": false,
  "responseStatus": 429
 },
 "ws2p": {
  "uuid": "df2ea0f2",
  "privateAccess": true,
  "publicAccess": true,
  "preferedOnly": false,
  "privilegedOnly": false,
  "upnp": false,
  "host": "retservo.int.neptura.org",
  "port": 20901,
  "remoteport": 443,
  "remotehost": "g1.neptura.org",
  "remotepath": "/ws2p"
 },
 "proxiesConf": {
  "reachingClearEp": "clear",
  "forceTor": false
 },
 "sigStock": 100,
 "sigWindow": 5259600,
 "idtyWindow": 5259600,
 "msWindow": 5259600,
 "rootoffset": 0,
 "remoteipv6": "2a01:e0a:55b:d8c1::1:3",
 "remoteport": "443",
 "ipv4": "10.21.0.3",
 "ipv6": "2a01:e0a:55b:d8c1::1:3",
 "port": "10901",
 "remoteipv4": "82.64.219.104",
 "remotehost": "g1.neptura.org",
 "udTime0": 1488970800,
 "udReevalTime0": 1490094000
}

Oui, justement, le fichier keyring.yml avait été mis à jour avec une nouvelle clé. J’ai dû aller récupérer ma vraie clé sur un autre poste.

4

Je vois quelques soucis mineurs dans ta conf réseau mais rien à voir avec tes problèmes :

  • Quand tu as un ndd il ne faut pas indiquer d’ip → supprime les champs remoteipv4 et remoteipv6.
  • Ton Duniter n’étant pas exposé frontalement, il ne doit écouter que là où le reverse proxy transmet les requêtes, donc sauf config exotique’ que en ipv4 → supprime le champ ipv6.

En effet ce n’est pas normal, mais je doute que ce soit causé par Duniter, du moins pas directement. Le plus probable est que lors du redémarrage de Duniter, ce-dernier n’est pas trouvé le fichier keyring.yml à l’emplacement attendu où n’est pas réussi à le lire; il a donc généré un trousseau aléatoire qu’il a persisté dans keyring.yml, ce qui est bien le comportement attendu.

Je penche donc pour une cause externe, un souci avec le volume docker peut-être.

5

Genre, pour une raison inconnue, il a démarré avec un mauvais nom d’utilisateur, et comme j’ai mis le mode en 640, il n’a pas réussi à le lire.

1 Like
6

Nginx transfert à un nom de domaine (interne à mon réseau). Mon réseau étant totalement dual stack, je préfère écouter les 2 protocoles, car si, en général, tout fonctionne en ipv6, il peut arriver que le service tombe et bascule en ipv4.

Si je comprends bien le code, si je ne spécifie pas de remote6, il va prendre par défaut ipv6, donc je ne peux pas le supprimer. Du coup, autant également conserver remote4.

Dans mon cas, par contre, remote6 était sensé être différent de ipv6. J’ai donc effectué la correction, et lorsque je démarre, j’ai toujours une tentative d’ouverture du port 443 sur l’interface remote… Je pense que c’est un bug…

1 Like