For learners who are helped by seeing someone think through a problem and explain why they made the choices they did it doesn’t get much better than YSAP. (Here’s the link: ysap.sh)

Not sure about a PDF, but he sells an epub that’s $15 US.

Michael Lucas released a stellar book on the subject not long ago (https://www.tiltedwindmillpress.com/product/ryoms/). It’s pretty thorough, relatively up-to-date, and (like all his stuff) a fun read. It does a great job of demystifying the mechanics. As far as the implementation goes, I’ll put in another vote for Mailcow, which combines all of the components into a very usable docker stack.

Very interesting idea. I’ve gotten into the habit of using something like /^-o to search for short flags.

I landed on KDE and I don’t worry about it matching my Mac desktop, though you certainly could. The thing I miss most is the Finder, oddly. There’s not much in Linux world that gives Miller columns, unfortunately.

I’ll mention that if you like your Mac keyboard, or just want to keep using the familiar shortcuts, check out Toshy. It remaps the keys so that command still does what you expect it to do.

Way to go!

Yes absolutely. I must’ve misinterpreted what you said. What did you mean by “not visible anymore over the network.”

I’ve only used dropbear on openwrt systems, but I’m pretty sure it doesn’t use the '/etc/ssh/sshd_configfile. The alpine wiki says the config file is at/etc/conf.d/dropbear`.

That bit about the pi not being visible in the network after reboot makes me wonder if this is more of a networking issue rather than an ssh one.

The pi zero is WiFi-only, right? Can you confirm that it’s getting on the WiFi network successfully? If so, maybe it’s getting a different IP than it initially did via DHCP.

I pretty much stick to straight bash and core utils, so it’s not much of a burden. Plus on the Linux side, I mostly stay with Debian and its derivatives, which limits some of the work.

But really I don’t consider every feature of my dot files to be a finished product. The core stuff is reliable, but if I catch a problem with anything more esoteric or if I see some functionality that looks interesting, it’s a brain teaser I get to tackle.

I do a git repo for my dot files with an installer that configures it based on whether I’m using Linux, macOS, or FreeBSD; a server or desktop; and whether I’m in bash or zsh. It also includes a bunch of functions and aliases that I find useful. It’s not always pretty because I also use it as a practical place to try new shell script bits when I have time. I’m hoping to change some things around soon thanks to some ideas from Dave Eddy’s bash course at ysap.sh.

Great idea; these are nice little machines. I have one running as part of a Proxmox cluster. I recall that there was some rigamarole to get it installed because of the T2 security chip that comes in that vintage of Mac. I’ll check my notes and see if I can find how I handled that.

Traefik is a very robust reverse proxy, but I think you have easier options. If you want to keep it all in the same stack, have a look at Caddy. The configuration is just a few lines. Another very good option since you’re already using pfSense would be to use the HAProxy plugin. You’ll get a UI to manage everything and Tom Lawrence has some very helpful videos about setting it up from start to finish.

It’s not exactly a single tool, but torsocks kind of enables doing what you’re describing. The syntax would be something like torsocks curl $url

1. This sounds like a weird one. It would be helpful to have some more info about your network. Would you share your PVE host’s /etc/network/interfaces file and the config file for the VMs (from /etc/pve/qemu-server)?
2. Excellent
3. I think ZFS would likely help since it can make use of block level snapshots. I think the way to move things over would be to create a ZFS datastore in Proxmox and then just migrate each VM’s disk.
4. Personally I think this is a bit simpler in an LXC container and there are a bunch of tutorials to help. These two are similar to my own setup:

• https://blog.bekh.fr/jellyfin-lxc-with-hardware-transcoding-igpu-passtrough/
• https://www.wundertech.net/installing-jellyfin-on-proxmox/

Hope some of that helps

Not sure if this is the kind of thing you’re after, but I think learning a little about the very fundamental pieces of these systems really helps to understand the mechanisms at work.

One place that was really useful to me was years ago, the Security Now podcast did a series called “How the Internet Works” ( I think). Steve Gibson went over all the principles layer by layer and it helped my understanding a ton. This was many years ago, so the rest of each episode is probably filled with really old security news, but the main bits are as relevant as ever.

Unbound can query the root dns servers, but it’s also commonly used as a recursive resolver, which just uses a server upstream, similar to systemd-resolved. I use unbound network-wide, but I have it querying 9.9.9.9 to take advantage of their filtering.

You may already have a local dns caching mechanism on your computer. I think by default Ubuntu uses systemd-resolved (it does on my desktops anyway). If you check dig it’ll show lookups coming from 127.0.0.53. With that in place, your local machine is caching lookup results and anything it doesn’t know, it’s forwarding to the network’s resolver (which it gets via dhcp, usually).

I’ve only ever tinkered with it slightly on a Proxmox host, but I ran it locally when I was testing it and it was glad to setup the VMs on the same system it was on.

You can definitely run VMs or containers on your desktop system and there are a lot of ways to do that (as others have said). If it’s the automated, reproducible setup you’re after (and you are purposely avoiding docker), give a look to terraform and ansible to create and provision your software.

I set up an old thin client with Debian and lxqt to connect to a VM on Proxmox. Got the idea from an Apalrd’s Adventures video about VDI. It worked pretty well on a decent network, but it really suffered on high latency networks.