Lab

I recently learnt that you can control the UniFi APs LEDs via SSH, which allows you to script their control. This means that I can change what colour they are using, and schedule them to turn on and off automatically - see here for that. However, I though it might be worth making a small post regarding exactly what I found. DISCLAIMER: Proceed at your own risk. These have been tested on a U7 Pro, and are unlikely to have any catastrophic problems on other APs, but be careful regardless. ...

Modularity always helps when it comes to the maintenance of complex systems, and so it should help when it comes to managing Home Assistant. A while back, I stumbled across Frenck’s GitHub profile, where he was showcasing his Home Assistant config - https://github.com/frenck/home-assistant-config. I found the idea of splitting each entry into it’s own dedicated file, rather then having one huge config file, much more intuitive and easier to manage. Setup Navigate to your data folder 03:43:35 vivaan@ultimate ~ → cd /clstr/homeassistant/data Create a new integrations folder This will be where all the entries for Home Assistant’s config will be stored. ...

The UniFi U7 Pros have these neat LED rings on them, but they can be pretty distracting during the night - so I thought it would be cool to be able to control them via Home Assistant, and automate them. And honestly, another set of lights to have control over - especially considering they seem to make pretty good night lights. Setting up the APs In order to control the AP LEDs, you will need to enable SSH. You can do this via the UniFi Controller. ...

In order to fully utilise the UniFi APs full feature set, you’ll need to have a UniFi controller of some sort. This can be a UniFi Cloud Key, a UniFi Cloud Gateway, or… you can host one yourself. So obviously, I chose the third option. There are two methods for installing the controller. One is on Docker, or you can use a Bare-Metal install. I’ll go through both, but I personally use the Docker setup. ...

Passwords are one of the most important aspects of our digital lives nowadays, making the password manager of your choice one of the most important tools you use. I was using Bitwarden, until I decided that I’m gonna take a little risk and self-host my password manager. Enter: Vaultwarden - an unofficial rewrite of the Bitwarden server. Brief Introductions For the uninitiated, Bitwarden is an incredibly powerful password manager, with many feature, and a pretty intuitive UI. However, a few of it’s major painpoints revolved around a few of it’s features being locked behind a paywall. It’s not that I needed those features, they were just a nice to have - take organisations for an example. I like to follow a similar idea to Zero-Trust Architectures, in which all devices only are able to access the resources they need. One way I could achieve this with Bitwarden is having all my Personal devices use one account, and all my School devices use another. ...

I’m planning to possibly add a Raspberry Pi 2 (Old, I know, but it does the job) to my lab, for providing some key network services. It will be dedicated to this, reducing the risk of another service breaking and bringing down both the lab, and the network. I thought it might be worth scripting the setup process, as it’s a pretty repetitive process. What does each node need? It must be a part of the tailnet It must have docker installed on it It must have access to the /ultmt folder, whether its via a CIFS mount, or using glusterfs-client It must use the LLDAP server for centralised authentication It must have the main 5 nodes in its hosts file, in case DNS fails It must have certain tools/packages installed I want it to be very general, in the sense that I can use it for things other then just the nodes of the server, say if I want one specific computer to authenticate against my LLDAP server. ...

Let me just start by saying that I do not need any of this, it is more-or-less just because I can, and want to. Internet We have a gigabit fibre connection running into our house. I’d love to have multiple WAN for failover, but frankly, it’s not worth it, as we have high enough uptime with our current ISP alone. Internal network From there, it heads into our ISP modem, then ISP router, and then straight into our main 8-port switch. This, then connects to out PoE switch, which powers our two Unifi U7 Pro access points (that’s what the Unifi Controller is for). There are also 3 cables that then come out of the 8-port switch. Two for the Raspberry Pis, and one for my laptop. This allows all the server nodes to have the fastest possible internet connection they can have. ...

Why? One of the central aspects of my setup is the LLDAP server. This allows all services to authenticate using the same credentials, meaning users just need to remember one set of logins. One thing I wanted to do was to ensure the servers also authenticated against the same server. Let’s get started I initially started off by following the guide on the LLDAP repository to setup NSLCD in combination with LLDAP, however I soon found the NSLCD was no longer actively supported. This meant that it was quite lacking in the feature space, and often had weird compatibility issues. ...

Nodes Let’s take a look into what the ‘(home)lab’ (that’s quite a generous word) consists of… 1 Raspberry Pi 5 1 Raspberry Pi 3 2 Oracle cloud free-tier VMs My other laptop, which adds some power to the ‘cluster’ when I’m not using it So in the grand scheme of things, it’s not that powerful. But that also adds to the challenge, as things might need some tweaking to get working. Of course, this comes with the caveat of wanting to drop-kick my laptop out of the windows when things don’t work, but it’s all part of the fun…, right? ...