While I have moved away from using Proxmox in my home lab I noticed a large number of Terraform users had been using Telmate/proxmox provider. In my experience this provider is almost abandoned and seriously lags behind bpg/proxmox, bpg in my experience has fewer bugs and more features.
This post was not written during the struggles, some details may be missing as the details fade from memory. It seems best to write about my failures here as the process of moving to Harvester actually resulted in me redeploying my lab twice. My first Harvester implementation was severely flawed.
Due to the hardware I had available I thought it would be best to assign the three SFF machines I had to be Harvester master nodes. In hindsight this provided me no real benefit, Harvester handles the promotion and demotion of nodes to master or worker by default. This did not truly provide me any advantage, while it is good practice to keep workloads off of master nodes in traditional Kubernetes clusters Harvester can somewhat break this model. Harvester does not support/condone deploying workloads to the Harvester cluster itself (same as Rancher MCM), the intended model is to deploy downstream clusters for said workloads, this most likely provides the security benefit an operator would be looking for. This is not to say, if someone has the hardware available then they should not dedicate certain nodes as master, but that in my lab with the limited hardware I did not stand to gain much.
For sometime I have been in need not only to study for my CKA but to find an easier way to deploy new clusters, and test new applications. Before this endeavour the best option was to use K3d, and this worked well for trying out applications but if I wanted to play with a new CNI I was out of luck. The next option was to deploy a cluster to VirtualBox, which again, works but my desktop only has so many resources available to it and the setup even with vagrant was far from bullet proof. As a result it was time to move on to finding a solution for the lab. The goal was to find a solution to my cluster building woes, I wanted it to be easy to get a cluster up and running with as little friction as possible, but I didn’t want a cluster with a bunch of caveats, this needed to be a full cluster with all the bells and whistles.
FreshRSS has relatively good documentation but I did find a couple things confusing when attempting to add OIDC authentication via Keycloak. As a result the below set of steps should guide other in setting up their instance.
In the realm you intend on using, create a new OIDC client.
I have come to the realization that online documentation around configuring Nextcloud to use SAML is lacking. I am not an expert by ANY means but I know enough to get things working with some trial and error. The following post is more or less a TL;DR of what to set to enable SAML auth in Nextcloud via Keycloak.
Below are the settings needed for each section of the SAML settings page, do note most settings are hidden so you will need to expand them.
Add externalTrafficPolicy: Local to a kubernetes service to capture source IPs.
Kubernetes by default will not pass the source IP to a LoadBalancer service. Usually this is not particularly an issue most days, however this has become an issue as I re-combine all my rke2 clusters. It was simple before to place internal only applications on one of the two internal only clusters, as I move back to a single cluster Traefik needs to be made aware of source IPs so white listing can be used.
Currently there appears to be a lack of options for home cameras that meet my current needs/expectations. As a result I set out to build my own cameras to fill this need. The intent is to build basic home security cameras that meet the following needs:
The majority of these needs are driven by a need for privacy/security.
As a result of migrating from a single cluster with external access, to multiple internal clusters, cert-manager (on some clusters) necessarily lost access to Let’s Encrypt. This has lead to self signed certificates being used on all (intra-cluster) HTTPS endpoints internally. Realistically this is fine, however an OPNsense firewall is available and this gives the option to use its Trust function. In this example an intermediate certificate authority will be created for one of the three clusters (all three will get their own, but that does not need to be shown here).
Don’t do it, if your certificate does not have a root CA certificate attached git will not read the certificate as valid but the GitLab runner will. Your runner will authenticate but git pulls will continue to fail. If your runner is from an internal non-TLS endpoint this does not impact you.
If you have deployed GitLab via Kustomize and only have access to a self signed certificate, you will need to pass the self signed certificate into the GitLab runner allowing it to authenticate with GitLab.
If your Nextcloud instance is returning “invalid requester” after SAML has been working for some time there is a chance the certificate has expired. Many tutorials online for setting up Nextcloud with SAML+Keycloak have the user use the “Regenerate” button for creating the key/cert pair. This is perhaps more complicated and the renewal time is sub 3 months, so this process needs to be done fairly often. Below is a set of simple steps to update those certs and keys.