WireGUI - a Wireguard hub and spoke server

WireGUI - a Wireguard hub and spoke server

I've been working on and using WireGUI for both my personal home lab and at work for my ~50 users, it's been in production for a few months now and it's gained a bit of traction on Github.

I know there is many options out there but none of the available ones fit my needs, so I decided to put together my own solution.

Would love to get some feedback and opinions about it, especially if you're looking for a simple solution with SSO/OIDC. I am planning to get SCIM implemented in it as well but not sure if there is interest in it.

Here is a link to the project on Github: https://github.com/bartei/wiregui

Hopefully my post is not gonna be taken down 😄

u/bartei81 — 1 day ago

Raspberry Pi Hat for power and RS485 Communication

I've been working on this board for a while now and this is the current status of it:

  • Wide DC Input 6-36V stepped down to 5V adjustable for the PI
  • Input protection with PPTC resettable fuse
  • Reverse polarity protection
  • TVS protection for surges
  • Half duplex RS485 with an SP3485 up to 10Mbps and automatic TX/RX detection

This is all designed with EasyEDA pro, the project is here:

https://github.com/bartei/drdro-powercom

I use this board regularly on my builds for drDRO:

https://drdro.provvedo.com/

u/bartei81 — 2 months ago
▲ 12 r/homelab

I have been running my own homelab for many years now (IIRC I started around 2002-2003). A lot has changed since I started — the biggest shift for me was moving from scripted/manual configuration to IaC. Managing hybrid infra at work (data center + AWS) made the homelab feel painfully manual by comparison, so eventually I bit the bullet.

I primarily use Proxmox and have a 3-node cluster. Everything apart from the Proxmox hypervisor itself is defined with Terraform and Terragrunt — both LXC and VM instances. Provisioning is done with the excellent bpg provider for Proxmox.

The interesting bit (for me at least) is configuration. What runs on each VM/LXC is handled with NixOS, and I built my own Terraform provider to apply the configurations directly from Terraform. For edge cases where NixOS doesn't fit, I use cloud images configured with Salt — and I built another provider to run Salt directly from Terraform too. I went this route instead of leaning on existing tooling because I wanted everything to flow through a single terraform apply, with state tracked in one place.

End result: everything is declarative, single source of truth, Terragrunt+Terraform is the only place you ever touch.

My forever question is bootstrapping. Proxmox installation in my world is still done manually and I don't see an easy way to automate that. If I ever wanted to scale to an indefinite number of cluster nodes, that's where I'd hit a wall.

A large part of the networking stack is also still manual — VLANs, switch configuration, LACP. Probably simpler to solve from IaC since providers exist, but for now I'm happy with manual backups of the configs, even though it breaks my single source of truth paradigm.

Curious how others handle the bootstrapping problem specifically — do you PXE boot your hypervisors? Use something like MAAS or FOG? Or just accept the manual install? And more broadly, how do you folks use IaC in your homelab — if at all?

reddit.com
u/bartei81 — 3 months ago
▲ 1 r/DevOpsLinks+1 crossposts

After one too many rounds of bolting local-exec + Ansible onto Terraform and losing all visibility into what changed, I built a provider that does post-provision config as a proper Terraform resource: terraform-provider-salt.

What it does:

  • SSHes into a target host, installs Salt if missing, uploads your .sls files, and runs salt-call --local state.apply
  • Strictly masterless — no Salt master, no minion daemon. After bootstrap the minion service is killed, disabled, and masked so nothing tries to phone home.
  • Real drift detectionterraform plan runs salt-call test=True so drift shows up in the plan, not after the fact (something local-exec can never do)
  • Pass Terraform variables straight through as pillar data
  • triggers block to force re-apply when state files change

Quick example pairing it with Proxmox:

resource "salt_state" "k3s" {
  host        = proxmox_vm_qemu.node.default_ipv4_address
  user        = "root"
  private_key = file("~/.ssh/id_ed25519")

  states = {
    "k3s/init.sls" = file("${path.module}/salt/k3s/init.sls")
    "top.sls"      = file("${path.module}/salt/top.sls")
  }

  pillar = {
    cluster_token = random_password.k3s_token.result
    node_ip       = proxmox_vm_qemu.node.default_ipv4_address
  }
}

I've been using it for a while now across a few Linux distros and VM platforms. MIT licensed.

Repo: https://github.com/bartei/terraform-provider-salt

Feedback, issues, and PRs all welcome!

u/bartei81 — 1 day ago