Damn… You too?
Damn… You too?
That has not been my experience… amdgpindriver was crashing quite often, gfx ring 0 timeout. Tons of people with that problem forums. I managed to adjust some parameters and fix it eventually.
VRR doesn’t work properly, I can get it to work, burnout is a shore every time.
I have both and nvidia and an amd GPU, and with xwayland fixed, the nvidia one can run just as well.
That said, paying 2k for a GPU to have raytracing and 24gb of RAM isn’t that attractive.
I can’t remember all the details, but depending on the CPU you are running you may need some extra configuration on opnsense.
There were a few issues, on my servers, running on older Intel Xeon CPUs, but I eventually fixed them adding proper flags to deal with different bugs.
Other than that, running on a VM is really handy.
It is nice that you got it running, but when everything you end up doing is running services in low ports or needing specific IP address in different networks, rootless podman is just a PITA.
In my case I have one pihole running on a docker container and another one that runs directly on a VM.
Someone said before “what’s the point of running in a container”… Well, there really isn’t any measurable overhead and you have the benefit of having a very portable configuration.
I do think the compromises one has to go through for podman rootless are not worth in this case, for me, not even the rootful worked properly (a few years ago), but this is a nice walkthrough for people wanting to understand more.
I can’t say if you are overstating it but, only mention that I went through a similar path. I had it multiple scripts running and it was a neverending thing.
Since I have moved to small step I never had a problem.
The biggest advantage I got is for products like opnsense, you can do automatic renewal of certificates using your internal CA.
Generating new certs is still as simple (actually much easier for me) than relying on openssl or easyrsa scripts.
There are a few ways to do it, but you don’t use caddy for SSH.
Last option is how I run my Gitea instance, authorized keys is managed by gitea so you don’t really need to do anything high maintenance.
~git/.ssh/authorized_keys:
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-9",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-rsa PUBLICKEYHASH
/usr/local/bin/gitea:
ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.14 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"
127.0.0.14 is the local git docker access where I expose the service, but you couldn’t different ports, IPS, etc.