rename validator

ci/localnet-sanity.sh

@@ -202,8 +202,8 @@ killNodes() {
   # Try to use the RPC exit API to cleanly exit the first two nodes
   # (dynamic nodes, -x, are just killed)
   echo "--- RPC exit"
-  $solana_validator --ledger "$SOLANA_CONFIG_DIR"/bootstrap-validator exit --force || true
-  $solana_validator --ledger "$SOLANA_CONFIG_DIR"/validator exit --force || true
+  $agave_validator --ledger "$SOLANA_CONFIG_DIR"/bootstrap-validator exit --force || true
+  $agave_validator --ledger "$SOLANA_CONFIG_DIR"/validator exit --force || true
 
   # Give the nodes a splash of time to cleanly exit before killing them
   sleep 2

ci/run-sanity.sh

@@ -31,7 +31,7 @@ while [[ $latest_slot -le $((snapshot_slot + 1)) ]]; do
   latest_slot=$($solana_cli --url http://localhost:8899 slot --commitment processed)
 done
 
-$solana_validator --ledger config/ledger exit --force || true
+$agave_validator --ledger config/ledger exit --force || true
 
 wait $pid
 

docs/src/clusters/benchmark.md

@@ -108,7 +108,7 @@ For example
 
 Generally we are using `debug` for infrequent debug messages, `trace` for potentially frequent messages and `info` for performance-related logging.
 
-You can also attach to a running process with GDB. The leader's process is named _solana-validator_:
+You can also attach to a running process with GDB. The leader's process is named _agave-validator_:
 
 ```bash
 sudo gdb

docs/src/implemented-proposals/installer.md

@@ -60,7 +60,7 @@ $ solana-install deploy http://example.com/path/to/solana-release.tar.bz2 update
 $ solana-install init --pubkey 92DMonmBYXwEMHJ99c9ceRSpAmk9v6i3RdvDdXaVcrfj  # <-- pubkey is obtained from whoever is deploying the updates
 $ export PATH=~/.local/share/solana-install/bin:$PATH
 $ solana-keygen ...  # <-- runs the latest solana-keygen
-$ solana-install run solana-validator ...  # <-- runs a validator, restarting it as necessary when an update is applied
+$ solana-install run agave-validator ...  # <-- runs a validator, restarting it as necessary when an update is applied
 ```
 
 ## On-chain Update Manifest

docs/src/operations/best-practices/general.md

@@ -23,12 +23,12 @@ watch past workshops through the
 
 ## Help with the validator command line
 
-From within the Solana CLI, you can execute the `solana-validator` command with
+From within the Solana CLI, you can execute the `agave-validator` command with
 the `--help` flag to get a better understanding of the flags and sub commands
 available.
 
 ```
-solana-validator --help
+agave-validator --help
 ```
 
 ## Restarting your validator
@@ -49,14 +49,14 @@ solana leader-schedule
 Based on the current slot and the leader schedule, you can calculate open time
 windows where your validator is not expected to produce blocks.
 
-Assuming you are ready to restart, you may use the `solana-validator exit`
+Assuming you are ready to restart, you may use the `agave-validator exit`
 command. The command exits your validator process when an appropriate idle time
 window is reached. Assuming that you have systemd implemented for your validator
 process, the validator should restart automatically after the exit. See the
 below help command for details:
 
 ```
-solana-validator exit --help
+agave-validator exit --help
 ```
 
 ## Upgrading
@@ -75,7 +75,7 @@ process.
 It is a best practice to always build your Solana binaries from source. If you
 build from source, you are certain that the code you are building has not been
 tampered with before the binary was created. You may also be able to optimize
-your `solana-validator` binary to your specific hardware.
+your `agave-validator` binary to your specific hardware.
 
 If you build from source on the validator machine (or a machine with the same
 CPU), you can target your specific architecture using the `-march` flag. Refer
@@ -106,7 +106,7 @@ options.
 ### Restart
 
 For all install methods, the validator process will need to be restarted before
-the newly installed version is in use. Use `solana-validator exit` to restart
+the newly installed version is in use. Use `agave-validator exit` to restart
 your validator process.
 
 ### Verifying version
@@ -132,13 +132,13 @@ have state locally. In other cases such as restarts for upgrades, a snapshot
 download should be avoided.
 
 To avoid downloading a snapshot on restart, add the following flag to the
-`solana-validator` command:
+`agave-validator` command:
 
 ```
 --no-snapshot-fetch
 ```
 
-If you use this flag with the `solana-validator` command, make sure that you run
+If you use this flag with the `agave-validator` command, make sure that you run
 `solana catchup <pubkey>` after your validator starts to make sure that the
 validator is catching up in a reasonable time. After some time (potentially a
 few hours), if it appears that your validator continues to fall behind, then you
@@ -199,7 +199,7 @@ It is important that you do not accidentally run out of funds in your identity
 account, as your node will stop voting. It is also important to note that this
 account keypair is the most vulnerable of the three keypairs in a vote account
 because the keypair for the identity account is stored on your validator when
-running the `solana-validator` software. How much SOL you should store there is
+running the `agave-validator` software. How much SOL you should store there is
 up to you. As a best practice, make sure to check the account regularly and
 refill or deduct from it as needed. To check the account balance do:
 

docs/src/operations/best-practices/monitoring.md

@@ -27,11 +27,11 @@ The command will monitor your validator, but you will not get notifications unle
 
 It is a best practice to run the `agave-watchtower` command on a separate server from your validator.
 
-In the case that you run `agave-watchtower` on the same computer as your `solana-validator` process, then during catastrophic events like a power outage, you will not be aware of the issue, because your `agave-watchtower` process will stop at the same time as your `solana-validator` process.
+In the case that you run `agave-watchtower` on the same computer as your `agave-validator` process, then during catastrophic events like a power outage, you will not be aware of the issue, because your `agave-watchtower` process will stop at the same time as your `agave-validator` process.
 
 Additionally, while running the `agave-watchtower` process manually with environment variables set in the terminal is a good way to test out the command, it is not operationally sound because the process will not be restarted when the terminal closes or during a system restart.
 
-Instead, you could run your `agave-watchtower` command as a system process similar to `solana-validator`. In the system process file, you can specify the environment variables for your bot.
+Instead, you could run your `agave-watchtower` command as a system process similar to `agave-validator`. In the system process file, you can specify the environment variables for your bot.
 
 ### Setup Telegram Notifications
 

docs/src/operations/guides/restart-cluster.md

@@ -68,7 +68,7 @@ Post something like the following to #announcements (adjusting the text as appro
 > 2. a. Preferred method, start from your local ledger with:
 >
 > ```bash
-> solana-validator
+> agave-validator
 >   --wait-for-supermajority SLOT_X     # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART
 >   --expected-bank-hash NEW_BANK_HASH  # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART
 >   --hard-fork SLOT_X                  # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART
@@ -84,7 +84,7 @@ Post something like the following to #announcements (adjusting the text as appro
 > b. If your validator doesn't have ledger up to slot SLOT_X or if you have deleted your ledger, have it instead download a snapshot with:
 >
 > ```bash
-> solana-validator
+> agave-validator
 >   --wait-for-supermajority SLOT_X     # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART
 >   --expected-bank-hash NEW_BANK_HASH  # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART
 >   --entrypoint entrypoint.testnet.solana.com:8001

docs/src/operations/guides/validator-failover.md

@@ -85,11 +85,11 @@ For more information on etcd TLS setup, please refer to
 https://etcd.io/docs/v3.5/op-guide/security/#example-2-client-to-server-authentication-with-https-client-certificates
 
 ### Primary Validator
-The following additional `solana-validator` parameters are required to enable
+The following additional `agave-validator` parameters are required to enable
 tower storage into etcd:
 
 ```
-solana-validator ... \
+agave-validator ... \
   --tower-storage etcd \
   --etcd-cacert-file certs/etcd-ca.pem \
   --etcd-cert-file certs/validator.pem \
@@ -103,7 +103,7 @@ that your etcd endpoint remain accessible at all times.
 
 ### Secondary Validator
 Configure the secondary validator like the primary with the exception of the
-following `solana-validator` command-line argument changes:
+following `agave-validator` command-line argument changes:
 * Generate and use a secondary validator identity: `--identity secondary-validator-keypair.json`
 * Add `--no-check-vote-account`
 * Add `--authorized-voter validator-keypair.json` (where
@@ -114,8 +114,8 @@ When both validators are running normally and caught up to the cluster, a
 failover from primary to secondary can be triggered by running the following
 command on the secondary validator:
 ```bash
-$ solana-validator wait-for-restart-window --identity validator-keypair.json \
-  && solana-validator set-identity validator-keypair.json
+$ agave-validator wait-for-restart-window --identity validator-keypair.json \
+  && agave-validator set-identity validator-keypair.json
 ```
 
 The secondary validator will acquire a lock on the tower in etcd to ensure
@@ -131,7 +131,7 @@ exit. However if/when the secondary validator restarts, it will do so using the
 secondary validator identity and thus the restart cycle is broken.
 
 ## Triggering a failover via monitoring
-Monitoring of your choosing can invoke the `solana-validator set-identity
+Monitoring of your choosing can invoke the `agave-validator set-identity
 validator-keypair.json` command mentioned in the previous section.
 
 It is not necessary to guarantee the primary validator has halted before failing