* linter * Add markdown linter * add env * only check markdown * Add token * Update .github/workflows/test-suite.yml * Markdown linter * Exit code * Update script * rename * mdlint * Add an empty line after end of file * Testing disable * add text * update mdlint.sh * ori validator inclusion * Add config yml file * Remove MD041 and fix advanced-datadir file * FIx validator inclusion file conflict * Merge branch 'unstable' into markdown-linter * change files * Merge branch 'markdown-linter' of https://github.com/chong-he/lighthouse into markdown-linter * mdlint * Remove MD025 * Remove MD036 * Remove MD045 * Removr MD001 * Set MD028 to false * Remove MD024 * Remove MD055 * Remove MD029 * Remove MD040 * Set MD040 to false * Set MD033 to false * Set MD013 to false * Rearrange yml file * Update mdlint.sh and test * Test remove fix * Test with fix * Test with space * Fix summary indentation * Test mdlint.sh * Update mdlint.sh * Test * Update * Test fix * Test again * Fix * merge into check-code * Update scripts/mdlint.sh Co-authored-by: Mac L <mjladson@pm.me> * Update scripts/mdlint.sh Co-authored-by: Mac L <mjladson@pm.me> * Remove set -e * Add comment * Merge pull request #7 from chong-he/unstable Merge unstable to markdown branch * mdlint * Merge branch 'unstable' into markdown-linter * mdlint
2.9 KiB
Custom Data Directories
Users can override the default Lighthouse data directories (e.g., ~/.lighthouse/mainnet) using the --datadir flag. The custom data directory mirrors the structure of any network specific default directory (e.g. ~/.lighthouse/mainnet).
Note: Users should specify different custom directories for different networks.
Below is an example flow for importing validator keys, running a beacon node and validator client using a custom data directory /var/lib/my-custom-dir for the Mainnet network.
lighthouse --network mainnet --datadir /var/lib/my-custom-dir account validator import --directory <PATH-TO-LAUNCHPAD-KEYS-DIRECTORY>
lighthouse --network mainnet --datadir /var/lib/my-custom-dir bn --staking
lighthouse --network mainnet --datadir /var/lib/my-custom-dir vc
The first step creates a validators directory under /var/lib/my-custom-dir which contains the imported keys and validator_definitions.yml.
After that, we simply run the beacon chain and validator client with the custom dir path.
Relative Paths
Prior to the introduction of #2682 and #2846 (releases v2.0.1 and earlier), Lighthouse would
not correctly parse relative paths from the lighthouse bn --datadir flag.
If the user provided a relative path (e.g., --datadir here or --datadir ./here), the beacon
directory would be split across two paths:
~/here(in the home directory), containing:chain_dbfreezer_db
./here(in the present working directory), containing:logsnetwork
All versions released after the fix (#2846) will default to storing all files in the present
working directory (i.e. ./here). New users need not be concerned with the old behaviour.
For existing users which already have a split data directory, a backwards compatibility feature will
be applied. On start-up, if a split directory scenario is detected (i.e. ~/here exists),
Lighthouse will continue to operate with split directories. In such a scenario, the following
harmless log will show:
WARN Legacy datadir location location: "/home/user/datadir/beacon", msg: this occurs when using relative paths for a datadir location
In this case, the user could solve this warn by following these steps:
- Stopping the BN process
- Consolidating the legacy directory with the new one:
mv /home/user/datadir/beacon/* $(pwd)/datadir/beacon- Where
$(pwd)is the present working directory for the Lighthouse binary
- Removing the legacy directory:
rm -r /home/user/datadir/beacon
- Restarting the BN process
Although there are no known issues with using backwards compatibility functionality, having split directories is likely to cause confusion for users. Therefore, we recommend that affected users migrate to a consolidated directory structure.