Homelab Dashboard

Introduction

We have decided to setup a Home Lab dashboard to monitor and administer the entire estate of Virtual Machines, Proxmox hosts and all of the services that we have created. initially we will use the dashy dashboard but may well change for something else if dashy proves to be to difficult or in some way unsuitable.

Dashy Setup

in the interests of security for this sensitive project we are extending your "Full-Chain TLS" SME standard to Blackberry. This ensures that even if a client bypasses the proxy (Raisin) and hits Blackberry directly on the network, the traffic is still encrypted and presents the valid *.seaoffate.net certificate. It will also mean that within the Pfsense side of the LAN any client will still meet the same secure SSL certificate system provided by Letsencrypt. 🛡️We will mount our existing SSL certificates (synced from Raisin) directly into the Dashy container and configure Dashy to serve HTTPS natively. Details of how the Certs are downloaded and installed can be found here.

Installation on Blackberry

🛠️ The "Dockge-Way" Setup, on our Dockge UI on Blackberry, create a new stack called dashy, and use this single, hardened configuration

services:
  dashy:
    image: lissy93/dashy:latest
    container_name: dashy
    restart: unless-stopped
    ports:
      - 443:443
    volumes:
      # Use the path that we proved works:
      - /mnt/archive_data/docker_data/stacks/dashy/conf.yml:/app/public/conf.yml
      # SSL Certificates (Synced from Raisin)
      - /etc/nginx/ssl/seaoffate.net/fullchain.pem:/etc/ssl/certs/fullchain.pem:ro
      - /etc/nginx/ssl/seaoffate.net/privkey.pem:/etc/ssl/private/privkey.pem:ro
    environment:
      - NODE_ENV=production
      - DOCKGE_ENABLE_CONSOLE=true
      - SSL_PUB_KEY_PATH=/etc/ssl/certs/fullchain.pem
      - SSL_PRIV_KEY_PATH=/etc/ssl/private/privkey.pem
      - NODE_OPTIONS=--max-old-space-size=2048
networks: {}

Post-Installation Steps

Certificate Synchronization Hook

Before the container will start correctly in SSL mode, we must have a basic conf.yml in the same directory as our compose.yaml. This file defines our users and our "Fruit Cluster" links. It is better to be sure that the docker app has the correct permissions for the yml, especially if it is in a non standard location.

touch sudo nano /mnt/archive_data/docker_data/stacks/dashy/conf.yml
sudo chown 1000:1000 /mnt/archive_data/docker_data/stacks/dashy/conf.yml
sudo chmod 644 /mnt/archive_data/docker_data/stacks/dashy/conf.yml

Note we are using a non standard directory for our stacks, the more common location for the conf.yml is /opt/dockge/stacks/dashy/conf.yml

To ensure Dashy stays updated when Raisin renews the Wildcard certs, make sure the deploy-wildcard.sh script on Raisin includes the Blackberry sync. It should have the Blackberry host in the servers list and the dashy restart in the if statements something like

 # Restart Dashy (Blackberry)
 if [ \$(docker ps -q -f name=dashy) ]; then
     echo '  Restarting Dashy...'
     docker restart dashy
 fi

Authentication Hardening

To fulfill the "Secure Application" requirement, we enable Dashy’s internal authentication. Even with a valid SSL cert, no data is visible without a login. Dashy requires a SHA-256 hash for the admin password. Run this on any terminal:

echo -n "YourSecretPassword" | sha256sum

Note the quotes are only needed if there is spaces or similar in the password and the quotation marks are not part of the password Take the resulting string and place it in the auth section of your conf.yml on Blackberry

nano /mnt/archive_data/docker_data/stacks/dashy/conf.yml

A sample conf is as follows ( including the password YourSecretPassword it is assumed that the user will change the hash to some other password):

appConfig:
   title: SeaOfFate Command
   statusCheck: true
   auth:
     enable: true
     enableGuestAccess: false
     users:
       - user: nigel
         hash: '790e294c25e704e042c899bb4dbb696b9daa2ed330d270082599f8591dc62b96'
         type: admin
 sections:
   - name: Infrastructure
     items:
       - title: Vaultwarden
         url: https://vault.seaoffate.net/alive
         icon: hl-bitwarden

💡 Why /alive

if you just ping the main URL, Dashy might get a 401 Unauthorized or a redirect, which can sometimes show up as a "Yellow" or "Red" dot even if the service is fine. The /alive path is specifically designed for health checks like this and always returns a simple 200 OK

Verification

Once started, you can verify the "Full-Chain TLS" by visiting:

• Internal(inside Pfsence): https://192.168.100.85 (Should show the valid seaoffate.net certificate from letsencrypt ).
• Internal(inside Pfsence): https://blackberry (Assuming the internal nameserver ctns1 has the DNS entry for blackberry set should show the valid seaoffate.net certificate from letsencrypt).
• Internal(inside Pfsence): https://dashy.seaoffate.net (Assuming the internal nameserver ctns1 has the DNS entry for dashy set should show the valid seaoffate.net certificate from letsencrypt).
• Internal:(outside Pfsence) https://dashy.seaoffate.net (Assuming the DNS rewrite foe seaoffate.net on adguard set and Raisin reverse proxy rule is set, should show the valid seaoffate.net certificate from letsencrypt).
• External(though mobile phone Internet): https://dashy.seaoffate.net (Assuming the DNS for dashy is set on Cloudflare's control panel and dashy is proxied through Raisin it should show the Cloudflare SSL certificate).

When we have proved that the the dashboard works and that the login screen is displayed first we can move on to adding items to the dashboard.