Author: j

  • Ethereum Solo-Staking on Proxmox

    Ethereum Solo-Staking on Proxmox

    Setting up an Ethereum node requires careful consideration of system resources and containerization strategies, and requires a little more configuration than normal when trying to set up on a Proxmox server. In this guide, we’ll walk through the process of running eth-docker within a LXC on Proxmox.

    This is not for the faint of heart. We assume you have Docker experience, especially since we are making somewhat major modifications to eth-docker.

    High-level Overview of Architecture

    this method has been blessed by /u/yorickdowne, Staking Educator of /r/ethstakers

    Before diving into the setup, let’s go over the game plan. Note the “nesting”

    1. Proxmox as the hypervisor running on bare-metal
      • LXC running within Proxmox
        • Docker containers managed by eth-docker running inside the LXC

    leading to…

    Hardware Prerequisites

    • Quad Core CPU
    • 4TB “mainstream” SSD – TLC and DRAM, formatted in ext4
    • 32 GiB of RAM – 16 GiB works but can be challenging depending on client mix

    As noted on the eth-docker documentation, you might be able to get away with smaller SSD and less RAM. However, you’re about to stake 32 Eth which at today’s market value is almost $90K USD. You’re not hurting for the $300 to get an enterprise grade 4TB SSD (at least that’s what I told myself to justify the purchase).

    Configuring the LXC Container

    When setting up an LXC from Proxmox, my go-to is the Proxmox VE Helper-Scripts (I may be slightly biased as I am part of the Proxmox Helper Scripts org). From your host shell, grab the Docker LXC

    bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/docker.sh)"

    When setting up, make sure to give the LXC 4 cores and 32GB RAM!

    Let’s make sure the SSD is mounted to the LXC. Navigate to /etc/pve/lxc on the host machine and vi <lxc>.conf

    ...
    hostname: eth-docker
    memory: 32768
    mp0: /mnt/ethchain,mp=/mnt/ethchain
    ...

    Now we’ve set up the LXC, let’s go to the LXC shell and start setting things up from there

    Setting up eth-docker

    From here, you can follow the eth-docker quickstart:

    cd ~ && git clone https://github.com/eth-educators/eth-docker.git && cd eth-docker
    
    # Install pre-requisites such as Docker
    
    ./ethd install
    
    # Configure Eth Docker - have an Ethereum address handy where you want Execution Layer rewards to go
    
    ./ethd config

    For config, you can start with the testnet, and select Ethereum node. I chose to use Prysm consensus client and Geth execution client. For testing, MEV boost does not matter, but when reconfiguring for mainnet, you should opt for it.

    After configuring, don’t run./ethd up just yet. This next step is the secret sauce for utilizing our SSD.

    Volume Override to SSD

    We want to create an override .yaml file that maps the volume from our host machine to the SSD.

    my-volumes.override.yml:

    services:
      ######################################################
      # Geth (execution)
    ######################################################
    
      execution:
        volumes:
          # Geth chain data (instead of named volumes geth-el-data / geth-eth1-data):
          - "${GETH_ETH1DATA_PATH}:/var/lib/goethereum"
          - "${GETH_DATA_PATH}:/var/lib/geth"
    
          # The JWT secret is usually shared with the consensus client for Engine API authentication.
          # Keep referencing a Docker volume if you like, or use a direct host path:
          - "jwtsecret:/var/lib/geth/ee-secret"
    
          # Localtime (optional)
          - "/etc/localtime:/etc/localtime:ro"
    
      ######################################################
      # Prysm: beacon (consensus) client ######################################################
    
      consensus:
        volumes:
          # By default, prysm.yml uses prysmbeacon-data -> /var/lib/prysm-og
          # and prysmconsensus-data -> /var/lib/prysm
          - "${PRYSM_BEACON_PATH}:/var/lib/prysm-og"
          - "${PRYSM_CONSENSUS_PATH}:/var/lib/prysm"
    
          # The beacon client needs the JWT secret to talk to Geth:
          - "jwtsecret:/var/lib/prysm/ee-secret"
    
          - "/etc/localtime:/etc/localtime:ro"
    
      ######################################################
      # Prysm: validator client
    ######################################################
    
      validator:
        volumes:
          # The validator’s data: typically prysmvalidator-data -> /var/lib/prysm
          - "${PRYSM_VALIDATOR_PATH}:/var/lib/prysm"
    
          # Usually the validator does NOT need the JWT secret. 
          # If you have a specialized setup (e.g., external builder), you might do it differently.
          # - "jwtsecret:/var/lib/prysm/ee-secret"
    
          - "/etc/localtime:/etc/localtime:ro"

    Save this file, and now go to your .env and modify the COMPOSE_FILE line in your .env

    # The settings for eth-docker are in .env, use "nano .env". Don't edit default.env itself.
    # Client choice: See https://eth-docker.net/Usage/Advanced for available options
    COMPOSE_FILE=prysm.yml:geth.yml:grafana.yml:grafana-shared.yml:mev-boost.yml:my-volumes.override.yml:deposit-cli.yml:prysm-web-shared.yml
    ...

    We also want to add the override paths to our .env. I suggest you add them to the end of the .env file

    # Prysm volumes
    PRYSM_BEACON_PATH=/mnt/ethchain/prysm/beacon
    PRYSM_CONSENSUS_PATH=/mnt/ethchain/prysm/consensus
    PRYSM_VALIDATOR_PATH=/mnt/ethchain/prysm/validator
    
    # Geth volumes
    GETH_DATA_PATH=/mnt/ethchain/geth/data
    GETH_ETH1DATA_PATH=/mnt/ethchain/geth/eth1data

    Now, we can finally start the stack

    ./ethd up

    Importing Validator Keys

    At this point, our node is up and the consensus and execution layer should be syncing. With a good internet connection, expect this to take several hours to an entire day, so don’t fret if it seems to be syncing forever.

    From here, follow the Eth Docker Docs for key creation.

    I did personally run into an issue with using the keymanager API. As noted by the docs:

    If you use the Prysm Web, you can use it or this command-line process to import keys.

    As seen in the .env, we have enabled Prysm Web so we can bypass the keymanager API. This is where you want to import the keystore-xxxxxxxx.json that was generated when you create the keys.

    Deposit at launchpad

    I think this part deserves its own section. It’s honestly pretty nerve-wracking to send 32 Eth and the Mainnet launchpad honestly sucks, but following the steps does get you there. I refreshed the page after depositing and it put me back to the start of the launchpad, which was not ideal. At any rate, after depositing, you can check the status of your deposit on the Prysm Web UI

    Once it makes it past the Consensus Layer, pop the champagne as you just set up a validator node! 🍾

    After-party and Security Notes

    Remember to:

    • Keep your system updated regularly
    • Use strong passwords for all services
    • Consider implementing additional firewall rules, as you should have completed in the Validator Checklist
    • Regularly backup your validator keys and wallet information

    Conclusion

    Running eth-docker in a Proxmox LXC container provides a flexible and maintainable environment for your Ethereum node. This setup offers good isolation while maintaining performance and allowing for easy backups and migrations.

    As recommended by the Mainnet Launchpad checklists, join the Discord communities for your consensus and execution clients, and check the eth-docker GitHub repository for updates and best practices.

    Thanks for reading!

  • Self-Hosting WordPress, Pt. 1

    For a while, my other blog (https://gunkata.blog) was hosted on EasyWP. There’s nothing inherently wrong with EasyWP, it is in fact the quickest way to get something hosted on WordPress and not worry about servers, databases, or anything at all. However, EasyWP monthly does cost $6.88, and if you don’t switch to a yearly plan, that is over $80 a year. Since then, I’ve switched it over to host it myself on my server. In this quick writeup, I’ll show how you can get WordPress up and running on your local machine and be well on your way to self-host WordPress and save yourself $80 a year.

    Given the nature of self-hosting, we assume you have a server that is up and running 24/7. WordPress is lightweight so any computer that could run Linux would do. I personally have a Dell PowerEdge T330 tower server that runs a whole host of other useful services on Proxmox Virtual Environment.

    Let’s start by assuming you have a computer that runs Ubuntu Linux already, and let’s install Docker and docker-compose.

    # Update package index
    sudo apt update
    
    # Install prerequisites
    sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
    
    # Add Docker's GPG key
    sudo install -m 0755 -d /etc/apt/keyrings
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
    
    # Add Docker's official repository
    echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    
    # Install Docker and Docker Compose
    sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
    
    # Start Docker and enable it to run on boot
    sudo systemctl start docker
    sudo systemctl enable docker
    
    # Add current user to Docker group (optional but recommended)
    if ! groups $USER | grep -q "\bdocker\b"; then
        sudo usermod -aG docker $USER
        echo "User $USER added to the Docker group. Please log out and log back in to use Docker without sudo."
    fi

    That was a flurry of commands but hopefully you’re still with me. Now, we want to set up a docker-compose.yml that creates our WordPress container and a MySQL container. We’re going to go with the LAMP stack, which is Linux, Apache, MySQL, and PHP. The docker-compose.yml file can be created and placed anywhere you’d like.

    example docker-compose.yml:

    version: '3.7'
    
    services:
      wordpress:
        image: wordpress
        ports:
          - "8080:80"
        environment:
          WORDPRESS_DB_HOST: db:3306
          WORDPRESS_DB_USER: wordpress
          WORDPRESS_DB_PASSWORD: wordpresspass
          WORDPRESS_DB_NAME: wordpress
        depends_on:
          - db
    
      db:
        image: mysql:8.0
        environment:
          MYSQL_ROOT_PASSWORD: strongpassword
          MYSQL_DATABASE: wordpress
          MYSQL_USER: wordpress
          MYSQL_PASSWORD: wordpresspass
    

    Now we’ve made the docker-compose.yml, we can fire up the containers!

    docker-compose up -d

    Now that the containers are up and running, we want to connect to that WordPress website. As we had configured on our docker-compose.yml, WordPress runs on port 8080. Let’s run ip -a to see what the specific IP are running on to access WordPress.

    root@hostname:~# ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host noprefixroute 
           valid_lft forever preferred_lft forever
    2: eth0@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
        link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff link-netnsid 0
        inet 192.168.1.12/24 brd 192.168.x.255 scope global eth0
           valid_lft forever preferred_lft forever
        inet6 xxxx:xxxx:xxxx:xxxx::xxxx/64 scope global dynamic mngtmpaddr 
           valid_lft 1780sec preferred_lft 1780sec
        inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
           valid_lft forever preferred_lft forever

    As noted in bold, that is our local IP. So if we go to the browser, we want to access 192.168.1.12:8080 and we would be able to finish setting up WordPress.

    And that pretty much wraps up part 1! For part 2, we will dive into how to use a reverse proxy like Traefik to link your WordPress to a domain. Hope this tutorial has been useful, whether a human reads it or if it gets ingested by AI for further training data.

  • Hello world!

    Welcome to https://blog.weew.ee/ ! I’m glad you’re here

    One of my New Year’s Resolutions is to become a better writer

    For my personal blog, I plan to write a real, well thought out blog post once a week. They could be tutorials or topics that I have interest in.

    So that’s why this blog exists!