Duniter-indexer problème de droits sur les logs

Nodes Indexers
1

Hier avec le nouveau réseau j’ai pu redémarrer sans problème mon indexeur squid avec le nouveau genesis, mais par contre, pour duniter-indexer, il y a un problème de droits :

# dans les logs
docker compose logs -f
# on voit
| Error: EACCES: permission denied, open './logs/production-logs.log'
# dans mon docker compose
volumes:
    - logs:/logs
    - resources:/resources

Je ne vois pas bien pourquoi il y a ce problème. En plus, @pini tu n’as rien changé, c’est toujours la même image de base

# avant
FROM node:18-alpine
# après
FROM docker.io/library/node:18-alpine

et tu as juste changé docker en podman.

Je ne m’y connais pas tellement en question de droits dans les conteneurs docker donc je sèche un peu, mais en attendant il n’y a pas d’indexeur à jour sur le réseau : le mien est HS et celui de cgeek est toujours sur l’ancien réseau.

2

Utilise un répertoire local à ta machine pour les logs, j’ai toujours eu ce soucis avec duniter-indexer.

Je note de màj le mien.

3

Au contraire, ce type de pb est bien plus fréquent avec un répertoire local car l’UID dans le conteneur n’est pas forcément le même que celui du propriétaire du répertoire sur l’hôte.

Avec des volumes nommés c’est bien plus rare. Je ne vais pas avoir le temps de regarder ce soir, mais je m’y mets demain matin.

4

Oui, normalement. Mais cet indexeur semble avoir une logique différente.

Mon indexeur est à jour.

5

@HugoTrentesaux Peux-tu partager ton fichier docker-compose.yml ? J’ai testé avec celui-ci mais il ne semble pas fonctionnel du tout concernant la conf postgresql :

postgres_1        | 2023-12-01 09:17:57.143 UTC [1] LOG:  starting PostgreSQL 12.17 (Debian 12.17-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
postgres_1        | 2023-12-01 09:17:57.144 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
postgres_1        | 2023-12-01 09:17:57.144 UTC [1] LOG:  listening on IPv6 address "::", port 5432
postgres_1        | 2023-12-01 09:17:57.290 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1        | 2023-12-01 09:17:57.580 UTC [68] LOG:  database system was shut down at 2023-12-01 09:17:56 UTC
postgres_1        | 2023-12-01 09:17:57.700 UTC [1] LOG:  database system is ready to accept connections
indexer_1         | Unable to map [u8; 32] to a lookup index
postgres_1        | 2023-12-01 09:18:16.865 UTC [75] FATAL:  password authentication failed for user "postgres"
postgres_1        | 2023-12-01 09:18:16.865 UTC [75] DETAIL:  Password does not match for user "postgres".
postgres_1        |     Connection matched pg_hba.conf line 99: "host all all all md5"
postgres_1        | 2023-12-01 09:18:16.950 UTC [76] FATAL:  password authentication failed for user "postgres"
postgres_1        | 2023-12-01 09:18:16.950 UTC [76] DETAIL:  Password does not match for user "postgres".
postgres_1        |     Connection matched pg_hba.conf line 99: "host all all all md5"

As-tu une version plus récente de ce fichier quelque part ?

6

Oui, en effet, je n’ai pas mis à jour celui du dépôt, par contre celui de la doc est à jour : Duniter | Duniter indexer

Voilà le mien actuel :

docker-compose.yml 
services:
  # postgres database
  postgres:
    image: postgres:12
    restart: always
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: postgrespassword

  # hasura
  graphql-engine:
    image: duniter/hasura-indexer:latest
    depends_on:
      - postgres
    restart: always
    ports:
      - 127.0.0.1:8484:8080 # 8080 already used by wotwizard
    environment:
      # postgres database
      HASURA_GRAPHQL_DATABASE_URL: postgres://postgres:postgrespassword@postgres:5432/postgres
      # enable the console served by server
      HASURA_GRAPHQL_ENABLE_CONSOLE: "true"
      # dev mode
      HASURA_GRAPHQL_DEV_MODE: "false"
      # logging
      # HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup
      # admin password
      HASURA_GRAPHQL_ADMIN_SECRET: hasura_password
      # Name of role when the Authorization header is absent in JWT
      HASURA_GRAPHQL_UNAUTHORIZED_ROLE: public
      # telemetry
      HASURA_GRAPHQL_ENABLE_TELEMETRY: "false"

  # indexer (must have duniter-archive on duniter network)
  indexer:
    image: duniter/duniter-indexer:latest
    environment:
      - POSTGRES_HOST=postgres
      - INDEXER_DUNITER_WS_ENDPOINT=ws://duniter-archive:9944
      - INDEXER_DUNITER_WS_ENDPOINT_GRAPHIQL=wss://gdev.coinduf.eu/ws
      - INDEXER_HASURA_GRAPHQL_ENDPOINT_GRAPHIQL=https://hasura.gdev.coinduf.eu
    restart: unless-stopped
    ports:
      - 127.0.0.1:3000:3000
    depends_on:
      # - duniter-archive # depends on archive node through network
      - postgres
      - graphql-engine
    volumes:
      - logs:/logs
      - resources:/resources
    # allows to connect to duniter node
    networks:
      - default
      - duniter

# define volumes
volumes:
  postgres-data:
  logs:
  resources:

# define duniter external network to allow connect to duniter archive node
networks:
  duniter:
    name: duniter-gdev-archive_default
1 Like
7

Je ne comprends pas pourquoi il n’y a aucune autre info de connexion à postgres (user, passwd) pour ce service indexer. Il ne peut pas deviner ça tout seul, si ?

J’ai toujours les erreurs d’authentification sur postgres.

8

Je crois qu’il utilise les valeurs par défaut si non précisé.

const schema = {
  type: 'object',
  properties: {
    POSTGRES_HOST: {
      type: 'string',
      default: 'localhost'
    },
    POSTGRES_USER: {
      type: 'string',
      default: 'postgres'
    },
    POSTGRES_PASSWORD: {
      type: 'string',
      default: 'postgrespassword'
    },
    POSTGRES_DB: {
      type: 'string',
      default: 'postgres'
    },

J’ai pas trop réfléchi à la question, je me suis contenté de reprendre ce qui avait été laissé par Manu et Elois en ajoutant des commentaires, et comme ça marchait avant, j’ai pas plus creusé.

Mais ça vaudrait peut-être le coup de remettre ça au propre parce qu’on n’arrête pas d’avoir des problèmes de déploiement de cet indexeur (et il y a toujours l’option de passer sur duniter-squid uniquement pour la phase de développement des outils et de reprendre duniter-indexer quand on sera plus clair sur les besoins mais ça c’est un autre sujet dont il faut qu’on parle en visio dev je pense).

9

Ah ben il faut le mettre dans le compose alors. Car quelqu’un qui va copier ce fichier et juste modifier le mot de passe va tomber sur le même problème.

Je reproduis bien l’erreur sur les logs maintenant. Je vais pouvoir instruire.

1 Like
10

Voilà ça marche. En fait pour l’utilisation de volumes nommés, les permissions par défaut sont celles du point de montage. Dans le Dockerfile il est donc impératif de créer le répertoire /logs et lui donner node:node comme propriétaire.

MR !21.

3 Likes
11

Ça a l’air si simple quand tu expliques !

J’avais pensé à ça mais n’ayant pas vu les resources dans le dockerfile, je m’étais dit qu’il avait un autre moyen de les avoir. Parce que dans le dockerfile de duniter-squid, on copie explicitement les assets : Dockerfile · main · Hugo Trentesaux / duniter-squid · GitLab

12

J’ai aussi ça dans les logs de l’indexeur en état de marche. Alors que j’ai pas ça en mode dev.
Décidément il est capricieux et difficile à débugger, celui là ><

13

Celui là je suis bien incapable de le diagnostiquer :confused:

14

Oui, ça relève pas de la mise en prod mais bien du développement. Mais comme j’ai pas le bug en mode dev, ça devient compliqué. Donc on va le laisser tranquillement en l’état, il ne gène pas, l’indexeur fait son travail avec ses bugs, et ça suffira pour un moment !

15

Je l’ai aussi, il ne m’a jamais gêné.

16

Pour tout vous dire, cet indexer m’a un peu “traumatisé” (bon le mot de fort), depuis le début, j’ai passé énormément de temps à essayer de configurer le mode dev/prod, et quand je finissais pas miracle à le faire tourner en prod je n’y touchait plus pas peur de ne plus pouvoir le faire repartir.

J’ai beaucoup de mal avec ce système de multi docker compose mergé en fonction de l’usage, je sais que certains dirons que c’est le bonne façon de faire, mais perso je n’ai vue ça nul par ailleurs (et j’ai mis en prod pas mal d’outils avec le temps), en tout cas pas sous cette forme.

Ya quelques jours sur le runtime 700 j’ai tenté de relancer l’indexer, j’y ai passé 3h, j’ai finis par reprendre les dernière conf de Hugo qui a encore changé les composes, mais rien n’y fait, j’avais des erreurs de key params déjà existantes alors que la DB est bien supprimé j’en suis sûr et certains, l’indexation semblait bien tenter de se lancer j’ai l’impression (je crois…) mais rien n’arrivait, et trop d’erreur dans les logs pour comprendre d’où ça vient… J’ai laissé tombé et juste viré mon endpoint de la conf gecko.

Je n’en ai pas parlé car j’ai l’impression d’avoir toujours les mêmes soucis avec cet indexer, et je préfère qu’on se focus sur squid qui j’espère est plus stable et plus simple à switcher du mode dev/prod.
Quand j’ai voulu y contribuer juste pour ajouter des requêtes, j’ai passé tout mon temps à essayer d’avancer dans l’environnement de dev et de stabiliser ça, en vain, ce qui a finit par me décourager…

Bref tout ce pamphlet pour ne rien dire juste me défouler de mon incapacité à prendre cet outil en main :laughing:

4 Likes
17

Rassures-toi : tu n’es pas le seul. Quand j’ai touché aux Dockerfile il y a un an je crois, j’ai dû passer deux jours pour un un résultat assez discutable. Je n’en suis pas ressorti totalement indemne :slight_smile:

3 Likes