Great video, thanks for sharing!

For what it’s worth, I have a server with two rj45s (and a third for BMC), but I only plugged one of them into my switch. I run anywhere from 2-8 containers/vms on that server and never felt the need to hook up the other jack. I guess there’s probably some contention of running multiple hosts all through that one connection, but typically I don’t really need anything faster than the ~2-400mbps I get with WiFi anyway. So to answer you question, it depends, but I would generally say maybe start with the one and don’t worry about it unless you’re really moving massive amounts of data regularly and saturating your line. You’d also need to consider you’ll need a switch and other network hardware capable of handling that throughout as well if you’re really going to potentially saturate those ports.

Nice, congrats on getting it working and learning new stuff in the process!

As for why you have to open port 80: I don’t know if this is (still) how certbot works, but back before certbot was a thing, you setup an SSL certificate by adding an HTML tag to your site’s header. That way, when the certificate issuer loaded your site from their end they could see that you did indeed have access to that site (otherwise you wouldn’t be able to add the requisite tag). Once the verification was complete, you could remove the tag. I assume certbot is automating a process similar to this (maybe at the proxy level even), and that’s why you have to open port 80 - so that certbot’s issuer can “see” your site from their connection and verify that you do indeed have access and therefore ownership of it.

To renew your cert, I don’t know if you will need to re-open the ports or not, but I would not be surprised if you did need to. You should be able to run certbot with a dry run flag that will do everything except actually implement a new certificate. You could try doing that with the ports closed and see if it succeeds or fails. If it fails, you probably need the ports open. If it succeeds, you probably don’t need them open. Either way, you’ll find out in November when the automatic renew takes place. Worse case scenario, you get a security warning when you go to the site on your LAN indicating that the cert is expired. You’d then open the ports, renew, and close them again.

As for the risk of having the ports opened for a couple minutes, I think that would be negligible unless you’re hosting something that is inherently insecure. Someone would have to know your public ip and hit it at just the right time to see your site on the open ports. Then they would have to do whatever attacks they want to within the amount of time it takes for you to renew the cert. If you’re hosting something that doesn’t use a secure login page and could be used as a jump box to other devices in your network - that’s probably no bueno. But if you’re running something that’s secured your risk shouldn’t be too bad. Bonus points if you setup your gateway to block outbound connections from your server except for ports 80 and 443, but that’s assuming your server doesn’t need to use other ports of course. It all depends what you’re hosting there, hopefully that makes sense.

Edit: This forum post indicates that access is required for certificate renewal, meaning you would indeed need to open the ports to renew. There is also another style of ownership verification mentioned in that thread which would not require you to open the ports, because it uses DNS to check for ownership. This would essentially require you to add a DNS text record to prove that you own the site’s domain. I am less familiar with this process, but it may be an option for you if you are willing to research it.

I think you’d need to open port 80 since certbot needs to be able to “see” your site to verify you own it before generating the certificate. Once it does its thing you can close the ports from public access (leaving it open on your LAN) again though

Debian 12 - bookworm

I have always gravitated toward Debian until recently. I run LXCs on proxmox and apparently Debian needs nesting enabled or else it takes around 30s to login. I think it’s trying to access a system file when a user logs in that can’t be accessed when nesting is disabled, and it waits to timeout before continuing with the login. Also, I have noticed that when running htop on Debian, it reports the total number of cores on my server, rather than the number of cores I have assigned to the container. Ubuntu doesn’t have either of these problems - I can run it with nesting disabled (more secure) and still login without delay, and htop reports only the number of cores I have assigned to the container.

These are small issues, and there’s probably a way to address them, but I haven’t found any solutions yet. And when I just want to spin up a LXC quickly so I can work on an idea/pipeline/whatever, I’m finding myself going with the more frictionless option lately.

Edit to add: I run all of this headless, so I can’t comment on GUI differences or anything like that