docs: fix docs links (#6233)

* docs: add google landing page for old layout until reindexed

* docs: fix broken links

* docs: add SECURITY to docs site pages

* chore: lint docs

* docs: remove committed security.md

* docs: fix mkdocs warnings

.gitignore

@@ -43,6 +43,7 @@ packages/**/typedocs
 docs/pages/**/*-cli.md
 docs/pages/assets
 docs/pages/images
+docs/pages/security.md
 docs/pages/lightclient-prover/lightclient.md
 docs/pages/lightclient-prover/prover.md
 docs/pages/api/api-reference.md

docs/mkdocs.yml

@@ -73,6 +73,7 @@ extra:
 nav:
   - Home: index.md
   - Introduction: introduction.md
+  - Security: security.md
   - Getting Started:
       - Quick Start: getting-started/quick-start.md
       - Installation: getting-started/installation.md
@@ -121,7 +122,7 @@ nav:
       - Dependency Graph: contribution/depgraph.md
       # - Repo: contribution/repo.md
       - Testing:
-          - Overview: contribution/testing/overview.md
+          - Overview: contribution/testing/index.md
           # - Unit Tests: contribution/testing/unit-tests.md
           # - Integration Tests: contribution/testing/integration-tests.md
           # - E2E Tests: contribution/testing/e2e-tests.md

docs/pages/beacon-management/networking.md

@@ -6,33 +6,33 @@ Starting up Lodestar will automatically connect it to peers on the network. Peer
 
 Some of the important Lodestar flags related to networking are:
 
-- [`--discv5`](./configuration.md#--discv5)
-- [`--listenAddress`](./configuration.md#--listenAddress)
-- [`--port`](./configuration.md#--port)
-- [`--discoveryPort`](./configuration.md#--discoveryPort)
-- [`--listenAddress6`](./configuration.md#--listenAddress6)
-- [`--port6`](./configuration.md#--port6)
-- [`--discoveryPort6`](./configuration.md#--discoveryPort6)
-- [`--bootnodes`](./configuration.md#--bootnodes)
-- [`--deterministicLongLivedAttnets`](./configuration.md#--deterministicLongLivedAttnets)
-- [`--subscribeAllSubnets`](./configuration.md#--subscribeAllSubnets)
-- [`--disablePeerScoring`](./configuration.md#--disablePeerScoring)
-- [`--enr.ip`](./configuration.md#--enr.ip)
-- [`--enr.tcp`](./configuration.md#--enr.tcp)
-- [`--enr.udp`](./configuration.md#--enr.udp)
-- [`--enr.ip6`](./configuration.md#--enr.ip6)
-- [`--enr.tcp6`](./configuration.md#--enr.tcp6)
-- [`--enr.udp6`](./configuration.md#--enr.udp6)
-- [`--nat`](./configuration.md#--nat)
-- [`--private`](./configuration.md#`--private`)
+- [`--discv5`](./beacon-cli.md#-discv5)
+- [`--listenAddress`](./beacon-cli.md#-listenaddress)
+- [`--port`](./beacon-cli.md#-port)
+- [`--discoveryPort`](./beacon-cli.md#-discoveryport)
+- [`--listenAddress6`](./beacon-cli.md#-listenaddress6)
+- [`--port6`](./beacon-cli.md#-port6)
+- [`--discoveryPort6`](./beacon-cli.md#-discoveryport6)
+- [`--bootnodes`](./beacon-cli.md#-bootnodes)
+- [`--deterministicLongLivedAttnets`](./beacon-cli.md#-deterministiclonglivedattnets)
+- [`--subscribeAllSubnets`](./beacon-cli.md#-subscribeallsubnets)
+- [`--disablePeerScoring`](./beacon-cli.md#-disablepeerscoring)
+- [`--enr.ip`](./beacon-cli.md#-enrip)
+- [`--enr.tcp`](./beacon-cli.md#-enrtcp)
+- [`--enr.udp`](./beacon-cli.md#-enrudp)
+- [`--enr.ip6`](./beacon-cli.md#-enrip6)
+- [`--enr.tcp6`](./beacon-cli.md#-enrtcp6)
+- [`--enr.udp6`](./beacon-cli.md#-enrudp6)
+- [`--nat`](./beacon-cli.md#-nat)
+- [`--private`](./beacon-cli.md#`-private`)
 
 ## Peer Discovery (Discv5)
 
-In Ethereum, discv5 plays a pivotal role in the peer discovery process, facilitating nodes to find and locate each other in order to form the peer-to-peer network​. The process begins with an interaction between new nodes and bootnodes at start-up. Bootnodes are nodes with hard-coded addresses, or can be overridden via the cli flag `--bootnodes`, to bootstrap the discovery process​. Through a method called FINDNODE-NODES, a new node establishes a bond with each bootnode, and it returns a list of peers for the new node to connect to. Following this trail, the new node engages through FINDNODE-NODES with the provided peers to further establish a web of connections​.
+In Ethereum, discv5 plays a pivotal role in the peer discovery process, facilitating nodes to find and locate each other in order to form the peer-to-peer network​. The process begins with an interaction between new nodes and bootnodes at start-up. Bootnodes are nodes with hard-coded addresses, or can be overridden via the cli flag [`--bootnodes`](./beacon-cli.md#-bootnodes), to bootstrap the discovery process​. Through a method called FINDNODE-NODES, a new node establishes a bond with each bootnode, and it returns a list of peers for the new node to connect to. Following this trail, the new node engages through FINDNODE-NODES with the provided peers to further establish a web of connections​.
 
 Discv5 operates as a peer advertisement medium in this network, where nodes can act as both providers and consumers of data. Every participating node in the Discv5 protocol discovers peer data from other nodes and later relays it, making the discovery process dynamic and efficient​.
 
-Discv5 is designed to be a standalone protocol running via UDP on a dedicated port solely for peer discovery. Peer data is exchanged via self-certified, flexible peer records (ENRs). These key features cater to the Ethereum network​ and being a good peer often means running a discv5 worker​. Lodestar offers simple configuration to setup and run a bootnode independently of a beacon node. See [bootnode](./bootnode.md) for more information and configuration options.
+Discv5 is designed to be a standalone protocol running via UDP on a dedicated port solely for peer discovery. Peer data is exchanged via self-certified, flexible peer records (ENRs). These key features cater to the Ethereum network​ and being a good peer often means running a discv5 worker​. Lodestar offers simple configuration to setup and run a bootnode independently of a beacon node. See the [bootnode cli](../bootnode/bootnode-cli.md) page for more information and configuration options.
 
 ## ENR
 

docs/pages/beacon-management/syncing.md

@@ -2,7 +2,7 @@
 
 Syncing an Ethereum node involves obtaining a copy of the blockchain data from other peers in the network to reach a consistent state. This process is crucial for new nodes or nodes that have been offline and need to catch up with the network's current state. Syncing can be performed for both the execution layer and the beacon chain, although the focus here will be primarily on the beacon chain.
 
-Lodestar allows for several methods of syncing however the recommended method is `checkpoint sync` as it is the fastest and least resource intensive. It is generally a good idea to sync via a [`--checkpointSyncUrl`](./configuration.md#--checkpointSyncUrl). If starting at a specific point is necessary specify the [`--checkpointState`](./configuration.md#--checkpointState) that should be where the sync begins.
+Lodestar allows for several methods of syncing however the recommended method is `checkpoint sync` as it is the fastest and least resource intensive. It is generally a good idea to sync via a [`--checkpointSyncUrl`](./beacon-cli.md#-checkpointsyncurl). If starting at a specific point is necessary specify the [`--checkpointState`](./beacon-cli.md#-checkpointstate) that should be where the sync begins.
 
 ## Weak Subjectivity
 
@@ -36,7 +36,7 @@ The implementation of the different syncing styles in Lodestar are actually one
 
 There are several flags that can be used to configure the sync process.
 
-- [`--checkpointSyncUrl`](./configuration.md#--checkpointSyncUrl)
-- [`--checkpointState`](./configuration.md#--checkpointState)
-- [`--wssCheckpoint`](./configuration.md#--wssCheckpoint)
-- [`--forceCheckpointSync`](./configuration.md#--forceCheckpointSync)
+- [`--checkpointSyncUrl`](./beacon-cli.md#-checkpointsyncurl)
+- [`--checkpointState`](./beacon-cli.md#-checkpointstate)
+- [`--wssCheckpoint`](./beacon-cli.md#-wsscheckpoint)
+- [`--forceCheckpointSync`](./beacon-cli.md#-forcecheckpointsync)

docs/pages/contribution/testing/end-to-end-tests.md

@@ -0,0 +1,3 @@
+# End-To-End Tests
+
+Check back soon for more information!! We are in the process of updating our docs.

docs/pages/contribution/testing/performance-tests.md

@@ -0,0 +1,3 @@
+# Performance Tests
+
+Check back soon for more information!! We are in the process of updating our docs.

docs/pages/contribution/testing/simulation-tests.md

@@ -1,4 +1,4 @@
-# Simulation Testing
+# Simulation Tests
 
 "Sim" testing for Lodestar is the most comprehensive, and complex, testing that is run. The goal is to fully simulate a testnet and to actuate the code in a way that closely mimics what will happen when turning on Lodestar in the wild. This is a very complex task and requires a lot of moving parts to work together. The following sections will describe the various components and how they work together.
 
@@ -54,7 +54,7 @@ GETH_DOCKER_IMAGE=ethereum/client-go:v1.11.6 \
 
 ## Sim Test Infrastructure
 
-When setting up and running the simulations, interactions with the nodes is through the published node API's. All functionality is actuated via http request and by "plugging in" this way it is possible to run the nodes in a stand-alone fashion, as they would be run in production, but to still achieve a tightly monitored and controlled environment. If code needs to be executed on a "class by class" basis or with mocking involved then the test is not a simulation test and would fall into one of the other testing categories. See the [Testing](../testing.md) page for more information on the other types of tests available for Lodestar.
+When setting up and running the simulations, interactions with the nodes is through the published node API's. All functionality is actuated via http request and by "plugging in" this way it is possible to run the nodes in a stand-alone fashion, as they would be run in production, but to still achieve a tightly monitored and controlled environment. If code needs to be executed on a "class by class" basis or with mocking involved then the test is not a simulation test and would fall into one of the other testing categories. See the [Testing Overview](./index.md) page for more information on the other types of tests available for Lodestar.
 
 ### Simulation Environment
 

docs/pages/contribution/testing/spec-tests.md

@@ -0,0 +1,3 @@
+# Specification Tests
+
+Check back soon for more information!! We are in the process of updating our docs.

docs/pages/contribution/testing/unit-tests.md

@@ -0,0 +1,3 @@
+# Unit Tests
+
+Check back soon for more information!! We are in the process of updating our docs.

docs/pages/data-retention.md

@@ -6,7 +6,7 @@ There are several processes that need to store data for Lodestar. These data set
 
 ```bash
 $executionDir # this changes depending on the execution client
-    └── execution-db 
+    └── execution-db
 
 $dataDir # specified by --dataDir on the beacon command
 ├── .log_rotate_audit.json
@@ -49,6 +49,6 @@ Configuring your node to store and prune data is key to success. On average you
 
 `keystores`, `keystore-cache` and `peerstore` are not usually very large and are not expected to grow much during normal operation.
 
-Logs can also become quite large so please check out the section on [log management](../logging-and-metrics/log-management.md) for more information.
+Logs can also become quite large so please check out the section on [log management](./logging-and-metrics/log-management.md) for more information.
 
-There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./configuration.md#--dataDir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document.
+There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-management/beacon-cli.md#-datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document.

docs/pages/getting-started/installation.md

@@ -90,4 +90,4 @@ See [Command Line Reference](./../reference/cli.md) for further information.
 <!-- prettier-ignore-start -->
 !!! danger
     For mainnet (production) usage, we only recommend installing with docker due to [NPM supply chain attacks](https://hackaday.com/2021/10/22/supply-chain-attack-npm-library-used-by-facebook-and-others-was-compromised/). Until a [safer installation method has been found](https://github.com/ChainSafe/lodestar/issues/3596), do not use this install method except for experimental purposes only.
-<!-- prettier-ignore-end -->
+<!-- prettier-ignore-end -->

docs/pages/getting-started/starting-a-node.md

@@ -14,7 +14,7 @@ Make sure Lodestar is installed in your local environment, following the chosen
 ./lodestar --help
 ```
 
-For a complete list of beacon node CLI commands and options, see the [Command Line Reference](../../reference/cli/)
+For a complete list of beacon node CLI commands and options, see the [`beacon` CLI Command](../beacon-management/beacon-cli.md) section.
 
 To select a known testnet or mainnet, use the `--network` flag. `mainnet` is selected by default, and a list of available networks is listed with the `--help` flag. Setting the `--network` flag will conveniently configure the beacon node or validator client for the selected network. For power users, any configuration option should be able to be overridden.
 
@@ -181,4 +181,4 @@ Apr-20 15:16:17.017[]                 info: Synced - slot: 6264979 - head: 0xde9
 
 6. Peer info: Current total number of outbound or inbound peers, for e.g.: `peers: 27`
 
-For more insight into how a Lodestar beacon node is functioning, you may setup lodestar metrics and use the prepared Grafana dashboards that are found in the repository. Check out our section on [Prometheus and Grafana](./prometheus-grafana.md) for more details.
+For more insight into how a Lodestar beacon node is functioning, you may setup lodestar metrics and use the prepared Grafana dashboards that are found in the repository. Check out our section on [Prometheus and Grafana](../logging-and-metrics/prometheus-grafana.md) for more details.

docs/pages/index.md

@@ -1,19 +1,19 @@
 ![lodestar logo](assets/lodestar_icon_text_black_stroke.png)
 
-## Welcome to the Lodestar documentation!
+## Welcome to the Lodestar documentation
 
 > **Lodestar is an open-source Ethereum Consensus client and Typescript ecosystem, maintained by ChainSafe Systems**
 
 ### Getting started
 
-- Follow the installation method for [source install](install/source.md), [NPM install](install/npm.md), or [Docker install](install/docker.md) to install Lodestar. Or use our [Lodestar Quickstart scripts](https://github.com/ChainSafe/lodestar-quickstart).
-- Use [Lodestar libraries](libraries) in your next Ethereum Typescript project.
-- Run a beacon node on [mainnet or a public testnet](usage/beacon-management.md).
-- Utilize the whole stack by [starting a local testnet](usage/local).
-- View the Lodestar [CLI commands and options](https://chainsafe.github.io/lodestar/reference/cli/)
-- Prospective contributors can read the [contributing section](https://chainsafe.github.io/lodestar/contributing/) to understand how we develop and test on Lodestar.
+- Follow the installation method for [source install](./getting-started/installation.md/#build-from-source) or [Docker install](./getting-started/installation.md/#docker-installation) to install Lodestar. Or use our [Lodestar Quickstart scripts](https://github.com/ChainSafe/lodestar-quickstart).
+- Use [Lodestar libraries](./supporting-libraries/index.md) in your next Ethereum Typescript project.
+- Run a beacon node on [mainnet or a public testnet](./getting-started/starting-a-node.md).
+- Utilize the whole stack by [starting a local testnet](./advanced-topics/setting-up-a-testnet.md).
+- View the Lodestar [CLI commands and options](./beacon-management/beacon-cli.md)
+- Prospective contributors can read the [contributing section](./contribution/getting-started.md) to understand how we develop and test on Lodestar.
 - If you have questions [submit an issue](https://github.com/ChainSafe/lodestar/issues/new) or join us on [Discord](https://discord.gg/yjyvFRP)!
-- Please note our [security policy](https://github.com/ChainSafe/lodestar/blob/unstable/SECURITY.md).
+- Please note our [security policy](./security.md).
 - Sign up to our [mailing list](https://chainsafe.typeform.com/lodestar) for announcements and any critical information about Lodestar.
 
 ## Specifications

docs/pages/introduction.md

@@ -10,11 +10,11 @@ In Ethereum's Proof of Stake (PoS) model, validators replace miners from the Pro
 
 In an effort to promote client diversity there are several beacon-nodes being developed. Each is programmed in a different language and by a different team. The following is a list of the current beacon-node clients:
 
-[Lodestar](https://chainsafe.io/lodestar.html)
-[Prysm](https://prysmaticlabs.com/)
-[Lighthouse](https://lighthouse.sigmaprime.io/)
-[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
-[Nimbus](https://nimbus.team/)
+- [Lodestar](https://chainsafe.io/lodestar.html)
+- [Prysm](https://prysmaticlabs.com/)
+- [Lighthouse](https://lighthouse.sigmaprime.io/)
+- [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
+- [Nimbus](https://nimbus.team/)
 
 ## Why Client Diversity?
 

docs/pages/logging-and-metrics/log-management.md

@@ -0,0 +1,3 @@
+# Log Management
+
+Check back soon for more information!!

docs/pages/reference/cli.md

@@ -0,0 +1,8 @@
+# Page relocated
+
+_**Welcome! This page has been moved. Please checkout our new docs layout from the Table of Contents! Below are some helpful links to the CLI pages that were split out from this original document**_
+
+- [Beacon Node CLI](../beacon-management/beacon-cli.md)
+- [Validator CLI](../validator-management/validator-cli.md)
+- [Bootnode CLI](../bootnode/bootnode-cli.md)
+- [Light Client CLI](../lightclient-prover/lightclient-cli.md)