If you have the docker-compose.yml locally, you can nix run github:aksiksi/compose2nix to translate it into a nix file for inclusion in your nixos system config. I think that could be done in the config itself with a git url but I’m not that great at nix. You will surely still need some manual config to e.g. set environment variables for paths and secrets.
How do the DNS servers resolve local hostnames then? The pihole DHCP integration adds local hostnames to DNS when they are assigned an address. If there’s two DHCP servers handing out leases, presumable only one would be accepted, how then would the DNS servers sync those names?
I think I had my secondary pihole resolve local names from the primary, and leases were copied over on a cronjob in case the secondary DHCP server had to be enabled.
Not that it particularly matters for just queries. The problem is that DHCP can only be enabled on one host. If that one fails then devices can’t get on to the network themselves. I’d like to know a good way to have a failover DHCP server - my janky cronjob isn’t great.
Where do you do DHCP? I had a primary pihole with DHCP enabled and a secondary with a cron job that enabled DHCP if the primary was down or disabled it if the primary was working. The cron job did sync DHCP leases from one to the other but it was a bit janky. I tried to update the secondary to pihole v6 and hosed it so I have no backup for now. I’d like to re-image the secondary and get a better setup - when I have time.
Edit to say I really wanted to try keepalived - that’s really cool to fail over without clients noticing.
There’s a talk here: https://www.youtube.com/watch?v=jMUMRNRkcMg but I’m not much clearer after scrubbing through some of the slides. It sounds like all GPIO pins on recent Intel chips support this Timed I/O functionality. I don’t know if they could measure the timing of transactions to a NIC - I would think this is only for specialist hardware or testing. They mention using a logic analyser to compare the clocks of two systems after synchronisation.
Ah, I saw another comment about this. The free plan is 300,000 queries a month. That’d last me almost a week before it stops working.
That says it will only function for 300,000 queries per month. Based on my last 24 hours from pi-hole, that wouldn’t even last a week. Are you using a paid plan?
And Structured Query Language is a handy language for querying structured data?
83 Wooster Street New York. American buildings just be that way.
It’s important for objects that can be dereferenced. Smart pointers have methods that can be accessed with dot syntax like swap(). You can still dereference through a smart pointer using arrow syntax to access methods on the referenced type since they overload the operator->() method.
“abbabba”
“abbabba” doesn’t match the original regex but “abbaabba” does
I think you’d only have to read it once, then you should be able to just filter it out next time you see it.
- Sent from my iPhone
Why use separate partitions over subvolumes within btrfs?
Well at that point, just don’t install any kernel mode EDR software at all.
NixOS can be set up for impermanence where all config is recreated every boot and nothing persists besides the nix store. There’s helpers for ephemeral home also, so you can have something like TailsOS. I’m sure you could do that with other distros but you’d need absolute discipline to have everything the machine needs provisioned at boot.
I think having an A partition and a B partition (I’m assuming that’s how SteamOS works) wouldn’t help in this case. If the A partition downloaded the definition file, crashed and failed to reboot; the bootloader could failover to the B partition - which would then download the definition file, crash and fail to reboot. It would have to keep rolling back to a last known good snapshot until the update got withdrawn.
You could have an ephemeral set up that wipes /var and /etc and recreates them every boot. I don’t think these EDR tools would like that very much though.
Yeah, you’d need to snapshot their data directory and roll that back. The previous kernel module may well have had the bug already, just not a malformed config file to trip it.
Also, if the driver booted ok, but then panicked soon after, would that count as a bad boot? The description seems to indicate the boot counters get reset as soon as a boot succeeds.
It’s a proprietary config file. I think it’s a list of rules to forbid certain behaviours on the system. Presumably it’s downloaded by some userland service, but it has to be parsed by the kernel driver. I think the files get loaded ok but the driver crashes when iterating over an array of pointers. Possibly these are the rules and some have uninitialised pointers but this is speculation based on some kernel dumps on twitter. So the bug probably existed in the kernel driver for quite a while, but they pushed a (somehow) malformed config file that triggered the crash.
That’s a biblically accurate implementation if ever I’ve seen one.