Running local LLMs: ollama + opencode with gemma4:e2b

Assuming you have ollama installed and a local model already downloaded, install opencode following steps here.

Create an opencode.json with config pointing to your downloaded model:

{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"gemma4": {
"name": "gemma4:e4b"
}
}
}
}
}

Start opencode from ollama with:

ollama launch opencode

Scroll down to other models and select the model you configured above.

You have a backup for your homelab pfSense config, right?

I’ve fallen into the trap of not having backups for parts of my homelab, in this case pfsense.

I’ve been using pfsense to bridge traffic between my home network and a vlan in my Proxnox homelab (documented here), but after attempting to update my config to use a static up for the wan up, apparently I broke all access to the web config hi, and then after trying to put it back, I still can’t access it, a,though it appears to be running running (routing traffic from my home lan to my homelab lan as expected).

I don’t have a backup of the settings, or even a snapshot of the VW that I can restore.

Hard lessons learnt are often then best lessons ☹️

GitLab CI – docker compose to remote host fails with: Host key verification failed

I’m getting this error when a GitLab CI job is attempting to ‘docker compose up’ to a remote context:

$ docker --context remote compose -f docker-compose-remote-db.yml up -d --pull always
unable to get image '10.0.10.3:5000/my-image:latest': error during connect: Get "http://docker.example.com/v1.51/images/10.0.10.3:5000/adsb-dashboard:latest/json": command [ssh -l gitlab-runner -o ConnectTimeout=30 -T -- 10.0.10.3 docker system dial-stdio] has exited with exit status 255, make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=Host key verification failed.

According to answers here, this could be because when the job runs for the first time the host signature has not been added to known_hosts yet. You can avoid this by:

echo "StrictHostKeyChecking no" >> ~/.ssh/config