Musings of a noob as I migrate from Windows to FreeBSD in my homelab

I am envious and my hat is off.
While
resisting the primal urge to become de facto sysadmin at home, when I fled the career - not wanting to spend any more hours figuring out other people's software, avoiding traps and hacking around just to make it a bit more usable.

Home Assistant is the max I am willing to administer, which is not much of a hassle.
But I need me some OPNSense, just to make sure my TV is not sharing my StarGate Atlantis view counter or Hermes agent is not hacking National Bank or exchanging my boudoir photos for tokens.
 
bakul which files did I omit? I did my best to be thorough in my posts about the LDAP+Kerberos setup... let me know what I missed and I'll fill in the blanks.
 
bakul which files did I omit? I did my best to be thorough in my posts about the LDAP+Kerberos setup... let me know what I missed and I'll fill in the blanks.
Er.... I wasn't paying (sufficient) attention to past posts! I meant everything needed to set up something as fancy as the diagram you showed in #74! I will read through it all and respond.
 

Service deployment update: I burned down my CA and started over​

Or: what a 2015 guide doesn’t know about 2026 browsers​

Much earlier in my setup journey log, I described how I implemented root and intermediate CAs, built by following JamieLinux’s very well-written OpenSSL CA guide. I stand by “very well-written,” it's excellent, but now I'd add the caveat that it's out of date. His guide was posted in 2015, and a lot has changed since then. A couple of weeks ago (between the jail repair and the SSO posts) I rebuilt both CAs from scratch. If you noticed the two-cert chain file in my SSO post, this is where it came from.

The problem that finally got to me: certificates served by my own web services weren’t trusted, even though the clients trusted the CAs that issued them.
  • I put an nginx reverse proxy in front of jellyfin and gave it a cert signed by my intermediate CA. Firefox on my desktop threw an SSL_ERROR_BAD_CERT_DOMAIN error and refused to load the page.
    • Both CA certs were in the client trust store, and openssl verify against the chain said OK. I have to admit I was stumped for a while, and with larger tasks on my to-do list I just kept procrastinating... most browsers will allow you to add an exception and click through a cert error, so that's what I did.
  • Same story for phpLDAPadmin behind an nginx reverse proxy: I had just been clicking through the warning on that one for months, promising myself that someday I'd fix the certificate trust issue.
Once I got to work it turned out the solution was straightforward: the jaimelinux guide’s server_cert extension section has no subjectAltName. Every cert I'd issued carried the hostname in the CN, but no SAN. Internet history buffs will know that browsers stopped looking at the CN years ago. I had no clue... live and learn. Apparently modern browsers only check the SAN, so a cert without one doesn’t match any hostname, no matter who signed it. My chain of trust was fine. The certs just didn’t name the servers they were protecting.

Quick fix: revoke the bad certs and reissue them with an extfile that adds subjectAltName = DNS:host.mydomain.com. That worked, and my browsers were finally happy.

Once I started reading up on what was missing from the stock jaimelinux CA build, I found that the most of his guide’s extensions were also showing their age:
  • Netscape extensions (nsCertType, nsComment) that nothing has read in years
  • authorityKeyIdentifier = keyid,issuer:always, where the issuer part pins the CA cert’s serial and breaks chain building if the CA is ever reissued
  • keyEncipherment on every server cert, which is wrong for modern ECDSA keys
  • Server keys generated on the CA and then copied out to the server. The private key should never leave the box it belongs to.
  • Sequential serials, plus unique_subject = yes, which blocks a renewal until the old cert is revoked. That means an outage window on every renewal. I couldn't care less about this one... it takes 3-5 minutes to go from envisioning a renewed cert to having it installed and working, and with < 5 people in the house there will always be a time for me to do this. If anyone else is using my posts as any sort of guide (you probably shouldn't), this could be more of an issue.
  • No CRL Distribution Point or AIA in any cert, so clients have no way to find out a cert was revoked. I'd always had plans for an online CRL, but never actually followed through. See my signature...
  • No limits on what the intermediate can sign. If someone steals that key, they can mint a cert for google.com that every one of my machines would trust.
I’d only issued about half a dozen certs. Patching the old CA would have meant re-signing the intermediate anyway, so starting over was less work than fixing it. The root CA jail got rebuilt too, from a clean 15.1 base.txz, after my recent jail corruption adventure made me paranoid about every jail built from my original template.

I’ll admit I had help on this one. Claude wrote the issue-cert script below (my scripting skills are non-existent, and I really wanted a menu-driven process), and I spent the session double-checking its work and correcting it when it wandered off. Same disclaimer as before: it’s a fast assistant, not a substitute for knowing what you’re signing.

What changed vs. the JamieLinux guide​

The basic structure is unchanged: offline root in an encrypted jail, intermediate in its own jail doing the day-to-day signing. If you refer to jaimelinux's guide as a starting point, everything should look familiar. The differences:
  • SAN on every server cert, FQDN first. No exceptions.
  • ECDSA everywhere. P-384 for both CAs with SHA-384 signatures, and P-256 for server certs (RSA 3072 is still an option if some client can’t handle ECDSA). The guide used RSA 4096/2048.
  • Server keys are made on the server. Only the CSR goes to the intermediate CA, and only the signed cert comes back.
  • Key usage matches the key type. ECDSA gets digitalSignature, and RSA also gets keyEncipherment.
  • authorityKeyIdentifier = keyid:always, with no issuer part.
  • Random serials (rand_serial = yes) and unique_subject = no. To renew, I issue the new cert, deploy it, and then revoke the old one with reason set to "superseded". No outage window, if that matters to you.
  • Validity: 397 days by default and a hard cap of 825. Apple rejects private-CA certs valid longer than 825 days, and my kids are on iPhones (peer pressure).
  • nameConstraints on the intermediate. It can only sign names under mydomain.com and addresses in 192.168.0.0/16 and 10.0.0.0/8. A stolen intermediate key is worthless for anything outside my own network.
  • pathlen:0 on the intermediate, so it can sign server certs but not another CA.
  • CDP and AIA in every cert, pointing at http://pki.mydomain.com/. The root CRL URL goes in the intermediate’s CDP, and the intermediate CRL plus the intermediate cert (for AIA) go in the leaf certs.
  • No hand-typed openssl ca commands. A small issue-cert script builds a per-cert extension file, signs the cert, builds the full chain, verifies it, and keeps the extension file on record. Fewer typos...
  • The root CA jail has no network at all. Its jail.conf block is literally just vnet;, so it gets an isolated stack with only lo0. CSRs and certs move between the root and intermediate jails through the host’s filesystem. As before, it lives on an encrypted dataset whose keyfile is on a USB stick that’s never near the machine unless I’m signing something.
[ CA_default ]
# ... dir/certs/crl/etc same layout as JamieLinux ...
rand_serial = yes
default_md = sha384
default_crl_days = 365
unique_subject = no
copy_extensions = none

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:true
keyUsage = critical, keyCertSign, cRLSign

[ v3_intermediate_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, keyCertSign, cRLSign
nameConstraints = critical, @name_constraints
crlDistributionPoints = URI:http://pki.mydomain.com/root.crl

[ name_constraints ]
permitted;DNS.0 = mydomain.com
permitted;IP.0 = 192.168.0.0/255.255.0.0
permitted;IP.1 = 10.0.0.0/255.0.0.0

[ crl_ext ]
authorityKeyIdentifier = keyid:always

CA keys are ECDSA P-384 instead of RSA 4096:
# jexec rootcajail openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 -aes-256-cbc -out /root/ca/private/ca.key.pem

The root is good for 20 years and the intermediate for 10 (-days 7300 and -days 3650), same as the guide. The intermediate’s openssl.cnf uses default_md = sha384, default_days = 397, default_crl_days = 180, rand_serial = yes, unique_subject = no.

#!/bin/sh
# Sign a CSR with the intermediate CA, choosing extensions per certificate.
# The per-cert extension file is kept in ext/, so every cert's settings are on record.
set -eu

CA=/root/ca/intermediate
CONF=$CA/openssl.cnf
INTER=$CA/certs/intermediate.cert.pem
CHAIN=$CA/certs/ca-chain.cert.pem
CDP_URL=http://pki.mydomain.com/intermediate.crl
AIA_URL=http://pki.mydomain.com/intermediate.cer
DEFAULT_DAYS=397
MAX_DAYS=825

usage() {
cat >&2 <<EOF
usage: issue-cert -n FQDN -r CSR [-s SAN]... [-p PROFILE] [-d DAYS] [-C] [-A] [-o DIR] [-y]
-n FQDN primary name: first DNS SAN and the output file prefix
-r CSR certificate signing request (PEM)
-s SAN extra SAN, repeatable: DNS:alias.mydomain.com or IP:10.0.0.4
-p PROFILE server (default) | server-client | client
-d DAYS validity in days (default $DEFAULT_DAYS, max $MAX_DAYS)
-C add the CRL Distribution Point ($CDP_URL)
-A add AIA caIssuers ($AIA_URL)
-o DIR also copy the cert and full chain to DIR
-y don't ask to sign/commit (the passphrase is still asked)
EOF
exit 2
}

die() {
echo "issue-cert: $*" >&2
exit 1
}

NAME= CSR= EXTRA= PROFILE=server DAYS=$DEFAULT_DAYS CDP=no AIA=no OUT= BATCH=
while getopts n:r:s:p:d:CAo:yh opt; do
case $opt in
n) NAME=$OPTARG ;;
r) CSR=$OPTARG ;;
s) EXTRA="$EXTRA,$OPTARG" ;;
p) PROFILE=$OPTARG ;;
d) DAYS=$OPTARG ;;
C) CDP=yes ;;
A) AIA=yes ;;
o) OUT=$OPTARG ;;
y) BATCH=-batch ;;
*) usage ;;
esac
done
if [ -z "$NAME" ] || [ -z "$CSR" ]; then usage; fi

# --- check the arguments ---
[ -r "$CSR" ] || die "can't read $CSR"
case $NAME in
*.*) ;;
*) die "-n must be a fully qualified name, e.g. host.mydomain.com" ;;
esac
case $DAYS in
''|*[!0-9]*) die "-d needs a whole number of days" ;;
esac
[ "$DAYS" -le "$MAX_DAYS" ] || die "$DAYS days is over the $MAX_DAYS-day limit"
case $PROFILE in
server) EKU=serverAuth ;;
server-client) EKU="serverAuth, clientAuth" ;;
client) EKU=clientAuth ;;
*) die "unknown profile '$PROFILE'" ;;
esac
for s in $(echo "$EXTRA" | tr ',' ' '); do
case $s in
DNS:?*|IP:?*|email:?*|URI:?*) ;;
*) die "bad SAN '$s' - use DNS:, IP:, email: or URI:" ;;
esac
done
if [ -n "$OUT" ] && [ ! -d "$OUT" ]; then die "no such directory $OUT"; fi

# --- check the CSR and pick key usage from its key type ---
openssl req -in "$CSR" -noout -verify >/dev/null 2>&1 || die "CSR self-signature does not verify"
TEXT=$(openssl req -in "$CSR" -noout -text)
ALG=$(echo "$TEXT" | sed -n 's/^ *Public Key Algorithm: *//p' | head -n 1)
case $ALG in
rsaEncryption)
BITS=$(echo "$TEXT" | sed -n 's/.*Public-Key: (\([0-9]*\) bit).*/\1/p' | head -n 1)
[ "${BITS:-0}" -ge 2048 ] || die "RSA key is ${BITS:-?} bits; 2048 is the minimum"
KU="critical, digitalSignature, keyEncipherment" ;;
id-ecPublicKey)
KU="critical, digitalSignature" ;;
*) die "unsupported key algorithm '$ALG' - use RSA or ECDSA" ;;
esac
CN=$(openssl req -in "$CSR" -noout -subject -nameopt multiline | sed -n 's/^ *commonName *= *//p')
if [ "$CN" != "$NAME" ]; then
echo "issue-cert: note: CSR Common Name is '$CN'; the SAN will use '$NAME'" >&2
fi

# --- output names ---
STAMP=$(date +%Y-%m-%d)
BASE=$NAME.$STAMP
EXT=$CA/ext/$BASE.ext
KEEPCSR=$CA/csr/$BASE.csr.pem
CRT=$CA/certs/$BASE.cert.pem
FULL=$CA/certs/$BASE.fullchain.pem
if [ -e "$CRT" ]; then die "$CRT already exists"; fi
mkdir -p "$CA/ext" "$CA/csr"
cp "$CSR" "$KEEPCSR"

# --- write this cert's extension file ---
{
echo "[ leaf ]"
echo "basicConstraints = critical, CA:FALSE"
echo "keyUsage = $KU"
echo "extendedKeyUsage = $EKU"
echo "subjectKeyIdentifier = hash"
echo "authorityKeyIdentifier = keyid:always"
echo "subjectAltName = DNS:$NAME$EXTRA"
if [ "$CDP" = yes ]; then echo "crlDistributionPoints = URI:$CDP_URL"; fi
if [ "$AIA" = yes ]; then echo "authorityInfoAccess = caIssuers;URI:$AIA_URL"; fi
} > "$EXT"

# --- sign ---
if ! openssl ca -config "$CONF" -extfile "$EXT" -extensions leaf \
-days "$DAYS" -notext $BATCH -in "$KEEPCSR" -out "$CRT" ||
[ ! -s "$CRT" ]; then
rm -f "$CRT" "$EXT" "$KEEPCSR"
die "certificate not issued"
fi

# --- full chain, verify, summary ---
cat "$CRT" "$INTER" > "$FULL"
chmod 444 "$CRT" "$FULL"
openssl verify -CAfile "$CHAIN" "$CRT"
openssl x509 -in "$CRT" -noout -subject -serial -enddate -ext subjectAltName,extendedKeyUsage
if [ -n "$OUT" ]; then
cp "$CRT" "$FULL" "$OUT/"
chmod 444 "$OUT/$BASE.cert.pem" "$OUT/$BASE.fullchain.pem"
fi
echo "cert: $CRT"
echo "full chain: $FULL"
echo "extensions: $EXT"

On the server that will use the cert (key never leaves it):
# openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc -keyout host.mydomain.com.key.pem -out host.mydomain.com.csr.pem -subj "/CN=host.mydomain.com"
# chmod 600 host.mydomain.com.key.pem

Copy the CSR over to the intermediate CA jail (with SSO in place, plain scp as my own user works), then from the jailhost:
# jexec intermediatecajail sh -c '/root/ca/bin/issue-cert -n host.mydomain.com -r ~myuser/host.mydomain.com.csr.pem -C -A -o ~myuser'

Just follow the menu prompts- the script does the work for you. Add -s DNS:alias.mydomain.com or -s IP:10.0.0.4 for extra names. Copy the fullchain back, and check that the cert matches the key before installing anything:
# openssl x509 -in cert.pem -noout -pubkey > /tmp/c.pub; openssl pkey -in key.pem -pubout > /tmp/k.pub; cmp -s /tmp/c.pub /tmp/k.pub && echo KEY-MATCHES; rm -f /tmp/c.pub /tmp/k.pub

nginx and slapd both get the full chain (leaf + intermediate).
And there you have it... no more cert issues raised by browsers when using my internal services. Unlike many of the nitpicky little problems that distract me, this one had broader impact. A cert warning would stop my wife and kids cold and have them come running to me asking why they can't get to jellyfin. Now, once I finish re-ripping my damaged media files and grant them access, they won't have any problems hiding away to watch a movie instead of interacting with the rest of us.
  • Correction to something I said in one of my LDAP posts: I said OpenLDAP couldn’t read a .pem with more than one cert in it, and split my chain to work around that. Both slapd instances now use the two-cert chain file for olcTLSCACertificateFile without complaint, so whatever was wrong back then, it wasn’t that. My guess is YAT (yet another typo).
 
Fun with SSO:
(you know, for kids!)

SSO for SSH logins solved an annoyance for me, so I went looking for another spot where I had a gap and might be able to make things easier. An obvious place was the rpi I use for IOT - for simplicity it runs Raspbian (Trixie-based) and uses Docker compose to fire up Node Red, Zwave-JS UI, Zigbee2mqtt, and Mosquitto. Mosquitto doesn't have a built-in front end, but the other 3 packages do, and they were unsecured. There are hoops you can jump through to individually lock down access with a local auth setup and/or SSL cert, but they're not that well documented and I didn't want to risk locking myself out while implementing some ad-hoc fix. Instead, I went with an nginx reverse proxy that serves up a landing page I can use to navigate to my IOT GUI sites.

I issued a cert with my rebuilt CA for the nginx site and got the reverse proxy up and running. All was good, but there was still no security - anyone on my network could access the site and potentially break my hard-won automations while poking around. No password auth for me... I wanted to use Kerberos tickets for site auth instead, and it just so happens a package exists for this: the SPNEGO module (libnginx-mod-http-auth-spnego if you're looking for it with apt) is a bolt-on for nginx that does exactly what I needed. Properly configured, it will ask for a Kerberos ticket from a user visiting the site and authenticate that ticket against my KDC. (The pi is already part of my house-wide SSO setup, so it has a host principal and keytab and knows how to talk to the KDC)

There's a Firefox tweak I had to make in order to get the browser to forward my ticket when asked - in about:config set network.negotiate-auth.trusted-uris to the FQDN of the site.

Just having a ticket meant you could still get in to my IOT web pages, and that's no good. The most likely interlopers are my kids (they have accounts and can get tickets), not some unknown intruder - I needed additional control. The security lockdown comes in with the SPNEGO config. I told the module to accept tickets only from my user, so nobody else can get in and start breaking things. No ticket, no access. Ticket says you're my daughter, sorry but you can't come in. It's one line in /etc/nginx/iotpi-authz.conf, which is then included in the SPNEGO config:
Code:
auth_gss_authorized_principal myuser@MYDOMAIN.COM;

And that's the end of the story... get the reverse proxy set up, install and configure SPNEGO, tweak the browser, and site access is restricted to just me. Here's what it looks like when I go to the site - no password required, it just pops up:
iotpi access granted.png

Here's what everyone else sees:
iotpi access denied.png


# Me, with a ticket: challenge, retry over HTTP/1.1, ticket accepted (304 code)
10.0.0.52 - - [29/Oct/2026:05:45:57 -0400] "GET / HTTP/2.0" 401 172 "-" "<Firefox>"
10.0.0.52 - - [29/Oct/2026:05:45:57 -0400] "GET / HTTP/1.1" 401 172 "-" "<Firefox>"
10.0.0.52 - myuser@MYDOMAIN.COM [29/Oct/2026:05:45:57 -0400] "GET / HTTP/1.1" 304 0 "-" "<Firefox>"

# My wife, with a ticket: same handshake, identity confirmed, refused (403 code)
10.0.0.52 - - [29/Oct/2026:05:57:13 -0400] "GET / HTTP/1.1" 301 162 "-" "<Firefox>"
10.0.0.52 - - [29/Oct/2026:05:57:13 -0400] "GET / HTTP/2.0" 401 172 "-" "<Firefox>"
10.0.0.52 - - [29/Oct/2026:05:57:13 -0400] "GET / HTTP/1.1" 401 172 "-" "<Firefox>"
10.0.0.52 - wifeuser@MYDOMAIN.COM [29/Oct/2026:05:57:13 -0400] "GET / HTTP/1.1" 403 118 "-" "<Firefox>"

One principal, one keytab, a dozen lines of nginx config, and every web GUI in the house could get the same treatment. Next candidates are the jellyfin admin pages and phpLDAPadmin.
 
We were clearly misled !

This is no noob.

Warning:
Yesterday, I started to restore Home Assistant backup (2 GB compressed) to my new install on proxmox.
12 hours later it is still burning CPU.
Haas Forum lookup showed it is common occurrence and source of grief among users. No explanation other than that database rebuild takes time. People reporting days and many others reporting they just gave up, even on very powerful servers.
I will give it another day and then go back to my Rapsberry with the outlook that when the SD CARD fails, I am just screwed and back to analog life - no commander Data switching off lights for me. Maybe I can restore automations, scripts and dashboards manually elsewhere and let the Ai agent just rewrite the device names to fit vanilla manual new install.

It just reminds me of old sysadmin days - every disaster recovery I witnessed, resulted in very manual restore process, no matter the claims and promises of backup solutions.
I am glad I am not sysadmin anymore - these days the complexity is just too much.
 
12 hours later it is still burning CPU.
Haas Forum lookup showed it is common occurrence and source of grief among users. No explanation other than that database rebuild takes time.
That's alarming - I'll have to re-think using the built-in backup facility in HA. My other pis are backed up using rsync with sanoid keeping track of everything + yearly full card images. I can image the card on my HA pi no problem, but for the rest... I'm glad HA doesn't hold the keys to my automation. DanielBowman it sounds like now might be a great opportunity to mess around with HA alternatives... my 4-component IOT pi is using Docker containers that "just worked". Automations aren't exactly a breeze - there's a learning curve to Node Red - but if you've ever messed around with LabView it'll be very familiar. An example:

1793358482066.png
 
We were clearly misled !

This is no noob
Definitely not a noob! 😂

I feel compelled to push back- I did add a disclaimer in my 1st post:

I admit things have come along better than I'd hoped for- I attribute that to being old enough that when I was in school the emphasis was on teaching us to teach ourselves. Nothing like good old fashioned problem solving skills to get you where you need to go. I weep for the current generation, who in many cases can't seem to follow a trail of breadcrumbs even if you hold their hands and give them a bloodhound to point the way.
 
emphasis was on teaching us to teach ourselves
There is no other way really. One has to learn himself.
And we had no other chance. No Internet, books were scarce/expensive even if you knew they even existed. Teachers even if good had no time to explain in detail/big picture.
Frankly, the best teaching I got was from other classmates. They had time (or you bribed them with snack) and they just told you the bare bones - not trying to maintain aura and academic acumen - "Look idiot, the integral is just a fancy method to calculate approximately the area of a function by small rectangles. You know what rectangle is, right, dummy? Spoiler, it has nothing to do with your mom's rectum." Yeah my classmates were really coarse set of ungentlemanly proto-engineers.
 
DanielBowman it sounds like now might be a great opportunity to mess around with HA alternatives...
Don't tempt me, devil.
I will not be sysadmin where I eat....or anywhere anymore. I had enough. I am not natural. My systems worked flawlessly but it was too much pain and effort for me. And I more and more dislike fiddling with software or hardware quirks someone else build. No more reading of the f..king manuals....which are more like empty promises anyway (yeah the restore is on it's 17th hour and still going, I am disappointed and pi$$ed )
 
My systems worked flawlessly but it was too much pain and effort for me.
Just one bite... apples are yummy! Seriously tho, my experience with mqtt, zwave, and z2m on a pi, automated with Node red has been stellar. I haven't had one instance where I've needed to do actual sysadmin work to recover from something going wrong, knock on wood. Plus, the configs are all backed up (I should write a post on my backup scheme). Relatively easy recovery if the pi or it's MMC fails... start fresh, install containers, copy over configs, done.
 
That's alarming - I'll have to re-think using the built-in backup facility in HA. My other pis are backed up using rsync with sanoid keeping track of everything + yearly full card images. I can image the card on my HA pi no problem, but for the rest... I'm glad HA doesn't hold the keys to my automation. DanielBowman it sounds like now might be a great opportunity to mess around with HA alternatives... my 4-component IOT pi is using Docker containers that "just worked". Automations aren't exactly a breeze - there's a learning curve to Node Red - but if you've ever messed around with LabView it'll be very familiar. An example:

View attachment 27790
At which application i am looking at ?
 
I will give it another day and then go back to my Rapsberry with the outlook that when the SD CARD fails, I am just screwed and back to analog life
Stick that card in a reader and dd it to grab an image. If/when the card fails, at least you have a point in time snapshot you can easily write to a new card and get running again.
 
ganttchart
Did one in Excel some years ago, i.e. with no Ai.
I fu.king hate VBA.
I had temporary contract, tho. Otherwise I would tell them where to find Mr. Gantt.
"Look, this company made nice gantt diagram for past project, just copy it." - Yeah well, those f.ckers just colored it in Excel manually and for milestones they manually pasted pictures of arrows.
So I took two free samples, each one wrong in some way, inspired myself and did THE GANTTCHART, fully automated. Stll fuc.ing useless, really - no way to make the calendar zoom.
 
FYI, all is good with Home Assistant Restore to proxmox.
It did not change the IPv4 to the original but everything else was there ...just not showing completion.
Reason for that might be Whisper and Piper apps not being able to load, not having the proper processor functions at disposal.
I assumed creators of the proxmox helper script know what they are doing. You need the processor type set to host for piper, whisper etc. to work.
Also memory balooning should have been disabled btw.
 
all is good with Home Assistant Restore to proxmox.
Good to hear- always a relief when that pending multi-day fix turns out to be unnecessary. At work I don't mind so much- job security. At home... let me know if/when you get fed up enough to drop Home Assistant and go DIY. Happy to help...
 
Back
Top