NaibofTabr

VPNs as a technology might not be illegal but circumventing the firewall certainly is.

Unless you are very vocal and high profile person no one will black bag you in a country of billion people, lol.

This is a bit of a misunderstanding about how things work in an authoritarian system. Sure, you might fly under the radar for awhile, but if you call attention to yourself (say, by getting caught trying to bypass the government firewall) and you are not high-profile, then it is very low-effort to make you disappear. Few will notice, and those that do will stay silent out of fear.

If you are more high-profile you still get black-bagged, you just get released after, with your behavior suitably modified.

Naomi Wu no longer uploads to YouTube.

Depends - how many family members do you have that the PRC might use against you? or who would miss you if the PRC black bagged you?

And there are hundreds if not thousands of them, plus a lot of automated tooling.

Beyond your eventual technical solution, keep this in mind: untested backups don’t exist.

I recommend reading some documentation about industry-leading solutions like Veeam… you won’t be able to reproduce all of the enterprise-level functionality, at least not without spending a lot of money, but you can try to reproduce the basic practices of good backup systems.

Whatever system you implement, draft a testing plan. A simpler backup solution that you can test and validate will be worth more than something complex and highly detailed.

I mean… exposed to each other, sure, but they’re all exposed to Syncthing and the public relays.

It is a fantastic idea to start your home server project on some e-waste hardware, and use it until you know specifically what features you’re lacking that you would need better hardware for.

Er, wait, are you using Syncthing for its intended purpose of syncing files across devices on your local network? And then exposing that infrastructure to the internet? Or are you isolating Syncthing instances?

The issue is more that trying to upgrade everything at the same time is a recipe for disaster and a troubleshooting nightmare. Once you have a few interdependent services/VMs/containers/environments/hosts running, what you want to do is upgrade them separately, one at a time, then restart that service and anything that connects to it and make sure everything still works, then move on to updating the next thing.

If you do this shotgun approach for the sake of expediency, what happens is something halfway through the stack of upgrades breaks connectivity with something else, and then you have to go digging through the logs trying to figure out which piece needs a rollback.

Even more fun if two things in the same environment have conflicting dependencies, and one of them upgrades and installs its new dependency version and breaks whatever manual fix you did to get them to play nice together before, and good luck remembering what you did to fix it in that one environment six months ago.

It’s not FUD, it’s experience.

This is also a great way to just break everything you’ve set up.

I recommend getting familiar with SMART and understanding what the various attributes mean and how they affect a drive’s performance and reliability. You may need to install smartmontools to interact with SMART, though some Linux distributions include this by default.

Some problems reported by SMART are not a big deal at low rates (like Soft Read Errors) but enterprise organizations will replace them anyway. Sometimes drives are simply replaced at a certain number of Power-On Hours, regardless of condition. Some problems are survivable if they’re static, like Uncorrectable Sector Count - every drive has some overhead of extra sectors for internal redundancy, so one bad sector isn’t a big deal , but if the number is increasing over time then you have a problem and should replace the drive immediately.

Also keep in mind, hard drives are consumables. Mirroring and failovers are a must if your data is important. New drives fail too. There’s nothing wrong with buying used if you’re comfortable with drive’s condition.

Yeah, pay somebody else to be responsible for the server uptime and the bandwidth. Somebody who specializes in providing that.

I think the answer depends a lot on the use case of each business’s website and what the business owner/employees expect from it.

Is the website a storefront? You’ll be spending a lot of time maintaining integration with payment networks and ensuring that the transaction process is secure and can’t be exploited to create fake invoices or spammed with fake orders. Also probably maintaining a database of customer orders with names, emails, physical addresses, credit card info, and payment and order fulfillment records… so now you have to worry about handling and storing PII, maybe PCI DSS compliance, and you’ll end up performing some accounting tasks as well due to controlling the payment processing. HIPAA compliance too if it’s something medical like a small doctor’s office, therapist, dialysis clinic, outpatient care - basically anything that might be billable to health insurance.

Does the business have a private email server? You’ll be spending a lot of time maintaining spam filters and block lists and ensuring that their email server has a good reputation with the major email service providers.

Do the employees need user logins so that they can add or edit content on the website or perform other business tasks? Now you’re not just a web host, you’re also a sysadmin for a small enterprise which means you’ll be handling common end-user support tasks like password resets. Have fun with that.

Do they regularly upload new content? (e.g. product photos and descriptions, customer testimonies, demo videos) Now you’re a database admin too.

Does the website allow the business’s customers to upload information? (comments/reviews/pictures/etc, e.g. is it Web 2.0 in some way) god help you.

You’re going to expose this to the public internet. It will be crawled, and its content scraped by various bots. At some point, someone will try to install a cryptominer on it. Someone will try to use it as a C2 server. Someone will notice that you’re running multiple sites/services from one infrastructure stack and attempt to punch their way out of the webhost VM and into the main server just to poke around and see what else you’ve got there. Someone will install mirai and try to make it part of a DDOS service provider’s network.

yet

Ah, if all of your email aliases trace back to your personal, locally hosted server, of which you are the only user, on presumably your personally owned domain, it will not be private… well private in the sense that it’s just you I guess… but super duper identifiable - because it’s just you. At which point why bother with the aliases.

Hahhh… well really, the only way to test backups is to try to restore from them. VMs are extremely helpful for this - you can try to restore a VM mirror of your production system, see if it works as expected, wipe it and start over if it doesn’t.

I second this - virtualization is the easiest way to branch out and try new things. You can keep the working system you already have, and also experiment with other systems.

A further advantage is that you can run services in separate VMs, which helps if you need isolated contexts for security, privacy, or stability reasons. And, if you break something while you’re learning you can just delete that VM and start over without affecting your other working services.

• a few git repos (pushed and backup in the important stuff) with all docker compose, keys and such (the 5%)

Um, maybe I’m misunderstanding, but you’re storing keys in git repositories which are where…?

And remember, if you haven’t tested your backups then you don’t have backups!

You will own nothing and like it have no recourse.

And even if the cooperation doesn’t last, it’s an opportunity for the open source developers to work with the product engineers and get direct information from them right now. There’s nothing as valuable as talking to the guy that actually designed the thing, or the guy who can make changes to the product code.

Even if that relationship doesn’t hold long term, the information gathered in the short term will be useful.

If I were part of this project this is what I’d be going for. Push the company to give you direct contact with the relevant engineers, right now while the negative public opinion is fresh and they’re most willing to make concessions, and then get as much out of that contact as you can. Take them at their word, make them actually back it up, take advantage of the offer to cooperate. Sort the rest of it out later.

Yes, it is damage control. That’s OK.

The whole point of spreading the word about an incident like this is to get public attention on it, and make the company realize that the way they’ve handled things was bad.

A letter like this indicates that they’ve realized they fucked up and they want to do things differently going forward. That doesn’t mean they’re suddenly trustworthy, but it does mean they can be negotiated with.

The correct response is to accept the offer of working together. We want to encourage companies to be cooperative and discourage insular, proprietary behavior. If you slap away the offered hand then you discourage future cooperation, and now you’re the roadblock to developing an open system.

When you start getting the results that you want, don’t respond with further hostility.