8.5 KiB
:PROPERTIES:
:END:
Homelab homelab
HTTPS @ Home
:PROPERTIES:
:END:
I run a lot of services at home.
This includes, but isn't limited to
- ArchiveBox
- VaultWarden
- Navidrome
- Plex
- LibrePhotos
- This blog
and a lot more.
Pretty much anything that's served up over HTTP is always nice if not necessary to have behind TLS.
LetsEncrypt long ago brought free certs to the masses and there are a lot of tools for automating that nowadays.
My preferred approach for getting all the unnecessary nonsense I self-host at home behind TLS is Caddy.
I have a super straight forward setup, generally:
- Run Caddy in a docker container
- Create a wildcard CNAME record in my DNS pointing at my home's (effectively) static IP
- Add an entry in my Caddyfile for each services I'm running at home on its own subdomain
- If it's a service then I add it with a
reverse_proxyblock - If it's a static site (like this) then there's a block for
- If it's something I want only accessible on my home network then I put a block like
@local_network {
path *
remote_ip
}
in the directive. And voila.
Then tell Caddy to reload the config and I'm done.
My multiroom audio setup
:PROPERTIES:
:END:
I've put my home audio solution together out of the following components.
- Snapcast
- MPD
- Librespot
- Shairport-sync
- A mini-PC in my closet running the above software
- Two Raspberry Pi 4s
- Four Raspberry Pi Zero Ws
- Some desktop speakers and some Bluetooth speakers (wired to the Pis)
Each of the Raspberry Pis is in a room or porch attached to a speaker.
Snapcast lets me take an audio source and synchronize it across multiple
clients. Each of the Raspberry Pis are running a snapclient instance
and play whatever the snapserver instance tells them to.
Snapcast is setup to send whichever of the streams (MPD, Spotify, Shairport-sync/AirPlay) is playing audio to each of the clients that are connected to it.
This lets me or anyone else on my WiFi network play directly on one or more of the speakers - each named for the room that they're in using either Spotify, AirPlay, picking from my own music collection or by pointing at a URL (like to a podcast episode).
This works out great and we've used it at home for the past year.
I'd like to get the podcast experience to a more seamless place but it's pretty OK right now using AirMusic on my phone to play audio to the speakers over AirPlay.
Tooling tooling
vi modal editing in most places
:PROPERTIES:
:END: For my sake, I prefer to have Vim bindings in as many places as possible.
Most shells can be configured to use Vim bindings by putting set -o vi
somewhere in your shell startup script.
If you're using ZSH then you'll probably want an additional binding to restore CTRL-R reverse history search.
bindkey '^R' history-incremental-search-backward
For CLI tools that use the readline library then you can configure its
input mode using a .inputrc file in your $HOME directory.
This affects REPLs like ghci and tools like psql.
set editing-mode vi
$if mode=vi
set keymap vi-command
# these are for vi-command mode
Control-l: clear-screen
set keymap vi-insert
# these are for vi-insert mode
Control-l: clear-screen
$endifAWS aws
Structed and passively collected metrics via AWS CloudWatch
:PROPERTIES:
:END:
AWS is a vast and sprawling set of services. It can be hard to find the hidden gems like this one so I wanted to point this one out.
Structured metrics are very helpful to monitoring the health and function of an software system.
- Do you want to know how long a particular transaction typically takes?
- How fast your database queries are?
- How long external APIs take to respond?
- Fire an alert when a particular function on the site happens too many times? Or too few times?
…plus a million other things specific to whatever system you're working on.
There are a lot of great tools for doing this and one that you might not know about is AWS CloudWatch Metric Filters. If you're already on AWS then you should consider these because it requires only that your application logs to CloudWatch.
If you're on ECS then the awslogs log driver for Docker gets you that nearly for free. By "free" I mean that your application itself can have zero dependencies on AWS services and not require any AWS credentials or libraries to start pumping out metrics that you can visualize, alert on and record over time.
The AWS docs themselves offer the canonical reference for configuring these so I won't go into detail here.
However, the gist is that for a log filter you define the following properties
- A filter pattern for extracting a discrete metric value out of a log entry
- A metric name to store the value in
- An optional dimension for sub-classifying the value
- And finally a log group to extract the metric values from
After that you just run the application and as the logs roll in the metric values get pumped out. Then you can define alarms for alerting on them, graph them, define autoscaling rules from them and more.
To conclude - AWS is big and hairy. While there are benefits to staying platform agnostic, some AWS services don't require much or any coupling of your application code to take advantage of. Cloudwatch Metrics is one of those services and you can get a lot of value out of it with not much effort.
Musings musings
TODO My job description
TODO Managing expectations
TODO Just let people be wrong
:PROPERTIES:
:END:
Warning: This, like most things, will involve a fair bit of projection.
I have some thoughts about collaboration.
While a lot of this is obvious and well accepted, I think there are some fine points worth elaborating on.
The obvious part is that people work better together when they believe they are trusted. Trust breeds initiative and independence. Distrust breeds resentment and inaction.
Consider the flip side of trust, for a moment.
A common way that people show distrust when collaborating is either micromanaging or just coming in behind someone and redoing their work.
If that demonstrates distrust then
It's not enough that you simply do trust someone else to get the benefits, you need to show it. I think this is the part that many people skip or ignore.
This is, of course, true in general.
Very simple CSS frameworks
:PROPERTIES:
:END:
Minimal CSS / fancy resets
I really like simple drop-in CSS resets like the one I use for this site.
At the time of writing, I'm using Pico but I also considered tacit
The idea is that they provide nice default styling of HTML elements out of the box without the need to reference any specific classes.
The idea works well for sites that are much more content than layout - like this one.
Using tacit is a matter of incluing this link tag in the page's HEAD element:
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.min.css"> doThings :: String -> IO ()
doThings name = do
putStrLn name