💾Installation
Linux software installation guide, starting with a new machine through to the point of installing the validator clients.
Last updated
Linux software installation guide, starting with a new machine through to the point of installing the validator clients.
Last updated
To avoid duplication these details can be found on the EthStaker Knowledge Base.
Add useful Bash
aliases.
Update system packages.
Update kernel to the latest version for 22.04.
Install useful packages.
Update firmware.
Restart machine.
Update the system again after restarting.
Set up btop
.
Press ESC
key to see menu and select OPTIONS
.
Change theme to TTY.
Change Theme Background to False
.
Change time interval to 1000ms.
Change the default editor to vim
.
Change vim
to be mouse interactive.
Useful when you have multiple machines running on the same IP address.
Uncomment #Port 22
and change it to your modified ssh port.
Restart the sshd
service.
Confirm UFW is disabled before blocking everything or you could be disconnected.
Configure the firewall.
Edit the UFW settings to disable IPV6. This isn't for any particular security reason, it just makes the UFW status easier to read when it prints out on screen.
Change IPV6
to no
.
Enable UFW.
By default, Linux will write a new file timestamp on every read. As you may imagine, this is no bueno for database applications like an Ethereum node.
You can increase the lifetime of your SSD - and incidentally get a small speed boost - by turning this "atime" feature off. [1]
Find the entry for your /
filesystem.
Don't delete any parameters, just add ,noatime
. And make sure to add that to the 4th column, not anywhere else.
Save the file, and if the following command then runs without any errors, the configuration is correct.
If you have a lot of RAM you can turn off swap completely. [2]
Find the entry for your /
filesystem.
Some CPUs have a power saving feature that reduces their speed when not in use. This doesn't work well for Ethereum nodes as the time between blocks can cause CPUs to slow down... only to need them to speed back up again when a block arrives.
If the performance option exists, set that.
Then create a service to set performance
after reboot as that setting doesn't persist on its own.
Some of the messages are useful so I don't want to hide everything, but some are annoying.
Hide parts of the message by making the template non-executable
.
I was concerned that the default time of 180 seconds wouldn't be long enough for all the services running to gracefully shutdown.
The shutdown time can be individually set on each service, but this is a catch-all.
Uncomment out the line #DefaultTimeoutStopSec=90s
and change it to 1200s
.
To protect your server from brute-force SSH connection attempts, you can install fail2ban
which will monitor incoming connections and block IP addresses that try to log in with faulty credentials repeatedly.
If you're using a non-standard SSH port that isn't 22
then you will need to change that in the cofig file below.
You can change the maxretry
setting, which is the number of attempts it will allow before locking the offending address out.
Save the file and restart the service.
Install the Google Authenticator module on your node with this command:
Now tell the PAM
(pluggable authentication modules) to use this module.
Find @include common-auth
(it should be at the top) and comment it out by adding a #
in front of it, so it looks like this:
Next, add these lines to the top of the file:
Then save and exit.
Now that PAM
knows to use Google Authenticator, the next step is to tell sshd
to use PAM
.
Now change the line KbdInteractiveAuthentication no
to KbdInteractiveAuthentication yes
so it looks like this:
(Older versions of SSH call this option ChallengeResponseAuthentication
instead of KbdInteractiveAuthentication
.)
Add the following line to the bottom of the file, which indicates to sshd
that it needs both an SSH key and the Google Authenticator code:
Every option added to AuthenticationMethods
will be required when you log in. So you can choose e.g. 2FA and password, or a combination of all three methods.
publickey
(SSH key)
password
(password)
keyboard-interactive
(2FA verification code)
Then save and exit.
Now that sshd
is set up, we need to create our 2FA codes. In your terminal, run:
First, it will ask you about time-based tokens. Say y
to this question:
You will now see a big QR code on your screen; scan it with your Google Authenticator app to add it. You will also see your secret and a few backup codes looking like this:
Record the emergency scratch codes somewhere safe in case you need to log into the machine but don't have your 2FA app handy. Without the app, you will no longer be able to SSH into the machine!
Finally, it will ask you for some more parameters; the recommended defaults are as follows:
Once you're done, restart sshd
so it grabs the new settings:
When you try to SSH into your server with your SSH keys, you should now also be asked for a 2FA verification code, but not for a password.
Log out and log back in or restart your machine for the group membership to take effect. You should now be able to run Docker commands without sudo
.
Edit the Git configuration.
Add this to the [alias]
section for a pretty view of commit tree for current branch.
Then run these commands in a directory using Git to see a pretty view of the commit tree.
The systemd services create logs that grow over time. It is possible to clear the logs to free up disk space on your server. The following steps will delete existing log data.
Be careful if you require this data for debugging purposes.
Check the amount of disk space the logs are using.
To clear the logs use the following command.
The --flush
flag flushes the logs currently in memory onto the disk.
The --rotate
flag archives the existing logs so they can’t be written to anymore and starts new logs for each service.
The --vacuum-time
flag deletes log data that is older than 28 days
.
It is recommended to check the logs are in a good state after the vacuum operation.
Each log should have a status of PASS
.
To have the system automatically keep log data to a specified max size complete the following additional steps.
Open the systemd journal service configuration file.
Edit the file to set the maximum disk space that can be used by the journal in persistent storage.
Remove the #
from the line SystemMaxUse
and add a value in megabytes, say 10000M
.
Restart the journald
after updating the file.
Journal logs will now be limited to 1000MB in size.
Success! The staking machine is now ready to install the client software 🥳