Docker won’t make much sense if you don’t understand the underlying Linux systems and/or applications.

It’s similar with Wine and Bottles. If you don’t get what’s in the bottle, then running the bottle won’t make sense.

Find tasks that run on the native OS. learn to manage Linux itself. skip containers, Snap, virtual machines, etc.

try running a web server using httpd or something.

Why do tape drives seen to be best? What’s your use case? They’re still used in enterprise environments because they’re insanely dense compared to hard disks, and it’s real easy to load a truck with a few petabytes to ship elsewhere. Is that what you need? Density? Seems like not for just a few gigs.

If you want backups you need to ship your media, tapes or otherwise, off-site.

Pop your files into a cloud service and call it done. If you’re looking for long term archives and don’t want to use other people’s computers, burn some DVDs and store them at someone else’s house.

Devops will have more job openings, network will have a higher salary, especially as you become more senior.

Devops people who don’t know networking and/or general traditional sysadmin work are a crushing pain in the ass for those of us who have to support them though. Networking background will make you better at devops, but not necessarily vice versa.

no. Arp bridges layer 1 and 2. It’s switch local. With a VLAN, it becomes VLAN local, in the sense that 802.1q creates a “virtual” switch.

Broadcast traffic (such as DHCP) doesn’t cross subnets without a router configured to forward it. It’s one of the reasons subnets exist.

What in the world is “a proprietary OS I cannot trust”. What’s your actual threat model? Have you actually run any risk analyses or code audits against these OSes vs. (i assume) Linux to know for sure that you can trust any give FOSS OS? You do realize there’s still an OS on your dumb switch, right?

This is a silly reason to not learn to manage your networking hardware.

A VLAN is (theoretically) equivalent to a physically separated layer 2 domain. The only way for machines to communicate between vlans is via a gateway interface.

If you don’t trust the operating system, then you don’t trust that it won’t change it’s IP/subnet to just hop onto the other network. Or even send packets with the other network’s header and spoof packets onto the other subnets.

It’s trivially easy to malform broadcast traffic and hop subnets, or to use various arp table attacks to trick the switching device. If you need to segregate traffic, you need a VLAN.

Edit: Should probably note that simply VLAN tagging from the endpoints on a trunk port isn’t any better than subnetting, since an untrusted machine can just tag packets however it wants. You need to use an 802.1q aware switch and gateway to use VLANs effectively.

What you are asking will work. That’s the whole point of subnets. No you don’t need a VLAN to segregate traffic. It can be helpful for things like broadcast control.

However, you used the word “trust” which means that this is a security concern. If you are subnetting because of trust, then yes you absolutely do need to use VLANs.

WOL being unreliable is usually a question of hardware. If it works sometimes, then your configuration is probably correct and the issue les6s in your switching network, your NIC, or your motherboard.

A lot of switches suck. Start by validating that every single wakeup packet is getting from wakeup server to client while it’s awake, and make sure the payload is intact.

If you’re seeing occasional packet loss, modify your WOL script to spam several magic packets over a couple minutes. Won’t hurt devices that are already awake.

If you’re not getting packets lost, put another WOL device on the same port and see if it wakes up more reliably.

Why specifically an SSH app? Use SSH for shells. Use bitwarden for secrets. Use rsync (across ssh) for files.

In addition to other suggestions, the cards need to show what they’re alternative to without clicking.

ZFS dedup is memory constrained, and the memory use scales with the block hashes.

If performance isn’t a concern, you’re better off compressing your media. You’ll get similar storage efficiency with less crash consistency risk.

deleted by creator

deleted by creator

deleted by creator

deleted by creator

deleted by creator

The answer to your overarching question is not “common maintenance procedures”, but “change management processes”

When things change, things can break. Immutable OSes and declarative configuration notwithstanding.

OS and Configuration drift only actually matter if you’ve got a documented baseline. That’s what your declaratives can solve. However they don’t help when you’re tinkering in a home server and drifting your declaratives.

I’m pretty certain every service I want to run has a docker image already, so does it matter?

This right here is the attitude that’s going to undermine everything you’re asking. There’s nothing about containers that is inherently “safer” than running native OS packages or even building your own. Containerization is about scalability and repeatability, not availability or reliability. It’s still up to you to monitor changelogs and determine exactly what is going to break when you pull the latest docker image. That’s no different than a native package.

Depends on the specific Zigbee switch, but generally yes.

The magic is in the fact that you can decouple the relay, and use the switch as a sensor that triggers things that may or may not be related to the physical switch position.

The other reason I like it better than a typical “smart switch” is that I can use the shellys with whatever switch I want, so I can have it match my dumb switches and use different colors.

shelly relays will do exactly what you want. just wire them as disconnected switches. i do this to simulate 3-way switches, but it’ll work just as well to swap circuit behavior.

you can use a homeassistant action if you’re already using HA, or you can have the shellys call each others web api when it senses the switch.