chiisana

If you invite them to your “plex home”, they won’t need Plexpass to get the benefits on your Plex server, they also don’t need to pay to unlock the mobile apps.

This is pretty standard for enterprise equipments — comes with some amount of years of warranty, enterprises depreciate the cost over that many years and sell them as/before the warranty expires to get whatever value they can get (as far as books concerned, they’re already depreciated to $0 anyway).

Backblaze has drives with very similar models in service, has an annualized failure rate of less than 1% on average, and have been in service for 5 years. The average age will continue to rise as usage time continues to rack up.

There were some older language taken out of context, and they’ve since removed the wording after things blew up. Some people who knee jerk reacted will continue to hold their initial reaction and never change their opinion, others will take ages to convince otherwise.

Approx 35k power on hours. Tested with 0 errors, 0 bad sectors, 0 defects. SMART details intact.

That’s about 4 years of power on time. Considering they’re enterprise grade equipment, they should still be good for many years to come, but it is worth taking into consideration.

I’ve bought from these guys before, packaging was super professional. Card board box with special designed drive holders made of foam; each drive is also individually packed with anti-static bags and silica packs.

Highly recommend.

I don’t use NPM but if “Cache Assets” means what it means in the traditional sense, it wouldn’t affect most home deployments.

Historically, resources are limited and getting Apache to load images/javascript/CSS files from disk each time they’re requested, even if the OS kernel eventually caches them to RAM, was a resources intensive process. Reverse proxies stepped up and identifies assets (images, JS and CSS), and stores them in memory for subsequent requests. This reduces the load on the Apache web server and reduces the hops required to serve the request. Thereby making everything faster.

For homelabs, and single user systems, this is essentially irrelevant, as you’re not going to be putting so much load on the back end system to notice the difference. May be good to still turn it on, but if you’re noticing odd behaviors (ie updates to CSS or images not taking), it may be a good idea to turn it off to see if that’s the culprit.

Filled it!

I understand your experiment is already under way, so it is unlikely that you’d be able to change your methodologies at this point. One small feedback on the questions, however. As presented (to me, maybe the system is randomized, I don’t know) the questions felt leaning towards difficult/complex to use, which may lead the user skewing their responses negatively. While this may be counterweighted by the fact that you’re asking a niche community using these systems already to complete the survey, it may still be a good idea to ask more neutral questions and allowing the users to select from a spectrum instead.

For example; instead of “I find the system unnecessarily complex; Strongly Disagree… Strongly Agree”, it may potentially be better to ask “How do you find the system? Very Straightforward … Very Complex”. Your score for each of the selection would be consistent (1 is less complex while 5 is more complex), but you’re not impressing a negative sentiment on the user.

Anyway, good luck with your study! Looking forward to your published results!

Docker inside LXC adds not only the overhead they’d individually add — probably not significant enough for it to matter in a homelab setting — but with it also the added layer of complexity that you’re going to hit when it comes to debugging anything. You’re much better off dropping docker in a full fledged VM instead of running it inside LXC. With a full VM, if nothing else, you can allow the virtual networking to be treated as it’s own separate device on your network, which should reduce a layer of complexity in the problem you’re trying to solve.

As for your original problem… it sounds like you’re not exposing the docker container layer’s network to your host. Without knowing exactly how you’re launching them (beyond the quirky docker inside LXC setup), it is hard to say where the issue may be. If you’re using compose, try setting the network to external, or bridge, and see if you can expose the service’s port that way. Once you’ve got the port exposure thing figured out, you’re probably better off unexposing the service, setup a proper reverse proxy, and wiring the service to go through your reverse proxy instead.

No problem! It’s a small change that might not affect most people :)

The documentation seems to suggest just IP address and CIDR notation.

NextCloud’s trusted_proxies setting supports CIDR notation, so it mught be better to set the subnet of Traefik’s network as opposed to the IP address. That way, if you ever need to do anything with the container (I.e. upgrade traefik), the IP can change but the subnet is less likely to change.

It may not affect this current use case for a home media server, but people should still be aware of it so as they learn and grow, they don’t paint themselves in a corner by knowing only the anti patterns as the path forward.