Crash du l'app en configurant le port 443

poka · 17 October 2017 13:50

Je viens d’ouvrir un ticket github pour mon problème, mais je me rend compte que j’aurais très bien pu l’exposer ici: https://github.com/duniter/duniter/issues/1153

Pour résumer l’app duniter crash lorsque je souhaite configurer le remote port sur 443, de manière à accéder à mon noeud en https: g1.citiz-network.org:16262/network/peering

Rien n’écoute le port 443 sur le serveur et le crash n’a pas lieu lorsque j’essai n’importe quel autre port.
Plus d’infos sur le ticket.

Aurais-je omis quelque chose ?
J’utilise Ubuntu 16.04 et Duniter 1.6.10.

cgeek · 17 October 2017 14:02

Ce serveur n’a vraiment aucun Nginx ou Apache en route ?

En tout cas, tu peux voir la raison du crash en lançant avec direct_start par exemple.

elois · 17 October 2017 14:46

@poka BMA ne sais pas faire de https, pour avoir BMA accessible en https il te faut un reverse proxy nginx (ou autre) qui redirige sur ton serveur duniter, c’est seulement à ça que servent les options port et remotePort.
Sans reverse proxy, il faut que port=remotePort.

En revanche WS2P ~~sais faire du wss nativement sur 443~~ en fait non plus cf. réponse de cgeek.

Peut tu nous partager ton fichier de conf ?

Aussi évite de modifier manuellement le fichier de conf, utilise plutôt la commande duniter wizard network, comme expliqué sur le wiki : https://duniter.org/fr/wiki/duniter/configurer/

cgeek · 17 October 2017 15:08

Non c’est comme pour BMA, Duniter ne gère pas de certificats HTTPS. Par contre quand il s’agit de se connecter à un WebSocket WS2P proposé sur le port 443, alors le logiciel tentera de se connecter avec le protcole wss:// (sécurisé) plutôt que ws://.

Mais pour celui qui propose WS2P sur 443, il y a forcément un Nginx/Apache derrière.

poka · 17 October 2017 16:23

Non rien n’écoute le 443, apache et nginx off, le résultat de cette command est null:
netstat -pnl | grep 443

Ok alors au risque de paraître débile, en faite l’alias de la commande duniter ne s’est pas fait, et je ne vois pas où est l’executable duniter sur ma ubuntu:
./duniter start dans /opt/duniter/bin/ ne fonctionne pas, ni node duniter start …
Je l’ai simplement installer avec un dpkg -i duniter.deb et j’utilise l’interface graphique, rien de plus.

Pour répondre a @elois, j’ai bien configurer mon nginx en reverse proxy pour rediriger vers le noeud depuis le port 443, avec certificat Let’s Encrypt: https://g1.citiz-network.org/network/peering

Cependant, depuis Cesium, mon noeud est référencé comme étant sur le port 16262, donc le lien est mort. C’est pour cela que je souhaite le configurer en 443 localement.

Comme demandé, voici ma config:

{
 "currency": "g1",
 "endpoints": [],
 "rmEndpoints": [],
 "upInterval": 3600000,
 "c": 0.0488,
 "dt": 86400,
 "dtReeval": 15778800,
 "ud0": 1000,
 "stepMax": 5,
 "sigPeriod": 432000,
 "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,
 "sync": {},
 "cpu": 0.6,
 "port": 16262,
 "remoteport": 16262,
 "upnp": false,
 "ipv4": "10.0.2.122",
 "sigStock": 100,
 "sigWindow": 5259600,
 "idtyWindow": 5259600,
 "msWindow": 5259600,
 "rootoffset": 0,
 "remotehost": "g1.citiz-network.org",
 "remoteipv6": "fe80::51ac:e293:7f42:1a4a",
 "ipv6": "fe80::51ac:e293:7f42:1a4a",
 "dos": {
  "whitelist": [
   "127.0.0.1",
   "10.0.2.122",
   "fe80::51ac:e293:7f42:1a4a"
  ],
  "maxcount": 80,
  "burst": 20,
  "limit": 40,
  "maxexpiry": 120,
  "checkinterval": 1,
  "trustProxy": true,
  "includeUserAgent": true,
  "errormessage": "Error",
  "testmode": false,
  "silent": false,
  "silentStart": true,
  "responseStatus": 429
 },
 "udTime0": 1488970800,
 "udReevalTime0": 1490094000,
 "loglevel": "info",
 "msPeriod": 5259600,
 "prefix": 1,
 "nobma": false,
 "ws2p": {
  "uuid": "82745ee3",
  "privateAccess": true,
  "publicAccess": true,
  "upnp": true,
  "maxPublic": 10,
  "maxPrivate": 10,
  "remotepath": ""
 }
}

Je précise car ce n’est pas forcément évident que mon reverse proxy se trouve sur un container LXC différent de la VM hébergeant le noeud.

cgeek · 17 October 2017 16:29

Ah mais alors tu as juste à configurer remoteport à 443

poka · 17 October 2017 16:39

C’est ça qui bug justement, quand je fait ça, crash, et pas d’erreur loggué au redémarrage
Que je change juste le remoteporte ou bien le localport ou les 2, ça crash direct quand j’applique le changement, que ce soit depuis l’interface graphique ou bien directement dans le fichier de conf (et pas de duniter wizard car l’alias n’est pas config et je ne trouve pas le bin …)

elois · 17 October 2017 17:08

Tu devrais passer a duniter-server, c’est le même programme mais sans le navigateur intégré, pour un utilisateur qui veut faire du https c’est mieux, tu aura davantage la main (la version desktop sert juste a être “user-friendly”).

Une fois ton nœud lancé avec duniter webstart il te suffit d’aller sur localhost:9220 pour accéder a l’interface graphique

poka · 17 October 2017 17:42

Aaaah ok on en découvre tous les jours lol. Voila j’utilise donc duniter-server, donc lorsque je change le remoteport pour 443, voila ce que m’affiche duniter direct_start:

2017-10-17T19:40:39+02:00 - debug: Plugging file system...
2017-10-17T19:40:39+02:00 - debug: Loading conf...
2017-10-17T19:40:39+02:00 - debug: Configuration saved.
2017-10-17T19:40:39+02:00 - debug: Opening SQLite database "/home/poka/.config/duniter/duniter_default/duniter.db"...
2017-10-17T19:40:39+02:00 - debug: Upgrade database...
2017-10-17T19:40:39+02:00 - info: Block resolution: 0 potential blocks after current#61607...
2017-10-17T19:40:39+02:00 - info: >> Server starting...
2017-10-17T19:40:39+02:00 - info: Node version: 1.5.9
2017-10-17T19:40:39+02:00 - info: Node pubkey: Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P
2017-10-17T19:40:39+02:00 - info: Crawling the network...
2017-10-17T19:40:39+02:00 - info: Pulling blocks from the network...
2017-10-17T19:40:39+02:00 - info: Duniter server listening on http://10.0.2.122:16262
2017-10-17T19:40:39+02:00 - error: Error on WS Server
2017-10-17T19:40:39+02:00 - error:  Error: listen EACCES fe80::51ac:e293:7f42:1a4a:443
    at Object.exports._errnoException (util.js:1020:11)
    at exports._exceptionWithHostPort (util.js:1043:20)
    at Server._listen2 (net.js:1245:19)
    at listen (net.js:1294:10)
    at net.js:1404:9
    at _combinedTickCallback (internal/process/next_tick.js:83:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
2017-10-17T19:40:39+02:00 - error:  Error: listen EACCES fe80::51ac:e293:7f42:1a4a:443
    at Object.exports._errnoException (util.js:1020:11)
    at exports._exceptionWithHostPort (util.js:1043:20)
    at Server._listen2 (net.js:1245:19)
    at listen (net.js:1294:10)
    at net.js:1404:9
    at _combinedTickCallback (internal/process/next_tick.js:83:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)

elois · 17 October 2017 19:04

Comme tu est en 1.6 tu a deux api : BMA et WS2P, comment a tu configuré chacune ? Typiquement si les deux écoutent sur le même port ça ne peut pas fonctionner. Tu peut faire un duniter check-config et vérifier que tu obtiens bien :
warn: Configuration seems correct.

A la vue de tes log je vois que tu a configurer le port d’écoute sur 443 pour au moins une des api, hors ça ne peut pas fonctionner puisque c’est ton nginx qui écoute déjà sur 443. C’est seulement le remote port qu’il faut configurer a 443, le port lui doit être différent (typiquement 10901 pour BMA et 20901 pour WS2P public par exemple).

De plus si tu veut que les deux api (bma et ws2p) écoutent sur 443 il te faut définir un patch pour ws2p, je n’ai pas encore documenté cette fonction tiens, je vais m’y mettre de suite

EDIT : C’est fait. la commande est :

duniter config --ws2p-remote-path <path>

cgeek · 17 October 2017 19:24

C’est un bon conseil mais je ne suis pas sûr que la commande vérifier les conflits de port !

Non Poka dit que justement cette machine n’a pas de Nginx, c’est une VM (un container) à part. Il y a reverse proxy du port 443 par la machine hôte vers son container, ceci étant piloté par un Nginx dans l’hôte je pense.

Oui à mon avis c’est plus ça le problème. Il y a vraisemblablement un autre service qui écoute ce même port 443, mais qui ne serait pas Nginx ni Apache. Mais ce n’est pas WS2P, car la config utilise UPnP ici.

@poka : déjà tu peux retirer le remoteipv6, vu que tu as déjà la résolution DNS par remotehost. Tu peux gérer les résolutions IPv4 et IPv6 par tes enregistrements DNS.

Aussi, que dit un ps aux | grep duniter ? Il se peut que tu aies 2 installations concurrentes. Notamment si c’est le même container que tu utilises depuis le début de Duniter, tu as certainement un ~/.duniter qui co-existe et pollue peut-être ton installation qui se trouve normalement dans /opt/duniter.

Déjà tu peux supprimer l’application avec un dpkg -r duniter, et vérifier que la commande duniter config ne fonctionne plus (tu dois avoir une erreur système, « commande non reconnue »).

poka · 17 October 2017 21:36

Alors je n’ai pas été configurer aussi loin la chose, il s’agit ici d’une install fraiche, désormais en 1.5.9 car il s’agit de la dernière disponible pour duniter-server. duniter-desktop a été désinstallé et il n’y aucune autre instance duniter de lancé (pas de ~/.duniter)

C’est bien le cas

Comme l’a dit cgeek mon nginx n’est pas sur ce système, mais sur une autre VM, c’est mon reverse proxy général pour tout mes sous-domaines entre VM. Rien n’écoute le port 443 et c’est vérifier par la commande:
netstat -pnl | grep 443

Rien de lancé actuellement

C’est fait

Avant que je n’install duniter-server je n’avais que le desktop qui n’avait pas d’alias de commande duniter installé, donc duniter config n’existait pas.

poka · 17 October 2017 21:58

Ok donc j’ai plus de précisions: En réalité se sont tous les ports inférieurs à 1024 en remoteport qui amènent ce crash C’est cocasse ^^
Et alors là je n’ai plus la moindre idée de pourquoi, car je soupçonnait avant ça la nature de ma translation de port par iptables pour les port 80 et 443 vers ma VM nginx (reverse proxy pour toutes mes VM par sous-domaine) mais la du coup pas du tout.
1024 ce n’est pas un nombre random voyez-vous, une idée du coup de se que ça pourrait vouloir dire ?
Un conflit entre BMA et WS2P comme vous dites ? Je n’ai pas touché a cela, je ne sais même pas se que c’est
Comment vérifier ?

Leo · 17 October 2017 22:48

C’est pas une histoire de permissions ?

elois · 17 October 2017 23:04

Oui c’est le plus probable.

Si tu est en 1.5.9 non, ws2p n’existe qu’a partir des versions 1.6.x

Inso · 18 October 2017 04:03

Une application doit être Root pour pouvoir se binder sur un port <= 1024

cgeek · 18 October 2017 07:18

Ça ressemble beaucoup à une erreur de permissions oui. Mais c’est curieux, car ton port d’écoute est 16262 si j’ai bien compris.

Retire carrément le champ ipv6 pour voir ?

poka · 18 October 2017 09:26

Bon effectivement il suffisait de lancer duniter en root pour que cela fonctionne

Maintenant j’ai donc lancé mon noeud avec le port 16262 en locale et 443 en remoteport. Sur mon nginx je redirige donc vers le port 443 mais cela ne fonctionne pas pour le moment, mon noeud n’apparaît même pas sous cesium. Je vais attendre que les changements se propage peut être.

PS: Chose étrange, j’ai tester avec le port 450 pour voir, cela ne marchait pas, j’ai remis 16262, et là mon noeud s’affichait avec le port 450 sous cesium, puis disparait, et c’est toujours le cas quel que soit le port que je mette en remoteport, le serveur redémarre, le noeud s’affiche en port 450 sous cesium pendant quelques secondes puis disparait. Je vais attendre un peu que tout se propage avec le port 443.

PS2: Donc mon noeud est configuré en remoteport 443, mais n’est accessible qu’avec un nginx qui pointe vers le port 16262 et a cette adresse: https://g1.citiz-network.org/network/peering
Qui indique que le port est en 450 !

 "cpu": 0.6,
 "port": 16262,
 "remoteport": 443,
 "upnp": false,

cgeek · 18 October 2017 09:39

BASIC_MERKLED_API g1.citiz-network.org fe80::51ac:e293:7f42:1a4a 450

Je me répète, mais tu devrais vraiment retirer cette IPv6. En plus c’est une IP de réseau local il me semble.

C’est possiblement à cause de cette IPv6 de réseau local, qui fait échouer la connexion.

Inso · 18 October 2017 09:43

Je crois que tu t’embrouilles tout seul poka (no offence ^^)

Il faut que tu configures ton système comme ci-dessous :

Duniter doit écouter sur un port > 1024 (exemple : 16262) et déclarer “443” en port remote
Nginx doit écouter sur le port 443 et faire reverse proxy vers le port de Duniter (16262)

Ce qui va se passer :

Duniter va propager une ficher réseau qui pointera vers le port 443 (Nginx). Les connexions sur le 443 seront proxifiées par Nginx vers le port 1626 de Duniter.

Voila !