A hybrid is probably a good way forward. I had a career as a photographer for a while and I learned from that: going through 1000 photos takes very little time, but going through 10,000 takes an eternity. If you can star or mark your obviously important photos as you go along, it’ll take very little to print them at the end of the year.
This was a recent point of discussion on the 2.5 Admins podcast (https://2.5admins.com/2-5-admins-228/). Some good discussion on there.
My own thought is the best way to handle your family-member-finding-your-old-photos problem is the analog way: make some prints. It’s absolutely idiot proof, the methodology of keeping paper goods is well understood, and the technology is platform independent.
I do this with HAProxy and keepalived. My dns servers resolve my domains to a single virtual ip that keepalived manages. If one HAProxy node goes down, the other picks right up.
And this is one of the few things I’ve got setup with ansible, so deploying and making changes is pretty easy.
I can’t think of anything that specifically uses ssh, but Syncthing would do this, though for passwords I’m more inclined towards bitwarden.
With this concept in mind, I recently put together a VDI setup for a person who’s in one location for half of the year and another the other half. The idea is he’ll have a thin client at each location and connect to the same session wherever he is.
I’m doing this via a VM on Proxmox and SPICE. Maybe there’s some idea in there you could use.
In that case, I’m sure you’ll enjoy it. I’ve been reading a little bit before I go to bed and learning a lot that I glossed over when I set up my own mail server years ago. He and Alan Jude wrote some ZFS books as well that I keep coming back to and picking up new tricks each time.
I get pretty much anything Michael Lucas writes. The information is always great and his writing style is fun to read.
Important to note: it’s not a step-by-step guide to copy and paste and have a mail server running. It’s all about understand all the stuff that goes into it.
Take this with a grain of salt, the more I re-read, the more I realize I’m making assumptions about your setup that may or may not be true. First, I’m making an assumption that you’re doing ACLs for samba shares (and I know that system better on FreeBSD than Linux). I’m also assuming based on your description you want everyone to have access, but not write access.
I think you could do an officewide group with read-only permissions on all of the shares and then set the unix group to the department.
So, for your HR team you’d do chgrp -R hr /path/to/parent/shares/hr and setfacl -m d:g:rwx /path/to/parent/shares/hr and add the officewide group’s read-only perms: setfacl -m d:g:officewide:rx /path/to/parent/shares/hr. Rinse and repeat for each share.
Not sure if this is what you’re after, but maybe it’ll help lead in a good direction.
I’ve only ever tinkered with openmediavault, so I’m by no means an expert, but there is a ZFS plugin available. Here’s a forum post that may help: https://forum.openmediavault.org/index.php?thread/7633-howto-instal-zfs-plugin-use-zfs-on-omv/
That fruit argument is so that samba plays nicely with Apple’s SMB client implementation.
That will be totally doable, but there’s no one way to setup every service. Some you’ll install from the repository (like nginx or HAProxy or samba). Others you’d have to clone from git (like netbox or dokuwiki). Others have entirely different methods. So, unfortunately it’ll be a lot of reading the documentation.
In general, I prefer unprivileged LXC to a full VM unless there’s some specific requirement that countermands that preference (like running an appliance or a non-Linux OS).
What I tend to do is create a new container for each service (unless there’s a related stack). If the service runs on Docker, I’ll install that right inside the container and manage it with docker compose. By installing Docker directly from get.docker.com instead of the built in packages, it pretty much works all the time.
Since each service is in its own container, restoring backups is pretty service-specific. If you wanted some kind of central control plane for docker, you could check out swarm mode.
For me it’s the Mac Finder. It’s always running so (unless it crashes) there’s no delay in opening a file manager window and, more importantly, it has built in Quicklook and Miller columns. Haven’t managed to find a good-enough implementation of either of those in Linux, so I just work around it.
In my state (Vermont), the Secretary of State has an rss feed that basically presents the results as an xml file. I’m using that to make some local results spreadsheets. Could be other states have similar things.
I’m not familiar with the Ben Eater series, but there are certainly a couple options to check out.
Mark Ferneaux did a fantastic series on the workings of pfSense. It’s a little dated, but the core concepts are still sound and apply to networking generally.
There are also several sites that do in-depth networking topics with a focus on certifications. My favorite of the bunch is Viatto.
I also quite like The Network Berg, though his videos are specifically focused on Mikrotik.
Linux runs fine on Intel Macs. There are a couple peculiarities you’ll want to be aware of, though.
Other than those initial hiccups, everything works pretty flawlessly.
The thing that immediately came to mind was mailpiler.org. It’s been on my list to stand up for a while, but I’ve never got around to it.
Awesome. I’m glad it helps. I’d be a little weary of using the same directory in multiple containers. File systems may or may not behave well with multiple machines writing to them. Not saying anything bad will happen, but do keep an eye out for issues.
I’m making some assumptions, namely that you’re using an unprivileged LXC container and the mount point is a bind mount.
Unprivileged LXC shift user ID numbers so that an escape won’t result in root access to the host. The root user (uid 0) in the container is actually uid 100000 from the perspective of the Proxmox host.
What I usually do is set ownership of my bind mounts to that high-numbered ID (so something like chown -R 100000:100000 /path/to/bind/mount) from Proxmox. Then the root user in the container will be able to set whatever permissions you need directly.
I just had to do this. Don’t skip the release notes. They’re really good at highlighting potential pitfalls, just scroll back through and look for the heading “Breaking Changes.”
In my case there were a few, but they were only for API calls I’m not using, so I just did the update in one go and it worked out great. (Of course, I made sure to take a backup first.)