Me running everything on a single postgress instance on my shitbox 0€/month
Technology
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
I also self host and I wouldn't say the cost is zero. In the UK, energy costs alone mean that a 40W computer cost £8 per month to run (assuming a 28p/kWh price).
Of course, that's assuming you run it 24/7 at full energy use, but I know my PCs run on more than that.
I'm in the US and when I tried migrating from DO to Hetzner, I got asked to upload my passport to prove I'm not spam or something. Same experience with OVH.
Is this a thing for all European hosting companies? I ended up finding some Canadian hosting that would just let me sign up and pay like normal.
Lots of respectable EU hosting companies, and also aparently OVH, if they think there's a chance you're taking the piss will ask for a ID so they can ban you. It's not just anti-spam, it's anti-abuse and for preventing non-payment. They think there was a risk involved in accepting your business (whatever that may be, obviously companies don't dilvulge their criteria here), and if you go elsewhere they're not upset about it for that reason.
Good. I'm sick of all those ddos attack and bot attacks from other cloud provides like alibaba etc.
I never had that kind of experience with Hetzner or OVH as a European. I suppose there are extra hoops to jump through for US customers for some reason?
I’m European and had to do the same, so it’s based on something else.
I don't like uploading IDs. But recently I block almost all datacenters across the world due to ddos attack or other malicious attacks on my websites. So I don't think it's a bad idea to keep the web better. It's a mess today due to all those cheap cloud providers
When I signed up at Hetzner, I had to go through the same anti-abuse check. However I could choose to not upload my ID and pre-pay 20€ instead. Did that and have been a happy customer since.
Is this a thing for all European hosting companies?
Absolutely not. At least not in Europe.
Have you tried netcup as well?
Let's see! 🤞
Your order will be checked by one of our employees shortly. You will then receive further information on the status of your order by e-mail.
Ok so if I'm reading this correctly: They migrated from an OS and MySQL version receiving no updates since at least 2 years to MySQL 8.0 which will stop getting updates in 4 days. Also every service is running without any containerization and there is a single database for everything... and it all runs on a single host and I didn't read one word about a backup strategy or disk encryption. Also not a single word about infrastructure as code like ansible so that you can reliably recreate the system... and The whole stuff is hosted in Germany for a Turkish software company - sounds like very good latency.
My personal conclusion: This system WILL fail and the guy who designed it is stuck somewhere 10-20 years in the past.
Sounds like my homelab has better redundancy than these guys, and my monthly bill isn't much different than their new one. I only pay for power and networking, since I own my own hardware. I'm colocating in my city, so my latency to home is about 1ms, and I've got a full mirrored server in my house. Certain files are further backed up elsewhere for proper 3-2-1 backup (+ each server running raidz2 with disk encryption). Even if my home Internet goes out, I still have full access to my files at home, and all my public services stay running in the data center. If either server fails, it's all set up with containers so it's easy to spin up each service somewhere else.
One thing that's tricky to get right with disk encryption (especially with encrypted /boot) is having a redundant boot partition. I was able to hack this together by having sofware raid duplicate my boot partition to a second drive. Now if I remove either OS boot drive it falls back to the remaining one. To prevent breaking EFI boot, you need to use the Version 1 RAID format so the metadata is stored at the end of the partition, not the front where EFI reads.
every service is running without any containerization and there is a single database for everything... and it all runs on a single host and I didn't read one word about a backup strategy or disk encryption.
Man, a paragraph that can give someone some serious PTSD flashbacks....
The number of times I've had to clean up a customer's environment after they let little Billy play corporate IT and things went boom.....
the guy who designed it is stuck somewhere 10-20 years in the past.
Well, using containerization for everything is very 2015-ish.
Seems like it would have been a good moment to split the database from the many web servers and reduce the single point of failure.
And get some replication in there. Even if there's not a single point of failure, if a DB instance ever goes tits-up, you'd better have a standby.
Source: I've cleaned up others' messes where they didn't.
Not a sysadmin but just an hobbyist: is it ok to have such a large install bare metal and not containerized?
For example the issue of MySQL 5 being unavailable would be a non-issue with a container
Yes it’s ok, in general. It’s not the most modern or efficient way of managing infrastructure but it’s worked for decades now. It all depends on what you’re hosting, for who, and for how many people.
If you’re hosting internal company infrastructure for a relatively static number of users in a single of set few regions to deliver to, bare metal monolithic stuff is absolutely fine. It’s when you’re an app or service company and your infrastructure is for the back end for a public service that needs to be able to scale dynamically, and you’re worried about high 24/7 uptime, and latency to end users is a global issue that things like microservice architecture, containerization, and iac starts becoming important.
The whole containerization crazy is important for microservices architecture where you split your app into different pieces. This lets you scale different parts of you app as needed, it prevents your entire app from failing just because one part of it failed, it allows for lifecycle management like blue/green deployments with no downtime, allows developers to work on different parts of the app and update at a faster cadence than one big release for the entire thing every time you update one small part of it, things like that.
Don't quote me, but as far as I know containers can't fix the issue if the host kernel is too old.
For example the issue of MySQL 5 being unavailable would be a non-issue with a container
So people careless enough to "just container it" for old, possibly security-compromised software - you call that a "non-issue"? How about upgrading and configuring for compatibility?
They're the ones running a 10 years old database on a 11 years old os in a public facing server "because it just works", not me
If it was a container, they could just tag a new version when the database went EOL 5 years ago, without being locked on what the package manager was offering
Because they used MySQL 5 on CentOS 7 from the package manager and couldn't easily upgrade
Totally fine. Containerization comes at a cost too. It's a matter of system design, knowing your risks and complexities, and handling them accordingly.
With such a size, before containerization I'm wondering if these services are not independent enough to split them onto multiple servers.
Having everything together reduce system complexities in some ways, but not in other ways.
you can just set up containers on your bare metal server. in fact if you're going to install insecure services you definitely want to containerize them, though tbh you need to run really far away from whatever it is you're doing that requires sql5, or at least don't let it be reachable on the internet, that should be network-isolated, which really limits its utility.
in fact if you're going to install insecure services you definitely want to containerize them,
While this is true, if you're running a platform that is root by default (looking at you, docker), you're not shielding yourself as much as you might think you are.
If you're running an insecure app as root, you better hope they don't also have an exploit to get out of the container after the app is popped, otherwise you're fucked.
Always nice to see people moving away from enshittified US services.
Wait until you learn that Hetzner can and will take your public IP away at their own will without any warning. Happened to me.
One downtime is enough for me to never use that service again, no matter how cheap it is.
Do tell
Copy Paste since I am lazy:
“ They suspected me of serving “illegal” traffic. The server was located in Germany and they were contacted by typical DMCA lawyers, who were referencing a US District Court Order.
Hetzner blindly waved that through and just took my public IPv4 address.
At no point they were trying to contact me. At no point they asked themselves if a US District Court Order has any validity. At no point anyone of Hetzner explained what happened. At no point they apologized for their obvious mistake.”
Interesting, why did it happen?
They suspected me of serving “illegal” traffic. The server was located in Germany and they were contacted by typical DMCA lawyers, who were referencing a US District Court Order.
Hetzner blindly waved that through and just took my public IPv4 address.
At no point they were trying to contact me. At no point they asked themselves if a US District Court Order has any validity. At no point anyone of Hetzner explained what happened. At no point they apologized for their obvious mistake.
Once the dump was complete, we transferred it to the new server using rsync over SSH. With 248 GB of compressed chunks, this was significantly faster than any other transfer method:
rsync -avz --progress /root/mydumper_backup/ root@NEW_SERVER:/root/mydumper_backup/
that's a bit weird. rsync -z is compression, but they did compress in the mydumper export already, so this is a slow down (or neutral at best). also in my experience rsync is as fast as scp is as fast as piping anything to the tcp port on the destination etc. rsync does not win for speed but for enabling resume so to say...
besides this: nice read!
Really good blogpost, as a sysadmin, this is a great way to handle a migration with zero downtime.
When I was migrating my servers to NixOS I did the same thing, I tried to make my configuration the same as the old OS so everything works cleanly, and it worked fine, but since it was all in the same server, I had to do manual migration for things like files and databases.
what it feels like charging my phone from my laptop