I think you choose a poor example.

When I say long name I wasn’t implying meaningless ones.

Sooo, that example wasn’t exactly “contrived” - it’s based on a standard I see where I work.

DB - it's a database!
DW - and a data warehouse at that!
ORCL - It's an Oracle database!
HHI - Application or team using / managing this database
P - Production (T for Test - love the 1 char difference between names!)
01 - There may be more than one.

This is more what I’m arguing against - embedding meta-data about the thing into its name. Especially when all of that information is available in AWS metadata.

[Site][service][Rack] makes sense for on-premise stuff - no argument there.

I’m just saying long names dont have to be obtuse or confusing.

Agree

In a business with tens of thousands of servers, it makes sense to have long complicated names.

I’m actually not convinced of this approach. It’s one of those things that makes perfect logical sense when you say it - but in practice “DBDWWHORCLHHIP01” is just as meaningless as “Hercules”. And it’s a lot more difficult to say, remember and differentiate from “DBDWWHORCLHHID01”. You may as well just use UUIDs at that point.

Humans are really good at associating names with things. It’s why people have names. We don’t call people “AMCAM601W” for a reason. Even in conversations you don’t rattle off the long initialism names of systems - you say “The <product> database”.

God I hate the “stuff as much information into a server name as you can with no separators in all caps” naming conventions…

I get that - it’s difficult to see the point in it until you’ve gone along without it. Especially as a beginner since you don’t have a strong sense of what problems you will encounter and how these tools solve those problems.

At some point the learning curve for IaaC becomes worth the investment. I actually pushed off learning k8s myself for some time because it was “too complicated” and docker-compose worked just fine for me. And now that I’ve spent time learning it I converted over very quickly and wouldn’t go back… It’s much easier to maintain, monitor and setup new services now.

Depending on your environment something like Ansible might be a good place to start. You can begin even with just a simple playbook that does an “apt update && apt upgrade” on all your systems. And then start using it to push out standard configurations, install software, create users, etc. The benefit pays off in time. For example - recently (yesterday) I was able to install Apache Alloy on a half-dozen systems trivially because I have a set of Ansible scripts that manage my systems. Literally took 10 mins. All servers have the app installed, running, and using the same configuration. And I can modify that configuration across all those systems just as easily. It’s very powerful and reduces “drift” where some systems are configured incorrectly and over time you forget “which one the correct one?” For me the “correct one” is the one in source control.

The fun thing about infrastructure as code is that the terraform, ansible and k8s manifests are documentation.

I only really need to document some bootstrap things in case of emergency and maybe some “architectural” things. I use joplin for that (and many other things).

Y’all are assuming the security issue is something exploitable without authentication or has something to do with auth.

But it it could be a supply chain issue which a VPN won’t protect you from.

After years of running a rolling distro (gentoo) I had come to realize that it was a bit of a distinction without a difference. Major updates simply felt less planned than a ‘traditional’ distro.

You still get “major releases” with rolling distros. They’re just smaller. Updating to new plasma/gnome versions, new glibc, etc.

Terraform, ansible and kubernetes (microk8s).

K8s in particular has been a huge change to simplifying my network despite the complexities involved and the initial learning curve. Deploying and updating services is much easier now.

So going back to the title, what to study? Maybe some specific book? Private classes/courses?

Networking. If you want to understand the reasoning behind things this is where you start. A good foundation in tcp/ip, the 7 layer network stack, as well as basic network protocols (dns, dhcp, http, etc.) will go a long way toward helping you troubleshoot when things go wrong.

Maybe throw in some operating systems study as well for when you start to use docker.

You’re talking a lot of storage - it might be worth investing in some low-end server hardware. A Dell tower or something, maybe one off eBay if you’re looking to cut costs.

I picked up a PowerEdge T110II a long time ago and it’s been… flawless. Just a simple server with a 4x4TB RAID5. No hardware problems (aside from occasional disk failures over the years), easy to manage. It costs a bit more - but server hardware is often just more reliable and for a NAS that’s job #1. This server just runs.

I just upgraded the memory in it to 32GB for ~$100USD. Before that it had 8GB. I needed more for restic doing backups. I probably could have gotten away with 16GB but I figured I’d max it out for that price.

Wow, this question takes me back to like the 00’s when laptops had battery life measured in minutes.

How about “no”.

I love how you came up with a completely different scenario to answer “yes” to .

Doubt

You willing to go to jail then? Or just asking others to do so?

When you open and read files from a program the OS (kernel) will typically cache part or all of those files in memory. This is to speed up subsequent reads of that file since disk access is slow.

“preload” seems to be making use of that feature.

The kernel maintains this cache and evicts (unloads) things from it as needed. You don’t need to worry about it.

Gonna make provisioning servers a lot more interesting…

Man, what’s up with Linux filesystem developers?

Compared to checks notes reinstalling an entirely different distro???

Jesus the cli phobia here is ridiculous.