486

joined 1 year ago
[–] 486@lemmy.world 1 points 8 hours ago

It is. It might end up on disk in swap, if you run low on memory (and have some sort of disk-based swap enabled), but usually it is located in RAM.

[–] 486@lemmy.world 4 points 3 days ago

Try diasbling the second DHCP server altogether. You only need one, since you have a flat network.

[–] 486@lemmy.world 8 points 4 days ago* (last edited 4 days ago) (4 children)

Are you sure there is exactly one DHCP server running?

[–] 486@lemmy.world 3 points 1 week ago

I'm exclusively running unprivileged LXC containers and haven't had any issues regarding the firewall, neither with iptables nor nftables.

[–] 486@lemmy.world 5 points 1 week ago* (last edited 1 week ago) (3 children)

No, it is not like Docker. You can treat an LXC container pretty much like a VM in most instances, including firewall rules. To answer the question, you can use fail2ban just like you had done in your VM, meaning you can run it inside the LXC container, where fail2ban can change the firewall rules of that container as it sees fit.

[–] 486@lemmy.world 1 points 3 weeks ago* (last edited 3 weeks ago)

You could give bubblewrap a try instead. It is quite similar to systemd-nspawn.

[–] 486@lemmy.world 1 points 1 month ago

I understood that. My point was rather that in this particular case (a CPU bug that could be fixed via microcode, but AMD chose not to do so for certain CPUs), RISC-V wouldn't have been of any advantage, because there would be nothing to fix in the first place. Sure, one could introduce microcode for RISC-V and people have argued in favor of doing so for this exact reason, but the architecture was intentionally designed to not require microcode.

[–] 486@lemmy.world 4 points 1 month ago (3 children)

As much as I like RISC-V, it is kind of ironic to suggest RISC-V ist the solution to this. At least as it stands, because of RISC-V's simplicity, most if not all current RISC-V CPUs don't even run microcode, so there is nothing to update/fix in case of a CPU bug. There's even a very current example of this problem with that chinese RISC-V cpu that has this "GhostWrite" bug that allows every unpriviliged process to gain root access.

[–] 486@lemmy.world 27 points 1 month ago (2 children)

That's good, I never liked the clunky .home.arpa domain.

[–] 486@lemmy.world 3 points 1 month ago (1 children)

What does it offer that nginx doesnt?

Automatic HTTPS, you don't have to use certbot or something similar to get/renew certificates. Also, its configuration is really simple and straight forward.

[–] 486@lemmy.world 1 points 2 months ago (1 children)

IT-Tools - hands down one of the coolest self hosted tool sets you can use.

Looks similar to Cyberchef. Any reason to use that one over Cyberchef?

[–] 486@lemmy.world 22 points 3 months ago

The guide mentions:

Your ISP will give you the first 64 bits, and your host machine will have the last 64 bits.

This isn't correct. While some ISPs do give you the first 64 bit (a /64 prefix), this isn't recommended and not terribly common either. An ISP should give its users prefixes with less than 64 bit. Typically a residential user will get a /56 and commercial users usually get a /48. With such a prefix the user can then generate multiple /64 networks which can be used on the local network as desired.

view more: next ›