Live data from Hacker News

Reclaiming the lost art of Linux server administration

pietrorea.com

391–400 of 485 posts

Re: Reclaiming the lost art of Linux server administration

#391
post #274

Earlier quoted context omitted.

No but I founded and help run https://hashbang.sh where we give out free shell services and mentor people in security, privacy, and digital sovereignty.

curious that the souce metions MIT license at top but in the bottom it says "2. Don't use our resources for closed source projects"; was that intentional? my current understanding of MIT license is a "do anything, i don't care, just don't blame me". if i were you and wanted to use "dont use our resources" part, i would set it as AGPL or even SSPL if you are brave enough.

There's a difference between what you are allowed to do with the code, which is what the MIT license covers, and what you are allowed to do with a specific hosted platform on which the code is running, which is what that term is part of.

Re: Reclaiming the lost art of Linux server administration

#392

I used to reach for shell scripts to configure servers, then Puppet, then Salt, and then finally to Ansible. Configuring servers declaratively is such a massive improvement over shell scripts. The fact that Ansible is agentless is also very nice and works very well for when you only have a handful of servers. Only thing I dislike is YML, which I think is yucky!

YML is the exact reason I don't use Ansible anymore. Writing complex YML for simple tasks is a time burner.

After I discovered https://efs2.sh I switched over to this simple config management solution, which simply executes commands and scripts over ssh. It is so much simpler and faster (both in regards to creation and execution) than Ansible.

Re: Reclaiming the lost art of Linux server administration

#393
A proper engineer should learn some GNU/Linux server administration, if anything to understand all the artificial limitation that modern cloud services inflict to their customers.

Or the absurd prices for stuff that basically does not make sense.

Or for practices that would otherwise be absolutely unlawful but that people let be because cloud providers are just too big to fight.

Re: Reclaiming the lost art of Linux server administration

#394
post #61

I have over 20 years of Linux/FreeBSD sysadmin experience ranging from universities to major silicon valley companies in both cloud and on-prem. When it comes to companies I mostly support cloud these days but when it comes to me and my family I accept every downside and host as almost all of our digital lives in a 42u rack in a gutted closet in our house with static IPs and business fiber. I know where our data live…

Same here. There is, at least for me, one big serious downside: what happens when I die.

My wife is quite concerned about her being left with a web of home automation, hosted emails etc. I understand her and I am trying to find a way out.

My current idea is to document how to de-automatize the home and how to deal with emails and fiber access (the main things to worry about).

Any ideas are very much welcome

Re: Reclaiming the lost art of Linux server administration

#395
Reading the comments, they seem sadly fairly black and white.

Either you need to have pets on tin, or cattle via cloud, but that never was the case. I worked at a hosting company ~2007 whom was an early IaaS provider. We PXE booted xen nodes, that automatically connected to our management layer, allowing customers to provision virtual machines. Most of our own fleet would be cattle well before this was meme worthy.

Today, you could bootstrap a k8s cluster with almost no effort on tin. You'll quickly have autoscaling cattle and a distributed cron. Sure you'd probably pet etcd and maybe the API servers. Running a database, API, and small management layer is well within the responsibilities of a professional system administrator. If this is beyond your orgs / teams capabilities you probably should use the cloud provider.

P.S. Not having a team that can run production services without outsourcing the database is fine. We all have different specilisms.

The storage layer is a bit more complex if you want to roll PVC.

You shouldn't bootstrap a $1m team to defeat a $500k cloud bill.

Re: Reclaiming the lost art of Linux server administration

#396
I have a clear statement in my profile at linkedin: I am a Unix/Linux sysadmin, not a "DevOps" or a "Cloud/AWS/Azure engineer". I am only doing traditional Unix/Linux sysadmin stuff.

There is not a day going by where a recruiter doesn't tell me "we are urgently looking for an experienced Linux sysadmin. Are you interested?"

Re: Reclaiming the lost art of Linux server administration

#397
post #61

I have over 20 years of Linux/FreeBSD sysadmin experience ranging from universities to major silicon valley companies in both cloud and on-prem. When it comes to companies I mostly support cloud these days but when it comes to me and my family I accept every downside and host as almost all of our digital lives in a 42u rack in a gutted closet in our house with static IPs and business fiber. I know where our data live…

I self-host my stuff as well but with a 2012 Mac Mini running Proxmox. I use it as a means to learn sysadmin things. I get my static IP by using the smallest VPS from vultr with a wireguard tunnel forwarding http/s traffic to a docker container running nginx proxy manager. For those wanting to learn, I highly recommend joining r/homelab and r/selfhosted. Those communities have a lot in common and you can learn a lot.

Why not simply use DyDns to your local home server ?

Most modern routers have an option to integrate with dynamic dns providers.

Re: Reclaiming the lost art of Linux server administration

#398
My setup:

For business related services I use root servers hosted by e.g. Hetzner. I don't want to deal with hardware maintenance nor the 24/7 power bill.

For private stuff (pictures, videos, movies) I have a cheap old desktop machine at home with lots of storage running Ubuntu. Easy to administer, and I can switch it off if not needed. Data is mirrored and snapshotted.

For long-term backup I encrypt my data and upload it to Amazon Glacier Deep Archive (around 1$/TB!)

That said the cloud in general is great and you can do some things today for cheap that weren't possible for most companies 10 years ago. For some use cases it's the best choice.

In general a lot of workloads can be served orders of magnitudes cheaper than 10 years ago.

Re: Reclaiming the lost art of Linux server administration

#399
post #87

Earlier quoted context omitted.

I remember how surprised people were when I demoed a $200/month bare metal server outperforming by a huge margin RDS MySQL instance that they were paying something upwards of 16k/month. IIRC we ended up using it as a disposable replica for some non-real time but heavy operations.

Here's what the bare metal server didn't come with: API access for managing configuration, version updates/rollbacks, and ACL. A solution for unlimited scheduled snapshots without affecting performance. Close to immediate replacement of identical setup within seconds of failure. API-managed VPC/VPN built in. No underlying OS management. (Probably forgot a few...) I get that going bare metal is a good solution for som…

That should cost more but not 80x more.

Sure, you're paying the cost of some DBAs and SREs with that price. Still, seems too way above what it costs.

Re: Reclaiming the lost art of Linux server administration

#400
post #119
post #87

Earlier quoted context omitted.

I remember how surprised people were when I demoed a $200/month bare metal server outperforming by a huge margin RDS MySQL instance that they were paying something upwards of 16k/month. IIRC we ended up using it as a disposable replica for some non-real time but heavy operations.

It's 2022 and we're about to rediscover something we know for 40 years already: mainframes are freaking expensive.

It's 2022 and we're about to rediscover something we know for 40 years already: mainframes have freaking performance.
Post reply on HN