It literally is a cron job or systemd timer to load an updated blocklist from time to time and I haven’t looked at it for years (well… other an changing a path when I switched from unbound to dnsproxy, because that one is even simpler, doesn’t even need a config other than a few parameters at startup and can provide DoH, DoT and/or DoQ access for when I’m not at home)
If you just want simple ad blocking you don’t actually need pi hole for it’s web interface you don’t ever look at once it runs. Unbound alone can do the job with minimal configuration.
Nowadays I even changed my setup to dnsproxy, which doesn’t even need any config. It’s just a handful parameters when you start it. And it does all the filtering for my home network as well as providing DoH access for when I’m not at home and connected from somewhere else.
I never understood pihole in the first place. It’s just a fancy web interface you do never look at if the thing does its job quietly in the background. And unbound alone is perfectly able to use blocklists with one line of configuration (and an onliner script to convert the common lists into the right format).
I use no-ip because that was one of the few my router back then many, many, many years ago supported out-of-the-box and there was never a reason to change…
That’s generally good advice but not actually security related.
Removing all the stress on your ressources by using a non-standard port is good for your ressources, But those automated scanners looking for unsecured devices and trying out password like admin/admin are not actually a risk. It’s just a case of security by obscurity and never actually serves its purpose.
No, thanks. My “research” is testing AI from time to time. And it is indeed artificial idiocy most of the time.
And when basically all answers I ever get from AI proponents is either “Those local models are just not powerful enough so it’s on you that you don’t get sane results” or “Those models just need some tuning so it’s on you for not running a local one you can optimise for your usecase” you start to realize there might be an entirely different problem…
I get perfectly good search results by avoiding AI, so there is really no need for me to tune anything but the settings on my searxng instance…
I still don’t understand where people are findign these useful AI answers. Every single time I try it seems AI is an acronym for artificial idiocy and I wouldn’t even trust it to tell me the time.
(In fact I just resently tried asking that stupid meta AI in sand-boxed Whatsapp (I still have to keep because of some stubborn examples of humanity) about the time in another time zone… It could tell my local time, in which time zone I was, what timezone I was asking about and what the difference between those zones was. Yet it could somehow not answer the question directly before being led there step by step. And then it still did the math wrong… 🤬)
I have made the completely opposite experience. I tried so many distros and every single time some non-trivial issues came up my search ended in the arch wiki finally explaining stuff and writing out available options in config files instead of just telling my what option in what GUI config tool (that might or might not exist in my distro) I should click, then pray it works (felt very alike to windows actually where you get two dozen guides to solve a problem, each one editing another obscure registry key and trying to find the one actually working with the current version).
So I wasted years listening to the “No, Archlinux is a meme and totally unusable for inexperienced people” before installing archlinux, which is now running for more than 9 years without problems, and will happily point people asking questions for other distros to the relevant parts of the arch wiki that actually spell stuff out properly.
how it affects the temperature
positively… 🔥
“Learn to love the slob! The slob is the future!”
That’s what the documentation says. I don’t know if/when that changed as I barely use docker.
Well… it’s the default iirc (192.168.65.0/24). So that’s what docker uses if there is no explicit configuration you could find.
the 192.168.65.1 address that manifested out of nowhere
Or it’s indeed the internal virtual lan your docker config uses…
Is that an actual problem or are you really just trying to fix the logs? That should be doable via headers so the real origin is preserved independent of proxying.
If you use the shortlived profile and your key is compromised, you benefit from the short lifetime.
Maybe I’m just too stupid to understand how those certificates work.
But in what scenario is my key compromised but not my server? Because someone getting control of my server can just get an new long-term certificate. That was my actual point in the comment above. I understand the argument of added security if they only issue short-term certificates. But where is the benefit of my short-term certificate when someone compromising my server can just get a new long-term one in seconds?
Also we are talking about self hosting. I understand the issue of revoking certificates when you have a massive userbase where some might miss the revocation for quite some time. Not so much with the dozen max family and friends.
Washer/dryer getting their signal to start from an outside source according to electricity price (with a dynamic plan) or weather (with your own solar) actually makes sense. I really don’t care when it does my laundry as long as it’s done between me leaving the house in the morning and coming back in the evening.
The main point is that even smart appliances barely ever need their own connection to the internet. Getting (meaningful) communication from inside your home network (including from the one device that acts as your access point from the outside that has a connection) is absolutely enough.
I know that I could easily change my config. My point is that a) they are failing to advertise this and b) I don’t see any reason to do it. I understand the arguments about security benefits of shorter certificates on their side and iirc they are already planning to change it from 3 months to 1.5 months in the future. But in what scenario do I benefit from a short-term certificate as long as the regular ones are still available anyway?
Certbot came with a systemd timer running twice a day (0, 12 +12h random) that only renews –iirc– when the certificate has 30 days or less to live. Also I looked it up and my (version 6.7) Certbot neither mentions the option with the --help option, nor in the manual (where there is just one instance of “profiles exist, no other details given”).
So they probably need another way than a random blog post when they want users to use (or even just know about) that option…
It’s been pretty much a set-and-forget experience
Yeah, that’s what it always has been. So no need to change anything unless they make it the new standard on their side with an update…
So exactly like an AGI emerging after just one more update.
You mean they are reaching geo-synchronous orbit after already skyrocketing this year?
My “script” to update the blocklist from time to time was literally
curl <blocklist1 link> > templistcurl <blocklist2 link> >> templistgrep '^0\.0\.0\.0' templist | awk '{print "local-zone: \""$2"\" always_refuse"} > blocklist.confsystemctl restart unbound.serviceand an
include blocklist.confat the bottom ofunbound.conf(awk to convert it from the “0.0.0.0 <site>” format to “local-zone: <site> always_refuse”).