Updating
From time to time validators need to be updated to support new features in the software and chain, or new configuration to support various changes. The setup documentation and config files will always be updated to incorporate these updates, so this document is mainly targeted for users who have pre-existing installations.
Updates
Versions
Release Date | Version | Archive Name | Notes |
---|---|---|---|
2022-12-12 | 912717-v5.0.0 | elvmasterd-18ee34-v5.0.0.tgz |
Updates Ethereum base to 1.10.19 (including EIP155) |
2022-08-12 | 4c79e3-main | elvmasterd-4c79e3-main.tgz |
Adds Genesis Update Commands |
Forks
From time to time the chain needs to be updated to support new capabilities and features. When this happens, the chain is forked by specifying a block where the agreed upon changes will happen. This table will document which features are activated, at which block ,and if certain minimum software is needed to support this.
Block | Genesis File | Minimum Software Release | Notes |
---|---|---|---|
22680000 | genesis.json |
912717-v5.0.0 | Enables muirGlacier, berlin, london, arrowGlacier, grayGlacier features |
17793000 | Archived genesis.json |
4c79e3-main | Enables constantinople, petersburg, and istanbul features |
Config
When the example configurations found on the Configuration page are updated to reflect new features or changes to best practices, it may be hard to know what was changed. Here is a summary of changes by date. Please reference the files for the specific changes. Table will note the example file name.
Release Date | Example File Changed | Parameters | Nature of Change |
---|---|---|---|
2022-12-12 | N/A | N/A | No config changes needed to support 912717-v5.0.0 |
2022-08-12 | system-scope-elvmasterd.service |
Type |
Add/Change to allow proper TERM signals to elvmasterd |
2022-08-12 | system-scope-elvmasterd.service |
KillMode |
Add/Change to allow proper TERM signals to elvmasterd |
2022-08-12 | system-scope-elvmasterd.service |
ExecStart |
Added --allow-insecure-unlock so miner can function |
2022-08-12 | validator.toml |
enc_block |
Updated to reflect new Genesis |
2022-08-12 | validator.toml |
discovery_urls |
Introduced discovery_urls and removed staticnodes since discovery_urls preferred |
How To…
Local Database Backup
From time to time the local state database used by elvmasterd
changes in such a way that it is not possible to rollback. The following proceedure is only needed on upgrade and the resulting backup can be removed once it has been determined the upgrade was successful. If this step is skipped, a full re-sync of the database is needed, which can take 24hrs or more with the current chain size.
This example presumes the datadir
where the database files are located in the same location defined in the example config.toml
. Ensure the correct directory (defined in node.datadir
of the config.toml
is used)
sudo systemctl stop elvmasterd
cp -r /var/elvmasterd-data/elvmasterd /var/elvmasterd-data/elvmasterd.$(date +%Y-%m-%d)
sudo systemctl start elvmasterd
Update elvmasterd
The attached script, update_elvmasterd.sh
is an example updater. It works with a system-level install of elvmasterd
installed at /usr/local
.
ELUVIO_PKG_GCS_URL=https://storage.googleapis.com/eluvio-public-builds
ELV_TGZ=elvmasterd-18ee34-v5.0.0.tgz
hash curl || {
echo "Please install curl to use this script"
exit 1
}
if [ $# -ne 1 ]; then
echo "need a binary to deploy"
exit 1
fi
if [[ $1 =~ \.tgz$ ]]; then
ELV_TGZ=${1}
else
echo "file does not look right"
exit 1
fi
curl --output /dev/null --silent --head --fail "${ELUVIO_PKG_GCS_URL}/${ELV_TGZ}" || {
echo "${ELVTAR} does not exist"
exit 1
}
(
sudo systemctl stop elvmasterd
curl -s ${ELUVIO_PKG_GCS_URL}/${ELV_TGZ} | sudo tar -C /usr/local -zxvf -
sudo systemctl start elvmasterd
)
To use it, Run the script with the latest elvmasterd
tar as the only argument. The latest is listed above in the versions section, so the script would run like so:
./update_elvmasterd.sh elvmasterd-18ee34-v5.0.0.tgz
Update Genesis
The latest fork at block TBD
is to enable features up tp Grey Glacier. New chains which are setup with the example config in this document will not need to do anything to pick up these changes. If the validator was setup prior to these updates and prior to this block, a new Genesis will need to be applied. The following steps will need to be followed:
- Update to the latest
elvmasterd
following the instructions in this document, or by pulling a new version of the container. - Run the
genesis-update
command with thegenesis.json
in the Configuration
Running genesis-update
is straightforward. The daemon will need to be stopped to access the database, which is protected by a mutex to ensure only one process can access it.
Assumes install location is /usr/local
and genesis.json
is located in /tmp
.
sudo systemctl stop elvmasterd
/usr/local/bin/elvmasterd genesis-update /tmp/genesis.json --config /etc/elvmasterd/config.toml
sudo systemctl start elvmasterd
Stop the container, then run the following. Place the genesis.json
in the /fast-disk/conf
equivalent.
podman run \
--hostname org-validator-01 --rm=true -ti \
-v /fast-disk/conf:/conf \
-v /fast-disk/data:/data \
-p 40304:40304 \
-p 40304:40304/udp \
elvmasterd-validator:latest genesis-update /conf/genesis.json --config /conf/config.toml
Then restart the container
Checking Update
There are 2 simple checks to ensure the genesis was updated correctly and that config or software changes have been applied correctly (outside of ensuring the daemon is simply running)
Checking currently synced block number
On a chain that has been sitting inactive for some time (common on restart or when not updated on a fork), the simplest test to see if syncing activity is occurring is to see what the current block number is. If it is behind, it should grow a lot in a short period of time as the local chain syncs with the peers. If it is synced up, the current block will still advance regularly as new transactions are written.
/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "eth.blockNumber"
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "eth.blockNumber"
Then restart the container
Checking number of peers
When a local node is misconfigured or has problems with the genesis (such as not having the same genesis due to a fork), nodes will be unable to connect to peers due to the mismatch. The simplest check to perform is to see how many peers the local node has. The following command will print the current count. A good value is over 3.
/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "admin.peers.length"
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "admin.peers.length"
Then restart the container
Start Miner
On restart the wallet will be locked and the miner process will be off. The following can be run to unlock the wallet and start the miner:
Assumes install location is /usr/local
/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "personal.unlockAccount(eth.coinbase, 'the password goes here', 0)"
/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "miner.start(8)"
Assumes container instance is named org-validator-01
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "personal.unlockAccount(eth.coinbase, 'the password goes here', 0)"
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
--exec "miner.start(8)"