Fair enough. I guess I’m not saying “there’s no point in --” because I know people do these things. (Man, I wish I had the attention span to read as much as you.) I’m just saying I’m not going to host something just to keep track with no recommendations or interaction because that doesn’t click for me personally.

Same. I don’t really see the point of tracking what you read if you’re not interested in connecting it to other peoples’ readings. Storygraph has been great.

So in the, let’s say, top one-third tier of the options, something like this: https://www.amazon.com/Beelink-SER5-Mini-PC-Desktop-Computer/dp/B0C286SR8V/ref=pd_ci_mcx_pspc_dp_d_2_i_1?pd_rd_i=B0C286SR8V

Or, similarly, this, which is my current mediaserver: https://www.amazon.com/gp/product/B0C1X191NR/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1

I went with the second one–more ram. Anecdotally, some people think beelink is more reliable but this is not a universal opinion, and my experience has been that the minisforum is extremely reliable.

If you search similar you can find options both up and down depending on your actual budget. You probably don’t want to do components on these things, apart from maybe putting in a bigger m.2 nvme.

Seriously, is there anything about this character that is a “monster”? This is literally just a person in tight clothing

Well people use ansible for a wide variety of things so there’s no straightforward answer. It’s a Python program, it can in theory do anything, and you’ll find people trying to do anything with it. That said, some common ways to replace it include

• you need terraform or pulumi or something for provisioning infrastructure anyway, so a ton of stuff can be done that way instead of using ansible. Infra tools aren’t really the same thing, but there are definitely a few neat tricks you can do with them that might save you from reaching for ansible.
• Kubernetes + helm is a big bear to wrestle, but if your company is also a big bear, it’s worth doing. K8s will also solve a lot of the same problems as ansible in a more maintainable way.
• Containerization of components is great even if you don’t use kubernetes.
• if you’re working at the VM level instead of the container level, cloud-init can allow you to take your generic multipurpose image and make it configure itself into whatever you need at boot. Teams sometimes use ansible in the cloud-init architecture, but it’s usually doing only a tiny amount of localhost work and no dynamic invetory in that role, so it’s a lot nicer there.
• maybe just write a Python program or even a shell script? If your team has development skills at all, a simple bespoke tool to solve a specific problem can be way nicer.

Really all of these have solutions, but they’re constantly biting you and slowing down development and requiring people to be constantly trained on the gotchas. So it’s not that you can’t make it work, it’s that the cost of keeping it working eats away at all the productive things you can be doing, and that problem accelerates.

The last bullet is perhaps unfair; any decent system would be a maintainable system, and any unmaintainable system becomes less maintainable the bigger your investment in it. Still, it’s why I urge teams to stop using it as soon as they can, because the problem only gets worse.

Sure, I mean, we could talk about

• dynamic inventory on AWS means the ansible interpreter will end up with three completely separate sets of hostnames for your architecture, not even including the actual DNS name. if you also need dynamic inventory on GCP, that’s three completely different sets of hostnames, i.e. they are derived from different properties of the instances than the AWS names.
• btw, those names are exposed to the ansible runtime graph via different names i.e. ansible_inventory vs some other thing, based on who even fuckin knows, but sometimes the way you access the name will completely change from one role to the next.
• ansible-vault’s semantics for when things can be decrypted and when they can’t leads to completely nonsense solutions like a yaml file with normal contents where individual strings are encrypted and base64-encoded inline within the yaml, and others are not. This syntax doesn’t work everywhere. The opaque contents of the encrypted strings can sometimes be treated as traversible yaml and sometimes cannot be.
• ansible uses the system python interpreter, so if you need it to do anything that uses a different Python interpreter (because that’s where your apps are installed), you have to force it to switch back and forth between interpreters. Also, the python setting in ansible is global to the interpreter meaning you could end up leaking the wrong interpreter into the role that follows the one you were trying to tweak, causing almost invisible problems.
• ansible output and error reporting is just a goddamn mess. I mean look at this shit. Care to guess which one of those gives you a stream which is parseable as json? Just kidding, none of them do, because ansible always prefixes each line.
• tags are a joke. do you want to run just part of a playbook? --start-at. But oops, because not every single task in your playbook is idempotent, that will not work, ever, because something was supposed to happen earlier on that didn’t. So if you start at a particular tag, or run only the tasks that have a particular tag, your playbook will fail. Or worse, it will work, but it will work completely differently than in production because of some value that leaked into the role you were skipping into.
• Last but not least, using ansible in production means your engineers will keep building onto it, making it more and more complex, “just one more task bro”. The bigger it gets, the more fragile it gets, and the more all of these problems rears its head.

Heh. I am, as I said, a cloud sw eng, which is why I would never touch any solution that mentioned ansible, outside of the work I am required to do professionally. Too many scars. It’s like owning a pet raccoon, you can maybe get it to do clever things if you give it enough treats, but it will eventually kill your dog.

deleted by creator

I can answer this one, but mainly only in reference to the other popular solutions:

• nginx. Solid, reliable, uncomplicated, but. Reverse proxy semantics have a weird dependency on manually setting up a dns resolver (why??) and you have to restart the instance if your upstream gets replaced.
• traefik. I am literally a cloud software engineer, I’ve been doing Linux networking since 1994 and I’ve made 3 separate attempts to configure traefik to work according to its promises. It has never worked correctly. Traefik’s main selling point to me is its automatic docker proxying via labels, but this doesn’t even help you if you also have multiple VMs. Basically a non-starter due to poor docs and complexity.
• caddy. Solid, reliable, uncomplicated. It will do acme cert provisioning out of the box for you if you want (I don’t use that feature because I have a wildcard cert, but it seems nice). Also doesn’t suffer from the problems I’ve listed above.

deleted by creator

Does that make it not a substantive complaint about nextcloud, if it can’t run well in docker?

I have a dozen apps all running perfectly happy in Docker, i don’t see why Nextcloud should get a pass for this

There are actually technical requirements for HIPAA compliance (HITRUST or HITECH, or maybe both, idr any more). Essentially no HPI (healthcare information about an individual), unencrypted, in transit, ever. Also, not unencrypted on disk, ever. The idea is that if your network security slips and someone manages to place a traffic snoop somewhere, they still can’t listen in.

It’s almost never a requirement (and very rarely implemented) in mid- to low-risk security situations, and even for HIPAA entitties, encryption in transit is usually implemented with an encrypted layer 3 of some kind. But I could see a fairly simple high-risk app needing the network to contain nothing in plaintext.

Unless you’re Jason Bourne, I doubt you need it for your homelab.

While that’s true, op has rightly raised the issue of photos, videos and documents meaning things that were created by them and uniquely meaningful to the family. If those only exist within the self hosting Rube Goldberg machine, they’re not coming back out without careful documentation.

I would also add anything created by me, so art, my personal writing and drafts, software I haven’t released yet, and so on.

deleted by creator

Personally I try not to attach my real name or picture to anything that isn’t related to a job interview or my current employment. I’m planning to buy my realname domain, because I know it’s free and it probably always will be. The only thing that I’ll use it for is professional email, as I slowly phase out google.

I have a handful of other domains for fun stuff, which reveal nothing about me.

Mine is running on one of these https://www.amazon.com/dp/B0BYZC4SMW which exceeds your specs by quite a bit. They have substantially cheaper models closer to your range, I’ll bet you can find something.

I haven’t had mine for very long but so far it’s been A+.

deleted by creator

I just picked up one of these since I had the change: https://www.amazon.com/gp/product/B0C1X191NR

Plus a 4TB samsung external drive. Should be awesome, and fits anywhere in my house.

Seconded that used minis ought to be quite reasonable and fast if this seems like too much. (Although you can also get a similar new one for half this, if you cut down on disk and ram.)

Oof. Devs, don’t talk to customers or users like this. Ever. You have no idea what’s actually going on at the other end of the conversation. “Sorry we couldn’t help you,” is all this person needed to say, but now a whole bunch of people are going to stay the hell away from OST paid subs.