Tycho, UTAH, Attom, lots more in my instrumental playlist. These are mostly chilled or electronic type genre songs, but I also have a “djentstrumental” playlist if that’s your jam, with artists like For Giants, Andromida, Returning We Hear the Larks (a personal favorite), and more.
That definitely makes sense too, particularly when making new friends in my age group. I guess it’s just when contacting people for business vs social communications? I’m not sure
I agree, but I still have this idea that it’s rude to text people unless you have gotten permission first. I think it’s a relic from the 2000s-2010s when not everyone’s phone had texting and if you did text them they could get charged by their phone provider. Obviously nowadays that’s much less of a concern, but still feels like a social grey area for some reason
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
The rightmost is Debian, not sure about the other one though.
Debian 12 - bookworm
Thanks!
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
The Lexus IS500. I know it’s not as fast or “spirited” or technologically advanced as an M340i or a C43. But I love the styling, the reliability, and the naturally aspirated V8. I’ve been talking my wife’s ear off about it and saving up for a while now. I’m hoping maybe in December I can snag one.
Source: https://youtu.be/gRgIpMEcJdc?si=ru97IcPNZpY2fbOf