Live data from Hacker News

Reclaiming the lost art of Linux server administration

pietrorea.com

221–230 of 485 posts

Re: Reclaiming the lost art of Linux server administration

#221

Blame the folks demonizing/shaming having "pet" servers and pushing immutable infrastructure. Linux server administration is quite enjoyable, and with how well apps these days can scale vertically, it really takes a special kind of workload to need (and actually saturate) fleets of servers.

This works fine from the perspective of the admin, but think from the perspective of a business owner hiring admins. What happens when you have employee turnover? You don't want all of the knowledge needed to deploy your critical IT infrastructure stored in one guy's head or personal notebook. Maybe your admins were all disciplined enough to make sure they never made a single change without documenting it and kept extremely detailed, easy to use runbooks, but maybe they didn't. You don't want to get Dennis Nedry'd.

Re: Reclaiming the lost art of Linux server administration

#222

Full disclaimer, I'm very much not a sysadmin or devops guy. However, every team I've been on recently has spent a lot of time struggling with gluing their AWS stuff together, diagnosing bugs etc. It didn't seem to save a heck of a lot of time at all. I couldn't figure out AWS. But I could figure out how to host sites on a linux VPS. So what's the story here - is serverless something that only makes sense at a certai…

Serverless was always around and always had a place. It used to be a shell and sftp account on a shared Linux server where you could upload your html and cgi scripts or php files into your own Apache virtual host and get billed per hit on your web site or bandwidth usage. It now just has a lot of tooling around it with a big learning curve and vendor lock in, but at least you get your hits and bandwidth for cheaper than you used to.

Re: Reclaiming the lost art of Linux server administration

#223
post #136

I know how to setup a basic VPS with firewalls, nginx, etc, but I'm scared to death to do that for a production environment available online.

It's harder if you didn't learn back in the 90s or early 2000s. Getting hit by a bad actor was considerably less likely so we were able to learn from our mistakes without a significant cost.

There's much less of a margin for error now.

Re: Reclaiming the lost art of Linux server administration

#224
post #47

Earlier quoted context omitted.

Hey, you actually have a few options, notably, doing nothing! Comcast doesn't actually change your public IP address between DHCP renewals and thus it's effectively static. The only time that it'll change is when the modem is powered off for an amount of time, or the upstream DOCSIS concentrator is powered off for maintenance or otherwise.

I would be more worried about violating the ISP's terms of service. Running a business based on that seems pretty precarious.

What’s the worst that can realistically happen?

Re: Reclaiming the lost art of Linux server administration

#225

Time is money, and the more time I spend on infrastructure, the less time I spend on product. And thus is born the incredible demand of infrastructure as a service. Thankfully one person's cloud is another person's on prem infrastructure so sysadmin skills will always be in demand. From my perspective in enterprise computing, I now see people taking 2 paths. One where they become super deep sysadmins and work on infr…

That's when it clicked for me.. comparing my hourly salary rate vs. the cost of running these services "in the cloud." Entirely eliminating "system administration" from my duties was absolutely a net win for me and our team.

My brother is a CPA running a practice solely focused on auditing and optimizing cloud expense.

The amount of money set aflame is astounding.

You don’t go cloud to save money. You go cloud to get flexible and reduce capital expense. It’s like leasing a building vs buying. More about tax and accounting.

Re: Reclaiming the lost art of Linux server administration

#226

Earlier quoted context omitted.

> Entirely eliminating "system administration" from my duties... ... and adding "cloud administration". What is it with people doing completely one-sided analysis even when they experiment the thing by themselves? Is cloud administration less time consuming than system administration? That's not my experience, so I'm quite interested on how it got so.

> Is cloud administration less time consuming than system administration? Infinitely, and if you look at it from a startup lens it only makes sense. One needs to point only at the recent log4j incident. This is obviously a gigantic black swan event, but even just ongoing security patching at the OS level can be a full-time gig. There is absolutely no substitution for being able to ship code to a platform that just ru…

> in the future, 100% of the code that you write will be business logic

How much business logic is there across all businesses?

I'm aware of a joke at Google about how it could reduce 90% of the employees without any impact on the business.

Re: Reclaiming the lost art of Linux server administration

#227

Earlier quoted context omitted.

Rent a $5 VPS, run a VPN tunnel from your lab to that box, and run a reverse proxy on it. You'll get some additional latency, but that's about it.

Caution: you may end up with your packets blackholing on the way for unknown reasons after temporary loss of connectivity. I think it might have something to do with the NAT forgetting about my UDP "connection", but haven't found the culprit yet.

Could be because you’re using a terrible ISP-provided router. Switch that to bridge mode and connect the server directly (if necessary, use the server as a router with a second network card for your LAN) or use a proper, enterprise-grade router (OpenWRT would work as well as long as the underlying hardware is performant enough).

Re: Reclaiming the lost art of Linux server administration

#228

Honestly after discovering NixOS I have a new found joy of administering Linux servers. It's easy and painless, everything is declarative and versioned, and new machines can be set up for new projects or scaling in a matter of minutes. This "cattle not pets" mentality doesn't make sense for everything and is highly inefficient if the OS itself seamlessly supports immutable workloads and configuration.

When it comes to server admin, nothing is painless. You just may not know where you're bleeding yet.

Re: Reclaiming the lost art of Linux server administration

#229
post #34

When my SaaS app started scaling, I saw how badly cloud can be priced if you have even slightly unusual use-cases. It occurred to me that instead of spending ~$600/mo on GCP, I can invest in a $3000 PowerEdge server with much better hardware, run it out of my home office, and it pays for itself in less than a year. Running your own server is an investment that doesn't make sense for everyone. If you can get it, it is…

> I can invest in a $3000 PowerEdge server with much better hardware And when some component of the server fails, your app is unavailable until you can repair it. So you need another server for redundancy. And a load balancer. And a UPS. And a second internet connection. If your app is at all critical, you need to replicate all of this at a disaster recovery site. And buy/run/administer DR software. And hardware has…

>And when some component of the server fails, your app is unavailable until you can repair it. So you need another server for redundancy. And a load balancer. And a UPS. And a second internet connection.

Most applications don't actually have a four 9s uptime requirement. Like, how many otherwise healthy businesses closed up shop during the cloud providers we've seen in the last year because they didn't have their stuff implemented and deployed such that it would remain fully functional when these issues happen?

Re: Reclaiming the lost art of Linux server administration

#230
post #151

Earlier quoted context omitted.

Unless you actually look at real Linux deployments, which are: #!/bin/mksh Android doesn't allow GPL code in userland, and the installed base is massive.

> Android doesn't allow GPL code in userland, and the installed base is massive. You aren't administering Android devices. Stop obsessing about writing portable scripts. Write scripts for the targets that you are going to run them on.

I run Lineage, and use a number of scripts.

Stop ignoring standards. They exist for important reasons. Invent your existentialism in some other realm.

Post reply on HN