Shadow

joined 2 years ago
MODERATOR OF
[–] Shadow@lemmy.ca 18 points 1 year ago (1 children)

I can't tell what this does from the site linked, but I said the apps name out loud and my cat came running.

[–] Shadow@lemmy.ca 13 points 1 year ago (5 children)

This is such a great steam deck game to play casually while watching TV or something, horribly addictive too.

[–] Shadow@lemmy.ca 4 points 1 year ago* (last edited 1 year ago) (1 children)

Yes it's really that easy. Raid in Linux is usually at the partition level, not the whole device. The bootloader resides in the first few blocks of the disk before your partitions, and isn't included in the raid.

Use grub-install on the new disk device, ie /dev/sda

[–] Shadow@lemmy.ca 7 points 1 year ago* (last edited 1 year ago) (3 children)

Replace one disk, let the raid rebuild. Do the same with the other disk. Do an mdadm grow, then maybe fdisk / lvm / resize fs depending on your setup. Don't forget to install a bootloader when you put a new disk in.

Making a new array and migrating data is for chumps.

[–] Shadow@lemmy.ca 3 points 1 year ago

Interesting, thanks for the link!

[–] Shadow@lemmy.ca 3 points 1 year ago (2 children)

Well that's technically correct, but if you're so dependent on disk cache for system performance that you can't live without it then you really need to look at doing an upgrade.

When a box swap deaths, it usually struggles to actually fill swap enough to have the kernel still OOM kill it at any point. Generally the massive performance impact of swapping just slows the app down to the point of being useless, along with the entire rest of the box. Disk cache should not be a concern during these abnormal events.

[–] Shadow@lemmy.ca 8 points 1 year ago (6 children)

Just turn off swap? You don't really need it, and the kernel wiil just oom kill without it.

[–] Shadow@lemmy.ca 32 points 2 years ago (2 children)

Self hosting email is even more of a pain.

[–] Shadow@lemmy.ca 11 points 2 years ago

A lot of reasonably competent geeks just never get deep into networking, and VPNs can be overwhelming. It doesn't really help that for a long time it was all IPSec which basically you need to learn voodoo to manage. Thankfully we have much better tools now, but it's still just a tech layer that many people don't touch frequently.

[–] Shadow@lemmy.ca 2 points 2 years ago* (last edited 2 years ago) (1 children)

The tailscale client should have created an interface, but I've never used it on a box also running wg. You don't have a tailscale specific interface in ip addr show at all? That's.... odd.

Do you have a device at /dev/net/tun?

[–] Shadow@lemmy.ca 2 points 2 years ago (3 children)

How do I do this?

Run ip route show table all

I would expect to see a line like:

192.168.178.0/24 dev tailscale0 table 52

Out of curiosity on a remote node do tcpdump -i tailscale0 -n icmp and then do a ping from the other side, does tcpdump see the icmp packets come in?

[–] Shadow@lemmy.ca 2 points 2 years ago* (last edited 2 years ago) (5 children)

Relay "ams" means you're using tailscales DERP node in amsterdam, this is expected if you don't have direct connectivity through your firewall. Since you opened the ports that's unusual and worth looking into, but I'd worry about that after you get basic connectivity.

So to confirm your behavior, you can tailscale ping each other fine and tailscale ping to the internal network. You cannot however ping from the OS to the remote internal network?

Have you checked your routing tables to make sure the tailscale client added the route properly?

Also have you checked your firewall rules? If you're using ipfw or something, try just turning off iptables briefly and see if that lets you ping through.

view more: ‹ prev next ›