ObolNetwork / ObolNetwork/charon-distributed-validator-node

multi-client data directory permissions

Open
#357 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

protocol
Dominant language
Shell
Stars
91
Forks
235
Avg merge
1h 42m
Merged PRs (30d)
1

Description

while incorporating vc-nimbus and vc-teku into a multi-client cluster I ran into issues with both related to permissions on the charon-distributed-validator-node/data folder. When starting the stack for the first time, Docker creates the data/ directories as root:root

Permission Requirements for Validator Client Data Directories

Different validator clients have different permission requirements for their data directories:

Nimbus
  • Requires 700 (drwx------) on data directory
  • Must be owned by container UID (1000)
Teku
  • Requires write access to create logs directory
  • May need to be owned by container UID (1000)?

work-around

modify the local charon-distributed-validator-node/data permissions as follows:

# For Nimbus
sudo mkdir -p ./data/vc-nimbus/validators
sudo chown -R 1000:1000 ./data/vc-nimbus
sudo chmod 700 ./data/vc-nimbus
sudo chmod 700 ./data/vc-nimbus/validators

# For Teku
sudo mkdir -p ./data/vc-teku/logs
sudo chown -R 1000:1000 ./data/vc-teku
sudo chmod -R 700 ./data/vc-teku

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Docker Compose volume and data-directory setup for charon-distributed-validator-node/data, focusing on the vc-nimbus and vc-teku paths. Reproduce a first-time stack startup and compare the resulting ownership and permissions with the documented client requirements; done means both clients can create or use their required directories without the manual workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, docker-compose, shell
Domain
devops, infrastructure
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.