yorickdowne

Medalla non-finality mid October

What is happening with the Medalla eth2 testnet currently, Oct 17th 2020? Here's an ELI5. (Not exactly 5. Maybe 10. You get the idea.)

1. A bunch of validators turned off (maybe zinken, maybe bored, who knows)
2. We entered non-finality. This means we don't have enough validators online to agree to what the state of the network is. We need 2/3rds.
3. Some sync bugs reared their heads, in Prysm and Nimbus. We lost more validators to the bugs, not everyone has updated since
4. Non-finality increases memory and CPU requirements, we likely lost more validators because their nodes couldn't handle it
5. Either people come back in and we regain finality or
6. They don't and offline validators lose eth faster and faster, until we regain finality. Some may be ejected if their balance falls too low.

yorickdowne

Emergency procedure

Only do this in emergencies, such as when eth2 is not syncing or RAM/CPU use is spiking. This procedure can be used for Prysm or Lighthouse.

The specific client versions mentioned here are for RocketPool 0.0.8. They will not work in prior versions of RP.

Edit config.yml:

cd ~/.rocketpool

yorickdowne

Keybase proof

I hereby claim:

• I am yorickdowne on github.
• I am yorickdowne (https://keybase.io/yorickdowne) on keybase.
• I have a public key ASAMH3gm5u914DMwcR4DXVgPeCKqlPdP9Tdurg-LiKUzVQo

To claim this, I am signing this object:

yorickdowne

Use ufw for some, but not all, Docker traffic

This is a slight tweak to https://github.com/chaifeng/ufw-docker by way of https://p1ngouin.com/posts/how-to-manage-iptables-rules-with-ufw-and-docker

For an automated way of handling ufw rules via docker-compose, see https://github.com/shinebayar-g/ufw-docker-automated

Use case

I wanted Docker to keep managing its own iptables rules, including automatically opening port forwards, with the option of stepping in and restricting a port that I did not want open to "world". Container-to-container traffic should flow unimpeded,

yorickdowne

/u/settleddown posted some excellent instructions on how to create your own BloxStaking KeyVault instance in AWS and keep it updated yourself.

I've adjusted these instructions to "take over" the existing instance, without needing to spin up an entirely new one. The Python script now prompts the user for the password.

NB: pip3 is very slow on WSL2. This can be resolved by running pip3 install -U keyring, and then mkdir -p ~/.config/python_keyring/ and edit vi ~/.config/python_keyring/keyringrc.cfg and paste into it:

[backend]
default-keyring=keyring.backends.null.Keyring

yorickdowne

#! /bin/bash
 
# http://linuxcommand.org/wss0150.php
function error_exit
{
	echo "$1" 1>&2
	exit 1
} 

# http://unix.stackexchange.com/questions/70859/why-doesnt-sudo-su-in-a-shell-script-run-the-rest-of-the-script-as-root 

yorickdowne

These instructions have moved.

yorickdowne

Overview

Running on netcup is not much different from running on any other Linux host. The main difference is that the host is directly exposed to the Internet, and that it is provisioned with Debian, not Ubuntu, to begin with.

Install Ubuntu

In netcup's customer control panel, Overview, click on "SCP Auto-Login". This gets you into their Server Control Panel.

In netcup's server control panel, choose Media on the left, and the Images tab. Select the Ubuntu 20.04 image and install it, partitioning the whole disk. The "SCP password" being asked for here is the password for the Server Control Panel, which you received in a welcome email when first signing up with netcup.

yorickdowne

Overview

Geth 1.10.23 fixes a bug in 1.10.22, which would have resulted in missing state in its database. The Go-Ethereum team recommends to roll the chain back and let Geth catch up again, if and only if you had updated to 1.10.22. If you did not, just update to 1.10.23 now and call it done.

This is how to roll back to a previous block when using eth-docker.

Update Geth to 1.10.23

./ethd update and ./ethd up should do it.

yorickdowne

Overview

Geth, and other execution clients such as Erigon, Nethermind, and Besu, take some time on shutdown to cleanly close their database. When not given that time, they will need to resync upon restart, often for hours. This gist describes the systemd service file parameter to give them up to 5 minutes of time for a clean shutdown.

Steps

• Find your service file. It may be called /etc/systemd/system/geth.service or /etc/systemd/system/eth1.service.
• Edit it using sudo nano FILENAME, and add TimeoutStopSec=300 to the [Service] section. Here is an example of a service file after the change: