So I am pretty sure that error is happening because certbot can’t retrieve the certificate which is coming from that API no matter what type of challenge you are using (this is what ACME is).

Now when you say you are blocking inbound traffic, have you made an exception for established outbound session return traffic? If not then you your inbound rule will block all traffic because without that exception the explicit deny will typically override any session/stateful based rules your firewall might have by default (this applies to most firewall vendors I have run into).

That said, I’m not sure what your goal is but blocking outbound traffic to those ASN might be more effective for you anyway because your firewall should already be dropping any inbound traffic that isn’t otherwise allowed so I’m not sure blocking inbound traffic really gains you anything but I’m just guessing. Hope that all makes sense!

I think your bigger problem with that board is going to be that PCIe slot is a PCIe 2.0 x1 slot so it will be slow but you can just use an adapter like this:

https://www.newegg.com/startech-com-model-pex1to162-pci-express-to-pci-card/p/N82E16815158223

Flexible versions exist too! I’m also not sure you would get a lot of benefit out of a GT730 really so YMMV.

I am in the same boat, long time infrastructure automation engineer as well. Sometimes it’s faster to explain how terraform or whatever needs to act and then fix the issues rather than having to sift through the docs for every provider.

I also do a similar thing to you with code, I also have to read a lot of other people’s code in languages I don’t know to help troubleshoot things and while I can usually follow the logic it is such a time saver to have AI to read the docs for the libraries and languages for me to at least find the part of the docs I need to read faster than searching myself.

Overall, I also agree with the sentiment on AI most of the time and all of its criticisms are definitely valid but I think too many people try to use AI to do their work for them instead of using it more like a rubber duck you can program with normal language.

Lots of good alternatives advice already here but I have a couple comets and they work pretty well! They don’t require cloud access except for updates if you want them, I think it has Tailscale built in as well. Their newest one has an HDMI pass through as well which is handy in some situations. I have the PoE version of the other one and it works the same way, the power control kits work too! I also have a jet KVM and it’s fine, I like the comet better I think! They have also open sourced their cloud thing so you can centrally manage them all, it’s pretty neat!

I had a few ideas, I’m suspicious that handbrake is falling back to CPU, maybe check the logs of the container to make sure it isn’t falling back to CPU decoding. Otherwise here are a few things I would check next:

• If you are not using docker locally so you are already doing this, you will need to configure the docker container to pass through the GPU for quicksync to work inside the container.
• If you are already doing that then I would make sure the device is the same name on the synology, it probably is but just to be sure.
• you will likely need to add your user to the video and/or render group on the synology if you haven’t, especially if you are running the container as your user instead of root
• make sure you are reading and writing to volumes that use bind mounts and not docker volumes, overlayfs is not what I would call fast and writing especially.

So I had a few thoughts. I’m not sure that you can use the docker device flag with a directory as you have there, I think it expects a device node, you can pass that directory as a volume (-v) though.

If that doesn’t work you might also try running the VM with host-passthrough mode set on the CPU as well if it isn’t set that way already, sometimes that is also required for pass through to work from my experience. Also, make sure you passed through the whole device node, sometimes there are audio devices you have to pass through with the GPU device or you will get odd errors like those initialization ones you had. I’m not sure if this is the case for Intel iGPU though offhand though. Are you able to use intel_gpu_top on the VM to access the GPU? None of that is necessarily specific to proxmox though (but probably applies to anything libvirt powered) so YMMV.

Edit: I realized you may not know what a “device node” is, that is the full path to the device, like /dev/dri/renderD128 vs /dev/dri which is actually a directory.

I do on some of mine because it makes some of the automation i have for them simpler to maintain when it is also applied to x86 hardware or virtual machines. It used to be a huge pain to use on a pi but it works pretty well these days, especially since about 24.04 I want to say.